XML et les bases de données 

Copyright 1999-2003 par Ronald Bourret
Dernière mise à jour: Novembre 2003

Traduction [02/12/2003] par Patrick Peccatte (Soft Experience)
de l’article original XML and Databases

Table des matières

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

 

1.0 Introduction

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.

2.0 XML est-il une base de données ?

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.

3.0 Pourquoi utiliser 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.

4.0 Données et Documents

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.)

4.1 Les contenus orientés données

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>

 4.2 Les contenus orientés document

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>

 4.3 Données, documents et bases de données

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.

5.0 Stocker et retrouver des données

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.

5.1 La correspondance entre les schémas de documents et les schémas de bases de données

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.

5.1.1 La correspondance basée sur des tables

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.

5.1.2 La correspondance basée sur un modèle objet relationnel

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 :

Pour une description complète de la correspondance basée sur un modèle objet relationnel, consultez la section 3 de l’article "Mapping DTDs to Databases".

5.2 Les langages de requête

Plusieurs produits transfèrent les données directement selon le modèle sur lequel ils sont construits. Étant donné que la structure du document XML est souvent différente de la structure de la base, ces produits incluent ou sont souvent utilisés avec des XSLT. Cela permet de transformer des documents selon la structure commandée par le modèle avant de transférer les données à la base (et vice-versa). Comme le traitement XSLT peut être coûteux, quelques produits intègrent aussi un nombre limité de transformations intégrées à leurs correspondances.

La solution à long terme à ce problème est l’implémentation de langages de requête renvoyant du XML. Actuellement (Novembre 2002), la plupart de ces langages reposent sur des ordres SELECT contenus dans des modèles. On s’attend à ce que la situation change alors que XQuery et SQL/XML sont en cours de finalisation et que les principaux fournisseurs de bases de données sont déjà en train de travailler sur ces implémentations. Malheureusement, presque tous les langages de requête XML (y compris XQuery 1.0 et la version initiale de SQL/XML) sont en lecture seule, ce qui signifie que différentes méthodes doivent être utilisées dans l’immédiat pour insérer, mettre à jour et effacer des données. (XQuery et SQL/XML intègreront à long terme ces possibilités.)

5.2.1 Les langages de requête basés sur des modèles

Les langages de requête les plus communs qui soient capables de renvoyer du XML depuis une base relationnelle sont ceux qui sont basés sur des modèles [template-based]. Dans ces langages, il n’existe pas de correspondance prédéfinie entre le document et la base. Au lieu de cela, les ordres SELECT sont englobés dans un modèle et les résultats sont traités par le logiciel de transfert de données. Ainsi par exemple, le modèle suivant (qui n’est employé dans aucun produit réel) utilise les éléments <SelectStmt> pour inclure les ordres SELECT et les valeurs $column-name pour déterminer où les résultats doivent être placés :

   <?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.

5.2.2 Les langages de requête basés sur SQL

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.

5.2.3 Les langages de requête XML

À 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.

5.3 Le stockage des données dans une base XML native

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é.

5.4 Types de données, valeurs nulles, jeux de caractères, etc.

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.

5.4.1 Types de données

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.

5.4.2 Données binaires

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.)

5.4.3 Données nulles

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).

En raison du fait que la communauté XML possède une conception de ce que signifie une donnée nulle sans doute plus relâchée que la communauté des bases de données [en particulier, de nombreux utilisateurs de XML considèrent probablement que des attributs contenant des chaînes de longueur zéro et des éléments vides sont en fait "nuls"], vous devez vérifier comment votre logiciel traite cette situation. Certains logiciels offrent à l’utilisateur le choix de définir ce qu’est le "nul" dans un document XML, y compris en supportant l’attribut xsi:null dans les XML Schemas.

5.4.4 Jeux de caractères

Par définition, un document XML peut contenir n’importe quel caractère Unicode à l’exception des caractères de contrôle. Malheureusement, beaucoup de bases de données proposent un support limité ou inexistant de l’Unicode et demandent une configuration spéciale pour traiter les caractères non ASCII. Si vos données contiennent des caractères non ASCII, vérifiez que la base et le logiciel de transfert traitent bien ces caractères.

5.4.5 Instructions de traitement et commentaires

Les instructions de traitement et les commentaires ne font pas partie des "données" d’un document XML et la plupart des logiciels de transfert de données (si ce n’est tous) ne peuvent pas les traiter. Ces instructions et commentaires peuvent intervenir pratiquement n’importe où dans un document XML et en conséquence ils sont mal adaptés aux correspondances basées sur des tables et aux correspondances basées sur un modèle objet relationnel. (Une solution clairement impraticable avec les bases relationnelles consisterait à ajouter des tables pour les instructions de traitement et les commentaires, d’ajouter des clés étrangères à ces tables pour toutes les autres tables, et de vérifier ces nouvelles tables lors de chaque traitement d’une de ces autres tables.) Ainsi, la plupart des logiciels de transfert de données les ignorent tout simplement. Si les instructions de traitement et les commentaires sont importants pour vous, vérifiez que votre logiciel les traite bien. Vous pourriez aussi envisager d’utiliser une base XML native.

5.4.6 Stocker le balisage

Ainsi que nous le mentionnions à la section 5.1.2, il est parfois utile de stocker des éléments possédant des contenus mixtes dans la base sans effectuer de plus ample analyse. Quand ceci est réalisé, le balisage est stocké avec des caractères de balisage. Un problème survient cependant quand on examine comment stocker des balises qui ne sont pas utilisées à des fins de balisage. Dans un document XML, celles-ci sont stockées en utilisant les entités lt, gt, amp, quot et apos. Ceci peut également être réalisé dans une base de données. Par exemple, la description suivante :

   <description>
     
<b>Un exemple confus:</b> &lt;foo/&gt;
  
</description>

peut être stockée dans la base de la manière suivante:

      <b>Un exemple confus:</b> &lt;foo/&gt;

Le problème avec ce genre de solution vient du fait que les langages de requête non XML comme SQL n’examinent pas les valeurs des colonnes selon leur utilisation comme balise et entité et les interprètent en conséquence. Ainsi, si vous souhaitez rechercher la chaîne de caractères "<foo/>" à l’aide de SQL, vous avez besoin de savoir que la recherche doit s’effectuer sur la chaîne "&lt;foo/&gt;".

