7. The Basic Scenario
When representing an object in a non-temporal table, the most basic things we can do are to insert a row representing the object, update the row as changes happen to the object, and delete the row if and when the object ceases to exist, or ceases to be of interest to us. Almost always, we don't know in advance if or when any of these things will happen: if or when a row will be inserted; if or when the next update will occur; if or when the row will be deleted.
These rows represent objects of interest to us. They are not the objects themselves. A row in a Policy table is not a policy; it is data which represents the policy in our database. Through the DBMS, for the most part mediated by application software, we manage these rows. We insert them, update them and sometimes delete them. We put them in result sets in response to queries. We put them on reports. By managing them, we are able to manage the policies which they represent. For this reason, we will call these rows managed objects.
Sometimes it is harmless enough to finesse this distinction, and speak of the DBMS, for example, updating policies. But what the DBMS updates, of course, are rows representing policies. It updates managed objects, not the objects they represent. As we enter into a series of chapters which will describe our method of temporal data management in great detail, we will sometimes find it useful to emphasize the distinction between objects and managed objects. But if we do occasionally speak of software doing something to an object, that will simply be a non-tendentious shorthand for speaking about software doing something to a managed object which represents that object.
This basic sequence of insert, update and delete transactions accounts for most of the activity against any table, whether non-temporal or bi-temporal. And just as we usually don't know if or when updates to a non-temporal row will occur, and if or when it will be deleted, so too, as each row representing some stage in the life history of an object is inserted into a bi-temporal table, we usually don't know if or when another row for that same object will come along.
In this chapter, we will follow a sequence of basic temporal transactions. Temporal transactions are inserts, updates and deletes whose target is an asserted version table. As we explained in Chapter 5, all asserted version tables are bi-temporal tables. Uni-temporal assertion tables and uni-temporal version tables, as we sometimes call them, are actually views on bi-temporal tables. Conventional tables, which we also call non-temporal tables, are the third kind of view which can be defined on Asserted Versioning's physical bi-temporal tables.
Basic temporal transactions are temporal transactions that do not specify any bi-temporal parameters. As we will see later, any one or more of three bi-temporal parameters—an assertion begin date, an effective begin date or an effective end date—may be specified on a temporal transaction. On a basic temporal transaction, none of them are specified.
By starting out with basic temporal transactions, we can introduce the most common sequence of transactions that occur against asserted version tables, and show how these transactions are processed. In chapters that follow, we will examine temporal transactions which are not basic, and whose processing is considerably more complex, although because of the maintenance encapsulation provided by Asserted Versioning, are just as easy for the user to write as are basic temporal transactions.
The Representation of Objects in Time Periods
The basic scenario, and by far the most commonly encountered one, is for a series of updates that would overwrite data in a conventional table to result in an effective-time contiguous series of versions in an asserted version table. Just as it is logically impossible to apply an update to a conventional table that takes effect either in the past or in the future, basic temporal updates to asserted version tables also take place in the present. Just as an update to a conventional table remains in effect until further notice, rather than for a predetermined length of time, a basic temporal update to an asserted version table will be to a current episode that is open, i.e. whose latest version has an effective end date of 12/31/9999, and it will always leave that episode open after the transaction is complete.
Basic temporal transactions are the Asserted Versioning equivalent of conventional transactions. No bi-temporal parameters are specified on them, and so their content is identical to that of their corresponding conventional transactions. They contain exactly the same information that is present on conventional transactions—nothing more and nothing less. But if temporal transactions are to take effect some time in the future, or some time in the past, then those non-current effective time periods must be explicitly specified on those transactions. And if we wish to update the database with deferred assertions, the assertion begin date must also be specified. In these cases, the temporal transactions are no longer basic; they explicitly state the bi-temporal parameters they want.
Corresponding to each appearance of a managed object in a conventional table, i.e. to each period of time starting when a row for an object is inserted and ending if and when it is deleted, there would be an episode of that object if that table were instead an asserted version table. It follows that there can be any number of episodes of the same object present at the same time in an asserted version table, although no more than one of them, of course, can be current. Each episode is a managed object, representing an object as it exists over a continuous period of time. Each version of that episode is also a managed object, representing an object as it exists over one continuous period of time that is included within the episode's period of time.
In Figure 7.1, eight versions, grouped into three episodes, are shown along a timeline. The first two episodes are closed, as all but the latest episode of an object must be. The last one is open. All are managed objects representing one object, policy P861.
 |
