scispace - formally typeset
Search or ask a question
Journal Article•DOI•

Managing the chip design database

01 Dec 1983-IEEE Computer (IEEE)-Vol. 16, Iss: 12, pp 26-36
TL;DR: This work describes what design data management is and how it can integrate design tools, and presents the architecture of a prototype design management system in which designs are organized into a richly interconnected data structure, using an object data model.
Abstract: A design data management system bridges the gap between design tools and database systems, creating an integrated tool environment. Although design databases have long been of interest, they have been largely ignored within the context of the new tools. Our purpose is to describe what design data management is and how it can integrate design tools. Our discussion focuses on unique data management requirements of design systems and conventional database facilities and their shortcomings for supporting design data. We also present the architecture of a prototype design management system in which designs are organized into a richly interconnected data structure, using an object data model. The structures of that system's storage, recovery, concurrency control, and design validation subsystems are also described as is a "browser" for interactively viewing design data.

Content maybe subject to copyright    Report

Citations
More filters
Journal Article•DOI•
TL;DR: This work provides a common terminology and collection of mechanisms that underlie any approach for representing engineering design information in a database, and proposes a single framework, based on these mechanisms, which can be tailored for the needs of a given version environment.
Abstract: Support for unusual applications such as computer-aided design data has been of increasing interest to database system architects. In this survey, we concentrate on one aspect of such support, namely, version modeling. By this, we mean the concepts suitable for structuring a database of complex engineering artifacts that evolve across multiple representations and over time and the operations through which such artifact descriptions are created and modified. There have been many proposals for new models and mechanisms to support such concepts within database data models in general and engineering data models in particular; here we not only describe such proposals; we also unify them. We do not propose yet another model but provide a common terminology and collection of mechanisms that underlie any approach for representing engineering design information in a database. The key remaining challenge is to construct a single framework, based on these mechanisms, which can be tailored for the needs of a given version environment.

535 citations

Journal Article•DOI•
01 Jun 1986
TL;DR: This paper describes the results of developing the GemStone object-oriented database server, which supports a model of objects similar to that of Smalltalk-80, and discusses satisfying the remaining requirements in an object oriented context.
Abstract: We describe the results of developing the GemStone object-oriented database server, which supports a model of objects similar to that of Smalltalk-80. We begin with a summary of the goals and requirements for the system: an extensible data model that captures behavioral semantics, no artificial bounds on the number or size of database objects, database amenities (concurrency, transactions, recovery, associative access, authorization) and an interactive development environment. Object-oriented languages, Smalltalk in particular, answer some of these requirements. We discuss satisfying the remaining requirements in an object oriented context, and report briefly on the status of the development efforts. This paper is directed at an audience familiar with object-oriented languages and their implementation, but perhaps unacquainted with the difficulties and techniques of database system development. It updates the original report on the project [CM], and expands upon a more recent article [MDP].

418 citations

Book•
13 Jan 1990
TL;DR: The GemStone object-oriented database server as discussed by the authors is a Smalltalk-based database server that supports a model of objects similar to that of Smalltalk 80, which is similar to the one described in this paper.
Abstract: We describe the results of developing the GemStone object-oriented database server, which supports a model of objects similar to that of Smalltalk-80. We begin with a summary of the goals and requirements for the system: an extensible data model that captures behavioral semantics, no artificial bounds on the number or size of database objects, database amenities (concurrency, transactions, recovery, associative access, authorization) and an interactive development environment. Object-oriented languages, Smalltalk in particular, answer some of these requirements. We discuss satisfying the remaining requirements in an object oriented context, and report briefly on the status of the development efforts. This paper is directed at an audience familiar with object-oriented languages and their implementation, but perhaps unacquainted with the difficulties and techniques of database system development. It updates the original report on the project [CM], and expands upon a more recent article [MDP].

212 citations

Journal Article•DOI•
TL;DR: Megaprogramming is a technology for programming with large modules called megamodules that capture the functionality of services provided by large organizations like banks, airline reservation systems, and city transportation systems.
Abstract: Megaprogramming is a technology for programming with large modules called megamodules that capture the functionality of services provided by large organizations like banks, airline reservation systems, and city transportation systems. Megamodules are internally homogeneous, independently maintained software systems managed by a community with its own terminology, goals, knowledge, and programming traditions. Each megamodule describes its externally accessible data structures and operations and has an internally consistent behavior. The concepts, terminology, and interpretation paradigm of a megamodule is called its ontology.

