In Part 1, we introduced the topic of temporal data management. We presented a brief history of how temporal data has been managed over the last quarter-century, and we also developed a taxonomy of temporal data management methods. Within the distinction between reconstructable and queryable data, we situated Asserted Versioning as, first of all, a method of managing and providing access to queryable data. Next, within the distinction between keeping track of changes over time as a series of events or as a series of states through which objects pass, we situated Asserted Versioning as a method of managing data which describes the states through which persistent objects pass as they change over time. At the third level of the taxonomy, we distinguished between the management of data along a single temporal dimension from the management of data along two temporal dimensions, and situated Asserted Versioning as a method in the latter category. Finally, within the category of the management of queryable bi-temporal data about persistent objects, we distinguished Asserted Versioning from the standard temporal model on the basis of its management of future assertion time and its encapsulation of the mechanisms which enforce temporal semantics.

In Part 2, we introduced the core concepts of Asserted Versioning, reviewed the schema common to all asserted version tables, and developed a scenario which illustrates the use of basic temporal insert, update and delete transactions. The most basic concept of Asserted Versioning is that of a persistent object. Although hardly a novel concept, we believe that the organization of methods of temporal data management on the basis of that concept is novel.

Like the standard temporal model, Asserted Versioning distinguishes two temporal dimensions in which persistent object data is located. The ontological dimension is called effective time in Asserted Versioning, and valid time in both the standard model and in the computer science community. The epistemological dimension is called assertion time in Asserted Versioning, and transaction time in the standard model and by computer scientists; and it is here that their accounts and ours differ.

Asserted Versioning manages data located in future assertion time, while the standard model ignores the notion of future transaction time. Asserted Versioning also emphasizes that effective time exists within assertion time, while the standard model seems to treat its two temporal dimensions as orthogonal.

With the completion of Parts 1 and 2, all the preliminary work is behind us. Part 3 is an in-depth presentation of Asserted Versioning itself. It begins with Chapter 8, in which we discuss how temporal design requirements are expressed in metadata associated with a conventional logical data model, how this metadata is used to convert non-temporal table schemas into bi-temporal table schemas, and also how it is used to generate the code, such as stored procedures, that enforce both temporal entity integrity and temporal referential integrity on those tables. If ERwin is used as the data modeling tool, then a set of ERwin macros which we have written will do the conversion automatically. Otherwise, the conversion will be a manual process.

In Chapter 9, we discuss the temporal transactions with which asserted version tables are maintained. From the external point of view, that being the point of view of the person writing those transactions, the three temporal parameters that may be specified on these transactions are optional. The most common case is that these transactions are intended to result in production data that is immediately asserted, that becomes effective the moment the transactions are complete, and that remains in effect until a later transaction for the same object is applied. When these are the intentions accompanying transactions against asserted version tables, those transactions will be identical in content to conventional SQL transactions against non-temporal tables, and we will call them basic temporal transactions.

But maintenance to asserted version tables doesn't just insert, update or delete single rows. It brings about transformations of those tables from one state to a new state, transformations which may affect any number of physical rows in any number of physical tables. In order to be sure that all valid transformations can be specified with temporal transactions, we once again need a taxonomy. So in Chapter 9, we also develop a taxonomy of what we will call temporal extent state transformations to asserted version tables.

In Chapter 10, we focus our discussion on the maintenance of individual asserted version tables. This allows us to exclude considerations of temporal referential integrity (TRI) from the discussion. Then in Chapter 11, we examine scenarios that do modify multiple asserted version tables, and that do involve temporal referential integrity and its enforcement.

In Chapter 12, we discuss the topic of pipeline datasets, in general, and of one kind of pipeline dataset—deferred assertions—in particular. We begin by noting that deferred assertions represent past, present and future versions in future assertion time, but that past, present and future versions also exist in past and present assertion time. This gives us nine categories of temporal data, one of which is currently asserted current versions of things. That category is what we know as conventional data, physically located in what we call production tables. The other eight categories correspond to what we call pipeline datasets, being data that has those production tables as either their destinations or their origins.

Deferred assertions are the result of applying deferred transactions to the database. Instead of holding on to maintenance transactions until it is the right time to apply them, Asserted Versioning applies them right away, but does not immediately assert them. These deferred assertions may themselves be updated or deleted, and the moment on which their assertion periods become current is the moment on which we begin to claim that the world was, is or will be as they describe it.

Just as deferred assertions replace collections of transactions that have not yet been applied to the database, bi-temporal data in any of the other seven categories replaces other physically external datasets. Asserted version tables contain data in all these temporal categories and, in doing so, internalize what would otherwise be physically distinct datasets, ones whose management costs are obviously significant.

In Chapter 13, we look more closely at the entire family of pipeline datasets. We distinguish eight logical categories of pipeline datasets, based on where in a combination of past, present or future assertion and effective time their data is located. Having previously shown how to eliminate these physically distinct datasets by bringing them into the production tables which are their destinations and points of origin, we now discuss each of them and show how queries and views can reassemble, as queryable objects, exactly the data that had existed in those datasets. This demonstrates that while eliminating the management costs associated with this data, we can still make this data available in whatever combinations it is needed.

In Chapter 14, we discuss how to query asserted version tables. As we said before, many queries, especially the ad hoc queries written by non-technical database users, will be directed against non-temporal or uni-temporal views of asserted version tables, not against those bi-temporal tables themselves. But many queries will be written directly against those physical tables, especially those we call production queries. In that case, the effective time period specified on the query, and which qualifies the result set, will have to be compared to the effective time periods of the rows targeted by the query; and as we know from our review of the Allen relationships, there are 13 different ways in which those two time periods may be positioned with respect to one another. And when those queries involve joins across two (or more) asserted version tables, then the Allen relationship issues can become even more difficult.

In Chapter 15, we discuss how to optimize the performance of Asserted Versioning databases. Our focus is on optimizing access to currently asserted current versions, i.e. to the rows that correspond to rows in a conventional table of persistent objects. In this chapter, we focus on index design, although a wide range of other optimization techniques are also considered.

In Chapter 16, we conclude our presentation of Asserted Versioning. We discuss each of the four objectives we had for Asserted Versioning, and which we described in the Preface, and explain why we think those objectives have been met. We point out that Asserted Versioning has value both as a bridge to a future standards-based and vendor-provided implementation of bi-temporal data, and as a destination, being itself a semantically complete implementation of bi-temporal data which works with today's SQL and today's databases. In the last section, we discuss ongoing research and development at Asserted Versioning LLC, and explain how interested readers can learn more about Asserted Versioning.