You are on page 1of 11

Information and Software Technology 44 (2002) 41±51

Translating object-oriented database transactions into relational

Joseph Fong*
Computer Science Department, City University of Hong Kong, Tat Chee Avenue, Kowloon, Hong Kong, People's Republic of China
Received 14 November 2000; revised 31 August 2001; accepted 24 October 2001

In this paper, we present methods of translating transactions from object-oriented database (OODB) to relational database (RDB). The
process involves schema mapping in data de®nition language and transaction translation in data manipulation language. They include scheme
de®nition, data query and transaction operation of insert, update, and deletion. We also discuss the object-oriented features in OODB
operations that are not supported by RDB, such as class hierarchy, class composition hierarchy, and set attribute, and provide a general
solution to realize those mechanisms by traditional relation operations. The result of the transaction translation can be applied into adding
object-oriented interface into relational database management system and to the interoperability between OODB and RDB. q 2002 Elsevier
Science B.V. All rights reserved.
Keywords: Object-oriented database; Relational database; Object-relational database; Multidatabase; Transaction translation; Interoperability

1. Introduction order to keep the semantic of inheritance and to simplify the

mapping, we propose a different way. Our way is, in addition
The requirement of interoperability of autonomous data- to mapping each class in a class hierarchy to a table, to extend
bases leads to the multidatabase system, which consists of the attributes of superclass tables to all their subclass tables
homogenous or heterogenous databases. In heterogenous according to inheritance rules. Our approach on the trans-
multidatabase system, the translation between operations action translation from OODB to RDB follows after the
of databases with different data models is critical [1]. As schema translation from OODB to RDB. Our model on the
relational database (RDB) is the dominating database appli- interoperability of relational and OODBs is described in Fig. 1.
cation and object-relational database (ORDB) maybe the The model in Fig. 1 is equivalent to build an object-
next generation database to meet advanced business require- oriented interface on top of a relational database manage-
ments, it is necessary and practical to search for a solution of ment system (RDBMS). In the model, the Gateway
transaction translation. translates OSQL [11] to relational SQL.
There are methods of transaction translation between The following sections are arranged in this way. Section 2
object-oriented database (OODB) and RDB, and each direc- describes relational data model and object-oriented data
tion re¯ects, based on the architecture of a multidatabase model. Section 3 discusses transaction translations and
system, a certain system function. Meng [2] discussed the gives translation mappings and algorithms for each typical
transaction translation from RDB to OODB based on a database operation. The operations include scheme de®ni-
schema translation from OODB to RDB. Keim [3] and Yu tion, data insertion, data query, data update, and data
[4] discussed the query translation from OODB to RDB based deletion. Section 4 gives a real world case study. Section
on a schema translation from RDB to OODB. Zhang and 5 concludes the paper.
Fong [5,6] provided techniques in translating structural
query language (SQL) to object-oriented query language
(OSQL) and OQL. Much work [7±9] were done on query 2. Data model
translation between RDB and OODB. Blaha [10] proposed
four ways to handle inheritance by use of relation tables. In The data models described in this section contain the
standard features of relational data model [12] and object-
* Tel.: 1852-2788-8580; fax: 1852-2788-8614. oriented data model. We also establish a correspondence
E-mail address: (J. Fong). between their parallel counterparts with notations.
0950-5849/02/$ - see front matter q 2002 Elsevier Science B.V. All rights reserved.
PII: S 0950-584 9(01)00211-7
42 J. Fong / Information and Software Technology 44 (2002) 41±51

state. Objects with the same attributes and behaviors are

