Modèles relationnel et objet

Transcription

1 Informatique de gestion et systèmes d information Modèles relationnel et objet Peter.Daehne@heg.ge.ch Pierre.Leutert@heg.ge.ch / Novembre 2001 ISNet15_19.doc

2 TABLE DES MATIERES 1 Objectif Le modèle relationnel Données Concepts de base Implantation des concepts Conception d'applications Forces du modèle relationnel Faiblesses du modèle relationnel Le modèle objet Actions et données Concepts de base Mise en œuvre Persistance Sérialisation SGBD orienté-objet SGBD relationnel Forces du modèle objet Faiblesses du modèle objet Comparaison des deux paradigmes Caractéristiques des deux modèles Modèle relationnel Modèle objet Liens entre entités Modèle relationnel Modèle objet Accès aux données Modèle relationnel Modèle objet Le modèle objet-relationnel Liens entre entités Accès aux données En conclusion Observations finales Bibliographie Page 2 sur 19 26/11/01

3 1 Objectif L'objectif de ce document est de présenter les modèles relationnel et objet afin de mettre en évidence, pour chacun d'eux, leurs forces et leurs faiblesses. Pour ce faire, nous présenterons les principales caractéristiques et les concepts de base des deux modèles, nous étudierons ensuite les conditions de leur mise en œuvre et de leur implantation et nous examinerons enfin les problèmes spécifiques qui pourraient se poser. L'étude de ces deux modèles devrait servir de base à une réflexion sur la position du modèle relationnel-objet dans le contexte actuel de la conception d'applications, contexte principalement centré sur la technologie objet. Page 3 sur 19 26/11/01

4 2 Le modèle relationnel 2.1 Données Les concepts mis en œuvre dans le modèle relationnel sont fondés sur une théorie mathématique directement issue de l'algèbre relationnelle, de la théorie des ensembles et de la logique formelle. Cette technologie a vu le jour dans les années 70 avec les travaux de E. Codd [COD 70]. La conception de logiciel mettant en œuvre le modèle relationnel repose sur le principe de la séparation de l'analyse des données et de l'analyse des traitements, comme par exemple, la méthodologie Merise [TAR 91]. Dans la phase d'analyse des données, on s'applique à modéliser les informations du système indépendamment des traitements que ces données vont éventuellement subir. Comme le centre de préoccupation est principalement les données, les systèmes de gestion de base de données (SGBD) se sont trouvés particulièrement bien adaptés à l'implantation de ce concept. 2.2 Concepts de base Bien que le modèle relationnel repose sur des principes simples, il permet néanmoins de modéliser des données complexes. Une relation est une structure de données tabulaire. Une relation est composée d'attributs ; chaque attribut prend sa valeur dans un domaine. Une relation est donc un sous-ensemble du produit cartésien des domaines des attributs. Des opérateurs algébriques permettent d'effectuer des opérations entre les relations ; les principales opérations envisageables sont : les opérations ensemblistes : union, différence, produit cartésien ; les opérations relationnelles : projection, restriction ; les opérations dérivées : intersection, division. Les contraintes d'intégrité sont des assertions s'appliquant à une ou plusieurs relations et qui doivent toujours être vérifiées. Notons enfin qu'un processus de normalisation permet de construire des modèles de données sans redondance d'information. Page 4 sur 19 26/11/01

5 2.3 Implantation des concepts Un SGBD implantant ces concepts est appelé un système de gestion de base de données relationnel (SGBDR). Physiquement, le concept de relation est implanté par une table dont les colonnes représentent les attributs et les lignes, les occurrences de la relation. Chaque ligne de la table est identifiée par une clé primaire, formée de la valeur d'une (ou de la concaténation des valeurs de plusieurs) colonne(s). Les liens entre tables de la base de données sont réalisés à l'aide de clés étrangères. Une clé étrangère est un attribut ou groupe d'attributs dont les valeurs se retrouvent comme valeurs de clé primaire d'une table. Les clés étrangères sont donc des pointeurs logiques ; le concept de pointeur physique n'existe pas. En raison de cette caractéristique, le modèle relationnel est souvent qualifié de modèle à valeurs. Cette implantation des liens entre les tables crée de fait des chemins d'accès bi-directionnels aux données ; ainsi, il sera en général possible de répondre à un ensemble de problèmes qui sont en partie inconnus au moment de la création de la base de données. Le SGBDR est muni d'un langage de programmation unique, non procédural et normalisé, le langage SQL, qui permet : de déclarer et de créer toutes les entités de la base de données (tables, index, clés, contraintes, ); de manipuler les données mémorisées dans les tables (insertion, modification et suppression de lignes) ; d'interroger la base de données et d'en extraire des informations en fonction d'un certain nombre de critères exprimés à l'aide des opérateurs algébriques vus plus haut ; de définir des transactions ; de contrôler l'accès aux données (vues) et d'affecter des privilèges à des utilisateurs ; de poser des verrous sur des lignes et/ou des tables afin de gérer l'accès concurrent aux même données par plusieurs utilisateurs. Les informations mémorisées sont typées : à chaque attribut est associé un type. Les types principaux offerts par les SGBDR du marché comprennent les valeurs numériques, alphanumériques, date et logique. Avec l'avènement du multimédia, les types CLOB (character large object) et BLOB (binary large object) ont été introduits ; ils permettent la mémorisation de textes non structurés, d'images animées ou non et de sons, sans toutefois être manipulables directement par le langage SQL. La nature même de l'implantation du modèle relationnel règle de fait le problème de la persistance des informations traitées. Page 5 sur 19 26/11/01

