Integrity constraints
Uniqueness
constraint
Definition: Each time an n-tuple is created, the
uniqueness constraint makes sure the value of the primary key does not already
exist.
The preservation
of the uniqueness of a table's primary key is an integrity constraint which has
already been dealt with using a "unique index".
Referential
integrity
Definition: Inter-table constraint, which consists of the
imposition that the value of a group of attributes of a first table should
appear as key value in a second table.
This integrity
constraint, which generally only applies to associations, specifies that an
association instance can only exist if the entities which take part in this
association already exist. It is set up through the re-definition of outside
keys that have an impact on the updating operations. When an association
element is inserted, it is necessary to check that the referenced elements do
exist. Similarly, when a referenced element is deleted, it is necessary to
check that the element no longer exists in the association (or, depending on
the case, to destroy the corresponding association instance).
Example

Figure 52. Example
of associations with integrity control
The mapping of the "belong" and "localization" associations
introduces several reference integrity constraints:
·
any value
of the HIS_SERVICE attribute appearing in the EMPLOYEE table should be
described in the SERVICE table
·
any tuple
of the BUILDING_LOCALIZATION_SERVICE and SERVICE_LOCALIZATION_BUILDING, must
reference a tuple of the BUILDING table and a tuple of the SERVICE table
Consequences
Referential
integrity constraints are used to check consistency during extraction from and
insertion into the table that represents the association.
A ban is imposed during the deletion of an instance referenced by an outside
key, or during insertion into a table representing an association of keys which
references instances which do not exist. The implementation of these
constraints depends on the RDBMS used.
The effect of the integrity constraints can be modified using tagged values
specific to the RDBMS, such as {onDeleteCascade}.
Generalization and
constraints
Between classes
which have children, constraint generation on association tables differs
according to the chosen generalization mode:
·
one table
per concrete class
·
one table
per class
One table per
concrete class

Figure 53. One table per concrete class
The SQL tables generated are as follows (Figure 54):

Figure 54. The SQL tables generated with one table per concrete class
One table per class

Figure 55. One table per class
The SQL tables generated are as follows (Figure 56):

Figure 56. The SQL tables generated with one table per class
"Not
null" attributes
In addition to
the "not null" deduced from the model (constraints on keys,
association multiplicity ...), the user may define locally that a particular
attribute must always be entered in a database, using the
<<notNull>> constraint.
Integrity tagged
values
The code
generated ensures the database is complete, but if it must be used by other
sources, specific reflexes have to be added, such as on delete cascade (see the
appendix specific to the RDBMS used).