La persistance des données

Dans l’élaboration du prototype du forum DIACOM, nous avons besoin de rendre persistant les objets créés par les utilisateurs du système. Il est, en effet, nécessaire de sauvegarder les cas décrits par les médecins, les informations extraites de ces cas par le module appariement, ou encore les discussions qui ont lieu sur le forum. L’utilisation d’un Système de Gestion de Bases de Données (SGBD) permet d’assurer cette persistance, tout en prenant en charge les problèmes de concurrence d’accès, de reprise sur panne ou encore de recherche efficace d’informations. Les SGBD les plus répandus sont les SGBD Relationnels (SGBDR).

® Les SGBD Relationnels

Apparues dans les années 80, les bases de données relationnelles sont fondées sur le modèle relationnel [Codd, 1970]. Le modèle relationnel se base sur la notion de table, qui a l’avantage d’être compréhensible par tout le monde. En effet, la métaphore du carnet d’adresses est souvent utilisée pour expliquer la structure d’une table!: il est aussi simple de lire une table de base de données relationnelles que de lire un carnet d’adresses. Le fondement de l’interrogation des SGBDR est l’algèbre relationnelle. C’est un mode d’interrogation ensembliste et les opérations exécutées sur les tables donnent en résultat à nouveau des tables. Pour assurer ce mode d’interrogation, la plupart des SGBDR proposent un langage tel que SQL. Cette standardisation du modèle des données et du mode d’interrogation, constitue un important avantage à l’utilisation des SGBDR.

Enfin, le dernier avantage des SGBDR est que la plupart s’appuient sur les mêmes fondements théoriques. En effet, à partir de ce modèle de données simple de nombreux travaux ont été réalisés visant à rendre ces systèmes les plus performants possible. On a donc une grande convergence des modes d’indexation des données, des modes de gestion de la mémoire et de la gestion de la concurrence d’accès et des pannes. De plus, il existe des méthodes permettant d’optimiser les performances des bases de données.

Toutefois, les bases de données relationnelles répondent mal à certains besoins [Gardarin,!1999]. En effet, le plus souvent, elles ne gèrent que des types simples (entier, réel, chaînes de caractères, etc.). De plus, aujourd’hui les modélisations d’applications sont orientées objet (UML), tout comme les langages d’implémentation tels que C++ ou Java. Ainsi, implanter la persistance de données conceptuellement objet, par le biais d’un SGBD relationnel, implique de réaliser une étape de transformation du modèle objet

en un modèle relationnel, appelée le «!mapping!». Cette étape est coûteuse en temps et nécessite une double compétence de la part du (des) développeur(s) objet et relationnel. Le développement de l’application nécessite alors la manipulation de deux langages de programmation!: un langage orienté objet, pour gérer l’application elle-même, et un langage tel que SQL pour interroger et mettre à jour la base. Le développeur doit donc, d’une part, opérer une transformation des données objet pour permettre leur sauvegarde dans la base par le biais de requêtes SQL. D’autre part, lors des phases d’extraction de données, il doit réaliser une transformation des données rapatriées par SQL en données compréhensibles et manipulables par le langage objet de l’application.

Pour pallier ces problèmes, des SGBD objet ont été élaborés. ® Les SGBD Objet

Selon Bouzeghoub [Bouzeghoub et al., 1997], une base de données objet est «!une organisation cohérente d’objets persistants et partagés par des utilisateurs concurrents!». Ainsi, partant du concept objet, il s’agit d’ajouter des mécanismes de persistance de ces objets1.

Selon Atkinson [Atkinson et al., 1989], les règles qui définissent un SGBDO viennent à la fois du paradigme objet et du paradigme des bases de données. Parmi les règles issues du paradigme objet, on retrouve, notamment, la capacité des SGBDO à gérer la persistance d’objets complexes!; le fait que chaque objet de la base possède un identifiant géré par le système. On retrouve également la possibilité de définir des types abstraits de données grâce aux notions de classe, d’encapsulation et d’héritage. Parmi les règles issues du paradigme des bases de données, on retiendra notamment la gestion de la persistance, de la concurrence d’accès, de la reprise sur panne et de la fiabilité des objets et la facilité d’interrogation.

L’utilisation de bases de données objet présente certains avantages par rapport aux bases de données relationnelles [Gardarin,!1999]. Tout d’abord développer une application objet avec un SGBDO se fait à l’aide d’un unique langage de programmation!: le langage de développement de l’application. Un objet de l’application peut alors être soit transiant*, soit persistant. Aucune opération de mapping n’est nécessaire puisque le modèle objet des données persistantes de l’application devient précisément le modèle de la base. L’héritage et le typage abstrait sont automatiquement supportés et le

1 Nous faisons ici la différence avec les bases de données relationnelles-objet qui partent plutôt des bases de données relationnelles et y insèrent des fonctionnalités issues du paradigme objet telles que l’héritage.

développeur n’a pas à gérer de numérotation des enregistrements de données car le SGBD assure cette numérotation grâce aux identifiants d’objet.

De plus, les SGBDO permettent une gestion plus simple des objets complexes!: par exemple, les objets composites peuvent être extraits de la base en une seule opération. En relationnel, la modélisation d’un objet se baserait sur plusieurs tables. L’extraction d’un seul de ces objets nécessiterait l’écriture d’une requête comportant autant de jointures que de niveaux de composition dans l’objet.

