DOSSIER omment stocker les objets

DOSSIER
omment stocker les objets ?
par Philippe BRIDON, membre du Cercle Objet du Club Génie Logiciel de la SEE
Mots-clés :
Orienté-objet,
Relationnel-
objet,
Persistance,
SGBD.
Le développement croissant des
techniques orientées objet conduisent de
nombreux projets à utiliser une analyse
et une conception orientées objet suivie
d'une implémentation avec un langage
orienté objet comme C++ ou Java [1
Pour certaines applications, il est
nécessaire d'assurer la persistance des
données et donc dans ce cas des objets.
Or les techniques de stockage pour les
objets sont multiples et en pleine
évolution.
PROBLÉMATIQUE
Les besoins de persistance de données dans une applica-
tion sont divers :
- conserver une trace des données entre deux sessions,
- assurer la sécurité et la fiabilité des données en cas d'in-
cident au cours d'une session,
- partager des données entre plusieurs utilisateurs ou
applications.
La persistance des informations est relativement maîtri-
sée pour des techniques dites " classiques " (modèles
entité/relation ou Merise, codage en C ou Cobol...). Dans le
domaine orienté objet, la jeunesse de la technologie induit
encore quelques tâtonnements. Les structures de données
plus complexes du modèle objet (objets composites, réfé-
rences, héritage...) nécessitent des approches de stockage
adaptées : verrouillage sur les objets, requêtes navigation-
nelles, indexation sur les instances de sous-classes...
La solution idéale semble l'emploi de systèmes de ges-
tion de bases de données (SGBD) orientés objet. Mais les
produits sont jeunes, le marché en forte évolution et les
standards émergeants. Utiliser des solutions éprouvées peut
sembler plus rassurant dans une logique industrielle (péren-
nité des acteurs et standards) mais leurs paradigmes peu-
vent imposer des contraintes de conception et de réalisa-
tion. D'autres solutions plus simples ou innovantes sont
également disponibles sur le marché. Si l'on tient compte
de l'ensemble des critères (adéquation du modèle objet à la
technique de stockage, productivité en développement, per-
formances en exécution, pérennité...) chaque solution a ses
avantages et ses inconvénients.
'se
Avec l'essor de la technologie objet pour l'analyse
et la conception se pose le problème de la persis-
tance des applications écrites en objet (C++,
Java...).
Plusieurs techniques sont disponibles avec les
SGBD objet, les plus adaptés, les SGBD relation-
nels-objet, récemment apparus, et les couplages à
des SGBD relationnels ou des systèmes de fichiers.
Mais l'offre technique et les produits évoluent rapi-
dement. Le choix n'est donc pas simple et doit tenir
compte non seulement d'aspects technologiques
mais également industriels (productivité, exploita-
tion, pérennité du fournisseur...). Sans oublier de
se poser la question : désire-t-on concevoir un sys-
tème d'information ou une application persistante.
With the success of the object-oriented technology
for analysis and design, comes the problem of
making persistent applications, written in object
(C++, Java).
Several techniques are available such as object
DBMS, the more suitable, relational-object DBMS,
recently appeared, and gateway to relational
DBMS and file management systems.
But the technical offer and the products change
quickly. Thus, the choice is not easy and must
include technological requirements and also indus-
trial strengths (productivity, administration, trust in
future of the provider...). Without forgotten, the
right question to wonder : do we want designing
an information system or a persistent application ?
QUELQUES SOLUTIONS
Cinq solutions majeures permettent de stocker les objets
définis dans une application conçue et implémentée avec
des techniques objet (figure 1). Ces solutions sont présen-
tées selon une adéquation décroissante à la technologie
objet, soit depuis l'utilisation d'une base de données objet
jusqu'à un stockage " maison " dans des fichiers. Cet ordre
fait donc apparaître une croissance de la gestion des don-
nées dans la partie applicative, la solution avec SGBD objet
tendant à rendre transparente la persistance des objets.
REE
NI 6
juin 1998 i 73