| Figure 7.1 Eight Versions and Three Episodes of Policy P861. |
Occupied and Represented
In subsequent discussions, we will find it convenient to speak of time periods as being occupied by an object or, equivalently, of an object being represented in a time period by a managed object. In a conventional table, a time period is occupied by an object just in case a row representing that object exists in its table throughout that time period. In an asserted version table, a time period is occupied by an object just in case one or more contiguous versions representing that object span that time period or, as we will also say, occupy every clock tick in that time period. For example, the clock tick of March 2010 is occupied by policy P861 just in case there is a row with the value “P861” as its object identifier and which has an effective begin date less than or equal to March 2010 and an effective end date greater than March 2010. We can equivalently say that policy P861 is represented in the effective time clock tick of March 2010.
Because Asserted Versioning is a method of managing bi-temporal data, the time periods in question may be either effective time periods or assertion time periods. But we will often find it convenient to speak simply about versions and their effective times, presupposing that the rows we are talking about all exist in current assertion time.
Basic Temporal Transactions: The Mental Model
The mental model supported by basic temporal transactions is one which completely hides the temporality of the tables that those transactions maintain. As far as the user is concerned, she submits transactions to a program, which then submits them to the DBMS. It is no concern of hers that the program actually calls the AVF which, after some translation and constraint checking, submits one or more SQL transactions to the DBMS. Rather, it seems to her that she is inserting, updating or deleting rows in conventional tables.
Consequently, the user thinks about what she is doing in the same way whether she is updating a conventional table or an asserted version table. This means that as long as the user writes basic temporal transactions—which will be the vast majority of temporal transactions she will write—maintenance of temporal rather than conventional data places no additional semantic burden on her.
Maintaining Asserted Version Tables: The Basic Scenario
In response to a temporal transaction, the AVF generates one or more physical transactions and at the same time enforces temporal entity integrity and temporal referential integrity. In this way, it encapsulates bi-temporal complexity, and preserves for the user the image of a single transaction affecting a single physical representation of a single object.
Let's now see how temporal transactions are mapped to physical transactions in this situation we call the basic scenario. To avoid unnecessary complications in this initial look at how asserted version tables are updated, we will ignore temporal referential integrity issues, and leave an explanation of how they work to a later chapter.
A Temporal Insert Transaction
Figure 7.2 shows the mapping for a temporal insert transaction. In the example shown in Figure 7.3, the transaction specifies no bi-temporal parameters and is therefore a basic transaction.
 |
| Figure 7.2 Basic Scenario, Insert Transaction: Temporal to Physical Mapping. |
 |
| Figure 7.3 Basic Scenario, Temporal Insert: Before the Physical Transaction. |
Assertion begin and end dates delimit the assertion time period for a row in an asserted version table. For the next several chapters, we will assume that all temporal transactions accept the default value for the assertion begin date, that default value being the date current when the version is created. As long as this is the case, our assertion time periods will behave like what the standard temporal model calls transaction time periods. This means that an assertion begin date will function like a row creation date. Not only are both assigned the date current when the physical transaction is applied, but also once created, neither date can be changed. 1
1In fact, a future assertion begin date can be changed. But in this basic scenario, we are limiting ourselves to temporal transactions which use the current date as the assertion begin date. And neither past nor current assertion begin dates can be changed because once we begin to claim that something is so, we can't “take it back”. If we did, we would lose the information that once upon a time, we did make such claims. And it is an explicit objective of bi-temporal data management to preserve such information.
An insert into a non-temporal table is valid just in case a row for the object does not exist in the target table at the time of the insert. In the same way, a temporal insert into an asserted version table is valid just in case no version for that object exists in the target table, at the time of the insert, anywhere within the effective time period specified on the transaction. If such a version did exist, its time period would [intersect] that of the transaction. Since every version is part of an episode, the intersection of an insert transaction with a version already in the table is a temporal entity integrity conflict. It is equivalent, if only for a single clock tick, to an attempt to insert a row into a non-temporal table which has the same primary key as a row already in that table.
Thus, an insert whose target is an asserted version table is valid if the target table is empty, and is also valid if the target table contains other episodes of the same object, provided that the transaction's effective time period does not [intersect] the effective time period of any of those other episodes. In the non-temporal case, this constraint is known as entity integrity. In the Asserted Versioning case, it is what we call temporal entity integrity (TEI).
The physical transaction is derived from the temporal transaction by the AVF. Before it is applied, the target table is as shown in Figure 7.3. In this example, it is now January 2010.
Figure 7.4 shows the result of applying the physical transaction derived from this temporal transaction to the target table. The unique identifier of the policy is its object identifier, P861. The AVF supplied this unique identifier, since on an insert transaction, a surrogate key value has not yet been assigned to represent the object. This version is effective beginning in January 2010 because it was applied in January 2010 and no effective begin date was specified on the temporal transaction. It will remain in effect until further notice because no effective end date was specified.
 |