D’un autre côté, si les références à des entités sont étendues, le logiciel de transfert de données ne peut pas distinguer entre une balise et l’utilisation d’une entité. Si, par exemple, la description ci-dessus est stockée dans la base comme il suit, le logiciel ne peut pas dire si <b>, </b> et <foo/> sont des balises ou du texte :

      <b>Un exemple confus:</b> <foo/>

La solution à long terme réside dans les bases de données compatibles XML dans lesquelles une véritable balise est traitée différemment des choses qui ressemblent seulement à des balises. Il subsistera néanmoins probablement des problèmes quand des applications non XML traiteront du XML.

5.5 La génération de schémas XML à partir de schémas relationnels et vice-versa

Une question habituelle se pose quand on transfère des données entre des documents XML et une base : comment générer des schémas XML à partir de schémas relationnels et vice-versa. Avant d’expliquer comment réaliser cela, il est intéressant de noter qu’il s’agit d’une opération intervenant lors de la conception. La raison en est que la plupart des applications orientées données, et virtuellement toutes les applications verticales, travaillent avec un corpus bien établi de schémas XML et de schémas de base de données. Elles ne nécessitent donc pas de générer des schémas lors de l’exécution. Par ailleurs, ainsi que nous le verrons plus loin, les procédures de génération des schémas sont loin d’être parfaites. Les applications qui nécessitent de stocker des documents XML disparates dans une base devraient probablement utiliser une base XML native au lieu de générer des schémas au moment de l’exécution.

La façon la plus simple pour générer des schémas relationnels à partir de schémas XML et vice-versa consiste simplement à coder "en dur" un chemin vers la correspondance basée sur un modèle objet relationnel, qui possède un certain nombre de caractéristiques optionnelles. Des procédures similaires existent pour les bases orientées objet. (Des exemples pas à pas de telles procédures sont données à la section 4 du document Mapping DTDs to Databases).

Pour générer un schéma relationnel à partir d’un schéma XML, il convient de :

1.      Créer une table et une colonne clé primaire pour tout type d’éléments complexes.

2.      Pour chaque type d’élément possédant un contenu mixte, créer une table séparée dans laquelle sont stockées les PCDATA ; cette table est liée à la table parente grâce à la clé primaire de celle-ci.

3.      Pour chaque attribut de ce type d’élément qui possède une valeur unique, et pour chaque élément fils simple présentant une seule occurrence, créer une colonne dans cette table. Si le schéma XML contient des informations concernant le type de données, affecter le type de données de la colonne au type qui lui correspond. Dans le cas contraire, affecter lui un type prédéterminé comme CLOB ou VARCHAR(255). Si le type de l’élément fils ou de l’attribut est optionnel, attribuer à la colonne la possibilité d’y affecter des valeurs nulles.

4.      Pour chaque attribut possédant plusieurs valeurs et pour chaque élément-fils simple présentant plusieurs occurrences, créer une table séparée pour stocker des valeurs ; cette table est liée à la table parente grâce à la clé primaire de celle-ci.

5.      Pour chaque élément fils complexe, lier la table du type d’élément parent à la table du type de l’élément fils à l’aide de la clé primaire de la table parent.

Pour générer un schéma XML à partir d’un schéma relationnel, il convient de :

1.      Créer un type d’élément par table.

2.      Pour chaque colonne de cette table qui ne soit pas une clé et pour la(les) colonne(s) correspondant à la clé primaire, ajouter un attribut au type d’élément ou ajouter un élément fils de type PCDATA seul à son modèle de contenu.

3.      Pour chaque table pour laquelle la clé primaire est exportée, ajouter un élément fils au modèle de contenu, puis traiter la table récursivement.

4.      Pour chaque clé étrangère, ajouter un élément fils au contenu du modèle et traiter récursivement la table de la clé étrangère.

Ces procédures présentent un certain nombre d’inconvénients. Plusieurs sont faciles à corriger manuellement, comme par exemple les conflits de noms et la spécification des types de données et des longueurs. (Les DTD ne contiennent pas d’information sur les types de données ; il est donc impossible de prévoir quels types de données devraient être utilisés dans la base. On notera que les types de données et les longueurs peuvent être déduits d’un document XML Schema.)

Un problème plus sérieux existe : le "modèle" de données utilisé par le document XML est souvent différent (et habituellement plus complexe) que le plus efficace des modèles de stockage de données dans une base. Considérons par exemple le fragment suivant de document XML :

   <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>

La procédure permettant de générer un schéma relationnel à partir d’un schéma XML conduirait à créer ici deux tables : une pour les clients et une pour les adresses. Dans la plupart des cas, pourtant, il serait plus intelligent de stocker l’adresse dans la table client et non dans une table séparée.

L’élément <Adresse> est un bon exemple d’élément wrapper [wrapper element]. Les éléments wrapper sont en général employés pour deux raisons. En premier lieu, ils contribuent à procurer une structure additionnelle qui rend le document plus facile à comprendre. Deuxièmement, ils sont couramment utilisés comme une sorte de typage de données. L’élément <Adresse> pourrait par exemple être passé à une routine qui convertirait toutes les adresses en objets de type Adresse indépendamment de l’endroit où les adresses apparaissent.

Bien que les éléments wrapper soient utiles en XML, ils sont en général à l’origine de complications sous la forme de structures complémentaires quand ils sont implémentés dans la base. Pour cette raison, ils sont donc habituellement supprimés des schémas XML avant la génération d’un schéma relationnel. Et puisqu’il est peu probable qu’un schéma XML puisse ou doive changer de manière permanente, il en résulte une mauvaise adéquation entre les documents réels et les documents attendus par le logiciel de transfert de données, car les éléments wrapper ne sont pas inclus dans la correspondance. Ceci peut être résolu en transformant les documents lors de l’exécution, à l’aide de XSLT par exemple : les éléments wrapper sont alors éliminés avant le transfert des données et insérés après le transfert depuis la base.

