PROCEEDINGS OF WORLD ACADEMY OF SCIENCE, ENGINEERING AND TECHNOLOGY VOLUME 6 JUNE 2005 ISSN 1307-6884

New Approach for the Modeling and the

Implementation of the Object-Relational
Databases
Amel Grissa-Touzi, and Minyar Sassi

remain limited to some concepts always. Indeed, these tools

Abstract—Conception is the primordial part in the realization of leave always is the E/A diagram in the case of PowerAMC,
a computer system. Several tools have been used to help inventors to Designer, either of the class diagram in the case of Rational
describe their software. These tools knew a big success in the Rose for modeling the object-relational databases or object-
relational databases domain since they permit to generate SQL script
oriented databases.
modeling the database from an Entity/Association model. However,
with the evolution of the computer domain, the relational databases In 2000, SOUTOU introduced in [7] a model called
proved their limits and object-relational model became used more navigational model that permits of modeling all new object-
and more. Tools of present conception don't support all new concepts relational database concepts and more precisely the new
introduced by this model and the syntax of the SQL3 language. We concepts introduced with the SQL3 language. SOUTOU has
propose in this paper a tool of help to the conception and specify in [1] rules of passage of this model toward the UML
implementation of object-relational databases called «NAVIG-
class diagram and toward the language SQL3. He showed the
TOOLS" that allows the user to generate script modeling its database
in SQL3 language. This tool bases itself on the Entity/Association possible choice number that can have an object-relational
and navigational model for modeling the object-relational databases. database inventor to pass navigational model toward the
implementation of the basis with SQL3 in addition. This
Keywords—Abstract Data Table, Navigational model, Object- model will be primordial in the conception of the object-
relational databases, References. relational databases.
We present in this paper a tool of conception and modeling
I. INTRODUCTION of object-relational databases, based on the navigational

A T the end years 90, a new generation of databases

management systems called object relational was born. It
intends to remedy the weak points of the present systems and
model, called NAVIG_TOOLS. This tool gives to the inventor
the possibility to draw the E/A model, to help him to define
his navigational model of his object-relational database and to
to permit a power of modeling importing (semantically rich) deduct the corresponding script of it in language SQL3, while
and offer all other functionalities of database management using rules of passage proposed by SOUTOU [7]. We have
system. This system is based on the extended relational model tried to adopt the same interfacings of PowerAMC, so that
to the main concepts of object-oriented model (extensibility of users who familiarize already find again quickly.
the set of type, complex structures, object identity, inheritance The remainder of paper is organized in six sections. Section
and methods) [1]-[2]-[3]. II presents object-relational databases technologies. Section
Currently, all big constructors of databases management III presents conception of object-relational databases. Section
systems are conscious of limits of the relational model and IV describes the navigational model. Section V is devoted to
propose systems of this type. They even participated in the the description of our tool called NAVIG-TOOLS. The
development of the norm of the new version of SQL, SQL3. balance of this work and its future perspectives are discussed
As example of databases management systems, we can in Section VI.
mention Informix, Postgres, oracle [1]-[2].
Several computer solutions have been proposed trying of II. OBJECT-RELATIONAL TECHNOLOGIES
enrich their tools to can modelize the object-oriented concept The object-relational technology was born in 1992, it is
as the inheritance, classes etc. Among these tools, we illustrate therefore new enough on the market of database management
the Win'Design[4], PowerAMC[4], Rational Rose[4]-[5], systems. Currently, all big publishers of database management
Designer [4]and JDevelopper [4]-[6] etc. But these tools systems are conscious of limits of the relational model. They
saw therefore in the object-relational model a manner to
enrich this model. Informix was the first publisher of
Manuscript received Mai 20, 2005. management systems to raise the challenge of the object-
A Grissa-Touzi M. Sassi, with the Department of Electrical Engineering of
National School of Engineers of Tunis, Tunisia (e-mail: amel.touzi@
relational as purchasing the business illustrated, that
enit.rnu.tn, sassi_minyar@yahoo.fr). developed a commercial version of the Postgres system, an

© 2005 WASET.ORG
PWASET VOLUME 6 JUNE 2005 ISSN 1307-6884 263
 PROCEEDINGS OF WORLD ACADEMY OF SCIENCE, ENGINEERING AND TECHNOLOGY VOLUME 6 JUNE 2005 ISSN 1307-6884

extended relational management system. Others big publishers III. OBJECT-REALATIONAL DATABASES CONCEPTION
of management systems, as IBM and Oracle, followed this Methods of classic conception of relational databases
evolution [1]-[2]-[7]-[8]. recommend to pass from E/A model (conceptual level) to a
A. Object-relational model principle normalized relational model (logical level), then to link on an
The object-relational model is founded on the idea of optimized relational model (internal level). Views are finally
extension of the relational model with object concepts. declared (external level) according to prerogatives of users of
the data base. For the classic relational model, the passage
User types and
between every level makes them while respecting of precise
encapsulation
rules.
Conception process of an object-relational database,
Reference Inheritance described in Fig.2 inspires itself of the process of conception
And reuse and identity of a relational database [7].
Real World
Collection and
complex object

