Databases Reference
In-Depth Information
Deferred Assertions and Temporal
Referential Integrity
Deferred update and delete transactions, like their non-
deferred cousins, lock matching assertions that were already in
the database at the time those transactions were carried out. It
locks them by giving them a non-12/31/9999 assertion end date.
In the case of a non-deferred update or delete, these locked
assertions exist in past assertion time. But in the case of a
deferred transaction, the locked assertions remain in current
assertion time, and their assertion time periods [meet] the asser-
tion time periods of the deferred assertions that replace or
supercede them.
When an approval transaction is applied to a group of
deferred assertions, those assertions are moved backwards in
assertion time, usually to just a few clock ticks later than the cur-
rent moment in time. Then, with the passage of those few clock
ticks, those deferred assertions become current assertions.
In moving backwards in assertion time, those approved
assertions override any locked matching assertions. In overriding
them, it “sets them to naught” almost literally, by setting their
assertion end dates to match their assertion begin dates, thus
moving them into empty assertion time.
But there is one last issue to deal with. We have emphasized
that semantic constraints do not exist across assertion time per-
iods. But if a TRI child managed object is moved backwards into
an earlier period of assertion time, one which begins before the
assertion time period containing its parent managed object, then
the TRI relationship between them will be broken. The assertion
time movement will make the child managed object a referential
“orphan” until the passage of time reaches the beginning of the
assertion time period of the parent managed object.
So the AVF must block any such movement, or else insure
that as part of the same atomic and isolated unit of work, parent
and child managed objects are moved together so as to preserve
the referential relationships.
It turns out that this isn't always easy to do, especially when
the related managed objects exist in different deferred assertion
groups. The problem is that, as long as an approval transaction
is not applied, the assertion time of any TRI deferred parent is
guaranteed to include the assertion time of all of its deferred
children. But by applying an approval transaction, we may
break the inclusion relationship by moving the start of the
assertion time of the approved children to a date prior to the