grouped in a class as instances of that class.
Class de®nes attributes and methods for the state and
behavior of a group of similar objects. With inheritance,
classes are organized in class hierarchies such that subclass
inherits attributes and methods from its superclasses, and
may re¯ect generalization or specialization relationship
semantics between superclass and subclass. These seman-
tics are presented in database operations.
Attributes in the classes may be divided into atomic
attribute, aggregate attribute (or composite attribute),
Fig. 1. Research model.
and set attribute. Atomic attribute is de®ned as a basic
type, such as integer, boolean, and string. Aggregate attri-
bute is de®ned as a stored OID 1 in a class. Stored OID is
2.1. Relational data model an aggregation attribute in an object of a class which
references (pointing) to an OID stored in an object of
We de®ne a RDB as a 3-tuple: RDB ˆ kR; T; OPr l; another class. The aggregate attributes may form a class
where composition hierarchy in a directed graph. Set attribute is
de®ned to have multiple values of atomic type or aggre-
R ˆ {RuR is a relation scheme de®ned in RDB} gate attribute. We regard OID as the value of an implied
T ˆ {TRuTR is a relation (set of tuples) having R as its atomic attribute.
scheme} Each OODB operation may contain mechanisms not
OPr ˆ {opruopr is a relational database operation} supported by RDB. For example, range clause in query
may denote a class or a group of classes in a class hierarchy,
Relational data model is in the form of two-dimensional
and target clause may contain path expression to navigate
tables of relations. Each relation has a scheme de®nition and
through composition hierarchy.
tuples. Relation scheme determines the structure of a rela-
tion by de®ning a set of attributes, and each tuple is an
2.3. Notations
instance of the relation with given values for each attribute
de®ned in the scheme. Attribute de®ned in relation scheme We de®ne notations to express concepts and operations in
may associate with an atomic data type, which restricts on a RDB and OODB. They represent functions and semantics of
set of permissible data for the value of the corresponding typical database operations.
attribute. A subset of a relation's attributes is called a key,
which can be referred by the attributes of another relation in ² RDB scheme:
a foreign key. AR: an attribute de®ned in relation scheme R.
The RDB operations are scheme de®nition, data inser- Akey
R : key attribute(s) of relation scheme R.
tion, data update, data deletion, and data query. Query can Afkey
R : foreign key attribute(s) of relation scheme R.
be divided into set operations, such as union, intersection, NAME(AR): name of attribute AR.
and difference, and relation operations include cartesian DOM(AR): type of attribute AR.
product, projection, selection and join. NAME(R): name of relation R.
ATT(R): a set of all attributes de®ned in relation
2.2. Object-oriented data model
scheme R.
We de®ne an OODB in a 3-tuple: OODB ˆ kC; O; OPO l; ² RDB operation:
where Cr(R,SA): create relation R with a set of attributes in set
C ˆ {CuC is a class de®ned in OODB} Ir(R,SV): insert a tuple into relation R with a set of
O ˆ {OCuOC is a set of instances which have class C as its values in set SV.
type} Sr(R,QR,AR): select the values, satisfying quali®cation
OPo ˆ {opouopo is an object-oriented database operation} QR, of attribute AR of relation R.
Ur(R,QR,AR,vR): update the values, satisfying quali®ca-
Object-oriented data model consists of objects. Each tion QR, of attribute AR of relation R with new value vR.
object is uniquely identi®ed by object identi®er (OID) Dr(R,QR): delete the tuples of relation R, which satisfy
de®ned and assigned by system with a state and behavior quali®cation QR.
associated with it. The state of an object is determined by
the value of its attributes and operations. The behavior of an 1
Stored OID is an aggregation attribute in an object of a class which
object is speci®ed by the methods that operate on the object references (pointing) to an OID stored in an object of another class.
J. Fong / Information and Software Technology 44 (2002) 41±51 43

² OODB class: level such that each class is mapped to a relation scheme.
T oid: type of implied attribute having object identi®er The other is attribute level such that different type attributes
as its value. are treated differently. Implied OID is mapped to a key
T atomic: type of atomic attribute. attribute. Atomic attribute is mapped into an attribute with-
T class: type of aggregate attribute. out change. Composite attribute is mapped into a foreign
T set: type of set attribute. key attribute referencing to the key of the relation corre-
AC or ATC : an attribute of class C or a T type attribute of sponding to the attribute domain class. Set attribute is
class C. mapped into an atomic attribute plus an extra relation
NAME(AC): name of attribute AC. scheme which has two attributes. One is to set a link to
DOM(AC): class or type of attribute AC. the attribute corresponding to the set attribute. The other
ELEDOM…Aset C † : class or type of set element. is to deal with set elements. Suppose we have SC ˆ
NAME(C): name of class C. {C1 ; ¼; C m }; SA {A1C ; ¼; AnC }; m $ 0 and n $ 0 in class
ATT(C): a set of attributes de®ned in class C. creation operation Co(C,SC,SA). The scheme mapping rS is
SUB(C): a set of subclasses of class C. expressed as
² OODB operation:    
Co(C,SC,SA): create class C as a subclass of classes in rS Co C; {C 1 ; ¼; Cm }; A1C ; ¼; AnC
set SC with additional attributes in set SA.
Io(C,SV): create an object of class C with values in set
SV. ! Cr RC ; A1RC ; ¼; AkRC
So(C,QC,AC): select values, satisfying quali®cation QC,       
of attribute AC of class C. and Cr RAiC ; A1RAi ; A2RAi uDOM AiC ˆ T set
Uo(C,QC,AC,vC): update values, satisfying quali®cation C C

QC, of attribute AC of class C with new value vC. and attribute mapping is
Do(C,QC): delete objects of class C, which satis®es  
quali®cation QC. rS Aoid
C ! Akey

rS Aatomic
C ! AR C
3. Transaction translation
rS Aset 1 2
Transaction translation is to realize the functions and C C

semantics of operations of one set by using another set of  

