Données semi-structurées Actives

Transcription

1 Institut National de formation en Informatique INI Mémoire de Magister intitulé : Données semi-structurées Actives Cas de cours en ligne Réalisé par : K. ELARABA ZIANE Encadré Par : Dr Azeddine CHIKH Juin 2007

2 Table des matières Données semi-structurées actives Chapitre I : Introduction 7 PARTIE I : DONNEES SEMI-STRUCTUREES Chapitre II : Représentation des données semi-structurées II.1. Introduction 10 II.2. L'objet structuré, l'objet semi structuré et l objet non structuré.. 11 II.3. Définition données Semi-structurées (SSD) 11 II.4. Modèles des SSD II.4.1 Le modèle OEM II.4.2 Le modèle XML 16 II.5. Base de documents ou base de données pour les SSD? II.6. Gestion des donnés semi-structurées.. 19 II.6.1 Théories autour de l émergence de ces nouveaux SGBD.. 19 II.7. SGBD semi-structurées.. 20 II.7.1 LORE.. 20 II.7.2 TAMINO. 20 II.8. Extension des systèmes relationnels existants 21 II.8.1 XML et ORACLE 10g. 21 II.8.2 XML et les autres SGBDs. 22 II.9 Conclusion 23 Chapitre III : Interrogation des données semi-structurées III.1.Introduction. 24 III.2. Caractéristiques d un Langage de requêtes de SSD.. 25 III.3. Modèles de données de type orienté OEM 26 III. 3.1OEM-QL.. 26 III. 3.2 Lorel 26 III.4. Modèles de données de type XML. 27 III.4. 1Xpath 29 III.4.2 XML-QL 29 III.4.3 XQL 30 III.4.4 XQuery. 30 III.5. Conclusion.. 35 PARTIE II ACTIVE XML Chapitre IV : Active XML & les technologies associées IV.1. Introduction 36 IV.2. Service web. 36 IV.2.1Vue d ensemble.. 36 IV.2.2 La description des services avec WSDL 36 IV.2.3 Le protocole SOAP.. 38 IV.3. Active XML.. 40 IV.3.1 Brève description

3 IV.3.2 Principe d Actif XML IV document AXML IV service AXML. 44 IV.3.3 Architecture globale IV.4.base de données Actives et AXML IV.4.1 Les bases de données actives et les déclencheurs 48 IV.4.2 Définition des triggers en XML. 48 IV.5 Conclusion 50 PARTIE III CONTRIBUTION Chapitre V : Représentation SSD du contenu pédagogique V.1 Introduction.. 51 V.2 spécification IMS-LD.. 52 V.3 Rappel sur le rapport entre les SSD et XML.. 54 V.4 Utilisation conjointe des bases de documents et des bases de données 56 V.4.1 Principe général 56 V.4.2 Méta-modèle du système.. 60 V.5 Architecture d édition du contenu semi-structuré 62 V.6 Conclusion 64 Chapitre VI : Application de AXML en e-learning VI.1. Introduction VI.2. L objet pédagogique d'une plate-forme e-learning VI.3 Différents type de projets E-Learning ; 66 VI.4 Les besoins des différents types d utilisateurs VI.5 Les activités dans une plate-forme e-learning 68 VI.6. Diffusion d objets pédagogiques fondée services web.. 69 VI.6.1 Les bases de services web VI.6.2 L approche services web VI.7. Définition des tâches et des services correspondants. 71 VI.7.1 Création de documents pédagogiques. 72 VI.7.2 Stockage des objets pédagogiques VI.7.3 Présentation des documents pédagogiques VI.7.4 Implantation des exercices.. 74 VI Environnement de développement à distance.. 74 VI Evaluation du parcours VI.8. Conception de l environnement de développement à distance.. 76 VI.8.1 Les fonctionnalités retenues.. 76 VI.8.2 implantation de l environnement de développement. 76 VI.8.3 Approche pour un développement SOAP.. 77 VI.8.4 Mise en œuvre du service VI.9 Conclusion 80 Chapitre VII : Architecture détaillée du Pair AXML VII.1 introduction 81 VII.2 Pair AXML comme client 82 3

4 VII.2.1 Quand activer un appel?.. 82 VII Pull explicite. 83 VII Pull implicite. 83 VII mode Push. 83 VII.2.2 Le temps de validité pour les données retournées. 84 VII La validité zéro VII Illimité VII.2.3 Quoi faire avec le résultat?.. 85 VII.2.4 Où obtenir les paramètres d'appel?.. 86 VII.3 Pair AXML comme serveur 87 VII.3.1 Pull : interroger et mettre à jour les services VII.3.2 Push : services continus VII.4 Spécifications techniques. 89 VII.4.1 La machine virtuelle de Java 89 VII.4.2 Les outils de XML. 89 VII.4.3 Le processeur de requête de Xquery.. 90 VII.4.4 Le moteur de servlet de Tomcat.. 90 VII.4.5 La palette d outils de SOAP Axis. 90 Chapitre VIII : Conclusion 91 Glossaire.. 93 Bibliographie. 94 Webographie. 97 4

