approach is better at tracking changes to persistent objects and
to relationships other than metric balances.
State Temporal Data: Uni-Temporal
and Bi-Temporal Data
At this point in our discussion, we are concerned with state
data rather than with event data, and with state data that is
queryable rather than state data that needs to be reconstructed.
What then are the various options for managing temporal
queryable state data?
First of all, we need to recognize that there are two kinds of
states to manage. One is the state of the things we are interested
in, the states those things pass through as they change over time.
But there is another kind of state, that being the state of the data
itself. Data, such as rows in tables, can be in one of two states:
correct or incorrect. (As we will see in Chapter 12, it can also
be in a third state, one in which it is neither correct nor incor-
rect.) Version tables and assertion tables record, respectively,
the state of objects and the state of our data about those objects.
Uni-Temporal State Data
In a conventional Customer table, each row represents the cur-
rent state of a customer. Each time the state of a customer
changes, i.e. each time a row is updated, the old data is overwritten
with the new data. By adding one (or sometimes two) date(s) or
timestamp(s) to the primary key of the table, it becomes a uni-
temporal table. But since we already know that there are two dif-
ferent temporal dimensions that can be associated with data, we
know to ask “What kind of uni-temporal table?”
As we saw in the Preface, there are uni-temporal version
tables and uni-temporal assertion tables. Version tables keep
track of changes that happen in the real world, changes to the
objects represented in those tables. Each change is recorded as

ral model was developed
by Chris Date, Hugh Darwen and Dr. Nikos Lorentzos in their
book Temporal Data and the Relational Model (Morgan-
Kaufmann, 2002).
6
This model is based in large part on tec-
hniques developed by Dr. Lorentzos to manage temporal data
by breaking temporal durations down into temporally atomic
components, applying various transformations to those compo-
nents, and then re-assembling the components back into those
temporal durations—a technique, as the authors note, whose
applicability is not restricted to temporal data.
As we said, except for the penultimate chapter in that book,
the
entire book is a discussi
on of uni-temporal versioned tables.
In that chapter, the authors recommend that if there is a require-
ment to keep track of the assertion time history of a table (which
they call “logged-time history”), it be implemented by means of
an auxiliary table which is maintained by the DBMS.
4
Lacking criteria to distinguish the best from the rest, the term “best practices” has
come to mean little more than “standard practices”. What we call “best practices”, and
which we discuss in Chapter 4, are standard practices we have seen used by many of
our clients.
5
An even worse solution is to mix up versions and assertions by creating a new row,
with a begin date of Now(), both every time there is a real change, and also every time
there is an error in the data to correct. When that happens, we no longer have a history
of the changes things went through, because we cannot distinguish versions from

kept in one and the same Customer table. Corrections may or
may not be flagged; but if they are not, it will be impossible to
distinguish versions created because something about a cus-
tomer changed from versions created because past customer
data was entered incorrectly. On the other hand, if they are
flagged, the management and use of these flags will quickly
become difficult and confusing.
There are many variations on the theme of versioning, which
we have grouped into four major categories. We will discuss
them in Chapter 4.
The IT community has always used the term “version” for this
kind of uni-temporal data. And this terminology seems to reflect
an awareness of an important concept that, as we shall see, is cen-
tral to the Asserted Versioning approach to temporal data. For the
term “version” naturally raises the question “A version of what?”, to
which our answer is “A version of anything that can persist and
change over time”. This is the concept of a persistent object, and
it is, most fundamentally, what Asserted Versioning is about.
Bi-Temporal State Data
We now come to our second option, which is to manage
both versions and assertions and, most importantly, their
interdependencies. This is bi-temporal data management, the
subject of both Dr. Rick Snodgrass’s book [2000, Snodgrass] and
of our book.
Chapter 2 A TAXONOMY OF BI-TEMPORAL DATA MANAGEMENT METHODS
43
The Standard Temporal Model
What we call the standard temporal model was developed
by Dr. Rick Snodgrass in his book Developing Time-Oriented
Database Applications in SQL (Morgan-Kaufmann, 2000).

nology and current SQL.
The Asserted Versioning model of uni-temporal and bi-tem-
poral data management supports all of the functionality of the
standard model. In addition, it extends the standard model’s
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. This is done
by means of deferred transactions, which result in deferred
assertions, those being the inserted, updated or logically deleted
44
Chapter 2 A TAXONOMY OF BI-TEMPORAL DATA MANAGEMENT METHODS
rows resulting from those transactions.
7
Deferred assertions,
although physically co-located in the same tables as other data,
will not be immediately available to normal queries. But once
time in the real world reaches the beginning of their assertion
periods, they will, by that very fact, become currently asserted
data, part of the production data that makes up the database
as it is perceived by its users.
We emphasize that deferred assertions are not the same thing
as
rows describing what
things will be like at some time in the
future. Those latter rows are current claims about what things
will be like in the future. They are ontologically post-dated.
Deferred assertions are rows describing what things were, are,
or will be like, but rows which we are not yet willing to claim
make true statements. They are epistemologically post-dated.
Another way that Asserted Versioning differs from the stan-

Chapter 2 A TAXONOMY OF BI-TEMPORAL DATA MANAGEMENT METHODS
45
episode in an assertion version table can sometime later be
followed by the insertion of a new episode for the same object.
In a non-temporal table, each row must conform to entity
integrity and referential integrity constraints. In an asserted ver-
sion table, each version must conform to temporal entity integ-
rity and temporal referential integrity constraints. As we will
see, the parallels are in more than name only. Temporal entity
integrity really is entity integrity applied to temporal data. Tem-
poral referential integrity really is referential integrity applied to
temporal data.
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 sev-
eral 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.
as-is
as-was
Asserted Versioning
Asserted Versioning Framework (AVF)
episode
persistent object
state
thing
physical transaction

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
Managing Time in Relational Databases. Doi: 10.1016/B978-0-12-375041-9.00024-8
Copyright
#
2010 Elsevier Inc. All rights of reproduction in any form reserved.
47
timeline. For example, one time period may entirely precede or
entirely follow another, they may partially overlap or be identi-
cal, they may start at different times but end at the same time,
and so on. These different relationships among pairs of time per-
iods 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 dif-
ference 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 trans-
actions 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