Stockage des données semi-structurées Lapproche S.TO.RE.D (Semi-structured TO RElational Data)

Présentation au sujet: "Stockage des données semi-structurées Lapproche S.TO.RE.D (Semi-structured TO RElational Data)"— Transcription de la présentation:

1 Stockage des données semi-structurées Lapproche S.TO.RE.D (Semi-structured TO RElational Data)

2 PLAN DE LEXPOSE 1.Introduction Les données semi-structurées Ce qui existe déjà 2.Principes de STORED Son architecture Son apport à la communauté 3.STORED en détails Requêtes de stockage Requêtes surcharge Requêtes dextraction et de mise à jour 4.Performances 5.Conclusions

3 Introduction Les données semi-structurées Les données semi-structurées sont partout. Elles sont très importantes sur le Web. Le développement de XML accentue encore cet état de fait. Données structurées : –Les données contiennent intrinsèquement leurs propres significations et leur structure –Leur structure est importante et évolutive. –La structure est descriptive et non prescriptive : les violations sont autorisées. –Le typage des données nest pas stricte : des objets différents peuvent avoir un attribut de même nom mais de types différents. XML est un langage dexpression pour les données semi-structurées. Il est composé : –dobjets complexes (ensemble dobjets complexes et atomiques) –dobjets atomiques (chaîne, nombre, …) –dattributs

4 Un exemple XML Peter 4711 Fruitdale Ave. John 5361 Columbia Ave. swimming cycling David 4711 Fruitdale Ave. Mary 4711 Fruitdale Ave. painting

5 Introduction : Ce qui existe déjà … Outils de manipulation de données semi-structurées : –LOREL : Langage de requête pour données semi-structurées –TSIMMIS : Intégration des données de données non structurées et hétérogènes. –STRUDEL : Gestion de site web avec intégration de données –CARAVEL : Vu en groupe de recherche Problèmes constatés : 1.On ne peut pas utiliser de Systèmes Relationnels de base de données existant pour indexer ces documents XML 2.Ce sont des solutions flexibles et efficaces. Cependant, elles posent un problème de coût despace et de temps de réponse à cause des réplications des données indexées (doublons).

6 Principes de STORED : Son architecture STORED propose une autre approche. Il propose une technique pour : 1.stocker, interroger, manipuler des données semi-structurées en utilisant une SGBD Relationnelle 2.Permettre le stockage et la manipulation transparente de données XML. 3.Interroger les données stockées Les objectifs sont : 1.Maintenir des performances optimales 2.Lutilisation de Stored doit être sans perte dinformation 3.Lutilisation doit être la plus aisée possible 4.Minimiser loccupation disque 5.Minimiser la fragmentation de la base de données 6.Respecter les contraintes DBMS

7 Principes de STORED : Son apport à la communauté Les auteurs des STORED ont donc développé : 1.Un langage pour spécifier les « masques » de conversion XML SGBDR, effectuer des requêtes (extraction, recherche et M.A.J.) 2.Un générateur de modèle relationnel et de masques de conversion pour transférer des données XML vers une SGBDR. 3.Un générateur de schéma de surcharge permettant 4.Un algorithme de M.A.J. et dajout de données dans la base SGBDR Ce quil ne permet pas de faire : 1.Les « regular-path » expressions car cela implique la prise en compte de la possibilité de récursivité infinie. 2.Le langage est moins puissant que les autres car les auteurs ont fait des suppositions fortes.

8 STORED en détails : Requête de stockage (1) Création automatique de lensemble M des masques de conversion XML (informations + arcs) vers le modèle SGBDR à partir dun ensemble de données XML noté D. Recherche dune solution optimale avec les contraintes suivantes : K Nombre maximum de tables A Nombre maximum dattributs par table S Espace maximum pour créer la base de données C Nombre maximum doccurrences avant quun ensemble soit considéré comme grand Supp Paramètre spécifié par ladministrateur de base de données pour optimiser les performances des requêtes Minimisation dune fonction de coût f(M) = c(M) + d(M) c(M) coût en espace des données d(M)= f id (Q M i ) coût dexécution des requêtes prédéfinies Cest un problème NP-Complet. Les auteurs ont donc choisi une méthode heuristique. Génération des requêtes de stockage des données en langage STORED.

