Figure 10.2 depicts the history of policy P861 along a fragment of the calendar timeline, the fragment extending from January 2010 through January 2014. Let's recall that our examples all use, unless otherwise indicated, a clock that ticks once a month. And so, using our page-width-preserving notation, “Jan10” stands for January 1^st, 2010, “May12” for May 1^st, 2012, and so on. In the text, we will write, more concisely, “January 2010” and “May 2012”, not bothering to indicate that the clock always starts the tick on the first moment of the first day of each month and lasts through the last moment of the last day of that month.

We emphasize here a point that we originally made in Chapter 3. A clock tick is a logical concept, not a physical one. It is the smallest unit of time that can intervene between two adjacent versions of the same object. Thus, if one version begins on the first of the month, then given the granularity for clock ticks used in the examples in this book, the next one cannot begin until the first of the next month.

A clock tick gap, in physical time, is whatever the duration of a clock tick happens to be. But the duration of a clock tick, in physical time, is not the issue. As far as recorded data is concerned, there is no duration. There are either clock ticks that happen between two rows of interest to us, or clock ticks that don't.

Unless otherwise indicated, these diagrams show the history of our policy as we currently believe it to be. In other words, it depicts the history of our policy in current assertion time.

Here is a temporal insert transaction, which takes place on August 2011.

This is a retroactive transaction because it is attempting to insert a representation of the policy into an effective time period that is already in the past. This transaction is directing us to insert its data into January 2011 and February 2011. Another way to express this target time period in English, using this example, would be “Starting on January 2011 and continuing up to but not including March 2011 . . . . .”

Immediately prior to this transaction, the currently asserted life history of policy P861 is as shown in Figure 10.2. After the transaction is completed, that history will be the history of the policy as asserted up to (but not including) August 2011. The new currently asserted history of the policy will be as shown in Figure 10.3.

Episode C, as we have labeled it, is a single-version episode. Of course all episodes, when initially created, are single-version episodes. Using the in-line notation introduced in Chapter 6, this new episode looks like this:

This example shows our business correcting a mistake. The mistake was forgetting to record that policy P861 was in effect for those two months until eight months after the fact. What probably happened is that in August, the policy holder filed a claim against the policy. The claim was rejected, the policy holder complained, people in the company did some research, the customer service representative apologized, the policy was retroactively created and, finally, the claim was processed.

New episodes can be created proactively, before they go into effect, just as easily as they can be created retroactively, after they go into effect. But in the scenario shown here, that is not possible. The reason is that Episode B is an open episode; it remains in effect until further notice. Its version 4 has an effective end date of 12/31/9999. Therefore, any attempt to proactively create a new episode, i.e. to create an episode that began sometime after August 2011, would violate temporal entity integrity.

In the previous example, the mistake our company made was to fail to record that a policy was in effect until several months after the fact. Another kind of mistake is to get the effective begin date wrong. For example, Figure 10.3 shows the first episode of our policy becoming effective on February 2010. But let's suppose that the correct date was actually the month before that. How will we make this correction?

Because this correction will place data about an object into a clock tick where it previously was absent, it is carried out with a temporal insert transaction. Similarly, if we mistakenly place data about an object into a clock tick where it doesn't belong, we will need to use a temporal delete transaction to correct our mistake. So we should note that with temporal data, it is not just update transactions that can correct mistakes.

Immediately prior to this transaction, the currently asserted life history of policy P861 is as shown in Figure 10.3. It is still August 2011, and we now submit the following transaction to the AVF:

Immediately after this transaction is completed, that history will be the history of the policy as asserted from when the previous transaction was applied up to August 2011. The new currently asserted history of the policy will be as shown in Figure 10.4. The new version—version 6—looks like this:

Unlike our first insert transaction, this one does not create a new episode; it extends an existing episode backwards in time. But in doing so, it changes that episode's begin date. As we can see from the schema common to all asserted version tables, the episode begin date is repeated on every version in an episode. And by extending this episode backwards, this transaction changes that episode's begin date. So as part of the atomic isolated unit of work started by this transaction, the AVF must also change the episode begin date on versions 1 and 2, the other two versions in the new Episode A. This is done by withdrawing those two versions and replacing them with versions identical to them except that they have the correct episode begin date. Those two replacement versions are versions 7 and 8, and the versions they replace are shown as superscripts next to them. At the end of the transaction, versions 6, 7 and 8 make up the currently asserted Episode A, and all have an episode begin date of January 2010.

