Dans la méthode traditionnelle de conception des bases de données, le développement d’un modèle conceptuel constitue la première étape. Une fois celui-ci conçu, le plus souvent désormais dans un langage objet, typiquement EXPRESS ou UML se pose la question de gestion des données. C’est le développement du modèle logique que nous discutons dans la section suivante.
3 Gestion persistante des objets
Dans cette section, nous discutons de l’évolution des modèles spécifications de données qui s’est réalisée en parallèle avec la généralisation de l’approche objet au niveau conceptuel. Nous discuterons successivement des trois modèles proposés [82] : le modèle relationnel, le modèle ob-jet et le modèle relationnel-obob-jet (apparu pour concilier les univers relationnel et obob-jet).
Enfin, nous discutons de façon plus approfondie des méthodes et outils permettant une co-existence entre les applications et le modèle objet d’une part, et, la représentation relationnelle d’autre part, puisque c’est le problème que nous devrons traiter pour la représentation des on-tologies dans les bases de données (cf. chapitre 3).
3.1 Le modèle relationnel
Le modèle relationnel, apparu dans les années 70 [40], visait à fournir un modèle simple pour faciliter l’accès aux données. Le modèle possède une seule notion : celle de relation mathématique représentée comme une table. Les opérations (création, suppression, insertion, mise à jour, etc.) sur les données sont faites aux moyens du langage SQL (Structured Query Language) qui est un langage déclaratif. Aujourd’hui encore, le modèle relationnel domine ses concurrents [152] parce qu’il est (1) efficace pour gérer des données de très grande taille, (2) basé sur des fondements ma-thématiques solides (l’algèbre relationnelle), (3) est basé sur des concepts simples, consistants et faciles d’utilisation [151] et (4) normalisé. Toutefois, il est limité pour les applications nécessitant des structures de données complexes (CAO, multimédia, SIG, IA, etc.).
3.2 Le modèle objet
Une deuxième catégorie de systèmes de bases de données [12, 91] est apparue dans les années 80 après l’émergence des concepts objets. Les bases de données orientées objets (BDOO) offrent la possibilité de représenter directement les instances des classes d’un modèle objet. Les objets sont donc stockés de façon persistante contrairement aux objets des langages de programmation orientés objets. Afin d’assurer la portabilité des interfaces d’un SGBD objet à un autre. L’ODMG a proposé un modèle abstrait de données : OQL-Object Query Language qui a été ensuite im-plémenté pour les langages de programmation orienté objet, tels que C++, Smalltalk et Java. Les avantages étaient les suivants. (1) Le modèle conceptuel et le modèle logique deviennent identiques. Les classes définies au niveau du modèle conceptuel sont directement représentées dans la base de données empêchant tout problème d’"impédance mismatch". (2) Une BDOO offre la possibilité de stocker des données de types diverses (Multimédia, SIG, CAO, etc.). (3) Elle est moins assujettie aux erreurs lors des mises à jour [91]. Malgré ces avantages, force est de constater que le modèle objet n’a pas connu le même succès commercial que le modèle relationnel
(cf. section 3.1). Aujourd’hui les BDOO sont cantonnées à des marchés de niche. Leur modèle n’est plus considéré comme une solution générale pour la définition des modèles logiques.
3.3 Le modèle relationnel objet
Le modèle relationnel objet est un compromis entre le modèle objet et le modèle relationnel [152]. L’idée de base, proposée par Atkinson et al. [12] lors du deuxième manifeste des bases de données objet, était de tirer profit de la maturité et des performances du modèle relationnel et des avantages de la modélisation objets des données. Cela a abouti à la définition d’une extension de la théorie du relationnel pour supporter les données ne respectant pas la première forme nor-male (1FN). Il fournit des types abstraits de données (ADT), des types complexes de données, les collections, l’encapsulation, l’héritage, des OIDs pour les instances. Un nouveau SQL en a découlé et est normalisé aujourd’hui sous le nom de SQL99 [52]. Plusieurs éditeurs de SGBD relationnels (Oracle, DB2, PostgreSQL) se sont lancés dans cette approche pour étendre leurs produits.
Aujourd’hui, dans le contexte industriel, on peut constater si la modélisation orientée-objet s’impose face aux autres approches de modélisation de l’information [151], au niveau représenta-tion des données, les SGBDRs et les SGBDROs s’imposent dans la plupart des cas par rapport aux SGBDOOs. Néanmoins, les SGBDROs qui implémentent la norme SQL99 [52] sont très ré-cents et ne supportent tous qu’une partie de la norme. Par exemple, PostgreSQL implémente l’héritage de table, ce que ne fait pas Oracle. Par contre, Oracle implémente les associations entre classes avec la possibilité de polymorphisme et le calcul des références inverses des associations, ce qui n’existe pas en PostgreSQL. Cette différence d’implémentation fait que les schémas de bases de données ne sont pas portables d’un SGBDRO à un autre. Pour cette raison, une des approches très fréquente consiste à marier un schéma objet avec un schéma essentiellement rela-tionnel, c’est l’approche hybride que nous présentons dans la section 3.4.
Notons que le prototype de base de données à base ontologique que nous avons implémenté au cours de notre thèse a été réalisé sur le SGBDRO PostgreSQL dont nous présentons les principales caractéristiques dans l’annexe B.
3.4 Approches hybrides de conception de bases de données : les mappings
objet/relationnel
Compte tenu des divergences croissantes apparaissant entre les formalismes de modélisation conceptuelle et logique, depuis les années 1990, plusieurs études ont été menées [37, 101, 106, 152] en vue de concilier l’univers objet de l’approche relationnelle. Deux grandes approches ont été proposées :
1. La connexion des applications objets directement aux bases données relationnelles en co-dant dans les méthodes de classes ("getters", "setters", constructeurs, destructeurs, etc.) l’accès aux données. Cet accès se fait généralement par du "embedded SQL" repartit dans tout le code des applications.
3. Gestion persistante des objets 2. La définition d’un gestionnaire d’objets (ou object layers) entre les applications objets et les bases de données relationnelles (cf. figure 1.5). Le gestionnaire d’objets (1) reçoit les requêtes (OQL par exemple) venant des applications objets, (2) les traduit en SQL et les envoie au SGBDR pour exécution ; (3) récupère les résultats et enfin (4) les traduit de nouveau dans le format adapté (OQL par exemple) pour les applications objets. Exemple : Ibatis [94], Hibernate [70], JDO [132], etc.
Les deux approches précédentes partagent le fait que les objets des classes de l’application sont stockés dans des bases de données de type relationnel (ou relationnel-objet). Ces approches néces-sitent donc de définir des correspondances entre les concepts objets et les concepts relationnels, puis de gérer de façon la plus simple possible les transformations associées à ces correspondances. Dans la section 3.4.1, nous discutons les principales règles de correspondances objet/relationnel qu’on trouve dans la littérature. Nous devrons en effet choisir de telles règles pour représenter nos ontologies dans nos BDBOs. Dans la section 3.4.3, nous présentons un exemple d’outils pour la gestion des transformations, à savoir le "framework" hibernate qui est un outils de transfor-mation objet / relationnel paramétrable très fréquemment utilisé et que nous utiliserons dans notre travail. SGBDR/O Gestionnaire d’objets Application (1) requêtes (OQL) (2) Traduction requêtes en SQL (3) Envoie de la requête au SGBDR/O (4) exécution de la requête SQL (5) récupération de données (7) données objets (OQL)
(6) Traduction des données en objets (OQL) SGBDR/O Gestionnaire d’objets Application (1) requêtes (OQL) (2) Traduction requêtes en SQL (3) Envoie de la requête au SGBDR/O (4) exécution de la requête SQL (5) récupération de données (7) données objets (OQL)
(6) Traduction des données en objets (OQL)
Fig. 1.5 – Approche hybride de représentation d’objets : gestionnaire d’objets
3.4.1 Règles de transposition objet-relationnel
Plusieurs approches ont été proposées pour la représentation des concepts objets dans un environnement relationnel. Nous discuterons essentiellement ici les propositions portant sur la représentation des relations d’héritage [134, 141, 97, 53, 108], d’associations et d’agrégations [54, 145] qui sont les principaux concepts objets qui exigent des règles de transformations particulières pour être représentés en relationnel.
3.4.1.1 Représentation de la relation d’héritage
Les propositions de représentation de la relation d’héritage peuvent être classées en trois ca-tégories :
2. Représentation horizontale, 3. Représentation verticale.
1. Représentation "à plat" : une table par arborescence
Dans cette stratégie, tous les attributs de toutes les classes d’une hiérarchie sont stockés dans une seule et même table. Le nom de la racine de la hiérarchie est le plus souvent utilisé pour nommer cette table. Deux autres attributs sont ajoutés. Le premier représente l’identifiant, ou clé primaire de la table. Le second est généralement un code spécifiant le type effectif de l’objet instancié (cf. (1a) dans la figure 1.6). Une variante de cette approche consiste à remplacer ce second attribut par plusieurs attributs de type booléen (cf. (1b) dans la figure 1.6) ; chacun d’eux correspondants à un des types possibles.
Cette approche est simple et supporte le polymorphisme car tous les objets polymorphes appartiennent à la même table. Ils peuvent donc être référencés par une même clé étran-gère. L’accès aux instances d’un niveau quelconque de la hiérarchie demande seulement la projection d’une sélection car toutes les instances sont rangées dans une seule table. C’est la seule méthode qui sera économe en jointure. L’inconvénient, par contre, se situe au niveau de l’espace de stockage car les tables peuvent être très grandes et contenir de nombreuses valeurs nulles [5]. Ceci est en particulier le cas lorsque des motifs de classes abstraites sont utilisés pour représenter des mécanismes génériques, tels, par exemple, le motif Modèle-Vue-Controleur (MVC) [96]. La mise à plat impose alors de regrouper un très grand nombre de classes disparates, qui n’ont pas d’autres points communs que d’utiliser le même mécanisme.
2. Représentation horizontale : une table par classe concrète
Dans cette approche (cf. (2) dans la figure 1.6), une table est créée pour chaque classe concrète. Tous les attributs de la classe concrète et ceux hérités des super-classes de cette dernière constituent les colonnes de la table. A ces colonnes, s’ajoute une clé primaire. Lorsqu’il n’y a qu’un seul niveau de classes concrètes, l’avantage de cette approche est qu’il est facile d’obtenir et de stocker les informations sur les objets existants car toutes les informations sur un objet se retrouvent dans une seule table.
Les inconvénients principaux de cette représentation sont (1) qu’une requête générique sur une classe abstraite nécessite des unions de projections des tables des sous-classes et (2) que le polymorphisme n’est pas supporté de façon aisée car un lien vers une classe abstraite se matérialise par une référence vers des tables différentes selon les instances. De complexes mécanismes d’"aiguillage" (cf. section 3.4.1.2) sont alors nécessaires.
3. Représentation verticale : une table par classe
Dans cette approche (cf. (3) dans la figure 1.6), on crée une table pour chaque classe. Chaque table a pour colonnes les attributs définis au niveau de la classe qu’elle représente. Un même identifiant est utilisé comme clé primaire pour toutes les tables. Au niveau des sous-classes, il représente à la fois une clé primaire et une clé étrangère.
3. Gestion persistante des objets L’avantage de cette approche est qu’elle représente de façon très adéquate les concepts orientés objets. Le polymorphisme peut se représenter assez aisément par une clé étran-gère unique (avec jointure automatique avec les super-classes) parce que nous avons un enregistrement dans la table correspondant à chaque classe auquel un objet appartient. Il est facile également de modifier les super-classes et d’ajouter de nouvelles sous-classes car cela correspond respectivement à la modification et à l’ajout d’une table. Outre le nombre important de tables dans la base de données (une pour chaque classe), le principal incon-vénient de cette approche est que les informations sur un objet d’une classe se retrouvent reparties entre grand nombre de tables. Ainsi, tout accès à un objet nécessite de faire de nombreuses jointures, ce qui peut devenir très coûteux.
A
oid is_A a is_A1 a1 is_A2 a2
A1 oid a a1 A2 oid a a2 A oid a oid aA1 1 A2 oid a2
(1b) – Représentation à plat – variante avec plusieurs colonnes de type booléen
(2) – Représentation horizontale
(3) – Représentation verticale A
oid A_type a a1 a2
(1a) – Représentation à plat – variante avec une colonne discriminante
a1 a2
a
(ABS)
A
A1 A2
Fig. 1.6 – Différentes approches de représentation de l’héritage
3.4.1.2 Représentation des relations d’association, d’agrégation et de composition Pour ce qui concerne les associations, agrégations et compositions, on trouve également dans la littérature, plusieurs propositions de représentation [54, 137, 136, 138, 139, 140]. Ces propositions sont définies en fonction des cardinalités des relations (1 : 1, 1 : n, n : m) et des propriétés des relations d’agrégations (dépendance, partage, exclusivité, prédominance) [105]. [145] énumère toutes les solutions envisageables pour la représentation de ces relations en relationnel. Ces différentes solutions se résument soit à la création de tables intermédiaires entre les tables des classes participantes à la relation, soit à la déclaration de clés étrangères sur des colonnes de tables. Ces différentes propositions ne s’appliquent que lorsque le choix de représentation de l’héritage est vertical ou à plat. Lorsque seules les classes concrètes sont représentées, il est nécessaire de représenter tout lien par un aiguillage comportant en particulier une colonne qui indique le type effectif de l’instance référencée.
3.4.2 Choix de règles de transposition
Chaque représentation possible de chaque mécanisme objet présente des avantages et des inconvénients. Ceci fait que la meilleure représentation dans chaque cas dépend étroitement des caractéristiques locales du modèle objet à transposer. Trois solutions sont alors envisageables :
– Choisir pour chaque classe la représentation spécifique adaptée et programmer spécifique-ment pour chaque classe les accès à ses objets persistants. Cette méthode est extrêmespécifique-ment coûteuse et peut difficilement être envisagée lorsque, comme c’était notre cas, plusieurs centaines de classes doivent être transposées.
– Utiliser des méta-règles permettant dans chaque contexte de choisir les règles à appliquer, et de générer automatiquement les représentations relationnelles et les programmes de transformation. C’est ce que nous avons fait pour représenter le modèle d’ontologie PLIB et lui associer une API adaptée.
– Utiliser un outil paramétrable pour la gestion des transformations permettant une défini-tion déclarative des règles à utiliser pour chaque classe. Nous utiliserons également une telle approche lorsque nous souhaiterons développer une API objet plus simple que le modèle objet initial [128].
Nous présentons ci-dessus un exemple d’un tel outil, qui est précisément celui que nous avons utilisé.
3.4.3 Outil de gestion des transpositions relationnel-objet : l’exemple d’Hibernate Hibernate est une couche logicielle de transposition objet/relationnel pour les environnements Java et .NET. Hibernate permet de libérer les programmeurs de la plus grosse partie de la pro-grammation liée à la persistance des données sous forme d’objets dans les bases de données. Les classes (Java ou .NET) et les tables sont mises en correspondance grâce à un langage de mapping dont la syntaxe est en XML. Hibernate génère alors l’implémentation des méthodes des différentes classes par accès à la base de données. Il permet également de faire des requêtes dans le langage HQL qui porte directement sur le modèle objet.
Un des avantages d’Hibernate est que le langage de mise en correspondance objet/relationnel qu’il propose est paramétrable. En effet, Hibernate autorise de spécifier pour chacun des princi-paux concepts objets (classe, héritage, association, composition, etc.) et pour chacune des classes la stratégie la plus adaptée pour la représentation des données dans les bases de données. Un document XML de correspondance est exploité par Hibernate pour (1) connecter les sélecteurs des classes aux colonnes correspondant aux attributs dans la base de données, (2) gérer les accès concurrents aux objets en mémoire en assurant la synchronisation des objets en mémoire avec la base de données et (3) pour générer éventuellement le schéma de la base de données et/ou les classes si elles n’existent pas encore.
3. Gestion persistante des objets