Information and Software Technology 44 (2002) 41±51

www.elsevier.com/locate/infsof

Translating object-oriented database transactions into relational

transactions
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

Abstract
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

The requirement of interoperability of autonomous data-
bases leads to the multidatabase system, which consists of
homogenous or heterogenous databases. In heterogenous
multidatabase system, the translation between operations
of databases with different data models is critical [1]. As
relational database (RDB) is the dominating database appli-
cation and object-relational database (ORDB) maybe the
next generation database to meet advanced business require-
ments, it is necessary and practical to search for a solution of
transaction translation.
There are methods of transaction translation between
object-oriented database (OODB) and RDB, and each direc-
tion re¯ects, based on the architecture of a multidatabase
system, a certain system function. Meng [2] discussed the
transaction translation from RDB to OODB based on a
schema translation from OODB to RDB. Keim [3] and Yu
[4] discussed the query translation from OODB to RDB based
on a schema translation from RDB to OODB. Zhang and
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
translation between RDB and OODB. Blaha [10] proposed
four ways to handle inheritance by use of relation tables. In
* Tel.: 1852-2788-8580; fax: 1852-2788-8614.
E-mail address: csjfong@cityu.edu.hk (J. Fong).
0950-5849/02/$ - see front matter q 2002 Elsevier Science B.V. All rights reserved.
PII: S 0950-584 9(01)00211-7
mapping, we propose a different way. Our way is, in addition
to mapping each class in a class hierarchy to a table, to extend
the attributes of superclass tables to all their subclass tables
according to inheritance rules. Our approach on the trans-
action translation from OODB to RDB follows after the
schema translation from OODB to RDB. Our model on the
interoperability of relational and OODBs is described in Fig. 1.
The model in Fig. 1 is equivalent to build an object-
oriented interface on top of a relational database manage-
ment system (RDBMS). In the model, the Gateway
translates OSQL [11] to relational SQL.
The following sections are arranged in this way. Section 2
describes relational data model and object-oriented data
model. Section 3 discusses transaction translations and
gives translation mappings and algorithms for each typical
database operation. The operations include scheme de®ni-
tion, data insertion, data query, data update, and data
deletion. Section 4 gives a real world case study. Section
5 concludes the paper.
2. Data model
The data models described in this section contain the
standard features of relational data model [12] and object-
oriented data model. We also establish a correspondence
between their parallel counterparts with notations.
42 J. Fong / Information and Software Technology 44 (2002) 41±51
Fig. 1. Research model.
2.1. Relational data model
We de®ne a RDB as a 3-tuple: RDB ˆ kR; T; OPr l;
where
R ˆ {RuR is a relation scheme de®ned in RDB}
T ˆ {TRuTR is a relation (set of tuples) having R as its
scheme}
OPr ˆ {opruopr is a relational database operation}
Relational data model is in the form of two-dimensional
tables of relations. Each relation has a scheme de®nition and
tuples. Relation scheme determines the structure of a rela-
tion by de®ning a set of attributes, and each tuple is an
instance of the relation with given values for each attribute
de®ned in the scheme. Attribute de®ned in relation scheme
may associate with an atomic data type, which restricts on a
set of permissible data for the value of the corresponding
attribute. A subset of a relation's attributes is called a key,
which can be referred by the attributes of another relation in
a foreign key.
The RDB operations are scheme de®nition, data inser-
tion, data update, data deletion, and data query. Query can
be divided into set operations, such as union, intersection,
and difference, and relation operations include cartesian
product, projection, selection and join.
2.2. Object-oriented data model
We de®ne an OODB in a 3-tuple: OODB ˆ kC; O; OPO l;
where
C ˆ {CuC is a class de®ned in OODB}
O ˆ {OCuOC is a set of instances which have class C as its
type}
OPo ˆ {opouopo is an object-oriented database operation}
Object-oriented data model consists of objects. Each
object is uniquely identi®ed by object identi®er (OID)
de®ned and assigned by system with a state and behavior
associated with it. The state of an object is determined by
the value of its attributes and operations. The behavior of an
object is speci®ed by the methods that operate on the object
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),
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
an aggregation attribute in an object of a class which
references (pointing) to an OID stored in an object of
another class. The aggregate attributes may form a class
composition hierarchy in a directed graph. Set attribute is
de®ned to have multiple values of atomic type or aggre-
gate attribute. We regard OID as the value of an implied
atomic attribute.
Each OODB operation may contain mechanisms not
supported by RDB. For example, range clause in query
may denote a class or a group of classes in a class hierarchy,
and target clause may contain path expression to navigate
through composition hierarchy.
2.3. Notations
We de®ne notations to express concepts and operations in
RDB and OODB. They represent functions and semantics of
typical database operations.
² RDB scheme:
AR: an attribute de®ned in relation scheme R.
Akey
R : key attribute(s) of relation scheme R.
Afkey
R : foreign key attribute(s) of relation scheme R.
NAME(AR): name of attribute AR.
DOM(AR): type of attribute AR.
NAME(R): name of relation R.
ATT(R): a set of all attributes de®ned in relation
scheme R.
² RDB operation:
Cr(R,SA): create relation R with a set of attributes in set
SA.
Ir(R,SV): insert a tuple into relation R with a set of
values in set SV.
Sr(R,QR,AR): select the values, satisfying quali®cation
QR, of attribute AR of relation R.
Ur(R,QR,AR,vR): update the values, satisfying quali®ca-
tion QR, of attribute AR of relation R with new value vR.
Dr(R,QR): delete the tuples of relation R, which satisfy
quali®cation QR.
1
Stored OID is an aggregation attribute in an object of a class which
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:
T oid: type of implied attribute having object identi®er
as its value.
T atomic: type of atomic attribute.
T class: type of aggregate attribute.
T set: type of set attribute.
AC or ATC : an attribute of class C or a T type attribute of
class C.
NAME(AC): name of attribute AC.
DOM(AC): class or type of attribute AC.
ELEDOM…Aset C † : class or type of set element.
NAME(C): name of class C.
ATT(C): a set of attributes de®ned in class C.
SUB(C): a set of subclasses of class C.
² OODB operation:
Co(C,SC,SA): create class C as a subclass of classes in
set SC with additional attributes in set SA.
Io(C,SV): create an object of class C with values in set
SV.
So(C,QC,AC): select values, satisfying quali®cation QC,
of attribute AC of class C.
Uo(C,QC,AC,vC): update values, satisfying quali®cation
level such that each class is mapped to a relation scheme.
The other is attribute level such that different type attributes
are treated differently. Implied OID is mapped to a key
attribute. Atomic attribute is mapped into an attribute with-
out change. Composite attribute is mapped into a foreign
key attribute referencing to the key of the relation corre-
sponding to the attribute domain class. Set attribute is
mapped into an atomic attribute plus an extra relation
scheme which has two attributes. One is to set a link to
the attribute corresponding to the set attribute. The other
is to deal with set elements. Suppose we have SC ˆ
{C1 ; ¼; C m }; SA {A1C ; ¼; AnC }; m $ 0 and n $ 0 in class
creation operation Co(C,SC,SA). The scheme mapping rS is
expressed as
   
