Databases Reference
In-Depth Information
data must be available on-line, just as current data is. Trans-
actions to maintain temporal data must be as easy to write as
are transactions to maintain current data. Queries to retrieve
temporal data, or a combination of temporal and current data,
must be as easy to write as are queries to retrieve current data
only. This is the usability aspect of seamless access.
Second, it means that queries which return temporal data, or
a mix of temporal and current data, must return equivalent-
sized results in an equivalent amount of elapsed time. This is
the performance aspect of seamless access.
Closing In on Seamless Access
Throughout the history of computerized data management, file
access methods (e.g. VSAM) and database management systems
(DBMSs) have been designed and deployed to manage current
data. All of them have a structure for representing types of objects,
a structure for representing instances of those types, and a struc-
ture for representing properties and relationships of those
instances. But none of them have structures for representing
objects as they exist within periods of time, let alone structures
for representing objects as they exist within two periods of time.
The earliest DBMSs supported sequential (one-to-one) and
hierarchical (one-to-many) relationships among types and
instances, and the main example was IBM's IMS. Later systems
more directly supported network (many-to-many) relationships
than did IMS. Important examples were Cincom's TOTAL, ADR's
DataCom, and Cullinet's IDMS (the latter two now Computer
Associates' products).
Later, beginning with IBM's System R, and Dr. Michael
Stonebreaker's Ingres, Dr. Ted Codd's relational paradigm for data
management began to be deployed. Relational DBMSs could
do everything that network DBMSs could do, but less well
understood is the fact that they could also do nothing more
than network DBMSs could do. Relational DBMSs prevailed
over CODASYL network DBMSs because they simplified the
work required to maintain and access data by supporting
declaratively specified set-at-a-time operations rather than pro-
cedurally specified record-at-a-time operations.
Those record-at-a-time operations work like this. Network
DBMSs require us to retrieve or update multiple rows in tables
by coding a loop. In doing so, we are writing a procedure; we
are telling the computer how to retrieve the rows we are inter-
ested in. So we wrote these loops, and retrieved (or updated)
one row at a time. Sometimes we wrote code that produced