9 STORED en détails : Requête de stockage (2) M4a = FROM Audit.taxpayer : $X { name : $N, addr : $P, OPT{audited : $A}, OPT{taxamount : $T} } WHERE typeOf($P, "string") STORE Taxpr4a($X, $N, $P, $A, $T) M4b = FROM Audit.taxpayer : $X { name : $N, addr : { street $S, OPT{city $C, OPT{zip $Z}}} OPT{audited : $A}, OPT{taxamount : $T} } STORE Taxpr4b($X, $N, $S, $Ap, $C, $Z, $A, $T) Sur-définition possible. Les conditions ne sont pas exclusives. Une données peut correspondre à plusieurs requêtes. UNE SEULE sera choisie. OPT désigne les paramètres optionnels STORE désigne la table relationnelle dans laquelle les donnée seront stockées. Pour les attributs multiples, on a 2 cas : –Petits ensembles (cardinalité T < C) création de T attributs dans la table si possible (paramètre A) –Grands ensembles (cardinalité T C) création dune table relationnelle séparée. Exemple 1 : (nom, …, date mariage[0,2]) table (oid, nom, …, date_marriage1, date_marriage2) Exemple 2 : (nom, …,date visite médecin[*]) table1 (oid, nom, …) table2 (oid, date visite)

10 STORED en détails : Requête de stockage (3) Audit: &o1 { taxpayer: &o24 {name : &o41 "Gluschko", address : &o34 {street : &105 "Tyuratam", appartment : &o623 "2C" zip : &121 "07099"} audited : &o46 "10/12/63", taxamount : &o47 12332}, taxpayer : &o21 {name : &o132 "Kosberg", address : &o25 {street : &427 "Tyuratam", number : &928 206, zip : &121 "92443"} audited : &o46 "11/1/68", audited : &o46 "10/12/77", taxamount : &o283 0, taxevasion : &o632 "likely"} taxpayer : &o20 {name : &o132 "Korolev", address : &o253 "Baikonur, Russia", audited : &o46 "10/12/86", taxamount : &o283 0, taxevasion : &o632 "likely"} company : &o26 {name : &o623 "Rocket Propulsion Inc.", owner : &o24} } Taxpayer1 Taxpayer2 Company Oidnamestreetnoaptzipaudit1audit2taxamounttaxevasion o24 GluschkoTyuratam2C0709910/12/6312332 o21 KosbergTyuratam2069244311/1/6810/12/77 0 likely Oidnameadressaudittaxamounttaxevasion o20 KorolevBaykonur10/12/86 0 likely Oidnameowner o26 Rocket Propulsion Inc.o24

11 STORED en détails : Requête de surcharge (1) Permet après définition de lensemble M (requête de création) de compléter la base de données pour ne pas perdre dinformation. Ce sont, entre autre, des compléments ponctuels qui évitent les champs vides –Exemple ajouter les super gagnants du loto à une base de noms M vérifie les conditions initiale mais en général, ne couvre pas 100% des informations Stockage des arcs de liaisons non encore traités du graphe sous forme de relation ternaires dans des tables relationnelles. Pour les objets complexes, on fait des simplifications de structure. Car souvent, le objets sont « sur-définis » (on utilise * pour des cardinalités [0,2]). Exemple : on transforme les tuples XML (flattern / applanissement) (p|p) en p?, p? (p*)? en p* (p,p)* en p*, p* Noyau : ensemble des masques M. Surcharge

