Coercing DBMSs to cooperate - DBMS: Distributed Databases - includes related articles titled 'IBM's distributed database direction,' military's Cals provides distributed DBMS model,' and 'importance of optimization'

Software Magazine, Nov, 1989 by Barbara Bochenski, Mike Bucken

IBM's R* (pronounced "RStar") project was the best known prototype of a distributed DBMS. Stonebraker says the R* benefitted from insight to the mistakes of earlier prototypes, as well as from the availability of Vtam software for communication. It was developed at IBM Research in San Jose, Calif.

R* consists of multiple, cooperating copies of System R, IBM's earlier research database system. R* is designed to run on a group of IBM mainframes that communicate with the InterSystems Communication facility (ISC) of CICS (CICS/ISC.)

TAKING "SNAPSHOTS"

All of these research prototypes made valuable contributions to the state-of-the-art of distributed database technology. Many of the techniques developed in the laboratories are appearing in commercial products today.

One of the specific features of R* that is expected to make an appearance in DB2 is support for "snapshots." A snapshot is a named, derived table.

Creating a snapshot is similar to executing an SQL query. The value is stored in the database under the snapshot's name. The definition of the snapshot and the time of its creation are stored in the system catalog. The snapshot is "refreshed," or recreated, according to the interval specified in the snapshot's definition.

Snapshots provide a way of creating multiple copies of data and allow those copies to be stored at multiple sites. Retrieval requests can be directed to the nearest snapshot, instead of to the "master" copy.

But the data is only as current as the most recent refresh operation. For many applications, however, this is acceptable.

When thinking about the advantages of distributed database systems, one needs to be wary. For its many advantages, there are corresponding disadvantages. The problems must be overcome or the distributed system loses strength.

CCA's Winter says that while much of the recent work involving distributed systems has centered around SQL, people will soon need to handle text and graphics-oriented objects.

Often, distributed databases are justified for business reasons. As Stonebraker points out, many companies are fundamentally distributed. For example, Relational Technology, Inc. (RTI) has its headquarters and U.S. customer base stored in Alameda, Calif. But it also has a British customer base in London, Frankfurt, West Germany and Paris.

Generally, only the local customer base is accessed by RTI users. But sometimes users need cross database access. If a salesman wants to know all the RTI sites within a multinational corporation, access to all of the RTI customer databases is required.

Using Ingres, the RTI user can access that information with a simple query. While the system will access numerous, geographically dispersed systems for the data to the end user, it will appear that there is only one system--the local one.

Using Ingres as a focal point, the geographically dispersed systems could even consist of DBMSs from different vendors, comprising a heterogeneous system. If the database management systems at different sites are the same, the system is a homogeneous distributed database system.