Databases Reference
In-Depth Information
Temporal Gap Versioning
Let's begin by looking at the state of a temporal gap version
table that would have resulted from applying all our transactions
to this kind of version table. We begin with the state of the table
on November 2010, just before the delete transaction is applied,
as shown in
Figure 4.7
.
We notice, first of all, that a logical delete flag is not present
on the table. We will see later why it isn't needed. Next, we see
that except for the last version, each version's end date is the
same as the next version's begin date. As we explained in
Chapter 3, the interpretation of these pair of dates is that each
version begins on the clock tick represented by its begin date,
and ends one clock tick before its end date.
In the last row, we use the value 9999 to represent the highest
date the DBMS is capable of recording. In the text, we usually
use the value 12/31/9999, which is that date for SQL Server, the
DBMS we have used for our initial implementation of the
Asserted Versioning Framework. Notice that, with this value in
ver_end, at any time from August 2010 forward the following
WHERE clause predicate will pick out the last row:
WHERE ver_dt <ΒΌ Now() AND Now() < ver_end
1
Or, at any time from May to August, the same predicate will
pick out the middle row. In other words, this WHERE clause
predicate will always pick out the row current at the time the
query containing it is issued, no matter when that is.
Figure 4.8
shows how logical deletions are handled in tempo-
ral gap version tables.
Nov10
Jan
2010
BK
P861
P861
P861
Jan
2011
Jan
2012
Jan
2013
Jan
2014
copay
$15
$20
$20
ver-dt
client
type
ver-end
Jan10
C882
C882
C882
HMO
May10
May10
HMO
Aug10
Aug10
9999
PPO
Figure 4.7 A Temporal Gap Version Table: Before the Delete Transaction.
1
We use hyphens in column names in the illustrations, because underscores are more
difficult to see inside the outline of the cell that contains them. In sample SQL, we
replace those hyphens with underscores.