6 2.4 Conception d'applications Dans le cadre du modèle relationnel, les applications sont en général conçues sur la base d'une architecture client-serveur [GAR 96] ; le rôle de serveur étant dévolu au SGBDR. La partie client d'une telle application est en général réalisée au moyen d'un langage de programmation traditionnel ; ces langages s'interfacent alors avec le langage SQL soit de manière native, soit via un pré processeur, soit au moyen de couches logicielles fournies par le constructeur du SGBDR, par l'éditeur du langage de programmation ou encore par des tiers. Du coté du serveur, les grands fournisseurs de SGBDR proposent en général un langage procédural universel complétant le SQL et permettant de programmer des fonctions et des procédures stockées, des paquetages et des déclencheurs. Ce langage s'interface également avec le langage de programmation d'application, en général de manière semblable à celle décrite ci-dessus pour le SQL. Un exemple d'un tel langage est le PL/SQL, proposé par le SGBDR Oracle [FEU 97]. Ce langage est en général employé pour coder des traitements spécifiques à la base de données et communs à l'ensemble des applications qui y accèdent ; parmi ces traitements, on peut citer la spécification de contraintes d'intégrité comportementale complexes. Les algorithmes exprimés à l'aide de ce langage sont exécutés dans l'espace mémoire du serveur de données (SGBDR). Lors de la conception de la base de données elle-même opération centrale dans l'approche relationnelle, on applique un processus de normalisation qui permet d'éliminer les redondances d'informations tout en préservant la cohérence des données mémorisées dans la base. Ce processus, s'il réduit les sources d'erreurs, a un prix : le nombre de tables est augmenté du fait de la décomposition résultant de la normalisation ; cette inflation augmente le nombre de jointures nécessaires à l'interrogation de la base de données. Page 6 sur 19 26/11/01

7 2.5 Forces du modèle relationnel De ce qui précède, on peut dégager les principales forces du modèle relationnel. Ce sont : les fondements mathématiques rigoureux sur lesquels le modèle repose ; ceux-ci permettent en particulier au moteur du SGBDR d'optimiser automatiquement les requêtes qui lui sont soumises en appliquant des théorèmes de l'algèbre relationnelle ; l'indépendance des données et des programmes de traitement, permettant un partage aisé d'informations entre les applications ; un langage de programmation non procédural puissant, concis et normalisé, le SQL, permettant de décrire, de mettre à jour et d'interroger les données mémorisées, d'effectuer des opérations algébriques complexes sur ces données, de spécifier des contraintes d'intégrité ainsi que de contrôler les accès aux données et de gérer des utilisateurs ; un langage de programmation universel qui rend la base active ; la spécification logique des liens entre tables qui affranchit le schéma de base de données de tout chemin d'accès prédéfini ; le concept de transaction garantissant l'intégrité de la base de données à la suite de l'exécution d'une séquence d'instructions de mise à jour ; le concept de verrou qui permet l'accès concurrent aux données. Il faut bien sûr encore citer, bien qu'il ne s'agisse pas de qualités intrinsèques du modèle relationnel, les éléments suivants : la large diffusion auprès de la majorité des grands comptes de SGBDR qui sont maintenant arrivés à maturité : ces systèmes sont performants, fiables, permettent la gestion de grandes quantités de données (de l'ordre du péta-octet) et intègrent souvent des outils de développement tels que les générateurs d'état, de formulaires, etc. ; le retour à la centralisation des données induit par la baisse continue des coûts des télécommunications, par l'émergence de réseaux rapides et par le développement des portails d'entreprise. Page 7 sur 19 26/11/01

