All asserted version tables have the same non-business-data columns. Figure 6.1 shows an asserted version table of health insurance policies which has two business data columns: type and copay. All the other columns are part of the syntax common to all asserted version tables, part of the bi-temporal machinery of Asserted Versioning. We will learn how to read these diagrams in the next section. For now, let's examine each column, and the roles that various columns and pairs of columns play.

Row #. Row number. This column is not part of the table. Row numbers are tags we place on asserted version rows in these diagrams. We will sometimes use these tags in our discussions to indicate which rows we are talking about. Note that if this column were included as part of the table, it could be used as a single-column surrogate primary key.

Oid. Object identifier. A surrogate-valued unique identifier of the persistent object for which the row is a bi-temporally located description, i.e. a description located in both a specific effective time period and also a specific assertion time period. If an asserted version table were a conventional table instead, the oid would be the full primary key of that table.

Eff-beg. Effective begin date. The date on which the business data in a row goes into effect, i.e. on which it first becomes a description of what that object is like, beginning on that date. As we have pointed out before, these columns which implement Asserted Versioning are all shown as date columns in this book, but they could as well be timestamps.

Also note that although this column heading is eff-beg, all SQL statements or predicates which reference this column will refer to it as eff_beg_dt. We use hyphens in these column headings because underscores do not stand out as well, particularly when a column heading is underlined, as it is for all primary key columns. When these columns names are used in the text, they will be italicized, although usually we will replace them with their full spelling equivalents. For example, when referring, in the text, to the column heading eff-beg, we will either use eff_beg_dt or the full name, as for example, in saying that the effective begin date is the temporal delimiter of the start of an effective time period.

Eff-end. Effective end date. The date on which the business data in a row is no longer in effect. In other words, the date which is one clock tick past the last date on which the business data in a row is in effect.

Asr-beg. Assertion begin date. The date on which the business data in a row is first asserted as being a true and/or actionable description of what that object is like, during its effective time period.

Asr-end. Assertion end date. The date on which the business data in a row is no longer asserted to be a true and/or actionable statement of what that object is like, during its effective time period. In other words, the date which is one clock tick past the last date on which that assertion is made.

Epis-beg. Episode begin date. The date on which the episode which contains the version begins. The begin date of an episode is always the same as the effective begin date of the first version in the episode.

Temporal Foreign Key: Client. The object identifier of the client who owns the policy, functioning as a temporal foreign key to an asserted version Client table.

Business data: Type. The type of the insurance policy. Types used in these examples are: HMO (Health Maintenance Organization); PPO (Preferred Provider Organization); and POS (point of service).

Business data: Copay. The copay amount that the policy holder is obligated to pay for each covered healthcare product or service.

Row-crt. Row creation date. The date on which the row is physically inserted into the table.

Figure 6.2 is an example of the basic diagram we will use to illustrate Asserted Versioning. The schema in this diagram was explained in the previous section. Now it's time to explain how to read the diagram itself. Figure 6.2 shows us the state of an asserted version table after a temporal insert transaction which took place on January 2010, and a temporal update transaction which took place on May 2010.

On January 2010, a temporal insert transaction was processed for policy P861. ¹ It said that policy P861 was to become effective on that date, and that, as is almost always the case when a temporal transaction is processed, was to be immediately asserted.

Then in May, a temporal update transaction for that policy was processed. The transaction changed the copay amount from $15 to $20, effective immediately. But this invalidated row 1 because row 1 asserted that a copay of $15 would continue to be in effect after May. So as part of carrying out the directives specified by that temporal transaction, we withdrew the assertion made by row 1, by overwriting the original assertion end date of 12/31/9999 on row 1 with the date May 2010.

When a row is withdrawn, it is given a non-12/31/9999 assertion end date. Withdrawn rows, in these diagrams, are graphically indicated by shading them. In addition, every row is represented by a numbered rectangular box on a horizontal row of all versions whose assertions begin on the same date. We will call these horizontal rows assertion time snapshots. These snapshots are located above the calendar timeline, and when their rectangular boxes represent withdrawn rows, those boxes are also shaded. So in Figure 6.2, the box for row 1 is shaded.

