DOSSIER omment stocker les objets

DOSSIER
Mots-clés :
omment
stocker
les
objets
?
Orienté-objet,
Relationnelobjet,
Persistance,
SGBD.
par Philippe BRIDON, membre du Cercle Objet du Club Génie Logiciel de la SEE
Le développement
techniques
nombreux
croissant
orientées objet conduisent de
projets à utiliser une analyse
et une conception
d'une
orientées
implémentation
orienté
objet
Pour certaines
nécessaire
données
des
comme
objet suivie
avec un langage
C++
ou Java
applications,
d'assurer
et donc
[1
des
dans ce cas des objets.
Or les techniques
de stockage
objets sont multiples
évolution.
pour
Plusieurs techniques sont disponibles avec les
SGBD objet, les plus adaptés, les SGBD relationnels-objet, récemmentapparus, et les couplagesà
des SGBDrelationnelsou des systèmesde fichiers.
il est
la persistance
Avec l'essorde la technologieobjet pour l'analyse
'se
et la conceptionse pose le problème de la persistance des applications écrites en objet (C++,
Java...).
les
et en pleine
Mais l'offre techniqueet les produits évoluent rapidement. Lechoix n'est donc pas simple et doit tenir
compte non seulement d'aspects technologiques
mais également industriels (productivité, exploitation, pérennité du fournisseur...).Sans oublier de
se poser la question : désire-t-onconcevoir un système d'information ou une application persistante.
PROBLÉMATIQUE
Les besoinsde persistancede donnéesdans une application sont divers :
- conserverune trace des donnéesentre deux sessions,
- assurerla sécurité et la fiabilité des donnéesen cas d'incident au cours d'une session,
- partager des données entre plusieurs utilisateurs ou
applications.
La persistancedes informations est relativement maîtrisée pour des techniques dites " classiques " (modèles
entité/relation ou Merise, codageen C ou Cobol...). Dans le
domaine orienté objet, la jeunessede 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êtesnavigationnelles, indexation sur les instancesde sous-classes...
La solution idéale semble l'emploi de systèmesde gestion de basesde données(SGBD) orientés objet. Mais les
produits sont jeunes, le marché en forte évolution et les
standardsémergeants.Utiliser des solutions éprouvéespeut
semblerplus rassurantdans une logique industrielle (pérennité des acteurs et standards) mais leurs paradigmes peuvent imposer des contraintes de conception et de réalisation. D'autres solutions plus simples ou innovantes sont
égalementdisponibles sur le marché. Si l'on tient compte
de l'ensembledes critères (adéquationdu modèle objet à la
techniquede stockage,productivité en développement,performancesen exécution, pérennité...) chaque solution a ses
avantageset sesinconvénients.
With the successof 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
DBMSand file managementsystems.
But the technical offer and the products change
quickly. Thus, the choice is not easy and must
include technologicalrequirementsand also industrial strengths(productivity, administration, trust in
future of the provider...). Without forgotten, the
right question to wonder : do we want designing
an information systemor a persistentapplication ?
QUELQUES SOLUTIONS
Cinq solutions majeurespermettent 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ésenté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îtreune croissancede la gestion des donnéesdans la partie applicative, la solution avec SGBD objet
tendant à rendre transparentela persistancedes objets.
REE
NI 6
juin 1998 i 73
LE GÉNIE
LOGICIEL
: LES CONCEPTS
Mais, comme toute industrie naissante, les SGBD objet
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 complexes, héritage, identité d'objet...) [2]. L'objectif est d'offrir une persistance transparente, c'est-à-dire qu'hormis les
déclarations de création des objets et la gestion des transactions, 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'application. 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
représentent encore pour beaucoup de décideurs un risque
industriel majeur : nombreuses start-up, sans leader apparent, standard
(ODMG)
récent encore partiellement
appliqué
[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é,
d'architectures distribuées complexes).
support
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 stocké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 restocker sur le serveur la nouvelle valeur. Le gain de la technologie objet sur le parcours navigationnel est ici perdu dans
des flux de données trop importants sur le réseau. Bien
composants. Toutes les applications de XAO notamment
où les requêtes sont essentiellement navigationnelles (pas-
entendu, la plupart des vendeurs de SGBD objet se penchent sur la possibilité de faire exécuter des traitements sur
le serveur ( " load balancing ") et de faire des indexations et
ser d'un objet à un de ses composants ou associés, suivre
optimiseurs de requêtes adaptés au modèle objet (ex : 02).
des références...) deviennent très performantes. En effet,
dans ce cas, un SGBD objet se contente de faire du parcours de pointeur, tandis qu'un SGBD relationnel peine sur
des jointures multiples.
Tout Objet
ob » te
Relationnel-Objet
1 Obiab
om
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
Conversion
Obl « a
f »gr*mme
C*+
.
4
Fichiers
Encapsulation
Pmomnxn* C+*
1 , Rbqub*SOL,
jiï4uae SOL3 Rbqub* SOL iibwo.
mômis
tj)
Mt) « t)ft*lationrit
e)at)ont'
Objet
1'om4m
om
Me'tteMawM).
111
eoqt"
PtaaNtWfMC
sç.,
fumaffla
Imm
nn
u
oj
*bd 1
r'._>
Objets
SGBDO
: :'3
e
ObjetsrTables Tables Fichiers
SGBDRO
_3
e
SGBDR
1. Cing techniques de stockage d'objets.
REE
'-'NI 6
74 Juin1998
JB
c
Fchiers
SGBDR
SGF
Comment
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 informations de l'Entreprise des applicatifs qui les exploitent et
qui sont souvent moins stables et pérennes. La transparence 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 relationnels é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 relationnelle et donc le langage SQL pour la manipulation des
données complexes. L'idée est de pouvoir manipuler de nouveaux types de données (abstract data type), avec leurs procé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 relationnels qui veulent adapter leurs serveurs aux applications multimedia (serveurs web, imagerie, SIG, VOD...).
L'intérêt est d'être facilement pris en main par des administrateurs de bases de données généralement formés à
SQL et d'avoir des performances élevées grâce au savoirfaire acquis dans la réalisation de serveurs pour SQL (optimiseur de requêtes, cluster, techniques d'indexation, traitements 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 complets et fiables et les fournisseurs majeurs de SGBD relationnels 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 extensions à SQL qui seront standardisées au mieux dans SQL 3
(en 1998 ou 1999 ?) [4].
stocker
les objets
?
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 informations. 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'application 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 stockage profite des avantages des produits relationnels (pérennité, 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 relationnel 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 performances 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 données. L'intégration se contente d'être une encapsulation
" objet " de la base de données, notamment pour sa manipulation 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 1i :i
.,,,6
Jmnl998
i.. 1998
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 navigationnelles à travers les objets.
-
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...
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
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,
de migrer progressivement des applicatifs anciens en pro-
même sur un marché de la technologie objet en plein essor
grammation objet. Par rapport à la solution précédente,
celle-ci à l'avantage de la maîtrise du schéma de la base
(méthodes, outils d'analyse/conception, programmation...),
les SGBD objet ne font pas le plein de leur clients potentiels et que d'autres technologies plus récentes (ex : objet-
puisqu'il faut le concevoir soi-même et de la possibilité de
foptimiser explicitement, soit pour un fonctionnement relationnel (cas des bases existantes), soit pour un fonctionnement objet. Par rapport à la problématique des SGBD objet
relationnel) ou anciennes (ex : relationnel) ont leur place.
qui risquent de conduire à des applications persistantes, on
se place par contre dans ce cas, dans une logique de
Références
conception autonome de la base d'information (définition
des structures, relations, règles d'intégrité et de gestion...)
[1] Du C++ à Merise Objet : Objets, par M. Bouzhegoub, G.
Gardarin et P. Valduriez, chez Eyrolles, Paris, 1994
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 explicitement la persistance des données par des lectures/écritures dans des fichiers. Pour chaque classe, les méthodes
lire et écrire sont décrites, avec des difficultés non négligeables lors de la mise à plat des objets pour le stockage
(déréférencement des pointeurs) et inversement la reconstruction des structures complexes à la lecture. Cette solution 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éserver pour conserver des informations, si possible de structure simple, entre deux sessions (ex : paramètres de configuration, données initiales). L'implémentation de cette solution 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 :
REE
N, 6
Juin1998
[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
Organization, ISO-ANSIworking draft.
Standard
[5] Object Engineering: The Fourth Dimension, par Ph. Desfray,
chez Addison-Wesley, Paris, 1994.
PhilippeBRIDON estconsultant
entechnologie
orientée
objetetgénielogiciel. A ce titre,il assure
la veille technologique
surlesproduitset méthodes
orientés
objet,leurmiseenplaceet l'animation
technique
desprojets.Il travaille
actuellement
chezungrandéquipementier
entélécommunication.
Actifdepuis
dix anssurcesujet,il participeauCercleObjetdu ClubGénieLogiciel(19)de
la SEEet au GroupeCOOSI(ConceptionOrientéeObjet desSystèmes
d'Information)
del'AFCET.Il aundiplômed'Ingénieur
det'ISEP,complété
d'un
mastère
deGénieLogicielduCERICS.
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
SQL
VOD
Structured Query Language
Video On Demand
XAO
<technique> Assistée par Ordinateur
Géographique