Databases Reference
In-Depth Information
to it except that it states that the business data it contains ceases to
be effective on May 2010. We then follow that with another asser-
tion which records the actual change in business data that does
become effective on May 2010.
The First Physical Transaction
It is now December 2010.
Figure 7.15
shows the state of the
target table before the first of the two physical transactions for
this temporal delete transaction has been applied. Because the
temporal transaction does not include any bi-temporal
parameters, default values are used. The result is that the trans-
action tells us to delete P861 as of December 2010. Using the
default values, the transaction specifies an assertion and effec-
tive time range, in both cases, of [Dec 2010 - 12/31/9999]. It is
row 5 which the transaction's two time periods overlap, and so
it is row 5 which will be affected by the delete.
Figure 7.16
shows the results of applying the first physical
transaction.
As indicated in
Figure 7.16
, the first of these physical trans-
actions withdraws the currently asserted, currently effective
row, row 5. Because a specific assertion end date is not specified,
the default of Now() is used, and the assertion end date for row 5
is therefore changed from 12/31/9999 to December 2010. This
“clears the decks” because the latest thing we are still currently
asserting about P861 is a version covering May 2010 to August
2010, which is row 4.
Dec10
DELETE FROM Policy [P861]
Jan10
1
1
2
1
2
1
May10
3
4
3
Aug10
5
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
eff-beg
client
row-cut
Row
#
1
2
3
4
<5>
oid
eff-end
asr-beg asr-end
epis-
beg
type
copay
Jan10
P861
Jan10
9999
Jan10
May10
Jan10
C882
HMO
$15
$15
$20
$20
$20
P861
P861
P861
P861
Jan10
May10
May10
May10
9999
Jan10
Jan10
Jan10
Jan10
C882
C882
C882
C882
HMO
HMO
HMO
PPO
May10
May10
9999
Aug10
May10
May10
Aug10
Aug10
Aug10
Aug10
9999
9999
Aug10
Aug10
Dec10
Figure 7.16 Basic Scenario, Temporal Delete: After the First Physical Transaction.
