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.
Backward Extension
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.
Be the first to comment on this post using the section below.