9. An Introduction to Temporal Transactions
Contents
Effective Time Within Assertion Time192
Explicitly Temporal Transactions: The Mental Model195
A Taxonomy of Temporal Extent State Transformations197
Glossary References211
Temporal transactions are inserts, updates or deletes whose targets are asserted version tables. But temporal transactions are not submitted directly to the DBMS. The work that has to be done to manage conventional tables is straightforward enough that we can let users directly manipulate those tables. But bi-temporal tables, including asserted version tables, are too complex to expose to the transaction author. The difference between what the user wants done, and what has to take place to accomplish it, is too great. And so temporal transactions are the way that the query author tells us what she wants done to the database, without having to tell us how to do it. The mechanics of how her intentions are carried out are encapsulated within our Asserted Versioning Framework. All that the application accepting the transaction has to do is to pass it on to the AVF.
A DBMS can enforce such constraints as entity integrity and referential integrity, but it cannot enforce the significantly more complex constraints of their temporal analogs. It is the AVF which enforces temporal entity integrity and temporal referential integrity. It is the AVF which rejects any temporal transactions that violate the semantic constraints that give bi-temporal data its meaning. It is the AVF that gives the user a declarative means of expressing her intentions with respect to the transactions she submits.
In the Asserted Versioning temporal model, the two bi-temporal dimensions are effective time and assertion time. If assertion time were completely equivalent to the standard temporal model's transaction time, then every row added to an asserted version table would use the date the transaction was physically applied as its assertion begin date. Important additional functionality is possible, however, if we permit rows to be added with assertion begin dates in the future. This is functionality not supported by the standard temporal model. But it comes at the price of additional complexity, both in its semantics and in its implementation.
Fortunately, it is possible to segregate this additional functionality, which is based on what we call deferred transactions and deferred assertions, and to discuss Asserted Versioning as though both its temporal dimensions are strictly analogous to the temporal dimensions of the standard temporal model. This makes the discussion easier to follow, and so this is the approach we will adopt. Deferred assertions, then, will not be discussed until Chapter 12.
Effective Time Within Assertion Time
A row in a conventional table makes a statement. Such a row, in a conventional Policy table, is shown in Figure 9.1.
 |
| Figure 9.1 A Non-Temporal Row. |
This row makes the following statement: “I represent a policy which has an object identifier of P861, a client of C882, a type of HMO and a copay of $15.” The statement makes no explicit reference to time. But we all understand that it means “I represent a policy which exists at the current moment, and which at the current moment has an object identifier of . . . . . ”.
This same row, with an effective time period attached, is shown in Figure 9.2.
 |
| Figure 9.2 A Uni-Temporal Version. |
It makes the following statement: “I represent a policy which has an object identifier of P861 and which, from January 2010 to July 2010, has a client of C882, a type of HMO and a copay of $15.” In other words, the row shown in Figure 9.2 has been placed in a temporal container, and is treated as representing the object as it exists within that container, but as saying nothing about the object as it may exist outside that container.
If we were managing uni-temporal versioned data, that would be the end of the story. But if we are managing bi-temporal data, there is one more temporal tag to add. This same row, with an assertion time period attached, is shown in Figure 9.3.
 |
| Figure 9.3 A Bi-Temporal Row. |
It makes the following statement: “I represent the assertion, made on January 2010 but withdrawn on October 2010, that this row represents a policy which has an object identifier of P861 and which, from January 2010 to July 2010, has a client of C882, a type of HMO and a copay of $15.” In other words, the row shown in Figure 9.2, as included in its first temporal container, has been placed in a second temporal container, and is treated as representing what we claim, within that second container, is true of the object as it exists within that first container, but as saying nothing about what we might claim about the object within its first container outside that second container.
From January to July, this statement makes a current claim about what P861 is like during that period of time. From July to October, this statement makes an historical claim, a claim about what P861 was like at that time. But from October on, this statement makes no claim at all, not even an historical one. It is simply a record of what we once claimed was true, but no longer claim is true.
All this is another way of saying (i) that a non-temporal row represents an object; (ii) that when that row is tagged with an effective time period, it represents that object as it exists during that period of time (January to July in our example); and (iii) that when that tagged row receives an additional time period tag, it represents our assertion, during the indicated period of time (January to October in our example) that the effective-time tagged row represents that object as it is/was during the other indicated period of time (January to July).
So an effective time tag qualifies the representation of an object, while an assertion time tag qualifies the effective-time qualified representation of an object. Effective time containment turns a row representing an object into a version. Assertion time containment turns a row representing a version into an assertion of a version, i.e. into a temporally delimited truth claim. 1 This is illustrated in Figure 9.4.
1And if there were no versioning, and non-temporal statements were contained directly in assertion time, i.e. non-temporal rows were given an assertion time tag but not an effective time tag, then assertion time containment would turn non-temporal statements directly into temporally delimited truth claims.
 |