En dépit de ces inconvénients, les procédures décrites ci-dessus fournissent tout de même un bon point de départ pour la génération des schémas XML depuis un schéma relationnel (et vice-versa), tout particulièrement dans le cas des grands systèmes.

6.0 Stocker et retrouver des documents

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.

6.1 Stocker des documents sur le système de fichiers

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.

6.2 Stocker des documents 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 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.

6.3 Les bases de données XML natives

Si vous avez besoin de plus de fonctionnalités que celles offertes par l’un des systèmes simples décrits ci-dessus, vous devez prendre en considération les bases XML natives. Les bases de données XML natives sont des bases conçues spécialement pour stocker des documents XML. Comme toutes les autres bases, elles 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 autres bases, c’est qu’elles sont basées sur XML, et pas sur autre chose comme dans le cas des bases relationnelles.

Les bases de données XML natives sont plus franchement utiles pour le stockage des contenus orientés document, en raison du fait qu’elles préservent des choses 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. En outre, les bases XML natives supportent les langages de requête XML qui permettent de poser des questions 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 dans un langage tel que SQL.

Les bases de données XML natives sont également utiles pour stocker des documents dont le "format naturel" est XML (peu importe ce que contiennent ces documents). Supposons par exemple que des documents XML soient utilisés à des fins de messages dans un système de e-commerce. Bien que ces documents soient probablement orientés données, leur format naturel en tant que messages est bien XML. Ainsi, lorsqu’ils sont stockés dans une file d’attente de messages, il semble plus raisonnable d’utiliser une file d’attente construite sur une base XML native plutôt qu’à partir d’une base non XML. Les bases XML natives offrent des possibilités en matière de caractéristiques spécifiques au XML, comme les langages de requête XML, et la recherche de l’ensemble des messages y sera généralement plus rapide. Un système de cache Web est un autre exemple de ce genre où les bases XML sont intéressantes.

Il existe plusieurs autres utilisations des bases XML natives, comme le stockage des données semi-structurées, l’accroissement de la vitesse de recherche dans certaines situations, et le stockage de documents qui ne possèdent pas de DTDs ou tout autre type de schéma XML (les documents sans schémas). Les deux premières utilisations ont été décrites dans la section 5.3 intitulée Le stockage des données dans une base XML native. La dernière est une tâche que les bases non XML ne réalisent pas correctement. 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. Le transfert de données d’un document XML vers une base relationnelle ou une base orientée objet nécessite que l’on crée d’abord une correspondance et un schéma de base. L’absence de configuration préalable est un avantage pour des applications comme les moteurs de recherche sur le Web où aucun schéma ou ensemble de schémas XML ne s’applique à tous les documents en question.

6.3.1 Qu'est-ce qu'une base de données XML native ?

L’expression "base de données XML native" a initialement eu une grande importance dans la campagne marketing de Tamino, une base native proposée par la société Software AG. À cause probablement du grand succès de cette campagne, le terme est devenu courant parmi les compagnies qui développent des produits similaires. L’inconvénient de ce succès, c’est que ce terme marketing n’a jamais reçu de définition technique formelle.

L’une des définitions possibles, développée par les membres de la liste de diffusion XML:DB, est la suivante :

Une base de données XML native définit un modèle (logique) de document XML [modèle est ici opposé aux données du document], et stocke et retrouve les documents en fonction de ce modèle. Le modèle doit au minimum inclure les éléments, les attributs, les PCDATA et l’ordre interne du document. Quelques exemples de tels modèles sont : le modèle de données de XPath, le glossaire XML Infoset, et les modèles implicites de DOM et des événements de SAX 1.0.

Le document XML est l’unité fondamentale du stockage (logique) dans une base de données XML native, tout comme une ligne d’une table constitue l’unité fondamentale du stockage (logique) dans une base relationnelle.

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.

La première partie de cette définition est semblable à celles d’autres types de bases de données et se concentre sur le modèle utilisé par la base. Il est important de noter qu’une base XML native pourrait stocker plus d’informations qu’il n’y en a dans le modèle qu’elle utilise. Elle pourrait par exemple supporter les requêtes basées sur le modèle XPath mais stocker les documents comme des textes. Dans ce cas, des choses telles que les sections CDATA et l’utilisation des entités sont stockées dans la base mais ne sont pas inclues dans le modèle.

La seconde partie de la définition stipule que l’unité fondamentale du stockage dans une base de données XML native est le document XML. Bien qu’il semble possible qu’une base XML native puisse assigner ce rôle à des fragments de document, l’unité fondamentale est bien le document lui-même dans toutes (?) les bases XML natives actuelles.

(L’unité fondamentale du stockage est le niveau le plus bas du contexte dans lequel un lot quelconque de données puisse s’adapter ; c’est l’équivalent d’une ligne pour une base relationnelle. L’existence d’une telle unité de base n’exclut pas la possibilité de retrouver des unités de données plus fines comme des fragments de document ou des éléments individuels ; elle n’exclut pas non plus la possibilité de combiner des fragments d’un document avec des fragments d’un autre document. En termes relationnels, c’est l’équivalent du fait que l’existence des lignes n’exclut pas la possibilité de rechercher des valeurs individuelles dans une colonne et n’exclut pas non plus la possibilité de créer de nouvelles lignes à partir de lignes existantes.)

La troisième partie de la définition stipule que le format de stockage sous-jacent n’est pas important. C’est exact et analogue au fait que le format physique de stockage utilisé par une base relationnelle n’est pas lié au caractère relationnel de la base.

6.3.2 Les architectures des bases de données XML natives

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.

6.3.2.1 Les bases de données XML natives basées sur le texte

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.

6.3.2.2 Les bases de données XML natives basées sur un modèle

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 stockent le modèle dans une base relationnelle ou orientée objet. Stocker par exemple le DOM dans une base relationnelle pourrait conduire à des tables du genre Éléments, Attributs, PCDATA, Entités et RéférencesDesEntités. D’autres bases utilisent un format de stockage propriétaire adapté à leur modèle.

