This column discusses proactive updates, updates in which the effective begin date of the version carrying the update lies in the future.
In Scenario 1, we described updates that were forward extensions of episodes. Proactive updates are also forward extensions. The difference lies in default values. In Scenario 1, we accepted the original transaction default values for the effective begin and end dates and the assertion begin date. For all three the default value is the date current when the transaction is physically carried out. In a proactive update, we override the default for the effective begin and date, instead, specify a future date on the original transaction.
So, our taxonomy diagram remains at four transformations completed with four to go, as shown in Figure 1.
Figure 1: Asserted Versioning State Transformations - Four Complete, Four to Go
A proactive update adds a version to an episode with an effective begin date in the future. For such a transaction to be valid, however, the update cannot introduce a gap in effectivity time into the episode. If it did, it would not be updating an episode; it would be creating a new episode. Allowing that to happen would be equivalent to allowing an update against a non-temporal table to be turned into an insert if the target row of the update isn't already in the table. Some database management systems support what is called an upsert transaction, which applies its data as an insert if its target row is not in the table, and as an update if it is.
So we adopt the following rule for asserted version original updates: They are valid only if a currently asserted episode exists with an effective time that is either adjacent to the effective begin date on the transaction or has an effective time that includes that date. We will have more to say about this point later on, when we discuss temporal integrity constraints. For now, as we move through our taxonomy, we will only discuss valid examples of each of the nodes in the taxonomy, leaving the discussion of temporal integrity constraints until later.
Proactive updates can be applied to either open-ended or close-ended episodes. Close-ended episodes have a known effective end date; open-ended episodes do not. Open-ended episodes are fairly common. Whenever we create or update an episode without knowing when the next change to that episode will occur, or when the episode will end, the result is an open-ended episode, one whose episode effective end date (which is the same as the end date of its latest version) has the value 9999.
In this installment of the series, we will discuss a proactive update to an open-ended episode.
A Proactive Update to an Open-Ended Episode
Figure 2 shows an episode, that began on 8/01/04. It is now 3/1/05, and the original transaction specifies that policy P861 will be assigned policy type PPO in exactly three months, on 6/1/05.
Figure 2: Extending Forwards - Before Image
The asserted versioning (AV) Policy table shows one row and, therefore, an episode with one version. The timeline diagram shows the same thing. The table states that the episode began on 8/01/04, and is both currently in effect (on 3/01/05) and will remain in effect "until further notice" (until 12/31/9999). This version was asserted on 8/01/04, and the assertion is in effect now and will remain in effect until further notice. The timeline diagram contains two arrows, both of which begin on 8/01/04, and both of which are current now, and both of which are open-ended (i.e., right-pointing arrows rather than line segments).
Because a proactive update is an update, it is translated into three temporal transactions, just as any original update is. That translation is shown in Figure 3.
Figure 3: Translating an Original Update
All three temporal transactions are asserted on the same date they are physically applied. The only exception to this rule are deferred assertions, whose consideration we have postponed until after all variations on the theme of non-deferred assertions have been exhausted. So the withdrawal of the current assertion - row 1 in Figure 4 - is carried out on 3/01/05, as is shown in that row's assertion end date. And the assertion of row 1's replacement, and row 1's successor (rows 2 and 3, respectively), is carried out on 3/01/05, as is shown in the assertion begin dates of those rows.
Be the first to comment on this post using the section below.