Databases Reference
In-Depth Information
and errors will multiply with applications using the software. Moreover, bugs
introduced to internal subsystems of a DBMS, such as index structures, can
easily corrupt not only the DBMS process but also the DB. Thus, methods
and tools that guide and assist the design, implementation, and evaluation
(or at least testing) of new components are of paramount importance. That is
particularly true whenever users (not only vendors) are allowed to add com-
ponents. An example for this type of tool support is the DataBlade Develop-
ers Kit by Informix [25].
12.6
Related Work: The Roots of CDBMSs
This section reviews the roots of component DB systems. In a nutshell, those
roots are relational DB systems, object-orientation in general and object-
oriented DBMSs in particular, and extensible DB systems.
In the mid-1970s, companies like IBM (with System R [13] and later
DB2), Oracle, and Ingres started to build relational DBMSs. The success of
those systems (i.e., the relational model and SQL, the transaction concept)
for mission-critical applications in enterprises led to the desire for DB
support in further areas, for which relational DBMSs were originally neither
intended nor adequate.
Object-oriented DB systems [2, 3] were developed starting in the mid-
1980s, with the objective of integrating into the data model object-oriented
features such as object identity, specialization and inheritance, and classes,
including class-specific behavior (methods). Thus, many enhancements like
user-defined types and functions that recently have been made available in
relational DBMSs have been supported in OODBMSs from the very begin-
ning. Concepts like inheritance and complex objects are crucial for powerful
extension mechanisms and component models; thus all component DBMSs
surveyed in this chapter use object-oriented (DBMS) features to at least some
degree.
Extensible DB systems [5568] all attempted to ease the construction
of DBMSs [69] by exploiting some kind of software reusability. They pro-
posed a general core that could be customized or extended in some way
by users or even to generate some DBMS parts. Hence, they shared the
aims of component DBMSs. Several of the techniques proposed for extensi-
ble DBMSs (such as extensible query optimization [70] and user-definable
types [66]) are now used in CDBMSs. However, many still open problems
render the construction of entire, full-fledged DBMSs based on reuse
impracticable.
