Time and Time Again: Managing Time in Relational Databases, Part 23 - Original and Temporal Updates
InfoManagement Direct, April 4, 2008
Note: A glossary of technical terms used in these articles can be found on the Web sites of the authors. The URLs are MindfulData.com and InbaseInc.com.
This glossary is being constructed as a controlled vocabulary. By that we mean that any expression involving temporal concepts used in the definition of a glossary entry must itself be a glossary entry.
Advertisement
One reason for being this careful with definitions is that this kind of rigor must be applied to definitions before they can be "ontologized," i.e., expressed in a formal notation like first-order logic. That, in turn, is needed to make definitions available for manipulation by software-realized inferencing engines.
Another reason for being this careful with definitions is that this rigor must be applied to any set of technical definitions before we can claim not only that we say what we mean, but also that we know what we mean when we say it.
In our previous three articles, we introduced the distinction between original and temporal transactions. We then reviewed temporal referential integrity (RI) rules as they apply to temporal deletes. This article continues the discussion by reviewing temporal RI rules as they apply to temporal updates.
These same discussions also provide the insight necessary to decide whether we should attempt to enforce temporal RI on the updates themselves, or instead defer that integrity checking until data is retrieved. With respect to the deferral option, we will repeat what we said about it in the previous article:
It's easy to disparage [the deferral option] by describing it as letting temporal "garbage" onto the database, and then trying to hide that garbage from queries. But this is indeed the approach we have taken on temporal databases that we have designed, built, put into production and supported, and we had good reason for doing so. Like almost all database professionals, we were concerned that there would be an overwhelming volume of cascade updates if we tried to enforce temporal RI at time of update, especially when the update involves the delete of a versioned object that was the "parent" of possibly many other objects, in many other tables. (See the introduction to Part 10 for a more complete description of this "cascade update" fear.)
For the sake of continuity, we repeat the following definitions which are especially important for understanding the material in this article. These, and other technical terms, are all defined in the glossary.
Temporal Referential Integrity: Definition
If there is a temporal RI dependency from table Y to version table X (not necessarily distinct), then no exposed state of the database is valid in which any row in table Y is not object-RI linked to a row in table X, or in which the effectivity time period of a row in table Y is not wholly contained within the effectivity time period of its parent row in table X. No queries are valid which would expose such a state.
Original and Temporal Transactions: Definitions
An "original" transaction is a transaction against a versioned object.
A "temporal" transaction is the result of translating an original transaction into one or more transactions against one or more episodes of that versioned object.
Updating a Versioned Object: the Original Update Transaction
Page 1 of 4.