Another thing we can use a temporal insert for is to {extend an episode forwards} in time. This is, naturally enough, much the same process as {extending an episode backwards}. In both cases, the timespan of the transaction must [meet] the timespan of an episode already in the table. The two timespans cannot [intersect], and they cannot have a gap between them. ² However, {extending an episode forwards} is a little less work for the AVF than {extending an episode backwards} because extending forwards leaves the episode begin date unchanged on the other versions in the episode.

All of our temporal inserts, so far, have done retroactive work. So let's set up this next example as a proactive transaction. The main lesson to be learned is that the distinction between proactive and retroactive transactions is one we make, but not one that matters to the AVF. It is a matter of the relationship between when the transaction takes place, and what period of effective time it affects. As a relationship between a point in time and a period of time, the basic options are that the point in time can be earlier than the period of time, within the period of time, or later than the period of time. This gives us, against a current episode, proactive, current and retroactive temporal transactions.

To illustrate a proactive transaction, let's assume that it is now May 2010, and that at this point in time, our database looks as shown in Figure 10.5.

It is May 2010, and the following transaction is submitted to the AVF:

Immediately after this transaction is completed, the history shown in Figure 10.5 will no longer be currently asserted. Instead, it will be the history of the policy as asserted from when the previous transaction was applied up to May 2010. The new currently asserted history of the policy will be as shown in Figure 10.6. Version 9 looks like this:

Episode begin dates are not supplied on transactions. They are always determined by the AVF. In this case, the AVF sees that there is already a version of that same policy in the table whose effective end date [meets⁻¹] the effective begin date on the transaction. Because this match means that the episode is being extended forwards, the AVF assigns version 9 the episode begin date on the version it is contiguous with—in this case, version 8.

So now, on May 2010, we are claiming that we know several things about policy P861's future. We know that it will remain in effect until December 2010, i.e. through November 30^th, 2010. We know that from May 2010 to October 2010, it will have the properties ascribed to it by version 8. We also know that in October and November of that year, it will be an HMO policy with a $25 copay.

We say we know this about the future. But, of course, as with any statement about the future, we may be wrong. However, since anyone viewing this data about the future will understand this, we are misrepresenting nothing.

We have seen how temporal inserts can create new episodes and can extend existing episodes backwards and forwards. But when any but the latest episode of an object is extended forwards, there is an episode ahead of it to “bump into”. Similarly, when any but the earliest episode of an object is extended backwards, there is an episode behind it to bump into.

In either case, however, a successful temporal insert will {merge} the two adjacent episodes together. The resulting episode will contain all the versions in both of the original episodes, and also the one version that caused them to {merge}.

To illustrate a temporal transaction merging two episodes, let's go all the way back to Figure 10.2 and assume that it is now January 2012. Immediately after this next transaction is completed, the history shown in Figure 10.2 will no longer be currently asserted. Instead, it will be the history of the policy as asserted from when the previous transaction was applied up to January 2012. The new currently asserted history of the policy will be as shown in Figure 10.7.

It is now January 2012, and the following transaction is submitted to the AVF:

Version 7 looks like this:

The AVF sees that this transaction will {merge} two episodes. It can tell that because there are already two versions of that same policy in the table such that the effective end date of the earlier one [meets⁻¹] the effective begin date on the transaction, and the effective begin date of the later one [meets] the effective end date on the transaction. Because the result is a single episode, all versions in that episode must have the same episode begin date. Therefore, to complete the transaction, the AVF sets the episode begin date of version 7 to February 2010, and withdraws versions 3 and 4, replacing them with versions that are identical except that they remain in current assertion time and have an episode begin date of February 2010.

