partie 3 utilisation de xml et des bases de données pour la...

Mourad Ouziri / Thèse en informatique / 2003 / Institut national des sciences appliquées de Lyon 74

Partie 3 Utilisation de XML et des bases de données pour la génération automatique d’enquêtes médicales

XML et les bases de données / Introduction


Chapitre 4 : Utilisation de XML et des bases de données pour la génération automatique d’enquêtes médicales

4.1 Introduction Actuellement, XML est le format le plus utilisé pour représenter les données sur le Web. De par sa simplicité et sa souplesse, le format de données semi-structurées est très sollicité dans l’ingénierie et la réingénierie des systèmes d'in-formation actuels, notamment sur le Web, dans le cadre des applications de commerce électronique (e-commerce), les bibliothèques virtuelles (digital libra-ries) et de plus en plus pour les systèmes d'informations médicaux. Les spécifi-cités de ce type de données font qu’il ne peut être modélisé en utilisant les mo-dèles des bases de données traditionnelles. Les données modélisées par les bases de données doivent être bien structurées avec un schéma stable donné a priori.

XML est un format de représentation très souple permettant de repré-senter très aisément les données semi-structurées. En effet, XML représente conjointement les données et les métadonnées dans une même structure. Etant donné que XML est un langage de balisage structurel, la sémantique des données est portée par les balises qui enveloppent les données. En recherche d’information, le moteur d’indexation consiste à extraire des termes significatifs à partir de textes bruts, c’est-à-dire non structurés, comme par exemple Georges Gardarin est l’auteur du livre “Bases de données”. Les données sur le Web sont semi-structurées, c’est-à-dire (entre autre) que le schéma et les données sont re-présentés dans une même structure. Le texte précédent peut être représenté, en XML, comme suit : <livre titre = “Bases de données”> <auteur> Georges Gardarin </auteur></livre>.

XML est indépendant de toute plateforme et véhicule des données auto-descriptives ; les balises représentent la structure des données et le texte (attaché aux balises) représente les données. Ces caractéristiques ont fait que XML est le format d’échange de données le plus utilisé entre les systèmes d’information et même entre les systèmes informatiques (échange de données entre matériels, protocoles réseaux, etc.). Dans une application du e-commerce, XML est utilisé pour formater puis envoyer les données concernant les produits vendus par un vendeur aux clients. Les clients présentent les données aux utilisateurs clients qui formulent des commandes. Les commandes sont formatées en XML et transmises au vendeur. XML facilite cet échange en proposant de présenter les

XML et les bases de données / Introduction


données et leurs structures dans une même représentation sans faire appel à d’autres structures lourdes associées aux données.

Parallèlement à XML, plus de 75% du volume d’informations sur le Web est stocké dans des bases de données, généralement relationnelles. Il est important de noter que la plupart des applications utilise les bases de données comme support de stockage des données à partir duquel sont générés les docu-ments XML qui circulent sur le Web. Vu les performances qu’offrent les bases de données relationnelles en termes de stockage, de sécurité et d’interrogation, il est improbable qu’elles cèdent à XML à ce niveau. Nous pensons plutôt à une coexistence entre ces deux paradigmes à deux niveaux de représentation diffé-rents ; les bases de données à un niveau plus bas pour le stockage et XML au ni-veau interface pour l’échange de données. Ceci constitue la principale raison qui nous a amené à étudier les relations entre XML et les bases de données relation-nelles.

Dans la suite de ce chapitre, nous présentons dans un premier temps une comparaison entre ces deux paradigmes puis le passage de XML vers le modèle relationnel et inversement. Nous avons réalisé un outil visuel de génération de documents XML à partir de bases de données relationnelles. Cet outil consiste en une interface graphique très facile à utiliser par des non informaticiens qui leur permet de personnaliser la structure, le contenu et la présentation des docu-ments créés. Nous avons proposé aussi une démarche utilisant conjointement les logiques de descriptions et les calculs statistiques pour le stockage de documents XML dans une base de données relationnelle. En se basant sur cette proposition, nous avons développé un système générique pour la conception d’enquêtes mé-dicales.

4.2 Comparaison entre le modèle relationnel et XML

Nous présentons dans cette section une brève comparaison de quelques aspects des bases de données et de XML. Le lecteur pourra trouver une comparaison plus détaillée dans [Kapp 01].

4.2.1 Objectifs L'objectif des bases de données relationnelles est de stocker de grandes masses de données dites alphanumériques d'une façon fiable, persistante et sécurisée

XML et les bases de données / Comparaison du modèle relationnel et XML


puis d’y avoir accès par interrogation. Par contre XML a été utilisé comme for-mat de représentation de données de type documentaire et hypertextuel.

Le modèle relationnel est une théorie qui offre un modèle de stockage de données alors que XML n'est qu'un format de représentation de données. Le stockage de documents XML nécessite donc l'utilisation d'un des modèles de stockage de données ou de documents qui peut être le relationnel lui-même.

4.2.2 Structuration des données La structure de documents XML est spécifiée en terme d’élément et d’attribut. Le relationnel définit le schéma de données par des tables relationnelles et d’attributs.

Les éléments d'un document XML peuvent être imbriqués ; un élément peut contenir un autre élément comme sous-élément qui se référencent mutuel-lement par le mécanisme d'attributs ID et IDREF. Dans le modèle relationnel, une table ne peut être composée que d'attributs élémentaires. La mise en relation entre deux ou plusieurs tables se fait par les Clés et les Clés étrangères. D'une façon similaire aux noms des relations dans un schéma relationnel, les noms d'éléments dans une DTD ou dans un XML Schema sont uniques.

4.2.3 Types de données La notion de type de données est utilisée différemment dans les deux paradig-mes. En relationnel, un type de données est obligatoirement associé à chaque at-tribut par le concepteur alors qu’en XML la notion de typage est facultative et les documents XML peuvent être édités sans la moindre précision du typage.

4.2.4 Identification Dans une table relationnelle, l'identification des tuples se fait d'une seule façon en définissant une clé primaire qui peut-être formée d'un ou de plusieurs attri-buts d’une relation. Dans un document XML, un seul attribut d'un élément peut-être désigné comme identifiant d’un élément grâce à l’attribut ID des DTD.

4.2.5 L'ordre Les éléments d'un document XML sont explicitement ordonnés par l'opérateur de séquence "," défini dans la DTD et les instances des éléments répétitifs sont

XML et les bases de données / Comparaison du modèle relationnel et XML


implicitement ordonnées. Les tuples d'une table relationnelle ne respectent au-cun ordre entre eux sauf qu'à l'interrogation un ordre de sélection des tuples peut-être précisé par le requérant.

4.2.6 Schéma prescriptif versus schéma descriptif Dans une base de données, le schéma de données est prescriptif. Cela signifie que lors des mises-à-jour, les données doivent être conformes au schéma. Dans le cas contraire, ces données ne peuvent être insérées dans la base. Par contre en XML, le schéma/DTD est descriptif puisqu’il se contente de donner la structure des documents mais il tolère toute mise-à-jour qui peut conduire à l’altération de cette structure.

4.3 Représenter les bases de données relationnelles en XML

Exporter le contenu ou une partie d'une base de données dans un ou plusieurs documents XML présente plusieurs avantages. Puisque XML est devenu le stan-dard d’échange de données, la génération de documents XML à partir de bases de données permettra d'échanger le contenu des bases de données avec toute au-tre application. Ceci facilitera la conception d'interfaces de communication habi-tuellement réalisées par des protocoles assez lourds. XML est un protocole sim-ple, efficace et permet d’échanger, dans un seul document, les données et les métadonnées d’une base de données. Le document XML généré à partir d'une base de données peut être considéré comme une vue de la base de données. Le document XML peut contenir la totalité des informations de la base ou unique-ment une partie. Ceci permettra donc de construire des vues sur les bases de données. Cette fonctionnalité est importante notamment pour le e-commerce. Considérons le schéma de la base de données d'un vendeur :

Produits (pid, label, catégorie, coût) Prix_Vente (pid, prix)

Ce schéma appartient au vendeur qui souhaiterait donner des vues restreintes de ce schéma à ses clients. Par exemple, le vendeur donne la possibilité à ses clients de consulter le label des produits, leur description et le prix de vente mais pas le coût de production des produits. Une fois que les données d’une vue de la base sont exportées sous XML, il est ensuite préférable de les présenter sous une forme conviviale aux clients. Ce point est encore l'un des avantages de XML qui permet de séparer le contenu de sa présentation. Ceci permet de per-

XML et les bases de données / Représenter les bases de données en XML


sonnaliser la présentation des données de cette vue à chaque client en créant le document XSL conséquent.

Nous présentons dans ce qui suit quelques systèmes de génération de documents XML à partir de bases de données, à savoir les systèmes e-XML XMLizer, DB2XML, XPERANTO et SilkRoute. Nous présentons notre applica-tion qui permet à l’administrateur de la base de données relationnelles de créer des vues en XML via une interface visuelle, conviviale et facile à utiliser.

4.3.1 Le système DB2XML DB2XML est un outil [Tura 99] de transformation de contenus de bases de don-nées relationnelles en documents XML. Il a essentiellement trois fonctions :

• Transforme le résultat d'une requête ou du contenu de la base de données en XML,

• Génère les métadonnées sous forme de DTD, • Transforme les documents XML générés en utilisant les feuilles de styles

