cl1 02 wom kim cl1 research directions in object oriented database systems

7/29/2019 Cl1 02 Wom Kim CL1 Research Directions in Object Oriented Database Systems

1/15

Research Directions inObject-Oriented Database SystemsWon KimMicroelectronics and Computer Technology Corporation3500 West Balcones Center DriveAustin, Texas 78750

ABSTRACTThe set of object-oriented concepts ound in object-oriented programming languages orms a good basis or a

data model fo r post-relational database systems whichwill extend the domain o f database applications beyondconventional business data processing. However, despitethe high level of research and development activities dur-ing the past several years, there is no standard object-ori-ented data model, and criticisms and concerns about thefield still remain. In this paper, I will first provide a histor-ical perspective on the emergence of object-oriented da-tabasesystems n order to derive a definition of object-o-riented databasesystems. will then examine a number ofmajor challenge which remain for researchers and imple-mentors of object-oriented database systems.1. INTRODUCTION

The rapidly increasing use of object-oriented con-cepts in various components of software technology hasnaturally necessitated object-oriented databasesystems.There is a flurry of activities to build and market object-o-riented database systems RELE89, KIM9Od]. There areseveral commercial products in various stages of readi-ness. There are at least a dozen industrial research proj-ects around the world to prototype object-oriented data-base systems, and object-oriented database systemsarealso under development in a comparable number of uni-versity laboratories.

Permission to copy without fee all or part of this matettial is grantedprovided that the copies are not made or distributed for directcommercial advantage, the ACM copyright notice and the title of thepublication and its date appear, and notice is given that the copying is bypermission of the Association for Computing Machinery. To copy other-wise, or to republish, requires a fee and/or specific permission.0 1990 ACM 089791-352-3/90/0004/0001 $1.50 1

Despite all these activities, currently there is nostandard for ob ject-oriented databases; hat is, there isno standard object-oriented database anguage in whichto program applications. Further, the lack of standard se-mantics for object-oriented programming and the appar-ent lack of a computational formalism for object-ori-ented databasesystemshave given rise to concerns aboutthe validity of object-oriented database systems.Theseconcerns certainly must and, I believe, can be addressed.The recent proposals for high-level rules for object-ori-ented database systems, [ATKI89] and [KIM9Oa,KIM9Oe], reflect the view that the field of object-ori-ented databaseshas matured enough during the past sev-eral years. I believe that databasesystemsbasedon an ob-ject-oriented data model will take root in the near futureas one form of post-relational databasesystems.The pri-mary reason s that object-oriented programming and theobject-oriented approach is the most promising solutionavailable today to the problems of developing, modifying,and extending complex, data-intensive software systems[GOLD83, STEF86, MICA88, STRO88]; the use of ob-ject-oriented concepts in applications which generateand manage a very large number of objects and complexrelationships among them will have to turn to databasesystems which directly capture the object semantics[KIM89a]. Further, there is a long list of shortcomings ofcurrent relational database systems; hese shortcomingsmust be removed if the utility of database systems s toextend beyond the domain of business data processing.

In this paper, I will first provide a historical perspec-tive on the emergence of object-oriented database sys-tems. This will lead to a working definition of object-ori-ented database systems, and will allow some light to beshed on the current concerns about and prospects for ob-ject-oriented databasesystems. will then outline a num-


2/15

ber of important topics of research which I hope other re-searchers will take up.2. HISTORICAL BACKGROUND

I believe that the emergence of object-oriented da-tabase systemsduring the second half o f the 1980s s dueto the simultaneous coming of age of object-orientedprogramming and the push for post-relational databasetechnology. The discovery of the limitations of the rela-tional database systems and the need to manage a largevolume of objects with object semantics found in object-oriented programming languages ed to the introductionof commercial object-oriented database systems n themid- to late-1980s. Let us briefly review the evolutionaryhistory of database systemsand the rationale for object-oriented programming.2.1 Push for Object-Oriented Concepts

Object-oriented concepts have evolved in three dif-ferent disciplines: first in programming languages, thenin artificial intelligence, and then in databases.Simula-67 is generally regarded as the first object-ori-ented programming language. Since Simula-67, re-searchers n programming languages have taken two dif-ferent paths to promote object-oriented programming[MICA88]. One was he development of new object-ori-ented languages, most notably Smalltalk. Another wasthe extension of conventional languages: Flavors andLOOPS as extensions of LISP; Objective C and C + + asextensions of C; and so on. After Marvin Minskys intro-duction of frames [MINS75] as a knowledge representa-tion scheme, researchers in artificial intelligence havedeveloped such frame-based knowledge representationlanguages as KEE, ART and so on. In the databasearea,research into semantic data models has led to data mod-eling concepts similar to those embedded in object-ori-ented programming and knowledge representation lan-guages. The c lass concept captures the instance-of rela-tionship between an object and the class to which it be-longs; the concept of a subclassspecializing its superclasscaptures the generalization (IS-A) relationship; and thecomposition of an object in terms of attributes capturesthe aggregation relationship. Some of the better-knownsemantic data models include E/R (entity-relationship)[CHEN76], SDM (semantic data model) [HAMMSl],and DAPLEX [SHIPSI]. Indeed, object-oriented con-cepts are the common thread linking frame-based knowl-edge representation and reasoning systems, object-or i-ented programming (application development) environ-

ments, and object-oriented advanced human interfacesystems.Therefore, they may be the key to building onetype of intelligent high-performance programming sys-tem of the foreseeable future.An object-oriented approach to programming isbased on the concepts of encapsulation and extensibility.A program in general consists of data and code that oper-ates on the data. Object-oriented programming encapsu-lates in an object some data, and programs to operate onthe data: the data is the sta te of the object, and the code sthe behavior of the object. The sta te of an object is thevalues of the attributes defined for the object, and the be-havior is a set of programs with a well-defined interfacefor their invocation. Object-oriented programming re-quires the behavior of an object to be invoked via mes-sages o the object through the interface defined for theobject. For example, one may define a Shape object,whose state consists of the values of the attributes Cen-ter-Point and Bounding-Box for the object, and whose

behavior includes a program called Display-Shape to dis-play the object on a screen. One may causea Shapeobjectto Display itself on a screen by sending a message o in-voke the Display-Shape behavior of the object. The no-tion of encapsulation has proven to be a natural and easyparadigm for various application environments, such asgraphical user-interface systems.Extensibility refers to the ability to extend an exist-ing systemwithout introducing changes o it. Extensibilityis an especially powerful concept for building and evolv-ing very large and complex software systems.An object-

oriented approach to programming offers extensibility intwo ways: behavioral extension and inheritance. The be-havior of an object may be extended by simply includingadditional programs. A behavioral extension of an objectdoes not affect the validity of any existing program. Forexample, a new program named Rotate-Shape may beadded to the Shape object defined above. An object-or i-ented approach further promotes extensibility throughreuse or inheritance. The behavior, and even the attrib-utes, defined for an object may be reused in the definitionof more specialized objects, that is, they may be inheritedby new objects. For example, a new object namedTrianglemay be defined as a specialized Shape object. TheTriangle object inherits (reuses) the behavior (Display-Shape and Rotate-Shape) and attributes (Center-Pointand Bounding Box) defined for the Shape object. Fur-ther, one may define additional behavior and attributesfor the Triangle object, and even redefine some of theinherited behavior and attributes.

2


3/15

2.2 Push for Next-Generation Database Sys-temsDuring the past three decades,database echnologyhas undergone four generations of evolution, and thefifth generation of database echnology is currently underdevelopment. The first generation was the file systems;

