Vous êtes sur la page 1sur 24

BASES DE DONNÉES ORIENTÉES OBJETS

1. Limites des SGBD relationnels et nouveaux besoins


Les SGBD relationnels ont à leur avantage:
- le modèle de données est très simple et donc facile à comprendre pour les utilisateurs,
- le modèle repose sur une base formellement définie, ce qui a permis de définir des méthodes de
conception de schémas (théorie de la normalisation) et des langages de manipulation de données
(LMD) standardisés (SQL, QUEL, ...).

Mais, ils ont des faiblesses:


- le modèle de données est trop simple et ne permet pas de représenter facilement les objets du
monde réel qui sont souvent plus complexes qu'une relation. Dans les schémas, les objets du
monde réel sont éclatés en plusieurs relations, ce qui multiplie les jointures dans les requêtes des
utilisateurs.
- l'incompatibilité des LMD relationnels et des langages de programmation:
.  les LMD sont déclaratifs et fournissent en résultat un ensemble de tuples, alors que les
langages de programmation sont impératifs et travaillent sur un élément à la fois,
.  les types de données manipulés par les langages de programmation sont plus complets et plus
complexes que ceux des LMD relationnels.
- le développement d'applications n'est pas satisfaisant: lenteur du développement, résultat souvent
décevant (ne correspond pas ou mal aux besoins), applications difficilement maintenables.

Nouveaux besoins
De nouvelles applications, différentes de celles de gestion classique, se répandent: conception ou
production assistée par ordinateur, génie logiciel, bureautique,… Il faut gérer des objets plus
complexes et plus gros, comme les textes, graphiques, cartes, images, dessins multidimensionnels,
… Par exemple, une image peut occuper des millions d'octets.

Les bases de données orientées objets (BDO) sont nées de la convergence de deux domaines:
-  les bases de données,
-  les langages de programmation orientés objets, tels que Simula, Eiffel, Smalltalk, C ++,…
L'objectif de ces langages est d'accroître la productivité des développeurs en permettant de créer
des logiciels structurés, extensibles, réutilisables et de maintenance aisée. Leurs principes
essentiels sont:
- les objets, qui comportent deux parties: leur valeur, et les opérations, appelées méthodes, qui
permettent de les manipuler. La valeur est cachée. L'accès et la mise à jour des objets se fait
par appel des méthodes. Cela rend plus facile la maintenance des logiciels construits selon
ce paradigme.
- l'héritage, qui permet à une classe d'objets d'avoir les mêmes propriétés (structure de
données et méthodes) qu'une autre classe sans avoir à les redéfinir. C'est l'héritage qui
permet d'étendre et de réutiliser facilement des logiciels.

Les bases de données orientées objets sont caractérisées par quatre points essentiels:
-  un modèle de données qui permet de représenter des structures de données complexes,
-  les données et les traitements ne sont plus séparés. La dynamique (les méthodes) fait partie de la
déclaration des objets,
-  l'héritage,
-  tout objet possède une identité qui le distingue de tout autre objet, même s'ils ont la même valeur.

© Christine Parent 1
D'autres critères sont souvent ajoutés à cette liste, notamment le suivant:
-  il n'y a plus d'incompatibilité entre le langage de programmation et le langage de manipulation
des données.

Les SGBDO sont un domaine en pleine évolution. De nombreuses recherches ont lieu actuellement.
Il n'y a que peu de formalisation, et très peu de consensus, tant sur le modèle de BDO que sur les
LMD objets, alors que de nombreux produits sont proposés sur le marché. Parmi les SGBDO
existants on peut citer, entre autres, pour les plus anciens: GemStone (Servio Logic), Ontos
(Ontologic), Statice (Symbolics), Gbase (Object Databases) et Vision (Innovative Systems); pour la
deuxième génération: Objectivity/DB (Objectivity), Versant (Object Technology), ObjectStore
(Object Design), O2 (O2 Technology), OpenODB (Hewlett Packard), Orion (Itasca Systems); pour
les SGBD relationnels étendus aux objets: Illustra (Illustra Inc.), SQLX (UniSQL).... Cette liste est
incomplète et aucunement limitative.

2. Structure de données
La structure de données des modèles orientés objets (OO) est caractérisée par le fait que, comme en
relationnel, il n'y a qu'un seul concept principal: l'objet. Les objets sont décrits par des propriétés
appelées attributs, et sont regroupés en classes. Chaque objet a une identité qui lui est propre et qui
le distingue de tous les autres. Cette identité est permanente et immuable. On l'appelle oid de l'objet
(en anglais "object identity").

Il existe deux types de liens entre les objets :


• les liens de composition: "tel objet est composé de tel(s) objet(s)". Ces liens sont décrits par
des attributs particuliers, appelés attributs référence, qui ont pour domaine une classe d'objets;
• les liens de généralisation/spécialisation: "tel objet de la base décrit sous un autre point de vue
(plus général ou au contraire plus détaillé) le même fait du monde réel que tel autre objet de la
base". Ce sont les liens IS-A des modèles sémantiques auxquels sont associés un mécanisme
d'héritage des propriétés de la classe d'objets génériques par la classe d'objets spécialisés.

Il n'existe pas un seul modèle de données OO, mais un par SGBDO existant. Il n'y a pas encore de
norme, comme pour le modèle relationnel. Nous présentons ici les points essentiels sur lesquels il y
a consensus.

2.1 Structure complexe


La structure des objets peut être complexe: les attributs peuvent être, comme en entité association
ou en Codasyl, complexes et multivalués. La terminologie, cependant, est différente.

La structure d'une classe est définie en employant des constructeurs:

• le constructeur de tuples, "TUPLE", qui crée un type tuple composé d'une suite d'attributs:
TUPLE (nomatt1: dom1, nomatt2: dom2, ...)
où "domi" est le domaine de l'attribut de nom "nomatti"; c'est :
soit un domaine prédéfini (STRING, REAL, INT, DATE ...),
soit un type défini par un constructeur,
soit un nom d'une classe (voir § 2.2).

• Le constructeur d'ensembles, "SET", qui crée un type ensemble composé d'un ensemble de
valeurs:
SET domaine
où "domaine" a la même définition que ci-dessus.

© Christine Parent 2
Certains SGBDO proposent des constructeurs de collection autres que l'ensemble, tels que la liste,
le multi-ensemble (ensemble avec doubles), le tableau, ...

Exemple:

CLASS Etudiant1
TYPE TUPLE ( num : INT,
nom : STRING,
prénoms : SET STRING,
date-nais : DATE,
adresse : TUPLE (n° : INT,
rue : STRING,
ville : STRING,
pays : STRING)
cours-suivis : SET TUPLE ( nom-cours : STRING,
note : REAL) )

2.2 Liens de composition


Un lien de composition relie une classe C1 à une classe C2 si les objets de C1 (appelés "objets
composites") sont composés d'objets C2 (appelés "objets composants"). Par exemple, les objets
bicyclettes sont composés d'objets roues, cadre, pédalier ... Il y a un lien de composition entre la
classe bicyclette et la classe roue, un autre entre la classe bicyclette et la classe cadre,...
Les liens de composition sont représentés sur les diagrammes représentant les schémas par des
flèches fines.

Ces liens de composition sont implantés par des attributs-référence qui pointent sur les objets
composants. Leur valeur est l'oid de l'objet référencé. C'est ce concept d'oid qui permet d'avoir des
objets partagés (qui sont composants de plusieurs objets composites). La déclaration d'un lien de
composition est faite à l'intérieur de la description de la classe composite par un attribut-référence
dont le domaine est celui de la classe composante.

Exemple: La classe Cours est une classe composante de la classe Etudiant2


CLASS Etudiant2
TYPE TUPLE (num : INT,
nom : STRING,
prénoms : SET STRING,
cours-suivis : SET TUPLE (cours : Cours,
note : REAL) )

CLASS Cours
TYPE TUPLE (nomC : STRING, .... )

Les modèles de BDO existants proposent différentes variantes du lien de composition et parfois des
contraintes d'intégrité qui peuvent lui être associées. Ce sont essentiellement:

• Un objet composant peut être, ou non, partagé entre plusieurs objets de la même classe
composite. Par exemple, dans une base de données décrivant des voitures en réparation dans
un garage, Moteur est une classe d'objets composants non partagés de la classe Voiture. Par
contre, dans une base de données décrivant les modèles de voitures, Moteur serait une classe
d'objets composants partagés de la classe Voiture, puisque deux modèles de voitures peuvent
avoir le même type de moteur.

© Christine Parent 3
• Une classe composante peut être, ou non, dépendante de sa (d'une de ses) classe composite.
Un objet o1 composant est dépendant de tel objet père o2 si l'existence de o1 dépend de celle
de o2, c'est-à-dire si la destruction de o2 entraîne automatiquement celle de o1. Par exemple,
dans la base de données décrivant les voitures en cours de réparation, si le garage ne récupère
aucune pièce sur les voitures envoyées à la casse, alors Moteur serait une classe d'objets
composants dépendants de Voiture. Si au contraire, le garagiste récupère des pièces, et en
particulier certains moteurs, alors Moteur serait une classe composante non dépendante de
Voiture.
Certains SGBDO assurent la contrainte inverse: l'objet composite dépend de ses objets
composants. Les contraintes de dépendance définissent l'ordre selon lequel les objets doivent
être créés (et détruits): d'abord les composants ou d'abord le composite.

• Des cardinalités peuvent être associées au lien de composition, semblables aux cardinalités des
rôles des types d'association du modèle entité-association. La contrainte "C2 est une classe
composante non partagée de la classe C1", qui signifie qu'un objet de C2 ne peut être lié par
un lien de composition qu'à un seul objet de la classe C1, s'exprime alors par:
cardmax ( < lien de composition C1-C2 >, C2 ) = 1

• Le lien de référence est orienté de la classe composite vers la classe composante, de par son
implémentation (pointeur sur les objets de la classe composante), ce qui implique que dans les
requêtes il est beaucoup plus facile et rapide d'aller de l'objet composite aux objets composants
que l'inverse. Pour avoir un accès aisé dans les deux sens dans la base de données, il est utile
de décrire le lien de composition et son inverse.

© Christine Parent 4
Exemple :
CLASS Cours2
TYPE TUPLE (nomC : STRING,
étudiants : SET Etudiant2)
L'attribut étudiants de Cours2 est un attribut référence inverse de l'attribut cours-suivis de la
classe Etudiant2.

Pour que le SGBDO soit à même d'assurer la cohérence de ces attributs-référence inverses,
certains systèmes permettent de déclarer l'existence des attributs inverses par une clause
"INVERSE OF". L'exemple s'écrit alors:
CLASS Cours2
TYPE: TUPLE (nomC : STRING,
étudiants: SET Etudiant2 INVERSEOF cours-suivis•cours )

2.3. Identité d'objet
L'objectif est de pouvoir identifier tout objet indépendamment de sa valeur (ce qui implique, entre
autres, de pouvoir gérer des objets de même valeur mais distincts). Cet identifiant doit être
permanent, fixe (qui ne change pas durant la vie de l'objet) et unique dans la base et dans le temps
(deux objets distincts de la même base, même s'ils n'existent pas en même temps n'auront jamais la
même identité). C'est ce concept d'identité des objets qui permet à plusieurs objets de partager le
même objet composant; ce qui était impossible avec les modèles de données sans identité, comme
par exemple le modèle relationnel.

L'identité des objets est implantée par un identifiant système géré par le SGBDO. Dès la création
d'un objet, un identifiant système lui est attaché. La valeur de cet identifiant n'est ni affichable, ni
imprimable, ni modifiable. On appelle cet identifiant, la référence de l'objet, ou son oid.

L'égalité de deux objets, o1 et o2, peut se mesurer à plusieurs niveaux:


- l'identité d'objets, notée:
o1 == o2
et qui signifie: "est-ce le même objet (le même oid)?"
- l'égalité de surface, notée:
o1 =1 o2
et qui signifie: "les objets o1 et o2 ont-ils la même valeur "au premier niveau"?" C'est-à-dire tous
leurs attributs ont la même valeur, que ce soient des attributs-valeur ou des attributs-référence.
- l'égalité de profondeur, notée:
o1 =* o2
et qui signifie: "les objets o1 et o2 ont-ils "au fond" la même valeur?" C'est-à-dire:
- les objets o1 et o2 ont des graphes de composition isomorphes (leurs attributs-référence
constituent des graphes semblables), et
- les attributs-valeur correspondants, à tous les niveaux, sont égaux.

On a les propriétés suivantes:


o1 == o2  o1 =1 o2
o1 =1 o2  o1 =* o2

Exemple: Soient les deux classes d'objets représentées ci-dessous

© Christine Parent 5
Util isez Word 6.0c (ou ultŽrieur)

pou r affi cher une image Macintosh.

© Christine Parent 6
on a alors:
o1.B == o2.B mais o1 == o2 est faux
o1 =1 o2 mais o1 =1 o3 est faux
o1 =* o3
o21 =1 o22 mais o21 == o22 est faux

Comparaison :
C'est le même principe que dans les langages de programmation où chaque élément d'un
programme possède une identité (nom de la variable ou adresse physique).
C'est différent du relationnel qui est basé sur les valeurs. En relationnel, l'utilisateur doit inventer
des identifiants (ou clés) et les gérer (donner des valeurs différentes aux clés des différents tuples);
ce qui pose problème en cas de mise à jour des attributs de la clé.
Les SGBD Codasyl gèrent aussi l'identité des objets: tout record a un identifiant système appelé
"database key".

2.4. Graphe de généralisation des classes


Certains ensembles d'objets du monde réel ayant des caractéristiques communes peuvent être
perçus comme l'union de plusieurs sous-ensembles d'objets, chaque sous-ensemble ayant des
propriétés particulières. Les modèles de données OO, comme les modèles sémantiques, permettent
de décrire ce type de situation à l'aide du concept de généralisation/spécialisation.
Déclarer une classe CS comme sous-classe (appelée aussi classe spécifique) d'une autre classe CG
(appelée classe générique ou sur-classe):
CS IS-A CG , noté aussi CS ‹ CG ,
(symbolisé graphiquement par une flèche épaisse) implique que:
- CS représente un sous-ensemble des entités du monde réel décrites par CG. Du point de vue
conceptuel, la population de CS est incluse dans celle de CG. (En pratique, au niveau interne,
souvent, ce n'est pas le cas.) Du point de vue de la manipulation des objets, cela signifie que
partout où l'on peut employer un objet de type CG, on peut aussi employer un objet de type
CS;
- si CG a une structure de type tuple (TUPLE ...), alors CS a aussi une structure de type tuple, et
hérite des attributs de CG,
- si CG a une structure de type ensemble (SET ...), alors CS a aussi une structure de type
ensemble,
- CS hérite des méthodes (voir § 3) de CG.

C'est ce concept d'héritage de la structure et des méthodes qui permet la réutilisation des classes
OO.

Exemple : graphe de généralisation des classes décrivant les personnes dans une université
U til isez Word 6 .0c (ou ultŽri eur)

pour affiche r une ima ge Macintosh.

© Christine Parent 7
Déclaration partielle de ce graphe de généralisation:
Class Personne
Type tuple (nom : String [30] ,
prénoms : Set String [30] ,
adr : String [100] )
Methods afficher ;

© Christine Parent 8
Class Etudiant
Is-a Personne
Type tuple (n°E : Int ,
dateN : Date ,
études : Set Tuple : (année : Int ,
diplôme : String [30] ) ,
cours-obtenus : Set Tuple ( cours : Cours ,
année : Int ,
notes : Set Real ) ,
cours-suivis : Set Cours )
Methods afficher ; /* nouvelle définition de la méthode, particulière aux objets de type Etudiant
*/
nouveauétud (nom : String, prénoms : Set String , n°E : Int , adr : String ,
dateN : Date ) ;
inscrire (cours : Cours ) ;
aobtenu (cours : Cours , notes : Set Int ) ;

Class Enseignant
Is-a Personne
Type tuple (tél : Int ,
statut : String [30] ,
rens.banc : Tuple : ( banque : String [30] ,
agence : String [30] ,
compte : Int ) ,
coursdonnés : Set Cours )
Methods afficher ; /* nouvelle définition de la méthode, particulière aux objets de type
Enseignant*/
nouvelens (nom : String, prénoms : Set String, statut : String ) ;
assure (cours : Cours ) ;
nassureplus (cours : Cours ) ;

Dans cette base de données, tout professeur est à la fois un Prof, un Enseignant et une Personne. En
d'autres termes, tout objet Prof "a" les attributs et méthodes de ces trois classes. Plus précisément,
la classe Enseignant possède des attributs et méthodes qui lui sont propres: tel, statut, rens.banc,
coursdonnés, nouvelens, assure, nassureplus. Elle hérite des attributs et méthodes de sa sur-classe
Personne: nom, prénoms, adr, afficher (voir ci-dessous pour l'héritage avec redéfinition de
afficher).

Avantages des sous-classes:


- description plus proche du monde réel (comme dans les modèles sémantiques)
- partage accru des déclaration de structure et des codes des procédures: réutilisation.

Le graphe engendré par la hiérarchie des classes doit être un treillis (pas de cycle autorisé). Cette
interdiction des cycles découle directement de la définition des liens IS-A avec inclusion de
population. En effet si l'on décrivait par exemple les deux liens suivants:
C1 ‹C2 et C2 ‹C1
Cela signifierait que la population de C1 est contenue dans celle de C2 et vice versa. Donc, les
deux classes devraient décrire exactement le même ensemble d'objets; elles devraient donc être
confondues en une seule et même classe.

Des contraintes d'intégrité de couverture et de disjonction peuvent être associées aux sous-classes
d'une classe.

© Christine Parent 9
- un sous-ensemble, S, des sous-classes immédiates d'une super-classe C est disjoint si toute
occurrence de C peut être occurrence d'au plus une des classes de S.
Dans l'exemple du graphe de généralisation des personnes d'une université, un assistant ne peut
pas être aussi un professeur, on a donc une contrainte de disjonction entre ces deux sous-classes.
- un sous-ensemble, S, des sous-classes immédiates d'une super-classe C est couvrant si toute
occurrence de C est aussi occurrence d'une (au moins) des classes de S.
Dans l'exemple du graphe de généralisation des personnes d'une université, si les seules
personnes enregistrées dans la base sont les enseignants et les étudiants, alors il y a une
contrainte de couverture: Enseignant et Etudiant constituent une couverture de Personne. Mais il
n'y a pas de disjonction entre Enseignant et Etudiant, car il peut y avoir des assistant-doctorants
(assistants inscrits en thèse).

Lors de l'héritage, généralement les SGBDO permettent de redéfinir les attributs et/ou les
méthodes héritées. Pour un attribut, le domaine de l'attribut hérité peut être redéfini comme un
sous-ensemble du domaine de l'attribut de la sur-classe. Pour une méthode, son corps (code de la
procédure) peut être redéfini de façon appropriée à la sous-classe. C'est le cas ci-dessus de la
méthode afficher qui est redéfinie dans les sous-classes Etudiant et Enseignant, de façon à afficher,
en plus des attributs de Personne ceux propres à la sous-classe.

L'héritage multiple est possible: une classe peut avoir plusieurs sur-classes. C'est le cas ci-dessus
pour la classe Assistant-Doctorant. Les assistants doctorants sont à la fois assistants (et donc
enseignants) et doctorants (et donc étudiants). Dans le cas d'héritage multiple, un conflit peut
survenir lors de l'héritage des attributs et des méthodes: deux attributs ou méthodes de deux sur-
classes peuvent avoir le même nom et n'être pas identiques. Par exemple, pour Assistant-Doctorant,
quelle est la bonne méthode afficher qu'il faut employer? Celle de Enseignant ou celle de Etudiant?
Face à une telle situation, les SGBDO réagissent différemment:
- soit ils ne savent pas résoudre ce conflit, et refusent la définition d'un tel schéma;
- soit ils demandent au concepteur, lors de la définition d'un tel schéma, qu'il choisisse la sur-
classe "dominante" dont la sous-classe héritera;
- soit ils appliquent une règle déterministe pour ce choix (par exemple la première classe citée
dans la clause IS-A).

L'héritage conduit parfois, à l'image de ce qui se fait dans les langages de programmation, à créer
des classes sans population propre, uniquement pour pouvoir hériter de leurs méthodes. C'est ce
que font les SGBDO en créant une bibliothèque de classes prédéfinies contenant des méthodes
utiles à toutes leurs sous-classes. Par exemple, la méthode new, qui crée un objet d'une classe, est
valable pour toute classe. Ces classes prédéfinies constituent le début du graphe de généralisation
qui regroupe toutes les classes existantes dans le SGBDO.

Exemple : Graphe de généralisation des classes dans le SGBDO Gemstone

© Christine Parent 10
Utilisez Word 6.0c (ou ultŽrieur)

pour afficher une image Macintosh.

Les classes RootClass, Object et Set, sont trois classes prédéfinies par le SGBDO. La classe Object
décrit les méthodes communes à toutes les classes de structure tuple, la classe Set celles communes
à toutes les classes de structure ensemble. L'utilisateur-concepteur définit ses classes en tant que
sous-classes de Object ou de Set. Les classes prédéfinies par le SGBDO possèdent les méthodes
suivantes (qui seront présentées plus en détails au paragraphe 4):

© Christine Parent 11
• classe RootClass :
méthode NEW : création d'un objet.

• classe Object :
méthode GET : permet de lire la valeur d'un attribut pour un objet de cette classe.
méthode STORE : permet d'écrire la valeur d'un attribut pour un objet de cette classe.

• classe Set :
méthodes ADD et REMOVE : insertion ou suppression d'un élément dans un objet de cette classe
(NB cet objet est un ensemble d'objets ou éléments).
méthodes SELECT et DETECT : recherche d'éléments satisfaisant une condition dans un objet de
cette classe.

2.5 Populations et persistance


Dans les SGBD classiques, un type (relation, type d'entité, record type) comporte deux aspects:
- définition de la structure des occurrences potentielles du type. C'est par exemple pour une
relation, la liste des attributs avec leur domaine;
- déclaration d'un récipient contenant toutes les occurrences existantes du type, appelé population
du type. Par exemple en relationnel, dans les LMD le nom de la relation représente l'ensemble de
ses tuples. De plus, toutes les occurrences sont, par définition, permanentes.

Dans les langages de programmation au contraire, un type ne décrit que la structure (et les
opérations associées) des occurrences potentielles. Par exemple, le type INTEGER n'a pas de
population associée: l'ensemble des entiers n'est pas stocké quelque part. Ainsi, les SGBDO, selon
qu'ils ont été conçus par des chercheurs du monde des bases de données ou par ceux du monde des
langages de programmation OO, ont une approche différente de la population des classes.

• Les SGBDO issus du monde des bases de données, associent automatiquement à chaque classe
sa population qui est permanente. Tout objet créé est automatiquement stocké par le système
dans le récipient associé à la classe et qui a pour nom celui de la classe (c'est le cas du SGBDO
Orion).

• Les SGBDO issus du monde des langages de programmation OO, séparent nettement les deux
fonctions de la classe: d'un côté le moule pour créer des occurrences, de l'autre le récipient de
stockage. Les récipients sont créés grâce aux constructeurs de collections qui permettent de
définir des objets qui sont eux-mêmes des collections d'objets. Le concepteur doit, pour chaque
classe CElément dont il veut conserver les occurrences, créer une classe de structure: SET
CElément (ou LIST CElément...), dans les objets de laquelle il stockera tous les objets de type
CElément qu'il voudra conserver.
Par exemple, pour conserver les différentes promotions d'étudiants de premier cycle du
paragraphe 2.4, l'utilisateur devra décrire le schéma suivant:

Class E1cycle
Is-a Etudiant
Type tuple ( ... )
...;

Class Promo1cycle
Is-a Set
Type set E1cycle

Puis les utilisateurs créeront dynamiquement des objets de type Promo1cycle dans lesquels ils
stockeront explicitement les objets créés de type E1cycle, de la façon suivante:

© Christine Parent 12
Program
Declare promo1cycle93 : Promo1cycle;
Declare lucie : Etudiant;
..........
promo1cycle93 : = Promo1cycle.new ;
......
lucie : = E1cycle.nouveauétud ("Dupont", {"Lucie"}, 15344, "chemin des oiseaux 2,
Lausanne", 1/1/70);
promo1cycle93.add(lucie)

Dans ce programme, un récipient pour les étudiants de 1er cycle a été créé: promo1cycle93.
Dans ce récipient l'objet lucie a été stocké. On pourra donc par balayage (ou autre recherche) de
promo1cycle93 retrouver les étudiants de 1er cycle de 1993. Il reste à rendre ce récipient et son
contenu permanents.

En effet, ce type de SGBDO gère deux sortes d'objets: les objets temporaires qui sont détruits
automatiquement à la fin du programme utilisateur qui les a créés, et les objets permanents qui
sont conservés jusqu'à ce que l'utilisateur veuille les détruire. Les SGBDO offrent là aussi
plusieurs solutions:

- une instruction permet de rendre permanent un objet.


Exemple: soit o une variable contenant l'oid d'un objet temporaire, SAVE(o) rend l'objet
opermanent, et o devient le nom par lequel cet objet est désormais accessible;

- la règle suivante est instituée:


"Est permanent tout objet qui est accessible à partir d'un objet permanent".
C'est-à-dire que tous les objets composants d'un objet composite permanent sont eux-mêmes
permanents, et ceci récursivement. Le SGBD offre une "racine de persistance" (ou le moyen
de la créer); c'est un premier objet permanent dont tous les autres objets permanents seront des
composants, par exemple une liste, PersistList, dans laquelle l'utilisateur insérera les objets
qu'il veut rendre permanents.
Dans l'exemple ci-dessus de la promotion 1993 des étudiants de 1er cycle, il faut pour rendre
cet ensemble d'étudiants permanents, rajouter une instruction qui insère promo1cycle93 dans
la liste PersistList.
Cette dernière solution est celle retenue par les SGBDO Gemstone et O2.

L'intérêt de cette approche (celle des SGBDO issus du monde des langages de programmation) est
de faire de la permanence une propriété indépendante des autres. Les objets temporaires et les
objets permanents peuvent être manipulés de la même manière par l'utilisateur. La même classe
peut servir à créer des objets permanents et des objets temporaires de même type.
A l'opposé, l'approche suivie par les SGBDO issus du monde des bases de données, a l'avantage de
décharger entièrement l'utilisateur de la gestion de la permanence des objets.

3. La dynamique
Lors de la conception du schéma d'une base de données orientée objets, la structure des données et
les opérations (les méthodes) qu'on peut effectuer sur ces données sont définies en même temps.
L'accès aux données des objets se fait ensuite à travers ces opérations: on dit que les données sont
"encapsulées". Plus précisément, le principe d'encapsulation consiste à ne laisser connaître aux
utilisateurs des objets d'une classe que l'interface d'appel des méthodes de la classe. La structure des
objets et le code des méthodes leur sont cachés. Seules les méthodes de la classe et de ses sous-
classes peuvent accéder directement à la valeur des objets.

Ce principe d'encapsulation répond aux objectifs suivants:

© Christine Parent 13
- simplifier le travail des programmeurs d'application en ne leur demandant que de connaître le
minimum,
- faciliter la maintenance des applications: on peut facilement changer la structure d'un objet, le
code d'une méthode ou rajouter une nouvelleméthode sans avoir à connaître les autres classes,
ni à modifier les programmes d'application.
- réutiliser au maximum le code des programmes: les méthodes sont écrites une fois pour toutes
et utilisées par tous les programmes d'application dont la taille (en nombre de lignes de code)
diminue d'autant,

3.1 Les méthodes


Déclaration d'une classe d'objets:
La définition d'une classe d'objets comporte donc la définition de la structure des objets et celle des
méthodes servant à manipuler les objets. La déclaration d'une classe d'objets est séparée en deux
parties:
- l'interface, qui est visible aux utilisateurs: définition de la signature de chaque méthode (nom de
la méthode, liste des paramètres d'appel avec leur type, type du résultat s'il en existe un)
- l'implantation, qui est invisible aux utilisateurs: description du type d'objet (cf. § 2), et du corps
de chaque méthode (code de la procédure).

Exemple :
Class Personne
Type tuple (nom : String [30] ,
prénoms : Set String [30] ,
adr : String [100] )
Methods afficher ;
Procedure afficher : <code de la méthode "afficher" en C++ ou autre langage de
programmation> ;

Utilisez Word 6.0c (ou ultŽrieur)

pour afficher une image Macintosh.

Encapsulation des classes

Degrés d'encapsulation

© Christine Parent 14
Les SGBDO n'appliquent pas tous strictement l'encapsulation. L'encapsulation stricte est lourde à
appliquer, notamment elle rend difficile la définition d'un LMD déclaratif de type SQL ou QUEL.
On peut définir différents degrés d'encapsulation:
- encapsulation stricte: tout accès aux données d'un objet d'une autre classe se fait par appel
d'une méthode de la classe de l'objet;
- encapsulation des écritures: tout accès en écriture se fait par appel d'une méthode, les accès en
lecture peuvent être faits directement (sans passer par l'appel d'une méthode);
- encapsulation partielle: les classes d'objets ont deux types de données, les données publiques
accessibles directement, et les données privées accessibles uniquement par l'appel de
méthodes.
Par exemple O2 propose trois niveaux d'encapsulation pour les attributs et méthodes:
- Private: (option par défaut) qui signifie l'encapsulation stricte,
- Read: (option possible pour un attribut uniquement) qui signifie l'encapsulation des écritures,
- Public: aucune encapsulation, accès possible par tous en lecture et écriture.

Pour le SGBDO présenté en exemple dans ce chapitre, nous respectons l'encapsulation stricte.

3.2. Surcharge et liaison dynamique


Un concept important de la programmation orientée objet est la surcharge des méthodes. Ce
concept existait déjà dans les langages traditionnels. Il consiste à permettre de donner le même
nom à plusieurs opérations différentes. Par exemple le signe + est utilisé pour l'addition de deux
entiers et pour celle de deux réels, parfois aussi pour deux booléens ou pour concaténer deux
chaînes. Le même nom, +, appellera l'exécution de codes différents selon le type des arguments.

L'association du nom de l'opérateur au "bon" code peut être faite:


- soit lors de la compilation. C'est le cas des langages de programmation typés tels que Pascal ou
C;
- soit lors de l'exécution. C'est le cas des langages de programmation non typés tels que
Smalltalk. Dans ce cas on parle de liaison dynamique ou tardive ("dynamic binding" ou "late
binding").

Les SGBDO, même s'ils ont un langage de programmation typé, utilisent le mécanisme de liaison
dynamique pour le choix du corps des méthodes dans le cas de redéfinition de méthodes dans une
sous-classe. En reprenant l'exemple de la méthode afficher du paragraphe 2.4, supposons que la
méthode afficher de Personne affiche les nom, prénoms et adr, et que la méthode afficher de
Enseignant affiche les nom, prénoms, adr, tel et coursdonnés. Soit le programme suivant:

Declare John: Personne;


Declare Annie: Enseignant;
......
John.afficher ;
John: = Annie ;
John.afficher ;

Ce programme déclare deux variables-oid, John de type Personne, Annie de type Enseignant. La
première instruction, John.afficher, lance l'exécution de la méthode afficher de Personne.
L'instruction, John: = Annie, est valide car le type d'Annie (Enseignant) est un sous-type de celui
de John (Personne). La dernière instruction va donc lancer l'exécution de la méthode correspondant
non pas au type déclaré pour John mais au type réel de John lors de l'exécution, c'est-à-dire la
méthode de Enseignant.

© Christine Parent 15
La liaison dynamique donne une grande souplesse et une grande puissance à la programmation.
Les SGBDO permettent ainsi de combiner les avantages de la liaison dynamique et ceux des
langages typés (détection plus facile des erreurs).

4. Interface de manipulation des données


L'interface naturel des SGBDO est procédural et navigationnel. Les utilisateurs écrivent des
programmes dans lesquels les accès et mises à jour des objets de la base se font par envoi de
messages aux objets (appels de méthodes). Ce type d'interface possède un double avantage:
- les utilisateurs disposent de la puissance d'expression d'un langage de programmation; ce qui n'est
pas le cas lors de l'emploi d'un LMD type SQL seul;
- le problème d'incompatibilité qui existe en relationnel entre les LMD et les langages de
programmation est réduit au minimum: les mêmes structures de données peuvent être utilisées
dans le langage de programmation et dans les méthodes des classes; le même type d'interface
que celui des langages de programmation (impératif, un élément à la fois) peut être employé
pour les méthodes.
Mais, si l'on ne veut pas avoir de problème ultérieur de modification de schéma, cela suppose lors
de la conception de la BDO, de déclarer toutes les méthodes qui seront utilisées par la suite.

Les méthodes associées aux classes utilisent dans leur code les méthodes prédéfinies des classes
prédéfinies. Ces méthodes prédéfinies permettent d'effectuer des manipulations élémentaires sur la
base de données, telles que la création d'un objet, le stockage d'un objet, le passage d'un objet
composé à un de ses composants, la recherche dans un objet de type collection d'un élément de
cette collection, ....

Nous présentons ci-dessous, à titre d'exemple, un jeu de méthodes prédéfinies inspirées de celles du
SGBDO Gemstone.

© Christine Parent 16
• Navigation d'un objet  à un autre objet 1, composant de 
Il existe une méthode prédéfinie associée à la classe Object, GET, qui permet de passer d'un objet
de type tuple à l'un de ses composants, mais il n'existe pas de méthode prédéfinie inverse: le lien de
composition est orienté de l'objet composé vers le composant.
message d'appel: v := oid.get (nom-attribut)

Exemple:
Dans la BDO FormaPerm définie en annexe 2, on veut imprimer la liste des noms des cours
obtenus par l'étudiante lucie (lucie est une variable contenant l'oid de l'objet décrivant l'étudiante en
question).
Declare ctuple : Tuple ( cours : Cours
année : Int,
notes : Set Real ) ;
Declare cs : Set ctuple ;
Declare c : Cours ;
cs := lucie.get(cours-obtenus) /* cs contient un ensemble d'oids de Cours */
pour chaque ctuple de cs faire:
c:= ctuple.cours ; /* c contient l'oid d'un cours obtenu par lucie */
imprimer( c.get(nomC) ) ;
fintantque

• Insertion de nouveaux objets


L'insertion d'un nouvel objet s'effectue à l'aide des méthodes prédéfinies, notamment NEW de la
classe RootClass, STORE de la classe Object, et ADD de la classe Set.
messages d'appel: v := nom-classe.new
oid.store (nom-attribut, valeur-attribut)
oid-ensemble.add (élément)

Exemple:
Dans la BDO FormaPerm, création de l'étudiante lucie dans la promotion 1993, et inscription de
lucie aux cours de bases de données et de langages.
Soient: - promo93 un objet permanent de la classe Etudiants destiné à rassembler tous les
étudiants de la promotion 1993,
- bd l'oid de l'objet Cours décrivant le cours de bases de données,
- lp l'oid de l'objet Cours décrivant le cours de langages.

Declare lucie : Etudiant;


lucie := nouveauétud( "Dupont", { "Lucie" }, 15467, "chemin des oiseaux 2, Lausanne",
1/1/70 );
promo93.add(lucie) ; /* la méthode ADD ajoute un élément à un ensemble */
lucie.inscrire(bd);
lucie.inscrire(lp);

• Recherche dans un ensemble


- SELECT: méthode de la classe Set, qui permet de chercher dans un ensemble d'objets, le ou les
objets qui satisfont une formule logique.
Le résultat est un objet du même type (c'est aussi un ensemble).
message d'appel: v-ensemble1 := oid-ensemble2.select x formule(x))
/* x est une variable qui, à l'exécution,
balayera les objets de l'ensemble2 */

© Christine Parent 17
Exemple: recherche des cours donnés par le professeur de nom Duval en 1993/94
Soit cours93 un objet permanent de la classe Courss contenant tous les cours de l'année 93/94
Declare coursDuval : Courss ;
coursDuval: = cours93.select (c  (c.get(prof)).get(nom) = "Duval") ;

- DETECT: méthode de la classe Set, qui fournit en résultat le premier objet de l'ensemble qui
satisfait une formule logique
message d'appel: v := oid-ensemble.detect (x | formule(x))

Exemple : la recherche du cours de bases de données dans l'ensemble des cours de l'année 1993/94
se fait de la façon suivante:
Declare bd : Cours ;
bd : = cours93.detect (c  c.get(nom) = "BD") ;

• Suppression
- REMOVE: méthode de la classe Set qui supprime un élément de l'ensemble
message d'appel: oid-ensemble.remove (élément-à-supprimer)

Exemple: supprimer l'étudiant d'oid eo de la promotion 1993:


promo93.remove(eo) ;

Ce type d'interface navigationnel est très puissant, mais il est nettement moins efficace quant à la
productivité des programmeurs que les langages déclaratifs tels SQL auxquels les utilisateurs de
base de données sont habitués. Aussi les SGBDO actuels commencent à offrir des LMD OO
déclaratifs plus ou moins proches de SQL.

5. Conclusion
Nombreux avantages :
- ceux de l'approche orientée objets: réutilisation, maintenance facilitée, ...
- modèle de données riche
- prise en compte de la dynamique
- fusion LMD / langage de programmation: beaucoup moins d'incompatibilité entre le LMD et le
langage de programmation.

De nombreux problèmes non encore résolus:


- il n'y a pas (encore) de contrainte d'intégrité. Par exemple, la notion de lien de composition
inverse n'existe pas toujours et c'est au concepteur de l'implémenter dans les méthodes.
- la simplicité du modèle relationnel est perdue
- il n'existe pas encore de consensus sur un standard pour un LMD déclaratif de type SQL (auquel
les utilisateurs sont habitués). deux propositions s'affrontent: ODMG et SQL3.
- la conception du schéma avec les méthodes associées n'est pas facile: il n'existe pas encore de
méthode complète de conception des données et des méthodes associées.
- des travaux sont en cours sur les vues, les versions, l'évolution du schéma, les aspects temporels,
la fusion des bases de données orientées objets et des bases de données déductives, …

Bibliographie
M. Adiba, C. Collet: Objets et bases de données, le SGBD O2, Hermes 1993

© Christine Parent 18
American National Standards Institute (ANSI) Database Committee (X3H2): Database Language
SQL3, J. Melton (Editor), August 1994

M. Bouzeghoub, G. Gardarin, P. Valduriez: Objets: concepts, langages, bases de données,


methodes, interfaces: Du C++ à Merise Objet, Eyrolles 1994

R. G. G. Cattell: The Object Database Management Standard : ODMG-93, Morgan Kaufmann


Publishers, 1994

R. G. G. Cattell: Object Data Management, Addison Wesley 1991

K. R. Dittrich, U. Dayal, A. P. Buchmann (Eds): On Object Oriented Database Systems,


Springer Verlag, 1991

S. Khoshafian: Object Oriented Databases, Wiley 1993

W. Kim: Introduction to Object-Oriented Databases, The MIT Press 1990

J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Lorensen: Object Oriented Modeling and


Design, Prentice Hall, 1991

S. B. Zdonik, D. Maier (Eds): Readings in Object-Oriented Database Systems, Morgan


Khaufmann Publishers, 1990

© Christine Parent 19
Annexe 1 : Définition du LDD

Class nom-classe1 [is-a nom-classe2 [, nom-classe3, ...] ]


[ Type <type-tuple>  <type-ensemble> ]
[ Methods nom-méthode1 [(paramètre11 : dom11, paramètre12 : dom12, ....)]
[ › domrésultat1 ] ;
…]
[ Procedures nom-méthode1 : <code de la méthode1>;
…]

<type-tuple> ::= tuple ( nom-att1 : <dom1> [, nom-att2 : <dom2> , ... ] )


<type-collection> ::= set <dom3>  list <dom3> multiset <dom3>
<domi> ::= Char  Int  Real  Date  nom-classe4  <type-tuple>  <type-collection>

Syntaxe des messages d'appel:


- pour une méthode portant sur une classe, par exemple new, nouveauétud:
[variable :=] nom-classe.nom-méthode (paramètre1, ...)
- pour une méthode portant sur un objet, par exemple get, inscrire:
[variable :=] oid.nom-méthode (paramètre1, ...)

Annexe 2 : Schéma OO de FormaPerm

Nous donnons ici un exemple de conception d'une base de données orientées objets. La description
est partielle en ce sens que toutes les méthodes n'ont pas été définies et que le corps (code) des
méthodes n'est pas précisé.

Soit un institut de formation permanente qui veut gérer avec une base de données ses cours, ses
enseignants et ses étudiants, avec leurs inscriptions et leurs résultats.
Les cours, identifiés par leur nom, sont répartis sur trois cycles (1, 2 et 3). Chaque cours peut avoir
zéro, un ou plusieurs autres cours du même cycle ou des cycles précédents en prérequis.
Un enseignant, identifié par son nom, peut assurer un ou plusieurs cours; mais un cours est assuré
par un seul enseignant. L'institut mémorise, pour chaque enseignant, ses nom, prénom, adresse,
numéro de téléphone, statut (universitaire, professionnel...), et renseignements bancaires.
Les étudiants s'inscrivent à un ou plusieurs cours et paient un droit d'inscription pour chaque cours
(qui est le même pour tous les cours).
Lors de sa première inscription à l'institut, l'étudiant reçoit un numéro qu'il conserve tout au long de
sa formation. Chaque étudiant est décrit par ses nom, prénoms, numéro, adresse, études antérieures

© Christine Parent 20
(diplômes et année) et date de naissance. L'institut conserve, pour chaque étudiant, la liste des cours
qu'il a obtenus, avec la note et l'année.

© Christine Parent 21
Diagramme OO de la structure des données de FormaPerm

Utilisez Word 6.0c (ou ultŽrieur)

pour afficher une image Macintosh.

© Christine Parent 22
Schéma de FormaPerm

Class Personne Is-a Object


Type tuple (nom : String [30],
prénoms : List String [30],
adr : String [100] )
Methods afficher ;

Class Etudiant Is-a Personne


Type tuple (n°E : Int,
dateN : Date,
Etudes : List Tuple (année : Int,
diplôme : String [30] ),
cours-obtenus : List Tuple ( cours : Cours ,
année : Int,
notes : Set Real ) ,
cours-suivis : Set Cours )
Methods afficher ;
nouveauétud (nvnom : String, nvprénoms : Set String, nvn°E : Int,
nvadr : String, nvdateN : Date ) ;
inscrire (nvcours : Cours ) ;
aobtenu (nvcours : Cours , nvnotes : Set Real, nvannée : Int ) ;

Class Enseignant Is-a Personne


Type tuple (tél : Int,
statut : String [30],
rens.banc : Tuple ( banque : String [30],
agence : String [30],
compte : Int ) ,
cours-assurés : Set Cours )
Methods afficher ;
nouvelens (nvnom : String, nvprénoms : Set String, nvadr : String,
nvstatut : String );
assure (nvcours : Cours ) ;
nassureplus (oldcours : Cours ) ;

Class Cours Is-a Object


Type tuple (nomC : String [30] ,
cycle : Int,
prof : Enseignant Inverse coursdonnés ,
étudiants : Set Etudiant Inverse courssuivis ,
prérequis : Set Cours )
Methods afficher ;
nouveaucours (nvnomC : String , nvcycle : Int , nvprérequis : Set Cours ) ;

Class Enseignants Is-a Set


Type set Enseignant ;

© Christine Parent 23
Class Etudiants Is-a Set
Type set Etudiant ;

Class Courss Is-a Set


Type set Cours ;

© Christine Parent 24

Vous aimerez peut-être aussi