Bases de Données Orientées Objets

Télécharger au format pdf ou txt
Télécharger au format pdf ou txt
Vous êtes sur la page 1sur 12

Bases de données orientées objets

par Claude CHRISMENT


Docteur ès Sciences
Professeur d’informatique à l’Université Toulouse III
Geneviève PUJOLLE
Maître de Conférences en informatique à l’Université Toulouse I
et Gilles ZURFLUH
Docteur ès Sciences
Professeur d’informatique à l’Université Toulouse I

1. Domaines d’application ......................................................................... H 3 840 - 2


1.1 Applications multimédia ............................................................................. — 2
1.2 Limites des systèmes relationnels ............................................................. — 2
1.3 Origine de l’approche objet ........................................................................ — 2
2. Concepts et modélisation...................................................................... — 3
2.1 Présentation informelle du modèle............................................................ — 3
2.2 Objets, types et classes ............................................................................... — 3
2.2.1 Identifiant d’un objet .......................................................................... — 3
2.2.2 Type d’un objet ................................................................................... — 4
2.2.3 Classes................................................................................................. — 4
2.3 Liens d’héritage et de composition............................................................ — 5
2.4 Surcharge ..................................................................................................... — 5
2.5 Encapsulation............................................................................................... — 7
2.6 Messages...................................................................................................... — 8
3. Interfaces ................................................................................................... — 8
3.1 Envoi de messages...................................................................................... — 9
3.2 Schéma des objets ...................................................................................... — 9
3.3 Requêtes....................................................................................................... — 9
4. Évolutions de schémas........................................................................... — 10
5. Systèmes orientés objets : deux exemples ...................................... — 11
5.1 Système O2 .................................................................................................. — 11
5.2 Système Orion ............................................................................................. — 12
6. Conclusion et perspectives................................................................... — 12
Références bibliographiques ......................................................................... — 12

et article présente les concepts orientés objets tels qu’on les utilise dans
C
6 - 1992

le domaine des bases de données, et tente de mettre en évidence l’intérêt


de ces concepts pour la modélisation et la manipulation des objets complexes.
H 3 840

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 ___________________________________________________________________________________________________

1. Domaines d’application De plus, la théorie relationnelle ne supporte pas le concept


