Stockage des donn

1
Stockage des donnéessemi-structurées

• Lapproche S.TO.RE.D
• (Semi-structured TO RElational Data)

2
PLAN DE LEXPOSE

• 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 dextraction 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 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

• ltpersongt ltid1, age55gt
• ltnamegtPeterlt/namegt
• ltaddressgt4711 Fruitdale Ave.lt/addressgt
• ltchildgt
• ltpersongt ltid3, age22gt
• ltnamegtJohnlt/namegt
• ltaddressgt5361 Columbia Ave.lt/addressgt
• lthobbygtswimminglt/hobbygt
• lthobbygtcyclinglt/hobbygt
• lt/persongt
• lt/childgt
• ltchildgt
• ltpersongt ltid4, age7gt
• ltnamegtDavidlt/namegt
• ltaddressgt4711 Fruitdale
  Ave.lt/addressgt
• lt/persongt
• lt/childgt
• lt/persongt
• ltpersongt ltid2, age38, child4gt

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
  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
• 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
• Lutilisation de Stored doit être sans perte
  dinformation
• Lutilisation doit être la plus aisée possible
• Minimiser loccupation 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 dajout de données
  dans la base SGBDR
• Ce quil 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 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)?fid(QMi)?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,
• OPTaudited A,
• OPTtaxamount T
• WHERE typeOf(P, "string")
• STORE Taxpr4a(X, N, P, A, T)
• M4b FROM Audit.taxpayer X
• name N,
• addr street S,
• OPTcity C, OPTzip Z
• OPTaudited A,
• OPTtaxamount 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 lt 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 mariage0,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",

Company
Oid name owner
o26 Rocket Propulsion Inc. o24
Taxpayer2
Oid name adress audit taxamount taxevasion
o20 Korolev Baykonur 10/12/86 0 likely
Taxpayer1
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
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)
• (pp) en p?, p?
• (p)? en p
• (p,p) en p, p

12
STORED en détails Requête de surcharge (2)

• S1Audit1
• taxpayer0,
• name1,
• address1,2,
• taxreturn0,
• year1,
• amount1,
• extension0,1
•  
•  

M FROM Audit.taxpayer X name1N,
address1A, OPT taxreturn1 year1 Y,
amount1 A, extension1 E STORE R(X, N,
A, Y, A, E)
O1 FROM Audit.taxpayerX nameN,
addressA, 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
PerformancesInfluence du paramètre A
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

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

16
PerformancesInfluence du paramètre S
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

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

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.