operations. For translation, we need to set up mapping regu- rS Aclass
C ! Afkey
lations between the two set operations. In this section, we
map each OODB operation to RDB operations and then
based on the mappings, we formulate algorithms to derive 3.1.2. Translation algorithm
the uncertain parameters from the known parameters or Based on the mapping of rS, algorithm for scheme trans-
parameters determined by system. lation can be realized by determining relation name with its
structure, and attribute name with its data type as follows:
3.1. Scheme creation translation
scheme_translation(C,C 1,¼,C m,A1C ; ¼; AnC )
Schema is the set of all schemes de®ned in a database. // input: Co(C,{C 1,¼,C m},{A1C ; ¼; AnC })
Scheme is class de®nition in OODB and is relation in RDB. // output: Cr(RC,{A1RC ; ¼; AkRC }) and
The scheme creation translation maps a class de®nition // {Cr(RAiC ; {A1RAi ; A2RAi })uDOM…AiC † ˆ T set }
to a relation scheme de®nition. Each attribute of the { C C

class is mapped into an attribute of the corresponding NAME(RC) ˆ NAME(C);

relation with the preservation of the semantics of the class att ˆ {Aoid oid
C }; // AC is an atomic type attribute de®ned
in the mapped relation scheme. However, relation scheme by system //
does not have inheritance and non-atomic data types. As att ˆ att < {A1C ; ¼; AnC };
for inheritance, we have ATT…C† $ SA in operation for every class C i [ {C 1,¼,C m} do
Co(C,SC,SA). It is necessary to ensure what attributes the att ˆ att < ATT…C i †;
class C has by taking SC into consideration. As for non- for every attribute AiC [ att do // 1 # i # k ˆ uattu //
atomic type attributes in OODB, they are mapped to atomic {
type attributes or relation schemes in RDB. case DOM…AiC † ˆ T oid :
AiRC ˆ AiC ;
3.1.1. Translation mapping case DOM…AiC † ˆ T atomic :
We set the scheme mapping to two levels. One is scheme AiRC ˆ AiC ;
44 J. Fong / Information and Software Technology 44 (2002) 41±51

case DOM…AiC † ˆ T class : object with OID attribute assigned by system. The set values
AiRC ˆ Akey
R i
; of an attribute will be mapped into multiple tuples in an
case DOM…AiC † ˆ T set : additional relation. If the set is empty, there is no tuple
AiRC ˆ Aset ; // A set is an atomic type attribute inserted to the relation.
de®ned by system //
NAME…RAiC † ˆ NAME…C† 1 NAME…AiC †; 3.2.1. Translation mapping
Suppose we have SV ˆ {v1C ; ¼; vnC } in operation Io(C,SV)
A1RAi ˆ AiRC ;
C which creates an object of class C with values v1C ; ¼; vnC :
if …ELEDOM…AiC † ˆ T class † Each value viC corresponds to one attribute AiC de®ned in the
A2RAi ˆ Akey
RELEDOM…Ai † ; class C, 1 # i # n and n ˆ uATT…C†u: The value of a
else C C
composite attribute is an OID. Based on the scheme transla-
2 ele
AR A i ˆ A ; ==NAME…Aele † ˆ tion, creation operation mapping is
NAME…AC † and DOM…A † ˆ ELEDOM…AiC †
C i ele
} 1 n 1 n
} rC Io C; vC ; ¼; vC ! Ir RC ; oidRC ; vRC ; ¼; vRC

After the scheme translation, both the source scheme
and Ir RAiC ; oidRAi ; vjR i u DOM AiC ˆ T set
and target scheme are kept by system as metadata. The C
information about the relationship between superclass  
and its subclasses, between composite class and its
and …1 # i # n† and 1 # j # vic
component classes, between class and its attributes,
between class and its corresponding relations, and
between relation and its attributes are available for
transaction translations. 3.2.2. Translation algorithm
Based on the mapping rC, we have an algorithm for
3.1.3. Example scheme translation to produce a unique OID.
Below is an example of schema translation. Suppose we
have a series of class creation operations for the following creation_translation(C,v1c ; ¼; vnc ;rS)
class de®nitions: // input: Io(C,{v1c ; ¼; vnc }) and rS
// output:
 Ir(RC,{oidRC ;  viRC ; ¼; vnRC }) and 
class S1(A1:integer) // Ir RAiC ; oidRAi ; vR i u DOM AiC ˆ T set and
class S2(A2:integer, A3:string, A4:¯oat) subclass of S1 …1 # i # n† and 1 # j # vic
class S3(A5:S2) subclass of S1 {
class S4(A6:set of (string), A7:integer) subclass of S3 RC Ã rS(C);
class S5(A8:S3, A9:S4) subclass of S1 oidRC ˆ oid_generator… †;
for (i ˆ 1; i # ATT…C†; i ˆ i 1 1)
According to the scheme translation algorithm, the crea- {
tion operations create the relation schemes as follows: case AiC ˆ T atomic :
viRC ˆ viC ;
relation scheme S1(S1_OID:atomic type, A1:integer)
case AiC ˆ T class :
relation scheme S2(S2_OID:atomic type, A1:integer,
viRC ˆ viC ; // the value of a composite type attri-
A2:integer, A3:string, A4:¯oat)
bute is an oid of an object //
relation scheme S3(S3_OID:atomic type, A1:integer,
case AiC ˆ T set :
S2_OID:atomic type)
if …uviC u ˆ 0†
relation scheme S4(S4_OID:atomic type, A1:integer,
viRC ˆ null;
S2_OID:atomic type, A6_SET:atomic type, A7:integer)
relation scheme S4A6(A6_SET:atomic type, A6:string)
relation scheme S5(S5_OID:atomic type, A1:integer,
viRC ˆ oid_generator… †;
S3_OID:atomic type, S4_OID:aomic type)
RAiC à rS …AiC †;
oidRAi ˆ viRC ;
3.2. Creation translation for ( j ˆ 1; j # uviC u; j ˆ j 1 1) // viC should be a
set of values //
Creation translation maps an insertion operation of a class vjR i ˆ vijC ; // vijC is the jth element of set viC //
object to the insertion operation of a relation tuple with }

inserted tuples into appropriate relations mapped from the }

class. The tuples are reorganized by the given values of the }
J. Fong / Information and Software Technology 44 (2002) 41±51 45

3.2.3. Example attribute and Q is either the universal quanti®er (;) or

Suppose we want to create an object of class S4. The the existential quanti®er (').
object creation operation is:
The OODB schema draws a schema graph of two dimen-
Io …S4; {1; s2-oid-i; {`abc'; `efg'; `hij'}; 2}†
sions which presents two natures of OODB. Class hierarchy
After translation, the resultant relation tuple insertion is a class that may have superclasses and subclasses. Class
operations are composition hierarchy is a class that has attributes whose
domains are also classes. From class composition hierarchy,
Ir …S4; {s4-oid-j; 1; s2-oid-i; a6-set-k; 2}†
we can abstract a sub-graph of quali®cation graph, denoted
Ir …S4A6; {a6-oid-k; `abc'}† as GC. From class composition hierarchy, we can abstract
the model of QC.
Ir …S4A6; {a6-oid-k; `efg'}† We de®ne object quali®cation graph G C as an annotated
directed graph OG(OV, OE), where OV is a set of vertices,
Ir …S4A6; {a6-oid-k; `hij'}† and OE is a set of directed edges. OG is a weak connected
graph which has one vertex of source vertex with in-degree
being zero and m…m $ 1† vertices of terminal vertices with
3.3. Quali®cation translation
out-degree being zero. A non-terminal vertex v in OV
The function of object quali®cation QC ®lters certain associates with a class and a terminal vertex v in OV with
objects from all objects of class C. In some transactions, a predicate having path expression of n ˆ 0 in its operands.
we need to map QC to a relational quali®cation QR which A directed edge e from non-terminal vertex v1 to non-
®lters the tuples corresponding to the objects quali®ed by terminal vertex v2 in OE indicates a composition association
QC. The mapping is denoted as rQUA(QC) ! QR. such that the class of vertex v2 is a component class of the
Both QC and QR are of boolean expressions, but QC has class of vertex v1, and the annotation attached to the edge e
two extra mechanisms which QR does not have. One is the is an attribute of the class of vertex v1 and its domain is the
path expression operand. The other is set operand with its class of vertex v2. A directed edge e from non-terminal
operator and quanti®er. The problem is how to map these vertex v1 to terminal vertex v2 in OE indicates that the
two mechanisms to relational correspondents. Since class predicate of vertex v2 works on attribute of the class of
and set attribute are mapped to relations, the path expression vertex v1, and there is no annotation attached to the edge.
operand used for navigation operation in QC is mapped to
join conditions in QR and set operations in QC is mapped to 3.3.2. Organizing OODB quali®cation graph
relation operation in QR. We will show a simpli®ed model For a given QC, we can organize a quali®cation graph GC.
for QC, and offer algorithms to translate QC to QR by using The graph has the class C as its source vertex and each
graph technique. For simplicity we regard QC and QR, being predicate qiC corresponds to a path of the graph. The path
connective form of predicates, as two sets of the predicates. starts from the source vertex and ends to one of terminal
vertices. Each non-terminal vertex of the graph associates
3.3.1. Quali®cation model with a class which has the domain of a composite attribute
QC ®lters certain objects not only by directly setting appeared in a path expression and the edge to the vertex is
predicates on some attributes of class C but also by navigat- annotated with the attribute. Each terminal vertex of the
ing through the class composition hierarchy starting at class graph associates with a predicate which contains the last
C and setting predicates on some attributes of the direct or attribute in a path expression. Algorithm of organizing GC
indirect component classes of class C. In general, QC is a from QC is
combination of predicates with logical connectives ^ , _ ,
: . We assume QC has the form QC ˆ …q1C † ^ ¼ ^ …qnC †; n $ OQG_organizing(QC,rS)
0: That is QC contains zero or more OODB predicates in // input: QC and rS
conjunctive form. Each OODB predicate qiC …1 # i # n† is // output: GC
recursively de®ned as follows: {
let C be the source vertex of GC;
1. Atomic predicate: t1ut2. tj … j ˆ 1; 2† is either a path for every qiC in QC do
expression or a constant distinctively. The path expres- {
sion contains a sequence of attributes derived from an set a pointer P to point source vertex;
attribute of class C and has the form of AC0.AC1.AC2.¼.ACn, for every attribute ACi in path expression do
n $ 0; C0 ˆ C; and (DOM…ACi † ˆ Ci11 ; 0 # i # n 2 1) {
where n . 0. u is a comparison operator such as ,, #, if ACi is not the last attribute in the path expression
ˆ , ±, ., $, . , $ , ÷ , , , # , [ , Ó depending on {
the data type of the operands. if DOM…ACi † is not a vertex adjacent from the
2. Quanti®ed predicate: Q…q Ci †: qiC contains a set value vertex pointed by P
46 J. Fong / Information and Software Technology 44 (2002) 41±51

directed graph RG(RV,RE), where RV is a set of vertices,

and RE is a set of directed edges. A non-terminal vertex v in
RV associates with a relation and a terminal vertex v in OV
associates with a predicate. An edge e from non-terminal
vertex v1 to non-terminal vertex v2 in RE indicates a join
association between the two relations, and the annotation
attached to edge e is the join predicate on the two related
relations. An edge e from non-terminal vertex v1 to terminal
vertex v2 in OE indicates that the predicate of vertex v2
works on the attribute of the relation of vertex v1, and
Fig. 2. Object quali®cation graph of QS5. there is no annotation attached to the edge.
To translate OODB quali®cation graph to a correspond-
{ ing RDB quali®cation graph is to replace class of each non-
if vertex DOM…ACi † does not exist terminal vertex of GC by its corresponding relation. To
create a vertex with class DOM…ACi †; replace annotated attribute of each edge between two non-
let vertex DOM…ACi † be adjacent from the terminal vertices of GC by join predicate which sets the
vertex pointed by the pointer P; attribute, corresponding to the annotated attribute of GC,
let ACi be the annotation of the edge to the of the relation of the tail vertex of the edge is equal to the
vertex DOM…ACi †; key attribute of the relation of the head vertex of the edge.
} To replace attribute in each terminal vertex of GC by its
adjust P to point vertex DOM…ACi †; counterpart attribute in corresponding relation, if the
} attribute in a terminal vertex is set type, insert a new non-
else terminal vertex of the relation mapped from the set attribute
{ between the terminal vertex and its adjacent from vertex in
create a vertex adjacent from the vertex GR. To annotate the edge to this new inserted vertex with a
pointed by P with predicate on ACi ; join predicate that is the ®rst attribute of the relation of the
} new inserted vertex is equal to the attribute, corresponding
} to the set attribute, in the relation of its adjacent from vertex.
} Modify the predicate in the terminal vertex according to the
} semantics of the set operator. In schema translation [10], we
give the mapping from set related operations such as [ , ;,
For example, graph for QS5: (A1 , 10) ^ ', and # to relation operations. Algorithm of translating
(A8.A5.A2 . 0) ^ (A8.A5.A3 ˆ `abc') ^ (A9.A5.A4 5.5) ^ GC to GR is (Fig. 3)
(`bcd' [ A9.A6) is shown in Fig. 2.
3.3.3. Translating OODB quali®cation graph to RDB // input: GC and rS
quali®cation graph // output: GR
Class can be mapped to relation. The semantics of navi- {
gation operation used in the query of OODB can be realized traverse graph GC and for every vertex do
by using join operation in the query of RDB. We can map {
OODB quali®cation graph to RDB quali®cation graph of if the vertex is not a terminal vertex
GR, which expresses predicates on a set of relations for {
relational query operation. replace the class of the vertex by its corresponding
We de®ne relation quali®cation graph GR as an annotated relation;

Fig. 3. GR translated from GC of QS5 in Fig. 2.

J. Fong / Information and Software Technology 44 (2002) 41±51 47

for every edge to the vertex do Continuing to the above example by using breadth-®rst
{ search to traverse the graph of Fig. 3, we get
replace the annotated attribute of the edge
QR ˆ {…S5:A1 , 10†; …S5:S3_OID ˆ S3:S3_OID†;
by join predicates (i.e. the attribute, corre-
sponding to the annotated attribute, of the …S5:S4_OID ˆ S4:S4_OID†;
relation of the tail vertex is set to be equal
to the key attribute of the relation of the …S3:S2_OID ˆ S2:S2_OID†;
head vertex);
} …S4:S2_OID ˆ S2:S2_OID†;
else …S4:A6_SET ˆ S4A6:A6_SET†; …S2:A2 . 0†;
if the attribute in the terminal vertex is not a …S2:A3 ˆ `abc'†; …S2:A4 ˆ 5:5†; …`bcd' in S4A6†}
set type
replace the attribute in the terminal vertex
3.3.5. Quali®cation translation algorithm
by corresponding relation attribute;
As mentioned before, the algorithm of quali®cation trans-
lation is
insert a new vertex between the terminal quali®cation_translation(QC,rS);
vertex and its adjacent from vertex; // input: QC and rS
set the new inserted vertex as the relation // output: QR
mapped from the set attribute; {
annotate the edge to the new inserted vertex OQG_organizing(QC,rS); // organizing GC from QC //
with a join predicate (i.e. the ®rst attribute OQG_to_RQG_translating(GC,rS); // translating GC to
of the relation of the head vertex is equal to GR //
the attribute, corresponding to the set attri- RQ_producing(GR,rS); // producing QR from GR //
bute, in the relation of the tail vertex); }
modify the terminal vertex predicate accord-
ing to the semantic of set operator;
} 3.4. Query translation
} Query So(C,QC,A) in OODB is divided into three parts.
} Range part C indicates the class that the selected objects
belong. Quali®cation part QC indicates predicates that the
selected objects must satisfy. Target part A indicates the
3.3.4. Producing RDB quali®cation attributes that the result values come from. But compared
By traversing graph GR, we can produce the set of the with RDB counterparts, each part in OODB query has new
predicates which constitute the corresponding relation mechanisms. Range part indicates one class or a set of
quali®cation. The translation algorithm is classes in a class hierarchy. Quali®cation part may contain
new kinds of operands and operators. Target part can be an
RQ_producing(GR,rS) attribute of the given class in range part or one attribute of a
// input: GR and rS class that is derived by navigating through the class compo-
// output: QR sition hierarchy rooted at the given class.
{ For query translation, we map object query operation to
QR ˆ B; relation query operations and select the tuples correspond-
traverse graph GR and for each vertex do ing to the objects quali®ed by QC from the appropriate rela-
{ tions mapped from indicated class or the class with all of its
if the vertex is a terminal vertex subclasses. The selected tuples are ®ltered by relational
QR ˆ QR < {the predicate of the vertex}; quali®cation QR, mapped from QC, and also from path
else expressions in target part of object query operation.
QR ˆ QR < {the predicates of the edges to the 3.4.1. Translation mapping
vertex}; The general form of target part A is expressed as
} AC0 :AC1 :AC2 :¼:ACn ; where n $ 0; C ˆ C0 when n ˆ 0;
} and (DOM…ACi † ˆ Ci11 ; 0 # i # n 2 1) when n . 0. The
} values of ACn of the selected objects are the result of
48 J. Fong / Information and Software Technology 44 (2002) 41±51

query. The mapping rQ are query_translation2(C all,QC,A,rS)

rQ …So …C; QC ; AC0 :AC1 :AC2 :¼:ACn †† ! Sr …R; QR ; AR †;
for (every C i [ {C} < SUB(C)) do
where query_translation1(C i,QC,A,rS);
² the mapped range part is
RCn DOM…ACn † ± T set
Rˆ 3.4.3. Example
RACn DOM…ACn † ˆ T set According to the translation algorithm, we translate
object query:
² the mapped quali®cation part is So …S5; QS5 ; A9:A7†

2 1 n
n[ o
* rQUA …QC † < RCi :ARCi ˆ RCi11 :Akey
RCi11 ; DOM…ACn † ± T set
QR ˆ !
2 1 n
n[ o n o
rQUA …QC † < RCi :ARCi ˆ RCi11 :Akey
RCi11 < RCn :ARCn ˆ RACn :A1RA DOM…ACn † ˆ T set

² the mapped target is to relation query:

*A DOM…ACn ± T set
RCn ; Sr …S4; …S5:A1 , 10† ^ …S5:S3_OID
AR ˆ
A2RA DOM…ACn ˆ T set
ˆ S3:S3_OID† ^ …S5:S4_OID

ˆ S4:S4_OID† ^ …S3:S2_OID

3.4.2. Translation algorithm ˆ S2:S2_OID† ^ …S4:S2_OID

Based on the mapping rQ, algorithm for scheme transla-
tion is ˆ S2:S2_OID† ^ …S4:A6_SET
query_translation1…C; QC ; AC0 :AC1 :AC2 :¼:ACn ; rS †
// input: So …C; QC ; AC0 :AC1 :AC2 :¼:ACn † and rS ˆ S4A6:A6_SET† ^ …S2:A2 . 0† ^ …S2:A3
// output: Sr(R,QR,AR)
{ ˆ `abc'† ^ …S2:A4 ˆ 5:5† ^ …`bcd' in S4A6†; A7†
R Ã rS(Cn)
QR ˆ qualification_translation…QC ; rS †;
for (i ˆ 0; I , n; i ˆ i 1 1) 3.5. Update translation
QR ˆ QR < {…RCi :ARCi ˆ RCi11 :Akey RCi11 †};
if …DOM…ACn † ± T set For update translation, we map object update opera-
AR ˆ ARCn ; tion to relational update operations. The process updates
else the values of the indicated attribute of the tuples quali-
{ ®ed by QR mapped from QC in object update operation
QR ˆ QR < {…RCn :ARCn ˆ RACn :A1RA †}; from the appropriate relations mapped from indicated
AR ˆ A2RA ;
class or the class with its subclasses. According to
scheme mapping, the elements of a set value are stored
} in a relation, and different values of a set attribute may
have different elements. This means different set values
For inherence, the object query operation is represented correspond to different tuples in a relation. Thus, we
as So(C all,QC,A) which indicates that the range part are all may need to delete some tuples if the elements of the
classes in the class hierarchy having class C as superclass. In old values are more than the new ones. Otherwise we
this case we have may need to insert some tuples. Our approach is to
delete all tuples of old value and then insert tuples
So …Call ; QC ; A† ˆ YCi [{C}YSUB…C† So …Ci ; QCi ; A†; and for the new value.
J. Fong / Information and Software Technology 44 (2002) 41±51 49

3.5.1. Translation mapping object update operation:

Based on the scheme translation, the update operation
mapping is: Uo …S4; S4:A1 . 0; A6; {`uvw'; `xyz'}†

* U …R ; Q ; A ; v †; DOM…AC † ± T set
rU …Uo …C; QC ; AC ; vC †† ! n  n o o
Dr …RAC ; Q 0R †; Ur …RC ; QR ; ARC ; vRC † and Ir RAC ; oidRA ; vjRA uI # j # uvC u ; DOM…AC † ˆ T set

3.5.2. Translation algorithm to the following relation operations:

Based on the mapping rU, algorithm for scheme transla-
tion is Ur …S4; S4:A1 . 0; A6_SET; a6-oid-n†;
Dr …S4A6; S4:A1 . 0 ^ S4:A6_SET ˆ S4A6:A6† and
update_translation1(C,QC,AC,vC,rS) {Ir(S4A6,{a6-oid-n,`uvw'}),Ir(S4A6,{a6-oid-n,`xyz'})}
// input: Uo(C,QC,AC,vC) and rS
// output: Ur(RC,QR,ARC ;vRC ) and
// Dr …RAC ; Q 0R † and {Ir …RAC ; {oidRA ; vjRA }†u1 # j # uvC u} 3.6. Deletion translation
For deletion translation, we map object deletion operation
RC Ã rS(C);
to relational deletion operations by deleting the tuples
QR ˆ qualification_translation…QC ; rS †;
®ltered by quali®cation QR mapped from QC in object dele-
ARC à rS …AC †;
tion operation from the appropriate relations mapped from
if …DOM…AC † ± T set †
indicated class or the class with its subclasses. If the objects
vR C ˆ v C ;
to be deleted contain set values, all the tuples corresponding
to those set values must be deleted from the related relations
mapped from the set attributes. The deleted objects may be
if …uvC u ˆ 0†
components of other composite objects. Thus, we need to
vRC ˆ null;
set null values to the foreign key attributes in the tuples
corresponding to the composite objects.
vRC ˆ oid_generator… †;
RAC à rS …AC †; 3.6.1. Translation mapping
Q 0R ˆ QR < {…RC :ARC ˆ RAC :A1RA †}; Based on the scheme translation, the deletion operation
C mapping is
for ( j ˆ 1; j # uvC u; j ˆ j 1 1) // vC should be a n     
set of values // rD …Do …C; QC †† ! Dr RAiC ; QiR u DOM AiC ˆ T set
vjRA ˆ vjC ; // vjC is the jth element of set vC //
C o
} and …1 # i # uATT…C†u† ;
} n   o
Ur RCj ; QjR ; ARCj ; null uDOM…ACj † ˆ C and Dr …RC ; QR †
As for inheritance, the object update operation is repre-
sented as Uo(C all,QC,AC,vC) which indicates the objects to be
updated belong to all classes in the class hierarchy having 3.6.2. Translation algorithm
class C as superclass. In this case, we have Based on the mapping rD algorithm, scheme translation is

Uo(C all,QC,AC,vC) ˆ {Uo(C i,QC i,AC i,vC i)u(C i [ {C} < deletion_translation1(C,QC,rS)
SUB(C)) and …0 # i # uSUB…C†u† and …C 0 ˆ // input: Do(C,QC) and rS
C† and …ACi [ ATT…C ††}; and // output: {Dr …RAiC ; QiR †u…DOM…AiC † ˆ T set † and …1 # i #
update_translation2(C all,QC,AC,vC,rS) uATT…C†u†};
{ // {Ur …RCj ; QjR ; ARCj ; null†uDOM…ACj † ˆ
for (every C i [ {C} < SUB(C)) do C} and Dr …RC ; QR †
update_translation1(C i,QC,AC,vC,rS); {
} QR ˆ qualification_translation…QC ; rS †;
for (i ˆ 1; i # uATT…C†u; i ˆ i 1 1)
if …DOM…AiC † ˆ T set †
3.5.2. Example {
According to the translation algorithm, we translate RAiC à rS …AiC †;
50 J. Fong / Information and Software Technology 44 (2002) 41±51

QiR ˆ QR < {…RC :ARC ˆ RAiC :A1RAi †} ªdatabase systemº});

} C
5. update STUDENT
RC à rS(C); set course_taken ˆ {ªJavaº, ªcompilerº}
for (every C j [ C) where dept.dept_name ˆ ªComputer Scienceº;
for (every ACj [ ATT…C j †) 6. delete from STUDENT where name ˆ ªJohn Smithº;
if …DOM…ACj † ˆ C† 7. delete from DEPT where dept_name ˆ ªMathematicsº;
RCj à rS …C j †; After translation, we get the following resultant relation
ARCj ˆ Akey
RC ; operations in an SQL-like format corresponding to our
QjR ˆ QR < {…RC :Akey
RC ˆ RC j :ARCj †} relation operation:
} 1. create table DEPT(dept_oid: integer, dept_no: integer,
dept_name: string);
As for inheritance, the object delete operation can be 2. create table STUDENT(student_oid: integer, name:
represented as Do(C all,QC) which indicates the objects to string, student_no: integer, dept_oid: integer,
be deleted belong to all classes in the class hierarchy having course_taken_set: integer);
class C as superclass. In this case, we have create table STUDENTCOURSE_TAKEN(course_
taken_set: integer, course_taken: string);
Do …C all ; QC † ˆ {Do …Ck ; QCk †u…C k [ {C} < SUB…C†† and
3. insert into DEPT values(4, 12, ªComputer Scienceº);
…0 # k # uSUB…C†u† and …C 0 ˆ C†}; 4. insert into STUDENT values(5, ªTom Wangº, 2345, 4, 6);
insert into STUDENCOURSE_TAKEN values(6, ªdata
and structureº);
insert into STUDENCOURSE_TAKEN values(6,
deletion_translation2(C all,QCi ;rS) ªdatabase systemº);
{ 5. delete from STUDENTCOURSE_TAKEN
for (every C k [ {C} < SUB(C)) do where STUDENTCOURSE_TAKEN.course_taken_ set
deletion_translation1(C k,QCk ;rS); in
} (select STUDENTCOURSE_TAKEN.course_taken_
3.6.3. Example DEPT
According to the translation algorithm, we translate where STUDENT.dept_oid ˆ DEPT.dept_oid
object delete operation: and DEPT.dept_name ˆ ªComputer Scienceº
Do …S4; S4:A1 . 0† and
STUDENT.course_taken_set ˆ
to the following relation operations: STUDENTCOURSE_TAKEN.course_taken_set);
update STUDENT
{Dr(S4A6,S4.A1 . 0 ^ S4.A6_SET ˆ S4A6.A6_SET)}, set course_taken_set ˆ 7
{Ur(S5,S4.A1 . 0 ^ S4.S4_OID ˆ S5.S4_OID,S4_OID, where STUDENT.student_oid in
null)} and (select STUDENT.student_oid
Dr …S4; S4:A1 . 0† from STUDENT, DEPT
where STUDENT.dept_oid ˆ DEPT.dept_oid
and DEPT.dept_name ˆ ªComputer Scienceº);
4. Case study insert into STUDENCOURSE_TAKEN values(7,
Suppose we have the source object-oriented operations insert into STUDENCOURSE_TAKEN values(7,
written in UniSQL [13] corresponding to our OODB opera- ªcompilerº);
tions as follows: 6. delete from STUDENTCOURSE_TAKEN
where STUDENTCOURSE_TAKEN.course_ taken_set
1. create class DEPT(dept_no: integer, dept_name: string); in
2. create class STUDENT(student_no: integer, name: (select STUDENTCOURSE_TAKEN.course_
string, dept: DEPT, course_taken: set(string)); taken_set
values(12, ªComputer Scienceº); where ˆ ªJohn Smithº
4. insert into STUDENT and STUDENT.course_taken_set ˆ STUDENT-
values(2345, ªTom Wangº, oid2, {ªdata structureº, COURSE_TAKEN.course_taken_set);
J. Fong / Information and Software Technology 44 (2002) 41±51 51

delete from STUDENT The author thanks Zeng Xiaoqin of the City University of
where ˆ ªJohn Smithº; Hong Kong for his assistance in drafting the paper.
7. update STUDENT
set STUDENT.dept_oid ˆ null;
where STUDENT.student_oid in
(select STUDENT.student_oid
from STUDENT, DEPT [1] A.P. Sheth, J.A. Larson, Federated database systems for managing
where DEPT.dept_name ˆ ªmathematicsº distributed, heterogeneous, and autonomous databases, ACM
and DEPT.dept_oid ˆ STUDENT.dept_oid); Comput. Surv. 22 (3) (1990) 183±236.
8. delete from DEPT [2] W. Meng, et al., Construction of a relational front-end for object-
9. where DEPT.dept_name ˆ ªMathematicsº; oriented database systems, Proc. IEEE Data Engng (1993) 476±
[3] D. Keim, H.P. Kriegel, A. Miethsam, Object-oriented querying of
existing relational database, Proceedings of the Fourth International
5. Conclusion Conference on Database and Expert System Applications (DEXA
'93), September 1993.
[4] C. Yu, et al., Translation of object-oriented queries to relational
Transaction translation between OODB and RDB plays
queries, IEEE Proceedings of the 11th International Conference On
an important role in the multidatabase interoperability. In Data Engineering, 1995, pp. 90±97.
this paper, we show methods of mappings and algorithms [5] Xiuzhen Zhang, Joseph Fong, Translating update operations from
which translate transactions of OODB to transactions of relational to object-oriented databases, J. Info. Soft. Technol. 42 (3)
RDB. The discussion aims at the functions in OODB (2000).
operations which are not supported by RDB operations [6] Joseph Fong, Paul Chitson, Query translation from SQL to OQL for
database reengineering, Int. J. Info. Technol. 3 (1) (1997) 83±101.
without translation. In transactions translation, the class [7] E. Bertino, M. Negri, G. Pelagatti, L. Sbattella, Object_oriented query
hierarchy semantics in OODB are mapped to relational languages: the notion and the issues, IEEE Trans. Knowledge Data
union operation. The semantics of navigation through Engng 4 (3) (1992) 223±237.
composition hierarchy are mapped to relational join [8] V.M. Markowitz, A. Shoshani, Object queries over relational data-
operation, and set operations are mapped to relevant rela- base: language, implementation, and applications, Proc. IEEE Data
Engng (1993) 71±80.
tion operations. To map multiple path expressions origi-
[9] Q. Xiaolei, R. Louiqa, Query interoperation among object-oriented
nated from one class in a quali®cation of an object and relational databases, IEEE Proceedings of the 11th International
operation, we use a graph to model and process the Conference On Data Engineering, 1995, pp. 271±278.
mapping. For future research of this paper, we will [10] M. Blaha, W. Premerlani, H. Shen, Converting OO models into
include the PSM [14] routine (cover both user-de®ned RDBMS schema, IEEE Soft. 1 (1) (1994) 28±39.
functions and procedures) in the transaction translation [11] J.G. Hughes, Object-Oriented Databases, Prentice-Hall, Englewood
Cliffs, NJ, 1991.
processing. [12] D. Maier, The Theory of Relational Database, Computer Science
Press, 1983.
[13] UniSQL/X User's Manual, UniSQL, Inc.
Acknowledgement [14] C.J. Date, Hugh Darwen, A Guide to the SQL Standard, Addison-
Wesley Publishing, 1993.
This research project is supported by a strategic research
grant 7001240 of City University of Hong Kong.