Cours bases de données

Support pour Apprendre à créer des Bases de données


Télécharger Support pour Apprendre à créer des Bases de données

★★★★★★★★★★3.5 étoiles sur 5 basé sur 1 votes.
Votez ce document:

Télécharger aussi :


Support pour Apprendre à créer des Bases de données

...

Les bases de données XML natives

Définition

Les bases de données XML natives (en anglais NXD pour « Native XML Database ») sont

des bases de données réalisées pour le stockage de données XML. On peut les caractériser par le fait qu'elles offrent à l'utilisateur une vision logique des données en accord avec le modèle XML (organisation hiérarchique des informations...), de la même façon que les bases de données relationnelles présentent une vision logique des données conforme au modèle relationnel (organisation des informations sous forme de tables). Cette vision logique conforme au modèle XML permet d'envisager aisément d'utiliser les standards définis autour de XML (XQuery, XPath, XSLT, XUpdate) pour accéder et traiter les données de la base.

L'initiative XML:DB

Il s'agit d'une initiative visant à fédérer les efforts déployés par des industries ou des organisations autour de la nouvelle technologie représentée par les bases de données XML. Plus concrètement, les buts de cette initiative sont  :

  • développer des spécifications techniques pour la manipulation des données au sein des bases de données XML ;
  • contribuer au développement d'implémentations de référence de ces spécifications sous une licence Open Source ;
  • former une communauté où utilisateurs et distributeurs de bases de données XML peuvent échanger ;
  • faire la publicité des produits et technologies bases de données XML sur le marché.

Dans ce but, cette initiative est à l'origine de plusieurs projets dont notamment :

  • la mise en place d'une interface de programmation ( XML:DB API ) standard d'accès aux bases de données XML indépendante de tout constructeur () ;
  • la définition d'un language de mise à jour de données XML ( XUpdate ), lui même véhiculé sous forme de données XML () ;
  • la définition d'un langage de définition et de modification de données ( SiXDML ) pour les base de données XML () à l'instar de SQL pour les bases de données relationnelles.