We have now discussed all the temporal extent transformations that are carried out in response to a temporal insert transaction. At the end of this chapter, we will review the taxonomy of temporal extent transformations shown in Figure 9.5 (and repeated as Figure 10.21) to be sure that we have demonstrated that each of them can be produced by one of the three temporal transactions.

In the meantime, let's turn to temporal update transactions. But before we do, let's note that update transactions do not bring about temporal extent transformations. A temporal extent transformation necessarily involves adding the representation of an object to one or more clock ticks, or removing the representation of an object from one or more clock ticks. Temporal updates do neither. They simply change business data on versions that [intersect] a designated target range.

The temporal update transactions discussed in this book are restricted temporal updates. By that we mean that these transactions designate a specific object, a span of effective time, and a value for one or more columns of business data, and then change all representations of that object, in all clock ticks within that timespan, to those new values. But limited to only restricted update transactions, Asserted Versioning could not, for example, change the copay amounts on all policies within a target timespan provided that the original amounts are less than a certain value. Instead, the AVF could only change all copay amounts within that timespan, for a single object, to that new value.

Obviously, a series of carefully designed restricted temporal updates could produce any desired result, and do so across any set of objects. But just as obviously, it would be a tedious process. And because of the careful analysis required, it would also be an error-prone process.

As we go to press, these limitations on temporal update transactions have been removed. Release 1 of our Asserted Versioning Framework now supports unrestricted temporal update transactions, ones which will update multiple objects within a target timespan, and will do so based on WHERE clause qualifying criteria. The AVF also now supports unrestricted temporal deletes as well.

In addition, instead of requiring the user to write transactions in a proprietary format required by an Application Programming Interface (API) we were developing, the AVF now accepts temporal insert, update and delete transactions written as native SQL. This is done by means of Instead of Triggers, as described in the section Ongoing Research and Development, in Chapter 16.

Our new support for unrestricted temporal transactions, written as native SQL statements, can be found on our website AssertedVersioning.com.

We will begin with the set of three episodes shown in Figure 10.14. These are the current episodes A, B and C after being updated as shown in Figure 10.12. We have also reset the version numbers so they correspond to the row numbers in Figure 10.12.

To completely remove an episode from current assertion time, we do not need to provide the exact begin and end dates of the episode, but simply need to include its effective time period in the transaction's target timespan. If that target timespan includes that of the episode, the result is to remove the entire episode, i.e. to {erase} that episode from current assertion time.

It is now March 2012, and either of the following two transactions is submitted to the AVF:

or

These two temporal delete transactions have the same result. They both {erase} Episode A, the episode consisting of versions 6, 1, 7 and 8. The author of the transaction will not be confused by this fact provided she remembers that a delete transaction simply stops asserting the presence of an object anywhere in the effective timespan indicated on the transaction. Both timespans shown here contain exactly the same occupied clock ticks.

Withdrawing these versions is the first of the three physical transaction steps shown in Figure 10.15. As for the other two steps, neither of them is needed to complete this temporal transaction. The reason is that since an entire episode is being {erased}, and the object is represented nowhere else in the target timespan, no other episodes are affected. We can think of the empty clock tick or clock ticks that exist on both ends of an episode as insulating other episodes from whatever happens to just that one episode.

We still currently assert episodes C and B in Figure 10.14. It is now May 2012, and the following transaction is submitted to the AVF:

This transaction will {erase} Episode C, and {shorten Episode B forwards} by one month.

Because the delete transaction {shortens Episode B forwards}, it alters the episode begin date. Specifically, it changes that begin date from April 2011 to May 2011. This transaction will require all three of the physical transaction steps shown in Figure 10.13.

The first physical transaction step withdraws versions 9 and 10. The result is shown in Figure 10.16. These versions have been withdrawn, as all versions are, by overwriting their assertion end dates. The overwrites which withdraw rows into past assertion time do not lose information, however, as overwrites of business data do. This is because we always know what the assertion end date was before the row was withdrawn. In all cases, it was 12/31/9999. This is guaranteed because (i) all versions are created with an assertion end date of 12/31/9999, and (ii) the AVF will never alter an assertion end date that is not 12/31/9999.

