PROOF

Data Modeling—Object-Oriented Data ModelMichalis VazirgiannisAthens University of Economics and Business

EnC

I. INTRODUCTIONII. MOTIVATION AND THEORY

III. INDUSTRIAL SYSTEMS—STANDARDS

IV. CONCLUSION—RESEARCH ISSUES AND PERSPECTIVESV. CASE STUDY: OBJECT RELATIONAL SOLUTIONS FOR

MULTIMEDIA DATABASES

GLOSSARY

d

e

in

o

p

framework of the program, the internal mech-sm determines what specific name of differentposes is known as function overloading.nal model A data modeling approach havingnd very successful industrial implementations

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

ata model In data modeling we tso that they represent as closelyworld situation, yet representati

cyclopedia of Information Systems, Volume Oneopyright 2002, Elsevier Science (USA). All rig

still feasible. A data model ethree elements: objects’ structtegrity constraints.

ncapsulation A property of the odence. This is achieved by hiditure and implementation detaworld simplifying thus the maof a multitude of object classe

heritance The ability of one structure and behavior of its aallows an object to inherit a cefrom another object while allospecific features.

bject-oriented modeling It is an aworld that represents objects’ sbehavior in terms of classes’ htural content is defined as a setached values and the behavio(functions that implement obje

olymorphism The ability of dclass hierarchy to have differsponse to the same message. Pits meaning from the Greek single behavior can generate sponses from objects in the

ry to organize data as possible a realon in computers is

theanipur

relatiofou

hts reserved. 55-1

ncapsulatesure, behavior and in-

bject oriented model, promoting data and operation indepen-ng the internal struc-ils from the externalintenance and usages in an application.class to inherit thencestor. Inheritancertain set of attributeswing the addition of

bstraction of the realtructural content andierarchies. The struc-t of attributes and at-r as a set of methodsct’s behavior).

ifferent objects in aent behaviors in re-olymorphism derivesfor “many forms.” Aentirely different re-same group. Within

in DBMS. The fundamental modeling constructsare the relations consisting of tuples of values eachone taking its semantics from an appropriate at-tribute. The relations represent entities of the realworld 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 alwayscorrespond to concrete or actual facts. They may beimprecise 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 theycan be processed effectively. In data modeling we try toorganize 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

PROOF

frequently conflicting. The optimal way to organizedata 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 abouthow data are organized and processed.

It is evident that an interpretation of the world isneeded, sufficiently abstract to allow minorperturbations, yet sufficiently powerful to give someunderstanding concerning how data about the worldare related. An intellectual tool that provides such aninterpretation will be referred to as a datamodel. It is a model about data by which a reasonableinterpretation of the data can be obtained. A datamodel 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 servicesfrom information stored in computing systems. Gradu-ally, the focus of computing, shifted from process-oriented

to data-oriented systems, where data play an importantrole 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, whichwere based on hierarchical and network (Codasyl)models, provided logical organization of data in treesand graphs. IBM’s IMS, General Electric’s IDS, Uni-vac’s DMS 110, Cincom’s Total, MRI’s System 200, andCullinet’s (now Computer Associates) IDMS are someof the well-known representatives of this generation.Although efficient, these systems used proce-dural languages and did not offer physical or logicalindependence, thus limiting its flexibility. Inspite of that, DBMSs were an important advance com-pared to the file systems.

IBM’s addition of data communication facilities toits IMS software gave rise to the first large-scale data-base/data communication (DB/DC) system, in whichmany users access the DB through a communicationnetwork. Since then, access to DBs through commu-nication networks has been offered by commerciallyavailable DBMSs.

