Sommaire

Explication en globale

Explication par classification

Document et les données

Problème à poser

*La publication de documents XML qui comprennent des parties statiques et des parties dynamiques extraites d'une base de données au moment de la consultation du document par un utilisateur.le problè à résoudre est celui de l'extraction des données sous une forme que facilite la fusion avec la partie XML statique .

*La production et la publication de documents XML incorporant des donné extraites de plusieurs bases de donné hétégès. Le problèest identique au précédent mais ne peut ê résolu de facon ad hoc,spécifique au schéma d'une BD unique .

*L'utilisation de XML et XSLT pour donner une vision agréable et lisible &grave des données extraites d'un SGBD en réponse à une réquête.Le problème est purement celui du formatage et de ma mise en page de données .

*XML utilisé en tant que formalisme d'échange de données structurése entre deux application sans présence d'un utilisateur humain, hors cas de dysfonctionnement d'erreur.Le problème sera essentiellement celui de la préservation de l'information pertinente (par exemple les indications de types )lors de la sérialisation des données.Ce peut être aussi celui de l'efficacité lorsque les échanges sont synchrones ou en temps contraint.

*La gestion d'un grand nombre de composants d'infomation (documents XML , images,vidéos numériques,etc)dans un lenvironnement de production, qui nécessite d'indexer ces composants d'une facon ou d'une autre dans une base de données.

*La création d'un moteur de recherche pour un intranet, ou pourquoi pas , pour l'internet tout entier .

Dans tous ces cas de figure , le concepteur de l'application va être confrontéà quelques vrais problème:

-comment éviter d'avoir à programmer des méthodes spécifiques à chaque schéma relationnel et à chaque DTD

-comment éviter de réécrire du code de bas niveau au moindre changement de structure côté base de données ou côté XML?

-comment éviter de perdre de l'information lors de chaque transformation ?

-les transformations doivent-elles être réversibles?

-est-ce seulement possible?

-la solution envisagée permet-elle les changements d'échelle avec un coût de traitement croissant de facon linéaire ou exponentielle?

De facon plus pragmatique , le concepteur d'application XML pourra simplement être soucieux de ne pas perdre son temps à réinventer l'eau tiède , et surtout cherchera à se faire une opinion sur l'adéquation réelle de telle ou telle technologie <<sur étagère>> au problè qu'il doit résoudre.

Modèles relationnels et XML

pour tender d'y voir clair , il est nécessaire de s'abstraire un instant des caractéristiques des technologies, de ne pas s'obnubiler sur les langages de programmation, les APL ou les protocolis client-serveur, et de considérer de facon quelque peu avstraite les deux modèles que nous manipulons , et les provlèmes qui se posent pour passer de l'un à l'autre.il ne s'agit pas de faire de la théorie pour le plaisir mais d'identifier les vraies difficultés.

dans le modèle ralationnel, les données sont organisées en tables.chaque table est formée de colonnes qui correspondent à des attributs des entités décrites .chaque attribut est typé,les types utilisés se ramenant toujours aux types fondamentaux numériques(entiers,flottants etc) dates et chaines de caractères plus ou moins longues.une données peut être absente,ce qui n'est pas équivalent à une valeur nulle on peut définir sur une table une cléunique,qui est soit un attribut soit le produit cartésien de plusieurs attributs.une clé ne peut pas avoir plusieurs fois la même valeur .on peut relier deux tables en définissanat dans la première une clé unique et dans la seconde une clé étrangère qui peut être vue comme une référence à la clé unique de la premi`re table .enfin les colonnes (attributs) d'une table ne sont pas ordonnées

dans le modèle XML ,les données sont organisése sous d'arbres.au moins dans la version XML 1.0 exploitée dans nos applications actuelles (sans les schémas ), les données ne sont pas typées.on peut définir un attribut ID qui aura une valeur unique sur l'ensemble d'un document , et un qutre attribut,IDREF, qui sera une référence au premier.les éléments frè,fils d'un même élément , sont ordonnés.

