Note: A glossary of technical terms used in these articles can be found on the websites of the authors. The URLs are and


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).


Note that this proviso does not distinguish between TRI-mandatory and TRI-optional relationships. It clearly applies to mandatory relationships, but at this time we are not sure whether or not it should also apply to optional ones.


It's time now to see what the "provided that" clause entails.


Updating a Versioned Object: When TRI-Checking Does Come Into Play


Suppose we have a policy whose effectivity period is 1/1/2007 through 12/31/2007, and an owning client whose effectivity period is 1/1/2004 through 12/31/9999. Although "12/31/9999" means "until further notice," it is treated by the database management systems as a real date. Thus, the client's effectivity period wholly contains that of the policy. This is shown in Figure 2.



The graphical conventions used in this illustration are:

  1. The vertical bars constitute a timeline, with each bar representing one month. The timeline runs from Jan 1, 2004 through Dec 31, 2009.

  2. A client and a policy episode are shown, each starting on its effectivity begin date.

  3. The client episode contains four versions, the policy episode three.

    • All versions begin with left-most vertical bars.

    • Adjacent versions share a vertical bar.

    • Versions with a known effectivity end date have a right-most vertical bar indicating that end date. Thus, the most recent version of the policy episode has a 12/31/2007 effectivity end date.

    • Versions whose effectivity end date is not known have an ellipsis in place of the right-most vertical bar and always have an end date value of "12/31/9999."

    • We will call the former kind of episode "closed," and the latter kind "open".

  4. {Now}, relative to the example, is indicated by the black box arrow, pointing to March 1, 2007. So, for purposes of discussing the example, we should assume that it is now March 1, 2007.

  5. The "OFK" labeled crow's foot notation indicates a TRI relationship from clients to policies. Note in particular what this is not a relationship between. It is not a relationship between:

    • A specific client and a specific policy.

    • A specific version of the client and a specific version of the policy.

    • A specific episode of the client and a specific episode of the policy.

    Just as a relationship type is defined on a pair of conventional tables, a temporal relationship type is defined on a pair of tables, at least one of which is temporal.

As long as these effectivity periods do not change, and the policy continues to have an OFK to its owning client, TRI constraints between these two rows remain satisfied. Thus, no updates that leave this OFK and these pairs of dates alone can violate TRI, and therefore no versioning caused by these updates needs to be accompanied by TRI checks. Consequently, there is no TRI performance penalty in such cases.


Suppose that it is now some time during 2007, say March 1, 2007. And suppose that the client's effectivity end date is moved back to 5/1/2007. If no other changes are made to that client, she will be temporally deleted on that date, which will then terminate her current episode. In addition, all versions of all future episodes will be temporally deleted. (Although we are postponing discussion of how future episodes are managed, recall that, as we explained earlier, original transaction authors will think of future episodes as future transactions that are queued up in a virtual "transaction batch file," with the promise that they will be applied on their effectivity date. From this point of view, temporally deleting all future episodes appears to be flushing those not-yet-applied transactions from that virtual batch file.)


Because this new version of the client "shrinks" the client's effectivity time period, TRI checks are required. In our example, there is a policy that is TRI dependent on that client, and that policy's effective end date is 12/31/2007. Since 5/1/2007 is earlier than 12/31/2007, this violates the TRI constraint that the effectivity period of a child version be wholly contained in the effectivity period of the corresponding parent version. From the point of view of the real world, it means that if we let the update proceed, the result would be a database which showed a policy in effect for six months after its owning client was deleted. This situation, a violation of TRI, is shown in Figure 3. The period of time during which TRI is violated is indicated by a red block.



This is an example of a change to the effectivity period of a parent object. If that effectivity period "shrinks," TRI checking is triggered on all its dependents to see that they are not "temporally stranded" by the shrinkage. There is obviously a correlative process when an update changes the effectivity period of a child object. In that case, if the effectivity period "expands," TRI checking is triggered on all its parents to see that they do not "temporally strand" themselves by extending their effectivity range beyond that of one of the objects they are dependent on.


On original updates to versioned objects, then, TRI checks must be done whenever there are TRI dependencies, and effectivity periods are changed. Otherwise, original updates to versioned objects do not trigger TRI checks, and thus do not incur any TRI performance penalty.


There is one more situation in which a temporal update may trigger TRI checking. That is when a {null} OFK in the updated object takes on a real value, or when an existing OFK value is changed. In either case, TRI checking is required to ensure that the effectivity timespan of a version of the newly referenced object wholly encloses the effectivity timespan of the object whose OFK was updated.


With conventional RI, constraints exist to ensure that after any database update, there are no foreign keys with "dangling references," with values for which there is no corresponding primary key in the referenced table. With TRI, constraints exist to ensure that after any database update, there are no object foreign keys with "dangling references," with values for which there is no row in the referenced table for that object whose effectivity timespan wholly encloses the effectivity timespan of the referencing object.


New Terms Added to the Glossary


  • Adjacent versions.
  • Closed episode.
  • Dangling reference.
  • Expanding a time period.
  • Flushing the virtual batch file.
  • Open episode.
  • Shrinking a time period.
  • Temporally stranded objects.
  • TRI (as an acronym for "temporal referential integrity").
  • TRI mandatory relationship.
  • TRI optional relationship.
  • Virtual batch (transaction) file.

Our discussion of TRI, except for a consideration of how future versions are affected by it, is nearly done. Next time, we will discuss TRI for the temporal transactions resulting from original inserts and original upserts. Then we will go on to extend our discussion to consider the effect of TRI constraints on future versions of objects. As we shall see, those considerations are not insignificant.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access