Databases Reference
In-Depth Information
is assigned as the end of the time period of the former row and
the beginning of the time period of the latter row.
2
Versions
Each row in an asserted version table represents one version
of an object. Each version represents the state of an object dur-
ing a specified period of time. In an asserted version table, that
period of time extends from each version's effective begin date
to its effective end date. In Asserted Versioning, the begin and
end dates associated with versions are called effective time
dates. In the standard temporal model, they are called valid time
dates.
In version tables, every time a change happens to an object,
the version representing the current state of that object is cop-
ied. The copy is updated, and is then inserted to become the
new current version of that object. The original copied-from ver-
sion ends its effective time period at this point in time, just as
the updated copy of that version begins its effective time period
at this same point in time. When this happens, we say that the
new version supercedes the old one.
Row-Level vs. Column-Level Versioning
We might think that some changes to certain columns of data
in versioned tables are not important enough to keep track of. In
those cases, we could overwrite an old value with a new value
instead of creating a new version. In the early stages of the devel-
opment of Asserted Versioning, we supported this distinction
between what we then called versionable changes and non-
versionable changes, the latter being the ones that were handled
by overwriting data.
But Asserted Versioning no longer supports this distinction.
On the one hand, the only value we are able to find for it is that
non-versionable updates save disk space by not creating new
versions every time an update takes place. In a table of
100 columns, for example, in which we are only interested in
keeping track of changes to a handful of those columns, and in
which many of the other columns change frequently, we would
indeed consume a lot more disk space than we would if we
2
This, in fact, is a description of what we call a basic temporal update. Basic
transactions will be discussed in Chapter 7, but we point out that many temporal
insert, update and delete transactions are not basic, and are far more complex than
this.
