Data Modeling Object Oriented Data Model Encyclopaedia of Information Systems, Academic Press Vaz

PROOF

Data Modeling—Object-Oriented Data Model

Michalis Vazirgiannis

Athens University of Economics and Business

Encyclopedia of Information Systems, Volume One

55-1

I. INTRODUCTION

II. MOTIVATION AND THEORY

III. INDUSTRIAL SYSTEMS—STANDARDS

IV. CONCLUSION—RESEARCH ISSUES AND PERSPECTIVES

V. CASE STUDY: OBJECT RELATIONAL SOLUTIONS FOR

MULTIMEDIA DATABASES

GLOSSARY

data model In data modeling we try to organize data

so that they represent as closely as possible a real
world situation, yet representation in computers is
still feasible. A data model encapsulates
three elements: objects’ structure, behavior and in-
tegrity constraints.

encapsulation A property of the object oriented model, promoting data and operation indepen-

dence. This is achieved by hiding the internal struc-
ture and implementation details from the external
world simplifying thus the maintenance and usage
of a multitude of object classes in an application.

inheritance The ability of one class to inherit the

structure and behavior of its ancestor. Inheritance
allows an object to inherit a certain set of attributes
from another object while allowing the addition of
specific features.

object-oriented modeling It is an abstraction of the real

world that represents objects’ structural content and
behavior in terms of classes’ hierarchies. The struc-
tural content is defined as a set of attributes and at-
tached values and the behavior as a set of methods
(functions that implement object’s behavior).

polymorphism The ability of different objects in a

class hierarchy to have different behaviors in re-
sponse to the same message. Polymorphism derives
its meaning from the Greek for “many forms.” A
single behavior can generate entirely different re-
sponses from objects in the same group. Within

the framework of the program, the internal mech-
anism determines what specific name of different
purposes is known as function overloading.

relational model A data modeling approach having

found very successful industrial implementations
in DBMS. The fundamental modeling constructs
are the relations consisting of tuples of values each
one taking its semantics from an appropriate at-
tribute. The relations represent entities of the real
world and relationships among entities.

I. INTRODUCTION

A. Need for Data Modeling

The word “datum” comes from Latin and, literally in-
terpreted, means a fact. However, data do not always
correspond to concrete or actual facts. They may be
imprecise or may describe things that have never hap-
pened (e.g., an idea).

Data will be of interest to us if they are worth not only
thinking about, but also worth recording in a
precise manner.

Many different ways of organizing data exist.

For data to be useful in providing information,they
need to be organized so that they
can be processed effectively. In data modeling we try to
organize data so that they represent as closely as possi-
ble a real world situation, yet are still represetation in
computers is still feasible. These two requirements are

9902.ch55 2/5/02 2:28 PM Page 1

PROOF

frequently conflicting. The optimal way to organize
data for a given application can be determined by un-
derstanding the characteristics of data that are im-
portant for capturing their meaning. These charac-
teristics allow us to make general statements about
how data are organized and processed.

It is evident that an interpretation of the world is

needed, sufficiently abstract to allow minor
perturbations, yet sufficiently powerful to give some
understanding concerning how data about the world
are related. An intellectual tool that provides such an
interpretation will be referred to as a data
model. It is a model about data by which a reasonable
interpretation of the data can be obtained. A data
model is an abstraction device that allows us to focus
on theinformation content of the data as op-
posed to individual values of the data).

B. Historical Overview: First and
Second Database Model Generations

Informaton
system demands more and more services
from information stored in computing systems. Gradu-
ally, the focus of computing, shifted from process-oriented

to data-oriented systems, where data play an important
role for software engineers. Today, many design prob-
lems center in data modeling and structuring.

After the initial file systems in

the 1960s and early 1970s, the first generation
of database products was born. Database sys-
tems can be considered as intermediaries between
physical devices where data are stored and the users
(humans) of the data. Database management systems
(DBMS) are the software tools that enable the man-
agement (definition, creation, maintenance, and use)
of large amounts of interrelated data stored in
computer-accessible media. The early DBMSs, which
were based on hierarchical and network (Codasyl)
models, provided logical organization of data in trees
and graphs. IBM’s IMS, General Electric’s IDS, Uni-
vac’s DMS 110, Cincom’s Total, MRI’s System 200, and
Cullinet’s (now Computer Associates) IDMS are some
of the well-known representatives of this generation.
Although efficient, these systems used proce-
dural languages and did not offer physical or logical
independence, thus limiting its flexibility. In
spite of that, DBMSs were an important advance com-
pared to the file systems.

IBM’s addition of data communication facilities to

its IMS software gave rise to the first large-scale data-
base/data communication (DB/DC) system, in which
many users access the DB through a communication
network. Since then, access to DBs through commu-
nication networks has been offered by commercially
available DBMSs.

C.W. Bachman played a pioneering role in the de-

velopment of network DB systems (IDS product and
Codasyl DataBase Task Group, or DBTG, proposals).
The DBTG model is based on the data structure dia-
grams, which are also known as Bachman’s diagrams.
In the model, the links between record types, called
Codasyl sets, are always one occurrence of one record
type. To many, that is, a functional link. In its 1978
specifications, Codasyl also proposed a data definition
language (DDL) at three levels (schema DDL, sub-
schema DDL, and internal DDL) and a procedural
(prescriptive) data manipulation language (DML).

In 1969–1970, Dr. E. F. Codd proposed the rela-

tional model, which was considered an “elegant math-
ematical theory” without many possibilities of effi-
cient implementation in commercial products. In
1970, few people imagined that, in the 1980s, the re-
lational model would become mandatory (a “decoy”)
for the promotion of DBMSs. Relational products like
Oracle, DB2, Ingres, Informix, Sybase, etc., are con-
sidered the second generation of DBs. These prod-
ucts have more physical and logical independence,
greater flexibility, and declarative query languages
(users indicate what they want without describing how
to get it) that deal with sets of records, and they can
be automatically optimized, although their DML and
host language are not integrated. With relational
DBMSs (RDBMSs), organizations have more facilities
for data distribution. RDBMSs provide not only better
usability but also a more solid theoretical foundation.