(Un exemple simple de base XML native basée sur un modèle et construite sur une base relationnelle a été décrit par Mark Birbeck sur la liste XML-L en Décembre 1998. Le système en question utilise cinq tables : définitions des attributs, association élément/attribut, définition du modèle de contenu, valeurs des attributs, et valeurs des éléments (PCDATA ou pointeurs sur d’autres éléments). Il utilise également un modèle incluant uniquement les éléments, les attributs, le texte et l’ordre interne du document. Examinez les articles intitulés "Record ends, Mixed content, and storing XML documents on relational database" et "storing XML documents on relational database".)

Les bases XML natives basées sur un modèle et construites sur d’autres bases possèdent vraisemblablement des performances similaires à ces bases sous-jacentes lors de la recherche des documents, et ce, pour la raison évidente qu’elles reposent sur ces systèmes pour retrouver les données. Cependant, la conception de la base -- tout particulièrement dans le cas des bases XML natives construites sur des bases relationnelles -- laisse place à des variations. Par exemple, à partir d’une base utilisant une stricte correspondance du DOM avec un modèle objet relationnel, il pourrait en résulter un système qui sollicite l’exécution d’instructions SELECT distinctes pour retrouver les enfants de chaque nœud. D’un autre côté, la plupart des bases de ce genre optimisent leurs modèles de stockage et leur logiciel de recherche. À titre d’exemple, Richard Edwards a décrit un système pour stocker le DOM dans une base de données relationnelle qui peut retrouver n’importe quel fragment de document (y compris le document en entier) à l’aide d’une seule instruction SELECT.

Lorsque l’on recherche les données dans l’ordre où elles sont stockées, les bases XML natives basées sur un modèle et qui utilisent un format de stockage propriétaire possèdent vraisemblablement des performances similaires aux bases XML natives basées sur le texte. Ceci est dû au fait que la plupart (?) de ces bases utilisent des pointeurs physiques entre les nœuds, ce qui devrait fournir des performances similaires à la recherche textuelle. (La vitesse dépend aussi du format de sortie. Les systèmes basées sur le texte sont manifestement plus rapides pour renvoyer des documents textuels, tandis que les systèmes basés sur un modèle sont indubitablement plus rapides pour renvoyer des arbres DOM, en supposant que leur modèle coïncide explicitement au DOM.)

À l’instar des bases XML natives basées sur le texte, les bases natives basées sur un modèle rencontrent probablement des problèmes de performance lorsque l’on recherche et retourne des données dans un format quelconque autre que celui sous lequel ces données sont stockées, par exemple lorsque l’on inverse la hiérarchie de certaines de ses parties. La question de savoir si ces bases seront plus rapides ou non que les systèmes basés sur le texte n’est pas claire non plus.

6.3.3 Les caractéristiques des bases de données XML natives

Cette section expose brièvement certaines caractéristiques des bases de données XML natives. Cela devrait aider le lecteur en lui donnant une idée des caractéristiques disponibles à l’heure actuelle et de celles que l’on attend dans le futur.

6.3.3.1 Les collections de documents

De nombreuses bases XML natives supportent la notion de collection. Ce concept joue un rôle similaire à la table dans une base de données relationnelle ou au répertoire dans un système de fichiers. Supposons par exemple que vous utilisiez une base XML native pour stocker des ordres de ventes. Dans ce cas, vous devriez définir une collection ordres de ventes de telle manière que les recherches sur des ordres de ventes soient limitées aux documents de cette collection.

Supposons maintenant que vous stockiez les manuels de tous les produits d’une société dans une base XML native. Vous devriez alors définir une hiérarchie de collections ; comme, par exemple, décrire une collection pour chaque produit, puis, à l’intérieur de cette collection, définir des collections pour chacun des chapitres de chaque manuel.

Selon la base envisagée, il est possible ou non d’imbriquer les collections.

6.3.3.2 Les langages de requête

Presque toutes les bases XML natives supportent un ou plusieurs langages de requête. Les plus populaires d’entre eux sont XPath (avec des extensions permettant des recherches sur des documents multiples) et XQL ; toutefois, plusieurs langages de requête propriétaires sont aussi supportés. Quand vous envisagez une base XML native, vous devriez probablement vérifier que le langage de requête supporte vos exigences, et celles-ci peuvent aller des recherches plein texte à la possibilité de réarranger des fragments pris dans plusieurs documents.

La plupart des bases XML natives supporteront probablement XQuery du W3C dans le futur.

6.3.3.3 Mises à jour et effacements

Les bases XML natives possèdent une grande variété de stratégies pour réaliser les mises à jour et les effacements de documents. Cela va d’un simple remplacement ou effacement du document existant jusqu’aux modifications effectuées à travers un arbre DOM actif ou aux langages qui spécifient comment modifier des fragments de document. En règle générale, chaque produit permettant de modifier des fragments de document possède son propre langage, bien qu’un certain nombre de produits supportent le langage XUpdate de groupe XML:DB Initiative. Néanmoins, les possibilités de mise à jour resteront vraisemblablement incomplètes dans un avenir proche, car il s’agit encore d’un domaine d’étude pour l’industrie et l’Université. [écrit en février 2002]

6.3.3.4 Transactions, verrouillages et accès concurrentiels

Pratiquement toutes les bases XML natives supportent les transactions (et vraisemblablement aussi les annulations de transactions [rollbacks]). Le verrouillage est cependant réalisé le plus souvent au niveau du document dans son intégralité plutôt qu’au niveau des fragments du document, et ainsi, les accès multi-utilisateur concurrents peuvent être relativement lents. La question de savoir si cela pose un problème dépend de l'application et de ce qui constitue un "document".

Si, par exemple, un guide d’utilisateur a été scindé en plusieurs chapitres individuels, chacun de ceux-ci constituant un document, alors les problèmes d’accès concurrents sont probablement réduits car il est peu probable que deux rédacteurs mettent à jour le même chapitre au même moment. Si, par contre, toutes les données clients d’une entreprise sont stockées dans un même document (ce qui serait très mal conçu), alors le verrouillage au niveau du document se révèlera très certainement désastreux.

La plupart des bases XML natives offriront probablement à l’avenir le verrouillage au niveau du fragment de document.

6.3.3.5 Les APIs [Application Programming Interfaces]

