Relational Databases

Investigation into the Techniques for Converting Relational Databases into Object-Oriented and ObjectRelational Databases

Abdelsalam M. Maatuk Msc computing Northumbria University 2004

Supervisor Dr Akhtar Ali

Contents Acknowledgements……………………………………………………..….……..………

vii

Abstract……………………………………………………………………….……...…… viii Chapter 1: introduction…………………..………………………………..……………

1

Background………………………………………………………………………………..

3

Project idea………………………………………………………………………..….…..

5

Project objectives………….…………………………………………………….………..

5

Dissertation outline…….…………………………………………………………..……..

5

Chapter 2: Comparative study of relational, object-oriented and object-relational databases ……………………………………………………………….………………..

7

Relational databases …………………………………………………….…………….…

9

Constraints………………………………………………………….……………...….

9

Primary and foreign keys………………………………………….…………….……..

10

Domain…………………………………………………………………………..….....

10

Standardization of SQL………………………………………………………………..

11

Advantages and disadvantages of relational databases………………………………..

12

Object-oriented databases ………………………………………………………….....….

12

Standardization and the ODMG………………………………………………...……..

13

Comparison of object and relational ………………………………………………...…

14

Advantages and disadvantages of object-oriented databases……………………...…...

14

Object-relational databases ……………………………………………………….……..

15

Advantages and disadvantages of object-relational databases…………………..……..

16

SQL3…………………………………………………………………………..………..

16

Comparison of object-oriented and object-relational databases….…………………….

17

Stonebraker's view ………………………………………………………..……………

17

Errors in Stonebraker's view ………………………………………….…..……………

18

The differences between the three types of databases…………………………………….

19

Summary ………………………………………..……………………………………......

20

ii

Contents Chapter 3: Schema conversion techniques………………………….…….……………

21

Converting relational database into object-oriented database schema…….……..……..…

22

Mapping relational data types into object types and relational table definitions to object classes……………………………………..…………….………………………….

24

Mapping attributes………………………….……………………………………….….

27

Mapping relationships (association attributes) ……………………………….........…..

27

Mapping a weak entity………………………………………………………..………...

30

Mapping inheritance…………………………………………………………………....

31

Converting relational database into object-relational database schema…………………..

32

Defining types…….…………………………………………………………………….

36

Defining collection types…………………………………………………………….....

37

Defining reference type…………………………………………………………………

38

Creating object tables…..……………………………………………………………….

39

Defining sub-type and super-type…………………………………………………...….

40

Summary ………………………..………………………………………………………… 41 Chapter 4: Methodology for converting a relational database schema………………

42

Converting a relational into an object-oriented database schema………………………....

43

Mapping the relation and its attributes into the OO schema……………………………...

44

Relationship relation……………………………………………………………..……. 44 Main relation……………………………………………………………………..........

45

Mapping attributes…………………………………………………………...…….….. 46 Mapping relationships……………………………………………………………..….…..

46

Association……………………………………………………………………….……

46

Aggregation ………………………………………………………..………………….

48

Inheritance……………………………………………………………..…………........

49

Converting a relational database into an object-relational database schema……..……….

50

Mapping relations into object-types………………………………………………………

51

iii

Contents Relationship relation…………………………………………………..……………….

51

Weak relation………………………………..……………………..………………......

51

Inheritance……………………………………………………….……………..……...

52

Main relation……………………………………………………..…………………..… 53 Mapping binary relationships into object references……………………..…………….… 53 Identify object-relational tables………………………..………………………………….

55

Summary ……………………………..……………………………………………...……

56

Chapter 5: Design and implementation of the prototype…….……………………….

58

Strategic design……………………………………………………..…………………….

59

Source to source schema script translator ……………………….…………………….

59

Working on a real database using data dictionary tables ………………….………….

61

Architectural design…………………………………….…..………….………………….

61

Details of the design………………………………………………………..………..…....

62

Summary ………………………………..……………………………………………...…. 70 Chapter 6: Evaluation of the prototype………………………………………………… 71 Converting an RDB in-memory into an equivalent OO in-memory structure….……..….

78

Identifying OO classes, their kinds and parents……………………………….………..

78

Identifying the OO class attributes……………………………………………..…...….

79

Identifying OO class relationships………………..…………………………………….

80

Converting an RDB in-memory into an equivalent OR in-memory structure……..……...

84

Identifying object types, their kinds and parents……………………………..………....

84

Identifying an object-type‟s attributes and domains………………………..….…..……. 84 Identifying object-type relationships using collections………………………...………..

86

Identifying OR object tables……………………………………………………..……… 87 Summary ………………………..…………………………………………..…………….

89

Chapter 7: Evaluation of the project / approach…………………………..………….

90

iv

Contents Conversion methodology…………………………………………………..….………….

93

Mapping attributes…………………………………..……………………..…………..

93

Mapping aggregations……………………………………………….……....................

94

Mapping inheritances………………………………………….…..…………………...

94

Mapping associations………………..………………………………….……..……….

95

Summary ……………………………..………………….…………………..........……..

96

Chapter 8: Conclusions and recommendations………………………………..……...

98

References and bibliography ……..…………………………………………….……..

102

v

List of figures: Figure 2-1: Database system environment…………..……………………....…………….

10

Figure 2-2: A sample of relation ……………………………………………..…………… 11 Figure 2-3: Stonebraker‟s DBMS Matrix for classifying DBMS applications……..……..

18

Figure 2-4: Modified DBMS Matrix for classifying DBMS applications……………..….. 18 Figure 3-1: Entity relationship diagram for purchase order application……………..…....

33

Figure 3-2: Class diagram for purchase order application…………………....….…...…...

35

Figure 5-1: The overall architectural design……………………………………..………..

62

Figure 5-2: Principle architectural of an RDB in-memory structure………………..…….

63

Figure 5-3: Pseudo-code algorithm for reading a database to construct an RDB inmemory structure………………………………………………………………………….

64

Figure 5-4: Pseudo-code algorithm of an RDB in-memory structure……………………..

65

Figure 5-5: Principle architectural of an OO in-memory structure…………………....…..

66

Figure 5-6: Principle architectural of an OR in-memory structure…………………….….

67

Figure 5-7: Pseudo-code algorithm of an OODB in-memory structure………………..….

68

Figure 5-8: Pseudo-code algorithm of an ORDB in-memory structure……………….......

69

Figure 6-1: The company_rel relational database schema…………………….….….……

76

Figure 6-2: Sample of vectors of an RDB in-memory structure…….………….….……...

77

Figure 6-3: The construction of vectors for DEPT table in the RDB in-memory structure.

77

Figure 6-4: Pseudo-code algorithm for specifying relationship by querying data…….......

80

Figure 6-5: Relational tables………………………………………………………………. 81

List of tables: Table 2-1: A comparison of database management systems……..……...………..………

vi

19

Acknowledgements

I would like to thank all those who have helped me with this work. Firstly, I would like to thank my parents for their encouragement and prayers for me. I would like to thank my wife and my children for their support and patience during this course. Special thanks go to my supervisor, Dr. Akhtar Ali, for his advice and guidance while working on this dissertation.

vii

Abstract Due to the use of object-oriented technology in software development, the demand for converting relational databases into their equivalent object-based databases appears to improve productivity and flexibility. The conversion process consists of schema, data and programs conversion. This dissertation describes a methodology for converting a relational database into an object-based database schema. The methodology unifies previous techniques into a single conversion process. This research talks briefly about relational, object-oriented and object-relational databases as a comparative study, discusses and investigates previous research into migrating schemas, and then produces a new methodology to extract a static structure for an object-based schema from the relational schema, where the static structure is defined by its properties (attributes and relationships). The new methodology facilitates the analysis of the advantages and disadvantages of previous techniques of migrating schemas and develops an integrated technique, which converts a relational database including constraints into an objectoriented and an object-relational schema. The integrated technique consists of a set of conversion rules. The methodology uses data dictionary tables to get information about tables, their attributes and constraints. Also, it uses key constraints and queries the data stored in the database to identify classes/object-types and relationships amongst them. The study considers the use of the Object Definition Language (ODL) of the ODMG standard as syntax for an object-oriented schema, and SQL keywords supported by Oracle9i as syntax for an object-relational schema. The methodology is supported by a prototype, which interacts with an Oracle 9i database using JDBC. The prototype constructs an in-memory representation of a given relational database. It then constructs an in-memory object-oriented (OO) and object-relational (OR) mapping of the inmemory relational representation. The in-memory OO and OR representations are then used to automatically generate an OO and OR database schema. The dissertation illustrates the integrated methodology using detailed examples. This dissertation recommends that issues such as data conversion, data specific manipulating operations (i.e. update/query) should be studied in detail to expand the methodology into a complete database migration package. Moreover, further prototyping is recommended to resolve attribute/relationship naming conflicts. viii

CHAPTER ONE INTRODUCTION

Chapter 1

Introduction

Chapter 1 Introduction Because of their simplicity, relational databases have become the standard solution for storing and retrieving data rapidly. However, relationships between tables cannot be extracted without the user‟s aid. To overcome the drawbacks of relational databases and to improve productivity and flexibility, the migration of existing relational into objectbased database schema has come an interesting issue. Because of its semantic richness and flexibility in modeling, the object-based data model is usually selected as the appropriate data model. Migration schemas are discussed by several significant reviews of research. The common motivation of converting schemas is to superimpose an object model on a relational model. Primary keys and foreign keys based on an inclusion dependency are used to identify classes/object-types and relationships amongst them. The mapping process is not simple, and therefore usually faces problems such as, the nonequivalence of the two database concepts. The conversion involves schema, data and programming conversion. However, the aim in this research is to investigate and consider different migration techniques to produce a method for conversion of an RDB schema into OODB/ORDB schemas without loss of data. This research will firstly talk briefly about three types of databases, which are relational databases (RDBs), object-oriented databases (OODBs) and object-relational databases (ORDBs) as a comparative study, focusing on their advantages, disadvantages and the relationships between them.

Secondly, previous significant researches into

migration schemas techniques will investigate. Then, a new methodology will be presented to construct a static structure of an object-based schema from the relational one. A set of conversion rules will be applied during the process. To demonstrate this methodology, a prototype will be developed to interact with Oracle 9i database using JDBC to construct an in-memory structure of relational tables with their constraints. Then, by applying related target schema converting rules, the system will re-construct the source structure to build up a new target in-memory structure. Moreover, data dictionary A. M. Maatuk

2

Chapter 1

Introduction

tables will be queried to get information about tables, their attributes and constraints, and data stored in the database will be queried to identify relationships amongst objects. In addition, the new structure will be translated to generate an object-based script automatically. Finally, the prototype is presented using our method and examples are giving to illustrate how the method achieves our objectives. The main features of this method involve the following: 

Identify an existing an RDB to generate both an OODB and ORDB schema.



Propose an intermediate representation containing the RDB information as a source to avoid accessing RDB twice during the migration process.



Consider integrity constraints such as functional dependency and inclusion dependency.



Query data stored in the database to identify relationships amongst objects.



Consider ODL of ODMG-standard group as the syntax for an OODB schema and SQL keywords supported by Oracle9i as the syntax for an ORDB schema.



Propose a prototype to produce a target object-based script automatically.

1.1 Background There are many different types of database systems available, from the traditional RDBs to OODBs [Connolly and Begg, 2002]. The RDB models and OO model are fundamentally different [Elmasri and Navathe, 2000]. RDBs use tables to store data and by comparing values stored in these tables can determine the associations between data. On the other hand, the OO model supports features such as encapsulation, inheritance and polymorphism. ORDBs use a data model that incorporates RDBs into OODB benefits, therefore, it stores data in tables having rows and columns. In addition, it is also designed to achieve object model features such as scalability and rich data type support abstract data type (ADTs). ORDBs support features such as complex objects, base data types, inheritance and active rules.

A. M. Maatuk

3

Chapter 1

Introduction

Different trends can be seen throughout software development, where ways of using and programming computers have changed dramatically. Consequently, there is interest in and demand for mapping an RDB into OODB and ORDB schemas in order to gain and improve productivity and flexibility. An object-based representation of an existing RDB gives the user a chance to specify missing semantics that may not be specified in relational schema. The Mapping procedure is not straightforward, and usually faces inconveniences such as the non-equivalence of database concepts. Mapping schema tasks will need various techniques which may differ depending on the data dependency considerations. Most work on mapping schemas considers functional dependency and inclusion dependency to identify classes/object-types and their relationships, for example, inheritance, aggregation and association relationships. However, some work is not detailed further, for example, the failure in entity fragmentation and ISA relationship consideration [Yan and Ling, 1993]. Some research assumes that the source relational schema should be at least in second normal form (2NF) [Ramanathan and Hodges, 1997]. However, to remove the redundancy caused by multi-valued dependency (MVD), other methods consider a relational schema in a fourth normal form (4NF) [Xiuzhen et al., 1999]. The conversion involves schema mapping, data and programming conversion. However, we concentrate on the schema migration of an RDB with constrains to produce a static structure of an OODB/ORDB schema. This project aims to investigate current migration techniques and build up a new methodology for integrating and converting an RDB with constraints into the static structure of an object-based schema using certain conversion rules. No particular OO model is assumed in some methods, the ODL syntax of ODMG-standard has been used in others, and some researches recommend a C++ like syntax for model class structures. However, ODL of ODMG-standard as the syntax for an OO schema and an SQL keywords that supported by Oracle9i as a syntax for an OR schema are considered in our method. It is taken into account that, our method will be programmed to produce a target schema script, and therefore some object-based modelling features will be lost due to programming difficulties. A. M. Maatuk

4

Chapter 1

Introduction

1.2 Project idea The idea behind this project is to investigate different databases concepts through comparing differences between RDBs, OODBs and ORDBs. In order to discuss and investigate the current techniques for mapping database schemas so as to develop a methodology for the conversion of RDB schemas into OODB/ORDB schemas. Finally, a prototype is designed to implement our method giving examples to illustrate how the method achieves our goals, which in turn enables us to assess OO features such as dealing with complex applications.

1.3 Project objectives 1. A comparative study of RDBs, OODBs and ORDBs. 2. To review the advantages and disadvantages of RDBs, OODBs and ORDBs. 3. To study the techniques and methods used for converting RDBs, OODBs and ORDBs. 4. To develop an integrated method that should assemble different approaches into one approach for migration an RDB schema into OODB and ORDB schemas. 5. To demonstrate the new approach for converting an RDB into an OODB and ORDB, and to design a prototype to generate an object-based schema automatically. 6. To demonstrate how the methodology / prototype can be evaluated. 7. To evaluate the project / approach 8. To write the dissertation reporting the research in an academic way.

1.4 Dissertation outlines The rest of this dissertation is organised as follows: Chapter1: Introduction, background and project idea, brief review of the research and outlines of the dissertation. Chapter 2: A comparative study of RDBs, OODBs and ORDBs. A. M. Maatuk

5

Chapter 1

Introduction

Chapter 3: Critical review and analysis of existing proposals, techniques and methods for converting an RDB schema into OODB and ORDB schemas. Chapter 4: Development of integrated method to assemble different approaches into one approach. Chapter 5: Design and implementation of a prototype to demonstrate our methodology. Chapter 6: Evaluation of the prototype. Chapter 7: Evaluation of the project/approach focusing on any reflections and what other methods have been considered. Chapter 8: Conclusions and recommendations.

A. M. Maatuk

6

CHAPTER TWO COMPARATIVE STUDY OF RELATIONAL, OBJECT-ORIENTED AND OBJECT-RELATIONAL DATABASES

Chapter 2

Comparative study

Chapter 2 Comparative study of relational, object-oriented and objectrelational databases There are many different types of database systems available, from the traditional RDBs to OODBs [Connolly and Begg, 2002]. Different trends can be seen throughout software development, the way of using and programming computer has changed dramatically. Many analysts expect that an OO technology is going to become the main trend. RDBs and OODBs are fundamentally different models [Elmasri and Navathe, 2000]. RDBs use tables to store data, and by comparing values stored in these tables can determine the associations between data. The OO model supports an OO features such as abstract data types (ADTs), OID, encapsulation, inheritance and polymorphism. An ORDB systems support a relational model extended with OO features. Therefore, they have all relational database management system (RDBMS) features such as conceptual simplicity, and a standard query language, in addition to many of the OO features mentioned above. This chapter briefly describes the three types of database, discussing their advantages and disadvantages and their common features.

Database A database is a structured collection of data describing the characteristics of people and things. Between the physical database and the users of the system is a layer known as a database server or database management system (DBMS). The database is used by the application system and managed by a DBMS [Date, 2000].

Database management system (DBMS) A DBMS is a collection of programs that enables users to create databases and manipulate their data to translate it into information. There are many DBMSs, such as

A. M. Maatuk

8

Chapter 2

Comparative study

Oracle, DB2, and MS SQL server. DBMS is a shell surrounding one or more databases throughout various interactions such as data maintenance, data retrieval, and data control.

2.1 Relational databases A relational model was formally proposed by Dr. E. F. Codd in 1970 and developed later through some implementations by IBM and other companies. In the 80s, RDBMSs revolutionized data management and business information system. In relational databases, data is stored in two-dimensional tables, which are called (relations), and hence the name (relational database). Organising data into tables/relations is a logical view of how data is represented by DBMS. How data is actually stored (i.e. the physical view) is not visible to the user and is independent of the logical view. Each table consists of a number of rows (tuples) representing data, and columns (fields or attributes) representing data categories (i.e. integer, char, date, etc). Each attribute occupies one column and each tuple occupies one row. For example, a table might contain student data with columns representing first name, surname, address and course and each row of the table represents information about a specific student. Each tuple is uniquely identifiable and independent of other tuples in the same table. Database designers define tables according to business requirements to put related tables together to form a database [Cattell, 2000].

2.1.1 Constraints

There are some restrictions on the data that can be stored in such RDBs. These are called constraints, which avoid inconstancies of the tuples in a database. The kinds of constraints are key, entity integrity, referential integrity, and domain constraints. Constraints should be enforced by RDBMSs at each instance of insertion, updating or deletion of data to or from tables.

A. M. Maatuk

9

Chapter 2

Comparative study DATABASE system

Application Programs/Queries

DBMS Software

Software to Process Queries/Programs

Software to access Data

Database definition Meta-Data

Database

Figure 2-1: Database system environment, adopted from Elmasri and Navathe, 2000

2.1.2 Primary and foreign keys Each row in a table represents one tuple, where the order and position of rows is insignificant. Tuple must be unique. Uniqueness is achieved by having identifier. An identifier can be a single or a set of attributes. In relational data model, the identifier is called the primary key (PK). Each table must have a primary key. It is the database designer‟s job to determine the best candidate keys to extract primary keys from, and this often uses numbers (e.g. student_ID). A tuple in a table may refer to another tuple in the same or other tables. Reference can be in the form of one or a set of attributes. Attributes used for referencing to PKs are called foreign keys (FKs). 2.1.3 Domain The primary unit of data is a data item (e.g. student_ID). Such a data item is said to be atomic. A set of data items of the same type is called a domain. A. M. Maatuk

10

Chapter 2