| Figure 9.4 Assertions Are About Versions Are About Objects. |
Temporal integrity constraints govern the effective time relationships among bi-temporal rows. But, as we pointed out earlier, these effective time relationships apply only within shared assertion time. For example, when one version is asserted from January 2012 to April 2014, and another version of the same object is asserted from March 2012 to 12/31/9999, then the effective time periods of those two versions must not [intersect] from March 2012 to April 2014 in assertion time. But from January 2012 to March 2012, they neither [intersect] nor do not [intersect]. During those two periods of assertion time, the comparison doesn't apply. During those times, those two versions are what philosophers call “incommensurable”.
In the following discussion of temporal integrity constraints, we will assume that all the rows involved exist in shared assertion time.
Note that it is effective time that exists with assertion time, and not vice versa. If the semantic containment were reversed, it would be possible to have some rows which are in effect and which we assert to be true, and also have other rows which are in effect but which we do not assert are true. But when we say that a row is in effect from January to June, we are saying that it makes a true statement about what its object is like during that period of time. In other words, we are asserting that it is true.
Consider a row with an assertion time of [Mar 2012 – Aug 2012] and an effective time of [Jan 2012 – Dec 2012]. Clearly this means that, from March to August, we assert that this row makes a true statement about what its object was like from January to December. Barring deferred assertions, we can tell that on March 2012, we retroactively inserted this version, effective as of January 2012, and that on August 2012, we withdrew the assertion.
Explicitly Temporal Transactions: The Mental Model
In every clock tick within a continuous period of effective time, an object is either represented by a row or not represented. If it is represented, there is business data which describes what that object is like during that clock tick. So our three temporal transactions affect the representation of an object in a period of time as follows:
(i) A temporal insert places business data representing an object into one or more clock ticks of effective time.
(ii) A temporal update replaces business data representing an object in one or more clock ticks of effective time.
(iii) A temporal delete removes business data representing an object from one or more clock ticks of effective time.
In all three cases, those clock ticks are contiguous with one another, as they must be since they constitute a continuous period of effective time. Let's call that continuous span of clock ticks the target span for a temporal transaction. A designated target span can be anywhere along the calendar timeline. It can also be open or closed, i.e. it can use either a normal date or 12/31/9999 to mark the end of the span.
When the user writes a temporal insert transaction, she is doing two things. First, she is designating a target span of clock ticks. Second, she is specifying business data that she wants inserted into the table, and that will occupy precisely that effective time target span within current assertion time. That current assertion time starts Now(), i.e. when the transaction is processed, and continues on until further notice. We can say that this transaction, like every transaction that accepts the default values for effective time, creates a version that describes what its object looks like from now on, and also that this transaction, like every transaction other than the deferred ones, creates an assertion that, from now on, claims that the version makes a true statement.
When the user writes a temporal update, she is also doing two things. First, she is designating a target span of clock ticks. Second, she is specifying a change in one or more columns of business data, a change that she wants applied to every version or part of a version of the designated object that falls, wholly or partially, within that effective time target span, a change that will be visible in current assertion time but not in past assertion time. She is not, however, necessarily specifying a change that will be applied to every clock tick in that target span, because a temporal update transaction does not require that the object it designates be represented in every clock tick within its target span—only that it be represented in at least one of those clock ticks.
A temporal delete is like a temporal update except that it specifies that every version or part of a version of the designated object that falls, wholly or partially, within that target span will be, in current assertion time, removed from that target effective timespan. Like a temporal update, a temporal delete does not require that its designated object occupy (be represented in) all of the clock ticks of the target span, only that it occupy at least one of them.
It follows that it is possible for more than one episode to be affected by an update or a delete. All episodes that fall within the target span of an update or delete transaction are affected. This includes parts of episodes as well as entire episodes. Given a target timespan, it is possible for one episode to begin outside that span and either extend into it or extend past the end of it, and also for one episode to begin within that span and either end within that span or extend past the end of it. By the same token, within either or both of those partially included target episodes, the start or end of the target span may or may not line up with the start or end of a specific version. In other words, one version may start outside a target span but extend into or even through it, and another version may begin within a target span and either end within it or extend past the end of it.
The details of how these transactions work will be discussed in the rest of this chapter. But we can already see that the mental image of designating a target span of clock ticks and then issuing a transaction whose scope is limited to that target span, is intuitively clear. But it is one thing to provide a clear mental image—that of transactions as designating (i) an object, (ii) a span of time, (iii) business data and (iv) an action to take—but another thing to provide the details. To that task we now turn.
A Taxonomy of Temporal Extent State Transformations
Because of the complexities of managing temporal data, we need a way to be sure that we understand how to carry out every possible temporal extent state transformation that could be specified against one or more asserted version tables. A temporal extent state transformation is one which, within a given period of assertion time, adds to or subtracts from the total number of effective-time clock ticks in which a given object is represented. We need a taxonomy of temporal extent state transformations.
As we explained in Chapter 2, a taxonomy is not just any hierarchical arrangement we happen to come up with. It is one whose components are distinguished on the basis of what they mean—and not, for example, on the basis of what they contain, as parts explosion hierarchies are. It is also a hierarchical arrangement whose components are, based on their meanings, mutually exclusive and jointly exhaustive. Because good taxonomies are like this, constructing them is a way to be sure that we haven't overlooked anything (because of the jointly exhaustive property) and haven't confused anything with anything else (because of the mutually exclusive property).
We begin with objects and episodes. The target of every temporal transaction is an episode of an object. Semantically, it is episodes which are created or destroyed, or which are transformed from one state into another state. Physically, of course, it is individual rows of data which are created and modified (but never deleted) in an asserted version table. But what we are concerned with here is semantics, not bits and bytes, not strings of letters and numerals. From a semantic point of view, episodes are the fundamental managed objects of Asserted Versioning.
Figure 9.5 shows our taxonomy. Under each leaf node, we have a graphic representing that transformation. A shaded rectangle represents an episode, and a non-shaded rectangle represents the absence of an episode. A short vertical bar separates the before-state, on the left-hand side, from the after-state, on the right-hand side, produced by a transformation.
 |
