Databases Reference
In-Depth Information
ceases to be in effect, i.e. even when it has an effective end date
in the past, we will usually continue to assert that, during its
effective time period, it was a true description of what its object
was like at that time.
However, and this is a very important point, there are
exceptions. With both the Asserted Versioning and the standard
temporal models, assertions may end even though the rows
that made them remain in the table. We terminate assertions if
and when we learn that they are mistaken, that the statement
they make is not true. In addition, with Asserted Versioning,
but not with the standard temporal model, rows can also be
created whose assertion is postponed until some later point in
time.
With non-temporal tables, we assert a row to be true by the
act of inserting it into its table, and we cease to assert that it is
true by deleting it from its table. With non-temporal tables, the
assertion time period of a row coincides with the row's physical
presence in the table. In these cases, the assertion begin date
is the same as the row creation date. Also, in most cases, once
we assert a row to be true, we continue to do so “until further
notice”.
The Row Creation Date
The row creation date is the date the row is physically
inserted into its table. In most cases, the row creation date will
be identical with the assertion begin date. In the standard tem-
poral model, it always is, and consequently, in that model, the
two dates are not distinguished. However, in our Asserted
Versioning implementation of bi-temporal data management,
it is valid to create a row with an assertion begin date in the
future. Thus, for Asserted Versioning, it is necessary to have a
row creation date which is distinct from the assertion begin
date.
The Basic Asserted Versioning Diagram
Figure 6.2
is an example of the basic diagram we will use to
illustrate Asserted Versioning. The schema in this diagram was
explained in the previous section. Now it's time to explain how
to read the diagram itself.
Figure 6.2
shows us the state of an
asserted version table after a temporal insert transaction which
took place on January 2010, and a temporal update transaction
which took place on May 2010.