Comparative study

Relation Name

Attributes

DEPT

Dept no D1 D2 D3 D4 D5

Tuples

Dept Name Production Sales Accounts Administration Personnel

Domain (£1-1m)

Manager No E5 Null E9 E8 E7

Budget 100,000 250,000 95,000 156,000 196,000

Relationships Represented Implicitly (by “Foreign Keys”)

EMP

Emp No

E7 E6 E5 ...

Emp Name McDougal Green Brown ...

Salary 20000 8000 18000 ...

Figure 2-2: A sample of relation adopted from databases module slices on, www.cgweb1.unn.ac.uk.

2.1.4 Standardization of SQL

Structured query language (SQL) was originally an IBM concept, and is therefore based on relational model. RDBMSs use SQL (usually SQL2) as data definition language (DDL) and data manipulation language (DML) [Connolly and Begg, 2002].

SQL

consists of certain statements such as SELECT, INSERT, UPDATE and DELETE for querying, inserting, updating, deleting and for constraints specifications. Furthermore, SQL has many query types for data manipulation of the field values of tuples from simple one table queries to complex multi tables, including nesting, join and union queries.

Today, there are hundreds of SQL products. Therefore, to overcome the differences amongst the different versions, international companies have developed standards for SQL such as ISO & ANSI, the Open Group and the SQL access group. The most important SQL standard is that which has been adopted by the International Organization for Standardizations (ISO) and the American National Standards Institute (ANSI) [Connolly and Begg, 2002].

A. M. Maatuk

11

Chapter 2

Comparative study

2.1.5 Advantages and disadvantages of relational databases

RDBMS programmers sometimes spend more than 25% of their coding time mapping program objects to database, according to Carl Olofson, program director of information and data management software for IDC [McClure, S, 1997]. Although RDBMSs have advantages of rapid data access and managing large storage capacity, and SQL standards provide the means to migrate database applications easily between database systems, they also have weaknesses and shortcomings in handling applications involving user-define data type such as images and videos. Moreover, they cannot handle application areas such as computed aided design (CAD), spatio-temporal databases, and other applications that involve complex data interrelationships.

2.2 Object-oriented databases The desire to manipulate complex objects and the development of object orientation technology and programming languages that support this has led to the development of object-oriented database systems (OODBS). OODBs are fundamentally different from RDBs since the latter are based on two-dimensional tables whereas OODB models are based on objects which have their own properties. Furthermore, the object model supports a tight integration of codes and data, flexible data types and hierarchal relationships between them, whereas each entity in the object model is called an object instance. OODBs work for data models that support data encapsulation, inheritance and polymorphism, which are properties held by all object-oriented software in addition to abstract data types (ADTs) [Connolly and Begg, 2002]. Abstract Data Types - ADT (also called user-defined types): The internal data structure is hidden and external operations can be applied to objects leading to encapsulation. Encapsulation: Code and data are packaged together to form objects and preventing them from other code defined outside.

A. M. Maatuk

12

Chapter 2

Comparative study

Inheritance: It concerns classes, which are derived from other classes. This is a powerful mechanism, which lets a child class inherit the attributes and operations (methods) of a previously defined parent class. Databases then have to manage object storage according to a class hierarchy. Polymorphism: Depending on run-time use of objects, this concept permits the same operator name to be bound to two or more different implementations of the operator. Object identification: Each object instance has a unique and unchangeable identifier (OID), which is used as a reference to an object. OIDs are independent of data contained and are generated by the object system. In addition, they are neither visible to the user nor change even though their contents have changed.

2.2.1 Standardization and the ODMG Until recently, the principle drawback of object-oriented database management systems (OODBMSs) was its lack of standards. Intensive efforts by Object Data Management Group (ODMG) has given the object database industry a “jump start” by proposing a standard known as the ODMG-93 or ODMG 1.0 standard, now revised into ODMG 3.0. The ODMG standard defines: 

Architecture for OODBMS



A data model which will take action as a logical model for OODBMS



The ODL, which is designed to support the semantic constructs of ODMG. ODL is used to create object specifications independently from any programming language.



The object query language (OQL), which is designed to work with ODMG binding programming languages such as C++ and Java. OQL provides an interface for posting ad hoc queries. ODL and OQL are based on the ODMG data model.



Number of bindings to OO programming languages like C++ and Java.

A. M. Maatuk

13

Chapter 2

Comparative study

QOL‟s syntax is similar to SQL with some additional OO features such as identity, ADTs, inheritance and polymorphism and which also supports constructed types like bags, sets and lists. ODL is similar to DDL in SQL with some additional features such as ADT definitions [Cattell, 2000].

2.2.2 Comparison of object and relational

RDBs are poor in stating the basic object features such as encapsulation, inheritance, polymorphism and user-defined data types. Therefore, OO approaches were developed which support the object model directly. Although the two approaches are fundamentally different, there are some similarities between them. For example, a relation is comparable to a class, nevertheless, it does not have the inheritance feature, which classes do. A tuple is like an object. Objects can have any data supported by OO languages, whereas a tuple has a restricted data structure. A column is similar to an attribute. Attributes can hold any OO language data-type, nevertheless, a column has a limited data-type. Finally, operations (methods) supported by OODBMSs are entirely different from stored procedure in RDBMSs.

2.2.3 Advantages and disadvantages of object-oriented databases OODBs are suitable for use with applications that deal with complex relationships along with data objects, and due to their convenience in the Internet age, ability to handle various types of multimedia and supporting OO technology; industry observers have widely touted OODBs. There will be fewer mismatch difficulties, when an OO programming language is implemented on OODB systems. Moreover, it was predicted that OODBMS will become the basic database technology, superseding RDBMS. Rick Cattell, distinguished engineer at Sun Microsystems, has indicated that, “Object-oriented databases are doing just fine, and the news of their demise is highly exaggerated. While their market [share] isn‟t as big, they continue to be used in areas like CAD (computeraided design) and telecommunications, where RDBMSs are not well suited” [Ramakanth, 2001]. OODBs are practical in removing the redundancy of data and update anomaly A. M. Maatuk

14

Chapter 2

Comparative study

problem which bring into being in existing relational database systems. The ODMBS‟s results are a lesser amount of code to develop, decreased development time and maintenance expenses. On the other hand, OODBMSs do have drawbacks too. Their query optimization is very complex, there are scalability problems and they are not able to support large-scale systems; need skilled users to manage data, as it is not understood as relational. They lack of a standard ad hoc query language. In addition, the increased functionality provided by OODBMS such as in schema evaluation and nested transaction, is naturally more complex than that of an RDB.

2.3 Object-relational databases An OR data model is an extension of the relational one. It provides ADTs including complex data structures, encapsulation, inheritance and OID. The OR model is relatively recent, nevertheless, it is not a new technology in its own right. It is a merging of relational and object-oriented models. An ORDB technology is showing potential, because it has a relational technology base and appends object features. The main goal of its design was to incorporate both relational and OO model features, such as scalability and support for rich data types. Together with handling alphanumerical data types, ORDBs can handle video, audio and multimedia data types. Furthermore, the development of ORDBs was triggered by the growth of OO programming languages and to avoid the mismatch between these programming languages and DBMS software. Mismatch problems require programmers to write large amounts of code to translate their inserted data format so as to be understood by the database, and it is no easy task to move from traditional databases to new ones. Therefore, ORDBs are valuable in allowing users to carry on using their existing system while starting to use OO systems in parallel. Object-relational database management system (ORDBMS) is expected to outsell RDBs, given their supplementary object capabilities compared to RDBs. ORDBMSs allow users to define data type, function and operator. For example, two attributes - location and picture - can be added to the previous STUDENT relation to be: STUDENT (first name, surname, address, course, location, picture) A. M. Maatuk

15

Chapter 2

Comparative study

Because the location attribute is a geographical point and the picture attribute is an image,

they cannot be included in relational STUDENT relation. The four main features of an ORDBMS are: 

Base data type extension.



Support complex objects.



Support inheritance.



Support for production rule system. [Stonebraker et al., 1998]

2.3.1 Advantages and disadvantages of object-relational databases

The main advantage of ORDBMSs is their huge scalability, because they are designed to have large storage capacities to satisfy massive organizations wanting to manage their large databases. “The main advantages of extending the relational data model come from reuse and sharing.” [Connolly and Begg, 2002] It will be the corner of the market within few years [Michael, 2003]. On the other hand, although the ORDBMS has many advanced features and most DBMS vendors expect it to become market leader, they have some disadvantages. An OR model architecture is not regarded as appropriate for highspeed web-application, given its complexity and high cost. 2.3.2 SQL3 The SQL-1999 (SQL3) is an extension of SQL-92 which includes new features and more furtherance, which are proper into the relational SQL. Some new query statements have been added to SQL3 to make SQL integral for object actions specified in SQL. The most widely expected feature, of the new SQL standard, is the addition of object technology to the language. According to Jim Melton (Oracle Corporation), “In 1999, the third generation of the SQL standard was published after a lengthy development period. The first two generations had appeared in 1986 and 1992 (with an intervening minor revision in 1989). The project known as SQL3 was thus not completed until seven years after the A. M. Maatuk

16

Chapter 2

Comparative study

publication of the 1992 version of the standard. In fact, development of some features was started more than a year before SQL-92 was published.” [Michael, 2003] The SQL3 standards include SQL/Framework, SQL/Foundation, SQL/Bindings, and SQL/Object [Elmasri and Navathe, 2000].

2.3.3 Comparison of Object-Oriented and Object-Relational Databases ORDBs are OODBs starting from and building on the relational model and SQL. Therefore, they have all of the RDBMS features, such as conceptual simplicity, standard query language, efficiency, availability, and scalability. Moreover, an ORDBMS also accommodates many object features, such as ADTs, OIDs, references, encapsulation, row type and inheritances. Stonebraker's view Dr. Michael Stonebraker has proposed a four-quadrant classification of DBMS applications [Stonebraker et al., 1998]. The lower left quadrant contains applications that process simple data and have no requirement for queries of the data such as Word application that can works under operating system to achieve DBMS functionality. In the lower right quadrant are applications that process complex data and also have no requirement for query the data such as CAD, and OODBMS may be the best of DBMS. In the top left quadrant are applications that process simple data and have the requirements for complex querying of data such as many business applications, and RDBMS may be the most approve DBMS. Finally, in the top right quadrant are applications that process complex data and have requirements for complex data queries such as many advanced database applications, and ORDBMS may be the best of DBMS. Dr. Stonebraker claimed that, this simple matrix can be used for classifying DBMS applications, and it has since become part of the database culture. However, it is also incorrect. The problem is the lower right quadrant, which asserts that OODBMS does not support queries.

A. M. Maatuk

17

Chapter 2

Comparative study

Query

Relational DBMS

Object-Relational DBMS

No Query

File System

Object-Oriented DBMS

Simple Data

Complex Data

Figure 2-3: Stonebraker‟s DBMS Matrix for classifying DBMS applications

Errors in Stonebraker's view The main error in Stonebraker's DBMS Matrix is the idea that OODBMSs do not have a query capability. Complex data can be handled with either an ORDBMS or an OODBMS. So, by modifying the DBMS Matrix accordingly, it now appears as the follows:

Object-Relational Query

Relational DBMS

DBMS and Object-Oriented DBMS

No Query

File System

--

Simple Data

Complex Data

Figure 2-4: Modified DBMS Matrix for classifying DBMS applications

A. M. Maatuk

18

Chapter 2

Comparative study

2.4 The differences between the three types of databases The following table shows a comparison between the three databases approaches. (Adapted from: International Data Corporation, 1997 [McClure, 1997]) Table 2-1: A Comparison of DBMSs Criteria

RDBMS

ORDBMS

ODBMS

Defining standard

SQL2 (ANSI X3H2)

SQL3/4 (in process)

ODMG-V2.0 &V3.0

Support for object-oriented programming

Poor; programmers spend 25% of coding time Limited mostly to new data mapping the program object types to the database

Direct and extensive

Simplicity of use

Table structures easy to understand; many end-user tools available

OK for programmers; some SQL access for end users

Simplicity of development

Objects are a natural way to Provides independence of Provides independence of model; can accommodate a data from application, good data from application, good wide variety of types and for simple relationships for simple relationships relationships

Extensibility and content

None

Same as RDBMS, with some confusing extensions

Limited mostly to new data types

Can handle arbitrary complexity; users can write methods and on any structure

Complex data relationships

Difficult to model

Difficult to model

Can handle arbitrary complexity; users can write methods and on any structure

Performance versus interoperability

Level of safety varies with vendor, must be traded off; achieving both requires extensive testing

Level of safety varies with vendor, must be traded off; achieving both requires extensive testing

Level of safety varies with vendor; most ODBMSs allow programmers to extend DBMS functionality by defining new classes

Distribution, replication, and Extensive federated databases

Extensive

Varies with vendor; a few provide extensive support

Product maturity

Very mature

Immature; extensions are new, are still being defined, Relatively mature and are relatively unproven

Legacy people and the universality of SQL

Extensive supply of tools and trained developers

Can take advantages of RDBMS tools and developers

Software ecosystems

ODBMS vendors beginning Provided by major RDBMS Provided by major RDBMS to emulate RDBMS vendors, companies companies but none offers large markets to other ISVs

Vendor viability

Expected for the major established RDBMS vendors

A. M. Maatuk

Expected for the major RDBMS vendors; UniSQL is struggling

SQL accommodated, but intended for object-oriented programmers.

Less of an issue than it was; some shakeout still expected

19

Chapter 2

Comparative study

2.5 Summary This chapter has introduced the three types of databases. These include RDBs, OODBs and ORDBs. Some important ideas, such as constraints and the standardization of SQL in RDB, encapsulation, inheritance, polymorphism and the ODMG standard, in addition to type definitions and SQL3 have been discussed concentrating on the main aspects related to each type of database. Moreover, their advantages and disadvantages, and their common features have been discussed. Stonebraker's view and its errors are then described, and finally, the relationships among database types have also been discussed and illustrated.

A. M. Maatuk

20

CHAPTER THREE SCHEMA CONVERSION TECHNIQUES

Chapter 3

Schema Conversion Techniques

Chapter 3 Schema Conversion Techniques There is a current interest in converting an RDB into an OODB and ORDB. Such conversion is related to the task of deriving structures according to conceptual models such as entity relationship (ER) or extend-entity relationship (EER) [Ramanathan and Hodges, 1997]. Schema conversions are discussed in several significant researches. The common motivation for converting schemas is to superimpose an object model on a relational model. “Due to its semantic richness and flexibility in modeling, objectoriented data model (OODM) is usually chosen as the canonical data model.” [Yan and Ling, 1993]

3.1 Converting relational database into object-oriented database schema The mapping schema tasks go through a series of techniques (rules), which map the source schema concept (relational) to the target schema (object-oriented) [Chiang et al., 1994]. [Ramanathan and Hodges, 1997] present an approach for extracting the structural part of an OODB schema from an existing RDB schema, considering that, no modifying for source schema, and optimization of the database including the use of binary large objects (BLOBs), horizontal and vertical partitioning. Moreover, the source relational schema should be at least in the 2NF, and attributes are considered to be synonymous if they have the same domain, and no homonyms. “It is also assumed that there are no homonyms (attributes that have the same name but different domain) in the schema” [Ramanathan and Hodges, 1997]. The major migration methodologies are based on the use of integrity constraints (functional dependency key constraints and inclusion dependency). However, there are some work is not detailed further, for instance, entity fragmentation and ISA relationships are not considered [Yan and Ling, 1993]. The semantics of the use of integrity constraints stand for database‟s semantics, therefore, to A. M. Maatuk

22

Chapter 3


maintain database, the integrity constraints should be considered so as to remove ambiguity during the mapping process. [Tari, 1993] Some approaches are designed to extract semantics by investigating the structure of relations and their constraints, identifying an ISA hierarchy, and generating inter-object relationships in addition to identifying relation clusters to represent object-classes [Yan and Ling, 1993]. A methodology on mapping ER and relational model into an OO model is proposed in [Narasimhan et al., 1993], which considers the characteristic features of ER models to deal with an abstraction of the relational model. To remove the redundancy caused by MVD, a methodology has been proposed to convert a relational schema into well-structured class taking into account relational schema in the 4NF [Xiuzhen, 1999]. The method is proposed to reduce an RDB schema while transforming RDB into OODB. ”A well-structured class is not only equivalent to the original relation schema but also remove data redundancy” [Xiuzhen, 1999]. An automated support for existing relational schema, which enables the user to understand the entities, their attributes and relationships, is proposed by [Monk et al., 1996] describing results from a long-term project. There is no particular OO model assumed in some methodologies, whereas a C++ like syntax for model class structures are used [Narasimhan et al., 1993]. ODL of the ODMG standard has been used in other methodologies. Mapping tables to objects will involve such rules as follows: o Mapping relational data type into object-type o Mapping tables to object classes o Mapping inheritance tables based on tables or multi-tables to inherited classes o Mapping association tables (intersection) to relationship objects o Mapping dependent relations (weak entity) depending on parent relation into dependent objects [Xiuzhen, 1999; Narasimhan et al, 1993; Fong, 1997; Ramanathan and Hodges, 1997; Yan and Ling, 1993].

A. M. Maatuk

23

Chapter 3


3.1.1 Mapping relational data types into object-types and relational table definitions to object classes A cluster of relations from the source RDB corresponds to an object-class based on the main class relation and their component relation concept is proposed in [Yan and Ling, 1993]. “Intuitively, a main class relation represents the core part of an object-class while a component relation represents other properties of an object class” [Yan and Ling, 1993]. Therefore, relation R is a main class relation if: o R is not involved in any relationships o Its primary key does not contain more than one disjoint foreign key, no inclusion dependency in which right hand side is a subset of its primary key or it is a reference of another Relation R’. o R is identified by ID-dependency identification as a main relation Relation R1 is a component relation of a main class relation R if: o There is no relation reference R1, and its primary key does not compose into more than one disjoint foreign key. o Where R1 [P1]  R [P], where P is primary key of R and P1 is primary key of R1. So, an object-class is built up from a relation‟s cluster, which is formed by the main class relation and its component relation [Yan and Ling, 1993]. This methodology is based on the concept of grouping operations and clusters to avoid object-classes reproducing, by combining related relations and relationships to construct a cluster. Consider the following relational schema (adapted from [Yan and Ling, 1993]): Person (Pno, name, age) PersonPhone (Pno*, phoneNo) DrivingLicence (Pno*, licenceNo) By applying the approach described in [Yan and Ling, 1993], the Person relation is identified as a main class relation. Because there are no relations that reference both PersonPhone and DrivingLicence relations, they are not main class relations, however, they are component relations of the Person relation because they hold its primary key Pno. The relation cluster is identified as follows: A. M. Maatuk

24

Chapter 3


Person (Person, PersonPhone, DrivingLicence) The Person relation cluster will convert into the target schema as: Class Person { String Pno; String name; Integer age; Integer DrivingLicence-licenceNo; SetOf (string) PersonPhone-phoneNo;}; Note: During the mapping into OO schema, the language / notation, and class definitions are explained as they proposed while we are discussing any methodology.