8 2.6 Faiblesses du modèle relationnel Les principales faiblesses du modèle relationnel mises en évidence sont : l'indépendance des données et des programmes de traitement qui dissocie les données de leur comportement ; le respect des formes normales qui a pour conséquence de multiplier le nombre de tables et donc le nombre d'opérations de jointures dont le coût en ressources mémoire et processeur est élevé ; le nombre de types de base restreint et non extensible (il n'est pas possible de définir de nouveaux types de données par composition de types existants) ; le contenu des types objets longs (CLOB et BLOB) n'est pas manipulable directement par le langage SQL et nécessite donc le recours à des couches logicielles non normalisées ; l'interfaçage nécessaire entre des langages de programmation tiers et le SQL (ainsi que le langage de programmation de la base, s'il existe) pour réaliser des applications client-serveur ou multi-tiers (impedance mismatch) ; la faible capacité de modélisation : il est difficile de représenter directement des structures de données complexes (hiérarchies, graphes, collections, ). Page 8 sur 19 26/11/01

9 3 Le modèle objet 3.1 Actions et données La conception de logiciel mettant en œuvre le modèle objet repose sur une idée élémentaire : un système informatique réalise certaines actions sur certaines données ; pour obtenir des systèmes souples, réutilisables et évolutifs, il vaut mieux structurer le logiciel autour des données plutôt qu'autour des actions [MEY 90]. Cette idée se fonde sur l'observation du fait que tout système informatique réussi sera l'objet de nombreuses modifications tout au long de sa vie. Or, dans un système en évolution, les actions représentent la partie la plus volatile : un bon système devra un jour ou l'autre résoudre de nouvelles tâches et certaines de ses tâches initiales peuvent même changer radicalement. Les ensembles de données qu'un système traite sont moins changeantes, du moins si l'on se place à un niveau d'abstraction suffisant. Lorsqu'on conçoit un système selon cette technique, la principale question que l'on se pose n'est pas ce que fait le système, mais à quelles données il le fait ; autrement dit, on va centrer l'attention sur les données et sur leur comportement. 3.2 Concepts de base Nous avons vu ci-dessus qu'un système informatique construit en se basant sur le modèle objet était focalisé sur les données et sur le comportement qu'elles avaient ; examinons donc les concepts qui permettront de modéliser ces données. Un type de données abstrait est la description d'une entité constituée de structures de données (les attributs) et de primitives d'accès (les opérations ou les méthodes). Le masquage de l'information consiste à encapsuler un type de données abstrait de telle manière que ses utilisateurs n'aient accès qu'à une vue abstraite, une description officielle de celui-ci : son interface. L'héritage permet de définir un nouveau type de données abstrait en étendant un type de données abstrait de base. Le nouveau type ainsi créé comprend : tous les attributs du type de base ; toutes les méthodes du type de base ; des attributs supplémentaires ; des méthodes supplémentaires. Certaines méthodes du type de base peuvent de plus être redéfinies pour spécifier un nouveau comportement. Le type de données abstrait créé par héritage est également appelé type dérivé du type de données abstrait de base. Le type dérivé est compatible avec le type de données abstrait de base. La référence à une instance d'un type de données abstrait a donc deux types qui peuvent éventuellement être distincts : son type statique qui est celui de sa déclaration dans le texte du programme ; son type dynamique qui est celui du type effectivement référencé ; cela peut-être le même type que le type statique ou bien cela peut-être un type dérivé du type statique. Lorsqu'une méthode associée à un type de données abstrait est appelée, le choix de la méthode effectivement appelée est fait lors de l'exécution en fonction du type Page 9 sur 19 26/11/01

