Stockage des donnéessemi-structurées

L’approche S.TO.RE.D

(Semi-structured TO RElational Data)

PLAN DE L’EXPOSE1. 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 d’extraction et de mise à jour

4. Performances

5. Conclusions

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

Un exemple XML<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>

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

Principes de STORED : Son architectureSTORED 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. L’utilisation de Stored doit être sans perte d’information

3. L’utilisation doit être la plus aisée possible

4. Minimiser l’occupation disque

5. Minimiser la fragmentation de la base de données

6. Respecter les contraintes DBMS

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

XMLSGBDR, 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 d’ajout de données dans la base SGBDR

Ce qu’il 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.

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.

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

Oid name street no apt zip audit1 audit2 taxamount taxevasion

o24 Gluschko Tyuratam 2C 07099 10/12/63 12332

o21 Kosberg Tyuratam 206 92443 11/1/68 10/12/77 0 likely

Oid name adress audit taxamount taxevasion

o20 Korolev Baykonur 10/12/86 0 likely

Oid name owner

o26 Rocket Propulsion Inc. o24

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

Noyau : ensemble des masques M.

Surcharge

Surcharge

Surcharge

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 = addressOVERFLOW G1($L)

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.

Performances : Le protocole de testDonné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)

PerformancesInfluence du paramètre A

Rappel : A est le nombre maximum d’attribut par tableLes 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%.

A 3 4 5 6 7 8 9

Requêtes 9 9 5 4 4 3 3

Couverture % 91 94 94 90 92 90 90

Espace (Mo) 1,19 1.59 1,15 1 1 0,9 1,2

Champs nuls (Ko) 23 116 112 123 91 106 201

Espace gaspillé (%) 1,9 7,2 9,7 12,3 9,1 11,7 16,75

PerformancesInfluence du paramètre S

Rappel : S est la taille maximum de la baseLes 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)

S 0,5 Mo 0,78 Mo 0.93 Mo 1.0 Mo

Couverture % 59 77 90 90

Champs nuls (Ko) 2,5 40 106 106

Espace gaspillé (%) 0,5 5,13 11,4 10,6

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

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.