Continue in 2 seconds

Time and Time Again: State Transformations

By
  • Tom Johnston, Randall Weis
Published
  • January 02 2009, 3:07am EST

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.

 

Our first scenario is complete. With it, we have seen how the three original transactions of asserted versioning work. As with non-temporal tables, those three transactions are insert, update and delete. And as with non-temporal tables, there are no other transaction types. But these three basic transactions are just the raw material out of which we craft transformations of asserted version tables from valid states to new valid states.

 

In this column we turn to a classification of the state transformations that are valid for asserted version tables. We will then develop a scenario for each transformation. In the process, we will be using original transactions on which various combinations of bi-temporal dates have been explicitly supplied, and we will also illustrate how and why relevant integrity constraints are applied.

 

A Taxonomy of Asserted Versioning State Transformations

 

We have emphasized that the target of every asserted version transaction is an episode of an object. It is not the object itself. Neither is it a version or an assertion of a version.

 

This is reflected in the taxonomy shown in Figure 1. As with anything we can manipulate, there are three basic things we can do with it. We can create an instance of it, modify an existing instance, or "un-create" an instance. In the case of bi-temporal episodes, the un-create action is neither a physical nor a logical delete. Instead, it is the action we have called "terminating" an episode - the action in which we set an episode's effective end date to a non-12/31/9999 value.

 

Create, modify and terminate are clearly both exhaustive of the set of all AV transformations and also mutually exclusive of one another. Thus, at its first two levels, this taxonomy is, as all taxonomies should be, a mathematical partitioning.

 

At the level of abstraction we are dealing with, there is no further breakdown of either the create or terminate transformations. For the modify transformation, we achieve a partitioning by distinguishing transformations which change one episode into two episodes, or vice versa, from transformations that transform episodes one for one, and then in the latter category, transformations that make an episode bigger from those that make an episode smaller. We make an episode bigger by extending it along the effective timeline and smaller by truncating it along the effective timeline. Thus, we extend the property of being a mathematical partition down to the third level of this taxonomy.

 

Next, it is possible for both to extend and truncate an episode at the start or the end of the episode. And so, finally, we complete this taxonomy with the assurance that no instance of any parent node can fail to be an instance of a child node of that parent, and also that every instance of any parent node exists as no more than one instance across the set of its child nodes.

 

Finally, we need to be aware of the different scenarios possible under each of these nodes. For there are two relevant variables that were not used to construct the taxonomy. The first is the distinction between open and closed. An open version is one whose effective end date is 12/31/9999, and an open episode is one whose latest version is open. Closed versions have non-12/31/9999 end dates, as do closed episodes.

 

So under both the create and terminate nodes of the taxonomy, we can have four open/closed combinations. The before state can consist of open or closed episodes, and the after state can, too. As for the modify nodes, in each case we may be dealing with open or closed episodes in either the before or after states, although not all possible combinations are in fact valid. These details, of course, will be considered as we continue on with this series.

 

The second relevant variable which was not used in the construction of this taxonomy is assertion time. And with every one of the seven possible transformations, they may be created in either current assertion time or in future assertion time. We will begin our scenarios with current assertion time transformations, but for the sake of completeness it will be necessary, later on, to present corresponding future assertion time scenarios.

 

Given this explanation of our taxonomy, the graphics under each leaf node should be clear. The before state of each transformation is shown to the left of the subscript arrow, and the after state to the right. Extensions are indicated by non-subscripted solid arrows and truncations by non-subscripted dotted line arrows.

 

 

Figure 1: A Taxonomy of Asserted Version State Transformations

 

A Discussion of the Taxonomy Nodes

 

There are seven leaf nodes in this taxonomy, an exhaustive and mutually exclusive set of seven from-state and to-state transformations that can transform valid sets of episodes into other valid sets of episodes. As we develop the scenarios that will illustrate the mechanics of asserted versioning, we will also be applying the three constraints that together guarantee the semantic integrity of the transformations, those constraints being referential integrity (RI), temporal referential integrity (TRI) and temporal entity integrity (TEI).

 