10 dynamique de l'instance dont on invoque la méthode : ce mécanisme s'appelle la liaison dynamique. Une classe est un type de données abstrait mettant en œuvre le principe du masquage de l'information, extensible par héritage et dont les méthodes sont activées par liaison dynamique. Un objet est une instance d'une classe. Un langage de programmation est dit orienté objet lorsqu'il implante le concept de classe comme défini ci-dessus. 3.3 Mise en œuvre Il est intéressant de constater que cette approche réintroduit les actions des systèmes logiciels d'une façon symétrique de celle des données : une classe définit une catégorie de données par les services que cette catégorie est capable de fournir. Notons également qu'une classe est une unité intéressante et utile en elle-même, indépendamment du système auquel elle appartient. Remarquons enfin qu'il peut y avoir des classes sans données (offrant uniquement des services) et des classes sans méthodes (modélisant des données inertes). Lorsqu'on conçoit un logiciel en mettant en œuvre le modèle objet, on commence par identifier les classes du domaine d'étude, puis on les assemble pour former le système informatique désiré. Un certain nombre de ces classes peut être puisé dans une bibliothèque générale, en particulier les objets de l'application et les objets d'implémentation [RUM 91]. D'autres classes, identifiées lors de l'analyse de l'activité de l'entreprise, les objets métiers [RUM 91] proviennent d'une bibliothèque spécialisée regroupant les classes communes aux applications métier de l'entreprise. Les classes spécifiques de l'application enfin, font l'objet d'un développement ad hoc. Notons toutefois que le rôle du concepteur ne se borne pas à assembler des classes comme les briques d'un mur ; la plupart du temps, le concepteur sera amené à développer un ensemble de classes techniques jouant le rôle de colle, de mortier entre les classes à disposition et celles qu'il a développées, de manière à obtenir une application fonctionnelle. Remarquons enfin qu'à l'issue du processus d'analyse, les données du domaine sont modélisées par des classes reliées entre-elles par des associations et qu'au cours de l'exécution de l'application issue de la conception, les informations effectivement traitées sont représentées par des objets reliées entre-eux par des références, formant ainsi un graphe en général complexe. La description succincte de la démarche de conception par composition de classes que nous avons décrite ci-dessus met clairement en évidence que nous nous trouvons en présence d'une approche ascendante. Il s'agit donc d'une démarche se situant à l'opposé de celle appliquée en général par le concepteur traditionnel, à savoir la conception fonctionnelle descendante, introduite par N. Wirth [WIR 71], recommandée par de nombreux ouvrages et mise en œuvre dans des méthodologies de conception telles que Merise [TAR 91]. 3.4 Persistance Il peut être souhaitable que certains objets créés par une application survivent à l'exécution de cette application, c'est-à-dire soient persistants. Cette caractéristique est particulièrement requise dans les situations suivantes : les informations mémorisées par les objets sont partagées entre plusieurs applications ; Page 10 sur 19 26/11/01

