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 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 op erations

In contrast Data are instances of concrete typ es eg numb ers strings or constructed typ es eg

tuple or

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 to nested relational algebra where the inputs

and outputs of the op erations are sets of ob jects Hence query op erators can b e applied to extents

of classes setvalued function results and query results The algebra has an ob jectpreserving

semantics in the sense that queries return some of the input ob jects This semantics for queries

allows the application of metho ds and up date op erations to results of a query since these contain

base ob jects As query op erators we provide selection of ob jects pro jection extension and the set

op erations for union intersection and dierence

BASIC SCHEMA TRANSFORMATION PROCESSORS

In this section we dene and analyze three basic schema transformation pro cessors for federated

ob jectbases i schema extension to add new derivable information p ersistently to a schema ii

ltering to hide schema information from users and iii composition to combine several schemata

together We showhowtheytinto ShethLarsons reference architecture while at the same time

they attack the problems mentioned in the intro duction

Schema Extension Views

It is widely accepted for relational systems that a primary step towards extensibility and exibility

of database schemata is the p owerful mechanism of dening views p ersistent queries In the

COCOON mo del views are dened as virtual classes whose extentandtyp e is derived by a query

based on other classes The main dierence to other ob jectoriented view approaches is that we

use the query language ob ject algebra and do not intro duce sp ecialpurp ose syntactic constructs

for view denition Hence views are declared as

dene view v as e

an algebraic query expression of arbitrary complexity Another imp ortant dierence is that with e

views are p ositioned in the typ e and class hierarchies according to their computed typ e and extent

Previous work has b een done to nd a formal semantics and to makesuch views up datable

In the sequel wegive a summary for views dened byeach of the basic algebra op erators Notice

however that views can also b e dened over other views or by comp osite queries We describ e what

the member typ e and the extent is and how these are p ositioned in the typ e and class hierarchies

Selection views dene view v as selectpe The extent of the view v is a subset of the base

class memb ers namely those satisfying the predicate pThemember typ e remains unchanged such

that there are nowtwo classes v and c of that typ e Consequently the view class v is p ositioned

as sub class of the base class c with fewer ob jects but the same member typ e

Projection views dene view v as pro jectf e The member typ e of view v is

a sup ertyp e of the original one since less functions are dened on it namely those listed in the

pro jection However pro jection do es not manipulate the extent such that the extentofv is the

same as that of e The view is therefore p ositioned as a sup erclass v is a sup erclass of c with smaller

set of applicable functions

Extend views dene view v as extendf expre While pro jection eliminates

functions extend denes new derived ones f byany legal arithmetic b o olean or setexpression

expr So the typ e of view v is a subtyp e of the base class typ e since it has more functions all the

old functions plus the new ones are dened Like with pro jection the extentisunchanged again

The view v is therefore a sub class of chaving the same extent but additional functions

Setoperator views dene view v as e union j intersect j dierence e Astheextentof

classes are sets of ob jects we can p erform set op erations as usual These views change extents as

well as member typ es However in a p olymorphic typ e system we need no restrictions on op erand

typ es of set op erations ultimately they are all instances of typ e ob ject A union view creates a

common sup erclass of its bases classes where the extent is the union of the base class ob jects and

the member typ e is the lowest common sup ertyp e intersection of base class functions of the input

typ es An intersection view is common sub class with the intersection of the input ob jects and

the greatest common sup ertyp e union of base class functions as member typ e Finally dierence

views are sub classes of their base classes with the same member typ e and the dierence of the base

class ob jects as extent

Based on the abstraction of derived classes as views schema extension is nowdenedasthe

pro cessor that enhances a given schema with derived information

Denition Schema Extension Let S CVTF b e a database schema Furthermore



V b e a set of views dened on C and V The extension of S by V is a schema S let

S S

     

C V T F with C C and V V V

S

   

Recall from Denition that typ es T and functions F are computed from C V Related

to federated systems schema extension is used on two dierentlevels In LOBs to customize the

comp onentschema b efore it participates the federation and in FOBs to create external schemata

of the global federated system

Example The following DDL statements dene a schema SalesDB as an extension of SalesDB

