Databases Reference
In-Depth Information
moment ago—leaving what looks like a non-temporal or a uni-
temporal table?
It is particularly important to hide the complexity of asserted
version tables from query authors who are not IT professionals,
from query authors who may be business analysts, scientists or
researchers. For these query authors, the solution is to query
asserted version tables through views. And no matter how much
history is contained in an asserted version table, and no matter
how much conjecture about or anticipation of the future may
be contained in an asserted version table, we are still going to
be primarily interested in what we believe, right now, things
are like right now. That is, our most frequent view of an asserted
version table will be the view that makes it look like a non-
temporal table containing current data.
The Conventional Table View
So let's create that view. Its DDL looks something like this:
CREATE VIEW V_Policy_Curr AS
SELECT oid, client, type, copay
FROM Policy_AV
WHERE eff_beg_dt
<¼
Now()
AND Now()
eff_end_dt
AND asr_beg_dt
<
<¼
Now()
asr_end_dt
Now()
may be replaced with
CURRENT TIMESTAMP, CURRENT_DATE
or getdate()
, depending on the granularity and the DBMS.
This statement will result in a view that is current whenever it
is run. So, for example, run any time prior to January 2010,
against a table containing just the three rows shown in
Figure 6.4
,
it would return an empty result set. Run on January 2010, or on
any date after that, up to but not including April 2010, it would
return the result set shown in
Figure 6.5
.
And if run on April 2010, or on any date after that, up to but
not including July 2010, it would return the result set shown in
Figure 6.6
.
AND Now()
<
oid
P861
client
Row #
1
type
HMO
copay
$15
C882
Figure 6.5 The Current Non-Temporal View from January to April.
