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.

Last month, we completed our first update to policy P861. This month, we will apply a second update. As Figure 1 shows, all original updates are translated into three physical transactions against the target table, which we call temporal transactions. The first of the three is always a physical update; the second two are always physical inserts.

 

 

Figure 1: Scenario 1, Transcation Three - Original Temporal Mapping

 

Figure 2 shows transaction three, and the state of the target table before that transaction is processed.

 

 

Figure 2: Scenario 1, Original Transaction Three - Before the First Temporal Transaction

 

Notice that the two timelines for row 1 have been moved up to the shaded bar above the calendar timeline, and that the assertion timeline is now a line, not an arrow. From these two lines alone, we can determine what the two effective period and assertion period dates are. Both periods begin on 1/01/04. The effectivity end date is 12/31/9999, indicated by the green arrow. The assertion end date is 5/01/04, indicated by the red line.

 

Figure 3 shows the state of the target table after the first of the three temporal transactions has been applied.

 

 

Figure 3: Scenario 1, Original Transaction Three - After the First Temporal Transaction

 

The three columns with headings are shaded gray columns that cannot appear in original transactions. However, as we will see later, they are columns that can be specified in queries. First, an assertion end date is always set to 12/31/9999 when an asserted version row X is first inserted. It retains that value unless and until a later temporal transaction inserts a row Y with an effective time period wholly or partially overlaping that of row X, in which case, the 12/31/9999 assertion end date of X is overwritten with the same value used for the assertion begin date of Y.

 

When the effective time period of Y wholly overlaps that of X, this process is straightforward. When the overlap is partial, it can get a little complicated. But in both cases, what we are doing is correcting an erroneous entry in an asserted version table while retaining the information that the erroneous entry did exist and was returned to queries as the truth during the specified assertion period of time.

 

Second, an episode begin date, on all versions in the same episode, has the same value, and that value is the effective begin date of the earliest version in the episode. This, again, is straightforward except for one case in which an episode is extended backward in effective time by adding an effective time contiguous row to the episode whose effective time period is earlier than that of the currently earliest row.

 

Finally, the column labeled txn contains the date on which the row was physically inserted into the asserted version table. This column is needed in order to be able to recreate the physical state of the table as of any point in time. While the assertion begin date usually has the same value as this transaction date, and in the computer science account of bi-temporality always has the same value, asserted versioning permits assertion begin dates to have any value that do not precede the transaction date.

 

The Second Temporal Transaction

 

The original update will result, when the third temporal transaction is applied, in a version of P861 with an effective begin date of 5/01/04. But what about the effective time period from 1/01/04 to 5/01/04? By withdrawing row 1 (i.e., by moving it into past assertion time) we no longer currently assert anything about P861 prior to 5/01/04. Yet, the purpose of the original update was not to alter anything about P861 prior to 5/01/04. So we need to replace the withdrawn assertion with one that is identical to it, with one exception - instead of an unknown effective end date, it has an end date of 5/01/04. The result is shown in Figure 4.

 

 

Figure 4: Scenario 1, Original Transaction Three - After the Second Temporal Transaction

 

Row 2 is now the only row that exists in current assertion time; it is the only row shown which we currently assert to be true. This row asserts that policy P861, with client, type and co-pay as indicated, was effective from 1/01/04 to 5/01/04. This is the first of the two assertions that should result from the original update transaction.

 

If we had not moved row 1 into past assertion time, inserting the row representing the original update, would have resulted in two conflicting claims about what P861 was like after 5/01/04. Because its effective end date is 12/31/9999, row 1 would have claimed that P861 has a $15 co-pay at any time after 5/01/04. Row 3, on the other hand, would have claimed that, from 5/01/04 forward, P861 has a $20 co-pay. By withdrawing row 1, we avoid this conflict. By replacing it in current assertion time with row 2 we retain the information about P861 that describes that policy prior to 5/01/04.

 

The Third Temporal Transaction

 