Ces deux brefs paragraphes (sans doute superflus pour beaucoup de nos lecteurs), placés l'un derrière l'autre, rendent -nous l'espérons - immédiatement visible le fait que les deux modèles ne sont pas du tout équivalents .Tout le défi va consister à inventer des méthodes pour passer d'un modèle agrave un autre sans perdre trop d'information ,, c'est à-dire en ne perdant que l'information que l'ion accepte sciemment de perdre.

Document et données

En fait ,les bonnes méthodes et les bons outils diffèrent selon que XML est utilisé dans votre application pour représenter des données ou des documents .La nuance est importante. les releés d'observations météorologiques, utilisés comme schémas, sont des données sérialisées en XML:

La structure des relevés est répétitive.les données dans les relevés sont typées,mêsi la DTD laisse ce typage implicite et qu'il nous faille recourir aux schémas pour le rendre explicite.Surtout,l'ordre des éléments dans le document importe peu.sSi l'on modifie l'ordre des relevés obs,ou, à l'intérieur d'un relevé,l'ordre entre les données local,date,temps,etc.., la sémantique du document n'est pas modifiée.l'ordre des éléments ne véhicule aucune information perinente pour les applications qui vont traiter ces données dans une base de données en ne gardant pas l'information sur l'ordre respectif des éléments obs dans le flot XML d'origine, cela n'a aucune importance.

A l'inverse , un documentt XML qui <<représente>> un livre , un article scientifique ou un manuel technique , est bien un document.Les structures ne sont pas (ou seulement très; localement répétitives.les éléments contiennent des chaines de caractères ou des objets binaires (image) . Surtout, l'ordre entre les éléments est essentiel.Un auteur ou un lecteur n'apprécie pas beaucoup de trouver les chapitres ou , à l'intérieur d'un chapitre , les sections,dans un ordre aléatoire . Un logiciel qui va <<sauver>> un tel document dans un SGBD doit impérativement préserver l'ordre entre les éléments.

Bien entendu, la fronti&gravere est floue. Qui plus est , un document pourra localement contenir des îlots de données, au sens mentionné ci-dessus.il n'en reste pas moins que les méthodes de traitement de données structurées ne se prêtent pas , ou mal , à la gestion documentaire , et vice versa.

Dans la suite de ce chapitre , nous regardons successivement comment extraire des données d'un SGBD relationnel et les sérialiser en XML , comment stocker des données XML dans une base de données relationnelle , et enfin comment indexer des ressources XML dans un SGBD en vue de gérer la production ou la distribution de ces ressources.

1.1Extraction de données

Soit une base de données commerciale , qui contient de nombreuses tables relatives aux produits, fournisseurs , clients , commandes , etc. de l'entreprise , dont les deux tables PRODUITS et FOURNISSEURS sont structurées de la facon suivante(pour chaque table , nous donnons les attributs colonnes et leur type

Nous souhaitons extraire de cette base de données et représenter en XML une description de tous les produits dont le fournisseur est à Rouen, cad le résultat de la requête:

La mise en page finale sera réalisée bien évidemment avec XSLT.Nous nous concertrons ici sur la premiè étape du traitement: la génération d'un document XML qui soit une représentation sérialisée des données extraites par une requê telle que cell que nous venons de voir.

Trois méthodes peuvent être employées .Dans la première, la génération de la ressource XML est pilotée par un script ad hoc, spécifique à notre application, à la structure des données manipulées , et à la requête. Dans la deuxi&egrve;me, la génération se fait selon un modèle d'arbre XML défini en fonction du schéma relationnel ,valable pour toutes les requêtes formulables sur ce schéma. Il existe plusieurs outils qui implémentent l'une ou l'autre de ces méthodes . Certains sont purement des APL que l'on utilise dans le code de l'application. D'autres sont conçus pour être utilisés en servlet, voire en application indépendante pour la génération de fichiers XML

Extraction contrôlée par un modèle XML