Unlike network models, the relational model is

value-oriented and does not support object identity.
Needless to mention, there is an important trade-off
between object identity and declarative features. As a
result of Codasyl DBTG and IMS support object iden-
tity, some authors introduced them in the object-
oriented DB class.

The initial relational systems, suffered from

performance problems. While nowadays these
products have achieved wide acceptance,
it must be recognized
that they are not exempt from difficulties.
Perhaps one of the greatest demands on
RDBMSs is the support of complex data
types; also, null values, recursive queries, and scarce
support for integrity rules and for domains (or ab-

55-2

Data Modeling—Object-Oriented Data Model

9902.ch55 2/5/02 2:28 PM Page 2

Au: unclear

PROOF

stract data types) are now other weaknesses of rela-
tional systems. Some of those problems are solved in
the recent version of Structured Query Language
(SQL), SQL: 1999 (previously SQL3).

In the 1970s, debate emerged on the relative mer-

its of Codasyl and relational models. It resutled in
pare both classes of models and to obtain a better un-
derstanding of their strengths and weaknesses.

During the late 1970s and in the 1980s, research

work (and, later, industrial applications) focused on
query optimization, high-level languages, the normal-
ization theory, physical structures for stored relations,
bugger and memory management algorithms, index-
ing techniques (variations of B-tress), distributed sys-
tems, data dictionaries, transaction management, and
so on. That work allowed efficient and secure on-line
transactional processing (OLTP) environments (in
the first DB generation, DBMSs were oriented toward
batch processing). In the 1980s, the SQL language
was also standardized (SQL/ANS 86 was approved by
the American National Standard Institute, ANSI and
the International Standard Organization, ISO in
1986), and today, every RDBMS offers SQL.

Many of the DB technology advances at that time

were founded on two elements: reference models and
data models. ISO and ANSI proposals on reference
models have positively influenced not only theoretical
researches but also practical applications, especially in
DB development methodologies. In most of those ref-
erence models, two main concepts can be found; the
well-known three-level architecture (external, logical,
and internal layers), also proposed by Codasyl in 1978,
and the recursive data description. The separation be-
tween logical description of data and physical imple-
mentation (data application independence) devices
was always an important objective in DB evolution,
and the three-level architecture, together with the re-
lational data model, was a major step in that direction.

In terms of data models, the relational model has

influenced research agendas for many years and is
supported by most of the current products. Recently,
other DBMSs have appeared that implement other
models, most of which are based on object-oriented
principles.

Three key factors can be identified in the evolution

of DBs: theoretical basis (resulting from researcher’s
work), products (developed by vendors), and practi-
cal applications (requested by users). These three fac-
tors have been present throughout the history of DB,
but the equilibrium among them has changed. What
began as a product technology demanded by users’
needs have always influenced the evolution of DB
technology, but especially so in the last decade.

Today, we are witnessing an extraordinary develop-

ment of DB technology. Areas that were exclusive of
research laboratories and centers are appearing in
DBMSs’ latest releases: World Wide Web, multimedia,
active, object-oriented, secure, temporal, parallel, and
multidimensional DBs. The need for exploiting the
Object-Oriented Model for such complex systems is
apparent.

II. MOTIVATION AND THEORY

A. Motivation

Although one might think that DB technology has
reached its maturity, the new DB generation has
demonstrated that we still ignore the solutions to
some of the problems of the new millennium. In spite
of the success of this technology, different “preoccu-
pation signals” must be taken into account. We iden-
tify the following architectural issues that need to be
solved in the light of new application domains:

• Current DBMSs are monolithic; they offer all

kinds of services and functionalities in a single
“package,” regardless of the users’ needs, at a very
high cost, and with a loss of efficiency

• About half of the production data are in legacy

systems

• Workflow management (WFM) systems are not

based on DB technology; they simply access DBs
though application programming interfaces (APIs)

• Replication services do not scale well over 10,000

nodes

• Integration of strictly structured data with loosely

structured data (e.g., data from a relational DB
with data from electronic mail)

On the other hand there is wealth of new application
domains that produce huge amounts of data and
therefore call for database support. Such domains are
computer-aided design (CAD), computer-aided soft-
ware engineering (CASE), office-automation, multi-
media databases, geographic information systems
(GIS), scientific experiments, telecommunications, etc.

These application domains present some impor-

tant common characteristics that make their database
support by traditional relational systems problematic.
Such features include:

• Hierarchical data structures (complex objects)
• New data types for storing images or large textual

items

Data Modeling—Object-Oriented Data Model

55-3

9902.ch55 2/5/02 2:28 PM Page 3

PROOF

• No general-purpose data structure available
• Nonstandard application-specific operations
• Dynamic changes
• Cooperative design process among designers
• Large number of types
• Small number of instances
• Longer duration transactions

The database technology has to respond to these chal-
lenges in a way that the above requirements are ad-
dressed as database technology design features. In the
sequel we identify the shortcomings of current data-
base technology in the context of the new applications:

• Poor representation of “real-world” entities, need

to decompose objects over relations

• Fixed build-in types; no set-valued attributes are

supported, thus complex and highly nested
objects cannot be represented efficiently

• Semantic overloading
• Poor support for integrity and enterprise

constraints

• No data abstraction such as aggregation and

generalization, thus inheritance and specialization
cannot be addressed

• Limited operations
• Difficulty handling recursive queries
• No adequate version control is supported

B. Object-Oriented Model

1. Historical Preview of
Object-Oriented Databases

Before we proceed with our discussion of data mod-
eling, it is necessary to define, even if only approxi-
mately, the elementary objects that will be modeled
(i.e., what a datum is). Suppose that we accept as a
working definition of an atomic piece of data the tu-
ple <object name, object property value, time>. After all, a
phenomenon or idea usually refers to an object (ob-
ject name) and to some aspect of the object (object prop-
erty), which is captured by a value (property value) at a
certain time (time).

Of these four aspects of data, time is perhaps the