Note that here some attributes are prefixed by their relation name. However, some approaches are based on converting stand-alone relations to target object-class directly as mandatory mapping [Fong, 1997]. [Ramanathan and Hodges, 1997] assumed that the relation to be mapped into an object-class should be in the 2NF, when there is functional dependency on its key and other attributes. For example, consider the relation R as follows: R (A, B, C, D, E); A is the primary key, and there is the following functional dependency A

B

B

CD

Therefore, the relation R should be split into two class relations, R1 and R2, as follows: R1 (A, B*, E); R2 (B, C, D);

After that, each of the two relations maps into object-classes. On the other hand, to remove the original data redundancy that caused by MVD, source relational schema should be in 4NF [Zhang and Fong, 2000]. “Before starting with schema transformation, in the input RDB schema, we repeatedly replace any pair of such schemas {R1, R2} with the schema R resulting from the composition process […] this composition and replacement process is denoted as A. M. Maatuk

25

Chapter 3

R: {M, I}


compose (R1 :{ M1, I1}, R2 :{ M2, I2}). With this expression we state explicitly

that the MVDs (M1 and M2) and IDs (I1 and I2) on R1 and R2 are maintained by R (M and I) resulting from composition” [Xiuzhen et al., 1999]. So, in the technique proposed, a composition process before converting is required. This process can be further explained with the following relational schema (adapted from [Xiuzhen et al., 1999]). Course (code, title) Person (ssn, name), se) Staff (ssn, staff-idt, dept) Staff-dependent (Stf, ssn, name, relationship) Student (ssn, sno, prog) Lecturer (Course,stf): {M1=course stf} Course-stud (Course,stud): {M2=course stud} Sched (Course, hour, room): {M3=course hour, room} M1, M2 and M3 are MVDs and also some inclusion dependency: 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] By applying step 1 - Composition and replacement - in the methodology, so: With I9 and M1, M2, M3, the process might be applied on Lecturer, Course-stud and Sched relations to produce a new relation (Schedule): Schedule: {M1, M2, M3}

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

Therefore, we will get the relation, Schedule (Course, hour, room, Stf, stud). Moreover, by applying step 4 - Establishing association between classes - according to rule (d) and theorem 1, Schedule relation will be mapped into class Cschedule as follows: Class Cschedule ( course: Ccourse, hour-room: set(Chour-room), staff: set(Cstaff), student: set(Cstudent));

A. M. Maatuk

26

Chapter 3


Class Chour-room ( hour: string; room: string;); [Xiuzhen et al., 1999] 3.1.2 Mapping attributes Attributes of source relation to be converted to object-class will become instance variable of the class instance. The first mapping rule in [Narasimhan et al., 1993] is stated as: “Map each entity as a class and declare its specific attributes as its instance variables.” In addition to this rule, the methodology describes further attribute mapping by proposing other rules such as: “Rule 3: map multi-valued attributes as lists or sets of values with a suitable constructor” [Narasimhan et al., 1993]. Hence, by this rule, the target OO schema can avoid redundancy of data. Attributes that may compose to form one attribute, for example Address may form composite attribute that includes flat-no, street and post code. This type of attribute might be separated into another class. “Rule 4: for each composite attribute, define a separate class, and make it an instance variable of the parent class” [Narasimhan et al., 1993]. A derived attribute is one that can be extracted from given data. For example, age of a person can be calculated from date of birth and current date. This feature is not provided by relational model. However, OO model can provides it using functions (methods). “Rule 5: map derived attributes into methods that would execute the derivation procedure.” [Narasimhan et al., 1993]

3.1.3 Mapping relationships (association attributes) This mapping takes the value of relationship in a relational model (foreign key) and maps them into the OO model as association attributes [Fong, 1997]. Relationships mapping can be described as one-one, one-many, and many-many relationships, represented by “inverse variables”. However, three types of relationships can be represented in OO models, which are association, aggregation and inheritance [Ramanathan and Hodges, 1997]. ”Association between object-classes can be identified based on two cases. First, every relation whose primary key is entirely composed of foreign keys is a class that A. M. Maatuk

27

Chapter 3


represents an association between all the classes corresponding to the class-relation that the foreign key refers to. Second, for every class-relation that is not an association class, establish an association relationship between the corresponding class and the class corresponding to each non-key foreign key” [Ramanathan and Hodges, 1997]. The relationship could be non-recursive or recursive. A non-recursive relationship is an association between two or more objects; whereas a recursive relationship is where the entity type participates in the relationship twice, once as owner and another as a member [Narasimhan et al., 1993]. Mapping one-to-one and one-to-many relationship A containment hierarchy and “inverse variables” can represent one-one and one-to-many relationships [Fong, 1997]. A foreign key makes a link between two, parent and child relations. Hence, on mapping, the parent class will contain a complex attribute of a child class. For instance, consider the following relational schema:

Department (DeptNo, dept-name) Instructor (inst-name, address, deptNo*) To convert the source schema, the target schema will be as follows: Class Department Attr deptNo: integer; Attr dept-name: string; Association attr hire ref set (instructor); End Class Instructor Attr inst-name: string; Attr address: string Association attr hired by ref Department; End Inverse variables can be used in two classes. The association attributes hire and hired by form the above are inversed to each other [Fong, 1997].

A. M. Maatuk

28

Chapter 3


Mapping of relationship object classes (many-many relationship) “Intuitively, relations whose primary key consists of disjoint foreign keys will be treated as a relationship object class” [Yan and Ling, 1993]. An object-relationship class (or class object section) is similar to an object class. However the primary key of an objectrelationship class is not atomic and it holds more than one disjoint foreign key. Moreover, neither ISA relationship nor ID-dependency is involved in object-relationship class [Yan and Ling, 1993]. For instance, consider the following relational schema [Yan and Ling, 1993]: Project (projNo, projName) Employee (Eno, Pno, dateOfJoin) ProjStaff (projNo, Eno, position) In the above schema, ProjNo and Eno are foreign keys that refer to Project and Employee object-classes. Hence, the relation ProjectStaff represents a relationship class. A containment hierarchy and “inverse variables” can be used to map the relational schema into the target, as stated in the previous example from [Fong, 1997]. However, a target schema might be mapped as follows [Yan and Ling, 1993]: Class Employee: Public Person { String Eno; String Pno; Date dateOfJoin;}; Class Project { String ProjNo; String ProjName;}; Class ProjStaff { Project ProjNo-Project; Employee Eno-Employee; String position;}; Note that, the attribute name and the name of the relation that comes from it are attached together to form a new association attribute. For example, the ProjNo attribute that comes from the Project relation will represent the ProjNo-Project relationship [Yan and Ling, 1993]. A. M. Maatuk

29

Chapter 3


3.1.4 Mapping a weak entity An entity A is a weak entity if it depends on the existence of another entity. For example the identification of the entity Dependent depends on Employee, therefore, Dependent cannot exist without existing of Employee [Narasimhan et al., 1993]. In OO this is a case of a complex object. The Dependent objects should be seen as a component of Employee object. Although the Dependent object existence depends on the existence of Employee, it can cooperate with other objects [Yan and Ling, 1993]. Consider the following relations: Hospital (Hname, address) Ward (Hname, wardNo, doctor) Since the relation Ward is a weak relation, both relations will be mapped as follows: Class Hospital { String Hname; String address; Own setOf (Ward) ward;} Class Ward { String Hname; String wardNo; String docter;} Although, a weak entity mapping is not discussed further in some methodologies [Fong, 1997], it is described with extra details as identifying aggregation relationship [Ramanathan and Hodges, 1997]. “Many RDBMs these days provide support for BOLBs data type to facilitate the storage of multimedia and lack of support for arrays of value as single tuple value. Many RDBs utilize the BOLBs to store multi-valued attribute.” [Ramanathan and Hodges, 1997] “If the attribute corresponds to an array data type, then there as basically an aggregation relationship between the class-relation and the elements of the array.” [Ramanathan and Hodges, 1997] Furthermore, it stated and called a dependent relation. [Xiuzhen et al., 1999] In OO schema, the parent class constructor may call a method to get the child attribute value. Likewise, the main class destructor A. M. Maatuk

30

Chapter 3


used to delete the instance of weak entity classes. “Rule: 2 use main classes to instantiate and destruct weak classes” [Narasimhan et al., 1993]. 3.1.5 Mapping inheritance Consider two main class relations R1 and R2, whose keys are P1 and P2 respectively. If P1 (the primary key of R1) is also a foreign key in R2, then P1 is subset of P2. Hence, this is the simplest case of an inheritance relationship between R1 and R2 [Fong, 1997]. R1 ISA R2 through R1 [P1]  R2 [P2] For example, consider the following students relational schema [Fong, 1997]: Student (studentNo, name) Graduate-student (studentNo, degree) ID: Graduate-student. studentNo  Student.studentNo On mapping into the target schema, Student will be a super class and Graduate-student a subclass. The inclusion constraints have to be between the keys of both relations R1 and R2, to be mapped into subclass and super class. However, [Yan and Ling, 1993] emphasise that, the two relations R1 and R2 must be main class relations. R1, which will be a subclass in the target schema, should hold the main class relation condition that motioned in 3.4.1. On the example above, no other relations reference the Graduatestudent relation [Yan and Ling, 1993]. Therefore, the OO target schema will be as a super object-class (Student) and sub-object-class (Graduate-student). The subclass inherits all attributes and methods (operations) of the super class. Class Student attr studentNo: integer; attr name: string; End; Class Graduate-student inherit Student attr degree: string; End; The attribute Graduate-student.studentNo is inherited from the class Student. However, the subclass still contains its key attribute (studentNo), because, it is the property of the A. M. Maatuk

31

Chapter 3


subclass, it represents the connection between the subclass and its parent class and for query optimization on OOBD schema [Yan and Ling, 1993].

3.2 Converting relational database into object-relational database schema ORDBs introduce modern technology for supporting new data types. They provide scalability and incorporated data storage, and manipulation of spatial, image and text data. The OR model is an extension of relational concepts in addition to incorporating object features such as structured attribute types, OID, methods and references [Moline et al., 2002]. An example of how to create and use user-defined data types in Oracle is given in [Gietz and Dupree, 2002]. Their example manages the schema of Customer Purchase Order to develop the relational and then OR version through an ER. The basic entities in this example are Customer, Purchase Order, Line-Item and Stock-Item. A user-defined type is created for each entity in the OR version and then instances are given for particular user-defined types. In [Stonebraker et al., 1999], some concepts of RDB design are shown and then extended into OR design, also through ER. Moreover, various problems that may face database designers are mentioned. “Relational database design is difficult and developers struggle with this fact all too frequently. But ORDB design is harder yet. The great wave of ORDBMSs may be threatened by the challenges real users will face when they try to create reasonable database designs” [Stonebraker et al., 1999]. An ER is used to help users with the design of databases. ER tools -boxes and arrows- assist in representing data and relationship between entities. [Stonebraker et al., 1999] The following ER shows the Purchase Order application. [Gietz and Dupree, 2002]

A. M. Maatuk

32

Chapter 3


Figure 3-1: Entity Relationship Diagram for Purchase Order Application

The entity relationships among the entities are showed in the diagram and the following four tables appear. 

Customer.



Purchase-Order.



Line-Item of a purchase order, represents Entity-relationship.



Stock-Item.

A. M. Maatuk

33

Chapter 3


The relationships between entities in the ER diagram are: o A customer places zero or more purchase orders. o A purchase order has one customer. o A purchase order contains one or many line items. o A given line item occurs on just one purchase order. o Each line item refers to one stock item. o A stock item can happen in zero or many line items. [Gietz and Dupree, 2002]

The complete ER diagram above and the relationships are used to generate and construct a collection of tables. Each entity becomes a table containing attributes, having a primary key and foreign keys to represent the relationships with other tables. The relational approach results in the following tables: o

Customer_reltab (CustNo, CustName ,Street,City,State,Zip,Phone1 Phone2, Phone3)

o

PurchaseOrder_reltab (PONo,Custno*,orderDate,thipDate,toStreet,toCity,toState, ToZip)

o

LineItems_reltab (LineItemNo, PONo*, StockNo*,Quantity,Discount)

o

Stock_reltab (StockNo ,Price,TaxRate)

PurchaseOrder_reltab - the relationship between the customer and the purchase order - is managed by a foreign key (CustNo), which references the key of Customer_reltab (CustNo) As shown in the ER diagram, line items has relationships with the purchase order and the stock item, which are managed by LineItems_reltab by two foreign keys PONo and StockNo, in PurchaseOrder_reltab (PONo) and Stock_reltab (StockNo) respectively. A convention of the suffix _reltab is added to the relation names to make the code easier to maintain [Gietz and Dupree, 2002]. Therefore, (_reltab) means a relational table, (objtyp) means object-type, and so on. On mapping the previous RDBs schema into OR schema, an OO viewpoint is required. The translation of the ER diagram into a class diagram for Purchase Order Application allows the user to translate more real-world structure into the database schema [Gietz and Dupree, 2002].

A. M. Maatuk

34

Chapter 3


“The main entities: customers, stock, and purchase orders--become object-types. Object references: are used to express some of the relationships among them. Collection types: varrays and nested tables--are used to model multi-valued attributes.” [Gietz and Dupree, 2002]

Figure 3-2: Class diagram for Purchase Order Application

From the two database approaches and both ER and class diagrams, it may be noted that, a costumer address in the relational approach is repeated twice in the Customer entity and then in the Purchase entity. Furthermore, phone number attributes are a set of phone numbers. However, the OR approach defines types to represent a customer addresses as a single “Address” object, which contain all address attributes. The Address is also used by the Purchase Order object which is related to a customer. A Purchase Order contains a set of Line-items which refer at the same time to a Stock Item. A. M. Maatuk

35

Chapter 3


In relational schema, the Line-items are stored in a separate table. However, the OR approach provides nested table to represent Line-items as attribute containing a collection of line items [Gietz and Dupree, 2002]. 3.2.1 Defining types A user-defined type with a CREATE TYPE statement should be created for every table in the relational schema as follows: CREATE TYPE StockItem_objtyp AS OBJECT ( StockNo NUMBER, Price NUMBER, TaxRate NUMBER); However, the user needs to wait to define types that refer to other types until these other types have been defined. The basis type has to be defined before the child. CREATE TYPE LineItem_objtyp AS OBJECT ( LineItemNo NUMBER, Stock_ref REF StockItem_objtyp, Quantity NUMBER, Discount NUMBER); The line-item entity is converted into the LineItem_objtyp having an object reference to the related stock object. Demanding and complex schemas may lead the user to create types before all the types that it presupposes are created. Therefore Oracle provides what is called an “incomplete type” using the CREATE TYPE statement without the AS OBJECT clause to create an incomplete type. After that the user needs to use the OR REPLACE clause to replace an incomplete type with a complete definition. For instance, to create LineItem_objtyp before creating StockItem_objtyp, the following statements might be used:

CREATE TYPE LineItem_objtyp; Now swap an incomplete type with a complete definition, using the OR REPLACE clause as follows: A. M. Maatuk

36

Chapter 3


CREATE OR REPLACE TYPE LineItem_objtyp AS OBJECT ( LineItemNo NUMBER, Stock_ref REF StockItem_objtyp, Quantity NUMBER, Discount NUMBER); [Gietz and Dupree, 2002] 3.2.2 Defining collection types “Collections are used to store multiple values in a single column of a table and can result in a nested table where a column in one table actually contains another table.” [Connolly and Begg, 2002] A varray or a nested table can be used to map multi-valued attributes. In relational approach multi-valued attribute would be handled by creating new tables. This does not occur with the OR approach because all the attributes (even multi-valued ones) are encapsulated within the object [Elmasri and Navathe, 2000].

In our relational

schema, defining a varray type for the list of phone numbers is quite useful. To map the list of phone numbers, a varray is better than a nested table because a varray is ordered whereas a nested table is not. Moreover, the user can query a nested table, but cannot query a varray. Therefore, a list of phone numbers could be mapped as follows: CREATE TYPE PhoneList_vartyp AS VARRAY (10) OF VARCHAR2 (20); “If you need to query the collection, then use nested tables if you intend to retrieve the collection as a whole, then use varrays. “[Gietz and Dupree, 2002] Therefore, addresses could be mapped as follows: CREATE TYPE Address_objtyp AS OBJECT ( Street VARCHAR2 (200), City VARCHAR2 (200), State CHAR (2), Zip VARCHAR2 (20)) Now, the definition of the object-type Customer_objtyp, which is based on PhoneList_vartyp and Address_objtyp user-defined types, will be as follows: CREATE TYPE Customer_objtyp AS OBJECT ( CustNo NUMBER, CustName VARCHAR2 (200), Address_obj Address_objtyp, PhoneList_var PhoneList_vartyp) NOT FINAL; A. M. Maatuk

37

Chapter 3


The NOT FINAL phrase here allows the user to create subtypes of the customer type later (the default is FINAL). This means that other subtypes can inherit the object-type. Then, define a type for a nested table of line items. This nested table type is to contain the line items, which will be used by the Purchase order:

CREATE TYPE LineItemList_ntabtyp AS TABLE OF LineItem_objtyp; To map the multi-value line item list, a nested table of line items is better than a varray, because queries of lineItem are required, which cannot be done if a varray is used. The object-type PurchaseOrder_objtyp will be defined as follows: CREATE TYPE PurchaseOrder_objtyp AUTHID CURRENT_USER AS OBJECT ( PONo NUMBER, Cust_ref REF Customer_objtyp, OrderDate DATE, ShipDate DATE, LineItemList_ntab LineItemList_ntabtyp, ShipToAddr_obj Address_objtyp);

3.2.3 Defining reference type OID and reference types have a similar function. Other objects use the OID to reference them as a unique way and the reference enables the user to overcome the complex join definition in queries, and it also supports sharing among multiple tables [Connolly and Begg, 2002]. The relationship between the Customer and the Purchase-order must be managed by the purchase-order using Cust_ref REF as a reference to Customer_objtyp. In the relational Purchase Order schema, the table LineItems_reltab has a primary key (lineItem, Pono) and part of it is the primary key of Purchase-Order, which is Pono. Therefore, this is a relationship which means that line-item is a part of purchase order. Such relationship will be mapped into the OR approach by using nested tables. In addition, the LineItem_reltab has a relationship with Stock_reltab represented by StockNo which will be mapped into the OR approach by storing a reference using REF to StockItem_objtyp in LineItem_objtyp [Gietz and Dupree, 2002]. All user-defined types A. M. Maatuk

38

Chapter 3


for the OR schema of the purchase-order are defined. To create instances of these types to contain actual purchase order data, it is necessary to create tables to store such data.