L'initiative XML:DB montre un certain ralentissement d'activité (les dernières mises à jour du site de l'initiative XML:DB datent de mai 2003 et les résultats des différents projets semblent arrêtés au stade du « Working Draft », dont le plus récent date de 2002 !), cependant, les projets XUpdate et XML:DB API semblent avoir rempli une part de l'objectif fédérateur en ce sens que de nombreuses bases XML implémentent ou essayent d'implémenter ces spécifications, même à un stade non abouti.

Aperçu des bases de données XML existantes

De nombreux produits commerciaux ou sous licence Open Source existent, dans un état de réalisation plus ou moins avancé (voire abandonné !). Un aperçu relativement exhaustif (autant que cela puisse être possible) est donné sur la page internet suivante :

Au niveau de cette étude, on signalera juste que les solutions proposées reposent sur des technologies variées : bases de données relationnelles ou orientées objet offrant des extensions permettant d'intégrer des données XML (« XML-enabled databases »), bases XML natives dont le stockage repose sur un modèle relationnel ou sur une implémentation propre.

Nous nous sommes concentrés ici, sur deux projets open source encore très actifs et ayant atteint un degré de réalisation permettant d'envisager une utilisation industrielle : Xindice et eXist (cf. Annexe A pour les tests effectués).

Solutions de stockage des fichiers XML

Les enjeux du stockage de données XML dans des SGBD-R et dans des bases de données XML natives sont abordés d'une manière théorique et approfondie dans un article de Ronald Bourret, consultable aux adresses suivantes :

Le Projet Diffusion des données en a réalisé une version PDF, disponible à l'adresse suivante :

Dans le contexte des besoins du Projet, on étudiera la pertinence des différentes solutions de stockage aux regard des fonctionnalités énoncées précédemment : stockage, consultation et échanges.

Stockage et mise en ligne

Schéma de données

Le stockage de données dans un SGBD relationnel nécessite la définition au préalable de la structure des données (tables et relations) qui vont y être insérées. Une fois définie, toute donnée non conforme à cette structure ne pourra y être insérée à moins de modifier cette dernière.

Les bases de données XML natives proposent une vision logique des données conforme au modèle XML. La seule contrainte concernant la structure des documents XML stockés dans la base est que ceux-ci soient « bien formés », à savoir qu'ils respectent bien la syntaxe XML. Certaines bases offrent, au travers du parser XML utilisé, la possibilité ou non de valider la syntaxe d'un fichier par rapport à un schéma donné (XSD, DTD...), mais la définition de ce schéma est indépendante de la base : on peut insérer n'importe quel type de document conforme à n'importe quel schéma sans avoir à modifier la base. L'organisation des données au sein d'une base XML native se fait au niveau des documents, que l'on peut regrouper au sein de collections, exactement de la même manière que l'on regroupe des fichiers dans des répertoires.

Cette souplesse de stockage est intéressante pour la manipulation de documents dont la structure n'est pas définie ou fluctuante, ce qui ne sera pas le cas des métadonnées que l'on souhaite stocker qui seront structurées selon un schéma fixe .

La différence entre les deux solutions pour ce type de donn ées structurées réside sur les transformations qui seront nécessaires pour l'intégration des données dans le SGBD Relationnel : un script de création de la structure des métadonnées sous forme de tables et une application de transformation des fichiers XML en script d'importation des informations dans la structure, contre une intégration directe du document dans une base de données XML.

Normalisation

La normalisation est une opération qui vise à définir un schéma de données qui minimise la taille des données stockées en supprimant la redondance. Il va de soi qu'une telle opération dépend surtout de la conception du schéma des données à héberger . La solution de stockage va permettre avec plus ou moins de souplesse de mettre en oeuvre un schéma optimisé :

  • il s'agit du concept même des bases de données relationnelles, qui permettent d'organiser les données en tables et relations ;
  • XML permet de définir des relations entre documents ou des références à des noeuds au travers des standards XLink (liens inter documents), XInclude (inclusion de fragments de documents) et XPointer (références à des fragments documents). Selon les bases, ces standards sont plus ou moins supportés. La base eXist offre une implémentation des liens au travers de XInclude et XPointer (cf. Annexe A - tests sur les métadonnées)

La normalisation induit des règles de cohérence entre les données liées (intégrité référentielle). Les bases de données relationnelles permettent généralement d'assurer cette cohérence, ce qui n'est pas forcément le cas pour les bases XML natives (dans eXist, la disparition de noeuds XML référencés à l'aide de XInclude par d'autres documents de la base se fait sans vérification particulière).



En ce qui concerne les métadonnées que le Projet souhaite stocker, on aura une normalisation à deux niveaux :

  1. une normalisation « implicite » du fait de l'organisation hiérarchique des métadonnées : les métadonnées de produit vont contenir des éléments communs à toutes les métadonnées sur les données appartenant à ce produit. Ici, les références se feront au travers des champs des métadonnées liant parent et enfants (éventuellement à l'aide d'XPointer), mais ces liens devront être restitués tels quels (en aucun cas ils ne seront instanciés). Ici, l'optimisation viendra d'une intelligente répartition de ces informations entre parents et enfants qui devra se faire au niveau de la création des métadonnées plutôt qu'au niveau du stockage ;
  2. certaines informations communes à toutes les données d'un produit devront quand même figurer dans les métadonnées sur les données du fait du caractère obligatoire des champs de la norme auxquels elles correspondent . Dans ce cas, on pourra envisager d'effectuer des regroupements d'informations au niveau du stockage, reposant sur des liens.

Il convient de noter que le volume des informations pouvant être redondantes dans le second cas reste assez négligeable comparé au volume total des métadonnées : la mise en oeuvre d'une gestion de liens ne représentera pas un gain extraordinaire vis à vis de la taille de la base.

Sécurité et administration

Il s'agit ici des fonctions de base permettant d'assurer la sécurité et l'intégrité des données contenues dans la base dans le cadre d'une utilisation comme serveur de données :

  • gestion des droits d'accès ;
  • gestion d'accès concurrents ;
  • gestion de transactions ; • gestions de sauvegardes.

Si dans leur ensemble, les SGBD transactionnels mettent en oeuvre ces fonctionnalités, les bases de données XML ne les offrent pas toutes :

  • eXist offre une gestion des droits d'accès aux documents identique à celle d'un système de fichiers UNIX, gère les accès concurrents par un système de verrouillage des ressources et propose un utilitaire de Backup/Restore de la base mais n'est pas transactionnel ;
  • Xindice ne propose aucun système d'authentification pour accéder à la base (accès libre) en déléguant cette responsabilité au serveur http qui diffuse la base ; il n'est pas non plus transactionnel et ne semble pas gérer les accès concurrents. Le système de sauvegarde de la base est sommaire : arrêt du serveur et copie des fichiers de données !

Capacité d'évolution (« Scalabilité »)

Il s'agit ici de la capacité du système de gestion à maintenir de bonnes performances sur de gros volumes de données.

L'étude technique sur la mise en place de la base de métadonnées  proposait un scénario dans lequel la base de métadonnées décrivant l'intégralité des données relatives aux produits tels que la BDDOrtho, la BDPays, les PVA et la BDParcellaire aurait une taille de 1Go. Les tests effectués sur la base eXist montrent que celle-ci réussit à « encaisser » un chargement de 45000 documents représentant un volume de données de l'ordre de 1,9Go tout en offrant des temps de réponse corrects à des requêtes simples (1 à 2 sec. sans index et 50ms avec index) . Des documents de gros volume (de l'ordre de 5Mo) ont pu être chargés au travers d'une interface réseau comme au travers d'un accès direct à la base. Les tests sur la base Xindice n'ont pas pu aboutir pour l'instant sur ce type de données).