Create an episode. Via an original insert, this transformation creates a version of an object which is not effective-time temporally contiguous with any earlier or later version of that object. The result is a single-version episode.

 

What is the point of the "not effective-time temporally contiguous" constraint? It is that if the newly created version were contiguous with another version of the same object, it would not be a new episode, but instead an extension of an existing episode. Versions of an object that are contiguous are members of the same episode; versions that are not are members of different episodes. It follows that an episode is a set or one or more contiguous versions, surrounded on both sides by an effective time gap of at least one clock tick.

 

Terminate an episode. Via an original delete, or the simple passage of time, the latest version of an episode comes to have an effective end date that is in the past. In the first case, there is a currently open episode, one with a 12/31/9999 effective end date. The delete transactions supercedes the latest version of that episode with a more recently asserted version with a non-12/31/9999 effective end date. If the delete transaction accepts its date default, that end date is set to {now} and the episode is immediately terminated.

 

The other way an episode can be terminated is by the simple passage of time. These are already closed episodes, but ones whose effective end dates lie in the future. Closed but not yet terminated episodes are created in one of two ways. One way is to issue an original delete, specifying a future date as the effective end date. The other way is to issue an original update, also specifying a future date as the effective end date.

 

Extend an episode backward. Via an original update, create a version of an object whose effective end date is equal to the effective begin date of the initial version of that episode and whose effective begin date is at least one clock tick earlier than that.

 

An example would be updating a policy episode whose effective begin date was 6/1/08. This would be done with an original update that specified an effective end date of 6/1/08 and an earlier effective begin date. Of course, as with all episode extensions, the transaction will be invalid if it causes the episode being extended to "collide" with another episode of the same object, in effective time. This "no collision rule" is, of course, simply the constraint we have called temporal entity integrity.

 

Extend an episode forward. Via an original update, create a version of an object whose effective begin date is equal to the effective end date of the latest version of that episode. In the typical case of an open episode, one whose latest version has an effective end date of 12/31/9999, this is achieved by updating that end date to the same value as the begin date of the version being added.

 

This is the most common type of original update. If submitted with all bi-temporal dates defaulted against an open episode,the current value of {now} is used as the effective end date of the latest version in the episode and also as the effective begin date of the version being created by the update, and 12/31/99 is the value given to the effective end date of the new version (and, thus, of the episode). If submitted against a closed episode, whether that episode lie entirely in the past, or is now current, or lies entirely in the future, the original update must specify an effective begin date which is identical to the then current effective end date of the episode.

 

Split an episode. Via an original update, replace a non-initial version of an episode with one that has an earlier effective end date, or replace a non-latest version of an episode with one that has a later effective begin date, or both.

 

A split is thus a truncation that is made somewhere in the middle of an episode. It either moves the effective end date of a non-latest version backward in time or moves the effective begin date of a non-initial version forward in time, or does both. Since prior to the split, the versions of the episode were effective time contiguous, the split transformation introduces a temporal gap into their midst, thus transforming one episode into two episodes.

 

Merge a pair of adjacent episodes. Via an original update, create a version of an objectwhose effective begin date is equal to the episode end date of the earlier episode and whose effective end date is equal to the episode begin date of the later episode.

 

A merge is thus an extension that is made to fill the effective time gap between a pair of adjacent episodes.

 

Truncate an episode forward. Via an original update, replace the initial version of an episode with one that has a later effective begin date.

 

This action would be taken on an episode that was begun too early in effective time. But as with all transformations to asserted version tables, the before state of the episode is not lost. It continues to exist, only in past assertion time.

 

Truncate an episode backward. Via an original update, replace the latest version of an already closed episode with one that has an earlier effective end date. An example would be a policy episode that had been terminated on 6/1/08 but that should have been terminated on 5/31/08.

 

With all of these transformations, the before state in the transformation is never lost. Instead, it is moved from current assertion time into past assertion time and is replaced with a new state that exists in either current or in future assertion time. If that new state exists in future assertion time, then no other states of the episode can be created with an earlier assertion time. However, assertion time issues complicate the discussion, and our approach, as stated earlier, will be to first discuss scenarios in which only current assertion time is used.

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