SYSTÈMES INFORMATIQUES Systèmes de gestion de bases de données

Données semi-structurées et documents XML

Le modèle relationnel n'est pas adapté aux données hétérogènes ou de structure mal définie.

Exemple : Supposons que l'on veuille stocker des informations clients de deux banques indépendantes qui représentent leurs clients de manière différente (fig. 4).

Une représentation comme celle que propose XML permet de manipuler plus facilement des informations irrégulières, grâce à la possibilité de structurer et d'annoter des informations sans la définition d'un schéma fortement structuré et contraignant.

Le langage XML représente les informations sous forme de documents textuels annotés et structurés par des balises. La structure générée par les balises correspond à une arborescence d'éléments.

Par exemple, le document XML ci-dessous intègre les informations des deux tables Client 1 et Client 2 de la figure 4 (Les clients sont représentés sous forme d'éléments <client> qui contiennent les informations connues dans les deux sources, et les deux n-uplets correspondant au client Durant Pierre sont « fusionnés » en un seul élément comptant les deux numéros de client provenant des deux sources.) :

L'utilisation la plus simple de XML consiste à créer des documents sans avoir défini de contrainte sur leur structure. Mais on peut également, comme dans le modèle relationnel, contraindre un (ensemble de) document(s) à respecter une structure définie sous forme de schémas ou types de documents.

Une DTD (définition du type de documents) est un ensemble de règles qui spécifient pour chaque type d'élément les types de ses éléments fils, leur ordonnancement et leur fréquence. Par exemple, la règle DTD suivante signifie que les éléments <client> contiennent dans l'ordre un ou plusieurs éléments <numéro>, trois éléments <nom>, <prénom> et <adresse>, deux éléments optionnels <profession> et <âge>, suivis de zéro ou plusieurs éléments <comptes> :

< !ELEMENT client (numéro+ nom prénom adresse profession ?, age ?, compte*)>

L'adresse d'une personne est définie par un code et/ou une ville :

< !ELEMENT adresse ((code ville) | code | ville)>

Si on compare ces deux règles à la définition d'une table relationnelle, on voit deux différences importantes. Premièrement, la structure d'un élément est moins rigide que celle d'un n-uplet, où il ne peut y avoir de champs optionnels et où tous les attributs sont uniques. Deuxièmement, un attribut relationnel contient toujours une valeur atomique dans le domaine de définition, tandis qu'un élément peut contenir d'autres éléments, ce qui permet de construire des arbres XML de profondeur quelconque.

Il est possible de poser des requêtes précises en exploitant les noms des éléments et les relations topologiques qui existent entre les nœuds des arbres XML interrogés. Le langage de requêtes XPath permet ainsi de caractériser et d'extraire des éléments d'un document XML en spécifiant des contraintes sur leur structure et le contenu.

Une requête XPath est une séquence d'étapes qui « parcourent » le document ou l'ensemble de documents interrogés en suivant des axes structurels (enfants/parent, descendants/ancêtres, etc.) et en spécifiant des contraintes sur les types et les valeurs de nœuds parcourus.

Exemple : Les trois requêtes suivantes partent de la racine du document interrogé et chaque étape descend dans l'arborescence du document en filtrant les éléments par leur nom de balise. La réponse correspond aux éléments sélectionnés à la dernière étape.

Requête Q1 : Numéros de comptes dont le montant disponible est supérieur à 10 000 euros ?

/document/client/compte[montant>10000]/numéro

Chaque étape descend un niveau dans le document en filtrant le ou les éléments d'un certain[...]