5 Table des figures II.1 Une base de données OEM sur les bâtiments Montpelliérains.. 14 II.2 Exemple de document XML III.1 Exemple d une requête Lorel. 26 III.2 Résultat d une requête Lorel. 27 III.3 DTD du document «bibliographie.xml». 28 III.4 Exemple (Q2-1) de XML-QL III.5 Exemple (Q2-2) de XML-QL 29 III.6 Exemple (Q2-3) de XML-QL 30 III.7 Exemple d'une requête FLWR de XQuery.. 32 III.8 Document XML à interroger par XQuery.. 33 III.9 Les expressions conditionnelles en XQuery. 33 III.10 Les constructeurs en XQuery. 33 III.11 Résultat d évaluation d un constructeur III.12 Exemple de document XML pour fonctions XQuery. 34 III.13 Exemple de fonction XQuery IV.1 Illustration de l invocation d un service Web IV.2 Format d un message SOAP IV.3 Exemple de requête SOAP RPC IV.4 Résultat de requête SOAP RPC.. 39 IV.5 Matérialisation d un appel.. 41 IV.6 Un document AXML avant/après un appel service IV.7 Exemple de document AXML IV.8 Document AXML après appel service.. 44 IV.9 Après invocation d un service IV.10 Architecture globale pour AXML.. 48 IV.11 Trigger en XML. 50 V.1 Un document XML. 56 V.2 Systèmes classiques documents/bases de données V.3 Traitement d un document avec automatisation V.4 Un document balisé avec/sans précision V.5 Présentation entité-association de données.. 61 V.6 Schéma de l implantation du système VI.1 La gestion du contenu pédagogique Actif. 73 VI.2 Les activités e-learning présentées par des services web.. 74 VI.3 Modèle de gestion d un cours représenté par un réseau de Petri.. 76 VI.4 Schéma de fonctionnement de l EDD. 77 VI.5 Implémentation du service Web pour l'exécution des exercices. 79 VII.1 Architecture P2P d AXML VII.2 Document AXML persistent.. 86 VII.3 Définition d un Service AXML donné comme une requête.. 88 VII.4 La pile des technologies du Pair AXML. 90 5

6 RESUME Le traitement de l information passe aujourd hui par les bases de données qui ont su prendre une place importante dans le domaine informatique. Avec l évolution de la technologie informatique. Les SGBDs (Systèmes de Gestion de Base de Données) ne cessent de s améliorer et de se perfectionner. Dans les années 80, les SGBD offraient un large éventail de modèles de données et de traitement. Cependant, ils se révélaient souvent très limites pour gérer explicitement la dynamique des bases des données. Ces systèmes sont souvent qualifie de passif, par opposition aux systèmes actifs qui eux, sont capable d effectuer des actions prédéfinies, en réponse a des événements spécifiques lorsque certaine conditions sont vérifiées. La prochaine génération des bases de données sera capable de réagir à des modifications. Cette introduction de la réactivité au sein des bases de données résulte de deux tendances : d une part, le développement de langage de règles (règles de production, règles actives, règles déductives). Et d autre part le développement des technologies de modélisations. La popularité sans cesse croissante de XML et l émergence des services web ont donnée naissance à une nouvelle génération de données semi-structurées dite Active XML AXML document. Cette famille de données est caractérisée par le fait qu une partie des données est présentée explicitement pendant qu une autre est définie intentionnellement à l aide d appels imbriqués des services web. Les services web peuvent échanger dans ce contexte l information intentionnelle en utilisant les données AXML comme paramètre et résultats. Le présent travail de recherche s intéresse aux données semistructurées actives et plus particulièrement a la technologie AXML. Il tente de faire un état de l art correspondant à ce domaine qui est en plein émersion, et étudier son applicabilité dans le domaine de l enseignement en vue de construire des cours en ligne qui soient semi-structurés et actifs. Nous considérons que le caractère actif de ces cours les rend plus interactifs. Mots clé : Données semi-structurées, OEM, AXML, Cours en ligne, e-learning, service Web. 6