d’identité d’objet ; elle est « orientée valeur » dans le sens où un objet
relationnel, un n-uplet, ne peut exister indépendamment de sa
La communauté informatique fonde beaucoup d’espoir sur valeur. Ainsi, un n-uplet ne peut être référencé que par la valeur de
l’approche orientée objets pour développer des logiciels complexes sa clé primaire.
dans les domaines du génie logiciel, de l’intelligence artificielle et D’une part, les SGBDR proposent une gestion de transactions
des bases de données. Bien que cette approche relève encore de courtes inadaptée aux applications multimédia. Ces transactions
la recherche, plusieurs systèmes commerciaux sont apparus sur le sont écrites dans un langage procédural (Fortran, Cobol, Ada, C...)
marché ces dernières années. Pourtant, la notion d’objets est parfois et accèdent à la base de données via un langage déclaratif propre
interprétée différemment selon le domaine auquel on s’intéresse [5]. au SGBDR (SQL principalement) ; cette dualité procédural/déclaratif
Dans cet article, nous essaierons de définir les concepts essentiels nuit à l’efficacité du fonctionnement de l’application.
de l’approche orientée objets et la façon dont ils sont utilisés pour
mettre en œuvre une base de données.
Avec les langages de programmation objets, l’utilisateur dispose
de puissantes capacités de description et de manipulation de 1.3 Origine de l’approche objet
données [1]. Mais, dans ces langages, les données résident dans la
mémoire principale de l’ordinateur et disparaissent avec le pro-
cessus qui les a créées. Or, de nouvelles applications, dites multi- L’intérêt croissant pour l’approche objet vient certainement de sa
média parce qu’elles mixent textes, images et graphiques, ont besoin capacité à décrire les objets du monde réel et à les gérer sous une
de données permanentes qui sont stockées dans des bases de forme « naturelle » en termes informatiques. On attend donc de l’uti-
données pouvant atteindre plusieurs milliards d’octets. lisation des concepts orientés objets un gain sensible de productivité
dans le développement et la maintenance des applications.
Il faut chercher l’origine des bases de données orientées objets
dans les domaines du génie logiciel et de l’intelligence artificielle.
1.1 Applications multimédia
En effet, les concepts d’objets, de classes, d’héritage, de messages
Les applications de l’informatique dite classique (calcul sont utilisés depuis plusieurs années dans les langages de program-
numérique, gestion de production, gestion commerciale...) traitent mation tels que Simula, Smalltalk et Eiffel [1]. Par exemple, les
principalement des données de type numérique ou chaîne de carac- langages Simula et Smalltalk datent respectivement de 1967 et 1972 ;
tères. L’accroissement de la puissance des ordinateurs, allié à la plus récemment, des extensions orientées objets ont été apportées
vulgarisation de l’informatique dans les entreprises, a permis le à des langages existants, notamment C++, Objective C et Common
développement de nouvelles applications qui gèrent d’autres types Lisp Objet System.
de données ; parmi ces applications, on peut citer la bureautique, Le concept d’objet est aussi apparu très tôt en intelligence artifi-
la CAO, l’EAO, la robotique, l’imagerie médicale,... Ces applications cielle où des connaissances peuvent être représentées par des
sont dites multimédia parce qu’elles ont besoin de traiter et de stoc- objets. Ainsi, la représentation sous forme de « frames » proposée
ker des données volumineuses et multitypes (textes longs, images par Minsky en 1975 est un formalisme précurseur en la matière [2].
numérisées, graphiques) qui peuvent présenter une structure Dans le domaine des bases de données, les concepts orientés
hiérarchique profonde (documents, cartes, schémas). Elles posent objets sont apparus dans les travaux relatifs aux modèles
en outre des problèmes, résolus en informatique classique, mais qui sémantiques, c’est-à-dire aux modèles dont l’objectif est de décrire
prennent ici une toute autre dimension ; par exemple : la réalité le plus fidèlement possible. Des extensions du modèle rela-
— le contrôle des accès concurrents aux objets ; tionnel ont été proposées avec notamment le modèle RM/ T de Codd
— la gestion des transactions longues ; en 1979 et le modèle NF2 (Non First Normal Form) du Centre IBM
— la gestion de l’évolution des gros objets (versions). à Heidelberg (Allemagne) en 1982. Cependant, ces modèles ne
On emploie généralement le terme « objet complexe » pour supportent que certains concepts : l’identité d’objets et les structures
désigner les données manipulées par les applications multimédia. complexes principalement.
Actuellement, les prototypes de recherche et les systèmes
commercialisés (O2, Orion, Ontos,...) supportent les concepts
1.2 Limites des systèmes relationnels essentiels de l’approche orientée objets : objet, classe, héritage,
message.
Les Systèmes de Gestion de Bases de Données Relationnels Cependant, si un certain consensus se dégage sur les concepts
(SGBDR), qui sont apparus à la fin des années 70, sont bien adaptés que doivent posséder modèles et systèmes, la communauté infor-
à la gestion des applications traditionnelles. Actuellement, ces matique n’est pas toujours d’accord sur l’interprétation de ces dif-
systèmes (Oracle, DataBase2, Ingres, Informix,...) connaissent un férents concepts. Cette situation provient certainement de la
succès remarquable auprès des entreprises et cela tant sur gros diversité des champs d’application (génie logiciel, intelligence
ordinateurs que sur micro-ordinateurs. Ils supplantent progres- artificielle, base de données,...) qui a naturellement entraîné une
sivement tous les autres systèmes de gestion de données grâce à diversité des préoccupations (modularité, richesse et évolution des
la simplicité du modèle de données et à la puissance des langages structures de données,...).
qu’ils proposent (cf. article Langages de bases de données : SQL et Cette présentation se situe dans le domaine des bases de données
les évolutions vers l’objet [H 3 128], dans ce traité). Dans le modèle et plus précisément dans celui de la modélisation des objets
relationnel, les données atomiques (nombres, chaînes de complexes. Ces objets, qui sont généralement volumineux et ont une
caractères,...) sont agrégées en n-uplets qui sont eux-mêmes structure hiérarchique profonde, doivent être stockés de façon per-
regroupés en relations. Ce modèle impose des contraintes stru- manente en mémoire auxiliaire (magnétique ou optique). Dans cet
cturelles, appelées règles de normalisation, pour éliminer les article, nous définissons les principaux concepts orientés objets au
redondances de données. Ces contraintes (notamment la première travers d’un modèle mettant en lumière l’importance de ces concepts
forme normale) conduisent le concepteur de la base de données à pour modéliser les données. Les interfaces de gestion de données
décomposer un objet (complexe) en un ensemble de relations. Cela mises en œuvre soit par un programme d’application, soit directe-
entraîne très souvent une perte sémantique dans la notion d’objet ment par l’utilisateur utilisent les spécificités de ce modèle.
et conduit à réaliser des opérations coûteuses pour reconstituer
l’objet initial (opérations de jointure notamment).

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.