Pour information eXist présente une limitation théorique du nombre de documents stockés dans la base de données à 2^31 (plus de 2 milliards de documents).

Consultation

Langages de requêtes

Les SGBD relationnels bénéficient d'un langage standard de manipulation de base de données : le SQL. Celui-ci est implémenté par tous les producteurs de SGBD-R dignes de ce nom (et surtout qui souhaitent pouvoir être exploités sur le marché). Le langage SQL offre tout un panel de commandes permettant d'effectuer les opérations nécessaires à la manipulation d'une base de données :

  • manipulation de données : insertion, suppression, interrogation ( DML : Data Manipulation Language )
  • définition de données : création, modification, suppression du schéma (DDL : Data Definition Language )
  • administration : attribution, révocation de droits d'accès (DCL : Data Control Language )

La syntaxe SQL est adaptée à des données conformes au modèle relationnel ; en aucun cas au modèle XML. Ce dernier s'accompagne de standards spécifiques permettant la manipulation des informations qu'il véhicule : XPath, XQuery, SiXDML ou XUpdate. Aucun de ces langages ne couvre l'ensemble des fonctionnalités du SQL. On peut les répartir ainsi selon la classification DML, DDL  et DCL :

...

Mis à part SiDXML, tous les autres langages ne couvrent qu'un domaine partiel des fonctionnalités d'un langage de manipulation de bases de données. L'accès aux bases XML natives se fait donc au travers de plusieurs langages, qui ne seront pas toujours standards :

  • l'administration des bases de données XML natives reste complètement propriétaire du produit utilisé  ;
  • à part XPath qui semble être implémenté par la plupart des bases de données XML, aucun langage ne semble s'être imposé comme LE langage de référence de manipulation de ces bases. A titre d'exemple : eXist utilise XPath, XQuery et XUpdate

Xindice utilise XPath, SiXDML et XUpdate

Si SiDXML semble être le plus à même de remplir le rôle d'un SQL pour les bases de données XML, celui-ci ne semble pas avoir été massivement adopté et semble même abandonné. XQuery, du fait de son origine W3C et de sa souplesse d'utilisation, permettant d'effectuer des requêtes d'une complexité comparable à celles effectuées à l'aide de SQL, devrait sans doute devenir un langage de requête de référence pour les bases de données XML.

Indexation

La définition d'index sur les données XML est nécessaire pour satisfaire les besoins énoncés pour l'interrogation des métadonnées dans des délais raisonnables face à une montée en charge de la base :

  • les requêtes sémantiques sur des mots-clefs nécessitent la définition d'index textuels sur certains champs des métadonnées. Les bases de données XML comme les SGBDRelationnels permettent de définir des index. Si cela peut se faire de manière standard pour les SGBDs avec des commandes SQL, la définition d'index pour des bases de données XML reste propriétaire de la solution utilisée  (on les définit à l'aide du fichier de configuration de la base pour eXist alors qu'on les définit en ligne de commande pour Xindice) ;
  • les requêtes géographiques (sélection par emprise...) nécessitent la définition d'index géographiques particuliers (de type rtree ou autre). Aucune base de données XML ne semble proposer de telle possibilité alors que les SGBDs relationnels proposent de plus en plus de telles extensions (Oracle, Informix, PostgreSQL, MySQL,...).