11 la même application peut s'exécuter ultérieurement en prenant comme état initial un état mémorisé par les objets persistants ; les résultats de traitements effectués par l'application doivent être mémorisés en vue de leur archivage. Un dispositif de mémorisation permanent est alors nécessaire ; ce dispositif peut être un fichier séquentiel ou un système de gestion de bases de données (SGBD). 3.5 Sérialisation La plupart des langages de programmation orientés objets implantent un mécanisme de persistance nommé sérialisation qui permet d'enregistrer un graphe quelconque d'objets dans un fichier séquentiel de bytes. À la suite de la sérialisation d'un tel graphe, la même application (ou une application différente) peut recharger en mémoire le graphe précédemment sérialisé. Ce mécanisme est en général particulièrement simple d'emploi. Dans le langage Java par exemple (à partir de la version 1.1), il suffit d'invoquer une méthode d'écriture de l'objet constituant la racine du graphe pour que tous les objets du graphe soient récursivement et automatiquement sérialisés [FLA 97]. Une méthode correspondante de lecture permet d'effectuer le processus inverse. L'intégrité et la cohérence des données sont assurées par l'enregistrement d'informations supplémentaires caractérisant la classe et sa version, informations vérifiées automatiquement lors d'un rechargement ultérieur. Les principales qualités d'un tel système sont : la simplicité d'emploi du mécanisme ; la possibilité de faire circuler des objets entre applications distribuées sans encodage ni décodage spécifiques à programmer. Les principaux défauts de la sérialisation sont : l'ensemble d'un graphe d'objets est mémorisé/rechargé en une seule opération alors que peut-être seulement une partie de ce graphe était utile pour le traitement en cours ; l'absence totale d'un concept de transaction sans lequel il est impensable d'envisager le partage de données entre plusieurs applications différentes. 3.6 SGBD orienté-objet Les bases de données orientées objet existent depuis le milieu des années Leur objectif principal est d'unifier deux technologies : les systèmes de gestion de bases de données et la programmation orientée objet. Un langage de programmation orienté objet est en général très expressif mais manque d'outils performants de gestion de la persistance ; un SGBD, pour sa part, a comme principale caractéristique de gérer la persistance des données en manquant d'expressivité dans la formulation des traitements appliqués aux données. Un SGBD orienté objet (SGBDOO) implante toutes les caractéristiques des langages de programmation orientés objets et est capable de fournir des services de persistance performants pour des applications traitant de grandes quantités de données. Dans un tel SGBD, les liens entre les objets sont bien sûr implantés sous forme de références à d'autres objets (en d'autres termes, sous la forme de pointeurs physiques) et l'accès aux informations est principalement de type navigationnel. Un accès sous forme de requêtes permettant d'extraire un ensemble d'objets satisfaisant un certain nombre de caractéristiques est en général également possible ; certains standards, tel ODMG 2.0 [CAT 97], ont d'ailleurs été proposés pour résoudre ce Page 11 sur 19 26/11/01

12 problème. Notons enfin que le concept de transaction est en général également à disposition du concepteur d'applications. Un SGBDOO est donc naturellement adapté à l'implantation de la gestion de la persistance des objets d'une application. Il existe même des SGBDOO où cette persistance est gérée de façon complètement transparente pour le concepteur d'applications : un sous-ensemble des objets de l'application est déclaré persistent et des librairies additionnelles fournies par le constructeur du SGBDOO se chargent de l'interfaçage. C'est le cas par exemple du SGBDOO Jasmine, distribué par Computer Associates, qui fournit des outil gérant de façon transparente la persistance des objets d'applications écrites dans les langages de programmation C ++ et Java [KET 98], supprimant ainsi l'impedance mismatch. 3.7 SGBD relationnel On peut également employer un SGBDR pour implanter la persistance des objets d'une application développée selon le modèle objet. Le problème principal auquel on devra faire face est que les modèles relationnel et objet ne sont pas vraiment compatibles : le modèle relationnel est centré sur les données alors que le modèle objet est centré sur le comportement. Il s'agit donc réellement de deux appréhensions différentes du monde réel. Néanmoins, souvent pour des raisons stratégiques (l'entreprise concernée possède de nombreuses applications développées selon le modèle relationnel, les données doivent être partagées avec d'autres applications de l'entreprise, ), le concepteur d'une application objet sera amené à implanter la persistance de ses objets au moyen d'un SGBDR. Le principal défi auquel le concepteur est confronté est d'encapsuler suffisamment la base de données relationnelle pour qu'une petite modification dans le modèle relationnel des données n'invalide pas le modèle objet des données et vice-versa. Lorsqu'on considère le modèle objet obtenu à l'issue de l'analyse, on peut en général assez facilement établir une correspondance directe entre classes et tables et implanter un accès direct aux tables depuis le programme d'application ; cette solution ne peut être que ad hoc et nécessitera des modifications de grandes parties du code à chaque modification du modèle objet. La solution consiste bien sûr en la conception d'une couche logicielle spécialisée, réalisant l'encapsulation décrite plus haut. Cette couche logicielle sera chargée de la gestion de la correspondance entre les objets de l'application et les éléments relationnels de la base de données. Un des principaux problèmes que l'on va rencontrer est un problème de performance ; en effet, dans le modèle objet, l'accès aux informations est essentiellement navigationnel et la navigation, dans le modèle relationnel, devra être implantée en utilisant l'opération de jointure, opération coûteuse en ressources. 3.8 Forces du modèle objet Les principales forces du modèle objet qui se dégagent de ce qui précède sont : l'unité entre les données et les programmes de traitement : un objet est l'association de structures de données et d'opérations spécifiant les capacités de l'objet ; le principe de la liaison dynamique, qui permet de spécifier des algorithmes de traitement qui pourront être appliqués à une famille de classes, certaines d'entre-elles encore inconnues au moment de la conception de l'algorithme ; un langage de programmation et un modèle de données uniques, lorsque la persistance peut être implantée de façon transparente à l'aide d'un SGBDOO ; Page 12 sur 19 26/11/01

13 la réduction des différences entre le monde à modéliser et le modèle de données ; la richesse des types de données à disposition ainsi que la possibilité, via les concepts de type de données abstrait et de classe, d'en créer de nouveaux ; la grande capacité de modélisation, en particulier celle de structures de données complexes telles que les hiérarchies, les graphes, les collections, ; la possibilité de concevoir des composants logiciels réutilisables, permettant ainsi de construire des applications par composition. 3.9 Faiblesses du modèle objet Les faiblesses du modèle objet qu'on peut relever sont principalement : le manque de bases théoriques dans la systématisation de la conception d'un modèle objet ; le problème de la gestion de la persistance dans un environnement sans SGBDOO, seul système de gestion de données vraiment adapté ; on retrouve alors le problème de l'impedance mismatch. la navigation entre objets du modèle est définie une fois pour toutes ; si de nouveaux problèmes posés sur les mêmes données doivent être résolus postérieurement à la conception du modèle, celui-ci devra vraisemblablement être modifié ; la tenue de charge des moteurs de SGBDOO, lorsque le nombre d'utilisateurs concurrents augmente d'une manière importante ; Page 13 sur 19 26/11/01