7 ABSTRACT The data processing passes today by the databases which take an important place in the data-processing field. Since the evolution of dataprocessing technology, the SGBDs (Data base management systems) do not cease improving. In the Eighties, the DBMS offered a broad range of treatment and data models. However, they proved often very limiting to explicitly manage the dynamics of the data bases. These systems are often describes as passive, in opposition to the active systems, which are able to carry out pre-defined actions, in response to specific events when certain conditions are checked. The next generation of the databases will be able to react to modifications. This introduction of the reactivity within the databases results from two tendencies: (1) the development of language of rules (rules of production, rules active, deductive rules), and (2) the development of technologies of modeling. The increasing popularity of XML and the emergence of the Web services gave rise to a new generation of semi-structured data known as Active XML, AXML document. This family of data is characterized by the fact that part of the data is presented explicitly while another is intentionally defined using overlapping calls of the Web services. The Web services can exchange in this context intentional information by using data AXML like parameters and results. This research task is interested in the active semi-structured data and more particularly in technology AXML. It tries to make a state of the art corresponding to this field which is into full emergence, and to study its applicability in the curricular area in order to build courses on line which are semi-structured and active. Keywords: Semi structured data, OEM, AXML, curses online, e-learning, web service 7

8 Chapitre 1 Introduction Données semi-structurées actives La gestion de données est sans doute l'un des aspects les plus importants de l'informatique. Pendant longtemps, les bases de données respectant certaines structurations, ont été les sources essentielles d'information. Faire communiquer ou coopérer ces sources revenait à faire de l'intégration de bases de données. Maintenant que les bases de données n'ont plus ce monopole, surtout depuis l'émergence de l'internet (Web), l'intégration se retrouve plus compliquée puisque nous ne pouvons plus compter sur la forte structuration des bases de données., de nombreux efforts ont été dévolus à l'extension de ces techniques pour également prendre en compte des données semi-structurées, en particulier leurs mise à jour [OZSU99]. Mais l ouverture des systèmes d information sur Web (e-system) est en train de changer la vision à la gestion des données distribuées sur le Web, et de constituer un changement de contexte important, d'une part en raison de la grande hétérogénéité des sources de données et du problème posé par leur flexibilité, et d'autre part parce que ces sources de données sont autonomes, et réparties à une grande échelle, celle du Web. L'objectif de ce travail est de proposer une approche novatrice pour intégrer des données semi-structurées et des services, qui prennent en compte ces deux aspects, et de ce fait est adaptée à la gestion de données à l'échelle du Web. Flexibilité XML [W3C05], en tant que standard définissant un modèle de données et un format de représentation pour les données semistructurées, a suscité un intérêt considérable au sein de la communauté de gestion de données, en raison principalement de la flexibilité qu'il apporte pour résoudre les problèmes de dynamique de structure. Cependant, sur le Web, une grande partie des problèmes de flexibilité proviennent du fait que les sources exposent leurs données sous forme de pages HTML, mêlant ainsi structure et présentation. De plus ces données ne sont souvent que partiellement accessibles, au travers de formulaires HTML. Heureusement, de nouvelles technologies et standards de communication sont récemment apparus, qui permettent la publication de données sur le Web et l'accès à celle-ci de manière adéquate : les services Web. Ces derniers sont simplement des programmes qui acceptent des paramètres et retournent en résultat des données XML. Les standards WSDL et SOAP régissent respectivement la manière dont ils sont décrits et invoqués à distance à travers l'internet. Notre modèle met en œuvre efficacement XML et les services Web pour des tâches de gestion de données distribuée. Autonomie D'une certaine manière, les architectures centralisées d'intégration de données vont à l'encontre de l'esprit du Web, celui d'un 8