Presque toutes les bases XML natives proposent des APIs. Elles prennent habituellement la forme d’une interface semblable à ODBC, avec des méthodes permettant la connexion à la base, l’exploration des métadonnées, l’exécution des requêtes et la recherche des résultats. Ces résultats sont ordinairement renvoyés sous la forme d’une chaîne XML, d’un arbre DOM, ou bien encore d’un analyseur SAX ou XMLReader sur le document retourné. Si les recherches permettent de renvoyer plusieurs documents, alors des méthodes permettant de parcourir l’ensemble des résultats sont également disponibles.

Une caractéristique qui prend probablement tout son intérêt pour les applications orientées données (et qui est proposée dans une base XML native au moins) est la capacité de lier des variables d’application à des éléments ou des attributs dans les documents renvoyés. Cette aptitude évite à l’application d’analyser le document dans le but de construire des objets internes représentant les données ; elle est susceptible d'être supportée plus largement à mesure que l'utilisation des technologies de liaison des données XML s’amplifie.

Bien que presque toutes les bases XML natives offrent des APIs propriétaires, une API de base XML native indépendante par rapport aux fournisseurs a été développée par le groupe XML:DB.org. Plusieurs bases XML natives l’ont implémenté et elle peut d’ailleurs aussi avoir été implémentée dans une base non native. Si cette API ou une autre devient la norme de l'industrie, l'adoption éventuelle sur une large échelle d'une telle API semble alors inévitable.

La plupart des bases XML natives proposent également la possibilité d’exécuter des requêtes et de renvoyer des résultats en HTTP.

6.3.3.6 L’aller-retour des documents [Round-Tripping]

Une caractéristique importante des bases XML natives est qu’elles permettent l’aller-retour des documents [Round-Tripping]. Cela signifie que l’on peut stocker un document XML dans une base XML native et obtenir à nouveau le "même" document. Cette propriété est importante pour les applications orientées document pour lesquelles des choses comme les sections CDATA, l’utilisation des entités, les commentaires, et les instructions de traitement sont parties intégrantes du document. Elle est également cruciale pour de nombreuses applications légales et médicales qui doivent conserver légalement des copies exactes des documents.

(L’aller-retour des documents est moins important pour les applications orientées données qui s’occupent en général seulement des éléments, des attributs, du texte et de l’ordre hiérarchique interne. Tout logiciel qui transfère des données entre les documents XML et les bases peut effectuer ces aller-retour. Ce genre de logiciel peut également réaliser l’aller-retour de l’ordre des enfants d’un même parent (l’ordre des éléments et les PCDATAs inclus dans leur parent) dans un nombre limité de cas importants pour les applications orientées données. Cependant, comme il ne peut pas effectuer l’aller-retour de l’ordre des enfants d’un même parent dans le cas général, et ne peut pas non plus procéder à cet aller-retour pour les instructions de traitement, les commentaires, ainsi que les structures physiques (références des entités, sections CDATA, etc.), il ne convient pas pour les applications orientées document.)

Toutes les bases XML natives permettent l’aller-retour des documents au niveau des éléments, des attributs, des PCDATAs et de l’ordre interne du document. Les possibilités supplémentaires en matière d’aller-retour dépendent de la base considérée. En règle générale, les bases XML natives basées sur le texte effectuent l’aller-retour des documents XML de manière exacte, tandis que les bases XML natives basées sur un modèle réalisent l’aller-retour des documents XML au niveau de leur modèle de document. Dans le cas où les modèles de document sont particulièrement minimalistes, cela signifie que l’aller-retour s’effectue à un niveau inférieur au XML canonique.

Comme le niveau d’aller-retour dont vous avez besoin dépend entièrement de votre application, vous pouvez avoir le choix entre de nombreuses bases XML natives ou être restreint à un petit nombre.

6.3.3.7 Les données distantes

Quelques bases XML natives peuvent inclure des données distantes dans les documents stockés dans la base. Ce sont habituellement des données retrouvées à partir de bases relationnelles à l’aide d’ODBC, OLE DB ou JDBC, et qui sont élaborées en utilisant la correspondance basée sur une table ou la correspondance basée sur un modèle objet relationnel. La question de savoir si ces données sont actives -- c'est-à-dire, si des mises à jour du document dans la base XML native sont reflétées dans la base distante -- dépend de la base native. Par la suite, la plupart des bases XML natives supporteront probablement les données distantes actives.

6.3.3.8 Les index

Presque toutes les bases XML natives supportent l’indexation des valeurs des éléments et des attributs. Les index sont utilisés pour accélérer les recherches, comme pour les bases non XML.

6.3.3.9 Le stockage des entités externes

En ce qui concerne le stockage des documents XML, la question de la manipulation des entités externes reste difficile. Les entités externes doivent-elles être développées et leurs valeurs stockées avec le reste du document, ou les références aux entités doivent-elles être conservées telles quelles ? Il n’existe pas de réponse unique à cette question.

Supposons par exemple qu’un document contienne une entité générale externe qui appelle un programme CGI établissant le bulletin météo du jour. Si le document est utilisé en tant que page Web pour fournir des bulletins météos réguliers, ce serait une erreur de développer la référence à l’entité, car alors, la page Web ne renverrait plus de données actualisées. À l’inverse, si le document fait partie d’une collection de bulletins météos historiques, ce serait une erreur de ne pas développer la référence à l’entité en question, car le document renverrait toujours les données actuelles au lieu des données historiques.

Considérons maintenant le manuel d’un produit consistant simplement en des références à des entités externes pointant sur des chapitres du manuel. Si certains de ces chapitres étaient utilisés dans d’autres documents en tant que manuels pour différents modèles du même produit, ce serait une erreur de développer ces références parce qu’il en résulterait alors de multiples copies des mêmes chapitres.

Je ne suis pas certain de la manière dont les bases XML natives traitent ce problème. Elles devraient idéalement permettre de spécifier au cas par cas si les références à des entités externes sont développées.

6.3.4 Normalisation, intégrité référentielle et scalabilité

Pour de nombreuses personnes, et tout particulièrement pour celles qui disposent d’une culture en matière de bases de données relationnelles, les bases XML natives soulèvent un certain nombre de questions controversées, en particulier en ce qui concerne le stockage des données (par opposition aux documents). Nous discutons ces questions dans les sections suivantes.

