Referential integrity

Integrity and integrity constraints

References are important information items in our application’s database. However, they are only meaningful when the application maintains its referential integrity. This requires that for any reference, there’s a referenced object in the database. Consequently, any reference property p with domain class C and range class D comes with a referential integrity constraint that has to be checked in the following circumstances:

1. A new object of type C is created.
2. The value of p is exchanged for an object of type C.
3. An object of type D is destroyed.

A referential integrity constraint also implies these two change dependencies:

1. An object creation dependence, which is an object with a reference to another object, can only be created after the referenced object has already been created.

2. An object destruction dependency, which is an object that’s referenced by another object, can only be destroyed if it meets either of the following conditions:

   • The referencing object is destroyed first, which is known as the CASCADE deletion policy.
   • The reference in the referencing object is either dropped through the DROP-REFERENCE deletion policy or replaced by another reference.

3. For every reference property in our application’s model classes, we have to choose which of these two possible deletion policies apply.

In certain cases, we may want to relax this strict regime and allow the creation of objects that have non-referencing values for an ID reference property. However, these types of cases don’t apply to this course.

Typically, object creation dependencies are managed in the user interface by not allowing the user to enter a value of an ID reference property. Instead, the user can only select one from a list of all existing target objects.