175 citations


Cites background from "Managing the chip design database"

  • ...However, it has become clear that not all database applications fit into this basic paradigm, so that new models of transactions are emerging, including long transactions [16] and nested transactions [20]....

    [...]

Journal Article•DOI•
15 Jun 1986
TL;DR: A semantic object-oriented data model for representing how a complex design database evolves over time is described, supporting version histories, time-varying configurations, and equivalences among objects of different types.
Abstract: We describe a semantic object-oriented data model for representing how a complex design database evolves over time. Structural relationships, introduced by the data management system, are imposed on the objects created by existing CAD tools. The relationships supported by the model are (1) version histories, (2) time-varying configurations, and (3) equivalences among objects of different types. We describe mechanisms for (1) identifying current versions, (2) supporting dynamic configuration binding, and (3) verifying equivalence relationships. The data model is being implemented in a Version Server, under development at the University of California, Berkeley.

142 citations

References
More filters
Book•
01 Jan 1978

2,993 citations

Book•
01 Jun 1988
TL;DR: Some areas which require further study are described: the integration of the transaction concept with the notion of abstract data type, some techniques to allow transactions to be composed of sub- transactions, and handles which last for extremely long times.
Abstract: A transaction is a transformation of state which has the properties of atomicity (all or nothing), durability (effects survive failures) and consistency (a correct transformation). The transaction concept is key to the structuring of data management applications. The concept may have applicability to programming systems in general. This paper restates the transaction concepts and attempts to put several implementation approaches in perspective. It then describes some areas which require further study: (1) the integration of the transaction concept with the notion of abstract data type, (2) some techniques to allow transactions to be composed of sub- transactions, and (3) handling transactions which last for extremely long times (days or months).

759 citations

Proceedings Article•
01 Jan 1979
TL;DR: In this paper, the authors describe a mechanism that solves synchronization of accesses to shared data and recovering the state of such data in the case of failures in a decentralized system.
Abstract: Synchronization of accesses to shared data and recovering the state of such data in the case of failures are really two aspects of the same problem--implementing atomic actions on a related set of data items. In this paper a mechanism that solves both problems simultaneously in a way that is compatible with requirements of decentralized systems is described. In particular, the correct construction and execution of a new atomic action can be accomplished without knowledge of all other atomic actions in the system that might execute concurrently. Further, the mechanisms degrade gracefully if parts of the system fail: only those atomic actions that require resources in failed parts of the system are prevented from executing, and there is no single coordinator that can fail and bring down the whole system.

284 citations

Journal Article•DOI•
TL;DR: A mechanism that solves both problems of synchronization of accesses to shared data and recovering the state of such data in the case of failures simultaneously in a way that is compatible with requirements of decentralized systems is described.
Abstract: Synchronization of accesses to shared data and recovering the state of such data in the case of failures are really two aspects of the same problem--implementing atomic actions on a related set of data items. In this paper a mechanism that solves both problems simultaneously in a way that is compatible with requirements of decentralized systems is described. In particular, the correct construction and execution of a new atomic action can be accomplished without knowledge of all other atomic actions in the system that might execute concurrently. Further, the mechanisms degrade gracefully if parts of the system fail: only those atomic actions that require resources in failed parts of the system are prevented from executing, and there is no single coordinator that can fail and bring down the whole system.

275 citations

Proceedings Article•DOI•
Roger L. Haskin1, Raymond A. Lorie1•
02 Jun 1982
TL;DR: Additions to System R, a prototypical relational system, are introduced to satisfy demands: long fields, for storing non-coded data, and complex objects, which declare the semantic relationships among data items and provide a means for adequately supporting interactive access.
Abstract: Relational database systems are attracting great interest from potential users outside the traditional areas in which such systems have been employed. Features of modern relational systems such as powerful query facilities, data and device independence, concurrency control, and recovery are useful in applications such as engineering design, office automation, and graphics. However, such applications place demands on the system that it must be extended to handle. This paper identifies three of these demands: storing non-coded information of arbitrary length within the database, dealing with aggregate objects as a unit, and improving support for interactive access. Additions to System R, a prototypical relational system, are introduced to satisfy these demands: long fields, for storing non-coded data, and complex objects, which declare the semantic relationships among data items and provide a means for adequately supporting interactive access.

264 citations