3.2.4 Creating object tables Defining and creating the object-types of the schema achieve a logical structure. Tables are the next step to be created to store data. Creating an object table in an OR approach is based on data type specification which will represent object instances for each row in an object table. Furthermore, many object tables can be created using the same object-type. “Each row in an object table is a single object instance. So, in one sense, an object table has, or consists of, only a single column of the declared object-type. But this is not as different as it may seem from the case with relational tables. Each row in a relational table theoretically represents a single entity as well--for example, a customer, in a relational Customers table.” [Gietz and Dupree, 2002] Object tables that hold related object-types are defined as follows: CREATE TABLE Customer_objtab OF Customer_objtyp (CustNo PRIMARY KEY) OBJECT IDENTIFIER IS PRIMARY KEY; CREATE TABLE Stock_objtab OF StockItem_objtyp (StockNo PRIMARY KEY) OBJECT IDENTIFIER IS PRIMARY KEY; “Oracle requires every row object to have a unique OID. You may specify the unique OID value to be system-generated or specify the row object's primary key to serve as its unique OID. You indicate this when you execute the CREATE TABLE statement by specifying OBJECT IDENTIFIER IS PRIMARY KEY or OBJECT IDENTIFIER IS SYSTEM GENERATED. The latter is the default.” [Gietz and Dupree, 2002] CREATE TABLE PurchaseOrder_objtab OF PurchaseOrder_objtyp PRIMARY KEY (PONo), FOREIGN KEY (Cust_ref) REFERENCES Customer_objtab) OBJECT IDENTIFIER IS PRIMARY KEY NESTED TABLE LineItemList_ntab STORE AS PoLine_ntab ((PRIMARY KEY (NESTED_TABLE_ID, LineItemNo)) ORGANIZATION INDEX COMPRESS) RETURN AS LOCATOR [Gietz and Dupree, 2002] A. M. Maatuk

39

Chapter 3


Similar to relational tables, the statement FOREIGN KEY (Cust_ref) REFERENCES Customer_objtab) determines referential constraints on the Cust_ref column. Thus, Cust_ref REFs can refer to row objects in Customer_objtab. Furthermore, Customer_objtab holds the object of Customer_objtyp as a row object, which may be referenced by means of its OID. The rows of nested table column, LineItemList_ntab are specified and stored separately. The NESTED_TABLE_ID (a hidden column in the table) matches the rows with their related parent row. Therefore, all nested table‟s elements have the same NESTED_TABLE_ID value of their connected parent row [Gietz and Dupree, 2002].

3.2.5 Defining subtype and super-type Sub-type and super-type are allowed in the OR approach using the UNDER clause. “A sub-type inherits all the attributes and behaviour of its super-type and it can define additional attributes and functions like any other UDT and it can override inherited functions” [Connolly and Begg, 2002]. Creating sub-types under a super-type should be considered while creating the super-type using the NOT FINAL keyword, which is FINAL as a default. Therefore, specifying NOT FINAL for a super-type in the CREATE TYPE statement allows the user to create a subtype. For example, CREATE TYPE Corp_Customer_objtyp UNDER Customer_objtyp ( account_mgr_id NUMBER (6)) NOT FINAL; [Gietz and Dupree, 2002] The Corp_Customer_objtyp sub-type is created by the statement above under Customer_objtyp super-type. Although Corp_Customer_objtyp sub-type inherits all attributes and methods of Customer_objtyp super-type, it has its own attributes and methods. Instances of a sub-type can be stored in any object table. This is called “substitutability”. “Columns and tables are substitutable unless they have been explicitly declared to be NOT SUBSTITUTABLE” [Gietz and Dupree, 2002]. “A sub-table inherits every column from its super-table; every row of a sub-table corresponds to one and only one row in the super-table; every row in the super-table corresponds to at most one row in a sub-table” [Elmasri and Navathe, 2000]. A. M. Maatuk

40

Chapter 3


3.3 Summary This chapter has described various existing techniques for converting an RDB into an OODB/ORDB schema. Section 3.1 has discussed techniques for mapping an RDB into an OODB. Mapping relations, their attributes and relationships are described with appropriate examples. Attributes were described further, including multi-valued, composite and derived attributes. Relationship types are represented in an OODB as association, aggregation and inheritance. The major methodologies are based on the use of integrity constraints, and there is no particular OO model assumed in some methodologies, whereas ODL of the ODMG standard has been used in others. Section 3.2 has discussed techniques for converting an RDB into an ORDB schema with a given example of how to define user-defined types in Oracle. Objecttypes, collections, references, object tables, and sub-types and super-types are described. A logical structure is achieved by defining and creating object-types. Creating object tables is based on data types. Sub-types and super-types are allowed in the OR using the UNDER clause and should be considered while creating the super-type using the NOT FINAL keyword. During the discussion of mapping techniques into an OO schema, the notation of class definitions is explained as it is proposed in each methodology.

A. M. Maatuk

41

CHAPTER FOUR METHODOLOGY FOR CONVERTING A RELATIONAL DATABASE SCHEMA

Chapter 4

Methodology for converting a relational database schema

Chapter 4 Methodology for converting a relational database schema Converting RDBs into their equivalent object-based databases makes it possible to improve productivity and flexibility. The main goal of the present work is to develop a methodology for integrating schema migration. The new methodology facilitates the analysis of the advantages and disadvantages of previous techniques of migration schemas and develops a new method to convert an RDB with constraints into an OODB/ORDB schema. Converting schema consists of reconstructing the relational structure to produce the static structure of the target schema, in addition to deriving the dynamic methods for new target schema. However, the new methodology will consider the static structure of the target schema, so we do not consider methods mapping (because a relational schema does not defined methods over tables /relations). Functional dependency and inclusion dependency will be considered. The relational schema should be at least in 3NF. Attributes that represent links between relations should hold the same name, however, attributes that have the same names should not have different domains. The mapping process (of converting a relational schema into target schemas) assumes the existence of a relational schema (and hence a database) in which it operates.

4.1 Converting a relational into an object-oriented database schema Assume relation R (K, A) where: A1=K  A; A1 is a set of attributes of R; K is the primary key of R; and A is a subset of A1. Thus, depending on whether the primary key (K) is single or composite and may contain foreign keys, R is mapped into main-class, relationship-class, subclass or a component of another class. In addition, the foreign keys in relation R will be mapped into binary, inheritance or aggregation relationships. A. M. Maatuk

43

Chapter 4


4.1.1 Mapping relations and their attributes into the OO classes 4.1.1.1 Relationship relation If the primary key of a relation consists of disjoint foreign keys, it is called a relationship relation. A relation that consists of more than two disjoint foreign keys in its primary key is not considered in our method, therefore, it is treated as a main relation. Suppose, R [K, A], R1 [K1] and R2 [K2] where K=K01  K02; K, K1 and K2 are the primary keys of R, R1 and R2 respectively. If R [K01]  R1 [K1] and R [K02]  R2 [K2], then that means K of R consists of disjoint foreign keys. 1. If there are no attributes except the key (A=  ), and R1and R2 are mapped into C1 and C2 respectively, in that case R will be mapped into inversed binaryrelationship between C1 and C2. For example, consider the following relational schema: Employee (Empno, name) Project (Prono, position) ProjEmp (Empno*, Prono*) Since ProjEmp is a relationship relation without attributes except the key, which consists of disjoint foreign keys, then the Employee and Project relations will be mapped into equivalent classes. Each class will define a collection-valued inversed relationship. The migration will produce the following two class definitions: class Employee ( extent employees, key empno){ attribute string empno; attribute string name; relationship set < Project > worksFor inverse Project :: employees; }; class Project ( extent projects, key prono){ attribute string prono; attribute string position; relationship set < Employee > employees inverse Employee :: worksFor ; };

A. M. Maatuk

44

Chapter 4


2. If there are some attributes with the key (A   ) and R1 and R2 are mapped into C1 and C2 respectively, then the relationship relation should be mapped into a relationship-class holding its attributes and a pair of single valued relationships with collection-valued inverses in both C1 and C2 classes. For example, consider the following relational schema: Student (Stno, name) Unit (Unitno, title) Enrol (Stno*, Unitno*, grade) Since Enrol is a relationship relation with its own attributes and the key consists of disjoint foreign keys, therefore, the Student and Unit relations will be mapped into equivalent classes and the Enrol relationship relation will be mapped into a relationshipclass holding its attributes with relationship attributes defining a collection-valued of both Student and Unit classes. Attributes that represent relationships will be dropped from the new relationship class. The migration will produce the following class definitions: class Student ( extent students, key stno){ attribute string stno; attribute string name; relationship set enrolFor inverse Enrol :: enrols; }; class Unit ( extent units, key unitno){ attribute string unitno; attribute string title; relationship set offers inverse Enrol :: enrolledBy; }; class Enrol ( extent enrols, key stno,unitno){ attribute string grade; relationship Student enrols inverse Student :: enrolFor; }; relationship Unit enrolledBy inverse Unit :: offers; };

4.1.1.2 Main relation A one-to-one mapping of relations into classes in the target schema would not be a good idea except with very simple databases [Scott, 2000]. Therefore, relation R [K] in a relational schema, where its key K does not contain any foreign keys, is called the main

A. M. Maatuk

45

Chapter 4


relation, which will become an object-class and its attributes will become the class attributes. This mapping rule could be stated as: Map each main relation into an object-class and its attributes will become the mapped class attributes.

4.1.1.3 Mapping attributes Not all attributes are persistent [Scott, 2000]. Multi-valued attributes that are modelled by relation may be mapped into a collection of attributes using sets, lists or bags. Composite attributes which consist of more than one attribute may be usefully mapped into a single attribute such as an Address attribute that hold flat-number, street and postcode. Derived attributes are extracted from given data and used for calculation purposes. For example, a person‟s age is calculated from date of birth using class methods. However, because of the difficulty in determining such kinds of attributes in programmed methods, and also because dynamic structures are not considered in our methodology, therefore columns in an RDB will be simply mapped into class attributes. 4.1.2 Mapping Relationships 4.1.2.1 Association Foreign keys represent link (or association) attributes between relations. In the mapping process foreign keys in each relation should be determined and mapped into new classes as association attributes. However, the foreign key should be dropped from the new target schema, to be replaced by a relationship attribute. Moreover, the two classes should contain an inverse reference that shows the relationship between them. Having an inverse provides the ability to trace linked objects bi-directionally. The rule of association relationship attribute mapping is stated as follows: Map each relationship between relations into a relationship attribute, making a close relationship between the new classes with inverse reference.

A. M. Maatuk

46

Chapter 4


Therefore, using inverse references, a relationship in both directions can be traced. A relationship that represents an association between two or more different relations is called a non-recursive relationship; whereas if it represents an association of the relation with itself, it is called a recursive relationship. A recursive relationship means that a relation participates twice in a relationship, once as an „owner‟ and once as a „member‟. The mapping process is the same for non-recursive and recursive relationships. However, each object-class with a recursive relationship may have two attributes, once as an owner and once as a member. Relationships between relations are represented as one-to-many, one-to-one and many-to-many. Therefore, they can be described as follows: Case 1: One-to-many relationship A one-to-many relationship (also referred to as a many-to-one) is a common relationship. The relations on two sides are mapped into object-classes and the relation that holds the primary key will map with a relationship attribute having a set-valued (collection) of instances of the class that holds the foreign key. The rule of one-to-many relationship mapping is stated as follows:

Map a one-to-many relationship between classes by defining an inverse relationship that represents instances of the parent class and a collection-valued of the child class. Case 2: One-to-one relationship A one-to-one relationship is a special case of a one-to-many relationship. Therefore, the mapping processes are similar, except that a single object-class replaces a set of objects. Case 3: Many-to-many relationship This relationship in an RDB is very difficult because of normalisation problems. Therefore, an additional relation (intersection relation) should be created to hold the two related relations‟ primary keys. However, OO modelling supports many-to-many relationships. In the mapping process, after mapping both relations into target classes,

A. M. Maatuk

47

Chapter 4


each will hold a collection-valued of relative class instances in the other side. The rule of mapping a many-to-many relationship is stated as follows:

Map a many-to-many relationship as a relationship between classes using relationship attributes containing a set of class instances of each other. However, if the intersection relation contains attributes other than the PKs of participating relations, then the intersection relation will be mapped into a separate class. Having a pair of relationships with appropriate collection-valued inverses defined is participating classes.

4.1.2.2 Aggregation An entity that is dependent on another entity is called a „weak entity‟, and it has to be identified based on an identifier dependency (ID-dependency) relationship. For example, the Dependent relation depends on the Employee relation because it is part of it and Dependent cannot exist without Employee. This represents an aggregation relationship. The relationship between Dependent and Employee represents a case of a complex object. The relationship attribute and key word „own‟ or „have‟ should indicate the dependency and aggregation relationship during mapping into the OO schema. Assume two relations R1 and R2 and their keys are K1 and K2 respectively and K‟ is a part of K1. If R1 [K‟]  R2 [K2], then R1 is a weak entity which will be mapped into a component-class. The rule of mapping an aggregation relationship is stated as the following two cases: 1. If R1 has a link with other relations, then R1 will be mapped into a component class C1 of the parent class C2. For example, consider the following relational schema: Hospital (hostno, address) Employee (empno, name) Ward (hostno*, wardno, manager*)

A. M. Maatuk

48

Chapter 4


A part of the Ward key is the Hospital key, and Ward.manager represents a link to the Employee relation. Therefore, the Ward relation will be mapped into a component class of the Hospital class and Hospital will be mapped into a class defining collection-valued of the Ward class. The migration will produce the following class definitions: class Hospital (extent hospitals, key hostno){ attribute string hostno; attribute string address; relationship set < Ward > has inverse Ward :: belongs; }; class Employee (extent employees, key empno){ attribute string empno; attribute string name; relationship Ward manager inverse Ward :: managedBy; }; class Ward (extent wards){ attribute string wardno; relationship Employee managedBy inverse Employee:: manager; relationship Hospital belongs inverse Hospital:: has;};

2. If R1 has no relationship with other relations except its parent R2, then R1 will be mapped into a set-valued attribute within class C2. For example, consider the following relational schema: Student (Stno, name) Hobby (Stno*, hobby)

A part of the Hobby key is the Student key and the Hobby relation has no link to anything other than the Student. Therefore, the Hobby relation will be mapped into a set-valued attribute within the mapped Student class. class Student (extent students, key stno){ attribute string stno; attribute string name; attribute set < string > hobby;};

A. M. Maatuk

49

Chapter 4


4.1.2.3 Inheritance After mapping all relations, an inheritance relationship can be identified among them using the rule of ISA hierarchy identification. The primary key of the sub-class relation is a subset of the primary key of the super-class relation. Assume two relations R and R1, if R [K]  R1 [K1] and K is a foreign key, then K represents an inheritance relationship; therefore, R1 will be mapped into super-class C1 and R will be mapped into sub-class C. Using FKs between relations, an inheritance will be mapped into an inheritance relationship (using the ‘extends’ keyword), which allows the sub-class to inherit all attributes of the super-class. For example, consider the following relational schema: Student (stno, name) Full-time-student (stno*, course) By mapping these two relations into the OO schema, we will get the super-class Student and the sub-class Full-time-Student which inherits all attributes of its super-class Student as follows: class Student (extent students, key stno){ attribute string stno; attribute string name;}; class Full-time-student extends Student (extent full-time-students, key stno){ attribute string course;};

4.2 Converting a relational database into an object-relational database schema Assume relation R (K, A) where: A1=K  A, A1 is a set of attributes of R, K is the primary key of R, and A is a subset of A1. Thus, depending on whether the primary key (K) is single or composite or if the relation R contains foreign keys, R will be mapped into object-type, sub-type, or nested table within another object-type. In addition, the FKs in relation R will be mapped into references representing relationships amongst objecttypes.

A. M. Maatuk

50

Chapter 4


4.2.1 Mapping relations into object-types 4.2.1.1 Relationship relation A relation that consists of disjoint FKs in its PK will be mapped into an object-type, even though it contains other attributes or manipulates other object-types. For example, consider the following relational schema: Student (stno, name) Unit (unitNo, title) Enrol (stno*, unitNo*, grade) The Enrol relation consists of two disjoint keys and other attributes, so it will be mapped into an equivalent object-type. Foreign keys stno and unitNo will be mapped into references attributes (using REF) to the corresponding objects as follows: CREATE OR REPLACE TYPE Enrol _objtype AS OBJECT ( stno REF Student _objtype, unitNo REF Unit _objtype, grade DECIMAL));

4.2.1.2 Weak relation A relation that depends on another relation is a weak relation and its key is a part of another relation key. In the mapping process, a weak relation will be mapped into an object-type and then mapped into a collection (using a nested table) within its parent object-type as a part of it. Assume two relations R1 and R2, and their keys are K1 and K2 respectively and K‟ is a part of K1. So, if R1 [K‟]  R2 [K2]; then, R1 will be mapped into a component object-type T1 first, and then it will be mapped into a nested table within its parent object-type T2. For example, consider the following relational schema: Hospital (hostno, address) Employee (empno, name) Ward (hostno*, wardno, manager*)

A. M. Maatuk

51

Chapter 4


The key of the Hospital relation is a foreign key in the relation Ward and it is part of its key, which means that, the Ward is a weak relation. Therefore, the Ward relation will be mapped into an equivalent object-type and then into a nested table to be a component of the Hospital object-type. The hostno foreign key will dropped from the Ward _objtype as follows: CREATE OR REPLACE TYPE Ward _objtype AS OBJECT ( wardno CHAR(25), manager REF Employee _objtype); CREATE OR REPLACE TYPE ward_nested_table AS TABLE OF Ward _objtype;

CREATE OR REPLACE TYPE Hospital _objtype AS OBJECT ( hostno CHAR(10), address CHAR(25), ward_ref ward_nested_table);

4.2.1.3 Inheritance Assume two relations R1 and R2, and K1 and K2 are their keys respectively. If the key of relation R1 is a subset of the key of relation R2 (R1 [K1]  R2 [K2]) and K1 is a foreign key, then the relation R2 is mapped into super-type T2 and relation R1 is mapped into sub-type T1 under its parent object-type. R1 will be mapped into a sub-type under its super-type, inheriting its attributes in addition to its own attributes. Using the clause UNDER, a sub-type can be created under a base-type. Types that are created by defaults cannot have sub-types created under them. Therefore, we must specify the NOT FINAL clause in the CREATE TYPE statement of the parent type. For example, consider the following relational schema: Student (stno, name) Full-time-student (stno*, course) Relations Student and Full-time student have an inheritance relationship, therefore, in the mapping process, the relation Student will be mapped into the super-type Student-objtype

A. M. Maatuk

52

Chapter 4


ended by the NOT FINAL clause, to be inherited by the sub-type Full-time studentobjtype and the foreign key will be dropped from the sub-type as follows: CREATE OR REPLACE TYPE Student _objtype AS OBJECT ( stno CHAR(10), name CHAR(25)) NOT FINAL; CREATE TYPE Full-time_student_objtype UNDER Student_objtype ( course CHAR(10));

4.2.1.4 Main relation A main relation R[K] which does not contain any foreign keys will be mapped into an object-type and its attributes will become the equivalent attributes. Map each main Relation into an object-type and its attributes will become the new object-type’s attributes. 4.2.2 Mapping binary relationships into object references Foreign keys in an RDB provide referential integrity between relations using columns of the same data type containing the same data. These foreign key columns will be mapped into references data types with different domains in the ORDB using REF or collection of objects. Reference data types are used to provide relationships between rows of objecttype columns of object-types and other object-type columns or tables of another related table. Hence, relationships can be mapped and implemented using two mechanisms: a reference using the REF keyword and a collection of objects using nested tables. Case 1: One-to-one relationship A one-to-one relationship is mapped into an OR Schema using REF. A one-to-one relationship will be mapped by replacing a foreign key column in the relational schema by a REF.

