Jorge F. Garza

Composite objects revisited

In object-oriented systems, an object may recursively reference any number of other objects. The references, however, do not capture any special relationships between objects. An important semantic relationship which may be superimposed on a reference is the IS-PART-OF relationship between a pair of objects. A set of objects related by the IS-PART-OF relationship is collectively called a composite object. An earlier paper [KIM87b] presented a model of composite objects which has been implemented in the ORION object-oriented database system at MCC. Although the composite-object feature has been found quite useful, the model suffers from a number of serious shortcomings, primarily because it overloads a number of orthogonal semantics on the references. In this paper, first we present a more general model of composite objects which does not suffer from these shortcomings. Further, [KIM87b] made an important contribution by exploring the use of composite objects as a unit for versions, physical clustering, and concurrency control. The extended model of composite objects necessitates non-trivial changes to the results of [KIM87b]. This paper describes the new results on the use of composite objects as a unit of not only versions, physical clustering and concurrency control, but also authorization.

Architecture of the ORION next-generation database system

Various architectural components of ORION-1 and ORION-1SX are described and a review of the current implementation is provided. The message handler receives all messages sent to the ORION system. The object subsystem provides high-level data management functions, including query optimization, schema management, long data management (including text search) and support for versionable objects, composite objects, and multimedia objects. The transaction management subsystem coordinates concurrent object accesses and provides recovery capabilities. The storage subsystem manages persistent storage of objects and controls the flow of objects between the secondary storage device and main memory buffers. In ORION-1, all subsystems reside in one computer. The ORION-1SX architecture is significantly different from ORION-1 in the management of shared data structures and distribution of these subsystems and their components. >

Composite object support in an object-oriented database system

Many applications in such domains as computer-aided design require the capability to define, store and retrieve as a single unit a collection of related objects known as a composite object. A composite object explicitly captures and enforces the IS-PART-OF integrity constraint between child and parent pairs of objects in a hierarchical collection of objects. Further, it can be used as a unit of storage and retrieval to enhance the performance of a database system. This paper provides a formal definition of the semantics of composite objects within an object-oriented data model, and describes their use as units of integrity control, storage and retrieval, and concurrency control in a prototype object-oriented database system we have implemented.

Transaction management in an object-oriented database system

In this paper, we describe transaction management in ORION, an object-oriented database system. The application environments for which ORION is intended led us to implement the notions of sessions of transactions, and hypothetical transactions (transactions which always abort). The object-oriented data model which ORION implements complicates locking requirements. ORION supports a concurrency control mechanism based on extensions to the current theory of locking, and a transaction recovery mechanism based on conventional logging.

Clustering a DAG for CAD databases

A DAG (direct acyclic graph) is an important data structure which requires efficient support in CAD (computer-aided design) databases. It typically arise from the design hierarchy, which describes complex designs in terms of subdesigns. A study is made of the properties of the three types of clustered sequences of nodes for hierarchies and DAGs, and algorithms are developed for generating the clustered sequences, retrieving the descendants of a given node, and inserting new nodes into existing clustered sequences of nodes which preserve their clustering properties. The performance of the clustering sequences is compared. >

A distributed object-oriented database system supporting shared and private databases

ORION-2 is a commercially available, federated, object-oriented database management system designed and implemented at MCC. One major architectural innovation in ORION-2 is the coexistence of a shared databese and a number of private databases. The shared database is accessible to all authorized users of the system, while each private database is accessible to only the user who owns it. A distributed database system with a shared database and private databases for individual users is a natural architecture for data-intensive application environments on a network of workstations, notably computer-aided design and engineering systems. This paper discusses the benefits and limitations of such a system and explores the impact of such an architecture on the semantics and implementation of some of the key functions of a database system, notably queries, database schema, and versions. Although the issues are discussed in the context of an object-oriented data model, the results (at least significant portions thereof) are applicable to database systems supporting other data models.

Object-oriented database support for CAD

Abstract ORION is a prototype object-oriented database system built in the Advanced Computer Technology (ACT) Program at MCC. It is intended to support the data management needs of applications in such domains as computer-aided design, artificial intelligence, and office information systems. The paper describes features of ORION which have been implemented specifically to support CAD environments. These include dynamic schema evolution, version control and change notification, and transaction management.

Spatial Data Management In Database Systems: Research Directions

Spatial data management has been an active area of research during the past two decades, and results of research into spatial data structures and research into mapping spatial data into records in relational databases have found their way into commercial implementations of geographical information systems. However, no commercial database system today directly supports spatial data management, in particular, data definition and query facilities for spatial data. The objective of this paper is to identify a number of key issues that need to be addressed in the near term before we can expect to see a rich support of spatial data management in commercial database systems.

Enhancing the object-oriented concepts for database support

In this paper, we elaborate on three major enhancements to the conventional object-oriented data model, namely, schema evolution, composite objects, and versions. Schema evolution is the ability to dynamically make changes to the class definitions and the structure of the class lattice. Composite objects are recursive collections of exclusive components that are treated as units of storage, retrieval, and integrity enforcement. Versions are variations of the same object that are related by the history of their derivation. These additional features are strongly motivated by data management requirements of object-oriented applications from the AI, CAD/CAM, and OIS (office information systems with multimedia documents) domains. An object-oriented data model, with these enhancements, has been incorporated into ORION, a prototype database system developed at MCC as a vehicle of research into object-oriented databases.