| Figure 7.4 Basic Scenario, Temporal Insert: After the Physical Transaction. |
The third component of the primary key of an asserted version table is the assertion begin date. Because no assertion begin date was specified on the temporal transaction, the current date is used. In other words, the default is for a version to be asserted as soon as it is created. The assertion end date is set to 12/31/9999, as it is for all temporal transactions, meaning that we will continue to assert what this row represents until further notice.
A valid temporal insert transaction results in a new episode unless it [meets] or [meets-1] an adjacent episode. If it [meets-1] an earlier episode, its begin date matches the end date of that earlier episode, and it has the effect of extending that episode forwards in time. If it [meets] a later episode, its end date matches the begin date of that later episode, and it has the effect of extending that episode backwards in time. 2 And if it does both, its begin and end dates match, respectively, the end date of the earlier episode and the begin date of the later episode, and it has the effect of “filling in the gap” between those two episodes, merging them into a single episode. In this chapter, however, we assume that our temporal insert creates a new episode.
An episode begin date is always set to the effective begin date of its earliest version. So in this case, since this transaction creates the initial version of a new episode, the episode begin date is set to January 2010.
A Temporal Update Transaction
In the scenario shown in Figure 7.5, it is now May 2010, and we are about to change the policy's copay amount to $20.
 |
| Figure 7.5 Basic Scenario, Temporal Update: Before the First Physical Transaction. |
We can read this diagram as follows. Row 1 represents the only version of this episode of policy P861. The business data on this row became effective on January 2010. It is currently in effect and will remain in effect until further notice. We currently assert that row 1 is correct, i.e. that the statement made by row 1 is true.
Since January 2010, this policy has been owned by client C882, and has been an HMO policy with a $15 copay. The client column is a temporal foreign key (TFK), implementing a temporal referential integrity relationship (TRI). It designates an object in a referenced asserted version Client table (not shown), but it does not designate any specific version or episode of that object. The AVF would not have permitted row 1 to be created, however, unless it satisfied the TRI constraint.
This means that, at the time the temporal update took place—which is indicated by the row creation date—the AVF was able to find an episode of client C882 whose effective time period included that of the new policy episode. In other words, there was, at that time, an episode of C882 with an effective begin date on or before January 2010, and an effective end date of 12/31/9999.
This policy row was inserted into the table in January 2010. There are several columns with a January 2010 value in row 1, but the column that records the physical insertion date is the row creation date column. This row was immediately asserted, meaning that we were ready, right away, to claim that the row makes a true statement. Until further notice, this row will be what we return to any query asking about what we currently believe is the case about this policy during this effective time period. At the time this row was created, no row for P861 was current, i.e. it was not the case that there was a row for P861 whose effective time period and assertion time period were both then current.
Updating the data about policy P861 is not the same thing as updating the row we currently have for that policy, as it would be if the Policy table were a non-temporal table. Instead, to update the policy while retaining the data which is about to be replaced and superceded by the new data in the update transaction, three physical transactions have to be applied to the target table. Figure 7.6 shows a temporal update transaction and its mapping into three types of physical transactions, resulting in any number of individual physical transactions.
 |
| Figure 7.6 Basic Scenario, Update Transaction: Temporal to Physical Mapping. |
The First Physical Transaction
The result of applying the first of these physical transactions is shown in Figure 7.7. This physical transaction withdraws the current assertion. It does so by doing a physical update of row 1, overwriting its assertion end date with the same date on which the two new versions will begin to be asserted. In this case, that is the same date as the date of the transaction itself, i.e. May 2010. In Figure 7.7, we can see that the database now shows that row 1 was asserted from January 2010 to May 2010, but not after that.
 |
