Object-Oriented Database Management Systems


The construction of Object-Oriented Database Management Systems started in the
middle 80ís, at a prototype building level, and at the beginning of the 90ís
the first commercial systems appeared. The interest for the development of
such systems stems from the need to cover the modeling deficiencies of their
predecessors, that is the relational database management systems. They were
intended to be used by applications that have to handle big and complex data
such as Computer Aided Engineering, Computer Aided Design, and Office
Information Systems.

The area of the OODBMSs is characterized by three things. First, it lacks a
common data model. There is no common data model although many proposals can
be found in the literature. This is a more general problem of all the
object-oriented systems not only the database management systems. Since the
data model determines the database language of the system, which in turn
determines the implementation of the system, we can understand that the
differences between the various systems with different data models can be big
and substantial. Second is the common theoretical framework. Although there
is no standard object-oriented model, most object-oriented database systems
that are operational or under development today share a set of fundamental
object-oriented concepts. Therefore the implementation issues in OODBMSs that
arise due to these concepts are universal. The third characteristic is that of
experimental activity. Plenty of prototypes have been implemented and some !

of them became commercial products. There is really a need for applications to
handle very complex data and that is why the interest of people in building
such systems is so strong.

Although there is no consensus on what an OODBMS is and which are the features
that differentiate it from other systems, there has been a lot of effort for an
agreement on defining the formal characteristics that can stand as the set of
specification requirements for the construction of such a system. These should
also be used as the set of features that one has to check in order to find out
if a system is really an OODBMS. The features of the OODBMS can be divided as
follows:

* mandatory features: these are the features that one system should have in
order to deserve the title OODBMS.

* optional features: these are the features that if one system has, should
be considered better than another that does not have them, provided that
both have all the mandatory features.

* open choices: these are features that a designer of a system can choose if
and how to implement. They represent the degrees of freedom left to the
system designers.

An OODBMS should be a database management system and at the same time an object
oriented system. The first characteristic is translated to the following
features: persistence, concurrency, recovery, secondary storage management,
and ad hoc query mechanisms. The second characteristic is translated to the
following: composite objects, object-identity, encapsulation, inheritance
overriding and late binding, extensibility, and computational completeness of
the database language used.

Composite objects can be built recursively from simpler ones by applying
constructors to them. These simpler objects can be integers, characters,
strings, booleans, and in general objects of types that all the programming
languages possess. There are various constructors such as list, set, bag,
array, tuple, etc. The minimal set of constructors that a system must have is:
set (to represent unordered collections of real world objects), list (to
represent ordered collections of real world objects), tuple (to represent
properties of real world objects). A system that supports composite objects
and therefore constructors for their building, should also support operators
for the retrieval, insertion, and deletion of their component objects. That
means that the database language should be extended in a way that these
operators will be included.

The identity of an object is what makes it different from all the other
objects. This allows the objects to be independent of their values. Therefore
the notion of identical objects is introduced: two objects are equal if they
have the same values, but are identical if they have the same object identity.
The fact that each object possesses an identity facilitates the handling of
composite objects since it makes the common use of objects possible and it
protects the consistency of the database. If a component object is changed,
this change affects all the composite objects that reference it. Due to the
object identity, there is no need for replicates, and that is how the
consistency of the database is protected.

The mechanism of encapsulation allows the hiding of the internal state of the
objects. The internal state of an object is not liable