Translating update operations from relational to object-oriented databases

Translating update operations from relational to object-oriented databases

Xiuzhen Zhang, Joseph Fong*

Department of Computer Science, City University of Hong Kong, Kowloon, Hong Kong, People’s Republic of China

Received 19 August 1998; received in revised form 14 June 1999; accepted 8 July 1999

Abstract

In migrating a legacy relational database system to the object-oriented (OO) platform, when database migration completes, applicationmodules are to be migrated, where embedded relational database operations are mapped into their OO correspondents. In this paper we studymapping relational update operations to their OO equivalents, which include UPDATE1, INSERT and DELETE operations. Relationalupdate operation translation from relational to OO faces the touchy problem of transformation from a value-based relationship model to areference-based model and maintaining the relational integrity constraints. Moreover, with a relational database where inheritance isexpressed as attribute value subset relationship, changing of some attribute values may lead to the change of the position of an object inthe class inheritance hierarchy, which we call object migration. Considering all these aspects, algorithms are given mapping relationalUPDATE, INSERT and DELETE operations to their OO correspondents. Our work emphasize in examining the differences in the repre-sentation of the source schema’s semantics resulting from the translation process, as well as differences in the inherent semantics of the twomodels.q 2000 Elsevier Science B.V. All rights reserved.

Keywords:Relational model; Object-oriented model; Query translation; Update translation

1. Introduction

Migrating a legacy database system consists of migratingthe database and the application programs. With migrating arelational database system to object-oriented (OO) platform,we consider a methodology where the database is firstmigrated. In the migration process, a database gateway isnecessary providing flexibility for timing of applicationmigration with and target database. Both the database gate-way and the application program (with embedded databaseoperations) migration make it necessary to study mappingrelational database operations to their OO correspondents.

Database operations include query and update operations.In this paper, we will consider update operation translationfrom relational to OO model. While query translation fromrelational to OO model for database system migration hasbeen discussed [1], there has not been any work reported onupdate operation translation. Given an update operationUagainst a relational view, there exist more than one databaseupdates corresponding toU. So relational view updateoperation translation focuses on choosing the most suitable

database update operation corresponding to a view updateoperation from the candidates.

Considering the schema mapping between relational andOO model, we examine translating relational and updateoperations into corresponding OO operations. RDB toOODB schema mappingr , which is injective and surjec-tive, defines the 1:1 correspondence between databasestates. So given a relationalQ query whose target data isd , we can form the OO correspondentW of Q whose targetdata isg � r�d�. Moreover, given an update operationU:U�S� � T; whereS andT are the relational database statesbefore and afterU, respectively. Suppose thatr�S� � X;r�T� � Y; the OO operation(s) corresponding toU is Vwhich changes the OODB from stateX to stateY : V�X� �Y:

For exposition, we will use SQL [2] expressing relationaldatabase operations and OQL and C1 1 OML defined byODMG 2.0 [3] for OODB operations. A surjective andinjective mapping between relational and OO constructs isthe precondition for update operation translation from rela-tional to OO model.

In Section 2, we will discuss related work. Section 3describes mapping relational to OO schema. In Section 4,we propose the object migration problem in update opera-tion translation. Section 5 gives the algorithms mappingrelational UPDATE, INSERT and DELETE operations toOO operations. The prototype of mapping SQL to OSQL is

Information and Software Technology 42 (2000) 197–210

0950-5849/00/$ - see front matterq 2000 Elsevier Science B.V. All rights reserved.PII: S0950-5849(99)00058-0

www.elsevier.nl/locate/infsof

* Corresponding author. Tel.:1 852-2788-8580; fax: 1 852-2788-8614.

E-mail addresses:[email protected] (X. Zhang), [email protected] (J. Fong).

1 Note that we useupdatefor general update operations and UPDATE formodifying certain data values.

given in Section 6 followed by concluding remarks inSection 7.

2. Related work and contribution

Research efforts relating to our work come from twoareas: the work on multidatabase provides interoperabilitybetween data sources of different data models or provide aninterface of certain data model while the underlying data-base is of another database. This work focuses on translatingqueries between relational and OO models only [4–7]. Littleis addressed about the update operation translation betweendifferent data models. The second kind of related workcomes from the examination of translating relational viewupdate operations and has been discussed by severalresearchers [8–10].

The research activities along the two lines, however, havequite different motivations and condition than our problem.With the first kind of work, only query translation betweenexisting databases is considered and uniform and simplemappings between database constructs are assumed. Rela-tional views are defined by queries on the underlying data-base.

The provision of a relational front-end to different data-base models has been discussed by several authors [11,12].In these works the relational schema being queried iscreated using a set of simple syntactic mapping rules fromthe target non-relational schema. The simplicity of theserules makes the translation task much easier. In databasere-engineering however, the target schema is derived fromthe source relational schema through a process called‘Schema Translation’ [13–15]. The schema translationprocess requires user interaction to recapture and re-expressthe semantics of the Domain of Discourse. Generally theresult of the schema translation process will not be describ-able as the rigorous application of a small set of simplesyntactic transformations; and the data manipulationlanguage (DML) translation process must be changed.

The task of database update translation can be describedas follows. Given a source updateU the task is to find aninformational equivalent updateU 0 over the new target data-base. ForU 0 to be deemed informational equivalent it mustbe possible to show that (see also Fig. 1):

Given,X�Rext� � Oext

where Rext and Oext are the relational and object-oriented

database extensions, andP

is the information preservinginstance level schema transformation.

That,X�U�Rext�� U 0�Oext�

whereU�Rext� is the relational database extension after theapplication of updateU, U 0 is the translation of updateU,expressed over the object database, andU 0�Oext� is theobject-oriented database extension after the application ofupdateU 0.

It has been shown by others, that for this statement to betrue the schema transformation

