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. Please do a search for "Time and Time Again" on www.dmreview.com for a list of previous articles in this series.
We will proceed now to a discussion of original and temporal inserts, and will explain how the temporal correlates of entity integrity and referential integrity apply to them.
Inserting a Versioned Object: the Original Insert Transaction
When businesspeople issue 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 that 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 1.
Inserting a Versioned Object: Temporal Entity Integrity Constraints
When a conventional table is the target of an insert, the transaction is invalid if a row representing that object already exists in the table. This reflects the tacitly understood semantics of the transaction, which is that its creator is claiming that he knows that no such row already exists in the table. Note that a row for that object may have existed in the table at some point in the past. But if it was deleted prior to the insert, it has no effect on the insert, and the insert may proceed. The constraint which enforces these semantics against relational tables is known as the entity integrity constraint.
What are the corresponding semantics when the target table is a versioned table? To the user, of course, i.e., to the author of the transaction, there is no difference. She neither knows nor cares whether the target table is versioned or conventional. But consider the situation just mentioned, in which a row for the object being inserted did exist in the table at some point in the past but was deleted prior to the insert. In a conventional table, the delete means that, at the time of insert, no such row exists in the table. But in a versioned table, a versioned delete of the object means two things. It means that at the time of insert:
