Databases Reference
In-Depth Information
of those nine categories, and that find all of that data in the
same tables that, in today's databases, contain only current
data, is precisely what we mean by seamless access to bi-
temporal data.
So Asserted Versioning simplifies the life of the query author
in two ways. For those writing ad hoc queries, a wide range of
views can be provided that express criteria that would otherwise
have to be written into each ad hoc query. One such view is a
view which makes an asserted version table look like a conven-
tional non-temporal table. Another one is a view which makes
an asserted version table look like a uni-temporal versioned
table.
For those writing production queries, Asserted Versioning
guarantees that the bi-temporal data those queries access will
be semantically valid. There will be no temporal gaps in the rep-
resentation of an object between each temporal insert transac-
tion for that object, and the temporal delete transaction for all
but the current episode of that object. There will be no periods
of time at which two or more rows will both claim to describe
the object as it was/is/will be during a period of time in its life
history. There will be no cases in which any representation of
an existence-dependent child object will exist in effective time
unless a representation of its parent object also exists in that
effective time.
Surrogate Keys and Bi-Temporal Match
Logic
In Chapter 7, we will see each of the three temporal trans-
actions used in what we called the basic scenario. In those
examples, the object identifier we will use will be P861,
representing an insurance policy. This object identifier will be
used on all three temporal transactions. But if the string “P861”
is in fact a surrogate key value, then on the temporal insert trans-
action specifically, where did that value come from?
Surrogate Keys, Business Keys and Conventional
Tables
If we abstract from implementation details, surrogate keys
always work the same way. An insert transaction will not have
a surrogate key on it, because the presumption is that there is
no surrogate key already assigned to the object it represents.
So the search for a match between the transaction and the
