Tom Johnston

The Basic Scenario

When an object is represented by a row in a nontemporal 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 nontemporal table, additional rows corresponding to the updates to the original row in the nontemporal table, and an additional row if a delete eventually takes place. This sequence of events constitutes what is called the basic scenario of activity against both conventional and asserted version tables. This chapter describes how the basic scenario works when the target of that activity is an asserted version table. Basic temporal transactions are temporal transactions that do not specify any bitemporal parameters. Any one or more of three bitemporal 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. A temporal delete is translated into a set of physical update transactions that withdraw the affected versions, followed by either one or two physical insert transactions that 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.

The Core Concepts of Asserted Versioning

This chapter presents the conceptual foundations of Asserted Versioning. It defines the core concepts of objects, episodes, versions, and assertions. Every row in an asserted version table is the assertion of a version of an episode of an object. With temporal tables an object may be represented by any number of rows; for these tables, then, the entity integrity constraint must be modified. That modification results in temporal entity integrity. For temporal tables, the corresponding constraint is temporal entity integrity (TEI). In enforcing the rule that no two versions of the same object may conflict, TEI is analogous to conventional entity integrity. The only physical tables managed by Asserted Versioning are bitemporal tables. But on the basis of those bitemporal tables, Asserted Versioning also manages two unitemporal views, and one nontemporal view. Asserted Versioning defines one bitemporal schema, and manages only that one kind of physical table. Those tables support unitemporal versions and unitemporal assertions, but it supports them as views. By means of views, those tables also support conventional, nontemporal tables.

Temporal Transactions on Single Tables

This chapter presents a discussion on the maintenance of individual asserted version tables, with focus on temporal entity integrity (TEI). TEI checks insure that, at any given moment of assertion time or during any given period of assertion time, no object may be represented in an effective time clock tick more than once. TEI applies to both episodes and to versions within episodes. For episodes, it is the constraint that no two episodes of the same object, in the same period of assertion time, either are contiguous with one another or share even a single clock tick. Using the terminology from Allen relationship taxonomy, it is the constraint that no two episodes of the same object, in the same period of assertion time, either [meet] or [intersect]. They share no clock ticks, and they all have at least one unoccupied clock tick between them. One is always [before] the other. For versions within an episode, temporal entity integrity is the constraint that each effective-time adjacent pair of versions [meet] but do not [intersect]. They share no clock ticks, and have no unoccupied clock ticks between them. There are two ways of demonstrating completeness of temporal transactions, including Allen relationship check, and temporal extent transformation completeness check.

2 – A Taxonomy of Bi-Temporal Data Management Methods

This chapter presents a developing process of bitemporal data management methods taxonomy and in particular, of how Asserted Versioning supports nontemporal, unitemporal, and bitemporal data by means of physical bitemporal tables. In terms of granularity, temporal data can be managed at the level of databases, or tables within databases, or rows within tables, or even columns within rows. And at each of these levels, one could be managing nontemporal, unitemporal, or bitemporal data. Temporal data is data about, not just how things are right now, but also about how things used to be and how things will become or might become. The two nodes that partition temporal data management are reconstructable data and queryable data. Reconstructable data is the node under which all methods of managing temporal data that require manipulation of the data are classified before it can be queried. Queryable temporal data, in contrast, is data that can be directly queried, without the need to first transform that data in some way. In fact, the principal reason for the success of data warehousing is that it transformed reconstructable historical data into queryable historical data. The Asserted Versioning model of unitemporal and bitemporal data management supports all of the functionality of the standard model. In addition, it extends the standard models notion of transaction time by permitting data to be physically added to a table prior to the time when that data will appear in the table as production data, available for use. The taxonomy developed in this chapter is a partitioned semantic hierarchy, which is designed to lead through a range of possible ways of managing temporal data, and to end up with Asserted Versioning as a leaf node.

A Brief History of Temporal Data Management

This chapter presents a brief history of temporal data management, and discusses a brief account of changes in methods of managing data over the last quarter-century. Temporal data management is not a new development. From the earliest days of business data processing (as it was called back then), transactions were captured in a transaction log and the files and tables those transactions were applied to were periodically backed up. With those backups and logfiles, one could usually recreate what the data looked like at any point in time along either of the temporal dimensions we will be discussing. Indeed, together they contain all the “raw material” needed to support fully bitemporal data management. What has changed about temporal data management, over the decades, is accessibility to temporal data. In the 80s, as disk storage costs plummeted, the concept of backup data introduced temporal data management at the database level. On an architecturally smaller scale, IT developers were also beginning to design and implement several other ways of managing temporal data, such as the use of history tables, and the use of version tables. In addition, developers were also beginning to create on-line transaction tables. By the early 90s, significant computer science research on bitemporality had been completed. The second major development in the 90s was that the concept of a data warehouse was proselytized and extended by Bill Inmon. At about the same time, Ralph Kimball took a complementary approach, describing a method of recording history by means of a collection of transactions. In the first decade of 2000s, several major developments took place related to the management of temporal data: on-line analytical processing (OLAP) data cubes; slowly changing dimensions (SCDs); and real-time data warehousing.