LE GÉNIE LOGICIEL : LES CONCEPTS
Tout objet
La voie royale est bien entendu le SGBD objet dont le
principe... est de rendre persistant les objets (ObjectStore
d'Object Design, 02 d'02 Technology, devenu après fusion
Ardent Software...). Les SGBD objet réunissent les caracté-
ristiques connues des SGBD (gestion de la concurrence,
gestion des accès et échanges, sécurité, fiabilité...) mais
selon un paradigme de stockage objet (structures com-
plexes, héritage, identité d'objet...) [2]. L'objectif est d'of-
frir une persistance transparente, c'est-à-dire qu'hormis les
déclarations de création des objets et la gestion des transac-
tions, la programmation est rigoureusement la même.
L'avantage évident est de supprimer la frontière entre les
manipulations des données dans le programme et dans la
base de données ( " impedance mismatch ") et les contorsions
entre par exemple le monde C et le monde SQL.
Autre avantage, la conception de la base de données est
directement issue du modèle objet de conception de l'appli-
cation. Ce sont les classes " marquées " persistantes dans le
modèle. Non seulement, il n'est pas nécessaire de mener
une étude de conception de l'application en parallèle de la
modélisation conceptuelle de ses données (MCD), mais les
objets sont les mêmes.
Dernier avantage, ces SGBD objet ayant l'objet même
pour paradigme de stockage, il leur est aisé de faire des
recherches par objet (identifiant unique), de les regrouper
sur disque par classes d'objet ou bien par composé et ses
composants. Toutes les applications de XAO notamment
où les requêtes sont essentiellement navigationnelles (pas-
ser d'un objet à un de ses composants ou associés, suivre
des références...) deviennent très performantes. En effet,
dans ce cas, un SGBD objet se contente de faire du par-
cours de pointeur, tandis qu'un SGBD relationnel peine sur
des jointures multiples.
Mais, comme toute industrie naissante, les SGBD objet
représentent encore pour beaucoup de décideurs un risque
industriel majeur : nombreuses start-up, sans leader appa-
rent, standard récent encore partiellement appliqué
(ODMG) [3]. En outre, pour les sociétés, qui viennent à
peine de faire la migration vers le relationnel et le langage
de requête SQL, se former à un nouveau standard apparaît
comme trop coûteux. En outre, la plupart de ces produits
sont encore jeunes (fonctionnalités stabilisées, fiabilité...),
et restent faibles sur les aspects exploitation et tenue en
charge (transactionnel lourd, haute disponibilité, support
d'architectures distribuées complexes).
D'autre part, il faut noter que les performances ne sont
pas toujours au rendez-vous. En effet, sur certains
domaines applicatifs, les requêtes ensemblistes sont au
contraire les plus répandues. Or les SGBD objet n'ont pas
encore acquis la maturité des SGBD relationnels sur ce
point. Ces derniers permettent d'optimiser les requêtes et
de faire des traitements sur le serveur (procédures stoc-
kées) qui permettent de limiter le flux des informations
entre le serveur et le client. Par exemple, augmenter de
10% tous les employés avec un SGBD objet, nécessite de
charger chaque instance d'employé sur le poste de travail
client, pour y calculer son nouveau salaire, puis de restoc-
ker sur le serveur la nouvelle valeur. Le gain de la techno-
logie objet sur le parcours navigationnel est ici perdu dans
des flux de données trop importants sur le réseau. Bien
entendu, la plupart des vendeurs de SGBD objet se pen-
chent sur la possibilité de faire exécuter des traitements sur
le serveur ( " load balancing ") et de faire des indexations et
optimiseurs de requêtes adaptés au modèle objet (ex : 02).
Mais peut-être qu'un des grands désavantages des SGBD
objet provient justement de leur argument de vente, la
transparence de la persistance. Le risque méthodologique
est en effet de concevoir des applications persistantes au
Tout Objet
ob » te
.4
Relationnel-Objet
1 Obiab
om
f » gr*mme C*+
Conversion
Obl « a
Pmomnxn* C+*
1 , Rbqub* SOL,
mômis ft*lationrittj) Mt) « t) e) at) ont'
Encapsulation
Objet
1'om4m
om
Me'tteMawM).
111 eoqt " sç.,
Fichiers
PtaaNtWfMC
jiï4uae SOL3 Rbqub* SOL iibwo.
fumaffla
Imm
*bd 1
nn u oj
r'._> : :'3 e _3 e JB c
Objets ObjetsrTables Tables Fichiers Fchiers
SGBDO SGBDRO SGBDR SGBDR SGF
1. Cing techniques de stockage d'objets.
REE
'-'NI 6
74 Juin 1998