In comparing the transaction's time period to that of the episode, we see that it completely includes version 10 but only [overlaps] version 9. So, having withdrawn version 9, we must now replace it with a version identical to it except that its effective time period begins on May 2011. But because version 9 is the first version of Episode B, it changes the episode begin date of the episode from April 2011 to May 2011. This, in turn, affects version 4, which is the second version in that episode. Consequently, we must withdraw version 4, and replace it with a version that is identical to it except for having the new episode begin date. The result of all this work is shown in Figure 10.17.

Episode C has been {erased}, completely withdrawn into past assertion time. Episode B has been {shortened forwards} by one month.

The first delete transaction we considered covered an entire episode, {removing} that episode by withdrawing all its versions into past assertion time. This delete transaction, however, left part of a target episode in current assertion time. It withdrew part but not all of that episode, bringing about the temporal extent transformation in which an episode is {shortened forwards}.

In this way, a temporal delete is different from a non-temporal delete. Non-temporal deletes remove the one and only row representing an object from the database. Temporal deletes remove some but not necessarily all of the possibly multiple rows representing an object, and may also remove part but not necessarily all of any one (or two) of those rows. And, of course, temporal deletes do not physically remove any data from the database. They just withdraw assertions and end the effective time of versions, so that at any point in time, what used to be the case can be recreated exactly as it was then.

A temporal delete can also {shorten an episode backwards} in time. This happens when the transaction's target range [overlaps] later clock ticks in the episode (and perhaps additional clock ticks as well) while one or more earlier clock ticks are not [overlapped].

{Shortening an episode backwards} is easier than {shortening it forwards} because it doesn't alter the episode's begin date. Since the episode's begin date remains the same, the only versions in the episode that are affected by the transaction are those which [overlap] the transaction's target range. If we're really fortunate, the target range will line up on version boundaries. An example would be a temporal delete whose target range is [Jul 2011 – 12/31/9999] against the episode still asserted in Figure 10.17. In this case, the timespan on this transaction [equals] the effective time of version 12.

When a temporal delete's timespan lines up on a version boundary within a target episode, then all that has to be done is to withdraw the affected versions. Doing so, in this case, leaves an episode whose effective time extends from May 2011 to July 2011. So the effective end date, July 2011, of this previous version, row 11, would designate the end of the episode.

{Splitting} an episode is a little more interesting than either {shortening an episode backwards} or {shortening an episode forwards}. The reason is that, from the point of view of the earlier of the two resulting episodes, {splitting} is {shortening an episode backwards}, while from the point of view of the later of the two resulting episodes, it is {shortening an episode forwards}. From the point of view of the “internals” of AVF processing, of course, it is simply another case of removing the representation of an object from a series of clock ticks, the case in which those clock ticks are contained within the clock ticks of a single episode.

Let's begin with the life history of policy P861 as represented in the table in Figure 10.15 and as graphically illustrated in Figure 10.14. In that table, versions (row numbers) 9 and 4 constitute a currently asserted episode, one which extends from April 2011 to 12/31/9999.

It is now February 2012. Note that this is one month before the {shorten forwards} transaction, described in the previous section, is processed. That's why we're going back to Figure 10.15, rather than to Figure 10.16. The following transaction is submitted to the AVF:

Policy P861 exists, in current assertion time, in every clock tick from May 2011 to December 2012. As we can see from version 9, it also exists for exactly one clock tick prior to that timespan. And as we can see from version 4, it exists past December 2012, into the indefinite future.

The first physical transaction step in this deletion is to withdraw versions 9 and 4 since each of them has at least one clock tick included in the timespan specified by the temporal delete. The result is shown in Figure 10.18.

Having {erased} the entire episode, the next step is to replace those parts of those versions which lie outside the scope of the transaction. For version 9, [Apr 2011 – May 2011] is the single clock tick that must be replaced. For version 4, [Dec 2012 – 12/31/9999] is the effective timespan that must be replaced. The result is shown in Figure 10.19.

The second physical transaction step in carrying out a temporal delete is to assert the replacement versions which delimit the time period of the deletion. This is done with versions 12 and 13. Version 12 replaces the one clock tick from version 9 that was not included in the range of the delete. Version 13 replaces the clock ticks from December 2012 to 12/31/9999 from version 4 that were not included in the range of the delete.

