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 be found on DMReview.com, MindfulData.com and InbaseInc.com.
In our last column, we completed our second update to policy P861. In this column, we will apply a delete transaction. As Figure 1 shows, all original deletes are translated into two physical transactions against the target table, which we call temporal transactions. The first of the two is always a physical update; the second is always a physical insert.
Figure 1: Scenario 1, Transaction 4: Original to Temporal Mapping
Notice that the original transaction refers to an object. It says that the policy is to be deleted. Original transactions are the language in which the authors, or originators, of transactions specify changes they want to make to asserted version tables. But in this language, concepts like episodes, versions and assertions have no place. Unless these authors wish to override the defaults for effective and/or assertion times, they will write the same transactions they would have written for non-temporal tables.
Temporal transactions are the physical transactions that insert or update rows in asserted version tables. (There are no physical deletes of rows in asserted version tables.) They are created by a layer of software (which we are currently writing) that translates original transactions into physical transactions against asserted version tables. The targets of these transactions, however, are not objects, nor are they versions or assertions. The targets of these transactions are episodes of objects. Just as transactions against non-temporal tables insert, update or delete individual rows representing objects, transactions against asserted version tables insert or update rows that, as part of effective time contiguous sets of such rows, represent episodes of objects. In doing so, they create, modify or terminate those episodes.
Figure 2 shows transaction 4, and the state of the target table before that transaction is processed.
Figure 2: Scenario 1, Original Transaction 4: Before the First Temporal Transaction
Notice that there are five pairs of timelines - one for each of the rows in the table. The timelines situated in the shaded bar correspond to the shaded rows in the table. These are the rows in which the assertions have been withdrawn, as shown by their non-9999 assertion end dates. Each of those two rows has been replaced by a currently asserted row with an assertion that begins on the same clock ends.
Rows 1 and 2 contain the same business data, the same information about the version of policy P861 that began on 1/01/04. The difference is that row 1 asserted that P861 would be a type HMO policy, with a $15 co-pay, from that date until further notice. But on 5/01/04, we learned that the co-pay would change to $20, effective on that date. Therefore, at that point in time, our original assertion (row 1) ceased being true. It ceased being the case that P861 would continue to be an HMO policy with a $15 co-pay until further notice. On 5/01/04, that notice was given, and so the original assertion had to be withdrawn. In its place, we put an assertion identical to it except that it states that the business data it contains ceases to be effective one clock tick before 5/01/04. We then follow that with another assertion which records the actual change in business data that did become effective on 5/01/04.
Be the first to comment on this post using the section below.