Dans cette méthode, nous écrivons un modèle XML , qui va définir exactement la structure du document cible , les données extraites du SGBD étant insérées dans cette structure . Nous utiliserons pour illustrer cette approche la syntaxe supportée par ODBC2XML , qui nous parait typique de cette méthode , mais il existe d'autres outils plus ou moins semblables ,fondésur le même principe . La liste des outils est fournie en fin de ce chapitre.

Le modèle XML est un document XML bien formé dans lequel les requêtes SQL apparaissent dans des instructions de traitement . Les données recues de la connexion ODBC en réponse à ces requêtes sont utilisées pour générer les éléments qui suivent immédiatement l'instruction de traitement. soit par exemple:

La requête est incluse dans un élément liste dont elle va générer le contenu conformément à la structure donnée à cet élément par le modèle XML.La portée de la requê,te est très exactement égale àl'arbre défini par l'élément qui suit immédiatement l'instruction de traitement qui contient la requète.en l'occurrence , le processeur va générer autant d'instances de l'élément item qu'il y aura de tupples dans la réponse. La requète reçoit un nom , ici q1 , ce qui permet de la référencer plus loin dans le modèle , à l'intérieur de sa portée. Les instructions de traitement incluses dans le modèle permettent de distribuer les données reçues dans les différents éléments figurant dans la portée de la requète.

Le traitement de ce modèle par une application exploitant l'API ODBC2XML générera le document XML suivant:

Notre requête, proposée en exemple au début de la section 1.1 , fait une jointure entre deux tables , et le modèle est un tout petit peu plus compliqué à écrire . en effet , la requ&ecire;te ne peut pas apparaître dans une instruction de traitement unique, et doit être décomposée en deux requête liées ayant des portées difféentes:

La premièrequête,rq1,recherche les fournisseurs installés àRouen . Sa portée est l'élément fournisseur , dont elle va générer autant d'instances qu'il y aura de réponses. au passage, on voit dans la forme donnée à l'attribut id de l'élément fournisseur , la syntaxe un peu différente utilisée pour affecter des données provenant de la requête comme valeur à un attribut .

La seconde requˆte, rq2 , va générer autant d'élément produit qu'elle récupérera de réponses . On remarque dans l'expression de cette requête la syntaxe spéciale qui permet de faire référence à un attribut idf récupéré de la première requête.

La syntaxe présentee ici est évidement spécifique à l'outil utilisé ,ODBC2XML . d'autres outils proposent des syntaxes quelque peu diffécifier ainsi des modèle à instancier qui incluent des requête sql . on retiendra que, dans cette approche de la sérialisation XML de données extraites d'un SGBD relationnel, l'outil n'impose pas un modèle (une DTD) aux ressources XML généres . La souplesse est donc optimale , mais elle se paie par la nécessité de devoir écrire des modèle détaillés pour chaque requête.

on remarquera également que nous avons perdu de l'information au passage. Dans les documents instances génés, le typagedes données est devenu implicite . Les clés uniqus et étrangères ne sont plus identifiées . Cela n'est pas forcément gênant pour nos applications, mais cela implique que l'on ne peut pas mécaniquement recréer une base de données identique à partir des données ainsi sérialisées.

Extraction selon un modele XML

L'autre approche consiste a definir un modele generique (susceptible, nous le verrons, de quelques variations) sur lequel il soit possible de projeter des donnees relationnelles quelconques . On construit alors un outil generique qui prend en entree une requete sql, et produit en sortie une instance XML de ce modele generique.

un modele frequemment utilise par les outils qui suivent cette approche est le suivant:

En utilisant DB2XML (la encore, un outil typique de la categorie choisi parmi beaucoup d'autres), la requete figurant qu debut de la section 1 produit l'instance suivante:

l'outil genere un document valide , avec une DTD interne ou externe que nous n'avons pas montree ici. Pour obtenir un tel resultat , il suffit de fournir le nom d'une source JDBC et une requete SQL a l'outil utilise , il n'est pas necessaire d'ecrire une forme XML a instancier puisque le modele generique est <<grave>> dans le code de l'outil.Cette facilite d'empoi se paie par la necessite de faire sans doute un peu plus de poste-traitement avec XSLT pour parvenir a une version de document XML repondant parfaitement aux besoins de l'application .il est toutefois possible de controler le nom des elements generes .

1.1.3 Projection d'un schema relationnel sur un arbre XML

La troisieme methode possible pour serialiser en XML des donnees extraites d'une base de donnees relationelle se situe a mi-chemin entre la methode consistant a instancier un modele librement defini pour chaque requete , et la methode generant un document XML conforme a un modele generique . elle consiste a definir un modele d'arbre XML et des regles de projection entre cette structure XML et le schema relationnnel de la base .Un programme pour'ra des lors exploiter ces regles de projection pour generer des documents XML a partir des donnees de la vase .nous verrons du reste que le principe s'applique dans les deux sens :au prix de quelques contraintes , les memes regles de projection s'exploitent ausssi bien pour generer des documents XML a partir d'une base de donnees , ou pour ecrire des donnees extraites de decuments XML dans la base relationnelle.

Un outil au moins , XML-DBMS, implemente cette approche. il s'agit d'un ensemble de paquetages java que l'on peut utiliser pour developper sa propre application , ou a travers deux applications java existantes distribuees avec le logiciel.

le concepteur de l'application ecrit un fichier de correspondances (mapping ) qui specifie dans une syntaxe xml les regles de correspondance entre, d'une part les elements d'attributs d'un arbre XML, et d'autre part les tableet proprietes d'un schema relationnel. pour traiter notre petit exemple de releves meteo ,on pourra,par exemple , ecrire le fichier de correspondances suivant. ne vous fiez pas au nom de l'element racine, c'est bien le meme fichier de correspondances qui permet de fraire les transferts dans les deux directions, vers la vase de donnees ou vers l'arbre XML

Ces declarations commencent par un element option qui indique ici le format a utiliser pour representer les dates . Ce meme element peut egalement contenir des indications sur le domaine nominal des elements a generer , et sur la facon de representer les donnees nulles . l'element IgnoreRoot est indipensable pour generer un document XML bien forme qui doit avoir un element racine unique . il indique que les elements obs correspondant qux n-uplets(lignes) recuperes dans la table devront etre inseres dans un element pere meteo.

L'element ToRootTable declare quelle est la table de la base concernee par les correspondances qui suivent . Les elements PropertyMap decrivent ces correspondances entre colonne et element ou entre colonne et attribut XML.

Notre petit exemple , tres simple , ne traite qu'une table relationnelle unique . Il ne fait donc pas apparaitre la syntaxe utilisee pour traiter les relations entre tables , materialisees par des couples [cle unique - cle etrangere ]. Ces relations se traduisent au niveau de XML par des relations pere - fils entre elements . le langage de correspondance utilise par XML-DBMS donne d'autres possibilites non decrites ici , que vous pourrez decouvrir en lisant la documentation si vous decidez d'utiliser ce logiciel.

Etant donne un fichier de correspondances entre structures relationnelles et structures XML , le programme d'application peut creer un objet qui peut etre considere comme une forme compilee des declarations de correspondance. Ctte comilation prend comme parametres une connexion JDBC et un parseur SAX . enfin , cet objet peut etre passe a une classe de transfert de donnees DBMSToDOM , qui assurera la generation d'un arbre DOM peut enfin etre transforme en fichier XML . une autre classe de transfert DOMToDBMS permet d'ecrire des applications qui font la transformation inverse

1.2 Import de donnees

Nous traitons ici du stockage dans un SGBD des donnees contenues dans une ressource XML et non du stockage de la ressource XML elle meme . Comme nous l'avons dit en introduction , la nuance est importante : lors du stockage des donnees , nous acceptons de perdre les noms des elements XML (les noms des tables et colonnes dans la base de donnees peuvent etre differents des noms des elements et attributs XML) . Nous acceptons aussi de perdre l'ordre entre les elements lorsque cela n'entraine pas de changement de la structure .

Lorsque toutes les instances XML que l'on veut stocker dans une base de donnees sont conformes a une meme DTD , et que cette structure est plate comme dans notre exemple de releves meteo , le probleme peut se resoudre par un programme assez simple base sur une APL SAX . Il n'est en effet pas tres complique d'ecrire un DocumentHandler SAX qui va construire progressivement des chaines de caracteres du type:

   INSERT INTO OBSERVATIONS VALUES ('PY54476VZ32','Paris-Montsouris','2005-4-25T15:31:.5',12.3,88,8,3,6)

en recuperant les contenus des elements et les valeurs des attributs , puis d'affecter cette chaine comme valeur a une variable string, et la passer comme argument a une methode cursor.execute(string) qui inscrira ces donnees dans la base prealablement connectee . L'ecriture de ce programmme peut se reveler un peu moins triviale que ce que notre exemple «meteo» laisse penser, si l'on souhaite traiter ainsi des elements avec des structures hierarchiques relativement profondes , les relations de descendance entre elements devant se traduire par des relations cle unique-cle etrangere entre des tables. Ajoutez a cela que certains elements peuvent contenir des donnees non-XML(binaires , par exemple) a stocker comme des BLOB , et l'on peut se voir confronte a l'ecriture d'un programme qui n'est plus un exercice d'ecole.

Le probleme devient sensiblement plus complexe lorsque l'on veut stocker dans une meme base de donnees des donnees XML contenues dans des decuments aux DTD diverses. On peut en effet vouloir traiter des donnees qui ont la meme semantique - et doivent donc etre ecrites dans les memes tables et colonnes d'une base de donnees - mais qui sont importees en XML ans des elements aux noms variables : temprature dans un ensemble de documents sera tempt dans un autre et WaterTemperature dans un troisieme, tout en decrivant bien toujours la temperature de l'eau de mer mesuree 30 cm sous la surface .Plus souvent encore , les structures seront differentes , que ce soit par l'organisation hierarchique des donnees ou par l'utilisation differente des elements et des atrributs . enfin il peut y avoir des differences syntaxiques dans le contenu meme des elements : dates exprimees selon le format ISO dans un cas et dans un format «a l'americaine» dans un autre, grandeurs physiques exprimees dans des unites differentes etc

Pour importer de telles donnees dans une base de donnees , il faut donc d'une part definir une projection de la structure des donnees XML sur la structure de la base, et eventuellement programmer pour chaque type d'element ou d'attribut quelques transformations syntaxiques a appliquer systematiquement pour «normaliser» les donnees avant de les ecrire dans les tables de la base.

Bien sur , il est possible de programmer cette projection et ces transformations syntaxiques dans un langage de haut niveau dote d'une API SAX . toutefois , il sera necessaire de modifier le programme chaque fois que l'on voudra traiter des donnees XML s'ecartant du modele prevu dans le programme. Il semble nettement preferable d'utiliser un outil qui exploite un langage declaratif de mapping , tel que XML-DBMS , deja presente plus haut . En effet , rien ne s'oppose a definir plusieurs fichiers de regles de correspondances , concus pour importer les donnees conformes aux diverses DT utilisees toujours dans le meme schema relationnel . L'application pourra simplement regarder le doctype de chaque source de donnees XML , ou a defaut le nom de l'element racine , pour choisir automatiquement le fichier de correspondance adequat . On peut ainsi automatiser assez facilement l'ecriture de donnees XML ayant des DTD differentes mais une semantique coherente dans une base de donnnees relationnelle unique .

1.3 Conclusion sur les echanges de donnees SGBD-XML

De nombreux outils permettent de transformer des donnees structurees depuis leur representation XML. vers leur representation dans le modele relationnel , et vice versa . Pour precieux qu'ils soient , ils ne peuvent rien au fait que le modele d'arbre de donnees XML, s'il n'est pas augmente par la specification d'un schema XML, ne vehicule pas des donnees typees . il y a donc perte d'information lorsque l'on passe d'une representation typee (programmes ou base de donnees ) a une representation XML, et cette transformation n'est pas automatiquement reversible .

Inversement , lorsque l'on ecrit dans une base de donnees des donnees XML, on est oblige de suppleer a l'absence de typage explicite . Ce typage est de fait introduit par le programme k'import qui va devoir de toutes facons decider si un contenu d'element est une chaine de caracteres , une date,etc.La encore , on ne pourra ecrire de programmes d'import totalement generiques que lorsque les donnees XML seront vehiculees avec leur schema

Pour l'instant , il n'existe aucun outil qui exploite les schemas XML pour permettre ces changements de modele sans perte d'infomation.La proposition du protocole SOAP montre toutefois que les choses evoluent rapidement .

1 Data versus documents

lorsque nous choisissons la base de donnees , il est plus important que on va stocker les donnees ou les documents , par exemple , on utilise xml comme un utile de transiton entre la base de donnees et programme applique , ou en tant de agregation comme xhtml et docbook , parce que tous les document "document-centric" ont beaucoup de memes caracteristiques et tous les document "data-centric" ont memes caracteristiques , cela influance comment stocker dans la base de donnees

1.1 Data-Centric Document

Data-Cebtruc Document est que on transmet les donnees a l'aide de xml , c'est a dire que xml est comme un utile , il n'est pas necessaire , autrement dit , a propro de programme applique ou base de donnees il est pas tres important de stocker les donnees par document xml , tels que horaire de la ligne aerienne , donnees de scientifique ,bourge d'action

avantage: unite de donnees est le niveau de PCDATA element ou attibut , quasiement il n'existe pas de contenu melange

les documents de Data-Centric Document peuvent venir de lui-meme tel que les base de donnees relationnells , et venir de exterieur .

voici un exemple

   <SalesOrder SONumber="12345">
      <Customer CustNumber="543">
         <CustName>ABC Industries</CustName>

         <Street>123 Main St.</Street>
         <City>Chicago</City>
         <State>IL</State>
         <PostCode>60609</PostCode>

      </Customer>
      <OrderDate>981215</OrderDate>
      <Item ItemNumber="1">
         <Part PartNumber="123">
            <Description>

               <p><b>Turkey wrench:</b><br />
               Stainless steel, one-piece construction,
               lifetime guarantee.</p>
            </Description>
            <Price>9.95</Price>

         </Part>
         <Quantity>10</Quantity>
      </Item>
      <Item ItemNumber="2">
         <Part PartNumber="456">

            <Description>
               <p><b>Stuffing separator:<b><br />
               Aluminum, one-year guarantee.</p>
            </Description>

            <Price>13.27</Price>
         </Part>
         <Quantity>5</Quantity>
      </Item>
   </SalesOrder>

sauf l'exemple ci-dessus qui est data-centric document nombreur de prose-rich est aussi data-centric amazon.com

Exemple de un document de description des infos airline

   <FlightInfo>
      <Airline>ABC Airways</Airline> provides <Count>three</Count>

      non-stop flights daily from <Origin>Dallas</Origin> to
      <Destination>Fort Worth</Destination>. Departure times are
      <Departure>09:15</Departure>, <Departure>11:15</Departure>,
      and <Departure>13:15</Departure>. Arrival times are minutes later.
   </FlightInfo>

Creer un docment depuis xml et un simple formulaire :

   <Flights>
      <Airline>ABC Airways</Airline>
      <Origin>Dallas</Origin>

      <Destination>Fort Worth</Destination>
      <Flight>
         <Departure>09:15</Departure>
         <Arrival>09:16</Arrival>

      </Flight>
      <Flight>
         <Departure>11:15</Departure>
         <Arrival>11:16</Arrival>
      </Flight>

      <Flight>
         <Departure>13:15</Departure>
         <Arrival>13:16</Arrival>
      </Flight>
   </Flights>

1.2 Data-Centric Document

Data-Centric Document est souvent sur le domaine de "consommation" tels que livres , publicite ,email

la caractristique : la structure n'est pas tres reguliere nombreur de contenues melanges

le document est manuscrit ou est transfere de PDF,SGML a XML, en un mot la resource n'est pas la base de donnees

voici un exemple

   <Product>

   <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>
   <List>
   <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>
   </List>
   
      <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>
   
   </Product>

1.3 Data, Document,and Databases

Dans la vie il est diffecile de distinguer entre data-centric document et Docment-centric documents mais d'eclaircir deux cas peux nous aider de selectinner le type de la base de donnees,

normalement pour data-centric docments , la relation tels que modele ralatinnel ,modele oriente , les donnees sont stockees , on peut realiser par l'intermediat ou support interieur de la base de donnees

pour document-centric documents , les donnees peuvent etre stockes la base de donnees xml(native) (designe pour xml) ou systeme de gestion de contenu (etabli et gerant processus document de gestion )

bien entendu ,la bordure entre la base de donnees de "traduction" et la base de donnees de xml native est de plus en plus ambigue, on renforce la fonctionalite de xml native sur "tradition" ,et puis on renforce aussi le support de la base de donnees exterieur de stockage de documents sur la base de donnees de xml native.pour xml native , on va discuter apres

Storing and Retrieving Data

Pour pouvoir echanger les donnees entre xml et database ,il faut projecter schema (dtd xml schema relax ) a schema de dadabase , on utilise le logiciel qui s'appelle langage xml query tel que Xpath,Xquery ) ou simplement avec (select * from table )

pour utilisation de select ,la structure de document doit s'adapter a celle demandee , normalement , il est tres diffecile , donc on a aussi besoin de founir XSLT.Soit avant que les donnes soient transfere , il faut transformer la structure demandee, apres les donnees sont extraites , le document obtenu s'adapte a la structure etant necessite par programme applique

2.1Mapping document schemas to database schemas

2.1.1 Table-Based Mapping

   <database>
      <table>
      <row>
           <column1>...</column1>
            <column2>...</column2>

            ...
         </row>
         <row>
            ...
         </row>
         ...
      </table>
      <table>

         ...
      </table>
      ...
   </database>

avantage: on peut stocker par les elements et les attributs

2.1.2 Object-Relational Mapping

tous les databases de modele relationnel peuvent utiliser cette maniere de projection ,data de xml est comme un modele de l'arbre oriente , dans lequel les elements , leur types, contenu sont comme classe sauf PCDATA , attribut qui sont comme attribut simple , et puis on projette ce modele a dadabase ralationnel par vue objet de sql

exemple

4 classes composent un arbre SalesOrder,Customer, Item,et Part

                    SalesOrder
                   /    |    \
             Customer   Item   Item
                         |      |
                        Part   Part

dans le dom (document objet modele) l'arbre oriente est compose par l'element ,l'attribut,et document :

                     element   attribut
                    (SalesOrder) (SONumber)
               ____/   /   \   \_____
              /       /     \        \
      element      doc        element    element
     (Customer) (OrderDate)  (Item)    (Item)
          |                    |         |
         etc.                 etc.      etc.

ici pour logiel qui supporte ce modele , je vous explique pendans la soutenance

2.2Query Languages

2.1.1 Template-Based Query

Exemple dessous est de inserer directement template il est traite par le logiel

<?xml version="1.0"?>
   <FlightInfo>
      <Introduction>The following flights have available seats:</Introduction>
      <SelectStmt>SELECT Airline, FltNumber, Depart, Arrive FROM Flights</SelectStmt>

         <Flight>
            <Airline>$Airline</Airline>
            <FltNumber>$FltNumber</FltNumber>
            <Depart>$Depart</Depart>

            <Arrive>$Arrive</Arrive>
         </Flight>
      <Conclusion>We hope one of these meets your needs</Conclusion>
   </FlightInfo>

Apres le traitement

<?xml version="1.0"?>
   <FlightInfo>
      <Introduction>The following flights have available seats:</Introduction>
      <Flights>

         <Flight>
            <Airline>ACME</Airline>
            <FltNumber>123</FltNumber>
            <Depart>Dec 12, 1998 13:43</Depart>

            <Arrive>Dec 13, 1998 01:21</Arrive>
         </Flight>
         ...
      </Flights>
      <Conclusion>We hope one of these meets your needs.</Conclusion>

   </FlightInfo>

Avantage : l'utilisation de template est habile bien que des logiels soient differents , ils sont memes proprietes :

1. pouvoir retourner n'import quel endroit de document importe , y compris les parametres de "select"

2. pouvoir utiliser "for" et "if" .

3. pouvoir definir les variables et fonctions .

4. pouvoir realiser la parametralisation des "select" avec les parametres de http .

de database relationnel a doc xml , quasiement on a besoin de ce langage .

2.1.2 SQL-Based Query Languages

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

quand SONNumber=123 le document de xml est :

<Order SONumber="123">
	<Date>10/29/02</Date>

	<Customer>Gallagher Industries</Customer>
</Order>

2.1.3 XML Query Languages

- Le langage XPath

Tout d'abord, toute expression de chemin Xpath est une requête valide appelée requête XPath dont la définition est la suivante :

Requête XPath
Expression de chemin XPath interprétée comme une requête appliqué à un document ou à une collection de documents dont le résultat est l?ensemble des sous-arbres sélectionnés dans chaque document.

Ainsi, si l'on souhaite obtenir des noms des restaurants du guide normand :

Document("http://www.guidenormand.fr")//Restaurant/Nom/text()

où le symbole // permet de faciliter une recherche sur une structure imprécise et exprime des chemins indéterminés et text() permet de retourner tous les noeuds enfant du noeud courant contenant pour type le type texte.

Si on reprend notre exemple précédent (guide), on peut faire la requête suivante :
Lister les noms des restaurants de la collection de documents Guide
collection("Guide")//Restaurant/Nom/text()

Cette requête retournera en format texte la réponse suivante :
Le Passage Brady
Le Lhassa
Le Grand Hôtel
L'Absinthe

De même, collection("Guide")//Menu
Nous retournera tous les menus présents dans la base de données sous la même forme de balises.

Cependant, XQuery ne s'arrête pas aux fonctions XPath, il introduit également les expressions FLWR qui sont appliqués sur des forêts d?arbres XML.

2.3 Data Types,Null Values,Character Sets, and All That Stuff

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

2.3.1. Types de données

On n'a pas réellement de notion de type de données en XML. 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. Il y a deux méthodes de conversion.
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.

2.3.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+/] ),
- 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]
- 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.