12 STORED en détails : Requête de surcharge (2) S1=Audit[1] : { taxpayer[0,*] : { name[1], address[1,2], taxreturn[0,*]: { year[1], amount[1], extension[0,1] } M = FROM Audit.taxpayer: $X { name[1]:$N, address[1]:$A, OPT taxreturn[1]: year[1]: $Y, amount[1]: $A, extension[1]: $E} STORE R($X, $N, $A, $Y, $A, $E) O1 = FROM Audit.taxpayer:$X { name:$N, address:$A, $L:_} WHERE $L = address OVERFLOW G1($L)

13 STORED en détails : Requête dextraction et de M.A.J. But : convertir des requêtes STORED vers des requêtes en SQL pur puis les exécutés. Recherche par élagage : –Détermination des tables relationnelles concernées –Les requêtes SQL sont générées puis optimisées –Exécution de la requête et génération du résultat Pour les « Mise A Jour », si la table perd trop en performance, une ré-organisation (similaire à une requête de création) est effectuée.

14 Performances : Le protocole de test Données utilisées pour les tests –Provenance :Web site DBLP –DBLP contient des articles, des livres, des thèses, … –La publication de nouvelles données est stochastique. –La structure des documents est irrégulière –Le site contient 92 000 publications pour un total de 95Mo –861 000 arcs / liens 2 tests ont été effectués : –Un en faisant varier le nombre maximum dattributs par table (paramètre A) –Un en faisant varier lespace disponible pour la base (paramètre S)

15 Performances Influence du paramètre A Rappel : A est le nombre maximum dattribut par table Les paramètres étudiés sont –Requêtes : le nombre de requêtes nécessaires pour extraire les données –Couverture : Pourcentage des liens couverts par la base générée –Espace : Taille estimée de la base –Champs nuls : Champs non remplis par des valeurs –Espace gaspillé : Pourcentage de lespace non efficace On se rend bien compte que lalgorithme est heuristique mais de manière générale : –Quand A est petit : Il faut beaucoup de relation pour extraire les données (jointures). On a une meilleure utilisation de lespace. La tendance sinverse lorsque A augmente. –Quelque soit la valeur de A, la couverture tourne toujours autour de 90%. A3456789 Requêtes9954433 Couverture %9194 909290 Espace (Mo)1,191.591,15110,91,2 Champs nuls (Ko)2311611212391106201 Espace gaspillé (%)1,97,29,712,39,111,716,75

16 Performances Influence du paramètre S Rappel : S est la taille maximum de la base Les paramètres étudiés sont –Couverture : Pourcentage des liens couvert par la base générée –Champs nuls : Champs non remplis par des valeurs –Espace gaspillé : Pourcentage de lespace non efficace de la base Les résultats sont : –Montre limportance de lespace disque (la contrainte est très forte et limitative) –Lorsque S est petit lalgorithme reste efficace (Espace gaspillé est très faible). –Sélection des informations les plus importantes. –Dans des environnements raisonnables : lalgorithme est efficace (90% couverture) S0,5 Mo0,78 Mo0.93 Mo1.0 Mo Couverture %597790 Champs nuls (Ko)2,540106 Espace gaspillé (%)0,55,1311,410,6

17 Conclusion STORED a le mérite de proposer un algorithme précis de conversion XML vers un schéma SGBDR. Prise en compte des limitations des SGBDR utilisés (nombre maximum dattributs par table, taille du disque). Pas besoin de DTD pour la conversion. Les algorithmes sont encore à optimiser. Les données XML sont quasi-régulière : seulement quelques éléments sont non réguliers (hors normes).

18 Bibliographie Lorel : Serge Abiteboul, Dallan Quass, Jason McHugh, Jennifer Widom, and Janet Wiener. The Lorel query language for semistructured data. International Journal on Digital Libraries, 1(1):68-88, April 1997. Strudel : Mary Fernandez, Daniela Florescu, Jaewoo Kang, Alon Levy, and Dan Suciu. Catching the boat with Strudel: Experiences with a web-site management system. In Proc. of ACM SIGMOD Conf. on Management of Data, Seattle, WA, 1998. Daniela Florescu, Donald Kossmann. A Performance Evaluation of Alternative Mapping Schemes for Storing XML Data in a Relational Database. Research report.