Modeling concepts for VLSI CAD objects
ACM Transactions on Database Systems (TODS)
Modeling the storage architectures of commercial database systems
ACM Transactions on Database Systems (TODS)
Panel: Extensible database systems
SIGMOD '86 Proceedings of the 1986 ACM SIGMOD international conference on Management of data
SIGMOD '86 Proceedings of the 1986 ACM SIGMOD international conference on Management of data
The functional data model and the data languages DAPLEX
ACM Transactions on Database Systems (TODS)
An implementation technique for database query languages
ACM Transactions on Database Systems (TODS)
A unifying model of physical databases
ACM Transactions on Database Systems (TODS)
Genesis: A Reconfigurable Database Management System
Genesis: A Reconfigurable Database Management System
Query processing in a multimedia document system
ACM Transactions on Information Systems (TOIS)
Extensible query processing in starburst
SIGMOD '89 Proceedings of the 1989 ACM SIGMOD international conference on Management of data
Encapsulation of parallelism in the Volcano query processing system
SIGMOD '90 Proceedings of the 1990 ACM SIGMOD international conference on Management of data
Extensions to Starburst: objects, types, functions, and rules
Communications of the ACM
Starburst Mid-Flight: As the Dust Clears
IEEE Transactions on Knowledge and Data Engineering
Supporting Flat Relations by a Nested Relational Kernel
VLDB '87 Proceedings of the 13th International Conference on Very Large Data Bases
Of Objects and Databases: A Decade of Turmoil
VLDB '96 Proceedings of the 22th International Conference on Very Large Data Bases
Extensions to Starburst: objects, types, functions and rules
CASCON First Decade High Impact Papers
Hi-index | 0.02 |
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.