the second generation was the hierarchical database sys-tems; the third generation was the CODASYL databasesystems;and the fourth generation is the relational data-base systems. The second and third generation systemsrealized the sharing of an integrated database amongmany users within an application environment. The lackof data independence and the tedious navigational accessto the database gave rise to the fourth-generation data-base technology. All four generations of database sys-tems have been designed to meet the requirements ofbusiness data-processing applications, such as inventorycontrol, payroll, accounts, and so on. The fifth-genera-tion database echnology will be characterized by a richerdata model and a richer set of database facilities neces-sary to meet the requirements of applications beyond thebusiness data-processing applications for which the firstfour generations of database echnology have been devel-oped.

The transition from one generation of databasetechnology to the next has been marked by the offloadingof some tedious and repetitive bookkeeping functionsfrom the applications into the database system. This hasmade it easy or the application programmers to programdatabaseapplications; however, it made the performanceof database systemsa major problem, and required con-siderable research and development efforts to increasethe performance o f the new generation databases o anacceptable level. This point is particularly true for thetransition into the era of relational databases.The intro-duction of declarative queries in relational databases e-lieved application programmers of the tedious chore ofprogramming navigational retrieval of records from thedatabase.However, a major new component, namely thequery optimizer, had to be added to the database systemto automatically arrive at an optimal plan for executingany given query, such that the plan will make use of ap-propriate accessmethods available in the system.

During the 1970s esearch and development activi-ties in databaseswere focused on realizing the relationaldatabase echnology. These efforts culminated in the in-troduction of commercial relational database systems nthe late 70sand early 80s.However, attempts to make useof the relational database echnology in a wide variety of

types of application have exposed several serious short-comings of the relational and past-generation databasetechnology. The shortcomings of conventional databasetechnology became the subjects of database research anddevelopment during the 80s. The new applications in-clude computer-aided design, engineering, software en-gineering, and manufacturing (CAD, CAE, CASE, andCAM - hereafter abbreviated as CAX) systemsand appli-cations that run on them; knowledge-based systems ex-pert systems and expert system shells); multimedia sys-tems which deal with images, voice, and textual docu-ments; real-time systems; programming language sys-tems; and so on. Some of these applications require facili-ties for modelling and managing complex nested entities(such as design and engineering objects, and compounddocuments); a richer set of data types, that is, user-de-fined data types, and long unstructured data (such asimages, audio, and textual documents); frequently usefulsemantic concepts (such as generalization and aggrega-tion relationships); the concept of temporal evolution ofdata (i.e., temporal dimension of data, and versioning ofdata); and so on. Some of the applications are highly com-pute-intensive on a large volume of memory-residentdata, and impose performance demands that cannot bemet by conventional database systems.The environmentof some of the applications requires long-duration, inter-active, and cooperative transactions. Further, conven-tional database systems equire application programs tobe implemented in some algorithmic programming lan-guage and some database anguage embedded in it; thedatabase anguages are very different from the program-ming languages, in both the data model and data struc-tures.3. OBJECT-ORIENTED DATABASE SY-

TEMSIn this section, I will first set forth broad minimumrequirements for object-oriented database systems.Then, on the basis of the historical background I outlinedin Section 2, I will examine a broader definition, and ad-dress important reasons for the current concerns aboutthe definition and validity of object-oriented database

systems.3.1 Minimum RequirementsI take the view that a database system must satisfythe following two broad conditions before it can be calledan object-oriented database system.

1. It supports a core object-oriented data model.2. It supports all the database features found in conventional

3


4/15

database systems, with their semantics e%endedlmodified tobe consistent with the semantics of the core object-orienteddata model.

An object-oriented database system is a persistentand sharable repository and manager of an object-ori-ented database;and an object-oriented database s a col-lection of objects defined by an object-oriented datamodel, that is, objects that capture the semantics of ob-jects supported in object-oriented programming. I notethat [MAIE89b] questions whether it makes sense toeven talk about a data model for ob ject-oriented data-base systems. , like most others [LECL88], will never-theless use the term object-oriented data model to meana logical organization of real-world objects (entities),constraints on them, and relationships among objects. Aset of core object-oriented concepts forms the basis of anobject-oriented data model for an object-oriented data-base system. regard, as does [ATKI89], the following ascore object-oriented concepts; as they are familiar con-cepts by now, I will not elaborate on them here.1. Any real-world entity is uniformly modeled as anobject, and is associated with a unique identifier.

2. Every object encapsulates a state and a behavior,where the state of an object is the set of values for the at-tributes of the object, and the behavior of an object is theset of methods (program code) which operate on the stateof the object. The value o f an attribute of an object is alsoan object in its own right. Further, an attribute of an ob-ject may take on a single value or a set of values.3. All objects which share the same set of attributes

and methods are grouped together as a class*, such thatan object belongs to only one class as an instance of thatclass.4. The domain (type) of an attribute of a classmay beany class.The domain class may be a primitive class,suchas integer, string, or boolean. It may be a general classwith its own set of attributes and methods. The domain ofan attribute of a class C may be the class C.5. All the classesare organized as a rooted directedacyclic graph or a hierarchy (called a class hierarchy). Aclass nherits all the attributes and methods from its di-rect and indirect ancestors n the class hierarchy. Seman-tically, a class s a specialization (subclass)of the class(es)

from which it inherits attributes and methods; conversely,a class s a generalization (superclass) of the class$swhichinherit attributes and methods from it. The class hierar-chy must be dynamically extensible; that is, a new subclasscan be derived from one or more existing classes.6. The state and behavior encapsulated in an objectmay be accessedor invoked from outside the object only

through explicit messagepassing. Further, it must sup-port the run-time binding of a message o its correspond-ing method, since the method may have been inheritedinto the object from a superclass.The evolutionary history of database systems hasshown that the transition from one generation to the nexthas never resulted in the elimination of essential data-base features. Conventional database systems providedatabase anguages to allow application programmers todefine and manipulate the database. A conventional da-tabase anguage consists of three components (or sublan-guages): data definition language for specifying the sche-

