We have now used all three temporal transactions, in a variety of situations. There are several ways to categorize the situations which temporal transactions might encounter, but we concluded, a couple of chapters ago, that we could not provide an example for all of them. Nonetheless, we would like some assurance that any semantically valid request to transform one or more asserted version tables from one state to another state can be made with temporal transactions and can be carried out with the physical transactions that the AVF maps them into.
We know of two ways to do this. One is with the Allen relationships. The other is with our taxonomy of temporal extent state transformations. The relationship of these two ways of demonstrating completeness is this. While we will use the Allen relationships to compare temporal transactions to their target episodes, we will use the temporal extent state transformations to compare before and after states of a target database.
An Allen Relationship Completeness Check
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−1]. 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−1] 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−1] 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−1]. When a temporal transaction's effective time [meets] or [meets−1] 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−1] an adjacent episode, the result will be a {merge} transformation.
The [before], [before−1], [meets] and [meets−1] 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−1]. 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−1]. 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−1]. 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.