On examining constraints {SC 3-5} and {SC 3-6}, we found no differences. These constraints apply, without modification, to Pattern 5. This brings us to the last two constraints for Pattern 3. Do they also apply to Pattern 5? Except for the minor rewording of {SC 3-1} and dropping {SC 3-4}, are the semantic constraints for Pattern 5 exactly the same as those for Pattern 3?
Chart of Version Patterns
Before continuing, we insert here the current chart of version patterns. References back to earlier patterns are happening pretty frequently now, and we hope this will help the reader recall what those prior version patterns were like.
Figure 1: Chart of Version Patterns
The Importance of Semantic Constraints
Before we proceed, let's remind ourselves of the importance of explicitly listing the semantic constraints for each pattern. There are two reasons for doing so. The first is that, together with the schemas for each pattern - the columns used to implement the pattern - these constraints are the formal and fully explicit definition of each pattern.
The scenarios show how each pattern works. The diagrams provide useful visual representations of what is going on. But the constraints and the schemas are the patterns.
The second reason for explicitly listing semantic constraints is that we will have fully and correctly implemented a version pattern if and only if a) we include the versioning columns defined for the pattern in all tables we wish to version; b) we enforce each of these pattern-specific constraints; and c) for all version patterns, we implement what I will call "temporal referential integrity."
Entity integrity constraints - the uniqueness of primary keys - are still enforced by the DBMS. But, as we shall see later on, we cannot use the DBMS to enforce referential integrity. When standards committees stop squabbling and produce a temporal data management standard, and then when vendors implement that standard, it is to be hoped that "temporal referential integrity" will be enforced by the DBMS. But because we are still in the "do it yourself" period, as far as the evolution of temporal database management is concerned, that's what we will have to do. We will have to implement temporal referential integrity ourselves, and also the specific constraints that define each version pattern. That means, in most cases, that we will have to write code. In general, that code will be written as before-insert triggers.
But this is getting ahead of ourselves. For now, let's wrap up Version Pattern 5 by looking at its last two semantic constraints.
Semantic Constraints {SC 3-7 and 3-8}
Constraints 5 and 6 apply to initial versions of objects. For Pattern 3, these are the versions that implement the insert of a new object. For Pattern 5, these are the versions that implement the insert of a new episode of an object. Inserting a new object is thus a special case of inserting a new episode of an object. It is the special case of inserting an initial episode of an object.
Constraint 5 applies to the effectivity begin date, and constraint 6 to the logical delete date. Constraints 7 and 8 apply to the same pair of dates, but implement versioned updates rather than versioned inserts.
{SC 3-7} states the constraint on the effectivity begin date. It says of any noninitial, non-logical-delete version of an object, that "its ver-beg-dt must be at least one clock tick past the ver-beg-dt of the immediately prior version for the policy. If it is not, then the two versions will overlap for at least one clock tick. But that is invalid because there cannot be two versions of the truth at any given point in time."
This constraint also applies to Pattern 5, and for exactly the same reason. However, in reviewing Pattern 3, we have discovered that constraint 7 is a corollary of constraint 1. Constraint 1 states that "If a (non-terminal) version for an object is followed by another version for that same object, the end date of the former version must be one tick of the clock prior to the begin date for the latter version." This is the same thing as saying that "... the begin date of the latter version must be one tick of the clock later than the end date for the former version." If it must be one tick of the clock later, then it follows that it "must be at least one tick of the clock" later.
So constraint 7, first of all, should have said "exactly" instead of "at least." But in either form, it is not a distinct constraint because it follows from constraint 1. If code implemented constraint 1, there would be no need for additional code to implement constraint 7.
