Databases Reference
In-Depth Information
Temporal Update
Physical Transaction(s)
Update an object
within a designated
timespan.
Withdraw the affected
versions.
Assert the before-update
replacements.
Assert the after-update
successors.
Figure 7.6 Basic Scenario, Update Transaction: Temporal to Physical Mapping.
The First Physical Transaction
The result of applying the first of these physical transactions is
shown in
Figure 7.7
. This physical transaction
withdraws
the cur-
rent assertion. It does so by doing a physical update of row 1, over-
writing its assertion end date with the same date on which the two
new versions will begin to be asserted. In this case, that is the
same date as the date of the transaction itself, i.e. May 2010.
In
Figure 7.7
, we can see that the database now shows that row 1
was asserted from January 2010 to May 2010, but not after that.
Row 1, and its assertion time snapshot, are shaded to indicate
that row 1 is no longer asserted. The row number is enclosed
within angle brackets as a way of showing that the row is locked.
It is locked—from other updates and also, unless dirty reads are
allowed, from viewing as well—because it is part of an all-or-
nothing isolated unit of work that will not be complete until
the third physical transaction is complete.
This row says that from January 2010 to 12/31/9999, policy
P861 is as shown. But based on the information supplied by
the temporal update transaction, we now know that it is not true
May10
UPDATE Policy [P861, , , $20]
Jan10
1
1
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
Row
#
<1>
oid
eff-beg
eff-end
asr-beg
asr-end
epis-
beg
client
type
copay
row-crt
P861
9999
Jan10
Jan10
C882
$15
Jan10
Jan10
May10
HMO
Figure 7.7 Basic Scenario, First Temporal Update: After the First Physical Transaction.
