Note: A glossary of technical terms used in these columns can be found on the Web sites of the authors. In addition, a listing of earlier articles and/or columns in this series can be found on info-mgmt.com, MindfulData.com and InbaseInc.com. The glossary was recently updated.
In our last column, we began to discuss proactive updates to closed episodes. In earlier columns, we used a diagram to illustrate the mapping of a single original update transaction to the multiple temporal transactions that physically carry it out. But the mapping diagram in the previous column was a little different than the diagram used up to that point. The main difference is that we have generalized the diagram so it represents update mappings that the original diagram did not.
Mapping Original Updates Onto Temporal Transactions
Figure 1: Original Update - Mapping to Temporal Transactions
Figure 1 appeared in several earlier columns, and it shows how asserted versioning creates three temporal transactions when presented with a single original update transaction. The first temporal transaction, the withdrawal, is an update in place to the only current version for the object. This version is the current version of the only current episode for the object.
The update in place overwrites an assertion end date of 12/31/9999 with the assertion end date specified on the transaction. This transaction assertion end date is specified either explicitly by providing a date value on the transaction or it is specified implicitly by accepting the date the transaction is applied as that date value.
The next temporal transaction creates the replacement for the version that has just been withdrawn. This replacement is identical to the version just replaced, except that it is given an effective end date that is identical to the effective begin date specified (either implicitly or explicitly) on the original transaction.
These two temporal transactions clear the decks, preparing the affected episode to receive the new current version specified on the original transaction. If all three asserted versioning dates are defaulted on the original transaction, the new current version will have an effective time period and also an assertion time period starting with the current date and extending to 12/31/9999.
This description is still valid for an original update that affects the current version of an object. But it is not valid for all original updates. For example, an original update might specify an effective time range that began sometime last year and therefore will require multiple versions to be withdrawn. If it is the current episode that is being updated, these versions may or may not include the current version. If it is a non-current episode being updated, there will be no current version to withdraw.
Before we discuss the other changes in our description of original updates and their mapping to temporal transactions, the reader should note that we have changed from talk about assertions to talk about versions. For example, Figure 1 describes temporal transactions in terms of withdrawing, replacing and succeeding assertions. But, our description of it in this column talks about carrying out these activities against versions.
We believe that the new terminology is clearer, but we want to emphasize that it does not invalidate or change anything we have said thus far about temporal transactions, because every row in an asserted version table is both a version and an assertion. With this switch in terminology, there is no switch in the physical rows being discussed.
Figure 2: Original Update - Mapping to Temporal Transactions (revised)
Figure 2 depicts our revised description of the mapping from an original update to the temporal transactions that implement it. Besides describing temporal transactions as affecting versions rather than as affecting assertions, another difference is that the wording now recognizes that an original update can cause more than a single version to be withdrawn and replaced. The reason is that an original update can designate any effective time period for an object - provided that time period begins and/or ends in an episode of that object. It follows that the effective time period specified on an original transaction can cover the effective time period of any number of effective-time contiguous assertions.
We said that the effective time period for an original update must start and/or end in an existing episode of the object being updated. To see why that is so, consider an original update that did not meet this requirement. In that case, the update would specify a period of effective time during which there was no episode for the object being updated. In a conventional table, this corresponds to an attempt to update a row that isn't there. Non-temporal updates are invalid if their target data does not exist in the target table. Temporal updates, by the same logic, require their target data to exist in the target table so that the effective time period on the transaction and on the target table, for the same object, overlap for at least one clock tick.
A third new feature of the revised description is that the wording now emphasizes that replacements for withdrawn versions create a (newly asserted) before-image of those versions, and that the final temporal transaction creates an after-image. As the examples throughout this series have illustrated, the replacements for withdrawn versions contain exactly the same business data as the versions they replace. Thus, they are a before-image of the target table. The difference between them and the versions they replaced is that the replacements adjust the currently asserted effective time periods so that there is a gap into which the version created by the update transaction will exactly fit. But this gap is not a valid state. It is a stage in an atomic update, and that update is not semantically complete until the gap is filled in with the last temporal transaction in the update.
Original Updates That Span Episodes
We said in the previous section that the effective time period for an original update must start and/or end in an existing episode of the object being updated. Although we are getting a little ahead of ourselves in our progress through asserted versioning state transformations, we should note that the episode that contains the original update's effective begin date is not necessarily the same as the episode that contains the original update's effective end date. To understand why, let's look at our taxonomy of asserted version state transformations.
Figure 3: Asserted Versioning State Transformations
We have four possible situations to which an original update can be applied. An original update can:
- Begin in one episode and end in another. This is the merge episode node in the taxonomy. And, although the graphic for that node shows two episodes being merged into one, it is possible, with a single transaction, to merge any number of episodes for an object, provided those episodes are in effective time sequence and no episodes between the first and last are skipped.
- Begin outside an episode and end in an episode. This is the extend episode backward node in the taxonomy.
- Begin in an episode and end outside an episode. This is the extend episode forward node.
- Begin and end in the same episode. This situation is not covered by this taxonomy, because it is a taxonomy only of state transformations that alter the total effective time for an object represented in an asserted version table. There are many transformations that operate completely within a single episode and that do not extend, truncate, merge or split that episode.
An update to an open episode replaces the open version of an episode with two versions. The first is a version that takes the episode up to the point in time at which the update takes effect and represents a before-image to the update. The second is a version that reflects the changes to business data made by the update and that takes the episode forward from that effective time point into the indefinite future. So it was natural to call the first of these two versions a replacement for the original version and the latter of the two a successor to it.
However, this terminology is misleading when used for original updates to a closed episode. The reason is that an update to a closed episode leaves the effective time period of the episode unaffected. The first of the two replacement versions takes the episode up to the point in time at which the update takes effect and represents a before-image to the update. The second is a version that reflects the changes to business data made by the update and is, therefore, an after-image of the update. But, it does not extend the episode forward in effective time; the episode still ends on the same date specified prior to the update. Therefore, it would be misleading to call this second replacement a successor to the original version. The correct terminology is that of a before-image and after-image pair, which together replace the original version. The correct terminology for an update to an open episode is that of a before-image and after-image pair, which both replace the original version together and supersede it, extending it forward in effective time with a version that we call a successor to the original.
We now have a clearer understanding of original update transactions. Originally, we described that type mapping as updating a single row in an asserted version table, adding a replacement row and adding a successor row. We now understand that an original update may affect any number of existing versions - first withdrawing them and then replacing them with a before-image version that makes room for the new after-image version created by the update.
Next time, we will return to our proactive update and complete the transaction.
Note: Johnston and Weis will be publishing a book on temporal data management, based in large part on the material in this series. It will be published by Morgan-Kaufmann, and will be available in the second quarter of 2010.
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