body

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 to direct access. It
can only be accessed by
its methods. Objects that
have this ability are called
encapsulated objects.
There are many types of
encapsulation including:
full, write, and partial.
Using full encapsulation, all
the operations on objects
are done via message
sending and method
execution. In write
encapsulation, the internal
state of the objects is
visible only for reading
operations. Partial
encapsulation involves
allowing direct access for
reading and writing for
only a part of the internal
state (private and public
part). The use of the same
message for different
methods that belong to
different classes can
facilitate the design of the
database as well as of the
applications that access it.

In general, since the
internal structure of an
object is not visible by the
other objects, we can
assign to methods with the
same functionality the
same message even if their
implementation is different.
This is called overloading
of the message. Since a
message can correspond
to more than one method,
the code of the method
that has to be executed
can only be found at run
time. That