Pmust be reversible (total,

onto, 1:1) [16]. Therefore, before we can specify a methodfor update translation we must be able to make the assump-tion that the schema translation process is carried out in sucha fashion that its results are reversible. Fortunately, researchin schema translation has provided us with the very vehicleto meet such a rigorous requirement, “Database Transfor-mations” [2,13–15]. From the available literature on data-base transformation, several useful reversibletransformations have been documented [13,15]. Throughapplication of these transformation operators it is possibleto conclude that (1) the database schema has an equivalentinformation capacity, and (2) that given an equally expres-sive database language that an equivalent database updateexists. In the following we assume that a user has used sucha method in deriving the source schema, therefore anequivalent database update is guaranteed to exist.

The effects of database updates on the position of anobject in the class lattice have been studied by variousauthors [17,18]. Predicates are used to determine classmembership (this predicate positioning method is similarto the taxonomic reasoning method presented in Ref.[19]). If an object satisfies the predicates of a class it isconsidered a member of that class. An object in this methodcan be a member of only one class at a time, any updateviolating this principle is considered to be unsafe (a relaxa-tion of this restriction and a simple set of migration opera-tors can be found in Ref. [18]). Updates that cause anexisting object to change its membership represent a poten-tial migration. The update is accepted and the migrationoccurs if and only if a migration path has been specifiedbetween the source and destination classes. We haveadapted the work discussed in Refs. [17–19] to constructmethods suitable for the placement and migration of data-base entities resulting from the execution of a databaseupdate expressions.

In this paper we look at the process of update translationbetween the relational data model and the object-orienteddata model for database reengineering. Unlike previouswork on the provision of a relational interface to anobject-oriented database system, the schema of the OO data-base is a translation of the relational database schema. Ourcontribution is that during the process of schema translationthe semantics of relational schema are reformulated to better

X. Zhang, J. Fong / Information and Software Technology 42 (2000) 197–210198

Fig. 1. The update translation problem.

describe the semantics of the domain of discourse. Suchchanges provide additional complexity to the translationprocess yet are necessary if we are to provide the freedomfor redesign in the re-engineering process.

3. Migrating relational to OO databases

In this section, we examine migrating a legacy relationaldatabase to OO platform. This process consists of two steps:First the relational schema is mapped into an OO schema,then data is migrated to the OO platform according toschema mapping.

3.1. Mapping RDB schema into OODB schema

Mapping relational to OO schema consists of two parts:Restructuring the relational structure to form a well-definedOO static structure and deriving the dynamic method defini-tions for classes. We will discuss here how to construct thestatic structure of the OO schema. However, we do notintend to propose new schema mapping method but onlysummarize the commonly recognized schema mappingtechniques as the base for our discussion of database opera-tion translation.

A lot of work has been reported on mapping relational toOO schema. Most work considers only functional depen-dency (FD) and inclusion dependency (IND) and assumes arelational schema with only key FDs (and so in BCNF) andkey-based INDs (foreign key) as the canonical form formapping into OO schema. However, to further remove theredundancy caused by multi-valued dependency (MVD), wefurther require that the relational schema is in 4NF. Weconsider a 4NF relational schema with foreign keys as thecanonical form for mapping into OO schema. Given a rela-tional schema, considering the FDs and MVDs, it shouldfirst be mapped into 4NF before being mapped into OOschema.

When the meaning is clear from the context, relationschemes are simply called relations. A canonical RDBschema must also satisfy the following conditions: No tworelation schemes are the same. That is, we don’t support thata relation is partitioned horizontally. Given a foreign keyFof R : R�F� # S�K�; then there does not exist any otherrelation S0 whereR�F� # S0�K 0� and S0�K 0� # S�K� and Sis called the host relation (scheme) ofF. A foreign key canhave more than one host relation. Foreign keys are eitherdisjoint or the same (this restriction means that the relationalschema can only be ER-designed). Attributes which areneither prime nor involve any foreign key are called localattributes.

Our OO schema conforms to the ODMG 2.0 objectmodel. With our schema mapping defined below, the resul-tant OODB schema is a typical OODB schema with classinheritance hierarchy (simply class hierarchy). Withoutconsidering the system-defined abstract class OBJECT, anOODB schema consists of semantic class hierarchies. A

semantic class which is not a subclass of any other semanticclasses is called a base class. The static structure of a class isdefined by attributes and relationships. Given a classC, anattributeA of C can be an atomic attribute, whose value is ofliteral type, or complex attribute, whose value is an objectidentifier of some other classC0 andC0 is called a compo-nent class ofC. A relationship is defined between twoclasses and both take as values object identifiers from theopposite class. An attribute or relationship can also besingle-valued or set-valued. The resulting OODB schemais without data redundancy.

