GENESIS: a project to develop an extensible database management system

  • Authors:
  • D. S. Batory

  • Affiliations:
  • Department of Computer Sciences, The University of Texas at Austin, Austin, Texas

  • Venue:
  • OODS '86 Proceedings on the 1986 international workshop on Object-oriented database systems
  • Year:
  • 1986

Quantified Score

Hi-index 0.02

Visualization

Abstract

Existing database management systems are tailored to traditional business applications. Since 1980, a variety of new database applications have arisen: VLSI CAD, graphics, and statistical databases are examples. These new applications cannot be handled easily or efficiently by available DBMSs because their requirements are so unusual. In particular, they demand special-purpose data types and operators, and require novel storage structures and new query processing techniques. The idea that a single DBMS can handle all database tasks equally well is no longer practical. Customized database systems are needed.Two approaches are currently taken to customize a DBMS. Either a system is built from scratch, or an existing system is modified. However, neither approach is cost effective as it takes many man-years of effort and hundreds of thousands of dollars to produce an operational system.Recently, a number of researchers have independently conceived the idea of extensible or reconfigurable DBMSs ([Car85], [Day85], [Sto86], [Bat86a]). These systems are modular, they are essentially software busses where modules with desired DBMS capabilities can be plugged or unplugged in a matter of hours or days at virtually no cost to produce a customized DBMS. The idea of extensible DBMSs is a powerful concept, and is certainly a more attractive approach to DBMS customization than current methods. Features that can be customized in DBMSs can be broadly categorized as being logical front-end or physical back-end. At the logical front-end of a DBMS, it should be possible to introduce new object types and new operators. For example, conventional relational DBMSs provide only integer, float, and string data types. Nontraditional applications require novel data types, such as polygons and time-series. It should be possible to support new abstraction concepts, such as molecular objects and versions which are useful in the context of VLSI CAD data ([Bat85a]). Also, it should be possible to express and process recursive queries and rules. At the physical back-end of a DBMS, it should be possible to admit new storage structures, new concurrency control and recovery algorithms, and new query optimization algorithms. These are just some of the more important examples.GENESIS is an extensible database management system that is being developed to address the needs of nontraditional applications. Our approach to developing GENESIS software is based on three principles. First, we are using theoretical models of logical and physical database organization to help identify the software atoms of database management systems. That is, we are taking a building blocks approach to DBMS construction: by composing different atoms (modules) in different ways, we can quickly construct different (i.e., customized) DBMSs. There are several important advantages to this approach. Software atoms (modules) can be written and debugged separately rather than the common approach to write and debug compositions of many atoms simultaneously. In this way, software development is simplified. Also, our approach provides the means for fast technology transfer. If a new file structure or database algorithm is invented, it is a matter of writing the software atom (module) that encodes this file structure or algorithm. The atom could then be used immediately in the construction of DBMSs.Second, all software atoms are plug compatible. That is, all modules that implement DBMS primitives have the same interface. This makes module composition trivial.Third, all software atoms are reusable. Many DBMSs use exactly the same software atoms, which means that many algorithms have been reinvented over and over again at an enormous cost. Our approach attempts to minimize technology reinvention by writing atoms once and reusing them.It turns out that the techniques that are needed to achieve logical database extensibility and physical database extensibility are rather different. We are using a functional data model and data language as the logical front-end to GENESIS ([Shi81], [Bun82]). The functional approach is well-suited for extensible database systems as it is open-ended: new object types and operators can be added easily. A description of the GENESIS data model and data language, the techniques that are being used for its implementation, and how the data language is being used to express and process queries on non1NF relational databases is given in [Bat86b].The physical back-end of GENESIS is based on the Unifying Model ([Bat82]) and Transformation Model ([Bat85b]). These models explain how complicated storage structures that are used in commercial database management systems are actually are combinations of primitive file structures, linkset structures, and conceptual-to-internal mappings. A description of the implementation of the physical back-end of GENESIS is given in [Bat86c].We are using object-based models as a means for unifying database research with techniques in software engineering.