The Rdb To The Ordb English Language Essay

Published:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

This paper is an approach for migrating the relational databases to the object-relational databases. This approach is more advanced than other approaches because it provides algorithms with the passage of a RDB to an ORDB with the capture of aggregation, association and inheritance.

Abstract

This document deals with the passage of RDB to ORDB seen the benefits that offers the ORDB, the transition is done with methods that can extract the various functions from a RDB which is based on aggregations, associations between the various tables and the reflexive relationships. These methods can extract even the inheritance knowing that no process of reverse engineering cannot know that it is an Inheritance, so my approach exceeded all of the studies already made for ​​the transition from RDB to ORDB. To sum up in three steps, the creation of NDM that stocks the RDB in a form of a structured table, from the NDM we create our   navigational model   to simplify the implementation object from which we develop our different types, through these types we proceed for the last step, the creation of tables.

The step mentioned above does not require any human interference. All this is done in an automatic way, and a prototype has already been created which proves the effectiveness of this approach.

Introduction

Many problems have emerged with the DBR, I quote from them the reconstruction of complex objects split across relational tables is costly because it causes many joins. For this a solution has appeared, it's the BDOR who has addressed most of these problems, I quote from them the use of reference facilitates the use of very large multimedia data by allowing them simply sharing and lesser cost.

But the question that arises is how to achieve a migration from RDB to an ORDB

Several approaches have addressed the topic of migration, among them the approach of Eric Pardede, J. Wenny Rahayu and David Taniar [1], which shows the transformation of the aggregation and associations from the conceptual model to the object relational based on the notion of collections of the UML. Other approach that is based on the creation of a ORDB from the UML [4].

The approach of Maatuk Abdelsalam, M. Akhtar Ali, Nick Rossiter[2][5][6][7][8], which takes all of the relational database and store it in a structured table that holds several parameters, tables, attributes, classification, class type (abstract / concrete), the name of the relationship, class that interacts with the relationship and cardinalities to realize the schema Translation.

But all approaches require the interference of the human factor in order to achieve migration, on all the work, or on one or several parts.

That is why in this paper we propose a method that requires no human interference.

While our approach is based on capturing metadata from a BDR, treat and store it as a structured table that holds the information necessary for the migration.

This paper deals with the steps of the migration that are composed of 3 parts, the first part is the implementation of the structured table<<NDM>> in Section 2, the second part of the conversion from the NDM to the navigational model[3] in Section 3, and the third part deals with the transformation of MNav to DBOR.

New Data Model

definition

The NEW DATA MODEL is a sort of table describes the different classes extracted from a RDB with the data necessary for the realization of an ORDB.

Identification of the NDM

The NDM is defined as a collection of classes NDM: = {C | C: = (cn, degree, cls, a, contributor)}

Cn =the name of the class.

Degree = first degree | 2nd degree.

Cls=aggregation, association, inheritance, simple class.

contributor=class list.

A=attribute:={a|a := (an,t, tag, l, n, d)}

An =name of the attribute

T=type of the attribute

Tag=key (primary | secondary)

L= length of the attribute

N=if the attribute takes the parameter null

D=the default value of the attribute

*observation: treating cardinalities can't help us since the transformation of CDM (conceptual data model) to the LDM (logical data model) in RDB has already treated for the migration of attributes.

Degree

-Each table in the RDB has a degree.

-The degree consists of two parts:

+1st degree: the tables that contain PK.

+2nd degree: the tables that contain FK without PK.

Classification (cls)

For classification, classes are composed of four parts

The simple classes: these are the classes of the first degree and which are not within the classification of aggregation, inheritance and association.

Aggregation: is when the class interact with a single class (the class itself may be the (first degree | 2nd degree)), not included in the classification and inheritance as the class has a FK.

Associations: a class of 2nd degree which interacts with two or more classes.

Special case: for reflexive relationships including their cardinalities in the CDM were « 1-n» «0-n » become an association with two FK with the name of the attribute of FK not found in any other table in the RDB, which includes a special treatment of the entities to know the referencing.

