Databases Reference
In-Depth Information
Episode A
7
1
8
2
6
9
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
Figure 10.6 Lengthening an Episode Forwards: After the Transaction.
It is May 2010, and the following transaction is submitted to
the AVF:
INSERT INTO Policy [P861, C882, HMO, $25] Oct 2010, Dec 2010
Immediately after this transaction is completed, the history
shown in
Figure 10.5
will no longer be currently asserted.
Instead, it will be the history of the policy as asserted from when
the previous transaction was applied up to May 2010. The
new currently asserted history of the policy will be as shown in
Figure 10.6
. Version 9 looks like this:
P[P861[Oct10-Dec10][May10-9999][Jan10][C882, HMO, $25]
[May10]]
Episode begin dates are not supplied on transactions. They
are always determined by the AVF. In this case, the AVF sees that
there is already a version of that same policy in the table whose
effective end date [meets
1
] the effective begin date on the
transaction. Because this match means that the episode is being
extended forwards, the AVF assigns version 9 the episode begin
date on the version it is contiguous with—in this case, version 8.
So now, on May 2010, we are claiming that we know several
things about policy P861's future. We know that it will remain
in effect until December 2010, i.e. through November 30
th
,
2010. We know that from May 2010 to October 2010, it will have
the properties ascribed to it by version 8. We also know that in
October and November of that year, it will be an HMO policy
with a $25 copay.
We say we know this about the future. But, of course, as with
any statement about the future, we may be wrong. However,
since anyone viewing this data about the future will understand
this, we are misrepresenting nothing.
Merging Episodes
We have seen how temporal inserts can create new episodes
and can extend existing episodes backwards and forwards. But
when any but
the latest episode of an object
is extended
