Contribution à l'interrogation flexible de données semi-structurées

INSTITUT DE RECHERCHE EN INFORMATIQUE DE TOULOUSE CNR S – INP – UPS – UT1

Université Paul Sabatier, 118 Route de Narbonne, 31062 Toulouse Cedex 04 Tel 05.61.55.66.11

THÈSE

Présenté devant

l’Université Paul Sabatier de Toulouse

Doctorat de l’Université Paul Sabatier

Spécialité : INFORMATIQUE

Par

Abdeslame ALILAOUAR

Contribution à l’interrogation

flexible de données semi-structurées

Soutenue le 26 octobre 2007 devant le jury composé de :

M. Claude CHRISMENT Professeur à l’université P. Sabatier, Toulouse Président

Mme Florence SEDES Professeur à l’université P. Sabatier, Toulouse Directrice de thèse M. Noureddine MOUADDIB Professeur à l'École Polytechnique de l'Université de Nantes Rapporteur Mme. Sylvie CALABRETTO Maître de Conférences HDR à l’INSA de Lyon Rapporteur Mme Gabriella PASI Professeur à l'université de Milano, Italie Examinateur M. Mohand BOUGHANEM Professeur à l’université P. Sabatier, Toulouse Examinateur

Résumé

Pour manipuler les Données Semi-Structurées (DSS) et en extraire les informations pertinentes en termes de structure et/ou de contenu pour l’utilisateur, de nombreux langages de requêtes ont été proposés. Ces langages de requêtes devraient donc prendre en compte non seulement le contenu mais aussi la structure sous-jacente car cette dernière peut changer complètement leur pertinence et leur adéquation vis à vis des besoins exprimés par l'utilisateur. Cependant, la non connaissance a priori et l’hétérogénéité de structure de DSS rendent les langages d’interrogation de BD classiques incompatibles avec l’interrogation de telles collections semi-structurées. Les techniques standards d’interrogations basées sur l’appariement exact sont donc inadaptées pour interroger des sources de DSS : une requête peut aboutir à un ensemble vide ou incomplet de réponses lors de l’interrogation même s’il existe des réponses pertinentes dans la(les) source(s) à interroger. Un autre problème relève de la prise en compte de l’information "manquante". En effet, puisque la structure de l’instance de document est par essence incomplète, il est possible que l’information ne soit pas explicitement signifiée ou encore qu’elle n’ait pas été correctement élicitée. Ceci implique de ne pas considérer cette absence d’information comme une information négative, mais de traiter ces cas avec l’incertitude qui convient, dans un algorithme général de "ranking".

Pour résoudre ces problèmes le recours aux techniques d’appariement flexible (approximatif) et la réponse sous forme des listes ordonnées de réponses selon les préférences de l’utilisateur, représentent un choix presque inévitable. Les travaux menés jusqu'ici dans le cadre de l’interrogation flexible de BD ont révélé que la logique floue constitue un cadre particulièrement bien adapté pour modéliser la notion de flexibilité et de préférences selon le raisonnement humain. Dans ce sens, nous proposons un modèle d’interrogation flexible pour les DSS en général et pour les documents XML en particulier, en prenant en compte le contenu et la structure sous-jacente des DSS. La logique floue sera utilisée pour représenter les préférences de l’utilisateur sur le contenu et la structure des DSS. D’autre part, à la fin du processus d'interrogation, chaque réponse est associée à un degré compris dans l’intervalle ]0,1]. Plus ce degré est faible, moins la réponse semble pertinente. Ce degré est calculé en utilisant le degré d’appartenance (µ) et des mesures de similarité connues dans les systèmes de recherche d’informations (SRI) pour le contenu, et l’arbre recouvrant minimal pour la structure. Le modèle proposé a été évalué et validé dans le cadre de plateforme PRETI et d’INEX, grâce au prototype que nous avons développé.

Mots-clés :

Interrogation flexible, documents et données semi-structurés, théorie des sous-ensembles flous, arbre recouvrant minimal.

Je tiens d’abord à remercier Monsieur Claude CHRISMENT, responsable de l’équipe SIG, qui m’a accueilli durant la durée de ma thèse et qui me fait l'honneur de présider ce jury.

Je remercie ensuite les membres du jury:

Madame Sylvie CALABRETTO et Monsieur Noureddine MOUADDIB pour avoir accepté de rapporter sur ma thèse et pour les judicieuses remarques qu'ils m'ont faites. Je leur suis reconnaissant de l'intérêt qu'ils ont porté à mon travail,

Madame Gabriella PASI et Monsieur Mohand BOUGHANEM, pour l'intérêt manifesté pour cette thèse en acceptant d'en être examinateurs.

Je remercie enfin Madame Florence SEDES, pour avoir encadré cette thèse, pour avoir cru en moi dès le début, pour m'avoir soutenu tout au long de ces années, pour la patience, la gentillesse et la disponibilité dont il a fait preuve à mon égard. Ses idées, ses conseils et remarques constructives m’ont permis d’améliorer la qualité de mes travaux et de ce mémoire.

Un grand merci également à Monsieur André PENINOU pour l’intérêt qu’il a porté à mes travaux en relisant ce mémoire.

Je remercie tous ceux avec qui j'ai eu la chance de discuter de mon travail et qui m'ont offert idées et conseils.

Mes derniers remerciements vont à ceux qui m'ont soutenu de loin. Je pense particulièrement à ma famille : mes parents, mes frères et sœurs, que je n'ai pas vus ces dernières années mais qui sont restés près de moi et à qui je dédie cette thèse.

Introduction générale ...10

1. Documents et Données Semi-Structurés ...14

1.1. Introduction...14

1.2. Représentation des données semi-structurées ...16

1.2.1. Le modèle de données OEM...17

1.2.2. Les documents XML...18

1.2.3. Métadonnées pour données semi-structurées...19

1.2.3.1 Le XSD (XML Schema Definition) ...20

1.2.3.2 Les espaces de noms...21

1.2.4. Synthèse sur XML ...22

1.3. Données et documents: Documents orientés données vs documents orientés texte ...23

1.3.1. Les documents orientés données ...24

1.3.2. Les documents orientés texte ...25

1.4. Manipulation des documents XML ...26

1.4.1. Les parseurs orientés événements ...26

1.4.2. Les parseurs de type arbre ...27

1.4.3. Parseurs DOM Vs parseurs SAX ...27

1.5. Stocker des documents XML...28

1.5.1. Stocker les documents XML sur le système de fichiers...28

1.5.2. Stocker des documents XML dans des BLOBs ...29

1.5.3. Les schémas XML et les schémas de bases de données...30

1.5.4. Stocker des documents XML dans des bases de données XML natives ...31

1.5.5. Synthèse sur les systèmes de stockage de documents XML ...33

1.6. Indexation des documents XML...34

1.6.1. Indexation basée sur les valeurs ...34

1.6.2. Indexation structurelle ...36

1.6.2.1. Numérotation de Dietz ...37

1.6.2.2. Numérotation basée sur la position des nœuds ...38

1.6.2.3. Le système XISS ...38

1.6.2.4. Numérotation en arbre k-aire par niveau ...40

1.6.2.5. Numérotation virtuelle par niveau ...41

1.6.2.6. Numérotation dynamique par niveau ...42

1.7. eXist, une base de données XML native libre ...45

1.7.1. Architecture ...46

1.7.2. Système de stockage dans eXist ...47

2. Interrogation flexible ...49

2.1. Introduction...49

2.2. Les langages de requête pour XML...50

2.2.1. XPath : langage d’expression de chemins ...50

2.2.2. XML-QL...51

2.2.3. XQL ...52