Figure 1 – Création de la classe EMPLOYÉS


2.1 Présentation informelle du modèle

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 ___________________________________________________________________________________________________

2.2.2 Type d’un objet ■ Attributs


Les attributs d’un objet, qui apparaissent dans sa structure de
Un objet est soit atomique, soit constitué d’autres objets. Dans données, sont associés à des domaines de valeurs. Le domaine
ce dernier cas, l’objet référence d’autres objets, traduisant ainsi des d’un attribut est une classe primitive ou non.
associations entre entités ; l’objet est alors un n-uplet constitué des Pour reprendre la terminologie des bases de données, une classe
identifiants qui référencent les objets qui lui sont associés. Sur le d’objets est définie par un schéma. Lorsque ce schéma comporte
principe, cette notion de référence par identifiant d’objet peut être des attributs, chacun d’eux est associé à une classe primitive ou
rapprochée de la notion de pointeur qui autorisait une manipulation complexe : il s’agit du domaine de l’attribut.
navigationnelle des données dans les SGBD réseaux. Cependant, la
comparaison avec ces systèmes s’arrête là dans la mesure où les Par exemple, le schéma de la classe EMPLOYÉS pourrait être défini
systèmes orientés objets offrent des possibilités d’interrogation comme suit :
beaucoup plus puissantes grâce aux langages ensemblistes. classe EMPLOYÉS
Plus formellement, un objet est un couple constitué d’un identifiant structure [MATRICULE : Integer ;
et d’une valeur primitive ou complexe. Il peut être défini comme suit : NOM : String ;
— un objet O est primitif si sa valeur est définie par un type AGE : Integer ;
atomique : un entier, une chaîne de caractères, mais aussi un texte APPARTENIR : SERVICES]
(sans structure) ou une image ; Les domaines des attributs de la classe EMPLOYÉS sont respecti-
— un objet O est complexe : vement :
• si c’est un ensemble de la forme O = {O1 , O2 , ..., On} où O1 , — les classes primitives (Integer, Real et String) prédéfinies dans
O2 , ..., On sont des objets, notre modèle ;
• si c’est un n-uplet de la forme O = [A1 : O1, A2 : O2, ..., Ap : Op] — la classe complexe SERVICES définie par ailleurs.
où A1, A2, ..., Ap sont des noms d’attributs distincts et O1, O2, ...,
Op sont des objets. En fait, le concept de domaine est particulièrement puissant
puisqu’il permet à la fois :
Cette définition est récursive ; autrement dit, pour définir un objet,
on peut faire successivement appel à une même définition. Par — d’associer une définition à un attribut en termes de structure
exemple, dans un n-uplet, l’un des attributs peut lui-même être défini de données et de comportement ;
comme un n-uplet. — de désigner un ensemble fini d’objets comme valeurs possibles
de l’attribut.
Exemple d’objets où Xi représente l’identifiant interne : Ainsi, l’attribut APPARTENIR, qui bénéficie du type de la classe
— objets primitifs : (X1 , 186), (X2 , 524), SERVICES, ne peut prendre pour valeur que l’un des objets
(X3 , ’Dupont’), (X 4 , ’Martin’) ; contenus dans cette même classe.
— objets complexes : (X5 , [MATRICULE : X1, NOM : X3])
Au travers de cet exemple, on voit que la notion de domaine définit
(X6 , [MATRICULE : X2 , NOM : X4])
un lien formel entre des classes (en l’occurrence EMPLOYÉS et
(X7 , {X5 , X6}).
SERVICES), que l’on appelle une contrainte d’intégrité référentielle
L’objet X1 est de type entier alors que l’objet X6 est un n-uplet et dans le modèle relationnel (liens sémantiques entre n-uplets).
l’objet X7 est un ensemble de n-uplets.
■ Méthodes
Comme dans les langages de programmation récents (Ada
notamment), un type de données abstrait permet de définir des Les méthodes permettent de décrire les aspects dynamiques d’un
objets (variables) en termes de structure de données (attributs) et objet, c’est-à-dire son comportement. Une méthode peut être vue
de méthodes (opérateurs) ; par exemple, le type String définit la comme une procédure (ou fonction) qui agit sur l’état de l’objet.
forme des chaînes de caractères et les opérateurs qui leur sont ■ Description d’une classe
applicables (concaténation, extraction,...). Cette définition est
Une classe est décrite à l’aide d’une liste d’attributs et d’une liste
« encapsulée » de telle manière que l’utilisateur n’ait accès qu’à la
de méthodes sauf pour les classes primitives qui sont prédéfinies
partie conceptuelle de la définition appelée interface abstraite (le
(figure 2).
code des méthodes notamment n’est pas visible) (§ 2.5).
Dans un modèle orienté objets, on appelle type de l’objet cette À chaque classe sont généralement associées les méthodes :
interface qui définit conceptuellement l’ensemble des méthodes a ) créer ;
associées à l’objet, c’est-à-dire le nom de la méthode et le type des b ) sélectionner ;
paramètres. Par exemple, dans le type String, la méthode de c ) supprimer ;
concaténation notée + a pour paramètre une chaîne de caractères d ) modifier.
et produit une nouvelle chaîne de caractères. Cette chaîne est
obtenue en concaténant le paramètre à l’objet auquel est appliquée La méthode a ) permet la création des instances. La méthode b )
la méthode. permet la localisation des instances répondant à un filtre de sélection
autrement que par une analyse séquentielle systématique. La fonc-
tion de suppression c ) ne se justifie qu’avec des classes persistantes.
2.2.3 Classes La fonction d ) correspond en fait à une liste de méthodes spécialisées
selon les attributs dont on veut modifier la valeur.
Les objets qui partagent les mêmes attributs et méthodes se Si un objet est une instance de classe et si une classe peut être
regroupent en classes. Instancier une classe correspond à créer, dans vue comme un objet, on peut définir une classe de classes
cette classe, un nouvel objet appelé instance. (MÉTACLASSE). Toute métaclasse pouvant à son tour être
considérée comme un objet, on peut définir des classes de
Une classe regroupe un ensemble d’objets définis selon un
métaclasses et ainsi de suite. Il s’agit d’une définition récursive, mais,
même type ; les objets de la classe ont donc la même structure de
dans la plupart des systèmes, le niveau « méta » est limité : une
données et le même comportement. Une classe est décrite à la fois
classe système prédéfinie est la classe des classes.
au niveau conceptuel (type) et au niveau interne (corps des
méthodes). D’autre part, les domaines des attributs pouvant être des classes
avec leurs propres attributs, la définition complète d’une classe est
élaborée en considérant le graphe des classes enraciné par cette
classe.

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

