Databases Reference
In-Depth Information
So business needs for a collection of temporal data against
which queries can be written are often difficult to meet. Some
of the needed data may be in a data warehouse; the rest of
it may be contained in various history tables and version tables
in the production database, and the odds of those history tables
all using the same schemas and all being updated according
to the same rules are not good. As for version tables, we have
seen how many different kinds there are, and how difficult it
can be to write queries that extract exactly the desired data
from them.
We need an enterprise solution to the provision of queryable
bi-temporal data. We need one consistent set of schemas, across
all tables and all databases. We need one set of transactions that
update bi-temporal data, and enforce the same temporal integ-
rity constraints, across all tables and all databases. We need a
standard way to ask for uni-temporal or bi-temporal data. And
we need a way to remove all temporal logic from application
programs, isolate it in a separate layer of code, and invoke it
declaratively.
Asserted Versioning is that enterprise solution.
Asserted Versioning as a Bridge and
as a Destination
Asserted Versioning, either in the form of the AVF or of a
home-grown implementation of its concepts, has value as both
a bridge and as a destination. As a bridge to a standards-based,
vendor-supported implementation of bi-temporal data manage-
ment, Asserted Versioning is a way to begin migrating databases
and applications right away, using the DBMSs available today
and the SQL available today. As a destination, Asserted
Versioning is an implementation of a more complete semantics
for bi-temporality than has yet been defined in the academic
literature.
Asserted Versioning as a Bridge
Applications which manage temporal data intermingle code
expressing subject-matter-specific business rules with code for
managing these different forms in which temporal data is stored.
Queries which access temporal data in these databases cannot
be written correctly without a deep knowledge of the specific
schemas used to store the data, and of both the scope and limits
of the semantics of that data. Assembling data from two or more