2.2.4. XQuery ...53

2.2.5. Les langages orientés RI...53

2.2.6. Synthèse ...54

2.3. Interrogation flexible de BD...54

2.3.1. Critères complémentaires pour le classement...55

2.3.2. Distance et Similarité...55

2.3.3. Préférences ...55

2.4. Théorie des sous-ensembles flous ...56

2.5. Les sous-ensembles flous et l’interrogation des bases de données...60

2.5.1. Opérateurs ensemblistes...61

2.5.2. SQLf ...62

2.5.3. Les difficultés d’utilisation des préférences...63

2.5.3.1. Les préférences dépendant du contexte ...63

2.5.3.2. Inversion de préférences ...64

2.6. Interrogation flexible de données semi-structurées ...65

2.6.1. Relaxation des requêtes ...65

2.6.1.1. La relaxation de contenu ...66

2.6.1.2. La relaxation de structure ...66

2.6.3. Appariement approximatif d’arbres...68

2.6.2.1. Distance d’édition...69

2.6.2.2. Distance d’alignement ...74

2.6.2.3. Problème d’inclusion d’arbres...76

2.6.3. Approche basée sur la fermeture floue ...76

2.6.3.1. Calcul du poids ...77

2.6.3.1.1. Poids lié aux nœuds ...78

2.6.3.1.2. Poids lié aux arcs ...78

2.6.3.2. Calcul de fermeture floue ...80

2.6.3.3. Exécution des requêtes ...80

2.7. Comparaison ...80

3.1. Introduction...83

3.2. Généralités sur les Arbres Couvrants Minimaux...84

3.2.1. Définition de l'ACM ...84

3.2.2. Solutions proposées pour le calcul d’un ACM ...85

3.2.2.1. Algorithme de Prim ...85

3.2.2.2. Algorithme de Kruskal ...86

3.2.3. Conclusion sur l’ACM...87

3.3. L’interrogation flexible de documents XML et l’ACM ...87

3.3.1. Expression et représentation de requêtes ...88

3.3.2. Evaluation du poids des noeuds...90

3.3.3. Algorithme d’appariement...93

3.3.4. La jointure et la propagation des poids...94

3.3.5. Discussion...103

3.4. Conclusion...104

4. Expérimentations et résultats ...105

4.1. Introduction ...105

4.2. Plate-forme PRETI ...106

4.3. La campagne d’évaluation INEX 2006 ...109

4.4. Mesures d’évaluation ...112

4.5. Les résultats sous PRETI...117

4.6. Les résultats sous INEX ...120

4.7. Conclusion...125

5. Conclusion et Perspectives ...127

Bibliographie ...131

Annexe I ...139

Architecture et description du prototype développé ...139

Annexe II...142

Introduction générale

La popularité croissante et l’évolution incontestable de l’utilisation du langage XML (eXtensible Markup Language), l’ont amené à devenir le format incontournable de description et d’échange de données sur le Web et entre applications. La nature des données échangées est différente de celles manipulées par les Systèmes classiques de Gestion de Bases de Données (SGBD) ou encore celles utilisées dans les systèmes documentaires classiques. Il s’agit, pour la plupart, de données qui ont une certaine régularité mais dont la structure sous-jacente reste limitée, implicite, inconnue a priori et hétérogène d’une source à une autre, voire dans la même source. Pour manipuler ces données qualifiées de Données Semi-Structurées (DSS) et en extraire les informations pertinentes en termes de structure et/ou de contenu pour l’utilisateur, plusieurs équipes de recherche ont investi dans le développement de langages d’interrogation adaptés. Ces langages devraient donc prendre en compte non seulement le contenu mais aussi la structure sous-jacente ; en effet, celle-ci peut changer complètement leur pertinence et leur adéquation vis à vis des besoins exprimés par l'utilisateur.

Ce travail prend sa source dans le projet REPARTIR1 du programme INTERREG

III B SUDOE2 sur lequel j’ai été amené à travailler en 2003 et 2004 dans le cadre

de mes travaux de recherche. La problématique posée reposait sur l’interrogation de sources de données hétérogènes (de schémas et de SGBD différents : 4D, Ms-Access, PostgresQL, etc.) et réparties sur plusieurs sites géographiquement distants (les différents pays ou régions partenaires du projet) accessibles via le web.

