Note: A glossary of technical terms used in these articles can be found on the websites of the authors. The URLs are MindfulData.com and InbaseInc.com.
This glossary is being constructed as a controlled vocabulary. By that we mean that any expression involving temporal concepts which is used in the definition of a glossary entry must itself be a glossary entry.
One reason for being this careful with definitions is that this kind of rigor must be applied to definitions before they can be "ontologized," i.e., expressed in a formal notation like first-order logic. That, in turn, is what is needed to make definitions available for manipulation by software-realized inferencing engines.
Another reason for being this careful with definitions is that this is the kind of rigor that must be applied to any set of technical definitions before we can claim not only that we say what we mean, but also that we know what we mean when we say it.
As this series continues, context becomes increasingly important so that the thread of the discussion is not lost. We begin by updating our chart of installments, which last appeared in Part 13.
(See PDF at the end of this article for a chart of installments to date in this series.)
With Part 19, we interrupted our presentation of the physical implementation of the versioning patterns that we developed in earlier articles in the series and began a discussion of temporal referential integrity (TRI). On completing Part 23, we had introduced and defined TRI and related concepts, and discussed TRI as it applies to deletes and updates. We now turn to TRI as it applies to inserts.
Updating a Versioned Object: When TRI Checking Does Not Come Into Play
Last time, we described a temporal update in which a current version of a client was superceded by a new current version in a client version table. We also alluded to a TRI dependent policy version table, in which every policy was owned by exactly one client. So if the client version that was superceded owned one or more policies, doesn't that mean that we must either block the supercession, set null the references in the policies, or else cascade update them to point to the new version of the client?
To raise the question is to begin to see the outline of the answer to it. Those policies –versioned or not – do not point to the superceded client version, because versioned tables are not referenced by foreign keys; they are referenced only by object foreign keys (OFKs), which point to the referenced object but do not point to any specific version of it.
Let's think about the situation in terms of what is going on in the real world, not simply in terms of what is going on in the database. In the real world, policies are owned by clients. As those policies change over time, or as the client that owns them changes over time, those claims are still owned by those clients. This last sentence, translated into the language of database activity against versioned tables, reads like this: even as versions of those policies are superceded by newer versions, or as versions of the client that owns them are superceded by newer versions, those policies are still owned by those clients. Versioning of either or both objects has no effect on the ownership relationship between them.
But because we are dealing with a temporally qualified relationship, there is a proviso. Versioning of either or both objects has no effect on the ownership relationship between them, provided that the superceding version of a TRI child (parent) object has an effectivity period that is wholly contained within (wholly contains) the effectivity period of all objects it is a TRI child of (a TRI parent of).