14 4 Comparaison des deux paradigmes Les modèles relationnel et objet fournissent à l'analyste un cadre conceptuel et un ensemble d'outils lui permettant de modéliser des informations du monde réel. Cet état de fait étant établi, il convient de garder présent à l'esprit que ces deux modèles se fondent sur des paradigmes complètement différents. Cette différence fondamentale de référentiel interdit donc d'appliquer des raisonnements identiques aux deux modèles. Des concepts qui seront pertinents dans un cadre ne le seront pas dans l'autre et vice-versa. Dans le cadre de ce document, nous rappellerons succintement les principales caractéristiques des deux modèles, puis nous examinerons comment les liens entre entités sont représentés et les conséquences que ces représentations ont sur l'accès aux données. Enfin, nous étudierons comment le modèle objet-relationnel se positionne dans ce contexte. 4.1 Caractéristiques des deux modèles Modèle relationnel Le modèle relationnel est fondé sur l'algèbre relationnelle, la théorie des ensembles et la logique formelle. Lors de la conception du modèle de données issu de l'analyse, on applique un processus de normalisation qui élimine les redondances d'information tout en préservant la cohérence des faits mémorisés. Le modèle de données qui est obtenu à l'issue de ce processus de normalisation est dit être en troisième forme normale (3NF) Modèle objet Le modèle objet a comme objectif de permettre la modélisation des entités du monde réel de telle sorte que la différence entre le monde réel et le modèle obtenu soit la plus ténue possible. Dans ce cadre, il est aisé de modéliser des structures complexes telles que les hiérarchies, les graphes et les collections. Lors de la conception d'un modèle de données, l'expérience de l'anayste joue un très grand rôle, principalement en raison de l'absence de bases théoriques dans la systématisation de la conception objet. Page 14 sur 19 26/11/01

