Transforming RDB schema into well-structured OODB schema

Transforming RDB schema into well-structured OODB schema

Xiuzhen Zhanga,* , Yanchun Zhangb, Joseph Fonga, Xiaohua Jiaa

aDepartment of Computer Science, City University of Hong Kong, Kowloon, Hong Kong, People’s Republic of ChinabDepartment of Mathematics and Computing, University of Southern Queensland, Australia

Received 30 October 1997; received in revised form 17 November 1998; accepted 24 November 1998

Abstract

When transforming relational database (RDB) schema into object-oriented database(OODB) schema, much effort was put on examiningkey and inclusion dependency (ID) constraints to identify class and establish inheritance and association between classes. However, in orderto further remove the original data redundancy and update anomaly, multi-valued dependency (MVD) should also be examined. In this paper,we discuss class structures and define well-structured classes. Based on MVDs, a theorem is given transforming a relation schema into a well-structured class. To transform RDB schema into OODB schema, a composition process simplifying the input RDB schema and an algorithmtransforming the simplified RDB schema into well-structured OODB classes are developed.q 1999 Elsevier Science B.V. All rightsreserved.

Keywords:Integrity constraints; Multi-valued dependency; Object-oriented model; Relational model; Schema transformation

1. Introduction

With the development of object-oriented technology,relational database (RDBs) are seeking ways to transit toobject-oriented database (OODBs). This makes transform-ing RDB schema into OODB schema an important task andconsiderable effort has been seen on this topic [1,8]. Allstudies done so far focus on examining keys and key-based inclusion dependency (IDs) [6] to identify classesand derive inheritance and association between classes.Such transformation scheme usually results in classeshaving the same flat structure as the original relationschemas. In our view, however, this kind of class struc-ture fails to make use of the OO modeling power to thelargest extent and has not eliminated the data redun-dancy and update anomaly problem existing in the originalRDB schema. Example 1 below explains the notion of classstructure.

Example 1. Given a relation schemaService, key isunderlined, and multi-valued dependency (MVDs) andIDs on the schema are explicitly listed (Later discussionsfollow the same style).

Service(flight; working-day; plane-type):{ flight !! working-day, flight!! plane-type}

An example relationserviceover the schema is shown inTable 1. Owing to the MVDs, data redundancy and updateanomaly is obvious inservice: The same value forflight isrepeated four times and so when it is updated, four tuples areaffected.

How are we going to transformServiceinto a class? Themost direct approach is as follows:

class Service-1 (

flight: int,working-day: string,plane-type: int

);

With this class definition, corresponding to each tupleof relation servicewe have an object in classService-1(Table 2). In Table 2 each row represents an object andobject identifiers (OIDs) are explicitly listed. However,data redundancy of the original relation is retained.When we update the value ofplane-typefor object O1

from 747 to 727, to maintain the MVDs holding onService, we must change the value ofplane-type forobject O2 accordingly. In other words, with suchschema transformation, we must use the methodmechanism of the OO model to enforce the MVDs ofthe relational model.

Information and Software Technology 41 (1999) 275–281

0950-5849/99/$ - see front matterq 1999 Elsevier Science B.V. All rights reserved.PII: S0950-5849(98)00126-8

* Corresponding author. Department of Computer Science, University ofMelbourne, Parkville VIC 3052, Australia.

E-mail address:[email protected] (X. Zhang)

A more appropriate class structure for this transformationis as follows:

class Service-2 (

flight: int,working-day: set(string),plane-type: set(int)

);

As shown in Table 3, under this class definition, there areonly two objects in the resulting class. Objects are no longerin 1 : 1 correspondence with tuples of the original relation,instead, an object is the composition of several tuples. Noinformation is lost, but the data redundancy of the originalrelation is completely removed. When we change the valueof eitherplane-typeor working-dayof one object, only thatobject itself is affected. The MVDs onServiceare built intothe class definition and enforced by that attributesworking-dayandplane-typeare defined to be set-valued.

Comparing the two classesService-1 and Service-2defined over the same attribute set, we say they are of differ-ent structures. Moreover, we sayService-2is well-struc-tured butService-1is not.

