LEGOND AUBRY Fabrice 04/04/2001

Fiche de lecture
Titre du document : STORED : Semi-structured TO RElational Data
Type du document : Article
Auteurs : Alien Deutsch, Mary Fernandez, Dan Suciu
Cadre de la publication : ?
Date de la publication : 2000
Nombre de page de la publication : 12 pages

Plan du rapport

Introduction....................................................................................................................................................2
Larchitecture gnrale de STORED..............................................................................................................2
Gnration des filtres de conversions XML vers SQL..................................................................................3
CRATION DES TABLES NOYAUX .....................................................................................................4
Etape 1 : Dtermination de prfixes de chemin importants.......................................................4
Etape 2 Dterminations des liens entre chemins.....................................................................4
Etape 3 : Agrgations des prfixes de chemin............................................................................5
Etape 4 : Slection des attributs obligatoires.............................................................................5
Etape 5 : Gnration des requtes en langage STORED...........................................................5
Le rsultat...................................................................................................................................5
CRATIONS DES TABLES DE SURCHARGE..............................................................................................6
Etape 1 : Indexation des attributs..............................................................................................6
Etape 2 : Gnration des requtes de surcharge........................................................................6
Le rsultat...................................................................................................................................7
Requte de M.A.J. et dextraction.................................................................................................................7
Etape 1 : Construction des rgles dinversion...........................................................................7
Etapes 2-3 : Dcomposition en sous-requtes et optimisation algbrique.................................8
Etapes 4 : Construction et excution des sous-requtes.............................................................8
Les mises jour ( query updates )..........................................................................................8
Conclusion.....................................................................................................................................................8

Page 1 sur 9
LEGOND AUBRY Fabrice 04/04/2001

Introduction
Comme il a dj t dit, les donnes semi-structures sont partout. Depuis le dveloppement de
lXML, la prsence de ce type de donnes c'est encore accentu et dmocratis. Le XML est cependant un
langage complexe, verbeux et descriptif. Il n'est en aucun cas prescriptif. Cela lui offre une grande
puissance syntaxique, mais le rend souvent irrgulier (dans le sens o les donnes ne sont pas forces de
suivrent strictement le schma dfini) et donc difficile stocker et manipuler.
Le XML est souvent vu comme un graphe orient potentiellement cyclique. Diffrentes approches
ont t tudies pour traiter ces donnes. Elles ont donn lieu au dveloppement de diffrents
programmes comme Lorel, Tsimmis ou Strudel. Cependant, ils ont tous une architecture propritaire qui
leur donne certes de nombreux avantages en terme de performance et de flexibilit mais qui a une
contrepartie : Ces "approches" sont souvent coteuses en espace et elles n'utilisent pas les SGBDR
classiques - et ne peuvent donc pas tirer profit de lexprience que les programmeurs ont acquis dans ce
domaine.
Dans mon expos, je me suis surtout attach dcrire, de faon sommaire mais claire, les tapes et
procds mis en place par les auteurs pour aboutir la solution propose. Dans ce document, je
mattacherai plutt la partie algorithmique de la solution.

Larchitecture gnrale de STORED

Le principal but de STORED est donc de grer la transcription XML / SQL. Cette conversion doit
tre optimiser de manire minimiser lespace disque occup par la base relationnelle tout en conservant
la totalit des donnes.
Il a t dmontr que les donnes semi-structures peuvent tre stockes comme des relations
ternaires et unaire :
Les tuples ternaire [origine, attribut, destination] sont mis dans une table g.edges(x,l,y)

Les tuples unaires [oid des objets racines] sont mis dans une table g.roots(x).
STORED utilise un algorithme puissant pour gnrer les tables relationnelles partir des sources
XML proposs par lutilisateur. Cette conversion ce fait en deux phases bien distinctes : la premire
gnre le noyau des lments rguliers. Par rgulier, les auteurs signifient que llment suit les rgles
respectes par la majorit dentre eux. La seconde phase, elle, permet dajouter les lments exclus -hors
normes- lors de la premire phase, dans des tables spcifiques appeles tables de surcharges (overflow).
A la fin de la conversion, les algorithmes de conversions :
fourniront les filtres de conversion XML vers SQL
creront des tables relationnelles permettant de stocker les valeurs des attributs
creront des tables relationnelles permettant de stocks les liens (arcs) et par consquent la
structure des donnes.

Page 2 sur 9
LEGOND AUBRY Fabrice 04/04/2001