C.W. Bachman played a pioneering role in the de-velopment of network DB systems (IDS product andCodasyl 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, calledCodasyl sets, are always one occurrence of one recordtype. To many, that is, a functional link. In its 1978specifications, Codasyl also proposed a data definitionlanguage (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. In1970, few people imagined that, in the 1980s, the re-lational model would become mandatory (a “decoy”)for the promotion of DBMSs. Relational products likeOracle, 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 howto get it) that deal with sets of records, and they canbe automatically optimized, although their DML andhost language are not integrated. With relationalDBMSs (RDBMSs), organizations have more facilitiesfor data distribution. RDBMSs provide not only betterusability but also a more solid theoretical foundation.

Unlike network models, the relational model isvalue-oriented and does not support object identity.Needless to mention, there is an important trade-offbetween object identity and declarative features. As aresult 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 onRDBMSs is the support of complex datatypes; also, null values, recursive queries, and scarcesupport 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

PROOF

stract data types) are now other weaknesses of rela-tional systems. Some of those problems are solved inthe 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, researchwork (and, later, industrial applications) focused onquery 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, andso on. That work allowed efficient and secure on-linetransactional processing (OLTP) environments (inthe first DB generation, DBMSs were oriented towardbatch processing). In the 1980s, the SQL languagewas also standardized (SQL/ANS 86 was approved bythe American National Standard Institute, ANSI andthe International Standard Organization, ISO in1986), and today, every RDBMS offers SQL.

Many of the DB technology advances at that timewere founded on two elements: reference models anddata models. ISO and ANSI proposals on referencemodels have positively influenced not only theoreticalresearches but also practical applications, especially inDB development methodologies. In most of those ref-erence models, two main concepts can be found; thewell-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) deviceswas 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 hasinfluenced research agendas for many years and issupported by most of the current products. Recently,other DBMSs have appeared that implement othermodels, most of which are based on object-orientedprinciples.

Three key factors can be identified in the evolutionof DBs: theoretical basis (resulting from researcher’swork), 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. Whatbegan as a product technology demanded by users’needs have always influenced the evolution of DBtechnology, but especially so in the last decade.

Today, we are witnessing an extraordinary develop-ment of DB technology. Areas that were exclusive ofresearch laboratories and centers are appearing inDBMSs’ latest releases: World Wide Web, multimedia,active, object-oriented, secure, temporal, parallel, andmultidimensional DBs. The need for exploiting theObject-Oriented Model for such complex systems isapparent.

II. MOTIVATION AND THEORY

A. Motivation

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

• Current DBMSs are monolithic; they offer allkinds of services and functionalities in a single“package,” regardless of the users’ needs, at a veryhigh cost, and with a loss of efficiency

• About half of the production data are in legacysystems

• Workflow management (WFM) systems are notbased on DB technology; they simply access DBsthough application programming interfaces (APIs)

• Replication services do not scale well over 10,000nodes

• Integration of strictly structured data with looselystructured data (e.g., data from a relational DBwith data from electronic mail)

On the other hand there is wealth of new applicationdomains that produce huge amounts of data andtherefore call for database support. Such domains arecomputer-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 databasesupport 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 thesequel we identify the shortcomings of current data-base technology in the context of the new applications:

• Poor representation of “real-world” entities, needto decompose objects over relations

• Fixed build-in types; no set-valued attributes aresupported, thus complex and highly nestedobjects cannot be represented efficiently

• Semantic overloading• Poor support for integrity and enterprise

constraints• No data abstraction such as aggregation and

generalization, thus inheritance and specializationcannot 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 aworking definition of an atomic piece of data the tu-ple <object name, object property value, time>. After all, aphenomenon 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 acertain time (time).

Of these four aspects of data, time is perhaps themost cumbersome aspect of data modeling. There-fore, many data models completely drop the notionof time and replace it either with other kinds of ex-plicit properties or with orderings among objects. Theissues 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 objectidentity issues. Then OO languages providing persis-tency (persistence by class, creation, marking, refer-ence) are necessary so that users of an OODBMS areable to define and manipulate database objects.

2. Object-Oriented Modeling and Programming Concepts

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

An object has an inherent state followed by its be-havior, which defines the way the object treats its stateas well the communication protocol between the ob-ject and the xternal world. We have to differentiatebetween the transient objects in OOPLs and the persistent objects—in object-oriented databases(OODBs). In the first case the objects are eliminatedfrom the main memory as soon as they are not neededwhereas 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 moreOOPLs.

The three features that differentiate an object froma relational tuple are

1. Object identity, a unique identifier generatedwith the object creation and follows it throughoutits life cycle

