Time and Time Again: State Transformations

Information Management Online, January 2, 2009

Tom Johnston, Randall Weis

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.

Page 1 of 4.