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.

 

The First Temporal Transaction

 

On 12/01/04, Figure 3 shows that the state of the target table after the first of the two temporal transactions for this original delete transaction has been applied.

 

 

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

 

As indicated in Figure 1, the first of these temporal transactions withdraws the current assertion. Because a specific assertion withdrawal time is not specified, the default of {now} is used, and the assertion end date is therefore changed to 12/01/04. Graphically, the assertion timeline is changed from an arrow to a line, moved to the shaded bar above the calendar timeline and the row in the table is shaded.

 

If no further temporal transactions were applied, what would the result be? As you can see from the table, among all the currently asserted rows, row 4 has the chronologically latest effective time. Consequently, it is the most current (currently asserted) version in this episode, and therefore its effective end date is also the episode's effective end date. If this date was 9999 (12/31/9999), this would be an open episode and the current episode of the object. But because the episode end date is not 9999, it is a closed episode that ended on 8/01/04.

 

The Second Temporal Transaction

 

The result of applying the second temporal transaction implementing an original delete is shown in Figure 4.

 

 

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

 

Row 5 was the current version before the original transaction began. The first temporal transaction withdrew it, and this second temporal transaction replaces it. It replaces it with a version identical to the withdrawn version, except for having an effective end date of 12/01/04. With this effective end date, the episode is now a closed episode. The logical delete transaction has been completed.

 

Scenario 1, Transaction 4: 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 what this transaction effected would include the following points:

 

  • The most common kind of original delete - 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 delete is submitted. A current episode has an episode begin date less than the current date and whose latest version has an effective end date greater than the current date.
  • Conversely, if there were no current episode for P861 on 12/01/04, the delete transaction submitted on that date would have been invalid. There might have been a past episode, i.e. one whose episode end date (physically expressed as the effective end date of the last version in the episode) was a date in the past. There might have been a future episode, although we have deferred the discussion of future episodes until later. Or, there might have been no episode at all. In any of these three cases, the original delete would have been invalid.
  • The encapsulation layer that translates the original transaction into the two temporal transactions guarantees that the version created by the delete is identical to the version it replaces, except for effective end date, and for a temporally contiguous assertion time period which begins when the withdrawn version's assertion time period ended - in this case, on 12/01/04.

Our original delete transaction is now complete and, with it, our discussion of original insert, update and delete transactions involving current episodes. These are the basic transactions on which all maintenance to asserted version tables are based.

 

Next time, we will create a taxonomy of scenarios that will carry us through the remainder of this series. This taxonomy will describe all the transformations that can be applied to asserted version tables.

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