Databases Reference
In-Depth Information
Query Encapsulation
As we have already pointed out, production queries against
Asserted Versioning databases do not have to check for TEI or
TRI violations. The maintenance processes carried out by the AVF
guarantee that asserted version tables will already conform to
those semantic requirements. For example, when joining from a
TRI child to a TRI parent, these queries do not have to check that
the parent object is represented by an effective-time set of contig-
uous and non-overlapping rows whose end-to-end time period
fully includes that of the child row. Asserted Versioning already
guarantees that those parent version rows [meet] within an epi-
sode, and that they [
fill
-1
] the effective time period of the child row.
Ad hoc queries against Asserted Versioning databases can be
written directly against asserted version tables. But as far as pos-
sible, they should be written against views in order to simplify
the query-writing task of predominately non-technical query
authors. So we recommend that a basic set of views be provided
for each asserted version table. Additional subject-matter-
specific views written against these basic views could also be
created. Some basic views that we believe might prove useful
for these query authors are:
(i) The Conventional Data View, consisting of all currently
asserted current versions in the table. This is a one-row-
per-object view.
(ii) The Current Versions View, consisting of all currently asserted
versions in the table, past, present and future. This is a view
that will satisfy all the requirements satisfied by any best
practice versioning tables, as described in Chapter 4.
(iii) The Episode View, consisting of one current assertion for
each episode. That is the current version for current
episodes, the last version for past episodes, and the latest
version for future episodes. This view is useful because it
filters out the “blow-by-blow” history which version tables
provide, and leaves only a “latest row” to represent each
episode of an object of interest.
(iv) The Semantic Logfile View, consisting of all no longer
asserted versions in the table. This view collects all asserted
version data that we no longer claim is true, and should be
of particular interest to auditors.
(v) The Transaction File View, consisting of all near future
asserted versions. These are deferred assertions that will
become currently asserted data soon enough that the busi-
ness is willing to let them become current by means of the
passage of time.