6.3.4.1 La normalisation

La normalisation se réfère au processus de conception d’un schéma de base de données dans lequel un segment de données est représenté une seule fois. La normalisation présente plusieurs avantages évidents, comme la réduction de l’espace disque et l’élimination de la possibilité de données inconsistantes (ce qui peut intervenir quand un segment de données est stocké en plusieurs endroits). Il s’agit là de l’une des pierres angulaires de la technologie relationnelle et c’est un sujet brûlant dans les discussions concernant le stockage des données dans les bases XML natives.

Avant de poursuivre plus avant cette discussion, il est important de noter que la question de la normalisation n’est pas un problème pour de nombreux contenus orientés document. Considérons par exemple une collection de documents décrivant les produits d’une société. Dans une telle collection, il existe seulement un petit nombre de données communes à tous les documents -- le copyright, les adresses de la société et les numéros de téléphone, les logos des produits, etc. -- et ce nombre est si faible en comparaison de la totalité des données que presque personne ne considère qu’ils doivent être normalisés. (À l’inverse, d’autres ensembles de documentation possèdent une répétition significative de données entre les documents et méritent d’être normalisés.)

À l’instar des bases relationnelles, il n’existe rien dans les bases XML natives qui vous force à normaliser vos données. Autrement dit, vous pouvez concevoir un mauvais stockage de données avec une base XML native aussi facilement qu’avec une base relationnelle. Il est donc important d’examiner attentivement la structure de vos documents avant de les stocker dans une base XML native. (Les bases XML natives présentent toutefois un avantage sur les bases relationnelles. Comme elles ne possèdent pas de schémas de base de données, vous pouvez stocker en même temps dans la base des documents similaires qui se réfèrent à plus d’un schéma. Lorsque vous en êtes encore à concevoir les requêtes et à convertir les documents existants (ce qui peut être une tâche non triviale), cela peut faciliter le processus de transition.)

La normalisation des données pour une base XML native est largement similaire à la normalisation dans le cas d’une base relationnelle : vous avez besoin de concevoir vos documents de telle façon qu’aucune donnée ne soit répétée. L’une des différences entre les deux processus, c’est que XML supporte les propriétés multi-valuées alors que les bases relationnelles (pou la plupart) ne le supportent pas. Cela rend possible la "normalisation" de données dans une base XML native selon un procédé qui n’est pas possible avec une base relationnelle.

Considérons par exemple un ordre de ventes. Il consiste en informations d’en-tête, telles que le numéro d’ordre, la date, le numéro du client, et en une ou plusieurs lignes d’articles chacune contenant un numéro de lot, une quantité et le prix total. Dans une base relationnelle, les informations d’en-tête doivent être stockées dans une table séparée des lignes d’articles, puisqu’il existe plusieurs articles par en-tête. Dans une base XML native, cette information peut-être stockée dans un seul document sans redondance car la nature hiérarchique de XML autorise un élément parent à posséder plusieurs enfants.

La normalisation n’est malheureusement pas aussi simple dans le monde réel. Que se passe-t-il par exemple quand vous souhaitez que les ordres de vente contiennent des informations concernant le client, comme les noms des contacts ainsi que les adresses de livraison et de facturation ? Il existe alors deux choix. Vous pouvez en premier lieu dupliquer les informations concernant le client dans chacun des ordres de ventes de ce client, ce qui conduit à des informations redondantes avec tous les problèmes qui en découlent. Vous pouvez au contraire stocker les informations concernant le client séparément et fournir soit un XLink dans le document contenant l’ordre de ventes vers le document sur le client, soit joindre les deux documents quand les données sont demandées. Cela suppose que les XLink soient supportés (et dans la plupart des cas, ils ne le sont pas, bien que le support soit envisagé), ou bien que le langage de requête supporte les jointures (et là encore, ce n’est pas toujours le cas).

Il n’existe en pratique aucune réponse claire. Les données relationnelles réelles sont souvent non normalisées pour des raisons de performance, et en fait, disposer de données non normalisées peut ne pas être aussi épouvantable qu’il y paraît ; il s’agit là toutefois d’une décision que vous devrez prendre. Si vous stockez des contenus orientés document et que vous pouvez les normaliser à un degré raisonnable (en stockant par exemple des chapitres ou des procédures comme des documents séparés et en les joignant afin de créer des documents destinés à l’utilisateur final), alors une base XML native constitue probablement un bon choix pour vous, notamment parce qu’elle vous fournira des méthodes telles que des langages de requêtes qui n’existent pas dans les autres bases. Si vous stockez des contenus orientés données et qu’une base XML native améliore les performances de votre application ou vous procure des techniques de stockage de données semi-structurées que vous ne pouvez pas trouver dans d’autres bases, alors vous devez aussi utiliser ce genre de base. Mais si vous estimez que pour l’essentiel vous êtes en train de construire une base relationnelle à l’intérieur de votre base XML native, vous devriez vous demander pourquoi ne pas utiliser carrément une base relationnelle à la place.

6.3.4.2 L’intégrité référentielle

La question de l’intégrité référentielle est intiment liée à celle de la normalisation. L’intégrité référentielle se réfère à la validité des pointeurs vers des données liées et il s’agit là d’un aspect indispensable de la tâche consistant à maintenir l’état consistant d’une base. Il n’est pas bon en effet qu’un ordre de ventes contienne un numéro de client qui ne corresponde à aucun enregistrement client ; le service des livraisons ne sait pas où envoyer les articles achetés et le service de facturation ne sait pas où envoyer la facture.

Dans une base relationnelle, l’intégrité référentielle signifie que l’on s’assure que les clés étrangères pointent bien sur des clés primaires valides -- autrement dit, que l’on vérifie que la ligne de clé primaire correspondant à une clé étrangère existe bien. Dans une base XML native, l’intégrité référentielle signifie que l’on s’assure que les "pointeurs" dans un document XML pointent bien sur des documents ou des fragments de documents valides.