XSLT en d’autres formats. DB2XML génère pour chaque table et pour chaque attribut un type

Element dans le document XML. Des métadonnées sont associées aux éléments grâce aux attributs. Par exemple, le texte de la requête SQL servant à générer la table ou la requête est représenté par l'attribut QUERY, le type de l'attribut de table relationnelle est représenté par l'attribut TYPE, l'attribut ISPKEY est égal à vrai si l'élément représente un attribut clé de la table, etc. L'élément racine de la DTD générée représente le contenu de plusieurs tables ou de résultats de requê-tes ou encore les deux. Le nom de cet élément peut être choisi par l'utilisateur, sinon c’est database par défaut. Cet élément a un seul attribut URL qui conserve l'adresse URL de la base de données dans une syntaxe spécifique au driver ser-vant de passerelle d'accès entre DB2XML et la base de données. Tous les tuples d'une table/requête sont regroupés dans un seul élément qui porte soit le nom de la table soit un nom système table_i (i est le numéro de séquence de la table dans la base de données). A cet élément sont associés les attributs QUERY, PKEY, FORKEY qui désignent respectivement le texte de la requête, l'élément qui représente la clé primaire de la table (liste de mots séparés par des virgules) et l'élément qui représente la clé étrangère. Un tuple d'une table est représenté par un élément portant par défaut le nom record_i (i est le numéro du tuple) contenant un élément pour chaque champ de la table. Oracle [Orac 98] a intégré un outil de publication de bases de données sous forme de documents XML. Les documents XML sont générés en appliquant les mêmes règles de transformation que nous venons de présenter.



4.3.2 Le système XPERANTO XPERANTO (Xml Publishing of Entities, Relationships, ANd Typed Objects) [Care 00] est conçu par IBM Almaden Research Center. C’est une interface d’interrogation (utilise la syntaxe XML-QL) et de génération automatique de vues XML à partir de bases de données de type objet-relationnel. Une vue d'une base de données est une description de son schéma en utilisant le standard W3C XMLSchema. Il permet de définir des types de données, des contraintes, des rela-tions d'héritages, des clés étrangères, etc. Par exemple, le XML Schema de la table 4.2 est une vue XML qui peut être créée à partir du schéma suivant :

Tableau 4.1 Définition d'un schéma objet-relationnel d'après [Care 00]

Une fois la vue XML créée, les utilisateurs peuvent formuler des requê-tes pour interroger ou définir d'autres vues plus restreintes sur cette vue en utili-sant XML-QL.

Create Table book AS (bookID CHAR(30), name CHAR(255), publisher VARCHAR(30)) Create Table publisher AS ( name VARCHAR(255), address VARCHAR(30)) Create Type author_type AS (bookID CHAR(30), first CHAR(255), last CHAR(30)) Create Table author OF author_type (REF IS ssn USER GENERATED)



Tableau 4.2 Une vue XMLSchema du schéma présenté par la table 4.1

Cette vue n’est utilisée que par l'administrateur qui définit grâce au lan-gage de requêtes XML-QL d’autres vues plus restrictives pour les utilisateurs. Les requêtes spécifiées sur la vue XML sont transformées dans une représenta-tion intermédiaire appelée XQGM (XML Query Graph Model) puis en SQL et exécutée par le langage de requêtes de la base de données.

4.3.3 Le système SilkRoute Dans SilkRoute [Fern 00], les données relationnelles sont exportées en deux éta-pes. Dans la première étape, une vue XML (virtuelle) est définie en utilisant un langage de requêtes déclaratif appelé RXL (Relational to XML Transformation Language). Ensuite, les utilisateurs (ou les applications clientes) peuvent formu-ler des requêtes sur la vue en utilisant le langage XML-QL pour extraire des données.

Le cœur du système est le langage RXL qui transforme les tables rela-tionnelles en documents XML. L'administrateur du système soumet une requête RXL décrivant une vue sur la base de données. Cette vue est interrogée par les utilisateurs de SilkRoute en utilisant des requêtes XML-QL. La requête RXL

<ComplexType name="bookTupleType"> <element name="bookID" type="string30"> <element name="name" type="string255"> <element name="publisher" type="string30">

<\complexType> <ComplexType name="bookSetType">

<element name="bookTuple" type="bookTupleType" maxOccuurs="*"/> <\complexType> <element name="book" type bookSetType"/> <ComplexType name="author_type">

<element name="bookID" type="string30"> <element name="first" type="string30"> <element name="last" type="string30">

<\complexType> <ComplexType name="authorTupleType" source="author_type" de-rivedBy="extension">

<attribute name="ssn" type="ID"> <\complexType> <ComplexType name="authorSetType">

<element name="authorTuple" type=" authorTupleType " maxOccurs="*"/> <\complexType> <element name="author" type="authorSetType"/>



(qui définit la vue) et la requête XML-QL (qui définit les données du requérant) sont fusionnées en une seule requête RXL. L’évaluation de cette requête génère le document XML spécifié par l'utilisateur. Pour mieux comprendre cette appro-che, considérons la requête RXL suivante qui définit une vue sur une base de données :

Cette requête produit une vue XML (stockée dans le fichier http://home/vue.xml) dont la structure est définie par la clause construct. Soit la requête XML-QL spécifiée sur la vue précédente :

Pour évaluer cette requête XML-QL, le système fusionne cette requête

avec celle de définition de la vue (écrite en RXL) et génère le résultat en RXL. La requête de fusion des requêtes RXL et XML-QL précédentes est :

from Patient $p, Exam $e where $p.degry = “level 3”, $p.nss = $e.nss construct <patient> <nom> $p.name <\nom> <date_naissance> $p.dob <\date_naissance > <médecin> $e.doctor <\médecin> <examen> <date> $e.date <\date> <résultat> $e.result <\résultat> <\examen> <\patient>

construct <results> {where <patient> <nom> $n <\nom> <examen> $e <\examen> <médecin> $m <\médecin> <\patient> in http://home/vue.xml, m = Pr. Peter construct <patients de Peter> <nom du patient> $n <\nom du patient > <examen du patient> $e <\examen du patient > <\patients de Peter > } <\results>

http://home/vue.xml

http://home/vue.xml



Cette requête est transformée en une ou plusieurs requêtes SQL et, après exécu-tion, le résultat est formaté dans le document XML dont la structure est décrite dans la clause construct de la requête de fusion.

4.3.4 Un outil graphique de génération de vues conceptuelles en XML à partir de bases de données relationnelles

4.3.4.1 Démarche

Aucun des systèmes présentés ne produit une vue XML générée à partir du schéma conceptuel de la base de données. Le système DB2XML produit un do-cument XML qui représente directement les tables et leurs attributs par des élé-ments dans le document XML sans tenir compte des relations qui peuvent exis-ter entre ces tables. Les systèmes XPERANTO et SilkRoute offrent à l'utilisateur un langage de construction de vues XML sur des bases de données. Il est évident que seul l’administrateur de ces systèmes peut utiliser ce langage puisqu'il n'y a que lui qui connaisse le schéma de la base de données. De plus, l'utilisation du système SilkRoute nécessite la connaissance du langage de définition de vues RXL. Le système XPERANTO définit une vue globale en XMLSchema sur toute la base de données et ensuite l'administrateur formule des requêtes XML-QL qui définissent des sous-vues. Pour de gros schémas complexes, la vue représentée dans un document XMLSchema peut être illisible pour l'administrateur afin qu'il puisse définir des sous-vues.

L'idée de notre proposition est d'utiliser le schéma conceptuel de la base de données relationnelle pour établir la représentation des données de la base

construct <results> { from Patient $c, Exam $e where $p.degry = “level 3”, e.doctor = Pr. Peter, $p.nss = $e.nss construct <patient de Peter> <nom du patient> $p.name <\nom du patient> <examen du patient> <date> $e.date <\date> <résultat> $e.result <\résultat> <\examen du patient> <\patient de Peter> } <\result>



sous forme de documents XML. Nous avons proposé un outil graphique de conception de vues XML très facile à utiliser qui ne nécessite pas de connaître aucun langage de requête ni le schéma de la base de données. Afin de donner plus de sens aux documents XML générés et pour augmenter la compréhension des données par l'utilisateur, celles-ci doivent avoir une disposition conforme à la structure conceptuelle de la base. Pour illustrer cet aspect, nous allons pro-duire à partir de la base de données de la table 4.3 deux documents XML. Le document a) est généré directement en transformant les tables et les attributs en éléments XML et pour générer le document b) nous avons tenu compte du sché-ma conceptuel de la base de données.

Tableau 4.3 Deux manières pour générer une structure XML à partir d’un schéma E/A

Les règles de la génération automatique de document XML (en tenant compte de la structure du schéma conceptuel) sont les suivantes : • Nous créons un élément pour chaque table (qui porte le nom de la table). Cet

élément possédera comme sous-éléments les attributs de la table concernée sans les clés étrangères.

• Pour toute relation de type (1-n), l’élément XML de la table (source de la dépendance fonctionnelle – cardinalité 1) deviendra un sous-élément de l’élément de la table (source de la cardinalité n).

• Concernant les relations de type (n-n), deux représentations peuvent être gé-nérées. Ces deux formalismes produisent deux documents XML contenant les mêmes données (et la même sémantique).

<database> <facture> <nf> <date> <prix_total> <\facture> <article> <na> <libelle> <pu> <\article> <ass_f_a> <nf> <na> <qt> <\ass_f_a> <\database>

<database> <facture nf=42> <date> <prix_total> <article na=132> <libelle> <pu> <qt> <\article> <\facture> <\database>

facture (nf, date, prix_total) article (na, libelle, pu) ass_f_a (nf, na, qt)

a) b)