Given a canonical RDB schemakR;Dl; and a relationschemeR [ R; R� K < A; whereK andA are subsets ofattributes andK is the primary key ofR, depending on thestructure ofK, foreign keys inK are uniquely identified asinheritance, aggregation and relationship andR is uniquelymapped into a base class, a subclass, a binary relationshipbetween two classes or a component of another class:

1. K is a foreign key:R�K� # R1�K1�: This foreign keymeans inheritance: SupposeR1 is mapped into classC1, thenR is mapped into a subclassC of C1:

ClassC ISA C1{Definitions_for_Attributes_in_A}R iscalled asubclass relation(SCR).C inherits the keyKfrom C1.

2. Part ofK is a foreign key:K 0 , K andR�K 0� # R1�K1�:In ER terms,R corresponds to a weak entity. In OOterms,R represents a component of classC1, which ismapped fromR1. An object ofC1 (identified by the valueof K) aggregates several instances ofR. Two cases aredistinguished:

• If A� F; uK 2 K 0u � 1; K 2 K 0 � { A0} and R is notthe r.h.s of any IND, thenR is mapped into a set-valued attributeA0 of C1 which is literal typed:

ClassC1{attribute…; attribute setkTypeOfAlA} R iscalled a set-valued attribute relation (SAR).

• OtherwiseR is mapped into classC with K as the keyandC is a component class ofC1:

classC1{attribute…; attribute setkC1l A1};classC (keys K) {Attribute_Defs KA};R is called acomponent class relation (CCR).

3. K � K10 < K20; K10 > K20 � B; R�K10� # R1�K1�;R�K20� # R2�K2�; A� B; and R does not appear onthe r.h.s of any IND.R is a binary relationship betweenthe two entities identified byK1 andK2 and is called abinary relationship relation (BRR). Suppose thatR1 andR2 are mapped into classesC1 andC2, respectively.R ismapped into a binary relationship betweenC1 andC2:

classC1{…, relationship [Set]kC2l A1 inverseC2 <

A2};class C2{…, relationship [Set] kC1l A2 inverseC1:A1};Note that in the above notation, depending on

X. Zhang, J. Fong / Information and Software Technology 42 (2000) 197–210 199

the cardinality of the relationship,A1(A2) may be set-valued.

4. OtherwiseR is mapped into a classC. In ER terms, rela-tions that fall into this category include relations thatrepresent

• Entity whereK does not contain any foreign key.R iscalled aentity class relation(ECR). K becomes thekey of C and the local attributes ofR are mapped intothose ofC.

• Binary relationship with local attributes whose keystructure is the same as that in (3) butA ± f or n-ary relationship�n . 2� with or without local attri-butes. R is called a relationship class relation(RCR). An object inC aggregates objects of the invol-ving classes.

Foreign keys of SCR, CCR, ECR and RCR that aredisjoint with primary keys are mapped into relationshipsbetween the corresponding classes. Also note that in case(2) the existence dependency of a component object ofC ona composite objectC1 is not automatically supported by theODMG data model and the application should enforce it.Together with mapping relational constructs to OO staticstructure, methods are established on classes to maintainthe key of classes. A constructor is created for each classwhich create objects of the class, with all the property valuessupplied.

Example 1. A sample relational schema is given belowand used for our later discussions:Person(ssn, name, drive) Person�drive� # Car�license#�

Per_Hobby(ssn, hobby) Staff�teach� # Course�cno�

Staff(ssn, staff_id, title, teach) Staff�ssn� # Person�ssn�

Course(cno, title) Person_Dept[ssn]# Person[ssn]

Car(license#, model) Person_Dept[code]# Department[code]

Department(code, location)

Person_Dept(ssn, code)

Primary keys are underlined. Under the schema mappingdiscussed,Person, Course, Car andDepartmentare ECRs,Per_Hobbyis an SVR andStaffis an SCR.Person_Deptis aBRR. The mapped OO schema is as below.

class Person (integer ssn, string name, set(string)hobby,Department dept)class Staff: Person (integer staff_id, string title,set(Course) teach);

class Course (integer cno, string title, Staff taught_by);class Car (integer license#, string model);class Department (string code, string location, set(Staff)has)

3.2. Data migration

According to the schema mapping, relational data shouldbe reorganized under the OO schema. Relational schemauses attribute values to represent the association betweendata. In the OO model data values are organized into objectsand objects are related by direct object identifier references.Non-foreign key attribute values become literal attributevalues of objects or elements of collections. Foreign keyvalues establish the relationship between objects.

Migrating data from the relational to OO platformconsists of unloading relational data, restructuring anduploading data to the OO platform. We will not go intothe detail process but only give the data migration rules sothat we have an overall picture of data migration [20]. Weshould first populate those classes which are mapped fromECR, and then subclasses, component classes, classesmapped from RCR and finally establish the relationshipbetween classes.

A problem that deserves special attention is that in reor-ganizing data, data of a relationr�R� may not necessarilybecome data of its corresponding classC, but may also bemapped into data ofC‘s subclasses. This is due to the differ-ence for representing inheritance: In the relational model,both structure and data are inherited. In the OO model,however, only structure is inherited. Where data should beplaced in the class hierarchy depends on the lowest positionof the key in the IND graph. This also causes the objectmigration problem in update operation translation, whichis detailed in Section 4. When database migrationcompletes, a table is formed recording the schema mappinginformation. For a given relation scheme, its type, mappedOO construct etc are recorded.

4. Object migration in class hierarchy

As stated before, in the relational model, semantic asso-ciation between data is expressed as constraints betweendata values. To be more specific, foreign keys are used toexpress inheritance, aggregation and relationship betweenentities (an entity consists of a set of attributes and is thebasic unit for organizing information). In the OO model,attribute values are organized into objects and the semanticassociations between objects, inheritance, relationship oraggregation, are directly expressed as inheritance or refer-ences between objects by OIDs. In the relational model,update operations insert new data value, delete existingdata value or modify data values. Semantically such treat-ment may really mean corresponding operations on attribute


values, but it may also mean treatment to the associationbetween values.

Example 2. Referring back to the relational schema inexample 1 with the sample data shown on the left, accordingto the schema mapping, the corresponding OO databasestate is shown on the right.

When we insert a new tuple into relationStaff:

insert into Staff values (‘ss1’, ‘s1’, ‘AssProf’, ‘cs01’);

The foreign key Staff�ssn� # Person�ssn� is interpreted asinheritance. Insertion of this new tuple intoStaffmeans thatboth the attributes and their values of the tuple inPersonareinherited. On the OO side, as structural inheritance isdirectly supported, but data is directly organized under theclass structure, the corresponding database state is:

To bring the OO database from the previous state to thecurrent state, a set of operations is needed, of which the mostprominent one that the objectp1 of classPersonshouldmigrate to classStaffand becomes objects1 with the addi-tional data values supplied.

Example 3. Consider a more complicated example.Referring to Example 1, given consistent RDB and ODBstates shown.

The relational database state after the UPDATE operation

is shown on the left. According to the mapping definedbetween the relational and OO schemas, the correspondingODB state is shown on the right. To bring the previous ODBstate to the current state, objectp1 of class Personmigratesto class Staff and becomes objects2; On the other hand,objects1 of class Staffmigrates to class Person and gain anew identityp2. With this example we also want to show

that when an object is migrated, although its membershipclass is changed, its relationship with other classes isretained. In the above example, whenp1 is migrated fromclassPersonto classStaff, its bidirectional relationship withobject d1 is kept and so is the case with the migration ofobjects1.

The problem of object migration has been examined byseveral researchers [17,21]. The actual migration operationhas been discussed by Li and Dong [18] in some detail.

Three goals for migration are defined: identity preservation,behavior transition and information conservation. However,most current available ODBMSs are statically typedsystems and dynamic migration of objects between objectsis strictly prohibited. In this respect, we implement theobject migration functionmigrate( ) with available objectoperations. In a statically-typed ODBMS, themigrate( )function assign the object a new OID. Depending on thedirection of the movement, from superclass to subclass orvice versa, the object keep its information and behavior ornot.


An UPDATE operation on the relational database

UPDATE Staff SET ssn� ‘ss2’ WHERE ssn� ‘ss1’

According to the ODMG object model, we will makethe following assumptions about objects in the objectbase. Each object has a lifetime identifier (OID) toidentify itself. Names are designated by programmersto refer to particular objects. Moreover, the ODL inter-face providesconstructor and destructor to create anddelete objects explicitly, which is implicitly inherited byall user-defined object definitions. We adopt a Java-like

syntax for constructor and methoddelete() for destruc-tor. For example, withPerson p� new Person� � wedeclare an objectp of class Person and create an objectnamedp uninstantiated. Whereas withp.delete( )objectp is deleted.

With the basic operations, the functionmigrate�x;C;C1�migrate objectx, initially a member of classC, to aninstance of classC1. If x is not in classC, return a null


object, otherwise if migration succeeds, return the new OIDfor the object.

Begin

if x is not an instance ofC return (C1) null;C1 p� new C1��;if(C1 is a subclass ofC)

for each attributeai of C p:ai � x:ai;

else //C1 is a superclass ofC

for each attributeai of C1 p:ai � x:ai;

Redirect all references tox to p;x.delete( );return(p);

End

The object operations corresponding to the relationalupdate operation in Example 2 are shown.

Other basic object operations include:

selectx from all Cx where x:K � k; //Retrieve objectsfrom the class hierarchy rooted atC:Establish_Relationship_between_Objects_on foreign_key_K(x, y, Fg)Break_Relationship_on_foreign_key(x, y, Fg)

5. Update operation translation from relational to OOdatabases

The original relational database is considered the view onthe migrated OODB. Update operations submitted againstthe original relational database should be translated intoequivalent operations on the OODB.

We will use SQL data manipulation operations asthe representative for relational operations. Withoutconsidering operations involving cursors, the SQL

update2 operations we will discuss includeINSERT,UPDATE-(searched), DELETE(searched). Translating arelational update statement consists of locating theobjects to be manipulated (except INSERT) and check-ing the integrity constraint.

5.1. Integrity constraint enforcement

The SQL standard provides methods for defining integrityconstraints, including domain constraints, base table andcolumn constraints and general constraints. Most RDBMSsdirectly support base table constraints which include key,foreign key and check constraint. However, support for arbi-trary constraint checking is sadly lacked in many OODBMSproducts. Some have proposed to enforce constraints byconstraint methods defined on classes.

To ensure that the resultant OODB be in a state that can bemapped into a relational database state, the relational updateoperations and thus the translated OO operations should

enforce the integrity constraints defined on the original rela-tional schema. We assume that there are key and foreign keyconstraints defined on the original relational schema.

Primary key constraint:Primary key constraint guar-antees the uniqueness of a primary key value in a relation. Toenforce primary key constraint we create an index for eachrelation in the relational schema. This index stores key andassociated OID values for all the tuples currently representedin the database, and provides methods to insert, delete andfind entries in the index.

Foreign key constraint:Foreign key constraint ensuresthat all foreign keys identify a tuple in the host relation.Using the index created for each relation, we can findthe OID for each fully defined foreign key or updatedforeign key in a relational tuple. The bidirectionality ofassociations make the enforcement of foreign keys particu-larly easy.


Selectp1 from Personp1 wheressn� ‘ss2’ ; //migrate(p1, Person,s2, Staff)Staff s2� migrate(p1, Person, Staff) Staffs2� new Staff� �;s2:title � s1:title; s2:ssn� p1:ssn;s2:teach� s1:teach; s2:name� p1:name;p1:dept:people� p1:dept:people2 p1 1 s2 s2:dept� p1:dept;p1.delete();

Selects1 from Staffs1 wheressn� ‘ss1’ ; //migrate(s1, Staff, Person)Personp2� migrate(s1, Staff, Person); Personp2� new Person��;s1:dept:people� s1:dept:people2 s1 1 p2; p2:ssn� s1:ssn;s1.delete(); p2:name� s1:name;

p2:dept� s2:dept;

2 To distinguish update operation and the SQL UPDATE statement, weuse upper-case letters for the latter.

5.2. INSERT operation translation

Given a relational INSERT operation which supplies a setof attribute values for a new tuple:

INSERT INTO r(column-commalist)VALUES (value-commalist)

using default values and NULL values we can expandthe value-commalistto contain data for the entire tuple,producing an INSERT operation of the followinggeneral form:

INSERT INTO r�R� VALUES (tuple)

To map this relational INSERT operation into corre-sponding OO operations,tuple is first checked against theprimary key and foreign key constraints onr�R�: Translationproceeds only whentuple satisfies the constraint checking.Insertion of a new tuple intor�R� produces different opera-tions on the OO side depending on the type ofR, asdescribed in the algorithm below.

Algorithm 1. Translate Relational Single-tuple INSERTto object operations.Input: r�R� // relation and its scheme,supposeR� K < F < A; where K, F and A are primarykeys, foreign keys disjoint withK and local attributes,respectively

ind(r) // primary key index forrtuple // the data to be inserted

Output: TRUE if a valid sequence of object operations hasbeen formed otherwise FALSE.

Begin

Checkind(r) for primary key values ofr�R�;if( tuple violates the primary key constraint) returnFALSE;for each foreign key in K : Ki # K; r�Ki� #ri �Ki�; 1 # i # m do

Supposeri �Ri� is mapped into classCi;select xi from all Ci xi where xi:Ki � tuple�Ki�; //Check for foreign key constraintif(xi does not exist) return FALSE;

endforfor each foreign key in F : Fi # F; r�Fi� #ri 0�Ki 0�; 1 # i # n do

Suppose thatri 0�Ri0� is mapped into classCi 0;selectxi 0 from all Ci 0 xi 0 wherexi 0:Ki 0 � tuple�Fi�; //Check for foreign key constraintif(xi 0 does not exist) return FALSE;

endfor

if(R is ECR, SCR, RCR or CCR and is mapped into aclassC) {p� new C� �;for (eacha [ A) do p:a� tuple�A�;for (each foreign keyFi # F) do

Find the corresponding relationship�fi; fi 0� onC andCi 0

from the mapping table;Establish_Relationship_on_foreign_key�p; xi 0; fi; fi 0�;endfor}Switch(type ofR) {case ECR�m� 0� :for(eachk [ K) do p:k � tuple�k�;case CCR, SAR�m� 1� :if(R is CCR)

Establish_aggregation�x1;p; tuple�K 0��;else

Establish_aggregation�x1; tuple�K 2 K 0�; tuple�K 0��;case RCR, BRR�m $ 2� :if(R is a BRR){

retrieve the relationship pair�k1; k2� from schemamapping;Establish_relationship�x1; k1; x2; k2�;}else {

for�i � 1; i # m; i 1 1� dop:ai � xi;

}case SCR�m� 1� :x1 must be an object of classC1 which is the directsuperclass ofC;migrate�p; x1; tuple� // x1 obtain the identityp withmore attribute values of tuple.

end Switch;Insert entry intoind(r) for the primary key oftupleandp;return TRUE;

End

Example 4. When inserting a tuple into the relationPerson_hobby

insert into Person_hobby values (‘ss3’, ‘tennis’)

Person_hobbyis an SVR and its host relation isPerson. Thecorresponding OO operations are:

selectp from all Personp where p:ssn� ‘ss3’;p:hobby� p:hobby1 ‘tennis’;


Example 5. Given an INSERT operation on relationStaff

INSERT INTOStaffVALUES(‘ss2’, ‘AssProf’, ‘cs01’)

This will cause a new object created in Staff and the objectof class Person whose key is ‘ss2’ migrate to class Staff. TheOO operations are:

SELECTp FROM all Person WHERE p:ssn� ‘ss2’;SELECTc FROM all Course WHERE c:cno� ‘cs01’;x� new Staff�‘ss2’; ‘AssProf’�;Establish_association(x, c, teach, taught_by);migrate(x, p)

5.3. DELETE operation translation

The SQL standard provides positioned DELETE, whichdeletes the row pointed to by the current cursor pointer, or asearched UPDATE, which may result in the deletion ofseveral rows. We will focus on the deletion of a singletuple, which takes the form

DELETE FROMr�R� WHERE K � a

whereK is the primary key ofRanda is a valid value inK‘sdomain.

As BRRs and SVRs do not appear on the r.h.s. of anyINDs, deletion on BRRs and SVRs are unrestricted anddeletion of a tuple of such a relation does not correspondto the deletion of an object on the OO side but only breakingthe relationship between two objects or removal of anelement from a collection. Deletion of a tuple of a ECR,CCR or SCR must be first checked against the foreign keyconstraints defined and it is mapped into deletion of anobject of the corresponding class. For SCR, deletion of atuple may also cause object migration along the class hier-archy. A detailed translation for single tuple DELETEoperation is described in Algorithm 2.

Algorithm 2. Translate Relational Single-tuple DELETEto object operations.Input: r�R� // relation and its scheme,supposeR� K < F < A; where K, F and A are primarykeys, foreign keys disjoint withK and local attributes,respectively

ind(r) // primary key index forra // the primary key value of the tuple to be deleted


Begin

for(each foreign keyFi of tableri whose r.h.s. isR) do //Check for foreign key constraint

if (there is anyri �Fi� � a) return FALSE;

endforSwitch(type ofR) do

case ECR, SCR:

Suppose the class corresponding tor is C;selectx from Cx wherex:K � a; // x must be an objectof C but not subclasses ofCif R is an SCR

migrate(x, superclass_of_C);

else

Break relationships withx;x.delete(); // Oncex is deleted, references tox are set tonil.

case CCR, SVR:

Suppose the host class isC1 and for CCR suppose theclass corresponding tor�R� is C;selectx1 from all C1 x1 wherex1:K1� a�K1�;if(R is a CCR) {

selectx from C x wherex:K � a; // x must be an objectof C but not subclasses ofCbreak relationship withx;x1:p� x1:p 2 { x} ; // p is the 1:maggregation attribute,1:1 aggregation?x.delete( );

}else

x1:p� x1:p 2 A;

case BRR, RCR:

for each foreign key inK : Ki # K; r�Ki� # ri �Ki�;1 #i # m do

Supposeri �Ri� is mapped into classCi;selectxi from all Ci xi wherexi:Ki � a�Ki�; // Check forforeign key constraint

endforif(R is RCR and is mapped into a classC) {

Suppose the corresponding attributes arep1;p2;…; pm;selectx from C x where ,x:p1� x1 andx:p2� x2 and…x:pm� xm;for (each foreign keyFi # F) do

Find the corresponding relationship�fi; fi 0� on C andCi 0

from the mapping table;Break_Relationship_on_foreign_key�x; xi 0; fi; fi 0�;Endforx.delete( );

}else {

retrieve the relationship pair,�k1; k2� from schemamapping;


Break_relationship�x1; k1; x2; k2�;}

end Switch

Delete the entry fromind(r) for the primary key ofa;return TRUE;

End

Example 6. In the example relation schema, relationstaffis a SCR and contains a foreign key referencing cno ofPerson. To delete a tuple from staff

Delete from Staff where ssn� ‘ss3’

On the OO side:

select OID intos1 from Staff where ssn� ‘ss3’;s1:teach:taught_by� nullmigrate(p1, Staff, Person);

5.4. UPDATE operation translation

We consider an UPDATE operation which sets attributepof the tuplet identified by the primary key valuea the newvalueval:

UPDATE r�R� SETp� val WHEREK � a; whereR�K < F < A

If p [ A; then settingp to a new value will not violate theprimary key and foreign key constraints and, on the OOside, involves only locating and setting the piece of datato the new value. Ifp [ K or p [ F; setting p a newvalue must first check against the primary key and foreignkey constraints and may change the relationship betweenobjects or even cause object migration. A general translationprocess is summarized in Algorithm 3.

Algorithm 3. Translate Relational Single-tuple UPDATEto object operations.Input: r�R� // relation and its scheme,supposeR� K < F < A; where K, F and A are primarykeys, foreign keys disjoint withK and local attributes

ind(r) // primary key index forra // the primary key value of the tuple to be deletedp // the attribute to be updated


Begin

if(a is not in ind(r)) return FALSE;if �p [ K� {

// Check for primary key constraintSuppose the new value formed forK by val is k_val;Searchind(r) for the violation of primary key constraintof k_val;

if primary key constraint is violated return FALSE;if(R is a ECR, SCR, CCR or RCR) { //r is mapped intosome classSupposer�R� is mapped to classC;selectx from C x wherex:K � a;if x is not found return FALSE; // the tuplet wheret�K� � a is referred to by ISA foreign keys

if there is any set-valued attribute which takes as itsvalue a non-empty setreturn FALSE; //t is referred to by Component foreignkeys

}

}

else if (R is a ECR, SCR, CCR andp [ F) {

Supposer�R� is mapped to classC;selectx from all C x wherex:K � a;Supposep [ Fi : r�Fi� # ri �Ki�� and the new valueformed forFi by val is f_val;search ind(ri 0) for the entryf_val;if not found

return FALSE;

select x1 from all Ci 0 x1 wherex1:Ki � x:Fi; // oldvalue forFi;selectx2 from all Ci 0 x2 wherex2:Ki � f_val; // newFivalue formed byvalBreak relationship betweenx andx1 onFi;Establish relationship betweenx andx2 onFi;return TURE;

}switch (the type ofR) do

case ECR, SCR:

if,�p [ A� {

selectx from all C x wherex:K � a;x:p� val;

}else if�p [ K�if (R is a ECR)

x:p� val;

else {

Supposer�K� # r1�K� andr1 is mapped into classC1;selectx1 from C1 x1 wherex1:K � k_val;if x1 not found return FALSE;migrate�x1;C;C1�;migrate�x;C1;C�;}

}


case CCR:

SupposeK � K1 < B; where r�K1� # r1�K1�; r1 ismapped to classC1 with aggregation attributeagg;

selectx1 from all C1 x1 wherex1:K1� a�K1�;if �p [ A or p [ B�x:p� val;

else if�p [ K1� {

selectx2 from all C1 x2 wherex2:K1� k_val�K1�;if x2 not found return FALSE;x:p� val;x1:agg� x1:agg2 { x} ;x2:agg� x2:agg1 { x} ;

}case SVR: //F � f;A� fSupposeK � K1 < B; r�K1� # r1�K1�; r1 is mappedto classC1 with aggregation attributeagg;

selectx1 from all C1 x1 wherex1:K1� a�K1�;if �p [ B�x1:agg� x1:agg2 { a�B�} 1 { val} ;

else { // p [ K1

selectx2 from all C1 x2 wherex2:K1� k_val�K1�;if (x2 cannot be found)return FALSE; // If the foreign key constraint onK1 isviolatedx1:agg� x1:agg2 { a�B�} ;x2:agg� x2:agg1 { a�B�} ;}case RCR:

SupposeK � K1 < K2 < …< Km; r�Ki� # ri �Ki� andri is mapped to classCi �i � 1;…;m�;Suppose the attribute referring toCi is ppi, i � 1;…;m;

if �p [ A�x:p� val;else if�p [ F� {

// However, relationship may between relationships andsox:pp1:pp10:pp10…pp1000 0 � a�K1�select x from all C x where x:pp1:K1� a�K1� andx:pp2:K2� a�K2�… andx:ppm:Km� a�Km�;

Supposep [ Fi : r�Fi� # ri �Ki� and ri is mapped toclassCi;selectx1 from all Ci x1 wherex1:Ki � x:Fi;selectx2 from all Ci x2 wherex2:Ki � f_val;break_ relationship�x; x1�;establish_relationship�x; x2�;}else {// p [ K

Supposep [ Ki;selectxi from all Ci xi wherexi:Ki � k_val�Ki�;x:ppi� xi;

}case BRR: //F � f;A � fSuppose K � K1 < K2; r�Ki� # ri �Ki�; and ri ismapped to classCi, i � 1;2Suppose, without losing generality,p [ K1;selectx1 from C1 x1 wherex1:K1� a�K1�;selectx2 from C2 x2 wherex2:K2� a�K2�;selectx10 from all C1 x10 wherex10:K1� k_val�K1�;break_relationship�x1; x2�;establish_relationship�x10; x2�;end SwitchDelete the entry fromind(r) for the primary key ofa;return TRUE;

End

Example 7. Update the key value of a tuplet of CCRmeans that cut the old aggregation between the compositeobject and the component objecto (corresponding tot) andestablish the new aggregation relationship and modify thekey value ofo if necessary.


Fig. 2. Process for SQL transformation to OSQL.

Update Person_Hobby setssn� ‘ss2’ wheressn� ‘ss1’andhobby� ‘football’

The OO correspondent is:

select OID into:p1 wheressn� ‘ss1’ ;select OID into:p2 from all Person wheressn� ‘ss2’ ;p1:hobby� p1:hobby2 { football} ;/* Cut the old asso-ciation */p2:hobby� p2:hobby1 { tennis}

6. Prototype of mapping SQL to OSQL

To translate transaction from RDB to OODB, we canapply symbolic transformation technique which containssyntax translation and semantic translation for SQL. Forsyntax translation, SQL statement will be modified. Forsemantic translation, navigational syntax will be modified.For example, the join operation in RDB can be replaced byclass navigation (association) in OODB. Transaction ofsource language are built in our model. We navigate thetransaction graph (TG) of SQL and then map it to the TGof OSQL (object-oriented SQL) [22] with reference to theintermediate result of schema translation. Semantic rules(transformation definition) for transaction transformationfrom source language to target language will be applied.Then, transaction of target language will be produced. Theoutput transaction OSQL should be syntactic and semanticequivalent to the source SQL.

The OSQL, the object-oriented extension to SQL, allows

data retrieval using path expressions, and data manipulationusing methods. In transaction transformation, a syntax-directed parser converts the input OSQL into multi-waytrees. The transformation process is then performed, basedon the subtree matching and replacement technique. Theprocess of SQL to OSQL transformation is given in Fig. 2.

After schema mapping from RDB to OODB, we cantransform RDB transaction (SQL), to OODB transaction(OSQL). The nature of the query transactions of the SQLand OSQL are different. SQL is to navigate from relation torelation through foreign key. OSQL is to navigate from classto class through OID. The concept of database navigationcan be used to verify the equivalence of an SQL and itstranslated OSQL statement. To ensure the database state ispreserved after transaction translation, the target recordsaccessed by the OSQL statements must be the same as theones obtained by the SQL statements. The concept of anavigation statement can show the access paths of SQLand OSQL statements.

For example, the SQL statement for the transaction “Getthe names of the courses taken by student who are major inComputer Science” is shown in Fig. 3.SQL transactions:

Select Course-name from Course, Course-register,Student where Course.Course-no� Course-register.-Course-no and Course-register.Student#� Student.Stu-dent.Student# and Major� “ComputerScience”Insert Course-register (Student_no, Course_no) values(124, ‘CS101’)

Its relational schema is:

Relation Student (Student_no, Major)Relation Course (Course_no, Course_name)Relation Course-register (Student_no, Course_no)

Its navigation statement is shown in Fig. 3.

Course.Course-no.[Course-register.Student#.[Student.-Major.ComputeScience.[Student#].[Course-no].Course-name3


Fig. 3. Navigation access paths of SQL.

Fig. 4. Navigation access path of the translated OSQL. 3 Refer to Appendix A Navigation Statement.

To verify the equivalence between the SQL and its trans-lated OSQL statement, we can show that their target data arethe same by expressing them in the same domain of naviga-tion statement. The navigation statements present their data-base access paths. After deriving the nested OSQLtransaction and the nested SQL transaction along withtheir navigation statements, we can show them to be equiva-lent. For example, for the SQL transaction in Fig. 4, itsequivalent OSQL transaction with TG in Fig. 4 can beshown below:

The translated OODB schema is:Class Student Class Course

Attribute Attribute

Major: string Course_no: integer

Student_no: integer Course_name: string

Course-taken: set of Course Course-registered: set of student

End End

Translated OSQL transactions:

Select Course.taken.Course-name from Student whereMajor� “ComputerScience”Select * from Student where Student_no� 124 into:OIDstudent

Update Course set Course-registered� Course-registered1 :OIDstudent

Select * from Course where Course_no� ‘Cs101’ into:OIDcourse

Update Student set Course2 taken� Course2 taken1OIDcourse

Its navigation statement is:

Student.Major.ComputerScience.Course-taken.Course.-Course-name

7. Concluding remarks

In this paper we have studied mapping relational updateoperations to their OO equivalents, which includeUPDATE, INSERT and DELETE operations. Relationalupdate operation translation from relational to OO facesthe touchy problem of transformation from a value-basedrelationship model to a reference-based model and main-taining the relational integrity constraints. Moreover, witha relational database where inheritance is expressed as attri-bute value subset relationship, changing of some attributevalues may lead to the change of the position of an object inthe class inheritance hierarchy, which we call object migra-tion. Considering all these aspects, algorithms are givenmapping relational UPDATE, INSERT and DELET opera-tions to their OO correspondents. The continuation of this

research project will be to convert RDB programs to OODBmethods.

Appendix A. Navigation statement

A navigation statement is a function which maps one setof addresses (departure point) into another set of addresses(arrival point). We can use these departure and arrival pointsto model the navigation path of an object-oriented model asfollows [23,24]:

Let A be a set of addresses,N be a set of data names andVbe a set of atomic values. Suppose thatA, N and V aredisjoint sets. We consider the content of a database as a“database content” that is a collection of addresses, datanames and data values such that CON# A × N × �A < V�:A database content contains the tripleka1;n;a2l or ka;n; vl:The former means that at addressa1, there is datum withnamen and a pointer leading to data at addressa2. The lattermeans that at addressa, there is a datum with namen andatomic valuev. For example, for the following OODBschema:

Class COURSE (Course-no: integer, Course-name:string, Course-register: set (STUDENT))Class STUDENT (Student-no: integer, Major: String,Course-taken: set (COURSE))

Its OSQL query graph and navigation statement can beshown as in Fig. 1A. The following data are representationsof the database content for the database CON1:

ka1; student; a10l; ka1; student;a11l; ka1; student;a12l;ka1; student; a13l; ka10; student-no;a123l;ka11;major; computer-sciencel; ka12; course-taken; a2l;ka13; student-no;a124l; ka2; course;a21l;ka21; course-no;CS101l

Let Sbe the set of navigational statements. We denoteiSithe semantics of the statements. The functioniSi maps a setof addresses into another set of addresses. The set of argu-ments of the navigational statements will be the departurepoints, and the result will be the arrival points.iSi dependson particular database content CON, and is regarded as amapping ofiSi : r�A� × CON! r�A�; where CON is a setof all possible database contents, i.e. from one address of the


Fig. 1A. Navigation access path of the OODB.

database content, we can navigate to another address withinthe database content through pointers.

Let us consider a navigational statements [ S; whereS� S1;S2;…;Sk: If the statementS applied to the set ofaddressesA0 # A; then we can define a trajectory of navi-gation in a sequence of address sets:kA0;A1;…;Akl; whereA1 � iS1i�A0�; A2 � iS1·S2i�A0�; A3 � iS1·S2

…Ski�A0�: Forexample, Table A.1 contains the navigation statement repre-sentations for some transactions in Fig. 1A.

For sets of navigation statements, ifS is a navigationstatement containing expressions which are equivalent tosets of expression, we can group them together in oneexpression. For example, the navigation statements for“get course numbers of the courses taken by student withstudent#� 123 or 124” isOSQL statement Navigation statementSelect Course-taken.Course-no from Student

Student.Student#.(123,124).Course-taken.

Where Student#� 123 orStudent#� 124

Course.Course-no

For nested navigation statements, an inner statementS1

can be considered a set of values placed at addresses whichconstitute the arrival points of navigation according toS1.After evaluating the inner navigation statement, the outernavigation can be evaluated. For example, the navigationstatement of “Get the student number of students who havethe same major as the student with student number 123” is

Student.Major.[Student.123].Student#

References

[1] J. Frong, P. Chitson, Query translation from SQL to OQL for databasereengineering, International Journal of Information Technology 3 (1)(1997) 83–101.

[2] C.J. Date, H. Darwen, Guide to the SQL Standard: A User’s Guide tothe Standard Language SQL, 4, Addison-Wesley, Reading, MA, 1997.

[3] R.G.G. Cattell (Ed.), The Object Database Standard: ODMG 2.0Morgan Kaufmann, Los Altos, CA, 1997.

[4] V.M. Markowitz, A. Shoshani, Representing extended entity-relation-ship structures in relational databases: a modular approach, ACMTODS 17 (3) (1992) 423–464.

[5] W. Meng, C. Yu, W. Kim, G. Wang, T. Pham, S. Dao, Construction ofa relational front-end for object-oriented database systems, ICDE’93,1993, pp. 476–483.

[6] X. Qian, L. Raschid, Query interoperation among object-oriented andrelational databases, ICDE’95, 1995, pp. 271–278.

[7] C. Yu, Y. Zhang, W. Meng, W. Kim, G. Wang, T. Pham, S. Dao,Translation of object-oriented queries to relational queries, ICDE’95,1995, pp. 90–97.

[8] F. Bancilhon, N. Spyratos, Update semantics of relational views,ACM Transactions on Database Systems 6 (4) (1981) 557–575.

[9] U. Dayal, P.A. Bernstein, On the correct translation of update opera-tions on relational views, ACM Transactions on Database Systems, 7(3) (1982) 381–416.

[10] A.M. Keller, The role of semantics in translating view updates, IEEEComputer January (1986) 63–73.

[11] W. Meng, C. Yu, W. Kim, theory of translation from relationalqueries to hierarchical queries, IEEE Transactions on Knowledgeand Data Engineering 7 (2) (1995) 228–245.

[12] A. Rosenthal, D. Reiner, Querying Relational Views of Networks,Querying Processing in Database Systems, Springer Verlag, 1984,pp. 107–124.

[13] J.-L. Hainaut, C. Tonneau, M. Joris, M. Chandelon, Transformation-based database reverse engineering, ERA’93, 1993, pp. 364–375.

[14] S. Dumpala, S. Arora, Schema translation using the entity-relation-ship approach, Entity-Relationship Approach to Information Model-ing and Analysis, 1983, pp. 337–356.

[15] A. Rosenthal, D. Reiner, Tools and transformations—rigorous andotherwise—for practical database design, ACM TODS 19 (2) (1994)167–211.

[16] R. Hull, Relative information capacity of simple relational schemata,SIAM Journal of Computing 15 (3) (1986) 856–886.

[17] M.E. El-Sharkawi, Y. Kambayashi, Object migration mechanisms tosupport updates in object-oriented databases, in: N. Rishe, S. Navathe,D. Tal (Eds.), Databases: Theory, Design and Applications, ComputerSociety Press, Silver Spring, MD, 1991, pp. 73–93.

[18] Q. Li, G. Dong, framework for object migration in object-orienteddatabases, Data and Knowledge Engineering 13 (1994) 221–242.

[19] S. Bergmaschi, C. Sartori, On taxonomic reasoning in conceptualdesign, ACM TODS 17 (3) (1992) 385–422.

[20] J. Fong, Converting relational to object-oriented database, SIGMODRECORD 26 (1) (1997) 53–58.

[21] T.W. Ling, P.K. Teo, Object migration in ISA hierarchies,DASFAA’95, 1995, pp. 292–299.

[22] J.G. Hughes, Object-Oriented Database, Prentice-Hall, EnglewoodCliffs, NJ, 1991, pp. 1 pp. 153–154.

[23] K. Subieta, Navigational facilities for relational databases, Informa-tion Systems 8 (1993) 29–36.

[24] K. Subieta, High-level navigational facilities for network and rela-tional databases, Proceedings of the Ninth International Conferenceon Very Large Databases, October 1993.


Table A.1Navigation statement of transactions

Transaction function Navigation statement

Get all object occurrence of student StudentGet Student-no of all student Student.Student-noGet Course-no of student withstudent2 no� 123

Student.Student-no.123.Course-taken.Course.Course-no

Documents

Translating update operations from relational to object-oriented databases