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
C,
an object of type D is destroyed.
A referential integrity constraint also implies two change dependencies:
An object creation dependency: an object with a reference to another object can only be created after the referenced object has been created.
An object destruction dependency: an object that is referenced by another object can only be destroyed after
the referencing object is destroyed first, or
the reference in the referencing object is either dropped or replaced by a another reference.
For every reference property in our app's model classes, we have to choose, if we allow the deletion of referenced objects, and if yes, 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.