Figure 4.1 Représentation XML d’une association (n-n) La procédure présentée ci-dessus fournit une traduction de toute la base

de données en schéma XML. Cependant, l’utilisateur peut ne vouloir exporter que les données vérifiant certaines conditions. Pour cela, notre outil graphique de conception d’un schéma XML permet aux utilisateurs de spécifier leurs pro-pres conditions à travers des formulaires.

4.3.4.2 Description de l’outil graphique

L’outil graphique visualise le schéma conceptuel de la base de données. L’utilisateur peut composer sa vue graphiquement en sélectionnant les tables et les attributs utiles pour la création de sa vue (figure 4.2). Cette sélection se fait de manière conviviale par clicks souris sur les tables puis sur les attributs des tables. Les conditions et contraintes sont spécifiées dans une fenêtre. Au fur et à mesure des sélections, le système produit le document XML généré en temps ré-el. Le système génère un document XML à partir d’un schéma EA selon deux modes : • Mode automatique : Dans ce mode, le système génère la structure du docu-

ment XML automatiquement sans l’intervention de l’utilisateur. La structure du document est définie à partir des associations entre les entités et de leurs cardinalités et des préférences (modèle de l’utilisateur) de l’utilisateur.

• Mode assisté : L'utilisateur peut intervenir pendant le processus de généra-tion de la structure du document XML pour sélectionner les tables et choisir leur ordre d'attachement dans le document. Par exemple, pour une associa-tion triple liant les trois entités Patient, Médecin et Hôpital, le système pro-pose à l’utilisateur les deux structures XML suivantes : <Patient><Médecin><Hôpital></Médecin></Patient>, ou <Patient><Hôpital><Médecin></Hôpital></Patient> pour le sujet Patient.

Patient MédecinN N

<Patient> <nom> <Médecins> <Médecin> <Médecin> </Médecins> </Patient>

<Médecin> <nom> <Patients> <Patient> <Patient> </Patients> </Médecin>



Figure 4.2 Construction visuelle d’une vue en XML à partir d’un schéma EA

4.3.4.3 Génération du code

Le générateur de code du système traduit les actions de l’utilisateur en code JA-VA et en requêtes SQL d’accès à la base de données. La table 4.4 montre le pseudo-code du noyau de cette interface. Les noms des tables sélectionnées sont insérés dans une variable Tables_Select qui est mise à jour lors de chaque sélec-tion d’une table (par un click souris sur la table). Le code associé est donc tota-lement intégré dans le traitement de la procédure événementielle du click souris. Le pseudo-code est le suivant :



Tableau 4.4 Pseudo-code de génération de documents XML à partir d’une base de donnée

4.4 Modélisation relationnelle de documents XML

XML est un format de documents utilisé pour représenter tous types de contenu. Selon son contenu, un document XML est soit orienté données soit orienté texte/paragraphes. Le contenu de documents XML orientés texte est composé de paragraphes écrits en langue naturelle. Ces paragraphes ont une structure irrégu-lière et leur taille est relativement grande et variable. L’ordre des balises du do-cument est souvent très important. Contrairement au document orienté texte, le document XML orienté données contient des fragments de données de très peti-tes granularités, sa structure est assez régulière et l’ordre des balises du docu-ment est relativement peu significatif.

Dans nos travaux concernant la modélisation relationnelle de docu-ments XML, nous considérons uniquement les documents XML orientés don-nées. Pour les documents XML orientés texte, nous pensons qu’un système de gestion de documents est plus adapté que les bases de données. D’une part les bases de données offrent des fonctions très limitées pour rechercher dans du texte (elles se limitent au prédicat contains et l’utilisation des caractères généri-

Pour chaque table sélectionnée (stockée dans Table_Select) faire NoeudTable = Générer_Nœud (« < »Nom_Table »> ») ; Pour chaque attribut sélectionné faire Liste_attributs.ajouter (attribut) ; Critère.ajouter (attribut.critère) ; Générer_SQL (« SELECT Liste_attributs FROM Nom_Table WHERE Critère ») ; Pour chaque tuple T de la requête faire Pour chaque attribut dans Liste_attributs faire Nœud_attribut = Générer_Nœud (attribut, T.attribut) ; NoeudTable.ajouterNoeud (Nœud_attribut) ; Pour toute table Table ayant une relation faire Soit N_T le nœud associé à la table Si type (relation) = « 1-n » alors N_T.ajouterNoeud (NoeudTable) ; Si type (relation) = « n-1 » alors NoeudTable.ajouterNoeud (N_T) ; Si type (relation) = « n-n » alors Deux choix sont possibles NoeudTable.ajouterNoeud (N_T) ; Ou N_T.ajouterNoeud (NoeudTable) ; FIN

XML et les bases de données / Modélisation relationnelle des documents XML


ques * et ?). D’autre part, le texte est généralement non structuré tandis que les bases de données sont dédiées à stocker et à interroger des données fortement structurées. Néanmoins, le stockage de ce type de documents dans les bases de données est possible en les structurant davantage pour pouvoir passer du docu-ment orienté texte au document orienté données [Badr 01]. Ceci conduit à utili-ser les techniques de traitement de la langue naturelle.

Le stockage de documents XML peut se réaliser soit en créant une base de données native XML soit en représentant les données XML par un schéma re-lationnel. Dans la première solution, le document XML est stocké sur un support quelconque pouvant être une base de données relationnelle mais sa structure en balises (telle qu’elle est définie dans une DTD), est préservée. Pour interroger les données, ces systèmes utilisent des langages tels que XML-QL [Deut 99], XQL [Robi 98] ou Quilt [Robi 00]. Ces langages reposent généralement sur le modèle OEM. Nous nous intéressons plus particulièrement à la deuxième appro-che de stockage, qui consiste à représenter les documents XML en utilisant le modèle relationnel.

Pour stocker des documents XML dans une base de données, il faut d’abord définir le schéma (relationnel, objet, objet/relationnel) des données. La conception de schémas à partir de documents XML est dirigée soit par la struc-ture en arbre soit par la structure donnée par la DTD.

4.4.1 Modélisation basée sur la structure en arbre Dans cette approche, un document XML est considéré comme un arbre orienté et étiqueté dans lequel les nœuds internes représentent les éléments du document, les feuilles représentent les données ou les attributs et les arcs formalisent les re-lations de contenance élément-sous-élément ou élément-attribut et sont étiquetés par le nom du sous-élément.

Il est évident que plusieurs schémas relationnels peuvent représenter un arbre XML. Le modèle de MONET [Schm 00] formalise un document d par un quadruple M(d) = (r, R, A, T) où:

- R est l'ensemble des relations binaires entre tous les nœuds de l'arbre, - A est l'ensemble des relations binaires associant les nœuds et leurs

valeurs ou leurs attributs, - T est l'ensemble des relations binaires associant les nœuds avec leurs

numéros d'ordre, - r est la racine du document.

Les nœuds, les valeurs et les attributs du graphe sont des objets et les associa-tions sont des arcs entre les oids des objets associés. Un modèle dit hybride a été développé pour le système NATIX [Kann 99]. Ce système utilise un modèle de stockage à objets physiques et considère la taille des nœuds et des pages-disques



pour optimiser le stockage des nœuds du document. Dans les travaux présentés dans [Vaka 00], les documents sont représentés à deux niveaux : le niveau intra-document représenté par les liens de composition d’éléments et le niveau inter-documents représenté par des liens inter-documents. Le modèle objet a été utili-sé pour le stockage des nœuds qui sont de deux types : • Les nœuds de type éléments qui représentent le méta-modèle utilisés pour la

navigation dans les documents ; ces nœuds sont stockés dans une mémoire cache pour être accessibles directement et rapidement.