Tables
Tables des arcs principales

Source XML

Tables des objets Tables de

racines surcharges

En rsum, les contributions que se propose dapporter STORED sont :

1. Un langage dclaratif permettant de dcrire les diffrents types de requtes : cration des
tables principales, crations des tables de surcharges, extraction et manipulation de donnes
2. Un algorithme de gnration des tables noyaux
3. Un algorithme de gnration des tables de surcharges
4. Un algorithme pour les M.A.J. et les interrogations de donnes
Ceci reprsente donc une solution complte pour la gestion des donnes semi-structures avec des
outils de base de donnes existant, connu et stables. Les objectifs sont : de maintenir des performances
optimales, lutilisation de STORED doit tre sans perte dinformation, lutilisation doit tre la plus aise
possible, minimiser loccupation disque, minimiser la fragmentation de la base de donnes et surtout
respecter les contraintes imposes par le modle relationnel.
Cependant, ces objectifs limitent aussi les possibilits de la solution. Par exemple, STORED ne
permet pas dutiliser les regular-path (car cela implique la prise en compte de la possibilit de
rcursivit infinie difficile grer avec une SGBDR), le langage est moins puissant que les autres
(limitations sur les jointures)

Gnration des filtres de conversions XML vers SQL

La gnration des tables est base sur un problme doptimisation. On cherche minimiser une
fonction de cot o(M). M tant un noyau gnr partir dune source de donnes D. On a o(M) telle que
o( M ) c ( M ) d ( M )
avec
k
d ( M ) f i d (QiM )
i 1

c(M) est le cot en terme despace de la solution trouv et d(M) le cot de terme de temps
dexcution des requtes pr-dfinies (Qi) auxquelles on a attribu un poids de pondration (fi). On tient
compte ainsi au maximum des conditions initiales du systme et de son cadre dutilisation.

Page 3 sur 9
LEGOND AUBRY Fabrice 04/04/2001
Pour complter tout cela, les auteurs ont spcifi des paramtres de contraintes stricts sur le noyau :
i. K Le nombre maximum de tables
ii. A Le nombre maximum dattribut par table
iii. S La taille disque maximum
iv. C Paramtre de seuil pour diffrencier grands et petits ensembles
v. Supp Limite basse pour le nombre dobjets qui permet lalgorithme de
dterminer un chemin comme important ou non. Voir les paragraphes
suivants.
Comme ce problme est NP-complet, les auteurs ont prfr utiliser la thorie heuristique pour le
simplifier et lallger.

Cration des tables noyaux

Lalgorithme est le suivant :
On suppose une source D de donnes structures en XML.
Soit o1,o2, ,on lensemble des objets atteignable par le chemin de prfixe F.
On dfinit le support comme le nombre dobjets ok (dfini prcdemment) qui contiennent
linformation B.
La dtermination du meilleur cur se fait en cinq tapes.
Etape 1 : Dtermination de prfixes de chemin importants
Elle consiste relever tous les prfixes F tels que le support (avec B quelconque -*-) est suprieur
au paramtre Supp. Cette liste de prfixes intressants seront des objets racines. Chaque entre de cette
liste est dveloppe rcursivement en arbre -dont il est racine-. La condition darrt sera comme pour la
racine que le support du sous-arbre (sous-prfixe) soit infrieur Supp.
Ex : avec Supp = 2000
TaxPayer (Support=5000)
Taxpayer.sexe (4000)
Taxpayer.address (3000)
Taxpayer.address.zip (3000)
Taxpayer.address.gate_entry_code (20) arrt
Taxpayer.pet (200) arrt

Etape 2 Dterminations des liens entre chemins

Cest ltape du Data-Mining bas sur une modification dune solution propose par Wang et Li.
On utilise les donnes et les requtes dinterrogations prdfinies. On dfinit les liens entre les arbres et
entre les sous-arbres.
Etape 3 : Agrgations des prfixes de chemin
Dans cette tape, on cre les liens du noyau de manire minimiser les recouvrements et les arbres
doublons. En cas de conflit entre deux prfixes de chemin, on prend celui de plus grand support.