The imp ort clause makes the base schema available such that additional views can b e dened

define schema SalesDB as

imp ort SalesDB

dene view PublArticles as pro ject ano matn boughtby Articles

dene view ArticlesUS as extend price price Articles

dene view UselessCustomers as select bought fg Customers

end

The extended schema SalesDB is illustrated in Figure Notice how views are p ositioned in the

class hierarchy Whereas selection and extend views are sub classes of their base class the pro jection

view is a sup erclass

Notice that for complex view queries the problem of p ositioning the result view is in general undecidable due

undecidability of predicate subsumption Alternative solutions are prop osed in

S fArticles Screws Customers g

SalesDB 

fPublArticles ArticlesUS UselessCustomersg

farticle screw customer ano matn boughtby ano matn price price g

fano price price matn boughtby thread name addr bought g

Remember that typ es are suciently sp ecied by their applicable set of functions and need not

b e named Eg the pro jection and the extension view pro duce new unnamed typ es For unnamed

typ es we alternatively enumerate its function sets ano matn boug htby andano matn pr ice pr ice

in the schema description

ano PublArticles matn boughtby

inv

name price Articles Customers addr

bought bought = { }

Useless ArticlesUS$ Screws

price$ thread Customers

Figure Schema SalesDB as the extension of SalesDB with view classes

Schema Filtering Subschemata

The opp osite pro cessor of adding derived information to a schema is ltering that is excluding parts

of a given schema eg classes and views After extending a schema with derived information it is

desirable to identify a subset of classes and views in order to build a subschema Only the selected

classes and views of a subschema are then exp orted to foreign services such as users applications

or other systems

Denition Subschema Let S CVTF be a schema Then a subschema of S is a

      

schema S C V T F with C C and V V

Schema ltering pro cessors are used in LOBs together with schema extension to dene a cus

tomized subschema that do es not contain all comp onent classes and views of the LOB In a FOB

subschemata are similarly used as global external schemata Below we give an example on howto

use subschemata to hide information from a users

Example To dene a subschema without pricing information we rst extend SalesDB with

view PublArticles pro jecting out the price function from the class ArticlesThentheexp ort clause

is used to mak e visible just the class Customers the view PublArticles and nothing else

define schema SalesDB as

imp ort SalesDB

dene view PublArticles as pro ject ano matn boughtby Articles

exp ort Customers PublArticles

end

The resulting subschema SalesDB is illustrated by the dotted area in Figure a b elow

S fCustomers g

SalesDB 

fPublArticles g

fcustomer ano matn boughtby g

fano matn boughtby name addr bought g

bought

ano ano name PublArticles PublArticles inv PublCustomers addr matn matn boughtby boughtby inv

name price Articles Customers price Articles Customers addr

bought

thread Screws thread Screws

(a) (b)

Figure a Not closed subschema SalesDB and b closed subschema SalesDB

The ma jor restriction to b e imp osed on subschemata is transitive closure of typ es This attacks

the problem that there must not b e a function in a subschema that leads out of it More formally

the range typ e of each function of a subschema has to b e part of the subschema itself Op en

schemata must b e omitted since programs running with them may result in runtime typ e errors

It is quite intuitive that an application cannot handle ob jects whose typ es are not describ ed in the

schema This restriction leads to the following revised denition

Denition Closed Subschema Let S CVTF be a schema Then a closed

       

subschema of S is a schema S C V T F with C C and V V suchthatf F



with range f ob ject range f T

For closure w e consider only ob jectvalued functions that is functions returning an instance

of an abstract ob ject typ e We assume that primitivevalue typ es suchasinteger b o olean and

string are by denition part of anyschema that is functions with such range typ es do not lead

out of the schema even if we did not explicitly include their range

Notice that the subschema of Figure a is NOT closed This can easily b e seen b ecause the

function bought leads out of the dotted area The application of function boughtc to a given

customer c is a valid expression according to op en subschema SalesDB The result is a set of

articles though the typ e article is not part of the schema only a sup ertyp e of it namely ano

matn boughtby Tomaketheschema closed the transitive closure of all functions range typ es

must b e built see also which results in the following closed version of SalesDB

S fCustomers g