Les pointeurs apparaissent sous plusieurs formes dans un document XML : des attributs ID/IDREF, des champs key/keyref (tels qu’ils sont définis dans des XML Schemas), des XLinks, et différents mécanismes propriétaires. Ces derniers incluent des éléments et des attributs de "référencement" propres au langage, comme l’attribut ref de l’élément <element> dans les XML Schemas, ainsi que des mécanismes de liaison spécifiques à la base envisagée. Cependant, les éléments et attributs de "référencement" propres au langage sont très courants tandis que les mécanismes de liaison spécifiques à une base ne le sont guère.

L’intégrité référentielle dans les bases XML natives peut se décomposer en deux catégories : l’intégrité des pointeurs internes (les pointeurs vers le document lui-même) et l’intégrité des pointeurs externes (les pointeurs entre documents). L’intégrité référentielle des pointeurs internes qui utilisent des mécanismes non standards n’est jamais imposée puisque les bases XML natives ne possèdent pas de moyen d’identifier ces types de pointeurs. L’intégrité référentielle des pointeurs internes qui reposent sur des mécanismes standards tels que ID/IDREF ou key/keyref, sont, au moins partiellement, supportés à travers la technique de validation XML.

Le fait que ce support soit partiel s’explique parce que la plupart des bases XML natives effectuent une validation seulement lorsque le document est inséré dans la base. Ainsi, si les mises à jour sont effectuées au niveau du document -- c’est-à-dire en effaçant l’ancien document et en le remplaçant par le nouveau -- la validation est suffisante pour assurer l’intégrité des pointeurs internes. Mais si les mises à jours sont réalisées au niveau des nœuds -- c’est-à-dire en insérant, modifiant et effaçant des nœuds individuels --, alors la base a besoin d’accomplir un travail supplémentaire (valider tous les changements) pour garantir l’intégrité référentielle des pointeurs internes. Peu de bases XML natives réalisent cela (si tant est qu’il en existe).

Autant que je sache, l’intégrité référentielle des pointeurs externes n’est pas supportée, même par les quelques bases peu nombreuses qui supportent ces pointeurs externes. Si un pointeur externe pointe vers une ressource stockée n’importe où dans la base, il n’y a pas de raison de ne pas imposer l’intégrité du pointeur. Mais si le pointeur pointe vers une ressource située en dehors de la base, il est compréhensible que l’on n’ait plus cette exigence. Supposons par exemple qu’un document contienne un XLink pointant vers un document situé sur un site Web externe. La base ne possède évidemment aucun contrôle sur l’existence ultérieure du document et ne peut donc raisonnablement pas imposer l’intégrité de ce XLink.

À l’avenir, la plupart des bases XML natives supporteront probablement l’intégrité référentielle des pointeurs internes qui utilisent des mécanismes standards. De nombreuses bases XML natives supporteront vraisemblablement les pointeurs externes du même genre, de même que les pointeurs externes qui pointent vers des ressources stockées dans la base. Pour le moment, cependant, il est du ressort des applications d’exiger l’intégrité des pointeurs internes et externes dans la plupart des cas.

6.3.4.3 La scalabilité [Scalability]

La scalabilité est largement en dehors de mon domaine d’expertise, aussi, la plus grande partie de ce qui suit est spéculatif. Je conjecture d’une manière générale que les bases XML natives s’adapteront très bien au changement d’échelle dans certains environnements, et très mal dans d’autres environnements.

Comme dans le cas des bases hiérarchiques ou relationnelles, les bases XML natives utilisent des index afin de retrouver initialement des données. Cela signifie que la localisation des documents ou des fragments de documents dépend seulement de la taille de l’index, et non de la taille du document et du nombre de documents ; et donc, les bases XML natives peuvent identifier le début d’un document ou d’un fragment aussi rapidement que toutes les autres bases utilisant la même technologie d’indexation. De ce point de vue, les bases XML natives s’adaptent aux changements d’échelle aussi bien que les autres bases.

Comme les bases hiérarchiques mais à la différence des bases relationnelles, plusieurs bases XML natives lient physiquement les données qui sont en relation. En particulier, les bases XML natives basées sur le texte regroupent physiquement des données en relation, et les bases XML natives basées sur un modèle qui adoptent des systèmes de stockage propriétaires utilisent souvent des pointeurs physiques pour regrouper des données en relation. (les bases XML natives basées sur un modèle et qui sont construites sur des bases relationnelles, utilisent, comme les bases relationnelles sous-jacentes, des liens logiques.)

Pour naviguer dans une base, les liens physiques sont plus rapides que les liens logiques ; les bases XML natives comme les bases hiérarchiques peuvent ainsi retrouver des données plus rapidement que les bases relationnelles. Elles s’adaptent donc bien aux changements d’échelle au regard de la recherche des données. Et en fait, elles devraient même s’adapter mieux que les bases relationnelles de ce point de vue, car la scalabilité est alors liée à la consultation d’un seul index initial plutôt qu’aux multiples consultations exigées par une base relationnelle. (On se doit de noter que les bases relationnelles proposent aussi la possibilité de lier physiquement des données, sous la forme des clustered index. Cependant, de tels liens s’appliquent à des tables individuelles plutôt qu’à une hiérarchie entière.)

Cette scalabilité est malheureusement limitée. Comme pour les bases de données hiérarchiques, le câblage physique dans les bases XML natives s'applique seulement à une hiérarchie particulière. Autrement dit, la recherche de données à l’intérieur de la hiérarchie dans laquelle les données sont stockées est très rapide, tandis que la recherche des même données au sein d’une autre hiérarchie ne l’est pas. Supposons par exemple que les informations clients soient stockées à l’intérieur de chaque ordre de ventes. La recherche des ordres de ventes sera très rapide puisqu’elle suit l’ordre dans lequel les données sont stockées. Par contre, la recherche selon une vue différente comme la liste des ordres de ventes concernant un client donné sera bien plus lente, puisque les liens physiques ne s’appliquent plus.

Pour atténuer ce problème, les bases XML natives font grand usage des index et indexent souvent tous les éléments et tous les attributs. Mais si cette technique permet d’améliorer le temps de recherche, elle accroît le temps de mise à jour car la maintenance de ces index peut être coûteuse en temps. Cela ne présente pas de difficulté pour les environnements en lecture seule, mais pourrait poser des problèmes dans les environnements transactionnels lourds.