most cumbersome aspect of data modeling. There-
fore, many data models completely drop the notion
of time and replace it either with other kinds of ex-
plicit properties or with orderings among objects. The
issues of Object-Oriented (OO) Models, object
structure–object Classes will be treated as the basis of

an object-oriented database management system
(OODBMS). Furthermore such a system must sup-
port Inheritance (single–multiple) and handle object
identity issues. Then OO languages providing persis-
tency (persistence by class, creation, marking, refer-
ence) are necessary so that users of an OODBMS are
able to define and manipulate database objects.

2. Object-Oriented Modeling
and Programming Concepts

Hereafter an overview of object-oriented concepts will
be presented. Object orientation has its origins in
object-oriented programming languages (OOPLS).
The “class” concept is introduced by SIMULA, where
as abstract data types encapsulation, message passing,
and inheritance features are further introduced by
the pioneering SMALLTALK. Another language of
this family is C that integrates the strengths of C
with object-oriented concepts. The newest OO lan-
guage is Java, inherently object-oriented providing a
wide selection of classes for different tasks (i.e., visu-
alization, network and task management, persistent
features). Its portability across platforms and operat-
ing systems made it a very attractive development en-
vironment, widely used and with important impact on
programming large-scale applications.

An object has an inherent state followed by its be-

havior, which defines the way the object treats its state
as well the communication protocol between the ob-
ject and the xternal world. We have to differentiate
between the transient objects in OOPLs and the
persistent objects—in object-oriented databases
(OODBs). In the first case the objects are eliminated
from the main memory as soon as they are not needed
whereas in the case of OODBMSs objects are persis-
tently stored and other mechanisms such as indexing,
concurrency, control, and recovery are available.
OODBMSs usually offer interfaces with one or more
OOPLs.

The three features that differentiate an object from

a relational tuple are

1. Object identity, a unique identifier generated

with the object creation and follows it throughout
its life cycle

2. Encapsulation features (promoting data and

operation independence), since the internal
structure and implementation details are not
accessible from the external world simplifying
thus the maintenance and usage of a multitude
of object classes in an application

55-4

Data Modeling—Object-Oriented Data Model

9902.ch55 2/5/02 2:28 PM Page 4

PROOF

3. Operator polymorphism and overloading, allowing

different behaviors to be grouped under the same
method and operator names; this facilitates design
and evolution of large sets of classes

Here after these features are further analyzed.

a. O

BJECT

DENTITY

, O

BJECT

TRUCTURE

AND

YPE

ONSTRUCTORS

The object identity (OID) is generated by the sys-

tem when a new object is created and is unique and
immutable. Each OID is used only once and is invisi-
ble to the users.

An OODBMS offers a set of type constructors that

