Databases Reference
In-Depth Information
time, like rows in conventional tables, the time in the life history
of the objects they represent is the eternal Now().
In physical versioned tables, there is only one version for an
object during any one period of time. It describes what the
object was/is/will be like during that period of time. If we later
find that the description is wrong, all we can do is overwrite it.
We cannot create a second version about the same object during
that same period of time. But when we overwrite it, we destroy
the information that we once described that period of time in
the life history of that object differently.
In physical assertion tables, there is only one version for an
object. It describes what the object is currently like, just as rows
in conventional tables do. If something about the object
changes, we update that version, just as we update conventional
data. We overwrite the old data with the new data, destroying
information about what the object used to be like. On the other
hand, if we discover, not that the object has changed, but rather
that our data is wrong, we do not overwrite the erroneous data.
Instead, we create a new assertion about that object and, on
the same clock tick that we enter that new, corrected assertion,
we stop asserting the row with the erroneous data.
5
Of course, the rows in the physical tables that Asserted
Versioning manages have both time periods. Each row is both a
version and an assertion about that version. Assertion tables, as
we said, are views on these physical tables. They are, as we will
see, views of objects which are never represented by more than
one version at a time. And version tables, by the same token,
are also views on these physical tables. They are views of objects
for which there is only one version in effect during any given
period of time, that being the currently asserted description of
what that object is like at that time.
A conventional table view can also be defined on an asserted
version bi-temporal table. This is a view of all and only those
rows which are currently asserted and currently in effect. These
rows in conventional table views have neither assertion nor
effective time periods associated with them. Updates may either
correct mistakes in the data, or reflect changes in the world. As
with physical conventional tables, there is no way to look at
the data and tell the difference. However, with a conventional
table view, versions with future effective begin dates automati-
cally roll into the view when that date arrives. Similarly, versions
5
If this description sounds unfamiliar, it is because IT professionals seldom use
assertion tables. It would be like keeping a logfile of corrections inside a conventional
table, and it just isn't done.