Figure 2 – Description de la classe EMPLOYÉS

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 ___________________________________________________________________________________________________

Figure 3 – Description de la classe PRODUIT avec introduction des concepts de hiérarchie

Figure 4 – Graphe d’héritage de la classe EMPLOYÉS


Figure 5 – Graphe de composition des classes

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

■ Sous-classe 2 : Spécification du langage utilisé pour décrire le corps de la


a ) Class EMPLOYÉS Inherits PERSONNES méthode : il s’agit ici du langage C dans lequel apparaissent des
primitives O2.
b ) Type Tuple Redefines TEL : Tuple (NOPOSTE Integer),
3, 5, 7 : Commentaires.
FONCTION : String,
SALAIRE : Real) 4 : Message demandant l’initialisation de l’objet en cours de
création au niveau générique ; SELF est un mot réservé désignant
c ) Method MAJ-SALAIRE ()... l’objet en cours de création ; PERSONNES∂INIT : est le nom de la
INIT () : EMPLOYÉS ; méthode (INIT) attachée à l’objet PERSONNES.
a) associe une classe à sa superclasse ; 6 : Initialisation de l’attribut SALAIRE de l’objet en cours de
b ) permet de redéfinir un attribut ; on ajoute un attribut création (SELF). Cette initialisation se fait par saisie d’un nombre réel
complémentaire NOPOSTE à l’attribut TEL (INDICATIF, NUMÉRO) au clavier contrôlée par la procédure Input.
de la classe générique ; 8 : Adjonction de l’instance créée à l’ensemble des instances.
c ) la méthode d’initialisation/création d’instance INIT au niveau 9 : Restitution par la méthode de l’identifiant de l’objet créé.
de la sous-classe est un raffinement de la méthode INIT de la super- 10 : Fin de la description du corps de la méthode.
classe.
De manière générale, ce sont les types des paramètres qui
Le raffinement de la méthode INIT (surcharge) se fait en réutilisant indiquent au système, lors de l’activation d’une méthode, celle qu’il
le corps de la méthode définie au niveau de la superclasse : (0) doit choisir. Ces types n’étant connus qu’au moment de l’appel de
la méthode (juste avant son exécution), on parle d’assignation
1 Body INIT ( ) : EMPLOYÉS in Class EMPLOYÉS tardive : il n’est pas possible dans une phase de compilation
2 CO2 { préalable de déterminer dans les opérations d’appel, parmi les
méthodes portant le même nom, celle qui sera effectivement activée.
3 /*Initialisation des attributs au niveau
générique*/
4 [SELF PERSONNES∂INIT]
 5 /*Initialisation des attributs au 2.5 Encapsulation
S  niveau spécifique*/
 ,
U  , Un objet encapsule son état et son comportement. Il en résulte
R  , deux niveaux de perception :

C  6 SELF → SALAIRE = Input (02 real) ; — le niveau spécification ;
 , — le niveau implantation.
H  ,
 , ■ Le niveau spécification correspond à la partie visible de l’objet
A 
R  7 /*Mémorisation de l’objet*/ (figure 6).

G  8 EMPLOYÉS + = Set (SELF), ■ Le niveau implantation correspond à la partie cachée ou interne :
 9 RETURN (SELF) il est local à l’objet et est sous la responsabilité de son créateur
E  (figure 7).
 10 } ;