• Les nœuds objets qui représentent les données (feuilles de l'arbre) et qui sont stockés dans une mémoire de masse (disques magnétiques ou disques opti-ques).

Dans [Flor 99], Florescu et al ont présenté six schémas relationnels pour représenter un graphe XML : trois façons pour représenter les arcs et deux façons pour les feuilles. Le schéma le plus simple consiste à représenter le gra-phe dans une seule table, appelée Edge, dont la structure est la suivante :

Edge (source, target, name, flag, ordinal) Un enregistrement de cette table contient les id des nœuds source et destination, le nom de l'arc, la nature de l'arc (inter-éléments, pointe un attribut ou une don-née) et un attribut d'ordre pour identifier l'ordre entre les arcs d'un élément. Les données peuvent être stockées soit comme attributs de la table Edge ou dans une table séparée ce qui imposera des opérations de jointure au moment de l'explora-tion de la base (le lecteur trouvera un exemple d’illustration dans [Flor 99]).

Un autre modèle est présenté dans [Shim 99]. La particularité de ce modèle est qu'il stocke le chemin de chaque élément dans la table sous une forme textuelle afin de faciliter l'évaluation de requêtes contenant des expres-sions de chemins et d'accélérer la reconstruction des documents XML à partir des tables.

e-XMLMedia [eXML 02] a développé une suite logicielle, appelée e-XML [Gard 02], qui permet l’accès aux données stockées dans des documents XML ou dans des bases de données (objet) relationnelles. De part son architec-ture modulaire, cette suite est composée de plusieurs outils (e-XML Mediator, e-XML Repository, XML/DBC) pouvant être utilisés séparément. Le composant e-XML Repository permet de stocker des documents XML dans une base de don-nées. Ce mapping est réalisé selon deux approches : générique et orienté-schéma. Dans l’approche dite générique, un schéma relationnel est créé à partir du document XML et les données sont rangées dans les tables suivant des direc-tives automatiquement créées. Dans l’approche dite orienté-schéma, les docu-ments XML sont stockés dans un schéma existant suivant des directives qui sont données par l’administrateur de la base.

L'avantage de cette approche est qu'elle produit un schéma générique. En effet, le point de départ de cette approche est la structure d'arbre que possède



tout document XML et les tables stockent à la fois la structure (les balises et leurs liens) et les données. La base de données peut loger donc n'importe quel document XML quelque soit sa DTD (y compris ceux qui n’en possèdent pas). Cette approche est bien adaptée pour la conception de wrapper pour la fédéra-tion de sources de données hétérogènes. De plus, la reconstruction du document original est très fiable et est très simple (se fait donc en un temps négligeable) quand on veut échanger le contenu de la base. Nous pensons que ce modèle fournit un bon support pour établir une algèbre notamment pour les opérations de structure telles que : la navigation dans les documents, l'union, l'intersection et la différence entre des documents XML, etc.

Ce modèle manipule un document XML comme une structure d'arbre et ignore complètement la sémantique des données. Les mises-à-jour de la base de données peuvent donc provoquer des incohérences sémantiques. En terme d'es-pace de stockage, pour chaque document sont stockées les informations de struc-ture et de données ; deux documents ayant la même structure et traitant d’un même sujet (contexte) sont stockés indépendamment l’un de l’autre. Aucun lien n’existe entre eux, ce qui conduit à dupliquer la structure de documents identi-ques.

4.4.2 Modélisation basée sur la DTD Une DTD (Document Type Definition) est un format de description de la struc-ture d'une collection de documents XML. Dans certaines applications, l'absence de DTD rend difficile d'extraire les similarités entre les structures des docu-ments et de trouver un schéma commun optimal. La génération du schéma d’une base de données à partir d’une DTD est une opération simple et directe puisque le contenu de la DTD est un ensemble de directives qui décrivent la structure des documents. La conception d'un schéma d'une base à partir d'une DTD peut se faire par plusieurs façons en fonction du modèle de données à générer, à savoir le relationnel [Shan 99], le relationnel-objet [Klet 99] ou l'objet pur [Chri 94]. La procédure de génération d'un schéma relationnel à partir d'une DTD dépend donc du modèle cible.

Une des caractéristiques de XML est qu'il a beaucoup de similarités avec le modèle objet. La génération du schéma objet à partir d'une DTD est plus facile. L'inconvénient de cette approche est lié aux performances du modèle ob-jet. En effet, les apports sémantiques du modèle objet ne peuvent seuls compen-ser ses performances insuffisantes ce qui l'a empêché de se stabiliser sur le plan commercial. Or, le modèle relationnel (en usage depuis les années 70), qui connaît toujours un vif succès de part sa simplicité, son algèbre et l'efficacité des SGBD qui le mettent en œuvre a été sollicité pour servir comme modèle et sup-port de stockage des documents XML et de faire encore preuve de sa perfor-



mance et de sa validité malgré l'émergence de nouvelles technologies de l'infor-mation. Le modèle relationnel s'est avéré insuffisant pour représenter des struc-tures complexes telles que les images, le son, la vidéo, etc. Des fonctionnalités ont été ajoutées notamment en introduisant les notions de type abstrait de don-nées, d'objet et d'identificateur d'objet.

Cette approche nécessite l'existence d'une DTD et elle génère un sché-ma d'une base de données dédiée pour stocker des documents XML validant la DTD qui ont servi à générer cette base. L'utilisation de cette base se restreint donc à une application dédiée et ne peut être utilisée comme support pour loger des documents ayant des structures différentes.

4.4.3 Représentation de documents XML en utilisant les Logiques de Descriptions (LD)

La logique de descriptions est un formalisme à la fois de représentation termino-logique et de raisonnement. Un document XML porte à la fois des données ainsi que leurs descriptions (méta données). Il est donc possible de représenter XML en utilisant les logiques de descriptions. La description des données d’un docu-ment est donnée par les noms des balises et les relations de composition entre el-les. Cette approche a été suffisamment explorée dans la littérature. Par exemple, [Calv 99] a présenté une démarche de génération d’une base de connaissances en LD à partir de DTD. Chaque élément d’une DTD est représenté dans la base de connaissances par deux rôles f et r (first et rest respectivement) où f représente la racine de l’élément et r représente le reste de l’arbre de l’élément. Pour un document d, le rôle f représente l'élément racine, le rôle (r° f) représente le pre-mier sous-élément, (r° r° f) le deuxième sous-élément et le dernier élément par rh+1 (h est le nombre de sous-éléments de d). La TBox est définie comme suit: Tag ⊑ ∀ (f ∪ r).⊥ Terminal ⊑ ∀ (f ∪ r).⊥ П ¬ Tag F ⊑ Terminal pour tout terminal F F1 ⊑ ¬F2 pour toute paire de deux terminaux différents StartE ⊑ Tag pour tout élément E EndE ⊑ Tag pour tout élément E et pour un élément E défini par E x dans la DTD

ED ≡ ∃ f.StartE П ∃ (r ° τ(x)).EndE

où τ est un rôle complexe utilisé pour définir x. Il est défini comme suit :

τ (S) = id(∃f.ac(D, S))°r

τ (x1 | x1) = τ (x1) ∪ τ (x1)



τ (x1 , x1) = τ (x1) °τ (x1)

et ° est un constructeur de concaténation de rôles et id est un constructeur d’identité :

[R1° R2] I = R1I ° R2

I [id(C)] I = {(o,o) | o ∈ CI} Appliquons ces règles sur les éléments d’une DTD D suivants : <!ELEMENT Adresse (Rue, Ville)> <!ELEMENT Rue (#PCDATA)> <!ELEMENT Ville (#PCDATA)> La TBox qui représente cette DTD est composée des axiomes suivants :

AdresseD ≡ ∃ f.StartAdresse ⊓ ∃ (r°id(∃f.RueD)°r°id(∃f.VilleD)°r).EndAdresse

RueD ≡ ∃ f.StartRue ⊓ ∃ (r°id(∃f.PCDATA)°r).EndRue

VilleD ≡ ∃ f.StartVille ⊓ ∃ (r°id(∃f.PCDATA)°r).EndVille Cette représentation permettra d’utiliser les raisonnements de subsomption, d’équivalence, et de disjonction pour tester la validité d'un document à une DTD, l'inclusion et la disjonction entre DTDs.

Dans [Haci 00], un algorithme (appelé Genк) de génération d'une base de connaissances dans la logique de descriptions à partir d'un graphe semistruc-turé a été présenté. L'algorithme génère pour chaque arc (oi, l, oj) l'instance du rôle l(oi, oj). Une assertion est ajoutée à la BC pour chaque objet qui dénote la structure de l'objet, en terme de LD, dans le graphe. Cette assertion correspond au calcul de la structure la plus spécifique en partant du nœud de l'objet jusqu'à atteindre les feuilles.

ED si S est un élément Eac (D, S) = F si S est un terminal F



Tableau 4.5 L’algorithme Genк de génération d'une BC à partir d'un graphe semi-structuré Cet algorithme consiste à générer d’abord la ABox à partir du graphe de données semi-structurées et génère ensuite la TBox à partir de cette ABox comme suit :

• Pour chaque objet o de la ABox, ajouter l’axiome No ≡ δo où No est le nom du concept représentant l’objet o et δo est une description termino-logique de No obtenue en calculant le msc (most specific concept) de o.

La TBox n’étant qu’une traduction de la ABox, les différentes descriptions d’un même concept sont fusionnées en une seule description. Cette fusion est réalisée par un algorithme, appelé ComT, en calculant le lcs (least common subsumer) de k concepts (K est un paramètre).

4.4.4 Proposition : une approche combinant la logique de descriptions et les statistiques pour générer un schéma relationnel normalisé et optimisé

Dans un document XML, les balises sont des métadonnées sur les données qu’elles enveloppent. Nous exploitons donc ces balises pour générer un schéma relationnel normalisé et optimisé. Pour cela, nous procédons en deux étapes : 1. Dans la première étape, une base terminologique TBox est créée à partir des

documents XML. Chaque axiome de cette TBox représente un élément com-

Input : DB = (Va ∪ Vc, E, L, v, r) // graphe de données Output : K = (Ts, A) // base de connaissances // étape 1 : génération de la ABox A Pour chaque (oi,l,oj) ∈ E faire A A∪ {l(oi,oj)} // étape 2 : Générer la TBox Ts // Traitement des objets atomiques Pour chaque oi ∈ Va faire Noi type(oi) // Noi est un nom de concept // Traitement des objets composés Pour chaque oi ∈Vc faire δoi ∅ // calcul de la structure exacte de chaque objet Pour chaque l(oi, oj) faire

δoi δoi ⊓ ∃l.Noj Pour chaque δoi généré faire Ts Ts ∪ {Noi ≡ δoi} // étape 3 : fusionner les concepts équivalents Fusionner les concepts équivalents de Ts Return KB = (Ts, A)



posé (défini par le constructeur ELEMENT des DTD) et les éléments sim-ples/attributs (PCDATA/ATLIST) sont représentés par des rôles. Afin de gé-nérer un schéma normalisé, des connaissances ontologiques sont ajoutées sous forme d’axiomes à la TBox. Les raisonnements logiques permettent de calculer automatiquement des relations conceptuelles entre les éléments XML représentés par des concepts de la TBox ce qui nous permet de calculer un premier schéma relationnel non optimisé.

2. Tandis que la première étape opère au niveau conceptuel des documents, cette deuxième étape opère au niveau des instances (données elles-mêmes). Elle consiste à optimiser le schéma créé dans la première étape en réduisant le nombre de tables. Cette optimisation est faite en calculant quelques mesu-res statistiques sur les données des documents XML.

Le schéma de la figure suivante résume notre démarche.

Figure 4.3 Schéma de génération d’un schéma relationnel à partir de XML

4.4.4.1 Génération de schémas relationnels normalisés

Le but de cette étape est de générer un schéma relationnel normalisé à partir de documents XML. Ce schéma sera optimisé par la suite dans la deuxième étape. La normalisation dans le modèle relationnel est une tâche du niveau conceptuel. Or, XML ne fournit que des métadonnées sur la structure des données d’un do-cument. Pour formaliser la structure des éléments de document XML nous utili-sons les LD. Les LD permettent de représenter (formaliser) des descriptions terminologiques d’entités et de raisonner sur ces descriptions. La description d’un élément XML est donnée par les balises qui le composent. Ces balises ne donnent aucune information quant à la structure conceptuelle des éléments. Afin de générer un schéma conceptuel normalisé, nous utilisons conjointement les descriptions structurelles et les éléments des axiomes extraits à partir d’une on-tologie du domaine. Le tout est représenté dans une seule TBox.



Les structures des éléments des documents XML à stocker sont repré-sentées par des descriptions conceptuelles/terminologiques dans une TBox. Les descriptions d’un même concept sont ensuite fusionnées pour extraire une struc-ture commune. Un premier schéma relationnel est enfin généré.

Soit à stocker les deux structures de documents XML suivants :

En considérant ces documents, nous expliquons dans ce qui suit la démarche de génération d’un premier schéma relationnel conceptuel à partir de leurs structu-res. Première étape : représenter les documents dans une TBox

Cette étape consiste à représenter les structures des éléments des docu-ments XML par des descriptions conceptuelles dans une TBox. Pour cela, nous suivons la même procédure que [Haci 00], à savoir :

• Représenter l’élément simple (sans sous-éléments) f par l’axiome Tf ⊑ Type où Type ∈ [String, Number, Date] est le type du contenu de la balise feuille f. Exemple : Tnom ⊑ String, Tddn ⊑ Date, Tdirige⊑ Service

• Représenter d’une façon incrémentale (du niveau de profondeur le plus interne vers les niveaux externes) chaque élément complexe e par l’axiome : Ce ⊑ ∀a1.Ta1 П … П ∀an.Tan П ∀r1.C1 П … П ∀rn.Cn où a1,…, an

sont des noms de rôles représentant les attributs et les éléments simples de l’élément e, et r1,…,rn sont des noms de rôles (extraits à partir d’une ontologie) associés respectivement aux sous-éléments représentés par Cf,

…, Ck et Cf, …, Ck précédemment créés dans la TBox. Exemple : les éléments complexes Hôpital et Patient (Patient est plus in-terne que Hôpital dans la hiérarchie du document) du document de gau-che sont représentés par :

<Hôpital nom> <unités> <Malade id> <nom> <adresse> <rue> <ville> </adresse> <Médecin idM> <spécialité/> <ordonnance/> <\Médecin> <\Malade> </Hôpital>

<Hôpital nom> <services> <Patient n°> <nom/> <ddn> <adresse\> <Médecin id> <dirige refService/> <dateSoin/> <résultat/> <\Médecin> <\Patient> </Hôpital>



Patient ≡ ∀ nom.String ⊓ ∀ ddn.Date ⊓ ∀ adresse.String⊓ ∀ role.Médecin Hôpital ≡ ∀ nom.String ⊓ ∀ patient.Patient1 ⊓ ∀ service.Service

Deuxième étape : renommer les noms des concepts, attributs et rôles

Plusieurs éléments dans un ou plusieurs documents représentant une même entité sémantique peuvent s’appeler différemment. Par exemple, dans l’exemple précédent, les éléments Patient et Malade et les attributs n° et id font référence à une même entité. Cette phase consiste à utiliser les relations de sy-nonymie pour uniformiser le vocabulaire utilisé. A cette étape, la TBox représen-tant les deux documents précédents est :

Hôpital1 ≡ ∀ nom.String ⊓ ∀ patient.Patient1 ⊓ ∀ service.Service

Hôpital2 ≡ ∀ nom.String ⊓ ∀ malade.Malade2 ⊓ ∀ service.Service

Patient1 ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ ddn.Date ⊓ ∀ examiné-Par.Médecin1

Malade2 ≡ Patient2 ≡ ∀ nom.String ⊓ ∀ adresse.Adresse2 ⊓ ∀ ddn.Date

⊓ ∀ examinéPar.Médecin2

Médecin1 ≡ ∀ idM.Number ⊓ ∀ dirige.Service ⊓ ∀ dateSoin.Date ⊓ ∀ résultat.String

Médecin2 ≡ ∀ idM.Number ⊓ ∀ spécialité.String ⊓ ∀ résultat.String

Adresse2 ≡ ∀ rue.Integer ⊓ ∀ ville.String A ce stade de la représentation, nous pouvons générer un schéma relationnel en créant une table pour chaque concept. Dans la TBox, un concept peut être repré-senté par plusieurs descriptions. Afin d’éviter que les attributs de la table rela-tionnelle d’un concept ne contiennent des valeurs nulles, la structure de la table représentant un concept C défini par les descriptions C1, C2,…, Cn est naturelle-ment composée des attributs de leur partie commune. Par exemple, le concept Patient est défini par les deux descriptions Patient1 et Patient2. La structure de la table relationnelle créée pour ce concept est la suivante : Patient(nom : String, ddn : Date, examinéPar : refMédecin) Nous appelons cette table la table primaire du concept Patient. La structure commune d’un ensemble de descriptions d’un même concept peut être obtenue en utilisant le raisonnement lcs (Least Common Subsumer). Donc :

Hôpital ≡ lcs(Hôpital1, Hôpital2) ≡ ∀ nom.String ⊓ ∀ patient.Patient ⊓ ∀ service.Service Patient ≡ lcs(Patient1, Patient2) ≡ ∀ nom.String ⊓ ∀ ddn.Date ⊓ ∀ examinéPar.Médecin



Médecin ≡ lcs(Médecin1, Médecin2) ≡ ∀ idM.Number ⊓ ∀ résul-tat.String

La base de connaissances terminologiques TBox peut être représentée après avoir calculé les lcs des concepts par le schéma conceptuel suivant :

Figure 4.4 Représentation graphique de la TBox Les tables primaires correspondent donc aux tables créées pour les lcs des diffé-rentes descriptions de chaque concept. Le schéma de la base de données rela-tionnelles contiendra les tables primaires suivantes :

Hôpital(id : numéroSyst, nom : String, patient : refPatient, service : ref-Service) Patient(id : numéroSyst, nom : String, ddn : Date, examinéPar : refMé-decin) Médecin(idM : number, résultat :String) Service(…)

Les rôles qui ne font pas partie des concepts lcs composent les tables que nous appelons les tables secondaires. Par exemple, les tables secondaires suivantes sont créées :

Patient1(id : numéroSyst, adresse : String) Patient2(id : numéroSyst, adresse : refAdresse) Médecin1(idM : number, spécialité : String) Médecin2(idM : number, dateSoin : Date)

Troisième étape : ajout d’axiomes de normalisation

Patient

Médecin2 Médecin1

Service

Hôpital

Patient1 Malade2

Légende Rôle Subsomption

nom ddn

idMadresse Adresse2

villerue

résultat

nom

Médecin

spécialité dateSoin

examinéPar

examinéPar

examinéPar

servicepatient



La TBox générée dans l’étape précédente représente les éléments XML tels qu’ils sont décrits dans les documents. Nous constatons que les tables Mé-decin et Médecin2 sont définies, entre autre, par les attributs résultat et date-Soin, respectivement. Or, la valeur de ces attributs ne dépend pas uniquement de Médecin mais aussi de Patient, car ce sont des attributs d’association. Ceci dit, la définition des concepts de la base de connaissances ne se représente pas par un schéma conceptuel E/A normalisé. Ceci est un problème typique qui se pose pour des associations de type (N,N). Le problème des associations de type (1,N), tel que présenté par les tables primaires Hôpital et Patient consiste en un mau-vais positionnement des clés étrangères. Dans un schéma normalisé, la clé de la table du concept “du côté N” est ajoutée comme clé étrangère à la table du concept “du côté 1”. Or dans le schéma précédemment créé, c’est la clé de Hôpi-tal (côté N) qui devrait se trouver comme clé étrangère dans la table Patient et non pas l’inverse. Les types d’associations entre les concepts peuvent être calcu-lés à partir des dépendances fonctionnelles. Les dépendances fonctionnelles peuvent être à leur tour calculées à partir des documents XML en utilisant des techniques de datamining [Nove 00].

Pour les associations de type (N,N) entre les concepts de la TBox nous ajoutons un concept représentant l’association qui contiendra les attributs d’association extraits à partir des concepts et un rôle faisant référence à chaque concept. Par exemple, pour les concepts Patient et Médecin nous ajoutons à la TBox le concept d’association Examen suivant :

Examen1 ≡ ∃ pat1.Patient1 ⊓ ∃ méd1.Médecin1 ⊓ ∀ dateSoin.String ⊓ ∀ résultat.String ⊓ = 1 résultat.String ⊓ = 1 dateSoin.Date Examen2 ≡ ∃ pat2.Patient2 ⊓ ∃ méd2.Médecin2 ⊓ ∀ résultat.String ⊓ = 1 résultat.String

Pour augmenter l’expressivité des descriptions de la TBox, notamment de Pa-tient et Médecin, nous ajoutons une référence vers le concept d’association Examen. Pour le concept Patient, cette référence représente tous les examens subis par un patient. Cette référence n’est autre que celle représentée par le rôle pat du concept Examen. En logique de descriptions, ce type de références est formalisé par la notion de rôle inverse :

Patient1 ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ ddn.Date ⊓ ∀ pExam1.Examen1 pExam1 ≡ pat1-1

Le rôle pExam1 est un rôle inverse du rôle pat1-1, c’est-à-dire : ∀ p∈ Patient1I, ∀ e∈ Examen1I, pat1(e,p) ⇒ pExam(p,e)

Cela signifie qu’il suffit de déclarer, dans la ABox, les instances du rôle pat1 (respectivement pExam) et le moteur d’inférence logique déduit les instances du rôle pExam (respectivement pat1). Si la ABox est définie par les assertions : Patient1(p1) Examen1(e1) pat(e1,p2)



Patient1(p2) Examen1(e2) pat(e2,p1) les assertions suivantes seront automatiquement inférées pour le rôle pExam : pExam(p1,e2) pExam(p2,e1) Ces rôles inverses ne sont pas représentés dans les tables créées pour le concept d’appartenance.

Pour les associations de type (1,N), nous ajoutons un rôle inverse dans la description du concept référencé. Par exemple, en supposant que les concepts Hôpital et Patient sont associés par une association (1,N), le concept Patient est référencé dans Hôpital par le rôle patient. Nous ajoutons à la description du concept Patient un rôle inverse au rôle patient qui fait référence au concept Hô-pital :

Patient1 ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ ddn.Date ⊓ ∀ pExam1.Examen1 ⊓ ∀ hôp1.Hôpital1 hôp ≡ patient1-1

Quatrième étape : traitement des contraintes d’intégrité

L’utilisation des LD nous permet de représenter et de raisonner sur des contraintes spécifiées sur les attributs/rôles. Considérons l’exemple suivant :

Patient1 ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ âge.Number ⊓ âge ≥ 18 Patient2 ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ âge.Number ⊓ âge < 18 Patient3 ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ âge.Number ⊓ âge ≥ 20

Le lcs des concepts Patient1 et Patient2 est nul ce qui signifie que les individus représentés par ces deux entités sont disjoints. Donc, les deux descrip-tions Patient1 et Patient2 représentent deux sous-concepts différents et nous pouvons procéder selon l’une des deux façons suivantes :

1. Deux tables relationnelles sont créées pour chacun de ces deux sous-concepts. Chaque table est créée en considérant les contraintes données dans la description de son sous-concept. En considérant une base de connaissances d’une ontologie, nous pouvons inférer (grâce au mécanisme de classification automatique dans la hiérar-chie des concepts de l’ontologie), par exemple, les relations suivantes : Patient1 ⊑ Adulte et Patient2 ⊑ Mineur

Deux tables sont donc créées qui s’appellerons 2. Une seule table est créée. Cette table correspond au concept qui repré-

sente l’union de ces deux sous-concepts. La description du concept de l’union est automatiquement calculée et est il est donné comme suit :

Patient ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ âge.Number ⊓ (âge ≥ 18 ⊔ âge < 18) ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ âge.Number

Le lcs des concepts Patient1 et Patient3 est le concept Patient1 ce qui signifie que Patient3 ⊑ Patient1. Dans ce cas, les individus du concept Patient3



sont entièrement représentés par Patient1. Une seule table relationnelle est créée et cette table correspond à la description Patient1.

Dans l’exemple suivant, nous utilisons le même principe pour traiter les contrainte de rôles :

Famille1 ≡ ∀ homme.Personne ⊓ ∀ femme.Personne ⊓ ∀ enfant.Personne ⊓ =1 mari⊓ =1 femme ⊓ <3 enfant Famille2 ≡ ∀ homme.Personne ⊓ ∀ femme.Personne ⊓ ∀ enfant.Personne ⊓ =1 mari⊓ =1 femme ⊓ ≥4 enfant

Dans le premier, nous créons deux tables pour les deux sous-concepts : Famille1 ⊑ PetiteFamille et Famille2 ⊑ FamilleNombreuse

Dans le deuxième cas, on crée une seule table qui représente l’union des deux descriptions :

Famille≡ Famille1 ⊔ Famille2 ≡ ∀ homme.Personne ⊓ ∀ femme.Personne ⊓ ∀ enfant.Personne ⊓ =1 mari⊓ =1 femme ⊓ (<3 enfant ⊔ ≥4 enfant)

Le choix de créer une seule ou deux tables dépend de plusieurs facteurs notamment ceux liés aux utilisations futures de la base de données. Cinquième étape : génération d’un schéma relationnel

En relationnel, un rôle et son rôle inverse sont identiques et corres-pondent au mécanisme de clé/clé étrangère. Donc, on conserve uniquement le rôle ou son inverse (défini dans le concept du côté 1) dans la table relationnelle. Les tables Hôpital et Patient sont redéfinies comme suit :

Hôpital(id : numéroSyst, nom : String, service : refService) Patient(id : numéroSyst, nom : String, ddn : Date, examinéPar : refMé-decin, hôp : refHopital)

En appliquant ces deux normalisations sur la totalité de la base terminologique, nous obtenons la TBox suivante :

Hôpital1 ≡ ∀ nom.String ⊓ ∀ patient1.Patient1 ⊓ ∀ service.Service

Hôpital2 ≡ ∀ nom.String ⊓ ∀ patient2.Patient2 ⊓ ∀ service.Service

Patient1 ≡ ∀ nom.String ⊓ ∀ adresse.String ⊓ ∀ ddn.Date ⊓ ∀ pat-

1.Examen1 ⊓ ∀ hôp1.Hôpital1 hôp1 ≡ patient1-1

Patient2 ≡ ∀ nom.String ⊓ ∀ adresse.Adresse2 ⊓ ∀ ddn.Date ⊓ ∀ pat2-

1.Examen2 ⊓ ∀ hôp2.Hôpital2 hôp2 ≡ patient2-1

Médecin1 ≡ ∀ idM.Number ⊓ ∀ dirige.Service ⊓ ∀ méd1-1.Examen1

Médecin2 ≡ ∀ idM.Number ⊓ ∀ spécialité.String ⊓ ∀ méd2-1.Examen2



Examen1 ≡ ∃ pat1.Patient1 ⊓ ∃ méd1.Médecin1 ⊓ ∀ dateSoin.String ⊓ ∀ résultat.String ⊓ = 1 résultat.String ⊓ = 1 dateSoin.Date

Examen2 ≡ ∃ pat2.Patient2 ⊓ ∃ méd2.Médecin2 ⊓ ∀ résultat.String ⊓ = 1 résultat.String

Les concepts lcs sont définis comme suit : Hôpital ≡ lcs(Hôpital1, Hôpital2) ≡ ∀ nom.String ⊓ ∀ patient.Patient ⊓ ∀ service.Service Patient ≡ lcs(Patient1, Patient2) ≡ ∀ nom.String ⊓ ∀ ddn.Date ⊓ ∀ pat-

1.Examen ⊓ ∀ hôp.Hôpital hôp ≡ patient-1 Médecin ≡ lcs(Médecin1, Médecin2) ≡ ∀ idM.Number ⊓ ∀ résultat.String ⊓ ∀ méd-1.Examen Examen ≡ lcs(Examen1,Examen2) ≡ Examen2 ≡ ∃ pat.Patient ⊓ ∃ méd.Médecin ⊓ ∀ résultat.String ⊓ = 1 résultat.String

Pour une description d’un concept du type :

Concept ≡ ∀ r1.C1 ⊓…⊓ ∀ rm.Cm ⊓ ≥ n ri ⊓ ≤ n rj … (1) La structure de la table générée pour ce concept dépend, entre autre, des restric-tions cardinales (≥ n ri ⊓ ≤ n rj ⊓ = n rk) de ses rôles. En effet, pour générer un schéma normalisé les attributs multivalués sont stockés dans une table séparée de la table générée pour le concept. Sinon, des tuples seront dupliqués autant de fois que les valeurs des attributs multivalués. Si, pour la description (1), n est re-lativement grand, on crée une table à part pour stocker le rôle et on lie ces deux tables par la clé primaire de la table du concept.

Après avoir normalisé la base terminologique, sa représentation graphi-que devient la suivante :



Figure 4.5 Représentation graphique de la TBox normalisée Le schéma relationnel normalisé est composé des deux types de tables suivan-tes :

1. Les tables primaires : ces tables correspondent aux concepts lcs calculés à partir des concepts de la TBox. Pour notre exemple, ce sont les tables : Hôpital(idH : numéroSystème, nom : String) Patient(idP :numéroSystème, nom : String, adresse : String, ddn : Date, hôp : idH) Médecin(idM : number, résultat : String) Examen(idE : numéroSystème, idP : numéroSystème, idM : number, ré-sultat : String)

2. Les table secondaires : ces tables correspondent aux descriptions qui ne font pas partie des concepts lcs. Pour notre exemple, ces tables sont : Patient1(idH : numéroSystème, adresse : String) Patient2(idH : numéroSystème, idAd : Adresse) Adresse(idAd :numéroSystème, rue : String, ville : String) Médecin1(idM : number, dirige : refService) Médecin2(idM : number, spécialité : String) Examen2(idE : numéroSystème, dateSoin : Date)

Patient

Médecin2 Médecin1

Service

Hôpital

Patient1 Malade2

nom ddn

idMadresse Adresse2

villerue

nom

Médecin

spécialité dirige

Légende Rôle Rôle/rôle inverse Subsomption

Examen1résultat

Examen

dateSoin



4.4.4.2 Optimisation de schémas relationnels

L’optimisation de schémas a comme but de réduire le nombre de tables créées en surnombre lors de l’étape précédente à cause de la normalisation. La première étape opère au niveau des descriptions des éléments XML, c’est-à-dire au niveau intentionnel, alors que la seconde étape opère au niveau des instances des docu-ments XML, c’est-à-dire au niveau extensionnel.

Les tables susceptibles d’être supprimées du schéma relationnel sont les tables secondaires. Ces tables sont créées pour contenir les attributs qui provo-quent la dénormalisation du schéma quand ils se retrouvent dans leurs tables primaires. L’idée de cette optimisation vient de la façon dont ces tables sont créées. En effet, les attributs des tables secondaires sont expatriés de leurs tables primaires pour l’une des deux raisons suivantes :

• Raison 1 : l’attribut ne fait pas partie de toutes les instances des éléments XML. Par exemple, l’attribut spécialité ne figure que dans certains élé-ments Médecin. Ceci correspond à la définition DTD suivante : <!ELEMENT Elt (attr)?>

• Raison 2 : l’attribut est multivalué dans l’élément parent. Par exemple, un patient à plusieurs adresses. Ceci correspond à la définition DTD sui-vante : <!ELEMENT Elt (attr)*> ou <!ELEMENT Elt (attr)+>

La normalisation réalisée lors de la création du schéma relationnel pourrait ne pas être efficace si on tient compte des instances des documents XML. Par exemple, si sur 1000 éléments Médecin, 999 éléments possèdent un sous-élément spécialité, la normalisation n’est pas efficace puisqu’il n’y aura qu’un seul attribut nul. De même pour les attributs multivalués, si sur les 1000 élé-ments Elt il n’y a qu’une seule instance qui contient plusieurs valeurs pour le sous-élément attr, il peut être dans ce cas préférable de laisser l’attribut dans la table et d’avoir quelques tuples qui seront dupliqués plutôt que de créer une nouvelle table et faire des jointures chaque fois que c’est nécessaire. Nous trai-tons la première raison d’optimisation par le calcul de la probabilité condition-nelle et la deuxième par le calcul de la fréquence de répétition de l‘attribut dans son élément père.

Calcul de la probabilité conditionnelle

Cette probabilité est calculée pour chaque attribut (non clé) des tables secondai-res qui vérifie la première raison. Etant donné un attribut Ai de la table se-condaire TSi créée pour la table primaire TPi, peut-on ramener cet attribut de la table TSi vers la table TPi? Si tous les attributs Ai de la table TSi sont ramenés



dans la table TPi, la table TSi n’a plus une raison d’être et est par conséquent supprimée du schéma relationnel.

Pour chaque attribut Ai, on calcule la probabilité que cet attribut existe dans l’élément parent PAi représenté par la table primaire TPi, c’est la probabili-té conditionnelle de Bayes. Nous avons :

)().()/(

i

iiii PAp

PAApPAAp = (1)

)( iAp est la probabilité d’avoir un l’élément <Ai> dans les documents XML et ).( ii PAAp est la probabilité d’avoir l’élément <Ai> comme sous-élément de

<PAi>. La probabilité d’un élément PAi, )( iPAp , est calculée comme suit :

documents de NombrePAélément l' de sapparitiond' Nombre)( i

=iPAp (2) et

documents de Nombre PA dent sous-éléme comme Al'élément de onsd'appariti Nombre).( ii=ii PAAp (3)

En remplaçant les deux formules (2) et (3) dans la formule (1) et après simplifi-cation, nous obtenons :

i

ii

PAl'élément de onsd'appariti NombrePA dent sous-éléme comme Al'élément deon d'appariti Nombre)/( =ii PAAp (4)

L’attribut Ai est réintégré dans la table primaire de l’élément parent PAi si cette probabilité tend vers 1, en d’autres termes si seuilPAAp ii ≥)/( , avec seuil ≈ 1. La valeur du seuil ne peut pas être fixée pour toutes les applications. Elle dé-pend de plusieurs facteurs comme par exemple, la taille de la base de données et la fréquence d’interrogation de ces attributs.

Calcul de la fréquence de répétition

La fréquence de répétition consiste à mesurer le nombre de fois qu’un attribut Ai d’une table secondaire apparaît dans l’élément parent (qui correspond à la table primaire) sur la totalité des documents XML. Cette mesure concerne les attributs qui ont été expatriés de leurs tables primaires car ils sont multivalués (Raison 2). Dans un document XML, un attribut multivalué est représenté par plusieurs ap-paritions de la balise de cet élément comme sous-élément de l’élément parent (représenté par la table primaire).

En partant du même principe que les attributs traités par les probabilités conditionnelles, si un de ces attributs a en moyenne x valeurs pour chaque tuple et qu’on estime que la fréquence de mise-à-jour est très faible par rapport à la fréquence d’interrogation de cet attribut, alors il est plus optimal de garder cet attribut dans sa table primaire malgré quelques duplications.



Cette fréquence est calculée pour chaque attribut d’une table secondaire afin de décider s’il sera réintégré dans sa table primaire ou non. Soient A un at-tribut d’une table secondaire et PA l’élément père représenté par une table pri-maire dans le schéma relationnel. Nous calculons la fréquence :

n

PAANbPAA

n

ii∑

=><><

= 1)/(

)/( FR où <A> est l’élément XML représentant l’attribut A, <PAi> est la ième instance de l’élément XML représentant la table PA, Nb(<A>/<PAi>) est le nombre d’éléments A qui apparaissent comme sous-éléments de PAi. n est le nombre d’instances (sur tous les documents XML) de l’élément PA qui contiennent au moins un sous-élément A. Les instances de l’élément PA qui ne contiennent aucun sous-élément A ne sont pas considérés et sont traités par les probabilités conditionnelles.

Si la valeur de cette fréquence, pour un attribut A, tend vers 1, ou en d’autres termes si FR(A/PA) ≤ seuil (seuil 1), alors l’attribut est réintégré dans sa table primaire PA.

La démarche ainsi présentée se résume par l’algorithme suivant :



Tableau 4.6 Algorithme de génération d’un schéma normalisé à partir de do-cuments XML

4.5 Application à la génération automatique d’enquêtes médicales

Les sondages et enquêtes statistiques divers sont créés et exploités par les orga-nisations qui les gèrent de manière essentiellement manuelle. En effet, il n'existe à notre connaissance aucun système capable de construire automatiquement des enquêtes. La façon la plus courante de faire des enquêtes (dans quelque domaine que ce soit) est la suivante : Les documents d'enquêtes sont constitués le plus souvent manuellement et reproduits sous un logiciel spécifique (par exemple Sphinx ou encore EpiInfo en médecine). Les données collectées sur les docu-ments d'enquête sont alors saisies et traitées dans un logiciel de statistique ou un tableur.

Entrées: Graphe semi-structuré G = (V, A, r) // les documents XML Sortie: Schéma relationnel normalisé // Etape 1: générer le graphe conceptuel logique GCL

GCL = Genκ (G); Calculer les lcs des concepts du graphe GCL, les ajouter à {C_lcs}; ****Insérer les concepts lcs dans le graphe Pour Chaque concept c(a1 , a2 , … an) de {C_lcs} Créer une table relationnelle c_Tab_lcs (a1 , a2 , … an) Ajouter cette table à {Tab_Prim} fpour Pour Chaque concept c(a1 , a2 , … an) de GCL – {C_lcs} Créer une table (secondaire) relationnelle c_Tab (a1 , a2 , … an) Ajouter cette table à {Tab_Sec} Lier la table par une clé étrangère vers la table (primaire) c_Tab_lcs fpour // Etape 2: optimisation du schéma Pour chaque table t de {Tab_Sec} Soit EP l’élément XML représentant la table primaire de t Pour chaque attribut ai de t pc = p(ai/EP) fr = FR (ai / EP) si(pc ≥ seuil1 et fr ≤ seuil2) Supprimer l’attribut a1 de la table t; Ajouter ai à sa table primaire; fsi fpour Si la table t n’est composée que de sa clé, la supprimer du schéma fpour

XML et les bases de données / Application à la génération automatique d’enquêtes médicales


Figure 4.6 Schéma classique de conception d’enquêtes médicales

Ce fonctionnement est l’une des motivations des travaux présentés dans ce chapitre. Notre groupe de travail a été régulièrement sollicité pour participer à des enquêtes épidémiologiques. Dans chaque étude, il fallait définir les ques-tionnaires électroniques puis réaliser un logiciel spécifique qui permettait d'as-socier aux questionnaires une base de données capable de mémoriser les infor-mations saisies au cours de l'enquête.

Nous proposons donc dans ce travail de montrer comment il est possible d'automatiser ces différentes tâches afin de permettre à l'administrateur de l'en-quête de travailler sans avoir recours à un informaticien en mettant à sa disposi-tion un outil générique de conception de documents pour les enquêtes médicales qui seront ensuite stockés dans une base de données. Notre système permet donc de :

• créer des documents structurés et de les traduire en XML, • générer automatiquement un schéma relationnel de la base de données

qui servira de support de stockage des documents, • alimenter la base de données à partir des documents, • interroger la base de données via les documents qui ont servi à la créa-

tion du schéma de la base. Une idée qui a surgi de cette application est que l'utilisateur communique uni-quement au travers du document pour les opérations de conception, de saisie, de visualisation et d’interrogation de documents médicaux.



Figure 4.7 Interaction de l’utilisateur avec les bases de données L’architecture de notre système de génération automatique d’enquêtes

médicales est réalisée suivant le concept de généricité [Lafo 97]. Dans une ar-chitecture générique, trois acteurs interviennent pour la conception des docu-ments d’enquêtes médicales : l’informaticien qui crée l’application (qui consiste en une interface) générique, l’expert du domaine d’application (médical, ban-quier, juridique,etc.; dans notre application c’est le domaine médical) qui utilise cette interface générique pour créer le document et l’utilisateur final qui utilise ce document en saisie ou en consultation de données. Chaque acteur possède un niveau d'expertise qui lui est propre mais qui permet la communication avec les autres acteurs : l'informaticien possède la connaissance technologique et infor-matique, l'expert doit posséder une légère connaissance de l'informatique et une très forte connaissance de son domaine (médical). L'utilisateur final quant à lui, sait remplir et interroger les documents. Nous pouvons représenter le système générique par le schéma ci-dessous.

Document

Modèle de données

Modèle de traitements



Figure 4.8 Description de la généricité Suivant ce concept de généricité, nous concevons notre système généri-

que de création de documents d’enquêtes médicales. Une session de travail avec le système peut être ouverte soit en mode conception de documents (par l’utilisateur expert) soit en mode utilisation des documents (par l’utilisateur fi-nal). La conception d’un document passe par les étapes suivantes :

1. Conception graphique du document Le système se présente à l’utilisateur expert sous forme d’une interface de cons-truction de documents médicaux. Cette interface a une boîte à outils composée d’un ensemble de contrôles (boutons, zone de texte, zone statique, zone de titre, liste déroulante, etc.). L’utilisateur expert utilise ces contrôles pour construire les documents médicaux. L’interface permet à l’utilisateur d’exprimer des rela-tions d’appartenance entre ces contrôles. Par exemple, le contrôle intitulé nom appartient au contrôle Patient. 2. Séparation des éléments graphiques et du contenu Le système traduit ces documents composés de contrôles graphiques en docu-ments XML. Cette traduction est quasi directe et consiste à générer un élément XML complexe pour chaque contrôle contenant des contrôles (zone de ti-tre/sous-titre, etc.) et un élément XML simple pour chaque contrôle simple (zone de texte). Le rôle de XML est important dans ce système. Il permet de séparer les éléments visuels et les éléments structurels des documents. Pour préserver la présentation visuelle des documents créés par l’utilisateur expert, un document XSL est conjointement créé avec le document XML.

Crée le modèle gé-nérique

Utilise l’interface gé-nérique pour cons-truire le document

Utilisateur final

Informaticien Expert du domaine



3. Génération du schéma relationnel Les documents XML sont stockés dans une base de données relationnelles. Le schéma de la base de données est généré suivant l’approche de stockage de do-cuments XML présenté dans la section précédente (voir section 3.4.4). Une fois les documents représentés, l’interface offre à l’utilisateur expert la possibilité de créer plusieurs vues en XML du schéma (voir section 3.3.4) selon les profils des utilisateurs finaux.

4. Alimentation de la base de données L’utilisateur entre dans le système en ouvrant une session utilisateur. Une liste d’enquêtes médicales est présentée. Dès que l’utilisateur choisit une enquête, l’interface présente l’une des versions graphiques du schéma relationnel créées par l’utilisateur expert lors de la phase de conception. Ensuite l’utilisateur rem-plit les champs de saisie du document et le système alimente automatiquement la base de données. 5. Interrogation des données d’une enquête Nous n’avons pas encore développé cette phase. Etant donné que l’utilisateur est familier avec la structure des documents des enquêtes médicales, nous pensons que le moyen le plus adapté pour l’interrogation des données est de permettre à l’utilisateur final d’interroger la base de données par l’intermédiaire des mêmes documents qui ont servis à la construire, c’est le principe de l’interrogation par l’exemple (QBE). L’interface présente un document vide et l’utilisateur exprime ses contraintes sur les données en remplissant les champs de saisie du document. Le système renvoie tous les documents, de structure identique, qui vérifient ces conditions.

L’architecture globale du système est la suivante :

XML et les bases de données / Conclusion


Figure 4.9 Système générique de conception d’enquêtes médicales

Nous avons développé un prototype (qui s’appelle Internet Enquêteur)

qui permet de gérer des enquêtes médicales via le Web. Les enquêtes médicales sont créées sous forme de formulaires HTML et sont stockées dans une base de données Oracle. Les enquêtes médicales sont gérées à partir de l’écran de la fi-gure suivante :

Système générique

NF

a

XML

Utilisateurs finaux

Vues de la BDR

Document d’enquête

Document XML de l’enquête

Utilisateur expert



Figure 4.10 Gestion d’enquêtes médicales sous Internet Enquêteur Une enquête est composée d’un ensemble de variables d’études. Les variables d’études d’une enquête sont définies par l’utilisateur expert en spécifiant son nom, son type, sa description, etc. comme le montre la figure suivante.

Figure 4.11 Description d’une variable d’étude sous Internet Enquêteur

4.6 Conclusion Nous avons particulièrement évoqué, dans ce chapitre, les relations qui existent entre les bases de données relationnelles et XML. Nous avons montré que ces deux formalismes peuvent coopérer pour la conception de systèmes d’information ouverts sur le Web. Les bases de données sont très puissantes



pour stocker et interroger de gros volumes de données et XML est un format de représentation très souple et permet ainsi de faire communiquer des systèmes hé-térogènes.

Deux liaisons peuvent être étudiées entre XML et les bases de données : exporter des bases de données dans des documents XML et stocker des docu-ments XML dans une base de données. Nous avons présenté quelques travaux existants pour chacune de ces deux directions. Notre contribution a consisté en la proposition d’une interface graphique de génération de vue en XML à partir d’une base de données relationnelle. Ces vues sont créées non seulement en considérant la structure logique du schéma des données mais aussi la structure conceptuelle des données. En ce qui concerne le stockage de documents XML, nous avons choisi le modèle relationnel qui est le modèle le plus performant et le plus mature malgré l’évolution des technologies de l’information vers une in-formation de plus en plus complexe. Nous pensons que XML ne peut être mani-pulé (stockage optimal de données XML, expressivité et rapidité d’interrogation, archivage, etc.) d’une façon efficace que s’il est stocké en utilisant les bases de données.

Nous avons présenté une approche de stockage de documents XML en deux étapes : la première opère au niveau conceptuel des documents XML et la deuxième opère au niveau des instances/données. Nous avons utilisé la logique de descriptions pour représenter les éléments XML des documents et le raison-nement logique lcs (Least Common Subsumer) pour calculer les structures com-munes et générer un premier schéma relationnel. Dans la deuxième phase, le schéma relationnel est optimisé en calculant des grandeurs statistiques à partir des instances des documents XML.

L’inconvénient de cette optimisation est qu’elle effectue des calculs uniquement sur les instances des documents XML actuels et elle ne tient pas compte des évolutions futures de ces documents. Pour remédier à ce problème, nous pouvons paramétrer les mesures statistiques en introduisant des valeurs es-timées des instances des documents à venir.

Nous avons appliqué ces approches à la conception d’enquêtes médica-les. Nous avons conçu un système générique permettant d’automatiser la tâche de conception de documents pour réaliser des enquêtes médicales.

Dans la suite de ce rapport, nous nous intéressons aux données multi-sources et hétérogènes, notamment la représentation, l’intégration, l’interrogation de données distribuées pour la reconstitution de documents cohé-rents et personnalisés pour l’utilisateur.

partie 3 utilisation de xml et des bases de données pour la...

Documents