Databases Reference
In-Depth Information
Dec10
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
UPDATE Policy
SET ver_end = 'Dec10'
WHERE BK = 'P861' AND ver_beg = 'Aug10'
BK
P861
P861
P861
ver-dt
client
type
copay
ver-end
May10
Aug10
Dec10
Jan10
C882
HMO
$15
May10
C882
HMO
$20
Aug10
C882
PPO
$20
Figure 4.8 A Temporal Gap Version Table: After the Delete Transaction.
As we have seen, when an insert or update is made, the ver-
sion created is given an end date of 12/31/9999. Since most of
the time, we do not know how long a version will remain current,
this isn't an unreasonable thing to do. So each of the first two
rows was originally entered with a 12/31/9999 end date. Then,
when the next version was created, its end date was given the
same value as the begin date of that next version.
So when applying a delete to a temporal gap version table, all
we need to do is set the end date of the latest version of the object
to the deletion date, as shown in
Figure 4.8
. In fact, although the
delete in this example takes effect as soon as the transaction is
processed, there is no reason why we can't do “proactive deletes”,
processing a delete transaction but specifying a date later than the
current date as the value to use in place of 12/31/9999.
Effective Time Versioning
The most advanced best practice for managing versioned data
which we have encountered in the IT world, other than our own
early implementations of the standard temporal model, is effective
time versioning.
Figure 4.9
shows the schema for effective time
versioning, and the results of applying a proactive insert, one
which specifies that the new version being created will not take
effect until two months after it is physically inserted.
Effective time versioning actually supports a limited kind of
bi-temporality. As we will see, the ways in which it falls short
of full bi-temporality are due to two features. First, instead of
adding a second a pair of dates to delimit a second time period