Page 4 sur 9
LEGOND AUBRY Fabrice 04/04/2001
Cette tape est arrter lorsque lon ne peut plus faire dagrgation.
Etape 4 : Slection des attributs obligatoires
Pour chaque arbre, on dtermine les attributs requis en fonction des paramtres K et A.On crer les
tables relationnelles la fin de cette tape.
Etape 5 : Gnration des requtes en langage STORED
On gnre alors les requte en langage STORED pour rpartir les donnes provenant dune XML
dans les diffrentes tables XML cres.
Le rsultat
En rsum, on a :
ALGORITHM: Automatic Storage Generation
INPUT: K, A, S, C, Supp, and query mix Q
OUTPUT: Set of relational STORED mappings
METHOD:
Step 1: Find all minimal prefixes with data support >= Supp
Step 2: - Run the WL data mining algorithm with the changes in the text.
- Let K' = number of maximally contained patterns found
Step 3: Select K0 (<= K) patterns out of the K'
Step 4: For each of the K0 patterns, select the set of ``required'' attributes
Step 5: For each of the K0 patterns with required attributes, generate one or more STORED relational queries.

Les sur-dfinitions sont possibles et mme courante car les conditions ne sont pas toujours
exclusives. Ainsi une donne peut parfois rpondre deux tables dans ce cas, il sera stock dans la table
choisie par lalgorithme.
Ex :
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)

Les requtes de stockage contiennent souvent des closes OPT qui dsignent des paramtres
optionnels (qui peuvent tre nuls). STORE dsigne la table relationnelle dans laquelle les donnes seront
stockes. Lorsquil existe des attributs multiples dans une source XML, on a 2 cas :
Petits ensembles (de cardinalit < C) : cration de T attributs dans la table si possible
(paramtre A)
Grands ensembles (de cardinalit C) : cration dune table relationnelle spare.

Page 5 sur 9
LEGOND AUBRY Fabrice 04/04/2001

Crations des tables de surcharge

Etape 1 : Indexation des attributs
On indexe tous les attributs. Pour chaque attribut, on utilise la fonction high(attribut) qui est le
nombre maximum doccurrences dans un tuple XML.
Ex :
S1 = Audit[1] :
{
taxpayer[0,*] :
{
address[1,2]

}
}

Si sur lensemble de la source XML, on trouve au maximum deux adresses par taxpayer ,
high(address)=2.
A partir de tous les attributs contenus dans la source D, on cre les arbres canoniques des attributs
(couvrant lensemble des possibilits de la source). Par exemple :

S1=Audit[1] :
{
taxpayer[0,*] :
{
name[1],
address[1,2],
taxreturn[0,*]:
{
year[1],
amount[1],
extension[0,1]
}
}
}

Etape 2 : Gnration des requtes de surcharge

On dtermine si le noyau est capable ou non de stocker les donnes produites par la source ( partir
des arbres canoniques). Si ce nest pas le cas, on gnre une requte de surcharge permettant de complter
le noyau pour y stocker les donnes hors-normes . Ce qui donne dans lexemple prcdent :
O1 = FROM Audit.taxpayer:$X
{ name:$N, address:$A, $L:_}
WHERE $L = address
OVERFLOW G1($L)
O2 = FROM Audit.taxpayer:$X
{ name:$N, address:$A, taxreturn:$T,
taxreturn: { year:$Y, amount:$A, $L:_ }}
WHERE $L = extension
OVERFLOW G2($L)

Page 6 sur 9
LEGOND AUBRY Fabrice 04/04/2001

Le rsultat
Encore une fois :
ALGORITHM Automatic Overflow Generation
INPUT Relational mapping M, schema S
OUTPUT Overflow mapping O
METHOD
Step 1: for each attribute a in S construct set of databases Da
Step 2: for each DDa compute M on D
if a is not STORED by M then generate overflow mapping

Requte de M.A.J. et dextraction

On suppose pour cette partie que la cration est termine. On peut alors modifier, interroger ou faire
des calculs sur les donnes. Les jointures ne sont possibles que dans la close WHERE.
Etape 1 : Construction des rgles dinversion
A partir des rgles de conversions XML / SQL, on engendre les rgles dinversion . Ces
fonctions sont masques lutilisateur. A partir des attributs passs dans la requte, le moteur dtermine
quelles tables SQL sont touches et, par consquent, utilises plus tard ltape 2.
On construit, ce moment, une base canonique en fusionnant tous les objets symboliques.
Chaque close CONSTRUCT fournit un arbre dans notre exemple cest S_audit dont les branches
(nodes) sont gnres par des fonctions de Skolem. Ces fonctions (S_name_1, S_addr_1, S_taxpayer,
S_taxamount_1, S_street_1, S_city_1) sont elles-mmes lies aux attributs.