15 4.2 Liens entre entités Modèle relationnel Dans un modèle de données relationnel normalisé, les liens entre entités sont représentés par des clés étrangères (association binaire de type 1-n) ou par des tables de correspondance de clés étrangères (association binaire de type n-n). Cette représentation contient toute l'information nécessaire pour calculer n'importe quel chemin d'accès aux données parcourant ces liens Modèle objet Dans un modèle de données objet, les liens entre entités sont représentés par des pointeurs. Pour implanter une association binaire de type 1-n, il est nécessaire de prévoir un pointeur du côté "1" et une table de pointeurs du côté "n" ; de même, pour implanter une association binaire de type n-n, il est nécessaire de prévoir une table de pointeurs des deux côtés. Cette représentation contient évidemment toute l'information nécessaire pour parcourir n'importe quel chemin d'accès aux données. 4.3 Accès aux données Modèle relationnel Dans le modèle relationnel, les chemins d'accès sont exprimés en compréhension. Pour parcourir un chemin d'accès aux données, il est nécessaire d'effectuer un calcul à l'aide des opérations algébriques : dans le cas d'une association binaire de type 1-n, il faut effectuer un produit cartésien suivi d'une restriction (jointure); dans le cas d'une association binaire de type n-n, il est nécessaire d'effectuer deux produits cartésiens puis une restriction sur le résultat de ces produits cartésiens (jointures). La longueur de ces calculs fastidieux fut l'une des causes de la piètre performance des premiers SGBD relationnels. Dans les SGBDR de dernière génération, l'administrateur de la base dispose d'une impressionnante panoplie d'outils lui permettant : d'analyser les types d'interrogations effectuées sur la base de données ainsi que de mesurer le coût en ressources de ces interrogations ; en fonction de cette analyse, d'optimiser les accès aux diverses tables constituant la base en créant des structures de données auxiliaires telles que des partitions - hachées ou non, des index, des bitmap indexes, des index organized tables, etc. ; de spécifier que certaines tables doivent être mises en mémoire cache ou encore accédées parallèlement lors de certaines requêtes. De plus, le moteur du SGBDR lui-même optimise automatiquement les requêtes en appliquant des théorèmes de l'algèbre relationnelle et en exploitant la structure de données auxiliaire (créée par l'administrateur) la plus adaptée à la nature de la requête. Toutes ces opérations d'optimisation visent à gommer les conséquences du processus de normalisation dont l'objectif principal est d'éliminer les redondances Page 15 sur 19 26/11/01

16 d'informations et donc de simplifier la mise à jour de la base de données en préservant son intégrité Modèle objet Dans le modèle objet, les chemins d'accès sont exprimés en extension. Pour parcourir un chemin d'accès aux données, il suffit de suivre les pointeurs mémorisant explicitement tous les chemins d'accès possibles. Aucun calcul autre que l'indirection n'est nécessaire ; le coût de celle-ci est quasiment nul. Ce type d'accès aux données a comme principaux avantages sa simplicité d'emploi lors du parcours des liens entre entités et sa performance ; c'est d'ailleurs le type d'accès qui était employé dans les bases de données réseau. En raison de cette simplicité, l'administrateur de la base dispose de très peu d'outils auxiliaires et la responsabilité de l'optimisation des chemins d'accès est en général reportée sur le concepteur de la base de données. Le principal défaut de ce modèle est que les mises à jour de la base de données peuvent devenir très complexes, et donc sources d'erreurs de programmation. En effet, les associations binaires de type 1-n et n-n étant implantées au moyen de pointeurs des deux cotés de l'association, il est nécessaire de mettre ces pointeurs à jour lors de chaque modification de l'une des tables prenant part à l'association. Ces mises à jour peuvent de plus être rendues encore plus complexes lorsque le concepteur de la base de données a optimisé certains chemins d'accès aux informations en rajoutant des pointeurs supplémentaires à certaines tables. Toutes ces raisons font que le concepteur d'une base de données dans le contexte objet doit définir les chemins d'accès effectivement employés et la navigation souhaitée très tôt au cours du processus d'analyse, de manière à pouvoir supprimer les pointeurs implantant des chemins non pertinents pour l'application en cours de développement. Ces suppressions permettront de simplifier les mises à jour puisque celles-ci devront actualiser moins de pointeurs, mais elles empêcheront également d'éventuels développements ultérieurs empruntant d'autres chemins d'accès que ceux initialement prévus. Notons enfin que les requêtes des langages d'interrogation ([SQL3], [CAT 97]) retournent des collections d'objets et que la simplicité de traitement de ces collections repose complètement sur les qualités du langage de programmation objet associé au SGBDOO. Page 16 sur 19 26/11/01

17 5 Le modèle objet-relationnel Le modèle objet-relationnel est une tentative de réunion des concepts présents dans les modèles relationnel et objet. Cette réunion est réalisée en étendant le modèle relationnel pour lui conférer un certain nombre de qualités reconnues du modèle objet. La totalité des fonctions d'un SGBDR classique est préservée et les concepts qui font le succès de l'approche objet ainsi que de nouveaux types de données y sont intégrés. Cette fusion ressemble parfois au mariage de la carpe et du lapin En effet, des concepts qui sont pertinents dans le contexte relationnel - comme ceux des formes normales (1NF, 2NF et 3NF) - ne le sont plus dans le contexte objet, d'où la définition de la NF 2 (Non First Normal Form). Inversément, les concepts de structures de données complexes et d'identité d'objet (OID) qui sont fondamentaux dans le modèle objet sont en contradiction avec les principes de base du modèle relationnel. 5.1 Liens entre entités Les liens entre entités peuvent être représentés comme dans le modèle relationnel, mais ils peuvent également être représentés comme dans le modèle objet. Toutes les solutions mixtes envisageables sont également possibles, les représentations relationnelles et objet n'étant finalement que celles qu'on trouve aux deux extrémités de la panoplie disponible. Une association binaire de type 1-n peut ainsi être représentée de 12 façons différentes et celle de type n-n peut quant à elle donner lieu à 16 représentations différentes, chaque représentation possédant ses avantages et ses inconvénients [SOU 99]. 5.2 Accès aux données L'accès aux données est bien sûr lié à la représentation des liens entre entités. Suivant les choix de représentation qui ont été faits, ce sont les caractéristiques du modèle correspondant relationnel lorsqu'on emploie des clés étrangères, objet lorsqu'on emploie des pointeurs qui s'appliquent. Le rôle du concepteur de la base de données est ici essentiel. Il doit non seulement être extrêmement compétent dans son domaine de base, mais il doit également posséder de solides connaissances dans le domaine de l'administration de la base de données de manière à choisir l'implantation la plus efficace possible en fonction des caractéristiques de l'application qu'il développe. Page 17 sur 19 26/11/01

18 5.3 En conclusion La motivation principale des éditeurs de SGBDR est manifestement de préserver l'ensemble des acquis du modèle relationnel de manière à ne pas se couper de l'énorme segment de marché qu'ils occupent avec cette technologie. En introduisant les concepts objet dans leur logiciel, ils prennent également le virage de la modernité en proposant des standards en vogue dans la conception d'applications distribuées et accessibles par le Web. Le pont entre les technologies relationnelles et objet est également assuré grâce au concept de vue objet-relationnelle. Cette intégration se fait quand même au prix d'une complexification importante du langage SQL qui perd ici, à notre avis, la simplicité qui en faisait sa force. Le travail du concepteur de la base de données est également rendu beaucoup plus difficile dans la mesure où le cadre conceptuel rigide que lui imposait le modèle relationnel est ici très relaché, voire inexistant. Remarquons enfin que nous trouvons ici en présence d'un système hybride comparable à ceux qui sont apparus au début de la vague relationnelle, lorsque les éditeurs ont rajouté une couche relationnelle sur des SGBD réseaux. 6 Observations finales L'emploi de la technologie objet pour la conception d'applications tient actuellement le haut du pavé. Cela est dû principalement à l'expressivité des langages de programmation orientés objets ainsi qu'à la puissance de modélisation du réel que possède le modèle objet. Il est donc fondamental que les éditeurs de logiciels proposent de nouveaux outils qui permettent de gérer l'ensemble du cycle de vie de données persistantes pour la plupart. D'un autre point de vue, il est essentiel de tenir compte du fait que des centaines de milliers d'applications en production de nos jours ont été conçues dans le cadre du modèle relationnel et s'appuient sur des informations mémorisées dans des SGBDR. Il faut également observer que les SGBDR actuellement sur le marché sont des produits de haute technologie, performants et fiables et qu'ils occupent presque en totalité le terrain de la gestion des données persistantes. La situation actuelle des SGBDOO est semblable à celle qu'avaient connu les SGBDR au moment de leur avènement, alors que la totalité du marché était occupée par des bases de données hiérarchiques et réseaux. On peut donc espérer qu'en arrivant à maturation, les SGBDOO vont se développer, simplifiant ainsi grandement le problème de la gestion des données persistantes des applications conçues selon le modèle objet. Des ponts avec les SGBDR devraient également voir le jour. L'implantation de la gestion de la persistance des objets au moyen de SGBD relationnels-objets est également un problème qui mérite une étude approfondie. Ce qu'on peut en tout cas affirmer sans grande chance de se tromper est que l'introduction des types abstraits de données, de l'héritage et de la navigabilité (pointeurs) dans le modèle relationnel permettront sûrement de résoudre ce problème de manière beaucoup plus élégante qu'avec un SGBDR traditionnel. Le développement des SGBD relationnels-objet permet également aux entreprises de préserver leur investissement puisqu'elles peuvent continuer à employer leurs applications purement relationnelles et développer de nouvelles applications mettant en oeuvre le modèle objet, tout en partageant les données entre les applications des divers types. On offre ainsi aux entreprises une possibilité de migration en douceur vers l'objet tout en préservant l'existant. Page 18 sur 19 26/11/01

19 7 Bibliographie [CAT 97] Rick CATTEL, The Object Database Standard : ODMG 2.0, Morgan and Kaufmann Publishers, 1997 [COD 70] Edward CODD, A Relational Model of Data for Large Shared Data Banks, Communications of the ACM, vol. 13, n 6, pp , 1970 [FEU 97] Steven FEUERSTEIN, Oracle PL/SQL, Guide de programmation, O'Reilly, 1997 [FLA 97] David FLANAGAN, Java in a Nutshell, 2 nd edition, O'Reilly, 1997 [GAR 96] Georges GARDARIN, Olivier GARDARIN, Le Client-Serveur, Eyrolles, 1996 [KET 98] Mohammad KETABCHI, Jasmine, The Perfect Platform to Build Java Applications, [MEY 90] Bertrand MEYER, Conception et programmation par objets Pour du logiciel de qualité, InterÉditions, 1990 [RUM 91] James RUMBAUGH, Michael BLAHA, William PREMERLANI, Frederick EDDY, William LORENSEN, Object-Oriented Modeling and Design, Prentice-Hall, 1991 [TAR 91] Hubert TARDIEU, Arnold ROCHFELD, René COLLETTI, La méthode Merise, Tome 1, Eyrolles, 1991 [WIR 71] Nicklaus WIRTH, Program Development by Stepwise Refinement, Communications of the ACM, vol. 14, n 4, pp , 1971 [SOU 99] Christian SOUTOU, Objet-relationnel sous Oracle 8. Modélisation avec UML, Eyrolles, 1999 [SQL3] Page 19 sur 19 26/11/01