Databases Reference
In-Depth Information
schemas and with support for the full semantics of versioning,
whether or not the specific business requirements, at the time,
specify those full semantics.
With all these various physical datasets internalized within
the production tables they are directed to or derived from,
Asserted Versioning eliminates the cost of managing them as
distinct physical data objects.
Asserted Versioning also eliminates the cost of coordinating
maintenance to them. There is no latency as updates to produc-
tion tables ripple out to downstream copies of that same data,
such as separate history tables. On the inward-bound side, there
is also no latency. As soon as a transaction is written, it becomes
part of its target table. The semantics supported here is, for
maintenance transactions, “submit it and forget it”.
We conclude that Asserted Versioning
does
support
the
semantics of the internalization of pipeline datasets.
Performance
We have provided techniques on how to index, partition,
cluster and query an Asserted Versioning database. We've
recommended key structures for primary keys, foreign keys
and search keys, and recommended the placement of temporal
columns in indexes for optimal performance. We have also
shown how to improve performance with the use of currency
flags. All these techniques help to provide query performance
in Asserted Versioning databases which is nearly equivalent to
the query performance in equivalent conventional databases.
We conclude that queries against even very large Asserted
Versioning databases, especially those queries retrieving cur-
rently asserted current versions of persistent objects, will per-
form as well or nearly as well as the corresponding queries
against a conventional database.
Enterprise Contextualization
As temporal data has become increasingly important, much
of it has migrated from being reconstructable temporal data to
being queryable temporal data. But much of that queryable tem-
poral data is still isolated in data warehouses or other historical
databases, although some of it also exists in production databases
as history tables, or as version tables. Often, this queryable tem-
poral data fails to distinguish between data which reflects changes
in the real world, and data which corrects mistakes in earlier data.
