In previous columns, we completed a proactive update transaction against an open episode. This time, we complete our discussion of a proactive update against a closed episode.
Figure 1 shows a closed episode, with a known effective end date. It is the same as the effective end date of its most current version, which happens, in this case, to also be its only version. The episode begins in effective time, on January 1, 2008 and ends on December 31 of that year. The current time in the example is May 1, 2008.
Figure 1: A Closed Episode and a Proactive Update - Before Image
This transaction will do a couple of things. First, it will update the episode's type and co-pay amount, effective August 1. Next, it will extend the effective time of the episode out to March 1, 2009. These are the two override dates specified on the transaction. But because no override is specified for the assertion begin date, these changes will be asserted immediately.
Let us be clear about what is happening. The changes to type and co-pay are not going to take effect immediately. Also, the extension of the episode to March 1 is not going to take effect immediately. What will happen immediately is that we will begin to assert that the current episode of policy P861 will have a type of point of sale and a co-pay of $10 beginning on August 1 (three months from now). And, on that same date, the end date for this episode of the policy will change from December 31 to February 28.
If this were a conventional table, we would talk about the policy itself. And so our discussion of these transactions may be a little easier to follow if we talk about their targets as policies rather than as episodes of policies. This terminological shorthand, however, doesn't really change anything. There is no such thing in an asserted version table as an object with no episode; there cannot be a policy but no policy episode. Additionally, if there are multiple episodes of an object, we always know which episode we are talking about, because the three asserted version dates that are specified or defaulted to on a transaction will always pick out a unique episode.
With this in mind, we can rephrase a couple of the things we said above as follows. This transaction will update the policy's type and co-pay amount, effective on August 1. Next, it will extend the effective time of the policy out to March 1, 2009. And, what will happen immediately is that we will begin to assert that policy P861 will have a type of POS and a co-pay of $10 beginning on August 1, and on that same date, the end date for that policy will be changed from December 31 to February 28.
Withdrawing the Current Assertion
Figure 2: A Closed Episode and a Proactive Update - Current Assertion Withdrawal
We begin to implement the original update transaction with the first temporal transaction resulting from the mapping of that original update. This first temporal transaction withdraws an assertion currently in the table that is no longer true. As Figure 2 illustrates that assertion is the one made by row 1 - the assertion that the business data in that row describes policy P861 from 1/01/08 to 12/31/08. Because the original update transaction specifies changes that will take effect on 8/01/08, the assertion made by row 1 is no longer true.
We withdraw row 1 on the same date that we begin to assert what is going to replace it. That date is the current date, 5/01/08. The withdrawal is carried out by overwriting the assertion end date that was on row 1 and replacing it with the date 5/01/08. This says that we stopped making this assertion yesterday, on April 30.
We continue the graphical convention described in earlier articles, with respect to withdrawn assertions. The box representing that row is moved up into the gray area over the calendar line, and because the assertion time no longer extends into the indefinite future, we change its representation from an arrow to a line. That assertion line is shown ended on 5/01/08.
Asserting Its Before-Image Replacement
Having withdrawn our assertion of the current version of the episode, we now insert its replacement. We are going to replace it with a version that extends to when the new version will go into effect (August 1). The business data will be the same as it was on the version we just withdrew, because the update leaves that data unchanged until August 1. This before-image replacement is shown in Figure 3.
Figure 3: A Closed Episode and a Proactive Update - Before-Image Replacement
Part of the effective-time gap created by the withdrawal has been filled by a newly asserted version. The remainder of that effective-time gap will be filled by another newly asserted version - this time a version that represents the results of applying the update.
Asserting Its After-Image Replacement
Figure 4: A Closed Episode and a Proactive Update - After-Image Replacement
Figure 4 shows the results of the database management system applying the last temporal transaction, the one that creates a version that reflects the specified update. Prior to 5/01/08, row 1 filled the effective time period 1/01/08 to 12/31/08 for policy P861. Beginning on 5/01/08, rows 2 and 3 replaced row 1 in current assertion time, filled that same effective time period and extended it forward. Row 2 contains the same business data as row 1, because it is the image of that data before the update is applied. Row 3, on the other hand, has different business data, because it is the image of the data after the update is applied, an update with 8/01/08 as an effective begin date.
Viewing Asserted Version Tables
As with all asserted version tables, this one is the physical amalgamation of a series of states of the table. We propose that nearly all access to asserted version tables be through views that include various filters. The most common view, of course, would be the current state of the table. That is materialized (or virtualized) with a CREATE VIEW statement that includes the following clause:
WHERE asr-beg =< CURRENT-DATE AND CURRENT-DATE < asr-end
Figure 5: Two Views of an Asserted Version Table
Figure 5 shows us two views of this table. With three of the columns dropped, this view will present the uni-temporal version table shown above the vertical line prior to May 1. Beginning on May 1, the same view statement will present the version table shown below the vertical line. Notice that the two tables say two different things about what P861 was like during 2008. The first table says that it was an HMO policy with a $15 co-pay through the entire year. The second table says that it was an HMO policy with a $15 co-pay until August of 2008, at which point it became a PPO policy with a $10 co-pay for the rest of the year. If this had been any of the types of version table analyzed in the early installments of this series, we could not have kept both the original state of the table and the state that succeeded it on May 1. It is bi-temporality that gives versioning this capability.
Figure 6: Where We Are
Figure 6 shows our taxonomy of asserted version state transformations. We have now reviewed the major ways in which episodes can be extended forward in time. Next time, we will begin a discussion of original transactions that merge two episodes into a single episode.
Note: The authors are writing 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