Note: A glossary of technical terms used in these articles can be found on the Web sites of the authors. In addition, a listing of earlier articles and/or columns in this series can also be found on DMReview.com, MindfulData.com and InbaseInc.com.
The past six columns illustrated an asserted versioning original insert, update and delete and, in the last column, introduced a taxonomy to guide the remainder of our work. Figure 1 shows that taxonomy. The transformations we have already covered in scenario 1 are shaded. These three transformations are the most basic ones in the sense that they correspond to inserting, updating and deleting in non-temporal tables.
Figure 1: Asserted Versioning State Transformations - Three Complete, Five to Go
In scenario 1, however, we did not discuss integrity constraints. In particular, we did not discuss temporal entity integrity and temporal referential integrity constraints. Our intent is to cover the remaining five transformations in the same manner. We will then go back and discuss how temporal entity integrity checking is done and how temporal referential integrity checking is done for each one for all eight state transformations.
In this installment, we will continue working through our taxonomy by discussing the transformation in which an episode is extended backward in effective time.
When an episode of an object is extended backward in effective time, the start of the episode is being moved to an earlier time. If the episode in question is a future episode, (i.e., one with an effective begin date still in the future) then a backward extension might leave its effective start time in the future (but earlier than it had been), might set its effective start time to the present moment or might extend its start time to a past point in time. But the typical case is when we realize that a current episode needs to be extended backward. Figure 2 shows such an episode, one that began on 8/01/04.
Figure 2: Extending Backward - Before Image
The original update transaction is being applied to the database on 11/01/04 and specifies the creation of a version with an effective period from 4/01/04 to 8/01/04. Because the transaction specifies an effectivity period that begins in the past, we will call it a retroactive update.
Because this is an update, it means that we intend to alter an existing episode. Because an episode consists of contiguous versions of the same object, the transaction must add a version that is contiguous with the episode on either its effective begin date its effective end date, or both. These three cases correspond, respectively, to extending an episode backward, extending a closed episode forward, or merging two adjacent episodes. At this node in our taxonomy, we are discussing the last case.
Figure 3: Extending Backward - After Image
After the update is applied, the database is as shown in Figure 3. The episode, as asserted from 8/01/04 to 11/01/04 (row 1's assertion begin and end dates) consists of row 1 and nothing else. Its episode begin date is the same as the begin date of its earliest (and only) version - the version represented by row 1.
But starting on 11/01/04 (the assertion begin date for rows 2 and 3), the episode consists of two versions that, in effective time sequence, are rows 2 and 3. Note that, as with any relational database table, the physical sequence of its rows carries no meaning. Its episode begin date is the same as the begin date of its earliest currently asserted version - the version represented by row 3.
Graphically, our diagramming convention becomes a little more complex as soon as assertion begin dates are not identical to effective begin dates.
- Row 1. The green arrow and red bar in the shaded area represent the version that was superceded by the update. This version is preserved because it has the original episode begin date on it, 8/01/04. It is shaded to indicate that it is no longer a currently asserted version. We no longer claim that it is correct.
- Row 2. The green and red arrows below the shaded area represent the version that superceded the row 1 version. This version is identical to that represented by row 1, except for the episode begin date.
- Row 3. Like row 2, this row shows a version with an assertion begin date of 11/01/04. It can become graphically confusing to represent complicated scenarios in which a version's effective and assertion begin dates are far apart. The clearest way we can think of to graphically represent such situations is to place an arrow representing an assertion begin date above the shaded bar in the diagram and use a dotted line to associate it with its version.
Correcting Versus Extent-Altering Transactions
All three cases extend an episode into ranges of effective time that, prior to the transaction, the episode did not include. The entire taxonomy is concerned with state transformations that alter the effective time extent of an object, either shrinking it or expanding it. We may also have update transactions that wholly or partially overlay effective time extents, changing the business data of an episode by those overlays. These we may naturally call corrections, and we defer consideration of them until later.
In this third case, the end date on the transaction's version must have the same value as the begin date of the episode. If the version's end date were greater, the new version would "overlap" one or more versions of the episode it is extending and (because this update is not designated as a correction) is invalid. In fact, it is a violation of temporal entity integrity, an issue we will discuss later. On the other hand, if the version's end date were earlier, it would leave at least one clock tick between its effective end date and the effective begin date of the episode, violating the version contiguity rule for episodes.
So on a noncorrecting update that extends an episode backward, the effective end date specified on the transaction is equal to the effective begin date of the initial version of the episode it is extending. This equality of date values eliminates any clock tick between them and thus, by definition, guarantees that they belong to one and the same episode. In addition, as is the case with any version that is created, that version's effective begin date must be at least one clock tick earlier than its effective end date. In other words, versions are extents in time, never points in time.
One final point about correcting transactions: Because by definition they do not alter the effective time extent of episodes, they can be applied without checking temporal entity integrity or temporal referential integrity constraints.
A Note on Merging and Splitting Episodes
The second way an episode of an object can be extended backward in effective time is by merging with a prior episode. An example would be updating a policy episode whose effective begin date was 6/1/08, when there is an earlier episode for the same object with an effective end date of 2/01/08 for example. This would be done with an original update that specified an effective period of 2/01/08 to 6/1/08. As with all episode extensions, the transaction will be invalid if it causes the episode being extended to collide with another episode of the same object in effective time. This no collision rule is in fact the constraint we call temporal entity integrity.
The process of extending an episode forward in time may also merge an episode with an adjacent episode. So together, if we ignore overlapping correction transactions for the moment, these are the only two ways to merge an episode. Episodes are merged when and only when the effective time gap between them is filled in. Viewed from the perspective of the earlier episode, it is a forward extension. Viewed from the perspective of the later episode, it is a backward extension.
By the same token, truncating an episode can cause it to split. This will happen when and only when: the effective end date of a non-terminal version of an episode is truncated and the truncation begins at least one clock tick after the start of the episode, the effective begin date of a non-initial version of an episode is truncated and the truncation ends at least one clock tick before the end of the episode, or both. We will examine split and merges in the next column.
Figure 4 shows our updated state transformation taxonomy. Four terminal nodes are now shaded, with four to go. Keep in mind that this taxonomy does not exhaust all the transformations possible on asserted version tables, but it does drain all the transformations for which we will later have to apply temporal entity integrity and temporal referential integrity checking. This is because it exhausts all the transformations that can alter the effective time extend of an episode.
Figure 4: Asserted Versioning State Transformations - Four Complete, Four to Go
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
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access