The third physical transaction step resets any versions that need their episode begin dates reset. That is version 13. Version 4, which it replaces, belongs to an episode which began on July 2011. That episode has been {shortened forwards} by the transaction so that it now begins on December 2012, the effective begin date of what is now its only version.

First of all, it is well established that the Allen relationships are a mutually exclusive and jointly exhaustive set of all the possible relationships between two time periods along a common timeline that are based on the temporal precedence and succession of one to the other (Figure 10.20). We ourselves derived precisely those Allen relationships as the leaf nodes in a taxonomy of our own invention. Since taxonomies are tools for demonstrating mutual exclusion and joint coverage of an original root node, this is further proof, if any were needed, of the validity of the Allen relationships.

In the case of temporal transactions, one of those two Allen relationship time periods is the effective time period specified on the transaction. The other time period is the effective time period of each episode and version to which those transactions may apply.

We should also remind ourselves that when we compare any two time periods in effective time, we are assuming that they exist in shared assertion time. When one of those time periods is on a transaction, that assertion time cannot begin in the past, and usually begins Now(); and the assertion time specified on the transaction always extends to 12/31/9999.

[Before], [before⁻¹]. When a temporal transaction's effective time is non-contiguous with that of any episodes of the same object already in the target table, a temporal insert will {create} a new episode of the object. In Allen relationship terms, this means that, for any episode of the same object already in the target table, the effective time period specified on a temporal insert is either [before] or [before⁻¹] that episode. Another way of making the same point is to say that the time period on the transaction is non-contiguous with the time period of any episode of the same object.

If the effective time period on a temporal update or delete transaction is either [before] or [before⁻¹] the effective time period of every episode of the same object already in the target table, then the temporal transaction is invalid. It is equivalent to a conventional transaction trying to update or delete a row that isn't there.

[Meets], [meets⁻¹]. When a temporal transaction's effective time [meets] or [meets⁻¹] that of an episode of the same object already in the target table, a temporal insert will result in one or the other of the {lengthen} transformations, depending on whether the transaction's timespan is later than or earlier than that of the episode. Also, if a temporal insert transaction's effective time both [meets] one episode and [meets⁻¹] an adjacent episode, the result will be a {merge} transformation.

The [before], [before⁻¹], [meets] and [meets⁻¹] relationships are subtypes, in our taxonomy, of the [excludes] relationship. And we can now see why this is an important group of relationships to define. Temporal insert transactions are valid only if they have an [excludes] relationship with every other episode of the same object already in the target table. And by the same token, temporal update and temporal delete transactions are valid only if there is at least one episode of the same object already in the target table with which they do not have an [excludes] relationship. So now that we are through with the [excludes] branch of the Allen taxonomy, we have exhausted all the Allen relationship possibilities for temporal insert transactions.

We will discuss how temporal delete transactions work with the remaining Allen relationships. We will not explicitly discuss temporal updates because temporal updates are semantically equivalent to temporal deletes followed by the insertion of updated versions which supercede those versions wholly or partially withdrawn. And so there are no Allen relationships possible for temporal updates that are not also possible for temporal deletes.

[Starts]. If a temporal delete transaction's effective time begins on the same clock tick as that of an episode, but ends earlier than the episode ends, it will withdraw all versions wholly or partially included within its timespan. If one version is partially within the timespan, the temporal delete will replace the part of that withdrawn version not within its timespan. In either case, the result is a {shorten backwards} transformation on that episode.

[Starts⁻¹]. If a temporal delete transaction's effective time begins on the same clock tick as that of an episode, but ends after the episode ends, the transaction will {erase} the episode; and, in addition, it will withdraw all other versions, for the same object, that are wholly or partially included within its timespan.

Those other versions will exist within one or more later episodes. On any of those episodes wholly included within the transaction's timespan, there will be an {erase} transformation on them, as well. The last episode within the transaction's timespan may be wholly or partially included within that timespan. If it is wholly contained, there will be an {erase} transformation on it. Otherwise, there will be a {shorten forwards} transformation. If the end of the transaction's timespan does not fall on a version effective time boundary, then the temporal delete will replace the part of that withdrawn version that is not within its timespan.

