Databases Reference
In-Depth Information
The reason we are interested in the intersection of facts and
claims is that rows in database tables are both. All rows in data-
base tables represent factual claims. One aspect of the row is
that it represents a statement of fact. The other aspect is that it
represents a claim that that statement of fact is, in fact, true. This
is just as true of conventional tables as it is of asserted version
tables.
When dealing with periods of time, as we are, the past
includes all and only those periods of time which end before
Now(). The future includes all and only those periods of time
which begin after Now(). The present includes all and only those
periods of time which include Now().
Every row in a bi-temporal table is tagged with two periods
of time, which we call assertion time and effective time. Conse-
quently, every row falls into one of these nine categories. Con-
ventional tables contain rows which exist in only one of these
nine temporal combinations. They are rows which represent
current claims about what things are currently like. But since
conventional tables do not contain any of the other eight
categories of rows, their rows don't need explicit time periods
to distinguish them from rows in those other categories. And in
conventional tables, of course, they don't have them.
Both the assertion and the effective time periods of conven-
tional rows are co-extensive with their physical presence in their
tables. They begin to be asserted, and also go into effect, when
they are created; and they remain asserted, and also remain in
effect, until they are deleted. They don't keep track of history
because they aren't interested in it. They don't distinguish
updates which correct mistakes in data from updates which keep
data current with a changing reality, ultimately because the busi-
ness doesn't notice the difference, or is willing to tolerate the
ambiguity in the data.
So conventional tables, all in all, are a poor kind of thing.
They do less than they could, and less than the business needs
them to do. They overwrite history. They don't distinguish
between correcting mistakes and making changes to keep up
with a changing world. And these conventional tables, as we all
know, make up the vast majority of all persistent object tables
managed by IT departments.
We put up with tables like these because the IT profession
isn't yet aware that there is an alternative and because, by dint
of hard work, we can make up for the shortcomings of these
tables. Data which falls into one of the other eight categories
can usually be found somewhere, or reconstructed from data
that can be found somewhere. If all else fails, DBMS archives
