Databases Reference
In-Depth Information
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-
dard temporal model is in the encapsulation and simplification
of integrity constraints. The
encapsulation
of integrity con-
straints is made possible by distinguishing temporal transactions
from physical transactions. Temporal transactions are the ones
that users write. The corresponding physical transactions are
what the DBMS applies to asserted version tables. The Asserted
Versioning Framework (AVF) uses an API to accept temporal
transactions. Once it validates them, the AVF translates each
temporal transaction into one or more physical transactions.
By means of triggers generated from a combination of a logical
data model together with supplementary metadata, the AVF
enforces temporal semantic constraints as it submits physical
transactions to the DBMS.
The
simplification
of these integrity constraints is made possi-
ble by introducing the concept of an
episode
. With non-temporal
tables, a row representing an object can be inserted into that table
at some point in time, and later deleted from the table. After it is
deleted, of course, that table no longer contains the information
that the row was ever present. Corresponding to the period of
time during which that row existed in that non-temporal table,
there would be an episode in an asserted version table, consisting
of one or more temporally contiguous rows for the same object.
So an episode of an object in an asserted version table is in effect
during exactly the period of time that a row for that object would
exist in a non-temporal table. And just as a deletion in a conven-
tional table can sometime later be followed by the insertion of a
new row with the same primary key, the termination of an
7
The term “deferred transaction” was suggested by Dr. Snodgrass during a series of
email exchanges which the authors had with him in the summer of 2008.
