Databases Reference
In-Depth Information
are run over and over again. Since the cost of writing them is
amortized over hundreds or often thousands of executions, it is
a negligible cost.
To provide seamless access to bi-temporal data, developers
will usually write these production queries directly against
asserted version tables, primarily to avoid the inflexibility which
exists when views are used. For these queries, and these query
authors, we believe that by imposing bi-temporal semantic
constraints on bi-temporal data as that data is maintained,
Asserted Versioning makes queries against its tables nearly as
easy to write as queries against conventional tables.
In the final section of this chapter, we discuss the use of sur-
rogate keys. Asserted Versioning uses a surrogate key as a unique
identifier of each represented object. When surrogate keys are
used with non-temporal tables, the logic for adding them to
transactions which do not already have them is simple: an insert
transaction gets assigned a surrogate key if and only if its busi-
ness key does not match a row already in the database; an
update or delete transaction that lacks a surrogate key gets
assigned the surrogate key of a row already in the database that
has a matching business key, and is otherwise rejected. But with
temporal tables, surrogate key assignment logic is more complex
than this. We conclude this chapter by noting the differences and
introducing the topic of how surrogate keys are assigned to
asserted version tables.
Objects, Episodes, Versions and Assertions
The basic statement of Asserted Versioning is this:
Every row in an asserted version table is the assertion of a version
of an episode of an object.
Asserted Versioning is a special kind of temporal data manage-
ment. One thing that makes it special is these core concepts.
Objects
Asserted Versioning recognizes persistent objects as the funda-
mental things its rows are about. Every row is about some partic-
ular thing, and that thing is an object that persists over time.
Every row contains business data which describes that object.
Objects are what, in Chapter 2, we called things. These things
may be abstract or concrete, real or imagined. The term “persistent