Having withdrawn an assertion, and affirmed its replacement, we can now complete the original transaction by asserting its successor. As shown in Figure 5, this is done by physically inserting row 3. Now, this becomes the current version of the current episode for P861, which began on 1/01/04. Because the original transaction specified neither an effective end date nor an assertion begin date, the effective end date defaults to 12/31/9999 and the assertion begin date to 5/01/04, the date of the physical insert.

 

 

Figure 5: Scenario 1, Original Transaction Three - After the Third Temporal Transaction

 

Reading the Timeline

 

In Figure 5, the timeline graphically represents all three rows in the table. Row 1, which has been withdrawn, is represented by the effective and assertion timelines that have been moved into the shaded bar above the calendar timeline. Both timelines for this row begin on 1/01/04. The effectivity timeline is an arrow, corresponding to an end date of 12/31/9999. The assertion timeline is a line that terminates on 5/01/04, the assertion end date of row 1.

 

Row 2 is represented by the first segment in the unshaded area just above the calendar timeline. This segment begins with a vertical bar on 1/01/04, and ends with a vertical bar on 5/01/04. The green effectivity timeline, which is not an arrow, graphically represents an effectivity time period from 1/01/04 to 5/01/04. The red arrow begins on 5/01/04, which is the begin date of this assertion. Because it is an arrow, it indicates a 12/31/9999 end date for the assertion.

 

Row 3 is represented by the second segment in the unshaded area. This segment is open on its right side (i.e., it does not have a vertical bar on that side). An open segment represents a version with an effectivity end date of 12/31/9999. A closed segment represents a version with an effectivity end date that is not 12/31/9999 and identical to the effectivity begin date of its successor version if it is not the latest version of its episode. The two arrows beginning on 5/01/04 represent effectivity and assertion time periods which begin on that date and have a 12/31/9999 end date.

 

Scenario 1, Transaction 3: Semantic Summary

 

Thus far, the description of this original update has been syntactical, a description of the mechanics of what happens in the target table as a result of the transaction. A semantic account of would include the following points:

 

1.   The most common kind of original update - one that is asserted as soon as it is physically applied - is invalid unless a current episode for the object being updated exists in the table at the time the update is submitted. A current episode is one with an episode begin date less than the current date and the latest version has an effective end date greater than the current date.

2.   Conversely, if the transaction submitted on 5/01/04 was submitted as an insert rather than as an update, the encapsulation layer would have rejected it. The reason is that, as of 5/01/04, the episode for P861 was a current episode (i.e. that 5/01/04 fell between its effective begin and end dates). As a current episode, accepting an insert against that object would be semantically equivalent to accepting an insert for a policy P861 whose target table was a non-temporal table and already contained a row for P861.

3.   We can recreate the state of the policy table at any point in time. For example, the table prior to 1/01/04 is empty. At any time from 1/01/04 to 5/01/04, it contains and asserts (returns to queries) row 1. At any time from 5/01/04 to the present, it contains rows 1 to 3 and asserts (returns to queries) rows 1 and 2. Yet, because it retains row 1, the table is still able to answer the question "What would you have returned to a query about P861, if asked prior to 5/01/04?"

4.   The encapsulation layer that translates the original transaction into the three temporal transactions guarantees that the version created by the update is temporally contiguous, in effective time, with the version representing the state of the policy immediately prior to that update.

5.   That same encapsulation layer also guarantees that the version of a policy that was current prior to an update will be moved into past assertion time if any part of its effectivity period overlaps with the effectivity period of the version the update will place in the table.

 

Our original update transaction is now complete. Our next column will discuss an original delete transaction. But prior to that, it is not too early to make the following important point: original transactions as semantic events do not insert, update or delete rows in a table. They do not insert, update or delete objects. They do not even insert, update or delete versions of objects. Rather:

 

  • In the case of an original insert of an episode of an object, they create that new episode by creating a version of the object that has no temporally contiguous predecessor in effective time.
  • In the case of an original update of an episode of an object, they withdraw the current version of the most current episode of the object, replace it with a version similar to it - except that its effective period now ends on the same clock tick as the effective period of the new version begins - and then supercede it with a new current version that reflects the business data on the original transaction.
  • In the case of an original delete transaction, they perform the first two of the three temporal transactions that make up an original update.

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

Don't have an account? Register for Free Unlimited Access