| Figure 7.7 Basic Scenario, First Temporal Update: After the First Physical Transaction. |
Row 1, and its assertion time snapshot, are shaded to indicate that row 1 is no longer asserted. The row number is enclosed within angle brackets as a way of showing that the row is locked. It is locked—from other updates and also, unless dirty reads are allowed, from viewing as well—because it is part of an all-or-nothing isolated unit of work that will not be complete until the third physical transaction is complete.
This row says that from January 2010 to 12/31/9999, policy P861 is as shown. But based on the information supplied by the temporal update transaction, we now know that it is not true that the data in row 1 describes the policy throughout the period [Jan 2010 – 12/31/9999]. We now know, starting in May 2010, that the data in row 1 is no longer an accurate description of the object as it exists starting in May 2010.
Updates in place, however, overwrite the data they update. So haven't we now lost the information that row 1 originally had an assertion end date of 12/31/9999? No, we have not lost that information. The reason is that no row can be physically added to an asserted version table with any assertion end date other than 12/31/9999; and if the assertion end date is ever changed, it can be changed only once. The AVF, which translates temporal into physical transactions, guarantees this.
Therefore, the assertion end date in row 1, as it exists in Figure 7.7, tells us two things. It tells us that from January 2010 (the assertion begin date), up to May 2010, this row had an assertion end date of 12/31/9999. It also tells us that, starting in May 2010, it will no longer be asserted. Any asserted version with a non-12/31/9999 assertion end date is one that was (or will be) moved into past assertion time on that assertion end date.
The Second Physical Transaction
We have now withdrawn row 1, “clearing the decks” for replacing part of it and superceding the rest of it. The temporal update will result, when the final physical transaction is applied, in a new current version of P861 with an effective begin date of May 2010.
But what about the effective time prior to then, the effective time period of [Jan 2010 – May 2010]? The temporal update says nothing about what the policy was like prior to May 2010. Yet by withdrawing row 1, i.e. by moving it into past assertion time, we have placed the database in a state (albeit an atomic transaction isolated state) in which nothing at all is asserted about P861 as it was prior to May 2010. And yet the purpose of the temporal update was certainly not to alter anything about P861 prior to May 2010. So we need to replace the withdrawn assertion with one which is identical to it except that, instead of an unknown effective end date, it has an end date of May 2010. The result is shown in Figure 7.8.
 |
| Figure 7.8 Basic Scenario, First Temporal Update: After the Second Physical Transaction. |
The superscript, in the assertion time snapshot of row 2, tells us that this row has the same business data as row 1. At this moment, row 2 is the only row which exists in current assertion time; it is the only row which we currently assert to be true. However, we are still in the midst of an atomic unit of work, one which isolates all affected rows until the unit of work is completed. So at this point, no one can see that row 1 is withdrawn, and no one can see that row 2 has been created. With row 2 we assert, starting in May 2010, that policy P861, with client, type and copay as indicated, was in effect during the period [Jan 2010 – May 2010].
The Third Physical Transaction
Having withdrawn an assertion, and asserted its replacement, we can now complete the temporal transaction by asserting its successor. As shown in Figure 7.9, this is done by inserting row 3. This now becomes the new current version of this current episode for P861, an episode which began in January 2010. With the physical insertion of row 3, this atomic unit of work is now complete and the rows it has updated and inserted become visible in the database. This is shown by removing the angle brackets from the row numbers.
 |
| Figure 7.9 Basic Scenario, First Temporal Update: After the Third Physical Transaction. |
Because the temporal transaction specified neither an effective end date nor an assertion begin date, the effective end date on row 3 defaults to 12/31/9999 and the assertion begin date to May 2010, the date of the physical insert.
A Second Temporal Update Transaction
Let's see how a second temporal update affects the asserted version Policy table. Figure 7.10 shows the state of the Policy table before that transaction begins.
 |
| Figure 7.10 Basic Scenario, Second Temporal Update: Before the First Physical Transaction. |
The First Physical Transaction
Figure 7.11 shows the state of the target table after the first of the three physical transactions has been applied. This physical transaction withdraws the current assertion. It does so by doing a physical update of row 3, overwriting its assertion end date with the date the new transaction will begin to be asserted. In this case, that is the same date as the date of the update itself, i.e. August 2010. In Figure 7.11, we can see that the database now shows that row 3 was asserted from May 2010 to August 2010, at which time it was withdrawn.
 |