SalesDB  

fPublArticles g

fcustomer ano matn boughtby article g

fano matn boughtby name addr bought price g

The schema is now closed again However the price function was included which is exactly what

wewanted to avoid The way out from the ab ove dilemma is an enhanced pro jection op erator that

allows to redirect function range typ es The redirecting projection allows to change the range

typ e of a pro jected function in the pro jection list

pro ject ft e with t r ang ef

Redirection m ust b e limited to sup ertyp es in order to stay within the typ e checking p ossibilities of

a p olymorphic typ e system

Example The revised attempt to nd a closed subschema without pricing information is to

dene two redirecting pro jection views as follows

define schema SalesDB as

imp ort SalesDB

dene view PublArticles as pro ject ano matn boughtbyPublCustomers Articles

dene view PublCustomers as pro ject name addr boughtPublArticles Customers

exp ort PublArticles PublCustomers

end

In the nal subschema SalesDB just these two views are made visible Figure b shows that

SalesDB is now closed and information ab out prices are completely hidden

S fg fPublArticles PublCustomers g

SalesDB 

f ano matn boughtbyPublCustomers name addr boughtPublArticles g

f ano matn boughtbyPublCustomers name addr boughtPublArticles g

t observation ab out the closure of subschemata is that there is no restriction on the An imp ortan

classes only on typ es Obviously the sole purp ose of schema ltering is to hide some ob ject collec

tions ie classes from the exp ort schema so there should not b e a need for inclusion of classes

or views into an exp ort schema b ecause of closure constraints Particularlywedonotneedto

include the base classes of a view into the subschema when including the view

Schema Comp osition Interop erability

Both schema transformations presented so far op erate on one single schema The next pro cessor

called schema comp osition is the rst step towards interop erabilityofmultiple ob jectbase systems

It is the elementary pro cess that combines schemata of multiple LOBs into one composed schema

This is the foundation for establishing a federated ob jectbase system Schema comp osition places

only minimal requirements on the degree of integration b etween participating ob jectbases In fact

it basically just imp orts the names of all schema elements classes views typ es and functions

from LOBs and makes them globally available

Example Assume wewant to create a FOB FedDB consisting of the LOBs SalesDB and ProdDB

from Example The very elementary step is to comp ose the schemata of the participating systems

define schema FedDB as

imp ort SalesDB

imp ort ProdDB

end

Figure graphically illustrates howschemata of SalesDB and ProdDB are put sidebyside bythe

ab ove imp ort clauses

FedDB Objects @FedDB

SalesDB ProductionDB Objects@ Objects@ SalesDB ProdDB

bought supplies ano name Articles@ inv Customers name mno Materials Suppliers price inv street SalesDB @SalesDB addr weight @ProdDB @ProdDB matn city boughtby supplby

thread Screws@

SalesDB

Figure Comp osition of lo cal schemata SalesDB and ProdDB into FedDB

More precisely comp osition of lo cal ob jectbases LO B into a federated system FOB combines

i

the class and typ e systems of the lo cal ob jectbases First the basic data typ es integer string

of the dierent systems are unied Second the class and typ e hierarchies of the lo cal ob jectbases

are put together on the schema level AND on the metaschema level in the following so far trivial

way

Schema Level A global schema is created with a new top typ e objectFOB a new b ottom typ e

bottomFOB and a new global top class ObjectsFOB

The global typ e hierarchy is established where all top typ es of the lo cal ob jectbases objectLOB

i

are made direct subtyp es of the new global top element objectFOB The new b ottom typ e bot

tomFOB is made common subtyp e of all lo cal b ottom typ es No further subtyp e relationships are

established

Similar a global sub class hierarchy is comp osed with the new top element ObjectsFOB as

common sup erclass to all lo cal top classes ObjectsLOB see Figure

i

MetaSchema Level A global metasc hema is created as well This is the meta schema of

the FOB The metaschema of each LO B contains three meta typ es class type functions and

i

three meta classes Classes Types Functions resp ectively a detailed discussion of the COCOON

metaschema is contained in



In the sequel we use the naming convention that schema comp onents are suxed by and the name of the