| Figure 9.5 A Taxonomy of Temporal Extent State Transformations. |
Each of the nodes in our Allen relationship taxonomy are referred to, in the text, by surrounding the name of the node with brackets, for example as with [meets], [during−1], [intersects], etc. We also underline the names of nodes which are not leaf nodes. We will use a similar convention for this taxonomy of temporal extent transformations, referring to each of its nodes by surrounding the name of the node with curly braces, for example as with {remove}, {shorten forwards}, {shorten}, etc.
With any type of thing we are concerned with, there are three basic things we can do with its instances. We can create an instance of it, modify an existing instance, or remove an instance. This is reflected in the three nodes of the first level underneath the root node.
Of course, in the case of episodes, the {erase} transformation is neither a physical nor a logical deletion. Instead, it is the action in which the entire episode is withdrawn from current assertion time into past assertion time.
{Create}, {modify} and {erase} are clearly jointly exhaustive of the set of all temporal extent transformations, and also mutually exclusive of one another. Thus, at its first two levels, this taxonomy is, as all taxonomies must be, a partitioning.
At the level of abstraction we are dealing with, there is no further breakdown of either the {create} or {erase} transformations. Of course, there are variations on those themes, as we will see in the next chapter. For example, we can create an episode retroactively, or in current time, or proactively, and similarly for modifying or erasing an episode.
As 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 lengthen an episode's representation in effective time from transformations that shorten it. Thus, we extend the property of being a mathematical partitioning down to the third level of this taxonomy. And again, as with the {create} and {erase} transformations, there are similar variations.
Next, for both the {lengthen} and {shorten} transformations, it is possible to do so at the beginning or at the end of the episode. And so 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.
Another way to reassure ourselves of the completeness of this taxonomy is to note its bilateral symmetry. If the diagram were folded along a vertical line running between the {merge} and {split} nodes, and also between the {lengthen forwards} and {shorten backwards} nodes, each transformation would overlay the transformation that is its inverse.
A third way to assure ourselves of completeness is to analyze the taxonomy in terms of its topology. On a line representing a timeline, we can place a line segment representing an episode. We can also remove a line segment from that line. Given a line segment, we can either lengthen it forwards or backwards, shorten it forwards or backwards, or split it. Given two line segments with no other segments between them, we can merge them (by lengthening one forwards towards the other and/or lengthening the other backwards towards the first, until they [meet]). There is nothing that can be done with the placement of segments on a line that cannot be done by means of combinations and iterations of these basic operations.
Finally, we need to be aware of the different scenarios possible under each of these nodes. As we have already pointed out, any of these transformations can result in changes to past, present or future effective time. Additional variations come into play when we distinguish between transformations that are applied to closed or to open episodes, and between transactions which leave an episode in a closed or open state.
With eight possible topological transformations, nine possible combinations of past, present and future effective time (three for the target and three for the transaction), and four possible open/closed combinations (two for the target and two for the transaction), we have a grand total of 288 scenarios. And this doesn't even take into consideration deferred assertions, which would at a minimum double the number of scenarios. Of course it might be possible to eliminate some of these scenarios as semantically impossible, i.e. as corresponding to no meaningful state and/or no meaningful transformation; but each one would still have to be analyzed.
We cannot analyze every one of these scenarios. Instead, our approach will be to analyze one variation of each temporal extent transformation, and then briefly discuss other variations which appear to be interestingly different.
The Asserted Versioning Temporal Transactions
Figure 9.6 shows three episodes—A, B and C—located along a four-year timeline. Eight versions make up these three episodes, which are all episodes of the same object, policy P861. We will be referring to this diagram throughout our discussion of temporal transactions.
 |
