Databases Reference
In-Depth Information
hand-off
to P861(r8) on precisely that clock tick. But then a sec-
ond deferred update was applied, which overrode P861(r8) with
P861(r9 & r10), and then updated P861(r9).
When we originally created P861(r9 & r10), that future clock
tick was January 2090. We are now about to change the assertion
begin date on those two assertions to April 2013.
But if we do so, and do nothing about P861(r6), we will create
a TEI violation. If we do nothing about P861(r6), then from
January 2013 to January 2090, P861(r6) will assert that P861's
copay amount in May 2012 was $30, but P861(r9) will assert that
it was $50. So even though P861(r6) exists in a closed period of
assertion time, it can, and indeed in this case must, be
overridden. So rather than thinking of the approval transaction
as changing the assertion begin date on one or more deferred
assertions, we should think of it as changing the
hand-over
clock
tick between locked assertions and the deferred assertions that
are being moved backwards in assertion time.
The approval transaction looks like this:
6
UPDATE Policy [ ],, Jan 2090, Apr 2013
This transaction is unlike the standard temporal update
transaction in that its temporal parameters are both assertion
dates. As indicated by the commas, there are no effective time
dates on this transaction. And although a standard transaction
can have one assertion date, this transaction has two assertion
dates.
The first assertion date on the approval transaction is the
assertion group date
. The second is the
assertion approval date
.
The transaction proceeds as an atomic (all-or-nothing, and
isolated) unit of work. For all assertions whose assertion begin
date matches the assertion group date, it changes their assertion
begin dates to the approval date. This is shown in
Figure 12.7
.
P861(r9 & r10) have been moved from far future (2090) into near
future (2013) assertion time. As soon as April 2013 occurs, those
two rows will fall into currency.
The approval transaction is almost complete, but it has one
thing left to do. As shown in
Figure 12.6
, P861(r6) has a January
2090 assertion end date prior to the approval transaction. If
nothing is done, then in less than a month after the approval
transaction is applied, P861(r9 &r10) will be in TEI conflict with
P861(r6), and will remain so for several decades.
6
As we have noted before, these examples do not use the syntax that will be used in
release 1 of the AVF. The temporal data in these transactions is shown in a refinement
of a comma-delimited positional notation.
