2. What are Object Oriented Databases?
Object-oriented databases (OODBs) represent the latest generation of
database systems technology. Research and development of OODBs has been
driven largely by the high-performance data storage and access
requirements of design support environments, such as Computer Aided
Design (CAD) and Computer-Aided Software Engineering (CASE) systems.
Atkinson et al. [4] and Zdonik and Maier [5] propose definitions of
object oriented database systems in terms of their mandatory
features, which we can divide into object-oriented features and
database features, as summarised below.
2.1 Object-oriented features
These features are essentially those of object-oriented programming
languages such as C++ and SmallTalk, but they are not generally found in
relational database management systems (RDBMS). The three most important
of these are:
- complex objects:
Complex objects can be built up from simpler ones by applying
set, tuple and list constructors which represent
collections, attributes and relations, and order.
- object identity:
An object in the database should have an identity independent of its
value, so that there is a useful equality distinction between two
identical objects which point to exactly the same data structure in
memory and two objects which are merely similar in that their types
and elements are equal. This provides for object sharing, i.e.
objects can share a single element and updates to that element will
be reflected in each object automatically.
- encapsulation:
An object has a visible external interface that is independent of
its hidden internal implementation. Only those operations
specified in the interface can be performed on the object by
applications. The implementation part includes both attributes
representing the state of the object, and procedures which describe each
operation.
Less central to the OODB concept according to Zdonik and Maier, but
still seen as mandatory by Atkinson et al. are the following features:
- types or classes:
Object types (found in C++) and classes (found in SmallTalk)
both summarise the common features of a set of objects with the same
characteristics, but they are employed in different ways. Types are not
objects themselves, and are used primarily to ensure program correctness
at compile time by allowing the user to declare the representation of
variables and expressions the program manipulates. Classes on the other
hand are objects, and are used at run-time to create new objects
(instances), for example by applying a new operator to the class.
Note that the type/class distinction corresponds to the difference
between static and dynamic data typing in procedure-oriented
programming languages such as C (static) and Lisp (dynamic), but these
do not have the added benefit of encapsulation.
- type or class hierarchies and inheritance:
Inheritance provides a means of avoiding the explicit and repeated
storage of data which can be inferred, and helps code reusability. When
two types t1 and t2 have features (attributes and
operations) in common, those features can be abstracted out into a
single subsuming type T, with t1 and t2 being declared
as subtypes of T so that they automatically gain the common
features without each having to respecify them.
- overriding, overloading and late binding:
It may be desirable for a type t to inherit certain attributes or
operations of type T, but not others which are under-specified or
otherwise inappropriate. In this case t can override the
features by defining its own local features with same name.
Having two or more types use the same name for related but distinct
attributes or operations is called overloading the name. The
system can select the appropriate binding for the name at run-time by
examining type of the object to which it is being applied (this is
called late binding).
- extensibility:
Applications can add to the set of types or classes built into the
OODB, and new types or classes must have the same status and usage
as predefined ones.
- computational completeness:
Either the database description and manipulation language should
itself be able to express any computable function (not the case for
the RDBMS query language SQL, for example), or it should provide an
application programmer's interface (API) to a standard programming
language.
2.2 Database features
These are the essential features of databases in general, including
RDBMS, which are not generally found in programming languages, whether
object-oriented or not.
- persistance:
The data manipulated by an application, whatever its type, should
survive beyond the execution of the process which runs it and be
available for re-use in subsequent processes. This should happen
implicitly - save and load operations etc. should not be
required.
- efficient secondary storage management:
Mechanisms should be provided for fast and efficient manipulation of
very large databases. Allocation of disk storage and transfer of
data to and from main memory should be invisible to the application.
- concurrency:
Multiple users should be able to work concurrently on a database,
viewing and updating shared data without affecting its integrity. The
system should lock objects when they are read or written to
prevent simultaneous access, and execute atomic operation
sequences which cannot be interrupted leaving the database partially
updated.
- recovery:
In the event of disk, processor or software failure, the OODB should
be able to restore the data to a coherent state.
- ad hoc query language:
The system should provide the functionality of an efficient,
high-level, application-independent, declarative ad hoc query
language. This does not necessarily mean it should provide a textual
query language per se; a graphic browser with equivalent access
facilities is just as good. The internal data manipulation language
could also be made available for this job.
Using OODBs in PLINTH...