Les bases XML natives s’adaptent aux changements d’échelle de manière beaucoup plus médiocre que les bases relationnelles pour ce qui est de la recherche des données non indexées. Les deux types de bases de données doivent dans ce cas rechercher linéairement les données, mais la situation est bien pire pour les bases XML natives parce que la normalisation est alors moins achevée. Supposons par exemple que vous souhaitiez rechercher tous les ordres de vente d’une certaine date et que ces dates ne soient pas indexées. Dans une base relationnelle, cela signifie lire toutes les valeurs contenues dans une colonne intitulée DateOrdre. Dans une base XML native, cela veut dire lire tous les documents ordres de ventes intégralement et rechercher à l’intérieur les éléments <DateOrdre>. Non seulement le contenu de chacun des éléments <DateOrdre> est lu, mais tous les contenus de tous les autres éléments sont également lus. Pire encore, dans les bases XML natives basées sur le texte, les textes doivent être analysés et convertis en un format date avant d’être comparés à la date recherchée.

En conséquence, la scalabilité constituera-t-elle un problème pour vous ? Cela dépend vraiment de votre application. Si celle-ci utilise habituellement les données selon la vue où elles ont été stockées, une base XML native devrait bien s’adapter aux changements d’échelle. C’est le cas pour beaucoup de contenus orientés document. Les documents qui composent un manuel de produit seront par exemple presque toujours recherchés dans leur intégralité. Si au contraire votre application ne présente pas de vue préférentielle des données, alors la scalabilité peut poser problème.

Cette section termine notre description des bases de données XML natives. Dans les deux sections suivantes, nous examinerons deux types spécialisés de bases XML natives : les DOMs persistants et les systèmes de gestion de contenus.

6.4 Les DOMs persistants [PDOMs: Persistant Document Object Models]

Un DOM persistant ou PDOM est un type spécialisé de base XML native qui implémente le DOM à travers une sorte de stockage persistant. À la différence de la plupart des bases XML natives qui peuvent renvoyer des documents sous la forme d’arbres DOM, un arbre DOM retourné par un PDOM est un objet dynamique. Cela signifie que les changements effectués sur l’arbre DOM sont reproduits directement dans la base de données. (La façon dont les changements sont effectivement réalisés -- soit instantanément, soit comme résultat d’un appel à une méthode de type commit -- dépend de la base.) Dans la plupart des bases XML natives, l’arbre DOM renvoyé par l’application est une copie, et les changements sont effectués dans la base à travers un langage de mise à jour XML ou en remplaçant entièrement le document.

Puisque les arbres PDOMs sont dynamiques, la base est habituellement locale. Autrement dit, la base est dans le même espace de processus que l’application, ou tout au moins sur la même machine (bien que ce ne soit pas nécessairement requis) ; ceci, pour des raisons d’efficacité, car un PDOM sur une base à distance exigerait des appels fréquents au serveur distant.

Les PDOMs jouent le même rôle pour les applications DOM que les bases orientées objet pour les applications orientées objet ; ils fournissent un stockage persistant pour les données applicatives et servent également de mémoire virtuelle pour l’application. Ce dernier rôle est particulièrement important pour les applications DOM qui opèrent sur de vastes documents, car les arbres DOM peuvent être dix fois plus grands que les documents XML. (Le facteur véritable dépend de la taille moyenne du texte du document, en tenant compte du fait que les documents qui contiennent des tailles moyennes de texte présentent un facteur bien plus élevé.)

6.5 Les systèmes de gestion de contenus [CMS: Content Management Systems]

Les systèmes de gestion de contenus constituent un autre type spécialisé de base de données XML native. Ils sont conçus pour gérer des documents écrits par des humains, comme des manuels utilisateurs ou des livres blancs [white papers], et sont construits sur des bases XML natives. La base est en général cachée à l’utilisateur derrière un frontal [front end] qui fournit des services tels que :

·        le contrôle de version et d’accès

·        des moteurs de recherche

·        des éditeurs XML/SGML

·        des moteurs de publication (papier, CD ou Web)

·        la séparation du contenu et des styles

·        l’extensibilité à l’aide de scripts ou de programmes

·        l’intégration de données de la base

Le terme système de gestion de contenu, conçu comme opposé à système de gestion de documents, reflète le fait que de tels systèmes permettent en général d’éclater vos documents en fragments discrets de contenu, tels que des exemples, des procédures, des chapitres, des sidebars, aussi bien que des métadonnées comme les noms des auteurs, les dates de révision, et les numéros des documents, plutôt que de devoir gérer chaque document comme un tout. Cela permet non seulement de simplifier des tâches comme le travail coordonné de plusieurs rédacteurs sur un même document, mais aussi de permettre l’assemblage de documents entièrement nouveaux à partir de documents existants.

7.0 Les produits "bases de données XML"

Une liste à jour des bases de données que l’on peut utiliser avec XML est proposée dans la page XML Database Products.

8.0 Liens complémentaires

Pour une liste de liens vers différentes ressources sur XML et les bases de données, y compris des ressources logicielles et différents papiers, consultez la page XML / Database Links.

9.0 Commentaires et avis

Vous pouvez envoyer vos commentaires et avis à Ronald Bourret à l’adresse suivante : rpbourret@rpbourret.com. Veuillez noter que je voyage souvent et qu’il se peut que je ne réponde que dans deux ou trois semaines.

J’adresse mes remerciements à Malachi de Aelfweald, Michael Champion, Joern Clausen, John Cowan, Marc Cyrenne, Kelvin Ginn, Marc de Graauw, Ingo Macherius, Lars Martin, Nick Leaton, Evan Lenz, Morten Primdahl, Michael Rys, Walter Perry, Kimbro Staken, Jim Tivy, Phillipe Vauclair, Dylan Walsh, Irsan Widarto, ainsi qu’à d’autres interlocuteurs pour leurs commentaires et leur patience.


Retour à la page principale du site de Soft Experience  Boutique livres en anglais sur XML
Livres Management 
Vers la page d’accueil du site de Ron Bourret