[Finishes]. If a temporal delete transaction's effective time ends on the same clock tick as that of an episode, but begins after that episode begins, it will withdraw all versions wholly or partially included within its timespan. If one version is partially within the timespan, the temporal delete will replace the part of that withdrawn version not within its timespan. In either case, the result is a {shorten forwards} transformation on that episode.

[Finishes⁻¹]. If a temporal delete transaction's effective time ends on the same clock tick as that of an episode, but begins before that episode begins, it will {erase} the episode; and, in addition, it will withdraw all other versions, for the same object, that are wholly or partially included within its timespan.

Those other versions will exist within one or more earlier episodes. On any of those episodes wholly included within the transaction's timespan, there will be an {erase} transformation on them, as well. The earliest episode within the transaction's timespan may be wholly or partially included within that timespan. If it is wholly contained, there will be an {erase} transformation on it. Otherwise, there will be a {shorten backwards} transformation. If the start of the transaction's timespan does not fall on a version effective time boundary, then the temporal delete will replace the part of that withdrawn version that is not within its timespan.

[During]. If a temporal delete transaction's effective time begins after that of an episode, and ends before that episode ends, then the transaction will withdraw all versions wholly or partially included within its timespan. At most two versions can be partially included in that timespan, those being the ones at the begin and/or end of the timespan. This delete transaction carries out a {split} transformation on the episode in question.

[During⁻¹]. If a temporal delete transaction's effective time begins before that of an episode, and ends after that episode ends, then the transaction will {erase} the one or more episodes wholly included within its timespan. In addition, as well as any number of additional episodes wholly included within the transaction's timespan, there may be one or two episodes only partially included within the transaction's timespan. If there is an earlier but partially included episode, the delete transaction will do a {shorten backwards} transformation on it. If there is a later but partially included episode, the delete transaction will result in a {shorten forwards} transformation. In either case, the partially included episode may or may not have a partially included version; in other words, the transaction's timespan may or may not align on version boundaries. In either case, a partially included version is {split}, and the part outside the transaction's timespan is replaced.

[Equals]. If a temporal transaction's effective time [equals] that of one episode of the same object already in the target table, a temporal delete will {erase} that episode.

[Overlaps]. If a temporal delete transaction's effective time [overlaps] that of an episode, then either it begins after the episode begins and before it ends, and ends after the episode ends; or else it begins before the episode begins and ends after the episode begins but before it ends. In either case, the transaction will withdraw all versions wholly or partially included within the timespan of the transaction. At most one version can be partially included. If there is such a version, a temporal delete will replace the part of the partially included version that is outside the timespan of the transaction. The result is to either {shorten the episode backwards} or {shorten it forwards}, depending on whether the episode began before or after the transaction's timespan.

We have now demonstrated that every Allen relationship between a transaction and a target is valid for an insert, an update or a delete. So although we have not worked through a separate example for each Allen relationship, we can now be confident that there are no temporal precedence and succession relationships between a transaction's time period and that of a target episode that Asserted Versioning temporal transactions cannot handle.

A second completeness check uses the taxonomy of Asserted Versioning temporal extent transformations presented in Chapter 9. After presenting that taxonomy, we argued there that the taxonomy is mutually exclusive and demonstrably complete. Its completeness was demonstrated by showing that all possible single-transformation topological transformations of two line segments are represented in the taxonomy.

Our second completeness check will use this taxonomy to review all extent-altering state transformations, and be sure that all of them can be brought about by valid temporal transactions.

This completeness check has proven to be easier to complete than we had originally anticipated. As indicated in Figure 10.21, all the transformations on the left-hand side of the diagram can be brought about by means of a temporal insert transaction. Indeed, each of those transformations was explicitly mentioned in the previous section. All the transformations on the right-hand side of the diagram can be brought about by means of a temporal delete transaction. Again, each of those transformations was explicitly mentioned in the previous section.