SETIT 2005

3
rd
International Conference: Sciences of Electronic ,
Technologies of Information and Telecommunications
MARCH 27-31, 2005 TUNISIA


ORM : Un Moteur de Persistance Objet Relationnelle
*Boubker Sbihi*, *Chihab Cherkaoui** Driss mamas*
*
Ecole des sciences de linformation
BP 6204 Agdal, Rabat, Maroc
*

*
Laboratoire CERDIE, Universit IBN ZOHR
Ecole Nationale de Commerce et de Gestion
BP.37/S Hay Essalam, Agadir Maroc
*

Bsbihi@esi.ac.ma
ccherkaoui@yahoo.frauteur

Rsum: Le travail prsent dans ce papier, sinscrit dans le cadre dun projet objet-relationnel qui a pour but la gestion
de la persistance des objets laide des SGBD relationnels ; il vise exploiter lexistant en matire de bases de donnes,
et rduire le cot dintgration de lapproche objet dans les systmes actuels. Il consiste faire correspondre les objets
du modle objet aux tables du modle relationnel en util isant des techniques de reprsentation sous forme relationnelle
des objets. Ensuite, une mise en uvre dune couche logicielle portable sur toutes les plateformes situe au dessus
dune base de donnes relationnelle ralisant cette correspondance automatique a t ralise.
Mots cls: Persistance, Objet-Relationnel, Rutilisation, Portabilit.

1-Introduction
Bas sur lalgbre relationnelle qui est une
approche purement mathmatique, le modle
relationnel, introduit par Codd [Codd 1970], est rput
par sa simplicit. Celle -ci dcoule des concepts fonds
sur la thorie des ensembles. Il offre un langage de
dfinition et de manipulation des donnes normalises
et fournit une base pour traiter les problmes de
cohrence des donnes laide des contraintes
dintgrit et des rgles de gestion.Dautres types de
donnes complexes ou fortement structures ont vu le
jour suite aux nouveaux besoins des utilisateurs. Ces
donnes, n'obissant pas la premire loi normale, se
trouvent donc inadapts au modle relationnel prouvant
par l ses limites ; il sen suit la naissance du modle
objet [Ayache et al 1996].
Lapproche oriente objet a pour but d'accrotre la
productivit des dveloppeurs et de faciliter la
maintenance et la rutilisabilit des logiciels construits
selon ce paradigme. Cependant, les langages objets
souffrent notamment de labsence des supports de
stockage.
Les SGBD orient objets grent la persistance et
rpondent aux besoins des utilisateurs dans un contexte
orient objet, mais la majorit des applications
existantes nutilisent que les tables du modle
relationnel comme support de stockage des donnes,
do lapparition du monde objet-relationnel [Gardarin
2000].
Le dveloppement dans ce nouveau monde objet-
relationnel se fait en objet, et le stockage se fait dans
des tables relationnelles. Il a t conu afin de
combiner les deux modles, objet et relationnel, pour
combler les insuffisances de lun par les atouts de
lautre.
Pour raliser une application, le choix de la
plateforme et celui du serveur de bases de donnes
savrent primordiales. Le programmeur aura le choix
entre J2EE/Oracle, .Net/SQL Server, ASP/Access ou
enfin PHP/MySQL. Notons bien quon peut mixer un
couple partir de ces possibilits. Un tel choix peut
tre surmont par notre solution qui s'oriente vers un
dveloppement dans un langage objet utilisant une base
de donnes relationnelle. Grce aux techniques de
transformation des modles objets en modles
relationnels, les difficults de cohabitation entre les
mondes objets et relationnels seront rsolues.
La figure ci-dessous (Figure 1) montre la mthode
utiliser pour raliser la sauvegarde et la restauration
dun ensemble dobjets dune application partir dune
base de donnes relationnelle.


SETIT2005


Figure 1 : Mthode de transformation objet-relationnelle