are used to define the data structures for an OO data-
base schema. The basic constructors offered created
atomic values (atom (integer, string, float, etc.), tu-
ples, and sets of objects. Other constructors create
lists, bags, and arrays of objects. It is also feasible to
have attributes that refer to other objects called ref-
erences—OID.

An object has an internal structure defined by a

triple (OID, type constructor, state). For instance, as-
sume an object o (i

, tuple, <manager: i

, start-date:

>). An object can be represented as a graph struc-

ture that can be constructed by recursively applying
the type constructors. Assume the following example:

In this example the types Employee, Date, and De-

partment are defined. As the object structures are po-
tentially complex the issue of object equality becomes
interesting. Object equality is a concept that can be
viewed from two aspects: deep and shallow.

• Two objects are said to have identical states (deep

equality) if the graphs representing their states
are identical in every respect, including the OIDs
at every level.

• Two objects have equal states (shallow equality) if

the graph structures are the same and all the
corresponding atomic values in the graphs are
also the same. However, some corresponding
internal nodes in the two graphs may have objects
with different OIDs.

b. E

NCAPSULATION

An important feature in the domain of OODBs is

the encapsulation that offers an abstraction mecha-
nism and contributes in information hiding since an
object encapsulates both data and functions into a
self-contained package. Thus the external aspects of
an object are separated from its internal details. The
external users of the object are only made aware of
the interface of the object type, i.e., name and pa-
rameters of each operation, also called signature.

The functionality of an object is implemented by a

set of methods and messages. A method consists of a
name and a body that perform the behavior associ-
ated with the method name, whereas a message is sim-
ply a request from one object to another object ask-
ing the second object to execute one of its methods.

In the context of database applications dealing with

objects we distinguish between visible attributes, imple-
mented by external operators or query language pred-
icates or hidden attributes which are referenced only
through predefined operations. Assume the example:

Data Modeling—Object-Oriented Data Model

55-5

Example 1

Object identities (OIDs).

Define class Employee;

type tuple ( ...)

operations

age:

integer;

create_emp:

Employee

destroy_emp: boolean;

end Employee;

is a reference to an Employee object, we can in-

voke an operation such as age by writing

d.age.

course the main issue in OODBs is to have a mechanism

9902.ch55 2/5/02 2:28 PM Page 5

Au: OK as set ?

PROOF

that makes the objects persistent, i.e., stored safely in
the secondary storage at appropriate times. The mech-
anisms for making an object persistent are called nam-
ing and reachability. The naming mechanism involves
giving an object a unique persistent name through
which it can be retrieved by this and other programs.
The following example illustrates this concept:

In other cases it is desirable that a type inherits

only part of structure and/or behavior of the a su-
pertype. This is the case of selective inheritance. The
EXCEPT clause may be used to list the functions in a
supertype that are not to be inherited by the subtype.

d. P

OLYMORPHISM

The term polymorphism integrates the various cases

where, during inheritance, redefinition of structure or
behavior is necessary. Polymorphism implies operator
overloading where the same operator name or symbol
is bound to two or more different implementations of
the operator, depending on the type of objects to
which the operator is applied. For instance the func-
tion Area should be overloaded by different imple-
mentations in the

Geometry_Object

example.

The process of selecting the appropriate method

based on an object’s type is called binding. In strongly
typed systems, this can be done at compile time. This
is termed early (static) binding.

On the other hand binding can take place at run-

time, in this case called dynamic binding. An exam-
ple follows:

template <type T>

T max(x:T, y:T) {

if (x > y) return x;

else

return y;

}

The actual methods are instantiated as follows:

int max(int, int);

real max(real, real);

If the determination of an object’s type can be de-
ferred until runtime (rather than compile time), the
selection is called dynamic binding.

e. C

OMPLEX

BJECTS

A complex object, an important concept in the

object-oriented approach, is an item that is perceived
as a single object in the real world, but combines with
other objects in a set of complex a-part-of relation-
ships.

We distinguish two categories of complex objects:

unstructured and structured ones. The unstructured
complex objects contain bitmap images, long text strings;
they are known as binary large objects (BLOBs),
OODBMSs provide the capability to directly process
selection conditions and other operations based on
values of these objects.

Such objects are defined by new abstract data types

and the user provides the pattern recognition pro-
gram to map the object attributes to the raw data.

55-6

Data Modeling—Object-Oriented Data Model

define class DepartmentSet:

type ...

operations ...

...

end DepartmentSet;

...

persistent name AllDepartments:

DepartmentSet;

...

d := create_dept;

PERSON: Name, Address, Birthdate,

Age, SSN

EMPLOYEE subtype-of PERSON: Salary,

HireDate, Seniority

STUDENT subtype-of PERSON: Major,

GPA

c. T

YPE

IERARCHIES AND

NHERITANCE

A type can be defined by giving it a type name and

then listing the names of its public functions. Then it
is possible to define subtypes emanating from the ba-
sic types. For example:

Each subtype inherits the structure and behavior

of its ancestor. It is also possible to redefine (over-
ride) an inherited property or method.

In some cases it is necessary to create a class that

inherits from more than one superclass. This is the
case of multiple inheritance which occurs when a cer-
tain subtype T is a subtype of two (or more) types and
hence inherits the functions of both supertypes. This
leads to the creation of a type lattice. In several cases
if the lattice grows integrity and ambiguity problems
may arise.

9902.ch55 2/5/02 2:28 PM Page 6

. / ?

New ¶ OK ?

PROOF

The second category, structured complex objects, im-

plies that the object’s structure is defined by repeated
application of the type constructors provided by the
OODBMS. Here we distinguish two types of reference
semantics: (1) ownership semantics (is-part-of; is-
component-of), and (2) is-associated-with relationship.
The idea is that OODBMSs constitute a “marriage” be-
tween the concepts of object-oriented programming
(OOP), such as inheritance, encapsulation, and poly-
morphism, and well-founded and industry level sup-
ported database capabilities (see Fig. 1).

Conclusively, the ideas that were worked out in the

OODBMS area have been concentrated and codified
by the Object-Oriented Database System Manifesto.
This is an effort toward standardization and promot-
ing ideas that should be part of an object-oriented
database system. The most important concepts from
this manifesto follow:

• An OODBMS should support complex objects.
• Object identity is an important part of an object

and must be supported.

• Encapsulation must be supported as an integral

part of the system.

• Types or classes must be supported along with

inheritance features, so that types or classes must
be able to inherit from their ancestors.

• Dynamic binding must be supported.
• The DML must be computationally complete and

the set of data types must be extensible. Moreover
The DBMS must provide a simple way of querying
data.

• Data persistence must be provided as a natural

feature of a database system.

• The DBMS must be capable of managing very

large databases.

• The DBMS must support concurrent users.
• The DBMS must be capable of recovery from

hardware and software failures.

Though these features are quite interesting and
promising, the impact on the database industry was
not as important as hoped. Instead the big database
industry tried to extend the well-established relational
technology by integrating some of the object-oriented
database concepts. This hybrid technology is known
as object relational. In the next section there is a re-
view of the main features of this technology.

Data Modeling—Object-Oriented Data Model

55-7

Figure 1

OODBMS is an amalgamation between OOP and traditional database concepts.

9902.ch55 2/5/02 2:28 PM Page 7

PROOF

C. The Object Relational Approach

Here we contrast and compare the relative strengths
and weaknesses of the relational and object-oriented
systems in order to motivate the need for object-
oriented modeling. The discussion will include user-
defined data types and set-based versus navigational
access to data. We also examine some simple model-
ing examples to illustrate the discussions.

1. A Quick Look at Relational
and Object-Oriented Databases

It is evident that the strengths of the relational para-
digm have revolutionized information technology. Re-
lational database technology was originally described
by E. F. Codd. Not long afterward, companies like
IBM and Oracle created very successful products. The
relational DB standard is published by ANSI, with the
current specification being X3H2 (SQL’92). The new
specification dealing with object extensibility has been
labeled X3H7. A relational DB stores data in one or
more tables or rows and columns. The rows corre-
spond to a record (tuple); the columns correspond to
attributes (fields in the record), with each column
having a data type like date, character, or number.
Commercial implementations currently support very
few data types. For example, character, string, time,
date, numbers (fixed and floating point), and cur-
rency describe the various options. Any attribute
(field) of a record can store only a single value.

Relational DBs enforce data integrity via relational

operations, and the data themselves are structures to
a simple model based on mathematical set theory. Re-
lationships are not explicit but rather implied by val-
ues in specific fields, for example, foreign keys in one
table that match those of records in a second table.
Many-to-many relationships typically require an inter-
mediate table that contains just the relationships. Re-
lational DBs offer simplicity in modifying table struc-
ture. For example, adding data columns to existing
tables or introducing entire tables remains an ex-
tremely simple operation. The beauty of relational
DBs continues to be in its simplicity. The process of
normalization establishes a succinct clarity to the man-
agement and organization of data in the DB. Redun-
dancies are eliminated and information retrieval its
governed by the associations created between primary
and foreign keys. Why store the same piece of infor-
mation in two or more places when a logical connec-
tion can be established to it in one place? Referential
integrity (RI) has also made an important contribu-
tion because it enables business rules to be controlled
through the use of constraints. The role of constraints

is to prevent the violation of data integrity and,
thereby, its normalization.

The origins of OODBs trace their beginnings to

the emergence of OOP in the 1970s. Technically, there
is no official standard for object DBs. The book The
Object Database Standard: ODMG-V2.0, under the
sponsorship of the Object Database Management
Group (ODMG) (http://www.odmg.com), describes
an industry-accepted de facto standard. Object DBMSs
emphasize objects, their relationships, and the stor-
age of those objects in the DB.

Designers of complex systems realized the limita-

tions of the relational paradigm when trying to model
complex systems. Characteristics of object DBs include
a data model that has object-oriented aspects like class,
with attributes, methods, and integrity constraints; they
also have OIDs for any persistent instantiation of
classes; they support encapsulation (data and meth-
ods), multiple inheritance, and abstract data types.

Object-oriented data types can be extended to sup-

port complex data such as multimedia by defining
new object classes that have operations to support the
new kinds of information.

The object-oriented modeling paradigm also sup-

ports inheritance, which allows incremental develop-
ment of solutions to complex problems by defining
new objects in terms of previously defined objects.
Polymorphism allows developers to define operations
for one object and then share the specification of the
operation with other objects. Objects incorporating
polymorphism also have the capability of extending
behaviors or operations to include specialized actions
or behaviors unique to a particular object. Dynamic
binding is used to determine at runtime which opera-
tions are actually executed and which are not. Object
DBs extend the functionality of object programming
languages like C or Java to provide full-
featured DB programming capability. The result is a
high level of congruence between the data model for
the application and the data model of the DB, result-
ing in less code, more natural data structures, and bet-
ter maintainability and greater reusability of code. All
of those capabilities deliver significant productivity ad-
vantages to DB application developers that differ sig-
nificantly from what is possible in the relational model.

2. Contrasting the Major Features of Pure
Relational and Object-Oriented Databases

In the relational DB, the query language is the means
to create, access, and update objects. In an object DB,
the primary interface for creating and modifying ob-
jects is directly via the object language (C, Java,
SMALLTALK) using the native language syntax even

55-8

Data Modeling—Object-Oriented Data Model

9902.ch55 2/5/02 2:28 PM Page 8

PROOF

though declarative queries are still possible. Addi-
tionally, every object in the system is automatically
given an OID that is unique and immutable during
the object’s life. One object can contain an OID that
logically references, or points to, another object.
Those references prove valuable when in the associa-
tion of objects with real-world entities, such as prod-
ucts, customers, or business processes; they also form
the basis of features such as bidirectional relation-
ships, versioning, composite objects, and distribution.
In most ODBMSs, the OIDs become physical (the log-
ical identifier is converted to pointers to specific mem-
ory addresses) once the data are loaded into memory
(cached) for use by the object-oriented application.
No such construct exists in the relational DB. In fact,
the addition of navigational access violates the very
principles of normalization because OIDs make no
reliance on keys.

To further explore the divergent nature of rela-

tional and object-oriented DBs, let us look more
closely at the drawbacks of each. Our discussion even-
tually leads us to the justification behind the object-
relational paradigm.

In the following we explore the specifics of what it

takes to define the object-relational paradigm. A first
issue is to enable object functionality in the relational
world. Two important aspects must be considered in
any definition of the object-relational paradigm. The
first is the logical design aspects of the architecture.
What data types will be supported? How will data be
accessed? The other aspect is the mapping of the log-
ical architecture to a physical implementation.

From a technological standpoint, certain capabili-

ties must be included in the list of logical capabilities,
or the DB will not qualify to the minimal require-
ments for being object-relational. Such capabilities
are behavior, collection types, encapsulation, inheri-
tance, and polymorphism.

a. B

EHAVIOR

A method, in the purely object-oriented paradigm,

is the incorporation of a specific behavior assigned to
an object or element. A method is a function of a par-
ticular class.

b. C

OLLECTION

YPES

An aggregate object is essentially a data-type defi-

nition that can be composed of many subtypes cou-
pled with behavior. In Oracle 8, for example, there
are two collection types: VARRAYs and nested tables.
VARRAYs are suitable when the subset of information
is static and the subset is small. A suitable implemen-
tation of a VARRAY might be in the same context
where a reference entity might be used. The contents

of reference entities remain relatively static and serve
to validate entries in the referencing table. For ex-
ample, a reference entity called MARKETS can be
created to store the valid set of areas where a com-
pany does business. In the same way, a VARRAY might
be substituted to perform the same reference and val-
idation. VARRAY constructs are stored inline. That
means the VARRAY structure and data are stores in
the same data block as the rest of the row as a RAW
data type. Although they bear some similarity to
PL/SQL tables, VARRAYSs are fixed size.

c. E

NCAPSULATION

Encapsulation is the definition of a class with data

members and functions. In other words, it is the mech-
anism that binds code and data together while pro-
tecting or hiding the encapsulation from outside of
the class. The actual implementation is hidden from
the user, who only sees the interface.

As an illustrative example, think of a plane engine.

You can open it and see that it is there, and the plane
pilot can start the ignition. The engine causes the
plane to move. Although you can see the motor, the
inner functions are hidden from your view. You can
appreciate the function that the motor performs with-
out ever knowing all the details of what occurs inside
or even how.

d. I

NHERITANCE

Inheritance is the ability of one class to inherit the

structure and behavior of its ancestor. Inheritance al-
lows an object to inherit a certain set of attributes
from another object while allowing the addition of
specific features.

e. P

OLYMORPHISM

Polymorphism is the ability of different objects in

a class hierarchy to have different behaviors in re-
sponse to the same message. Polymorphism derives its
meaning from the Greek for “many forms.” A single
behavior can generate entirely different responses
from objects in the same group. Within the frame-
work of the program, the internal mechanism deter-
mines specific names for different purposes and is
known as function overloading.

Data Modeling—Object-Oriented Data Model

55-9

9902.ch55 2/5/02 2:28 PM Page 9

sp / ?

PROOF

formance.

•

III. INDUSTRIAL SYSTEMS—STANDARDS

A. Standards—The Object
Model of the ODMG

ODMG was created at the initiative of a set of object
database vendors with the goal of defining and pro-
moting a portability standard for OODBs. It had eight
voting members (O2 Technology, Versant, Poet, Gem-
stone, Objectivity, Object Design, Uni SQL, IBEX), re-
viewing members (among which, CERN, Hewlett
Packard, Microsoft, Mitre, etc.), and academic mem-
bers (D. DeWitt, D. Maier, S. Zdonic, M. Carey,
E. Moss, and M. Solomon).

It provides the potential advantages of having stan-

dards: (1) portability, (2) interoperability, (3) com-
pares commercial products easily and consists of the
following modules:

1. Object model It describes the specific object model

supported by the ODMG system, being an
extension of the OMG(Object Management Group) model.

2. Object Definition Language (ODL) It is used to

specify the schema of an object database having a
specific schema with a C binding.

3. Object query Language (OQL) An SQL like language

that can be used as a stand-alone language for
interactive queries or embedded in a
programming language.

In the following we provide an overview of the ODMG
model. ODMG addresses objects and literals. An object
has both an OID and a state where a literal has only a
value but no OID. An object is described by four char-
acteristics: identifier, name, lifetime, and structure. On
the other hand, three types of literals are recognized:
atomic, collection, and structured. The notation of
ODMG uses the keyword “interface” in the place of the
keywords “type” and “class.” Below is an example:

interface Object {

...

boolean

same_as (...)

Object

copy ( );

void

deleted ( );

}

Interface Collection: Object {

...

boolean is_empty( );

...

};

o.same_as (p)

q = o.copy()

1. Built-In Interfaces
for Collection Objects

Any collection object inherits the basic Collection in-
terface. Given a collection object o, the

o.cardi-

nality()

operation returns the elements in the col-

lection.

O.insert_element(e)

and

o.remove_

element(e)

insert or remove an element from the

collection O. The ODMG object model uses excep-
tions for reporting errors or particular conditions.
For example, the

ElementNotfound

exception in

the Collection interface would be raised by the

o.re-

move_element(e)

operation if e is not an element

in the collection o. Collection objects are further spe-
cialized into Set, List, Array, and Dictionary.

2. Atomic (User-Defined) Objects

In the ODMG model, any user-defined object that is
not a collection object is called an atomic object. They
are specified using the keyword class in ODL. The
keyword Struct corresponds to the tuple constructor.
A relationship is a property that specifies that two ob-
jects in the database are related together. For exam-
ple,

work_for

relationship of Employee and

has_emps relationship

of Department, Inter-

faces, Classes, and Inheritance.

An interface is a specification of the abstract be-

havior of an object type, which specifies the operation
signatures. An interface is noninstantiable—that is,
one cannot create objects that correspond to an in-
terface definition.

A class is a specification of both the abstract be-

havior and abstract state of an object type, and is
instantiable.

Another object-oriented feature supported by

ODMG is inheritance, which is implemented by ex-
tends keyword.

The database designer can declare an extent for

any object type that is defined via a class declaration
and it contains all persistent objects of that class. Ex-
tents are also used to automatically enforce the
set/subset relationship between the extents of a su-
pertype and its subtype. A key consists of one or more

55-10

Data Modeling—Object-Oriented Data Model

9902.ch55 2/5/02 2:28 PM Page 10

Au: only 3
modules, not 5
as stated in text

Au: please define
OMG

PROOF

properties (attributes or relationships) whose values
are constrained to be unique for each object in the
extent.

3. The ODL

The ODL’s main use is to create object specifica-
tions—that is, classes and interfaces. The user can spec-
ify a database schema in ODL independently of any
programming language. Moreover it is feasible to use
the specific language bindings to specify how ODL
constructs that can be mapped to constructs in spe-
cific programming languages, such as C, Java,
SMALLTALK. There may be several possible map-
pings from an object schema diagram (or extended
entity relational schema diagram) into ODL classes.

The mapping method follows the following steps:

(1) the entity types are mapped into ODL classes, and
(2) inheritance is done using extends. Here we have
to stress that there is no direct way to support multi-
ple inheritance. Below is an example:

class Person extent persons

{

attribute struct Pname

...

};

Class Faculty extends Person ( extent

faculty )

{

attribute string rank;

....

};

The class Faculty extends the class Person which is in
turn an extension of class person. Therefore the leaf
class Faculty contains all the attributes of all the an-
cestor classes (person and Person).

In the following example we have two classes (Rec-

tangle, Circle) emanating from the same class

Geom-

etryObject

Interface GeometryObject

{

attribute ...

...

};

Class Rectangle : GeometryObject

{

attribute ...

...

};

Class Circle : GeometryObject

{

attribute ...

...

};

4. The OQL

The OQL is the query language proposed for the
ODMG object model in order to be able to query
OODBs. It is designed to work closely with the pro-
gramming languages for which an ODMG binding is
defined, such as C, SMALLTALK, and Java. It is
similar to SQL (the standard query language for rela-
tional databases) and the main difference is the han-
dling of path expressions related to the class frame-
work used. For example:

SELECT d.name

FROM d in departments

WHERE d.college = ‘Engineering’

This query results in the set of the names of the de-
partments on the Engineering college. The type of
the result is a bag of strings (i.e., duplicates allowed).
The query results have to involve in many cases path
expressions (i.e., the path from the root parent class
to the class required via inheritance links). The fol-
lowing example illustrates the use of path expressions
in OQL queries:

departments;

csdepartment;

csdepartment.chair;

csdepartment.has_faculty;

Csdepartment.has_faculty.rank ( x )

SELECT f.rank

FROM f in csdepartment.has_faculty;

Then we can write the following query to retrieve the
grade point average of all senior students majoring in
computer science, with the result ordered by gpa, and
within that by last and first name:

SELECT struct

(last_name:

s.name.lname, first_name:

s.name.fname, gpa: s.gpa)

FROM

s in csdepartment.

has_majors

WHERE

s.class = ‘senior’

ORDER BY

gpa DESC, last_name ASC,

first_name ASC;

Data Modeling—Object-Oriented Data Model

55-11

9902.ch55 2/5/02 2:28 PM Page 11

PROOF

Another facility provided is the specification of views
as named queries. For instance we can define the fol-
lowing view:

DEFINE has_minors(deptname) AS

SELECT s

FROM s in students

WHERE s.minors_in.dname = deptname;

Then a potential query searching for the students
that took as minor Computer Science the following
query can be formed:

Has_minors(‘Computer Science’);

QOL also provides aggregate functions, and quantifiers.
The following example query returns the number of
students that took as minor Computer Science:

count (s in has_minors(‘Computer

Science’));

avg (SELECT s.gpa

FROM s in students

WHERE s.major_in.dname = ‘Computer

Science’ and s.class = ‘senior’);

The following query illustrates the use of the “forall”
predicate. Are all computer science graduate students
advised by computer science faculty?

For all g in (

SELECT s

FROM s in grad_students

WHERE s.majors_in.dname =

‘Computer Science’)

: g.advisor in csdepartment.

has_faculty;

The following query illustrates the use of the “exists”
predicate. The query searches for any graduate com-
puter science major having a 4.0 gpa

exists g in (

SELECT s

FROM s in grad_students

WHERE s. majors_in.dname =

‘Computer Science’

AND g.gpa = 4) ;

5. Object Database Conceptual Design

An important issue that arises here is the conceptual
design of an object-oriented schema. Can we benefit
from the traditional design techniques applied in re-
lational databases? There are important differences
between conceptual design of object databases and
relational databases.

As regards relationships, object databases (ODB)

exploit object identifiers resulting in OID references
while a relational database system (RDB) references to
tuples by values or by externally specified/generated
foreign keys

Regarding inheritance, the ODB approach exploits

inheritance constructs such as derived (:) and EX-
TENDS, and this is a fundamental feature of the ap-
proach, whereas RDBs do not offer any built in sup-
port for inheritance. Of course object relational
systems and extended RDB systems are adding inher-
itance constructs.

An important issue for compatibility and reusabil-

ity of data is the mapping of an extended entity rela-
tionship (EER) schema to an ODB schema. The fol-
lowing steps have to be followed:

Step 1: Create an ODL class for each EER entity type

or subclass

Step 2: Add relationship properties or reference

attributes for each binary relationship into the ODL
classes that participate in the relationship

Step 3: Include appropriate operations for each class
Step 4: An ODL class that corresponds to a subclass in

the EER schema inherits the type and methods of
its superclass in the ODL schema

Step 5: Weak entity types can be mapped in the same

way as regular types

Step 6: Declare a class to represent the category and

define 1:1 relationships between the category and
each of its superclasses

Step 7: An n-ary relationship with degree n > 2 can be

mapped into a separate class, with appropriate
references to each participating class.

B. OO Systems: O2, Object Store, etc.

In this section we refer briefly to existing object-oriented
and object-relational database industrial approaches.

1. Example of ODBMS—O2 System

This system has historical importance as it was the
only European DBMS and one of the few OODBMSs.
Its architecture is based on a kernel, called O2En-
gine, and is responsible for much of the ODBMS func-
tionality. The implementation of O2Engine at the sys-
tem level is based on a client/server architecture.

At the functional level, three modules (storage

component, object manager, schema manager) im-
plement the functionality of the DBMS.

Data definition in O2 is carried out using pro-

gramming languages such as C or Java. Data ma-

55-12

Data Modeling—Object-Oriented Data Model

9902.ch55 2/5/02 2:28 PM Page 12

Au: OK as
set for best
fit / ?

. / ?

PROOF

nipulation in O2 is carried out in several ways. O2
supports OQL as both an ad hoc interactive query
language and as an embedded function in a language.
There are two alternative ways for using OQL queries.
For example:

Q1:

d_Bag<d_Ref<Department>>

engineering_depts;

departments ->query(engineering_depts,

‘’this.college = “Engineering’’ ‘’);

Q2:

d_Bag<d_String>

engineering_dept_names;

d_oql_Query q0(‘’select d.dname from

d in departments where

d.college = “Engineering” “);

d_oql_execute

(q0, engineering_dept_names);

Both queries (Q1and Q2) search for the names of the
departments of the college of Engineering.

2. Object Relational Systems—Complex
Types and Object Orientation

Object-relational DBs are the evolution of pure
object-oriented and relational DBs. The convergence
of those two disparate approaches came about as a re-
alization that there were inherent shortcomings in
the existing paradigms when considered individually.
Observers of information technology can still see the
debate that rages in the software community over the
ultimate character of object-relational DBs or object-
relational DBMSs (ORDBMS).

Industry experts are frequently critical of object-

relational DBs because they usually demonstrate a
limited or nonexistent ability to perform certain rela-
tional or object-oriented tasks in comparison to their
pure counterparts. A case in point would be the lim-
ited support for inheritance in object-relational DBs,
a feature fully supported in the object-oriented para-
digm. Others argue that inheritance is of such limited
consequence when employed in the storage of data
and datacentric objects that its pursuit is a waste of ef-
fort. Each point of view is almost always driven by the
particular background of the individual presenting
the criticism. Because the object-relational paradigm
is a compromise of two very different architectures,
the most effective definition of its ultimate character
will be devised by those who have an unbiased appre-
ciation for relational and object-oriented systems
alike.

An issue to be tackled can be the question whether

ORDBMSs should begin with a relational foundation
with added object-orientation of the reverse. From a
conceptual level relational DBs have been far more
successful than their OODBMS counterparts. It
should not be any surprise then, that virtually all ma-
jor vendors are approaching the object-relational
arena by extending the functionality of existing rela-
tional DB engines. A case in point would be IBM, Or-
acle, and Informix, whose efforts to create a “univer-
sal server” began by extending their core relational
engines.

Anything that causes such controversy should be

worth the effort, which begs two important questions:
First, what factors have led to the development of
object-relational DBs? And second, what characterizes
an accurate definition of an object-relational DB? The
general answer to the first question is that developers
need a more robust means of dealing with complex
data elements without sacrificing the access speed for
which relational DBs have become known. To answer
the second question, there are several characteristics
that, as a minimum, must be included to achieve a
true object-relational structure. Those characteristics
are the following:

• Retrieval mechanism, that is, a query language

like SQL but one adapted to the extended
features of the ORDBMS, the retrieval mechanism
must include not only relational navigation but
also object-oriented navigational support

• Support for relational features like keys,

constraints, indexes, and so on

• Support for referential integrity as it is currently

supported by the relational paradigm

• Support for the object metamodel (classes, types,

methods, encapsulation, etc)

• The ability to support user-defined data types
• Support for the SQL3 ANSI standard

A well known extension requirement regards spatial
information. Oracle, Informix, and IBM DB2 offer ca-
pabilities for user-defined data types and functions
that are applied to them. All of them propose the
nested storage model, where a complex attribute is
stored in an attribute (they call it in-line). They claim
it is more efficient when queries regarding an object
reposed since self-join is avoided. This is a good ar-
gument for choosing this approach.

DB2 Spatial extender provides a comprehensive set

of spatial predicates, including comparison functions
(contains, cross, disjoint, equals, intersects etc.), rela-
tionship functions (common point, embedded point,

Data Modeling—Object-Oriented Data Model

55-13

9902.ch55 2/5/02 2:28 PM Page 13

PROOF

line cross, area intersect, interior intersect, etc.), com-
bination functions (difference, symmetric difference,
intersection, overlay, union, etc.), calculation func-
tions (area, boundary, centroid, distance, end point,
length, minimum distance, etc.) and transformation
functions (buffer, locatealong, locate between, con-
vexhull, etc.).

The Informix Dynamic Server with Universal Data

Option offers type extensibility. So-called DataBlade
modules may be used with the system, thus offering
new types and associated functions that may be used
in columns of database tables. The Informix Geodetic
DataBlade Module offers types for time instants and
intervals as well as spatial types for points, line seg-
ments, strings, rings, polygons, boxes, circles, ellipses,
and coordinate pairs.

Since 1996, the Oracle DBMS has offered a so-

called spatial data option, also termed “spatial car-
tridge,” that allows the user to better manage spatial
data. Current support encompasses geometric forms
such as points and point clusters, lines and line strings,
and polygons and complex polygons with holes.

IV. CONCLUSION—RESEARCH
ISSUES AND PERSPECTIVES

The presence of rich voluminous and complex data
sets and related application domains rises require-
ments for object oriented features in database sup-
port. Significant research has been devoted in this
area of integrating such object-oriented features in
database technology. Important effort has been com-
mitted to either as pure OODBMS or as extensions of
the relational approach (ORDBMSs).

The object-oriented model offers the advantageous

features regarding:

• Flexibility to handle requirements of new database

applications

• Complex objects and operations specification

capabilities

• OODBs are designed so they can be directly—or

seamlessly—integrated with software that is
developed using OOPLs

Nevertheless, there are several interesting issues

for further research in the context of object-oriented
and object relations database systems. Some of them
are:

• View definition and management on the

ODB/ORDB schema

• Querying the schema, in terms of class names,

attributes, and behavior features

• Optimization in several levels such as path

expression queries, storage, and retrieval issues

• Access mechanisms, indexing, and hashing

techniques specialized for object-oriented and
object relations databases

• Dynamic issues such as schema evolution (class

removal or moving in the inheritance tree and
related instances management)

Last but not least one should take into account the re-
quirements and the tremendous potential of the
World Wide Web content viewed as a loosely struc-
tured database of complex objects. There the appli-
cability of the object-oriented approach both for mod-
eling and storage/retrieval is very promising.

V. CASE STUDY: OBJECT RELATIONAL
SOLUTIONS FOR MULTIMEDIA DATABASES

Hereafter we will present the soulutions provided by
different ORDMS for video storage and retrieval.
IBM’s DB2 system supports video retrieval via “video
extenders.” Video extenders allow for the import of
video clips and querying these clips based on attri-
butes such as the format, name/number, or descrip-
tion of the video as well as last modification time.

Oracle (v.8) introduced integrated support for a

variety of multimedia content (Oracle Integrated Mul-
timedia Support). This set of services includes text,
image, audio, video, and spatial information as native
data types, together with a suite of data cartridges that
provide functionality to store, manage, search, and ef-
ficiently retrieve multimedia content from the server.
Oracle 8i has extended this support with significant
innovations, including its ability to support cross-
domain applications that combine searches of a num-
ber of kinds of multimedia forms and native support
for data in a variety of standard Internet formats, in-
cluding JPEG, MPEG, GIF, and the like. Oracle has
packaged its complex datatype support features to-
gether with management and access facilities into a
product called Oracle 8i interMedia. This product en-
ables Oracle 8i to manage complex data in an inte-
grated fashion with other enterprise data, and per-
mits transparent access to such data through standard
SQL using appropriate operators. It also includes In-
ternet support for popular web-authoring tools and
web servers. It offers online Internet-based geocoding
services for locator applications, and powerful text
search features.

55-14

Data Modeling—Object-Oriented Data Model

9902.ch55 2/5/02 2:28 PM Page 14

PROOF

Informix’s multimedia asset management technol-

ogy offers a range of solutions for media or publish-
ing organizations. In fact, Informix’s database tech-
nology is already running at the core of innovative
multimedia solutions in use. Informix Dynamic Server
with Universal Data Option enables effective, efficient
management of all types of multimedia content—in-
cluding images, sound, video, electronic documents,
web pages, and more. The Universal Data Option en-
ables query, access, search, and archive digital assets
based on the content itself. Informix’s database tech-
nology provides: cataloging, retrieval, and reuse of
rich and complex media types like video, audio, im-
ages, time series, text, and more—enabling viewer ac-
cess to audio, video, and print news sources; high-
performance connectivity between your database and
Web servers providing on-line users with access to up-
to-the-minute information; tight integration between
your database and web development environments
for rapid application development and deployment;
and extensibility for adding features like custom news
and information profiles for viewers (Table I).