References are important information items in our application's database. However, they are only meaningful, when their referential integrity is maintained by the app. This requires that for any reference, there is 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 whenever
a new object of type
C is created,
the value of
p is changed for some object of type
an object of type
D is destroyed.
A referential integrity constraint also implies two change dependencies:
the referencing object is destroyed first (the CASCADE deletion policy), or
the reference in the referencing object is either dropped (the DROP-REFERENCE deletion policy) or replaced by another reference.
For every reference property in our app's model classes, we have to choose, which of these two possible deletion policies applies.
In certain cases, we may want to relax this strict regime and allow creating objects that have non-referencing values for an ID reference property, but we do not consider such cases.
Typically, object creation dependencies are managed in the user interface by not allowing the user to enter a value of an ID reference property, but only to select one from a list of all existing target objects.