2. Encapsulation features (promoting data andoperation independence), since the internalstructure and implementation details are notaccessible from the external world simplifyingthus the maintenance and usage of a multitudeof 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, allowingdifferent behaviors to be grouped under the samemethod and operator names; this facilitates designand evolution of large sets of classes

Here after these features are further analyzed.

a. OBJECT IDENTITY, OBJECT STRUCTURE

AND TYPE CONSTRUCTORS

The object identity (OID) is generated by the sys-tem when a new object is created and is unique andimmutable. Each OID is used only once and is invisi-ble to the users.

An OODBMS offers a set of type constructors thatare used to define the data structures for an OO data-base schema. The basic constructors offered createdatomic values (atom (integer, string, float, etc.), tu-ples, and sets of objects. Other constructors createlists, bags, and arrays of objects. It is also feasible tohave attributes that refer to other objects called ref-erences—OID.

An object has an internal structure defined by atriple (OID, type constructor, state). For instance, as-sume an object o � (i1, tuple, <manager: i3, start-date:i5>). An object can be represented as a graph struc-ture that can be constructed by recursively applyingthe 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 becomesinteresting. Object equality is a concept that can beviewed from two aspects: deep and shallow.

• Two objects are said to have identical states (deepequality) if the graphs representing their statesare identical in every respect, including the OIDsat every level.

• Two objects have equal states (shallow equality) ifthe graph structures are the same and all thecorresponding atomic values in the graphs arealso the same. However, some correspondinginternal nodes in the two graphs may have objectswith different OIDs.

b. ENCAPSULATION

An important feature in the domain of OODBs isthe encapsulation that offers an abstraction mecha-nism and contributes in information hiding since anobject encapsulates both data and functions into aself-contained package. Thus the external aspects ofan object are separated from its internal details. Theexternal users of the object are only made aware ofthe 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 aset of methods and messages. A method consists of aname 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 withobjects we distinguish between visible attributes, imple-mented by external operators or query language pred-icates or hidden attributes which are referenced onlythrough 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: Employeedestroy_emp: boolean;

end Employee;

If d is a reference to an Employee object, we can in-voke an operation such as age by writing d.age. Ofcourse the main issue in OODBs is to have a mechanism

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

PROOF

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

In other cases it is desirable that a type inheritsonly part of structure and/or behavior of the a su-pertype. This is the case of selective inheritance. TheEXCEPT clause may be used to list the functions in asupertype that are not to be inherited by the subtype.

d. POLYMORPHISM

The term polymorphism integrates the various caseswhere, during inheritance, redefinition of structure orbehavior is necessary. Polymorphism implies operatoroverloading where the same operator name or symbolis bound to two or more different implementations ofthe operator, depending on the type of objects towhich 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 methodbased on an object’s type is called binding. In stronglytyped systems, this can be done at compile time. Thisis 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), theselection is called dynamic binding.

e. COMPLEX OBJECTS

A complex object, an important concept in the object-oriented approach, is an item that is perceivedas a single object in the real world, but combines withother objects in a set of complex a-part-of relation-ships.

We distinguish two categories of complex objects:unstructured and structured ones. The unstructuredcomplex objects contain bitmap images, long text strings;they are known as binary large objects (BLOBs),OODBMSs provide the capability to directly processselection conditions and other operations based onvalues of these objects.

Such objects are defined by new abstract data typesand 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. TYPE HIERARCHIES AND INHERITANCE

A type can be defined by giving it a type name andthen listing the names of its public functions. Then itis possible to define subtypes emanating from the ba-sic types. For example:

Each subtype inherits the structure and behaviorof 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 thatinherits from more than one superclass. This is thecase of multiple inheritance which occurs when a cer-tain subtype T is a subtype of two (or more) types andhence inherits the functions of both supertypes. Thisleads to the creation of a type lattice. In several casesif the lattice grows integrity and ambiguity problemsmay arise.

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

PROOF

