Databases Reference
In-Depth Information
(Clifford, Jajodia, and Snodgrass 1993). A third temporal query language
is the TSQL2 (Temporal SQL version 2) (Androutsopoulos, Ritchie, and
Thanisch 1995; Böhlen, Jensen, and Snodgrass 1995). None of the query
languages have been generally adopted. The diἀ culty of learning such a
query syntax, lack of a standard, and lack of general adoption render the
use of temporal databases rather diἀ cult.
The relational integrity issues and relational integrity constraints work
together to render the task of managing time variant data even more dif-
ficult than it was for a nontemporal RDBMS. The double layered (i.e., Valid
Time & Transaction Time) Time Variant data can cause relational integ-
rity issues that are prevented from occurring by constraints within the
RDBMS (Gertz and Lipeck 1995).
The confusing query languages, none of which has yet been declared
the standard, render the task of querying time variant data more diἀ cult
than it was for a nontemporal RDBMS. The tuple construct embraces the
set logic inherent in an RDBMS, rather than resolve the set logic to join
one row of fact data to one row of dimension data. For these reasons, a
temporal database is not the solution to the performance bottleneck I
was seeking.
tIme vArIANt solutIoN DesIGN
The set logic inherent in every RDBMS causes each row of a f act table
to join to all the rows of a dimension table for a given primary key. The
result of that is a significant performance bottleneck. Stored procedures
can retrieve one row at a time but cannot be used by business users and
BI Reporting tools to query data from a data warehouse. Finally, tempo-
ral databases are a collective set of efforts to reconcile the join issue in
time variant data. In the process, temporal databases actually increase the
workload on the RDBMS as it enforces relational integrity constraints to
avoid relational integrity issues in the temporal database. The temporal
query languages are confusing and, as yet, not standardized.
So, what is the solution? How can a data warehouse present time vari-
ant data without the performance bottleneck caused by set logic, without
the relational integrity issues, and without the confusing query language?
Chapter 11 will present a Time Variant solution design that resolves all
these design issues and delivers Time Variant data.