Tous ces avantages ont influencé notre décision à utiliser un SGBDO pour assurer la persistance des objets dans le forum DIACOM. D’une part, le choix d’utilisation d’un SGBDO nous permet de suivre le paradigme du «!tout objet!» ce qui présente de nombreux avantages en termes de cohérence du modèle et d’évolutivité du projet. D’autre part, nous avons été séduits par la facilité de gestion des objets composites. En effet, dans le modèle du forum, on peut remarquer qu’un cas se compose de scènes, elles-mêmes composées d’entités, elles-mêmes composées d’attributs valués. Il nous parait donc relativement efficace de pouvoir récupérer en une seule opération les cas dont une scène comporte une entité particulière, par exemple une entité de type «!fièvre!» ou «!douleur!».

Le marché des SGBDO est à l’heure actuelle assez limité. Il a pris naissance à la fin des années 80 et compte une quinzaine de sociétés de petite taille. Nous nous sommes orientés vers l’un des SGBDO les plus concurrentiels du moment et proposant un interfaçage avec le langage Java. Il bénéficie d’une bonne implantation sur le marché avec des clients comme France Telecom, BNP Paribas, British Telecom ou encore Thomson CSF. Ce SGBDO est Versant ODBMS (Object DataBase Managment System) de la société Versant [Versant - http].

® Le SGBDO Versant

Fondé en 1988 par des architectes d’Informix et d’Oracle, Versant constitue l’un des seuls SGBDO conçus d’abord comme un serveur de bases de données. Une application Java persistante est une application Java qui gère des transactions avec une (ou plusieurs) bases de données objet, dont le stockage et les modes d’accès sont gérés par le moteur de Versant, appelé «!Versant ODBMS!», par l’intermédiaire de l’interface «!Java Versant Interface (JVI)!». Versant dispose d’une architecture Client Serveur. Le serveur Versant fournit les mécanismes de stockage et d’extraction des bases de données, à travers son composant principal, appelé le «!Versant Storage Manager!». Le serveur s’occupe également de l’indexation, de l’exécution des requêtes, des logins et des verrous. Le client Versant gère et manipule à la fois des données transiantes et des données

persistantes. Son composant principal, appelé «!l’Object Manager!», gère les sessions d’application, maintient les informations de connexion avec la base et le cache d’objets pour réduire au maximum le trafic sur le réseau. La communication entre le client et le serveur de Versant se fait par le protocole TCP/IP.

L’interface JVI, peut être considérée comme une couche intermédiaire, ajoutée au client de Versant, pour permettre l’interprétation des objets en Java. En effet, comme le montre le figure 6.1 ci-dessous, l’Object Manager de Versant gère une couche en Langage C. JVI interprète cette couche pour la transformer en une collection d’objets en langage Java, interprétable par la JVM du client.

JVM OBJECT MANAGER JVM CLIENT VERSANT SERVEUR VERSANT JVI TCP / IP

Figure 6.1!: Architecture Versant - JVI

JVI propose deux packages Java utilisables par le développeur. Le premier package est appelé com.versant.trans permet de gérer un accès transparent aux objets persistants. Le second, appelé com.versant.fund, comporte les primitives de stockage des données. Ainsi, l’importation de ces deux packages dans le code de l’application java, permet à cette application de gérer directement en langage Java les transactions avec le (ou les) base(s) de données du serveur Versant.

Concernant l’accès aux objets dans une base, Versant propose deux moyens. Tout d’abord, il est possible d’accéder aux objets par navigation!: à partir d’un objet situé dans le cache client, l’activation d’un lien d’association issu de cet objet engendre automatiquement l’activation, et le rapatriement dans le cache de l’objet associé. Le second mode d’accès aux objets persistants, est la possibilité d’écrire des requêtes. Dans Versant, ces requêtes sont écrites en langage VQL (Versant Query Language). Il s’agit d’un langage proche de SQL, mais qui prend en compte la spécificité du modèle objet. Comme

le montre l’exemple de la figure 6.2 ci-dessous, en langage java, exécuter une requête consiste en l’instanciation d’un objet VQLQuery. La requête est ensuite exécutée (myquery.execute()) et l’ensemble des résultats obtenus est stocké dans un objet de type Enumération.

VQLQuery myquery = new VQLQuery

(transaction, SELECT * from Cas WHERE

LesScenes->LesEntites->Est_instance_de->Nom = « Fièvre »)

//Instanciation d’un objet //VQLQuery avec en paramètre //le texte de la requête;

Enumeration result = myquery.execute() ;

//Execution de la requête //Recupération des résultats

Figure 6.2!: Exemple de Requête VQL Java / Versant

On remarque notamment que les requêtes peuvent être basées sur plusieurs objets liés entre eux par des liens de composition ou d’association. Dans l’exemple ci-dessus, la requête concerne à la fois les classes «!Cas!», «!Scene!», «!Entité!» et «!Type d’Entité!». Ce type de requête est appelé une «!path-query!». A travers cet exemple, on mesure tout l’avantage d’un tel mode d’interrogation par rapport à une requête SQL effectuée sur un SGBDR.

L’utilisation de Versant comme SGBD pour notre application comporte pourtant le désavantage d’une installation et d’une mise en œuvre assez coûteuse en temps. A plus long terme, pour une mise en place officielle du prototype dans une formation à distance du domaine de la FMC, nous serons peut être amenés à repenser ce choix, d’une part pour tenir compte des contraintes matérielles et logicielles des organismes de FMC et d’autre part pour faciliter la maintenance et la mise en œuvre, qui nécessitent une certaine expertise des SGBDO.

Une fois les choix techniques établis, l’étape suivante dans le développement du prototype du forum DIACOM a consisté en l’implantation du modèle et de l’interface de description de cas (DIACOM-IA).