DEFERRED ASSERTIONS AND OTHER PIPELINE DATASETS - Managing Time in Relational Databases - page 269

Policy Table

Row
#
1

oid eff-beg eff-end asr-beg asr-end epis-

beg

clinet type copay row-crt

Mar12 9999

9999

P861
P861
P861
P861
P861
P861
P861
P861
P861
P861

Nov11 Nov11 Nov11 C882 HMO Nov11

Mar12

$20
$50
$30
$40
$30
$30
$30
$55
$55
$55

2
3
4
5
6
7
<8>
<9>
<10>

Mar12 Mar12 Nov11

Nov11
Nov11
Nov11
Nov11
Nov11
Nov11
Nov11
Nov11

Apr12 C882

C882
C882
C882
C882
C882
C882
C882
C882

PPO

Aug12 Apr12 Jan13 Apr12

Aug12

Apr12 HMO

POS Aug12 9999 Aug12 9999

9999

May12

Apr12 Jan13 Jan13

Jan13
Jan13
Jan13
Feb13
Feb13

HMO
HMO
HMO
HMO
HMO
HMO

May12 Jul12 Jan90

Jan13

Jul12 Aug12 9999

Jan13
Jan90
Jan90
Jan90

May12
May12
Jun12

Jul12
Jun12
Jul12

Jan90

9999
9999

Figure 12.5 A Deferred Assertion: Effective Time Alignment.

equivalent pair of rows, one of which matches the transaction.
This is shown in Figure 12.5 . P861(r8) has been withdrawn. In
its place, the AVF has created the two rows P861(r9 & r10).
P861(r8) has been withdrawn into closed assertion time, but
that assertion time is neither past nor present assertion time. It
is empty assertion time , because the time period [Jan 2090 -
Jan 2090] includes no clock ticks, not a single one.

Reflections on Empty Assertion Time
In all our dealings with temporal transactions, the assertion
date specified on the transaction (or accepted as a default) is
used both as the assertion end date of the withdrawn row and
also as the assertion begin date of the row or rows that replace
and/or supercede it. In this way, our transactions build an
unbroken succession of assertions about what the object in
question is like during the unbroken extent of the episode's
effective time.
P861(r8) cannot be withdrawn into past assertion time
because it hasn't been asserted yet. But it also can't be allowed
to remain in future assertion time because if P861(r9 and/or
r10) are ever updated, they and P861(r8) would make different
statements about what P861 was like at the same point in time,
i.e. in either May or June 2012. In other words, P861(r8) can't
be allowed to remain in future assertion time because it would
then be a TEI conflict waiting to happen.
This is why the AVF moved it into empty assertion time. This
is the semantically correct thing to do. With P861(r9 & r10) now
in the database, which together match P861(r8), and with both
being in yet-to-come assertion time, one of them had to go.