lo cal schema For example class Articles in SalesDB has as globally unique name ArticlesSalesDB

A global metaschema is created with new typ es classFOB typeFOBandfunctionFOBas

well as three new meta classes ClassesFOB TypesFOBand FunctionsFOB The FOB meta

schema has therefore exactly the same structure as that of each LO B Then the lo cal meta classes

i

and meta typ es are made sub classsubtyp e of their global counterparts see Figure

Furthermore meta functions are unied during the comp osition pro cess eg in each LO B there

i

is a meta function super typestLOB nding all sup ertyp es of a given typ e t These functions

i

are all automatically unied over all ob jectbases

FOB Objects @FOB

Classes Types Functions @FOB @FOB @FOB

LOB1 LOB2 Objects Objects @LOB1 @LOB2

Classes Types Functions Classes Types Functions

@LOB1 @LOB1 @LOB1 @LOB2 @LOB2 @LOB2

Figure The global metaschema after comp osition

Denition Schema Comp osition Let S C V T F S C V T F

n n n n n

    

b e database schemata Then the comp osition of S S is a schema S C V T F with

n

 

C C C C and V V V where C f Objects Classes Types Functions

n n

g is the set of federated meta classes

Schema comp osition is not yet real ob jectbase integration In particular no instance of

objectF OB is instance of more than one comp onenttyp e objectLOB Furthermore the extent

i

of ObjectsFOB is partitioned into disjoint subsets ObjectsLOB As a consequence no two

i

ob jects in ObjectsFOB can b e the same identical unless they originate from the same LO B

i

and are identical in LO B

i

Real integration of instances and schemata is p erformed quite easily by applying schema exten

sion pro cessors to formerly comp osed LO B schemata This is elab orated next

i

INTEGRATION OF OBJECTBASES

The goal of a FOB is to have a uniform view over parts of multiple LOBs such that queries and

up dates can b e formulated against the federation that involveseveral LOBs Weintro duced schema

comp osition as the rst step towards interop erabilityofmultiple LOBs and mentioned that it is

not real integration but simply putting schemata sidebyside

In this section we show the next step for integration of ob jects and schemata the use of schema

extension The mechanisms of applying ob ject algebra and views in multiob jectbases have b een

discussed in We recall here some of the results as far as they are necessary to understand how

extension ltering and comp osition pro cessors work on FOBs

Querying Comp osed Schemas

Once two or more schemata are comp osed we are ready to formulate queries that involvemultiple

LOBs Recall comp osition FedDB of Example Figure and assume wewant to question which

customers are suppliers as well Since comp osition made basic data typ es and name spaces globally

available we can compare names of customers with names of suppliers

select select namec names sSupplierscCustomers

Unfortunately the p ossibilities of interob jectbase queries are very limited Eg the following more

elegant solution of the same problem is illegal

select c Suppliers cCustomers

Since the typ e of class Suppliers is supplier and the typ e of c iscustomer and the twotyp es

customer and supplier are not related this selection predicate would b e rejected by the typ e checker

The extend query op erator denes new functions derived by a query expression We can already

use this p ossibility to establish connections b etween LOBs Supp ose wewant to store together with

eachraw material of ProdDB the articles of SalesDB that are pro duced out of it

mats select matna mnomaArticles mMaterials extend

The new function mats is an interob jectbase link from ProdDB to SalesDB

Unifying Ob jects

Since LOBs have b een used indep endently of each other one real world entity ob ject maybe

represented by dierent database proxy ob jects in dierent LOBs The fundamental assumption

of ob jectoriented mo dels namely that one real world ob ject is represented by exactly one database

ob ject is therefore no longer true in FOBs We therefore need an additional notion wesay that

two lo cal ob jects are the same i they represent the same real world entity ob ject

Same ob jects are identied in FOBs by extending the comp osed schema using extend views to

dene so called samefunctions Formallywe require that for anytwotyp es from dierent LOBs

T from LO B and S from LO B the instances of which shall b e unied we are giving a query

i i j j

expression that determines for a given T ob ject what the corresp onding S ob ject is if any and

i j

vice versa This query expression is used to dene a deriv ed function same from T to S and

T S i j

i j

