Note: a glossary of technical terms used in these articles can be found on the Web sites of the authors, MindfulData.com and InbaseInc.com. In our last column, we merged two episodes of policy P861 into a single episode. One of the two was a closed episode, with an effective period from 1/1/08 to 4/1/08. The other was an open episode, with an effective period from 8/1/08 to 9999.  The user was not aware that she was merging episodes. In fact, she had has never heard of episodes. She was only aware of what she wanted done, and her intentions were fully and unambiguously specified in the original update submitted. Figure 1 in our previous column  shows that the update specified the effective time begin and end dates for the business data supplied with her transaction, those dates being 4/1/08 and 8/1/08, respectively.  The next transformation in our taxonomy splits one episode into two. That is the transformation we will describe at this time. In our last column, Figure 5 demonstrated that the two transformations are topological inverses of one another – a merge of two shapes, followed by a split of the resulting merged shape, returns us to the original two shapes. These split and merged shapes are each an episode, as are all of the shapes shown in our taxonomy,  .  These two transformations are also syntactic inverses of one another. The original two rows in the Policy table, as shown in Figure 1 our previous column, were transformed into the two rows shown in Figure 6; in the process, two episodes were merged into one. That Figure 6 is Figure 1 for this article; that end state is the begin state of this transformation. The end state of this split transformation, as we shall see, will be to return us to the begin state of the merge transformation from last time. The assertions will be different, because they are asserted at different times; but the business statements made by them will be the same. Semantics will have been preserved.

From January of last year to March of this year, our Policy table asserted that policy P861 was in effect for four months, then allowed to lapse for three months, at which time it was reinstated, but with a higher co-pay amount. But during March of this year, our Policy table has been asserting that P861 existed continuously, in effective time, from January 1 of last year until now. That it will remain in effect until further notice.  But these latest assertions about this policy are about to become history – literally. For we have just come to learn, so we suppose in our example, that we were right originally, before the new assertions that began last month. We have to reinstate the original claims about this policy, but do so in a manner which preserves the history of our vacillations.  To create a new set of claims about this policy that are identical to the claims we originally made, we have to reduce the total amount of effective time allocated to the single episode representing our policy. Topologically, the only ways to reduce the effective time period of an episode are by either shortening it on the left, on the right or in the middle. Semantically, the only ways to reduce the effective time period of an episode are by moving its begin date forward, moving its end date back or creating a gap somewhere between the middle and the end. Splitting an episode is the last of these three ways. The original transaction we will use to reduce effective time is a deletion. We could have created a fourth type of original transaction, one in addition to insert, update and deletion. We could also have extended the syntax of the original update transaction so it could be used to pick out a unique version, and describe how to alter its effective time. We could have taken either approach, because either would have provided the user a means to unambiguously state her intentions. Among all the various ways we could have provided for our user to express her intentions, we want one that is also intuitively natural and as succinct and elegant as possible. We rule out a fourth transaction type because it is not intuitively natural. In fact, it is counter-intuitive, because it violates the concept of using an insert to initially create the representation of something of interest to us, an update to reflect changes to whatever that something is, and a deletion to remove the representation of that something.  We also rule out extending the syntax of an original update transaction because it is also unintuitive and, besides that, is neither succinct nor elegant. It is unintuitive because it would use an update transaction to remove information from the database – more precisely, to remove information from the current effective time state of the database. It is inelegant because it would require an effective date and an assertion date to pick out the version to replace and additional dates to specify what to replace it with. So we choose the delete transaction as the means we provide the user to express her intention to shorten the total amount of effective time currently occupied by an episode of an object in the database. Figure 1 shows how an original delete transaction can specify the reduction in the total effective time occupied by an object. The original transaction consists of the operator (Delete), the object identifier (P861) and the effective begin and end dates marking out a continuous extent along the effective timeline from which policy P861 is to be excluded. We point out once again that all consideration of deferred transactions is being left till later in this series. So for this transaction, the assertion begin date is unspecified, and is therefore taken to be the current date. Just as an original update is invalid if the target it specifies does not exist, so too an original deletion is invalid in those same circumstances. In this case, because the deletion specifies two effective dates, it asserts that an episode of the object currently exists that does include the indicated effective time period. If such an episode cannot be found, the transaction will be rejected. Even if an episode of the object is found that occupies some but not all of the specified effective period, the transaction will be rejected. Even in this latter case, the database is not as the user assumed it to be. Something is wrong, and it is better to simply reject the transaction than to attempt to carry out part of it. Looking at Figure 1, we see that there is an episode in current assertion time. It is the episode consisting of rows 3 and 4. We can also see that this episode does contain the indicated effective time period, 4/1/08 – 8/1/08. Thus, the transaction is valid and the asserted versioning framework will proceed to carry it out. Figure 2 shows how that will be done.

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