For example, consider the following relational schema:

A. M. Maatuk

53

Chapter 4


Employee (empno, name) Ward (hostno*, wardno, manager*) The key of the Employee is a foreign key in the Ward, which means that, each ward has one manager. Therefore, the Ward relation will be mapped into an equivalent object-type and its manager attribute domain will be changed to references Employee using REF as follows: CREATE OR REPLACE TYPE Ward _objtype AS OBJECT ( wardno CHAR(25), manager REF Employee _objtype); CREATE OR REPLACE TYPE Employee _objtype AS OBJECT ( empno CHAR(10), name CHAR(25));

Case 2: One-to-many relationship A one-to-many relationship is mapped into the OR Schema using a collection of objects (i.e. a nested table). A one-to-many relationship will be mapped by replacing an FK column of the child object-type using REF as a reference to the parent object-type, and the latter will define a collection as a nested table of the child object-type. For example, consider the following schema: Department (deptNo, location) Employee (empno, name, deptNo*) Since the Department object-type has a one-to-many relationship with the Employee object-type as each department employs many employees, the Department _objtype will involve a collection of Employee_objtype as a nested table. Employee_nested_table should be defined in advance based on Employee_Ref objtype that defined collection of Employee _objtype as follows: CREATE OR REPLACE TYPE Employee _objtype AS OBJECT ( empno CHAR(10), A. M. Maatuk

54

Chapter 4


name CHAR(25), deptNo REF Department _objtype ) NOT FINAL; CREATE OR REPLACE TYPE Employee_Ref _objtype AS OBJECT (Emp REF Employee_objtype); CREATE TYPE Employee_nested_table AS TABLE OF Employee_Ref _objtype; CREATE OR REPLACE TYPE Department _objtype AS OBJECT ( deptNo CHAR(10), location CHAR(25), employee_ref Employee_nested_table) NOT FINAL;

Case 3: Many-to-many relationship A many-to-many relationship is mapped into the OR Schema using a collection of objects. A many-to-many relationship between two relations will be mapped into two object-types, and each of them will contain a collection-valued attributes. 4.2.3 Identify object-relational tables Defining and creating OR tables is the next step in order to store data. Creating an object table is based on a logical structure of data-type design throughout the creation of all object-types in the schema. In addition, a same object-type can be used to create many object tables. Object tables store collections of objects. Each row in an object table represents a single object instance. Object-types are categorized into two levels before they are placed in object tables. Object-types that are a part of other objects, or represent a nested table within other objects are categorized to a lower level than their parents, and the parent will be categorized to a higher level unless the parent is also nested or inherits other types. Then all higher level object-types are mapped into object tables. For example, consider the following relational schema: Hospital (hostno, address); Employee (empno, name); Ward (hostno*, wardno, manager*);

A. M. Maatuk

55

Chapter 4


Because part of the Ward key is the Hospital key, this means that the Ward is a weak relation. The Ward table will be mapped into the equivalent object-type and then into a nested table to be a component of the Hospital object-type. This means that it will be categorised to a lower level and the Hospital object-type to a higher level. Therefore, object-types and tables, which hold related object-types, are defined as follows: CREATE OR REPLACE TYPE Employee _objtyp AS OBJECT ( empno CHAR (10), name CHAR (25) ); CREATE OR REPLACE TYPE Ward _objtype AS OBJECT ( wardno CHAR(10), manager REF Employee _objtype); CREATE TYPE ward_nested_table AS TABLE OF Ward _objtype; CREATE OR REPLACE TYPE Hospital _objtype AS OBJECT ( hostno CHAR(10), address CHAR(25), ward_ref ward_nested_table); Now, creating object tables involving any nested tables will be defined as follows: CREATE TABLE Hospital _tab OF Hospital _objtyp (PRIMARY KEY hostno) NESTED TABLE ward_nested_table STORE AS ward_ntable; CREATE TABLE Employee _tab OF Employee _objtyp (PRIMARY KEY empno);

4.3 Summary In this chapter we have developed an integrated methodology for converting an RDB into an OODB/ORDB. The methodology was assembled from existing. By assuming a relation R[K, A] where: A1=K  A; A1 is a set of attributes of R; K is the primary key of R, and A is a subset of A1. Section 4.1 has described mapping an RDB into an OORB schema. Depending on whether K is single or composed attribute and the foreign key related to K, R is mapped into main-class, relationship-class, subclass or a component of

A. M. Maatuk

56

Chapter 4


another class and foreign keys are mapped into association, inherence or aggregation relationships. Foreign keys should be dropped from the new OO schema and replaced by relationships. Both classes should contain an inverse reference showing the relationship amongst them. Also, section 4.2 has described mapping an RDB into an ORDB schema. R is mapped into object-type, sub-type, or nested table within another object-type. Foreign keys in an RDB are mapped into references using REFs or collections of REFs representing relationships amongst object-types. Object tables are created based on a logical structure of object-type definitions. Object-types are classified into two levels. Object-types that are part of or nested within other object-types are at lower level than their parents that are at higher levels unless they are nested or inherit other types. All higher-level object-types are mapped into object tables.

A. M. Maatuk

57

CHAPTER FIVE DESIGN AND IMPLEMENTATION OF THE PROTOTYPE

Chapter 5

Design of the prototype

Chapter 5 Design and implementation of the prototype 5.1 Strategic design To convert an RDB into an object-based database schema, a source SQL script is needed as input. A source relational schema can be loaded into the system and handled in one of the following ways: 

Source to source schema script translation.



Working on a real database throughout a data dictionary.

5.1.1 Source to source schema script translation A relational schema script can be loaded into the system in standard text form containing DDL statements that define tables with related constraints and then converted into equivalent target script. The migration process is easy using this technique if each table is defined in the database with its attributes and associated constraints. However, the process will be more complicated if the script file has an unfamiliar form; for example, defining column domains and tables separately or creating tables based on other existing tables. Having read, the schema script as a text file, there may be problems converting it into the equivalent text script, because it does not represent the real database. Creating tables based on an existing table structure is one of these problems due to the need to modify table‟s attributes or constraints. In addition, defining a table‟s constraints and attributes domain separately from the table may lead to complications during the process of creating the target schema and recognising object-types and relationships amongst them. Defining an attribute’s domain separately from its table and creating a table based on another table Consider the following schema: A. M. Maatuk

59

Chapter 5


CREATE DOMAIN ROOM_NUM CHAR (4); CREATE DOMAIN PHONE_NO CHAR (20); CREATE TABLE OFFICE ( ROOM_NO ROOM_NUM PRIMARY KEY DEFERRABLE, TELEPHONE_EXT PHONE_NO, LOCATION CHARS (20)); The domain of ROOM_NUM column is defined separately from its table. This will create a domain predicament which may need considerable design work to overcome. A table created based on an existing table‟s structure and data values may make the recognition of characters that come after CREATE TBALE incomprehensible. For example, consider the following create statement: CREATE TABLE table1 AS SELECT col-1… col-n FROM table2 WHERE … Alter structure of tables Columns and constraints may be defined as part of a CREATE TABLE statement, however, altering the structure of some tables at the end of the script makes it difficult to determine the relationships between tables and modify constructed in-memory structure objects consequently. If they are added or dropped using an ALTER TABLE statement later on, this makes the design and programming complex. For example, updating column‟s properties form tables that have already been defined in the structure. This will mean modifying the structure many times when these ALTER statements are faced. Furthermore, adding extra constraints that determine the relationships amongst tables, or drop them will also put us in the same tricky situation. Specifying the relationships amongst tables The most important issue in the automated converting process is specifying the relationships between tables. However, this is not presented in RDB schema as text file script. For example, the concept that a Course has many Students enrolling for it is not present in the relational SQL script. Therefore dealing with database in reality with some data and querying the database is needed to specify the relationships between classes/object-types.

A. M. Maatuk

60

Chapter 5


5.1.2 Working on a real database using data dictionary tables In order to deal with a real database and to overcome all the drawbacks of reading a schema as a text file, our prototype is based on querying data dictionary tables to obtain information about tables, their attributes and constraints in an existing database. Oracle‟s data dictionary views, such as ALL_TABLES, ALL _TAB_COLUMNS and ALL_CONSTRAINTS can be queried using SELECT statement to provide the prototype with any information needed.

5.2 Architectural design A prototype is developed to demonstrate our methodology, providing some migration rules to generate an OODB/ORDB schema. Our prototype is intended to support the construction of in-memory structures of relational tables with constraints. It interacts with Oracle to read the RDB schema and construct the in-memory structure including table‟s name and types, their attributes and constraints. Moreover, once the relational in-memory structure is constructed, then the system applies the conversion rules to re-construct another equivalent OO/OR in-memory structure which will be translated to produce a selected target schema. The prototype will be developed in a Java environment using JDBC API (Java API) and Oracle 9i. Simple interfaces will be produced, therefore, the prototype we will use does not use GUI (i.e. Java frames or dialogue windows). Figure 5-1 illustrates our design architecture, which consists of three sequential phases. Phase-1: Construct an in-memory relational schema structure In this phase, the schema structure will be produced by accessing data dictionary views such as DBA_CONS_COLUMNS and DBA_CONSTRAINTS to get tables‟ name, columns and constraints in the database using JDBC. Phase-2: Transfer an RDB in-memory structure into an equivalent OO/OR inmemory structure

A. M. Maatuk

61

Chapter 5


Depending on phase-1, and applying the algorithms of our methodology, an equivalent in-memory OO/OR structure is created. In this phase the design uses the following two parallel processes to produce a selected target schema 

Construct an OO in-memory schema structure.



Construct an OR in-memory schema structure.

Phase-3: Generate ODL/SQL script from in-memory structure From the in-memory structure produced in phase-2, an ODL/SQL script is generated. DBA

Read database Reading relational database schema

Get table information

Relational schema

Determining relationship types

Construct relational

Data dictionary

in-memory structure

RDB In-memory structure Appling OO converting rules

OO conversion rules

Appling OR converting rules

OODB In-memory

ORDB In-memory

structure

structure

Generating

target object-based

ODL script

OR conversion rules

script

OR SQL script Implement SQL script

DATABASE

Figure 5-1: The overall architectural design

5.3 Details of the design In this section, each specific phase in the design is described. Phase-1: construct in-memory relational schema structure Figure 5-2 illustrates the relational in-memory structure, which is the first step to be constructed in this phase. Working with the data dictionary views to get all the A. M. Maatuk

62

Chapter 5


information needed about tables, columns and constraints in database will produce the structure. Several of data dictionary views are useful in our design to derive tables‟ information which, and these are listed below: 1.

USER_, ALL_, and DBA_TABLES give information about tables.

2.

USER_, ALL_, and DBA_CONSTRAINTS give information about constraints.

3.

USER_, ALL_, and DBA_CONS_COLUMNS give information about columns that have constraints.

After running an RDB script and creating all tables and constraints, the system reads the real tables and constraints from Oracle to identify each table and related attributes and constraints using data dictionary.

ExportKey pKey referedAttribute referedTable

Table Name Pkey Exportkey Attribute ForeignKey

Attribute Attr-name Domain

ForeignKey foreignKey referedTable relationshipType

Figure 5-2: Principle architecture of an RDB in-memory structure

The system produces the hierarchical in-memory structure of an RDB schema with constraints with the help of the data dictionary tables. Each table in the database will be represented by a corresponding in-memory component with its attributes and constraints. The RDB concept is applied to determine table‟s kind using primary and foreign key(s). Columns and their domain in each table will be represented by their equivalent in the new

A. M. Maatuk

63

Chapter 5