Fig.1 Relational model extension

An object-relational database is an extension of a relational Conceptual

database. It unites the key concepts of the object to facilitate level
Merise, EA, UML, OMT, etc
the integration of the two models. An object-relational SGBD
is a relational SGBD which will be added object
functionalities as the object identity, the encapsulation, the Navigational
inheritance of types and the support of complex objects. This level

is illustrated in Fig.1.
B. Essential Additional Concepts Internal
level
We present in this section, additional concepts of object-
relational databases: Fig.2 Modeling process
- User data types: user definite data type composed of a data Process must follow the three steps:
structure and operations encapsulates this structure. - The modeling of the real world according to a semantic
The types system of the database management database E/A or UML formalism (conceptual level).
becomes expandable and is not limited to the alphanumeric - The transposition of the conceptual diagram in a
types of basis anymore. In this context, user must define its navigational model (logical level).
types and to adapt those to the management of information. It - The transposition of the navigational diagram in types and
becomes possible to define the picture types, point, vector, in object-relational tables of the object-relational databases
etc. They are called Abstract Data Types (ADT). management systems (internal level).
- Collection templates: generic data type permitting to support
attributes multi-valuated and to organize them according to a
Until now, it doesn't exist software allowing the inventor to
collection type.
draw his E/A model or UML or navigational. Otherwise the
Bosses of lists permit to define some new types on the basis of
generation of the corresponding script in SQL3 language.
other type collections. They can use the different types of
collections of the object-relational model, as table, list, set and
dynamic tables. IV. NAVIGATIONAL MODEL
- Reference of object: Particular data type permitting to
A. Presentation of the Navigational Model
memorize the invariant address of an object or a tuple.
References are identifiers of object (OID) of the object- Navigational term is used because this model includes
relational model. They represent the unique and invariant drawers who facilitate the navigation between objects of the
values permitting of chaining objects between them without database. This model also proposes some notions as the types
passing by joints by values [6]-[7]-[8]-[9]. of wholes, structures and references. The navigational model
- Inheritance of type: Shape of inheritance implying the plays a pivot role between the conceptual model and the
possibility to define an under-type of an existing type, this one physical model. It facilitates the passage of an object
inheriting the structure and the possible operations of the basis conceptual model to a model of object-relational database and
type. limits the risks of incoherence. Indeed, object approaches
- Inheritance of table: Shape of inheritance implying the permits to represent the complex data directly without
possibility to define an under-table from existing tables, this necessary to normalize this information, but it is impossible to
one inheriting the structure and the possible operations of the eliminate the problems caused by the non normalized objects.
basis table.

© 2005 WASET.ORG
PWASET VOLUME 6 JUNE 2005 ISSN 1307-6884 264
 PROCEEDINGS OF WORLD ACADEMY OF SCIENCE, ENGINEERING AND TECHNOLOGY VOLUME 6 JUNE 2005 ISSN 1307-6884