Inheritance: When a class inherits from another class (no reverse approach can identify the inheritance)

For this we developed a technique that is based on creating a table that will contain a maximum of possible probability of inheritance in accordance with the naming standards, so our table will consist of two columns, first column contains the mother class and the second column, the subclasses;

And we compare the list of Pk from the NDM and check if there is a match between two or more keys. If there is a correspondence, we will compare the name of the first class degree to the first column of our created table .If we find a match we will compare the classes involved in our class with the elements of the second column in the same row of the table .So if there is a match we will extract an Inheritance, if not we will continue our treatment of classification knowing that the treatment of inheritance is the first step of the classification.

example:

inherited by

inherits

Person

Student

teacher

Animal

Cat

Dog

Horse

Document

Book

newspaper

Account

Savings

Current

...

Table 1: this table represents the case of inheritance the most common

contributor

This is the list of classes that the class starts interacting with them.

The purpose of this part knows whether it is an aggregation, an association, a single class or a class that inherits from the class starting, also for the creation of reference during the transition to the ORDB

Generation of the NDM from a RDB

The translation of the RDB to the NDM is the first step of the migration into the ORDB

Example

Considering the RDB include:F:\CED(or)\BDR_img - Copie.png

The PKs are in bold underline ex

The FKs are underline ex

The NDM generated from a BDR

Cn

Degré

classification

attribut

intervenant

An

type

tag

l

N

d

Person

1er

inherBy

Pno

Varchar

PK

N

kids

Dept

Works_on

Trainee

Employ

Person

Pname

Varchar

N

Bdate

Date

N

Adress

Varchar

255

N

Dno

Int

FK

N

Dept

PnoSup

Varchar

FK

Y

Person

Trainee

2eme

Inherts

Pno

Varchar

FK

N

Person

Level

Varchar

N

Type

Varchar

N

Employ

2eme

Inherts

Pno

Varchar

FK

N

Person

Salary

Int

Y

Grade

Varchar

FK

N

Works_on

2eme

association

Prno

Int

FK

N

Proj

Pno

Varchar

FK

N

Person

Dept

1er

simple

Dno

Int

PK

N

Person

Dname

Varchar

N

Proj

1er

simple

Prno

Int

PK

N

Work_on

Prname

Varchar

N

Description

Varchar

255

Y

Kids

1er

aggregation

Kno

Int

PK

N

Kname

Varchar

N

Sex

Char

N

Pno

Varchar

FK

n

Person

Result of the generation of the NDM.

Observation: VARCHAR is synonymous with VARCHAR2 but this usage may change in future versions (provided for backward compatibility only for Oracle datatypes).

MNAV(model navigational)

After obtaining the CDM, we create the navigational model.

Definition

a model that schematizes the object implementation of a database while drawing up the navigation path between relations with the principle of referencing.

Objectives

_ facilitating the transition towards the object by a set of rules for transposition.

_ Promoting visualization of complex structures and navigation paths possible.

Why navigational?

_ the model introduces the logical links of the type REF (REF implementation is undetermined in the conceptual level ) .

_the references (ref or REF) facilitate the navigation between objects.

Our classes will be divided into two parts, the external classes and internal classes:

+ Internal classes are the classes classified as aggregation in the NDM.

+ External classes are the other classifications in the NDM.

Example:

Extern

Attr1

Attr2

Attr3

Attr4

Intern

Attr6

Attr7

Example MNAV from passing UML:

Job

noA

nomA

0..1

emploie

0..n

Employ

noE

nomE

métier

UML

job

noA

nomA

lesEmploye

Employ

noE

nomE

metierE

MNAV

Note: The association is made ​​by an external link that uses a reference to one or many objects of the class employ.

Navigation symbol:

Simple

Multiple

Lien simple link

Single link can be null

single link Necessarily valued

The absence of the circle means necessarily valued

Multiple link

multiple link can be null

multiple link Necessarily valued

The absence of the circle means necessarily valued

Transformation rules

Inheritance:

It follows the same principle of the class diagram in UML, either for  the parent class or subclass.

Association :

The navigation link is simple and necessarily valued keeping attributes if it's an association with the class attributes.

The navigation links pointing from the class association to the class that interacts with it (universal solution).

Class 1

Attr1

Attr2

Association

Ref1

Ref2

Class 2

Attr3

Attr4

There is another type of representation:

+ No preference of course, two multiple links with two new attributes of type Ref.

Class 1

Attr1

Attr2

Class 2

Attr3

Attr4

Danger of incoherence, the forget of update when deleting

+ Two links are multiple and two single.

Class 1

Attr1

Attr2

Ref3

Association

Ref1

Ref2

Class 2

Attr3

Attr4

Ref4

Aggregation:

It becomes an internal class type object referenced by an attribute of assembly with a multiple link can be null.

Simple class:

For the simple class we must see the classification of the class that interacts with it.

+ If it is an association we will not need to trace the path of navigation because it is already done.

+ when a simple class interacts with another simple class, we have two navigation links, the first starts of the class that contains a foreign key   which is a primary key in the other class, the link is simple and necessarily valued.

The second link starts from the other class, which is multiple and can be null.

NDM transformed into MNAV.

Person

Pno

Pname

Bdate

Adress

laDept

lesKids

Kids

Kno

Kname

Sexe

Works_on

lesPerson

lesProj

Proj

Prno

Prname

Description

Employ

Pno

Salary

Grade

Trainee

Pno

Level

Type

Dept

Dno

Dname

lesEmps

Translation of the NDM to ORDB

approach for the translation of the NDM into ORDB

the creation of types

+ Creation of the types defined in the NDM as aggregation.

+ Creation of the types defined in the NDM as association.

For the creation of the types we keep the same name listed in the RDB and we add _type (concatenation)

+ Creation of composite types (classes entering in collaboration with the aggregation taking into account their classification) and other types which their classification in the NDM is simple.

+ The creation of the types defined in the NDM as an inheritance starting with the parent class and ending with the subclasses.

creating tables

The creation of tables is made by the typed classes, named in the NDM as inheritance (parent, subclasses), association, simple class and aggregations, they are included in the class of first degree that interacts within, all tables are created with the necessary constraints.

method of creating and naming rule

To create the types we keep the same name that appears in the RDB and we add _type (concatenation)

Syntax

CREATE [OR REPLACE] TYPE nameBDR_Type AS OBJECT

(colonne1 type1, colonne2 type2,...)

To create types that contain other types that represent aggregations, the type name that represents the aggregation remains the same and we added _t

Syntax

CREATE [OR REPLACE] TYPE nameRDB1_Type AS OBJECT

(column1 type1, column2 type2,...)

/

CREATE [OR REPLACE] TYPE nameRDB2_Type AS OBJECT

(column1 type1, column2 type2,nameRDB1_t set( nameRDB1_type),...)

For the creation of types with references, we add a ref_ next to the name of the RDB with the keyword REF and the referenced type.

Observation: for reflexive relationships   near many recordings [1-n] we concatenate the PK with the FK, and the side of a single record [1-1] we concatenate the FK with the PK.

Syntax

CREATE [OR REPLACE] TYPE nameRDB1_Type AS OBJECT

(column1 type1, column2 type2,...)

/

CREATE [OR REPLACE] TYPE nameRDB2_Type AS OBJECT

(column1 type1, column2 type2,nameRDB1_t nameRDB1_type,...)

/

CREATE [OR REPLACE] TYPE nameRDB3_Type AS OBJECT

(column1 type1, column2 type2,ref_nameRDB2 REF nameRDB2_type,...)

For the creation of types that represent the inheritance, we add   Under for the sub class and the keyword not final    if the type has subtypes, and final if the type has no subtypes.

Syntax

CREATE [OR REPLACE] TYPE nameRDB1_Type AS OBJECT

(column1 type1, column2 type2,...)

NOT FINAL

/

CREATE [OR REPLACE] TYPE nameRDB2_Type under nameRDB_type