| Figure 7.11 Basic Scenario, Second Temporal Update: After the First Physical Transaction. |
The Second Physical Transaction
The second physical transaction for this update replaces the version that was withdrawn by the first physical transaction. In Figure 7.12, row 4 is that replacement. Its effect is to shorten the effective time period of row 3 to precisely one clock tick before the effective time period of the superceding row will begin. (Recall that, because of the closed-open use of date pairs, this means that those two date values will be identical.)
 |
| Figure 7.12 Basic Scenario, Second Temporal Update: After the Second Physical Transaction. |
Notice that row 2 now appears in two assertion time snapshots. It appears in the May 2010 snapshot because that was when it was first asserted. It also appears in the August 2010 snapshot because, at that point in time, it is still currently asserted.
The Third Physical Transaction
We have withdrawn the version of P861 which was current as this second update transaction began. And we have now replaced it with a newly asserted version that covers all of the effective time of that original version that will not be covered by its superceding version. The final step is to insert the superceding version, which becomes the new current version, and which contains the changes specified in the temporal update. The result of doing this is shown in Figure 7.13. The transaction is complete, and all locks have been released.
 |
| Figure 7.13 Basic Scenario, Second Temporal Update: After the Third Physical Transaction. |
A Temporal Delete Transaction
Figure 7.13 shows us an asserted version table after a temporal insert and two temporal updates. This time, we will process a temporal delete. As Figure 7.14 shows, a temporal delete is translated into a set of physical update transactions which withdraw the affected versions, followed by either one or two physical insert transactions which delimit the scope of the delete and, if necessary, any number of withdrawals and replacements to adjust episode begin dates that may have been affected.
 |
| Figure 7.14 Basic Scenario, Delete Transaction: Temporal to Physical Mapping. |
Note that, like all temporal transactions, a temporal delete transaction refers to an object. It says that the policy is to be deleted which, for a temporally managed object, is to remove its representation from a period of time. Physical transactions are the transactions which are submitted to the DBMS, and which insert or update rows in asserted version tables. They are created by the AVF which translates temporal transactions into physical transactions.
The targets of these transactions, however, are not objects; nor are they versions or assertions. The targets of these transactions are episodes of objects. Just as transactions against non-temporal tables insert, update or delete individual rows representing objects, transactions against asserted version tables insert into a period of time, update within a period of time, or remove from a period of time, all or parts of individual episodes representing those objects.
Figure 7.15 shows the state of the target table before the delete transaction begins.
 |
| Figure 7.15 Basic Scenario, Temporal Delete: Before the First Physical Transaction. |
Rows 1 and 2 contain the same business data, the same information about the version of policy P861 which began in January 2010. The difference is that row 1 asserted that P861 would be a type HMO policy, with a $15 copay, from that date until further notice. But in May 2010, we learned that the copay changed to $20, effective on that date. Therefore, at that point in time, the assertion made by row 1 ceased being true. It ceased being the case that P861 would continue to be an HMO policy with a $15 copay until further notice. In May 2010, “further notice” was given, and so the original assertion had to be withdrawn. In its place, we put an assertion identical to it except that it states that the business data it contains ceases to be effective on May 2010. We then follow that with another assertion which records the actual change in business data that does become effective on May 2010.
The First Physical Transaction
It is now December 2010. Figure 7.15 shows the state of the target table before the first of the two physical transactions for this temporal delete transaction has been applied. Because the temporal transaction does not include any bi-temporal parameters, default values are used. The result is that the transaction tells us to delete P861 as of December 2010. Using the default values, the transaction specifies an assertion and effective time range, in both cases, of [Dec 2010 – 12/31/9999]. It is row 5 which the transaction's two time periods overlap, and so it is row 5 which will be affected by the delete.
Figure 7.16 shows the results of applying the first physical transaction.
 |
| Figure 7.16 Basic Scenario, Temporal Delete: After the First Physical Transaction. |
As indicated in Figure 7.16, the first of these physical transactions withdraws the currently asserted, currently effective row, row 5. Because a specific assertion end date is not specified, the default of Now() is used, and the assertion end date for row 5 is therefore changed from 12/31/9999 to December 2010. This “clears the decks” because the latest thing we are still currently asserting about P861 is a version covering May 2010 to August 2010, which is row 4.
The Second Physical Transaction
The result of applying the second physical transaction implementing the temporal delete is shown in Figure 7.17.
 |