9 «faible couplage» entre les systèmes participants, où le contrôle est le plus souvent partagé et les systèmes indépendants les uns des autres. De plus, le passage à l'échelle nécessaire pour prendre en charge un volume très large du Web est difficile pour les systèmes centralisés. En revanche, les architectures pair-à-pair, basées sur un partage des ressources par échanges directs entre systèmes participants, constituent une alternative crédible aux systèmes centralisés, et ont déjà fait leurs preuves dans le contexte du partage de fichiers sur Internet [FREE07]. Ces architectures capturent la nature autonome des systèmes, et leur capacité à jouer le rôle à la fois de producteurs d'information (c'est à dire de serveurs) et de consommateurs d'informations produites par d'autres (c'est à dire de clients). Dans notre modèle, les architectures pair-à-pair sont à la base de la gestion de données distribuées. Nous proposons Active XML (AXML, en abrégé), un langage qui tire profit des services Web pour la gestion de données, et qui est mis en œuvre dans une architecture pair-à-pair. Ce langage introduit la notion de documents AXML, qui sont des documents XML contenant des appels à des services Web. Le modèle AXML définit également les services AXML, comme étant des services Web capables d'échanger des documents AXML. L'introduction de ces services conduit à des mécanismes évolués d'interaction entre systèmes, qui ont la particularité d'être centrés sur les données. Ainsi, plusieurs systèmes peuvent collaborer dynamiquement à la réalisation d'une tâche de gestion de données, et sont en particulier capables de découvrir de nouvelles sources de données pertinentes au cours de leur exécution. Notre travail vise à transformer des appels de services Web inclus dans des documents XML semi-structuré en un puissant outil de gestion de données distribuées appliqué sur le cas de e-learning. En combinant de manière transparente des données semi-structurées extensionnelles (exprimées en XML) et des données intensionnelles (les appels de services, qui sont un moyen d'obtenir des données), Les documents et les services AXML s'intègrent parfaitement à une architecture pair-à-pair, dans laquelle chaque système joue le rôle de client, en invoquant les appels de services inclus dans ses documents AXML, et celui de serveur en fournissant des services utilisant ses documents. En nous basant sur ce paradigme. Dans le cadre de ce travail, nous allons nous intéresser aux problèmes de modélisation et d interrogation des données semi-structurées où nous montrons l'utilisation du modèle (resp. langage) XML pour la modélisation (l'interrogation) des données semi-structurées. Ainsi que l emploi d une nouvelle approche basée sur les documents Actif-XML où nous allons concevoir un système de e-learning qui manipule des données semistructurées et qui est basé sur des appels de services web. 9

10 Notre contribution consiste en deux points essentiels: Données semi-structurées actives 1. Actuellement, peu de travaux sur la modélisation des systèmes basés sur les données semi-structurées. Pour pallier à ce manque, nous proposons une modélisation d un contenu pédagogique semi-structuré d un système e-learning. 2. Nous proposons, que les cours semi-structurés de ce système permettent des appels aux services web afin de rendre ce système plus actif. Pour cela nous allons employer le nouveau langage Active XML (AXML). Ce document est organisé comme suit : Le premier chapitre est une introduction générale. Le deuxième chapitre présente les différentes approches proposées pour la modélisation des données semi-structurées. Le troisième chapitre traite les différents langages d interrogation des données semi-structurées où nous focalisons sur le langage XQuery qui est le plus adéquat et le plus récemment normalisé. Au quatrième chapitre nous nous intéressons au langage AXML qui permet de modéliser un système basé sur des documents semistructurés contenant des appels aux services web. A partir du cinquième chapitre commence l interprétation des fondements théoriques et méthodologiques étudiés dans les chapitres précédents à travers un cas d étude qui sera la gestion du contenu pédagogique dans un système e-learning. Au cinquième chapitre nous nous intéressons à la modélisation du contenu pédagogique «semi-structuré» et la façon dont il est interrogé. Au sixième chapitre, nous étudions l aspect fonctionnel des données par l emploi des appels au service web ainsi que l usage du langage AXML. Le dernier chapitre sera notre conclusion. Nous tenterons d'y mettre nos idées en perspective et mentionnerons quelques questions importantes qui, à notre sens, méritent d'être étudiées. 10

11 Chapitre 2 Les données semi-structurées Données semi-structurées actives II.1 Introduction : De nouveaux paradigmes ont vu le jour (e.g.. bases de données orientées-objet, bases de données déductives, bases de données contraintes). Ces paradigmes offrent une meilleure flexibilité comparés au modèle relationnel. Cependant, dans certains domaines d application, comme les bases de données Web, les bases de données biologiques, les bibliothèques virtuelles, etc, il subsiste un besoin considérable en flexibilité, à la fois dans la représentation et la manipulation des données. Ces applications sont caractérisées par l absence de structure fixe et rigide. Les modèles de données semi-structurés ont pour finalité la représentation de données qui ne sont pas structurées intentionnellement, mais qui sont structurées de façon hétérogène, ou qui évoluent si rapidement que les changements ne se répercutent pas au niveau de la structure. Un exemple typique est le World Wide Web avec ses pages HTML, ses fichiers textes, ses bases de données biologiques, ses données bibliographiques, etc Le problème principal dans les données semi-structurées est que la structure des données n est pas entièrement connue. Ceci conduit au fait que l interrogation de ces données suppose un accès par le contenu, ce qui l oppose à l accès via la structure (e.g., systèmes relationnels). De plus, ceci a conduit au fait que très souvent les utilisateurs naviguent au hasard dans les données en raison de la non nécessité d une connaissance structurelle. Le développement d Internet a augmenté la complexité des systèmes d informations par les différents niveaux d interactions (entre sources d information et de connaissances, entre systèmes et utilisateurs) par l offre de volumes importants d informations hétérogènes, multimédias et distribuées. En effet, les SI doivent supporter à la fois des données structurées (par exemple, stockées dans des bases de données relationnelles) et des données semi-structurés (par exemple les documents multimédias), ce qui nécessite d assurer la cohérence de cet ensemble. De nouveaux outils de recherche et d extraction de l information pertinente, sûre et fiable deviennent nécessaires. 11

12 12 Données semi-structurées actives II.2. L'objet structuré, l'objet semi-structuré et l objet non structuré : Trois types de sources de données peuvent être considérés pour les systèmes d information ouverts sur le Web : les sources de données fortement structurées, les sources de données semi-structurées et les sources de données non structurées. La première classe est représentée par les bases de données (relationnelles ou objets). Les données sont créées conformément à un schéma bien défini pendant la phase de conception. Une source de données semi-structurées ne possède pas un schéma de données explicitement représenté dans la source. Le schéma de données est implicite et il est véhiculé avec les données. Par conséquent, une même entité peut avoir plusieurs structures différentes dans une même source de données. Ce type de sources de données est généralement représenté en utilisant le format XML. La troisième catégorie est celle des données non structurées. Une source de données non structurée ne présente aucune notion de schéma de données. Ces sources représentent l information en utilisant soit des images soit des phrases exprimées en langue naturelle. Ces sources sont représentées sur le Web en utilisant le format HTML. Elles peuvent être transformées, en utilisant des techniques d indexation et d annotation, en sources de données semi-structurées. C est pour cela que nous ne considérons dans notre travail que les deux premiers types de sources. II.3. Définition Données Semi-structurées Les données semi-structurées sont des données qui possèdent une structure flexible et des données hétérogènes et qui n'ont pas de schéma a priori mais plutôt dont le schéma peut-être extrait à partir de la donnée. La plupart du temps, un ensemble de données semi-structurées est représenté sous la forme d'un graphe dont les feuilles contiennent les données et dont les nœuds et les liens représentent la structure de l'ensemble. La modification, l'ajout ou la suppression d'une donnée entraîne une modification du graphe, c'est-à-dire de la structure de l'ensemble. Modèles de données universels qui permettent de représenter des structures Irrégulières : on peut comparer des données dans formats différents (e.g. une chaîne de caractères avec un n-uplet) Implicites : données et structures (grammaire, schéma) sont mélangées Partielles : coexistence de données structurées et non-structurées Exemples: OEM, XML, graphes/arbres étiquetés Les données sont hétérogènes au niveau de la structure et de la sémantique:

13 Structure : (syntaxe irrégulière) un même document peut exister sous format PostScript (vue plate), SGML/XML/HTML (semi-structuré) _ le nom d une personne peut être une chaîne de caractères ou un n-uplet avec deux attributs (nom et prénom). La structure n est pas figée En plus les structures peuvent être imbriquées c.a.d des valeurs peuvent être à leurs tour d autres structures. Sémantique : un nom d attribut peut avoir différentes significations dans deux bases de données différentes (e.g. homonyme adresse = adresse professionnelle ou adresse personnelle) Données sans schéma ou auto descriptives II.4. Modèles des données semi-structurées Principe : partir des documents existants et trouver une structure commune, suffisamment souple pour prendre en compte les irrégularités, les valeurs manquantes, les évolutions, etc Les modèles semi-structurés utilisent des graphes annotés pour représenter les données. Les différents modèles diffèrent par : l endroit où sont situées les annotations (arêtes et/ou nœuds) l existence ou non d un ordre sur les fils d un nœud la façon de représenter le partage d information -Ex : OEM : annotations sur arcs et feuilles, pas d ordre UnQL: annotations sur les arcs, pas d ordre XML : annotations sur les nœuds et feuilles, existence d un ordre Deux principaux modèles de données semi-structurées ont vu le jour : OEM [PAPA 95], implanté dans le projet LORE [MCHU 97], et le modèle d XML [BUNE 96]. Pour le modèle UnQL il est basé sur OEM avec quelques modifications au niveau de l annotation. La caractéristique principale de ces modèles est qu ils sont autodescriptifs. En effet, les modèles de données usuels (relationnel et objet) présentent deux niveaux : Le niveau schéma, descriptif de la structure générale (classes et schémas relationnels) d un ensemble de données partageant des caractéristiques communes, et le niveau données où chaque occurrence (objet et n-uplet) obéit à une structure définie au niveau du schéma. Dans les modèles de données semi-structurées, schéma et données sont confondus en un seul et même niveau. Chaque objet contient son propre schéma. Ces modèles sont basés sur la théorie des graphes. 13

14 Un objet est un graphe dont la description des attributs est codée dans les arêtes. Le squelette du graphe représente donc la structure de l objet. Notons que la notion de type est très simple. Le modèle dispose de types atomiques de base, et d un type spécial (i.e. le type complexe) caractérisant tout objet composé d objets de type atomique ou d autres objets complexes. Tous les objets complexes ont alors une structure évolutive et non figée, qui peut être irrégulière et incomplète. La notion de classe y est inexistante. A l opposé des modèles objets pour les bases de données, le comportement des objets semi-structurés n est pas abordé pour l instant. Les bases de données semi-structurées, sauf pour certaines applications spécifiques pour lesquelles elles ont été créées spécialement, sont en général issues de l intégration de plusieurs bases de données hétérogènes, se trouvant notamment sur le web. II.4.1 Le modèle OEM Le modèle OEM (Object Exchange Model) [PAPA 95] a été conçu à l université de Stanford, et est dédié au stockage des données semistructurées. OEM fait partie d un vaste projet de système de gestion de bases de données semi-structurées LORE, dont il est le noyau. La structure sous-jacente d une base de données OEM est un graphe orienté connexe. Les objets sont alors représentés par des nœuds du graphe et les relations entre les objets sont représentées par des arcs étiquetés. Il y a deux types d objets différents : Les objets atomiques qui contiennent des valeurs (integer, string, etc.). Les nœuds correspondants peuvent contenir seulement des arcs entrants. Les objets complexes qui ne contiennent pas de valeurs, et sont composés d autres objets complexes ou atomiques. 14

15 Alger école près de résidence résidence près de gardien nom adresse nom nom concierge adresse adresse «Carnot» numéro "St Jean" "12 rue d Alger" "M. Contoz"St Priest" rue numéro rue "M. Rispe" "64" "Bd Metz" "64" "Av Fleming" FigII.1 modèle OEM sur bâtiments Montpelliérains Un nœud distingué du graphe, la racine, constitue le point d entrée de la base de données. La figure II.1 représente une base de données OEM qui contient des informations sur les bâtiments Montpelliérains. Observons que la structure peut être irrégulière (une adresse peut être soit une chaîne de caractères soit un objet complexe contenant un nom de rue et un numéro, une résidence peut contenir des informations sur un gardien ou non), de même que le typage (i.e. un numéro dans une adresse peut être un entier ou une chaîne de caractères). Une base de données OEM peut être interrogée par un langage spécifique pour les données semi-structurées appelé Lorel [ABIT 97a]. Lorel est une extension de OQL [CATT 94], sur deux points principaux : l utilisation d expressions de chemin, construites à partir d étiquettes et de jokers en utilisant des expressions régulières. l utilisation de la coercion, de manière à pallier le typage fort des bases de données traditionnelles, qui est incompatible avec la nature des données semi-structurées. Par exemple, la requête Lorel suivante (Fig II.2) renvoie les résidences dont le numéro de rue est 64 : SELECT Montpellier.résidence WHERE Montpellier.résidence.adresse.numéro=64 15

16 16 Données semi-structurées actives La réponse est la résidence St Priest, bien que le numéro de rue soit une chaîne, grâce à l utilisation de la coercicon. Une telle requête posée dans un système de bases de données traditionnel donnerait une réponse vide ou une erreur. Notons également qu une requête sur le numéro 12 n aurait pas donné la résidence Villa St Jean comme réponse, car son adresse ne contient pas de champ numéro. En effet, avec Lorel, l utilisateur est sensé connaître la structure de la base de données. C est la raison pour laquelle le système LORE inclut un guide de données (dataguide) qui permet à l utilisateur d examiner le squelette de la base. L exemple suivant renvoie le nom de tous les bâtiments de Montpellier dont le numéro de rue est 64: SELECT B.nom FROM Montpellier.# B WHERE B.adresse.numero=64 Les réponses sont la résidence St Priest et l école Carnot. Le symbole # joue le rôle d un joker et permet de sélectionner tous les attributs de l objet Montpellier, quel que soit leur nom (école, résidence). B est une variable prenant comme valeur les objets attributs successifs de d objet Montpellier. L exécution de la requête va donc considérer toutes les écoles et les résidences en testant si le numéro (s il existe) de leur adresse est 64. Pour interroger ces bases, on ne dispose à l heure actuelle que des techniques prouvées dans les bases de données classiques, c est-à-dire des langages du type SQL, OSQL, etc. Le problème est, par essence, l inexistence d un schéma global cohérent. Des outils, les dataguides [GOLD 97], permettent par ailleurs d aider à l exploration de la structure de la base et par conséquent à la formulation de requêtes. Extraire le schéma global des données est utile à l utilisateur dans l expression de ses requêtes, et au système pour l optimisation de l accès aux données. A l utilisateur car cela lui fournit une idée de la structure de la base, sans qu il ait à utiliser les dataguides, et au système car la structure permet d utiliser les techniques bien connues comme le clustering, les index, les arbres de placement, etc. mais permet aussi d utiliser un langage de programmation statiquement et fortement typé, ce qui assure la cohérence des applications. L un des objectifs est donc de trouver une structure unique sous-jacente. Cependant, cela ne paraît présenter d intérêt majeur que si les données semi-structurées peuvent être intégrées dans un modèle utilisant cette structure et effectuant les dites optimisations, comme dans les systèmes de bases de données objets traditionnels. Toutefois, l extraction de structure telle qu elle est se fait actuellement ne fournit pas de structuration parfaite des données. En effet, certains objets, peuvent se retrouver rattachés à un type qui ne les décrit pas exactement. Ainsi on dit qu ils sont presque d un type donné. Ce principe de typage approximatif pose tout de même de sérieux problèmes dans la mesure où l on ne peut parler de la structure d un objet, si celle-ci n est pas exacte. Toute tentative d intégration des objets issus de bases semi-

17 structurées dans des bases de données structurées est alors impossible, à moins d utiliser une solution brutale consistant à assigner un type différent pour chaque objet ayant une structure différente, même s ils sont sémantiquement du même type. Dans ce cas, la notion de type ne sert plus à rien, car on peut obtenir dans des cas extrêmes autant de types que d objets. Il est donc nécessaire d utiliser un modèle possédant des caractéristiques issues d un modèle structuré et également des caractéristiques issues des modèles de données semi-structurées. Un tel modèle permettrait de gérer les objets à type approximatif, et permettrait de résoudre le dilemme suivant: que choisir entre un modèle de données totalement structuré dans lequel les accès aux données sont optimisés, et un modèle de données flexible dans lequel les accès nécessitent des traitements plus lourds à cause de l absence d informations de typage? Le modèle des objets variables est donc un premier pas vers l intégration des données structurées et des données semi-structurées. Cela offre la possibilité d utiliser la structure quand celle-ci est connue, et de gérer néanmoins des données arbitraires. II.4.2 Le modèle XML XML [Bray et al98] (extended Markup Language) est un format textuel extensible de description de document défini par le W3C. De la famille des langages de marquage SGML [Goldfarb 91] (ISO 8879 :1986), il permet de s'adapter à quasiment tous les domaines où l'on a besoin de structurer de l'information de façon portable. XML permet de faire le lien entre un langage conçu plus spécialement pour le formatage de documents (SGML) et un modèle de données en émergence permettant une vision plus réaliste mais plus complexe des données qu'est le modèle semi-structuré. Ce langage permet ainsi de définir une structure de données et son contenu. XML est conçu de façon à faciliter l'intégration et l'échange de données entre applications. Il isole le formatage et le rendu des documents par rapport à sa structure. C'est à des langages de style spécifiques tels que XSL (extended Style Sheet) [Clark et Deach 2001] qu'on laisse le soin de s'occuper du rendu de la page XML lors de la publication. XML est un langage à base d'éléments, d'étiquettes, d'attributs et de valeurs. Les balises (tag) ouvrantes (resp. fermantes) sont constituées d'étiquettes (label) représentées entre le symbole < (resp. </) et le symbole >. Le composant logique compris entre une balise ouvrante et une balise fermante est appelé valeur. Le composant logique constitué de la balise ouvrante, de la valeur et de la balise fermante est appelé élément (element). 17

18 La valeur peut être vide, contenir du texte, d'autres éléments ou contenir un mélange des deux (mixed element content). Les balises définissent la structure du document. L'élément de plus haut niveau englobant tous les autres et n'ayant pas de parents est appelé élément racine. Un élément peut contenir des informations additionnelles appelées attributs (attributes). Un attribut est un couple formé d'un nom et d'une valeur et est représenté à l'intérieur de la balise ouvrante sous la forme nom = "valeur" Un document XML est un ensemble d'éléments ainsi imbriqués. Un document XML peut avoir deux qualifications, il peut être : {Bien formé : quand il respecte la syntaxe du langage XML définie par le W3C ; {Valide : quand il est associé à une définition de type de document et qu'il la respecte (nom des éléments, type, répétition et ordre d'apparition dans le document). Un document XML bien formé est un document XML qui respecte certaines règles simples : 1. Il existe un et un seul élément racine qui contient tous les autres éléments. 2. Les balises sont correctement imbriquées : chaque balise ouvrante a une balise fermante associée et il n'y a pas de chevauchement. 3. Le nom des balises est libre mais il contient au moins une lettre. 4. Les attributs des balises, lorsqu'ils existent, doivent comporter obligatoirement une valeur qui doit toujours apparaitre entre double apostrophes. 5. Quand un élément est vide, les balises peuvent être simplifiées : <balise></balise> est identique à <balise/>. La représentation XML du graphe de données semi-structurées de l'exemple de la figure II.2 est donnée dans le document 2.2. Un attribut catégorie (prenant la valeur '3' puis '5') a été aussi rajouté à l'élément restaurant (les attributs n'ont pas d'équivalents en OEM). 18

19 XML est à présent le format standard utilisé pour représenter des données semi-structurées, et [Goldman et al. 1999] montre que les projets utilisant OEM peuvent migrer aisément vers XML. <?xml version=1.0" encoding="iso " standalone="yes"?> <divertissement> <restaurant categorie="3"> <nom>palace d'ivry</nom> <plat>salade Thai</plat> <telephone> </telephone> <proprietaire>m. SALIM</proprietaire> </restaurant> <restaurant categorie="5"> <nom>royal Fata</nom> <plat>plaque chauffante de canard</plat> <plat>assortiment vapeur</plat> <plat>cafe liegois</plat> </restaurant> <pizzeria>nolpiltaine</pizzeria> </divertissement> Fig II.2 Exemple de document XML II.5 Bases de données ou base de documents Pour les SSD? La distinction entre contenus orientés données et contenus orientés document n est pas toujours claire en pratique. Un contenu orienté données comme une facture par exemple peut contenir aussi des données de granularité forte et irrégulièrement structurées telles que des descriptions. Et inversement, un contenu orienté document comme un manuel utilisateur peut contenir des données de granularité fine et régulièrement structurées, telles que le nom de l auteur ou une date de révision (il s agit la plupart du temps de métadonnées). Les documents juridiques ou médicaux constituent aussi d autres exemples, ils sont écrits sous forme de prose mais contiennent des parties distinctes telles que des dates, des noms, des procédures, et doivent souvent être stockés dans leur intégralité pour des raisons légales. En dépit de cette imprécision, la caractérisation de vos contenus comme orientés données ou orientés document vous aidera à décider du genre de base de données à utiliser. En règle générale, les données sont stockées dans une base traditionnelle, qu elle soit relationnelle, orientée objet ou hiérarchique. Cela peut être réalisé à l aide d un logiciel intermédiaire [middleware] ou par la base elle-même qui dispose alors de possibilités intrinsèques. Dans ce dernier cas, la base de données est qualifiée de compatible XML [XML-enabled]. Les documents quand à eux sont stockés dans une base XML native, c est-à-dire une base conçue spécialement pour stocker du XML, ou bien alors dans un système de gestion de contenu [content management system], c est-à-dire une application conçue pour gérer des documents et construite au-dessus d une base XML native. 19

20 20 Données semi-structurées actives Ces règles ne sont pas absolues. Les données, et particulièrement les données semi-structurées, peuvent être stockées dans des bases XML natives, et inversement, les documents peuvent être stockés dans des bases traditionnelles lorsque peu de caractéristiques spécifiques au format XML sont requises. En outre, les frontières entre les bases traditionnelles et les bases XML natives deviennent floues car les bases traditionnelles intègrent des capacités propres aux bases XML, et les bases XML natives supportent le stockage de parties de documents dans des bases externes (généralement des bases relationnelles). II.6 Gestion des donnés semi-structurées : Les réflexions sur la gestion intelligente des données semi-structurées sont en plein essor, en effet le développement d outils rendant possible une telle gestion mobilise un certain nombre de pôles de recherche. Les approches sont certes différentes, certains voulant créer des outils neufs et originaux ou d autres tentant d adapter des outils ayant déjà faits leurs preuves, à savoir les systèmes de gestions de bases de données relationnelles. Mais tous ces courants se rejoignent en un axe fédérateur à savoir que ces bases de données tentent de capturer la structuration variable et peu figée des données semi-structurées. Avec la prise en compte des liens inter-documents, ces bases de données supportent alors le multimédia et même l hypermédia. A l'heure de l'interconnexion des réseaux, le développement rapide de XML s'explique par la nécessité de disposer d'un langage universel permettant la communication entre applications hétérogènes. XML associe la souplesse des données semi-structurées (la description de la structure des données est facultative) et la simplicité des documents structurés (XML est auto descriptif : la structure est exprimée par des marques dans le document, cf. figure 1). Dans la suite de cet article nous ferons souvent l'amalgame entre XML, et documents structurés ou données semi-structurées. Avec XML, le semi-structuré constitue sans doute une voie d avenir pour les bases de données. Même s il est probable qu aucune méthode ne satisfera à elle seule tous les besoins et que l on utilisera plusieurs méthodes complémentaires. II.6.1 Théories autour de l émergence de ces nouveaux SGBD. Des systèmes de gestion de bases de données relationnels (SGDBR) peuvent sembler être un choix possible pour faciliter l'échange d'objets XML. Mais le modèle de données à base de table du SGBDR ne convient pas à la nature hiérarchique de XML. Un SGBDR devrait casser et aplanir un document XML dans une multitude de tables. Même des bases de données relationnelles multidimensionnelles ou des bases de données orientées objet, ne peuvent pas manipuler des données avec une telle structure dynamique. Une base de données XML doit être capable de