Information Technology Reference
In-Depth Information
former could require the latter (implication). The second data sample implies
that the only remaining potential configurations for
Title
or a
Birth date
is
at-least-one, or that the former requires the latter.
We also analyse each potential
functional dependency
to check if there is a
conflictual tuple among the previously provided tuples, i.e. if an existing tuple
has the same left-hand side but a different right-hand side when considering the
components of the functional dependency. If such a conflictual tuple exists, the
functional dependency is discarded and alternatives are recursively generated.
First of all, this implies that the right-hand side may be too large with respect
to left-hand side, and we therefore consider smaller right-hand sides by remov-
ing a component. The removed component may be purely dismissed, or added
to the left-hand side to consequently generate two alternatives per component.
For instance, the first data sample doesn't jeopardize the potential functional
dependencies, but the second data sample discards the FD
F
2
and generates the
alternatives
F
21
,
F
22
,
F
23
,
F
24
and
F
25
of Fig. 3. The second data sample then
discards the FD
F
4
and generates its subsequent alternatives.
Understanding the implications of a functional dependency is not always triv-
ial and easy to grasp. Presenting the end-users with automatically generated
data samples that would contradict the validity of existing functional dependen-
cies therefore helps them to visualise the relevance of these dependencies, while
reducing the number of tuples that they would need to provide by themselves. As
we can observe, a tuple
t
is actually problematic for the functional dependency
f
:
X
t
∈T
:
t
[
X
]=
t
[
X
]
t
[
Y
]
=
t
[
Y
].
If we already have several tuples in the tuples set of a given entity type, we gen-
erate problematic data samples for a given dependency by putting together pre-
viously provided data samples. Accepting such a generated data sample would
imply discarding the associated functional dependency and generate alternatives.
For instance, considering the functional dependency
F
23
, we generate the prob-
lematic tuple illustrated in Fig. 6 from the composition of the second and third
data samples of Fig. 4.
Finally, potential
unique constraints
are again induced from validated and po-
tential functional dependencies, using the same principle than during the initial-
isation of the process, i.e. the left-hand side of a functional dependency involving
all the components of a given entity type is a potential identifier for that entity
type.
→
Y
and the existing set of tuples
T
if
∃
∧
4.4 Acquiring Constraints and Dependencies
Another way to take advantage of user input is to directly acquire validated
or discarded constraints and dependencies, whenever they are trivial and easy
to express for the participants, and to invite them to arbitrate the potential
constraints and dependencies that could be suggested after the acquisition of
multiple data samples. The end-users should indeed be able to directly spec-
ify validated or discarded constraints and dependencies, even without look-
ing at possible suggestions. To be accepted as validated, a given constraint or
