Databases Reference
In-Depth Information
specified, the result is an as-is query, a query returning our best
and current data about what an object used to be like, is like, or
may eventually be like. When a past point in time is specified,
the result is an as-was query, a query returning data about the
past, present or future which was asserted at some past point
in time. As for queries specifying future assertion time, they are
queries about internalized batch transaction datasets, about
what our data is going to look like if and when we apply those
transactions.
Queries which specify an assertion point in time, but either
no effective time or else an effective range of time, are queries
which return versioned data. So clearly, queries can return result
sets all of whose rows reside in one of the nine bi-temporal
categories or result sets whose rows are drawn from several of
those bi-temporal categories. In this way, seamless access across
those categories is provided. By containing all this data in pro-
duction tables, there is no delay between a request for that data
and when a query can be written against it.
We conclude that Asserted Versioning does provide real-time
seamless access to the full range of bi-temporal data.
Encapsulation of Temporal Data Structures
and Processes
Asserted version tables are complex. There are two time per-
iods, and each is expressed as a pair of dates. Surrogate keys are
required. Temporal foreign keys are no kind of foreign key that a
DBMS can recognize. If these bi-temporal components of data
schemas must be designed and expressed in logical data models,
the work required of those data modelers will be more complex
than work on equivalent non-temporal models. Asserted Ver-
sioning shields data modelers from this temporal design work
by means of its support for design encapsulation.
The semantic constraints that make bi-temporal data mean-
ingful are complex. They involve extensive checks for temporal
gaps, temporal contiguity and temporal overlaps. Temporal
relationships between referential parent and child data are espe-
cially complex. The code that is required to make temporal for-
eign keys carry out a temporalized version of the same work
that conventional foreign keys do is not simple code. Asserted
Versioning shields developers and DBAs from this programming
work by means of its support for maintenance encapsulation.
This also shields those who write maintenance transactions from
the complexities involved in writing what is often a lengthy