its inverse same Obviously these query expressions are application dep endent and can in

S T

j i

general not b e derived automatically

To state that instances of typ e customer of SalesDB are identical with instances of typ e supplier

of ProdDB if they have identical names for example wehave to dened the following same

functions

extend same pickselectnamec namessSuppliers

customersupplier

cCustomers

extend same pickselectnames nameccCustomers

suppliercustomer

sSuppliers

Notice that the pick op erator do es a set collapse that is it takes a single ob ject out of a

singleton set This is valid here since we assume that each ob ject in one ob jectbase corresp onds to

at least one ob ject in the other ob jectbase

Same ob jects are formally dened by a notion of global object identity such that two ob jects

o o are global identical if they are from the same LOB and they are lo cal identical o o or

i j i j

if they are from dierent LOBs and they are dened to b e the same with a samefunction b etween

their typ es S T and o same o

j i i S T j

j i

Schema Integration

After unifying proxy ob jects in dierent LOBs wenow concentrate on schema integration that

is to nd out what the common parts in the lo cal schemata are and to dene a corresp ondence

among them

In Subsection wesaidthatschema comp osition also constructs a global meta schema To

dene corresp ondences b etween functions from dierent LOBs wemake use of the fact that every

function is represented by a meta ob ject Thus integrating functions from LO B and LO B is now

i j

straightforward we unify the ob jects that represent the functions in the metaschema by dening

a samefunction from meta typ e functionLO B to meta typ e functionLO B

i j

To unify for example the functions nameSalesDB and nameProdDB the following same

function is dened on the meta schema of FOB

extend same

functionSalesDBfunctionPro dDB

pickselect namef name nameg name

gFunctionsSalesDB

fFunctionsPro dDB

In contrast to most other schema integration approach that emphasis on solving semantic and struc

tural conicts among dierent systems we concentrate here on reducing schema integration

to unifying meta ob jects

Ob jectbase Integration Metho d

Wehavenow dened all prerequisites for tight ob jectbase integration weshowed how to nd same

ob jects over multiple systems and discussed schema integration as unication of metaob jects As

a consequence we can now come up with a metho dology for stepwise integration of p opulated

ob jectbase systems that uses schema comp osition together with extension

Step Use schema comp osition to put LOB schemata sidebyside and to maketyp es and classes

known to each other

Step Use schema extension to add extend views with samefunctions to identify proxy ob jects

from dierent LOBs that represent the same entity ob ject from the real world Use this

mechanism also to integrate corresp onding parts of the LOB schemata into an uniform schema

element in the FOB by unifying meta ob jects representing functions from dierent LOBs

Step Use schema extension again to add views that span over several ob jectbases They now

resp ect same ob jects from dierent LOBs and same prop erties from dierentLOBtyp es

Example Reconsider the schema FedDBFollowing to the ab o ve metho d we rst comp ose

the lo cal schemata by imp orting SalesDB and ProdDB Then we extend the classes Customers and

Suppliers with samefunctions Finally the meta class FunctionsSalesDB is extended to integrate

nameSalesDB and nameProdDB prop erties

define schema FedDB as

imp ort SalesDB

imp ort ProdDB



dene view Customers SalesDB as extend seeSubsection



dene view Suppliers ProdDB as extend seeSubsection



dene view Functions SalesDB as extend seeSubsection

 

dene view Persons as Customers SalesDB union Suppliers ProdDB

end



Since ob jectbase integration is not the main topic of this pap er but should just b e discussed as an application

of schema transformation pro cessors we refer for more details on samefunctions global identity solving structural

and semantic conicts to

Now we are ready to dene views that span multiple ob jectbases eg a view Persons as the union

 

over the extended classes Customers SalesDB and Suppliers ProdDB

The p ointofinterest is the extent and the typ e of the union view The extent is dened to b e

the union of the ob jects of the base classes However if there would b e a customer ob ject and a

supplier ob ject having equal names they are dened through the samefunction to represent one

and the same real world ob ject and will therefore app ear only once in the union view The typ e of

a union view is dened as intersection of the functions of the base classes Thus since the typ e of



Customer is name addr boug ht same and of Suppliers is name str eet city suppl ies same