structure. The prototype sends a massage instructing the user to produce the appropriate target schema. 1. The system checks whether a selected database schema is created. 2. The system reads an RDB schema and finds tables with their attributes and related constraints by means of directory tables. 3. The data dictionary provides all information about tables and constraints, such as table name, primary key and foreign keys. 4. The system defines each table specification (table name, primary key, foreign keys and attributes and build an in-memory structure of the RDB schema tables with their constraints. 5. The system confirms and displays a message that the in-memory structure is constructed. class Main { list allTables, allClasses , allORTypes; RInMemory rInMemory ; OOInMemory ooInMemory ; ORInMemory orInMemory ; String query = select * from tab; executeQuery(query); while (rss.next()) // while table in tab. { String tableName =getTable(); tableclass=TableClass(tableName); rInMemory.setPrimaryKey(tableclass); rInMemory.setForiegnKey(tableclass); rInMemory.setExportKeys(tableclass); String query = "select * from " + tableName; String rs =executeQuery(query); rInMemory.setAttribute1(rs,tableclass); allTables.add(tableclass); } do { switch(choice) { case '1' : rInMemory.listAllTables(allTables); // List all relational tables. case '2' : ooInMemory.ooInMemoryStracture (allTables); //Construct Object-oriented database Schema. case '3' : orInMemory.orInMemoryStracture (allTables); // Construct Object-relational database Schema. case '4' : Quit. } }while(choice != '4'); }

Figure 5-3: Pseudo-code algorithm for reading a database to construct an RDB in-memory structure

A. M. Maatuk

64

Chapter 5


// class RInMemory to construct in-memory structure of relational tables with their columns and constraints. class RInMemory { list allAttributes , allForiegnKeys, primaryKey,allExporyKeys; method setExportKeys(ResultSet rsIn,TableClass tableclassIn) { while(rsIn.next()) { String pktable_name = rsIn.getString("PKTABLE_NAME"); String pkcolumn_name = rsIn.getString("PKCOLUMN_NAME"); String fktable_name = rsIn.getString("FKTABLE_NAME"); String fkcolumn_name = rsIn.getString("FKCOLUMN_NAME"); String fk_name = rsIn.getString("FK_NAME"); String pk_name = rsIn.getString("PK_NAME"); tableclassIn.setExporyKeys(pktable_name,pkcolumn_name,fktable_name, fkcolumn_name ,fk_name,pk_name); } } method setPrimaryKey(ResultSet rsIn,TableClass tableclassIn) { while(rsIn.next()) { String name = rsIn.getString("TABLE_NAME"); String columnName = rsIn.getString("COLUMN_NAME"); String pkName = rsIn.getString("PK_NAME"); tableclassIn.setPrimaryKey(name,columnName,pkName); } } method setForiegnKey(ResultSet rsIn,TableClass tableclassIn) { while (rsIn.next()) { String pkTable = rsIn.getString("PKTABLE_NAME"); String pkColName = rsIn.getString("PKCOLUMN_NAME"); String fkTable = rsIn.getString("FKTABLE_NAME"); String fkColName = rsIn.getString("FKCOLUMN_NAME"); tableclassIn.setForiegnKeys(pkTable,pkColName,fkTable,fkColName); } } method setAttribute1(ResultSet rsIn,TableClass tableclassIn) { while (rsIn.next()) { int type = getColumnType(i); int size = getColumnDisplaySize(i); String name =.getColumnTypeName(i); String columnName = getColumnName(i); tableclassIn.setTableAttributes(columnName,name,size); } } }

Figure 5-4: Pseudo-code algorithm of an RDB in-memory structure

Phase-2: Transfer an RDB in-memory structure into an equivalent OO/OR inmemory structure Depending on phase-1, and applying the algorithms of our methodology, an equivalent OO/OR in-memory structure is created as illustrated in Figures 5-3 and 5-4. After constructing a hierarchical of the in-memory structure of RDB schema, the next step is to determine which type of target schema is to be generated. Then the prototype will read

A. M. Maatuk

65

Chapter 5


the RDB in-memory structure and apply the relevant conversion rules to produce an equivalent object-based in-memory structure. The system sends a massage instructing the user to produce the object-based schema. Two parallel processes to produce a selected target schema are involved in this phase of prototype design. Each has its own conversion rules. Whereas OR is supported by Oracle9i for conversion in phase-3 into SQL script, the OO in-memory structure does not. The data in the database must be queried to identify whether the relationship types between objects are one-to-one, one-to-many or many-to-many. 





Class

Attribute

Name classType OID attribute

attr-name attr-type

RelshipAttribute

RelshipAttribute attribute relationshipType referedClass relship-attribute

Figure 5-5: Principle architectural of an OO in-memory structure

A. M. Maatuk

66

Chapter 5


ObjectType name type pkey Attribute REF-Collectoin

ORTable TableName OID(pKey) ObjectType

Attribute Attr-name domain

REF referenceAttribute

referedType

Figure 5-6: Principle architectural of OR in-memory structure

1. The system reads the in-memory structure of an RDB schema 2. The user selects the appropriate target structure, OODB or ORDB schema to be generated. 3. The system reads each table specification (table name, primary key, foreign keys and attributes), then displays a massage confirming that the structure has been read. 4. The system applies the rules of the selected target structure and produces equivalent object-based specifications (class name, class type, user define type, relationships and attributes). 5. The system displays a message confirming that the target in-memory structure has been produced.

A. M. Maatuk

67

Chapter 5


class OOInMemory // class OOInMemory to construct in-memory structure of OODB schema . { // apply the OO rules to convert from RDB into OODB schema. method ooInMemoryStracture (Vector allTablesIn) { foreach tempTable in allTablesIn do { allForiegnKeys = tempTable.getFkey(); allExporyKeys = tempTable.getExportkey(); primaryKey = tempTable.getPkey(); allAttributes = tempTable.getAttributess(); createClass(getTableName(),classType , classParent ); setOOInMemoryAttributes(allAttributes,allForiegnKeys); setOOInMemoryRelationship(allForiegnKeys,allExporyKeys,classType); allClasses.add (ooclass); } checkOOrules(allClasses); listAllClass(allClasses); //call listAllClass method to print all classes and produce OOScript; produceOOScript(allClasses); } method setOOInMemoryAttributes (allAttributesIn, allForiegnKeysIn) { if (allForiegnKeysIn 0) { foreach attrName in allAttributesIn do { String attrb=getType(); String attrName=getAttr(); foreach attrName in allForiegnKeysIn do { String refferenceAttr=ForignKey.getRefferenceAttr(); if (not(refferenceAttr.equals(attrName))) ooclassIn.setClassAttributes(attrName,attrb); } } else { foreach attrName in allAttributesIn. do setClassAttributes(attrName ,attrb ); } } method setOOInMemoryRelationship (allForiegnKeysIn,allExporyKeysIn,ooclassIn,) { if (allExporyKeysIn.0 ) { list primaryColumn ,foriegnAttr ; foreach allExporyKeysIn do { ExportKeys tempExportKeys2, tempExportKeys3; String pkTable2 =tempExportKeys2.getPktable_name(); String fkTable2 =tempExportKeys2.getFktable_name(); String pkColumn2=tempExportKeys2.getPkcolumn_name(); String fkColumn2=tempExportKeys2.getFkcolumn_name(); String pkTable3=tempExportKeys3.getPktable_name(); String fkTable3=tempExportKeys3.getFktable_name(); String pkColumn3=tempExportKeys3.getPkcolumn_name(); String fkColumn3=tempExportKeys3.getFkcolumn_name(); foriegnAttr.add(fkColumn2); primaryColumn.add(pkColumn2); refferenceAttrIn+=fkColumn2+fkTable2; if (not(fkTable2.equals(fkTable3))) { applyRealtionshipRules(refferenceAttrIn,attributeIn,fkTable1,pkTable1,foriegnAttr,primaryColumn,ooclassIn); } } if (allForiegnKeysIn.0 ) { list primaryColumn , foriegnAttr ; foreach allForiegnKeysIn do { String pkTable1 = tempForignKey.getTable(); String fkTable1 = tempForignKey.getRefferenceTable(); String pkColumn1=tempForignKey.getAttribute(); String fkColumn1=tempForignKey.getRefferenceAttr(); if (not(pkTable1.equals(pkTable2))) { applyRealtionshipRules(refferenceAttrIn,attributeIn,fkTable1,pkTable1,foriegnAttr,primaryColumn,ooclassIn); } foriegnAttr.add(pkColumn1); primaryColumn.add(fkColumn1); refferenceAttrIn+=fkColumn1+fkTable1; } } }

Figure 5-7: Pseudo-code algorithm of an OODB in-memory structure

A. M. Maatuk

68

Chapter 5


class ORInMemory // class ORInMemory to construct in-memory structure of ORDB schema. {// apply the OR rules to convert from RDB into ORDB schema. method orInMemoryStracture (list allTablesIn) { list allType ; foreach tempTable in allTablesIn. do { allForiegnKeys = tempTable.getFkey(); primaryKey = tempTable.getPkey(); allAttributes = tempTable.getAttributess(); createORObjectType (tempTable.getTableName(),(type, typeParent); orObjectType.setORInMemoryAttributes(allAttributes); listallType(allType); //call listallType method to print all object types. produceORScript(allType); checkORrules(allClasses);} method setORInMemoryAttributes () { list primaryColumn, foriegnAttr tempAtrributeClass, attrTables, attrFTables, attributeList; if ((allExporyKeysIn = 0) and (allForiegnKeysIn = 0)) { foreach attrName in allAttributesIn do { String attrb=getType(); String attrName=getAttr(); orObjectTypeIn.setORTypeAttributes(attrName,attrb);} } else { String pkTable1, fkTable1, pkColumn1, fkColumn1, attributeIn, refferenceAttrIn, pkTable, fkTable; int i, count=0; foreach attrName in allAttributesIn do { boolean copm, find, find1; String attrb=getType(); String attrName=getAttr(); int attrsize=getSize(); if (allForiegnKeysIn 0) { foreach tempForignKey in allForiegnKeysIn do { pkTable1 = tempForignKey.getTable(); fkTable1 = tempForignKey.getRefferenceTable(); pkColumn1=tempForignKey.getAttribute(); fkColumn1=tempForignKey.getRefferenceAttr(); if(fkColumn1.equals(attrName)) { find=true; if(pkTable1.equals(attrTables.elementAt(i-1))) { foriegnAttr.add(fkColumn1); primaryColumn.add(pkColumn1); attrPrimaryTables.add (pkTable1); attrForiegnTables.add(fkTable1); } else { applyRealtionshipRules1 (refferenceAttrIn, pkTable, fkTable, foriegnAttr, primaryColumn, orObjectTypeIn); foriegnAttr.add(fkColumn1); primaryColumn.add(pkColumn1); attrTables.addElement(pkTable1); } if (find = false) {setORTypeAttributes(attrName,attrb); } } } }

Figure 5-8: Pseudo-code algorithm of an ORDB in-memory structure

Phase-3: Generate ODL/SQL script from the in-memory structure This phase consolidates the results gained from phase-2, concerning the static OO/OR target schema. After the system has read the database and produced a hierarchy of inmemory structure that is equivalent to the relational schema, the system sends a message to the user to produce the target schema. The user selects the type of target object-based

A. M. Maatuk

69

Chapter 5


schema to be produced and then the final output of this phase is generated, which will be the ODL/OR script. 1. The user selects the appropriate target schema (OODB or ORDB) to be produced. 2. The system reads the in-memory structure of all object-bases that are related to selected target schema. 3. The system displays a message confirming that the process of reading the inmemory structure is in progress. 4. The system defines each object-based specification (class name, class type, relationships and attributes) and generates the script of the object-based schema. 5. The system confirms that the target schema script is generated.

5.4 Summary This chapter has introduced a prototype design to demonstrate our methodology, describing the strategic, architectural and details of the design. Although a source relational schema can be loaded into the system as a source-to-source schema, we considered working with a database using data dictionary tables to deal with a real database and to avoid the complications of unfamiliar schema forms. The strategic design is detailed and sketched in section 5.3, explaining the prototype development. The prototype has been developed in Java with JDBC and Oracle 9i to construct an inmemory structure of an RDB to be re-constructed into an equivalent OO/OR in-memory structure to generate an object-based schema. The prototype design involved three main phases as follows: Phase-1: Construct an in-memory relational schema structure. Phase-2: Transfer an RDB in-memory structure into an equivalent object-based inmemory structure, which consists of two parallel processes: 





Phase-3: Generate ODL/SQL script automatically from an OO/OR in-memory structure. A. M. Maatuk

70

CHAPTER SIX EVALUATION OF THE PROTOTYPE

Chapter 6

Evaluation of the prototype

Chapter 6 Evaluation of the prototype To illustrate our methodology of converting relational to object-based schema, a prototype has been developed. This prototype is proposed to demonstrate our methodology providing some of the concepts behind the likely schema conversion rules that would assist the DBA in converting an existing RDB into an OODB/ORDB schema. The system has been developed in Java environment and supports connections to Oracle 9i database and data dictionary using JDBC, which sends SQL statements to a database server for execution. There are several mapping tools and prototypes that provide object technology and RDB migrations. Persistence [2003] presents a product for object/relational mapping to generate application objects code for an RDB. “Persistence Software's tools allow the object model to impose as few constraints on the relational schema as possible, and viceversa” [Persistence, 2003]. The system includes various tools that help with the mapping process, such as Data Dictionary Reader (DDR) and Persistence Object Builder (POB). The DDR reads data dictionary tables to get information about an existing database schema to be imported as a result file into the POB mapping tool to generate an object model. Monk et al. [1996] describe a tool for system migration. The tool is for transforming an RDB schema into an OODB schema and data conversion, and allows client programs to use the new database. The Object Integration Server (OIS) produced by Ontos [2003] provides the user with a fast and interactive way of integrating OO applications with an RDB. The product contains a schema translator that allows the user to select from several object/relational converting possibilities to translate an existing RDB into an OODB schema.

Then, the user carries out the process interactively

choosing the best solution for mapping. It can be observed that the user‟s intervention is required in all of these tools. However, the main difference between the systems mentioned above and the prototype proposed in this project is that our prototype is fully A. M. Maatuk

72

Chapter 6


automatic and because our methodology considers generating OODB and ORDB schemas at the same time, in-memory representations are proposed to avoid reading an existing RDB twice. An in-memory structure has been implemented under the prototype using Java classes, methods and interfaces, defining an effective structure of relational tables with their attributes and constraints in a given database while the system is running. Our prototype interacts with Oracle to construct an RDB in-memory structure. Once the structure is constructed, a target object-based schema to be produced is selected. Then by applying the relevant target schema conversion rules, the prototype constructs a new target in-memory structure, which will be translated to produce an OODB or ORDB SQL schema automatically. A data dictionary as input file holding information about an RDB schema is proposed in some methods, such as in Persistence [2003]. However, our prototype is based on querying data dictionary tables automatically during a connection to an existing database to obtain information about tables, their attributes and constraints. Data dictionary is one of the DBMS‟ components. The stored data in a data dictionary are called metadata. It is owned by the SYS user and is created automatically when a database is created to provide all information about objects in databases. Subsequently, Oracle updates the data dictionary every time a DDL statement is processed. A data dictionary consists of base tables and user-accessible views.

Base tables store

information about user-defined objects in the database. Data dictionary base tables are created and must stay in the SYSTEM table space. User-accessible views translate the base table data in order to display information stored in the base tables, such as table names and constraints. Users do not often access base tables directly, whereas users can access user-accessible views. At certain points in the database processes, Oracle reads the data dictionary to verify that schema objects exist, and it always updates the data dictionary to reflect changes in database structure and data. Oracle‟s data dictionary views, such as ALL_TABLES, ALL _TAB_COLUMNS and ALL_CONSTRAINTS, can be queried using SELECT statement to provide the prototype with the following information needed while working with an RDB: A. M. Maatuk

73

Chapter 6




The definitions of schema databases objects (tables, sequences, indexes, etc)



Integrity constraint information



Default column values

Also a JDBC API was used to construct such an RDB in-memory structure. JDBC is a standard set of Java classes providing easy and efficient access to an RDB and data dictionary tables through Java programs. It starts by connection with a database, sends SQL statements and processes the results. JDBC consists of the java.sql and the javax.sql packages. The prototype has used some useful interfaces of java.sql package, such as: 

DriverManager: makes a connection with a database.



Statement: used for sending SQL statements to a database.



Connection: used to provide methods for creating statements.



ResultSet: used for retrieving and updating the results of a query.



DatabaseMetaData: standard mapping of Metadata, which provides information about the database.



ResultSetMetaData: used to provide information about the columns of a ResultSet object.

The JDBC provides full access to the metadata of a database using DatabaseMetaData methods, which quickly retrieve a description of a given table‟s columns and constraints from the data dictionary in the form of ResultSet objects, such as getPrimaryKeys (arguments) and getExportedKeys (arguments). DatabaseMetaData methods receive arguments that are String patterns. For instance, the getPrimaryKeys (arguments) method gives a description of the given table's primary key columns, and the getExportedKeys (arguments) method gives a description of the foreign key exported by a table, which references the given table's primary key columns. Figure 5-2 shows an RDB in-memory structure that has been constructed by the prototype. When a table is read, its primary key (in sequence if it is composed), foreign keys, and all attributes are read constructing an inheritance hierarchy. Moreover, if the primary key is exported to be a foreign key in other tables, it will be added to the A. M. Maatuk

74

Chapter 6


hierarchy, which holds every key with related tables whether it is a single or composite key. Foreign keys and Export keys are to show the relationship on both sides. From here, each table with its attributes and constraints in this hierarchy is treated as a single block, which will be added to the RDB in-memory structure. Three options are available: 1) construct an RDB in-memory structure and list all tables displaying their attributes and constraints; 2) construct an OODB schema; or 3) construct an ORDB schema, which leads to the production of an appropriate script. The three options are managed by three main programs: (R-In-memory, OO-In-memory and OR-In-memory respectively). Each of these three programs works with other small programs (java classes) to do specific tasks. For example, the R-In-memory program constructs an RDB in-memory structure, and so on. The three programs are managed by the controller program (Main), which has the responsibility to connect to Oracle and the data dictionary using JDBC. The object-based definition‟s name and attributes will be constructed into another in-memory structure. Figures 5-5 and 5-6 show OO and OR in-memory structures respectively, which have been constructed by the system after applying the appropriate conversion rules. Most conversion rules that can be programmed are considered in our prototype. However, since our conversion process is different from hand written conversion process, some restricted concepts are proposed as well due to, for example, the difficulty of determining multi-valued attributes and whether the collection of objects should be stored as nested tables or arrays. Using the example of a relational schema shown in Figure 6-1, we will focus on all aspects of our prototype‟s results during the conversion process. When the system is ran, the Company_rel RDB schema is read to construct an inmemory structure containing a list of tables. Each element of the list represents one table with attributes and constraints. In addition to its name, a table contains four lists (Java Vector) as in the sample shown in Figure 6-2. 

One vector contains the table‟s columns and their domains.



Another vector contains the table‟s primary key, in sequence if it is composed.

A. M. Maatuk

75

Chapter 6




A third vector contains the table‟s foreign keys exported by a table to other tables and their columns.



A final vector contains the table‟s foreign keys, their primary exported column and their table‟s name.



EMPLOYEE (SSN, FNAME, SNAME, LNAME, BDATE, ADDRESS, SALARY, MARITAL_STATUS, SUPERSSN*, DNO*) FOREIGN KEY (SUPERSSN) REFERENCES EMPLOYEE (SSN) FOREIGN KEY (DNO) REFERENCES DEPT (DNUMBER));



EMPLOYEE_SUPER (ESSN*, OVERTIME_HOUR, HOUR_COST) FOREIGN KEY (ESSN) REFERENCES EMPLOYEE (SSN));



DEPT (DNUMBER, DNAME, MGRSSN*, MGRSTARTDATE) FOREIGN KEY (MGRSSN) REFERENCES EMPLOYEE (SSN)



DEPT_LOCATION (DNUMBER*, DLOCATION) FOREIGN KEY (DNUMBER) REFERENCES DEPT (DNUMBER)



PROJ (PNUMBER, PNAME, PLOCATION, DNUM*) FOREIGN KEY (DNUM) REFERENCES DEPT (DNUMBER)



WORK_FOR (ESSN*, PNO*, HOURS) FOREIGN KEY (ESSN) REFERENCES EMPLOYEE (SSN) FOREIGN KEY (PNO) REFERENCES PROJ (PNUMBER)



DEPENDENT (ESSN*, DEPENDENT_NAME, SEX, BDATE, RELATIONSHIP) FOREIGN KEY (ESSN) REFERENCES EMPLOYEE (SSN)

( - ): means primary key. ( * ): means foreign key. Figure 6-1: The company_rel relational database schema

A. M. Maatuk

76

Chapter 6


The In-memory table DEPT has the following four vectors: Primary key DNUMBER Exported keys DNUMBER exported to PROJ (DNUM), DEPT_LOCATION (DNUMBER), and EMPLOYEE (DNO) Foreign keys MGRSSN exported from EMPLOYEE (SSN) Attributes (DNUMBER, DNAME, MGRSSN, MGRSTARTDATE) The In-memory table PROJ has the following four vectors: Primary key PNUMBER Exported keys PNUMBER exported to WORK_FOR (PNO) Foreign keys DNUM exported from DEPT (DNUMBER) Attributes (PNUMBER, PNAME, PLOCATION, DNUM) Figure 6-2: Sample of vectors of an RDB in-memory structure

The vector called All-tables contains all RDB tables, every one of which contains the above four vectors. For example, the structure of these vectors for DEPT table shown in Figure 6-2 will be constructed as in Figure 6-3: 

PrimaryKey vector contains: TABLE_NAME

COLUMN_NAME

DEPT



DNUMBER

ForiegnKeys vector contains: PKTABLE_NAME

EMPLOYEE



PKCOLUMN_NAME

SSN

FKTABLE_NAME

DEPT

FKCOLUMN_NAME

KEY_SEQ

MGRSSN

1

FKCOLUMN_NAME

KEY_SEQ

DNUM DNUMBER DNO

1 1 1

ExporyKeys vector contains: PKTABLE_NAME

DEPT DEPT DEPT



KEY_SEQ

1

PKCOLUMN_NAME

DNUMBER DNUMBER DNUMBER

FKTABLE_NAME

PROJ DEPT_LOCATION EMPLOYEE

Attributes vector contains: column-Name

DNUMBER DNAME MGRSSN MGRSTARTDATE

columnSize

2 10 2 -

columnType

CHAR CHAR CHAR DATE

Figure 6-3: The construction of vectors for DEPT table in the RDB in-memory structure A. M. Maatuk

77

Chapter 6


Now, an in-memory relational structure has been constructed. Based on this, an OODB/ORDB in-memory structure can be built and a related schema can be generated.

6.1 Converting an RDB in-memory into an equivalent OO inmemory structure.

6.1.1 Identifying OO classes, their kinds and parents The first step in this process is to identify and classify OO classes, their types and parents. Based on the in-memory RDB structure, the table‟s name will become a class name, and using the primary key and foreign keys vectors and applying our methodology rules will specify class types and their parents. By applying the rule of 4.1.1 we can classify classes as super, sub, component or relationship classes. Example: TABLE WORK_FOR will be converted into the following class. class WORK_FOR ( extent work_fors, key essn,pno) { attribute string hours; relationship EMPLOYEE essnwork_for inverse EMPLOYEE :: ssnemployee; relationship PROJ pnumberproj inverse PROJ :: pnowork_for};

WORK_FOR is a relationship table with its own attributes and its key consists of disjoint foreign keys (essn and pno). Therefore, the WORK_FOR relationship table will be converted into a relationship class holding its attributes with two relationship attributes that represent both the EMPLOYEE and PROJ classes. The ODL of ODMG-standard is assumed as the syntax of the OO schema in our prototype. Hence, key words such as extent, inverse and extends are proposed. Moreover, extending classes is proposed by adding the letter (s). The Person and Employee classes should be extent as people, however, this is difficult to manage in our prototype. Therefore, WORK_FOR will have extent work_for with (s), to become work_fors.

A. M. Maatuk

78

Chapter 6


6.1.2 Identifying the OO class attributes Many conversion tools, such as Monk et al. [1996] and Ontos [2003] direct and allow the user to identify assumptions during the mapping of attributes. Multi-valued attributes could be mapped into a collection of attributes using set, list or bags. Composite attributes may be mapped into a single attribute to be used within more than one class. However, it is difficult for our prototype to specify whether attributes are multi-valued or composite, unless such attributes are modelled as a separate table. Composite attributes can be discovered using a semi-automatic method whereby a user may wish to intervene and direct the system to adopt a different action. Therefore, columns in the relational schema will be mapped into class attributes. By means of Java scalar type, the column domain is converted to be a similar type, unless it is not supported by OODBs. Using ResultSetMetaData, information about the column‟s names and data types can be obtained. Some information can be retrieved from the ResultSetMetaData using getColumnName () and getColumnType () methods. Since there is no correspondence between the types defined in java.sql.Types and types defined in an RDB, the latter will be mapped by the JDBC driver to a similar Java type. For example, CHAR and its group (i.e. VARCHAR2) will be converted into “string”. Table EMPLOYEE will be converted into the following class: class EMPLOYEE (extent employees, key ssn) { attribute string ssn; attribute string fname; attribute string sname; attribute string lname; attribute date bdate; attribute string address; attribute decimal salary; attribute string marital_status; attribute struct {string dependent_name; string sex; date bdate; string relationship;} dependent; relationship DEPT mgrssndept inverse DEPT :: ssnemployee; relationship set superssnemployee inverse EMPLOYEE :: ssnemployee; relationship WORK_FOR essn inverse WORK_FOR :: ssn; relationship DEPT dnoemployee inverse DEPT :: dnumberdept; relationship EMPLOYEE ssnemployee inverse EMPLOYEE::superssnemployee};

After the conversion process, we can see that the table‟s name and columns have been converted into an OO class name and attributes. The CHAR domain is converted into a A. M. Maatuk

79

Chapter 6