After row 1 was withdrawn, the update whose results are reflected in Figure 6.2 was then completed by inserting two rows which together represent our new knowledge about the policy, namely that it had a copay of $15 from January 2010 to May 2010, and had a copay of $20 thereafter.

The clock tick box is located to the left of the transaction, at the top of the diagram. It tells us that it is currently May 2010, in this example. This is graphically indicated by the solid vertical bar representing that month on the calendar timeline above the sample table. In this example, rows 2 and 3 have just been created. We can tell this because their row create date is May 2010.

The first row is no longer asserted. It has been withdrawn. It was first asserted on January 2010, but it stopped being asserted as part of the process of being replaced as a current assertion by row 2, and then superceded by row 3. This is indicated by the May 2010 value in row 1's assertion end date and the May 2010 value in the assertion begin dates of rows 2 and 3. It is graphically indicated by the two assertion time snapshots above and to the left of the timeline. Each snapshot shows the rows of the table that were currently asserted starting on that date. So from January 2010 to May 2010, row 1 is what we asserted about policy P861. From May 2010 forwards, rows 2 and 3 began to be asserted instead.

We say “instead” because rows 2 and 3 together replace and supercede row 1, in the following sense. First of all, they describe the same object that row 1 describes, that object being policy P861. Second, rows 2 and 3 together [equal] the effective time period of row 1, the period [Jan 2010 – 12/31/9999]. Row 2's effective time period is [Jan 2010 – May 2010]. Then, without skipping a clock tick, row 3's effective time period is [May 2010 – 12/31/9999]. Row 2 includes the part of row 1's effective time whose business data is not changed by the update; so we will say that row 2 replaces that part of row 1. Row 3 includes the part of row 1's effective time whose business data is changed by the update; so we will say that row 3 supercedes that part of row 1.

In our illustrations, 9999 represents the latest date that the DBMS can represent. In the case of SQL Server, for example, that date is 12/31/9999. This date does not represent a New Year's Eve some 8000 years hence. But it is a date as far as the DBMS is concerned. The importance of this “dual semantics” will become important later on when we explain how Asserted Versioning queries work.

Notice that all three rows in this example have assertion begin dates that are identical to their corresponding row creation dates. In the standard temporal model, a transaction time period is used instead of an assertion time period; and with transaction time periods, the begin date is always identical to the row creation date, and so a separate row creation date is not necessary.

But in the Asserted Versioning model, assertion begin dates and row creation dates are not semantically identical, and they do not necessarily have the same value in every row in which they appear. With Asserted Versioning, while no assertion begin date can be earlier than the corresponding row creation date, it can be later. If it is later, the transaction which creates the row is said to be a deferred transaction, not a current one. The row it creates in an asserted version table is said to be a deferred assertion, not a current one. Such rows are rows that we may eventually claim or assert are true, but that we are not yet willing to.

In this example, both before and after May 2010, the effective end date for policy P861 is not known. But sometimes effective end dates are known. Perhaps in another insurance company, all policies stop being in effect at the end of each calendar year. In that case, instead of an effective end date of 12/31/9999 in rows 1 and 3, the example would show a date of January 2011 (meaning, because of the closed-open convention, that the last date of effectivity for these policies is one clock tick prior to January 2011, that being December 2010).

We turn now to the graphics, the part of Figure 6.2 above the sample table. The purpose of these graphics is to abstract from the business details in the sample table and focus attention exclusively on the temporal features of the example.

Above a calendar which runs from January 2010 to February 2014, there are two horizontal rows of rectangular boxes. These rows are what we have already referred to as assertion time snapshots, with each rectangular box representing one version of the associated table. The lowest snapshot in a series of them contains a representation of the most recently asserted row or rows. These most recently asserted rows are almost always currently asserted and usually will continue to be asserted until further notice.

There are, however, two exceptions. Neither of them is part of the standard temporal model, but both of them support useful semantics. One exception is created by the presence of deferred assertions in the table which are, by definition, assertions whose begin dates, at the time the transaction is processed, lie in the future. The other exception is created when assertions are withdrawn without being replaced or superceded, i.e. when after a certain point in time we no longer wish to claim that those assertions ever were, are or will be a true description of what their object was, is or might be like during some stretch of effective time. But as we said earlier, we will not discuss deferred assertions until several chapters from now, at which time we will also discuss withdrawn assertions that are not replaced and/or superceded by other assertions.

