Stockage des données semi-structurées

1. Stockage des donnéessemi-structurées L’approche S.TO.RE.D (Semi-structured TO RElational Data)

2. PLAN DE L’EXPOSE • Introduction • Les données semi-structurées • Ce qui existe déjà • Principes de STORED • Son architecture • Son apport à la communauté • STORED en détails • Requêtes de stockage • Requêtes surcharge • Requêtes d’extraction et de mise à jour • Performances • Conclusions

3. IntroductionLes 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 n’est pas stricte : des objets différents peuvent avoir un attribut de même nom mais de types différents. XML est un langage d’expression pour les données semi-structurées. Il est composé : • d’objets complexes (ensemble d’objets complexes et atomiques) • d’objets atomiques (chaîne, nombre, …) • d’attributs

4. <person> <id=1, age=55> <name>Peter</name> <address>4711 Fruitdale Ave.</address> <child> <person> <id=3, age=22> <name>John</name> <address>5361 Columbia Ave.</address> <hobby>swimming</hobby> <hobby>cycling</hobby> </person> </child> <child> <person> <id=4, age=7> <name>David</name> <address>4711 Fruitdale Ave.</address> </person> </child> </person> <person> <id=2, age=38, child=4> <name>Mary</name> <address>4711 Fruitdale Ave.</address> <hobby>painting</hobby> </person> Un exemple XML

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 : • On ne peut pas utiliser de Systèmes Relationnels de base de données existant pour indexer ces documents XML • Ce sont des solutions flexibles et efficaces. Cependant, elles posent un problème de coût d’espace 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 : • stocker, interroger, manipuler des données semi-structurées en utilisant une SGBD Relationnelle • Permettre le stockage et la manipulation transparente de données XML. • Interroger les données stockées Les objectifs sont : • Maintenir des performances optimales • L’utilisation de Stored doit être sans perte d’information • L’utilisation doit être la plus aisée possible • Minimiser l’occupation disque • Minimiser la fragmentation de la base de données • Respecter les contraintes DBMS

7. Principes de STORED : Son apport à la communauté Les auteurs des STORED ont donc développé : • Un langage pour spécifier les  « masques » de conversion XMLSGBDR, effectuer des requêtes (extraction, recherche et M.A.J.) • Un générateur de modèle relationnel et de masques de conversion pour transférer des données XML vers une SGBDR. • Un générateur de schéma de surcharge permettant • Un algorithme de M.A.J. et d’ajout de données dans la base SGBDR Ce qu’il ne permet pas de faire : • Les « regular-path » expressions car cela implique la prise en compte de la possibilité de récursivité infinie. • 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 l’ensemble M des masques de conversion XML (informations + arcs) vers le modèle SGBDR à partir d’un ensemble de données XML noté D. • Recherche d’une solution optimale avec les contraintes suivantes : • K Nombre maximum de tables • A Nombre maximum d’attributs par table • S  Espace maximum pour créer la base de données • C Nombre maximum d’occurrences avant qu’un ensemble soit considéré comme grand • Supp Paramètre spécifié par l’administrateur de base de données pour optimiser les performances des requêtes • Minimisation d’une fonction de coût f(M) = c(M) + d(M) • c(M)coût en espace des données • d(M)=fid(QMi)coût d’exécution des requêtes prédéfinies • C’est 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. 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 d’une 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) STORED en détails : Requête de stockage (2)

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} } Company Taxpayer2 Taxpayer1

11. Surcharge Noyau : ensemble des masques M. Surcharge Surcharge STORED en détails : Requête de surcharge (1) • Permet après définition de l’ensemble M (requête de création) de compléter la base de données pour ne pas perdre d‘information. • 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’*

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 d’extraction 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 d’attributs par table (paramètre A) • Un en faisant varier l’espace disponible pour la base (paramètre S)

15. PerformancesInfluence du paramètre A Rappel : A est le nombre maximum d’attribut 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 l’espace non efficace On se rend bien compte que l’algorithme 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 l’espace. La tendance s’inverse lorsque A augmente. • Quelque soit la valeur de A, la couverture tourne toujours autour de 90%.

16. PerformancesInfluence 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 l’espace non efficace de la base Les résultats sont : • Montre l’importance de l’espace disque (la contrainte est très forte et limitative) • Lorsque S est petit l’algorithme reste efficace (Espace gaspillé est très faible). • Sélection des informations les plus importantes. • Dans des environnements raisonnables : l’algorithme est efficace (90% couverture)

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 d’attributs 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.