Page 7 sur 9
LEGOND AUBRY Fabrice 04/04/2001
Rgles dfinies Rgles dinversions produites

Ma = FROM Audit.taxpayer: $X Ia0 = FROM Taxpayer($X, $FN, $LN, $S, $C, $T)
{ CONSTRUCT Audit : S_Audit()
name[1] : {firstname[1] : $FN, {
taxpayer: S_taxpayer($X)
lastname[1] : $LN},
{
addr[1] : {street[1] : $S, city[1] : $C}, name : S_name_1($X)
OPT{taxamount[1] : $T} {firstname : S_firstname_1($X), $FN,
} lastname : S_lastname_1($X) $LN},
STORE Taxpayer($X, $FN, $LN, $S, $C, $T) addr : S_addr_1($X)
{street : S_street_1($X) $S, city : S_city_1($X) $C}
Mb = FROM Audit.taxpayer: $X }
{ }
addr[1] : {street[1] : $S, city[1] : $C, $L : _}} Ia1 = FROM Taxpayer($X, $FN, $LN, $S, $C, $T)
OVERFLOW G1($L) WHERE $T != null
CONSTRUCT Audit : S_Audit()
Mc = FROM Audit.taxpayer: $X {
{ taxpayer: S_taxpayer($X)
name[1] : $N, { taxamount : S_taxamount_1($X) $T
OPT{taxamount[1] : $T}, }
$L : _
Ib = FROM G1.roots($X), G1.edges($X,$L,$Y)
} CONSTRUCT Audit : S_Audit()
OVERFLOW G2($L) {
taxpayer: S_taxpayer($X)
Q = SELECT $N {addr : S_addr_1($X) {$L : $Y}}
FROM Audit.taxpayer:$X }
{ name : $N, taxamount:$T, w4form.income:$I, address.*:$A}
WHERE $T < 0.1 * $I, $A = "Philadelphia" Ic = FROM G2.roots($X), G2.edges($X, $K, $Z)
WHERE $K != taxamount
CONSTRUCT Audit : S_Audit()
{
taxpayer: S_taxpayer($X) {$K : $Z}
}

Etapes 2-3 : Dcomposition en sous-requtes et optimisation algbrique

Dans cette tape, on compose lensemble des combinaisons possibles de nodes (des branches)
atteintes par la requte. Pour chaque tuple, on cherche, dans les rgles dinversion, la couverture minimale
permettant de rpondre la requte.
Etapes 4 : Construction et excution des sous-requtes
On gnre les requtes SQL standard qui seront alors excuter et on transmettra le rsultat
lutilisateur.
Les mises jour ( query updates )
On transforme la requte avec les tapes 1 3 prcdentes. On se retrouve alors avec un ensemble
(cest souvent un singleton) de sous-requte SQL qui peuvent, chacune, mettre jour la base de faon
cohrente. Pour viter les doublons, on nen excute quune seule. On choisit alors celle qui implique le
moins de modifications possible de la base de donnes.

Conclusion
Larticle manque singulirement de prcision sur les tapes de chaque type de requtes. Il reste trop
souvent gnraliste. Il faudrait, mon avis, un complment dinformation et quelques tests
supplmentaires pour valider lutilisation de cette solution pour des grosses applications.

Page 8 sur 9
LEGOND AUBRY Fabrice 04/04/2001
Laspect performance est un peu oubli. Les valuations de cot dans larticle sont un peu lgre et
parfois mais bizarre (on part dune source XML de 95Mo pour gnrer une base de 1Mo). Il faudrait
mettre la main sur un article plus complet pour obtenir des informations plus viables. Je nai donc pas
aborder ce points des ce petit rapport. Cependant, ce que je peux dire, cest que lexemple pris dans
larticle me semble plutt petit par rapport aux tailles des bases de donnes actuelles (souvent quelques
Go).
De plus, je ne crois pas personnellement que cette solution soit trs efficace en terme de vitesse
pure. En effet, elle oblige la cration, suppression, modification de nombreuses- tables et non de
tuples. En gnrale, les crateurs de moteurs de BD relationnelles optimisent la manipulation des tuples et
pas celle des tables qui sont senses tre effectues seulement au moment de la cration de la base.
Or STORED oblige de frquentes rorganisations des tables. Il mest impossible de savoir si cela
implique un surcot important ou non mais je pense quil doit ltre.

Page 9 sur 9