Part 1 provided the context for Asserted Versioning, a history and a taxonomy of various ways in which temporal data has been managed over the last several decades. Here in Part 2, we introduce Asserted Versioning itself and prepare the way for the detailed discussion in Part 3 of how Asserted Versioning actually works.

In Chapter 3, we discuss the origins of Asserted Versioning in computer science research. Based on the work of computer scientists, we introduce the concepts of a clock tick and an atomic clock tick, the latter of which, in their terminology, is called a chronon. We go on to discuss the various ways in which time periods are represented by pairs of dates or of timestamps, since SQL does not directly support the concept of a time period.

There are only a finite number of ways that two time periods can be situated, with respect to one another, along a common timeline. For example, one time period may entirely precede or entirely follow another, they may partially overlap or be identical, they may start at different times but end at the same time, and so on. These different relationships among pairs of time periods have been identified and catalogued, and are called the Allen relationships. They will play an important role in our discussions of Asserted Versioning because there are various ways in which we will want to compare time periods. With the Allen relationships as a completeness check, we can make sure that we have considered all the possibilities.

Another important section of this chapter discusses the difference between the computer science notion of transaction time, and our own notion of assertion time. This difference is based on our development of the concepts of deferred transactions and deferred assertions, and for their subsumption under the more general concept of a pipeline dataset.

In Chapter 4, we discuss the origins of Asserted Versioning in IT best practices, specifically those related to versioning. We believe that these practices are variations on four basic methods of versioning data. In this chapter, we present each of these methods by means of examples which include sample tables and a running commentary on how inserts, updates and deletes affect the data in those tables.

In Chapter 5, we present the conceptual foundations of Asserted Versioning. The core concepts of objects, episodes, versions and assertions are defined, a discussion which leads us to the fundamental statement of Asserted Versioning, that every row in an asserted version table is the assertion of a version of an episode of an object. We continue on to discuss how time periods are represented in asserted version tables, how temporal entity integrity and temporal referential integrity enforce the core semantics of Asserted Versioning, and finally how Asserted Versioning internalizes the complexities of temporal data management.

In Chapter 6, we introduce the schema common to all asserted version tables, as well as various diagrams and notations that will be used in the rest of the book. We also introduce the topic of how Asserted Versioning supports the dynamic views that hide the complexities of that schema from query authors who would otherwise likely be confused by that complexity.

When an object is represented by a row in a non-temporal table, the sequence of events begins with the insertion of that row, continues with zero or more updates, and either continues on with no further activity, or ends when the row is eventually deleted. When an object is represented in an asserted version table, the result includes one row corresponding to the insert in the non-temporal table, additional rows corresponding to the updates to the original row in the non-temporal table, and an additional row if a delete eventually takes place. This sequence of events constitutes what we call the basic scenario of activity against both conventional and asserted version tables. In Chapter 7, we describe how the basic scenario works when the target of that activity is an asserted version table.