Bases de Données Orientées Objets
Bases de Données Orientées Objets
Bases de Données Orientées Objets
et article présente les concepts orientés objets tels qu’on les utilise dans
C
6 - 1992
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 3 840 − 1
BASES DE DONNÉES ORIENTÉES OBJETS ___________________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 3 840 − 2 © Techniques de l’Ingénieur, traité Informatique
__________________________________________________________________________________________________ BASES DE DONNÉES ORIENTÉES OBJETS
2. Concepts et modélisation
Un modèle de données orienté objets est un ensemble de concepts
destiné à décrire des objets et leurs associations. De tels modèles
ont été conçus pour offrir à l’utilisateur la possibilité de décrire et
de partager des objets complexes et volumineux, de prendre en
compte le concept de version et de gérer l’activité de la base de
données grâce à l’envoi de messages. La plupart des concepts
utilisés dans ces modèles se retrouvent dans les langages de
programmation objets (Smalltalk notamment) et dans les langages
de représentation de connaissances (Kool et Kee par exemple). Il
n’existe pas à l’heure actuelle de véritable consensus autour d’un
modèle de données orienté objets à l’image du standard relationnel.
On dispose donc de modèles, parfois très voisins, qui ont été
proposés dans des systèmes commerciaux et des prototypes de
recherche tels que O2, Orion, Ontos, Postgres et Gemstone.
Le modèle que nous présentons est un modèle minimal qui est
naturellement inspiré de l’état de l’art en la matière.
Les entités conceptuelles du monde réel telles que les nombres, 2.2 Objets, types et classes
les personnes, les automobiles sont représentées par un concept
unique : celui d’objet. Un objet possède un identifiant, un état qui
est donné par sa valeur et un comportement qui correspond aux Dans les applications classiques, on sépare les données (les
différents messages auxquels l’objet peut réagir. fichiers ou bases de données) des traitements qui les manipulent
(les programmes). Cette dualité disparaît dans l’approche orientée
Tout objet est défini conformément à un type abstrait qui, objets ; une application informatique est donc constituée d’un
comme dans la plupart des langages de programmation, spécifie : ensemble d’objets distincts possédant leur propre comportement
— l’ensemble des valeurs possibles (c’est-à-dire la structure de et capable d’échanger des messages pour réaliser les traitements.
données) ;
— l’ensemble des méthodes (opérations) applicables à ces
valeurs. 2.2.1 Identifiant d’un objet
Les objets de même type sont regroupés dans des classes
nommées ; chaque classe est donc associée à un type unique Un objet correspond à une entité du monde réel et est identifié
(définition de la classe) et contient un ensemble d’objets (l’extension de manière unique dans le système. Cet identifiant n’est ni modi-
de la classe). Pour créer une nouvelle classe, on lui donne un nom fiable, ni réutilisable car il s’agit d’un identifiant interne au système.
et on définit le type d’objets qui lui est associé ; à cet instant, l’exten- L’introduction de ce concept est liée à deux aspects :
sion de la classe est naturellement vide. La création d’un objet
— il permet de formaliser le concept d’état d’un objet : l’état d’un
consiste à instancier la classe : le système affecte un identifiant à
objet est une liste de valeurs d’attributs ; si cette valeur n’est pas
l’instance (objet) et l’utilisateur peut, s’il le souhaite, affecter une
primitive, elle est à son tour un identifiant d’objet et, donc, peut être
valeur à cette instance grâce à la méthode créer.
virtuellement considérée comme l’état d’un autre objet ; on a ainsi
Par exemple, la classe EMPLOYÉS est associée à un type de n-uplet une définition récursive ;
qui comporte deux attributs représentés par les symboles MATRICULE — les concepts orientés objets ont été initialement introduits indé-
et NOM : pendamment du concept bases de données à partir des langages
classe EMPLOYÉS = [MATRICULE : Integer, NOM : String] orientés objets ; les promoteurs de ce concept avaient comme
En instanciant la classe EMPLOYÉS, l’objet créé aura la forme définie préoccupation essentielle la mise en œuvre de mécanismes de dési-
par la structure de données ci-dessus, en l’occurrence celle d’un couple. gnation et de restitution. Dans une phase initiale, ils n’ont pas eu
comme préoccupation les mécanismes de sélection d’objets
Les valeurs d’attribut sont elles-mêmes des objets ; cela signifie que, répertoriés dans un ensemble via des prédicats de sélection : pour
pour valoriser un objet de la classe, l’utilisateur fournira (ou désignera) répondre à ce besoin, la structure initiale de l’identifiant d’objet et
deux objets appartenant respectivement aux classes primitives Integer les mécanismes de gestion associés ont dû être adaptés.
et String (figure 1).
Ce concept d’identifiant joue un rôle primordial dans les Systèmes
Naturellement, la valeur d’un attribut n’appartient pas de Gestion de Bases de Données Orientées Objets. Il a conduit
nécessairement à une classe primitive ; elle peut être elle-même un naturellement à un modèle navigationnel pour la manipulation des
objet complexe. Par exemple, si l’objet de la classe EMPLOYÉS objets. Les mécanismes d’accès agissent sur un réseau d’identifiants.
comportait un attribut APPARTENIR désignant le service auquel
appartient l’employé, cet attribut aurait pris pour valeur un objet de
la classe SERVICES.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 3 840 − 3
BASES DE DONNÉES ORIENTÉES OBJETS ___________________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 3 840 − 4 © Techniques de l’Ingénieur, traité Informatique
__________________________________________________________________________________________________ BASES DE DONNÉES ORIENTÉES OBJETS
Les deux remarques précédentes permettent la mise en œuvre Le concept d’héritage peut conduire à des conflits de noms
des concepts de : d’attributs et de méthodes. Les stratégies de résolution des conflits
— héritage (ou généralisation/spécialisation) ; de nom sont les suivantes.
— composition (ou agrégation). ■ Héritage simple : c’est le nom de la classe qui prévaut par rapport
Ces aspects sont présentés sur la figure 3. à celui de la superclasse. Le système considère toujours la spécifica-
tion locale.
■ Héritage multiple :
2.3 Liens d’héritage et de composition — soit il y a une mention explicite de la superclasse à considérer ;
— soit il y a un choix implicite (sélection, par exemple, de la
première superclasse indiquée dans la liste des superclasses).
Le concepteur d’une base de données orientée objets peut utiliser
Les intérêts de l’utilisation de l’héritage se résument en :
les concepts de généralisation / spécialisation pour mettre en
évidence des sous-classes au sein d’une classe dite générique (ou — spécification par niveaux d’abstraction ;
superclasse). Les liens établis entre classe et sous-classes sont — conception incrémentale ;
appelés liens d’héritage ; ils matérialisent la propriété, dont bénéficie — réutilisation de spécification et de code.
la sous-classe, d’hériter des propriétés de la superclasse. Le nombre
de niveaux de spécialisation n’est pas limité comme le montre
l’exemple suivant (figure 4). Le graphe ainsi formé est appelé graphe
d’héritage de la classe EMPLOYÉS.
2.4 Surcharge
Le concepteur peut également définir les liens de composition
entre classes grâce à la notion de domaine d’un attribut. Un domaine Le processus d’héritage peut imposer le fait d’affiner le compor-
peut être soit une classe primitive, soit une classe complexe définie tement de certaines méthodes selon que l’objet générique auquel
par l’utilisateur (il s’agit là d’une différence fondamentale entre un elles s’appliquent appartient à telle ou telle sous-classe.
modèle orienté objets et le modèle relationnel normalisé qui
On est ainsi amené à disposer de méthodes apparaissant à
n’autorise que les domaines atomiques).
plusieurs niveaux dans le graphe d’héritage. Le corps de ces
Considérons l’exemple qui décrit une classe de rapports (figure 5) méthodes a une spécification plus ou moins détaillée selon le niveau
Généralement, les classes primitives ne sont pas représentées de spécialisation.
pour ne pas alourdir les schémas. Pour illustrer ce propos, nous allons utiliser une spécification telle
Dans une instance de classe, un attribut représente une partie de qu’elle apparaîtrait dans le contexte du prototype de Système de
cette instance. La valeur prise par l’attribut est un objet d’une autre Gestion de Bases de Données Orientées Objets O2 .
classe qui peut être complexe et donc posséder des attributs
■ Classe générique
eux-mêmes complexes, etc. On voit comment un tel modèle permet
Class PERSONNES
de décrire la composition des objets complexes ; en effet, leurs struc-
tures hiérarchiques peuvent comporter un grand nombre de niveaux Type Tuple (NOM String, :
successifs. PRÉNOM String, :
AGE Integer,:
Dans un système orienté objets, les liens de composition sont
généralement traduits par le concept d’identité d’objet. Si l’on TEL :
Tuple (INDICATIF: Integer,
prend, par exemple, une instance de RAPPORTS, l’attribut ÉCRIRE NUMÉRO : Integer),
contient l’identifiant d’un employé ; l’attribut multivalué CHAP ENFANTS : List (PERSONNES))
contient, quant à lui, un ensemble d’identifiants d’objets de la Method INIT () : PERSONNES,
classe CHAPITRES. MAJ-ENFANTS... ;
Pour une classe donnée, l’ensemble des classes qui lui sont Le constructeur Tuple permet de définir un n-uplet en agrégeant
associées par des liens de composition forment un graphe de des attributs, le constructeur List permet de définir une liste.
composition.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 3 840 − 5
BASES DE DONNÉES ORIENTÉES OBJETS ___________________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 3 840 − 6 © Techniques de l’Ingénieur, traité Informatique
__________________________________________________________________________________________________ BASES DE DONNÉES ORIENTÉES OBJETS
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 3 840 − 7
BASES DE DONNÉES ORIENTÉES OBJETS ___________________________________________________________________________________________________
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 3 840 − 8 © Techniques de l’Ingénieur, traité Informatique
__________________________________________________________________________________________________ BASES DE DONNÉES ORIENTÉES OBJETS
Toute opération sur un objet nécessite l’envoi d’un message à cet Le modèle que nous avons présenté (§ 2.1) permet au concepteur
objet qui le décode et exécute la méthode correspondante si aucune de la base de créer des classes d’objets et des associations entre
anomalie n’est détectée. La syntaxe d’un message a été donnée classes. Nous avons considéré deux types d’associations :
(§ 2.6) : — les liens d’héritage entre une classe et ses sous-classes ;
(SÉLECTEUR OBJET PARAMÈTRES) — les liens de composition entre un attribut et sa classe de
définition.
Ainsi, pour créer un objet dans une classe, le programme d’appli-
Le schéma d’une base de données peut être représenté sous la
cation doit envoyer un message dont le sélecteur est créer :
forme d’un graphe où les nœuds sont des classes d’objets et où les
(créer EMPLOYÉS : MATRICULE = 258,
arcs correspondent à des liens entre classes. Or, dans plusieurs
NOM = ’Dupont’, systèmes orientés objets, le schéma de la base peut être visualisé
APPARTENIR = (créer SERVICEST : NOM_S = graphiquement à l’écran. L’utilisateur peut ainsi formuler ses
’Réseaux’)) requêtes plus aisément en appréhendant visuellement l’ensemble
Dans cet exemple, deux objets sont créés : l’un dans la classe des liaisons interobjets.
EMPLOYÉS et l’autre qui correspond à la valeur de l’attribut Le graphe présenté sur la figure 9 correspond au schéma d’une
APPARTENIR dans la classe SERVICES. base de données dans une entreprise. Il nous servira de base pour
Pour opérer sur les objets, le programmeur a la possibilité : les exemples de requêtes présentés dans le paragraphe suivant.
— d’écrire ses propres méthodes et de les attacher à une classe
d’objets ;
— d’utiliser des méthodes prédéfinies, analogues à la méthode 3.3 Requêtes
créer, qui permettent de réaliser les opérations fondamentales
(adjonction, suppression, consultation,...).
Parmi les méthodes prédéfinies, la méthode select revêt une Nous présentons ici quelques éléments des langages de requêtes
importance particulière. En effet, l’activation de cette méthode est proposés dans les systèmes orientés objets. Nous avons vu qu’une
comparable à la soumission d’une requête SQL dans une base de requête n’est autre qu’un message activant une méthode dans une
données relationnelle. Nous étudierons plusieurs exemples de classe. Pour interroger la base d’objets, l’utilisateur envoie un
requêtes dans le paragraphe 3.3. message select en précisant la classe d’objets cible et la condition
de sélection ; seules les instances satisfaisant ces conditions seront
retenues. Naturellement, l’utilisateur peut envoyer un message à une
sous-classe ; conformément aux liens d’héritage spécifiés dans le
schéma, la sous-classe hérite des attributs et des méthodes de sa
superclasse.
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 3 840 − 9
BASES DE DONNÉES ORIENTÉES OBJETS ___________________________________________________________________________________________________
D’autre part, depuis une classe donnée, une requête peut réfé- ■ Obtenir les informaticiens de moins de 25 ans affectés au projet
rencer d’autres classes grâce aux liens de composition. Nous verrons Colombus :
dans les exemples suivants comment la classe référencée est select i
désignée simplement dans la requête. from i in INFORMATICIENS
Dans le modèle relationnel, le résultat d’une requête est une rela- where i. AGE < 25
tion construite à partir des opérandes de la requête (les opérandes and exists p in i. AFFECTER : (p.INTITULÉ = « Colombus »)
sont les classes spécifiées dans la clause from d’une requête SQL).
INFORMATICIENS est une sous-classe d’EMPLOYÉS et, à ce titre,
Dans l’approche orientée objets, il serait séduisant de considérer que hérite de ses propriétés (AGE notamment). Le lien de composition
le résultat d’une requête soit une classe. Cependant, à une AFFECTER est un attribut multivalué, c’est-à-dire qu’une de ses
classe-opérande (notons C cette classe) s’ajouterait :
valeurs correspond à un sous-ensemble des instances de la classe
— l’ensemble des sous-classes de C figurant dans la hiérarchie PROJETS. Ce sous-ensemble est considéré comme une classe à
d’héritage ; laquelle est envoyé un message select qui retournera un ensemble
— l’ensemble des classes référencées par C telles qu’elles appa- d’instances éventuellement vide. Le prédicat exists vérifie la pré-
raissent dans la hiérarchie de composition. sence ou l’absence d’éléments dans cet ensemble.
Cette propriété a conduit des concepteurs de systèmes orientés
■ Obtenir les programmeurs appartenant au service Réseaux et affec-
objets à considérer le résultat d’une requête comme un ensemble
tés dans les projets dont le chef se nomme Dupont :
d’identifiants d’objets (dans Orion) ou de valeurs dans (O2).
select p
Les exemples de requêtes suivants font appel à la syntaxe du from p in PROGRAMMEURS
langage O2Query du système O2. where p. APPARTENIR · NOM_S = « Réseaux »
■ Obtenir les employés qui ont plus de 40 ans : and exists x in p. AFFECTER : (x ·CHEF ·NOM = «Dupont»).
select e Cette requête s’applique à la classe PROGRAMMEURS qui hérite
from e in EMPLOYÉS de l’union des propriétés des classes EMPLOYÉS et INFORMATI-
where e. AGE > 40 CIENS.
Cette requête (message select) s’applique à la classe EMPLOYÉS. Les liens de composition matérialisent des jointures implicites
Le résultat de la requête correspond à un ensemble d’objets de la entre classes ; mais ces liens doivent figurer dans le schéma de la
classe EMPLOYÉS, y compris les liens de composition avec la classe base. Or, l’utilisateur peut souhaiter établir dynamiquement
SERVICES et, le cas échéant, les liens avec les sous-classes. d’autres associations lors de la consultation des données. Ainsi,
La variable e désigne un objet de la classe EMPLOYÉS ; cette nota- certains systèmes comme Orion autorisent les jointures explicites
tion, qui s’inspire du calcul des prédicats (∃ e ∈ E,...), permet de lever sur des classes dès lors que celles-ci possèdent des attributs dont
les ambiguïtés lors de la manipulation des liens de composition. les domaines sont sémantiquement compatibles. Par exemple, la
requête permettant d’obtenir les employés du service auquel est
■ Obtenir les employés qui ont plus de 40 ans et qui sont affectés au rattaché le projet Colombus s’exprime par une jointure explicite
service informatique : entre les classes EMPLOYÉS et PROJETS. Cette jointure est rendue
select e possible par l’existence des attributs APPARTENIR et RATTACHER
from e in EMPLOYÉS qui partagent le même domaine (la classe SERVICES.)
where e. AGE > 40
and e. APPARTENIR · NOM_S = « Informatique »
Ici, bien que la requête s’applique encore à la classe EMPLOYÉS,
le prédicat de sélection utilise le lien de composition APPARTENIR ;
4. Évolutions de schémas
ce lien référence une instance de la classe SERVICES dont les attributs
peuvent intervenir dans la requête sur EMPLOYÉS. Le nom de l’attribut Les systèmes de gestion de bases de données relationnels
APPARTENIR se substitue au nom de la classe qu’il référence. permettent l’adjonction, la suppression, la modification d’une rela-
tion. La modification du schéma d’une relation concerne l’adjonction
■ Obtenir les employés du service informatique qui sont plus âgés d’une nouvelle colonne ou le changement de format d’une colonne.
que leur directeur : De manière simple, on peut dire qu’il suffit au système de mémoriser
select e la présence ou l’absence d’une relation et/ou colonne à l’aide du cata-
from e in EMPLOYÉS logue des relations (métabase). Cette situation simple ne se retrouve
where e. APPARTENIR · NOM_S = « Informatique » pas dans un contexte orienté objet.
and e. AGE > e. APPARTENIR. DIRECTEUR. AGE Le schéma d’une base de données objets peut évoluer sur deux
Cette requête utilise un graphe cyclique dans le schéma de base ; plans orthogonaux :
en effet, dans la classe EMPLOYÉS, l’attribut APPARTENIR référence — celui de la hiérarchie de classe (généralisation/spécialisation) ;
SERVICES et, inversement, dans SERVICES, l’attribut DIRECTEUR — celui de la hiérarchie de composition (agrégation).
référence EMPLOYÉS. La variable de désignation e, qui représente
Ainsi, si l’on considère le fait que chaque classe appartient à une
une instance courante dans la classe EMPLOYÉS, permet d’exprimer
hiérarchie de classe, la suppression d’une classe fait perdre aux
sans ambiguïté la partie droite de la dernière condition de la requête.
sous-classes les attributs et méthodes hérités de la classe supprimée
et par voie de conséquence les instances doivent perdre les valeurs
des attributs. On constate que l’impact d’une telle opération peut
être considérable et difficile à évaluer par l’auteur de l’opération de
suppression.
D’autre part, la création d’une nouvelle classe s’accompagne de
l’association à ses superclasses pour mettre en œuvre le mécanisme
d’héritage. Ainsi, dans un contexte objet, on peut envisager des
opérations de transformation de schéma qui n’avaient pas de sens
dans un contexte relationnel comme « déclarer une classe existante
superclasse d’une sous-classe existante ».
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 3 840 − 10 © Techniques de l’Ingénieur, traité Informatique
__________________________________________________________________________________________________ BASES DE DONNÉES ORIENTÉES OBJETS
Les opérations d’évolution de schéma peuvent se résumer ainsi. En revanche, si l’identifiant ne contient pas l’identifiant de la classe,
la migration se réalise sans toucher à l’identifiant d’objet, mais cette
■ Adjonction/suppression de classe approche pénalise alors les processus de filtrage (analyse de la liste
des instances d’une classe) nécessaires à la mise en œuvre des
Delete class 〈 Nom-classe〉 ...
Add
requêtes.
Add
Delete method 〈 Nom-méthode〉 ... in class 〈 Nom-classe〉
Replace 5.1 Système O2
● opérations sur le corps des méthodes
O2 est un système orienté objets qui a été développé en France
— adjonction d’un corps de méthode :
par le Groupement d’Intérêt Public ALTAIR. Il est commercialisé
Body 〈Nom-méthode〉 in class 〈Nom-classe〉 ... [*] depuis le début de l’année 1991 par O2 Technology. Il reprend les
principaux concepts orientés objets ainsi que les fonctionnalités des
La déclaration Body est suivie, dans la partie [*], de l’identifiant systèmes de gestion de bases de données (gestion de mémoire auxi-
du langage utilisé pour spécifier le corps de la méthode, et des liaire, langage de requêtes). Son modèle de données autorise la
marqueurs de début et fin de spécification [cf. § 2.4 exemple spé- définition de types d’objets complexes à partir des constructeurs
cifiant le corps de la méthode INIT ( )] ; n-uplets, ensemble et liste. Il permet de définir et de manipuler des
— suppression d’un corps de méthode : objets (identifiés) et des valeurs (sans identifiant propre). Une classe
est définie par un type et une collection de méthodes permettant
Delete body 〈Nom-méthode〉 in class 〈Nom-classe〉
d’opérer sur les objets de la classe.
La spécification des méthodes est désynchronisée dans le temps Les classes sont organisées selon une hiérarchie d’héritage basée
par rapport à la spécification des classes, ce qui permet la mise en sur l’inclusion d’ensembles : les objets d’une sous-classe doivent
œuvre d’approches modulaires et incrémentales. Les vérifications nécessairement être inclus dans ceux de sa superclasse. Le
de cohérences associées au concept d’encapsulation sont réalisées mécanisme de surcharge est également supporté par O2. Le schéma
à l’aide de commandes demandant les éditions de liens. de la base étudiée dans le paragraphe 3.2 serait décrit partiellement
■ Gestion de versions : dans un contexte multi-utilisateur, tout comme suit :
changement de schéma a un impact sur les autres vues des usagers class EMPLOYÉS
de la base. Ainsi, chaque fois qu’il y a suppression d’un attribut d’une type tuple (MATRICULE : Integer,
classe par un usager, cela a un impact sur les associations NOM : String,
classe/sous-classes et la modification se répercute sur les usagers de PHOTO : Bitmap,
la classe et des sous-classes. La solution traditionnelle pour assurer APPARTENIR : SERVICES)
la cohérence des modifications a été de limiter les possibilités de method AGE (MATRICULE : Integer) Integer is
modifications aux administrateurs de la base ou de proposer le public ;
concept de vue. Mais il semble qu’une solution satisfaisante ne peut class INFORMATICIENS
être proposée qu’à travers le concept de versions (ou vues du
inherits EMPLOYÉS
schéma) où il est possible de disposer de plusieurs versions d’une
même classe. Les versions sont identifiées au moyen d’une type tuple (AFFECTER : set (PROJETS)) ;
estampille <id-version, date>. Ainsi une classe regroupe des instan- class SERVICES
ces rattachées aux différentes versions de schéma de classe spécifié. ...
Ce type d’approche a été expérimenté dans le contexte du prototype En matière de manipulation de données, O2 propose le langage
Orion. O2C (et aussi le langage BasicO2). Ainsi, les méthodes qui opèrent
■ Particularités : certains systèmes proposent le concept de sur les objets de la base sont écrites en O2C qui est une extension
méthodes / attributs exceptionnels qui se rattachent aux instances du langage C (précompilé). Par exemple, la méthode new permet
d’objets. On peut donc dans des cas particuliers disposer d’instances de créer des instances d’une classe. De plus, le système propose
conformes au modèle défini par la classe, mais avec, en plus, des une bibliothèque de méthodes permettant notamment l’affichage
compléments spécifiques. Un des problèmes délicats à maîtriser ou la destruction d’un objet. O2 offre également un langage de
reste par contre la migration d’objets (d’instances) d’une classe vers requête de type SQL appelé O2Query dont des exemples ont été
une autre classe. En effet, cette migration doit être réalisée en tenant présentés dans le paragraphe 3.3.
compte du fait que cette instance peut être référencée (hiérarchie de L’architecture du système O2 comporte un certain nombre de
composition) par n’importe quel autre objet de la base. Ainsi, si modules :
l’identifiant d’objet contient l’identifiant de la classe à laquelle il est — le gérant d’objets est chargé notamment de la gestion de la
rattaché, cette migration modifie l’identifiant, ce qui doit être mémoire virtuelle dans laquelle les objets sont référencés et de la
répercuté sur tous les objets qui référencent l’objet qui migre ; c’est communication avec le gestionnaire des fichiers sur disque ;
une opération coûteuse. — le gérant des schémas assure la gestion des définitions de
types et de méthodes ;
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
© Techniques de l’Ingénieur, traité Informatique H 3 840 − 11
BASES DE DONNÉES ORIENTÉES OBJETS ___________________________________________________________________________________________________
— le précompilateur O2C traduit le langage O2C en un code Cette requête retourne un ensemble d’identifiants d’objets ; les
exécutable en effectuant le contrôle des types ; instances sont obtenues seulement sur demande.
— l’interpréteur de requêtes assure la transformation des Les prototypes Orion ont été développés sur des machines Lisp
requêtes O2Query en O2C ; puis portés ensuite sur des stations de travail SUN. Leur architecture
— le générateur d’interfaces graphiques O2Look offre un comporte quatre modules principaux :
programmeur des primitives d’affichage des données sur écran ;
— le gérant de messages reçoit et analyse les messages envoyés
— l’environnement de programmation O2Tools assiste le
à Orion ;
programmeur pour le développement des applications ; il s’appuie
— le gérant d’objets assure la gestion des objets, la gestion des
sur O2Look pour la gestion des affichages.
schémas et la gestion des versions ;
O2 est actuellement disponible sur station de travail SUN. Il a été — le gérant de transactions garantit l’intégrité des objets lors des
écrit en langage C et C++. accès simultanés aux données et gère les procédures de reprise
après incident ;
— le système de stockage gère la mémoire disque en
5.2 Système Orion communiquant avec les fonctions de bas niveau du système
d’exploitation (allocation de pages, gestion d’index,...).
Orion est un prototype de SGBD orienté objets qui a été conçu
et développé dans le cadre d’un projet de quatre ans au Micro-
electronics and Computer Technology Corporation (MCC-USA). En
fait, trois prototypes successifs ont été réalisés. 6. Conclusion et perspectives
L’objectif d’Orion est de réaliser l’intégration du langage de
programmation objets Lisp et des fonctionnalités d’un SGBD. Orion
assure principalement la gestion des objets complexes, la gestion Bien qu’il n’existe pas une théorie simple et universelle comme
des transactions, la gestion des versions d’objets et l’évolution des pour le modèle relationnel, les concepts fondamentaux de
schémas. l’approche objet se retrouvent dans la plupart des modèles orientés
objets. D’ailleurs, malgré les limites du modèle relationnel face aux
Le modèle de données d’Orion supporte les concepts de classe, applications multimédia, certains concepts sont présents dans les
d’identité d’objet, de méthode et de message. Il permet également modèles de données orientés objets (notamment au niveau des
de définir des liens de composition et d’héritage entre classes. langages de requêtes).
Comme dans O2, il s’agit d’un héritage par inclusion de
sous-ensembles. Une méthode associée à une classe est une fonc- Actuellement, les bases de données orientées objets représentent
tion écrite en Lisp. un important domaine de recherche et de développement. Ainsi, des
études en cours sont menées en matière d’architecture et de
Orion accepte les attributs multivalués mais, contrairement au performances des systèmes pour offrir une gestion de mémoire et
système O2, il n’autorise pas la définition de types complexes une gestion des accès adaptées aux objets complexes, volumineux,
(n-uplets imbriqués). Autrement dit, en présence d’un objet partagés et évolutifs. D’autre part, l’utilisation d’un nouveau modèle
complexe, il convient de décomposer l’objet en classes reliées par de données suppose l’existence de méthodes de conception basées
des liens de composition. sur ce modèle. Or, il ne suffit pas de déclarer que l’approche orientée
L’exemple de schéma du paragraphe 3.2 serait décrit comme suit : objets permet de décrire les entités du monde réel de manière
(make class EMPLOYÉS naturelle ; les concepteurs ont besoin d’outils méthodologiques
: superclasses nil offrant richesse sémantique, formalisation et simplicité, tant au
: attributes ((MATRICULE : domain Integer) niveau conceptuel qu’au niveau de la mise en œuvre informatique
(implantation de la base sur un système orienté objets).
(NOM : domain String)
(APPARTENIR : domain SERVICES)) Malgré l’existence de quelques produits commerciaux (O2, Ontos,
: methods ((AGE))) Gemstone), les systèmes de gestion de bases de données orientées
objets n’ont pas atteint leur maturité. Cependant, l’évolution des
(make class INFORMATICIENS
entreprises vers ces systèmes de gestion de données semble
: superclasses (EMPLOYÉS) inévitable. En effet, les applications informatiques multimédia, qui
: attributes((AFFECTER : domain (set-of PROJETS)))) se multiplient dans le monde industriel, nécessitent des systèmes
(make class SERVICES) de programmation et de gestion de données fonctionnellement
... puissants, performants et fiables. Les systèmes orientés objets
peuvent donc offrir, dès à présent, des solutions intéressantes même
La manipulation des données dans Orion permet de créer, mettre si elles ne sont que partielles.
à jour et consulter les instances de classe par l’envoi de messages.
Par exemple, le message suivant, envoyé à la classe EMPLOYÉS,
permet d’obtenir les employés de nom Dupont :
(select EMPLOYÉS (NOM = ’Dupont’))
Références bibliographiques
[1] BAILLY (C.), CHALLINE (J.F.), FERRI (H.C.), Publishing Company Inc, ISBN 0-8053-0091-0 MANIFESTO. First International Conference
GLOESS (P.Y.) et MARCHESIN (B.). – Les (1991). on Deductive and Object Oriented Database -
langages orientés objets. Cepadues-Édition [5] KIM (W.). – Object oriented database : defini- Kyoto, déc. 1989.
(1987). tion and research directions. IEEE Transac- [8] CHRISMENT (C.). – Mise en œuvre de bases
[2] VIGNARD (P.). – Représentation de tions on Knowledge and Data Engineering. de données : principes méthodologiques.
connaissances : mécanismes d’exploitation et Vol 2, no 3, p. 327 à 341 - ISSN 1041-4347, Eyrolles - 2e édition, fév. 1990.
d’apprentissage. INRIA (1985). sept. 1990. [9] GARDARIN (G.) et VALDURIEZ (P.). – SGBD
[3] ALAGIC (S.). – Object-oriented database [6] STONE (C.W.) et HENTCHELL (D.). – Database avancés : bases de données objets,
programming. Springer Verlag-ISBN wars revisited. Byte, p. 233 à 242, oct. 1990. déductives, réparties. Eyrolles (1990).
0-387-96754-0, ISBN 3-540-96754-0 (1989). [7] ATKINSON (M.), BANCILHON (F.), DEWITT [10] O2 TECHNOLOGY. – The O2 manual, juil.
[4] BOOCH (G.). – Object oriented design with (D.), DITTRICH (K.), MALER (D.) et ZDONIK 1991.
applications. Benjamin/Cummings (D.). – The object-oriented database system
Toute reproduction sans autorisation du Centre français d’exploitation du droit de copie est strictement interdite.
H 3 840 − 12 © Techniques de l’Ingénieur, traité Informatique