Dans ce papier, aprs une introduction (section1),
nous dcrivons la Gestion de la persistance (Section 2).
Ensuite nous prsenterons les techniques de traductions
(Section3). Avant de conclure cet article, une mise en
uvre du moteur objet-relationnel ORM sera illustre
avec le langage JAVA afin de garantir sa portabilit.
2-Gestion de la persistance
Dans ce contexte, deux principales solutions ont t
avances pour grer la persistance des objets et tendre
le modle re lationnel :
2.1-Gestion de la persistance des objets
Les langages objets ont largement prouv leur
intrt dans les domaines de la reprsentation des
connaissances [Kayser 1997] et en intelligence
artificielle, mais ils ont encore des lacunes tels que le
stockage permanent dobjets et linaptitude partager
des objets entre plusieurs utilisateurs.
Il existe des langages qui grent la persistance des
objets tels que PS-algol [PS-algol 1988], Napier88
[Morrison et al 1996] et Galileo [Albano et al 1995] ;
mais ils ne sont pas considrs comme des langages de
gestion des bases de donnes du fait quils ne prennent
pas en considration la concurrence, la scurit, la
fiabilit et l'intgrit des donnes.
Par ailleurs, il est possible de raliser la persistance
des objets Java l'aide du mcanisme de linarisation
propos par Java sans avoir besoin dun SGBDOO. Un
objet peut tre sauvegard et restaur partir dun
fichier, mais les fichiers peuvent facilement tre
modifis en dehors du programme application, do le
manque de scurit. Le partage de donnes entre
plusieurs applications nest pas possible. Aussi des
objets composites en liens avec dautres objets ne
peuvent pas tre sauvegards en entier. Parmi les
nombreux outils destins grer la persistance des
objets figurent :
- JDO [Roos 2004] qui est une technologie pour
assurer la persistance d'objets Java dans un systme de
gestion de bases de donnes.
- BeanBox. [Ambler2002] se basant sur les JavaBeans
qui sont des composants logiciels permettant la
persistance des objets.
2.2-Extension du modle relationnel
Comme leur nom lindique, les modles de donnes
Objet-Relationnel sont des modles hybrides entre les
deux mondes ; ils cherchent tendre le modle
relationnel par des concepts de la programmation
oriente objets, en particulier un systme de typage
spcifique. Ces nouveauts tentent dapporter des
solutions pour tendre le modle relationnel en
conservant la base relationnelle tout en bnficiant de
la puissance de la modlisation objet Selon Gardarin
[Gardarin 2004], pour tendre le modle relationnel
afin dassurer la gestion des donnes complexes, deux
solutions ont t proposes :
Lune, qui se situe au niveau de la relation
(imbrication de la relation) adopte par Illustra
de Stonebraker et UniSQL de Won Kim,
consiste reconstruire tout, depuis le dpart ;
mais cette solution se heurte au problme du
cot.
Lautre, se situant au niveau des
domaines relationnels tendus, a t retenue
par Oracle8, Microsoft et SQL3; comme la
prcdente, elle pose le problme des cots de
ces SGBD.
De nombreux enrichissements ont t apports au
langage SQL qui ont servi supporter la gestion de
donnes orientes objets do lapparition de SQL3
[Mattos 1996]. Celui-ci est une extension du langage
SQL 92 qui apporte plus de flexibilit en supportant les
types de donnes complexes sur une base de donnes
relationnelle.
Dautres solutions pour rendre les langages orients
objets persistants, dans le cadre relationnel, consistent
utiliser un driver spcifique tel que le midelleware
Object Driver [Object Driver 2004] ou loutil Castor
bas sur les beans [Castor 2002] ; mais le problme
dans ces cas rside dans lcriture des fichiers de
correspondance pour chaque application.
Le JDBC (Java Database Connectivity) 2.0 (qui est
un lment standard de JDK Java Development Kit 1.4,
ou Java 2, se prsente comme une solution mais
ncessite lintervention du dveloppeur pour effectuer
des requtes SQL. Notons que JDBC, dans sa version
2.0, prend en charge des types de donnes SQL3
apportant aux programmeurs de base de donnes une
SETIT2005

souplesse considrable pour stocker des objets Java
srialiss.
Nous proposons dans ce papier, une solution pour
intrt la gestion de la persistance des objets avec
lutilisation dun SGBDR au lieu dun SGBDOO afin
de maintenir lexistant en matire de bases de donnes
et de rduire les cots sans passer par des fichiers de
correspondance. Notre article portera sur la
prsentation des rgles de traductions (structures objets
/ structures relationnelles) dans une premire section et
ensuite le processus de sa mise en uvre, objet de la
section 2.
3-Les techniques de traductions
Notre but est de concrtiser la philosophie de
lObjet-Relationnel en nous attaquant la
reprsentation, sous forme relationnelle, des objets et
leurs liens. Il consiste implmenter un mcanisme
pour transformer les objets simples et composs (dans
le cas de lhritage, agrgation et association) en leur
traduction sous forme de tables relationnelles.
3.1-Les classes
Pour les besoins de notre solution, chaque classe
simple qui comporte des attributs publics ou protgs
atomiques (caractre, entier, rel, chane, etc.) sera
traduite par une table avec les mmes attributs de la
classe. Dans le cas dune classe composite, les attributs
complexes seront reprsents par des tables qui seront
rfrences laide de cls trangres comme le cas
dune association entre deux tables. Tout type
doprations figurant dans les classes ne sera pas pris
en compte et on limine toutes les classes abstraites ou
celles qui n'ont pas d'attributs.
3.2-La cl primaire
Une cl primaire selon Gardarin [Gardarin 2004]
peut tre dfinie comme un ensemble minimum
d'attributs dont la connaissance des valeurs permet
d'identifier un enregistrement unique de la relation
considre. Dans le modle objet, chaque
enregistrement doit tre identifi de faon unique. Pour
traduire cette contrainte, il faut crer une colonne
spciale qui se substituera lidentifiant de lobjet. Ce
nouvel identifiant cr, sera unique pour toutes les
tables. Il devient ds lors possible dajouter
lidentifiant gnr par la table, le nom de la classe de
lobjet.
3.3-L'hritage
L'hritage signifie que l'on peut dvelopper une
nouvelle classe en disant simplement en quoi elle
diffre d'une classe existante. Il permet de regrouper
des attributs et des mthodes au sein d'une classe
gnrique appele super-classe [Soutou 2002]. Le
mcanisme d'hritage est l'un des principaux apports de
la technologie objet. Les systmes orients objets
l'utilisent aussi bien pour raliser des implmentations
qui refltent la ralit que pour favoriser la
rutilisabilit et le polymorphisme. Lhritage peut
ainsi tre utilis pour raliser une classe virtuelle (la
concrtiser), pour spcialiser une classe existante en
ajoutant des nouvelles primitives ; il est utilis aussi
pour adapter une classe sans ajouter de nouvelles
primitives, pour acqurir un comportement dfini dans
une autre classe, ou pour fusionner les diffrentes
primitives provenant de plusieurs classes.
Le problme qui se pose est comment organiser les
attributs de lhritage lintrieur dune base de
donnes relationnelle. La faon dont nous rpondons
cette question peut avoir un grand impact sur le schma
de la base de donnes [Scott et al 2000]. Remarquons
que ORACLE, dans sa version 8.0, ne prend pas en
charge l'hritage [Soutou 2002].
Trois techniques fondamentales sont utilises pour
traduire l'hritage en des tables relationnelles selon
[Dell 1999] et [Scott et al 2000] ; nous pouvons les
rsumer en ce qui suit :
La premire approche consiste utiliser :
Une table pour la classe de base.
Pour chaque classe drive, une autre table ne
contenant que les informations additionnelles
relatives cette classe drive.
Les tables descendantes font rfrence la table de
base l'aide d'une colonne contenant l'OID de la table
de base sous forme dune cl trangre. Cette mthode
a l'inconvnient d'introduire de nombreux joints (pour
obtenir les informations dfinies dans la classe de
base), ce qui peut se traduire par une svre perte
d'efficacit. La gestion des relations entre tables
savre vite trs difficile lorsque le nombre de tables
commence devenir important. La dcomposition en
de nombreuses tables, lies au procd de
normalisation, fait perdre une trs grande partie du
contenu smantique des structures du monde rel que
la base est cense reprsenter.
La deuxime approche consiste utiliser :
Une seule table pour toutes les classes de la
structure d'hritage.
Le schma de la relation qui peut tre
subdivis en des sous schmas :
- Les attributs du premier sous schma reprsentent
la classe de base
- Les sous schmas suivants sont ddis aux
informations additionnelles apportes par chaque classe
drive.
Cette approche a l'inconvnient d'utiliser l'espace de
faon peu efficace. La structure de la table se trouve
modifie chaque adjonction dune classe drive.
La dernire approche, que nous avons adopte dans
notre solution, consiste :
Utiliser une table unique pour chaque classe.
On considre que cette table contient toute
l'information relative la classe. On supprime donc la
structure d'hritage au niveau de la base de donnes.
L'utilisation des jointures n'est plus ncessaire. C'est
une approche qui a montr son efficacit lors de la mise
en uvre.
SETIT2005

3.4-Lagrgation et lassociation
Pour traduire lagrgation en des tables
relationnelles, on fait appel aux recherches dans ce
domaine ; afin de choisir une technique performante et
plus adapte pour notre solution, nous les prsentons
dune manire rsume comme suit :
La premire approche [Rumbaugh 1999] consiste
considrer lagrgation comme une simple
association.
La deuxime approche [Blaha and al 1988] consiste

diviser lagrgation en deux types selon le
contexte qui se prsente :
- lune traite lagrgation comme une association N
- N o on cre une nouvelle table pour stocker la
relation dagrgation.
- lautre est similaire au cas du type de lassociation
1-N o la cl de la classe compose devient une cl
trangre dans la sous-classe composante.
La troisime approche [Kroenke 1995] consiste
retenir les notions dobjets composs et
dobjets composites :
- Un objet compos contient une ou plusieurs
instances dautres objets.
- Chaque objet destin entrer en association avec
un autre doit tre class parmi les objets Composs.
La transformation dobjets composs sous forme de
tables relationnelles est divise en trois catgories :1-1,
1-N, N-N.
- Un objet composite est un objet qui a des attributs
simples ou structurs multivalus qui sont eux mmes
des objets.
Afin de reprsenter cette relation, une table est
cre pour lobjet racine et une autre pour lattribut
structur dont la cl primaire est compose de celle de
lobjet de base et celle de la deuxime table.
La quatrime approche [Ambler et al 2002] consiste :
Traiter lagrgation et lassociation sans distinction
relle dans le processus de transformation traitant :
- Le cas o un objet fait partie dun autre.
- Le cas o un ensemble dobjets compose un objet.
Pour la transformation en tables relationnelles,
procder comme pour les groupes prcdents en faisant
des migrations des cls, de table en table.
Pour notre solution, la mthode adopte sinspire
des groupes prcdents en faisant des migrations des
cls de table en table sans distinction entre tout type
dassociations et agrgation. Dans le cas dune
association N-N, au lieu de crer une nouvelle table qui
complique le schma relationnel (surtout dans le cas de
plusieurs associations) pour maintenir le lien, on migre
la cl primaire de la premire table vers la deuxime en
introduisant des valeurs nulles et en crant des lignes
redondantes.
4-La mise en uvre
Notre solution Objet-Relationnel a pour but
dassurer une correspondance, au cas o elle existe,
entre le monde objet et le monde relationnel. Il possde
des fonctions assurant le stockage et la restauration
dobjets au moment de lexcution dune application
Java en des tables relationnelles cres par Microsoft
Access.
Pour stocker les objets dune application Java, notre
application traduit le modle objet par un schma
relationnel figurant dans le SGBDR Access
correspondant afin dassurer une restauration
transparente. La solution propose agit sur les attributs
publics et protgs des classes publiques. Quant aux
attributs privs, ils sont inaccessibles par ce dernier du
fait quil utilise des fonctions du JDBC lesquelles ne
prennent pas ces attributs en considration.
La correspondance gnre automatiquement lors
de lexcution ncessite lutilisation dun ensemble de
concepts et de mthodes concernant les paradigmes
objet qui seront prsents pratiquement ci-aprs.
4.1-Les fonctionnalits de notre solution
La solution propose possde un ensemble de
fonctions dune couche relationnelle qui permettra de
stocker et restaurer les objets Java lors de lexcution
dune manire automatique dans les tables
relationnelles correspondantes gnres.
La couche relationnelle a pour objectif de raliser
les taches suivantes :
Cration des tables de base.
Affectation des OID globaux ajouts aux tables de
base.
Affectation des valeurs de cls trangres aux tables
en
association pour permettre la reconstitution des objets.
Mise jour des valeurs des objets dans les tables.
Suppression des objets dans les tables.
Restauration dobjets.
Comme dans des travaux prcdents [Lee 1994], la
base de rcupration des valeurs des objets dans notre
application se fait partir des requtes SQL.
4.2-Cration des tables de base et affectation des
valeurs dobjets
La cration de la table de base pour chaque objet de
lutilisateur est ralise en utilisant la mthode
getName() ; celle-ci retourne le nom de la classe de
lobjet donnant lieu la constitution dune requte
SQL. La cration de tables utilise les noms et les types
des attributs visibles (Publics et protgs) de lobjet en
question qui seront obtenus par le biais des mthodes
getFields().getName() et getFields().getType().
Lexcution de cette requte se fait dans le
programme application appelant la mthode de
connexion une base de donnes ayant comme
paramtres le chemin de la base et son mot de passe qui
prend la valeur nulle dans le cas o il nexiste pas.
SETIT2005

Au moment de linsertion des objets simples dans la
table de base ralise lors de linstanciation, les
attributs visibles et les OID globaux sont ajouts la
table de base .Les OID ont pour but dassurer les liens
et didentifier, dune manire unique, chaque ligne des
tables relationnelles. On utilis era la mthode
Stocker de notre application qui a comme paramtre
un objet simple et qui retourne lOID de la ligne
dinsertion :

Classe1 o1=new Classe1() ;//Aucune association ou autre avec autre classe
NoyauOR N= new NoyauOR () // le noyau des fonctions de notre solution
//connection(String path,String motdepass)
N.connection(c:/ Mes Documents/ BDR, BDR ) ;String
S=N.Stocker(o1) ;
//simple
Figure 2 : Stockage Simple dun objet

4.3-Affectation des valeurs de cls trangres aux
tables en relation
Pour les objets composs, on procde linsertion
des cls trangres entre les diffrentes tables de base
pour maintenir les liens. Tout ce traitement est assur
par les fonctions de notre application : on suppose que
la classe1 a une seule relation dassociation avec la
classe2; dans ce cas, les objets de la classe2 doivent
tre insrs avant chaque objet de la classe1 afin de
maintenir le lien association.

Classe1 o2=new Classe1() ;
Classe1 o1=new Classe1() ;
NoyauOR N= new NoyauOR () // le noyau des fonctions de notre solution
//connection(String path,String pass)
N.connection(c:/ Mes Documents, BDR ) ;
String S=N.Stocke(o2) ;//simple
String S1=N.StockerASS1(o1,S)
Figure 3 : Stockage dobjets avec associations

Notons que notre solution comporte des fonctions
qui permettent de stocker un objet compos (en
agrgation avec dautres objets) en possdant plus
dune association.
4.4-Suppression et mise jour des valeurs dobjets
dans les tables
Pour supprimer un objet simple, il suffit de donner
son OID de la faon suivante :

Classe o=new Classe() ;
NoyauOR N= new NoyauOR () // le noyau des fonctions de notre solution
Int position=10 ;
Int a=N.Supprimer(o,position) ;
Figure 4 : Suppression dun objet simple

Si a =0, il na rien supprim
Si a <>0, il la supprim avec succs
Pour supprimer un objet composite, il faut
supprimer toutes les occurrences de ce dernier dans les
tables associes. On fait alors une rcupration des
champs en relation :
On suppose que lobjet o possde 2
associations avec les objets o3 et o4 des Class3 et
Classe4:
SETIT2005


Int position=4 ;
Classe3 o3=new Classe3() ;//instanciation de lobjet o3
Classe4 o4=new Classe4() ; //instanciation de lobjet o4
String s1= N.OID_Assocition1(o,position) ;//donner lOID de lassociation 1
String s2= N.OID_Assocition2(o,position) ; //donner lOID de lassociation 2
Int position 1= N.Recherche_OID(o3, s1) ; //donner lOID de lassociation 1
Int position 2= N.Recherche_OID(o4, s2) ; //donner lOID de lassociation 2
Int a3=N.Supprimer(o3,position1) ;
//supprimer la partie de lobjet o avec lassociation 1
Int a4=N.Supprimer(o4,position2) ;
//supprimer la partie de lobjet o avec lassociation 2
Int a=N.Supprimer(o,position) ;
//supprimer le reste de lobjet o
Figure 5 : Suppression dun objet composite

Si a3et a4 et a sont diffrents de 0, lobjet est
supprim.
Pour changer la valeur dun objet simple, il suffit de
donner son OID de la faon suivante :

Classe o=new Classe() ;
String s1= OID ;
Int position = N.Recherche_OID(o, s1) ;
Int Val= N.ChangerATT(o, position, i me Attribut,Nouvelle Valeur) ;
// changer dans la table correspondante lobjet o et la position (position)
le i me attribut avec la nouvelle valeur.

Figure 6 : Mise jour dun objet simple

Si Val=0 aucune modification.
Si Val<>0 un changement avec succs.
Pour changer un objet compos, il suffit de localiser
la valeur changer dans sa table et procder de la
mme faon que la suppression.
4.5-Restauration des objets des tables
Pour restaurer un objet simple, il suffit de donner
son OID de la faon suivante :

Classe1 o1=new Classe1() ;
Classe1 o=new Classe1() ;
Int position =10 ;
O=N.Restorer(o1,position) ;
Figure 7 : Restauration dun objet simple

Pour restaurer un objet composite, il faut restaurer
toutes les occurrences de ce dernier dans les tables
associes.
On suppose que lobjet o possde 2
associations avec la Class3 et Classe4 :

Int position=4 ;
Classe3 o3=new Classe3() ;
Classe4 o4=new Classe4() ;
Classe o=new Classe() ;
String s1= N.OID_Assocition1(o,position) ;
String s2= N.OID_Assocition2(o,position) ;
Int position 1= N.Recherche_OID(o3, s1) ;
Int position 2= N.Recherche_OID(o4, s2) ;
Classe3 a3=N.Restorer(o3,position1) ;
Classe4 a4= N.Restorer (o4,position2) ;
Classe a= N.Restorer (o,position) ;
o=N.Concat(a,a3,a4) ;
// une fonction pour la concatnation des objets a,a3 et a4 dans lobjet o
Figure 8 : Restauration dun objet composite

SETIT2005

Ainsi, notre solution permet de restaurer les objets
simples et composites selon les besoins de lapplication
objet en cours dexcution.
5-Conclusion
Le prsent article a permis de relever les limites des
solutions pour grer la persistance des objets proposes
actuellement dans un premier temps ; ensuite, il a
dcrit les lments de base et de la mise en uvre de
notre propre solution qui se focalise essentiellement sur
des techniques de stockage et de restauration objet-
relationnel.
Ainsi les notions de traduction des diffrents
paradigmes objets dont les classes, lhritage,
lagrgation et lassociation ont t ralises.
Cest grce aux des fonctions transparentes de
stockage et de restauration dobjets simples et
composites au moment de lexcution dune
application quon a pu dgager une bijection entre les
deux modles objet et relationnel, mise en uvre de
notre solution.
Notre objectif moyen terme est daboutir
intgrer des objets multi-points de vue [Sbihi 2004] et
galement dautres langages objets tel que
(C++,VBOOL,..) et dautres SGBDR
(Oracle,Informix,..). Lextension de notre solution va
tre effectue selon cinq axes en :
- Prenant en considration de la gestion des attributs
et classes privs.
- Prenant en considration les objets multi-points de
vue
- Amliorant notre solution dans le but de cibler
plusieurs SGBDR tels que Oracle, etc
- Amliorant des algorithmes de traduction pour le
rendre plus robuste et plus souple.
- Intgrant la relation de visibilit comme un
concept de lien entre objet.
Bibliographie
[Albano and al 1995] : A. Albano, G. Ghelli, and R. Orsini,
A.Fibonacci, "A programming language for object
databases". The VLDB Journal, 4(3):403-439, 1995.
[Ambler and al 2002] : S.Ambler, Ed Roman and
Tyler, Jewell, "Mastering Entreprise Javabeans", End edition,
ISBN 0- 471- 41711- 4, Ed Wiley, 2002.
[Ayache and al 1996] : M.Ayache and A.Flory, "Approche
oriente objet-Concepts et utilisation", 1re dition, ISBN : 2-
7178-3153-3, dition Eyrolles. 1996.
[Blaha and al 1988]: B.Blaha., "Relationnal Database Design
using an Object-Oriented Methodology ", Communication of
the ACM, volume 31, numro 4, 1988.
[Bouzegoub and al 1994] : M Bouzeghoub, G Gardarin and P
Valduriez, " Du C++ Merise objet", Edition Eyrolles, 1994.
[Castor 2002] : Documentation de loutil Castor,
http://portal.spiderlogic.com/modules.php
[Codd 1970] : E Codd, "A Relational Model for large schared
data banks", Communication de lACM, vol 13 N6, juin
1970.
[Dell 1999] :
http://www.montefiore.ulg.ac.be/~delleuze/TFE/rel-
OO3.html.
[Ferber 1990] : J. Ferber, "Conception et Programmation par
Objets", Editions Herms, Paris, 1990.
[Gardarin 2000] : G.Gardarin, "Bases de donnes objet et
relationnel", Eyrolles 2000.
[Gardarin 2004] : http://www.prism.uvsq.fr/~gardarin
[Guid2000 : Guidelines, "Maing an Object Model to a
Relational Data Model ", Relational Unified Process, 2000.
[Kayser 1997] : D.Kayser, "La reprsentation des
connaissances", Edition Hermes. ISBN : 2 86601 647 5,
1997.
[Ketabchi et al 1990] : M.A. Ketabchi, T. Risch, S. Mathur, J.
Chen, "Comparative Analysis of RDBMS and OODBMS : A
Case Study", IEEE conference, 1990
[Kroenke 1995]: A.Kroenke, "Database Processing
Fundamentals, Design, and Implementation", 5me edition ,
Prentice Hall, 1995.
[Lee 1994]: B.Lee., G.Wiederhold, "Efficiently Instantiating
View-Objects From Remote Relationnal Databases", VLB
Journal, Australie, 1994.
[Mapping 2004] : Ressources mapping,
http://www.ressources-java.net/mapping.jsp
[Mattos 1996] : N.Mattos, "An Overview of the SQL3
Standard", presentation foils, Database Technology Institute,
IBM Santa Teresa Lab., San Jose, CA, July 1996
[Matur 1996]:A. Mathur. "A Stochastic Process Model for
Transient Trace Data". PhD thesis, Computer Sciences.
Dept., Virginia Tech, October 1996.
[Morrison et al 1996] : R.Morrison, A.Brown, , R.Connor,
O.Cutts,A.Dearle, G.Kirby, & D.Munro,"Napier88 Reference
Manual (Release 2.2.1)". University of St Andrews, 1996.
[Object driver 2004] : Object driver Reference
Manual,www.infobjects.net/library/ ODUserGuide.pdf
[PS-algol 1988] : PS-algol, "PS-algol Reference Manual, 4th
edition". Universities of Glasgow and St Andrews Technical
Report PPRR-12-88,1988.
[Rahayu et al 1999]:W Rahayu, E Chang, TS Dillon, "
Composite Indices as a mechanism for Multilevel Composite
Objects into Relational Databases", la revue l'objet, Volume
5, OOIS 1999
[Rumbaugh et al 1999] : J.Rumbaugh,I.Jacobson and
G.Booch, "The Unified Modeling Language Reference
Manual"; Addison Wesley, 1999.
[Ros 2004] : S.Ros, Livre blanc sur le Mapping Objet-
Relationnel et la couche de Persistance,
http://www.dotnetguru.org/articles/Persistance/livreblanc/or
mapping.htm
[Roos 2004] : R.Roos, "Java Data Objects", Ed Addison-
Wesley, ISBN 0- 321- 12380- 8
http://www.theserverside.com/news/thread.tss?thread_id=154
88
[Sbihi 2004] : B. Sbihi, "The integration of the points of view
in UML", Advanced Modeling and Optimization, volume 6,
pp.107-115, 2004.
SETIT2005

[Scott et al 2000]: W.Scott and W Ambler, "Mapping Objects
To Relational Databases", version Octobre 2000,
http://www.Ambysoft.com
[Soutou 2002]: C Soutou, " De UML SQL", Edition 1,
ISBN : 2-212-11098-7,Eyrolles 2002.
[Stonbraker et al 1996]: M. Stonbraker and D Moore,
" Object Relational DBMSs, the next great wave", Morgan&
Kaufmann, 1996
[Silberschatz et al 1996]: A.Silberschatz,F.Henry and
S.Sudarshan, "modles de donnes", Mars 1996
:http://cui.unige.ch/~bernardo/article1.html#anchor1_2