Information Technology Reference
In-Depth Information
Fig. 4.
Three data samples for the form of Fig. 2
Fig. 5.
The relation
Person
after the acquisition of the data samples of Fig. 4. The
compound value of attribute
Contact
must be considered as a whole whose unique goal
is to reference a target tuple in the corresponding
CONTACT
table.
the constraints with which the tuple does not agree. Regarding the cardinalities,
we remove the possible mandatory constraints for components that are empty,
and we remove the value type constraints that are not compatible with the
value provided for each attribute and replace the value size if the provided value
is longer. For instance, adding the first data sample confirms that the
Title
is definitely optional, while the
Birth date
potentially remains a mandatory
attribute. The
Zip Code
of a
Contact
can now only be validated as integer, real
or textual. The second data sample still supports
Birth date
being a possibly
mandatory attribute.
Secondly, discarding the potential
existence constraints
that do not stand any
more also consists in removing the constraints with which the tuple does not
agree. Consequently, coexistence constraints are removed if their set of compo-
nents is different from the set of non empty optional components of the tuple.
Exactly-one, exclusion and at-least-one constraints are respectively removed if
there is not one and only one, more than one or less than one of their components
that is not null among the set of non empty optional components of the tuple.
Finally, we remove all the implication constraints for optional components if the
suggested prerequisite components are not part of the non empty components
of the tuple. The first data sample for instance suggests that there could be at-
least one, at-most one or exactly one value of
Title
or
Birth date
, or that the
