Databases Reference
In-Depth Information
academic work on bi-temporality. At that time, these version
tables which also contained a row create date were state of the
art in best practice methods for managing temporal data. We will
discuss them in the next chapter.
With a row creation date, of course, any query can be
restricted to the rows present inatableasofanyspecificdate
by including a WHERE clause predicate that qualifies only
thoserowswhosecreatedateislessthanorequaltothespeci-
fied date. With two effective dates, tables like these are also able
to specify one of the two temporal dimensions that make up
full bi-temporality.
The standard temporal model uses the term “valid time”
where we use the term “effective time”. But the difference is
purely verbal. We have found no differences between how valid
time works in the standard model, and how effective time works
in Asserted Versioning. We use “effective time” because it is the
preferred term among business IT professionals, and also
because it readily adapts itself to other grammatical forms such
as “becoming effective” and “in effect”.
The standard model states that “(v)alid time
...
captur(es) the
history of a changing reality, and transaction time . . . . . captur(es)
the sequence of states of a changing table . . . . . A table supporting
both is termed a “bi-temporal table” [2000, Snodgrass, p. 20]. But
as we will see later, Asserted Versioning does not define bi-tempo-
rality in exactly the same way. The difference lies primarily in the
second of the two temporal dimensions, what computer scientists
call “transaction time” and what we call “assertion time”. While a
transaction begin date always indicates when a row is physically
inserted into a table, an assertion begin date indicates when we
are first willing to assert, or claim, that a row is a true statement
about the object it represents, during that row's effective (valid)
time period, and also that the quality of the row's data is good
enough to base business decisions on.
In the standard temporal model, the beginning of a transaction
time period is the date on which the row is created. Obviously,
once the row is created, that date cannot be changed. But in the
Asserted Versioning temporal model, an assertion time period
begins either on the date a row is created, or on a later date.
Because an assertion begin date is not necessarily the same
as the date on which its row is physically created, Asserted
Versioning needs, in addition to the pair of dates that define this
time period, an additional date which is the physical creation
date of each row. That date serves as an audit trail, and as a
means of reconstructing a table as it physically existed at any
past point in time.