The normalization is not a specific concept to the relational The passage to the navigational model presented in Fig.4.
systems, it is susceptible to concern all the structures of data.
The navigational model can be considered like a theoretical C_Département
support facilitating the passage of a conceptual model to an C_Employé
No
object-relational database model while limiting the risks of NAS
Nas_Resp Nom
incoherence. Nom
The abstract data types don't appear explicitly to the
conceptual level. They are contained implicitly in the Adresse
T-adr
declaration of the entities (E/A) or of the classes (UML).
Those types are clarified more in the navigational model. Rue
Dépendants
CP
B. Formalism of navigational diagram Ville
The formalism of navigational diagram is very near to the
formalism of Object Database Management Group (ODMG), T-dep
to which has been added the notions of identifying, of
Prenom
structure and intra-classes ties. The navigational model Sexe
formalism permits to represent the static and dynamic aspects
of classes.
-Definitions: Classes contains some attributes (properties) Fig.4 Navigational model
and signatures of methods (functions or procedures).
As the shows the diagram, we can modelize comfortably
Attributes can be simples (string, number,…), struct,
the composed attributes, multi-valuated attributes and
references (drawers), set (collection of structures or
drawers.
references) or of the previous type combinations.
The ties can exist inside a same classes (intra-class) or
V. NAVIG-TOOLS
between two classes (inter-class).
-Choice of the graphic representation of the ties: in a In order to help understanding the stratification concept, we
navigational diagram, mono-valuated ties are represented by have built the tool NAVIG-TOOLS. This tool is plate-form
arrows and multi-valuated ties by arrows with duplicate tip. independent since it is developed with java. We chose
Example: Oracle9i like database management system.
The database organization has for goal to manage
employees, departments of an enterprise. NAVIG-TOOLS offer a convivial interface to the inventors of
An employee is described by identified Nas, a Name, an the object-relational databases that allow him:
Adresse composed by Rue, Cp and City and a dependant -Modeling its conceptual Model in E/A and/or navigational
described by last name and Sex. A department is described by model;
-Genering the corresponding SQL3 script;
identified number and name. A department is always managed
For every ambiguous steps, NAVIG-TOOLS propose to the
by only one employee.
inventor several solutions. Indeed, it is due to the fact that to
The E/A model of this database (presented in Fig.3)
represent a tie one can have several solutions [7].
contains two classes: the Employee class described by a In our first version of the software we limited ourselves to the
simple attributes Nas and name, a composed attribute adresse types offered by the version oracel 9i, as:
formed of three fields (Rue, CP, Ville) and a composed multi- -Scalar Type (Number, Varchar, Date,..)
valuated attribute described by (Prenom and Sex). The class -Object Type
Department described by simple attributes No, Nom and -Object Reference REF
Responsable. -Collections (VARRAY and NESTED TABLE)
Rue CP Ville
NAVIG-TOOLS present to the expert a main screen (Fig.5)
similar to the standard usually used in the IDE (Integrated
NAS Nom Adresse
Development Environment) and very similar to Power AMC
No Nom
but to which one added new functionalities modeling the new
0,1 1,1
symbols introduced by the navigational model and the new
concepts introduced by the object-relational databases
Employe dirige Departement
concepts and the SQL3 language.

Dependant

Prenom Sex

Fig.3 E/A model

© 2005 WASET.ORG
PWASET VOLUME 6 JUNE 2005 ISSN 1307-6884 265
 PROCEEDINGS OF WORLD ACADEMY OF SCIENCE, ENGINEERING AND TECHNOLOGY VOLUME 6 JUNE 2005 ISSN 1307-6884

Multi-
Class valuated tie

Inheritance

Fig.5 NAVIG-TOOLS Interface Fig.8 Generation of SQL3 Script

For implanting his database, the inventor must follow the two VI. CONCLUSION
following steps:
1) Conception of database In the next decade, the object-relational databases
The inventor can follow one of the three following management systems will very certainly constitute one of the
methods: biggest technological progresses in databases domain. Mainly
- To draw the E/A model of his database as the shows the because they are construct on the bases of the relational
Fig.3. NAVIG-TOOLS can deduct the navigational model technologies that gave its proofs since more of twenty years.
(Fig. 6). If the user is not satisfied, he can modify this It is for this reason, which we see that it is very important to
model. think from now on one efficient tool for helping about the
conception of object-reltional databases. As several of them
exist for the relational databases and supporting the
navigational model proposed by SOUTOU that showed its
proofs. We proposed in this paper a tool of conception, called
NAVIG-TOOLS that bring two main contributions to the
conception and the implementation of the object-relational
databases. The first improvement is that it offers to the user
the possibility to draw the E/A and/or navigational models.
The second is that it generated SQL3 script.
This work can be spread while proposing to test NAVIG-
Fig.6 E/A Model TOOLS on big database and to perfect our tools so that it can
- To draw directly the navigational model of its object- support the other types offered by the object-relational
relational database (Fig.7). concepts.
2) Generation of SQL3 script
The inventor chosen the database management system REFERENCES
menu, the button to generate the SQL3 script will be [1] P. Daehne, and P. Leutert, “Object and relational models”, High School
generated automatically by NAVIG-TOOLS (Fig.8). specialized of Switzerland Occidental, November 2001.
[2] A. Gamache, “Book on the databases ", Department of data processing
and software genius, University Laval.
[3] E. Meylan, “Theoretical introduction to the object-relational model”,
High School specialized of Switzerland Occidental, June 2001.
[4] C. SOUTOU, “Of UML in SQL“ , Eyrolles,2002.
[5] T. Quatrani, “Modélisation sur Rational Rose”, Eyrolles, 2000.
[6] G. Godin, “Database management systems by example”, Montréal,
Canada, 2003.
[7] C. SOUTOU,“Object - relational under Oracle 8. Modelling with UML
“ Eyrolles, 1999.
[8] R.G.G. Catell., “Object-Oriented Data Management: Object-Oriented
and Extended Relational Database Sytems”, Addison-Wesley
Publishing, Inc., 1994.
[9] M. Makowski, “A structured modeling technology”, European Journal of
Fig.7 Navigational Model Operational Research, Vol. 166, Issue 3, 1 November 2005.

© 2005 WASET.ORG
PWASET VOLUME 6 JUNE 2005 ISSN 1307-6884 266