JUNE1991,Volume 14, No. 2
a quarterlybulletin of the IEEEComputerSociety technicalcommittee on Data Engineering
CONTENTS
Letterfrom the IssueEditor 1 RakeshAgrawal
TheTwo Facets of Object—Oriented DataModels 3 SergeAbiteboulandParisC.Kanellakis
TheoreticalFoundations for OODB’s — a PersonalPerspective 8 CatrielBeen
A First—OrderFormalization of Object—OrientedLanguages 13 MichaelKifer
On DataRestructuring and Mergingwith ObjectIdentity 18 RichardHull, SurjatiniWidjojo,Dave Wile, andMasatoshiYoshikawa
DataStructuresand DataTypes for Object—OrientedDatabases 23 Vat Breazu—Tannen,PeterBuneman, andAtsushiOhori
Foundations of the 02 DatabaseSystem 28 C. Lecluseand P. Richard
Updating the Schema of an Object—OrientedDatabase 33 AlbertaCoen—Porisini~LuigiLavazza, andRobertoZicari
An Overview of IntegrityManagement in Object—OrientedDatabases 38 WonKim, Yoon—JoonLee, andJungyunSeo
SupportingViews in Object—OrientedDatabases 43 Marc H. SchollandH.—J.Schek
AlgebraicQueryProcessing in EXTRA/EXCESS 48 Scott L. VandenbergandDavid J. DeWitt
ENCORE: An Object—OrientedApproach to DatabaseModelingand’Querying 53 Stanley B. ZdonikandGailMitchell
QueryOptimization in Revelation, an Overview 58 ScottDaniels,GoetzGraefe,ThomasKeller,DavidMaier, Dun Schmidt, andBennetVance
Calls for Papers 63
SPECIALISSUE ON FOUNDATIONS OF OBJECT—ORIENTEDDATABASESYSTEMS 1951-1991
THE EISTTTUIE ~ ELECTEJCAL — + ~ ~. IEEE June1991,Volume 14, No.2
Editor—In—Chief,DataEngineering Chairperson, TC Dr. Won Kim Prof.JohnCarlis UNISQL, Inc. Dept. of ComputerScience 9390ResearchBoulevard University of Minnesota Austin, TX 78759 Minneapolis, MN 55455 (512)343—7297
AssociateEditors PastChairperson, IC Dr. RakeshAgrawal ProfLarryKerschberg IBMAlmadonResearchCenter Dept. of InformationSystemsandSystemsEngineering 650 HarryRoad GeorgeMasonUniversity SanJose,Calif. 95120 4400UniversityDrive (408)927—1734 Fairfax, VA 22030 S (703)764—6192
Prof.AhmedElmagarmid Distribution Department of ComputerSciences PurdueUniversity IEEEComputerSociety WestLafayette,Indiana47907 1730MassachusettsAve. (317)494—1998 Washington,D.C. 20036—1903 (202)371—1012
Prof. YannisIoannidis Department of ComputerSciences University of Wisconsin Madison,Wisconsin 53706 (608)263—7764
Prof. Kyu—YoungWhang Department of ComputerScience KAIST P.O. Box 150 Chung—Ryang,Seoul,Korea
DataEngineeringBulletin is a quarterlypublication of Opinionsexpressed in contributions are those of the the IEEEComputerSocietyTechnicalCommittee on individualauthorratherthan the officialposition of DataEngineering. Its scope of interestincludes:data the TC on DataEngineering, the IEEEComputer structuresand models,accessstrategies,access Society, or organizations with which the authormay controltechniques,databasearchitecture,database be affiliated. machines,intelligentfrontends,massstorage for verylargedatabases,distributeddatabasesystems and techniques,databasesoftwaredesign and im Membership in the DataEngineeringTechnical plementation,databaseutilities,databasesecurity Committee is open to individualswhodemonstrate and relatedareas. willingness to activelyparticipate in the variousacti vities of the TC. A member of the IEEEComputer Society mayjoin the TC as a full member. A non— Contribution to the Bulletin is herebysolicited.News member of the ComputerSociety mayjoin as a par items,letters,technicalpapers,bookreviews,meet ticipatingmember, with approvalfrom at leastone ing previews,summaries,casestudies, etc., should officer of the TC. Both full members and participat be sent to the Editor. All letters to the Editor will be ing members of the TC are entitled to receive the considered for publicationunlessaccompanied by a quarterlybulletin of the TC free of charge, untilfur request to the contrary.Technicalpapers are unre thernotice. formed. Letterfrom the IssueEditor
TheoreticalFoundations of Object-OrientedDatabaseSystems
Object-orientation has emerged as a major theme in current work on databasesystems, and several reseaithprototypes and commercialdatabaseproductsbased on object-orientedparadigm are in different stages of development. The enthusiasm and energy devoted to the development of object-oriented databasesystemsmatch, if not exceed, the development effort spent on relationalsystems in the late seventies and earlyeighties.Interestingly,however, the development of object-orienteddatabasesystems has taken a verydifferentevolutionarypath. While the relationalsystemsstarted with a strongtheoretical foundation, there is no consensus yet on a formal theory for object-oriented database systems. Experimentalsystemsandproductsseem to be driving this field at this stage.
This issuepresents a sampling of some recentattempts to provide a theoreticalfoundation for object- orienteddatabasesystems. The issuecuntains 12 papers. Thesepaperscovervariousaspects of object- orienteddatabasesystems,includingmodeling,schemaevolution,integrityconstraints,views, and queries.
Abiteboul and Kanellakis point out the two facets of object-oriented data models — structural and behavioral — thatreflect the twoorigins ofobject-orienteddatabasesystems — relationaldatabasetheory andobject-orientedprogramming. Theyformalize and analyzethese twofacets andgiveexamples of their integration.
Been argues for the extension of the existinglogic-basedapproaches to databases and programming languages for modelingobject-orienteddatabasesystems. He presents an initial modelapproach that unifies the theories of relationaldatabases,deductiveprogramming, and abstract data types. He also argues for functions as first class values and a flexiblefunctiondefinitionfacility to modelbehavioral aspects of object-orienteddatabasesystems.
Kiferpresents the salientfeatures of F-logic that make it possible to provide a full logicalformalization of object-orientedlanguages. F-logicbreaks the distinctionbetweenclasses,objects, and attributeswhich allowsqueries that may return sets of attributes,classes, or any other aggregation that involves these higher-orderentities. It is alsopossible to defineparametricclasses in F-logic.
Object identity is a central concept in object-orienteddatabasesystems. Hull, Widjojo, Wile, and Yoshikawadifferentiatebetweenobjectidentities and values,describe a formalmodelwhichencompasses objectidentities and values, and examine the impact of objectidentity in the contexts of data structuring and merging.
Breazu-Tannen,Buneman, and Ohori argue that the object-oriented database systems can be best understood in the framework of typed languages. They address the demandsplaced on programming languages by the addition of operations on records and “bulk” datatypessuch as sets.
Lecluse and Richard describe the foundations of the 02 database system. The 02 data model differentiatesbetweenvalues and objects, and between types and classes. It also supports the notions of the consistency of a classhierarchy and databaseschema.
Coen-Ponsini,Lavazza, and Zicariaddress the problem of schemaevaluation in object-orienteddatabase systems. Theydifferentiatebetweenstructural and behavioralconsistency of a schema and outline their solutions for maintainingschemaconsistency in the presence of schemamodifications.
Object-oriented data models give rise to additionalconstraints beyond those meaningful under the relational model. Kim, Lee, and Seo present a framework for classifyingintegrityconstraints in the context of an object-oriented datamodel on the basis of theirperformanceimpact.
Scholl and Schek describe how views may be supported in object-orienteddatabasesystems. They how introduceobject-preserving querysemantics of a genericobject-oriented querylanguage and show viewsdefined by suchqueryexpressions may be updated.Dynamicreclassificationallowsobjects to gain and loosetypes.
1 Vandenberg and DeWiudescribe the algebraicfundamentalsunderlying the processing and optimization of EXCESSqueries in the EXTRA/EXCESSDBMS. They describe the algebraicstructures and their operators, the algebra’sexpressivepower, and the algebraicqueryoptimization.
Zdonikand Mitchellpresent the ENCOREdatamodel and its queryalgebra,calledEQUAL. Thisalgebra generalizesrelationaloperations by providing the capability to access and produceencapsulated,logically complexobjects.
Finally,Daniels,(Iraefe,Keller,Maier,Schmidt, and Vancediscussqueryoptimization in object-oriented databases in the context of Revelationproject. Theydescnbemodelingfeatures that supportuser-defined data types,consider their impact on queryoptimization, and discuss the Revelationapproach to these problems.
Beforeclosing, I would like to thank the authors for providingexcellentpapers at a shortnotice. It is my fondhopethat this issuewill provideimpetus for furtherreseaith in this importantarea.
RakeshAgrawal IBMAlmadenResearchCenter SanJose,California95120
THE JUHF~H~IFhIN~ ~U9T~~IFIL~EElF1E~H
(.i.s ~urwui:r~i~ui~:sr FEIISF~ W1TF~ U~LITE~
A NationalSearch forcomputerbased applications to help persons with physical or learningdisabilities is be ing conducted by The JohnsHopkins University with grants from the Na tional ScienceFoundation and MCI CommunicationsCorporation.
A grandprizeof$10,000andmorethan 100 otherprizes will be awarded for the best ideas, systems,devices and computerprograms developed by Professionals,Amateurs,andStudents. Entrydeadline is August 23, 1991.
Formore informationwrite to Computing to AssistPersons withDisabilities P.O. Box 1200 Laurel,MD20723
2 The TwoFacets of Object-OrientedDataModels
SERGEABITEBOULS PARIS C. KANELLAKISt
0. Introduction:Object-orienteddatabasesystems(OODBs) are new softwaresystemsbuiltusingtechniquesfrom databases,object-orientedlanguages,programmingenvironments and user interfaces; for examples of this emerging technology see the editedcollections KL 89, ZM 90, BDK 91]. Unfortunately, there has been less progress on understanding the principles of OODBs. This is”in markedcontrast with the elements of relationaldatabasetheory, see U 88] and vL 90—ch.17].Generallyaccepteddefinitions of object-orienteddata models (as in A+ 89]) are still no morethan a list of desirableconcepts, with littleintegration or analysis. The conceptsthemselves can be divided in two categories,whichreflect their origins: fromrelationaldatabasetheory or fromobject-orientedprogramming. Each of these two facets of object-oriented data modelsinvolvesbothdatadescription and datamanipulation. So the division is not one of type-description vs type-manipulation, but rather one of concrete (or structural) vs abstract (or behavioural) typedisciplines. Key issues are formalizing the individualfacets and their integration.
In this short survey we: (1) presentsuccinct, but still fairly detailed,formalizations for the two facets, and (2) summarizetheiranalysisfrom AK 89], for the structural, and AKW 90], for the behaviouralpart. For each the format is an example-driven, two page outline. We close with examples A 89, LR 89, BDK 91] integrating the two facets, a description of somepromisingresearchdirections and a selected (but incomplete) list of references.
1. The StructuralDataModel: The datadescriptiongeneralizesexisting“nestedrelation” and “complexstruc ture” data models, in particular AB 87, KV 84]. Our data.manipulationlanguage IQL generalizesexisting rule- based,staticallytypeddatabasequerylanguages, and can be used to compare their expressivepower. After some preliminarynotation, we definedatabaseschemas and theirinstances,almost as succinctly as for the relationaldata model!Assume the infinite and sets: relationnames class followingcountably pairwisedisjoint (1) {R, R’, .. . , }, (2) names attributes base constants B = and or {C, C’,. . . , }, (3) {A, A’, .. . , }, (4) {b, b’,.. . , }, (5) objectidentifiers oids 0 = The set of o-values is the smallest set B and 0 and closedunder finite {o, o’, .. . , }. containing tupling
: : for distinct and finite An o-value relation A1 v1, .. . , A,~ vk] A’s) subseting ({vi, .. . ,v~}). assignment p maps names 11 to finite sets of o-values. A disjoint] oid assignment ir mapsclassnames C to pairwisedisjoint]finite sets of oids. A value map of an oid assignment r is a partialfunction ii associating the oids in r to o-values.Intuitively, o-valueassignments are like “relationaldatabaseinstances”, oid assignments put “objects” into “classes”, and value mapsassociate“objects” to “values” or whenundefined to “nullvalues”. A fine point is the cyclic use of classnames C and oid assignment ir, respectively, in the syntaxand semantics of types as follows: (1) Typeex~ressionstypes(C) are defined the r = C 0 B : : The domains by grammar I I I A1 r,. .. ,Ak r] I {r} I (rVr) I (TAr). (2) matchingtype are the sets Dom=~r(C) I {} I {b,b’,...} I Ai:Dom,...,A, : Dorm] I {Dom} I (DomUDorrt) I (DornflDorm).
Definition DB: A databaseschemaconsists of a finite set of relationnames R, a finite set of classnames C and a function T fromRuC to types(C). A databaseinstance of such a schemaconsists of an o-valueassignment p to R, a disjoint oid assignment ir to C, and a valuemap t’ of r suchthat: (1) each R in R containso-values of the right type,p(R) C Dom(T(R)), (2) each C in C contains oids mapped to o-values of the righttype, v(ir(C)) ç Dom(T(C)), and for o not] a set-valued oid, undefined v(o) is u(o) = 0 undefined u(o) is a null value]. C
‘INRIARocquencourt,FRANCE.([email protected]).Supported by the Projet de RechercheCoordonnéeBD3. tBrownUniv.,Providence RI, USA. (pck©cs.brown.edu).Supported by NSF grantIRI-8617344 and ONRgrantN00014-83-K-0146 ARPAOrder No. 6320-1. Also,would like to thankSridharRamaswamy for his help with the presentation.
3 The typesprovided in this structuraldatamodel are concrete, as opposed to abstract. They includerecords, sets (lists could be handledsimilarly) and pointers. In addition,non-disjoint oid assignments and intersection and uniontypes can be used for expressingstructuralpolymorphism and in particularstructuralinheritance;because of limitedspace we refer to AK 89] for details on this issue. Also in AK 89], we present a corresponding pure value datamodelwithout oids, based on the regularinfinite trees produced by iteratedapplications of the value map i’. We now present an example that illustrates the datamodel’ssubstantialdescriptivepower(fromGenesis no less!).
Example DB: Consider a schemawith two class namesC-lst-generaticn,C-2nd-generationand with two relation namesR-founded-lineage,Il-ancestor-of-celebrity. Theirtypes refer to a base domain, e.g., B-string, and to class names, e.g., C-lst.generation, but not to relationnames. Union is allowed.Thenconsider an instance of this schema, whoseoid’s are o-adam, 0-eve, c-cain,c-abel,o-seth,o-nameless. Note the cycles.
T( C-lst.generation) = name:B-string,spouse:C-lst-generaiion,children:{C-End-generation}] T( C-2nd-generation) = name:B-string,occupations:{B-siring}] T(R-founded-lineage) = C-2nd-generation T(R-ancestor-of-celebrity) = anc: C-2nd-generation,desc: (B-string V spouse:B-string]) ir(C-lst-generation) = { c-adam, 0-eve } and ~r(C-2nd-generation) = { c-cain,o-abel,c-seth,o-nameless }, p(R-founded-lineage) = { c-cain,c-seth,o-nameless }, p(R-ancestor-of-celebrity) = { anc: c-seth, desc: Noah], anc: c-cain,desc: spouse: Ada]] }, u(c-adarn.) = name:Adam,spouse: c-eve,children: { c-cain,c-abel,c-seth,c-nameless }],
v(o-eve) = name: Eve,spouse:c-adam,children: { c-cain,c-abel,c-seth,c-nameless }] v(c-cain) = name: Cain,occupations: { Farmer,Nomad,Artisan }], z~(o-abe() = name: Abel,occupations: { Shepherd }], 0 v(o-seth) = name: Seth,occupations: {}], ii(o-nameless) is a null value.
The structural data model comes with a “complete” query language. This language, IQL, is Datalog with negationcombinedwith set/tupletypes,invention of new oid’s, and a weakform of assignment. With no additional syntax,inflationarynegation can expresssequentialexecution and while-loops. IQL was designed as a minimal
rule-basedformalism for expressing all computablequeries. This preciseexpressivepower was achieved — modulo a technicalcondition (copyelimination). The design was influenced by both the COL language of AG 88], for the manipulation of sets, and the detDLlanguage of AV 88], for the invention of new oid’s. The followingexample illustrates all of its importantfeatures on an efficientlyexecutablequery. Thisquery is not expressible in mostother databaselanguages, but is easilyexpressible in any programminglanguage (e.g., Pascal).
Example IQL Query: Our type systemallowsmultiplerepresentations of the same information. For example, a directedgraph may be represented as a binaryrelationwhosetuples are the arcs of the graph or as a class whose type is cyclic. In the secondrepresentationeachnode has an oid, a name, and a set of descendantnodes. IQL allows converting the first representation into the second and vice-versa. More formally, let the input schema be just a
relation Il with 7~R) = Aj:B,A2:B] and the outputschema be a class C with T(C) = Ai:B,A2:{C}]. The input instance I representsdirectedgraph C over B nodes. The desiredquery is to transform the “flat” I into a “deep” outputinstance J that also represents G (where now the nodes are “objects”). Let us examine the computation in IQL in four separatestages. Usingsimpletechniquesfrom AV 88], one can modify the rules (addinginflationary negation) to force the stages’sequentialexecution.
Ro(z) i— R(z, y) and Ro(z) i—-— R(y, a). In this first stage, we produce (in standardDatalogfashion) the set of nodenames. We use a relation R0 with T(R0) A1 : B].
R’(a,p,p’) i— Ro(x). In this secondstage, we invent two oid’s per node,using the semantics of AV 88]. We use a relation R’ whosetuplescontainoid’sfromclass C and from a temporaryclass C’, that is, we have the types T(R’) A1 : B, A2 : C, A3 : C’] and T(C’) ={C}. This stage’s rule invents two oid’s for each node, one of which will go into class C and the other into class C’. Note how the variablesp,p’ in the head are not in the body. When the new oid’s 0,0’ are invented by instantiating p, p’ they are placed in the properclasses and they are automatically assigneddefaultvalues: v(o) is undefined and v(o’) is the empty set, because of the set valuedtype of C’.
4 ~(q) i— R’(z, p, yl), R’(y, q, q’), R(z, y). In this thirdstage, we nest the oid’s representingnodes in C into sets of successors of a node. Here p’ is set valued and its value, noted ~, is a set in which the corresponding q’s are collected. The nesting is done by using the oid’s of C’ as temporarynames that simulate AG 881’s data-functions.
(fr := z,~]) ~— R’(x,p,p’). In this finalstage, the nodes of C have been grouped into C’, and the connection in R’ between z, p, p’ is used to produce the desiredresult. Thisweakform of assignment is performed only when ~, the value of p, was undefined. It is a single-assignment-form, i.e., no furtherchanges are made to ~3. 0
Analysis of the StructuralDataModel: Our maincontributions in AK 89] are the succinctdescription of the datamodel, and the design/analysis of IQL. This querylanguage can be statically type checked, can be evaluated bottom-up and naturallygeneralizes many rule-basedlanguages. Interestingly, IQL uses oid’s for three critical purposes: (1) to representdata-structures with sharing and cycles, (2) to manipulate sets and (3) to express any computabledatabasequery — up to copyelimination. This last property is a “completeness”theorem — modulocopy elimination(which is not expressible in IQL).However, IQL can express all computablequeries on pure values. 0
2. The Behavioural Data Model: We proposemethodschemas as a core data model of the object-oriented programs used in most 00DBprototypes. We believe that our functionalformalism is the most natural one and that,independent of formalism, the casesstressed in AKW 90] (small-arity,recursion free methodschemas)should be central to anyobject-orienteddatamodel. Theformalism is programschemas vL 90—ch.9],that expresscomposition, recursionand if-then-else, and that respectencapsulation; the manipulationof’objects only via methods. We do not use the lambdacalculus vL 90—ch.7],because most 00DBprototypes do not havehigherorderfunctions.
A methodschema is an isa forest (or singleinheritance)hierarchy of classes, that is associated with method (or program)definitions, see Figures 1—3. Each object, in a databaseinstance of a methodschema, is created in a single class where it belongs. All objectsbelonging to the same class have the same methods, so methods are part of the schema.Objects have methodsexplicitlydefined at their class or implicitlyinherited from the ancestorclasses of theirclass in the isa hierarchy (see syntaxbelow).Programs are interpretedoperationallyusinggraphrewriting (see semanticsbelow). Eachobject has no othervisiblestructure, so we havealgebraicspecifications vL 90—ch.13].
MethodSyntax:There are two kinds of explicitmethoddefinitions at classnamesc1,..., c,~, n ~ 0, where at most
one definition is allowed at each A basemethoddefinition is a finitefunction explicit c1, ..., c~. m©c1, ..., c1,~ (of arity
n> which has name m and has a —~ A codedmethoddefinition has name 0) signature c1, ..., c~ c~1. m©c1, ..., c,,~ m and is associatedwith an n-term, that is, a finiterooteddirectedacyclicgraphwhosenodes are labeled by method
names and class names nodes and whose arcs are ordered at each node. idea is c1, ..., c,~ (at input 1, .. . , n) (The that n-termsrepresentfunctions, built from the base functions via composition and recursion;methodinheritance will provideif-then_else). Three1-terms t, t’, t” are shown in Figure 2, where arcs are orderedleft-to-right.Figure 3 contains an explicitmethoddefinitionexample. In addition to explicitdefinitions,methods of a class can be implicitly inherited by its descendants. (Theidea is to have a restrictedform of codepolymorphismfor the convenience of code reuse). For flexibility, we allowreusingmethodnames in differentparts of the isa hierarchy,however, we keep the sets of base andcodedmethodnamesdistinct.Inheritancemeans that we can have at most one explicit and possibly
severalimplicitdefinitions for a methodname at the same class names, i.e., it impliesmethodname overloading. Resolution of method name overloadingconsists of finding, for a givenmethod name and given classes, a unique definition. We use the closestancestor in the isa hierarchyresolution rule. For the multi-argument case we take the argument-wiseclosestancestor, see AKW 90]. For example, the method cost in Figures 1—3 is explicitlydefined on part,implicitlyinherited by basepart, comp_part, and explicitlyredefined on basepari(the overloadinghere is resolved in favor of the explicitdefinition); it is also explicitlydefined for pair_of_parts. 0
MethodSemantics: For the basemethods eachdatabaseinstancecontainsfiniteinterpretations that respect the
That —, is materialized as a finitefunctionwhich for of givensignatures. is, m©c1, ..., c,~ c,~1 any tuple objects
to an to or to one its descendantclasses. The of belonging c1, ..., c,, gives objectbelonging ~ of interpretations codedmethods are definedrecursivelyusinggraphrewriting,just like programschernas.However,because of name overloading, a givenmethodname in a term is interpretedbased on its context, i.e., on the classes of its arguments.
5 coded (The idea is to model late binding). We now give some intuition for the rewriting of methods. Consider a depth-onen-term,whose one internal node is labeled m and whoseinputs have been replaced by objects, as a procedure call to m. Based on the classes of the arguments, we can replace (or reduce or graphrewrite) this call either by some object/code if it is defined in a base/codedfashion, or by an error message if it is undefined. In general,given the n-termwithobjectssubstituted for classnameinputs, in order to compute we reduce the first (in the term’sdepth first ordering)methodname with instantiatedleaves as children. If this deterministicreduction processterminatesafter a finitesequence of graphrewritings then we will either (1) obtain a result (i.e., an object) of for the method cost or (2) reach an inconsistency (i.e., get an errormessage). A partialsequence graphrewritings in Figure 3 is shown in Figure 4, where o is in classpair_of..parts and o’,o” are in class basepart. 0
check In AKW 90] we analyze the nontrivialproblem of methodschemaconsistency. Moreprecisely, we want to whether a givenmethodschema can produce an inconsistency, for somefiniteinterpretation of the base methods as part of somefiniteterminatingcomputation. The Problem of TypeInference in OODBscan be modeled by the static methodschemaconsistencyquestion. Our analysis of this reachabilityproblemprimarilyproducessignatures for the codedmethods. The Problem of ManagingSchemaEvolution in an 00DB can be modeled by the incremental methodschemaconsistencyquestion. This is an example of dynamic type inference. In general, the staticmethod schemaconsistencyproblem is undecidable. The difficultiescome from the simultaneouspresence of recursion and the use of multi-argumentmethods to representcontexts. As in programschemaslinearrecursion and twoarguments suffice for undecidability.Practicalprograms are often less complex.Practicalmethodschemasinvolvemostly the one-argument(monadic)and/or the recursion-freecases. Also,signatures are covariant or coniravariant.
Analysis of the BehaviouralDataModel: In AKW 90] we show that in the monadic and recursion-freecase, consistencycheckingcan be doneusingfinitestateautomata in PTIME,just likelexicalanalysis in compilers. In this case,inheritance and nameoverloadingintroducenondeterminism but covarianceremoves it. In favor of covariance, we giveDLOGSPACE vs NLOGSPACEargumentsandlinear vs quadratictimealgorithmarguments. In the monadic recursive case we also have decidability, usingcontext free languageemptiness. In the multi-argumentrecursion- free case decidabilityfollowsfrom an exhaustivesearch, at the expense of co-NP-completeness even for arity two. Interestingly, in the recursion-freecovariant case there is a PTIME test for a singletwo-argumentcodedmethod.
We use our caseanalysis as the basis for a generalheuristic for the staticconsistencyproblems.Enhancements(such as varieties of multiple-inheritance,moreprecise or less precisesignatures,attachment of methods to first argument, and virtualclasses with no objectsbelonging to them) can be integrated and studied with this core datamodel. 0
3. Combining the TwoFacets:Despitetheirdifferentnature, it is possible to combine the two facets in one data model. Twoexamples,familiar to the authors, are the 02 object-orientedprototype (Vi version)BDK 91] and the extension of IQL with abstractdatatypes A 89]. The integration of the two styles of datadescription is relatively simple. The more complicated task is the integration of data manipulation; for imperativeformalisms in 02 see LR 89] and for logicalformalisms see A 89]. Onetechnicalproblem, for OODBs, is the interaction of structural and behaviouralinheritance with type checking and type inference. In AK 89], we propose a compilation of structural inheritance into union types, that preserves static type checking and the “completeness” of IQL. However, this staticsolution does not capture the commondynamic use of inheritance in object-orientedprogramminglanguages (as is done in LR 89] at the expense of full static type checking). The reason is that union types are hard to implement. Is it possible to have dynamic use of inheritance in the querylanguage,withoutgiving-upstatic type checking or “completeness”?Anothertechnicalproblem,important for OODBs, is managingschemaevolution. This is motivation for the analysis of incrementalmethodschemaconsistency,with structuralfeatures.
4. MoreExpressive and EfficientTypes: We close our expositionwith a description of two additionalproblem areas. (1) Howdoes one add polymorphism and higherorderfunctions to the typesystem?Inheritanceprovidesonly limitedpolymorphism. There has been a great deal of research on ML with records and inheritance. Can one use such a programminglanguage for an object-orienteddatamodel? Can one takeadvantage of the variouspolymorphic higherordercalculideveloped in recentyears,surveyed in vL 90—’ch.8]? (2) The mostimportantquestion,concerns efficientimplementations. The structuraldatamodelinheritsmuch of the existingdatabaseoptimizationtechnology U 88], but queryoptimizationremainsopen for the behavioural (and the combined)datamodel(s).
6 sum sum pair_of_parts price
assembhngcost cost cost cost SUbL Id
Figure 1: isa hierarchy term t term t’ term t” ______
Figure 2: terms
methodsum @int,int : mt methodsubparts @part : pair_of_parts methodhead @pair_of_parts : part methodassemblingcost@part : mt method tail @pair_of_parts : part methodcost @basepart = t” methodprice @basepart : mt methodcost @pair_of_parts =
methodcost @part = t Figure 3: Methods
c st cost cost cost cost pnce cost 17 COSt 17 cost * * I ~.* 0 h\,7 0’ ta~ ~‘ ta~ ta~ 0”
Figure 4: A (partial)seuuence of rewritings
5. References
A 89] S. Abiteboul.“Towards a DeductiveObject-OrientedDatabaseLanguage”. lrst DOOD,419—438, 1989. AB 87] S. Abiteboul, C. Been. “On the Power of Languages for the Manipulation of ComplexObjects”.INRIA-846, 1988. AG 88] S. Abiteboul, S. Grumbach. “COL: a Logic-basedLanguage for ComplexObjects”. lrst EDBT,271—293, 1988. AK 89] S. Abiteboul, P.C. Kanellakis.“ObjectIdentity as a QueryLanguagePrimitive”.SIGMOD,159—173, 1989. Also,INRIA-1022, 1989. AKW 90] S. Abiteboul, P.C. Kanellakis, B. Wailer. “MethodSchemas”. 9th PODS,16—27, 1990. ÀY 88] S. Abiteboul, V. Vianu. “Procedural and DeclarativeDatabaseUpdateLanguages”. 7th PODS,240—250, 1988. A+ 90] M. Atkinson, etal. “The Object-OrientedDatabaseSystemManifesto”. 1st DOOD,40—57, 1989. BDK 91] F. Bancillion, C. Delobel, P.C. Kanellakis (eds). “Building an Object-OrientedDatabaseSystem: the Story of 02”. MorganKaufmann, to appear1991. KL 89] W. Kim, F.H. Lochovsky(eds). “Object-OrientedConcepts,Databases, and Applications”. ACMPress, 1989. KY 84] G. Kuper, M.Y.Vardi. “TheLogicalDataModel: a New Approach to DatabaseLogic”. 3rd PODS,86—96, 1984. Lii. 89] C. Lecluse, P. Richard. “The 02 DatabaseProgrammingLanguage”. 15th VLDB,411—422, 1989. U 88] J.D. TJllman.“Database and Knowledge-BaseSystems:Volumes I and II”. ComputerSciencePress, 1988. vL 90] J. van Leeuwen(ed). “Handbook of TheoreticalComputerScience:Volume B”. NorthHolland, 1990. ZM 90] S.B. Zdonik, D. Maier(eds). “Readings in Object-OrientedDatabaseSystems”.MorganKaufmann, 1990.
7 * TheoreticalFoundations for OODB’s — a PersonalPerspective
CatrielBeen Department of ComputerScience The HebrewUniversity of Jerusalem
1 Introduction
Object-orientation is a majorparadigm in currentdatabaseresearch. An enormousamount of system work is invested in development of object-orienteddatabases(OODB’s); but all seem to agree that the theoreticalfoundations can best be described as fuzzy. For me, ‘theory’ or ‘formal foundations’means logic (not necessarilypredicatecalculus). There is much to be said for the logicalapproach to 00DBtheory, but for brevity I assume that the reader is alreadyconvinced.
Let me onlyemphasizethat I am lookingonly for logicsthat are axiomatizable, for obviousreasons.
The following is/a shortaccount of somedirections that I believe are relevant to the development of a logicalfoundations for 00DB.
The 00DBparadigm is rich in ideas and concepts. I do not believe that a comprehensive theoreticalfoundation for it can be developedeasily, in one big step. My approach has been to take as a startingpoint a familiar and well understoodtheory, and try to developextensions that each covers a useful and interestingcategory of 00DBconcepts.Hopefully, such extensions can be merged into progressively more generaltheories. I try to arguebelow that, indeed, there are severaldirections to go, thateach can ~be used to provide ~ foundation for someinterestingfeatures of OODB’s, and that they can be cómbinedwith each ~ther. In the givenspace, it is impossible to provide a detailedaccount. T discuss one (simple)directionratherextensively, and others only fleetingly. (But be warned: the reallyinterestingresults are to be found in thoseotherdirections).
Note: The ideas below are not all originally mine; some have been discussedextensively in the literature. I have not included a bibliography, but somepointers are provi4ed.
2 The InitialModelApproach
During the 80’s we havewitnessed the appearance of models such as nestedrelations and complex objects. Add to these object identity, the ability to define and use ADT’s, and finally the often expressedrequirement that the database and the applicationprogramminglanguageshould have compatible type structures. In short, a primarycharacteristic of OODB’s is a powerful and exten sible data type facility. Datatypes belong to the programminglanguagedomain. What can we
Researchpartiallysupported by a grantfrom the USA-ISRAELBinationalScienceFoundation.
8 borrowthere? Let us consider the theory of ADTspecifications.1
Recall that our viewpointaboutrelationaldatabaseschangedabout ten years ago frommodel theoretic to prooftheoretic: a database is a set of (groundatomic)formulas. Thesemantics of such a database was delineated in works by Reiter, that introducedadditional,implicit,axioms, and defined the meaning of a database as the logicalclosure of the explicit and the implicitaxioms. The implicitaxioms state that the constants in the database are the only elements(domainclosure), that they are distinct fromeachother(uniquenaming), and lastly, the well knownCWA:relation ships not given explicitly in the database are false. There is also an equivalentmodel-theoretic semanticssince,giventheseaxioms, the model is unique. The theory of deductiveprogramming is a generalization: the domain is Obtained from the constantsgiven in a program by closureunder
(syntactic)functionapplication — this is the Herbranduniverse. Theelements of this universe are assumed to be distinct.Obviously, this is a generalization of the domainclosure and uniquenaming assumptions.Finally, the semantics of a program is the set of groundatomicformulas it implies, or equivalently the minimalmodel in the Herbranduniverse — a generalization of the CWA.
Now,considerhowabstractdatatypes are specified. Theapproach is logic-based: Thelanguage containsfunctionsymbols(includingconstants), and the only predicatesymbol is equality. Thus, the only atomicformulas are equations.Specifications are presented as sets of (universallyquanti fied) equations or conditionalequations, that is, Horn-clauses. The models are algebras. The most commondefinition of the semantics of a specification is its initialalgebra or model.2 Initialmodels are unique, up to isomorphism, so this definition is indeed abstract — it defines the semantics uniquely only up to isomorphism,hidingrepresentationdetails.
A wellknownconstruction of an initialmodel is the following: Startwith the termalgebra,whose domain is the Herbranduniverse — the collection of all terms, and where the ‘application’ of a function to terms is defined to be the term The extension of the f ti,. . . , tT~ f(t1,. . ., t,~). equality predicatedefined by (conditional)equations is a congruencerelation on the terms. The quotient of the termalgebra by this relation is also an algebra, and it is an initialmodel. (We take the quotient so thatequalitybehaves‘normally’, that is, twoelements are ‘equal’ if they are the sameelement.)
For someintuition,consider the definition of stacks, with operationspush,pop,top,empty,where the equationsinclude, e.g.,pop(push(n, s)) = s. The ‘stack’elements of the termalgebra are those obtainedfromempty by applications of push and pop; but the equationsmakeelements like s and pop(push(n, s)) equivalent. The quotientalgebra is precisely what we intuitivelyexpect. An importantproperty of the initialmodel is that elementsdenoted by differentgroundterms are the same,that is a groundequationholds in it, preciselywhen the equation is logicallyimplied by the specification. This reflects a proof-theoreticinterpretation of the semantics, as the logical closure of the specification. Note the similarity to the semantics of deductiveprogramming. Can then the two approaches be unified? Yes, easily! Take a language with bothfunction and predicate symbols. For any set of Horn clauses, there exists a (unique up to isomorphism)initialmodel.
Its elements are the equivalenceclasses of termsmodulu the congruencerelationdefined by the
1The ideas below have been discussed in severalpapers by Goguen et a!; see, e.g, in D. DeGroot, G. Lindstrorn (eds.) LogicProgramming:Functions,relations, and Equations,Prentice Hall, 1986. 2lnitiaiity is easy to define, but we cannot go into details for lack of space.
9 formulas for the equalitypredicate and, in particular, the domain is the Herbranduniverse 1ff there are no nontrivialequations in the logicalclosure. It is still the case that a groundatomicformula holds in it if it is logicallyimplied from the givenprogram.Thus, the logicprogrammingparadigm is obtained as a special case, where the equalitypredicate is not used. Relationaldatabases are obtained by also dropping the functionsymbols, and allowing only atomicgroundformulas. All the theorems that underliedeductiveprogramminghold in this moregeneralframework. In short, it unifies the theories of relationaldatabases,deductiveprogramming, and ADT’s.
A unification of severaltheories is in itself a gratifyingachievement. But, there are also imme diate benefits: We can now (try to) generalizetechniques and results of the morelimitedtheories; this often succeeds, and even when it fails it providesinsight. We can relate results that were obtainedindependently in seeminglydistinctdomains, and oftenreinterpretthem as specialcases.
We can also investigateissues that exist oniy in the generalizedframework. All this, of course, is just advertisement; let me mentionsomeconcreteexamples.
The initialmodelapproachallows one to define a variety of generic data types, in particular tuples,finite sets,lists, and so on. Thus, this frameworkincludesnestedrelations/complexobjects models, in which the values are atoms,tuples, and sets. It also allows user definedADT’s. For example, to define finite sets, we use the constantempty, and the functioninsert, that takes an element and a set, and outputs a new set obtained by inserting the element into the given set. The equationsstatethat the order of insertion is irrelevant, and inserting an elementtwice has the same effect as inserting it once. Membership,union, and so on can similarly be defined.
Whyshould we care to formalize a simpleconceptsuch as sets? A restrictedformalization of sets is embedded in the notion of model of the predicatecalculus, and is used in relationaldatabases:
Certain sets (of tuples) are given, namely the predicateextensions, other sets are defined from them by formulas; one can ask if an element is in a set, or print all elements of a set. But, in the new models sets are values that can be manipulated,takenapart and reconstructed. We must tell the system how we understand sets. Trying to manipulate set naively may be dangerous: In unrestricted LDL one can express the paradoxes of set theory. A formalization, as above,helps us to discoverwhat can be donewith sets safely and efficiently. As an example, the existence of a least fixpointsemantics for LPS, proved by Kuperusingspecializedtechniques,follows as a corollary of the generaltheorems.Features of languages that allow sets as elements such as LPS, LDL, COL can now be compared and explainedThese are the benefits of having a generaltheory.
In this approach we cannotmodelupdates,hence we cannotmodel the fact that objectidentity does not changeeven when its value is updated. But, a simplestaticnotion of objectidentity can be modeled by a specification that definespairswhere one component, the identity, is takenfrom some abstractdomain(where the only operation is comparison), and the othercomponent is the value.3 For querylanguages, this is sufficient.
Traditionally,therehavebeen twoapproaches to querylanguages:calculus-based and algebraic.
Now, we can view a database in our framework in two ways: First, as a set of formulasinvolving, collection . . as a of named sets contents is defined say, predicatesPr,. , p~ second, s1,. . . , Sn (whose
3This may be ratherdisappointing, but withoutmodelingupdates, we cannot hope for muchmore.
10 by equations). In the first approach, a query is obtained by augmenting the database by additional formulas, then askingwhat are the elements t such that p(t) holds, for some p. This is the calculus- basedapproach: a formuladefines an unnamedpredicate,which is the querypredicate.Deductive languages also fall in this category. In the secondapproach, we applyfunctions to the given sets, to produce new values. Appropriategeneralizations of all the relationalalgebraoperations are definable as functions in this framework4, and so are other useful functions such as aggregates.
This sheds new light on the algebra vs. calculusdychotomy: these are functional and predicative programming styles, respectively. Are they equivalent in this generalsetting? The answer is positive, for both the nonrecursive and the recursivecases,undercertainconditions. this generalizes
manypreviousresults, and also uncoverssomelimitations. The theory of ADTspecification is usuallycouched in terms of ri-zany-sortedlogic, where the
algebras, or models,havedistinctdomains for the sorts. But,actually we havehere twoindependent ideas: that equality can be used to define(stateproperties of) data types, and that typing can
be incorporated into the calculus,allowingfunctions that are meaningful only on certainsubsets ~ of the domain. Theseideas can be used independently or together. The many-sortedapproach
has the benefit of simplicity. For example, one may modelsubtyping (a form of isa relationship)
by mappingsbetweendomains in the initial model, and investigate its properties.6 Of course,
ultimately we would like to generalize the framework to moresophisticated type disciplines.
3 Higher-OrderConcepts
Some relationalsystems now store queries; all OODB’s store functions in the form of methods.
Variousfeatures of the behavioralaspects of OODB’s, such as inheritance and overiding, are neatly
modeledwhen new functions can be definedfromgivenfunctions (see my paper in DOOD89). The
requirement of having a completedatabaseprogramminglanguage also entailshaving a powerful
functiondefinitionfacility. In short, we wantfunctions as first class values, and a flexiblefunction definitionfacility.
The formalismunderlyingfunctionallanguages is the (untyped or typed)A—calculus. This is
also a logic, but it does not containconnectives and quantifiers, nor predicates. In the 30’s,Church
tried to extendA—calculus to a full logic; his system was shown to be inconsistent.Nevertheless, he
later presented a consistent logic that combines the predicatecalculus and the typedA—calculus.7 I believe that the idea also works for the untypedA—calculus.8 An importantbenefit of this logic
is that A-abstraction can be applied to predicates, not just to functions. This furtherincreases
its power. This logic is a considerablegeneralization of the framework of the previoussection, where the first-orderfunctionallanguage with equality is replaced by the A—calculus. A database
41t is well known how to define a function map that given a function f and a list, outputs the list with f applied
to each element. There is no difficulty to adaptthdefinition to obtain such as select and project on sets. 5We can define, say, integers and stacks in a mono-typed logic, but then we have to careful never to write an expression that applies + to a stack. Typing is a naturalsolution. 6See my paper with T. Milo in PODS 91. 7See the paper by Nadathur and Miller in JACM, Oct. 90. 8However, in view of Church’sexperience, do not believe until you see a proof in print.
11 is described, as before, by a collection of Horn clauses. If we carry over the rest of the paradigm, that is the semantics as the logicalclosure, we have a veryattractiveframework,combining the full powers of relational and functionalprogramming, that can be used with variousexpressive type systems.
An importantcharacteristic of OODB’s is the ability to treat higher-order, or schema-level, entities as first class values. Functions are just one example. Othersinclude sets, attributes, relations,classes and types. For example, isa relationshipsrelate such entities, and we would like to reason or queryabout such relationships. The issue of a logic wherehigher-orderelements can be manipulated as if they were first-order has been investigated by Kifer and coauthors; see his paper in this journal. Let me consider just one issue. We have seen above how to models sets as values. There is anotherapproach to sets. If we make a selection from .a binaryrelation on an element that appears in the first position, we can view the result as representing a set associated with thatelement, and the element as an object id. Thus, we can in this way model(someaspects of) set-valuedobjects,which we may call classes. We can now modelrelationshipsbetweenclasses; e.g., isa is a binarypredicate with axioms that make it a partialorder.9 These are two of the
‘secrets’ of F-logic. We can similarlymodelbinary-relationvaluedobjects, and with axioms that make the relationsfunctional, we k~ave function-valuedobjects.Interestingly, the A—calculus has an axiomatization and ‘first-order’models, and the constructions of thesemodelsutilizesprecisely this idea of associatingfunctions with elements, with certainclosureproperties that ensure that
A abstraction is alwaysdefined. Thus, there are common ideas underlying the various‘feasible’ higher-orderlogics. It is important to note that the ideaabove is important for the designer of the logic,since he needseffectiveproofprocedures. A languageshouldcontainenoughsugar to let the users see just sets, functions,classes and so on. Users need not be botheredabout how the proof or modeltheory weredeveloped.
4 Conclusion
I haveshownthatexistinglogic-basedapproaches to databasesand programminglanguagespromise to be useful for modelingOODB’s. I hope that this extremelysketchyoutline has convinced you that the approach is interesting and potentiallyuseful. In particular, that there is a small set of conceptsunderlying the varioushigher-orderlogics. Often they are independent, and can be combined to suit our needs. By elucidatingthem, we can hope to obtain a toolkit for constructing expressivelogics to suit our needs.
Muchremains to be done in constructing new theories and extendingknownresults, and in providingsatisfactorymodeling of OODB’s. For the theoreticallyinclined, there is a wealth of problemswaiting to be investigated. I see the development of a full scalefoundation for OODB’s as an endeavor that may requireseveralyears. This is no reason to be alarmed; this is how science progresses. I see a goodreason to be excited and interestedabout this research; for if the approach
I havedescribedworks, then the results will be a unifiedfoundation for two of the centralfields of
ComputerScience — databases and programminglanguages.
9Thetricky part is, however, how to modelinheritance. See F-logic.
12 A First-OrderFormalization of Object-OrientedLanguages *
MichaelKifer Department of ComputerScience SUNY at StonyBrook StonyBrook, NY 11794 [email protected]
1 Introduction
The last few number of years saw a attempts to provide a formalfoundation to the object-orientedprogram
mingparadigm. In a nutshell, one of the mostsalientfeatures of this paradigm is the use of dataabstraction, i.e., encapsulatedobjectswithcomplexinternalstructureaccessiblethroughpubliclyknownfunctions,called methods. Semanticallysimilarobjects are classified into classes and the latter are organized in a hierarchy, sometimescalled IS-Ahierarchy.
IS-Ahierarchies are usefulbecausetheyhelpfactor out informationthat is shared by most ofthe members
of a class. Suchinformation is explicitlystated for the class and then is implicitlyinherited by subclasses and individualobjects.Subclasses and objects that do not share the commoninformationconstituteexceptions and can overwrite the inheritance. Thiskind ofinheritance is callednon-monotonic and has beenextensively studied in the literature.
Anotherimportantideaunderlyingobject-orientedlanguages is the notion of a type. Generally, the term refers type to an arbitrary set of abstractvalues. The collection of all types used in the language is called a
type system and is specified via a type expressionsublanguage. In object-orientedlanguages,types are used
to specifycollections of structurallysimilarobjects,where the “similarity” is manifested by a common set of methodsapplicable to the objects of the sametype. Methods are also typed, i.e., they are declared so as to expectarguments of certalntypes and returnobjects of certaintypes.
Sinceobjectspopulating a classsharesemanticsimilarity,1 it is reasonable to expect that theywould be
structurallysimilar as well. Moreover, the type of objects in a class C is inherited by everysubclass of C and so the type of a subclass is a subset of the type of a superclass. We thereforebelieve that in object-oriented languagestyping is secondary to the semanticclassification into classes. This also explains why in many languagesclasses and types are closely, yet mysteriously,related.
In thisshortpaper, we shallprovide an elementaryintroductioninto the results of our recentwork on the logicalfoundations of object-oriented and frame-basedlanguages. Our goal is to clarify the centralconcepts of such languages and outline a simplelogicaltheory for them. We start with a very basic object-centered language,roughlycorresponding to Maier’s0-logic 8] (but, in fact, datingback to the mid-seventies to the little-knownworks of Pawlak 9, 10]), and proceed by addingmorefeatures,going on the way past what is
‘Worksupported in part by the NSF grantIRI-8903507 1Classesthatrepresentheterogeneouscollections of objects do not contradict this claim,for—from the datamodelingpoint of view—semanticaffinity is the only properreason for placingdifferentobjects in the santeclass.
13 known as C-logic 1], the revised0-logic 5, 6], and eventuallyaccounting for many of the features of F-logic 2, 3].
2 Object-CenteredLanguages
By an object-centeredlanguage we mean one thatsupports (to variousdegree) the concept of an objectwith a complexinternalstructure. We start with what we call a “simple0-logic” and continue to add features until we (almost)reach the functionality of the full 0-logic, as described in 6].
Central to all object-centeredlanguages is the notion of objectidentity—asimpleconcept thatgenerated heateddebates in the databasecommunity. Our view is that objects are abstract or concreteentities in the real world and objectidentity is a syntacticwherewithalneeded to refer to theseobjects in the programming language. Moreaccurately,objectidentity is a purelyimplementationalnotion, a surrogate or a pointer to an object,while the syntacticcounterpart in the programminglanguage is a denotation of an object.
For the reason that is not completelyclear to me, somerecentproposalstried to incorporate the notion of objectidentitywithoutintroducingobjectdenotationsexplicitly into the language. This was essentially the reason why Maier’s0-logic 8] was unsuccessful in dealingwith databases that containanything more complexthan a simplecollection of objects. LDM of Kuper and Vardi 7] was morelucky in that respect, but only at the price of severelylimiting the language and the queries.
In our model,objects are referred to via theirdenotations,which are nothing else but first-orderterms, such as 13, .156, john32. Functionsymbols can be used to construct more complexdenotations, such as father(mary),head(csdept(stonybrook)).
2.1 Simple0-logic—TheDual of the RelationalModel
The centralconcept of the relationalmodel, the relation, is defined as a set of tuples,where a tuple is a function from the set of attributes of the relation into the domain.2 The dual concept can be stated as follows:
An attribute is a function that maps the set of objects into the domain.
This dual data model is actuallyrather old; it appeared in a little-knownpaper by Pawlak 9] and was subsequently used in 10] and in some of the laterpapers of Lipski.3
It is interesting to note here that Pawlak’smodel is not value-oriented, i.e., it is perfectly legal that all attributes will map two distinctobjects into the same values. In contrast, the relationalmodel is value- oriented: it is impossible for two differenttuples to mapattributes in the same way. hi otherwords, if .4 denotes the set of all attributesthen in Pawlak’smodel Va E A(a(obji) = a(obj2)) & obj1 obj2 is possible,
while in the relationalmodel Va E A(ti(a) = t2(a)) &ti t2 is impossible. Being cast in the concretesyntaxused by Maier in 8] and incorporating the aforesaidideaaboutobject identity,Pawlak’smodelyieldswhat we call Simple0-logic—alogical,object-centeredlanguage that Maier would have arrived should he the at, overcome problemsencountered on the way (which, in my view,
2Assuming, for simplicity, that all attributesshare the samedomain.
theseworks were before the 3lronically, publishedlong beginning of the recentcrasewithobject-orientedlanguagesand so Pawlaic did not due credit. This also to LDM of get applies Kuper andVardiwhoseworkmighthaveattractedmoreattention if they onlyused the “right”buss-words.
14 stemmedfrom an attempt to emulate ad hoc implementationalideas too closely).SimpleO-logicallows for the representation of factssuch as
—* “John ohnname Doe”; salary —* 20000]
— “MainSi. at.her(mary)address USA”; spouse —, sally] where john,father(mary), and sally are denotations of objects that are intended to representinformation about “John persons, Doe”, “Main St. USA” are denotations of string-objects, and 20000 is a denotation of an integer-object;name,salary, and address, spouse, are attributes.Besides the basic facts aboutobjects, one can write deductiverules,just as in deductivedatabases. regular Details can be found in 5, 6].
2.2 0-logicRevisited
SimpleO-logicaccounts only for a very limited type of For complexobjects. instance, there is no straight forward way of saying that John has childrei, and Alice. Mary, Bob, Nevertheless, it is very easy to extend this logic to supportfull-fledgedcomplex We have objects. just to allowsome attributes to be set-valued, i.e., be defined as functionsfrom to the objects powerset of the domain,ratherthan to the domainitself. For instance, we coulddefine a set-valuedattributechildren and assert ohnchildren —÷‘ {mary,bob,alice}]. What we called “attributes” in of case the Simple will be now called O-logic functional(scalar, or single- attributes.Details of the valued) semantics can be found in 5, 6]. The next step is to define the class hierarchy—acommon way of groupingsemanticallyrelatedobjects To together. this end, we introduce a sort C of separate constants, called class-objects, and a new kind of formulas,called IS-A atoms. With their help we couldwrite : john student,meaning that john is an instance of the class student € C; or student : person,meaning that the class student is a subclass of the class person.Introduction of the class and hierarchy IS-A atomsenables one to write class-sensitive deductiverules, e.g.,
X : — i— asketball_playersalary high] X : —‘ tudenthealth good; height —~ H] & H> 7/ t
(Tallstudentsinevitablybecomehighlypaidbasketballplayers.) The addition of set-valued attributes and classes us almost all of the gives functionality of O-logic as presented in 5, 6]. By removing the attributesfrom single-valued O-logic we obtainC-logic 1].
3 GoingHigher-Order:F-logic
It was not until the higher-order was introduced in syntax 2] when a full logicalformalization of object- oriented languagesbecamepossible. There are several reasons why a higher-ordersyntax is needed:
• In object-orientedlanguages, one needs to reasonaboutclasses andtheir instances in the samelanguage.
• Often one has to createclasses deductive using rules,just as in 0-logicone does this withplainobjects.
• One should be able to define the properties of classes values of their (i.e., attributes) the same way as this is done for objects.
• Higher-ordersyntaxmakesinheritance of fromclasses properties to subclasseseasier and moreelegant.
• One should be able to browse the databaseschema through in a natural way,withQuthaving to know the internal representation of the system to catalogue. (Thisapplies relationallanguages as well.)
15 The danger in flirtingwithhigher-orderlanguages is that the resultingsyntaxmayturn out to be non- while the of computable, even for the monotonic part of the logic. To avoidthis, designing language F-logic calculus. we kept a constant eye on the possibility of encoding the language in first-orderpredicate andattributes.4 Thehigher-ordersyntaxwasachieved by breakingthe distinctionbetweenclasses,objects,
In other words, we allow any objectdenotation to be construed as a reference to an object, a class, or an variables attribute,depending on the syntacticposition of that denotation in the formula.Logical can now that be instantiated by attributenames as well as objects. This creates the opportunity for askingqueries entities. For return sets of attributes,classes, or any other aggregation that involves these higher-order instance, to inquireabout all classes to which the object john belongs,write:
?— john : X
To find all superclasses of the classstudent,write:
?— student : X
consider Thecapabilities for browsing are actuallyquiteextensive. To get a feeling of what can be.expressed,
Objinterestingsttrs_of(Class) —‘-‘ {A}] 4— bjA —, V] & V : Class
For each class Class this defines an attributeinterestingsttr&of(Class),whosevalue for any object Obj is the set offunctionalattributes(because of the single-headedarrow“—+“)that are defined on Obj and return values that are instances of Class. We couldthen ask the query
?— ohninterestingsttrs..nf(person) —÷÷ {A}]
to find out whichfunctionalattributes are defined for the objectjohn and returnvalues of type pen
The next exampleshowshow parametricclasses can be defined in F-logic.
nil : list
cons(X, L) : list(T) 4— X : T & L : list(T)
4 Types and Signatures
The ability to defineparametricclassesopens the door for parametricpolymorphism,whichbrings in the issue of types and type-correctness. Since it is impossible to do justice here to these importantissues, the
motivatedreader is referred to 3, 4]. Very briefly, we introduce yet another kind of logicformulas,called signatures, that specify the types of variousattributes and methods. For instance,
employeename =~ string; friends =~ person]
says that every object in the dass employee has a single-valuedattribute name and a set-valued at tributefriends. The formerreturnsobjects that belong to the class string, while the latterreturns sets
of person-objects. There is also a semantictype-correctnesscondition,whichsortsill-typedlogicspecifica tions(databases) from the well-typedones.
4Ifnecessary, this distinctioncan be re-establishedwithoutloosing the benefits of higher-orderness. The key idea is to use
a sortedlanguage ~I~
16 For anotherexample, the next programdefines a polymorphicallytyped methodappend that, being invoked on a list-object with anotherlist-objectpassed as an argument,returns a concatenation of the two lists:
isi(T)append~list(T) =~‘. list(T)]
ist(T)append~flnil —‘ L] 4— L : list(T) 4— cons(X,l)append©L2 —* cons(X,L3)] 1avpend~L2 —i L3] & X : T & Li: lisi(T)
The first clauseabove is a signature that defines a parametricpolymorphic type for append. The last two clausesactuallydefine the appendmethod. (The symbol “~“ separatesmethodnames from their lists of properarguments.) As defined,append is consistent with the typingconstraintrepresented by the signature 3].
5 Conclusion
It is hoped that this short communication will motivate the reader to look into the excitingdevelopments thathavetakenplace in the past few yearsin an effort to develop a formalmodel for object-orientedlogiclan guages,databases in particular.There are manyissuesthat we did not have a chance to mention in this paper, due to the spacelimitation.Theseincludestructural and behavioralinheritanée, the prooftheory for F-logic, the programmingmethodology, andseveralothers. A comprehensivereport on F-logic can be obtainedfrom the FTP account at “cs file .dvi Z”. Other anonymous . sunysb . edu”, “pub/TechReports/kifer/flogic . papers in this specialissue advocatealternativeresearchdirections.
References
1] W. Chen and D. Warren.C-logic for complexobjects. In Proc. of PODS,pages369—378,March 1989.
2] M. Kifer and G. Lausen.F-logic: A higher-orderlanguage for reasoningaboutobjects,inheritance and
schema. In Proc. of the ACMSIGMOD Conf. on Management of Data,pages134—146, 1989.
3] M. Kifer, G. Lausen, and J. Wu. LogicalFoundations of Object-Oriented and Frame-BasedLanguages. Tech.Report90/14,Dept. of ComputerScience,SUNY at StonyBrook, July 1990.
4] M. Kifer and J. Wu. A first-ordertheory of types and polymorphism in logic programming. In Intl.
Symp. on Logic in ComputerScience,Amsterdam, The Netherlands, July 1991.
5] M. Kifer and J. Wu. A logic for object-orientedlogicprogramming(Maier’s0-logicrevisited). In Proc.
of PODS,pages379—393,March1989.
6] M. Kifer and J. Wu. A logic for programmingwith complexobjects. JCSS,1991. to appear.
7] G. Kuper and M. Vardi. A uew approach to databaselogic. In Proc. of PODS, 1984.
8] D. Maler. A logic for objects. In Workshop on Foundations of DeductiveDatabases and LogicProgram
ming,pages6—26,WashingtonD.C.,August 1986.
9] Z. Pawlak. Mathematicalfoundations of informationretrieval. In Proc. of Symp. on Mathematical
Foundations of ComputerScience,pages135—136,HighTatras,Czechoslovakia, 1973.
10] W. Marek and Z. Pawlak.Informationstorage and retrievalsystems:Mathematicalfoundations. The oreticalComputerScience,1:331—354,1976.
17 On DataRestructuring and Mergingwith ObjectIdentity*t
RichardHull SurjatiniWidjojo DaveWile MasatoshiYoshikawa
1 Introduction
Objectidentity, a powerfulabstractionused in databases and otherfields,correspondsclosely to mechanisms whichhumans use to organize their perceptions and understanding of the physical and conceptualworlds that we live in. Theemergence of semantic and object-orienteddatabasemodels is nowmaking it possible for databasedesigners and users to utilize this abstraction in an explicitmanner. The use of objectidentity in
thesemodels has placed a spotlight on a number of interesting,fundamentalproblems in datamodeling, and at the sametimeprovides the basis for resolvingthem. TheWorldBaséprojectWHW89], an ongoingproject at USC/InformationSciencesInstitute, is focused on the development of novelarchitectures and techniques for supportingsimultaneousaccess to heterogeneousdatabases. We describe here a number of concepts and resultsconcerning the conceptual and theoreticalimpact of objectidentity in the generalcontexts of data restructuring and merging,whichhaveemerged from the WorldBaseproject. In Bee89], Been provides a good articulation of the distinctionbetween OlDs and values as they arise in the databasecontext. A value is somethingwhich has intrinsicmeaning,which is universallyunderstood (relative to the family of databasesbeingconsidered);valuestypicallyinclude the integers, the floats,strings, booleans, and othername-basedtypesconstructedfromthese. In contrast, an OlD has no intrinsicmeaning
— and derives its meaning only from its relationship to values and other OlDs in a givendatabaseinstance. In particular, then, if an OlD is consideredindependently from its associateddatabaseinstance (e.g., in a database view or a query answer), then it conveysessentially no informationother than its identity as distinct from all other OIDs. As illustratedbelow, this opaqueness of OIDs has impact on queries, data restructuring, and datamerging (and also updates,which are not consideredhere). Section 2 informallydescribes a formalmodelwhichencompasses OlDs and values. Section 3 presents the family of ILOGlanguages;these are variants of datalogwhich are used to specify datarestructurings in the context of OlDs. Section 4 gives a moreinformaldiscussionpresenting a framework for specifying data merging in the presence of OIDs. The discussion here is extremelyterse;fullerexposition of many of these issues,numeroustheoretical and practicalresults, and additionalreferences may be found in HY9O,HY91, WHW89,WHW9O,Wid9O].
2 A formalism for OlDs
Been’scategorization of databaseobjectspartitions the world into values and OlDs. The distinguishing
feature of OIDs is that they uniquelyidenlifyobjectsfrom the real world — the objectsbeingmodeled. Of 1 course,values can play this role in certainsituations — such as SocialSecuritynumber or part number
— but there are manysituations in which it is more convenient to use pure OIDs than to artificiallycreate printablesurrogates.Examplesincludeapplicationsinvolvingentity sets arising in disparategeographical, politicaland/ororganizationalcontexts;objectsarising in engineeringdesign,which do not have a natural name;geographicalobjects;individualchips on a circuitboard; and in someapplications,documents,which are uniquelyidentified only by lengthystringshaving a variety of structures. The simpledatabaseschema of Figure 1(a) shows an abstract class (or entity set) person,which“holds”
R. Hull is at the University of SouthernCalifornia; S. Widjojo is at the Institute of SystemsScience,Singapore; D. Wile is at USC/InformationSciencesInstitute;and M. Yoshikawa is at KyotoSangyoUniversity. tR. Hull was supported in part by NSFgrantIRI-8719875; R. Hull and D. Wile in part by the DefenseAdvancedResearch ProjectsAgencyunderDARPAgrantMDA9O3-81-C-0335;and M. Yoshikawa in part by ScienceFoundationGrant # 02750298 of the Ministry of Education,Science and Culture of Japan, and a grantfrom the ObaseConsortium. 1Our modelformallydistinguishessuch values as surrogaies for the objects, but here we only considerOlDs for unique identification.
18 OlD name Ii OlD name age II age ll~oi ‘John’ 32 05 ‘John’ 32 II 0~ ‘Mary’ 37 j] 06 ‘Mary’ 37
p~ (a) (b) (c)
Figure 1: A simpleschema and two pre-instances
OlDs, with two simgle-valuedattributesgiving name and age, which map to character string and integer2 types, respectively. (This, and the other schemasshown in the document are 1F0 schemas as defined in HY9O]; the diagramaticconventions are essentially those of AH87,HK87].) Parts (b) and (c) show two tabularrepresentations of data sets that might be associated with this schema. Note that these two data sets are identical to each other, up to renaming of the OlDs. FollowingAK89}, we say that these two data sets are OlD-isomorphic. To capture the equivalence of the datasets of Figure 1(b) and (c) we call such datasets pre-instances, and define an instance to be an equivalenceclass of pre-instances,where two pre-instances are equivalent if there is an OID-isomorphismbetweenthem. Underthesedefinitions, the notion of instancecapturesprecisely the information that a databasestate can convey to a database user. (In contrast, a DBA may typicallywork directly with pre-instances.)
3 OlDs and datarestructuring
We now consider the impact of OlDs on data restructuring, as it arises in databasequeries,schema aug mentation(whicharises, e.g., in derived data), and schematranslation(whicharises, e.g., when defining stand-alonedatabaseviews). A significantimpact of OlDs in these contextsstems from the axiom that OlDsindependent of an associateddata set have no intrinsicmeaning. Thus, a query such as “List all OlDs of personshaving age > 35” against the schema of Figure 1(a) yields a set of OlDs, and gives no useful informationexcept for a cardinality. Moregenerally,whileOlDs do not carryindependentmeaning in query answers, they can be useful in indicatingconnectionsbetweendifferent dataelements (e.g., see AKS9]). Thesecondfundamentalimpact of OlDs on datarestructurings is thatrestructuringsshould be capable of building, in theiroutput,complexdata sets which may involvenewly“created” OlDs. Figure 2(a) shows an 1F0 schemamodelinghypotheticaldataconcerningpurchasesmade by governmentalagencies. Theschema includesabstractclasses for government—agency,invoice, and supplier, and a subclass of suppliercalled foreign—supplier. The multi-valuedattributepurchasesmapseachgovernmentagency to a set of invoices. The aggregation (or tuple) constructindicates that each item is an ordered pair, consisting of a part—name and a quantity. Consider now the issue of augmenting this schemawith the schemacomponentshighlighted in 2(b). This calls for the creation of a new entity set audit—unit, and two single-valuedattributes. We will create an audit-unitobject corresponding to each agency-supplier pair (a, s) where a has at least one invpice with foriegnsupplier s. Intuitively,each audit-unit can serve as a locus for dataconcerningaudits of such agency- supplierpairs. ILOG is an extension of datalog, and thususes the naturalsimulation of semanticmodels by the relational of model. For an instance I = I] and ILOGprogram P, P(I) is defined in terms of P(I), that is, in terms pre-instancesrepresenting the instance. The followingILOGprogram,which has output or targetrelations audit-unit,agency-of,supplier-of and total-of, can be used to specify the derived data definitiondesired for Figure 2(b). (ini-aud-un is used as an intermediaterelation.)
int-aud-un(*, a, s) i— purchases(a, i), supplied-by(i, s), foreign-supplier(s) attdit-unit(u) i— ini-aud-un(u, a, s) agency-of(u, a) ~— int-aud-un(u, a, s)
supplier-of(u, s) ~— int-aud-un(u, a, s) Lotal-value(u,sum(v)) ~— int-aud-un(u, a, s) ,purchases(a, i), supplied-by(i, s), value(i, v)
2Althoughnot emphasized in this document, types givestructuralinformationandhaveimmutableext~nts,whereasclasses give structuralinformation and havemutable,typicallyfinite,extents.
19 (a) sourceschema (b) schema with augmentation
Figure 2: Schemas used to illustratederived data and data translation
Intuitively,execution of this program on a pre-instaneeresults in the creation of (new) OlDs for each (a, s) pair satisfying the conditions of the body of the first rule givenabove. The relationint-aud-un is used to “create” each such OlD, and to “hold” its correspondence to the wiiness (i.e., tuple of values and OlDs which lead to its creation.) As with conventionaldatalog,variables in the rule body not occurring in the head (e.g., the variable i rangingover invoices) are viewed as existentiallyquantifiedwithin the body. The remainingrules are used to describe how the four componentsadded to the schema are to be populated. With regards to OlD creation, ILOGfollows the lead of Mai86] and subsequent logics (e.g., KW89, CW89]), by using a semanticsbased on Skolemfunctors. Thispermits the creation of OlDs in a systematic, set-at-a-timefashion, and forms a close tie between data restructuring and logic programming. Figure 3 illustrates the two phases of execution of the ILOGprogramgivenabove. Part (a) of that figureshows a smallfragment of a pre-instance for the schema of Figure2(a). To make the presentationmoreintuitive, we use strings to denote OlDsrepresentingagencies,invoices, and suppliers, and show only foriegnsuppliers. Part (b) of the figureshows (part of) the outputpre-instancecomputed by the first phase of execution. Here “OlDs” for type audit—unit are represented as termsconstructed using the Skolemfunctor f~-~ in general a distinctSkolemfunctor is used for each intermediaterelation of a programwhichcreates OlDs “i’ (i.e., by which a is used). This outputreflects the perspective on OlDstaken in KW89,CW89],called here “exposed”semantics. (In thisexample,only one audit-unitOlD is created for a pair (a, s), regardless of howmanyinvoicesrelate a with s; this followsfrom the rule definingint-aud-un. A differentILOGprogram could be used to obtainother policies for OlD creation.) Part (c) of the figureshows (part of) an output pre-instance of the secondphase; here a “new” OlD is associated with each distinct term occuring in the pre-instancecomputedduring the first phase. This “obscured”semantics for OlDs correspondsclosely to thosefound in most of the datarestructuringlanguages in the literature. The instancecorresponding to this pre-instanceserves as the output of the program. The full languageILOG’supports both recursion and stratifiednegation. This leads to six natural families of ILOGlanguage,based on twodimensions:negation or no negation; andfullrecursion, no recursion, or “weak”recursion,whichdoes not permitrecursionthroughOlD creation.Thesesublanguagescorrespond to variouslanguages in the literature, for example,nonrecursiveILOG(nrecILOG) can be viewed as unions of conjunctivequeriesbundled with OlD creation, and nrecILOG’ can express the core of most schema translationlanguages.
There are strongsimilaritiesbetweenILOG and IQL AK89] — both are relativelydeclarativelangauges whichsupport OlD creation. We note here three fundamentaldifferences. ILOG is essentiallyrelational, whereas IQL supports full complexobjects (in particular,sets). ILOG is essentiallyuntypedwhereas IQL is stronglytyped. Finally, OlD creation in ILOG is based on Skolemfunctors while in IQL it is based on
20 purchases IRS inv32 zni-aud-un IRS inv56 f0-~(IRS,UK2l) IRS UK~T~JI SS mvii fa-u(IRS,PRC5) IRS PFtC-5 agency-of SS inv88 f0-~(SS,DR-1O) SS DR-IO 0~. IRS supplied-by agency-of II 038 IRS
______inv32 UK-21 f0~(IRS,UK-21) IRS FLc~ ss inv56 PRC-5 f0-~(IRS,PRC-5) IRS mvii DR-b f0-~(SS,DR-lO) SS inv88 DR-b
(a) input (b) output with OlDs “exposed” (c) output with OlDs “obscured”
Figure 3: Partialpre-instancesillustratingILOGsemantics
OLD name ci~ 05 ‘John’ ‘LA’ 06 ‘Sue’ ‘NY’
(b)
Figure 4: The NAME-CITYschema and a pre-instance of it
somethingsubtleydifferent. As a result, the IQL analog of nrecILOG (i.e., positive,set-free,non-recursive IQL) is non-monotonic,whilenrecILOG is monotonic.
Importantly, the Skolemfunctor based approach to OlD creation can be used in the context of other langaugeparadigms. For example, a formalsemanticsbased on Skolemfunctors can easily be given for the OOAlgebraDay89]. Thus,researchconcerningILOG is “portable” to theseotherlanguages.
4 OlDs and data merging
We nowturn to the impact of OlDs on databasemerging. This is a particularlycrucialproblem in the context of heterogenousdatabases, where users may wish to combine data from multipleautonomousdatabases. Under the approach of WorldBase, we assume that beforemerging a family of datasets, theirschemas have been restructured so that they are compatible, in the sense that thereexists a singleschemawhichcontains subschemasisomorphic to the schemas of the data sets of be merged. The schemas of Figures 1(a) and 4(a) are compatible.Suppose now that name is known to be a key for the personentityclass,which is universalacrossbothdatabases. Then the instancesrepresented by Figures 1(b) (or (c)) and 4(b) can be merged in an unambiguousfashion, to yield an instancerepresented by the pre-instance of Figure 5(a) (permitting age and city to be partialattributes). On the otherhand, if name is not known to be a universal key for person, then the problem of merging the data of the NAME-AGE and NAME-CITYdatabases is ambiguous. For example,instancescorresponding to either of the pre-instances of Figure 5(a) and (b) couldarguably be the result of such a merge. This examplehighlights two of the fundamentalproblems that arise in data merging: (i) determining whenOlDsfrom two (or more)distinctdatabases refer to the sameobject “in the world”, and (ii) providing a systematicformalism for specifying the “merging” of these two OlDs (or the creation of a new OlD which is “linked” to these OlDs). There is a spectrum of possibilities for determiningwhen OlDs from differentdatabase(pre-)instances should be merged,rangingfromusingvalue-based keys, throughapproacheswhichpermitOlD-based keys whichrecursively“bottom out” with values, to approachesbased on subgraphisomorphisms (e.g., identify persons fromdistinctdatabases if they bothcorrespond to a chiefexecutiveofficer of a Fortune 500 corpo rationwhosehusbandserves as treasurer). A suitableformalmodel for specifying OlD merging is yet to be developed. One possibleapproach is to formsome kind of merger of ILOG and techniques from algebraic specifications(thesecome into play because of the apparent need to equateinitiallydistinctOlDs.) Anotherfundamental issue arises in databasemerging if the databases to be merged hold inconsistent
21 OlD name age city ~~D name age city Fl 020 ‘John’ 32 II 010 ‘John’ 32 ‘LAfl] 021 ‘John’ ‘LA’ Il 0i~ ‘Mary’ 37 022 ‘Mary’ 37 ~2 ‘Sue’ ‘NY’ 023 ‘Sue’ ‘NY’
(a) (b)
Figure 5: Possiblemerges of datafromNAME-AGE and NAME-CITYdatabases
informationDay83]. For example,suppose again that name is a universal key for the two schemasunder discussion, and suppose that in one instanceJohn is listed as having age 32, and in the other he has age 31. Whatvalue for John’s age should be given in the mergeddatabase? In WorldBase, data merging is accomplishedthrough a two-phaseprocess. In the first phase, the set of pairs of OlDs to be merged is determined, and in the second phase the targetschema is populatedusing the (possiblymerged) OlDs, and also all attribute and relationship data held in the sourceschemas. Two mechanisms are provided for dealing with inconsistent data during the secondphase. The first focuses on single-valuedattributes, and permits the specification of conflictresolutionstrategies (e.g.,prefer datafrom one of the sourcedatabases, or compute the averagevalue). The secondmechanismprovides tools to relax the integrityconstraints on the target schema. In particular, a preliminaryformalism is provided which permits the specification of naturalcombinations of the constraint sets on the sourceschema to serve as the constraint set on the targetschema. As a simpleexample, the single-valuedattributephone in source schemas for personal and business data might be combined to form a singlemulti-valuedattribute in the targetschema, with a restrictionpermitting at most two phonenumbers per person.
References
A1187] S. Abiteboul and R. Hull. IFO: A formalsemanticdatabasemodel. ACM Trans. on Database Systems,12(4):525—565, Dec. 1987. AK89] S. Abiteboul and P. Kanellakis. Objectidentity as a query languageprimitive. In Proc. ACM SJGMODSymp. on the Management of Data,pages159—173, 1989. Bee89J Catriel Been. Formalmodels for object orienteddatabases. In Proc. of First Intl. Conf. on Deductive and Object-OrientedDatabases, 1989. CW89] Weidong Chen and David S. Warren. C-Logic of complexobjects. In Proc. ACMSymp. on Principles of DatabaseSystems,pages369—378,1989. Day83] U. Dayal.Processingqueries over generalizationhierarchies in a multidataba.sesystem. In Proc. of Intl. Conf. on Very Large Data Bases,pages342—353, 1983. Day89] UmeshwarDayal. Queries and views in an object-oriented datamodel. In Proc. of Second Intl. Workshop on DatabaseProgrammingLanguages,pages80—102.MorganKaufmann, 1989. HK87] R. Hull and R. King. Semanticdatabasemodeling: Survey,applications, and researchissues. ACMComputingSurveys,19(3):201—260,September 1987. HY9O] R. Hull and M. Yoshikawa.ILOG:DeclarativeCreation and Manipulation of ObjectIdentifiers (ExtendedAbstract). In Proc. of Intl. Conf. on Very Large Data Bases,pages455—468, 1990. HY91] R. Hull and M. Yoshikawa. On the equivalence of databaserestructuringsinvolvingobjectiden tifiers. In Proc. ACMSymp. on Principles of DatabaseSystems, 1991. to appear. KW89J M. Kifer and James Wu. A logic for object-orientedlogicprogramming(Maier’so-logicrevisited). In Proc. ACMSymp. on Pnnciples of DatabaseSystems,pages379—393, 1989. Mai86] D. Maier. A logic for objects. In Workshop on Foundations of DeductiveDatabases and Logic Programming,pages6—26,Washington,D.C.,August 1986. WHW89]SurjatiniWidjojo,Richard Hull, and DaveWile. DistributedInformationSharingusingWorld- Base. IEEEOfficeKnowledgeEngineering,3(2):17—26,August 1989. WHW9O] S. Widjojo, R. Hull, and D. S. Wile. A specificationalapproach to mergingpersistentobject bases. In ImplementingPersistentObjectBases.MorganKaufmann, 1990. Wid9O] SurjatiniWidjojo.SharingPersistentObject-Bases in a WorkstationEnvironment.Ph.D.Thesis, ComputerScienceDepartment,University of SouthernCalifornia,August, 1990.
22 DataStructures and DataTypes for Object-Oriented Databases
Val Breazu-Tannen,PeterBuneman and AtsushiOhori*
1 Introduction
The possibility of finding a static type system for object-orientedprogramminglanguages was initiated by Cardelli{Car88,CW85] who showed that it i~ possible to express the polymorphicnature of functions such as
fun age(x) = thisyear — x.year_ofJirth which may be regarded as a method of the “class” of recordvalues that contain a numeric age field. It is possible both to integrate this form of recordpolymorphism with the parametric(universal)polymorphism andalso to express a number ofobject-orientedprogrammingparadigms by combininghigher-orderfunctions with field selection. Since then a number of alternativeschemesWan87,5ta88,0B88,3M88,Rem89,HP91] have beendeveloped thatinclude the possibility of typeinference and the use of abstracttypes0B89J. The extent to which these typingschemes give a satisfactoryaccount of all aspects of object-orientedlanguages remains an open question, and it may therefore be premature to complicate the picture by introducing database concepts. Nevertheless, if we are to treat databases of any kind (object-oriented or otherwise) properly in typedprogramminglanguagesthere are certainissues that must be resolved, and it is these that we shall brieflyinvestigate in this paper. Unlike the languagesassociated with the relational data model which have simple and more or less coincidentoperational and denotationalsemantics, the authors know of no equivalentformulation of an object-oriented data model. While severalpapers, e.g. ABD+89]describecertain desiderata of object- oriented is databases, a consensus has yet to emerge on a formalism for an object-oriented datamodel, nor there yet an adequateexplanation of what is fundamentally new about such a model. The issues we discuss in this paper are relevant to object-orienteddatabasesbecause they are of generalconcern in languages 5ch77,ABC+83,AC085} that integratedatabasestructures with their type systems, and object-oriented databasessurely fall into this category. We shall be mainlyconcerned with operations on records and some “bulk” data type such as sets. Any database programminglanguageAB87J mustsurely be capable of expressing a function such as
fun wealthy(s) = select x.Name fromx cc-s where x.Sal > 100,000
The be found in syntax here is taken from MachiavelliOBBT89], but very similardefinitions are to what is object-orientedlanguages such as 02 LRV88]. We would like a type system to expressexactly required of the argument S in order for the functionwealthy to be well defined. S containsrecords(perhaps with objects) appropriateproperties. S must be a set (or someother bulktypesuch as a bag or list.) Finally the we mustallow that in somedatabases S may be heterogeneous: the individualrecords may not all have samestructure. in this These three demands on a programminglanguage are the issues we discuss paper.
‘Authorsaddresses:Bunemanand Breazu-Tannen,Department of ComputerandInformationScience,University of Penn sylvania,Philadelphia, PA 19104-6389,USA; Ohori,KansaiLaboratory,OKIElectricIndustry,CrystalTower,1-2-27Chuo-ku, Osaka Bune.. 540,Japan.Breazu-Tamienwaspartiallysupportedby grantsOMItN000-14-88-K-0634andNSFCCR-90-57570. man was partiallysupported by rantsONRN000-14-88-K-0634, NSF 1111-86-10617and by a UK SERCvisitingfellowship at ImperialCollege,London
23 2 Operations on records
In OBBT89] the functionwealthy is given the type
(‘a) Nazue:’b,Sal:num]} —> {‘b}
instantiated The ‘a and ‘b are iI,pe variables and may, subject to restrictionsdiscussedbelow, be by any type. The notation { ‘b} describes the type of sets of values of type ‘b, and the notation (‘a) Name: ‘b, fieldsName Sal : nun] describes the restriction that an instance of ‘a must be a record typethatcontains the
a and Sal:numwhere a is any instance of ‘b. For example
Naxne:string,Sal:num,Weight:nuin]} —> {string} Name:First:string, Last:string],Sal:num]} —> First : string, Last:string]}
are legalinstantiations of the type of wealthy. of function like Using such a syntax it is not only possible to express the exact polymorphic type a inference If the wealthy; it is possible to infer a type by means of an extension of ML’s type system. well only operations on records wererecordformation and field selection, the necessarytechniques are now established (in fact the approachesgiven in Wan87,Sta88,0B88,JM88,Rem89]wouldagree.) The differences unusual arisewhen we add operations that extend or combinerecords, and this is wheredatabasesplace an consistentinfor demand on the type system. An operationcommon in databases is to join two records on mation. For exampleName=’Joe’,Lge=21] and Name=’Joe’,Sal30,000] join to form (Name=’Joe’, the of and Age~21,Sal=30,000]. On the otherhandthere is no type that can be given to join Id=1234]
‘ structures Id= A123’]. Thisjoin can be extended to sets of records i.e. relations, and in fact to arbitrary that on whichequality is provided, to define the naiuraljoin of complexobjectsOho9Ob]. it is arguable similar rule naturaljoin is needed in a databaseprogramminglanguage, but even if it is not, a very typing is needed for the intersection of heterogeneous sets (see below). of ML that There is a well-known result Mil78] that underlies the polymorphic type system every be obtained expression has a principal type scheme, i.e. every possibleground type for an expression can recordformation and by instantiating the typevariables of its principal type. If we add the typingrules for field selection: 1: A I~ej : r~, A I~’e~ : A I~e : ..., r,...... , (DoT~ (RECORD) ‘ / l~ : r1,.. .,l~ : r,~] AF?e.l :
that it can we retain the principaltypingpropertyOho9Oa].However, the rule for join is unusual in only be used provided a “sidecondition” is satisfied:
Ai>ei : ‘5i Ai>e2 : ‘52
(JOIN) . . ifö=61U52 AF~Jo1u(eI,e2) : ‘5 relax the notion Therequirement that anygroundtypealsosatisfy the side conditionsmeansthat we need to of the principaltypingproperty to include theseconditions;nevertheless it is still decidablewhether a given inference can expression has a type, and by suitablydelaying the checks for satisfaction, the process of type be madeefficient and to operateinteractively.
3 Operations on sets
be added to a The operations of the relationalalgebrasuggest one way in whichoperations on sets may there a programminglanguage. While these are adequate for a large number of databaseapplications, are with number of usefuloperations, such as transitiveclosure of a binaryrelation, that cannot be expressed the relationalalgebraalone. Moreover,there is no way of expressing the cardinality,sum, or otheraggregate operations on a set. Relationalquerylanguagesprovidethese as specialoperations, but there is no general way to construct new aggregateoperations. The problem is this: the relationalalgebraprovides us with an adequate set of operations for mapping sets of tuples (records) into sets of tuples, but provides us with no way of movingoutside this domain; this we cannotexpect the relationalalgebra to produce a set of sets or an integer. One could get rounds to by adding a chooseoperator, which picks arbitrarily an element of a set, and using generalrecursion
24 programfunctionsmapping sets to other types. However,chooseintroduces a nondeterministicsemantics, and makes it difficult to ensure that our programs are well-behaved. A betterapproach, we claim, is to use structuralrecursion as the generaltechnique for carrying sets into otherstructures. As opposed to general recursion, which most of the times requiresdestructors like choose, this form of programmingworks by matchingargumentsagainstdatatypeconstructors. One form of structuralrecursion on sets is given by the combinator$whjchtakes E:8, F:a—~/3 and U :~3x8—.$totheunique4’(E,F,U):{cr}—.$ satisfying
4’(E, F, U)(ø) = E
$(E, F, U({~e}) = F(z)
4’(E, F, U)(si U 82) = U(4(E, F, U)(si),4’(E, F, U)(s2)) providedthat on the range of 4’(E, F, U), U is associative and E is an identity for U (a monoidstructure), and moreoverthat U is commutativeandidempotent. This is similar to the pumpoperator of FADBBKV88} and the hornoperator of MachiavelliOBBT89],except that in thoselanguages the requirement of idempotence is dropped and the requirement that the sets s~, ~2 be disjoint in the third clause is added. Pump and horn have a naturaldenotationalsemantics, but their operationalsemantics is contrived. The evaluator must evaluate sets eagerly and then do time consumingdynamic tests for equality of values. Of course, this rules out working with sets of functions for example. Even for sets of, say, integers,mapping a function over a disjointunion may yield a non-disjoint one, which fed into hornwouldyield a run-timeerror. One would like to obtainstatically an assurance that the program goes through, but it seems that only a few very simple programs can be showncorrect in this sense. On the other hand pump and horn can be implemented in 4’ style, by converting sets to bags and then doingstructuralrecursion on those.
Appropriate uses of 4’ are, for example,$~(F) = 4’(O,F,u) and 4’A(P) 4’(true,P,A)where F: a {-‘} and P : a —~ bool. Usingthese, we can construct the followingfunctions on sets:
map f =
pairwith 8 x = map(Ay.(z, y)) s cartprod(81, 82) = 4’u(pairwith82)(3i)
= U powerset 4’({O} , Ax.{ø}U{{x}},A(sj,s2). map cartprod(si,s2))
(checking the commutative-idempotentmonoidrequirement for the use of 4’ in the last definition is quite interesting).
The denotational and operationalsemantics as well as an appropriatelogic for reasoningaboutprograms that compute withstructuralrecursion overbulkdatatypessuch as lists, bags and sets is studied in BS91], wheretransformations to otherpresentations of thesedatatypes are also given. In BBN91J, it is shownhow to computetransitiveclosureefficiently with structuralrecursion, and it is noted that relationalalgebra can be characterizedusingrestrictedforms of structuralrecursion: the expressions of relationalalgebra are semanticallyequivalent to preciselythoseexpressions that can be constructedusing the structuralrecursors 4’u and 1A together with elementaryoperations(concatenation,projection and conditionals) on tuples.
4 Heterogeneouscollections
Theability to dealwithheterogeneouscollections is claimedStr87] as an importantfeature ofobject-oriented programming, and we believe it is of specialimportance in object-orienteddatabases,where it appears to be the only way to reconcile twonaturalviews of inheritanceBO9O].Beforelooking at this issue we should remark that we have so far been working in a framework of typedlanguages. These are languages in which the 3 + only meaningfulexpressions are those that have a (declared or inferred) type. In such a language “cat” is not a programbecause it has no type. Compare this with the situation in “dynamicallytyped” languages in whichsuch expressions can be evaluated, but mayyield run-time typeerrors. In any persistent programminglanguageAB87] it is desirable, for safety, to maintain a structure that describes the type of a database along with the database. However, in order to reasonabout these external types in a typed languagerequires someextraapparatus. bulk The need for this is seen in any language that has someform of subtype rule in conjunction with a data the typesuch as lists. If 1 is an expression of type list(Person) and e is an expression of type Employee, expressioncons(e, 1) that “inserts” e into 1 also has, because of the subtyperule, list(Person). The expression
25 head(cons(e, 1)) now has type Person, and we have “lost” some of the structure of e; moregenerally we can no longer use the equation e = head(cons(e, 1)) to reasonabout our programs. In B090] we haveproposed an extension of the dynamictypes ACPP89] in whichvalues in a programminglanguage are “views” that express the partial type of somecompletelytypedobject. The way we achieve this is to incorporate into our typesystem a distinctionbçtween the type ofan object and its kind. In object-orientedterminology the formerspecifies the class of an object and hence its exact structure, while the latterspecifies that certainmethods are available. In order to incorporateassertions on kinds of objects in the typesystem, we introduce a new form of assertion e : 2(n) denoting that e has the kind For n. example, e :2 (
PersKind for
Alsosuppose that OB is a set of type {P(any) }. The meaning of any is the set of all possibletypes, so that we initially have no informationabout the structure of members of this set.
Since kinds denote sets of types, they can be ordered by set inclusion. In particular,Empkind is a “sub-kind” of PersKind. Fromthis, the inclusionfilter EnpKind (5) c filter PersKind (S) will always hold for any heterogeneous set S. This means that the “datamodel”(inclusion)inheritance is derived as a staticpropertyfrom an ordering on kindsrather thanbeingsomething that must be achieved by the explicit association of extentswithclasses with dynamicmaintenance of extents.Moreover,object-oriented(method sharing)inheritance is also derived from a polymorphic type of a method. For example, the type inference method we havedescribed in section 2 guaranteesthat any polymorphicfunctionapplicable to P(PersKind) is also applicable to P(EmpKin.d). Thus, we achieve the desiredcoupling of the twoforms of is-a in a static typesystem.
5 Conclusions
have We attempted to show that typedlanguages are a naturalmedium for manyaspects of database
programminglanguages. There are certain topics such as objectidentity,abstracttypes, views (and the interactionbetween these) that requirefurtherinvestigation. However we are confident that these can be resolved and that object-orienteddatabases will be best understood in the same framework of typed languages.
References
AB87] M.P. Atkinson and O.P. Buneman. Types and persistence in databaseprogramminglanguages. ACMComputingSurveys,June 1987.
ABC~83J M.P. Atkinson, P.J. Bailey, K.J. Chisholm, W.P. Cockshott, and R. Morrison. An approach to persistentprogramming.ComputerJournal,26(4), 1983.
ABD~89} M.P. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrick, D. Maier, and S. Zdonik. The object- orienteddatabasesystemmanifesto. In Proc. FirstDeductive and Object-OrientedDatabase Con ference, 1989.
26 AC085] A. Albano, L. Cardelli, and R. Orsini.Galileo: A stronglytyped,interactiveconceptuallanguage. Transaction on DatabaseSystems,10:230—260, 1985.
ACPP89] M. Abadi, L. Cardelli, B. Pierce, and G. Plotkin.Dynamictyping in a statically-typedlanguage. In Proc.ACMSymp. on Principles of ProgrammingLanguages, 1989.
and database BBKV88J F. Bancilhon, T. Briggs, S. Khoshafian, and P. Valduriez. FAD, a powerful simple 1988. language. In Proc. Intl. Conf. on Very LargeData Bases,pages97—105, Un BBN91} V. Brea2u-Tannen, P. Buneman, and S. Naqvi. StructuralRecursion as a QueryLanguage. publishedManuscript,University of Pennsylvania, 1991.
{B090] P. Buneman and A. Ohori. A type system that reconcileclasses and extents. Technicalreport, University of Pennsylvania, 1990.
BS91] V. Breazu-Tannen and R. Subrahmanyam.Logical and ComputationalAspects of Programming and with Sets/Bags/Lists. To appear in Proc. InternationalConference on Automata,Languages Programming(ICALP), 1991.
Car88] L. Cardeffi. A semantics of multipleinheritance.Information and Computation,76:138—164,1988.
CW85] L. Cardelli and P. Wegner. On understandingtypes, dataabstraction, and polymorphism. Com putingSurveys,17(4):471—522, 1985. concatenation. In Proc. ACM HP91] R. Harper and B. Pierce. A recordcalculus based on symmetric~ Symp. on Principles of ProgrammingLanguages, 1991.
JM88] L. A. Jategaonkar and J.C. Mitchell. ML with extendedpatternmatching and subtypes. In Proc. 198—2 1988. ACMConference on LISP and FunctionalProgramming,pages 11,
datamodel. In Proc.ACMSIGMOD LRV88} C. Lecluse, P. Richard, and F. Velez. 02, an object-oriented Conference,pages424—434, 1988. and Mil78] R. Milner. A theory of type polymorphism in programming. Journal of Computer System Sciences,17:348—375, 1978.
In Proc. A CM OB88] A. Ohori and P. Buneman. Typeinference in a databaseprogramminglanguage. 1988. Conference on LISP and FunctionalProgramming,pages174—183, OOPSLA OB89] A. Ohori and P. Buneman. Static type inference for parametricclasses. In Proc. ACM Conference,pages445—456, 1989.
OBBT89] A. Ohori, P. Buneman, and V. Breazu-Tannen.Databaseprogramming in Machiavelli — a poly morphiclanguage with static type inference. In Proc. ACMSIGMODconference, pages 46—57, 1989. of Oho9Oa] A. Ohori. Extendingpolymorphism to records and variants. TechnicalReport,University Glasgow, 1990. 1990. Oho9Ob] A. Ohori. Semantics of types for databaseobjects. TheoreticalComputerScience,76:53—9 1,
of ML. In Proc.ACMSymp. Rem89] D. Remy.Typecheckingrecords and variants in a naturalextension on Principles of ProgrammingLanguages, 1989.
Sch77] J.W. Schmidt. Some high level languageconstructs for data of type relation. Transactions on DatabaseSystems, 5(2), 1977.
Sta88] R. Stansifer. Typeinference with subtypes. In Proc. ACMSymposium on Principles of Program mingLanguages,pages88—97, 1988. Str87] B. Stroustrup. The C++programminglanguage.Addison-Wesley, 1987.
Wan87] M. Wand.Complete typeinference for simpleobjects. In Proc.Symposium on Logic in Computer Science,pages37—44, 1987.
27 Foundations of the 02 DatabaseSystem
C. Lécluse and P. Richard
Altair, BP 105 78153 Le ChesnayCedex,France
1 Introduction
In this paper, we describe the data model of the 02 system as it is implemented. We first implemented, in December 87, a throw away prototypeBBB*88] in order to test and show the functionalities of the system. This gave us a lot of feed back and we completelyredesigned the system, its data modelLR89J, its language and its architecture. The first prototypeconvinced us that the object-orientedapproach was be a good choice for databases.However, we also deduced from this experience that a lot of pointsshould carefullydesignedotherwiseobject-orienteddatabasesmight not reachtheirgoals and mighteven be a step backward.Among the new featureswhich we think are necessary to implement, let us quote: (i) complex valuestogether with objects, (ii) names for objects and values with an automaticpersistencemechanism attached to names, (iii) the list type constructor, (iv) the possibility of separatingclasses and method definitionsfrom the implementation, (v) the need for a designmodewhereemphasis is made on dynamicity and evolution and an executionmodewhereperformance are crucial. The 02 datamodelrelies on two kinds of concepts:complexvalues, on which we can perform a predefined set of primitives, and objectswhich have an identity and encapsulatevalues and user definedmethods. Values have types whichspecify their structure and objectsbelong to classes.
2 Values and objects
The presentation of this section has been largelyinfluenced by the works of LR89] and also AK89]. We supposegiven: (1) A set of atomic typesnames{integer,string, float, boolean) and their corresponding domains,Dnteger,D,grjng,Djioat,Dboolean,which are pairwisedisjoint. The set D of basic values is the union of thesebasictypesdomains. (ii) A set A of symbolscalledattributes: age,name (iii) A set I of objectidentifiers: #32, #765 (iv) A set of class names C. In the following, we shall use capitals for classnames,typewriter for attributenames and # followed by numerals for objectidentifiers.
Definition 1 Let I be a subset of I. A value over I (or just value if i is understood) is recursivelydefined as follows:
• The symbol nil is a value.
• Everyelement of D or I is a value.
• If values then : : is a value. is the value. v~, are Vj, .., a,~ v~] (tuple) ] emptytuple v1, .., al
• If are distinctvaluesthen is a value. is the set value. v1, .., v,~ {v1, .., v,~} (set) {} empty
• If vl,..,vn are values then < ~ > is a (list) value. < > is the empty list value.
We denote V(I) the set of all values over I and V = V(I). An object is the association of an object identifier of I with a value of VI. We note 0 the set of all objects. Classically, in object-oriented data models,everypiece of information is an object. In the 02 datamodel, we allowboth the’~concept of object and value. This means that, in the definition of an object, the component values of this object do not necessarilycontainobjects, but also othervalues. Here are someexamples of values and objects:
28 ILa.me: “Eiffel_tower”, address: city: #432, Street:“Champ de mars”], description: “ParisMonument”, a~mission..fee: 25]
{#23,#54)
#23 —~ name: “Eiffel_tower”, #432 —. name: “Paris”, address: city: #432, cou.ntry:“France”, street:“Champ de mars”], population: 2.6, description: “ParisMonument”, monuments: {#23,#54)] admission.iee: 25]
In object-orienteddatabasesystems, this value is classically a tuple or a set of objectssincedatabases mustprovideflexiblemanagement of large sets of data. However, this value is always a flat value, as it can onlycontainidentifiers of otherobjects, and not directlyothercomplexvalues. Thislimitation is exactlylike the limitation of relationalsystemswhich has motivated the introduction of nestedrelations and complex objects. In 02, we provide the user with the possibility of manipulating, not only objects, but also values as in standardprogramminglanguages or in the so-calledcomplexobjects’languages. Of course,complex (nested)structures can always be modeledthrough the use of identifiers but we think that this solution is awkward, like the modeling of nestedrelations with surrogates in relationalsystems. The address of the object#23abovecouldhavebeenwrittenusing an intermediaryobjet. However, this address is conceptually nothing else than a pair of strings and is totallylocal to the object #23.
3 Types and classes
Definition 2 Let C be a subset of C. We call typesover C (orjust types, if C is understood), the expressions constructed as follows:
• Thesymbol any is a type.
• The atomictypesinteger,float,boolean, and string are types.
• The classnames of C are types.
• Ifi1,...,t~ are types, then a1 : ~ : t~] is atype.
• If t is a type then {t} is a type.
• If t is a type then
We shall note T(C) the set of all types and T = T(C).
The following are examples of types. Notice that these two types are referencingclassesMonument and City.
name:string, name: string, address: city: City, country:string, street:string], population: float, description:string, monuments:{Monument}] adinission.iee:integer]
are not objects in the object-orientedterminology but rashercomplexvalues.
29 4 Classhierarchy and subtyping
Inheritance is a centralconcept in object-oriented(database)systems. It allows the user to derivenew classes fromexistingclasses by refiningtheirproperties. For example, the Monument class can be specialized into a HistoricaLmonumentclass. We say that the HistoricaLmonumentclassinheritsfrom the Monumentclass. Following the abstract datatype theory, the concept of subtype is based on the idea that a type is a form of behavior and a subtype is a compatiblespecialization of the behavior. A class hierarchy is made of two components: a set of class names with types associated to them, and a subclassrelationship. The type associated to a class describes the structure of the objectswhich are instances of the class. The subclass relationshipdescribes the (user-defined)inheritancepropertiesbetweenclasses.
Definition 3 A class hierarchy is a triple (C, o•, -<) where C is a finile set of class names, o~ is a mapping from C to T(C), and —< is a strictpartialorderingamong C.
The type tr(c) is the structure of the class of name c. We derive a sublypingrelationship < from the subclassrelationship as follows:
Definition 4 Let (C, u, -<) be a a classhierarchy, the subtypingrelationship •I-c • I— : : : < : : for all and n such that a1 ii,.., an i,~, .., a~+~ in+p] a1 Sj , .., a,~ sn], types i~ s, i=1, ..., ii si. • I- {t} < {s}, for all types s and t such that a < t. • I- • t The first rule just expresses that subclasses are subtypes. We then have one rule per type structure. Noticethat we can refinetuples by refiningsomefields or by adding new ones. We do not allow two related classes (c -~ c’) to have arbitraryassociatedtypes. The type associated to a class describes the internal structure of the instances of the class. An instance of a class (say Employee)being also an instance of its superclassPerson, we want the instances to sharecommonstructures. More precisely, if c and c’ are two relatedclasses (c —< c’), then we want to ensure that o(c) < o(c’). The followingdefinitioncharacterizes consistent classhierarchies. Definition 5 We say that the class hierarchy (C, ~, -<) is consistent if for all classes c and c’, if c -< c’ then o(c) < Methods are associated to classes and define the behavior of objects of the corresponding class. One importantfeature of the object-orientedparadigm is the encapsulalion. The objects of a class can only be manipulatedusing the methodsassociated to this class. A method can be seen as a functionfrom a source domain to a rangedomain. For example, the methodgeLname:Monument —p string can be applied to objectsbelonging to class Monument and the result will be a value of typestring. A method is represented in the model a A method on C is an m : c x x x —+ where 02 by signature. signaiure expression i.~ ... i~ I, m is the name of the and are over C. We also that the first c is a class method, c, ij . . . 1,~ types impose type name. Thefirst type of a methodsignature is the class to which the method is attached and it is called the receiver class of the method. An importantfeature of object-orientedsystems is the notion of overloading and lale binding. A method m can be defined with Me samename in severalclasses. Given an object and a methodname, the code to be executed is determined at run-time by searching for a method of thatname in the classhierarchy. Of course, the redefinitions of a method in subclasses of a classmustfollowsometyping rules in order to avoidtypinginconsistencies (see Definition 8). 30 5 Databaseschema Definition 6 A databaseschema is a 5-tuple S = (C, c, -<, M, G) such that: (i) (C, c, -<) is a consistent class hierarchy, (ii) M is a set of methodsignatures on C, (iii) G is a set of names with a type associated to each name. A databaseschemamodels both the structural and the behavioral parts of the database. Its main component is the class hierarchy and the methodsignatureswhichdescribe the programminginterface of the instances of the classes. The names of G are the entrypoints in the database. Theyserve as handles for some objects (or values) which are of a particularimportance. In manyobject-orientedsystems, the databaseentrypoints are the extensions of the classes. We want to be moregeneral and defineentrypoints which are arbitraryvalues or objects.Moreover, as databaseentrypoints, the names of G (globalnames) are also used to define the persistencesemanticswith the followingrules (i) everyobject or valueattached to a global name is persistent, (ii) every objett or value attached to a persistentobject or value is also persistent. The globalnames are the roots of the persistencemechanism. In order to define a notion of schemaconsistency, we first state the followingworkingdefinition: Definition 7 Let S be a databaseschema. If m is a method name and c a class of C, we say that m is in if there is m : c x —it in M. We that m is reachable c if there is c a . defined signature ij .. t,~ say from (at least) one superclass of c in which m is defined. The notion of reachabilityabovedefinesmethodinheritance.Indeed, if we view a method as a function, this function is defined in a class c but is reachablefrom (can be applied to) any subclasses of c. Methods inheritancemust alsofollowsometypingrules in order to avoidinheritanceconflicts. If two non comparable classesdefining a method m have a commonsubclass (say c”), then the method m can be inheritedfrom any of thesesuperclasses. Thesemantics of methodinheritancemustensure that the application of a method to an object is uniquelydefined. We now define the notion of a consistentdatabaseschema. Definition 8 A databaseschema S = (C, a, -<, M, G) is consistent if and only if it satisfies the following properties:(i)ifc-.cc’andm:cxtn...in—+tandm:c’xt~...i~—~t’areinM,theni1 The first propertyensures that the methodoverloading is done with compatiblesignatures, and the last one eliminates the multipleinheritanceconflicts. In the following, we shall alwaysconsiderconsistent databaseschemas. 6 Instances of a databaseschema In order to define the instances of a databaseschema, we have to define the interpretation of a type. This interpretation is defined,given an oid assignmentAK89Jwhichdescribes the instances of the classes in the hierarchy. Definition 9 Let (C, a, -<) be a subclasshierarchy. An oid assignment is a function w mappingeach class name on a set of objectidentifiers and such that for pairs of classes (c, c’) in C verifying c -< c’, we have ir(c) c ir(c’). Theconstraintsatisfied by an oid assignmentmaps the inheritancelinksfrom the classes to the instances. It means that an employee is a person and that a hotel is a monument. Definition 10 Let S be a (consistent)databaseschema. Given an oid assignment, the interpretationdom(t) of a type t in T( C) is defined as follows. • If I = u{ir(c) c E C} then dom(any) = V(I). 31 2. • For everyatomictype d, dom(d) is the domainassociated in Subsection • dom(c) = {nil} U ir(c) for all c E C. • = : : v om(aj:i~,... ,a~ : 2,2]) aj : v1,...,a~ : v~,a~÷j v,,~1.1,. .. ,an+m E dom(t1), i=1, • = dom({i}) {{vj,...,v~} I vj E dom(t), i=1, . .., n}. • = dom( Thedomainfunction is built in the usualway. Condition 1 expressesthat the onlyvalidobjectidentifiers are those of the existinginstances. We follow the CardelliapproachC84] for the domain of tupletypes and allowtuplevalueswithextraattributes. Thisdefinitionleads to a domaininclusionsemantics for subtyping, as shown in the followinglemmaswhichgeneralize the inclusion of domainsfromclasses to arbitrarytypes. Lemma 1 Let S = (C,o~,-<,M, G) be a consistentdatabaseschema. For all types t and t’ in T(C) such that t < t’ we have dom(t) C dom(t’). Lemma 2 Let S = (C,oy.<,M, C) be a consistentdatabaseschema. For all types t and t’ in T(C), t ~ t’ if and only if dom(t) C dom(t’) for all oid assignment ~r. We now define the instance of a databaseschema. Definition 11 An instance of a databaseschema S consists of a 4-tuple (7r, v, 6, a), where: • ir is an oid assignment for the schema and I = u{7r(c) I c E C}. • u is the mapping from objectidentifiers to the associatedvalues, that is ii is a function from I to V(I). This functiondefines the valueassociated to all the databaseobjectidentifiers. Of course,these valuesmust be consistent with the type of the correspondingclasses, and we imposethat: Vj E ~r(c), zi(j) E domfr(c)). • ö is an assignment for each methodsignature in M, such that 6 (m: w —~ t) E dom(w)~~0m(t). If the method m is overloaded with two differentsignatures w —p ~ and w’ —~ t’, such that w then we impose that the functions 6 (m: w —~ t) and 6 (m: w’ —+ t’) agree on dom(w). • a is a functionassociating each name of G, of type t, on a value of dom(t). This value is the value currentlyassigned to the globalname. Acknowledgements The work on the databaseprogramminglanguage and the datamodelbenefitedfrom help and feed back frommany of the AltaIrmembers. We are particularlyindebted to our colleagues in the languageteam and the systemteam. We also especiallyacknowledge F. Velez who participated in the design of a first version of the model and S. Abiteboul and P. Kanellakis who defined an object-oriented data modelAK89] from which we took inspiration. References AK89] S. Abiteboul and P. Kanellakis,“ObjectIdentity As a QueryLanguagePrimitive”, in proc. of ACM-Sigmod, 1989. BBB*88] F. Bancilhon, G. Barbedette, V. Benzaken, C. Delobel, S. Gamerman, C. Lécluse, P. Pfeffer, P. Richard and F. Velez, “The design and Implementation of 02, an Object-OrientedDatabase System”, in Advances in Object-OrientedDatabaseSystemsSpringer-Verlag,September1988. C84] L. Cardelli, “A Semantics of MultipleInheritance”,Semantics of DataTypes,LecisreNotes in CompvierScience, 1984. LR89] C. Lécluse and P. Richard.“ModelingComplexStructures in Object-OrientedDatabases”, in proc of the PODS 89 Conference,Philadelphia,March29—31, 1989. 32 UPDATING THE SCHEMA OF AN OBJECT-ORIENTEDDATABASE (Extendedabstract) AlbertoCoen-Porisini (*) Luigi aVr~z7r~ (**) RobertoZicari (*) (*) Politecnico di Milano,Dipartimento di Elettronica,PiazzaLeonardo da Vinci, 32 - 20133Milano,Italy e-mail:[email protected] (**)Cefriel, via Emanueli 15, 20100Milano,Italy 1. INTRODUCTION Schemaevolution is a concern in object-orientedsystemsbecause the dynamicnature of typicalobject-orienteddatabase applicationscalls for frequentchanges in the schemaPan88]. Therefore,updating the schema is an importantfacility for object-orienteddatabases.However,updatesshould not result in inconsistencieseither in the schema or in the database.Ensuring the consistency for an object-orienteddatabase is a difficulttask.Thisdifficulty is due to the richness of the object-orienteddatamodel and to the use, in mostsystems, of an imperativelanguage to implementmethods. One of the authors of thispaperbeganaddressing the problem in 1989 for a specificobject-orienteddatabasesystem: 02 developed by GIPAltair. We assume in the rest an object-orienteddatabasesystem with the characteristicsillustrated in the nextsubsection, but we do notrefer to a specificoodbms. 1.1 Basic Assumptions We consider a databasesystem with both the notion of types and classes.Instances of a class are objectswhich encapsulatedataand behavior.Instances of a type are values. To everyclass is associated a typedescribing the structure of the classinstances.Types can be complax;they are createdrecursivelyusingatomictypes(integer,boolean,etc...), classnames,and the set, list,andtupleconstructors.Objectshave a uniqueinternalidentifierand are encapsulated,their values are not directlyaccessible and they are manipulated by methods.Methoddefinition is composed of two parts: a signature, that is the type of the arguments (if any) and the type of the result (if any), and a bodywhichcontains the code of the method. We assume an imperativelanguage for specifying the body of methods.(Thiscontrasts withother object-orienteddatabasesystemsbased on “pure”object-orientedparadigmssuch as SmallTalk).Methods are attached to classes and therefore they are part of the schema. We considermultipleinheritance and assume a semantics for inheritancebased on the notion of subtyping.Inheritancebetweenclassesdefines a classhierarchy. A schema is composed of a set of classesrelated by inheritancewhichfollows the type compatibility rules of subtyping,and/or by compositionlinks, plus a set of methods.Classattributes and methods are identified by name. The system uses late binding and allowspolymorphism. We alsoassume the systemoffers a compile-typechecker to staticallydetect as manyillegalmanipulations as possible of objects and values.Examples of suchOOLlanguages are the EiffelprogramminglanguageMey881, and the schemadefinitionlanguage of the 02 object-orienteddatabase systemLR89]. 1.2 Schemaupdates: What is the problem? Informally, the problem withschemaupdatescan be stated as follows: We want to change the structure and behavioral part of a set of classeswithoutresulting in run-timeerrors,“anomalous”behaviorand any otherkinds of uncontrollable situations. In particular, we want to assure that the semantics of updates are such that when a schema is modified, it is still a consistentschema. Consistency can be classified as follows: 1. Structuralconsistency. This refers to the static part of the database. An object-orienteddatabase is structurally consistent if: i) its classstructure is a directacycicgraph(DAG); ii) its attributeand methodnamedefinitions,attributeandmethodscoperules,attributetypes and methodsignatures are all compatible. In particular we assume a covariancecondition to ensurethatmethodoverloading is donewith compatiblesignatures; iii) no multipleinheritanceconflicts(alsodenoted as nameconflicts)mustoccur. Thiswork has beenpartiallysupported by CNR - ProgettoFinalizzatoSistemiInformativi e CalcoloParallelo. 33 2. Behavioralconsistency.Thisrefers to the dynamic part of the database. An object-orienteddatabase is behaviorally consistent if execution of methodsdoes not result in run-timeerrors or unexpectedresults.Checking the signature of a method is not sufficient to ensurebehavioralcompatibility of the method.There are twodistinctnotions of behavioral inconsistencies:method’sfailure, i.e. run-timeerrors, and method’schange of behavior, i.e. no run-timeerrorsoccur, but the result of the method is different than the one expected. In the rest of this paper we will onlyconsider the first case. 2. SCHEMAUPDATESPRIMITIVES For reason of space we do not report the syntax and semantics of the full list of schemaupdateprimitives we have defined for changing the schema. A minimal set of schemaupdates is the following: 1. Add an attribute in a class,Delete an attribute in a class. 2. Add a method in a class,Delete a method in a class, 3. Add a class,Delete a class,Make a class a superclass(subclass) ofanotherclass,Re~nove a classfrom the superclass (subclass) list of a class,Change the name of a class. Updatescan be furtherclassified as type-preservingandnon-typepreserving. It is also worthnoticing how the notion of completeness of a set of basicupdates at schemalevel, that is whether the set of basic updatessubsumeseverypossible type of schemachange, is not necessarily the same one at data base instancelevel. For example,consider the update:change the name of a class, at schemalevel this is equivalent to deleting the classand thenadding a newclass.However this obviouslydoes not hold at (object)instancelevel. There are differentways to define the semantics of updates,especially of the oneslisted at point 3. Oneway to go is to defineverybasicupdateswith a defaultsemantics, the other is to definehigher-levelparametrizedprimitivesallowing the designer to definehis/herownsemantics. The followingsimpleexampleshows this point.Consider the schema of Figure 1 composed of threeclasses:Person,PhD, andEmployee(withassociatedtypes Ta, Tc, Th). Person type Ta PhD typeTc Employee type Th Figure 1 Suppose we perform the update:removeclassPhDfrom the superclass list ofEmployee. Theeffect of this update is in disconnecting the class Employee from the DAG (PhD is the only superclass of Employee). To preserveschema consistency, the classEmployee has to be connected to someotherclass(es) in the DAG.There are twopossibilities: - ClassEmployee is made a directsubclass of directsuperclasses of PhD(classPerson in the example); - ClassEmployee is made a directsubclass of the rootclass of the DAG:OBJECT. Moreover, we need to definewhathappens to the type of EmployeeTb.There are againtwopossibilities: - classEmployeeloses all attributesinheritedfromPhD; - classEmployeedoes not lose attributesinheritedfromPhD;attributeswhichwereinheritedbecomelocallydefined in Employee. Sameconsiderationshold for methods as well. The use of parametrizedupdateoperatorsallows the definition of all thesedifferentupdatesemantics. A moreprecise definition of the set of basicschemaupdatesprimitives and of the parametrizedones is reported in Zic9O],Zic9la], Zic9lb]. 3. ENSURINGSTRUCTURALCONSISTENCY An update to a schema is a mappingwhichtransforms a schema S into a (possibly)differentschema S’. Schemas S and S have to be structurallyconsistent. The semantics of the schemaupdateprimitives will have to ensure at least that structurallyconsistentschemas are produced as a result of an update. The approach is to use a graph-theoretic tool set to enforcenecessaryconditions for the structuralconsistency of a schema:nameconflicts,typeconflicts,requirements for signatures, andcycleconflicts.This is obtained by mapping the partiallyordered set of classes of a schema into a graphstructure. By definition a schema S is structurallyconsistent.Everytime an update is performed on a schema S andresults in a new schema S’, the graphcorresponding to S is analyzed to checkwhether S’ is a schema. Formoredetails the reader is referred to DelZi9l]where a graph-theoreticapproach is used to ensure the 02 schema structuralconsistencywhenperformingschemaupdates. 34 Whilemost of the workdone on schemaupdates has concentrated on preservingstructuralconsistencyB*871,PS871, an important and difficult area of investigation is behavioralconsistency. In Section 4 we sketch a new data-flow technique to detectbehavioralinconsistencies. 4. A DATA FLOWTECHNIQUE TO DETECTBEHAVIORALINCONSISTENCIES Our goal is to find a pragmaticalworkablesolution to avoid the risk of behavioralinconsistency due to run-time type errors. It is known that type safeness of a generalschema is an undecidableproblemAKW9O,HTY89].However, using a simple data flow analysistechnique we can expresssufficientconditionsensuring type safeness. If such conditions arc not satisfied then a run timeerrormightoccur;whether a run timeerrorreallyoccurs or not depends on the actualexecutionflow of the applicationusing the schema.Thisresearch is currently in progress. We present in the sequel ourpreliminaryresults. Examples of run-time typeerrorsare: a wronginput to a method, an incorrectassignment. a reference to a non existing method or classtype. We do not consider the case of non-terminatingmethodexecution. Standardcompilers are not alwaysable to detect all typeerrors. Let us consider the followingexample: Class A Class Example typetuple (a: Integer) type tuple (x : X; y: Y; p: A) methodget_a:Integer is public method m3 : Integer is public body { return(self.a) } bodyf end A 1 p= new(A); 2 Class B inherits A y= new(Y); typetuple (b: Integer) 3 x = methodget_b:Integer is public . y,; 4 body { return(self.b)) return(self.x.m1(p))) the obtained end B /* Returns value by adding the value of the attribute xl of x and the Class X value of the attributeaofp*/ typetuple (xl : A) end Example methodml(t:A):Integer is public body{return(self.xl.get_a + t.get_a)} end X Class Y inherits X typetuple (yl : B) end Y Suppose we want to redefine the method ml in class Y as follows: Addmethodml(t:B):Integer in class Y is public body {. return(self.yl.get_b + t.get_b) Note that the new definition of ml in class Y satisfies the covariance rule and mostcompilers (e.g. Eiffel, 02) will accept this change.After the updatemethod m3 will invoke the new method ml defined at Y since x is bound to an object of class Y (because of the assignment at line 3). Hence ml will try to access the attribute b of its actual parameter p. But p is bound to an object of class A whichdoes not have an attributenamed b and this causes a run time error to occur. We sketch in the rest of this section the dataflowtechniquewhichdetects thiskind of errors. 4.1 The Data Flow Analysis We associate to eachattribute Xj belonging to a class C1 a set S1 that contains the type of any object that X1 may be bound to at run time. S1 is called the type set of xi. Initially S1 contains the static type of Xj (i.e. the type specified in the declaration of x) and all of its subtypes (if any). In the example, the type set S~ of the attribute x in ClassExample is (X, Y}. It is possible to prove that by looking at the type set associated to eachattribute in the schema it is possible to identify run timetypeerrors. Let us define the set of all pairs exec(I1;I2;...;In,TD) = exec(12;...;In,exec(Ii,TD)) TheT-Descriptor is computedrecursively by applyingexec to eachstatement. 35 Objectdynamiccreation (Xj = new(Cj)) exec(xj=new(Ci),TD) = TD’, where TD: { The type set of the variablebounded to the newlycreatedobjectinitiallycontainsjust the type of the objectcreated. In the example in method m3 the I-Descriptorafter the analysis of the statement at line 2 is (x retains its initialtype set value{X,Y}): ID: { Assignmentstatement (Xj := xj.m(xI exec(xi := = TD’ where xj.m(xl,,...,xn), TD) , TD: { The variable xi in the left handside of the assignment has the sametype set of the expression in the righthand side of the assignment. Referring to the example, in the body of m3 the I-Descriptorafterexecution of line 3 is: ID: {.czx,(Y}>, exec(if C then!! else 12 fi, ID) = exec(Ii, TD) . exec(12, TD), where The type set associated to each variable is the set union of the type sets resulting at the end of both branches of the conditionalstatement. For reason of spacelimitation we omit the definition of the function exec for the othertypicalstatements of an imperativelanguage.Theinterestedreader is referred to CLZ9 1] for suchdefinitions. SufficientConditions A (runtime)typeerrormayoccur if one of the followingsufficientconditions for typesafeness is violated: 1) Type sets contain the types that the associatedattribute may be bound to at run-time;therefore, at each step of the dataflowanalysis~everytype set should be totallyorderedwithrespect to the subtypingrelation. In addition, the type set should be superiorlimited by the static type of the associatedattribute.Attributescannotrefer to objectsbelonging to a superclass of theirstatic type. For example, in the classExample the type set of the attribute x shouldcontainonly X and/orsubtypes of X. 2a) If a method is invoked on an attribute(e.g. x.m) then theremustexist a definition of the method,eitherlocally or inherited, for everytypebelonging to the type set of thisattribute (x). 2b) Type sets associated to everyactualparameter of a methodshould be superiorlimited by the statictype of their correspondingformalparameter. As a consequenceanyobject that is passed as a parameter to a methodconforms to the defmition of the correspondingformalparameter. In the example, the T-D descriptor for method m3 in classExampleduring the call of ml (line 4) is: { 5. OBJECTUPDATES Objectinstanceshave to be modified in accordance to the schemachange.There are threebasicapproaches to perform schemaupdateswithrespect to the database: - Screening, I We consideronlyassignmentstatement of the form xi := xj.m(xl, xn); this should not be viewed as a restriction since any assignment can be transformed into an equivalent(sequence of) new one(s)having the previousform. For instance x := y; can be transformed into x := y.m, wheremethod m simplyreturns self. The composition of methods such as x := y.m2.ml can be transformed into the following sequence of assignments: temp := y.m2; x := ternp.mi. - Immediateconversion, - On demandconversion. The comparison of theseapproaches is not simple, as it requires a cost-analysis and simulationtechniques. A first preliminaryanalysis is reported in Zic9ib]. 6. CONCLUSIONS Wehavedesigned and implemented a firstprototype of a tool whichensuresstructuralconsistencywhenupdating an 02 schema. The tool, calledInteractiveConsistencyChecker(ICC),allows an interactivedialogue with the schema designer. The ICC given a schemaand a proposedupdate,detectswhetherstructuralinconsistenciesmayoccur. It then refusesthoseupdateswhichproducestructuralinconsistencies. Thereason for the refusal of the update is alwaysgiven to the user. A detaileddescription of the ICC is reported in DelZi9l]. We haveimplemented a secondversion of the ICC tool for the object-orienteddatabaselanguageSQLdeveloped in the Espritproject2443“Stretch”ZCT9 1]. We are now designing a new tool which is a front-end of the compilerwith the followinggoals: - Reducing the number of recompilationsevery time a schemaupdate is performed. We are extending well known techniques for smartrecompilation to the object-orientedparadigm. - Detectpossiblebehavioralinconsistencies due to run-time type errors. The tool will use the data flow technique shown in section 4. - Helping the schemadesigner in performingschemaupdates. To this purpose, it is useful to groupupdatestogether: Thenotion of transactionupdatesallows the transformation of certainillegalupdates into a sequence of updateswhich result in legalschemamanipulations. Themostobviousevolution of our approachconsists in the integration of the varioustools in the compileritself. Moreover, we are studying the problem of schemaupdates in the presence of a set of constraintsassociatedboth to the schemaand to the instancedatabase. Acknowledgments RakeshAgrawalprovidedusefulcomments on an earlierversion of thispaper. REFERENCES AKW9O] Abiteboul S., P. Kanellakis, E. Wailer, “ MethodSchemas”, in Proc.ACM,PODS 1990. B*87] Banerjee et al. “Semantics and Implementation of SchemaEvolution in Object-OrientedDatabases”,Proc. ACMSIGMOD, 1987. “ CLZ91J Coen A., Lavazza L., Zicari R., Updating the Schema of an Object-OrientedDatabaseSystem”, Politecnico di Milano,ResearchReport, 1991 DelCourt C. Zicari “The of an Checker for DelZi9l] , R., Design IntegrityConsistency (ICC) an Object-Oriented DatabaseSystem”,Politecnico di Milano,Report91-021,April 1991. A shortversion in Proc.ECOOP, Geneve,July 1991 HTY89] Hull R., K:Tanaka, M. Yoshikawa“BehaviorAnalysis of Object-OrientedDatabases:MethodStructure, ExecutionTrees and Reachability”, Proc. 3rd Intl. Conf. on Foundations,of DataOrganization and Algorithms,Paris,June 1989. LR89] Lecluse C., Richard P., “02, an Object-Oriented Data Model”,Proc. 15th VLDBConf.,Amsterdam, August1989. Mey88] Meyer, B. “ObjectOrientedSoftwareConstruction “, Prentice Hall International - Series in Computer Science(1988). PS87} Penney D.J., Stein J., “ClassModification in the GemStoneObject-OrientedDBMS”,ACMOOPSLA, October1987. Pan88] Report on the Object-OrientedDatabaseWorkshop: Panel on SchemaEvolution and Version Management,SIGMODRECORD, Vol. 18, No.3,September1989. ZCT91] Zicari R., Ceri S. Tanca between a Rule-basedDatabase , L., “Interoperability Language and an Object- OrientedDatabaseLanguage”, in First mt. Workshop on Interoperability in MultidatabaseSystems, Kyoto,Japan,April 7-9, 1991. Zic9O] Zicari R., “Primitives for SchemaUpdates in an Object-OrientedSystem: A Proposal”,OODBTG X3 October Workshop, IPS, SPARCIDBSSG/OODBTG , 23, Ottawa,Canada. Zic9la] Zicari R., “A Framework for SchemaUpdates in an Object-OrientedDatabaseSystem”,shortversion of Zic9lb] in Proc. 7th IEEEDataEngineeringConference,April8-12,1991,Kobe,Japan. Zic9lb] Zicari R., “A Framework for SchemaUpdates in an Object-OrientedDatabaseSystem”, in “The 02 book”, (F. Bancilhon, C. Delobel. P. Kanellakiseds.),MorganKaufman, 1991 to appear. 37 An Overview of IntegrityManagement in Object-OrientedDatabases Won Kim Yoon-Joon Lee’ Jungyun ~ UniSQL, Inc. 9380ResearchBlvd. Austin, TX 78759 (512)343-7297 ‘Department of ComputerScience KAIST Daejeon,Korea 1 Introduction Ideally, a databasesystemshould be designed to enforcearbitraryintegrityconditions that the user may be able to specify 3, 2]. Although in the mid-seventies,researchersinvestigated the semantics and implementationarchitecture of integrityconstraints and triggers,currentcommercialdatabase systemsenforce a minimal set of integrityconditions,largelybecause of the performanceoverhead that enforcement of integrityconditionsincurs. However,during the past several years there has been a perceptiblerenewedinterest in integrityconstraintè and triggers 7], both in the context of active datamanagement and methodsupport in object-orienteddatabasesystems. We feel that a classification of integrityconditions on the basis of their performanceimpact may prove to be a useful basis for the currentresearch and developmentefforts. It may provide a good basis for the design and implementation of databasesystems that can support a significantlyricherenvironment for automaticpreservation of user-specifieddatabaseintegrity than is provided by the current databasesystems. In this paper, we provide a preliminarydiscussion of a framework for classifyingintegrity con straints in the context of an object-oriented datamodel. An object-oriented datamodel gives rise to additional types of constraintsbeyond those meaningful under the relationalmodel. A fuller treatment of the issues of integritymanagement in object-orienteddatabases is given in 5]. 2 Types of IntegrityConstraints We identify five types of integrityconstraints in the context of relationaldatabases on the basis of a qualitativecomplexity of their evaluation. We note that the classification does not presume the existence of special data structures (e.g., indexes,sortedtables). This classification, with certain extensions, is also applicable to object-orienteddatabases. Type-i: A singlecolumnwithin a singlerecord:constraintswhich can be checked in a single columnwithin a singlerecord. 38 Type-2: A singlerecord:constraintswhich can be checked in multiplecolumnswithin a single record. Type-3: A set of records of a table: constraintswhichrequireaccess to a set of records in a table. Type-4: All records of a singletable:constraintswhichrequireaccess to all records of a table. Type-5:Records of multipletables: constraints which require access to records of multiple tables. If we adopt the view that an object-oriented data model is a generalization of the relational data model, the five types of integrityconstraint for the relationalmodel have directcounterparts under an object-orientedmodel. All that is necessary is to substitute the termsrecord and relation with object and class, respectively. However, an object-oriented datamodelincludesseveralconcepts that the relationmodel does not have. We now examine how these additionalconcepts gives rise to additionalconstraints in object-orienteddatabases. The following are the additionalconceptssupported in object-oriented databases. • An objectencapsulatesattributevalues and methods. • An attribute may have an arbitrarilycomplexnesetedobject as its value. • An attribute may have a set of values. • Classes are organized in a class hierarchy. Methods There is no correspondingnotion of methods in the relational data model. Methods can be written in any programminglanguage, and, as such, have universalcomputingpower. Since a method is defined for a class, it can be used in specifyingconstraints on the objects of the class. Therefore,users are not limited to usingonlyqueryexpressions to specifyconstraints as in relational databasesystems.However,usersmust be aware of the complexity of the methodsused in constraint specifications and be prudent in the use of methods so as not to degradesystemperformance due to constraintchecking. NestedAttributes Unlike the relationalmodel, an object-orientedmodelallows an attribute to have as its value an instance of an arbitraryclass. If an attribute of an object, say Obj 1, has as valueanotherobject, say Obj2, users can use attributes of Obj2 (and the objects that attributes of Obj2 has as their values, and so on) in the constraintspecifications for Obji. The traversal of a nestedattribute is equivalent to a join in relationaldatabases. To check a constraint on a nestedattribute, the systemmustaccessobjects in morethan one class. Therefore, a constraintspecification on a nestedattribute is in general type 5 in our classification.1 1Depending on implementations, thesystemmay not have to check all instances of multipleclasses for a constraint on a nestedattribute; the checkmay be limited to a constantnumber of dataccesses.4] 39 Vehide (manufacturer.president.salary<600000) Figure 1: Placement of a constraint on a nestedattribute Anotherinterestingquestionconcerningconstraints on nested attributes is whether the con straintlogicallybelongs to the starting class or the terminal class of the nested attribute. For example, let us consider the followingconstraintspecification for the class Vehicle in Figure 1 whichshowsrelevantclasses in the schema and objects of the classes. ( manufacturer.president.salary < 300000 ) Thisconstraintinvolvesobjects of three differentclassçs:Vehicle,Compa.ny, and Employee. Intuitively,since the constraint is defined in the classVehicle it should be placed in the defini tion of Vehicle, the startingclass of the nestedattribute. In this case, the constraint is applicable to everyinstance of Vehicle. The constraint will be checked when the systemattempts to access the value of an instance of Vehicle, say V1001.manufacturer.president.salary. On the other hand, since the actual valuewhich must be compared is in one of the objects of the classEmployee, the constraint mayneed to be part of the definition of the classEmployee, the terminal class of the nestedattribute. The justification of this approach is that in object-oriented databases, an object,identified by a uniqueidentifier, is a logical unit of access, and therefore a constraintmay be associatedwith a singleobject,ratherthan a class. However,since this conStraint is meaningful for the class Vehicle and only one instance,E1928, of Employee, it does not seem appropriate to place the constraint in the class definition of Employee. Set-ValuedAttributes The fact that an attribute may have a set of valuesfrom its domaingives rise to a new type of constraint;namelyconstraints on the cardinality of the set of values for the attribute. Ex. 2.1 A new class definition for CountryClub. 40 ( CREATE—CLASSCouxitryClub :ATTRIBUTE ( (member:cardinality MAX 370 :domainperson ) ) ) In this example, the maximumnumber of members of a country club is 370. The constraint may also be specified with MIN or EXACT to specify the minimum and exactnumber of elements in a set of values. This type of constraint falls into type 3 in our classification. ComplexObjects A complexobject is in general a cluster of relatedobjects in which an object may recursively reference any number of other objects. A complexobject is modeled by combining the concepts of a nested attribute and a set-valuedattribute. In generaldatabases for engineering-oriented applications are collections of complexobjects, in which an object references other objects and an object may in turn be referenced(shared) by any number of otherobjects. When an object is updated or deleted, or a new version of the object is created,some or all otherobjects that reference it may becomeinvalid, and thus need to be notified of the change 6, 1]. It is desirable for users to be able to specifyconstraints for changenotification. For example, a user may need to specify the followingconstraint for a CAD application: when memory-layou~ 101 is updated or deleted, send a changenotification to board-design-groupi. We note that this constraint is defined not on the classmemory—layout, but on one instance(memory-instance—lol) of the class. This type of constraint falls into type 1 in our classification, since it can be checked against the singleobject on which the constraint is defined. In relationaldatabases, users can only specifyconstraints on a table,rather than on a singletuple of a table. ClassHierarchy A class hierarchyrepresents the isa relationshipbetweenclasses. The isa relationshipmeans, amongotherthings, that any instance of a class is logically an instance of the superclasses of the class. For example,when a user is to select all instances of Vehicle, the system mayneed to access all (direct)instances of Vehicle and all instances of the subclasses of Vehicle(indirectinstances). A constraintinvolvingonly directinstances of a class is of type 3, since it may be evaluated by accessing only the instances of the class. However, a constraint on all direct and indirectinstances of a classrequiresaccess to more than one class, and is of type 5 in our classification. 3 Conclusion In this paper, we discussedintegrityconstraints to which the paradigm shift from the relational model to an object-oriented model of data gives rise. This is one of the aspects of research into object-orienteddatabasesystems which have not receivedadequateattention up to now. The preliminaryresults we presented are a part of our broaderresearch into integritymanagment in activeobject-orienteddatabasesystems. The broaderresearch is motived by our wish to establish a classification of events,conditions, and actions in triggers in active data managementsystems which will be useful in helpingsystemdevelopers and users to understand the tradeoffbetween the performance and flexibility in specifyingintegrityconstraints. 41 4 Types of TriggeringEvents and Actions Due to space limitations, in this section we provide only a briefoutline of our classifications of events that triggerconstraintchecking, and actions that a databasesystem may take upon being triggered. Moredetails are provided in 5]. In the context of databasesystems, we can categorizeevents into two classes;databaseaccess event and non-database access event (or externalevent). The “intuitive”criterion we use for classifyingevents is the overhead to the system for processing the events. For eventsinvolving a smallnumber of objects (e.g., an update of a singlerecord), users will expect fast response; while users will be moretolerable of slowerresponses for eventsinvolving a largenumber of objects (e.g., a timer interrupt to checkpoint the database). When users can be expected to tolerateslower responses,complextriggering-eventspecifications may also be tolerable.However, for eventswhich requirequickresponses,complicatedtriggerspecifications may not be desirable. In mostexistingdatabasesystems, the onlyactiontaken in response to a violation of constraints is to reject the transaction and set a pre-definedparameter with some error code. This is often inadequate, and databasesystemsshould allow a set of more usefulactions. Actions can roughly be categorized as follows: • rejecttransaction • databaseupdates • othergeneralevents “whendeleting the table Department,updateEmployee.dept# to NULL”, and “if the object memory—layoutlOl is updated, set the update-timestamp to the current time” are examples of triggereddatabaseupdates. Othergeneraleventsinclude any action not related to the database, such as “call systemoperator”, and “send an e-mail to cpu-design-group” are examples of general events not related to the database. References 1] H.-T.Chou and W. Kim. A unifyingframework for versioncontrol in a cad environment. In Proceedings of the InternatwnalConference on Very Large Data Bases,pages336—344, 1986. 2] C. J. Date. An Introduction to DatabaseSystems.AddisonWesley, 4 edition, 1987. 3] E. B. Fernandez, R. C. Summers, and C. Wood,editors. DatabaseSecurity and Integrity. AddisonWesley, 1981. 4] W. Kim. Introduction to Object-OrientedDatabases. MIT Press, 1990. 5] W. Kim, Y.-J. Lee, and J.-Y. Seo. IntegrityManagement in Object-OrientedDatabases. UniSQL, Inc. TechnicalReport, Feb. 1991. 6] T. Neumann and C. Hornung.Consistency and transactions in cad databases. In Proceedings of the InternationalConference on Very LargeData Bases, Sept. 1982. 7] M. Stonebraker, E. Hanson, and C.-H. Hong. The design of the postgres rules system. In Proceedings of InternationalConference on Data Engineering,pages356—374, 1987. 42 SupportingViews in Object-OrientedDatabases Marc H. SchoIl and H.-J.Schek ETH Zunch, Dept. of ComputerScien~,InformationSystems — Databases ETH Zentrum,CH—8092Zurich,Switzerland.E-mail:{schofl,sthek}@inf.ethZ.ch 1 Introduction Relationaldatabasesystemsprovide a powerfulabstractionmechanism: any query,since it returns a relation, can be used to define a view, that becomes a derived (or virtual)relation. Views are defined by a statement such as “define view • Queryformulation is simplified, if frequentsubexpressions are predefined. • Applicationprograms are insulated from changes to the underlyingschema. • Information can be restructured to better suit an applicationprograms’requirements. • Derivedinformation is kept consistent with base data. • Accessrestrictions (for authorization) can be enforced by hiding data. In contrast to baserelations,views are typically not storedpermanently, but rathercomputed on demand.Queries to viewrelations are modified by querysubstitution so as to operate on the underlying base relations.Therefore, any update to a baserelationpropagatesautomatically to all viewsdefined over it. Conversely, view relations can not be updatedfreely,since it is oftenambiguous how to trace viewupdates back to updates of basetuples.1~’pically, only viewscontaining the key of their (one)underlying base relation can be updated. The view mechanismshould also be offered by the next generation,object-orientedDBMSs.Objectidentity (Old) will alleviate the view updateproblem. If objects are identifiedindependent of the valuesassociated with them, it is possible to propagateview updates back to base objects.1 If we want to defineviews as in relational DBMSs, by queries, this has importantconsequences on the querylanguage. Mostimportantly,queries will have to preserveobjectidentity. The otherpossibilitiesdiscussed in the literature are object-generatingqueries and queries returning data values (e.g., relations). We will resthctourselves to queriesreturningexistingobjects. Otherwise, updates to queryresultswould not propagate to the originalobjects. If queriesreturnoriginalobjects, the main questions are: How can we allowrestructuringoperations (if they change the type of objects)? Is it possible to use queryoperatorssimilar to the relationalprojection or join, and still have queriesdeliverbase objects? What flexibility is needed in the type system, and can we still apply(some) static type checking? Theseissues are addressed in this briefoverview of the workperformed in the COCOONproject at EThZurich 8, 9]. We first discussobject-preservingquerysemantics of a genericobject-orientedquerylanguage in the style of a relationalalgebra. Then we show how viewsdefined by such queryexpressions can be updated: We elaborate on certainfundamentalproperties of the objectmodel, such as the separationbetween types and classes,multiple instantiation (an object may be an instance of several types at the sametime), and multiple class membership (an object may be a member of severalclasses at the same time). 2 Terminology We use the object-function model called COCOON 9], that has been developed as an evolution from and generalization of the nestedrelationalmodel 7]. The IRIS model II] with its roots in DAPLEX has similar features.Objects are pureabstractions, all data (or objects) are associated to them (as “state” or “related”objects) by functions.2 This means that “attributes”,“components”, or “instancevariables” are not distinguished from “derived” or “computed”values. Similarly, we can oftenneglect the differencebetween(retrieval)functions and (update)methods, and treat them in the same way. We use the followingterminology: • Objects are instances of abstracttypes,specified by theirinterfaceoperations. Data are instances of concrete types (e.g., numbers,strings) or constructedtypes, such as tuples or sets 2, 9]. data. Formally,objectidentity is a prerequisite for updates:without Old we could only replace, but nevermodify 2 of In implementationterms, this means: the objectitself is just an identifier. The “state” of the object is the collection returnvalues of all functionsdefined on it the Old to other Olds or (that map objects, i.e., , values). 43 • Functions are eitherretrievalfunctions or updatemethods. They are described by their name and signature (that is, domain and rangetypes). Functions may be set-valued. • Types are described by their name and the set of functions that are applicable to their instances. Types are arranged in a subtypehierarchy,wheresubtypesinheritfunctions from their supertypes. Objects can be instances of more than one type at the same time (“multipleinstantiation”). • Classes are typed collections of objects(sometimes also called “type extents”). Classes are arranged in a subclasshierarchy that is exactly the set inclusionbetween the sets of objects they represent. Objects are “members of” classes,possibly more than one at a time (“multiple class membership”).Particularly, superclassescontain all members of their subclasses. We note that the separation of types and classes is essential. In the relationalmodel, a type corresponds to a relation’sschema (the structure), a class to a relation’sextent (the set of tuples). At first glance,classescould be viewed as (persistent) sets of objects. However, a set is data, whereas a class is an object 2, 9]. That is, it has an identity that is independent of that set of classmembers. Each class object is an instance of the type classtype, which has (amongothers) two importantfunctions: For each class C, membertype(C)returns the associated type, and ex:ent(C)returns a set of objects of this type, the class members. Classextents are polymorphic sets: member objects may be instances of many differenttypes. However, they are uniform in that every member is (among others) an instance of membertype(C). In the querylanguage,where we use classes as arguments, type checking is based on this uniquemember type. An importantadditionalfeaturedistinguishes our model fromothers: classpredicates.These are usuallyfound in knowledgerepresentation(classification)languages such as KL-ONE 4, 3]. Ourclasses may be constrained by a predicate thatmust be satisfied by all members of the class. We distinguish two cases: classpredicates may be only necessary or necessary and sufficientconditions. Classpredicates can serveseveralpurposes: first, they allow the specification of integrityconstraints(necessarypredicates).Second, they are our means of separatingcompile-time typecheckableaspects of objecttypes fromrun-timechecks: the former are part of type definitions(e.g., function signatures), the latter are expressed as classpredicates(e.g.,cardinalityrestrictions for set-valuedfunctions). Third, and most importantly, class predicates can be used to handleupdates to (selection)views: if class predicates are necessary and sufficientconditions, then all (common)members of the superclass(es) that satisfy the predicate are automaticallyclassified into the subclass.Conversely, if objects in a class (due to updates) no longersatisfy the classpredicate, they are re-classified(recursively) to belong to the superclass only. As an example,consider two classesPersons and Adults, both of the same typepersonlype. We know that a person is an adult, if and only if his or her age is over 17. So we define a necessary and sufficientclass predicate for classAdults that will automaticallyincludemembers of the Personsclass into the subclasswhenevertheir age is 18 or more. The systemshouldautomaticallyremovepersons from the subclass (andkeepthem in the superclass only)whenevertheir age is changed to a valuebelow 18. In COCOON, this situation is represented as follows: define typepersontype isa objeduype = name: string, age: integer defineclassPersons:persontypesomeObjects; defineclassAdults:persontype all p:Personswhereage(p) > 17; Type definitions list the (set of) supertypes(objecuype, the predefined top of the type hierarchy in our example) and the applicablefunctions with their range types. Class definitionsinclude the membertype and the (set of) superclasses(Objects, the predefined top of the class hierarchy, for Persons and Persons for Adults). The optional predicate(none is present for the classPersons), is a necessarycondition in case of a somequalifier, and necessary and sufficient in case of an all qualifier.Therefore, in all validdatabasestates, the extent of classAdults will always be exactly thosemembers of class Persons for which the age functionreturns a value over 17. Notice, that this class definition of Adults is just what we wouldexpectfrom a (selection) view definedover the Personsclass. 3 Object-PreservingQuerySemantics We use a set-orientedquerylanguagesimilar to relationalalgebra,where the inputs and outputs of the operations are sets of objects. Hence,queryoperators can be applied to extents of classes,set-valuedfunctionresults, and queryresults. Many such object-orientedalgebras havebeen proposed in the literature. We can distinguish three approaches to the exactsemantics of queries,depending on what the result of queries are: 44 I. “Relationalsemantics”: queryresults are data values, not objects. For example, every query may return a set of tuplescontainingsomevaluesdescribingproperties of objects. This semantics is useful for generating queryoutputs (we do not want to deliverobjects, or Olds, to the user), but it is not suited for the definition of (updatable)views, sinceobjectidentity is lost, so updatesmake no sense. 2. “Object-generatingsemantics”:queriesgeneratenewobjects. The states of the new objects are (J)artial)copies of the states of qualifyingobjects. Again the problem is how to propagateupdatesback to the originalobjects. This kind of querysemantics is motivated by objectmodels that do not allowobjects to be instances of more the than one type (class). If the type (“structure”) of objects is modified by the query (e.g., a projection), result has to be a set of new objects. 3. “Object-preservingsemantics”: queriesreturn(some of) the inputobjects. As an immediateconsequence of type-changingqueryoperators,such as projections or “joins”, we have to allowmultipleinstantiation.Multiple class membership is a consequence of makingqueryresultsclasses. This semantics for queriesallows the application of methods and genericupdateoperations to results of a query,sincethesecontain baseobjects. To defineupdatableviews by means of queries, we should opt for object-preservingoperatorsemantics.Otherwise, one must play some implementation tricks when voting for otherquerysemantics in order to provideupdatable views. For example, one can internally keep the original Olds together with the new objects. However,object- preserving query semantics is the cleanerconcept. Then views are additional(virtual)classes that need to be positioned in the class hierarchy, and their membertypes need to be positioned in the type hierarchy. The objects in these view classes are base objects. In the sequel, we give a briefoverview of the COOLquery language and its semantics in terms of result with types and extents. In COOL,operands are sets of objects, the operators are the relationalalgebraoperators appropriateextensions(syntactically,operandsmay be classes:formally, the operands are the extents of the classes). Queryresults are also sets of objects. Viewdefinitionsintroduce new (virtual)classes,whoseextent is defined by the query. For viewsdefined by each of the basicCOOLoperators, we describewhat the membertype and extent all views is, and how these are positioned in the type and class hierarchies. For ease of presentation,assume that are definedoverbaseclasses. In general,views may also be definedoverotherviews, or by compositequeries (see 8] for a detailedexposition). In the following, let C be a class with member type T. Selection (define view V as select P] (C) ). The viewclass V is a subclass of the baseclass C, with the same member type T. We now have two classes, V and C, of type T. The extent is the subset of C-memberssatisfying P. In fact, the effect of the viewdefinition is precisely the same as if class V were defined with a necessary and sufficient class predicate: “define class V:T all C where P”. Projection (defineview V as project ~f, f,j (C)). Theviewclass V is a superclass of C. Themembertype, say T’, of V is a supertypeofT(lessfunctions are defined,onlythoselisted in the projection: Ii f~), the extent of V is that of C. Theeffect is the same as a schemadefinitioncontaining a statement“defineclass V: T’ all C wheretrue”. Extend (define view V as extend/:= Set operations. As the extent of classes are sets of objects, we can perform set operations as usual. Their effects on class extents is theirstandard set theoreticsemantics. Due to the polymorphic type system, we need no restrictions on the operands’membertypes (ultimately, all objects are instances of objecttype). The member type of the result,however,depends on the operands’types: A union view is a commonsuperclass of the baseclasses, views whosemember type is the lowestcommonsupertype (in the type lattice) of the inputtypes. Difference are with subclasses of their baseclass with the samemembertype;finally, an intersectionview is a commonsubclass a member type that is the greatestcommonsubtype of the inputtypes. 4 View Updates Beyondtype-specificupdateoperations (i.e., methods), we provide a collection of genericupdateoperators to that take as facilitateset-orientedprocessing. First, there is a set-iterator for updates,update m] ( 45 arguments a set of objects and an updateoperation, m, to be performed on all elements. The othergenericupdate operators are insert and delete for creating and destroyingobjects, add and remove for including and excluding existingobjectsinto/from sets (in contrast to insert and delete, add and remove have no effect on the existence of the objects), and set to assignvalues (data or objects) to functions. For type-specificupdateoperations(methods), there are no restrictionswhatsoever on view classes and all methodsincluded in the view’s membertype can be invoked. Notice, that type-changingoperations, such as projections, deal with updatemethods and retrievalfunctions in the same way: a projection list includes the methods that shall be visible in the view! For the genericupdateoperators of COOL, the semantics of their application to view classes is alwaysdefined to be exactly the same as if the view class were defined as a base class with a necessary and sufficient class predicate(“define class V...all...where...”).Therefore, the foundation of our updatesemantics is automaticclassification:updatingobjects may cause the objects to dynamicallychange class memberships. The alternativesolution of disallowing all objectmodifications that cause class predicates to change their truth value is too resthctive. Consider the followingscenario: Let a class Persons have a subclassMyfriends. Certainly, we can not express a sufficientpredicate on persons to decide who are my friends. So, we need to tell the systemexplicitly, by the add operation, whichpersons to put into that subclass. Suppose there is anothersubclass,NewYorkers. Obviously, this subclasscan be definedwith a (necessaryand)sufficientpredicate,namely“defineclassNewYorkers: personlype all Personswhereaddr=’NewYork”.Alternatively, we could defineNewYorkers as a view by the statement“define viewNewYorkers as selectaddr = ‘NewYork’](Persons)”. In any case, we expect from the system to (i) automatically add a Personsmember to NewYorkers, if the ad4rfunction is set to NewYork, and (ii) to remove an object from NewYorkers, if addr is set to someothervalue. The latter is also true if we apply the update to class NewYorkers. On the otherhand, suppose we add somepersonobject p to NewYorkersexplicitly (by using the generic add operator). If the person fails to have a New York address, the update will not succeed, because the necessary class predicate is not fulfilled. In general, due to the dynamicreclassification of objectsbased on class predicates, we need to apply only few restrictions to view updates, since most “exceptions” are detectedduring the evaluation of class predicates. An example for updates that are disallowed is the assignment to derivedfunctions (e.g., in extend-views), the insertion/addition into union views (that could only be allowed if the two base classes have a discriminating predicate,becauseotherwise we can not disambiguate the insertion),or—thesymmetriccase—removals from intersectionviews. Details for eachkind of views and updateoperations are discussed in 8]. We did not mentionjoin views yet. COOL has no join operator. We can express the samesemantics by the extendoperator. Instead of joining two classes, we extend one of them by a new function. The other one may automatically be extended by the inversefunction. The new functionreturns, for eachmember of thatclass, the set of “join partners” from the otherclass 9]. The derivedfunction is definedusing a selectionapplied to the other class,where the predicatedepends on the currentmember of the first class. For example, a view overPersons that shows for eachperson the neighbors, that is, thosepersonsliving at the sameaddress is defined as define viewNeighborPersons as extendeighbors:=selectaddr(n) = addr(p)](n:Persons)](p.Persons). This way of expressingjoins is object-preserving,NeighborPersonscontains base objects,namely all members of Persons. Therefore, we can also update “join views”: we can modify all informationabout the personobjects and theirneighbors, the only restriction is that we disallowsetting the neighborfunction to a new value. We can, however,change its value indirectly by modifyingpersons’addresses. 5 FundamentalProperties The followingproperties of the querylanguage havebeen essential for the view definitioncapability and the view updatesemantics. If some of theseproperties are not met by a language, our solutions will fail, partly or completely. Thus, the results we obtained are not bound to the COOLlanguage, but to theseproperties. Objectpreservation is the centralconcept. It is crucial for a viewdefinitionfacility.Objectpreservingoperator semanticsmeans that the results of queries are existingobjects from the database, in contrast to object-generating (results are newlygeneratedobjects) or tuple-generating(results are data, not objects)semantics. 46 The type/classseparation is a consequence of objectpreservation: if both projections and selections are to preserveobjects, and if compositeselect/projectqueries are permitted, we need this separation in order to connect the view class properly with the base class. The position of query results in the type and class hierarchies have to be less precisewithout this distinction (see 6], where all query results are directsubclasses of “OBJECT”). Furthermore, no operationchanges both, type and extent,except for union and intersection of two classes with differingtypes. So, the separation is a clarification of distinctconcepts. Multipleinstantiation andmultipleclassmembership are otherconsequences of objectpreservation: since we have type-changingoperators(project,extend) all objects in their results“acquired” a new type. If we consider objects in results of queries as beingmembers of the resultclass as well as the inputclass(es), we can treatupdates to queryresults in the same way as updates to storedclasses and the updatespropagateautomatically. Dynamicreclassificationduring updates: Automaticclassificationfunctionality known from AL systems their becomesnecessary when we take into account, that objects can dynamically gain and loose types during it life time and that changes of an existingobject can make it a member of a more specific class (because now the satisfies it’s classpredicate) or a moregeneral one (if the classpredicate of it’s currentclass is violated by update). is Reclassification is the centralconcept in our viewupdatesemantics. Whileclassification(predicatesubsumption) undecidable in general, we try to identifytractablepredicates.Furthermore,reclassification—relative to an original class and a specificupdateoperation—issimpler than classification in general. 6 Related Work Recently, there have been otherproposals for view support in ooDBMSs 1, 5, 101. These are different from our approach in that we use the standard way of definingviews by nothing else than querylanguageexpressions. They other eitherintroducespecialviewdefinitionfeatures thatduplicateparts of the querylanguagecapabilities 1] or use facilities of theirsystems.FUGUE 5] uses type hierarchies for informationhiding: the user can implement a new type for the view that uses some base type(s) and offers only a restrictedfunctionality or extends the functionality. simulateviews. Also, not all instances of the basetype may be exported.POSTGRES 10] uses the rule system to for them. Derivedtables(views) can be defined by rules and otherrules may definespecializedupdatesemantics MarkusTresch. Acknowledgemeni.COOL’s view mechanism was developedtogether with ChristianLaasch and We thank BharatBhargava for criticalcomments on a draft. References 1] S. Abiteboul and A. Bonner.Objects and views.Manuscript,INRIA, Dec. 1990. 2] C. Been. A formalapproach to object-orienteddatabases.Data & KnowledgeEngineering,5:353—382, Oct. 1990. 3] A. Borgida, R. Brachman, D. McGuinness, and L. Resnick.CLASSIC: A structural data model for objects. In Proc.ACM SIGMODConf. n Management of Data,pages58—67,Portland, OR, June 1989. 41 R. J. Brachman and J. G. Schmolze. An overview of the KL-ONEknowledgerepresentationsystem.CognitiveScience, 9:171—216, 1985. 5] S. Heiler and S. Zdonik.Objectviews: Extending the vision. In Proc. IEEEData EngineeringConf., pages 86—93, Los Angeles, Feb. 1990. 6] W. Kim. A model of queries for object-orienteddatabases. In Proc. In!. Conf on Very LargeDatabases,pages423—432, Amsterdam, Aug. 1989. and 7] H.-J. Schek and M. H. Scholl. The two roles of nestedrelations in the DASDBSproject. In S. Abiteboul, P. C. Fischer, H.-J. Schek,editors,NestedRelatioas and ComplexObjects in Databases.LNCS 361, SpringerVerlag,Heidelberg, 1989. 8] M. Scholl, C. Laasch, and M. Tresch.Updatableviews in object-orienteddatabases.TechnicalReport 150, ETH Zurich, Dept. of ComputerScience, Dec. 1990. Submitted for publication. 9] M. Scholl and H.-J. Schek. A relationalobjectmodel. In S. Abiteboul and P. Kanellakis,editors,ICDT ‘90 — Proc. Int’l. Conf on DatabaseTheory,pages89—105, Paris, Dec. 1990. LNCS 470, SpringerVerlag,Heidelberg. 10] M. Stonebraker. A. Jhingran, J. Goh, and S. Potamianos. On rules,procedures,caching and views in databasesystems. In Atlantic H. Garcia-Moliria and H. Jagadish,editors,Proc.ACMSIGMODConf. on Management ofData,pages281—290, City, May 1990. ACM, New York. Data 11] K. Willdnson, P. Lyngbaek, and W. Hasan. The Iris architecture and implementation.IEEETraas. on Knowledge and Engineering,2(l):63—75, Mar. 1990. Special Issue on PrototypeSystems. 47 AlgebraicQueryProcessing in EXTRA/EXCESS Scott L. Vandenberg David I. DeWitt ComputerSciencesDepartment University of Wisconsin-Madison Madison, WI 53706 1. Introduction TheEXTRA/EXCESSDBMSCare8SJconsists of an advanced data model(EXTRA) and a non-procedural querylanguage(EXCESS),each of which is describedbriefly in Section 2. The system is implementedusing the EXODUSextensibledatabasesystemtoolkitCare9OJ.Motivations for EXTRA/EXCESS, as well as detailedcom parisons of it withsimilarsystems,can be found in Care88]. Thegoal ofthispaper is to describe the algebraicfun damentalsunderlying the processing and optimization of EXCESSqueries The relationship of thesefundamentals to otherwork is detailed in Vand9l]. Here we concentrate on describing the algebraicstructures and theiropera tors(Section 3), results on the algebra’sexpressivepower(Section 4), andalgebraicqueryoptimization(Section 5). Section 6 summarizes the currentstatus of this work. Many of these results are covered more completely in Vand9l]. 2. TheEXTRADataModelandEXCESSQueryLanguage Twoconcepts are central to thedesign of EXTRA/EXCESS:extensibilityandsupport for complexstructures withoptionalidentity. In addition, the modelincorporates the basicthemescommon to mostsemanticdatamodels. Extensibility in EXTRA/EXCESS is providedthroughboth an abstractdatatypemechanism,where new types can be written in the E persistentprogramminglanguageCare9O] andthenregisteredwith the system,and throughsup port for user-definedfunctions and proceduresthat are written in the EXCESSquerylanguage to operate on (user- defined)EXTRAtypes. TheEXTRAdatamodelincludessupport for complexstructureswithsharedsubobjects, a novel mix of object- and value-orientedsemantics for data, a multipleinheritancehierarchy for tupletypes,andsup port for persistentstructures of any typedefinable in the EXTRAtypesystem(i.e., a stricttype-instancedichotomy definetypePerson: definetypeStudent: ( ( ssnum: int4, dept refDepartment, name: har], advisor har I birthday: Date ) inheritsPerson ) definetypeDepartment definetypeEmployee: ( ( name: harJ, dept refDepartment, floor int4 salary: int4, ) kids: (Person) ) inheritsPerson createEmployees: (ownrefEmployee) createStudents: (own refStudent) createTopTen: array 1..10] of refEmployee Figure 1: A simpleEXTRAdatabase Thisresearch was partiallysupponed by the DefenseAdvanccdResearchProjectsAgencyunderenntnctN00014-85-K-0788. by an IBM GraduateFellowship. and by a donationfromTexasInsiniments. 48 exists). Figure 1 shows a simpledatabasedefinedusingEXTRA. In EXTRA, the tuple,multiset,,and array con structors for complexobjects arc denoted by parentheses,curlybraces, and squarebrackets,respectively. Object identity is denoted by the ref keyword, and the own keywordindicatesobjectownershipCare88]. In EXTRA, subordinateentities are treated as values (as in nestedrelationalmodelsSche86]), not as objects with theirown separateidentity,unlessprefaced by ref in a typedefinition or an objectcreationstatement. Thedeclaration ref x indicatesthat x is an objectidentifier(OlD). Briefly,Figure 1 defines fourtypes, all cI whichhappen to be topictypes. The StudentandEmployeetypes are subtypes of Person. Thesemantics of thisinheritance are that all attributesandmethods of Person are alsoattri butesandmethods of StudentandEmployee,andthat all StudentsandEmployeesarealsoPersons(substitutability). Anyinheritedmethod can be oveniddenwith a newmethodbody. Figure 1 creates a universitydatabase thatowns threenamed(i.e.,top-level),persistentobjects:Students (a set of Studentobjects),Employees (a set of Employee objects),andTopTen, a fixed-lengtharray ofreferences to Employees. The EXCESSquerylanguageprovidesfacilities for querying and updatingcomplexstructures, and as men tionedabove it can be extendedthrough the use of ADTfunctions andoperators(written in E) andprocedures and functions for manipulatingEXTRAschematypes(written in EXCESS).EXCESSqueriesrange over structures createdusing the createstatementEXCESS is designed to provide a uniformqueryinterface to multisets,arrays, tuples, and singleobjects, all of which can be composed and nestedarbitrarily in EXTRA. The language thus allows for the retrieval,combination,and dismantling of any structuredefinable in EXTRA. Theuser-definedfunc tions(written both in E and in EXCESS) and aggregatefunctions(written in E) are supported in a clean and con sistentway. As an example, the followingqueryfinds the names of the children of all employeeswhowork for a depart ment on the secondfloor,additionalexamplesappear in Sections 3 and 5. range of E is Employees retrieve (C.name) from C in E.kids where E.dept.floor = 2 3. TheEXCESSAlgebra EXCESSqueries are processedalgebraically — the algebraicparadigmhistorically has proveduseful for optimization,models of execution, and theoreticalresults. TheEXCESSalgebraVand9O]providesdirectsupport for many of the advancedconstructs of EXTRA/EXCESS,notablyarrays,multisets,grouping,inheritance,object identity, and orthogonality of typeconstructors. ThealgebraConsists of structures andoperators. A structure is an ordered pair (S, I), where S is a schema and I is an instance.Schemas are digraphswhosenodesrepresenttypecon structors and whoseedgesrepresent a “component-orrelationship. That is, an edgefrom A to B signifiesthat B is a component of A. Each node is labelled with either “set” (short for multiset), “tup” (for tuple types), “arr” (for arrays),“mr (forobjectidentity), or “val” (an atomicvaluewith no associatedstructure).These-correspond to the fourtypeconstructorsplussimplevalues. As in EXTRA,theseconstructorscan be composedarbitrarily — theyare completelyorthogonal. We also associate a uniquetypename witheach node.Components(fields) of tuples are alsonamed. Everyschema has a distinguishedrootnode. “Tup”nodesmayhave any number of components,“val” nodeshave no components, and the othertypeconstructorshaveexactly one component. Cycles in the graphmust contain a node of type “rer. Instances of a schema are elements of the appropriatedomain, and the domainassoci ated with a node of a schemagraph has beendefined(formally; see Vand9lJ) to account for objectidentity and. multipleinheritance. The orthogonalnature of the typeconstructors of EXCESS (and those of the algebra) has been incorporated into the operatordefinitions. Thealgebra is many-sorted, so instead of having all operatorsdefined on “sets of enti ties” (as in mostalgebras), we have(foreach sort”, or typeconstructor) a collection of operators thatapplyonly to structureswhoseoutermosttypeconstructor is thatsort In particular, the algebra is not set-oriented. Foreachcon structor we introduce a collection of primitiveoperators that togetherallow for arbitraryrestructuringsinvolving one or two structures of thatsort. We list the operatorshere, but do not describethem in detail;some of them will be morefullydefined in the nextsection(also see Vand9O]).There are eightprimitiveoperators for multisets (—, ~, x, DE,GRP,SET_COLLAPSE,SET_APPLY,SET);three for tuples(TUP_CAT,TUP EXTRACT,TUP); two for references(DEREF,REF); and nine forarrays(SUBARR,ARR_CAT,ARR_EXTRACT,ARR_COLLAPSE, ARR_DE,ARR_CROSS,ARR_DIFF,ARR_APPLY,ARR). We emphasize thattheseoperators do not depend at all on the schemas of theirinputs’components(except, of course, that both inputs of a binaryoperatormust be of the same type, modutoinheritancerules). For example, the unarymultisetoperators work on any multiset, no matterwhat it contains. Eachoperatoracceptsonlyinputs of the sort with which it is associated, with the excep tions of the SET,TUP,ARR, and REFoperators,whichacceptany structure as inputandplacetheirinputinside the 49 correspondingtypeconstructor(e.g..SETreturns a singletonmultisetcontaining its input). Sincealgebras are functionallanguages, we treatpredicates in a functionalmanner. That is, a predicate is an operation(calledCOMP)thatretun~ its (unmodified)inputexactlywhen thepredicate is satisfied(true). Otherwise COMPreturnsnothing(seeVand9O] for a discussion of nulls in EXTRA/EXCESS).COMP,whoseinputcan be of any type, is the onlyoperatorthathas a predicateparameter.Isolatingpredicateswithin thisoperatorsimplifies the otheroperatordefinitions as well as theirimplementations. We nowpresent a simplequery(seeFigure 2) to illustratethe flavor of thealgebra;morecomplicatedqueries appear in Section 5. The query in Figure 2 returns the name and salary of the 5th element of the TopTenarray (defined in Figure 1). Thisqueryuses the followingalgebraoperators:ARR_EXTRACT,whichreturns a single, specifiedelement of an array(theresult is the elementitself, not an arraycontaining the element);DEREF,which, given an OlD,returns the valuereferred to by the Oil); and it, whichreturns a tuplecontainingonly the specified fields of its input (it operates on a singletopic, not on a set of topics). Clearly, the operatordefinitions are heavilyinfluenced by the structures of EXTRAobjects. The operator definitions are also motivated by the fact that a rich set of primitiveoperatorsenables the derivation of an equally rich set of transformation rules for use in optimization.Furthermore,primitiveoperators are easier to implement than are complexones. It is alsoeasy to definenon-primitiveoperators in terms of the primitives. For example, a relational-likejoin can be defined as follows: reljoin9(A, B) = SET_APPLY~~(SET_APPLY~~T(fi~dIfi~)(A x B)), where 8 is thejoinpredicateand “fieldI” and “fieldT are the names of the twofields of the Cartesianproduct. 4. ExpressivePower of the Algebra The algebra was designed to implement the EXCESSquerylanguage, not to reflect a database-stylecalculus such as the relationalcalculus. Thus the interestingquestion of expressiveequivalence for this algebra is not whether it can express the queries of some formalcalculus but whether it can expressexactly the queries of EXCESS. This is one motivation for not forcing the algebra to be set-oriented.Naturally, it is crucial that any EXCESSquery be expressible in thealgebra. Theotherdirection of theeqwpollence is interesting in that it restricts the optimizationalternatives to the smallest set possiblegiven thepower of EXCESS and the structure of thealgebra and its rules. It alsoensuresthatintermediatesteps in the optimizationprocess are alwayscorrectrepresentations of EXCESSqueries and thatany expressivenessresultsregarding the algebraalsoapply to EXCESS. We onlysketch the proofhere;moredetailsareavailable in Wand9lI and in a forthcomingthesis. Theorem: TheEXCESSquerylanguageandalgebra are equipollent. Sketch of Proof: Reduction ofEXCESS to algebra: The proof thatEXCESS is reducible to the algebra is essen tially an algorithm thattranslates any EXCESSquery to an algebraicquerytree.Theproof is an inductiveproofthat follows the structure of the algorithm (the induction is on the number of certainEXCESSconstructsappearing in a query).Reduction of algebra to EXCESS: The otherdirection of the proof is a case-basedinductiveproof. The induction is on the number of operators in an algebraicexpression. An expression in the algebraconsists of one or morenamed,top-leveldatabaseobjects and 0 or moreoperators. 0 A few generalremarksabout the algebra’spower are in order. First, it is capable of simulatingmost of the algebrasmentioned in the literature as long as thesealgebras do notcontain the powersetoperator. We conjecture that ouralgebra is incapable of expressing the powerset, but we have notproved this yet. Such a resultwould pro vide an importantupperbound on the algebra’sexpressiveness and computationalcomplexity. This is because the powersetoperator,whichreturns the set of all subsets of its input set, is inherentlyexponential in nature and (in retrieveTopTen5].name, TopTen(5].salary) ( ( itnamesalary ( Figure 2: A SimpleQuery 50 manyalgebras) it allows for the formulation of leastfixpointqueriesEGyss88].Second, it has beenobserved that the addition of the powersetoperator to somealgebras has the sameeffect as addingwhile-loopswitharbitraiycon ditionsGyssS8]. Such loops are fundamentallydifferent from the style of loop provided by the SET_APPLY operator. The latterstyle of ioopexecutes a statement on eachelement of a (multi)set in turn. Theformerkind of loopexecutes a statementmanytimes, but is notrestricted to operating on successiveelements of a set. Finally, the EXCESS algebracontainssomeconstructs that are second-order in nature. Since the semantics of the algebra are definedoperationally(rather than proof-theoretically, as in manycalculi), it is not clear that the drawbacks of second-orderlogics(i.e. incompleteness)havecorrespondingdrawbacks in an algebraicsetting. 5. AlgebraicQueryOptimization in EXCESS EXTRA/EXCESSqueries are optimized by a rule-basedoptimizerwhichusesalgebraictransformationrules to rearrange a query Vand9l,Grae8l]. It determines the cost of each rearrangementusing cost functions and statistics and chooses the cheapestone for execution. Thissectiondescribes a few of the new transformationrules thatcan be used to optimizeEXCESSqueriesand illustratesthem via an example. Thealgebra is capable of simu latingnearly all of the transfonnationsfound in the literature. The examplepresents an EXCESSquery over the database of Figure 1 and a series of algebraicrepresentations of thatquery. None of thesequerytrees is necessarily intended to be the final or optimalplan for the query. Each one represents an alternativeexecutionstrategy to be examined by the optimizer. In the example we takesomelibertieswith the details of the algebra in order to clarify the presentation, but we losenone of the essence of the queries. We also use a graphicalnotation to represent the queries — data flowsupward in thesegraphs,following the arrows. A complete list of new transfonnationswould containseveraldozenrules,each of which can be provedsoundusing the operatordefinitions.Morerules can be found in Vand9ll. Theexamplequeryretrieves,withoutduplicates, the names of all advisors of Students,grouped by their stu dents’departments. It demonstrates the use of bothobject-basedaccesses (use of the Studenideptreferencefield) and value-basedaccesses (therelational-likejoin). TheEXCESSquery is: range of S is Students, E is Employees retrieveunique (S.dept.name, E.name) by S.dept where S.advisor = E.name Figure 3 is oneway to execute the query — it is similar to whatwould be produced as an initialquery tree by the EXCESSparser and translator. In the queryplans shown we make use of the followingalgebraoperators: SET_APPLY,whichapplies an algebraicexpression to all of the occurrences in a multiset DE, whicheliminates duplicatesfrom a multiset GRP,whichgroups the occurrences in a multiset intoequivalenceclassesbased on the result of an algebraicexpressionapplied to those occurrences; it, which is similar to relationalprojection but operates on a singletuple1 and “reljoin”,which is essentially a relationaljoin. “Reljoin” is not a primitive in the algebra, but is one style ofjoin we havedefinedusing the primitives; see Section 3. Subscripts to an operatorindi cate parameters to that operator, not its input(s). The plan in Figure 3 joins the two sets using “reljoin”, then groups the result(producing a multiset of multisets),performs the finalprojection, and eliminatesduplicates. The final projectionactuallyincludes an object-basedaccess(using the algebra’sDEREFoperator to get to a Student’s Departmenttuple), but we haveomitted this for brevity. Note that to process setsnestedwithinsets, the parameter to SET_APPLY can itselfcontain a SET_APPLY, as in Figure 3. Figure 4 shows the application of a rule pushing DE beforeGRP: SET_APPLYDE(GRPE(A)) = GRPE(DE(A)) This is especiallyadvantageouswhen the duplicationfactor is large, as it is likely to be here. We simultaneously take advantage of the ability to move it ahead of GRP if the it produces the attributesused by GRP. In Figure 5 we optimize the queryfurther by pushing the DE and it past the ‘reljoin”node,making use of this rule(amongothers): DE (A x B) = DE (A) x DE (B) Thisresults in DE operating on S and on I El occurrencesrather than on IS I * I E I occurrences. The DE and it have beenseparated intotwonodes in Figure 5 to clarify the presentation. ‘Thenusedhere is easilydefined in terms of the threeprimitivewpIeoperatorslistedearlier. 51 GR~ SET APPLY GRP — DR (SET~APPLY,~>(INPUT)) ~4CP1 reijoin I I GRP DE (SET APPLY ) - .dcpt DE DE reijoin reljoin advisor=namc advuog~name SET APPLY SET APPLY — S E S E S E Figure 3: InitialQuery Figure 4: 1stTransformation Figure 5: 2ndTransformation The algebra also provides for compile-timeoptimization of overriddenmethods. This particulartechnique, described in Vand9lj, can be used to avoidrun-timetypechecking in somequezie& 6. Conclusions,Status,and FutureWork The algebraicparadigm for queryprocessing, as shownhere, can be used to successfullymodel,implement, and optimizemanyaspects of advanced data models. Morecompleteresults may be found in Vand9O,Vand9l]. As mentioned in Section 4, the algebra can simulatemostotherdatabasealgebrasfound in the literature, as long as these do not includerecursivecapabilities. Any operator of such an algebra can be simulatedusing an EXCESS algebraexpression, and this is true for bothobject- and value-basedalgebras, due to the orthogonalintroduction of objectidentity into the EXCESSalgebra. Thisimplies that the optimizationsused in EXCESS can also be applied to theseotheralgebras and thatsomesystemswithoutalgebrascanbenefitfromusing the EXCESSalgebra. Much of the system is now operational,including the parser,many of the algebraicoperators, the runtime queryexecutionsystem, the DMLsupport, and supportcode for the EXODUSoptimizergenerator,which is being used to build the optimizer. Many of the algebraic rules are present in the currentgeneratedoptimizer. Some queries have beenexecuted at low levels of the system, and the full system is expected to beginrunningshortly. Interesting areas requiring futureresearchincludenormal forms for complexobjects,alternativeapproaches to incompleteinformation in a complexobjectdatabase, and the development of moresophisticatedstatistics for use by the optimizer. REFERENCES Care88J M. Carey, D. DeWiu, and S. Vandenberg, “A Data Model and QueryLanguage for EXODUS”,ACM SIGMODS8ConferenceProceedings,Chicago, IL, June1988. Care9O] M. Carey et al., “The EXODUSExtensibleDBMSProject An Overview,” in Readings in Object- OrientedDatabaseSystems, ed. S. Zdonikand D. Maier,MorganKaufmann,PaloAlto,CA, 1989. Grae8l] G. Graefe and D. DeWitt,“TheEXODUSOptimizerGenerator,”ACMSJGMOD87ConferenceProceed ings,SanFrancisco,CA,May1987. Gyss88] M. Gyssens and D. VanGucht,“ThePowersetAlgebra as a Result of AddingProgrammingConstructs to the NestedRelationalAlgebra,”Proc. SIGMODCoaf.,Chicago,Illinois,June1988. Sche8ó] H. Schek and M. Scholl,“TheRelationalModelwithRelation-ValuedAttributes,”Info.Sys. 11(2),1986. Vand9O] S. Vandenberg and D. DeWitt, “An Algebra for ComplexObjects with Arrays and Identity”,Univ. of Wisconsin-MadisonComputerSciencesTechnicalReport#918,March1990. Vand9l] S. Vandenberg and D. DeWitt,“AlgebraicSupport for ComplexObjectswithArrays,Identity, and Inher itance”,ACMSIGMOD9JConferenceProceedings,Denver,CO.May 1991. 52 ENCORE: An Object-OrientedApproach to DatabaseModelling and Querying Stanley B. Zdonik and Gail Mitche11~ Department of ComputerScience BrownUniversity Providence, R.I. 02912 sbz,gms©cs.brown.edu 1 Introduction The ENCORE’ 7] object-orienteddatabasesystem has been used at BrownUniversity for a number of It years as a vehicle for experimentation in many aspects of next-generationdatabasetechnology. was designed as a medium for combiningdatabase and programminglanguagetechnology. It was also designed as an extensibledatabase in which the basic extensionmechanism is the abstract data type. As a result, extensions are programmed in a way that conforms to good softwareengineeringpractice. The ENCORE DDL is, as in most conventionaldatabasesystems, a means for describing data that will be kept in a persistent,shareable store. It can be thought of as a type system. The DML is defined by the ability to invokemethods of abstract types on objects. Thus,ENCORE is a means for creating and manipulatingpersistentinstances of abstracttypes. A collection of ENCORE type definitions is analogous to a databaseschema. The ENCORE type system is a language-independent data model. The implementation of any given typecan, in theory, be provided in any programminglanguage. In fact, it is our intention to allow a type T1 to be implemented in programminglanguage P, and a type T2 to be implemented in programminglanguage P2. Instances of T, and T2 can be freely mixed in a given ENCOREdatabase. This is possiblebecause the only things that are passedbetweenmethods are atomicvalues and systemdefinedobject identifiers (oi4’s)which serve as handles for ENCOREobjects. If a methodreceives an oid for an object, the only thing that it can do to it is invoke a legal method for objects of that type. For atomictypes, we provide translationfunctionsthat convertbetween two differentrepresentations (say, a C integer and a LISPinteger representation). This does not add muchprogrammingoverheadbecause there are only a smallnumber of atomictypes. We also disallow the transmission of object representationsoutside of ENCORE since any safetycriteria(e.g.,constraints or type checking) that are definedwithinENCOREmay not be consistently enforced on datawhile it is outside of the system. Thisapproachretains the impedancemismatch of conventionaldatabases, but it easilyaccommodates the implementation of types by multiplelanguages.ENCOREprovides one type system,whileeach method implementationlanguageprovidesanother.Unlikemostcurrentobject-orienteddatabasesystems,ENCORE is not a completedatabaseprogramminglanguage. Notice,however, that it would be possible to wrap a programminglanguagearound the ENCOREtypesystem(something we are planning to do). Theimpedance mismatchproblemwoulddisappear for typeswhosemethods are implemented in this language. 2 The ENCOREDataModel is ENCORE is based strongly on abstract data types 4]. All types are defined by their interfacewhich specified in terms of a set of methodsignatures. A signature for method M is a name plus an ordered list ONR tSupport for this research was provided by IBM undercontract No. 559716, by DEC underaward No. DEC686, by undercontractN0014-88-K-0406, by ONR and DARPAundercontractN00014-83-K-0146 and ARPA Order No. 4786, by AppleComputer,Inc., and by TexasInstnnnents. ‘Manyyears ago ENCOREstood for Extensibleand NaturalCommonObjectREsource.Thesedays it stands for itself. 53 of types that correspond to the legaltypes for the arguments of M. Objects can be related to each other by means of these methods. The ENCORE type system has been designed to allow for static type checking. Typeequivalence is determined by nameequivalence. ENCOREdefines a set of atomictypes,Integer,Real,Bool, and String.Thesetypesdefine the only values in the system. A value is somethingwhich is guaranteed to be immutable.Unlikeotherobject-oriented databasesystems (e.g. 23]),ENCORE does not allow users to define new valuetypes. All user-defined typesdescribeobjects. A user-definedabstract type is a tuple (S,I) in which S is a specification and I is an implementation. The specification S is a pair (N,M) in which N is a name (i.e., a string) and M is a set of methodsignatures. P is set The implementation I of an abstract type is a pair (R,P) in which R is a representation type, and a of programs that implement the methods in M in terms of the representation type R. The type R can be Users any type including an atomictype, an instance of a parameterized type, or any otherabstract type. of an abstract type are forbidden fromknowing the implementation I. A parameterized type is a mechanism for specifying a family of relatedtypeswith one textualdefinition. do static The parameters for a parameterized type mayincludeothertypes. In order to retain our ability to typechecking, we restrict the parameters to be expressionswhich are staticallytyped. A parameterizedtype is like a metatype in that it is a generator for other types. An instance of a parameterized type is a type. For example,etInteger] is an instance of etT:Type~. ENCOREdefines and These twoveryimportantparameterizedtypes,etT] upleai:Ti, .. . ,a,~:T,,]. results. two types play a crucial role in the queryfacility,where they are used to construct types for query When the parameterized type etT] is given a value such as Integer for the parameter T, it generates instances a new type etInteger]. The name of this type is SetInteger]”. The type etInteger] has that are sets whosemembers are constrained to be integers. There can be multipleinstances of a type Set containingexactly the samemembers. A parameterized type P defines a set of methods, each of which can be parameterized by the type parameter(s) of P. For example, the etT] type defines an operation with a parameterizedsignature is also. Insert(S:etT],x: T). WhenetT] is supplied with a value for parameter T, the Insertoperation parameterized with the samevalue; i.e. type etInteger] has methodInsert(S:etInteger],x:Integer). The methodsdefined by a parameterized type do not apply to instances of that type. Instead, when a of the parameterizedtype is given a parameter, the newlygenerated type N is givenparameterizedversions methods,whichnowapply to the instances of N. For example,Insertdoes not apply to the typeetInteger] but applies to instances of that type. The basic type constructor in ENCORE is the abstract data type, in that it takes a type for its also representation(concretetype) and generates a new type as the abstract type. The parameterizedtypes provide a morestandard type constructionmechanism. ENCOREabstract data types are related to each other throughsubtyping. A type may have many instances subtypes andmanysupertypes.Subtypingrequiresthatinstances of a subtype can be substituted as of any of its supertypes(substitutability). The subtypingmechanism is designed to supportstrongstatic typingwhen the ENCORE type system is embedded in a compiledprogramminglanguage. well The collection of all currentinstances of an ENCORE type is the extent of the type. Extents as as arbitrary sets of instances can be maintained by ENCORE. Sets can be explicitlycreated or defined by a predicateoversomeexistingset. Forexample, if set Cars hastype SetCarl, we can define a predicate-defined subsetBlueCars as all members of Cars with a value of “blue” for their colorproperty. A predicate-defined subset has the sametype as its superset (i.e. BlueCars has type etCarl). We call a predicate-defined set, a class. Classes give us the ability to separateconstrained sets, requiringrun-timemembershiptests, from the type system that is reserved for compile-timechecking. It is important to note that while a subtype relationshipbetween two types induces a subsetrelationshipbetween their extents, a subsetrelationship between two classes does not necessarilyimply a subtyperelationship. A classdefinition can be defined to eitherconstrain its membership or provide a view of its parentclass. T to If a class C defined by predicate P is defined as a constrained-class, then any attempt by a transaction defined change the state of c, an element of C, such that P( c) is false will cause T to abort. A class C by that predicate P mayalso be defined to be a view. If the state of someobject c in class C changes such c no other longerobeyspredicate P, c is automaticallyremovedfrom the class. Object c may now satisfysome predicate P’ that defines class C’, in which case it is automaticallyinserted into C’. An instance z of a type T has a uniqueidentity that is independent of the state of z. Although an of the identifier object’sidentity may be implemented by a systemsuppliedobjectidentifier, the existence 54 is transparent to the languageinterface.Logically, the languagealways sees an object, and mustaccess that objectthrough the interfacedefined for its type. Objectidentityallows the implementation of references betweenobjects. When an object z refers to an object y by means of a method M (i.e., M(x)=y),applying M to z producesobject y (and does not give access to an identifier for y). Propeflies in ENCOREreflect the abstractstate of an object. The notion of property is modelled by one which or more of the methodsdefined on a type. A propertyvalue is accessed by a specialobservermethod called is required to have no side-effects on the observablestate of the object. Thismethod for property P is GetY. The GeLPmethod can return the value of a stored field or it may perform a moresophisticated computationbased on the storedrepresentation of the object. A property P may also supportanother functioncalledSet_P that allows the value of P to be changed. ENCORE, like manyobject-orientedprogramminglanguages 1], treats many parts of the language itself as objects. Thisincludestypes,methods, and properties. In particular, the treatment of properties as objectscomplicates the discussion in the previousparagraph. Thisreflectivecapability is useful to allow the databasesystem to manage its own metadata. We will not discuss this capability any further here. 3 Querying in ENCORE that The ENCOREQueryAlgebra(EQUAL) is a collection of operators,defined for parameterizedtype Set, about the can be used to constructqueriesoversets of ENCOREobjects. A query is a request for information state of the database, thus our queryoperatorsprovide an environment for gathering and organizingobjects data (and sometimesvalues, such as integers) in an ENCOREdatabase. The operatorssupportabstract types and encapsulation by accessingobjects only through the methodsdefined for their type, in particular the Get methods for properties. All queries are stronglytyped, and can be staticallytype-checked. The result of a query is a new databaseobject. The creation of new objects leads to two questions: What is the type of the object? and What is its identity? Our requirement for statictype-checkingmeans that we cannotbuild new abstractdatatypes. As a result, we define the type of any object built by a query In to be etT],where type T is either an existingdatabase type or a parameterized Set or Tupletype. this way EQUALcombinescomplexobjects with abstract data types. The queryoperators build new set and tupleobjects,intermixed in any order,above the abstracttypes. Unlikesomecomplexobjectmodels, EQUALtreats sets and tuples as objects. Eachobjectbuilt by a query is a newobjectwith a uniqueidentity. This means that we can buildalternativepaths to the same object, and also that we mightbuild objects that are considered to be duplicates. Our algebradoes not build,however,recursiveobjects. notion of The support for objectidentityimplies that we also need to support more than one object be identical to equality. Two objects are identicalwhen they are the sameobject (i.e. an object can only traversal of itself). We define a family of equalityoperations we call i-equalitywhere i specifies the level, in a objectstructures, at which two objects refer to identicalobjects. We discusstheseequalities in moredetail, and also discusssomeimplications of support for objectidentity on queryoptimization, in 5]. As statedabove, the EQUALnotion of a query is as an expression that, when evaluated,produces a new object. This is consistent with manyprogramminglanguagemodels that, for example, build a new returned arrayobjectevery time a new declaration is encountered.Programs are free to mutate the object the blue by a query at any time. Thus, we see that queryresults are not views. If we select, with a query, cars from a set of cars, nothingprevents us fromlaterplacing a yellow car into this set. Thisquerylanguage characteristicimpliesthat queries can be used as another kind of objectcreationmechanism in application programming. well EQUALincludesoperations that are the analogs of relationalalgebraicoperations as as operations to manipulate the logicalstructure of ENCOREobjects. The Select,Project and Ojoin(object join) op erations are similar to their relationalcounterparts in meaning, but generalize the relationaloperations by S Set and applyingfunctions (i.e. propertymethods or queryoperations) to the databaseobjects. For a and p a predicate, we defineSelect(S, p) = {s I (s in 5) A p(s)}. For S a Set, A~ a string, .f~ a function, : : = : : s in Project(S, (A1 Ii), ..., (A~ f,~)]) A1 li(s), ..., A,~ f~(s)] S}. As an example, the query Project(People, Ap (P : p), (Toys : Select(p.Cars, Ac c.cost > p.salary)]) For builds a set of tuples each of whichcontains a Personobject (P) and a etVehicle]object(Toys).2 whose each p in the People set, a tuple is created with a P attributewhose value is p and a Toysattribute that returns an of 2We assume here that People has type etPerson] and that type Person has a Carsproperty object the of typeetVebicle]. The Ap is simply a way to generate a boundvariablethat will range over meiTlbers People. 55 value is built by applying the GeLCarsmethod to object p. Note that in this example, the Projectoperation is similar to a relationalOuter-join; each result tuple contains a Personobject and may have an empty Toysattribute. The application of a property to an object p (i.e. the application of a GeLpropertymethod) is a nav from to igation p the objectrepresenting the value of the property. A navigation can be a singleproperty retrieval, or a string of retrievals (e.g. p.mother.mother.cars to find one’sgrandmother’scars). Suchnaviga tion follows pre-definedrelationshipsbetweenobjects. We also provide an Ojoinoperation to explicitlyjoin two of sets objectsthat are not necessarilyrelatednavigationally. For sets of tupleobjects, Ojoin is analogous to relational a Theta-join.When a etT] is involved in an Ojoin (for T someabstract,non-tupletype), it is treated as set of a single-attributetuplesetupleA:T]J. In otherwords, we defineOjoin(S, R, A, B, p) = B A : s, : r] s in S A r in R A p(s, r)} for S and R sets of objects of abstracttypes, A and B strings, and p a predicate. For example, an Ojoin of the set People with itself can be used to find pairs of people who are co-owners of a vehicle(Ojoin(People,People,“Owner”,“CoOwner”,Api,p2 p1.Cars fl p2.Cars) results in a set whosemembers have type upleOwner:Person,CoOwner:Person]). Our definition of Ojoinretains the associativity of the relationaljoin,whilestillrespecting the encapsulation of objectshaving abstracttypes. Other operationsthatretrieveinformationare Image,Union,IntersectionandDifference. Image is like a LISP it mapcar; allows the application of a function(whichagainmay be a property or an EQUALmethod) to each in object a set, collecting the results in a set object. We defineIrnage(S, 1) = {f(s) s in S} where S is a set and f is any functionthat can be applied to members of S. The Union,Intersectionand Difference operations are like the relationaloperations, but also account for subtyping. An operation that combines a with etT] a etQJresults in etR]where R is the closestcommonsupertype of T and Q. The equality test that naturallyoccurs in the definition of Union,Intersectionand Difference can potentiallyadd an extra level of complexity. If we assume that we always use the identicaloperation, then our definitions are the in same as mostothermodels. But we couldallowequality to be any of the othervarieties of equality. This induces a family of Union,Intersection and Differenceoperations, one for each equalityoperator. EQUAL also includesoperations that manipulate the structure and identity of objects. The Nest, UnNestand Flattenoperationswork onlywith the structure of objects.DupEliminate and Coalescemanip ulateidentities. DupEliminate is necessarybecause we oftenbuild new tupleobjects that maycontain the sameattributevalues. The Coalesceoperator is useful when we build new objects in a subquery. If two queries are executed, the results will be two distinctobjects even though those objects may represent the samevalues. For example,suppose in the Projectquerymatchingpeople and their toys that two people are of co-owners the same two (expensive) cars. The query will build a new set object for each person, both sets containing the same two cars. A Coalesceoperationcould be used to ensure that bothToysattributes referenceexactly the same set of cars. Accessing and creatingcomplexstructuresleads to the regular use of nestedqueryexpressions. In such expressions,queryvariables are not always used locally and can appear in nestedscopes. For example, in the querymatchingpeople and their Toys, the variable p, representing a Personobject, is nested in the of the predicate nestedSelectoperation. The algebraalsoallows us to buildflatterqueryexpressions(using, for the example, Ojoinoperator). The differenttypes of expressions give us differentopportunities for query optimization, so it is important that we be able to translatebetweenthem. Such transformations,however, are often context-sensitive since they involvearbitrarilynestedscoping of queryvariables. As a result, the optimization of such expressions may be very difficult. EQUALgeneralizesrelationaloperations by giving us the ability to access and produceencapsulated, logicallycomplexobjects. The algebradiffers from most other proposedalgebras for object-oriented sys in tems its treatment of abstract datatypes,encapsulatedobjects, and objectidentity. For moredetailed informationabout the algebra see 6]. 4 ResearchDirections the basic Although ENCOREdatabasesystem has been implemented, we are still extending it in a number of fundamentalways. Theseextensions are still underdevelopment at the time of this writing. The optimization of queries is of majorimportance in a databasesystem and we have found that an object-orienteddatabaserequires newoptimizationstrategies to supportfeaturessuch as abstractdatatypes, methods, and objectidentity. We are exploring a variety of strategies for queryoptimization to meet the 56 requirementsimposed by our modeland operators. Forexample, we are looking at strategies for transforming nestedqueries (such as the queryaboutpeople and their toys in the previoussection) and strategies that consider the effects of methodcost on querytransformation.Existingoptimizershave a fixed set of strategies for controlling the optimizationprocess. We have found that object-orienteddatabasesystemsgenerate a need for manydifferentoptimizationstrategies. To manage this need, we are designing a new architecture for a queryoptimizer that can incorporatemanydifferentstrategies for optimization and can be extended with new strategies. Thisarchitecture,althoughmotivated by the object-orientedmodel,represents a novel approach to the optimizationprocess for any databasemodel. The ENCOREmodel, like manytype systems,supportsconstraints in a limited way by means of static type-checking and constrainedcollections. Thesefacilities do not provide the kind of globalconstraints that one would like to express in a database. Globalconstraints span multipletypes. For example, the classic constraint, No Employee can make more than his/hermanager,involves the types Employee,Manager, and Department. The Department type is involvedindirectly since an employee e’s manager can only be discovered by navigating from e to e’s department d, and from d to d’s manager. We are looking at techniques for takingconstraints, such as the one expressed above, and decomposing them into a set of conjuncts such that each conjunctinvolves a single type T and together the conjuncts are equivalent to the originalconstraint. In this way, the conjuncts can only be violated by invoking an method of T on one of its instances. Thisapproachlimits the amount of checking that is required on databaseupdate. Viewdefinition is an area in whichmostobject-orienteddatabasesystemssuffer. We havebeenstudying the requirements for a view definitionfacility that could be added to the ENCOREmodel. Our current approachallows a view to be defined over a database,called the base, by means of a combination of data abstraction and queries 2]. The queryreturns a set of objectsfrom the base that mustconform to the type of the representation of an abstract type that is available in the view. In otl~er words, the queryprovides the representation for the view type and the dataabstractionallows the viewdefiner to layerarbitrary new interfaces over this representation. We are currentlylooking at efficientways to implement this idea. An ENCOREprototype has been implemented on Sun 4 and SparcStationplatformsrunningSunOS 4.1.1. It makes use of the ObServerobjectstoragesystem, also developed at Brown. References 1] Adele Goldberg and David Robson. Smalltalk-80: The Language and its Implementation. Addison- Wesley, 1983. 2] SandraHeiler and StanleyZdonik. Object Views: Extending the Vision. In Proceedings of the 6th InternationalConference on DataEngineering,pages86—93, 1990. 3] ParisKanellakis,ChristopheLécluse, and PhilippeRichard.Introduction to the DataModel. In F. Ban cilhon, C. Delobel, and P. Kanellakis,editors,Building an ObjectOrientedDatabaseSystem: The Story of 02. MorganKaufmann, San Mateo, CA, 1991. 4] BarbaraLiskov et al. AbstractionMechanisms in CLU. Communications of the ACM,20(8):564—576, August 1977. 5] Gail M. Shaw and Stanley B. Zdonik. Object-OrientedQueries: Equivalence and Optimization. In Proceedings of the First InternationalConference on Deductive and Object-OrientedDatabases, pages 264—278,December 1989. 6] Gail M. Shaw and Stanley B. Zdonik. A QueryAlgebra for Object-OrientedDatabases. In Proceedings version of the 6th InternationalConference on DataEngineering,pages154—162.IEEE, 1990. An early of this paperappears as BrownUniversity tech reportCS-89-19. 7] Stanley B. Zdonik and PeterWegner.Language and Methodology for Object-OrientedDatabaseEnvi ronments. In Proceedings of the HawaiiInternationalConference on SystemSciences,January 1986. 57 QueryOptimization in Revelation, an Overview* ScottDaniels,’GoetzGraefe,2ThomasKeller,’ DavidMaier,’ Dun Schmidt,’ and BennetVance’ Introduction The Revelationproject is an experiment in query optimization in object-orienteddatabasesGraefe88]. Our is to goal expandqueryoptimization and processingtechnology to address and exploit new modeling and queryextensions. Sinceencapsulation (an importantfeature in object-orientedsystems)worksagainst queryoptimization, we provide a systemcomponent that may cross the encapsulationboundary and reveal implementationdata. Our projectdraws its namefromthat component, the Revealer. The singlefeature early users of next-generationdatabaseprototypes and products value most is type to add extensibility—theability theirown application-specificdatatypes to the DBMS,givingmorenatural blocks for It also building modeling. provideslogical data independence,allowing data reorganization or reimplementation of behavior while providing a constantinterface to applications. Further,user-defined datatypes are well suited to re-usability,combiningdatastructure and operations in logicalunits. Somecommercial productsalreadysupportsome user extension of systemtypes, but we believeusers want more potent type extensibility, as suggested in “The Object-OrientedDatabaseManifesto”Atkinson9Oj. User-defined should be types first-class,immediate, and abstract.Instances of first-classtypes can appear whereverinstances of system-suppliedtypes can. Immediatetypedefinition is available as readily as schema modification and does not requirerebuilding the DBMS. This implies that typesshould be defined in the DataDefinition and ManipulationLanguages,rather than the implementationlanguage of the DBMS. An abstract type can hide its implementation;dataand function can be encapsulatedfromclients of the type. It is desirable (andpossiblyvital to queryoptimization)that thefunctionsassociatedwith a type be understood by the databasesystem, and not be simplyblack-boxroutinesinvoked at appropriatemoments. We have accordinglyconcentratedRevelation’sefforts on handlingmodelingfeatures that support user- defineddata types,retaining as muchset-processingtechnologyfromrelationaldatabases as we can. Features that provide thissupportincludeencapsulation,complexstate,objectidentity,polymorphism,ordereddata structures(such as vectors,matrices, and grids), and specification and implementationhierarchies. ModelingFeatures and TheirImpact on QueryOptimization Imagine a database for scenedescription, as might be used for renderingimages or motionplanning. One in this type database is Polygon, a basic buildingblock for scenes. The behavior of a polygonincludes returning an ordered list of its vertices,computing its intersection with a given line or plane, and moving its vertices. It has subtypeColoredpolywhich has its own subtype,PatternedPoly. Encapsulationallowsmultipleimplementations of a type to co-exist in the database.Considervarious pos sibleimplementations of Polygon—anexplicit list of Pointvalues, a list of references to Pointobjects, or a reference to anotherPolygon and a transformation(such as scaling or rotation) to apply to all its Points. One can imagineusing severalimplementationssimultaneously (for differentPolygons)within the same database.Encapsulation says the particularchoice can be hidden from clients of the type, because each supports the sameoperations. It also givescontrol over certaininvariantsduringupdate. If a Polygon is represented as a list of pointsthatapplications can modifydirectly, it is difficult to enforceinvariantssuch as coplanarity and convexity. If the updateoperations for a Polygon are encapsulated with its representation, then invariants can be checkedthere,rather than in the applicationcode. Current queryoptimization as sumes that a completedescription of the query is available, in terms of structuraloperators.Encapsulation, with its separation of behaviorfromstructure,impliesthat the structuralcomponentmay not be discernible duringqueryoptimization. It also causesproblemswithdefining and maintainingindices, as well as making * This research was supported in part by NationalScienceFoundationgrantsIRI-89-20642 andIRI-89-12618. 1 ComputerSciences and Engineering,OregonGraduateInstitute, 19600 SW Von Neumann Dr., Beaverton, OR 97006-1999 (daniels,tkeller,maier,schmidt,bennet)©cse.ogi.edu 2 Department of ComputerScience,University of Colorado,Boulder, CO 80309-0430 - graefe©cs.colorado.edu 58 it difficult for the optimizer to get the “big picture;”—withencapsulation, a singlemessageexpression may hide an arbitraryamount of data manipulation. With just a smallexpression to optimize, the range of transformations to apply is limited. Yet anotherproblemwithencapsulationcomeswithmultipleimplemen tations of a type. Current set processingdepends a great deal on homogeneity of structure, for example, in allocatingtemporaryspace for records in intermediateresults, or in computingoffsets for recordfields. ComplexSlatemeans a rich set of structuringmechanisms is available for specifying the representation of and that these a type, constructors can be freely composed. Thus, the representation of a Polygon in one implementationmight be (offset: (X, Y, Z: Integer),vertices: list of CX, Y, Z: Inte ger)). The list verticescaptures the points that define the shape and the triple offsetpositions the polygon in 3-space. Note the nesting of the tuple constructor inside the list constructor inside the tuple constructor.However, only a small part of that state may be needed for a particularquery. Reading the entire state of an object(especially if “entire”includesreferencedobjects) can fill memory with irrelevant information.Readingpieces of an object only as demanded for computation may not be efficient,either. ObjectIdentityallowssharedreferences to subcomponents of an objectirrespective of theirvalues. We might want to have an implementation of Polygonthat uses list of Point as a representation,wherePoints are objects. Two polygons can sharepoints in their representations, in order, say, to keep a edge in common while updates are made to underlyingpoints. The problems this causes for queryoptimizationresemble those of complexstate;straightforwardimplementationsquicklydegenerate into pointerchasing on disk. Hierarchiesexploitsimilaritiesamongclasses of entities, for type specification or implementation. A spec ification exampleassumesColoredPoly (a subtype of Polygon)responds to a color message, as does PatternedPoly (a subtype of ColoredPoly and thereforePolygon). If a Polygonresponds to a message - asking for its surfacearea, then ColoredPoly and PatternedPolymust alsorespond to that message. Thus, a heterogeneous set of Polygon,ColoredPoly, and PatternedPoly can be uniformlyqueried to selectthose largerthan a certainarea,since that is behaviorcommon to all threetypes. Similarly, a set of ColoredPoly and PatternedPolycould be uniformlyqueried to select red ones, though a simplePolygoncould not be included in such a set and maintaincorrecttyping. Typehierarchiesallowheterogeneouscollections of ob jects to be queried on their commonprotocol. Thismeans the languagebears a polymorphicinterpretation that reduces the efficiency of set processing. Thispolymorphism(much like encapsulation)causesproblems in defining and maintainingauxiliaryaccessstructures. Many of the new datamodelsprovidemoregeneralpersistentnamespacesthan conventionaldatamodels. These namespacesresemble those of programminglanguages, with variablesdeclared of arbitrary types, and arbitrarynumbers of variables of a giventype. Moreover, the variables can havetheirvaluesreassigned. Contrast this situationwiththat in relationaldatabases,where the persistentvariablesmayonly be relations (as opposed to tuples or scalars). One majorproblem for optimization is where to attachstatistics that an optimizerwould use in cost estimation. In a relationalsystem, for example,relationnames are statically bound to relationinstances, and there is no distinctionbetweenassociatingstatistics with a relation or its name. With a set-valuedvariablethat can be reassignedduring a transaction, it seems thatstatisticsshould be associatedwith set instances.However, it is the variablenamethat is availableduringqueryoptimization. In examiningorderedstructures, we see the “iterationidioms”supported by operators in recordprocessing systems (such as select and join) are not expressive for commonmanipulations on scientific data types. Biochernists are interested in correlatingpatterns of aminoacidswithstructuralfeatures.Supporting such patternsearchingefficiently at the physicallevelmeansscanning the underlying list structure with a window of elements.Typicalphysicalscans in relationalimplementations are built for record-at-a-timeaccess. The RevelationApproach In the Revelationproject we are looking at approaches to deal with each of the problemsabove. For encapsulation, we introduce a Revealer, a trustedsystemcomponent that is allowed to breakencap sulation in order to expandmessages into moredetailedexpressions. It provides the Optimizer with more transformationchoices and thus a largerscope for planning the query. To dealwithhierarchies and polymor “coincidences”— phism we employ two approaches. Oneapproachlooksacrossmultipleimplementations for commonalities of definition. The other is an algebraoperator that partitions a collection into multipledata streamsbased on type. For orderedstructures, we want our objectalgebra to containoperators that can 59 represent their most commoniterators. We are looking at scientificcodes and statisticalanalysispackages such S for as insights here. To avoid the inefficiencies of object-at-a-timeaccess from naive handling of and complexobjects objectidentifiers, we add the “assembly”operator for queryevaluation. in with Finally, dealing a moregeneralnamingscheme for persistent data items, we are trackingstability of in bindings our namespace. Thus, a variable name can be bound more or less statically to a type, a constraint, an implementation, an objectidentity, an auxiliaryaccess path, a statistic, or even a state. The queryoptimizer can incorporate this informationbased on the expectedlifetime of a query (e.g., one of transaction, one execution an applicationprogram, or multipleexecutions of an applicationprogram). QueryArchitecture The Revelationarchitecture has four levels. The top levelconsists of the In~erprelerand SchemaManager. The schemalanguage is used to define type interfaces(protocols) and their implementationsDaniels9O]. It also provides a namespace in which to declarepersistentvariables. The Interpreter can naivelyevaluate expressions, or alternatively it can pass an expression to the next level, the Revealer. The Revealerexpands an expression into a tree in an objectalgebra,throughreplacement of operations by their methods, and obtaininginformationaboutbindings and statistics from the namespace. The resultingalgebratree, with possibleannotations, is passed to the third level, the Oplimizer. The Revelationquery optimizer will be produced by a second-generationoptimizergeneratorbased on the EXODUSOptimizerGeneratorGraefe87]. The generator takes rules involvingalgebraicequivalences and cost metrics and produces an optimizer incorporatingthat knowledge. The Optimizerproduces a queryplan,which is a program for the Revelation QueryEvaluaior, the fourthlevel. Interpreterand SchemaManager A Revelationschema has three parts: protocols,implementation and the namespace. Protocolsdescribe the interfaces to databaseelements in terms of the permittedoperations on instances and give signatures to thoseoperations—protocols(types) for arguments and the result. Note that nothingabout datastruc tures or layout is included in a protocol. Protocols are related in a hierarchy by conformance, where if protocolColoredPolyconforms to protocolPolygon, an instance of ColoredPoly can be substitutedwhere an instance of Polygon is expected.Implementationsconsist of a representation and methoddefinitions. for instances Representations are constructed by free composition of datastructures, such as integer and array(T).Methods are defined in a language that extends the objectalgebrawith controlstructures and assignment. We allow one implementation to satisfyseveralprotocols, and one protocol may be satisfied by multipleimplementations. The namespace containspersistentvariables that may be typed by any of the definedprotocols;Thesevariables may havepropertiesbesidestypesstaticallybound to them, such as implementation or even state. The namespace is whereconstraints such as referentialdependencies and subsetrelationships are defined. The SchemaManagerkeepstrack of protocol and implementationdefinitions and declarations in the name space,supplyinginformation as requested by the Interpreter and Revealer. It can also track information relating to the relativepermanence of the bindings and statistics on the numbers of instantiations of each implementation in the database. The Interpreter can executeexpressions(queries)involving the persistent variables in a straightforwardmanner. Each objectcarries a reference to its implementation. When the Interpreterencounters an operation on an object, it looks up the method for thatoperation in the appropriate implementation and evaluates the expressions in it recursively. Revealer If the Interpreterpasses an expression to the Revealer, the Revealerattempts to expand thatexpression by incorporatinginformationfrom the schema and namespace. The reason for the expansion is to gain more foreknowledge of the computationsteps and dataelements used in a query. The expression as given may containoperationswhosemethods are encapsulated from its issuer, and leavingthem encapsulatedlimits the choices for transformationsavailable to the queryoptimizer. The Revealer may breakencapsulation on operations,expandingthem to their methodswherepossible. The goal of the Revealer is to expand as manymessagenodes in the objectalgebra tree as possible.Completeexpansionmay not be possiblebecause of differingimplementations per protocol or becausegeneralcontrolconstructs such as recursionprevent 60 it. In such cases, expressions are passed to the Optimizer as unexpandedsubtrees, to be evaluated by the Interpreter at run time. In somecases, even though the method for a messagecannot be determined, the Revealermay be able to providepartialinformationaboutsuch a subtree, such as the portion of the object’s representationaccessed by the method or whether the method is read only. The conversationbetween the Revealer and the SchemaManager is through the Anno~aier. A collection of annotationkinds are defined for nodes in an expressiontree,such as protocol,implementation,representation, and accessedstructure. The Revealermakesrequests of the Annotater to derive a particularannotation for a specificexpression node, whichdeduces and records the value of the annotation. The Annotater may return a collection of values, due to ambiguityarisingfrommultipleimplementations of a singleprotocol. Expansion of an operation to its implementingmethod is one such annotation. The Revealer can specify the level of stability the Annotatershouldassume when derivingannotations, such as whether to assume the set of implementations or protocols is fixed. Here is wkere the notion of coincidencescomes in. If, for example, we are optimizingassuming no change in implementations, the Annotater can determine all possibleimplementations of a particularprotocol. If there is only one implementation (or if there are several that all share a singlemethod), it may expand a message into the correspondingmethodbody. This may convert the access to a simplestructuralaccess. We note that the Annotateroperates on a singleexpression node at a time—theRevealercontrols the oçder and extent of expansion. Optimizer The expandedexpression tree is handed to the Optimizer for optimization and transformation to a query plan. The expression tree is mostlyoperatorsfrom the objectalgebra, with possiblyembeddedInterpreter invocations on schema-leveltypes. Theobjectalgebra is structural,operating on valuesformed by free com position of a fixed set of constructors,which will contain at the leastbase types(such as integer and string), tuples,multi-dimensionalarrays,bags, and objectreferences. In addition to the operators of relational al gebrasuch as select andjoin, we includeoperators that capturecommoncontrolpatterns of scientific data manipulation like matrixalgebraoperations,time-seriesaveraging, and time-stepcomputations on grids. The Optimizeritself will be produced by an optimizergenerator and providingrules for algebraicidentities on algebraoperatorsshould be straightforward.However,rules for translatingalgebratrees intoqueryplans and cost estimates will requiremorework. A querij plan is a directive as to what physicaloperators to run, where to run them and in what order to run them. The physicaloperatorscorrespondlargely to those in the logicalobjectalgebra in terms of the functions they compute.However, the physicaloperators use differentalgorithms to realizethosefunctions, and their execution costs dependgreatly on dataset sizes and layouts. We are undertaking a methodical examination of physicalproperties of data and theirinteractionwithdifferentphysicaloperators.Examples of physicalproperties are clustering,partitioning, size, auxiliaryaccesspaths, and location in the memory hierarchy. We categorizephysicaloperators by whetherthey require,preserve,enforce, or destroy a particular property. For example, a nested-loopsjoin mightpreserve a certain sort order, whilehash join will destroy it. We are looking at how to construct cost functions that incorporateinformation on these dataproperties. QueryAlgebra Our query algebra must include bulk operations,beyond the traditional set operations, for ordered data such as lists and matrices. We also need algebraicidentities on these new operators, for queryciptimization. Matrixalgebra is an obviousstartingpoint, but we anticipateotheridentities. In examiningscientificapplications, we have seen other commonclasses of operations on ordered struc tures that we shouldsupport. One is conversionsbetween bulk types. An exampleinvolves a relationwith attributes(Altitude,Temperature,Pressure). We want to sort on Altitude, and then project Tem perature and Pressure into two parallelone-dimensionalarrays to provideinput for statisticaloperations. Relationalquerylanguagesdon’t work on this querysince, althoughmost can express sort orderings, they don’tguaranteeorder preservation after the sort key is projected away. Anothercommonmanipulation is small structuralselection such as taking a slab or pencilfrom a multi-dimensionalarray. We are seeking a set of operations on orderedstructures that expresses a largevariety of the desiredmanipulations. unions A Anotherquery algebraproblem is subtyping, for which we hope to use discriminated Vance9l]. powerfulfeature of object-orientedsystems is the late binding of messagenames to methods. An object the orienteddatabase willcompletethisbinding as much as possiblebeforeevaluating a query, but ambiguity 61 of names at timestill message optimization presents a challenge.Because of substi.tutability, a set overtype include both of Polygon may objects type Polygon and type ColoredPoly.Suppose a query, over such a set sends a area to each in the If message object set. the samemethod for area is used by all Polygon and ColoredPolyobjects,references to areamaysafely be replaced with that methodbody. Thisextends the queryexpression tree and permitsoptimizationsacross the methodboundary. If ColoredPolyprovides a differentmethod for area, this optimization is invalid.However, if the Polygon and be ColoredPolyobjects can distinguished, the operations on the two cases can be optimizedseparately. each has a its Internally object tag indicating implementation. A queryevaluator,cooperatingwith a query optimizer, can use this tag to executedifferentoptimizedqueryplans for the differentkinds of objects. In the algebra we use discriminatedunions to distinguishobjects of different but conformingtypes. Thus, a set over is type Polygon represented in the algebra as a set over type (ColoredPoly + Polygon), and each in the set is into this object injected type. Using this abstraction does not change the way a set over is but it offers type Polygon stored, conceptualadvantages. At times it may be beneficial to split a set of into (ColoredPoly + Polygon) sets of ColoredPolyand Polygon,and thenoperate on those setsseparately. The use of the uniontypeallows this splitoperation to be expressedalgebraically.Moreover, the result sets contain strictlymonotype,untaggedobjects,affordingmoreefficientprocessing. QueryEvaluator The Evaluatorexecutes Query queryplansfrom the Optimizer. It is based on the Volcanoextensiblequery executionsoftwareGraefe9o],whichimplements the physicaloperators and handlesdataflowbetweenthem. We have used Volcano’s extensibility to add a pair of operations for these new accessforms. The assembly Keller9l]operatorsupportscomplexstate. It takes a template that describessomefragment of an object’s state and a set of objectreferences and then assembles the requiredpieces of eachreferencedobject in main Unlike the memory. naivelyorderedaccess of the Interpreter, the assemblyoperatorre-orders the accesses to take of advantage clustering.Anotheroperator we have used to extendVolcanoinvokes the Interpreter duringqueryexecution, thus resolvingunrevealedsubtreespassedthrough the Optimizer. Conclusion We have described a number of features of next-generationdatabases, and shown both theirutility and the to challenges they present queryoptimization. We have also laid out our basicattack on these challenges. We to expect complete our first prototypesystem this summer, and use it as a testbed for our optimization ideas. While the system we are building has an object-orientedmodel, we expect this work to provideuseful insights to anyonetrying to improvequeryoptimization in databases withuser-extensibletypes. Atkinson9o] M. Atkinson, F. Bancilhon, D. DeWitt, K. Dittrich, D. Maier, and S. Zdonik, “The Object- OrientedDatabaseManifesto,” Deductive and Object-OrientedDatabases, W. Kim, J.—M. Nicolas, and 5. Nishioeditors,ElsevierSciencePublishers B. V. (North-Holland), 1990. Daniels9o] S. Daniels,“Speaking in Tongues: The Language of Revelation,” OGI TR CSE-91-007, April 1990. Graefe87] G. Graefe and D. DeWitt, “The EXODUSOptimizerGenerator,”Proceedings of the 1987 SIGMODConference, San Francisco, CA, May 1987. Graefe88] G. Graefe and D. Maier, “QueryOptimization in Object-OrientedDatabaseSystems: a Prospectus,” Advances in Object-OrientedDatabaseSystems,Lecture Notes in Computer Science 334, Springer-Verlag,September 1988. Graefe9o] G. Graefe,“Encapsulation of Parallelism in the VolcanoQueryProcessingSystem,” Proceed ings of the 1990SIGMODConference,AtlanticCity, NJ, May 1990. Keller9l] T. Keller, G. Graefe, and D. Maier,“EfficientAssembly of ComplexObjects,” to appear in SIGMOD 91, also OGI TR CSE-90-023, April 1991. Vance9l] B. Vance,“Towards an Object-OrientedQueryAlgebra,” OGI TR CSE-91-008, May 1991. 62 IEEE ComputerSociety Non-profitOrg. \~~71730MassachusettsAvenue, NW U.S. Postage Washington, DC 20036-1903 PAID SilverSpring, MD Permit1398 Mr. Henr’y F. X~rtri University of Texas Taylor 21~4 Dept of Cs Austin~ TX 78712 USA, for all types s and t such that s ~ t.