Organization of the paper is as follows: in Section 2 wedefine well-structured class and propose a theorem onconstructing well-structured class from relation schema. Inlater discussions, when confusion does not arise, relationschemas will simply be called relations. In Section 3,based on MVDs, a composition process is proposed tofirst simplify the relational schema before the real trans-formation. Based on keys, key-based IDs, and MVDs, analgorithm is proposed mapping RDB schema intoequivalent well-structured OODB schema. Section 4 is theconclusion.

2. Constructing well-structured class

Let us first examine the semantics of an attribute taking aset of values from its domain. Given a classC, assume thatthere are two objects inC (Table 4).

classC (

A1: set(char),A2: set(int),A3: set(char)

);

As each object independently takes a set of values from itsdomain, when we ‘‘flatten’’C so that each attribute takes asingle value from its domain, we get eight combinations ofattribute values, as shown in Table 5. Ignoring the explicitlylisted OIDs, we can consider the eight rows of Table 5 aseight objects of the following classC0:

class C0 (

A1: char,A2: int,A3: char

);

However, to ensure thatC0 expresses set-valued attributescorrectly, we must also use the method mechanism. Inaddition, C0 has obvious data redundancy whileC doesnot. This notion is expressed in the following definitionand proposition.

Definition 1. A classC with attributesA1,…,An, is well-structuredif and only if (iff) Ai (1 # i # n) is defined as set-valued when there exist objects ofC taking 2 or more valuesfor Ai from its domain, independently of any other attributeAj (1 # j # n and j ± i).

An OODB schemaC consisting of a set of classes, whereC � { C1C2, …,Cn}, is well-structured if each classCi [ C;1 # i # n, is well-structured.

X. Zhang et al. / Information and Software Technology 41 (1999) 275–281276

Table 1Relationservice

Flight Working-day Plane-type

106 Monday 747106 Thursday 747106 Monday 1011106 Thursday 1011204 Wednesday 707204 Wednesday 727

Table 2ClassService-1

Oid Flight Working-day Plane-type

O1 106 Monday 747O2 106 Thursday 747O3 106 Monday 1011O4 106 Thursday 1011O5 204 Wednesday 707O6 204 Wednesday 727

Table 3ClassService-2

Oid Flight Working-day Plane-type

O1 106 {Monday, Thursday} {747, 1011}O2 204 {Wednesday} {707, 727}

Table 4ClassC

Oid A1 A2 A3

O1 {a} {1, 4} {x, y}O2 {a, c} {1} {s, t}

Proposition 1. A classC is without data redundancy iffCis well structured.

Schema transformation is a ubiquitous concept in data-base design [2]. In transforming a source schemaS into atarget schemaT, whereS and T may be of the same ordifferent data models, we should ensure the equivalencebetweenS and T, denoted asT , S. Equivalence in ourcontext is attribute value equivalence between the sourceand the target, which follows the generic equivalence defi-nition of [3].

A RDB schema is a pairkR, Sl, where R is a set ofrelations, andS are the integrity constraints defined onR.An OODB schema consists of a set of class definitions. Atthe present stage of the OO technology, integrity constraintsare more or less maintained by methods. In transforming aRDB schema into an OODB schema, we should try toexpress the constraints on the original relations as muchas possible with the OO modeling power itself but not resortto methods.

If we now think of Table 5 as a relation over schemaR(oid: int, A1:char, A2:int, A3:char), where we assumeOID is of int type. We find that the following MVDs holdon R

oid !! A1, oid !! A2, oid !! A3

This means that in a classC, if an attributeA is set-valued,oid!! A. Conversely, in schema transformation from RDBto OODB, when an MVDM holds on the original RDBschema, each object should take a different value for theattributes on the left-hand side (l.h.s.) ofM and multiplevalues for the attributes on the right-hand side (r.h.s.) ofM. So in the resulting definition, the l.h.s. attributes shouldbe single-valued whereas those on the r.h.s. should be set-valued. Classes thus formed are not only equivalent to theinput relations but are also well-structured. In example 1,assuming that the MVDs are enforced by methods, bothclass Service-1and Service-2are equivalent to relationService. However, Service-2 is well-structured butService-1is not.

Let us first introduce the notations that will be used inlater discussions. Given a relation schemaR,

• let R(X:DX, Y:DY, Z:DZ) denote thatX, YandZ are subsetsof R taking domainsDx, Dy andDz respectively, andR�X < Y< Z. Not considering the domains ofX, Yor Z, R is

simply written as R(XYZ). Similar notation is alsoadopted for classes.

• r(R), or simplyr, is the relation overR. ForX # R, r[X]denotespX(r).

Theorem 1. Given a relation R(X:DX, Y:DY, Z:DZ):{ X!! Y, X !! Z}, a composite classC defined in thefollowing is well-structured andC , R, wherey andz areattributes referring to a set of objects ofCy andCz, compo-nent classes ofC.

class C(

X: DX,y: set(Cy),z: set(Cz)

);class Cy(

Y: DY

);class Cz(

Z: DZ

);

Note that when Y(Z) consists of a single attribute,Cy(Cz) is then an atomic data type. As a result,y(z)becomes set-valued atomic attribute ofC and we donot need to define component classCy(Cz) by ourselves,which is the case with classService-2mapped from relationServiceof Example 1.

Proof. To mapR into classC, let us first decide the struc-ture ofC. Obviously each object ofC has a differentX value.As X !! Y(X !! Z), a set ofY(Z) values is uniquelydetermined by the OID of an object. Thus when transform-ing R into a classC, X should be single-valued, bothYandZshould be set-valued. As set-value is only for single attri-bute, component classes [4]Cy andCz are defined onYandZand we define attributes referring to a set of objects ofCy

andCz. ClassC and its component classesCy andCz result-ing from the aforementioned construction process are well-structured.

Let r be a relation onRandr[X] � X, r[Y] � Y, r[Z] � Z,map this relationr to a classC as follows:

(i) For eachy [ Y, create an objectOy in Cy with OyY� y.(ii) For eachz [ Z, create an objectOz in Cz with OzZ� z.(iii) Under X!! Y and thusX!! Z, assume that foreachx [ X the set ofY andZ values determined byx isdenoted asYx andZx:

Y x � pYs“X�x ” �r�; Z x � pZs“X�x ” �r�

X. Zhang et al. / Information and Software Technology 41 (1999) 275–281 277

Table 5FlattenedC

Oid A1 A2 . A3

O1 a 1 xO1 a 1 yO1 a 4 xO1 a 4 yO2 a 1 sO2 a 1 tO2 c 1 sO2 c 1 t

For eachx [ X, create an objectO in C with

O·X� x,O·y� { Oy [ Cy u Oy·Y � y, y [ Yx},O·z� { Oz [ Cz u Oz·Z � z, z [ Zx}

For a tuplet [ r with t�X� � x ; t�Y� � y ; t�Z� � z, itscorrespondence inC is an objectO [ C, whereO·X� x,O·y·Y� y, O·z·Z� z. Conversely in a similar way eachobject of classC, Cy andCz can find a counterpart in relationr. SoC, R.

We can see from the transformation process that no dataredundancy exists in the resulting classes. In classC no twoobjects have the sameX values,y refers to a set of objects inCy, andz refers to a set of objects inCz. With Cy andCz, nodata redundancy exists for the values ofY or Z: eachY or Zvalue appears in only one object.

Example 2. Given a relationr2 (Table 6) on schemaR2:

R2(A1 : int; A2 : char; A3 : char; A4 : char):{ A1!! A2 A3, A1!! A4}

R2 is transformed into classC2 and component classC20, as

shown below. Objects ofC2 andC20 are shown in Tables 7

and 8.

classC2(

A1: int,a2: set(C2

0),a4: set(char)

);classC2

0(

A2: char,A3: char

);

3. Transforming relations into well-structured classes

The analysis in Section 2 results in a complete transfor-mation process from RDB schema to a well-structuredOODB schema. Before starting the transformation, apreprocesscompositionis needed. The rationale is givenin the following.

3.1. Composition

When nontrivial MVDs hold on a relationR, to reducedata redundancy,R is often decomposed into several rela-tions in 4NF where only trivial MVDs hold [5]. In view ofschema transformation, however, this decomposition willonly blur the semantic interpretation of relations andincrease the number of classes in the target OODB schema.So, before proceeding with the transformation, we shouldrecompose the relations resulting from this decompositioninto one relation.

Theorem 2. For a relationr1 over schemaR1(XY): X!!Y, and a relationr2 over schemaR2(XZ): X!! Z. If r2[X] �r1[X] , we can construct a relationr � r1 n r2 over schemaR(XYZ):{ X!! Y, X!! Z} andR, { R1; R2}.

This theorem shows a composition process, a reverseprocess of lossless decomposition [5]. So its validity isobvious. In addition to preserve attribute values,R alsopreserves all the MVDs and IDs on {R1, R2}. Before startingwith schema transformation, in the input RDB schema, werepeatedly replace any pair of such schemas {R1, R2} withthe schemaR resulting from the composition processdescribed in Theorem 2. This composition and replacementprocess is denoted as

R:{M,I} ( compose(R1:{M1, I1}, R2:{M2, I2})

With this expression we state explicitly that the MVDs(M1

andM2) and IDs(I1 and I2) on R1 andR2 are maintained byR(M and I) resulting from composition.

Example 3. Given two relationsservice-day(Table 9) andservice-plane (Table 10) on schemasService-dayandService-plane:

Service-day(flight; working-day):{flight !! working-day}Service-plane(flight; plane-type):{flight !! plane-type}

To map these two relation schemas into OODB schema, we


Table 6Relationr2

A1 A2 A3 A4

1 a b x1 a b y1 a c x1 a c y2 b e s2 b e t

Table 7ClassC2

Oid A1 a2 A4

O11 1 {O21, O22} {x, y}O12 2 {O23} {s, t}

Table 8ClassC2

0

Oid A2 A3

O21 a bO22 a cO23 b e

first compose them into a single relation schemaService(Example 1),

Service(flight; working-day; plane-type):{flight !! working-day, flight!! plane-type}

and then transformServiceinto classService-2as discussedbefore.

3.2. Transforming RDB schema into well-structured OODBschema

The input RDB schema is assumed to be well defined [6]:only key functional dependencies and key-based IDs exist inthe RDB schema and the ID graph is a directed acyclicgraph. Some basic assumptions about keys and IDs are:

• Each relation is uniquely identified by its key. Given arelationR, KR denotes the key ofR.

• IDs describe direct subset relationship between two setsof values: if two IDs have the same l.h.s., then at least oneof them have an ID in the opposite direction and thusexpresses its equivalence with its r.h.s. For example,given two IDs I1 and I2, I1: r1[X] # r2[X] , I2: r1[X] #r20[X] , then one of them, suppose it isI2, have a reverse

ID I20: r2

0[X] # r1[X] . In this case,I2 andI20 together are

simply denoted asr1[X] � r2’[X] .

Under these assumptions, when the composition processdescribed in Section 3.1 completes, each ID has a clearsemantic interpretation and so each relation is uniquely clas-sified. Given a relation schemaR,

• R is a base relation if¡'R1 s.t. r[KR] # r1[KR1].• if there exists only oneR1 s.t. KR1 � KR and r[KR1]

# r1[KR1], each tuple inr(R) has a correspondent inr1(R1) but the converse does not hold. We sayR is aspecializingrelation that specializesR1. R1 is denotedas rhs(R).

• if there exists only oneR1 s.t. KR1 , KR andr[KR1] #r1[KR1], R is a dependentrelation whose identificationdepends onR1. R1 is denoted asrhs(R).

• R is acomposite relationif R is neither base nor depen-dent, i.e.,

• 'R1,…,Rm s.t. KR1 < … < KRm # KR(m $ 2) andr[[KRi]] # r i[KRi] for 1 # i # m.

• { R1,…,Rm} is denoted asrhs(R).

Given a relationR(A1:D1,…An:Dn), without losing general-ity, assume that keys and IDs are defined on the first severalattributes. Key and ID constraints help to classify relations,identify classes and establish inheritance and associationbetween classes. Different transformation rules are formedbased on the type ofR:

(a) R is a base relation, it becomes a class:

C(A1:D1,… An:Dn) which is the base of an inheritancehierarchy.

(b) R is a specializing relation that specializesR1:R(KR1, As:Ds, …, An:Dn). This specialization is theisa relationship [4] in OO model. Assume thatR1

was transformed into classC1, R then becomes a subclassof C1:

C(As:Ds…,An:Dn) as subclass ofC1

(c) R is a dependent relation (semantically a weakentity) depending on R1: R(KR1, As:Ds,…An:Dn).Assume thatR1 becomes classC1, R is then transformedinto

C(A1: C1, As:Ds,…, An:Dn)

(d) R is a composite relation:R(KR1,…, KRm, At:Dt,..,An:Dn). R describes some relationship betweenR1,…,Rm. Assume thatR1,…, Rm becomesC1,…, Cm in the targetOODB, R is then transformed into a class describing anassociation betweenC1,…, Cm:

C(B1:C1,…,Bm:Cm,At:Dt,…,An:Dn)

The above transformation rules only define attributesand its domains for a class. We should also definemethods enforcing the relational key, ID and otherintegrity constraints. For how to define these methods,please refer to [7]. To further remove the data redun-dancy and update anomaly of the original relationalschema, we must determine the structure of each class. Tothis end, the MVDs of the original relations must also beexamined. The composition process in Section 3.1 and themapping rules in Section 3.2 results in a detail transforma-tion algorithm.

Algorithm T. Transform a well-defined RDB schema intoa well-structured OODB schema.

Input: A well-defined RDB schemakR, Sl. R � { R1,R2,…, Rn} andS � F < I < M, whereF, I, M are setsf FDs, IDs and MVDs.

Output: A well-structured OODB schemaC , R.Begin// Step 1: Composition and replacement


Table 9Relationservice-day

Flight Working-day

106 Monday106 Thursday204 Wednesday

Table 10Relationservice-plane

Flight Plane-type

106 747106 1011204 707204 727

while('{ R1 [ R:{ M1�X!! Y1, I1},R2

[ R:{ M2�X!! Y, I2} s.t. r1[X] � r2[X]) do

R:{ M, I} ( compose(R1:{ M1,I1}, R2:{ M2, I2});

end while// Step 2: Classify the input relations.ClassifyR according toF andI, resulting in base rela-tion setB, specializing relation setZ, dependent rela-tion setD and composite relation setP.// Step 3: Construct base classes.for (eachR [ B) do

transformR:{ M [ M} into classC according to rule a)and Theorem 1;

end for// Step 4: Repeatedly transform relations inZ, D, P intoclasses.repeat {

// Step 4.1: Dealing with specializing relation.for(eachR[ Z whererhs(R)was transformed into classC1) do

transformR:{ M [ M} into classC as a subclass ofC1

according to rule b) and Theorem 1;let Z � Z 2 {R};

end for// Step 4.2: Dealing with dependent relation.for(each R [ D where rhs(R) was transformed intoclassC1) do

transformR:{ M [ M}into classC according to rule (c)and Theorem 1;let D � D 2 { R};

end for// Step 4.3: Dealing with composite relation.for(each R [ Pwhere rhs(R) � { R1,…,Rm} andR1,…,Rm becomeC1,…,Cm) do

transform R: { M [ M} into class C referencingC1,…,Cm according to rule (d) and Theorem 1;let P � P 2 { R};

end for

} until ( Z � D � P � B )

End

As the ID graph is acyclic, algorithm T definitely ends.Each relation inR is processed only once and all the result-ing classes are constructed according to theorem 1, so theresulting OODB schemaC is well-structured andC, R.

Theorem 3. Given a RDB schemakR, Sl, the OO schemaC resulting from Algorithm T is well structured andC, Rw.r.t. S.

The aforementioned transformation process can befurther explained with a representative example below.

Example 4. Look at the following RDB schema. Keys areunderlined.I � { Iiui � 1, …,9} and M � { M1, M2, M3}denote the IDs and MVDs. For simplicity,I9 denotes 3pairs of IDs of opposite directions.

Course(code: varchar�6�, title: varchar(20))Person(ssn: int, name: varchar(10), sex: char)Staff(ssn: int, staff-id: int, dept: char(2))Staff-dependent(stf : int; ssn: int, name:varchar(10),relationship: varchar(10))Student(ssn: int, sno: int, prog: varchar(10))Lecturer (course: varchar�6�; stf : int): {M 1� course!! stf}

Course-stud(course: varchar�6�; stud : int): {M 2 �course!! stud}Sched(course: varchar�6�; hour : varchar�7�; room :

varchar�5�): {M 3 � course!! hour, room}I1: Staff[ssn]# Person[ssn]I2: Staff-dependent[stf]# Staff[ssn]I3: Student[ssn]# Person[ssn]I4: Lecturer[course]# Course[code]I5: Lecturer[stf] # Staff[ssn]I6: Course-stud[course]# Course[code]I7: Course_stud[student]# Student[ssn]I8: Sched[course]# Course[code]I9: Lecturer[course]� Course-stud[course]� Sched[-course]

Step1. Composition and replacement.

With I9 and M1, M2, M3, the composition process can beapplied toLecturer, Course-studandSched:

Schedule:{M1, M2, M3} ( compose(Lecturer: {M1},Course-stud: {M2}, Sched: {M3})

We have Schedule(course; hour; room; stf; stud) andI50 ( I5, I7

0 ( I7, I ( { I4, I6, I8}:

I50: Schedule[stf]# Staff[ssn]

I7’: Schedule[stud]# Student[ssn]I: Schedule[course]# Course[code]

Now we have five relations: Course, Person, Staff, Staff_-dependent, Student, and Schedule.I � { I1, I2, I3, I5’, I7’, I}.M � { M1, M2, M3}, where M1, M2, M3 are defined onSchedule.

Step 2. Classification. According to relation keys andI,Person and Course are base relations.Staff and StudentspecializePerson. Staff_Dependentis a dependent relationof Staff. Scheduleis a composite relation.


Step 3. Base class construction. According to rule (a),CourseandPersonare transformed into base classes:

classCcourse (

code:string,title:string

);classCperson (

ssn:int,name:string,sex:char

);

Step4.1. Constructing subclasses. According to rule (b),StaffandStudentbecome subclasses ofCperson.

classCstaff as subclass of Cperson (

staff-id: int,dept: string

);classCstudentas subclass ofCperson (

sno: int,prog: String

)

Step 4.2. Create class for dependent relation. Accordingto rule (c), Staff_dependentis mapped into classCstaff-dependent:

classCstaff-dependent(

stf: Cstaff,ssn: int,relationship: string

);

Step4.3. Establishing association between classes.According to rule (d) and Theorem 1,Schedulebecomes

classCschedule:

classCschedule (

course: Ccourse,hour-room: set(Chour-room),staff: set(Cstaff),student: set(Cstudent)

);

classChour-room(hour: string;room: string;

);

The final OODB schema consists of the seven classes asdefined earlier.

4. Conclusion

In transforming RDB schema into OODB schema, whilekey and key-based IDs are critical for identifying classesand establishing inheritance and association betweenclasses, MVDs are important for defining well-structuredclasses. A well-structured class is not only equivalent tothe original relation schema but also remove the originaldata redundancy. However, not much work was seen onthis topic.

In this article, we propose the notion of class structure anddefine well-structured class. Based on MVDs, a theorem isgiven on transforming a relation schema into an equivalentwell-structured class. In transforming RDB schema intoOODB schema, a composition process is proposed to reducethe input RDB schema. All the analysis above helps toproduce an algorithm that completes the transformationfrom RDB to OODB schema. Theorems are given toprove that the transformation is information-preservingand the resulting classes are well-structured.

Acknowledgements

The authors would like to thank the anonymous refereesfor their valuable comments.

References

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

[2] J.-L. Hainaut, C. Tonneau, M. Joris, M. Chandelon, Transformation-based Database Reverse Engineering, in: R. A. Elmasri, V. Kourama-jian, B. Thalheim (Eds.), Entity Relationship Approach – ER’93,LNCS 823, Springer, Berlin, 1993, pp. 364–375.

[3] R. Hull, Relative information capacity of simple relational databaseschemata, SIAM J. Comp. 15 (3) (1986) 856–886.

[4] W. Kim, Introduction to Object-Oriented Databases, MIT Press,Cambridge, MA, 1990.

[5] D. Maier, The Theory of Relational Databases, Computer SciencePress, Rockville, MD, 1983.

[6] K.-J. Raiha, H. Mannila, The Design of Relational Databases, Addison-Wesley, Reading, MA, 1992.

[7] B. Narasimhan, S.B. Navathe, S. Jayaraman, On mapping ER andrelational models into OO schemas, in: R.A. Elmasri, V. Kouramajian,B. Thalheim (Eds.), Entity Relationship Approach – ER’93, LNCS823, Springer, Berlin, 1993, pp. 402.

[8] L.-L. Yan, T.-W. Ling, Translating relational schema with constraintsinto OODB schema, in: D.K. Hsiao, E.J. Neuhold, R. Sacks-Davis(Eds.), Interoperable Database Systems, Elsevier, Amsterdam, 1993,pp. 69–85.


Documents

Transforming RDB schema into well-structured OODB schema