Each of these assertion time snapshots consists of one or more boxes. As we said, each box contains the row number of the row it represents. The vertical line on the left-hand side of each box corresponds to the effective begin date of the row it represents. In this illustration, only one of the boxes is closed, in the sense of having a line on its right-hand side. The other two are open both graphically and, as we will see, semantically.

Let's consider these boxes, one at a time. The box for row 1 is open-ended. This always means that the corresponding row has an effective end date of 12/31/9999. The box directly below the box for row 1 represents row 2. Because that box is closed on its right-hand side, we know that the row it represents has a known effective end date which, in this case, is May 2010.

In these boxes that line up one under the other, the business data in the rows may or may not be identical. If the business data is identical, then the box underneath the other represents a replacement, and we will indicate that it has the same business data as the row it replaces by using the row number of the row it replaces as a superscript. But if the business data in two rows for the same object, during the same effective time period, is not identical, then the row represented by the lower box supercedes the row represented by the upper box, and in that case we will not include a superscript. This convention is illustrated in Figure 6.2, in which the box for row 2 has a superscript designating row 1, whereas the box for row 3 has no superscript.

The box directly to the right of the box for row 2 represents row 3. We can tell that the two rows are temporally adjacent along their effectivity timelines because the same vertical line which ends row 2's effective time period also begins row 3's effective time period. So this diagram shows us that there is an unbroken effective time period for policy P861, which began to be asserted on May 2010, and which extends from row 2's effective begin date of January 2010 to row 3's effective end date of 12/31/9999, this being exactly the same effective time period previously (in assertion time) represented by row 1 alone.

This description of Asserted Versioning's basic diagram has focused on a sample table whose contents reflect one temporal insert transaction, and one temporal update transaction.

Before proceeding, we need a more flexible way to supplement English in our discussions of Asserted Versioning. In the last section, we used what we called the “basic diagram” of an asserted version table. That diagram contains five main components. They are:

We will still need to use this basic diagram to illustrate many points. But for the most part, discussions in the next several chapters will focus on effective time. So we will often use a diagram in which rows in past assertion time are not shown in the sample table, and in which there are no assertion time snapshots either.

So, leaving assertion time snapshots out of the picture, we will often use the kind of diagram shown in Figure 6.3. And sometimes we will simply show a few rows from a sample table, as in Figure 6.4.

While illustrations are essential to understanding the complexities of bi-temporal data management, it will also be useful to have a notation that we can embed in-line with the text. In this notation, we will use capital letters to represent our sample tables. So far we have concentrated on the Policy table, and we will use “P” to represent it.

Almost always, what we will have to say involves rows and transactions that all contain data about the same object. For example, we will often be concerned with whether time periods for rows representing the same policy do or do not [meet]. But for the most part we will not be concerned with whether or not time periods for rows representing different policies [meet]. So the notation “P[X]” will indicate all rows in the Policy table that represent policy X.

In the next several chapters, we will be primarily concerned with the effective time periods of asserted version rows. So for example, the notation P[P861[Jun12-Mar14]] stands for the row (or possibly multiple rows) in the Policy table for the one or more versions of P861 that are in effect from June 2012 to March 2014. With this notation, we could point out that there is exactly one clock tick between P[P861[Jun12-Mar14]] and P[P861[Apr14-9999]]. If we needed to include assertion time as well, the notation would be, for example, P[P861[Jun12-Mar14][Jun12-9999]]. If we were concerned with assertion time but not with effective time, we would refer to the row(s) P[P861[][Jun12-9999]].

An example of the notation describing a complete asserted version row is:

We will use abbreviated forms of the notation wherever possible. For one thing, we will seldom refer to the row creation date, until Chapter 12, because until we discuss deferred assertions, the row creation date will always be the same as the assertion begin date. Also, the episode begin date is always identical to the effective begin date of the first version of an episode, so we will often leave it out of our in-line representation of an asserted version row unless it is relevant to the example at hand.

