Referential integrity constraint

2.3.2 Referential integrity constraint

The referential integrity constraint says that if a relation R2 includes a foreign key FK matching the primary key PK of other relation R1, then every value of FK in R2 must either

be equal to the value of PK in some tuple of R1 or be wholly null (each attribute value participating in that FK value must be null). R1 and R2 are not necessarily distinct.

The justification for referential integrity constraint is:  If some tuple t2 from relation R2 references some tuple t1 from relation R1, then

tuple t1 must exist, otherwise it does not make sense  Therefore, a given foreign key value must have a matching primary key value

somewhere in the referenced relation if that foreign key value is different from null  Sometimes, for practical reasons, it is necessary to permit the foreign key to accept

null values For example, in our OWNERS relation the foreign key is IdentificationNumber. This

attribute value must have matching values in the CARS relation, because a person must own an existing car to become an owner. If the foreign key has a null value, that means that the person does not yet have a car, but he could buy an existing one.

For each foreign key in the database, the database designer has to answer three important questions:

 Can the foreign key accept null values? For example, does it make sense to have an owner for which the car he owns is

not known? Note that the answer to this question depends, not on the whim of the database designer, but on the policies in effect in the portion of the real-world that is to be represented in the database.

 What should happen on an attempt to delete the primary key value tuple of a foreign key reference?

Database Fundamentals

46 For example, an attempt to delete a car which is owned by a person?

In general, there are three possibilities:

1. CASCADE – the delete operation “cascades” to delete those matching tuples also (the tuples from the foreign key relation). In our case, if the car is deleted the owner is deleted, too.

2. RESTRICT - the delete operation is “restricted” to the case where there are no such matching tuples (it is rejected otherwise). In our case, the car can be deleted only if it is not owned by a person.

3. NULLIFIES – the foreign key is set to null in all such matching cases and the tuple containing the primary key value is then deleted (of course, this case could not apply if the foreign key cannot accept null values). In our case, the car can be deleted after the IdentificationNumber attribute value of its former owner is set to null.

 What should happen on an attempt to update the primary key value of a foreign key reference?

In general, there are also three possibilities:

1. CASCADE – the update operation “cascades” updates the foreign key value of those matching tuples (including the tuples from the foreign key relation). In our case, if the car identification number is updated the car owner identification number is updated, too.

2. RESTRICT - the update operation is “restricted” to the case where there are no such matching tuples (it is rejected otherwise). In our case, the car identification number can be updated only if it is not owned by a person.

3. NULLIFIES – the foreign key is set to null in all such matching cases and the tuple containing the primary key value is then updated (of course, this case could not

apply if the foreign key cannot accept null values). In our case, the car identification number can be updated after the IdentificationNumber attribute value of its former owner is set to null.