Databases Reference
In-Depth Information
But as soon as we identified the nine logical categories of bi-
temporal data, we realized that deferred transactions and
deferred assertions dealt with only three of those nine
categories—with future assertions about past, present or future
versions. What, then, we wondered, did the three categories of
past assertions correspond to?
The answer is that past assertions play the role of a DBMS
semantic logfile, one specific to a particular production table.
Of course, by now we understand that past assertions do not
make it possible to fully recreate the physical state of a table as
of any point in past time because of deferred assertions which
are not, by definition, past assertions. Instead, they make it pos-
sible to recreate what we claimed, at some past point in time,
was the truth about the past, present and future of the things
we were interested in at the time. In this way, past assertions
support a semantic logfile, and allow us to recreate what we once
claimed was true, as of any point of time in the past. They pro-
vide the as-was semantics for bi-temporal data.
But Asserted Versioning also supports a table-specific physi-
cal logfile. It does so with the row create date. With this date,
we can almost recreate everything that was physically in a table
as of any past point in time, no matter where in assertion time or
effective time any of those rows are located.
2
This leaves us with only three of the nine categories—the cur-
rent assertion of past, present and future versions of objects. The
current assertions of current versions, of course, are the conven-
tional data in an asserted version table. This leaves currently
asserted past versions and currently asserted future versions.
But these are nothing new to IT professionals. They are what
IT best practice version tables have been trying to manage for
several decades.
Now it all comes together. Instead of conventional physical
logfiles, Asserted Versioning supports queries which make both
semantic logfile data and physical logfile data available. Instead
of batch transaction datasets, Asserted Versioning keeps track
of what the database will look like when those transactions are
applied—which, for asserted version tables, means when those
future assertions pass into currency. Instead of variations on best
practice version tables which support some part of the seman-
tics of versioning, Asserted Versioning is an enterprise solution
which implements versioning,
in every case, with the same
2
The exception is deferred assertions that have been moved backwards in assertion
time. Currently, Asserted Versioning does not preserve information about the far future
assertion time these assertions originally existed in.
