Databases Reference
In-Depth Information
whether a given attribute can take one or several values for the same
entity occurrence) and entity identifiers. For example, knowing that
Social Security numbers identify employees and knowing that each
employee has a single address, we can derive that the Social Security
number determines the employees address. We can use the same
key and cardinality constraints to infer independencies.
Combinations of all those inference rules reduce the number of potential
questions to ask the user, because answers to the questions can be automati-
cally derived.
Learning From Small Examples
Given a relation schema and a set of tuples for the relation, we can infer
from this example whether some functional independencies hold between
two different attributes. For example, from the extension of the relation in
Figure 13.14, we can easily derive that the following functional independen-
cies hold: {Author
¤®
Title,Editor,Date; Title
¤®
Author; Editor
¤®
Title,
Author,Date}.
This technique is based on the idea that domain expert users are not
familiar with the concept of functional dependency, so example is one of the
different ways to acquire this knowledge.
Mining Dependencies From Existing Files or DBs
Many current DBs are built from legacy files or DBs, in which there exist not
only a small sample of tuples but most of the real-world images representing
the application. Exploiting huge amounts of real tuples cannot be done
by the simple techniques presented in the preceding paragraph. Advanced
techniques based upon data mining algorithms have already been suggested
in the literature [13]. While exploiting a few examples leads to discovering
independencies, mining a large number of instances aims to find valid
dependencies.
Author
Title
Editor
Date
A1
T1
E1
D1
A2
T1
E1
D1
A2
T2
E2
D2
A3
T3
E2
D3
Figure 13.14
Learning from examples.
