Databases Reference
In-Depth Information
would need to know the assertion time period of the row, not
just when that time period ended.
As for the third objection, a row create date would be redun-
dant with an assertion end date if Asserted Versioning did not
support deferred assertions. In fact, neither the standard tempo-
ral model, nor any more recent computer science research that
we are aware of, includes deferred assertions. But Asserted
Versioning does. Because it does, the AVF may insert rows into
asserted version tables whose assertion begin dates are later
than their row creation dates.
A Real Redundancy in the Asserted Versioning
Schema
But there is one redundancy that we did introduce into the
Asserted Versioning schema. It was to add the episode begin date
to every row. The episode begin date, as we all know by now, is
the effective begin date of the effective-time earliest version of
an episode. So it is not functionally dependent on the primary
key of any row which is not the initial version of an episode.
2
The primary use of this column is to indicate, for any version,
when the episode that version is a part of began. It efficiently
associates every version with the one episode it belongs to.
Lacking this column, we would only be able to find all versions
of an episode by looking for versions with the same
oid
that
[meet], and we would only be able to distinguish one episode
from the next one by looking for a [before] or [before
1
] relation-
ship between adjacent versions with the same
oid
.
Together with that version's own effective end date, this tells
us that the object that version designates has been continuously
represented, in current assertion time, from the effective-time
beginning of that version's episode to the effective-time end of
that version. Since the parent managed object in a temporal ref-
erential integrity relationship is an episode, this means that
when we are validating temporal referential integrity on a child
version, all we need to do is find one parent version whose effec-
tive end date is not earlier than the effective end date of the new
2
Interestingly enough, although clearly redundant, this replication of the effective
begin date of each episode's initial version onto all other versions of the episode is not
a violation of any relational normal form. Its presence involves no partial, transitive or
multi-valued dependencies. For other examples of redundancies that are not caught
by fully normalizing a database, see Johnston's articles in the archives at
Information_Management.com (formerly DM Review), with links listed in the
bibliography.
