Note: A glossary of technical terms used in these articles can be found on the Web sites 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. Here is what we've done so far.
(See PDF below for Figure 1: Chart of Installments to Date in this Series.)
Beginning with Part 19, we interrupted our presentation of the physical implementation of the versioning patterns, which we described earlier in the series, and began a discussion of temporal integrity constraints. On completing Part 24, we had introduced and defined temporal RI and related concepts, and discussed these constraints as they apply to delete and to update transactions. In this and the following article, we turn to temporal integrity constraints as they apply to insert and to upsert transactions.
The "ultimate" versioning pattern we are working toward is what we, following the computer science community, call a "bi-temporal" pattern. In Parts 19 through 25, we have been discussing both temporal entity integrity and temporal referential integrity constraints. But it is important to note that these discussions have taken place in the context of a "uni-temporal" pattern. The only time period considered has been an effective time period, and the only dates an effective begin and effective end date.
As we have seen, integrity constraints in a uni-temporal versioning context have been far from simple. As we will see, integrity constraints in a bi-temporal versioning context are considerably more complex than that.
Inserting a Versioned Object: the Original Insert Transaction
To the business, when they are issuing an insert of an object, they don't care if the object is versioned or not, and indeed may not know. They are directing us to insert a row representing an object which is not already represented by a row in the target table. Thus, an original insert transaction doesn't need to specify a version, just the object being inserted, its business key, whether or not match logic should be applied, and the date the insert is to take effect. This is illustrated in Figure 2.
As we have pointed out before, we are using dates throughout these articles only for convenience. The approach to versioning which we are presenting here applies no matter what the granularity of the clock ticks that measure out time. The granularity used here would be the correct granularity for transactions taking place in batch mode and being applied at most once per day. As soon as online individually applied transactions are involved, however, we would need a finer granularity, such as a full timestamp.
Figure 2: An Original Insert Transaction