cs sc

and nameSalesDB and nameProdDB functions are dened to b e the same the typ e of the view

is name

ACCESS CONTROL AND AUTHORIZATION

FOBs are supp osed to bring together several comp onent systems Federation users will therefore

have p ossible access to large data rep ositories Consequentlyaccesscontrol and authorization is

a ma jor problem in the design of federated systems In this section we discuss the p ossibilities

there are to p ermit or deny access to ob jects in a federation using schema extension and ltering

pro cessors

Authorization Possibilities

So far weintro duced twomechanisms of hiding sp ecic information from users views and sub

schemata Views as virtual classes op erate on collections of ob jects The p ossibilities of a query

language are available to restrict either the set of visible ob jects or the applicable functions Sub

schemata as a collection of classes and views op erate on whole schemata They are used to grant

access to a sp ecic user for a dened subset of a given schema

Selection views are used to hide some of the ob jects in a class The hidden ob jects must b e

describable by a predicate using information of the database We can for example hide exp ensive

screws

dene view CheapScrews as select price Screws

or cover articles that havenever been boughtby someb o dy

dene view SoldArticles as select boughtby fgArticles

from users of SalesDB

A rst idea of how to use pro jection views in order to hide prop erties of classes was given in

Example Moreover since functions are abstractions of stored prop erties as wellasofmethods

access can b e restricted to read write or up date Consider in the same example the class Articles

price Pro jecting out the prop erty price while keeping get price has with an additional metho d get

the eect of setting a readonly privilege

Extend views are thoughttokeep the result of a query as a new prop ertyofobjectsAswehave

seen also in Section this is a very p owerful mechanism For authorization purp oses extend views

are adequate to show a new derived prop erty Assume users of the Materials class are not allowed

to see the supplier but need to know the city where the material is supplied from



dene view Materials as pro ject mno weight city

extend scity citysupplbym mMaterials

The setop erator views union intersection and dierence makephysical distribution transpar

ent Supp ose a union of two classes from dierent LOBs If only the union view is visible a user

do es not need to knowinwhich LOB the ob jects are physically stored

Schema extension together with ltering pro cessors are well suited as the basic mechanisms for

exible control of ob ject access in FOBs In fact due to ob ject identitywedonothave the problem

of view up datability in our mo del Furthermore abstract ob ject typ es ob ject encapsulation and

typ esp ecic metho ds enhance to p ossibilities of authorization using view classes compared to

relational systems for example We thereafter prop ose the following twostep authorization metho d

Step Use schema extension to dene a view class on those classes where you want to hide some

information

Step Use schema ltering to dene a subschema including your dened views while ltering

out their base classes

Notice that ltering out the base class of a view do es not restrict up datability In the example

ab ove we can create a new screw ob ject in the view CheapScrews at any time The up date will b e

propagated to the base class Screwseven if it is not part of the subschema The only sideeect

is that if the newly added ob ject was not a cheap one it is afterwards not any more visible in the

view Nevertheless the ob ject is available as an article of course

Levels of Access Control

In FOBs weuseschema extension and ltering pro cessors mainly on two dierentlevels i related

to LOBs to sp ecify exp ort schemata and therefore to control access to a comp onent system ii

related to FOBs to sp ecify global external schemata and therefore to control access to the global

federated system Negotiations b etween the comp onent DBAs and the federation DBA is necessary

to agree who has the control access on which ob jects

Example Consider the following scenario the twoLOBsgiven in Example should b e merged

into a federated system such that there will b e two new customized databases a PersonDB holding

all information ab out customers and suppliers and a ConstructionDB with all data on articles and

materials To do this there are mainly two p ossible alternatives to combine the LOBs SalesDB and

ProdDB b oth of which come to the same result

PersonDB ConstructionDB PersonDB ConstructionDB extension & composition composition filter

GlobalDB CustomerDBArticleDB SupplierDB MaterialDB extension extension & & filter filter composition

SalesDB ProdDB SalesDB ProdDB

(a) (b)

Figure Access control trusted a to federation DBAs and b to lo cal DBAs

Alternative The federation DBA comp oses complete LOB schemata into a single schema

