Databases Reference
In-Depth Information
result is that asserted version bi-temporal tables have two pairs
of dates, representing two different time periods. They are the
effective time period and the assertion time period of the rows
in those tables.
To assert a version is to claim that it is true. With any tables
other than bi-temporal tables, if something happens that makes
a row no longer true, that row is either updated or deleted. But
with asserted version tables, that isn't how we handle a row that
we discover is not true. We handle it by assigning it an assertion
end date (or a transaction end date, in the case of the standard
temporal model) representing the date on which we acknowl-
edge that it is not true. Then we add another row to the table.
This new row is a new assertion about the same version, a new
assertion about what the object is like during the same period
of time. The multiple rows representing the same version are
multiple assertions of that version.
In a series of assertions about the same object during the
same effective time period, the later one (in assertion time) of
every consecutive pair is a correction to the earlier one, and
the latest one of all is our current assertion about what is true.
We may also note here that corrections and the versions they
correct do not necessarily line up one to one. An error may span
only part of a version, or may span multiple versions, or may
span both. The ability to include in a table both corrections to
versions, as well as the original versions themselves, is precisely
what is lost when we remain with uni-temporal versions. This
ability is precisely what we gain when we manage data bi-
temporally.
For example, suppose that a row in a table states that pol-
icy P861 had a copay amount of $25 during the first six
months of 2010. But on July 1
st
of that year, we realized that
the copay amount was actually $20forthatpolicyoverthat
time period. If we were to overwrite that copay amount, we
would lose the information that prior to July 1
st
, all reports
and queries would have shown a copay of $25. To avoid losing
that information, we instead end the assertion time period for
the row showing a $25 copay, and insert another row. This new
row is also for policy P861, during the same six months of
2010, but it shows the correct copay of $20. Its assertion begin
date is the same as the assertion end date of the row showing
the $25 copay—July 1
st
.WenolongerassertthatP861hada
$25 copay during that period of time. Instead, we now assert
that it had a $20 copay during that period of time. We have
corrected a mistake without losing track of what the mistake