Au niveau implantation, on peut manipuler les données et
méthodes du niveau spécification (implicite). On dispose d’attributs
et de méthodes complémentaires qui peuvent être rajoutés par le
1 : Déclaration indiquant que l’on décrit le corps de la méthode créateur de l’objet. Généralement, le corps des méthodes est spécifié
INIT ( )... rattachée à la classe EMPLOYÉS. Il y a par ailleurs au niveau implantation et seule la signature est visible au niveau
description de INIT ( ) rattachée à PERSONNES. spécification.
Le concept d’encapsulation se schématise alors sur la figure 8.

Figure 6 – Niveau spécification


de la classe EMPLOYÉS

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 ___________________________________________________________________________________________________

Figure 7 – Niveau implantation


de la classe EMPLOYÉS

La structure d’un message est la suivante :


(SÉLECTEUR OBJET PARAMÈTRES)
〈nom méthode〉 〈receveur〉 〈paramètres effectifs
de la méthode〉
Ainsi, pour provoquer une augmentation de salaire de 250 F de
l’employé ’1702’, l’utilisateur de la base élabore au terminal un mes-
sage destiné à l’objet EMPLOYÉS avec la syntaxe suivante :
(AUGMENTER-SALAIRE EMPLOYÉS (1702,250))
Les messages sont généralement associés aux classes d’utili-
sateurs autorisés à les manipuler, ce qui permet de mettre en œuvre
le concept de sous-schéma à travers les méthodes.
Figure 8 – Principe d’encapsulation d’un objet