The second category, structured complex objects, im-plies that the object’s structure is defined by repeatedapplication of the type constructors provided by theOODBMS. Here we distinguish two types of referencesemantics: (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 theOODBMS area have been concentrated and codifiedby the Object-Oriented Database System Manifesto.This is an effort toward standardization and promot-ing ideas that should be part of an object-orienteddatabase system. The most important concepts fromthis 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 withinheritance features, so that types or classes mustbe 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. MoreoverThe DBMS must provide a simple way of queryingdata.

• Data persistence must be provided as a naturalfeature of a database system.

• The DBMS must be capable of managing verylarge 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 andpromising, the impact on the database industry wasnot as important as hoped. Instead the big databaseindustry tried to extend the well-established relationaltechnology by integrating some of the object-orienteddatabase concepts. This hybrid technology is knownas 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 strengthsand weaknesses of the relational and object-orientedsystems in order to motivate the need for object-oriented modeling. The discussion will include user-defined data types and set-based versus navigationalaccess 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 describedby E. F. Codd. Not long afterward, companies likeIBM and Oracle created very successful products. Therelational DB standard is published by ANSI, with thecurrent specification being X3H2 (SQL’92). The newspecification dealing with object extensibility has beenlabeled X3H7. A relational DB stores data in one ormore tables or rows and columns. The rows corre-spond to a record (tuple); the columns correspond toattributes (fields in the record), with each columnhaving a data type like date, character, or number.Commercial implementations currently support veryfew 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 relationaloperations, and the data themselves are structures toa 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 onetable 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 existingtables or introducing entire tables remains an ex-tremely simple operation. The beauty of relationalDBs continues to be in its simplicity. The process ofnormalization establishes a succinct clarity to the man-agement and organization of data in the DB. Redun-dancies are eliminated and information retrieval itsgoverned by the associations created between primaryand 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? Referentialintegrity (RI) has also made an important contribu-tion because it enables business rules to be controlledthrough 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 tothe emergence of OOP in the 1970s. Technically, thereis no official standard for object DBs. The book TheObject Database Standard: ODMG-V2.0, under the sponsorship of the Object Database ManagementGroup (ODMG) (http://www.odmg.com), describesan industry-accepted de facto standard. Object DBMSsemphasize 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 modelcomplex systems. Characteristics of object DBs includea data model that has object-oriented aspects like class,with attributes, methods, and integrity constraints; theyalso have OIDs for any persistent instantiation ofclasses; 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 definingnew object classes that have operations to support thenew kinds of information.

The object-oriented modeling paradigm also sup-ports inheritance, which allows incremental develop-ment of solutions to complex problems by definingnew objects in terms of previously defined objects.Polymorphism allows developers to define operationsfor one object and then share the specification of theoperation with other objects. Objects incorporatingpolymorphism also have the capability of extendingbehaviors or operations to include specialized actionsor behaviors unique to a particular object. Dynamicbinding is used to determine at runtime which opera-tions are actually executed and which are not. ObjectDBs extend the functionality of object programminglanguages like C�� or Java to provide full-featured DB programming capability. The result is ahigh level of congruence between the data model forthe 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. Allof 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 PureRelational and Object-Oriented Databases

In the relational DB, the query language is the meansto 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 automaticallygiven an OID that is unique and immutable duringthe object’s life. One object can contain an OID thatlogically 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 formthe 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 veryprinciples of normalization because OIDs make noreliance on keys.

To further explore the divergent nature of rela-tional and object-oriented DBs, let us look moreclosely 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 ittakes to define the object-relational paradigm. A firstissue is to enable object functionality in the relationalworld. Two important aspects must be considered inany definition of the object-relational paradigm. Thefirst is the logical design aspects of the architecture.What data types will be supported? How will data beaccessed? 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 capabilitiesare behavior, collection types, encapsulation, inheri-tance, and polymorphism.

a. BEHAVIOR

A method, in the purely object-oriented paradigm,is the incorporation of a specific behavior assigned toan object or element. A method is a function of a par-ticular class.

b. COLLECTION TYPES

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, thereare two collection types: VARRAYs and nested tables.VARRAYs are suitable when the subset of informationis static and the subset is small. A suitable implemen-tation of a VARRAY might be in the same contextwhere a reference entity might be used. The contents

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

c. ENCAPSULATION

Encapsulation is the definition of a class with datamembers 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 ofthe class. The actual implementation is hidden fromthe 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 planepilot can start the ignition. The engine causes theplane to move. Although you can see the motor, theinner functions are hidden from your view. You canappreciate the function that the motor performs with-out ever knowing all the details of what occurs insideor even how.

d. INHERITANCE

Inheritance is the ability of one class to inherit thestructure and behavior of its ancestor. Inheritance al-lows an object to inherit a certain set of attributesfrom another object while allowing the addition ofspecific features.

e. POLYMORPHISM

Polymorphism is the ability of different objects ina class hierarchy to have different behaviors in re-sponse to the same message. Polymorphism derives itsmeaning from the Greek for “many forms.” A singlebehavior can generate entirely different responsesfrom objects in the same group. Within the frame-work of the program, the internal mechanism deter-mines specific names for different purposes and isknown as function overloading.

.

Data Modeling—Object-Oriented Data Model 55-9

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

PROOF

formance.•

III. INDUSTRIAL SYSTEMS—STANDARDS

A. Standards—The Object Model of the ODMG

ODMG was created at the initiative of a set of objectdatabase vendors with the goal of defining and pro-moting a portability standard for OODBs. It had eightvoting members (O2 Technology, Versant, Poet, Gem-stone, Objectivity, Object Design, Uni SQL, IBEX), re-viewing members (among which, CERN, HewlettPackard, 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 modelsupported by the ODMG system, being anextension of the OMG(Object Management Group) model.

2. Object Definition Language (ODL) It is used tospecify the schema of an object database having aspecific schema with a C�� binding.

3. Object query Language (OQL) An SQL like languagethat can be used as a stand-alone language forinteractive queries or embedded in aprogramming language.

In the following we provide an overview of the ODMGmodel. ODMG addresses objects and literals. An objecthas both an OID and a state where a literal has only avalue but no OID. An object is described by four char-acteristics: identifier, name, lifetime, and structure. Onthe other hand, three types of literals are recognized:atomic, collection, and structured. The notation ofODMG uses the keyword “interface” in the place of thekeywords “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 thecollection O. The ODMG object model uses excep-tions for reporting errors or particular conditions.For example, the ElementNotfound exception inthe Collection interface would be raised by the o.re-move_element(e) operation if e is not an elementin 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 isnot a collection object is called an atomic object. Theyare specified using the keyword class in ODL. Thekeyword 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 andhas_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 operationsignatures. 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 byODMG is inheritance, which is implemented by ex-tends keyword.

The database designer can declare an extent forany object type that is defined via a class declarationand it contains all persistent objects of that class. Ex-tents are also used to automatically enforce theset/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

PROOF

properties (attributes or relationships) whose valuesare constrained to be unique for each object in theextent.

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 anyprogramming language. Moreover it is feasible to usethe specific language bindings to specify how ODLconstructs 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 extendedentity 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 haveto 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 ( extentfaculty )

{ attribute string rank;....

};

The class Faculty extends the class Person which is inturn an extension of class person. Therefore the leafclass 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 theODMG object model in order to be able to queryOODBs. It is designed to work closely with the pro-gramming languages for which an ODMG binding isdefined, such as C��, SMALLTALK, and Java. It issimilar 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.nameFROM d in departmentsWHERE d.college = ‘Engineering’

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

departments;csdepartment;csdepartment.chair;csdepartment.has_faculty;Csdepartment.has_faculty.rank ( x )

SELECT f.rankFROM f in csdepartment.has_faculty;

Then we can write the following query to retrieve thegrade point average of all senior students majoring incomputer science, with the result ordered by gpa, andwithin 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_majorsWHERE 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 viewsas named queries. For instance we can define the fol-lowing view:

DEFINE has_minors(deptname) ASSELECT sFROM s in studentsWHERE s.minors_in.dname = deptname;

Then a potential query searching for the studentsthat took as minor Computer Science the followingquery can be formed:

Has_minors(‘Computer Science’);

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

count (s in has_minors(‘Computer Science’));

avg (SELECT s.gpaFROM s in studentsWHERE s.major_in.dname = ‘ComputerScience’ and s.class = ‘senior’);

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

For all g in (SELECT s FROM s in grad_studentsWHERE 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_studentsWHERE s. majors_in.dname = ‘Computer Science’

AND g.gpa = 4) ;

5. Object Database Conceptual Design

An important issue that arises here is the conceptualdesign of an object-oriented schema. Can we benefitfrom the traditional design techniques applied in re-lational databases? There are important differencesbetween conceptual design of object databases andrelational databases.

As regards relationships, object databases (ODB)exploit object identifiers resulting in OID referenceswhile a relational database system (RDB) references totuples by values or by externally specified/generatedforeign keys

Regarding inheritance, the ODB approach exploitsinheritance 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 relationalsystems 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 typeor subclass

Step 2: Add relationship properties or referenceattributes for each binary relationship into the ODLclasses that participate in the relationship

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

the EER schema inherits the type and methods ofits superclass in the ODL schema

Step 5: Weak entity types can be mapped in the sameway as regular types

Step 6: Declare a class to represent the category anddefine 1:1 relationships between the category andeach of its superclasses

Step 7: An n-ary relationship with degree n > 2 can bemapped into a separate class, with appropriatereferences to each participating class.

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

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

1. Example of ODBMS—O2 System

This system has historical importance as it was theonly 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 (storagecomponent, 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

PROOF

nipulation in O2 is carried out in several ways. O2supports OQL as both an ad hoc interactive querylanguage 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 thedepartments of the college of Engineering.

2. Object Relational Systems—ComplexTypes and Object Orientation

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

Industry experts are frequently critical of object-relational DBs because they usually demonstrate alimited or nonexistent ability to perform certain rela-tional or object-oriented tasks in comparison to theirpure 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 limitedconsequence when employed in the storage of dataand datacentric objects that its pursuit is a waste of ef-fort. Each point of view is almost always driven by theparticular background of the individual presentingthe criticism. Because the object-relational paradigmis a compromise of two very different architectures,the most effective definition of its ultimate characterwill be devised by those who have an unbiased appre-ciation for relational and object-oriented systemsalike.

An issue to be tackled can be the question whetherORDBMSs should begin with a relational foundationwith added object-orientation of the reverse. From aconceptual level relational DBs have been far moresuccessful than their OODBMS counterparts. Itshould not be any surprise then, that virtually all ma-jor vendors are approaching the object-relationalarena 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 relationalengines.

Anything that causes such controversy should beworth the effort, which begs two important questions:First, what factors have led to the development of object-relational DBs? And second, what characterizesan accurate definition of an object-relational DB? Thegeneral answer to the first question is that developersneed a more robust means of dealing with complexdata elements without sacrificing the access speed forwhich relational DBs have become known. To answerthe second question, there are several characteristicsthat, as a minimum, must be included to achieve atrue object-relational structure. Those characteristicsare the following:

• Retrieval mechanism, that is, a query languagelike SQL but one adapted to the extendedfeatures of the ORDBMS, the retrieval mechanismmust include not only relational navigation butalso object-oriented navigational support

• Support for relational features like keys,constraints, indexes, and so on

• Support for referential integrity as it is currentlysupported 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 spatialinformation. Oracle, Informix, and IBM DB2 offer ca-pabilities for user-defined data types and functionsthat are applied to them. All of them propose thenested storage model, where a complex attribute isstored in an attribute (they call it in-line). They claimit is more efficient when queries regarding an objectreposed since self-join is avoided. This is a good ar-gument for choosing this approach.

DB2 Spatial extender provides a comprehensive setof 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 transformationfunctions (buffer, locatealong, locate between, con-vexhull, etc.).

The Informix Dynamic Server with Universal DataOption offers type extensibility. So-called DataBlademodules may be used with the system, thus offeringnew types and associated functions that may be usedin columns of database tables. The Informix GeodeticDataBlade Module offers types for time instants andintervals 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 spatialdata. Current support encompasses geometric formssuch 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 datasets and related application domains rises require-ments for object oriented features in database sup-port. Significant research has been devoted in thisarea of integrating such object-oriented features indatabase technology. Important effort has been com-mitted to either as pure OODBMS or as extensions ofthe relational approach (ORDBMSs).

The object-oriented model offers the advantageousfeatures regarding:

• Flexibility to handle requirements of new databaseapplications

• Complex objects and operations specificationcapabilities

• OODBs are designed so they can be directly—orseamlessly—integrated with software that isdeveloped using OOPLs

Nevertheless, there are several interesting issuesfor further research in the context of object-orientedand object relations database systems. Some of themare:

• View definition and management on theODB/ORDB schema

• Querying the schema, in terms of class names,attributes, and behavior features

• Optimization in several levels such as pathexpression queries, storage, and retrieval issues

• Access mechanisms, indexing, and hashingtechniques specialized for object-oriented andobject relations databases

• Dynamic issues such as schema evolution (classremoval or moving in the inheritance tree andrelated instances management)

Last but not least one should take into account the re-quirements and the tremendous potential of theWorld 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 RELATIONALSOLUTIONS FOR MULTIMEDIA DATABASES

Hereafter we will present the soulutions provided bydifferent ORDMS for video storage and retrieval.IBM’s DB2 system supports video retrieval via “videoextenders.” Video extenders allow for the import ofvideo 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 avariety of multimedia content (Oracle Integrated Mul-timedia Support). This set of services includes text,image, audio, video, and spatial information as nativedata types, together with a suite of data cartridges thatprovide functionality to store, manage, search, and ef-ficiently retrieve multimedia content from the server.Oracle 8i has extended this support with significantinnovations, including its ability to support cross-domain applications that combine searches of a num-ber of kinds of multimedia forms and native supportfor data in a variety of standard Internet formats, in-cluding JPEG, MPEG, GIF, and the like. Oracle haspackaged its complex datatype support features to-gether with management and access facilities into aproduct 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 standardSQL using appropriate operators. It also includes In-ternet support for popular web-authoring tools andweb servers. It offers online Internet-based geocodingservices for locator applications, and powerful textsearch 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 innovativemultimedia solutions in use. Informix Dynamic Serverwith Universal Data Option enables effective, efficientmanagement 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 assetsbased on the content itself. Informix’s database tech-nology provides: cataloging, retrieval, and reuse ofrich 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 andWeb servers providing on-line users with access to up-to-the-minute information; tight integration betweenyour database and web development environmentsfor rapid application development and deployment;and extensibility for adding features like custom newsand information profiles for viewers (Table I).

SEE ALSO THE FOLLOWING ARTICLES

REFERENCES

Ehoshafian, S., (1990) Insight into object-oriented databases.Information and Software Technology, 32(4).

Informix DataBlade Technology (1999). Transforming Datainto Smart Data.

Oracle 8 SQL Type Data Definition Language. (1997). An Or-acle Technical White Paper.

Davis, J. R. (1998). IBM’s DB2 Spatial Extender: Managing Geo-Spatial Information Within the DBMS. Technical report.IBM Corporation.

Date, C. J., and Darwen, J. (1996 ). Foundation for object/relationaldatabases, the third manifesto. Reading, MA:Addison-Wesley.

Piatini, M., and Diaz, O., eds. (2000). Advanced database tech-nology and design. Norwood, MA: Artech House.

Tsichritzis, D., and Lochovsky, F. (1982). Data models. New York:Prentice Hall.

Atkinson, M., Banceilhon, F., DeWitt, D., Dittrich, K., Maier, D.,and Zdonik, S. (1989). The object-oriented database systemmanifesto. In Proceedings of the first international confer-ence on deductive and object-oriented databases, pp.223–40. Kyoto, Japan.

Dahl, O. J., and Nygaard, K. (1966). SIMULA—An ALGOL-based simulation language. Communications of the ACM,9(9):671–678.

Goldberg, A., and Robson, D. (1982). Smalltalk 80: The languageand its implementation. Reading, MA: Addison-Wesley.

http://www.software.ibm.com/data/dbs/extenders.

Data Modeling—Object-Oriented Data Model 55-15

Table I Comparative presentation of multimedia retrieval capabilities of commercial object relational systems

QBIC Oracle Informix DB2

Color Percentage, layout (hist) Global, Local color Excalibur (Image Dblade)

Texture Similar Graininess, smoothness Excalibur (Image Dblade)

Shape Excalibur (Image Dblade)

Spatial Show positionrelationships

Scene detection MEDIAstra (Video Dblade)

Object detection MEDIAstra (Video Dblade)

MPEG-4 approach

Captions & Manual annotation DbFlix—meta-data storage Description (img)Annotations Time, frame, content based Format, frame rate,

approach. tracks (video)Format, last update

(audio)

Extend Datablades DB2 Extendersfunctionality

Sound Muscle Fish Audio Limited(content based queries)

Other Feature layout Ideal for Video on Feature vector (Exc) Feature layoutDemand Video reproduction (Media) Voice to text

Vis

ual

Info

Ret

riev

al

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

PROOF

SUGGESTED READING

Codd, E. F. (1970). A Relational Model for Large Shared DataBanks, Communications of the ACM, 13, 377–387.

Date, C. J., and Darwen, H., Foundation for object/relational data-base, the throd manifesto, Reading, MA: Addison, Wesley.

Dittrich, K. (1986). “Object-Oriented Database Systems: TheNotion and the Issues.” Proceedings of the International Work-shop on Object-Oriented Database Systems, September, PacificGrove, CA.

Dittrich, K., and Dayal, U. (eds.). (1986). Proceedings of the In-ternational Workshop on Object-Oriented Database Systems, Sep-tember, Pacific Grove, CA.

Atkinson, M., Banchillon, F., DeWitt, D., Dittrich, K., Maier, D.,and Zdonik, S. (1992). The Object-Oriented Database SystemManifesto. In Building an Object-Oriented Database System: TheStory of O2, Banchilhon et al. (eds), San Francisco: MorganKaufmann. Also in Proc. Int. Conf. Deductive Object-OrientedDatabases, Kyoto, Japan, Dec. 1989.

Copeland, G., and Khoshafian, S. (1986). Identity and Versions forComplex Objects, Proceedings of the International Workshop on Object-Oriented Database Systems, Spetember, Pacific Grove, CA.

Khoshafian, S. (1993). Object Oriented Databases. New York: JohnWiley.

Stonebraker, M., Rowe, L., Lindsay, B., Gray, J., and Carey, M.(1990). Third-Generation Data Base System Manifesto.Memorandum No. UCB/ELR. M90/23, April. The Com-mittee for Advanced DBMS Function, University of Califor-nia, Berkeley, CA.

Kim, W. (1991). Introduction to Object-Oriented Database. Cam-bridge. MA: The MIT Press.

Banchillon, F., Briggs, T., Khoshafian, S., Valduriez, P. (1987).FAD-a Simple and Powerful Database Language, Proceedingsof VLDB 1987.

Manola, F. (1989). An Evaluation of Object-Oriented DBMS Devel-opments, GTE Laboratories Incorporated, TR-0066-10-89-165.

Wilkinson, K., Lyngbaek, P., Hasan, W. (1990). The Iris Archi-tecture and Implementation, IEEE Transactions on Knowledgeand Data Engineering, 2(1), March 1990.

Lynbaek, P., and Kent, W. (1986). A Data Modeling Methodol-ogy for the Design and Implementation of Information Systems, Proceedings of the International Workshop on Object-Oriented Database Systems, September, Pacific Grove, CA.

Hewlett-Packard Company HP-SQL Reference Manual, PartNumber 36217-9001.

Ï. Deux et al. (1990). The story of O2, IEEE Transactions onKnowledge and Data Engineering, 2(1), March 1990.

Ç. Chou et al. (1985). Design and implementation of the Wis-consin storage system, Software-Practice and Experience, 15(10),Oct. 1985.

Maier, D., Stein, J. (1986). Indexing in an Object-OrientedDBMS, Proceedings of the International Workshop on Object-Oriented Database Systems, September, Pacific Grove, CA.

Ìaier, D. (1986). Why Object-Oriented Databases Can SucceedWhere Others Have Failed, Proceedings of the InternationalWorkshop on Object-Oriented Database Systems, September, Pa-cific Grove, CA.

Maiers, R. (1990). Making Database Systems Fast Enough forCAD, In Object-Oriented Concepts, Databases and Applications,(Kim, W., and Lochovsky, F., eds.). Reading, MA: Addison-Wesley Publishing.

55-16 Data Modeling—Object-Oriented Data Model

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