GlobalDB Based on this global schema he derives twosubschemata by extension and ltering

PersonDB including customers and suppliers and ConstructionDB with articles and materials see

Figure a

In this approach comp onentDBAsdonotmakeany restriction to the data they exp ort to the

federation Thus full access control is trusted to the federated DBA he is resp onsible to combine

the appropriate classes into subschemata of the federation and to makeavailable to the distinct

users

Alternative Eachcomponent DBA creates on his LOB site customized subschemata already

splitting the lo cal ob jectbase into information ab out p ersons and construction To the federation

DBA of the PersonDB and of the ConstructionDBwhichmay b e dierent only those subschemata

are made accessible they nally need So one will comp ose CustomerDB with SupplierDB and the

other ArticleDB with MaterialDB see Figure b

In this approach comp onent DBAs havecontrol on their lo cal data and provide access individ

uallyFederation DBAs mayeven not know what is the full contents in the LOBs

RELATED WORK

Recently there has b een an increasing numb er of prop osals on how to supp ort views in ob ject

oriented systems Our approach is fundamentally dierentinthatwemake exclusive use of query

language expressions ob ject algebra to dene views In contrast eg O and ORION

intro duce sp ecial purp ose view denition features FUGUE use typ e hierarchies for information

hiding and POSTGRES uses the rule system for view simulation

Moreover most of them do not consider p ositioning view classes in typ e and class hierarchies

One exception is a view denition metho dology of where one basic step is integration of virtual

classes into one consistent global schema presents a related solution byintro ducing a new view

derivation hierarchy that is orthogonal to the typ e and class hierarchies

Closure was recognized imp ortant for schema correctness in The latter presents an

algorithm making anyschema closed by transitively including all range classes As we discussed in

Subsection this approach is not satisfactory since it brings in prop erties of ob jects through the

back do or that weintentionally wanted to lter out

The approach of database integration by nding corresp onding prop erties and proxy ob jects

was also investigated in They intro duced for eachkindofsemantic relationship b etween

ob jects a new sp ecial typ e of generalization class In contrast our solution makes exclusiveuseof

an algebraic ob ject view mechanism using the p ossibilityofthe extend op erator to establish links

between LOBs

The p ower of views and query languages for access control was discussed very early for relational

systems realized that for databases including richer ob jectoriented and semantic concepts

an advanced mo del for authorization is needed Howevertheydonotinvestigate the enhanced

p ossibilities of an ob jectoriented algebra encapsulation typ esp ecic metho ds for authorization

purp oses

CONCLUSION

The contribution of this pap er is three basic schema transformation pro cessors for federated ob ject

bases schema extension to add views that are computed by an algebraic query language ltering

to build a closed subschema and comp osition to put schemata sidebyside

FOBs are supp osed to follow ShethLarsons reference architecture with veschema levels The

three pro cessors are said to b e complete in the sense that every transition b etween these schema

levels can b e attained by applying a combination of them as follows

Nevertheless the pro cessors do not require xed levels but supp ort incremental evolution from

given LOBs to customized useroriented FOBs In fact one may also see this as a b ottomup

development and design metho dology for FOBs Component LevelExport Level Federated Level External Level

extension & filter composition & extension extension & filter

Integration of ob jectbases was intro duced as schema comp osition followed byschema extension

the comp osition pro cessor puts LOB schemata sidebyside whereas the extension pro cessors adds

samefunctions and unied views This approach defuses the problem of huge federated schemata

b ecause there is no need to dene such a global view but instead only those parts are to b e combined

that are really needed It pays also attention to the fact that LOBs are p opulated b efore they come

together in a federation

Access control and authorization in FOBs was shown how to b e managed byschema extension

together with schema ltering the extension pro cessor adds virtual classes hiding sp ecic informa

tion whereas the ltering pro cessor denes a subschema including the view while ltering out its

base classes It was discussed that access control can b e p ermitted or denied either lo cally on

LOB level or globally on FOB level

At the b eginning wementioned that we are restricted to FOBs with homogeneous data mo dels

Future work will consider a fourth pro cessor schema mapping This pro cessors is needed to map

LOB schemata of dierent mo delslanguages into a common data mo del First results are already