ma; query and data manipulation language for queryingand updating the database;and data control language fortransaction management, integrity control, authoriza-tion, and resource management. All these facilities mustbe provided for object-oriented database systems[KIM9Oa, KIM9OdJ. Beyond the features expressed inthese database sublanguages, database systems providevarious facilities, including concurrency control, recov-ery, error reporting, and so on. The semantics of these fa-cilities in object-oriented database systems must be ex-tended/modified to be consistent with the semantics ofthe core object-orien ted concepts. I will e laborate on thispoint in Section 3.2.3.2 Core Object-Oriented Concepts and Data-

base System ArchitectureThe fact that under the core object-oriented datamodel, a class s both the root of an aggregation hierarchyand a class hierarchy has far-reaching consequences onthe architecture of a database system. It impacts thequery model [KIM89d], indexing [MAIE86b, KIM89b],authorization [RAEWO ], schema evolution [BANE87,ZICA89], concurrency control [GARZ88], and physicalclustering [KIM9Od]. In this section, I will make this con-crete only for the query model and indexing. (The re-

--------------------------------------------------------------------------------* In this paper, I will use the terms class and type interchangeably. Although it is correct to dif-ferentiate them, the two concepts are often combined into one term.

4


5/15

mainder of this subsection is taken largely from[KIM9Oa].)Query Model

A query is formulated against a portion of the data-base schema. Since the schema of an object-oriented da-tabase consists of a class hierarchy and an aggregationhierarchy rooted at each of the classes n the database,aquery against an object-oriented database can be veryrich. The semantics of a query in object-oriented data-bases is significantly different from and richer than aquery in standard relational databases.Let us consider a query against a single class;and forthe time being let us ignore the class hierarchy. A queryagainst a class will result in the retrieval of a set of in-stancesof the class hat satisfy user-specified search con-ditions. However, an instance of a class s a nested objectconsisting recursively of instances of the domains of theattributes of the instance. This means hat a query against

a class s really a query against the class and some of thedomains of the attributes of the class. In other words, aquery against a class is formulated against the nesteddefinition of the class.As an example, let us consider the schema of an ex-ample databaseas shown in Figure 1,and the query Findall vehicles that weigh more than 7500 lbs, and that aremanufactured by a company located in Detroit. Thisquery is targeted against the classVehicle, and associatesthe predicate Location = Detroit with the class Com-pany, and the predicate Weight > 7500 with the class

Vehicle.Next, let us introduce the concept of a class hierar-chy to a query, but ignore the nested definition of theclass. There are two meaningful interpretations for thescope of evaluation of such a query. One is obviously allinstances of the target c lass. The other is all instances ofthe classes n the classhierarchy rooted at the target class.This interpretation is correct when the user means thespecified target class o be the generalization of all directand indirect subclassesof the target class. For example,the user may specify the classVehicle as he target class n

a query intending to retrieve all types of vehicle, includ-ing Vehicle, Automobile, Truck, etc. The interpretationof a classas the generalization of all its subclassesmay beextended to the domain of an attribute. For example,when the user specifies the class Company as the domainof the Manufacturer attribute of the classvehicle, the at-tribute may take on as its values objects from the classCompany and any direct or indirect subclassof Company.

-VehicleEnaine

I &&ain /manufacturer I CC moanv

Iom/esticAuto\mobil$ 1 IAutoCoypanyTruckCompan3

+l IJapaneseAutoCompanyclass I subclass linkattribute I domain link

Figure 1. Class Hierarchy andAggregation HierarcyIndexing

The aggregation and generalization relationshipscaptured in an object-oriented data model requirechanges o the semantics of indexes. As I will show below,these relationships suggest different types of indexing:class-hierarchy indexing along a class hierarchy, andnested indexing along an aggregation hierarchy.An index is maintained on an attribute (or a combi-nation of attributes) of a class;an index is logically a list ofpairs c key-value, list of object identifiers > , where thekey-value is a value in the indexed attribute(s), and eachidentifier in the list of ob ject identifiers is the identifier ofan object in which the indexed attribute holds the key-value. For example, an index may be maintained on theWeight attribute of the class Vehicle to expedite theevaluation of queries with a search predicate involvingthe Weight attribute (e.g., Weight = 8000).In relational database systems, one index is main-tained on an attribute (or a combination of attributes) ofone relation. This technique, if applied directly to an ob-

5


6/15

ject-oriented database, will mean that one index isneeded for an attribute of each class. However, since theindexed attribute is common to all c lasses n the class hi-erarchy rooted at the user-specified target class, t makessense to maintain one index on the attribute for all theclasses n the classhierarchy rooted at the target class.Anindex on an attribute of a class and the class hierarchyrooted at the class s called a class-hierarchy index.As we have seen earlier, although a query returns aset of instances of the target class, search predicates maybe specified on any nested attribute of the class.Just as anindex on an attribute of a class s useful for evaluating aquery involving a predicate on the attribute, an index on anested attribute of a class should be useful for a query in-volving a predicate on the attribute. An index on a nestedattribute of a class is called a nested-at&&e in&~. Forexample, the domain of the Manufacturer attribute of theclass Vehicle is the class Company; and the class Com-pany has the Location attribute. Then Location is a

nested attribute of the class Vehicle.3.3 Concerns

I believe that the current concerns about the defini-tion and validity of object-oriented database systemsarebased on the following four major reasons. After statingthem, I will discuss each of them in turn.1. There is no standard object semantics.2. Object-oriented database systems oday arepot-boilers.3. The vendors of early systemsoffered systemswhichseriously lack in database features.4. There is apparently no formal foundation forobject-oriented database systems.1. There is no standard object semantics.Indeed, the only consensusabout object semantics sthat there is no consensus.However, there is a surprising-ly high degree of agreement about a number of high-levelconcepts; these are what I call core object-oriented con-cepts. These concepts are found in many object-orientedprogramming languages and object-oriented databasesystems. believe that, until a standard semantics of ob-jects emerges,a reasonable starting point of research ntoobject-oriented databases is the core object-orientedconcepts. I will saymore about the lack of standard objectsemantics in Section 4.1.2. Object-oriented database systems today are pot-

boilers consisting of five orthogonal elements: object-ori-ented concepts, database features supported in conventionaldatabase systems, many of the database features that are in

the list of shortcomings of conventional database systems,management of memory-resident objects, and object-ori-ented database programming language.

Around the mid-1980s object-oriented databasesystemsbecamea rallying point for research and develop-ment activities in databases,which had been fragmentedinto a number o f seemingly unrelated areas, such as ex-tended relational databases,multimedia databases,spa-tial databases, engineering databases, logic databases,temporal databases, mprecise databases, eal-time data-bases,databaseprogramming languages, and so on. Thatis, the push for object-oriented programming and thepush for solutions to a long list of deficiencies in conven-tional database systemswere translated into object-ori-ented databasesystems. t is for this reason that object-o-riented database systemshave become pot-boilers. I of-fer the following as an extended characterization of ob-ject-oriented database systemsas they are currently be-ing developed.

Object-Oriented Database System =Object-Oriented Concepts +Database Features Supported in

Conventional Database Systems +Memory-Resident Object Management +

Features Specific to CAx Applications +Object-Oriented Database Programming Languages

Note that the definition I gave in Section 3.1 requiredonly the first two elements. The other three elements areembellishments and are certainly orthogonal to object-o-riented concepts. Let us examine how these elementsfound their way into object-oriented database systems.

The impetus for object-oriented database systemscameprimarily from two application domains: object-ori-ented programming environments and CAX. The com-bined data management requirements of these two do-mains represent a significant part of the data manage-ment requirements unfulfilled by conventional databasesystems.The direct support of object semantics for a da-tabaseof persistent and sharable objects s one of the datamanagement requirements that are shared by the do-mains of object-oriented programming and CAx. Thecrying need for enhancing programmer productivity andfor controlling exploding software complexity has led tothe rise in interest in an object-oriented approach to thedesign and implementation of Cku systems,and to the in-tegration of CAx artifacts and tools. The need to directlysupport object semantics n a databasesystem o enhanceprogrammer productivity and to control software com-

G


7/15

plexity is as strong a rationale as any which led to the tran-sition in the past from one generation of databasesystemsto the next.The CAx applications demanded many of the datamanagement requirements which cannot be satisfactorilymet by conventional database systems.The core object-oriented concepts satisfy some of the data-modelling re-

quirements: the aggregation relationship (complexnested objects) and generalization relationship. Addi-tional data modeling requirements, which are not part ofthe core object-oriented concepts, include versions[CHOW%, KATZ361 and composite objects [KIM89c]which capture the version-of relationship and part-of re-lationship, respectively. Additional requirements, whichare not related to data modeling, include long-durationtransactions, checkout and checkin of objects between ashared database and private databases,change notifica-tion, and so on. Various object-oriented databasesystemsoperational today support or plan to support some or allof these features.The two domains of applications which galvanizedthe activities in object-oriented database systems shareone other important requirement, namely, managementof memory-resident objects to support extensive compu-tations. Some applications, such as nteractive simulatorsand editors for VLSI designs, must traverse a large col-lection of objects, recursively from one object to other ob-jects related to it. If, for example, relational databasesys-tems are used to manage objects for such applications,the applications have to use oins to express the traversalfrom one object to other objects [MAIE89a]. Obviously,the combined cost of crossing the boundary between theapplication and the database system, and joining one ob-ject with related ob jects, is simply intolerably expensivefor such applications. A much better solution is to storelogical object identifiers within the objects in the data-base,and convert them to memory pointers to related ob-jects. That is, as an object is fetched from the database,the object identifiers embedded in the ob ject are con-verted to memory pointers that will point to some des-criptors for the objects that the object references (refersto). The referenced objects may ater be fetched as neces-sary, f their descriptors are accessed. his is the approachdeveloped to make objects persistent in the LOOM sys-tem [KAEH81]; this approach has been adopted and re-fined in ORION [KIM88b].

This particular aspect of object-oriented databasesystems has led some implementors of object-orienteddatabase systems to the rather meaningless exercise ofcomparing the performance of memory-resident object

management of their systems with relational databasesystems. t has also contributed mightily to the largelyfalse impression that object-oriented database systemscan only use navigational access o objects, unnecessarilyinviting the criticism that object-oriented database sys-tems are at odds with declarative queries and thus repre-sent a throw-back to the days of hierarchical and CODA-SYL database systems [LAGU88]. I emphasize threepoints to clarify this concern. First, declarative queriescan certainly augment the navigational access n object-oriented database systems,as evidenced by the declara-tive query languages which have been proposed and im-plemented in more recent object-oriented database sys-tems, such as ORION [KIM9Ob], EXTRA/EXCESS[CARE88], and 02 [DEUX90]. Second, systems thatmanage memory-resident objects allow applications todirectly accessmemory-resident objects; one should re-member that conventional database systemsdo not allowapplications to directly accessobjects in the page buffers.Third, systems hat manage memory-resident objects ex-tend the capabilities of databasesystems o these objects.Simply put, object-oriented databasesystemswhich man-age memory-resident objects extend the capabilities ofdatabase systems to the virtual-memory workspace forthe applications; these functions include queries, transac-tion management, integrity enforcement, and so on.

The database languages for (programmatic inter-faces to) object-oriented database systems offered aseemingly excellent opportunity to remove the imped-ance mismatch [COPE841 found in the traditionalembedding of a database anguage in some programminglanguage. The reason is that object-oriented concepts al-ready include such data modeling concepts, found in con-ventional database anguages, as grouping objects into aclass (corresponding to grouping records into a recordtype, or tuples into a relation), aggregation relationshipsbetween an object and objects it consists of (nested ob-jects) , and generalization relationships between a classofobjects and classesof objects specialized from it. The ideaof extending an object-oriented programming languageinto a unified (object-oriented) programming and data-base anguage naturally leads to the notion of an (object-oriented) database programming language [BL0087,ATKI87, DANF88]. The fact that an object-oriented datamodel includes the aggregation and generalization rela-tionships means that an object-oriented databasesystemprovides a user interface for the definition and manipula-tion of the relationships among objects. This in turnmeans that application programmers need not explicitlyprogram and manage these relationships. For example,

7


8/15

the aggregation relationship is the basis of the recursivedefinition of a complex object in terms of other objects.This makes t possible to successively efine the represen-tation of complex objects often found in such applicationsas computer-aided design and engineering and com-pound documents.3. The vendors of early systems offered systems which

seriously lack in database features.In my view, the vendors of early object-oriented da-tabase systemsmisjudged both the size of the market forobject-oriented database systemsand the level of readi-ness to install systems or production use. They offeredsystems that lacked a host of database features whichhave proven their utility during the past three decades.These features primarily include transaction manage-ment, concurrency control, declarative queries, and auto-matic query optimization. This situation unfortunatelyreinforced the impression that object-oriented database

systemsare somehow ncompatible with the semantics oftraditional database eatures. The next-generation data-base technology must necessarily build on conventionaldatabase echnology to meet the requirements of todaysand newly emerging database applications.4. There is apparently no formal foundation for object-

oriented database systems.I hold the view that a core object-oriented datamodel is really one type of extended relational model ofdata. The core object-oriented data model extends theconventional relational model of data as follows. The

starting point for the extension is the approximate equiv-alence of a relation and a class.1. The domain of an attribute of a relation is generalizedto an arbitrary type, rather than a small set of system-de-fined primitive types. This leads to the aggregation hier-archy of classes, and nested objects as instances of thehierarchy.2. The properties of a relation are extended beyond theattributes and constraints on the attributes by addingmethods.3. Each relation is extended with a system-defined attrib-ute, the unique object identifier attribute. An objectidentifier or a set of object identifiers is stored for the val-ue of an attribute of a class whose domain is an arbitraryclass.4.The classesare organized in a hierarchy called a classhierarchy via the generalization ! specialization relation-ship between pairs of classes; he conventional relationalmodel does not organize relations into a corresponding

relation hierarchy.5. The properties of a class are allowed to be recursivelyinherited by its subtypes (subclases); t allows inheritedproperties to be modified in subclasses nd additional at-tributes and methods to be defined for the subclasses.6. The attributes and methods of a classare required to beaccessed nd invoked only by messages sing an explicitlydefined set of interfaces for the class. f a message ent toan instance of a class s undefined for the class, t is sentup the classhierarchy to determine the class n which it isdefined: this is called late binding of messages o objects.

To be sure, it is necessary o formalize a number ofaspectsof the core object-oriented data model; however,the core object-oriented data model is not exactly with-out foundation. The familiar proposals for extending theconventional relational model of data with such conceptsas aggregation, generalization, and surrogates [SMIT77,CODD79] did not engender much controversy in thepast. The points 1,3, and 4 above are merely these sameproposals. The idea of introducing a new type of attributecalled a procedure has been extensively studied and in-corporated into the POSTGRES extended relational da-tabase system [STON87b]; this idea is essentially point 2stated above.4. HURDLES FOR OBJECT-ORIENTED DA-

TABASE SYSTEMSThere are currently at least two proposed ap-proaches for transitioning from the fourth-generationdatabase echnology to the fifth-generation technology:extended relational database echnology and object-ori-ented database technology. The extended relational ap-proach starts with the relational model of data and a rela-tional query language, and extends them in various waysto allow the modeling and manipulation of additional se-mantic relationships and database facilities. The POST-GRES system [STON86b, STON87c, ROWE87], whichhas been prototyped at the University of California atBerkeley, is the best-known next-generation databasesystem which is based on the extended relational ap-proach. The object-oriented approach starts with an ob-ject-oriented data model and a database language that

captures it, and extends them in various ways o allow ad-ditional capabilities.An object-oriented data model is a more natural ba-sis than an extended relational model for addressingsome of the deficiencies of conventional database tech-nology previously outlined; for example, support for gen-eral data types, nested objects, and support for compute-intensive applications. (I note, however, that the underly-


9/15

ing data model has nothing to do with other deficiencies,such as ong-duration transactions, support for long data,and temporal data.) Further, an object-oriented pro-gramming language may be extended into a unified pro-gramming and database language. The resulting lan-guage s subject to the problem of impedance mismatch toa far less extent than the approach of embedding a cur-rent-generation database anguage in one of convention-al programming languages. An object-oriented databasesystem which supports such a unified object-orientedprogramming and database anguage will be a better plat-form for developing object-oriented database applica-tions than an extended relational database system whichsupports an extended relational database anguage.

I believe that both the extended relational and ob-ject-oriented approaches are viable, and that most likelysystemsadopting either approach will co-exist. The casefor the extended relational approach is based largely onthe fact that it is rooted on the familiar current-genera-tion database echnology; for the current-generation da-tabase echnology, there is already a large user/customerbase,and an industry-wide standard for the database an-guage.This is something that proponents of the object-o-riented next-generation database technology cannotclaim. However, object-oriented programming and ob-ject-oriented approach to designing complex softwaresystemsare to date the most promising approach to cop-ing with increasingly complex software systems and thecorresponding costs of developing, maintaining, andevolving such software systems. f the object-oriented ap-proach truly fu lfills its promise in the design and imple-mentation of software and representation of knowledgein future knowledge-based software, object-oriented da-tabase systemswill become crucial.

Once relational systemsare extended with abstractdata types, procedures, nested objects, and object identi-fiers, the distinction between extended relational data-base systems and object-oriented database systems canbecome rather blurred; however, two differences arelikely to remain. One is that extended relational databasesystemsmay support only some subset of the core object-oriented concepts, and such systemswill definitely stopshort of supporting the full semantics of the core object-oriented databasesystems.Another is that extended rela-tional database systems will continue to support SQL-like data languages on what is essentially a conventionaldatabase architecture, and as such they are not likely toreduce impedance mismatch or to provide managementof memory-resident objects.

There are two major hurdles that must be clearedbefore object-oriented database systems can claim itsplace in the era of the fifth-generation databasesystems.These are standardization and performance. I will discussthese issues below.4.1 Standardization

Various groups, such as the ANSI standards com-mittee on object-oriented databases, Object Manage-ment Group, and Open Software Foundation, are now at-tempting to forge standards for different components ofthe object-oriented technology, including object-ori-ented databases. Recently, the Common LISP ObjectSystem CLOS) [MOON891 has been proposed as a stan-dard object-oriented extension to Common LISP Fur-ther, the popularity of C + + will significantly increase,now that AT&T has announced that it will support it[STRO86], and efficient compilers are becoming avail-able, even in the public domain.If one examines existing object-oriented program-ming languages, knowledge representation languages,and semantic data models, one can identify a small set offundamental concepts whose primary semantics are com-mon to almost all o f them, that is, a set of core object-ori-ented concepts. A standard object-oriented data modelwill most certainly include these concepts, because heseconcepts have proven useful already. A useful launchingpoint for research and development in object-orienteddatabases oday is an object-oriented data model whichincludes at the minimum the core object-oriented con-

cepts. An object-oriented database language may thenbe specified for the data model. An object-oriented data-base system may then be constructed to support the lan-guage. This is essentially the approach taken in all cur-rently operational object-oriented database systems;al-though they differ in varying degrees, they pretty muchshare the same set of core concepts. I emphasize that,even if the eventual object-oriented model standard dif-fers in various minor ways rom the core model, the tech-nology for implementing a database system which sup-ports the core model will still be fairly straightforwardlyapplicable to a database system which will support theeventual standard. The reason is that the technology isbased on only the primary semantics of the core object-o-riented concepts.4.2 Performance

Various components of an object-oriented databasesystem must be architected to both support and take ad-vantage of the object-oriented semantics. Secondary n-

9


10/15

dexing, physical clustering, concurrency control, queryoptimization, authorization, and object directory man-agement are the primary components of an object-ori-ented database system which require new architecturaltechniques for satisfactory performance [KIM9Oc].These, except for object directory management, are alsoimportant components of conventional databasesystems;however, the architectural techniques used in conven-tional systems are inadequate or inappropriate for ob-ject-oriented database systems. The discussion of sec-ondary indexing illustrated this point; the class hierarchyand nested objects in object-oriented databasesgive riseto index structures that are designed to expedite the pro-cessing of queries involving them.Object-oriented databaseshave been proposed as aplatform for CAX applications and environments. To besure, object-oriented database systems can satisfy thedata modeling and performance requirements of manyaspects of these applications. However, some of these

applications pose seemingly impossible performance re-quirements to database systems, object-oriented orotherwise. They perform extensive computations on alarge number of interrelated objects; they typically loadall necessaryobjects n virtual memory first and then per-form necessarycomputations on them. The computation-al paradigm of conventional databasesystems s to deliverone object at a time to the application, and does notmatch that of these applications. Some object-orienteddatabase systems have been designed to bring the fullpowers of database systems to bear on in-memory ob-jects. However, they incur substantially higher perform-ance overhead than some of these applications can toler-ate, since the overhead incurred to accessa memory-re-sident object is still an order of magnitude higher thanwhat is necessary or these applications, running withoutan underlying database system, to accessan object in vir-tual memory by a few memory lookups.5. FUTURE R/D DIRECTIONS

Despite the high level o f research and developmentactivities during the past several years, there remain vari-ous technical challenges, beyond standardization andperformance, for researchers and implementors of ob-ject-oriented databasesystems.These challenges includedatabase tools, migration path from conventional data-bases, formalization, additional database facilities, ex-tensible architecture, and performance modeling; theseare all relatively unexplored areas. ( I have tried to men-tion in this section as many relevant topics as reasonable;however, I may have overlooked some worthy topics.) I

will not belabor the need for further work on integratingthe semantics of standard database features and the se-mantics of core objectToriented concepts, n particular, inthe areas of (possibly rule-driven) query optimization[GRAE87], indexing and clustering techniques, concur-rency control to better account for semantic modelingconstructs, extension of authorization to account formandatory and context-based security [THUR89], and soon.5.1 Database Tools

The richness of an object-oriented data model is amixed blessing. On the one hand, it makes it easier forthe users to model their applications. On the other hand,the complexity of the object-oriented database schema,with the class hierarchy and aggregation hierarchies, sig-nificantly complicates the problems of logical and physi-cal database design. Thus the need for friendly and effi-cient design aids for the logical and physical design of ob-ject-oriented databases s significantly stronger than thatfor relational databases. [KIM89b, BERT891 examinesthe properties of class-hierarchy indexes and nested-at-tribute indexes and their use in expediting the evaluationof object-oriented queries. The current research intostorage structures for non-first normal form relationaldatabases s certainly relevant for the physical design ofobject-oriented databases [DESH88]. The frameworkfor the evolution of an object-oriented database schemadiscussed in [SKAR86, BANE87, PENN87, ZICA89]represents important first steps towards the logical de-sign of object-oriented databases.

A programmatic interface to a database system istoo low level a tool for application development, and ven-dors of conventional database systemsoffer a number ofadditional tools as higher level interfaces to a databasesystem to help non-programmers to develop applica-tions. These interfaces include forms, menus, and graph-ics. The IRIS [FISH891 and 02 [DEUXSKI] projects havedeveloped first-generation graphical interfaces to theirdatabase systems o allow non-programmers to browsethe database schema and issue queries. However, high-level user interfaces remain an area of research not onlyfor object-oriented databases,but also for conventionaldatabases.5.2 Migration Path from Conventional Data-

basesA system or managing a heterogeneous mix of data-bases s important as a migration path between relationaldatabases o object-oriented databases,and is essential

10


11/15

for object-oriented databasesystems o take root. One vi-able approach is the development of an object-orientedSQL which is compatible with SQL; however, this ap-proach will leave the impedance-mismatch problem un-resolved. A preliminary proposal for such a language isreported in [BEEC88].Another interesting line of research is the object-o-

riented approach to the management of a heterogeneousmix of databases, n particular, a mix of object-orienteddatabasesand conventional databases. t is highly desir-able to allow the user to accessa heterogeneous mix ofdatabases under the illusion of a single common datamodel [DAYA84, LITW88]. For example, suppose thatan Employee database is managed by a relational data-base system, a Product database s managed by a hierar-chical database system, and a Company database s man-agedby an object-oriented databasesystem.An object-o-riented data model may be used as the common datamodel for presenting the schemasof these different data-bases o the user. The richness of an object-oriented datamodel makes it appropriate for use as the common datamodel for representing a broad range of data models.Further, since object-oriented design and programmingpromotes extensibility, it may be used for designing andimplementing a system to manage a heterogeneous mixof databaseswhich can accommodate he addition of newtypes of database.5.3 Formalization

The primary aspect of the core object-oriented datamodel which requires a formal basis is the query modelwhich takes into account methods, and both the aggrega-tion and class hierarchies. There have been a few recentproposals for such a query model which should provide agood basis for further research [KIM89d, CLUE89,SHAW89]. The query model for a core object-orienteddata model is more general than that for the nested rela-tional data model for two reasons. First, the aggregationhierarchy is actually a graph which admits cycles, whereasa nested relation is a strict hierarchy. Second, he core ob-ject-oriented data model includes a generalization hier-archy, which the nested relational data model does nothave. Therefore, the lowerbound for the expressivepow-er of a query language for a core object-oriented datamodel is that of a nested relational query language.

The concepts of extensible class hierarchy, inheri-tance along the classhierarchy, and late binding along theclass hierarchy are new concepts to database systemswhich do require precise analysis of semantics. Further,the notions of integrity constraints should be defined

anew for the core object-oriented schema which now in-cludes an aggregation hierarchy and a class hierarchy forevery class n the database.Recently, there have been worthy efforts to providea logic-based formalism for the core object-oriented con-cepts by extending first-order logic with the semantics ofobject identity, inheritance, nested objects, and declara-

tive functions [KIFE89a, KIFE89b, ABIT89, ZANI89].In view of the power of predicates for expressing con-straints, the discovery that the core object-oriented con-cepts can indeed be expressed using the logic formalismwas perhaps inevitable. This line o f research is also valu-able to lay the foundation for the integration of rules(goal-directed reasoning) into object-oriented data-bases.5.4 Additional Database FeaturesViews

In relational databases,a view is defined as a virtualrelation derived by a query on one or more stored rela-tions. The relational operations join, select, and projectmay be used to define a view. Views have been used fordata protection and as a shorthand for queries. A querymay be issued against views ust as though they were rela-tions. Further, authorization may be granted and re-voked on views as on relations, allowing content-basedauthorization on stored relations. Views are also used asexternal schemasderived from an underlying schema.Views are useful for object-oriented databases orsimilar reasons. Views may be used to specify logical par-

titioning of the instances of a class. Views may be used todefine content-based authorizations in object-orienteddatabases; hat is, views allow only the objects that satisfyspecified authorization conditions to be made visible. Theview mechanism may be used as one form of schemaver-sioning [KIM88a] to allow the users of a database o ex-periment with schema changes without introducing per-manent changes to the contents of the database. To thebest of our knowledge, no object-oriented database sys-tem supports views at this time; in fact, I do not know atthis time of any published account of research into viewsin object-oriented databases.Semantic Modeling

One area of research, although rather tangential toobject-oriented databases, s to augment the data model-ing power of the core object-oriented concepts with se-mantic data modeling concepts, particularly, versions andcomposite objects. There may be additional semanticmodeling concepts which are important for some major

11


12/15

applications; a worthy example is the modeling of roles[PERN90]. Just as versions and composite objects neces-sitated extensions and changes o the architecture of a da-tabase system, we expect that some of the additional se-mantic modeling concepts will have further impacts onthe architecture of an object-oriented database system,including query evaluation, storage structures, and con-currency control.Deductive Capabilities

Deductive databaseshas been an area of active re-search during the past decade. The objective of deductivedatabases s to integrate rules and traditional databaseoffacts in support of complex reasoning which is not possi-ble with queries against a traditional database. Much ofthe research has been focused on extending logic pro-gramming with database facilities [BANC86, TSUR86].A rule system has been interfaced to ORION [BALL88],a rule manager has been incorporated into POSTGRES[STON87a], and IRIS presently provides a rudimentarysupport for rules [FISH89]. However, there is no object-oriented databasesystem hat can be regarded asa deduc-tive database system. An object-oriented database sys-tem will become a deductive object-oriented databasesystem once it can directly support rules and various rea-soning concepts, such as truth maintenance and contra-diction resolution. The current research is focused on ex-tending an object-oriented database nterface with rulespecification and rule invocation. The issues of embed-ding various reasoning concepts, besides the forward andbackward chaining of rules, directly in a databasesystemhave not been explored.5.5 Extensible ArchitectureAbstract Data ljpes

As pointed out in [BL0087], the creation of user-defined types (often called abstract data types) has somedifficult and interesting consequences on database sys-tem architecture. [STON86a] discusseshow abstract datatypes may be incorporated into a relational database sys-tem. Abstract data types often require type-specific datastructures for storing objects. Much of the past researchinto efficient implementation of abstract data types hasbeen concerned with rectangular shapes n the context ofVLSI layouts [STON83, BANE86]. The problem of effi-ciently implementing user-defined operations on user-defined types is an open-ended one, specific to the se-mantics of user-defined types. An interesting issue is tointegrate user-defined predicates on user-defined types

.2

into the optimization framework which has been devel-oped for standard queries, that is, queries involving in-volving atomic data types and standard comparison oper-ators. To the best of my knowledge, this issue has not beenseriously addressed.Semantic Extensions

Designers of database systems have traditionallyshied away from capturing the semantics of data, largelybecause t has been very difficult to find consensusamongusers. One example is versions. There is no consensusonthe semantics of any type of version: versions of a singleobject, versions of a composite object [KIM89c], versionsof a class [SKAR86], and versions of schema [KIM88a].The few systemswhich have implemented versions (onlyof single objects), namely, ORION [CHOUSS] and IRIS[FISH89], have implemented their own models of ver-sions. Since the semantics of versions tend to differ in va-rying degrees from installation to installation, a worth-while approach may be to provide a layered architecturefor versions. The lower level may support a basic mecha-nism for low-level version semantics that are common tovarious proposals; the higher level may be made extens-ible to allow easy ailoring of installation-specific versionsemantics.This approach should be explored not only forversions but also for other semantic modeling concepts,such as composite objects, and even authorization; thisline of research will complement the current researchinto extensible database systems [CARE86, BAT088,LIND87].5.6 Performance Benchmarking

There is a clear need for performance modeling,and a meaningful and common benchmark for ob ject-ori-ented databasesystemswhich will improve on the prelim-inary benchmarks [RUBE87]. Relational databasebenchmarks, such as he Wisconsin benchmark [BITT83],cannot really be used for object-oriented database sys-tems, since operations supported in object-oriented data-base systemsand relational databasesystemsonly partial-ly overlap. For example, relational systemsdo not supportoperations based on concepts such as inheritance (classhierarchy), methods, object navigation (through objectidentifiers), and nested objects (hierarchy of inter-re-lated objects). Further, object-oriented databasesystemstend to be designed to support compute-intensive appli-cations on memory-resident objects in their in-memorydata structure; relational systemshave not fared well forsuch applications. The benchmark for object-orienteddatabase systems should not only be meaningful for ob-ject-oriented databases,but also be useful in allowing a


13/15

meaningful comparison with conventional database sys-tems.6. SUMMARY

The area of object-oriented databaseshas come along way during the past several years. After a few yearsof confusion, concerns, and high expectations, the areashows signs of reasonable maturity. In this paper, I of-fered both a minimal and extended definition of object-o-riented database systems on the basis of a reflection onthe history of evolution of database systems and theemergence of object-oriented programming. On the ba-sis of these definitions, I addressedmajor reasons or theconcerns and questions about the field of object-orienteddatabase systems that have persisted, and outlined theimpact of ob ject-oriented concepts on database systemarchitecture. Then I discussed he issues of standardiza-tion and performance, the two fundamental hurdles thatexist today for ob ject-oriented databasesystems,and out-lined several areas of research which not been well ex-plored thus far.

REFERENCES[ABIT89] Abiteboul, S., and P Kanellakis. ObjectIdentity as a Query Language Primitive, in Proc.ACM SIGMOD Intl. Co@ on Management of Data,Portland, Oregon, May 1989.ATK1!Z!rsistenceAtkinson, M., and I? Buneman. Types andln Database ProerammineLanguages, ACM Computing Surveys, v%l. 19,n;2, June 1987.[ ATKI89] Atkinson, M., et al. Object-OrientedDatabase System Manifesto, in Proc. 1st Intl.Conf on Deductive and Object-Oriented Databases ,Kyoto, Japan, Dec. 1989.[BALL881 Ballou, N., et al. Coupling an ExpertSystem Shell with an Object-Onented DatabaseSystem, Journal of Object-OrientedTE ;amming, vol. 1, no. 2, June/July 1988, pp.5.[BANC86] Bancilhon, F., and R. Ramakrishnan. AnAmateurs Introduction to Recursive QueryProcessin Strategies,P in Proc. ACM SIGMODIntl. Con . on Management of Data, Washington,D.C., 1986.[BANE861 Banerjee, J., and W. Kim. SupportingVLSI Geometry Operations in a DatabaseSystem, in Proc. 2nd Intl Conference on DataEngineering, Feb. 1986, Los Angeles, Calif.[BANEzz71h Brtnerjee, J., W. Kim, H.J. Kim, and H.F.

Schema Semantics and Implementatton ofEvolution Object-OrientedDatabases, in Proc. ACM%GMOD Intl. Conf onManagement of Data, San Francisco, Calif., May1987.

[BAT0881 Batory, D., et al. GENESIS: AnExtensible Database Management System,ZEEETrans. on Software Engineering, vol. 14,no. 11,Nov.1988.[BEEC88] Beech, D. OSQL: A Language forMigrating from SQL to Object Databases, inProc. Intl. Conf. on Extending Data BaseTechnology, Venice, Italy, March 1988.[BERT891 Bertino, E., and W. Kim. IndexingTechniques for Queries on Nested Objects, IEEEgj~&. on Knowledge and Data Engineermg, Oct.

[BHT83] Bitton, D., D. Dewitt, and C. Thrbyfill.Benchmarking Database Systems: A SystematicApproach, in Proc. Intl. Conf on Very Large DataBases, Oct. 1983.[BL0087] Bloos T, and S. Zdonik. Issues in theDesign Object-Oriented DatabaseProgramming Languages, in Proc. 2nd Intl. ConfObject-Oriented Programming Systems,znguages, and Applications, Orlando, Florida,Oct. 1987.[CARE861 Carey, M., D. Dewitt, J.E. Richardson, andE.J. Shekita. Object and File Management in theEXODUS Extensible Database System, Proc.12th Intl Conf on K&y Large Data Bases, August1986,Kyoto, Japan, pp. 91-100.[CARE881 Carey, M., D. Dewitt, and S. Vandenberg.A Data Model and Query Langua eEXODUS, in Proc. ACM SIGMOD Intl. t foronf onp3n;y3rnent of Data, Chicago, Ill., June 1988,pp.[CHEN76] dhen, P The Entity-Relationship Model:Toward a Unified View of Data, ACM Trans. onDatabase Systems,vol. 1, no. 1, Jan. 1976, pp. 9-36.[CHOU86] Chou, H.T., and W. Kim. A UnifyingFramework for Versions in a CAD Environment, in Proc. Intl Conf on tiry Large Data Bases, August

1986,Kyoto, Japan.[CHOUSS] Chou, H.T., and W. Kim. Versions andChange Notification in an Object-OrientedDatabase System, in Proc. Design AutomationConference, June 1988.[CLUEizhar%tei, S., C. Delobel, C. Lecluse, and PReloop: An Algebra-Based QueryLanguage for an Object-Oriented DatabaseSystem, in Proc. 1st Intl. Conf on Deductive andObject-Oriented Databases, Kyoto, Japan, Dec.1989.[CODD79] Codd, E.F.Model to Ca Extending the Relationalon Database ystems, vol. 4, no. 4, Dec. 1979.ture More Meaning, ACM Trans.[COPE841 Copeland, G., and D. Maier. MakingSmalltalk a Database Svstem. in Proc. ACMSIGMOD Intl. Conf on kanagement of Data, June1984, pp. 316-325.[DANF88] Danforth, S., and C. Tomlinson. TypeTheories and Ob ect-OrientedACM Computing J Programming,urveys, vol. 20, no. 1, March1988,pp. 29-72.[DAYA84] Dayal, U., H. Hwang. View Definitionand Generalization for Database Integration in a

13


14/15

Multidatabase Svstem. IEEE Trans. on SoftwareE&iip vol.- SE-lo, no. 6, Nov. 1984, pp.[DESH88] Deshpande, $.o,;andzestFdn Gucht. AnImplementation RelationalDatabases,Bases, 1988. in Proc. Intl. Conf on Very Large Data[DEUX90] Deux, O., et al. The Story of 02, IEEETrans. on Knowledge and Data Engineering, March[FISH:97 Fishman, D., et al. Overview of the IRISDBMS, Object-Orien ted Concepts, Applications,and Databases, (ed. W. Kim, and F. Lochovsky),Addison-Wesley, 1989.[GARZ88] Garza, J., and W. Kim. TransactionManagement in an Object-Oriented DatabaseSystem, in Proc. ACM SIGMOD Intl. Con . onManagement of Data, Chicago, Ill., June 198 f[GOLD821 ~a~~a~ A. an: D. Robson.Smalltalk~80:

1ts Implementation,Addison-Wesley, Reading, MA 1983.[GRAE87] Graefe, G., and D. Dewitt. TheEXODUS 0 timizer Generator, in Proc. ACMSIGMOD Int . Conf on Management of Data, SanFrancisco, Calif., May 1987.[HAMM81] Hammer, M., and D. McLeod. DatabaseDescription with SDM: A Semantic Data Model,ACM Trans. on Database Systems, vol. 6, no. 3,Sept. 1981.[HULL871 Hull, R., and R. King. Semantic DatabaseModeling: Survey, Applications, and ResearchIssues, ACM Computing Surveys, vol. 19, no. 3,Sept. 1987, pp. 201-260.[KAEH81] Kaehler, T. Virtual Memory for anOblect-Oriented Language, BTTE, pp. 378-387,August 1981.[KATZ861 Katz, R.,Version E. Chang, and R. Bhatea.Modeling Concepts iJComputer-Aided Design Databases, In Pro?ACM SIGMOD Intl. Conf on Management of Data,Washington, D.C., May 1986,pp. 379-386.[KIFE89a] Kifer, M., and J. Wu. A Logic forOblect-Oriented Logic Pro ramming,ACM SIGACT-SIGMOD- IGART Sympo. onin Proc.Principles of Database Systems, March 1989.[KIFE89b] Kifer, M., and G. Lausen. F-Logic: AHigher-Order Language for Reasoning aboutObects, Inheritance, and Scheme, in Proc. ACMdI MOD Intl. Conf on Management of Data,Portland, Oregon, May 1989.

]KIM8#tabasesVersions o f Schema for Object-Oriented, (with H.T. Chou) in Proc. Intl. ConfyG8zv Large Data Bases, Long Beach, Cahf., Sept.[KIM88b] Kim? W., et al.Object-Onented Programmin Integrating anDatabase System, in Proc. 5 System with ard Intl. Conf onObject-Oriented Programming Systems, Languages,and Applications, San Diego, Calif., Sept. 1988.[ KIM89a] Kim, W. and F. Lochovsky. Object-OrientedConcepts, Applications, and Databases, (ed. W.Kim, and F. Lochovslo/), Addison-Wesley, 1989.

[KIM89b] Kim, W., K.C. Kim, and A. Dale. IndexingTechniques for Object-Oriented Databases,Object-Oriented Concepts, Applications, andDatabases, (ed. W. Kim, and F. Lochovsky),Addison-Wesley, 1989.[KIM89c] Kim, W., E. Bertino, and J. Garza.Composite Objects Revisited, in Proc. ACMSIGMOD Intl. Conf on Management of Data,Portland, Oregon, June 1989.[KIM89d] Kim, W. A Model of Queries forObject-Onented Databases, in Proc. Intl. Con.on Very Large Data Bases, August d98 ,Amsterdam, Netherlands.[KIM9Oa] Kim, W. Object-Oriented DatabaseSystems: Mandatory Rules and Prospects,Datamation, Jan. 15 and Feb. 1, 1990[ KIM9Ob] Kim, W. et al. Architecture of the ORIONNext-Generation Database System, IEEE Trans.on knowledge and Data Engineering, March 1990.[ KIM9Oc] Kim, W. Architectural Issues inObject-Oriented Databases, Journal ofObject-Oriented Programming, March/April, 1990.[ KIMgOd] Kim, W. Introduction to Object-Orien tedDatabases, MIT Press, May 1990.[KIMgOe] Kim, W. Object-Oriented Databases:Definition and Research Directions, IEEE Trans.on Knowledge and Data Engineering, June 1990.[LAGU88] Laguna Beach Report on the FutureDirections for Database Research, presented as apanel position paper at the Intl. Conf on K+y LargeData Bases, Long Beach, Calif. Sept. 1988.[LECL88] Lecluse, C., F?Richard, and F. Velez. 02,an Object-Oriented Data Model, in Proc. ACMSIGMOD Intl. Con. on Management of Data,Chicago, Ill, June 1d88, pp. 424-433.[LIND~~~aheindsay, B., J. McPherson, and .H.A Data Mana ementArchitecture, B Extensionin Proc. ACM IGMOD Intl. Conf

on Management ofData, San Francisco, Calif., May1987,pp. 220-226.[LITWSS] Litwin, W. From Database Systems toMultidatabase Systems:Why and How, in Proc.6th British National Conf on Databases, July 1988,pp. 161-188.[MAIE86a] Maier, D. A Logic for Objects, in Proc.Workshop on Foundations of Deductive and LogicProgramming, Washington, D.C., August, 1986.[MAIE86b] Maier, D., and J. Stein. Indexing in anObject-Oriented DBMS, in Proc. Intl. Workshopon Object-Oriented Database Systems, Languages,Pacific Grove, Calif., Sept. 1986.[MAIE89a] Maier, D. Making Database SystemsFastEnough for CAD Applications, Object-OrientedConcepts, Applications, and Databases, (ed. W.Kim, and F. Lochovsky), Addison-Wesley, 1989.[MAIE89b] Maier, D. Why Isnt There anObject-Oriented Data Model, in Proc. IFIP IIthWorld Computer Congress, San Francisco, Calif.,August 1989.[MICA881 Micallef, J.and Encapsulation, Reusability,Extensibility inProgramming Oblect-OrientedLanguages, Journal of

14


15/15

Object-Oriented Programming, Vol. 1, No. 1,April/May 1988, pp. 12-36.[MINS75] Minsky, M. A Framework forRepresenting Knowledge, The Psychology ofComputer F&ion, (ed. P Winston), McGraw-Hill,New York, 1975.[MOON891 Moon, D. The Common LISPObject-Oriented Programming StandardSystem, Object-Oriented Concepts, Applications,and Databases, (ed. W. Kim, and F. Lochovsky),Addison-Wesley, 1989.[PENN871 Penney, J., and J. Stein. ClassModification 111he Gemstone Object-OrientedDBMS, in Proc. 2nd Intl. Conf on Object-OrientedProgramming Systems,Languages, and Applications,Orlando, Florida, Oct. 1987.[PERN90] Pemici, B. Obects with Roles, in Proc.ACM Conf on 0 ce Information Systems,Cambridge, Mass., April 1990.]RAB1$elk Rabitti, F., E. Bertino, W. Kim, and D.A Model of Authorization forNext-Generation Database Systems, o appear nACM Trans. on Database Systems.[RELE89] Release 1.0, Sept. 1989, EDventureHoldings, Inc., 375 Park Ave., New York, NY.[ROWE87PO Rowe, L., and M. Stonebraker. TheTGRES Data Model, in Proc. Intl. Conf onJ&y Large Data Bases, Brighton, England, Sept.1987,pp. 83-95.[RUBE87] Rubenstem, W., M. Kubicar, and R. Cattell.Benchmarking Simple Database Operations, inProc. ACM SIGMOD Intl. Conf on Management ofData,387-394.San Francisco, Calif., May 1987, pp.[SELI79] Selinger, PG. et. al. AccessPath Selectionin a Relational Database Management System, inProc. ACM SIGMOD Intl. Conf on Management ofData, Boston, Mass. pp 23-34, 1979.[SHAW89] Shaw, G., and S. Zdonik.Object-Oriented Queries: Equivalence andOptimization, in Proc. 1st Intl. Conf on Deductiveand Object-Oriented Databases, Kyoto, Japan,Dec. 1989.[SHIP811 Shipman, D. The Functional Data Modeland the Data Language DUPLEX, ACM Trans.on Database Systems, vol. 6, no. 1, March 1981.[ SKAR86] Skarra, A., and S. Zdonik. TheManagement of Changing Types in anObject-Oriented Database, in Proc. Ist Intl. ConfObject-Oriented Programming Systems,{yguagz and Applications, Portland, Oregon,[SMIT77] mith, J., and D. Smith. DatabaseAbstraction: Aggregation and Generalization,ACM Trans. on Database Systems, vol. 2, no. 2,June 1977,pp. 105-133.

[STEF86] Stefik, M. and D.G. Bobrow.Object-Oriented Programming: Themes and$..$kns, The AI Magazine, January 1986, pp.[STONtt\tmS$mebraker, M., B. Rubenstein, and A.. Application of Abstract Data Typesand Abstract Indices to CAD Data Bases,in Proc.Databases for Engineering Applications, DatabaseWeek 1983 (ACM), San Jose, Calif., May 1983,.[STON86a] Stonebraker, M. Inclusion of New Typesin Relational Database System, in Proc. 2nd Intl.Conf on Data Engineering, Los Angeles, Calif.,Feb. 1986,pp. 262-269.[STON86b] Stonebraker, M., and L. Rowe. TheDesign of POSTGRES, in Proc. ACM SIGMODIntl. Conf on Management of Data, Washington,DC., May 1986.[STONipig Stmebraker, M., E. Hanson, and C.H.

System, The Design of the POSTGRES Rulein Proc. Intl. Conf on Data Engineering,Feb. 1987, Los Angeles, Calif., pp. 356-374.[STON87b] Stonebraker, M., J. Anton, and E. Hanson.Extending a Database System with Procedures,ACM Trans. on Database Systems, vol. 12, no. 3,Sept. 1987.[STON87c] Stonebraker, M. The Design of thePOSTGRES Storage System, in Proc. Intl. Confon VeryLarge Data Bases, Brighton, England, Sept.1987.[SIR0861 Stroustrup, B. The C+ + ProgrammingLanguage, Addison-Wesley, Reading, Mass. 1986.[SIR0881 Stroustrup, B. What is Object-OrientedF; ;mmmg?,s IEEE Software, May 1988, pp.[THUR89] Thuraisingham, M.B. Mandatory andDiscretionary Security Issues in Object-OnentedDatabase Systems, in Proc. Object-OrientedProgramming Systems,Languages, and Applications,Oct. 1989, New Orleans, Louisiana.[TSUR86] ISur, S., and C. Zaniolo. LDL: aLogic-Based Data Language, in Proc. 12th Intl.Conf on Very Large Data Bases, August 1986,Kyoto, Japan.[WOEL87] Woelk, D., and W. Kim. MultimediaInformation Management in an Object-OrientedDatabase System, in Proc. Intl. Conf on VeryLargeff;f3f;es , Brtghton, England, Sept. 1987, pp.

[ZANI89] aniolo, C. Object Identity andInheritance in Deductive Databases -- AnEvolutionary ADeductive and 8 preach, in Proc. 1st Intl. Conf onbject-Oriented Databases, Kyoto,Japan, Dec. 1989.[ZICA89] Zicari, R. Schema U$ ates in the 02Object-Oriented Database ystem, AltairTechnical Report no. 89-057, Oct. 1989.

15

cl1 02 wom kim cl1 research directions in object oriented database systems

Documents