string. The FNAME, SNAME and LNAME columns are converted into fname, sname and lname. However, in hand written conversion and some mapping tools, these columns could be converted into record NAME using ODMG, which cannot be considered in the automatic methods without user help. Also Dependent table is mapped into a set-valued attribute as struct, because it does not participate any relations except its parent Employee.

6.1.3 Identifying OO class relationships By querying data in the database and applying the binary relationship rule in 4.1.2.1, the relationships amongst OO classes can be determined using the foreign keys and export keys vectors. They hold every attribute in a table that is exported by another table, including the primary key and the table that exports that key. Function applyRealtionshipRules (relationshipAttr, inverse, pKtab, fKtab, foriegnKeys, primaryKey, ooClass) {// this function applies for each in-memory table to determine the relationships between classes int countResult =0; String str1=""; String list st= primaryKey.size (); String query="select * from "+ pKtab; ResultSet rs =executeQuery (query); while (rs.next()) { for ( int i = 0 ; i < st.length ; i++) {st[i] = rs.getString(i+1);} String query1="select count (*) from "+fKtab+" where "; for ( int i = 0 ; i < st.length ; i++) { if((i = st.length-1) OR (st.length=1)) str1= str1+ foriegnKeys.elementAt (i)+" = "+"'"+ st[i]+"'"; else str1= str1+foriegnKeys.elementAt (i) +" = "+"'"+ st[i] +"'"+" and "; } query1= query1+str1; ResultSet rs1 =executeQuery (query1); While (rs1.next ()) { String sss = rs1.getString (1); int count=toInteger (sss); if (count>1) { countResult =count;} } } if (countResult>1) ooClass.setRelationshipAttribute (relationshipAttr,"set ", fKtab, inverse, pKtab); else ooClass.setRelationshipAttribute (relationshipAttr,"one", fKtab, inverse, pKtab); }

Figure 6-4: Pseudo-code algorithm for specifying relationship by querying data

A. M. Maatuk

80

Chapter 6


Each primary column in a primary table is selected and queried with the foreign key column and table name of another side foreign table using the SELECT COUNT (*) statement. If the results exceed the number 1, the relationship is many; otherwise (if the result is 0 or 1) the relationship is one. Figure 6-3 shows the algorithm of the querying data mechanism to specify relationships during the reconstruction of object-based inmemory structures. Example: to see how the specifying relationship algorithm works, let us implement it on the following tables: EMP EMP_NO E1 E2 E3 DEPT DEPT_NO D1 D2 D3

EMP_NAME Smith Jones Robes

DEPT_NAME Products Sales Accounts

SALARY 9050 8000 7000

DEPTNO* D1 D2 D2

BUDGET 100000 250000 950000

Figure 6-5: Relational tables

Say, the relationship to be specified is related to DEPT, so it is the PKtable, and its table name and foreign keys are required (provided from the RDB in-memory structure). Then, 

PKtable = DEPT



Primary key = DEPT_NO

The DEPT_NO key exported to EMP as DEPTNO, so 

FKtable = EMP



Foreign key = DEPTNO

Now, we need to query the PKtable to get its data as follows: Query1= select * from DEPT; From this, we will get all data in DEPT and the data of the primary key is selected (using next () method provided by JDBC), which is D1, D2 and D3, which will then be used in another repeated queries of COUNT statement in EMP to get the result of the query. A. M. Maatuk

81

Chapter 6


Depending on whether the result is 1, the relationship kind is specified accordingly as follows: Query2 [1] = select count (*) from EMP where DEPTNO =‟D1‟; Query2 [2] = select count (*) from EMP where DEPTNO =‟D2‟; Query2 [3] = select count (*) from EMP where DEPTNO =‟D3‟;

countResult =1 countResult =2 countResult =0

Since there is a countResult >1 then the relationship of DEPT class will be defined as “many” while re-constructing its in-memory structure as follows: ooClass.setRelationshipAttribute ("deptno_ dept", "set ", "EMP", "dept_no_ emp", "DEPT");

relationship attribute = dept_no _dept, defined in class DEPT, relationship type = "set", and inverse relationship = deptno_ emp comes from related class EMP. We believe that querying the data provides a safe and efficient way to specify relationships amongst objects, although it takes some time in the case of huge amounts of data. In example 6-1, the form of some generated relationships can be seen below: relationship set dept_no _dept inverse EMP :: deptno_ emp;

The relationship tells us that every department employs one or more employees and every employee employed by one department. In some tools, such as Persistence [2003] and Fahrner and Vossen [1995], relationship names can be determined using an ER Model or UML approach. However, specifying relationships is difficult in programmed methods unless an Edit option is added to the system to modify the relationship‟s name after the converting process is finished. Therefore, linking together attributes that represent a relationship name is proposed instead in our prototype, although this may result in long meaningless names. For example, consider the following relationship: relationship attribute DEPT dnoemployee inverse DEPT:: dnumberdept; This means that, via the dno attribute in the employee table (linked together to model the relationship name), a relationship is defined with the dnumber attribute in the dept table. This relationship is equivalent to the following hand-converted relationship:

A. M. Maatuk

82

Chapter 6


relationship DEPT works-for inverse DEPT:: employs;

Foreign keys should be dropped from the new target class and replaced by a relationship attribute. Moreover, the two related classes should inversely reference each other showing the relationships between them, and both of them should imply the inverse references. Each object-class that has recursive relationship may have two attributes, once as an owner and once as a member. This can be seen clearly in the following two relationships from the above EMPLOYEE class: relationship set superssnemployee inverse EMPLOYEE :: ssnemployee; relationship EMPLOYEE ssnemployee inverse EMPLOYEE :: superssnemployee

The first relationship shows that an employee could be a supervisor of more than one employee. The second relationship shows that every employee has only one supervisor. Aggregation and inheritance relationships could be converted by applying our methodology rules in 4.1.2.2 and 4.1.2.3 Table EMPLOYEE_SUPER will be converted into the following sub-class: class EMPLOYEE_SUPER extends EMPLOYEE ( extent employee_supers, key essn) { attribute string overtime_hour; attribute decimal hour_cost}; The EMPLOYEE_SUPER table holds the EMPLOYEE table‟s primary key, which means that it inherits all of the parent attributes and its key ESSN. The key word extends means that it is a sub-type of the super-type EMPLOYEE. The new OODB in-memory structure for each class will then be re-constructed as follows: 

The class name is mapped from the table name.



The class kind (i.e. super-class or relationship class) and its parent can be specified using the primary key and foreign keys vectors in the RDB in-memory structure and conversion rules.



The class key will be extracted from primary key vector.

A. M. Maatuk

83

Chapter 6




Vector contained attributes will be mapped from the in-memory RDB attributes vector for each table after dropping attributes which represent foreign keys or adding extra attributes such as set-valued attributes.



The relationship attributes vector, keeping class relationships and inverse relationships, are defined using foreign keys and exported keys vectors, and querying the data.

6.2 Converting an RDB in-memory into an equivalent OR inmemory structure 6.2.1 Identifying object-types, their kinds and parents Using the primary key and foreign keys‟ vectors in the in-memory RDB structure and applying the ORDB conversion rules, types and their parents are specified. Object-types will be classified as super, sub, or component types. Object-types are categorized into two levels at this stage of the process. Objects-types that are a part of other objects, inherit others or represent a nested table within other objects are categorized to a lower level than their parents, which will be categorized to a higher level unless the parent has become nested or inherits other types. All the higher level object-types will be considered to be object tables in the last stage of the converting process. 6.2.2 Identifying an object-type’s attributes and domains In hand-written conversion, collections are used to store multi-valued or composite attributes in a separate object-type, and this can result in nested tables or varrays to be used in many object-types [Gietz and Dupree, 2002]. For example, attributes fname, sname, and lname could be held in an object-type called name. Also an address could be modeled as a single "Address" object, which contains street, city, and postcode attributes [Gietz and Dupree, 2002]. However, it is difficult to determine such cases in our prototype. Therefore, attributes and their domains in the RDB structure will be converted into class attributes in their domains within object-types in the ORDB structure. A. M. Maatuk

84

Chapter 6


Table EMPLOYEE will be converted into the following object-type: CREATE TYPE dependent_nested_ref_table AS TABLE OF dependent_objType;

CREATE OR REPLACE TYPE EMPLOYEE_objType AS OBJECT ( ssn CHAR(2), fname CHAR(10), sname CHAR(10), lname CHAR(10), bdate DATE, address CHAR(20), salary DECIMAL, marital_status CHAR(1), superssn REF EMPLOYEE_objType, dno REF DEPT_objType, dependent_ref dependent_nested_ref_table) NOT FINAL; After the conversion process we can see that the table‟s name and columns are converted into an object-type name and attributes with the same name, attributes and domain. Attributes that represent foreign keys in the RDB structure will be converted into reference data types with a different domain using REF, unless it represents a many relationship or a component object-type, in which cases it will be represented into a collection of objects defined in a nested table within the type that hold the primary key. CREATE OR REPLACE TYPE DEPT_objType AS OBJECT ( dnumber CHAR(2), dname CHAR(10), mgrssn REF EMPLOYEE_objType, mgrstartdate DATE, employee_ref employee_nested_ref_table, proj_ref proj_nested_ref_table, dept_location_ref dept_location_ntabtype) NOT FINAL;

In the above object-type, the mgrssn attribute represented a department manager. Its domain is replaced to be a REF referring to the EMPLOYEE object-type. The employee_ref represents a relationship with the EMPLOYEE type via the employee_nested_ref_table nested table, showing a one-to-many relationship, which means that every Department has many Employees. The NOT FINAL phrase should be specified at the end of all object-types to let them be inherited by other sub-types.

A. M. Maatuk

85

Chapter 6


6.2.3 Identifying object-type relationships using collections

By means of the primary and foreign keys in the RDB in-memory structure, and querying data (in the same manner as an OO querying mechanism) a relationship can be implemented using REF or a collection of objects. If the querying result is less than 2, then the REF keyword will be used to represent the relationship. Otherwise, a collection of nested tables is used. In the case of inheritance relationships the querying process will be ignored, because the relationship has been specified previously. In an aggregation relationship, the parent type will define a nested table of its child object-type, and the foreign key in the child that represents the relationship will be omitted. Object-types that are a part of other objects, or nested within other objects are categorized to a lower level and their parent to a higher level (unless the parent has been nested within other types). To query the collections, nested tables are used for retrieving them as a whole, otherwise, varrays are used [Gietz and Dupree, 2002]. However, nested tables are proposed in our prototype for any collection, because specifying whether or not OR tables are to be queried is not possible in fully automatic methods. CREATE OR REPLACE TYPE DEPT_LOCATION_objType AS OBJECT ( dlocation CHAR(20)) NOT FINAL;

In the above DEPT_objType type we can see that the dept_location_ref represents a relationship with the DEPT_LOCATION object-type using the dept_location_ ref_table nested table, because DEPT_LOCATION is a component of DEPT. In addition, the dnumber attribute will be removed from the DEPT_LOCATION_objType. Sub-types can be created under their super-type, using the clause UNDER. By default, all object-types are defined to be non-inherited in Oracle9i. However, the NOT FINAL clause in the CREATE TYPE statement is recommended for all object-types.

For

example, the table EMPLOYEE_SUPER, which inherits EMPLOYEE, will be converted as the following type: CREATE OR REPLACE TYPE EMPLOYEE_SUPER_objType UNDER EMPLOYEE ( overtime_hour CHAR(2), hour_cost DECIMAL) NOT FINAL; A. M. Maatuk

86

Chapter 6


6.2.4 Identifying OR object tables The last stage in an OR in-memory structure converting process is the creation of object tables. Creating object tables is based on a logical structure of object-type design. Each row in an object table represents a single object instance. Specifying the row object's primary key as its unique OID value is proposed in our prototype. In our example, creating the DEPT_objtab object table is based on the DEPT_objtyp object-type and its primary key (DNUMBER) is the object identifier. All higher-level object-types will be defined as object tables. By this stage the ORDB in-memory structure has been constructed and can be turned into OR SQL script. While producing SQL script, tables in Oracle are accessed and retrieved alphabetically, and object-types in an ORDB in-memory structure will be stored in the same order. This leads to the possibility of creating types before types that refer to it which should have been created first (a problem which can be avoided in hand written conversion). However, to avoid this problem in our prototype, incomplete types can be used via the CREATE TYPE statement without the AS OBJECT clause, as provided by Oracle9i. For instance, in the company-rel schema the first step in producing the OR schema is converting all object-type names as incomplete object-types as follows: CREATE TYPE DEPENDENT_objType; CREATE TYPE DEPT_objType; CREATE TYPE DEPT_LOCATION_objType; CREATE TYPE EMPLOYEE_objType; Secondly, define object-types representing collections of REF for all object-types that represent nested tables and have manipulated more that one object-type (not weak entities) as follows: CREATE TYPE employee_ref_type AS OBJECT (emp_ref REF employee_objType); CREATE TYPE proj_ref_type AS OBJECT (proj_ref REF proj_objType); CREATE TYPE work_for_ref_type AS OBJECT (work_for_ref REF work_for_objType);

Then, every object-type defined as a collection will be denoted as a nested table as follows: CREATE OR REPLACE TYPE employee_nested_ref_table AS TABLE OF employee_ref_type; A. M. Maatuk

87

Chapter 6


CREATE OR REPLACE TYPE proj_nested_ref_table AS TABLE OF proj_ref_type; CREATE OR REPLACE TYPE dependent_nested_table AS TABLE OF dependent_objType;

CREATE OR REPLACE TYPE work_for_nested_ref_table AS TABLE OF work_for_ref_type; Then, the CREATE OR REPLACE TYPE clause is used to replace an incomplete type with a complete definition of object-types. Finally, the object table will be at the end of the schema as follows: CREATE TABLE DEPT_objtab OF DEPT_objType (PRIMARY KEY (DNUMBER)) NESTED TABLE employee_nested_ref_table STORE AS employee_nested_ref_tablentab, NESTED TABLE proj_nested_ref_table STORE AS proj_nested_ref_tablentab; CREATE TABLE EMPLOYEE_objtab OF EMPLOYEE_objType (PRIMARY KEY (SSN)) NESTED TABLE dependent_nested_table STORE AS dependent_nested_tablentab; CREATE TABLE PROJ_objtab OF PROJ_objType (PRIMARY KEY (PNUMBER)) NESTED TABLE work_for_nested_ref_table STORE AS work_for_nested_ref_tablentab; CREATE TABLE WORK_FOR_objtab OF WORK_FOR_objType (PRIMARY KEY (ESSN, PNO));

The new ORDB in-memory structure for each object-type is similar to the OODB inmemory structure, but there are some additional specifications, such as: 

Type levels are added to the object-type structure to show which type should be mapped as OR tables, as described in our methodology.



Object-types that are aggregated and need to be nested within other object-types, or have a “many” relationship from their side, will be stored in a separate vector to be created first as nested tables when generating the OR schema.



Vector contained attributes will be mapped from the in-memory RDB attributes vector. However, attributes representing foreign keys will not dropped, but replaced by references using REFs or collections, unless in aggregation or inheritance relationships.



The relationship attributes vector keeps the type relationships without inverse relationships using querying data.

A. M. Maatuk

88

Chapter 6


6.3 Summary Evaluating our prototype requires us to test all aspects of our methodology to find the desired results. This chapter has illustrated the methodology and conversion rules using given examples of relational schema to be tested. However, since the converting process is not like hand written conversion, some limiting concepts are faced, for example, the difficulty of determining multi-valued attributes and the naming of relationships, and whether collections of objects should be sorted as nested tables or arrays. Reading an RDB and constructing an in-memory structure containing a list of tables is discussed. Each table in the list contains four other Java vectors. One vector contains the table‟s columns and their domains, another vector contains the table‟s primary key, a third vector contains the table‟s foreign keys exported by a table to other tables and their columns, and a final vector contains the table‟s foreign keys. Based on the RDB in-memory structure, sections 6.1 and 6.2 have explained how OO/OR in-memory structures have been re-constructed, identifying OO classes/OR object-types, their attributes and relationships. Moreover, the OODB structure has been turned into an OODB schema, and the ORDB structure has been turned into an OR SQL schema.

A. M. Maatuk

89

CHAPTER SEVEN EVALUATION OF THE PROJECT / APPROACH

Chapter 7

Evolution of the Project

Chapter 7 Evaluation of the project / approach Converting schemas have been discussed by a considerable number of researchers. The general motivation for converting schemas is to construct an object-based model from a relational model, due to the object-based model‟s greater flexibility. This chapter evaluates the project/approach presented in this dissertation focusing on its intentions, reflections on the results and alternative methods that were considered. Converting a schema consists of reconstructing a relational structure to produce a static structure of the target schema in addition to deriving the dynamic methods for the new target schema. However, the main objective of this project is to investigate current migration techniques and to develop an integrated methodology for converting an RDB with constraints into OODB/ORDB schemas using various conversion rules. The method developed was intended to be fully automatic in generating a target schema. Therefore, since such the method is different from semi-automatic and hand-written conversion methods, some object-based modelling features will be lost due to difficulties in programming, such as reuse feature and specifying composite and multi-valued attributes. Given the differences between OO and relational modelling and the similarities between ORDBs and RDBs, there has been much research into conversion from relational into OO schema, but much less on converting relational into OR schema. Most studies done so far have focused on translating an RDB into an OODB or ORDB, such as Xiuzhen [1999] and Yan and Ling [1993]. Some methods consider ER or EER models as mediators during the process, such as Narasimhan et al. [1993] and Chiang et al. [1994]. Some authors recommend removing redundancy by making sure that the relational schema is well structured before the migration process, using MVD [Xiuzhen, 1999]. In addition, some work has not included further detail, for instance, ISA relationships were not considered in Yan and Ling [1993] and Fong [1997]. Moreover, some studies have

A. M. Maatuk

91

Chapter 7


focused on a specific topic of modelling, such as modelling relationships in ORDBs [Christian S, 2000] or translating update operations [Zhang and Fong, 2000]. Existing conversion techniques, in particular those based on a relational model, have focused on the migration of structure in relational schema and integrity constraints. However, integrity constraints are not always made explicit in the schema structure and relational schema can have different forms. The schema does not always come together with its constraints. Chiang et al. [1994] provided a technique for extracting an EER schema from an RDB schema, and proposed the automatic derivation of inclusion dependency. Fahrner and Vossen [1995] proposed 3NF normalization as a part of the first step before mapping the schema. However, this is unprofitable when our goal is mapping an existing RDB schema. Our methodology provides a way of mapping an existing RDB schema into an object-based schema without intermediate models (i.e. an ER model). Since the method has two paths for mapping an RDB schema into OODB and ORDB schemas, and avoids duplication in reading the RDB, it is proposed that a mediator of schema representation (structure) is produced involving all RDB schema information which are needed during the conversion process. To do this, a few things are required to help us in such a process, such as Oracle data dictionary tables and data stored in the database. Integrity constraints have been considered in our method. In case of a given intermediate relational structure has been produced involving all tables, their columns and constraints so that a conversion process of OODB/ORDB can be done as a target schemas. Data stored in the database is used to specify relationships between classes/object-types. No particular OO model is assumed in some methodologies [Fong, 1997]. The ODL of ODMG-standard has been used in others and some work recommends C++ like for modelling class structures [Narasimhan et al., 1993]. Many methods do not support automated conversion [Fong, 1997; Narasimhan et. al, 1993] and some do, but user intervention is required after the conversion process is finished [Monk et al., 1996; Fahrner and Vossen, 1995]. However, all methods mentioned above and others have been taken into account while developing our method. Our method uses ODL ODMG-standard group as the syntax for an OO schema and SQL keywords supported by Oracle9i as the A. M. Maatuk

92

Chapter 7


syntax for an OR schema and also provides a prototype to produce an object-based schema automatically.

7.1 Conversion methodology Many current methods are similar to our strategy for extracting object-types/classes from relations. However, others recommend different strategies. Yan and Ling [1993] specify object-classes by identifying relation clusters. Xiuzhen [1999] proposed a method to avoid the same relational flat structure and to eliminate data redundancy by recommending that a relational schema should be well structured before the migration process is started, using MVD. A relation, R (K, A) is assumed where: A1=K  A; A1 is a set of attributes of R; K is the primary key of R; and A is subset of A1. Thus, depending on whether the K is single or composite and may contain foreign keys, we proposed that R is mapped into a main, relationship, sub or component class. In addition, foreign keys in R are used to specify binary, inherence or aggregation relationships amongst objectbased classes. For relation R [K], it is called a main relation if its key K does not contain any foreign keys, and then it will become an object-class and its attributes will become the class attributes. Object-types can be specified by interfaces and classes in ODMG [Elmasri and Navathe, 2000]. Since interfaces are not instantable and mapping class‟s operations is not considered in our method, the word „class‟ is proposed rather than „interface‟.

Mapping attributes Not all attributes are constant. Narasimhan et al., [1993] have proposed that multi-valued attributes may be mapped into collections of class attributes using sets, lists or bags using classes‟ constructor declarations, which may be offered by OODB languages. Composite attributes, which consist of more than one attribute, are mapped into a single attribute in Narasimhan et al., [1993] and into a separate class in Fahrner and Vossen [1995]. Derived attributes, which are extracted from given data and used for calculation purposes are mapped through class methods [Narasimhan et al., 1993]. However, dynamic A. M. Maatuk

93

Chapter 7


retrieved attributes are not considered in our methodology, because the extraction methods or functions are outside the scope of this research and are not feasible in a relational schema. Basically, columns in an RDB will be mapped into class attributes or object-type columns. Foreign key columns have to be dropped from the new OO schema, to be replaced by a relationship attribute and replaced with another domain (i.e. a REF type or collection of object-types) in an OR schema. Mapping aggregations

An entity A is a weak entity if it depends on the existence of another entity. Although, weak entity mapping is not discussed further in some methodologies [Fong, 1997], it is described in great detail in term of identifying aggregation relationships [Ramanathan and Hodges, 1997]. However, Yan and Ling [1993] stated that a weak entity has to depend on its parent identification in order to be identified if it does not have its own key. A weak entity has to be identified in our method based on an identifier dependency relationship. By assuming two relations R1 and R2, and that their keys are K1 and K2 respectively where K‟ is a part of K1, so, if R1 [K‟]  R2 [K2]: 

If R1 has a relationship with other relations, then R1 will be mapped into a component class C1/obiect-type1 of the parent class C2/obiect-type2.



If R1 has no relationship with other relations except its parent R2, then R1 will be mapped into a set-valued attribute within class C2/obiect-type2.

Mapping inheritances

When relations have the same key types, they are said to represent inheritance relationships, therefore, inheritances are defined using inclusion dependency. Fahrner and Vossen [1995], and Ramanathan and Hodges [1997] have modelled an inheritance hierarchy by duplicating the attributes of the super-class in the sub-class. In Yan and Ling‟s [1993] method, a subclass still contains its key attribute, because this is its own property and it represents the connection between the subclass and its parent super-class, however, they added that if no other relation references the sub-class relation, this A. M. Maatuk

94

Chapter 7


relation has to be mapped as a “fragment” of its parent, rather than an independent class to avoid a “proliferation” of classes. However, there are three forms of representation of inheritance relationships in relational databases. Therefore, as inheritance is provided by object-based databases, and to eliminate the data redundancy that may be caused by the above methods, the simplest form of representing inheritance in relational modelling has been considered in our methodology. Therefore, a parent relation is mapped into a superclass/object-type and a child relation is mapped separately into a sub-class/object-type with its attributes. The super-class and sub-class attributes will not be repeated in both but the sub-class inherits its super-class‟s attributes. Due to our consideration of ODL ODMG-standard and Oracle9i SQL keywords, a foreign key that represents an inheritance relationship has been dropped from the new object-type/class. Moreover, a sub-type inherits the key and attributes of its super-type in an OR object-type using the UNDER clause, whereas, a sub-class inherits its super-class in an OO schema using the (extends) clause.

Mapping associations

Binary relationship mapping takes the value of relationships in a relational model (foreign key) and maps them into the OO model as association (relationship) attributes [Fong, 1997]. Association relationships can be defined as one-to-one, one-to-many, and many-to-many relationships, using “inverses”. The relationship could be non-recursive or recursive. A non-recursive relationship is an association between two or more objects; whereas, a recursive relationship is where the entity type participates itself in the relationship twice, once as owner and once as member [Narasimhan et al., 1993]. In our mapping process foreign keys in each relation should be determined and mapped into new classes as association attributes. However, foreign keys in the case of OO mapping have been dropped from the new schema and replaced by a relationship attribute. Moreover, the two classes should contain inverse reference that shows their relationship. In the case of OR mapping, a foreign key will be mapped with a different domain as a REF or a collection of objects.

A. M. Maatuk

95

Chapter 7


In a one-to-many relationship, relations on two sides are mapped into objectclasses and the relation that holds the primary key will map with a relationship attribute having a set of instances (collection-valued) of the class that holds the foreign key. Because of normalisation problems, many-to-many relationships in relational databases should not be allowed. Therefore, an additional relation (section relation) should be created to hold the related two relations‟ primary keys. Yan and Ling [1993] stated that a relation whose primary key consists of disjoint foreign keys is handled as a relationshipclass. Classes that represent a binary relationship are replaced by inverse relationships, defined within each class referred to it [Fahrner and Vossen, 1995]. However, because OO modelling supports many-to-many relationships, we proposed that both classes will define a collection of relative class instances. Moreover, a relation that consists of more then two disjoint foreign keys in its primary key is not treated as a relationship-class. One of the main features of our method is that it specifies the binary relationships between objects by querying stored data in the database. Querying data provides an easy and efficient way to specify relationships, for example, consider the following schema: EMPLOYEE (ssn, fname, sname, lname, bdate, address, salary, marital_status, superssn*, dno*) DEPT (dnumber, dname, mgrssn*, mgrstartdate)

In the above schema and without real data, it is difficult to determine that every Employee works in only one Department and that he/she might be a supervisor of none, one or more than one other Employees. However, this process is simplified by querying the data, although it takes some time in the case of huge amounts of data.

7.2 Summary This chapter has discussed, evaluated and reflected on the project/approach, and other methods considered. To begin with, differences and similarities between existing techniques and the proposed technique were discussed. Most methods have proposed translating an RDB into an OODB or ORDB. Some methods consider ER or EER models as intermediaries, whereas others focus on specific topics, such as modelling A. M. Maatuk

96

Chapter 7


relationships and translating update operations. We have discussed how our methodology considered other approaches and what it was intended to achieve. Our methodology provides for mapping an existing RDB schema without intermediate models into OODB and ORDB schemas. A mediator representation is proposed involving RDB information to avoid duplication in reading the RDB. Different aspects of conversion rules have been discussed and evaluated, and contrasting these with other approaches. Relations, and their attributes, aggregation, inheritance and association, have all been assessed and described.

A. M. Maatuk

97

CHAPTER EIGHT CONCLUSIONS AND RECOMMENDATIONS

Chapter 8

Conclusion and Recommendations

Chapter 8 Conclusions and recommendations The migration of existing relational into object-based databases has become an attentiongrabbing issue to improve productivity and flexibility. The motivation for converting schemas is to build an object model on a relational model. Such a process is sometimes carried through by means of other models, such as ER and EER. The migration process is not straightforward, therefore, problems are usually faced such as the non-equivalence of databases. This dissertation has aimed to investigate current migration techniques to produce a new methodology for integrating and converting an existing RDB with constraints into the static structure of an object-based schema using conversion rules. RDB, OODB, ORDB and previous significant research for migration schema techniques are discussed. Then, a new methodology is proposed to construct a static structure of an object-based from an RDB schema. Primary keys and foreign keys are used to identify classes/objecttypes and relationships amongst them. An ODL of ODMG-standard group is used as the syntax for an OO schema, and SQL keywords are used as the syntax for an OR schema in our method. Data dictionary tables are used to get RDB information, to construct an inmemory structure of relational tables with their constraints. Then, by applying the relevant schema conversion rules, a source structure is re-constructed to build a new object-based in-memory structure. A prototype is developed to demonstrate the methodology, giving examples to illustrate how the objectives are achieved. The prototype has been developed to interact with Oracle 9i databases using JDBC. Querying the data stored in the database is proposed in order to identify relationships amongst objects. Based on an OODB/ORDB in-memory structure, object-based schemas are generated automatically. The main features of this method involved the following: 

Identify an existing RDB to generate both an OODB and an ORDB schema.

A. M. Maatuk

99

Chapter 8




Propose an intermediate representation containing RDB information as source to avoid accessing RDB twice during the migration process.



Consider integrity constraints such as functional dependency and inclusion dependency.



Query data stored in the database to identify relationships amongst objects.



Consider ODL of ODMG-standard group as the syntax of an OO schema and SQL keywords supported by Oracle9i as the syntax of an OR schema.



Propose a prototype to produce a target object-based script automatically.

All of the above features and steps helped to produce a methodology and algorithms that perform the migration process. An object-based schema can be produced and the migration process can be tested with a real database. Because our methodology considers generating OODB and ORDB schemas at the same time, an intermediate representation holding all information needed about an RDB was helpful in order to avoid duplication in accessing and reading a source RDB during the process. Also data dictionary tables that are created and updated automatically by Oracle when a database is created have provided us with recent metadata information about objects in the RDB. Furthermore, we have chosen the ODMG-standard for OODB and SOL3 key words for ORDB because they have been adopted as standards by several vendors. Most conversion tools allow the user to identify assumptions to direct the mapping process. However, the prototype we have proposed is fully automatic and avoids user intervention. Java's ability to connect to an RDB and the reusability of code makes it preferable for use with the migration of databases through JDBC and its understanding of the metadata. The JDBC metadata classes and their methods were useful and saved time in providing full access to metadata and deriving information describing the database‟s contents. Defining relationships between objects based on the correspondence amongst attributes and inclusion dependency may bring complexity to the mapping process. However, querying data stored in a database by our proposed algorithm for specifying relationships between objects helped to resolve the problems of synonymous and homonyms, so that makes the process easier and more efficient.

A. M. Maatuk

100

Chapter 8


For future work, we recommend that related issues should be tackled such as data conversion, translating database operations including query and update operations, and further prototype development. Data conversion entails recognising retrieved data from an RDB to be understood by users of the object-based schema. In data conversion another extra two steps are needed, which are to unload and reload data from an RDB into an OODB. Such processes will expand our work into a complete conversion methodology. In migrating database applications, the conversion procedure involves the conversion of schema, data, and application programs. Therefore, another interesting issue is database operations mapping such as INSERT and DELETE operations. Considering the schema mapping, database operations embedded in applications need to be mapped into their correspondents in object-based schema. Relationship names can be determined using ER Models or UML approach in hand-written conversion. However, specifying relationship names was difficult in our prototype. To identify relationship names, linking together attributes that represent the relationship is proposed. However, such a process makes the relationship name meaningless, therefore, an extra interface or Edit option might be needed for solving conflicts in attribute names so that the prototype modifies the relationship names after the converting process is finished. On the other word, a semi-automatic method might be a good solution whereby a user intervenes and directs the system to assume suitable relationship names.

A. M. Maatuk

101

REFERENCES AND BIBLIOGRAPHY

References

References 

[Cattell, 2000] R.G.G. Cattell (Ed.). The Object Database Standard: ODMG-3.0. Morgan Kaufmann, Los Altos, CA, (2000).



[Chiang et al., 1994] R. H. L. Chiang, T. M. Barron and V. C. Storey Reverse engineering of relational databases: Extraction of an EER model from a relational database. Data & Knowledge Engineering, Vol. 12, Issue 2, pp.107-142, March (1994).



[Christian, 2000] Christian Soutou. Modeling relationships in object-relational databases. Data & Knowledge Engineering. Vol. 36, pp. 79-107 (2001).



[Connolly and Begg, 2002] T. Connolly and C. Begg. Database Systems. (Third Edition.), Addison-Wesley, New York (2002).



[Date, 2000] Date C. J. An Introduction to Database Systems. Addison-Wesley, New York (2000).



[Elmasri and Navathe, 2000] R. Elmasri and S.B. Navathe. Fundamentals of Database Systems. Addison-Wesley, New York (2000).



[Fahrner and Vossen, 1995] Fahrner C. and Vossen G. Transforming relational database schemas into object-oriented schemas to ODMG-93. In Proceeding of the 4th international conference on deductive and object-oriented database. Singapore, University of Singapore, pp. 429-446 (1995).



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



[Getta, 1993] J. R. Getta, Translation of Extended Entity-Relationship Database Model into Object-Oriented database Model. In: D. K. Hsiao, E. J. Neuhold, R. Sacks-avis (Eds). Interoperable Database Systems. Elsevier Science Publishers B. V. (North-Holland), pp87-100 (1993).



[Gietz and Dupree, 2002] Gietz W. and Dupree C. Oracle9i Application Developer's Guide - Object-Relational Features, Release 2 (9.2). Oracle Corporation (1996, 2002).

A. M. Maatuk

103

References



[Leavitt, 2003] Whatever Happened to Object-Oriented Databases? Leavitt Communications, Inc. (2003).



[McClure, 1997] McClure, S. IDC Bulletin #14821E. August, (1997).



[Michael, 2003] Michael Ley, ACM SIGMOD. (2003). Available at: www.acm.org.



[Moline et al., 2002] Hector Garacia-Moline, Jeffrey D. Ullmam and Jennifer Widom. Database System: The Complete Book, Prentice-Hall Inc., New Jersey. (2002).



[Monk et al., 1996] S. Monk, J. A. Mariani, B. Elgalal and H. Campbell, Migration from relational to object-oriented databases. Information and Software Technology, Vol. 38, issue 7, July, pp. 467-475, (1996).



[Narasimhan et al., 1993] Narasimhan B., Navathe S. B., Jayaraman S. On mapping ER and relational models into OO schemas. In: Elmasri, V. Kouramajian, B. Thalheim (Eds.). Entity relationship Approach-ER‟93, LNCS823, Springer, Berlin, pp.402 (1993).



[Ontos, 2003] Ontos Object Integration Server, (2003). Available at www.ontos.com



[Persistence, 2003]

Persistence Software Inc., (1991-2003).

Available at:

www.persistence.com /developers. 

[Ramakanth,2001] Ramakanth Systems

-

The

road

S. Devarakonda.

ahead.

ACM,

Inc.,

Object-Relational Database (2000-2002).

Available

at:

www.acm.org/crossroads/xrds7-3/ordbms.html. 

[Ramanathan and Hodges, 1997]

S. Ramanathan and J Hodges. Extraction of

Object-Oriented Structure from Existing Relational Databases. SIGMOD, record 26 1, pp.59–64 (1997). 

[Stonebraker et al., 1998] J. M. Stonebraker, P. Brown and D. Moore. ObjectRelational DBMSs: The Next Great Wave and Object-Relational DBMSs: Tracking the Next Great Wave, (1996, 1998).



[Tari, 1993] Z. Tari. Interoperability between Database Models in: D. K. Hsiao, E. J. Neuhold, R. Sacks-avis (Eds). Interoperable Database Systems. Elsevier Science Publishers B. V., pp 101-116 (1993).

A. M. Maatuk

104

References



[Wan and Qing, 1999] K wan and Qing Li. A hybrid approach to convert relational schema to object-oriented schema. Information Sciences, Vol. 117, issues 3-4, pp. 201-241, August (1999).



[Xiuzhen et al., 1999] Z. Xiuzhen, Z. Yanchun, Fong J. and Jia X. Transforming RDB schema into well-structured OODB schema. Information and Software Technology, Vol. 41, issue 5, pp. 275-281, March (1999).



[Yan and Ling, 1993] L. L. Yan and T. W. Ling. Translating relational Schema with Constraints into OODB Schema. In: D. K. Hsiao, E. J. Neuhold, R. Sacks-avis (Eds). Interoperable Database Systems (DS-5) (A-25) Elsevier Science Publishers B. V. (North-Holland). pp. 69-85 (1993).



[Zhang and Fong, 2000] X. Zhang and J. Fong. Translating update operations from relational to object-oriented databases. Information and Software Technology. Vol. 42, issue 3, pp. 197-210, February (2000).

Bibliography 

[Charatan and Kans, 2001] Quentin Charatan and Aaron Kans. Java in Two Semesters, McGraw-Hill Education, U. K, (2001).



[Dillon and Tan, 1993] T.S. Dillon and P.L. Tan. Object-oriented Conceptual Model. Prentice-Hall, Englewood Cliffs, NJ, (1993).



[Fong, 2002]

J. Fong. Translating object-oriented database transactions into

relational transactions. Information and Software Technology. Vol. 44, issue 1, pp. 41-51, January (2002). 

[Kroenke, 1995] D.M. Kroenke. Database Processing Fundamentals, Design, and Implementation (fifth ed.), Prentice-Hall, Englewood Cliffs, NJ (1995).



[Koffman and Wolz, 1999] Elliot Koffman and Ursula Wolz. Problem Solving with Java. Addison Wesley, (1999).



[Paton] Prof. N. Paton. Object Relational Databases. University of Manchester



[Rahayu et al., 2000] W. Rahayu, E. Chang, T. S. Dillon and D. Taniar.

A

methodology for transforming inheritance relationships in an object-oriented A. M. Maatuk

105

References

conceptual model to relational tables. Information and Software Technology. Vol. 42, issue 8, pp. 571-592, 15 May (2000). 

[Silva et al., 2000] S. D. Silva, A. H. F. Laender and M. A. Casanova. On the Relational Representation of Complex Specialization Structures. Information Systems. Vol. 25, issues 6-7, pp. 399-415, September-November (2000).



[Stoimenov et al., 1999] L. Stoimenov, A. Mitrovic, S. Djordjevic-Kajan and D. Mitrovic. Bridging objects and relations: a mediator for an OO front-end to RDBMSs. Information and Software Technology. Vol. 41, issue 2, pp. 57-66, January (1999).



[White et al., 1999] White, Fisher and Cattel. JDBC API Tutorial and Reference, (second edition.). Sun Microsystems, U. S. A, (1999).

A. M. Maatuk

106