Databases Reference
In-Depth Information
Now the information content of the two tables begins
to diverge. The version table tells us that P861 had a copay of
$15 from January to May, and a copay of $20 thereafter. The
non-temporal table does tell us that an update was made in
May, and that the copay for P861 is now $20, but it doesn't tell
us what data the update changed, or how many updates have
already been applied to the policy.
But the version table tells us all these things. We can deter-
mine what was changed by the update by comparing each
non-initial version of the object with its immediate predecessor.
We can tell what the policy was like before the change by looking
at the previous version. We can tell how many updates have
been applied to the policy by counting the versions, and we
can tell when each one took place.
A Second Update Transaction
Figure 4.3
shows a second update transaction. This transac-
tion updates the policy type from HMO (Health Maintenance
Organization) to PPO (Preferred Provider Organization).
Aug10
Jan
2010
Jan
2011
Jan
2012
Jan
2013
Jan
2014
UPDATE Policy
SET type = 'PPO', updt_dt = CURRENT_DATE
WHERE BK = 'P861'
BK
P861
client
type
copay
crt-dt
updt-dt
C882
PPO
$20
Jan10
Aug10
INSERT INTO Policy (BK, ver_dt, client, type, copay)
VALUES ('P861', CURRENT_DATE, 'C882', 'PPO', '$20')
BK
ver-dt
client
type
copay
P861
P861
P861
Jan10
C882
HMO
$15
May10
Aug10
C882
C882
HMO
PPO
$20
$20
Figure 4.3 Conventional and Basic Version Tables: A Second Update
Transaction.