available from the FEMUS pro ject where COCOON ob jectbases and algebra expressions were

mapp ed to an extended entityrelationship mo del with an ER calculus

References

S Abiteb oul and A Bonner Ob jects and views In Proc ACM SIGMOD Intl Conf on

Management of DataDenver Colorado June

M Andersson Y Dup ont S Spaccapietra K Yetongnon M Tresch and H Ye The FE

MUS exp erience in building a federated multilingual database In Proc st Intl Workshop on

Research Issues on Data Engineering Interoperability in Multidatabase Systems RIDEIMS

Vienna Austria April IEEE Computer So ciet y Press

C Batini M Lenzerini and SB Navathe A comparative analysis of metho dologies for data

base schema integration ACM Computing Surveys December

C Beeri Formal mo dels for ob jectoriented databases In Proc st Intl Conf on Deductive

and ObjectOriented Databases DOODKyoto Japan Decemb er NorthHolland

E Bertino Aviewmechanism for ob jectoriented databases In Proc rd Intl Conf on

Extending Database Technology EDBT Vienna Austria March Springer LNCS

J Geller Y and EJ Neuhold Structural schema integration in heterogeneous multi

database systems using the dual mo del In Proc st Intl Workshop on Research Issues on

Data Engineering Interoperability in Multidatabase Systems RIDEIMSKyoto Japan April

IEEE Computer So ciety Press

S Heiler and SB Zdonik Ob ject views Extending the vision In Proc th Intl IEEE Conf

on Data Engineering ICDE Los Angeles February

D K Hsiao Federated databases and systems VLDB Journal

W Kent The breakdown of the information mo del in multidatabase systems ACM SIGMOD

Record Decemb er

F Rabitti E Bertino W Kim and D Wo elk A mo del for authorization for nextgeneration

database systems ACM TODS March

EA Rundensteiner MultiView a metho dology for supp orting multiple views in ob ject

oriented databases In Proc th Intl Conf on Very Large Data Bases VLDBVancouver

Canada August

MH Scholl C Laasch C Rich M Tresch and HJ Schek The COCOON core ob ject mo del

Technical rep ort ETH Zuric h Dept of Computer Science in preparation

MH Scholl C Laasch and M Tresch Up datable views in ob jectoriented databases In

Proc nd Intl Conf on Deductive and ObjectOriented Databases DOOD Munich Germany

Decemb er Springer LNCS

MH Scholl and HJ Schek A relational ob ject mo del In Proc rd Intl Conf on Database

Theory ICDTParis

MH Scholl HJ Schek and M Tresch Ob ject algebra and views for multiob jectbases In

Proc Intl Workshop on Distributed Object ManagementEdmonton Canada August

Morgan Kaufmann

M Schre ObjectOriented Database Integration PhD thesis Technische Universitat Wien

Osterreich June

AP Sheth and JA Larson Federated database systems for managing distributed hetero

geneuos and autonomous databases ACM Computing Surveys September

S Spaccapietra C Parent and Y Dup ont View integration A step forward in solving

structural conicts IEEE Trans on Know ledge and Data Engineering Octob er

M Stonebraker and E Wong Access control in relational databases management systems by

query mo dication In Proc ACM National Conf

MR Stonebraker A Jhingran J Goh and S Potamianos On rules pro cedures caching

and views in database systems In Proc ACM SIGMOD Intl Conf on Management of Data

Atlantic CityUSAMay

M Tresch and MH Scholl Meta ob ject management and its application to database evolution

In Proc th Intl Conf EntityRelationship Approach Karlsruhe Germany Octob er

Springer LNCS

Contents

INTRODUCTION

AN OBJECT MODEL AND ALGEBRA

BASIC SCHEMA TRANSFORMATION PROCESSORS

Schema Extension Views

Schema Filtering Subschemata

Schema Comp osition Interop erability

INTEGRATION OF OBJECTBASES

Querying Comp osed Schemas

Unifying Ob jects

Schema Integration

Ob jectbase Integration Metho d

ACCESS CONTROL AND AUTHORIZATION

Authorization Possibilities

Levels of Access Control

RELATED WORK

CONCLUSION