rS Co C; {C 1 ; ¼; Cm }; A1C ; ¼; AnC
  
! Cr RC ; A1RC ; ¼; AkRC
      
and Cr RAiC ; A1RAi ; A2RAi uDOM AiC ˆ T set
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
RC

 
rS Aatomic
C ! AR C
3. Transaction translation

 
rS Aset 1 2
C ! ARC 1 RAC ARA ; ARA
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-
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
the uncertain parameters from the known parameters or
parameters determined by system.
3.1. Scheme creation translation
Schema is the set of all schemes de®ned in a database.
Scheme is class de®nition in OODB and is relation in RDB.
The scheme creation translation maps a class de®nition
to a relation scheme de®nition. Each attribute of the
rS Aclass
C ! Afkey
RC
3.1.2. Translation algorithm
Based on the mapping of rS, algorithm for scheme trans-
lation can be realized by determining relation name with its
structure, and attribute name with its data type as follows:
scheme_translation(C,C 1,¼,C m,A1C ; ¼; AnC )
// input: Co(C,{C 1,¼,C m},{A1C ; ¼; AnC })
// output: Cr(RC,{A1RC ; ¼; AkRC }) and
// {Cr(RAiC ; {A1RAi ; A2RAi })uDOM…AiC † ˆ T set }
{ 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
DOM…A †
C
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
A
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

j
class S1(A1:integer) // Ir RAiC ; oidRAi ; vR i u DOM AiC ˆ T set and
C
A
C  

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)
else
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 ;
C
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 }
A
C

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

² 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
Cn
ˆ 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 ;
Cn
class or the class with its subclasses. According to
}
Cn
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
r C R RC RC
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
C C

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