Databases Reference
In-Depth Information
would at a minimum double the number of scenarios. Of course
it might be possible to eliminate some of these scenarios as
semantically impossible, i.e. as corresponding to no meaningful
state and/or no meaningful transformation; but each one would
still have to be analyzed.
We cannot analyze every one of these scenarios. Instead, our
approach will be to analyze one variation of each temporal
extent transformation, and then briefly discuss other variations
which appear to be interestingly different.
The Asserted Versioning Temporal
Transactions
Figure 9.6
shows three episodes—A, B and C—located along a
four-year timeline. Eight versions make up these three episodes,
which are all episodes of the same object, policy P861. We will be
referring to this diagram throughout our discussion of temporal
transactions.
In the syntax used for the transactions shown below, values
are associated with business data columns by means of their
position in a bracket-delimited, comma-separated series of
values. Except for the object identifier, which occupies the first
position, the other six columns which implement Asserted
Versioning are not included in this list, those other columns
being effective begin date, effective end date, assertion begin
date, assertion end date, episode begin date and row create date.
And of those six temporal parameters, only the first three may be
specified on a temporal transaction.
The syntax used in this topic for temporal transactions is not
the syntax in which those transactions will be submitted to the
AVF. That is, it is not the syntax with which the AVF will be
invoked. We use it because it is unambiguous and compact.
The actual transactions supported by release 1 of the AVF can
be seen at our website, AssertedVersioning.com.
Episode A
Episode B
Episode C
1
2
3
4
5
6
7
8
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
Figure 9.6 Eight Versions and Three Episodes of Policy P861.
