PublishedinProc rd Intl Symp on Database Systems for Advanced Applications DASFAA Daejon Korea Apr SCHEMA TRANSFORMATION PROCESSORS FOR FEDERATED OBJECTBASES Markus Tresch Marc H Scholl Department of Computer Science Databases and Information Systems University of Ulm DW Ulm Germany ftreschschollgin formatik uni ul mde ABSTRACT In contrast to three schema levelsincentralized ob jectbases a reference architecture for fed erated ob jectbase systems prop oses velevels of schemata This pap er investigates the funda mental mechanisms to b e provided by an ob ject mo del to realize the pro cessors transforming between these levels The rst pro cess is schema extension which gives the p ossibil itytodene views The second pro cess is schema ltering that allows to dene subschemata The third one schema composition brings together several so far unrelated ob jectbases It is shown how comp osition and extension are used for stepwise b ottomup integration of existing ob jectbases into a federation and how extension and ltering supp ort authorization on dierentlevels in a federation A p owerful View denition mechanism and the p ossibil ity to dene subschemas ie parts of a schema are the key mechanisms used in these pro cesses elevel schema ar Keywords Ob jectoriented database systems federated ob jectbases v chitecture ob ject algebra ob ject views INTRODUCTION Federated ob jectbase FOB systems as a collection of co op erating but autonomous lo cal ob ject bases LOBs are getting increasing attention To clarify the various issues a rst reference architecture for federated database systems was presented by Sheth and Larson While the ANSISPARC threelevel schema architecture was adequate for centralized ob jectbases they in tro duced veschema levels for FOBs i the local schema as the conceptual schema of a LOB expressed in the native data mo del of each LOB ii the component schema as the translation of the lo cal schema into a canonical data mo del that is a mo del common to the federation iii the export schema as a subset of the comp onentschema holding the part that is made available to the federation and its users iv the federated schema as the integration of multiple exp ort schemata forming the global conceptual schema v the external schema as a sp ecial view of the federated schema customized for a class of federation users applications A close lo ok at this velevel reference architecture leads to the following observations Federated schemata are huge A federated schema as the global conceptual schema of the FOB may contain thousands of typ es and classes Moreover due to semantic heterogeneity a large numb er of structural conicts mayhav e to b e solved Thus static integration of many LOB schemata into one federated schema at one shot is not appropriate or even not feasible A view subschema mechanism is needed So far no widely accepted notion of views and subschemata in ob jectoriented database systems exists However this is essential for supp ort of customization and access control on LOB as well as on FOB level Within LOBs views subschemata are needed to sp ecify the exp orted part of the ob jectbase within FOBs they are used to dene external schemata of the federation Enforcing xed schema levels is to restrictive FOBs are supp osed to makeexisting data rep ositories dynamically work together Requiring vespecicschema levels mayb e to o static in fact it mighteven b e considered to violate the overall idea Thus not predened schema levels but typ es of schema transformation pro cessors should b e the main concern Lo cal ob jectbases are p opulated An FOB is basically develop ed in a b ottomup pro cess byintegrating existing LOBs Each of these LOBs supp osedly comes with already stored ob jects typ eclass instances Thus together with schema integration construction of the FOB must also consider the problem of unifying ob jects from dierent LOBs that represent the same real world entity This article tries identify the fundamental mechanisms that transform b etween the dierent levels of schemata in an FOB while at the same time taking into account the ab ove observations We dene three elementary schema transformation pro cessors schema extension schema ltering and schema composition and compare them with the reference architecture for federated ob jectbases We restrict our considerations to LOBs with homogeneous data mo dels That is we treat the problem of data mo del transformation as a separate issue Consequently there is no dierence between the lo cal and the comp onentschema of a LOB As a representative data mo del we use the ob jectoriented mo del COCOON However in vestigations are not limited to that mo del but can similarly b e applied to most other ob jectoriented mo delssystems The pap er is organized as follows In Section weoverview the ob jectoriented data mo del COCOON and its ob ject algebra Section intro duces the three basic schema transformation pro cessors extension lteringandcomposition In Section we describ e howtouseschema comp osition together with schema extension for the purp ose of integrating multiple LOBs into an FOB Section shows how to manage authorization and access control in FOBs using schema extension combined with ltering A comparison to other related work is made in Section Finally Section concludes with an outlo ok on op en issues AN OBJECT MODEL AND ALGEBRA We briey review the key concepts of the ob ject mo del COCOON and its algebra used throughout this pap er The COCOON ob jectmo del is an ob jectfunction mo del with the basic constituents objects functions types classesandviews Ob jects are instances of abstract ob ject typ es AOTs sp ecied by their interface op erations In contrast Data are instances of concrete typ es eg numb ers strings or constructed typ es eg tuple or set Functions are the generalized abstraction of attributes stored or computed relationships between ob jects and up date metho ds with sideeects They are describ ed by their name and signature ie domain and range typ e Functions can b e single or setvalued The implementation is given separately in the ob ject implementation language OIL which is not describ ed here any further y a set Typ es describ e the common interface to all of its instances So a typ e t is dened b of applicable functions functst The subtyp e isa relationship whichisusedfortyp echecking corresp onds to subset relationship of function sets such that typ e t is subtyp e of t i functst functst The ro ot of the typ e lattice is the predened typ e ob ject The language is strongly typ ed in the sense that it supp orts full static typ e checking Typ es can b e named However this is optional b ecause new typ es can arise dynamically as any set of functions Classes are strictly distinguished from typ es A class c isatyp ed collection of ob jects It has an asso ciated member typ e mtypec and an actual extension extentc ie the set of ob jects in the class We dene the extent of a class to include the memb ers of all its sub classes such that ob jects can b e memberofmultiple classes at the same time The sub class relationship is dened on the subset relationship of class extension and subtyp e relationship Hence c is a sub class of c i extentc extentc functsmtypec functsmtypec The top class of this hierarchy is the class Ob jects Views are virtual derived classes that is classes whose extent and member typ e are computed by a query expression We discuss views in more detail in Section b elow An ob jectbase schema is a representation of the structure syntax semantics and constraints on the use of an ob jectbase in the ob ject mo del In the COCOON mo del this is given as follows by classes views typ es and functions Denition Database Schema A database schema is a fourtuple S CVTF with C a set of given classes V a set of views dened on classes C S S mtype c T mtype v the set of member typ es of classes C and views V cC v V S F functs t the set of functions of typ es T tT Example As a running example throughout this pap er we use the sample scenario shown in Figure It illustrates a situation in a company using two indep endent COCOON ob jectbases SalesDB in the sales department storing information ab out articles and customers and ProdDB in the pro duction department with data on raw materials and their suppliers define database SalesDB as dene typ e article isa object ano price matn integer boughtby set of customer inverse bought dene typ e screw isa article thread string dene typ e customer isa object name addr string bought set of article inverse boughtby dene class A rticles article dene class Screws screw some Articles dene class Customers customer end define database ProdDB as dene typ e material isa object mno integer weight kilo supplby supplier inverse supplies dene typ e supplier isa object name street city string supplies set of materials inverse supplby dene class Materials material dene class Suppliers supplier end The schemata of the two databases SalesDB and ProdDB are given as S fArticles Screws Customers g fg farticle screw customer g SalesDB thread name cstreet addr bought g fano price matn boughtby S fMaterials Suppliers g fg fmaterial supplier g ProdDB fmno weight supplby name street city suppliesg SalesDB ProdDB bought ano supplies inv name price Articles Customers addr name matn mno Materials inv Suppliers street weight boughtby city supplby thread Screws Figure Lo cal ob jectbases SalesDB and ProdDB We use a setoriented query language similar