|
Copyright
1999-2003 par Ronald Bourret Traduction
[02/12/2003] par Patrick Peccatte (Soft
Experience)
de
l’article original
XML
and Databases
|
|
1.0 Introduction
2.0 XML est-il une base de données ?
3.0 Pourquoi utiliser une base de données ?
4.0 Données et Documents
4.1 Les contenus orientés données
4.2 Les contenus orientés document
4.3 Données, documents et bases de données
5.0 Stocker et retrouver des données
5.1 La correspondance entre les schémas de documents et les schémas de bases de données
5.1.1 La correspondance basée sur des tables
5.1.2 La correspondance basée sur un modèle objet relationnel
5.2 Les langages de requête
5.2.1 Les langages de requête basés sur des modèles
5.2.2 Les langages de requête basés sur SQL
5.2.3 Les langages de requête XML
5.3 Le stockage des données dans une base XML native
5.4 Types de données, valeurs nulles, jeux de caractères, etc.
5.4.1 Types de données
5.4.2 Données binaires
5.4.3 Données nulles
5.4.4 Jeux de caractères
5.4.5 Instructions de traitement et commentaires
5.4.6 Stocker le balisage
5.5 La génération de schémas XML à partir de schémas relationnels et vice-versa
6.0 Stocker et retrouver des documents
6.1 Stocker des documents sur le système de fichiers
6.2 Stocker des documents dans des BLOBs
6.3 Les bases de données XML natives
6.3.1 Qu'est-ce qu'une base de données XML native ?
6.3.2 Les architectures des bases de données XML natives
6.3.2.1 Les bases de données XML natives basées sur le texte
6.3.2.2 Les bases de données XML natives basées sur un modèle
6.3.3 Les caractéristiques des bases de données XML natives
6.3.3.1 Les collections de documents
6.3.3.2 Les langages de requête
6.3.3.3 Mises à jour et effacements
6.3.3.4 Transactions, verrouillages et accès concurrentiels
6.3.3.5 Les APIs [Application Programming Interfaces]
6.3.3.6 L’aller-retour des documents [Round-Tripping]
6.3.3.7 Les données distantes
6.3.3.8 Les index
6.3.3.9 Le stockage des entités externes
6.3.4 Normalisation, intégrité référentielle et scalabilité
6.3.4.1 La normalisation
6.3.4.2 L’intégrité référentielle
6.3.4.3 La scalabilité [Scalability]
6.4 Les DOMs persistants [PDOMs: Persistant Document Object Models]
6.5 Les systèmes de gestion de contenus [CMS: Content Management Systems]
7.0 Les produits "bases de données XML"
8.0 Liens complémentaires
9.0 Commentaires et avis
Cet article propose une vue d'ensemble de haut niveau sur la manière d'utiliser XML avec des bases de données. Il décrit la façon dont les différences entre les contenus orientés données et les contenus orientés document affectent l'utilisation des documents XML conjointement aux bases de données. Il montre aussi comment XML est habituellement utilisé avec des bases relationnelles et décrit ce que sont les bases de données XML natives et quand les utiliser.
Avant de commencer à parler de XML et des bases de données, nous devons répondre à une question que beaucoup de monde se pose : « XML est-il une base de données ? ».
Un document XML peut être considéré comme une base de donnés uniquement au sens le plus strict de l’expression. À savoir, une collection de données. XML en cela n’est guère différent des autres fichiers, car après tout, tous les fichiers contiennent d’une certaine manière des données. En tant que format de "base de données", XML présente cependant certains avantages. Il est par exemple auto-descriptif car les balises décrivent la structure et le type des noms des données ; il est portable puisque codé en Unicode, et il peut décrire les données sous la forme d’un arbre ou d’un graphe. Il présente aussi quelques inconvénients. Il est verbeux par exemple, et l’accès aux données est lent à cause de l’analyse [parsing] et de la conversion du texte.
Une question plus intéressante consiste à se demander si XML et les technologies qui lui sont associées constituent une "base de données" dans un sens plus large, c’est-à-dire au sens d’un système de gestion de base de données (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 bases de données : le stockage (les documents XML), les schémas (DTD, XML Schemas, RELAX NG, etc.), des langages de requête (XQuery, XPath, XQL, XML-QL, QUILT, etc.), des interfaces de programmation (SAX, DOM, JDOM), et ainsi de suite. Dans le sens d’une réponse négative, de nombreuses caractéristiques présentes 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, les déclencheurs [triggers], les requêtes sur plusieurs documents, etc.
Ainsi, bien qu’il soit possible d’utiliser un ou plusieurs documents XML comme une base de données dans les environnements qui présentent une faible quantité de données, qui comportent peu d’utilisateurs, et qui se satisfont de performances modestes, cela échouera dans la plupart des environnements de production qui disposent de nombreux utilisateurs, requièrent une stricte intégrité des données et ont besoin de bonnes performances.
Un fichier .ini -- c’est-à-dire un fichier contenant les informations de configuration d’une application -- constitue un bon exemple de type de "base de données" pour lequel un document XML est approprié. Il est bien plus facile d’inventer un petit langage XML et d’écrire une application SAX permettant d’interpréter ce langage que d’écrire un analyseur de fichier au format texte délimité par des virgules. De plus, XML permet d’imbriquer les entrées, ce qu’il est difficile de réaliser avec des fichiers au format texte délimité par des virgules. Il ne s’agit pourtant pas vraiment d’une base de données puisque le document XML est lu et écrit linéairement au début et à la fin de l’application.
Il existe d’autres exemples plus sophistiqués de collections de données pour lesquelles un document XML pourrait être utilisé en tant que base de donnée: les listes de contacts personnels (noms, numéros de téléphone, adresses, etc.), les liens favoris dans un navigateur, les descriptions des fichiers MP3 que vous avez subtilisés à l’aide de Napster… Cependant, étant donné le coût réduit et la facilité d’utilisation des bases de données telles que dBase ou Access, il semble, même pour les cas évoqués, qu’il existe peu de raisons d’utiliser un document XML en tant que base de données. Le seul véritable avantage d’un document XML est sa portabilité, et d’ailleurs, c’est un avantage moins crucial qu’il n’y paraît quand on considère le grand nombre d’outils disponibles pour sérialiser sous forme XML une base de données.
La première question à laquelle vous devez répondre quand vous commencez à penser à XML et aux bases de données est « pourquoi donc utiliser une base de données ? ». Avez-vous des données déjà existantes [legacy data] que vous souhaitez publier ? Recherchez-vous un endroit où stocker vos pages Web ? La base est-elle exploitée par une application de e-commerce dans laquelle XML est utilisé comme vecteur de données ? Les réponses à ces questions influenceront grandement votre choix de base de données et de logiciel intermédiaire [middleware] (s’il y a lieu) ainsi que la manière d’utiliser cette base.
Supposons par exemple que la base de données soit exploitée par une application de e-commerce dans laquelle XML est utilisé comme vecteur de données. Il y a fort à parier que vos données possèdent une structure hautement régulière et soient utilisées par des applications non XML. De plus, des notions telles que les entités et les techniques d’encodage utilisées dans les documents XML ne sont probablement pas importantes pour vous ; après tout, ce sont les données qui vous intéressent, pas la façon dont elles sont stockées dans un document XML. Dans ce cas de figure, vous aurez vraisemblablement besoin d’une base de données relationnelle et d’une couche logicielle pour transférer les données entre les documents XML et la base. Et si vos applications sont orientées objet, vous pourriez même souhaiter un système capable de stocker ces objets dans la base ou de les sérialiser en XML.
Supposons par contre que vous disposiez d’un site Web constitué d’un grand nombre de documents orientés texte. Vous souhaitez alors non seulement gérer ce site, mais également fournir aux utilisateurs un moyen de recherche sur le contenu. Vos documents ont toutes les chances d’avoir une structure bien moins régulière, et des notions telles que les entités seront probablement importantes pour vous parce qu’il s’agit là d’un aspect fondamental de la manière dont les documents sont structurés. Dans ce cas, vous souhaiterez utiliser une base de données XML native ou un système de gestion de contenu [content management system]. Cela vous permettra de préserver la structure physique des documents, de supporter les transactions au niveau du document, et d’effectuer des interrogations dans un langage de requête XML.
Le facteur le plus important en ce qui concerne le choix d’une base de données est peut-être de savoir si vous utiliserez la base pour stocker des données ou des documents. 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 ou DocBook ? Il s’agit là habituellement d’une question pratique, mais elle est d’importance, car tous les contenus orientés données partagent un certain nombre de caractéristiques [il en est de même de leur côté des contenus orientés document] et ces caractéristiques influencent la manière dont XML est stocké dans la base de données. Les deux sections suivantes examinent ces caractéristiques.
(Note historique : J’ai entendu parler pour la première fois des expressions orienté données [data-centric] et orienté document [document-centric] sur la liste de diffusion xml-dev. Je ne sais pas qui a inventé ces expressions, mais j’ai retrouvé des messages datant de 1997 utilisant document-centric et des messages de 1998 qui utilisent les deux locutions.)
Les contenus orientés données utilisent XML en tant que vecteur de données. Ils sont conçus pour être exploités par une machine et le fait que XML soit utilisé est généralement accessoire. Autrement dit, il n’est pas important pour l’application ou la base que les données soient stockées, pendant un certain temps, en tant que document XML. Les ordres de vente, les prévisions de vols, les données scientifiques, les cotations de marchés constituent quelques exemples de contenus orientés données.
Les contenus orientés données sont caractérisés par une structure assez régulière, des données qui présentent une granularité fine (c’est-à-dire que la plus petite unité indépendante de donnée est située au niveau d’un élément de type PCDATA unique ou d’un attribut), et peu ou pas du tout de contenus mixtes. L’ordre dans lequel les éléments enfants d’un même parent [les sibling elements] et les PCDATA apparaissent n’est en général pas significatif, excepté lorsque l’on valide le document au sens XML.
Les données que l’on trouve dans les contenus orientés données peuvent à la fois être originaires de la base (auquel cas on les publie sous forme XML) ou être situés en dehors de la base (et on les stocke alors dans la base). Un exemple du premier cas est fourni par la très grande quantité de données déjà existantes [legacy data] stockées dans les bases relationnelles ; un exemple du second cas est constitué par les données scientifiques collectées par un système de mesure et converties au format XML.
À titre d’exemple, l’ordre de ventes suivant est orienté données :
<OrdreDeVentes
NumeroOrdreDeVentes="12345">
<Client NumeroClient="543">
<NomClient>ABC
Industries</NomClient>
<Rue>123 Main St.</Rue>
<Ville>Chicago</Ville>
<Etat>IL</Etat>
<CodePostal>60609</CodePostal>
</Client>
<DateOrdre>981215</DateOrdre>
<Item NumeroItem="1">
<Lot
NumeroLot="123">
<Description>
<p><b>Turkey
wrench:</b><br />
Stainless steel, one-piece construction,
lifetime guarantee.</p>
</Description>
<Prix>9.95</Prix>
</Lot>
<Quantite>10</Quantite>
</Item>
<Item NumeroItem="2">
<Lot NumeroLot="456">
<Description>
<p><b>Stuffing
separator:<b><br />
Aluminum, one-year guarantee.</p>
</Description>
<Prix>13.27</Prix>
</Lot>
<Quantite>5</Quantite>
</Item>
</OrdreDeVentes>
En plus de contenus aussi manifestement orientés données que l’ordre de ventes ci-dessus, de nombreux documents riches en texte sont en fait également orientés données. Considérons par exemple une page du site Amazon.com affichant des informations à propos d’un livre. Bien que la page soit largement constituée de texte, la structure de ce texte est tout à fait régulière : la majeure partie est commune à toutes les pages qui décrivent des livres, et chaque portion de texte spécifique possède une taille limitée. Ainsi, la page peut être construite à partir d’un contenu orienté données simple contenant l’information relative à un livre unique ; ce contenu est retrouvé dans la base de données et une feuille de style XSL y ajoute les zones fixes. En règle générale, tout site Web actuel construisant dynamiquement du code HTML en remplissant un modèle à l’aide de données extraites d’une base peut probablement être remplacé par une série de documents XML orientés données et une ou plusieurs feuilles de style XSL.
Considérons par exemple le document suivant qui décrit un vol :
<InformationsVol>
<Compagnie>ABC
Airways</Compagnie> propose
<Nombre>trois</Nombre>
vols quotidiens sans escales depuis
<Depart>Dallas</Depart>
à destination de
<Destination>Fort
Worth</Destination>. Les heures de départ
sont
<HeureDepart>09:15</HeureDepart>,
<HeureDepart>11:15</HeureDepart>,
et
<HeureDepart>13:15</HeureDepart>. Les
arrivées interviennent une minute plus tard.
</InformationsVol>
Il pourrait être généré à partir du document XML suivant et d’une simple feuille de style :
<Vols>
<Compagnie>ABC Airways</Compagnie>
<Depart>Dallas</Depart>
<Destination>Fort Worth</Destination>
<Vol>
<HeureDepart>09:15</HeureDepart>
<HeureArrivee>09:16</HeureArrivee>
</Vol>
<Vol>
<HeureDepart>11:15</HeureDepart>
<HeureArrivee>11:16</HeureArrivee>
</Vol>
<Vol>
<HeureDepart>13:15</HeureDepart>
<HeureArrivee>13:16</HeureArrivee>
</Vol>
</Vols>
Les contenus orientés document sont habituellement conçus pour être utilisés par des humains. Les livres, messages électroniques, annonces, ainsi que presque toutes les pages XHTML écrites à la main constituent des exemples de tels documents. Ils sont caractérisés par une structure moins régulière ou même franchement irrégulière, des données qui présentent une granularité plus grande (c’est-à-dire que la plus petite unité indépendante de donnée peut être située au niveau d’un élément mêlant différents contenus, voire même au niveau du document lui-même), et beaucoup de contenus mixtes. L’ordre dans lequel les éléments enfants d’un même parent et les PCDATA apparaissent est presque toujours significatif.
Les contenus orientés document sont ordinairement écrits manuellement en XML ou sous d’autres formats tels que RTF, PDF ou SGML, puis ils sont convertis en XML. À la différence des contenus orientés données, ils ne sont pas habituellement localisés dans la base (les documents générés à partir de données insérées dans un modèle sont en fait orientés données - pour plus d’informations, voir la fin de la section 4.1.). Si vous recherchez des informations sur les logiciels des conversions vers XML à partir de plusieurs types de formats, vous pouvez consulter les liens vers différentes listes de logiciels XML.
Le document suivant, par exemple, décrit un produit et il est orienté document :
<Produit>
<Intro>
The
<ProductName>Turkey Wrench</ProductName>
from <Developer>Full
Fabrication Labs, Inc.</Developer> is
<Summary>like a monkey
wrench,
but not as
big.</Summary>
</Intro>
<Description>
<Para>The
turkey wrench, which comes in <i>both right- and left-
handed versions (skyhook optional)</i>, is
made of the
<b>finest
stainless
steel</b>. The Readi-grip rubberized handle quickly adapts
to your hands, even in the greasiest situations.
Adjustment is
possible through a variety of custom
dials.</Para>
<Para>You can:</Para>
<Liste>
<Item><Link
URL="Order.html">Order your own turkey
wrench</Link></Item>
<Item><Link
URL="Wrenches.htm">Read more about
wrenches</Link></Item>
<Item><Link
URL="Catalog.zip">Download the
catalog</Link></Item>
</Liste>
<Para>The
turkey wrench costs <b>just $19.99</b> and,
if you
order now, comes with a <b>hand-crafted
shrimp hammer</b> as
a
bonus gift.</Para>
</Description>
</Produit>
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.
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).
Le reste de cet article traite des stratégies et des problèmes liés au stockage et à la recherche de données (section 5) et de documents (section 6). Pour une liste à jour des systèmes de bases de données XML, consultez le document XML Database Products.
Dans le but de transférer des données entre les documents XML et une base, il est nécessaire de faire correspondre le schéma du document XML (c’est-à-dire la DTD, les XML Schemas ou RELAX NG, etc.) avec le schéma de la base. Le logiciel de transfert de données est alors construit au dessus de cette correspondance. Il peut utiliser un langage de requête XML (tel que XPath, XQuery, ou un langage propriétaire) ou simplement transférer des données selon la correspondance effectuée (l’équivalent XML d’un SELECT * FROM Table).
Dans le dernier cas, la structure du document doit coïncider exactement avec la structure attendue par la correspondance réalisée. Comme cela n’arrive pas souvent, les produits qui exploitent cette stratégie sont souvent utilisés avec XSLT. Autrement dit, avant de transférer les données à la base, le document est d’abord transformé en structure attendue par la correspondance, et ensuite seulement les données sont transférées. De la même manière, après avoir effectué un transfert de données depuis la base, le document résultant est transformé selon la structure attendue par l’application.
Les correspondances entre les schémas de documents et les schémas de bases de données sont effectués sur les types des éléments, les attributs et le texte. Elles omettent la plupart du temps la structure physique (comme les entités, les sections CDATA et les informations concernant l’encodage) et certaines structures logiques (telles que les instructions de traitement, les commentaires, ainsi que l’ordre dans lequel les éléments et les PCDATA apparaissent dans une filiation). Ceci est d’ailleurs plus raisonnable qu’il n’y paraît pour autant que la base et l’application soient uniquement concernées par les données à l’intérieur du document XML. Dans l’exemple évoqué ci-dessus concernant un ordre de ventes, il n’est pas important que le numéro du client soit stocké dans une section CDATA, une entité externe, ou directement dans une PCDATA, et il importe peu également que le numéro du client soit stocké avant la date de l’ordre ou après celle-ci.
Une conséquence de tout ceci c’est que l’"aller et retour" d’un document [le "round-tripping"] -- c’est-à-dire le stockage de données depuis un document dans la base et la reconstruction ultérieure du document à partir des données de la base -- conduit souvent à un autre document, même au sens canonique du terme. Le caractère acceptable ou non de ce fait dépend de vos besoins et peut influencer votre choix de logiciel.
Deux correspondances sont couramment utilisées pour faire coïncider un schéma de document XML avec un schéma de base de données : la correspondance basée sur des tables et la correspondance basée un modèle objet relationnel.
La correspondance basée sur des tables est utilisée par de nombreux logiciels intermédiaires [middleware] qui transfèrent les données entre un document XML et une base relationnelle. Elle modélise les documents sous la forme d’une table unique ou comme un ensemble de tables. Cela signifie que la structure d’un document XML doit être comme suit :
<database>
<table>
<row>
<column1>...</column1>
<column2>...</column2>
...
</row>
<row>
...
</row>
...
</table>
<table>
...
</table>
...
</database>
[l’élément <database> et les éléments supplémentaires <table> n’existent pas dans le cas où la modélisation est effectuée à l’aide d’une table unique].
Selon le logiciel, il peut être possible de spécifier si la colonne de données est stockée en tant qu’éléments fils ou comme attributs, ainsi que les noms à utiliser pour chaque élément ou attribut. De plus, les produits utilisant la correspondance basée sur des tables incluent souvent de manière optionnelle des métadonnées de table ou de colonne soit au début du document, soit comme attribut de chaque élément table ou colonne. Notez que le terme "table" est habituellement interprété de manière vague. Autrement dit, quand on transfère des données depuis une base vers un document, une "table" peut être constituée par n’importe quel ensemble de résultats, et quand on transfère des données depuis un document XML vers la base, une "table" peut être une véritable table ou une vue.
La correspondance basée sur des tables est utile pour sérialiser des données relationnelles, comme par exemple pour transférer des données entre deux bases de données relationnelles. Son inconvénient évident est qu’elle ne peut pas être utilisée pour un document qui n’est pas conforme au schéma exposé ci-dessus.
La correspondance basée sur un modèle objet relationnel est utilisée par toutes les bases de données relationnelles compatibles XML [XML-enabled] et quelques produits intermédiaires [middleware]. Les données du document sont alors modélisées comme un arbre d’objets spécifiques aux données. Dans ce modèle, les types d’éléments possédant des attributs, les contenus d’éléments ainsi que les contenus mixtes [les types d’éléments complexes] sont généralement modélisés comme des classes. Les types d’éléments contenant seulement des PCDATA [les types d’éléments simples], les attributs et les PCDATA elles-mêmes sont modélisés comme des propriétés scalaires. Le modèle est alors mis en correspondance avec la base relationnelle en utilisant des techniques de correspondance traditionnelles ou des vues d’objets en SQL 3. Autrement dit, les classes correspondent à des tables, les propriétés scalaires à des colonnes, et les propriétés de type objet/valeur correspondent à des paires du genre clé principale/clé secondaire.
(L’appellation "correspondance basée sur un modèle objet relationnel" est ici impropre, car l’arbre des objets peut être mis en correspondance aussi bien avec une base relationnelle qu’avec une base hiérarchique. Nous l’utilisons cependant parce que l’écrasante majorité des produits qui adoptent cette correspondance utilisent des bases relationnelles, et que l’expression "correspondance basée sur un modèle objet relationnel" est bien connue.)
Il est important de comprendre que le modèle objet utilisé ici n’est pas le Modèle Objet de Document [DOM - Document Object Model]. Le DOM modélise le document lui-même et il est le même pour tous les documents XML, tandis que le modèle décrit ci-dessus modélise les données du document et qu’il est ainsi différent pour chaque ensemble de documents XML conformes à un schéma XML donné. (Par convention, l’expression schéma XML avec un "s" bas de casse renvoie à n’importe quel schéma, que ce soit une DTD, un document XML Schema, ou un schéma RELAX NG. XML Schema avec un "S" capital se réfère au langage XML Schema du W3C.) À titre d’exemple, le document ordre de ventes décrit ci-dessus pourrait être modélisé comme un arbre d’objets composé de quatre classes -- OrdreDeVentes, Client, Item, Lot -- tel que le montre le schéma suivant :
OrdreDeVentes
/ | \
Client Item Item
| |
Lot Lot
Tandis qu’un arbre DOM du même document serait composé d’objets tels que les Éléments, les Attributs et les Textes :
Élément --- Attribut
(OrdreDeVentes) (NumeroOrdreDeVentes)
____/ / \ \_____
/ / \ \
Élément Texte Élément Élément
(Client) (DateOrdre) (Item) (Item)
| | |
etc. etc. etc.
La question de savoir si les objets du modèle sont effectivement instanciés dépend du produit. Certains produits autorisent la génération des classes du modèle et l’on utilise ensuite les objets instanciés à partir de ces classes dans l’application. Avec de tels produits, les données sont transférées entre le document XML et ces objets, puis entre ces objets et la base. D’autres produits utilisent les objets uniquement comme des outils qui permettent de visualiser la correspondance et le transfert des données directement entre le document XML et la base. La question de savoir s’il est utile d’instancier les objets intermédiaires dépend alors entièrement de votre application.
(La liaison entre les documents XML et les objets est appelée habituellement liaison des données XML [XML data binding], d’après le document Java Architecture for XML Binding de Sun. Plusieurs produits implémentent la liaison des données XML, et beaucoup d’entre eux peuvent transférer les données entre les objets et la base. Pour de plus amples informations, consultez le document XML Data Binding Resources.)
La manière dont la correspondance basée sur un modèle objet relationnel est supportée varie d’un produit à l’autre. Par exemple :
<?xml
version="1.0"?>
<InformationsVol>
<Introduction>The following flights have
available
seats:</Introduction>
<SelectStmt>SELECT Compagnie, NumeroVol,
Depart, Arrivee FROM
Vols</SelectStmt>
<Vol>
<Compagnie>$Compagnie</Compagnie>
<NumeroVol>$NumeroVol</NumeroVol>
<Depart>$Depart</Depart>
<Arrivee>$Arrivee</Arrivee>
</Vol>
<Conclusion>We hope one of these meets your
needs</Conclusion>
</InformationsVol>
Le résultat du traitement d’un tel modèle pourrait être:
<?xml version="1.0"?>
<InformationsVol>
<Introduction>The following flights have available seats:</Introduction>
<Vols>
<Vol>
<Compagnie>ACME</Compagnie>
<NumeroVol>123</NumeroVol>
<Depart>Dec 12, 1998 13:43</Depart>
<Arrivee>Dec 13, 1998 01:21</Arrivee>
</Vol>
...
</Vols>
<Conclusion>We hope one of these meets your needs.</Conclusion>
</InformationsVol>
Les langages de requête basés sur des modèles peuvent être extrêmement flexibles. Bien que l’ensemble des caractéristiques varie d’un produit à l’autre, voici quelques traits habituels :
Les langages de requête basés sur des modèles sont utilisés presque exclusivement pour transférer des données depuis les bases relationnelles vers les documents XML. Bien que certains produits utilisant les langages de requête basés sur des modèles permettent de transférer des données depuis les documents XML vers les bases relationnelles, ils n’utilisent pas pleinement ce langage à cette fin. Au lieu de cela, ils utilisent la correspondance basée sur des tables comme il est décrit ci-dessus.
Les langages de requête basés sur SQL utilisent des ordres SELECT modifiés dont les résultats sont transformés en XML. Un certain nombre de langages propriétaires de ce type sont actuellement disponibles. Les plus simples d’entre eux utilisent des ordres SELECT imbriqués qui sont transformés directement en code XML imbriqué selon la correspondance basée sur un modèle objet relationnel. D’autres utilisent des vues objets SQL 3 qui sont également transformées directement en XML. Les derniers enfin utilisent des ordres OUTER UNION et des balises spéciales pour déterminer comment les résultats sont transformés en XML.
En plus des langages propriétaires, un certain nombre de sociétés se sont réunies durant l’année 2000 pour standardiser des extensions XML au langage SQL. Ce travail fait maintenant partie intégrante de la spécification ISO SQL et il est connu sous le nom de SQL/XML ; l'acceptation finale est attendue fin 2003. SQL/XML introduit des types de données XML et ajoute un certain nombre de fonctions à SQL de telle façon qu’il soit possible de construire des éléments et des attributs XML à partir de données relationnelles.
La requête suivante, par exemple :
SELECT Orders.SONumber,
XMLELEMENT(NAME "Order",
XMLATTRIBUTES(Orders.SONumber AS SONumber),
XMLELEMENT(NAME "Date", Orders.Date),
XMLELEMENT(NAME "Customer", Orders.Customer)) AS xmldocument
FROM Orders
construit un ensemble résultant possédant deux colonnes. La première colonne contient un numéro d’ordre des ventes et la seconde colonne contient un document XML. Il y a un document XML par ligne et il est construit d’après les données provenant de la ligne correspondante dans la table intitulée Orders. Le document XML en question pour la ligne d’ordre de numéro 123 pourrait être par exemple :
<Order SONumber="123">
<Date>10/29/02</Date>
<Customer>Gallagher Industries</Customer>
</Order>
Les informations concernant SQL/XML sont assez difficiles à trouver sur le Web. Pour obtenir des informations anciennes ainsi que quelques articles d’introduction, consultez le Site Web du groupe SQLX. Pour obtenir une copie de la spécification SQL/XML, consultez le répertoire FTP du site sqlstandards.org (ftp://sqlstandards.org/SC32/WG3/Progression_Documents/Informal_working_drafts/). Vous devriez y trouver un document dont le nom est du genre WD5-14-xml-yyyy-mm.pdf ou wd5-14-xml-yyyy-mm.pdf, où yyyy-mm est l’année et le mois de la spécification. Ainsi, pour Novembre 2003, la dernière spécification s’appelle WD5-14-xml-2003-09.pdf. Notez que le site FTP sqlstandards.org est souvent hors-service, et vous devrez renouveler l’essai. Une autre possibilité consiste à rechercher les mots "XMLForest" et "XMLAgg" sur Google.
À la différence des langages de requête basés sur des modèles et des langages de requête basés sur SQL qui peuvent être utilisés uniquement avec des bases de données relationnelles, les langages de requête XML peuvent être utilisés sur n’importe quel document XML. Pour utiliser ces langages avec des bases de données relationnelles, les données de la base doivent donc être modélisées en XML, ce qui permet de ce fait de formuler des requêtes sur des documents XML virtuels.
Avec XQuery, on peut utiliser soit une correspondance basée sur des tables, soit une correspondance basée sur un modèle objet relationnel. Si une correspondance basée sur des tables est utilisée, chaque table est traitée comme un document séparé et les jointures entre tables (documents) sont spécifiées, comme en SQL, dans la requête elle-même. Si une correspondance basée sur un modèle objet relationnel est utilisée, les hiérarchies de tables sont traitées comme un unique document et les jointures sont spécifiées dans la correspondance. Il semble vraisemblable que les correspondances basées sur des tables seront employées dans la plupart des implémentations sur des bases de données relationnelles car elles paraissent plus simples à implémenter et plus familières aux utilisateurs de SQL.
Avec XPath, une correspondance basée sur un modèle objet relationnel doit être utilisée pour effectuer des requêtes qui portent sur plus d’une table. Ceci est dû au fait que XPath ne supporte pas les jointures de documents. Ainsi, si l’on utilise une correspondance basée sur des tables, il sera possible d’effectuer une requête uniquement sur une table à la fois.
Il est également possible de stocker des données issues de documents XML dans une base XML native. Il existe plusieurs raisons pour procéder de cette façon. La première de ces raisons s’impose quand vos données sont semi-structurées ; autrement dit, lorsque les données possèdent une structure régulière, mais que cette structure varie néanmoins suffisamment pour que la correspondance vers une base relationnelle conduise 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). Bien que des données semi-structurées puissent être stockées dans des bases orientées objet ou des bases hiérarchiques, vous pouvez aussi choisir de les stocker dans une base XML native sous la forme d’un document XML.
Une seconde raison tient à la vitesse d’accès. Selon la manière dont une base XML native stocke les données, elle peut être capable de retrouver des données beaucoup plus rapidement qu’une base relationnelle. L’explication de ce fait vient de ce que certaines stratégies de stockage utilisées par les bases natives sauvegardent physiquement ensemble des documents entiers ou utilisent des pointeurs physiques (plutôt que logiques) entre les différentes parties des documents. Ceci permet aux documents d’être retrouvés sans utilisation de jointures ou seulement à l’aide de jointures physiques, deux techniques qui sont bien plus rapides que les jointures logiques utilisées dans les bases relationnelles.
Considérons par exemple le document Ordre de ventes déjà examiné précédemment. Il pourrait être stocké dans une base relationnelle en utilisant quatre tables (OrdreDeVentes, Items, Clients, Lots) et la recherche du document exigerait de joindre ces quatre tables. Dans une base native, le document pourrait être stocké sur un emplacement physique unique sur disque, de telle manière que sa recherche ou la recherche de l’une de ses parties demanderait une seule interrogation d’index et une seule lecture pour retrouver les données. Une base relationnelle exigerait quatre consultations d’index et au moins quatre lectures pour le même résultat.
L’inconvénient manifeste, dans ce cas, tient au fait que le gain de vitesse s’applique seulement quand on recherche des données dans l’ordre où elles sont stockées sur disque. Si vous recherchez ces données selon une vue différente, telle par exemple une liste des clients et des ventes qui les concernent, les performances seront alors probablement pires qu’avec une base relationnelle. Ainsi donc, le stockage des données dans une base XML native pour des raisons de performance se justifie seulement quand l’une des vue sur les données prédomine dans l’application en question.
Une troisième raison en faveur du stockage des données dans une base XML native concerne l’exploitation des possibilités spécifiques au XML, telle que l’exécution de requêtes XML. Mais étant donné que peu d’applications orientées données ont besoin de cela aujourd’hui et que les bases relationnelles implémentent des langages de requête XML, cette dernière raison est moins contraignante.
La plupart des bases XML natives peuvent seulement renvoyer des données sous une forme XML, et cela constitue l’un des problèmes du stockage des données dans une telle base. (Peu de produits supportent le lien des éléments ou des attributs à des variables d’application). Si votre application a besoin de données dans un autre format (ce qui est probable), elle doit analyser le XML renvoyé avant d’utiliser les données. Ceci est clairement un désavantage des applications locales qui utilisent une base XML native au lieu d’une base relationnelle, car cela induit une surcharge que l’on ne trouve pas, par exemple, dans une application ODBC. Ce n’est pas un problème avec les applications distribuées utilisant XML comme transport de données puisque ces applications induisent une surcharge indépendamment du type de base utilisé.
Cette section traite d’un certain nombre de sujets relatifs au stockage des données d’un document XML dans les bases traditionnelles. (Ce qui a trait aux types de données et aux données binaires s’applique toutefois également aux bases XML natives). En général, on n’a guère le choix en ce qui concerne la manière dont le logiciel de transfert résout les questions évoquées. Vous devez cependant être conscient que ces questions existent et qu’elles peuvent vous aider à choisir un logiciel.
Quel que soit le sens que l’on donne à cette expression, XML ne supporte pas la notion de type de données. À l’exception des entités non analysées [unparsed entities], toute donnée d’un document XML est du texte, même si elle représente un autre type comme une date ou un nombre entier. En général, le logiciel de transfert convertira les données de type texte (dans le document XML) en données d’autres types (dans la base) et vice-versa.
La manière dont le logiciel détermine quelle conversion effectuer est propre à chaque produit. Deux méthodes sont néanmoins courantes. Dans la première méthode, le logiciel détermine le type d’après le schéma de la base qui est toujours disponible lors de l’exécution. (Alors que le schéma XML n’est pas nécessairement disponible au moment de l’exécution et peut même ne pas exister.) Dans la seconde méthode, l’utilisateur spécifie explicitement le type de données en utilisant par exemple une correspondance d’information. Ceci peut être exprimé par l’utilisateur ou généré automatiquement d’après un schéma de base ou un schéma XML. Dans le cas d’une génération automatique, les types de données peuvent alors être retrouvés depuis les schémas de la base et depuis certains types de schémas XML (comme les XML Schemas ou RELAX NG).
Un problème supplémentaire apparaît avec les conversions : quels formats de texte sont reconnus (quand les données sont transférées depuis le XML) ou peuvent être créés (quand les données sont transférées vers le XML). Dans la plupart des cas, le nombre de formats de texte supportés pour un type particulier de données sera probablement limité ; ce peut être par exemple un format unique et spécifique, ou les seuls formats supportés par un pilote JDBC donné. Les dates peuvent éventuellement poser des problèmes car la gamme des formats possibles est considérable. De même, les nombres avec leurs grande variété de formats internationaux peuvent poser des problèmes.
Il existe trois manières courantes de stocker des données binaires dans des documents XML : le codage Base64 (un codage MIME qui fait correspondre aux données binaires un sous-ensemble de l’ASCII-US [0-9a-zA-Z+/] -- voir la spécification RFC 2045), le codage hexadécimal où chaque octet binaire est codé en utilisant deux caractères représentant des digits décimaux [0-9a-fA-F], et des entités non analysées [unparsed entities] où les données binaires sont stockées dans une entité physique séparée du reste du document XML.
La principal problème en ce qui concerne les données binaires vient de ce que beaucoup de produits de transfert de données (si ce n’est la plupart) ne le supportent pas. Vérifiez-donc que le votre le permet. Un second problème intervient si des entités non analysées sont utilisées : car la plupart des produits de transfert de données (peut-être tous ?) ne stockent pas les déclarations d’entités et de notations. Ainsi, la notation associée à une entité particulière sera perdue quand les données seront transférées d’un document XML vers la base. (Pour de plus amples informations concernant les notations, consultez la section 4.7 de la recommandation XML 1.0.)
Dans le monde des bases de données, une donnée nulle [null data] signifie une donnée absente. Cette notion est très différente de la valeur 0 pour les nombres ou de la longueur zéro pour les chaînes de caractères. Supposons par exemple que vous collectiez des données d’une station météorologique. Si le thermomètre ne fonctionne pas, une valeur nulle est stockée dans la base plutôt qu’une valeur 0 qui signifie quelque chose de tout à fait différent.
XML supporte également le concept de donnée nulle à travers les notions de types d’éléments et d’attributs optionnels. Si la valeur d’un type d’élément ou d’un attribut optionnel est nul, cela signifie simplement qu’il n’est pas inclus dans le document. Comme pour les bases de données, les attributs qui contiennent des chaînes de longueur égales à zéro et les éléments vides ne sont pas nuls : leur valeur est une chaîne de longueur zéro.
Quand on met en correspondance la structure d’un document XML et celle d’une base de données, on doit prendre garde à ce que les types d’éléments et les attributs optionnels correspondent à des colonnes nulles et vice-versa. Ne pas se conformer à cela conduira vraisemblablement à une erreur d’insertion (quand on transfère les données vers la base) ou à un document invalide (quand on transfère les données depuis la base).
5.4.5 Instructions de traitement et commentaires
<description>
<b>Un exemple confus:</b>
<foo/>
</description>
<b>Un exemple confus:</b> <foo/>
<b>Un exemple confus:</b> <foo/>
<Client>
<Nom>ABC Industries</Nom>
<Adresse>
<Rue>123 Main St.</Rue>
<Ville>Fooville</Ville>
<Etat>CA</Etat>
<Pays>USA</Pays>
<CodePostal>95041</CodePostal>
</Adresse>
</Client>
Il existe deux méthodes de base pour stocker des documents XML : les enregistrer sur le système de fichiers ou sous forme de BLOB dans une base de données relationnelle et accepter alors des fonctionnalités XML limitées, ou les stocker dans une base XML native.
Si vous possédez un ensemble élémentaire de documents, comme par exemple une brève documentation, la meilleure méthode consiste à stocker ces documents sur le système de fichiers. Vous pouvez alors utiliser des outils comme grep pour les rechercher et sed pour les modifier. (Des recherches plein texte sur des documents XML sont évidemment inexactes car elles ne peuvent pas facilement distinguer les balises du texte et ne peuvent pas interpréter l’usage des entités.
Toutefois, dans un petit système, de telles inexactitudes peuvent être acceptables.) Si vous souhaitez disposer d’un contrôle de transaction simple, vous pouvez placer vos documents dans un système de contrôle de version tel que CVS ou RCS.
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 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 floues [fuzzy searches]. 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.
Quand vous stockez des documents XML sous forme de BLOBs, vous pouvez facilement implémenter votre propre indexation XML, même si la base de données ne sait pas indexer du XML. L’une des façons de réaliser ceci consiste à créer deux tables : une table d’index (connue sous le nom de side table en DB2 d’où provient l’idée) et une table des documents. La table des documents contient une clé primaire et une colonne BLOB où le document est stocké. La table index contient une colonne contenant la valeur à indexer et une clé étrangère pointant sur la clé primaire de la table des documents.
Quand le document est stocké dans la base, on recherche toutes les instances de l’élément ou de l’attribut en cours d’indexation. Chaque instance est stockée dans la table index, avec la clé primaire du document. La colonne valeur est alors indexée, ce qui permet à une application de rapidement rechercher un élément précis ou une valeur d’attribut et de retrouver le document correspondant.
Supposons par exemple que vous disposiez d’un ensemble de documents correspondant à la DTD suivante et que souhaitiez construire un index des auteurs :
<!ELEMENT
Brochure (Titre, Auteur, Contenu)>
<!ELEMENT Titre (#PCDATA)>
<!ELEMENT Auteur (#PCDATA)>
<!ELEMENT Contenu (%Inline;)> <!--
Inline est une entité XHTML
-->
Vous pourriez stocker ces documents dans les tables suivantes :
Auteurs
Brochures
----------------------------------------
---------------------------------------------
Auteur
VARCHAR(50)
BrochureID
INTEGER
BrochureID
INTEGER
Brochure
LONGVARCHAR
Quand vous insérez une brochure dans la base de données, l’application ajoute la brochure dans la table Brochures, analyse les éléments <Auteur>, enregistre leurs valeurs et le BrochureID dans la table des Auteurs. L’application peut alors retrouver les brochures par auteur à l’aide d’une simple instruction SELECT. Par exemple, pour chercher toutes les brochures écrites par l’auteur Chen, l’application exécute l’instruction
SELECT
Brochure
FROM Brochures
WHERE BrochureID IN (SELECT BrochureID FROM Auteurs WHERE
Auteur='Chen')
Une table index plus sophistiquée pourrait contenir quatre colonnes : type de l’élément ou nom de l’attribut, type (élément ou attribut), valeur et identifiant du document (ID). Ceci permettrait de stocker les valeurs de multiples balises dans une table simple et nécessiterait une indexation sur le nom, le type et la valeur. Écrire une application SAX générique pour charger une telle table serait relativement facile.
Il existe deux grandes catégories d’architectures de bases XML natives : les architectures basées sur le texte et celles qui sont basées sur un modèle.
Une base de données XML native basée sur le texte stocke le XML en tant que texte. Cela peut être un fichier dans un système de fichiers, un BLOB dans une base relationnelle, ou un format propriétaire. (Il est important de noter qu’une base relationnelle à laquelle on a ajouté un traitement compatible XML [XML-aware] des colonnes CLOB (Character Large Object) est bel et bien, au regard de ces capacités, une base XML native.)
Les index sont communs à toutes les bases de données XML natives basées sur le texte. Ils permettent au moteur de recherche de naviguer facilement en tout point d’un document XML quelconque. Cela procure à ce genre de base un avantage considérable en matière de vitesse quand on recherche des documents entiers ou des fragments de documents ; la base peut en effet réaliser une seule consultation de l’index, positionner la tête de lecture du disque une seule fois, puis, en supposant que le fragment requis est stocké dans des octets contigus sur le disque, retrouver le document entier ou un fragment en une seule lecture. Au contraire, ré-assembler un document à partir de morceaux comme on le fait avec une base relationnelle ou certaines bases XML natives basées sur un modèle demande de multiples consultations de l’index et de nombreuses lectures de disque.
De ce point de vue, une base de données XML native basée sur le texte est similaire à une base hiérarchique en ce sens que toutes deux surpassent une base relationnelle quand on recherche et retourne des données selon une hiérarchie prédéfinie. À l’instar également des bases hiérarchiques, les bases XML natives basées sur le texte sont susceptibles de rencontrer des problèmes de performance quand on recherche et retourne des données sous une forme quelconque, comme lorsqu’on inverse la hiérarchie ou des fragments de documents. On ne sait pas jusqu'ici si cela sera toujours vrai, mais la prédominance des bases de données relationnelles, dont l'utilisation des pointeurs logiques permet à toutes les questions d’une même complexité d'être exécutées avec la même vitesse, semble indiquer que ce sera le cas.
La seconde catégorie est constituée des bases XML natives basées sur un modèle. Plutôt que de stocker un document XML en tant que texte, elles construisent un modèle objet interne du document et stockent ce modèle. La manière dont le modèle est stocké dépend de la base. Certains produits st