2.3.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.
En XML, si la valeur d'un type d'élément ou d'un attribut optionnel est nulle, 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 égale à zéro et les éléments vides ne sont pas nuls: leur valeur est une chaîne de longueur zéro.

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

2.3.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.
Ainsi, la plupart des logiciels de transfert de données les ignorent tout simplement.

2.3.6. Stocker le balisage

Un problème survient 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> <foo/> </description>

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

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

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 on souhaite rechercher la chaîne de caractères "<foo/>" à l?aide de SQL, on a besoin de savoir que la recherche doit s?effectuer sur la chaîne "<foo/>".
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.

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

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.

Pour générer un schéma relationnel à partir d'un schéma XML, il faut:
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 faut:
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.

Conclusion

En résumé, les règles de distinction entre données et documents ne sont pas absolues. D'une part, les données (surtout semi-structurées) peuvent être stockées dans des bases XML natives et les documents peuvent être stockées dans des bases traditionnelles.D'autre part, 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 bases relationnelles).
Les bases de données XML se développent selon deux directions:middleware permettent de manipuler des documents XML en bases relationnelles ou objet relationnelles et base native XML. L'étude des différentes architectures de SGBD XML et les solutions Hybrides entre le pur middleware et le pur SGBD natif XML, aboutit,à un langage de requêtes pour interroger les collections de documents XML. Bien sur,XQuery du W3C est bien parti pour devenir le standard (puissant,langage complexe) mais ce dernier doit être complété pour les mises à jour(XUpdate).
Ceci nous ramène à traiter les différentes stratégies et problèmes liés au stockage et à la recherche de données et de document. Parmi les applications technologiques, la plupart s'appuient sur des bases de données capables de stocker et de produire des documents XML.
Ainsi,le mariage de XML et des bases de données va rapidement devenir la clé du succès et de l'ouverture pour les systèmes d'information de l'entreprise.