Comment stocker les objets ?
lieu d'applications exploitant une base de données. Il faut
rappeler que la démarche système d'information et SGBD
a justement pour intérêt d'isoler la connaissance/les infor-
mations de l'Entreprise des applicatifs qui les exploitent et
qui sont souvent moins stables et pérennes. La transparen-
ce apportée par les SGBD objets nuit parfois à la réflexion
sur la modélisation des applications, à l'identification des
objets du domaine, persistants, et ceux des applicatifs,
transcients. Alors que le marketing objet argumente sur la
réutilisation, on peut se demander dans certains systèmes
objets si la base de données est effectivement partageable
(réutilisable) par de nouvelles applications.
Objet-Relationnel
Intermédiaire entre le modèle relationnel et le " pur objet ",
une nouvelle gamme de SGBD perce actuellement sur le
marché. Qualifiés de serveurs d'objets complexes, de rela-
tionnels étendus ou d'objet-relationnels (Informix Dynamic
Server d'Informix après rachat d'Illustra, UniSQL/X
d'UniSQL), ces SGBD proposent d'étendre l'approche rela-
tionnelle et donc le langage SQL pour la manipulation des
données complexes. L'idée est de pouvoir manipuler de nou-
veaux types de données (abstract data type), avec leurs pro-
cédures adaptées de sélection, indexation et manipulation
(DataBlade d'Illustra) et des extensions au langage SQL
comme l'héritage, les valeurs multivaluées et les types de
données abstraits avec attachement de procédures associées.
Cette offre est poussée par les vendeurs de SGBD relation-
nels qui veulent adapter leurs serveurs aux applications mul-
timedia (serveurs web, imagerie, SIG, VOD...).
L'intérêt est d'être facilement pris en main par des admi-
nistrateurs de bases de données généralement formés à
SQL et d'avoir des performances élevées grâce au savoir-
faire acquis dans la réalisation de serveurs pour SQL (opti-
miseur de requêtes, cluster, techniques d'indexation, traite-
ments sur le serveur...). Un autre avantage est de pouvoir
fédérer facilement des SGBD objet-relationnels avec des
SGBD relationnels existants ( " legacy system ") à travers
l'usage commun du langage SQL. La passerelle fédératrice
(ex : UniSQL/M) se charge d'analyser les objets complexes
et d'éclater les requêtes selon nécessité sur les différents
serveurs de stockage.
Côté désavantage, tout comme les SBGD objet, les
SGBD objet-relationnels sont très récents. La pérennité de
ces start-up n'est pas assurée aujourd'hui. Quelle est en
outre la pérennité de ces vendeurs entre les SGBD objet
qui ne tarderont pas à s'affirmer comme des produits com-
plets et fiables et les fournisseurs majeurs de SGBD rela-
tionnels actuels qui font évoluer leurs noyaux (Sybase
Adaptive Server, Oracle V8...) ou achètent la technologie
(déjà fait par Informix avec Illustra) ? De plus, quoiqu'en
dise le marketing, ces produits avant-gardistes sont encore
en dehors de tout standard, puisqu'ils proposent des exten-
sions à SQL qui seront standardisées au mieux dans SQL 3
(en 1998 ou 1999 ?) [4].
Conversion
Cette approche et la suivante reposent sur une solution
où la conception/programmation objet a été retenue, mais
un SGBD relationnel a été préféré pour stocker les infor-
mations. Compte tenu que le modèle relationnel est moins
riche que le modèle objet, il est nécessaire de convertir le
modèle objet, de " l'aplatir " dans un modèle tabulaire. Bien
entendu, l'objectif est de réaliser le couplage entre l'appli-
cation objet et le SGBD relationnel de la façon la moins
douloureuse en conception et la plus efficace en exécution.
Des outils de conversion objet/relationnel apparaissent
sur le marché. Le principe est de marquer dans un modèle
de conception orienté objet, les classes que l'on désire faire
persister, puis de générer le schéma de base de données
relationnel correspondant. Ces convertisseurs s'appuient
sur des règles génériques de transformation de liens
sémantiques (héritage, agrégation, association l : n ou
n : m...) en tables relationnelles [5]. Il existe des outils indé-
pendants comme Persistence de Persistence ou bien des
générateurs inclus dans des ateliers de conception tels
qu'Objecteering de Softeam.
L'avantage est de convertir automatiquement le modèle de
conception objet en un modèle relationnel. Ainsi, si le stoc-
kage profite des avantages des produits relationnels (péren-
nité, maturité, fiabilité...), la conception de l'application et
du modèle de données demeurent dans le monde objet et il
n'y a pas de conception séparée de la base de données.
Le désavantage principal est de ne pas être maître/
conscient du modèle conceptuel et surtout physique de la
base relationnelle. Or les règles de conversion sont souvent
trop génériques pour être systématiquement applicables et
les outils incomplets (certains cas d'association sont mal
couverts). Si l'on désire optimiser les performances, il
devient alors nécessaire de se pencher sur le modèle rela-
tionnel généré ou de biaiser la conception objet initiale
pour que les classes persistantes soient générées vers un
modèle relationnel efficace. Le second désavantage, lié à
l'utilisation d'un SGBD relationnel, est que les perfor-
mances sur des accès navigationnels, courants dans des
applications objet, resteront faibles (jointure de tables vs
parcours de pointeurs).
Encapsulation
Une alternative moins automatisée est de distinguer la
conception (objet) de l'application et celle (relationnelle)
de la base de données. Comme une application classique
en C ou Cobol, l'application doit charger ses propres
variables avec des informations extraites de la base de don-
nées. L'intégration se contente d'être une encapsulation
" objet " de la base de données, notamment pour sa manipu-
lation afin d'intégrer plus facilement les échanges avec le
SGBD dans le code orienté objet. Plusieurs bibliothèques
existent sur le marché (RogueWave DBtools.h++, Ilog
DBlink), avec souvent l'avantage d'offrir une indépendance
par rapport au produit relationnel utilisé.
REE
6 i : i
.,,,6 1
i.. 1998Jmnl998

LE GÉNIE LOGICIEL : LES CONCEPTS
L'avantage que l'on peut reconnaître à cette solution, est
de s'appuyer sur un SGBD relationnel, dans la mesure où
l'on ne désire pas prendre le risque des technologies objet
ou relationnel-objet. Par contre, les données manipulées et
stockées restent dans un monde non objet, et se pose le
problème des performances pour des requêtes navigation-
nelles à travers les objets.
Autre avantage, c'est probablement la solution la plus
viable pour concevoir une (nouvelle) application autour
d'une base de données existante, souvent en relationnel ou
de migrer progressivement des applicatifs anciens en pro-
grammation objet. Par rapport à la solution précédente,
celle-ci à l'avantage de la maîtrise du schéma de la base
puisqu'il faut le concevoir soi-même et de la possibilité de
foptimiser explicitement, soit pour un fonctionnement rela-
tionnel (cas des bases existantes), soit pour un fonctionne-
ment objet. Par rapport à la problématique des SGBD objet
qui risquent de conduire à des applications persistantes, on
se place par contre dans ce cas, dans une logique de
conception autonome de la base d'information (définition
des structures, relations, règles d'intégrité et de gestion...)
indépendante des traitements qui peuvent avoir lieu.
Le principal désavantage, est d'avoir à réaliser soi même
tout l'interfaçage entre le modèle objet applicatif et le
modèle relationnel du SGBD. On peut être rapidement
amené à écrire une surcouche SGBD objet sur un SGBD
relationnel (transaction, verrou, distribution) puisque, par
exemple, non seulement le modèle de stockage est le modè-
le relationnel, mais le modèle de verrouillage également.
Fichiers
Dans cette solution simpliste, l'application gère explici-
tement la persistance des données par des lectures/écri-
tures dans des fichiers. Pour chaque classe, les méthodes
lire et écrire sont décrites, avec des difficultés non négli-
geables lors de la mise à plat des objets pour le stockage
(déréférencement des pointeurs) et inversement la recons-
truction des structures complexes à la lecture. Cette solu-
tion sans SGBD ne peut pas offrir les services de ceux-ci,
soit le partage entre plusieurs utilisateurs, les reprises sur
incident... à moins d'une programmation très lourde de ces
fonctionnalités. Cette solution " rustique " est plutôt à réser-
ver pour conserver des informations, si possible de structu-
re simple, entre deux sessions (ex : paramètres de configu-
ration, données initiales). L'implémentation de cette solu-
tion pourra être allégée par l'emploi de bibliothèques
offrant des classes fichiers, répertoires...
CONCLUSION
Il existe donc plusieurs solutions de stockage des objets,
plus ou moins adaptées au paradigme objet, performantes
et fiables industriellement. Faute de solution universelle,
chaque cas devra être évalué en fonction de ses priorités :
- système d'information ou applications persistantes en
C++ ou Smaltalk, couplage avec des bases existantes,
- productivité en développement et maintenance, perfor-
mances en exécution, facilités en exploitation,
- pérennité de l'offre, du produit, du fournisseur...
Quoiqu'il en soit, il s'avère que les solutions de stockage
pour des objets sont diverses et que même sur le marché
étroit par exemple du C++ persistant, les SGBD objet ne
sont pas forcément incontournables. En conséquence,
même sur un marché de la technologie objet en plein essor
(méthodes, outils d'analyse/conception, programmation...),
les SGBD objet ne font pas le plein de leur clients poten-
tiels et que d'autres technologies plus récentes (ex : objet-
relationnel) ou anciennes (ex : relationnel) ont leur place.
Références
[1] Du C++ à Merise Objet : Objets, par M. Bouzhegoub, G.
Gardarin et P. Valduriez, chez Eyrolles, Paris, 1994
[2] The Object-Oriented Database System Manifesto, par M.
Atkinson, F. Bancilhon, D. De Witt, K. Dittrich, D. Maier, et D.
Zdonick, actes de la conférence DOOD'89, Kyoto, 1989.
[3] The Object Database Standard : ODMG-93, par R.G.G.
Cattel, T. Atwood, J. Duhl, G. Ferran, M. Loomis et D. Wade,
version 1.1, chez Morgan Kaufmann Publishers, San Francisco,
1994.
[4] Database Language SQL3, International Standard
Organization, ISO-ANSI working draft.
[5] Object Engineering : The Fourth Dimension, par Ph. Desfray,
chez Addison-Wesley, Paris, 1994.
Philippe BRIDON est consultant en technologie orientée objet et génie logi-
ciel. A ce titre, il assure la veille technologique sur les produits et méthodes
orientés objet, leur mise en place et l'animation technique des projets. Il travaille
actuellement chez un grand équipementier en télécommunication. Actif depuis
dix ans sur ce sujet, il participe au Cercle Objet du Club Génie Logiciel (19) de
la SEE et au Groupe COOSI (Conception Orientée Objet des Systèmes
d'Information) de l'AFCET. Il a un diplôme d'Ingénieur de t'ISEP, complété d'un
mastère de Génie Logiciel du CERICS.
Abréviations
DBMS DataBase Management System
MCD Modèle Conceptuel de Données
ODMG Object Database Management Group
SGBD Système de Gestion de Bases de Données
SIG Système d'Information Géographique
SQL Structured Query Language
VOD Video On Demand
XAO <technique> Assistée par Ordinateur
REE
N, 6
Juin 1998