PROCEEDINGS OF FOURTH BERKELEY CONFERENCE ON DISTRIBUTED DATA MANAGEMENT AND COMPUTER NETWORKS.

Data base access is increasingly important in a networking environment.Two alternative approaches can be identified: i) implementation of distributed databases presenting the user with one logical database implemented across a collection of computers or, alternatively, ii) development of network data managers providing a uniform user and program viewpoint across heterogenous DBMSs.While the first approach is the most natural extension of the concept of an individual DBMS, its utilization imposes certain requirements including the necessity for converting existing DBMSs if their data is to be supported in the distributed environment.The second approach minimiz.esor eliminates cO"lwersion problems; however, it has not yet caen shown feasible.This paper describes an ongoing research project concerned with establishing the feasibility, issues, alternatives, and a technical approach for supporting a network data manager.Although implementation has not been completed, the initial evidence is positive and suggests that network data managers may well prove either an acceptable alternative or useful intermediate stage to a distributed database.Perhaps the three key issues in ensuring user acceptance of a network data manager are: i) access controls and semantic integrity, ii) developing more sophisticated translation capabilities optimizing the allocation of the translation process among NOM and LDBMS, and iii) performance.We believe the basic issues and a reasonable approach for (i) have, been discussed in this paper.Developing a more sophisticated translation capability is of obvious importance and closely relates to the performance issue.Implementation of translators should be paralleled with research directed toward a better understanding of the nature of the translation process.Some work is beginning to appear in this area [KLUGA 78] establishing the theoretical limits of translation feasibility. Implementation StatusXNDM translation is performed on a PDp11 /45 attached to the Arpanet as are the other host computers.Tbe operating system for the PDp11 145 is UNIX [THOMK 74] and the translator' is programmed in C. To provide a more uniform interface to the translator, small support modules termed envelopes are implemented on the system on which each LDBMS resides.Basic communications support between systems and the ability to preserve meaning ,in transporting structured records between heterogeneous systems is provided by. an Experimental Network Operating System (XNOS) [KIMBS 78].Work on the XNQL translator is still in progress.The current version handles two out of the six XNQL constructs (selections of columns and rows), for the following target systems:the Multics Relational Data Store (MRDS) [HONEY 77], a relational calculus system, and the Honeywell 600/6000 Integrated Data Store (IDS) [HONEY 71], a Codasyllike system.For MRDS, the translator can handle all target data structures In general, but for IDS, target records with multiple owners and multiple members are excluded. Implementation ApproachTwo different approaches to implementing XNDM can be considered.The first distributes the implementation across the supported host systems whiie the second, which we have adopted, offloads the implementation, to the extent possible, onto a separate satellite computer.The tradeoffs between these two approaches are essentially those of evaluating the cost of supporting an additional computer versus the cost of implementing common modules on several different systems.Given the opportunity for centralized design, implementation and support.afforded by offloading and the increasingly high' cost of software, we believe that offloading is the natural approach in an evolving technology.The alternative might be appropriate for an extremely static environment.6.

Fetched live from OpenAlex and de-inverted. Abstracts are not stored in this database: the inverted indexes are 8.6 GB of the frame’s 9.3 GB of text, and the host has 13 GB free.