1 _{http://www.rutmp.fr/repartir/} 2

Deux types de solutions à cette problématique ont été proposés dans la littérature : le premier consiste à utiliser une BD de médiation et donc à faire périodiquement des mises à jour de cette BD. Il faut alors créer un schéma de BD optimisé et commun entre les différentes sources pour la base de médiation. La seconde famille de solution est plus complexe : elle repose sur la formulation d’un ensemble de requêtes (un requête par source) puis la fusion des résultats de ces requêtes. Les problèmes sous-jacents sont le temps de réponse et la disponibilité de connexions réseau vers les sources de données.

Intégrant ces éléments, la solution choisie dans la cadre du projet REPARTIR, après exploration de ces différents voies de recherche et la prise en compte des paramètres d’infrastructure des différentes configurations par pays, a été toute différente : notre choix s’est porté vers une base « pivot » XML. En effet, presque tous les SGBD sur le marché proposent des outils pour la médiation de BD vers XML. Le point de départ de notre problématique pouvait donc être vu comme un ensemble de sources de DSS (Données Semi-Structurées) hétérogènes, constituant plus largement une collection de « documents » XML.

Le verrou à attaquer était dès lors le problème de l’interrogation de ces sources, par des utilisateurs (originaires des différents organismes et différents pays) n’ayant pas une connaissance fine des structures des données mises à disposition par les autres partenaires du projet. En effet, la non connaissance a priori et l’hétérogénéité de structure de ces sources de données rendent les langages d’interrogation de BD classiques inadaptés puisque les techniques standards d’interrogation sont basées sur l’appariement exact : une requête peut aboutir à un ensemble vide ou incomplet de réponses lors de l’interrogation même s’il existe des réponses pertinentes dans la (les) source(s) à interroger.

Un autre problème relève de la prise en compte de l’information "manquante" puisque chaque source est censée contenir l’information, mais, aucun schéma n’ayant été défini a priori, et les SGBD reposant sur des formats différents, on ne sait « où » (i.e. dans quelle sous-structure, rubrique, attribut ou commentaire). En effet, puisque la structure de l’instance des dits « documents » est par essence incomplète, il est possible que l’information ne soit pas explicitement signifiée ou encore qu’elle n’ait pas été correctement mise en valeur ou « élicitée ». Ceci

implique de ne pas considérer cette absence d’information comme une information négative, mais de traiter ces cas avec l’incertitude qui convient, par exemple dans un algorithme général de "ranking". Ainsi le recours aux techniques d’appariement flexible (autrement dit approximatif) a représenté un choix presque inévitable pour l’évaluation des requêtes : nous parlons donc dans ce cas d’interrogation flexible. Cependant, lorsque nous parlons d’une méthode ou d’une approche d’interrogation flexible, nous visons le processus d’évaluation des requêtes, indépendamment de leur langage d’expression. L’expression des requêtes peut être faite avec n’importe quel langage de requêtes ou interface graphique (langage graphique). Lorsque nous parlons d’un langage flexible, la flexibilité peut viser l’expression et le processus d’évaluation en même temps.

Des travaux sur les langages d’interrogation flexible de documents XML, comme, dans notre équipe, les travaux de K. Sauvagnat [Sau05], sont disponibles. Ces travaux découlent directement de recherches dans le domaine des systèmes documentaires et reposent sur l’enrichissement ou l’expansion de processus de Recherche d’Information (RI), initialement basés sur l’exploitation de contenus textuels, par introduction et prise en compte de la structure. Ces langages sont donc destinés à interroger des collections de documents XML orientés « texte » [Bou05], autrement dit, des collections documentaires.

A l’opposé, notre point de départ est une collection de documents XML orientés « donnée » ou plus précisément orientés BD (c’est-à-dire une BD XML native), dans laquelle la structure (ou plutôt son absence ou son incomplétude) est au premier plan. C’est la raison pour laquelle les langages issus des SRI sont a priori peu adaptés à cette problématique.

Les travaux menés jusqu’ici dans le cadre de l’interrogation flexible des BD ont révélé que la logique floue constitue un cadre particulièrement bien adapté pour modéliser la notion de flexibilité et de préférences selon le raisonnement humain.

Dans ce sens, nous proposons un modèle d’interrogation flexible pour les DSS en général et pour les documents XML en particulier, en prenant en compte le contenu et la structure sous-jacente des DSS. La logique floue est utilisée pour

représenter les préférences de l’utilisateur sur le contenu et la structure des DSS. En outre, à la fin de processus d'interrogation, chaque réponse est associée à un degré de confiance, autrement dit de pertinence, compris dans l’intervalle ]0,1]. Plus ce degré est faible, moins la réponse semble pertinente. Ce degré est calculé en utilisant des mesures de similarité connues en RI pour le contenu, et l’arbre couvrant minimale pour la structure, tout en essayant de traiter certaines anomalies de l’utilisation de préférences en employant le contexte de l’utilisateur.

Ce mémoire est organisé selon le plan suivant : dans le premier chapitre, nous présentons un état de l’art sur les documents et les DSS et particulièrement sur les documents XML, et les différentes techniques de stockage et d’indexation de ces documents. Le deuxième chapitre présentera la notion d’interrogation flexible. Nous présentons les travaux menés jusqu'ici sur l’interrogation flexible des BD et des documents et des Données Semi-Structurées et leurs avantages et inconvénients.

Dans le troisième chapitre nous détaillons notre méthode pour l’interrogation flexible des DSS. Nous donnons le cadre théorique de cette méthode, l’algorithme et un exemple d’illustration du processus d’interrogation.

Enfin, dans le quatrième chapitre nous abordons les résultats des expérimentations effectuées pour évaluer les performances de la méthode que nous avons proposée. Nous finissons par la conclusion et les perspectives.

C

HAPITRE

1

Documents et Données Semi-Structurés

1.1. Introduction

Le monde des bases de données usuelles s’appuie sur la régularité de structure des données qu’il manipule et la définition a priori d’une structure (logique, conceptuelle) de données à laquelle les données seront ensuite obligées de se conformer. Cela permet ainsi la mise en œuvre de méthodes de stockage et d’interrogation simples et efficaces. Par contre, une telle régularité ne permet pas de répondre à certains besoins du monde réel comme :

- l’évolution de schémas de données : la structure logique de données peut évoluer ce qui nécessite alors la modification de schéma (structure) et des contenus (données) en conséquence. Cette modification est très complexe et coûteuse à réaliser,

- les données qui peuvent ne pas se conformer exactement au schéma : ceci

nécessite le plus souvent d’employer beaucoup de valeurs nulles et/ou de redécouper et ignorer certaines données,

- certains attributs qui contiennent des données non structurées ou faiblement

structurées (exemple : attributs de type BLOB ou CLOB), ce qui ne permet pas d’utiliser des critères fins pour l’interrogation,

- le même attribut pourrait avoir des types différents selon les données : cela nécessite le plus souvent d’employer un type englobant (par exemple, le type chaîne de caractères). Ceci a pour conséquence de réduire l’efficacité des techniques d’interrogation.

Les Données Semi-Structurées ne sont pas contraintes par l’utilisation de structures aussi rigides que dans le cas des SGBD (relationnels ou objets) et sont caractérisées par [ACS02] :

- Une structure irrégulière : une collection de DSS peut comporter des éléments hétérogènes qui représentent la même information. Un même attribut peut être mono-valué dans certaines instances et multi-valué dans d’autres. Des informations supplémentaires (annotations, détails) peuvent apparaître à certains endroits.

- Une structure partielle : une partie des données peut être constituée

d’informations non structurées (texte brut).

- Un typage irrégulier : il n’y a pas de typage strict, au contraire des SGBD usuels,

qui imposent une politique de typage strict pour protéger la consistance des données. Le type des objets peut varier selon le point de vue adopté. Par exemple, pour décrire la situation familiale d’une personne on peut utiliser le type énuméré qui contient deux éléments "mariée", "célibataire" ou utiliser un attribut de type booléen qui aura deux valeurs : vrai pour une personne "mariée" et faux pour "célibataire".

- Une structure implicite : même si une certaine structuration peut sembler

présente (indiquée par l’intermédiaire de balises, de champs, etc.), il peut ne pas exister de description explicite de la structure de données. L’extraction et l’interprétation de structure constituent donc un processus difficile puisqu’il s’agit à la fois d’analyser, d’interpréter les données et d’effectuer des correspondances logiques pour enfin déduire la structure.

- Le fait que la structure peut être définie a priori ou a posteriori : les SGBD sont

basés sur l’hypothèse d’une structure fixée a priori, définie avant toute insertion de données. Dans le cas de DSS, la structure est souvent postérieure à l’existence de données. De telles données ne peuvent donc pas se conformer à une structure prédéfinie fixe. Ce type de données se rencontre fréquemment dans le monde du Web ou lors de l'intégration de sources hétérogènes.

- Un structure "large": en raison de l’hétérogénéité, la structure est la plupart du temps très large c’est-à-dire qu’elle ne contient pas beaucoup de détails, ce qui permet de contenir toutes les informations de différentes instances des données. - Une structure qui évolue rapidement : les sources de DSS sont habituellement

dynamiques. Leurs données et leur organisation changent fréquemment.

1.2. Représentation des données semi-structurées

La représentation des données semi-structurées se base couramment sur des arbres et/ou graphes étiquetés. Les éléments de structure sont alors représentés par des étiquettes attachées aux arcs ou aux nœuds du graphe. La figure 1.1 illustre le graphe (l’arbre) de deux maisons à la location ayant chacune un numéro, mais où le reste des informations varie. Ainsi, la première maison, est décrite par un numéro, un prix donné par saison (été et hors saison) et une description qui contient le nombre de lits dans la maison. La deuxième est aussi décrite par un numéro, un prix unique pour toute l’année et une description qui contient le nombre de lits par chambre.

Figure 1.1 : Exemple d’arbre représentant des DSS residence @numero ″140″ description nlits 4 maison été 1700 0 horssaison 1400 prix maison description @numero ″123″ prix 1400 chambre 3 chambre nlits 2 nlits

1.2.1. Le modèle de données OEM

Une des modélisations des données semi-structurées est le modèle OEM (Object Exchange Model). Ce modèle a été spécialement conçu pour représenter les données semi-structurées. Il est issu du projet "Tsimmis" de l'Université de Stanford [PGW95]. Les données dans OEM sont auto-descriptives et peuvent être vues comme un graphe étiqueté orienté qui peut comporter des cycles. La figure 1.2 montre un exemple de graphe OEM. Toutes les entités du modèle OEM sont des objets que l'on retrouve sous forme de nœuds. Chaque objet a un identifiant unique, un "OID" de la forme &i. i est un entier. Les objets atomiques n'ont pas d'arêtes sortantes et contiennent une valeur parmi les types de base atomiques tels que les entiers, réels, string, gif, html, etc. (par exemple, dans la figure 1.2, l'objet dont l'OID est &4 a pour valeur la chaîne de caractères "140"). Tous les autres types d'objets sont complexes et ont des arêtes sortantes. La valeur de ces objets complexes est l'ensemble des références de leurs sous-objets représentés par des paires (étiquette, OID), l'étiquette étant celle de l'arête entre l'objet complexe et le sous-objet (par exemple,. dans la figure 1.2, l'objet dont l'OID est &5 a pour valeur {(horssaison, &10), (été, &11)}. Notons aussi qu'un enfant peut avoir plusieurs parents comme pour l'objet dont l'OID est &13 et l'objet dont l'OID est &17.

.. numero ″140″ description nlits maison été 1700 prix maison description numero ″123″ prix 1400 chambre 4 chambre nlits 2 nlits &2 &3

&5 &6 &8 &9

&14 &12 &11 &10 &1 residence &18 &19 &15 &13 &7 &4 &16 &17 &20 horssaison

1.2.2. Les documents XML

Une autre forme de représentation des DSS est la représentation textuelle sous forme de document XML. En effet, XML est un format textuel extensible de description de document défini par le W3C. Il s’agit en fait d’un sous-ensemble de SGML [Gol90].

Comme HTML, XML utilise des balises et des attributs. Mais alors que HTML définit la signification de chaque balise et de chaque attribut (souvent la manière dont le texte qu'ils encadrent apparaîtra dans un navigateur), la philosophie de XML repose sur la séparation entre les données et leur présentation. XML utilise les balises pour délimiter les éléments de données et laisse l'entière interprétation des données à l'application qui les lit. En d'autres termes, si vous voyez "<p>" dans un fichier XML, ne supposez pas qu'il s'agit d'un paragraphe. Comme dans de nombreux de langages de balisage, un document XML repose lourdement sur trois blocs de construction fondamentaux : les éléments, les attributs, et les valeurs. Un élément sert à décrire ou à contenir un morceau d’information. Un élément se présente toujours sous la forme d’une balise ouvrante suivie de données facultatives puis d’une balise fermante. Les données comprises entre la balise ouvrante et la balise fermante d’un élément sont la valeur de celui-ci. La valeur peut être vide, contenir du texte ou d’autres éléments ou les deux (élément mixte). Lorsqu’un élément regroupe ou contient du texte et d’autres éléments, on parle alors de contenus mixtes (mixed contents), comme dans l’exemple suivant :

<prix>5<devise>Euro</devise></prix>

Dans cet exemple le contenu de l’élément "prix" est un contenu mixte, donc "prix" est un élément mixte. Un élément peut contenir des informations additionnelles appelées attributs. Un attribut est une information placée dans la balise d’ouverture de l’élément. Il se présente sous la forme : nom= "valeur". Un document XML est un ensemble d’éléments. Par convention, il est défini deux types de documents XML corrects, les documents dits bien formés et les documents dit valides.

Un document XML bien formé est un document XML qui respecte les règles lexicales et syntaxiques suivantes :

- il existe un seul élément (racine) qui contient tous les autres éléments du document.

- chaque balise ouvrante a une balise fermante associée et il n’y a pas de

chevauchement entre les éléments (correctement imbriqués).

- les noms des balises ne doivent pas commencer par "xml" et doivent commencer

par une lettre ou "_", les autres caractères peuvent être des chiffres, des lettres, "_", "." ou "-".

- les attributs doivent comporter obligatoirement une valeur.

1.2.3. Métadonnées pour données semi-structurées

Les DSS sont auto descriptives : le schéma est défini dans les données, et aucune structure n’est précisée a priori. Ceci permet une grande flexibilité dans le stockage et la mise à jour et l’échange. Par contre, une telle souplesse comporte les inconvénients suivants :

- Le stockage de données est inefficace. Le schéma doit être répliqué pour chaque

donnée ;

Figure 1.3 : Exemple d’un document XML bien formé

<?xml version="1.0" encoding="UTF-8"?> <residence> <maison numero="123"> <description> <chambre> <nblit>3</nblit> </chambre> <chambre> <nblit>2</nblit> </chambre> </description> <prix> 1400 </prix> </maison> <maison numero="140"> <description> <nblit>4</nblit> </description> <prix> <horssaison>1400</horssaison> <été>1700</été> </prix> </maison> </residence>

- Les requêtes sont complexes à évaluer de façon optimale : même une simple expression de chemin implique souvent le parcours complet du graphe ;

- Les requêtes sont complexes à reformuler : l’utilisateur ne peut s’appuyer que sur des informations incomplètes ou imprécises pour pouvoir formuler une requête.

Cependant, l’expérience a montré que les données semi-structurées employées dans l’échange (communication) entre applications, possèdent souvent une certaine régularité. Deux principales approches ont été proposées pour exploiter cette régularité sans toutefois utiliser un schéma ou une structure prédéfinie rigide :

- une structure déduite : calculée automatiquement a posteriori à partir des

données [WDC03].

- un formalisme de structure flexible défini a priori : il permet de décrire les données en offrant un degré de précision modulable sur la structure de données. De telles formalisations ont fait l’objet d’étude et de standardisation, notamment la DTD [W3C5] (Document Type Définition) et XML schéma [W3C4].

1.2.3.1 Le XSD (XML Schema Definition)

Lorsque la grammaire d’un document est définie dans une DTD et que le document respecte cette DTD, on parle de document valide. En effet, Les schémas XML permettent de décrire, tout comme les DTD, l'ensemble des règles pour la structure et des propriétés que doit suivre le document XML tels que les éléments et les attributs pouvant être utilisés et leur ordre d'apparition et imbrication.

Cependant, les schémas XML donnent en plus la possibilité d’introduire un typage de donnée beaucoup plus précis (booléen, entier…) ainsi que le support des espaces de noms et un définition fine du nombre d’occurrences d’un élément (dans une DTD, on était limité à 0, 1 ou un nombre quelconque de fois). Contrairement aux DTD, les XML schémas sont des documents XML à part entière qui peuvent être édités et manipulés à partir de n'importe quel outil d'édition ou de traitement des documents XML. La figure 1.4 illustre un exemple de fichier XML Schema. XML Schema apparaît comme le successeur des DTD car il est par nature

Ainsi XML Schema décrit (en XML) la structure d'un document XML c'est-à-dire :

- les éléments qui composent un document,

- les attributs,

- la hiérarchie entre les éléments,

- l'ordre des sous-éléments,

- le nombre de sous-éléments,

- les types des éléments et attributs,

- les valeurs par défaut, le format ou la restriction des valeurs d'un élément.

1.2.3.2 Les espaces de noms

Les espaces de noms permettent de combiner dans un seul document des vocabulaires XML (éléments et attributs) définis par plusieurs applications. Par exemple, des balises XHTML, MathML, etc. Il se peut que deux sémantiques fournissent des balises de même nom, mais de significations différentes. Les

Figure 1.4 : Exemple de XML Schema

<?xml version="1.0" encoding="UTF-8" standalone="no"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>

<xs:complexType name="residence"> <xs:sequence>

<xs:element ref="maison" maxOccurs="unbounded"/> </xs:sequence>

</xs:complexType>

<xs:element name="residence" type="residence"/> <xs:complexType name="maison">

<xs:sequence>

<xs:element ref="description"/> <xs:element ref="prix"/> </xs:sequence>

<xs:attribute name="numero" type="xs:string" use="required"/> </xs:complexType>

<xs:element name="maison" type="maison"/> <xs:complexType name="description">

<xs:sequence>

<xs:element ref="chambre" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence>

</xs:complexType>

<xs:element name="description" type="description"/> <xs:complexType name="chambre">

<xs:sequence>

<xs:element ref="nblit"/> </xs:sequence>

</xs:complexType>

<xs:element name="chambre" type="xs:string"/> <xs:element name="nblit" type="xs:string"/> <xs:element name="prix" type="xs:string"/> </xs:schema>

espaces de nom résolvent ce problème en qualifiant de manière unique un objet (élément ou attribut), caractérisé par un nom et un domaine de définition sur lequel il a telle signification. En pratique, on préfixera l'objet avec l'espace de nom correspondant. Les espaces de nom sont identifiés par des URIs (Uniform Resource Identifiers), mais l'on précise pour chacun d'eux un "label" qui servira de préfixe aux balises concernées. Ainsi, on écrira par exemple :

<UnElement xmlns:UnEspaceDeNom="UneURI">

xmlns étant le "mot-clé" XML permettant de définir un espace de nom. Le champ d'utilisation de notre espace de nom est délimité par les balises d'ouverture et de fermeture de l'élément auquel il est associé (UnElement ici); l'URI (UneURI ici) peut par exemple être: http://www.w3.org/REC-MathML pour les balises MathML.

L'intérêt des espaces de nom est particulièrement notable dans le cas où il y a "conflit" de signification. Si l'on fait appel à une DTD contenant des balises nommées B, et que l'on inclut dans le même document XML du code HTML utilisant la balise B, il faudra définir un espace de nom (par exemple xmlns:H="http://www.w3.org/REC-html40") qui permettra de lever l'ambiguïté (la balise <b> étant sémantiquement distincte de la balise <H:b> dans notre exemple).

1.2.4. Synthèse sur XML

XML avec l’ensemble des technologies qui lui sont associées (DTD, XML Schémas, espaces de noms, etc.) est certainement parvenu à un niveau de maturité qui en fait un format quasi universel pour structurer de données et de documents, si on considère la variété de ses usages :

- Langage de balisage de textes : XHTML, etc.

- Format de données : GML-données géographiques, XBRL-données comptables,

RSS (Really Simple Syndication).

- Langage de programmation : Servlet (serveur d'application Java), XAML

(langage développé pour les besoins du nouveau système d'exploitation de Windows Vista), etc.

- Langage de représentation (texte, image, etc.) : les documents Word sont en XML depuis sa version 2003 et les documents OpenOffice.org depuis 2001, etc.

- Protocole de communication : XForms (formulaires web W3C), WSDL

(Services Web), SOAP (transmission de messages entre objets distants), etc. - les nombreux formats de données issus de XML :

OFX (Open Financial eXchange) : pour les échanges d'informations dans le

monde financier,

MathML : pour représenter des formules mathématiques.

CML (Chemical Markup Language) : permet de décrire des composés

chimiques,

SMIL (Synchronized Multimedia Integration Language) : pour créer des

présentations multimédia en synchronisant diverses sources : audio, vidéo, texte, etc.

MusicXML : pour représenter les notations musicales.

1.3. Données et documents : documents orientés données vs

documents orientés texte

XML permet de structurer un document et gérer son contenu. Il en résulte une suite d'éléments parfaitement identifiables que rien n'empêche de considérer comme des données. On ne manque pas de faire le parallèle avec les BD dont le rôle est précisément de stocker des données afin de pouvoir les manipuler. On utilise même fréquemment des documents semi-structurés XML uniquement à des fins de conservation et gestion de données (initialement échangés).

Exemple : Une table de BD relationnelle comporte 1000 enregistrements de 4 champs -"Id", "Prix", "NbChambre", "Description"- qui vont s'afficher sous forme de tableau (grâce au SGBDR qui utilise le langage SQL) et parmi lesquels je pourrai sélectionner tous ceux dont le champ " NbChambre " égal à "3" par une simple requête (là encore grâce à SQL via mon SGBDR). Les mêmes enregistrements pourront être contenus dans un document XML sous forme de 1000 balises englobant chacune 4 balises — "Id", "Prix", "NbChambre", "Description" (ou, suivant une variante 4 attributs portant ces

noms) — et, de la même façon, on pourra les afficher grâce au XQuery [W3C1] qui met en forme XML.

En fait, la question qui se pose est : peut-on considérer une collection de milliers de documents XML comme une BD ? On peut la considérer comme une BD car les documents XML contiennent d’une certaine manière des données plus ou moins structurées. Mais XML présente quelques inconvénients : ainsi, la redondance de données existe et l’accès aux données est lent parce qu’il n’y a pas d’index ou d’indexation. Une autre question intéressante qui peut se poser aussi est de se demander si XML et les technologies qui lui sont associées constituent un SGBD. La réponse à cette question est : « XML est une sorte de SGBD ». Dans le sens d’une réponse positive, XML fournit plusieurs des caractéristiques que l’on retrouve dans les SGBD : le stockage (les documents XML), les schémas (DTD, XML Schema), les langages de requête (XQuery, XPath, XQL, etc.), des interfaces de programmation (SAX, DOM), etc. Dans le sens d’une réponse négative, de nombreuses caractéristiques présentés dans les bases de données lui font défaut : un stockage efficace, les index, la sécurité, les transactions et l’intégrité des données, l’accès multi-utilisateur, etc.

L’élément le plus important lors du choix de type de stockage de documents XML est de savoir si XML est utilisé pour stocker des données ou du texte. Est-ce que, par exemple, XML est utilisé simplement en tant que vecteur de données entre la base et une application (qui peut d’ailleurs ne pas être XML) ? Ou bien XML est-il exploité intégralement, à la manière des documents au format XHTML ?

1.3.1. Les documents orientés données

Les documents orientés données utilisent XML en tant que vecteur de données. Ils sont conçus pour être exploités par des applications et le fait que XML soit utilisé est généralement accessoire. Autrement dit, il n’est pas primordial pour le fonctionnement de l’application que les données soient stockées en tant que document XML. L’intérêt est souvent d’utiliser XML comme "format d’échange" de données avec d’autres applications facile à utiliser et à interpréter. Ces documents sont caractérisés par une structure assez régulière, des données qui

présentent une granularité très fine et l’absence de contenus mixtes. L’ordre dans lequel les éléments enfants d’un même parent apparaissent est souvent insignifiant. À titre d’exemple, le document de la figure 1.1 est orienté données.

1.3.2. Les documents orientés texte

Les documents orientés texte sont habituellement conçus pour être utilisés par des humains. Les livres, messages électroniques, annonces et XHTML écrites à la main constituent de bons exemples de tels documents. Ils sont caractérisés par une structure moins régulière ou même quasiment irrégulière, des données qui présentent une granularité plus grande et beaucoup de contenus mixtes. L’ordre dans lequel les éléments enfants d’un même parent apparaissent est important. A titre d’exemple le document de la figure 1.5 est orienté texte.

La différence entre documents orientés données et documents orientés texte n’est pas assez claire en pratique. Un document orienté données comme un bon de commande par exemple peut contenir aussi des données de granularité forte et irrégulièrement structurées telles que des descriptions. Et inversement, un document orienté texte 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 mise à jour. Les documents médicaux constituent aussi d’autres exemples : ils sont écrits sous forme de notes mais contiennent des parties

Figure 1.5 : Exemple d’un document XML orienté texte

<?xml version="1.0" encoding="UTF-8" ?> <residence>

<maison> T2 à

<commune>sonnac sur l’hers</commune> département de l'Aude <prix> 1400 <devise>euro</devise> </prix>

<confort> gîte de plain-pied mitoyen à une autre location à proximité de la maison du propriétaire comprenant : séjour avec cheminée, cuisine avec lave-linge, frigo-congélateur. 1 chambre (1 lit 2 pers.), salle d'eau, WC, chauffage électrique. Salon de jardin, barbecue, jeux de plein air. Séjour idéal pour les amoureux de la nature, les randonneurs, VTT, les cueilleurs de

champignons en saison. </confort>

</maison> </residence>

distinctes telles que des dates, des noms, des procédures, et doivent souvent être stockés dans leur intégralité.

1.4. Manipulation des documents XML

La manipulation d’un document XML par un programme se fait par le biais de "parseurs". Un "parseur" est une application dont le rôle est de convertir un flux de balisage en une structure de sortie accessible par un programme. Le parseur vérifie la conformité d’un document XML à la norme XML, à savoir qu’un document XML doit être bien formé et valide si celui-ci est associé à une DTD ou à un schéma. Il existe 2 approches pour accéder à un document XML : les parseurs orientés événements et les parseurs de type arbre.

1.4.1. Les parseurs orientés événements

Les parseurs orientés événements se basent sur un modèle d'envoi d'évènements à chaque élément rencontré. Dans cette approche, le programme définit le traitement à effectuer pour chaque événement et construit ainsi une

structure de données. Cette technique est celle employée par l’API3 SAX (Simple

API for XML). Cette API fournit une interface événementielle pour parcourir un document XML : elle renvoie à l'application qui manipule le document XML des "événements" (ouverture de balise, fermeture de balise, contenu textuel...). Elle permet donc de traiter à la volée l'occurrence de telle ou telle balise. Le début d’un élément est capturé par une méthode et sa fin par une autre méthode. Ainsi chacun des événements déclenchés demande une implémentation de l’interface SAX afin de travailler avec l’information fournie par le parseur. Il existe plusieurs parseurs

SAX gratuits sur le marché dont Xerces développé par la fondation Apache4

(existe en JAVA et C++), JAXP (Java API for XML Parsing) développée par Sun, etc.

3_{Application Programming Interface} 4 _{http://www.apache.org/}

1.4.2. Les parseurs de type arbre

Le modèle DOM (Document Object Model) est une recommandation du W3C

depuis octobre 1998 [W3C6]. Les parseurs DOM, à la différence des parseurs

SAX, utilisent une approche hiérarchique. Ces parseurs sont les plus souvent utilisés. Le parseur charge le document XML en mémoire sous la forme d'un arbre. Il permet à l'utilisateur (au programme) une navigation aisée dans le document, de modifier facilement l'arbre ce dernier et de sauvegarder de document met à jour au format XML. Le DOM procure un modèle objet qui permet le représenter et de fournir des interfaces pour travailler avec tous les objets respectant la spécification XML. N’étant pas lui même un programme, le DOM définit des interfaces API qui établissent comment un logiciel qui lui est compatible doit permettre l’accès à un document et à la manipulation de son contenu. Il existe différents types de parseurs DOM sur le marché dont Xerces de la fondation Apache conçu pour les langages de programmation Java et C++ (Xerces contient un parseurs DOM et SAX à la fois), JDOM développée par Sun, etc.

1.4.3. Parseurs DOM vs parseurs SAX

Comment choisir le type de parseur à utiliser lors de la manipulation d’un document XML ?

• L’API SAX est bien adaptée pour les traitements qui ne nécessitent qu'une seule

passe sur le document, ou dans le cas de gros volumes de données, s'il n'est pas nécessaire d'avoir une représentation complète des données en mémoire.

• Lorsque les données XML doivent être manipulées ensemble et restructurées, il

est préférable d’utiliser les parseurs de type DOM afin de bénéficier de leur souplesse. Cependant pour de gros documents dont la taille est proche de la quantité de mémoire présente sur la machine, DOM devient insuffisant (rend l'utilisation de DOM lente.

Évidemment, cela pose le problème du choix entre les deux types de parseurs, ce qui provoque l'apparition de nombreux parseurs utilisant des interfaces propriétaires (par exemple, les bases de données XML native).

1.5. Stocker

des

documents

XML

Il existe en général deux méthodes classiques pour stocker les documents textuels : les enregistrer sur le système de fichiers ou sous forme de BLOB dans une base de données.

En effet, la caractérisation des documents XML comme orientés données ou

orientés texte permet d’aider au choix du mode de stockage à utiliser pour ces

documents. En règle générale, les documents orientés données sont stockés dans une base traditionnelle. Les documents orientés texte quant à eux sont stockés dans une base XML native, c’est-à-dire une base conçue spécialement pour stocker du XML. 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.

1.5.1. Stocker

les

documents

XML

sur

le

système

de

fichiers

Dans le cas d’une collection élémentaire de documents, comme par exemple une brève documentation, cette méthode consiste à stocker ces documents sur le système de fichiers sous forme textuelle. On peut alors utiliser des outils comme "grep" (Unix) pour les rechercher ou, dans le cas d’une collection de taille importante, des techniques de Recherche d’Informations (RI) classiques basées sur la fréquence de termes (tf*idf) dans le document [SBU88]. L’expression "tf*idf" est très connue dans le milieu de la RI : tf signifie "term frequency" et idf "inverted document frequency". Par tf, on désigne une mesure qui a rapport à l'importance d'un terme pour un document. En général, cette valeur est déterminée par la fréquence du terme dans le document. Par idf, on mesure si le terme est discriminant (ou non-uniformément distribué).

Les formules le plus souvent utilisées pour calculer le tf et l'idf sont les suivantes :

tf = fréquence d'occurrence du terme t dans un document d noté : ft,d

tf =

m a x ( )

t,d t,d

f

f , où max(ft,d) est la fréquence maximale des termes dans le

tf = lo g ( f_t,d) ,

tf = lo g ( f_t,d + 1 ) , etc.

id f = lo g (N )

n où N est le nombre de documents dans le corpus, et n ceux

qui contiennent le terme

Une formule de tf*idf est donc la multiplication d'une tf par une idf. Par exemple :

( )

Une formule tf*idf combine donc les deux critères qui sont : l'importance du terme pour un document (par tf), et le pouvoir de discrimination de ce terme (par idf). Ainsi, un terme qui a une valeur de tf*idf élevée doit être à la fois important dans ce document, et aussi il doit apparaître peu dans les autres documents. C'est le cas d’un terme correspondant à une caractéristique importante et unique d'un document. Cependant, des recherches plein texte sur des documents XML sont évidemment inadéquates car elles ne peuvent pas facilement distinguer les balises du texte et ne peuvent pas interpréter l’usage des entités.

1.5.2. Stocker des documents XML dans des BLOBs

Une option légèrement plus sophistiquée consiste à stocker les documents comme des BLOBs dans une base relationnelle. Cette méthode apporte certains des

Système de fichiers BLOB BD usuelles

?

Figure 1.6 : Les différents modes de stockage de documents XML Fichier

XML (texte)

avantages propres aux bases de données : contrôle de transaction, sécurité, accès multi-utilisateur, etc. En outre, de nombreuses bases de données relationnelles possèdent des outils de recherche et sont capables par exemple d’effectuer des recherches plein texte, des recherches de proximité, des recherches de synonymes et des recherches avec le tf*idf. Plusieurs de ces outils sont conçus pour être compatibles avec XML, ce qui élimine les problèmes liés à la recherche de documents XML en tant que simple texte.

1.5.3. Les schémas XML et les schémas de bases de données

Dans le but de transférer des données entre des documents XML et une BD, il est nécessaire de faire correspondre la structure de document XML (c’est-à-dire la DTD ou les XML Schémas) avec un schéma de BD.

Le transfert de données est alors construit au dessus de cette correspondance et la structure du document doit coïncider exactement avec la structure attendue par la correspondance réalisée. Cette approche a été conçue particulièrement pour les documents fortement structurés, puisque c’est un contexte dans lequel la correspondance peut être facilement formulée.

Nom Société Licence Type BD Vers XML Vers BD ADO Microsoft Commercial Relationnel x X Altova MapForce Altova Commercial Relationnel x X DB2XML Volker Turau Open Source Relationnel x -- DbToXml SoftRUs Commercial Relationnel x X mysql, mysqldump MySQL Open Source Relationnel x -- Oracle XML Dev. Kit Oracle Free Relationnel x X XML for Tables IBM Commercial Relationnel x --

Tableau 1.1 : Quelques logiciels pour faire le transfert entre BD et XML

La BD employée est souvent une BD relationnelle, mais rien n’empêche qu’elle soit objet ou hiérarchique. Dans le cas d’utilisation d’une BD relationnelle, la correspondance est basée sur l'idée de la décomposition des documents XML dans un ensemble de tables relationnelles.

Il existe de nombreux logiciels commerciaux (tableau 1.1) qui permettent de faire cette correspondance. Selon le logiciel utilisé, il peut être possible de spécifier si la colonne de données est stockée en tant qu’éléments fils (comme dans la figure 1.7) ou en tant qu’attributs (comme dans la figure 1.8) ou les deux en même temps, ainsi que de choisir les noms à utiliser pour chaque élément ou attribut. Dans le cas de décomposition automatique, le système essaye de produire automatiquement le "bon" schéma relationnel pour l’instance de données XML existante. La décomposition est basée sur les modèles (patterns) découverts dans l’instance de données XML. Les parties des documents qui ne s'adaptent pas dans le schéma relationnel produit sont stockées dans une base de débordement qui peut être mise en œuvre par un stockage non-relationnel ou par exemple des BLOBs.

1.5.4.

Stocker des documents XML dans des bases de données XML natives

Quand les données sont semi-structurées, autrement dit, lorsque les données possèdent une structure moins régulière et instable, la correspondance vers une BD relationnelle conduit soit à un grand nombre de colonnes possédant une valeur nulle (d’où une perte de place) soit à un grand nombre de tables (ce qui n’est pas efficace).

Figure 1.7 : Correspondance table et document XML (les colonnes sont des éléments)

<?xml version="1.0" encoding="UTF-8"?> <table> <ligne> <colonne_1> <colonne_1> <colonne_2> <colonne_2/> . <colonne_n> <colonne_n/> <ligne/> . . <ligne> <colonne_1> <colonne_1> <colonne_2> <colonne_2/> . <colonne_n> <colonne_n/> <ligne/> <table/>

Les bases de données XML natives sont des bases conçues spécialement pour stocker des documents XML. Le tableau 1.2 donne quelques exemples de ces bases. Comme toutes les autres bases, ces bases possèdent des fonctionnalités telles que les transactions, la sécurité, les accès multi-utilisateurs, un ensemble d’APIs, des langages de requête, etc. La seule différence par rapport aux bases de données usuelles, c’est qu’elles sont basées sur XML, et pas sur un autre modèle comme dans le cas des bases relationnelles. Les bases de données XML natives sont souvent utilisées pour le stockage des contenus orientés texte, en raison du fait qu’elles préservent des propriétés telles que l’ordre interne du document, les instructions de traitement, les commentaires, les sections CDATA, l'utilisation des entités, etc., ce que ne font pas les bases qui sont seulement compatibles XML.

Nom Société Licence type de BD

Berkeley DB XML Oracle Open Source Key-value dbXML dbXML Group Open Source Propriétaire eXist Wolfgang Meier Open Source Relationnel Lore Stanford University Recherche Semi-structuré ozone ozone-db.org Open Source Orienté objet

Sonic XML Server Sonic Software Commercial Orienté objet, Relationnel Tamino Software AG Commercial Propriétaire, Relationnel Timber Univ.of Michigan Open Source Berkeley DB

Xindice Apache Open Source Propriétaire Xyleme Zone INRIA (Xyleme SA) Commercial Propriétaire XediX CEA (AM Systems) Commercial Propriétaire

Tableau 1. 2 : Quelques exemples des bases XML natives existantes

<?xml version="1.0" encoding="UTF-8"?> <table>

<ligne colonne_1=" " colonne_2=" " . . . colonne_n=" "/> .

. .

<ligne colonne_1=" " colonne_2=" " . . . colonne_n=" "/> </table>

En outre, les bases XML natives supportent les langages de requête XML qui permettent de poser des requêtes telles que : « Donnez-moi tous les documents dans lesquels le troisième paragraphe après le début d’une section contient un mot en caractères gras. » De telles recherches sont manifestement difficiles à formuler au moyen d’un langage tel que SQL. Il existe plusieurs autres utilisations des bases XML natives, comme le stockage des données semi-structurées, et le stockage de documents qui ne possèdent pas de DTDs ou tout autre type de schéma XML. Ce qui veut dire qu’une base de données XML native peut accepter, stocker et "comprendre" n’importe quel document XML sans configuration préalable. Une base de données XML native ne repose pas sur un modèle physique particulier pour le stockage. Elle peut par exemple être bâtie aussi bien sur une base relationnelle, hiérarchique, orientée objet, ou bien utiliser des techniques de stockage propriétaires comme des fichiers indexés ou compressés. Le tableau 1.2 montre quelques exemples des bases de données XML natives.

1.5.5. Synthèse sur les systèmes de stockage de documents XML

Avant de s'interroger sur la manière de stocker des données semi-structurées, il convient de savoir dans quel but on veut les stocker, et quelle utilisation on en fera. Ainsi si le stockage n'a qu'un but simplement documentaire, un simple stockage dans un système de fichier suffirait, par contre, une requête sur les valeurs internes de ce document sera impossible ou très coûteuse. Plusieurs façons de stocker des données XML existent : sous forme de BLOB dans un SGBD-R/O ou dans un SGBD natif semi-structuré. Le stockage par BLOB convient à un stockage orienté texte, c'est-à-dire de type documentaire. Le stockage SGBD-R convient plutôt à un stockage orienté données. Et le stockage dans un SGBD natif peut convenir aux deux types de stockage suivant les spécificités du SGBD natif utilisé. Cependant, les tailles des collections XML prennent souvent des proportions importantes, voire considérables. Si une recherche d'information dans une collection s'effectue de manière simplement séquentielle (c'est à dire en examinant toute la collection, du début jusqu'à la fin), le temps d'attente peut devenir prohibitif pour l'opérateur. L'indexation est l'outil qui permet de résoudre ce

problème. Dans la section suivante nous présentons un état de l’art sur les techniques d’indexation pour les documents XML.

1.6. Indexation des documents XML

D’un point de vue base de données, le format XML est une nouvelle approche pour modéliser l’information. Par conséquent, le développement de systèmes permettant de stocker et d’interroger efficacement des documents XML requiert aussi le développement de nouvelles techniques d’indexation. Rappelons que l’objectif des techniques d’indexation et d’accélérer l’accès à un donnée précise, autre que par un balayage séquentielle de l’ensemble complet des données. Nous allons étudier des techniques d’indexations basées sur les valeurs et l’indexation basée sur la structure

1.6.1. Indexation basée sur les valeurs

Pour indexer des données selon leurs valeurs, les structures de données communément utilisées dans les bases de données sont les arbres B ou "B-tree" et leurs variantes, comme le "B+-tree" ou arbre B+. Les arbres B sont des arbres balancés et triés qui permettent l’insertion et la suppression de nœuds en complexité amortie logarithmique [BMc71]. La recherche dans un tel arbre est similaire à celle effectuée dans un arbre binaire de recherche, c’est-à-dire en parcourant l’arbre de haut en bas et en choisissant à chaque fois le fils correspondant à la fourchette de valeur que l’on recherche.

L’idée principale des arbres B est que leurs nœuds peuvent avoir un nombre variable de fils dans une fourchette déterminée. Quand un nœud est inséré ou supprimé de l’arbre, le nombre de fils d’un nœud varie et les nœuds sont restructurés afin de garder la structure définie et de "rééquilibrer" l’arbre. Ce type d’arbre ne doit pas être "rééquilibré" aussi fréquemment qu’un arbre binaire de recherche auto-équilibré classique mais peut prendre plus de place en mémoire car certains nœuds peuvent ne pas être complètement remplis. Une variante très utilisée dans l’indexation, l’arbre B+, diffère des arbres B dans le fait que toutes les données sont sauvegardées dans les feuilles de l’arbre [BMc72]. Les nœuds internes ne contiennent que des clés et des pointeurs. Toutes les feuilles sont au même niveau et sont liées ensemble à la manière d’une liste afin de gérer facilement les requêtes portant sur des fourchettes de valeurs.

Nous pouvons citer aussi les arbres R et les arbres k-d et leurs variantes pour des données multidimensionnelles [BAG02]. Les arbres R sont toujours équilibrés et la taille de chacun de leurs noeuds voisine de celle d'une page disque.

Figure 1.9 : Partitionnement d’un ensemble de REMs dans un espace de dimension 2

Ils sont l'adaptation au domaine spatial de l'arbre B. Les rectangles englobants minimaux (REM) des objets spatiaux sont regroupés dans les feuilles selon un critère de proximité. Dans l’arbre R de base [Gut84], un objet spatial est inséré dans une seule feuille mais les noeuds internes, représentant des portions de l'espace, peuvent se recouvrir. L'arbre R s'adapte à des données évolutives et de distribution quelconque. Comme dans le cas de l'arbre B, les feuilles sont à la

même profondeur. Chaque noeud a un nombre d'entrées compris entre m (minimum) et M (maximum), 0<m<M/2. Au nombre des variantes, on remarque l'arbre R+ [SRF87] et l'arbre R* [BKS90]. L'arbre k-d est un arbre binaire tel que chaque noeud est associé à une région rectangulaire de l'espace [BAG02]. A chaque étape, l'espace est divisé en deux sous-espaces contenant si possible le même nombre d'objets. La décomposition s'arrête lorsque le nombre d'objets ayant leur centre dans le sous-espace est inférieur au seuil s fixé. Un noeud interne contient :

- un axe de division dit discriminant (l'axe des abscisses ou l'axe des ordonnées) ; - une valeur discriminante d=x0 ou d=y0 (la position de l'axe de division) ;

- deux pointeurs vers chacun des fils droit (sous-espace des centres de rem d'abscisse ou d'ordonnée inférieur ou égal à d) et gauche (sous- espace des centres de rem d'abscisse ou d'ordonnée supérieur ou égal à d).

- deux valeurs identifiant les emprises maximale et minimale atteintes par les rectangles englobants minimaux (REM) rangés dans le sous-espace suivant l'axe discriminant. Une feuille de l'arbre k-d contient au plus s (seuil) couples (REM, OID).

1.6.2. Indexation structurelle

Un nombre important de recherches a été fait récemment afin de concevoir des systèmes d’indexation correspondant aux besoins spécifiques de XML. Plusieurs plans de numérotation des nœuds pour les documents XML ont été proposés. Un plan de numérotation assigne un identificateur unique à chaque nœud dans l’arbre logique du document, comme en traversant l’arbre du document en préordre ou par niveau. Les identificateurs ainsi générés sont utilisés, dans le plan d’indexation, comme référence au nœud actuel. Un plan de numérotation doit fournir des mécanismes pour déterminer rapidement les relations structurelles entre une paire de nœuds et identifier toutes les occurrences d’une telle relation dans un document ou dans une collection de documents XML.

En résumé, un plan de numérotation doit supporter deux opérations basiques :

− La décision : Pour deux nœuds donnés, décider s’ils ont une relation spécifique, comme père-fils, ancêtre-descendant, frère-suivant, frère-précédent,

− La reconstruction : Pour un nœud donné, déterminer les identificateurs des nœuds de son voisinage comme, par exemple, le père, le frère suivant, le premier enfant, etc.

1.6.2.1. Numérotation de Dietz

Il est crucial pour l’interrogation des documents XML de fournir des mécanismes pour déterminer rapidement et efficacement le rapport de descendance entre les nœuds d'un arbre XML. La technique de la numérotation de Dietz [DSl87] est la première méthode qui a employé l'ordre de parcours d'arbre pour déterminer le rapport de descendance ou d’ascendance (ancêtre) entre n'importe quelle paire de nœuds d'arbre. La proposition de Dietz était : pour deux nœuds donnés x et y d'un arbre T, x est un ancêtre de y si et seulement si x apparaît avant y dans le parcours préordre de T et après y dans le parcours postordre de T. Dans la figure 1.8, un arbre XML dont les nœuds sont annotés par la numérotation de Dietz est montré. Chaque nœud est marqué avec une paire de préordre et de

postordre. Dans l'arbre, nous pouvons dire le nœud <3,3>est un ancêtre du nœud

<5,2>, parce que le nœud <3,3> vient avant le nœud <5,2>, dans le préordre (c’est-à-dire, 3<5) et après le nœud <5,2>dans le post-ordre (c’est-à-dire 3>2).

Le grand avantage de cette approche est que le rapport de descendance peut être déterminé dans un temps constant en examinant le préordre et le postordre des

Figure 1.10 : Un arbre XML annoté par la méthode Dietz residence numero ″140″ description nlits 4 maison été 1700 horssaison 1400 prix maison description numero ″123″ prix 1400 chambre 3 chambre nlits 2 nlits <1,14> <2,6> <3,3> <6,5> <4,1> <5,2> <7,4> <8,13> <9,7> <10,12> <13,11> <11,9> <12,8> <14,10>

nœuds de l'arbre. Par contre, en cas de mise à jour, une réindexation complète de l’arbre est nécessaire, ce qui fait que cette méthode ne sera pas efficace dans le domaine des bases de données, où les ajouts de données sont fréquents.

1.6.2.2. Numérotation basée sur la position des nœuds

Un plan d’indexation basé sur la position des nœuds et sur leur profondeur a été proposé par Zhang et al. [ZND01] en 2001. Dans ce plan, un élément est identifié par un quadruplet : l’identificateur du document (un numéro ou un référence unique attribué à chaque document), la position de départ dans le document, la position de fin et le niveau de profondeur. Les positions sont exprimées en terme de nombre de mots à partir du début du document XML. La proposition suivante permet de déterminer les relations ancêtre-descendant entre une paire de nœuds : un nœud x identifié par le quadruplet (D1,S1,E1,L1) est un descendant du nœud (D2,S2,E2,L2) si seulement si : D1=D2 et S1<S2 et E1>E2 (L est utilisé uniquement pour les relations père-fils).

1.6.2.3. Le système XISS

Le système XISS développé par Li et Moon en 2001 [LMo01], propose un plan de numérotation basé sur un parcours préordre étendu.

Figure 1.11 : Un arbre XML dont les nœuds sont annotés par XISS residence numero ″140″ description nlits 4 maison été 2000 horssaison 1700 prix maison description numero ″123″ prix 1400 chambre 3 chambre nlits 2 nlits <1,175> <10,65> <20,30> <55,15> <25,5> <35,5> <60,5> <80,75> <85,5> <95,45> <120,15> <100,15> <105,5> <125,5>