| Figure 9.6 Eight Versions and Three Episodes of Policy P861. |
In the syntax used for the transactions shown below, values are associated with business data columns by means of their position in a bracket-delimited, comma-separated series of values. Except for the object identifier, which occupies the first position, the other six columns which implement Asserted Versioning are not included in this list, those other columns being effective begin date, effective end date, assertion begin date, assertion end date, episode begin date and row create date. And of those six temporal parameters, only the first three may be specified on a temporal transaction.
The syntax used in this book for temporal transactions is not the syntax in which those transactions will be submitted to the AVF. That is, it is not the syntax with which the AVF will be invoked. We use it because it is unambiguous and compact. The actual transactions supported by release 1 of the AVF can be seen at our website, AssertedVersioning.com.
Every temporal transaction may supply an oid, a business key or both. In addition, every asserted version table has either reliable business keys, or unreliable ones. This gives us eight possible combinations of oids with reliable or unreliable business keys, for each of our three temporal transactions.
For every temporal transaction, the first thing the AVF does is to perform edits and validity checks. As we will see below, these eight combinations are the checklist the AVF uses for its validity checks.
The edit checks work like this. Following the object identifier are comma-delimited places for the business data associated with the object. In this case, that business data is, in order, client, policy type and copay. Following this set of values is a set of three asserted version dates. The effective begin date defaults to the current date, but may be overridden with any date, past, present or future, that is not 12/31/9999. The effective end date defaults to 12/31/9999, but may be overridden with any other date that is at least one clock tick later than the effective begin date. Assertion dates on transactions will be discussed in Chapter 12. Until then, we assume that the assertion begin date on all transactions takes on its default value of the date current when the transaction takes place. The assertion end date can never be specified on temporal transactions, and is always set to 12/31/9999.
After doing edit checks to insure that each element of the transaction, including its data values, is well formed, the AVF does validity checks on the transaction as a whole. Only if a transaction passes both edit and validity checks will the AVF map it into one or more physical SQL transactions, submit those transactions to the DBMS, and monitor the results to insure that either all of them or none of them update the database, i.e. that they make up a semantically complete atomic unit of work.
The Temporal Insert Transaction
The format of a temporal insert transaction is as follows:
INSERT INTO {tablename} [,,, ] eff_beg_dt, eff_end_dt, asr_beg_dt
The validity checks work like this:
(i) No oid, no business key, business key is reliable. In this case, the AVF rejects the insert. The reason is that if the business key is reliable, an insert must provide it, even if it also provides an oid. Otherwise, it would be like an insert to a conventional table with a missing or incomplete primary key.
(ii) No oid, no business key, business key is not reliable. In this case, the AVF accepts the insert and assigns it a new oid. The reason is that if a business key is not reliable, it is not required on an insert transaction. Since no business key match logic will ever be carried out on tables with unreliable business keys, it doesn't matter if rows lacking those business keys make their way onto those tables.
(iii) No oid, business key present, business key is reliable. In this case, the AVF looks for a match on the business key. If it finds one, it assigns the oid of the effective-time latest matching row to the transaction. Otherwise, it assigns a new oid to the transaction. The reason is that multiple appearances of the same object, separated by gaps in time, should be recognized as multiple appearances of the same object whenever possible, and not as appearances of different objects.
(iv) No oid, business key present, business key is not reliable. In this case, the AVF accepts the insert and assigns it a new oid. The reason is that if the business key is not reliable, it doesn't matter, and so the AVF proceeds as though the business key were not there. Note that in this case, multiple temporal inserts which lack an oid but which contain the same business key value will result in multiple object identifiers all using that same value. Semantically, the business key will be a homonym, a single value designating multiple different objects. This, of course, is precisely what the “unreliable” means in “unreliable business key”.
(v) Oid present, no business key, business key is reliable. In this case, the AVF rejects the insert. The reason is the same as it was for case (i); if the business key is reliable, an insert must provide it. Otherwise, it would be like an insert to a conventional table with a missing or incomplete primary key.
(vi) Oid present, no business key, business key is not reliable. In this case, the AVF accepts the insert and uses the oid supplied with it. The reason is that if the business key is not reliable, it doesn't matter, and so the AVF proceeds as though the business key were not there. And if the oid is already in use, that doesn't matter. If it is in use, and there is a collision in time periods, temporal entity integrity checks will catch it.
(vii) Oid present, business key present, business key is reliable. In this case, the AVF looks for a match on the business key. If it finds a match, and the oid of the matching row matches the oid on the transaction, the AVF accepts the transaction. If it finds a match, but the oid of the matching row does not match the oid on the transaction, the AVF rejects the transaction. If it does not find a match, and the oid on the transaction does not match any oid already in use, the AVF accepts the transaction. And if it does not find a match, but the oid on the transaction does match an oid already in use, the AVF rejects the transaction. The reason behind all this logic is that when both an oid and a reliable business key are present, any conflict makes the transaction invalid.
(viii) Oid present, business key present, business key is not reliable. In this case, the AVF accepts the insert and uses the oid supplied with it. The reason is that if the business key is not reliable, it doesn't matter, and so the AVF proceeds as though the business key were not there. And if the oid is already in use, that doesn't matter. If it is in use, and there is a collision in time periods, temporal entity integrity checks will catch it. Note that if the oid is in use, and there is no collision in time periods, then if the business key is a new one, the result of applying the transaction is to assign a new business key to an object, in clock ticks not previously occupied by that object.
The Temporal Insert Transaction: Semantics
In a conventional table, if an object is not represented and the user wishes to represent it, she issues an insert transaction which creates a row that does just that. The insert transaction expresses not only her intentions, but also her beliefs. It expresses her intention to create a representation of an object, as it currently exists, in the target table. But it also expresses her belief that such a representation does not already exist. If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen.
In an asserted version table, the question is not whether or not the object is already represented, but rather whether or not the object is already represented during all or part of the target timespan indicated on the transaction. If the user submits a temporal insert transaction, she also expresses both intention and belief. Her intention is to create a representation of an object in an effective time target span. Her belief is that such a representation does not already exist anywhere in that target span. If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen.
Another aspect of the semantics of a temporal insert is the interpretation of its target span. If the transaction does not supply an effective end date, that date defaults to 12/31/9999. The result is that an open episode will be created. However, in the scenario shown in Figure 9.6, an open episode cannot be created, and the AVF will reject the attempt to create one. For if we tried to create an open episode with an effective begin date prior to version 7, that new episode would collide with one of the three episodes shown, and thus violate the temporal entity integrity (TEI) constraint. And if we tried to create an open episode, or in fact any episode, with an effective begin date on or after May 2013, it would collide with Episode C, whose effective end date is 12/31/9999.
It follows that there can be at most one open episode for an object, within any period of assertion time. No episode, open or closed, can be created later than an open episode because if it were created, it would occupy effective time already occupied by that open episode. And an open episode cannot be created earlier than any other episode, open or closed, for the same reason.
What of a temporal insert that specifies a non-12/31/9999 effective end date? Here the situation is more straightforward. Such transactions satisfy TEI just in case none of the clock ticks specified in the transaction's target span are already occupied by that object. And we should remember that because of our closed-open convention, TEI will still be satisfied if an episode already exists whose begin date has the same value as the end date of the transaction's target span, or one whose end date has the same value as the begin date of the transaction's target span, or if both such episodes are present.
The Temporal Insert Transaction: Mechanics
The scope of a conventional insert is a single row in the target table. If the transaction is successful, the result is a new row added to the table. The scope of a temporal insert is a designated period of effective time, within current assertion time. So, in Figure 9.6, that scope cannot include any of the clock ticks already occupied by any of the three episodes shown there, but can include any other clock ticks. We should note that this means that the scope of the insert cannot be any clock tick from May 2013 forward. Since Episode C is open, it extends to 12/31/9999; consequently any other episode for the same object anywhere in the effective period starting with May 2013 would [intersect] that episode.
So a temporal insert of P861, given the state of the target table shown in Figure 9.6, can have an effective begin date which is any clock tick not occupied by any of the three episodes. What, then, of the effective end date? With a basic scenario temporal insert, both the effective begin and end dates are left to take on their default values which are, respectively, the date current when the transaction is applied, and 12/31/9999. But just as the effective begin date can be overridden on a transaction, so too can the effective end date.
What this means is that when a new episode is created, it does not need to be created as an open episode. If the user happens to know the effective end date for an episode of an object she is creating, she can specify this date on the temporal insert, as long as it is at least one clock tick later than the effective begin date, and does not [intersect] a time period already occupied by another episode of the same object.
In the scenario shown in Figure 9.6, in fact, a temporal insert would have to specify an effective end date. The reason is that no matter what the effective begin date is, an effective end date of 12/31/9999 would [intersect] one of the episodes already in the table.
For example, a temporal insert could place a new episode between the second two episodes, but given that our clock ticks only once a month, it would be a tight fit. In fact, there are only three possibilities. They are:
(i) P861[Feb 2013 – Mar 2013]
(ii) P861[Feb 2013 – Apr 2013]
(iii) P861[Mar 2013 – Apr 2013]
There are four ways in which Episode B could be {lengthened forwards}, the last listed of which would {merge} it with Episode C. They are:
(i) P861[Jan 2013 – Feb 2013]
(ii) P861[Jan 2013 – Mar 2013]
(iii) P861[Jan 2013 – Apr 2013]
(iv) P861[Jan 2013 – May 2013]
And there are also four ways in which Episode C could be {lengthened backwards}, the first listed of which would {merge} it with Episode B. They are:
(i) P861[Jan 2013 – May 2013]
(ii) P861[Feb 2013 – May 2013]
(iii) P861[Mar 2013 – May 2013]
(iv) P861[Apr 2013 – May 2013]
As we said earlier, no temporal insert would be valid that specified an effective time period of May 2013 or later. However, any temporal insert would be valid that specified an effective time period that ended on February 2010 or earlier because that insert would not result in a time period that [intersected] any time period for P861 already in the target table.
Sometimes we have no open episode of an object, but we may want to wake up the latest closed episode and change it to an open episode. It is only the latest episode of an object that can be transformed into an open episode, of course, because if it were not the latest, it would then collide with the next later episode and thus violate the TEI constraint.
So if a temporal insert specifies a 12/31/9999 end date, and no effective begin date is provided, the target span is [Now() – 12/31/9999]. An insert with this target timespan will wake up an existing episode of an object only if (i) there is a closed episode of the object already in the target table, and its effective end date is Now() (a situation which is very unlikely to occur when timestamps rather than dates are used to specify temporal parameters); and (ii) there are no representations of the object which begin in future effective time. So we cannot wake up a closed episode unless we supply an effective begin date on an insert transaction which matches the effective end date of an existing episode, and there are no other episodes of that object in later effective time.
Waking up a closed episode is a special case of the {lengthen episode forwards} transformation. But in every case, what the user must do to lengthen an episode forwards is to specify a target span whose effective begin date matches the effective end date of the last version of a closed episode, and whose effective end date does not [intersect] that of the next later episode of that object, if there is one. In this latter case, the episode is {lengthened forwards} because an unknown end date (represented by 12/31/9999) is replaced by a known end date.
The Temporal Update Transaction
The format of a temporal update transaction is as follows:
UPDATE {tablename} [,,, ] eff_beg_dt, eff_end_dt, asr_beg_dt
The validity checks work like this:
(i) No oid, no business key, business key is reliable. In this case, the AVF rejects the update. The reason is that an update must attempt to find a match, and must be rejected if it cannot make that attempt. Lacking both an oid and a reliable business key, the transaction cannot be matched to what is already in the target table.
(ii) No oid, no business key, business key is not reliable. In this case, the AVF rejects the update, for the same reason as for case (i).
(iii) No oid, business key present, business key is reliable. In this case, the AVF looks for a match on the business key. If it finds one, it assigns the oid of the matching row to the transaction. Otherwise, it rejects the transaction. The reason is that reliable business keys are unique identifiers of objects, and that, because all temporal insert transactions to tables with reliable business keys must have a business key on the transaction, all existing rows for the same object will contain that reliable business key. This means that a temporal update with a non-matching reliable business key is just like a conventional update which cannot match a primary key. It is a mistaken update.
(iv) No oid, business key present, business key is not reliable. In this case, the AVF rejects the update. The reason is that if the business key isn't reliable, it doesn't matter if it's there or not, and so the AVF proceeds as though the business key were not there. Note that if we did attempt a match on the business key, and were successful, we might or might not have the right oid to assign to the transaction. We can't be sure because the AVF can't guarantee that an unreliable business key value is not being used by two or more oids. If we use a match on a business key that may be associated with several different objects, then unless we have an oid supplied by the transaction itself, we have no way of knowing which oid is the correct target of the transaction.
(v) Oid present, no business key, business key is reliable. In this case, the AVF looks for a match on the oid. If it finds one, it accepts the transaction. Otherwise, it rejects it. The reason is obvious. Note that, unlike inserts, updates to tables with reliable business keys are not required to have the business key on the transaction.
(vi) Oid present, no business key, business key is not reliable. In this case, the AVF looks for a match on the oid. If it finds one, it accepts the transaction. Otherwise, it rejects it.
(vii) Oid present, business key present, business key is reliable. In this case, the AVF looks for a match on the business key. If it finds a match, and the oid of the matching row matches the oid on the transaction, the AVF accepts the transaction. If it finds a match, but the oid of the matching row does not match the oid on the transaction, the AVF rejects the transaction. If it does not find a match, and the oid on the transaction does not match any oid already in use, the AVF rejects the transaction. And if it does not find a match, but the oid on the transaction does match an oid already in use, the AVF rejects the transaction. The reason behind all this logic is that when both an oid and a reliable business key are present, any conflict makes the transaction invalid; and when a temporal update has an oid and business key that do agree, but that do not match anything on the target table, the temporal update fails the match, and is rejected.
(viii) Oid present, business key present, business key is not reliable. In this case, the AVF attempts to match on the oid. If it does, it accepts the transaction, and otherwise rejects it. Note that if the business key is a new one, then when the transaction is applied, it assigns a new business key to an object, in clock ticks already occupied by that object.
The Temporal Update Transaction: Semantics
In a conventional table, if an object is represented and the user wishes to modify the row doing the representing, she issues an update transaction which overwrites the data to be changed with the data that changes it. The update transaction expresses not only her intentions, but also her beliefs and assumptions. It expresses her intention to update a representation of an object, but it also expresses her belief that such a representation already exists. If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen.
In an asserted version table, the question is not whether or not the object is already represented, but rather whether or not the object is already represented, in current assertion time, within the effective-time target span indicated on the transaction. If the user submits a temporal update transaction, she also expresses both intention and belief. Her intention is to modify a currently asserted representation of an object in every clock tick within the target effective timespan. Her belief is that such a representation already exists in at least one clock tick within that target span. If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen.
The Temporal Update Transaction: Mechanics
Here are some examples that will illustrate how this interpretation of the target timespans on temporal update transactions works. Consider a temporal update with a [Nov 2011 – 12/31/9999] target timespan. This update affects all versions in Episodes B and C shown in Figure 9.6. A temporal update with an [Apr 2012 – Oct 2013] scope affects entire versions, but partial episodes. It will update versions 5–7, i.e. the last two versions of Episode B and the first version of Episode C.
For our final example, let's consider an update that affects partial versions. Suppose that the temporal update specifies a target span of [Jan 2012 – May 2012]. January 2012 is the third clock tick within version 3, and is not the last clock tick within that version. So the AVF must split version 3 into two versions, the first covering [Nov 2011 – Jan 2012] and the second covering [Jan 2012 – Mar 2012]. Call these two versions 3a and 3b, respectively. In just the same way, the AVF must split version 5 into versions 5a and 5b. Version 5a's effective target span is [Apr 2012 – May 2012], and 5b's is [May 2012 – Aug 2012].
Versions 3, 4 and 5 are then withdrawn into past assertion time. Versions 3a and 5b replace the unaffected parts of versions 3 and 5, in current assertion time. Finally, the update is applied to 3b, 4 and 5a, which now supercede the versions that previously occupied that effective target span in current assertion time.
Notice that the semantics we have given to temporal updates which span episodes is that they do not “fill in the gaps” between episodes. Filling in the gaps is left to temporal inserts, whose job is to place the representation of an object into one or more clock ticks that did not previously contain one. By the same token, temporal updates cannot be used for any {lengthen} transformation. Since any such expansion puts the representation of an object into one or more previously unoccupied clock ticks, temporal inserts are used for all of them.
The Temporal Delete Transaction
The format of a temporal delete transaction is as follows:
DELETE FROM {tablename} [,,, ] eff_beg_dt, eff_end_dt, asr_beg_dt
The validity checks work exactly as they do for temporal update transactions. The reason is that a temporal update is equivalent to a temporal delete followed by a temporal insert. So for purposes of validity checking, exactly the same logic applies to both.
Other than supplying the business key when the object identifier is not known, there is no business data to specify on a temporal delete. The target timespan picks out the effective-time range which is to be left empty of any representation of the object, in current assertion time, after the transaction has completed. The delete withdraws any such representations into past assertion time, leaving those corresponding effective time clock ticks unoccupied by the object in current assertion time.
The Temporal Delete Transaction: Semantics
In a conventional table, if an object is represented and the user wishes to delete it, she issues a delete transaction which deletes the one row representing the object. And once again, this kind of transaction expresses not only her intentions, but also her beliefs. It expresses her intention to delete a row representing an object, but it also expresses her belief that such a row is currently there to delete. If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen.
In an asserted version table, the question is not whether or not the object is already represented, but rather whether or not the object is represented, in current assertion time, within the target effective time span. If the user submits a temporal delete transaction, she also expresses both intention and belief. Her intention is to remove the representation of an object from the indicated timespan. Her belief is that such a representation already exists in one or more of the clock ticks within that target span. If she is mistaken in her belief, her transaction is rejected, which is precisely what she would expect and want to happen.
The Temporal Delete Transaction: Mechanics
The scope of a conventional delete is a single row in the target table. If the transaction is successful, the result is that the designated row is deleted from the table. The scope of a temporal delete is any set of one or more contiguous effective time clock ticks at least one of which contains a representation of the object. So, in Figure 9.6, it must include at least one of the clock ticks occupied by Episodes A, B or C.
In Chapter 7, we looked at a basic temporal delete transaction, submitted in December 2010, that specified a target timespan of [Now() – 12/31/9999], and we saw what the AVF did in response to that transaction. It found that an episode did exist whose effective time period [intersected] that target span. It split that episode into two parts. The part from the episode's begin date to (the then-current value of) Now() lay outside the target timespan, while the part from Now() to the end of the episode was found to lie entirely within the target timespan. This split occurred within the latest version of that episode. So the AVF split that version, withdrew it, and replaced the effective time earlier, unaffected part. Since the target timespan extended to 12/31/9999, no later part of the episode lay outside that target span, so nothing else was replaced. The transaction terminated a current episode as of Now(). But in doing so, it went through exactly the same steps that all temporal deletes go through.
Glossary References
Glossary entries whose definitions form strong inter-dependencies are grouped together in the following list. The same glossary entries may be grouped together in different ways at the end of different chapters, each grouping reflecting the semantic perspective of each chapter. There will usually be several other, and often many other, glossary entries that are not included in the list, and we recommend that the Glossary be consulted whenever an unfamiliar term is encountered.
We note, in particular, that none of the nodes in our taxonomy of temporal extent transformations are included in this list. In general, we leave taxonomy nodes out of these lists, but recommend that the reader look them up in the Glossary.
12/31/9999
Now()
asserted version table
Asserted Versioning Framework (AVF)
assertion
assertion begin date
assertion end date
assertion time
shared assertion time
statement
transaction time
version
bi-temporal
uni-temporal
business data
business key
reliable business key
unreliable business key
clock tick
closed-closed
closed-open
open-closed
open-open
closed episode
episode
episode begin date
open episode
conventional table
conventional transaction
deferred assertion
deferred transaction
effective begin date
effective end date
effective time
incommensurable
intersect
occupied
represented
managed object
object
object identifier
oid
replace
supercede
terminate
withdraw
row creation date
target episode
target span
temporal transaction
temporal dimension
temporal entity integrity (TEI)
temporal referential integrity (TRI)
temporal extent
temporal extent state transformation
the alternative temporal model
the standard temporal model
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.