Diagrams and Other Notations

This chapter introduces the schema common to all asserted version tables, as well as various diagrams, and notations. All of the concepts such as objects, episodes, versions, and assertions, and the two principal semantic constraints of temporal entity integrity and temporal referential integrity, are physically realized as rows in tables that are all based on the schema of asserted version tables. All asserted version tables have the same nonbusiness-data columns. All the other columns, such as row number, object identifier, effective begin date, effective end date, and effective end date are part of the syntax common to all asserted version tables, part of the bitemporal machinery of Asserted Versioning. For Asserted Versioning, it is necessary to have a row creation date which is distinct from the assertion begin date. The chapter presents diagrams that are used to illustrate Asserted Versioning. The “basic diagram” of an asserted version table contains five main components: current clock tick; a temporal insert, update or delete transaction; a calendar timeline covering approximately four years, in monthly increments; a stacked series of assertion time snapshots of the table; and the table itself, including all rows across all effective and assertion times. The chapter also explains how Asserted Versioning supports the dynamic views that hide the complexities of asserted version tables schema from query authors who would otherwise are likely be confused by the complexity.

Temporal Transactions on Multiple Tables

This chapter examines scenarios that modify multiple asserted version tables, and that involve temporal referential integrity (TRI) and its enforcement. TRI is referential integrity applied to the temporalized representations of objects by two types of managed objects—episodes and versions. A TRI relationship between a child managed object and a parent managed object is based on an existence dependency between the objects which those managed objects represent. In either an RI or a TRI relationship between a managed object representing a policy and one representing a client, a client may exist without a related policy, but a policy cannot exist without a related client. When TRI is concerned, “mays” and “cannots” are enforced on the managed objects that are versions and episodes, by the AVF, in accordance with rules declared to it as entries in metadata tables. A TRI child table is an asserted version table that contains a temporal foreign key (TFK). A TRI parent table is an asserted version table referenced by a TFK. The foreign key (FK) reference is a data value, and is unambiguous; but the TFK reference, as a data value, is not unambiguous. The chapter explains how TRI can be applied to temporal transactions including temporal insert, temporal updates, and temporal delete.

Deferred Assertions and Other Pipeline Datasets

This chapter discusses the topic of pipeline datasets, in general, and of one kind of pipeline dataset—deferred assertions—in particular. It begins 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 nine categories of temporal data, one of which is currently asserted current versions of things, which known as conventional data, physically located in production tables. The other eight categories correspond to 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 be updated or deleted by themselves. Just as deferred assertions replace collections of transactions that have not yet been applied to the database, bitemporal 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.

The Origins of Asserted Versioning: IT Best Practices

This chapter discusses the origins of Asserted Versioning in IT best practices, specifically those related to versioning. Versioning is the IT communitys way of providing queryable access to historical, current, and future data. It is believed that these practices are variations on four basic methods of versioning data. Those four types are: (i) Basic versioning; (ii) Logical delete versioning; (iii) Temporal gap versioning; and (iv) Effective time versioning. The simplest versioning method, called basic versioning, is to add a date to the primary key of the table to be versioned, thus transforming it from a nontemporal into a unitemporal table, i.e. into a table with one temporal dimension. In the logical delete versioning, a logical delete flag is included in the version table. It has two values, one marking the row as not being a delete, and the other marking the row as being a delete. Effective time versioning is the most advanced best practice for managing versioned data in the IT world. Effective time versioning actually supports a limited kind of bitemporality. The chapter discusses 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.

Allen Relationship and Other Queries

This chapter discusses how to query asserted version tables. Many queries, especially the ad hoc queries written by nontechnical database users, will be directed against nontemporal or unitemporal views of asserted version tables, not against those bitemporal tables themselves. But many queries will be written directly against those physical tables, especially 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. This chapter examines thirteen Allen relationships, and each nonleaf node in the taxonomy of Allen relationships. It describes the Allen relationships as they hold between two time periods, between a time period and a point in time, and also between two points in time. These relationships are expressed in terms of time periods represented with the closed-open convention, and provide a sample query for each one. Many of the Allen relationships are used by the Asserted Versioning to enforce temporal entity integrity (TEI) and temporal referential integrity (TRI).