| Figure 7.17 Basic Scenario, Temporal Delete: After the Second Physical Transaction. |
Row 5 was the current version before the temporal transaction began. The first physical transaction withdraws it, and this second physical transaction replaces it. It replaces it with a version identical to the withdrawn version, except for having an effective end date of December 2010, which is the default value from the temporal transaction. With this effective end date, we now currently assert a closed episode, and remove all traces of P861, in current assertion time, from the time period of [Dec 2010 – 12/31/9999].
This is what the result of a delete against an asserted version table looks like. It removes the representation of an object from an indicated period of effective time. In this case, doing so results in closing an open episode as of the specific effective end date.
We now have enough detail in our Policy table to illustrate how to read the history of an object from its assertion time snapshots. From the four snapshots in Figure 7.17 and without consulting the table itself, we can follow the assertion time history of this policy.
(i) In January 2010, we begin to assert an episode of policy P861, effective on that same date. 3 At this point in time, the episode consists of a single version with an effective time period beginning in January 2010 and extending to 12/31/9999. Because the effective end date is 12/31/9999, this is an open episode, one which will remain in effect “until further notice”. Row 1, at this time, is not shaded because it has not yet been withdrawn.
3Notice that we read the assertion begin date from the left of the snapshot, but read the effective begin date from the vertical alignment of each rectangle with the calendar timeline underneath the snapshots. These are two distinct dates which, because our transactions are using default values, happen in this case to be the same.
(ii) In May 2010, we update P861, effective on that same date. This episode now has two versions, and remains an open episode. Row 1 is now shaded because it is withdrawn as part of this update transaction. Row 3 will not be withdrawn, of course, until August 2010. So from now until August 2010, what we assert about this episode is rows 2 and 3.
(iii) On August 2010, we update P861 again, effective on that same date. The episode now has three versions, and remains an open episode. Row 3 is withdrawn at this time. From now until December 2010, what we assert about this episode is rows 2, 4 and 5.
(iv) In December 2010, we terminate this episode, effective on that same date. The episode still has three versions, but is now a closed episode. From this point in time, until further notice, what we assert about this episode of P861 is rows 2, 4 and 6.
While updates and deletes are very different actions as applied to a non-temporal table, temporal updates and temporal deletes actually result in very similar actions applied to an asserted version table. As we have seen, the first two physical transactions for a temporal update withdraw the current assertion, and replace it with a new currently asserted version which occupies all the effective time of the withdrawn assertion other than the effective time the superceding version will occupy. In most cases, including this basic scenario, that means that the replacement version will have the same effective begin date as the withdrawn version, and will have the current date as its effective end date. The superceding version picks it up from there. A temporal delete is simply a temporal update for which there is no superceding version, but instead only, if necessary, one or two (but never more than two) replacement versions.
We conclude by pointing out a subtlety of the graphic notation used here. In Figure 7.17, note that the “above the calendar timeline” graphics for row 1, 3 and 5 extend through December 2010, while the graphic for row 6 extends up to December 2010. The graphics for those three rows extend through December 2010 because, with this temporal transaction complete, the results are guaranteed to remain in the table, unaltered in any way, until the next clock tick. And as we said before, throughout this book we are using a clock that ticks once a month. The graphic for row 6 only extends up to December 2010 because the delete transaction sets the effective end date for that version (and thus for the entire episode) to December 2010.
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.
12/31/9999
until further notice
temporal parameter
adjacent
include
asserted version table
Asserted Versioning Framework (AVF)
Asserted Versioning
assertion begin date
assertion end date
assertion time period
Now()
temporal default values
bi-temporal table
business data
clock tick
closed-open
conventional table
conventional transaction
deferred assertion
effective begin date
effective end date
effective time period
episode
closed episode
open episode
current episode
episode begin date
lock
managed object
object
object identifier
non-temporal table
uni-temporal assertion table
uni-temporal version table
occupied
replace
represented
successor
supercede
withdraw
physical transaction
temporal transaction
temporal insert transaction
temporal update transaction
temporal delete transaction
row creation date
statement
target table
temporal entity integrity (TEI)
temporal foreign key (TFK)
temporal referential integrity (TRI)
the standard temporal model
time period
transaction time period
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.