Les principaux intérêts de l’encapsulation sont les suivants :


3. Interfaces
— la modularité : l’unité d’encapsulation est l’objet ;
— le concept d’abstraction qui permet la dissimulation des Dans les bases de données relationnelles, l’accès aux données est
détails d’implémentation des objets, détails souvent sans impor- réalisé grâce à un langage ensembliste, généralement de type SQL.
tance pour les utilisateurs de l’objet. On dissocie ainsi l’interface de Les programmeurs doivent donc insérer des requêtes SQL dans leurs
l’objet par rapport à sa partie interne ; programmes d’application. Ils utilisent (et apprennent) deux forma-
— la conception incrémentale : possible sur deux plans ortho- lismes distincts, mais aussi établissent un couplage entre deux
gonaux (spécification, implémentation) ; en effet, on peut définir de langages dont les modes de fonctionnement sont différents : le mode
nouvelles spécifications sans que toutes les implémentations soient ensembliste (SQL) et le mode procédural (programme hôte). Cette
connues. situation nuit non seulement au développement et à la maintenance
Les spécifications doivent être cohérentes entre elles. Cette cohé- des programmes, mais aussi aux performances de l’application.
rence se vérifie au moyen d’une compilation des spécifications. Dans l’approche orientée objets, les langages objets existants sont
Les implémentations doivent être cohérentes individuellement par souvent étendus pour intégrer, sous forme de méthodes, des primi-
rapport à la spécification à laquelle elles se rattachent. tives de manipulation de bases de données. C’est notamment le cas
dans le système Gemstone avec le langage Smalltalk et dans le
système Orion avec le langage Common Lisp. Cela confère à l’appli-
cation une bonne homogénéité des divers traitements qu’elle
2.6 Messages comporte.
Nous avons vu que, dans une base de données orientée objets,
L’activation d’une méthode (réalisation d’une action) est liée à la les objets disposent de méthodes capables de manipuler leur état ;
réception d’un message par un objet. Ainsi, les objets communiquent ces méthodes sont déclenchées par des requêtes externes (appelées
entre eux à travers des messages qu’ils peuvent recevoir ou émettre. messages). Cette façon de procéder est le seul moyen d’activer des
opérations sur les objets et donc de réaliser des traitements.

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

3.1 Envoi de messages 3.2 Schéma des 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.

Figure 9 – Schéma d’une base de données dans une entreprise

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.

■ Adjonction/suppression d’attributs (évolution structurelle d’une


classe) : cette modification peut être prise en compte avec le
mécanisme d’héritage et est mise en œuvre à travers le concept de 5. Systèmes orientés objets :
sous-typage.
deux exemples
■ Spécification des méthodes : au niveau des méthodes on
distingue les opérations concernant soit leur déclaration, soit leur
corps ; Dans cette section, nous présentons brièvement deux exemples
● opérations sur les déclarations de systèmes orientés objets qui nous paraissent représentatifs : le
système français O2 et le système Orion développé aux États-Unis.

 
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

Vous aimerez peut-être aussi