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
[IMGCAP(1)]
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.
[IMGCAP(2)]
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.
Be the first to comment on this post using the section below.