(column1 type1, column2 type2,nameRDB1_t nameRDB1_type,...)

FINAL

Creating tables   starts from   typed classes, the table keeps the same name that appears in the RDB, we add the keyword OF and the type corresponding with the constraints captured in the NDM (PK constraint, reference constraint, not null constraint ...).

Syntax:

CREATE TABLE [schema.]nameTable OF [schema.] nameType

[(column [DEFAULT expression]

[ constraintOnLine [constraintOnLine]...

| constraintREFOnLine ]

| { constraintOffline | constraintREFOffline }

[,column...] )]

;

final result of the migration

CREATE TYPE kids_type AS OBJECT

(kno int, kname varchar(20),sex char(1),pno varchar(20))

/

CREATE TYPE dept_type AS OBJECT

(dno int, dname varchar(20))

/

CREATE TYPE proj_type AS OBJECT

(prno int, prname varchar(20),description varchar(255))

/

CREATE TYPE person_type AS OBJECT

(pno varchar(10),pname varchar(20),bdate date,address varchar(255),dno int , pnosup varchar(20),kids_t set(kids_type),ref_dept ref (dept_type)scope dept,ref_pno_pnosup set(ref(person_type)),ref_pnosup_pno ref(person_type) scope person)

NOT FINAL

/

CREATE TYPE trainee_type UNDER person_type

(pno varchar(10), level varchar(20),type varchar(20))

FINAL

/

CREATE TYPE employe_type UNDER person_type

(pno varchar(10),salary int,grade varchar(20))

FINAL

/

CREATE TYPE work_on_type AS OBJECT

(prno int, pno varchar(20),ref_proj set (ref(proj_type)),ref_person set(ref(person_type)))

/

CREATE TABLE dept OF dept_type(

constraint pk_dept primary key(dno));

CREATE TABLE proj OF proj_type(

constraint pk_proj primary key(prno));

CREATE TABLE work_on OF work_on_type(

constraint refer_work_on_person ref_person references person,

constraint refer_work_on_proj ref_proj references proj);

CREATE TABLE person OF person_type(

constraint pk_person primary key(pno),

constraint refer_person ref_dept references dept);

CREATE TABLE trainee OF trainee_type UNDER person;

CREATE TABLE employe OF employe_type UNDER person;

CONCLUSION

The current work shows us the steps of moving from a RDB to ORDB with a simple and practical method to capture the relationships between different classes, associations, aggregations and even the inheritance that no approach has proposed a solution to extract it from a RDB. So we can trace the navigational model to better see how the navigation is made between classes and respect the navigation links for best listings.

So this solution exceeds the existing works as it generates an ORDB without the interference of the human factor, a prototype was created to prove the effectiveness of this approach.

Writing Services

Essay Writing
Service

Find out how the very best essay writing service can help you accomplish more and achieve higher marks today.

Assignment Writing Service

From complicated assignments to tricky tasks, our experts can tackle virtually any question thrown at them.

Dissertation Writing Service

A dissertation (also known as a thesis or research project) is probably the most important piece of work for any student! From full dissertations to individual chapters, we’re on hand to support you.

Coursework Writing Service

Our expert qualified writers can help you get your coursework right first time, every time.

Dissertation Proposal Service

The first step to completing a dissertation is to create a proposal that talks about what you wish to do. Our experts can design suitable methodologies - perfect to help you get started with a dissertation.

Report Writing
Service

Reports for any audience. Perfectly structured, professionally written, and tailored to suit your exact requirements.

Essay Skeleton Answer Service

If you’re just looking for some help to get started on an essay, our outline service provides you with a perfect essay plan.

Marking & Proofreading Service

Not sure if your work is hitting the mark? Struggling to get feedback from your lecturer? Our premium marking service was created just for you - get the feedback you deserve now.

Exam Revision
Service

Exams can be one of the most stressful experiences you’ll ever have! Revision is key, and we’re here to help. With custom created revision notes and exam answers, you’ll never feel underprepared again.