What is lost with this in-line notation is context. What is gained is focus. Diagrams also present us with a graphical representation of a timeline and a snapshot of effective time periods, grouped by common assertion times along that timeline. With the in-line notation, that context, too, is not represented.

We can already see that asserted version tables are more complex than non-temporal tables. For one thing, they have about half a dozen columns that are not present in non-temporal tables; and the semantics of these columns, the rules governing their correct use and interpretation, are sometimes subtle. For another thing, the fact that there are now multiple rows representing a single object adds another level of complexity to an asserted version table. Some of those rows represent what those objects used to be like, others what they are like right now, and yet others what they may, at some time in the future, be like. In addition, and quite distinctly, some of those rows represent what we used to say those objects were, are, or will be like; others what we currently say they were, are, or will be like; and yet others what we may, at some time in the future, say they were, are, or will be like.

All in all, the sum and interplay of these factors make asserted version tables quite complex. They can be complex to maintain in the sense that they can be easy to update in ways whose results do not reflect what the person writing the updates intended to do. And they can be difficult to interpret, as we just said.

Asserted Versioning attempts to eliminate this maintenance complexity, as far as possible, by making it seem to the user who writes temporal transactions which utilize default values for their temporal parameters that the insert she writes creates a single row, that the updates she writes update that single row, and that the delete she writes removes it. In this way, by providing a set of transactions that conform to the paradigm she is already familiar with, the possibility of misinterpretation, on the maintenance side of things, is minimized.

But what about the query side of things? What about looking at the data in an asserted version table? How can this data be presented so as to hide the mechanisms by which it is managed—those extras columns and extra rows we referred to a moment ago—leaving what looks like a non-temporal or a uni-temporal table?

It is particularly important to hide the complexity of asserted version tables from query authors who are not IT professionals, from query authors who may be business analysts, scientists or researchers. For these query authors, the solution is to query asserted version tables through views. And no matter how much history is contained in an asserted version table, and no matter how much conjecture about or anticipation of the future may be contained in an asserted version table, we are still going to be primarily interested in what we believe, right now, things are like right now. That is, our most frequent view of an asserted version table will be the view that makes it look like a non-temporal table containing current data.

Assuming (until Chapter 12) that temporal transactions never specify assertion dates, we can have three kinds of temporal transactions against asserted version tables, for example against our Policy table. With the first kind, no effective dates are specified. To authors of these transactions, they appear to be doing normal maintenance to a conventional Policy table, one that looks like the table shown in Figures 6.5 and 6.6. They have, or need have, no idea that the table they are actually maintaining is the table shown in Figures 6.3 and 6.4.

With the second kind of temporal transaction, effective begin and end dates may be specified, but neither of them can be a date which is already past at the time of the transaction. This is the way maintenance is done to version tables. Normally, current versions are created whenever they are needed to reflect a change in the object they represent. The version that was current at the time of the transaction is given an end date, and the transaction creates the new current version.

But Asserted Versioning, and the two most complete best practice forms of versioning, also permit transactions to create future versions. To authors of these transactions, they appear to be doing normal maintenance to a uni-temporal versioned Policy table, one that looks like the table shown in Figures 6.7 and 6.8. They have, or need have, no idea that the table they are actually maintaining is the table shown in Figures 6.3 and 6.4.

With the third kind of temporal transaction, effective begin and end dates may be specified, and either or both of them may be dates which are already past at the time of the transaction. This is the way maintenance is done to tables which support assertions of versions. But to authors whose mandate is to maintain either conventional or uni-temporal versioned tables, this kind of maintenance is impossible. A conventional table has no way of recognizing effective time. And it is semantically illegitimate to create past versions in uni-temporal version tables.

Here's why. If a past version were created in a version table, let's say one with an effective begin date of a week ago, it would be a lie. For all that week, the database would have said that the object represented by that version was not in effect during that week. Then, after the transaction, the database would say that the object was in effect during that same week. One or the other of those claims must be false. In fact, the latter one is.

But in a chapter whose purpose is to introduce notation that will be used in the rest of this book, much of what we have just said anticipates more detailed discussions that will occur later, particularly in Part 3.

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.