Mises à jour

Il s'agit ici de la mise à jour des données d'une base.

Les bases de données XML permettent de faire cela à deux niveaux :



  • au niveau du document, en supprimant l'ancien et insérant le nouveau ;
  • au niveau de la granularité du modèle XML (mise à jour de noeuds, d'attributs...) à l'aide du langage XUpdate ou SiXDML pour les bases qui les implémentent.

Présentation

Il s'agit de la mise en forme des données stockées dans la base.

Ici, les bases de données XML présentent tout leur intérêt : les résultats de requêtes sont directement des noeuds XML que l'on peut aisément transformer à l'aide de XSLT . Le mode de fonctionnement en mode application web adopté par les bases eXist et Xindice rend très aisé le branchement de ces bases sur des applications de publications telles que Cocoon , ou à d'autres applications web.

Echanges

« Round-tripping »

Il s'agit de « l'aller-retour » des documents, à savoir la conformité d'un document, inséré puis récupéré dans la base, au document original.

Dans ce domaine, les bases de données XML natives assurent en théorie de meilleurs résultats qu'un stockage des données dans des tables , puisqu'elles sauvegardent des éléments spécifiques au modèle XML  (commentaires, ordres des noeuds enfants au sein d'un même parent...). D'autre part, la restitution de l'information sous forme de document depuis une base XML native est immédiate alors qu'elle nécessite une étape d'interrogation (jointures entre tables) et de mise en forme des résultats depuis une base de données relationnelle.

Les fichiers de métadonnées qui seront stockés au travers de la base ne nécessiteront pas une conservation à l'identique mais seulement la conservation des informations véhiculées au travers des noeuds textes et des attributs ainsi que la validité de la structure par rapport au schéma de données, ce qui devrait pouvoir être assuré par les deux technologies.

Conclusion

Hormis l'indexation géographique qui n'est actuellement pas disponible ni à l'ordre du jour pour les bases de de données XML natives, ces dernières remplissent globalement les fonctionnalités que l'on attend pour un serveur de métadonnées.

Inconvénients des bases XML natives

Les bases de données XML dans leur ensemble souffrent d'un manque de standardisation (dû essentiellement à la jeunesse de cette technologie) et le choix, à l'heure actuelle, d'une telle solution impliquera l'utilisation de technologies propriétaires (notamment pour l'administration, la définition d'index et sans doute pour certaines requêtes) pour sa mise en oeuvre, ce qui rendra plus difficile une éventuelle migration vers une autre base de données XML.

On l'a vu aussi, si certaines bases de données XML peuvent permettre d'effectuer des liens inter-documents (comme eXist), elles n'assureront pas pour autant les règles d'intégrité référentielle. L'utilisation de tels liens pour optimiser le stockage au sein d'une base XML n'est donc pas conseillée à moins de mettre en oeuvre soi-même les mécanismes en assurant l'intégrité.

Avantages des bases XML natives

L'avantage de l'utilisation des bases de données XML réside dans le fait qu'elles manipulent directement le format XML, ce qui permet de mettre rapidement en oeuvre des services web d'accès à de telles bases :

  • le stockage des fichiers XML se fait directement (pas besoin de définir et d'écrire des règles de transformations XML<->relationnel) ;
  • de même la restitution des documents est immédiate alors qu'il faut le reconstituer à partir des tables d'une base de données relationnelle ;
  • la publication des résultats de requêtes au travers du web est très aisée à partir des base de données XML.

Mise en oeuvre de l'indexation géographique

La mise en oeuvre de l'indexation géographique avec une base XML native implique d'utiliser une solution tierce offrant de telles possibilités telle qu'un SGBD-R avec moteur géographique dans lequel les informations relatives à l'emprise géographique des métadonnées seront insérées et indexées avec une référence au document correspondant.

Indexation géographique

L'indexation géographique se ferait lors de l'intégration des documents XML selon le schéma de fonctionnement suivant : intégration du document dans la base XML native (1), récupération et mise en forme de l'information géographique (emprise) à l'aide de requêtes sémantiques sur le document XML (2) puis, indexation de cette information associée à la référence du document à l'aide du SGBD (3).

Requêtes géographiques

L'interrogation de la base de métadonnées selon des critères géographiques peut se dérouler ensuite selon le schéma suivant : récupération à l'aide de l'index géographique des références aux documents répondant aux critères de sélection (1), puis récupération de ces documents depuis la base XML native (2).

Glossaire

XML eXtensible Markup Language version 1.0 (troisième édition) - Recommandation W3C - 4 Février 2004

version 1.1 - Recommandation W3C - 4 Février 2004

 « Il s'agit d'un sous-ensemble de SGML  dont le but est de permettre au SGML générique d'être transmis, reçu et traité sur le Web de la même manière que l'est HTML aujourd'hui. XML a été conçu pour être facile à mettre en oeuvre et interopérable avec SGML et

HTML. »

DTD Document Type Definition

La notion de DTD fait partie de la définition de XML. Elle permet de définir la structure d'un document XML en en définissant les balises (type d'élément, liste d'attributs, entités ou notations).

XSD XML Schema Definition

Recommandations W3C - 2 Mai 2001

Il s'agit d'un langage permettant de décrire la structure et les contraintes sur le contenu de documents XML. Ce langage est lui-même exprimé à l'aide de XML. Ses possibilités sont beaucoup plus étendues que celles offertes par les DTD.

XSLT eXtensible Stylesheet Language Transformations version 1.0 Recommandations W3C - 16 Novembre 1999

Il s'agit d'un langage permettant de transformer des documents XML en d'autres documents XML. Il est exprimé à l'aide de XML.

XPath XML Path Language

version 1.0 - Recommandations W3C - 16 Novembre 1999

version 2.0 (définition commune avec XQuery 1.0) - Working Draft - 12 Novembre 2003

C'est un langage défini par le W3C permettant l'adressage d'informations au sein d'une arborescence XML. Cet adressage peut s'accompagner de prédicats permettant la sélection des informations en fonction de certains critères.

XQuery XML Query

version 1.0 - Working Draft - 12 Novembre 2003

C'est un langage de requêtes en cours de définition par le W3C offrant une syntaxe permettant d'extraire des informations depuis des documents XML au travers de critères complexes.

...

Tests sur des demandes de prestation

Il s'agit de fichiers de demandes de prestations effectuées au Serveur Général (novembre 2003 à février 2004). Tous conforme à une même DTD.

nombre : 665 taille moyenne : 8ko taille totale : 5,4 Mo



Intérêt : tests de base (chargement, requêtes sur des fichiers de taille moyenne).

L'évaluation des temps pour eXist est la suivante :

  • le temps de chargement des demandes de prestations comprend le temps de lancement et de fin du client (1 à 2 secondes) ;
  • les autres temps sont des temps de réponse du serveur (lus dans les logs !).

Pour Xindice, les temps de réponse du serveur n'étant pas disponibles, tous les temps présentés ici tiennent compte du temps de lancement et de fin du client (1 à 2 secondes) ; Chargement des fichiers dans la base

 eXist Xindice

Chargement des demandes de prestations

(5,4Mo répartis sur 665 fichiers)  1min 5s 3mn 52s

Récupération d'un document par sa clef (son nom) et sérialisation

fichier : dpsg2004-01-13-09-2527150-iso.xml

 eXist Xindice

récupération document  ~30ms  ~5000 ms

Requête XPATH (1)

Recherche des demandes de prestations effectuées un jour donné (14/11/2003). Affiche le contenu du noeud /Metadata/mdFileID des documents résultats.

/Metadata/mdDateSt[text()='14/11/2003']/../mdFileID[text()]

Elle est effectuée avec et sans l'index sur le noeud  //mdDateSt.

 Remarque   : pour eXist l'utilisation ou la non utilisation de l'index se fait en changeant l'opérateur utilisé dans le prédicat de sélection : sans index : [text()='14/11/2003'] avec index : [text()&='14/11/2003']

Pour Xindice, les résultats présentés sont (censés être) obtenus avec un index...

 eXist Xindice

requête XPATH (1)  380ms (8 résultats)  ~45000ms (8 résultats)

45 secondes

requête XPATH (1) avec index  ~20ms (0 résultats)  

  Avec eXist, la requête XPath (1) avec index ne retourne pas les mêmes résultats (aucun résultat) que sans index (8 résultats). Cela semble être dû au fait que la valeur recherchée est une date ayant la forme 'JJ/MM/AAAA' alors que l'index « full text » de eXist indexe les mots des valeurs textuelles. Le champ date ne semble pas avoir été indexé comme un mot complet. Le comportement de l'indexation (choix des mots et des césures) est paramétrable; mais ce paramétrage n'a pas été testé.

Requête XPATH (2)

Recherche des noeuds //resTitle contenant le texte « BDPays »

//resTitle[contains(text(),'BDPays')]

 Remarque   : pour eXist l'utilisation ou la non utilisation de l'index se fait en changeant l'opérateur utilisé dans le prédicat de sélection. Exemple, pour la requête XPATH (2), le prédicat s'écrit :

sans index : [contains(text(),'BDPays')] avec index : [starts-with(text(),'BDPays')]

Pour Xindice, les résultats présentés sont (censés être) obtenus avec un index...

 eXist Xindice

requête XPATH (2)  ~850ms (126 résultats) ~38000ms (126 résultats)

(38 secondes)

requête XPATH (2) avec

index  ~360ms (126 résultats)

Requête XPATH croisée

Recherche des demandes de prestations effectuées un jour donné (03/11/2003) sur un produit donné (Georoute). Affiche le contenu du noeud /Metadata/mdFileID des documents résultats.

/Metadata/mdDateSt[text()='03/11/2003']/../svIdInfo/operatesOn/idCitation/resTitle

[starts-with(text(),'Georoute')]/../../../../mdFileID[text()]

 eXist  Xindice

requête XPath croisée  ~360ms (5 résultats) ~63000ms(5 résultats)

1mn 3s

Requêtes XQuery

Affiche les noeuds /Metadata/mdFileID et /Metadata/svIdInfo/idAbs des documents dont le noeud /Metadata/mdDateSt a la valeur 14/11/2003

.

  let $collection := xmldb:collection($collURI, "gilles", "gilles1"),       $resources := coll:list-resources($collection)   for $doc in $resources

    where contains(document(concat("/db/test/dpsg/",$doc))/ Metadata/mdDateSt,"14/11/2003")   return         <resultat>

          {document(concat("/db/test/dpsg/",$doc))/Metadata/mdFileID}

          {document(concat("/db/test/dpsg/",$doc))/Metadata/svIdInfo/idAbs}

        </resultat>

 eXist  Xindice

requête XQuery  ~1800ms (3 résultats)  

Mise à jour au travers d'XUpdate

Insertion d'un commentaire avant le noeud //mdFileID :

<?xml version="1.0" encoding="ISO-8859-1"?> <xupdate:modifications version="1.0"     xmlns:xupdate="http://www.xmldb.org/xupdate">   <xupdate:insert-before select="//mdFileID">

      <xupdate:comment>identifiant des metadonnees...</xupdate:comment>

  </xupdate:insert-before>

</xupdate:modifications>

 eXist  Xindice

mise à jour XUpdate sur un document  ~400ms ~5000ms

5 secondes

...

Chargement dans la base

Le chargement des PVA dans eXist a été testé de deux manières :

  • au travers de l'interface XML-RPC sur un serveur eXist derrière un moteur de servlet dédié ;
  • en « local » (ou mode « embarqué ») : le client attaque directement la base dont une instance est lancée sur la même machine virtuelle que celle du client.

Les chargements des fichiers de PVA sur Xindice ont échoué pour les fichiers de gros volume, ce qui correspond à un comportement connu de Xindice.

Les tests des PVA avec cette base ont donc perdu tout leur intérêt...

L'évaluation des temps pour eXist est la suivante :

  • le temps de chargement des PVA comprend le temps de lancement et de fin du client (1 à 2 secondes) ;
  • les autres temps sont des temps de réponse du serveur (lus dans les logs !)



186