Vers une représentation formelle des schémas

Vers une représentation formelle
des schémas semi-structurés
Amar ZERDAZI1, Myriam LAMOLLE1, Ludovic MENET1, 2
1
LINC – Université Paris VIII
140, rue de la Nouvelle France 93000 - Montreuil, France
{a.zerdazi, m.lamolle, l.menet}@iut.univ-paris8.fr
2
Orchestranetworks
75, Boulevard Haussman 75008 - Paris, France
[email protected]
Abstract. Les données semi-structurées sont devenues de plus en plus
importantes avec la naissance du langage XML et l’évolution des technologies
associées. Ainsi, le passage des DTDs vers XML-Schema a-t-il permis une
amélioration dans la représentation structurelle de ces données par une meilleure
définition des types de données, de leurs cardinalités, de leurs réutilisations, etc.
Cependant, dans le cas des sources de données hétérogènes, les schémas XML
seuls, n’offrent pas assez de sémantique pour pouvoir intégrer automatiquement
ces sources hétérogènes. Dans cet article, nous proposons un modèle de données
sémantiques pour les données semi-structurées appelé CRP (Concept-RelationPropriété). Ce modèle a pour but principal de pouvoir unifier des représentations
issues de modélisations telles que, OEM, DTD, XSD, DSD, etc. CRP ne reflète
pas seulement la structure arborescente des données semi-structurées, mais il fait
la distinction entre concepts, relations et propriétés. Il est également possible de
spécifier par exemple le degré et la catégorie des relations et indiquer si une
propriété appartient à une relation ou à un concept. De telles informations sont
manquantes dans les modèles semi-structurés existants, et qui sont essentielles
pour la non-redondance, l’optimisation, le stockage des données semistructurées.
Keywords : données semi-structurées, intégration de données, schémas XML.
1 Introduction
Souvent les données du Web sont des données semi-structurées caractérisées par des
structures irrégulières, dynamiques ou inconnues. L’intérêt des données semistructurées dont le standard dominant est le format XML [15] provient de la facilité à
permettre l’échange et l’intégration des données entre applications. Cette nouvelle
représentation des données a conduit à définir des modèles et des systèmes plus
adaptés. Ainsi malgré la structure intrinsèque d’un document XML, une structure
commune plus générale peut être toutefois associée à un ensemble de documents. Cette
structure énoncée par des DTDs [3] (Document Type Definition) est remplacée
progressivement par des XSDs (XML-Schema Definition) [16] qui visent à pallier la
pauvreté sémantique de ces premières. Notamment, XML-Schema permet d’assurer
l’intégrité des données (typage de données, cardinalité, etc.), de réutiliser des structures
de données (héritage, surcharge, etc.) et donc d’assurer la qualité des données
échangées. Cette évolution diminue le fossé entre des représentations relationnelles,
des représentations « objets » avec des représentations semi-structurées. Cependant, les
modèles de données existants [4], [5], [9] ne permettent pas la définition d’un modèle
commun pour les schémas des bases de données traditionnelles et les schémas de
données semi-structurées. Or, il est indispensable de permettre l’échange et la
coopération entre des données provenant de sources classiques (hiérarchiques,
relationnelles, objets) et des sources semi-structurées (data guide, OEM, etc.). Les
techniques de médiation ont dû être adaptées pour prendre en compte ces nouveaux
types de données.
Dans cet article, nous proposons un modèle de données que nous appelons CRP
(Concept-Relation-Propriété) qui permet de représenter les données semi-structurées,
tout en capturant davantage la sémantique portée par ces données. Les données semistructurées sont souvent stockées dans des fichiers à plat ou des entrepôts, telles que
des bases de données relationnelles [13], des bases de données orienté-objet [11] ou
dans des systèmes semi-structurés spécialisés, tel que Strudel [7], Lore [12], Lotus
Notes [10] et Tamino [14]. Comme dans les SGBDs traditionnels, le stockage et
l’accès efficace, la minimisation des mises à jour sont importante et ne peuvent pas
être réalisés sans connaissance de la sémantique des données. Un des avantages
majeurs des données semi-structurées et en particulier XML, c’est que le stockage des
données est complètement indépendant des détails de la présentation. Cette dernière est
définie par des feuilles de styles, qui sont similaires à la définition de vues dans les
applications des bases de données traditionnelles. Afin de définir des présentations
significatives avec des mises à jour simples, le concepteur doit connaître forcément la
sémantique des ses données.
Dans notre approche, nous nous intéressons à la structure de ces données, autrement
dit aux schémas de données et non pas aux données elles-mêmes, du fait que la taille
du schéma est beaucoup moins importante que le volume des données. Aussi, le
contenu des données ne garantit pas toujours une représentation complète et
disponible.
Nous présentons le reste de l’article comme suit. La section 2 présente quelques
modèles de représentation des données semi-structurées. La section 3 illustre une
description détaillée du modèle CRP. La section 4 concerne le passage d’un schéma
semi-structuré vers le modèle CRP. Pour cela, nous avons choisi comme cas pratique
les schémas XML de type XSD. Enfin, une conclusion et nos futurs travaux font
l’objet de la section 5.
2. Représentation des données semi-structurées
Les premiers systèmes d’intégration de données ont utilisé les modèles relationnels ou
objets comme modèles communs. Cependant, l’intégration de sources de données peu
ou non structurées est difficile avec ces modèles dédiés à représenter spécifiquement
des bases de données. Les modèles de données semi-structurées ont été conçus pour
représenter facilement des données irrégulières provenant de sources hétérogènes,
structurées ou non [2]. Ce sont des modèles flexibles qui permettent de représenter des
données irrégulières en mélangeant la structure et les données [1].
2.1 OEM
Le modèle OEM (Object Exchange Model) [12] est l’un des modèles proposés pour les
données semi-structurées. Il a été conçu à l’origine pour le projet TSIMMIS [8] pour
assurer l’intégration de données de différentes sources. Les données en OEM sont sans
schéma et autodescriptives ; nous pourrions les percevoir comme un graphe dirigé et
étiqueté dont les noeuds sont des objets (comme illustré à la figure 1(a)). Un objet
OEM peut être perçu comme un quadruplet (oid, étiquette, type, valeur). Un objet1
OEM est constitué d’un identificateur d’objet unique (par exemple &8), d’une étiquette
descriptive (adresse), d’un type (chaîne de caractères) et d’une valeur ("Paris"). Les
objets sont soit atomiques, soit complexes. Un objet atomique contient une valeur d’un
type de base (par exemple entier ou chaîne de caractères) et se reconnaît dans le
diagramme au fait qu’il n’a pas de flèche sortante. Tous les autres objets sont qualifiés
d’objets complexes, dont le type est défini par un ensemble d’identificateurs de type, et
sont reconnaissables dans le diagramme car ils comportent une ou plusieurs flèches
sortantes. Un objet complexe peut être le parent d’un nombre quelconque d’objets
enfants OEM et un objet OEM peut avoir plusieurs objets parents, ce qui permet de
construire des réseaux de complexité arbitraire, de manière à modéliser les associations
parmi les données. Le modèle OEM a été conçu spécialement pour gérer l’aspect
incomplet des données, ainsi que l’irrégularité de leur structure et de leur type.
2.2 Les guides de données
La connaissance de la structure de la base de données est importante dans la
formulation de requêtes significatives. De même, le processeur de requête exige une
certaine connaissance de la structure de la base de données pour traiter efficacement
une requête. Malheureusement, les données semi-structurées peuvent ne pas avoir de
schéma et que le schéma doit alors être découvert à partir des données. Lorel [12] offre
une caractéristique innovante sous la forme d’un guide de données (DataGuide, en
anglais) un résumé structurel de la base de données, généré et entretenu
dynamiquement, qui sert de schéma dynamique [9]. Un guide de données possède trois
propriétés : (i) la concision, tout chemin d’étiquette dans la base de données n’apparaît
qu’une et une seule fois dans le guide de données. (ii) la précision, tout chemin
d’étiquette dans le guide de données existe dans la base de données initiale. (iii) le
confort. Le guide de données est un objet OEM (ou XML), de sorte qu’il peut être
1
Un objet OEM ne possède pas de comportement. En effet, il n’est pas possible de définir de
méthodes sur un objet OEM.
stocké et nous pouvons y accéder à l’aide des mêmes techniques que dans la base de
données source.
La figure 2(b) présente un guide de données correspondant aux données de la figure
1(a).
departement
nom
localisation
&2
&3
Informatique Bat A
&6
TEC110
departement
&1
cours
nom
cours
localisation
&4
&7
code
code libelle etudiant
etudiant
&8
OMGL
cours
&5
code libelle etudiant
&9
...
&
20
&
21
libelle
&
22
etudiant
TEC611 ALGO
adresse
numero nom
numero
nom
&
&
23
24
6234901 J.Dupont
&
25
adresse
Paris
(a). OEM
(b). Guide de données
Fig. 1. Représentation d’une structure de données par OEM et guide de données.
2.3 XML/XML-Schema
Le langage XML (eXtensible Markup Language) connaît depuis son apparition en
1996 un succès considérable. Recommandation W3C en 1998, XML est devenu un
standard pour les documents structurés. Sans en exposer tous les détails, faisons-en une
rapide présentation. XML est un sous-ensemble de SGML. Un document XML est
donc structuré en éléments. Les balises marquent le début et la fin de chaque élément.
Les éléments peuvent contenir du texte et éventuellement d’autres éléments.
L’ensemble des données du document XML est contenu dans un élément unique
appelé racine, élément qui contient tous les autres éléments.
XML-Schema [16] est uns standard permettant de définir et de typer un document
XML dans un formalisme proche de celui des bases de données. Il devient alors
possible de définir des schémas des bases de données comme dans un modèle objet. En
particulier, les schémas XSD présentent les avantages suivants.
Syntaxe XML : Adopter une syntaxe XML pour représenter le schéma lui-même, ce
qui permet de réaliser une économie en termes d’outils pour éditer, manipuler et
stocker les schémas, puisque ceux-ci deviennent eux-mêmes des documents XML.
Type de données : Les DTDs fournissent seulement un système sommaire de types,
basé sur les éléments textuels. Les schémas XSD prolonge ce mécanisme avec une
gamme étendue de types, du SQL, du Java tels que date/heure, binaire, URI, etc. De
plus, les schémas XSD intègrent la notion d’héritage soit par restriction soit par
extension des définitions de types.
Espace de noms : Les espaces de noms permettent à des éléments ayant le même
nom d’être employés dans différents contextes. En outre, les types des schémas et leurs
éléments peuvent être inclus (ou importés) dans un schéma XSD séparé en utilisant un
même (ou un autre) espace de noms.
Contraintes : Contrairement aux DTDs, les schémas XSD augmentent la richesse
des contraintes exprimables notamment des contraintes portant sur les contenus et le
type des données : les contraintes de clé et d’unicité, les références (clés étrangères),
les contraintes de valeurs (types énumérés), les contraintes de cardinalités et de valeurs
par défaut ou optionnelles.
Il semble donc nécessaire d’avoir un modèle unifié des modèles semi-structurés qui
essaye de diminuer le fossé sémantique entre eux, mais adaptable aux spécificités de
chacun.
3 Le modèle CRP
Dans le modèle CRP, il existe trois types d’éléments de base, à savoir :
-
Concept,
-
Relation,
-
Propriété.
Le modèle CRP fait une distinction précise de ces trois éléments. Il spécifie également
les contraintes sur les concepts et sur leurs relations telles que le degré et le type des
relations, ainsi que les contraintes sur les différentes propriétés. Toutes ces
informations nous permettront par la suite d’une représentation formelle de ces
éléments.
Définition 1 (CRP)
Le modèle CRP est représenté par le triplet 〈 CCRP, RCRP, PCRP〉 où :
CCRP : est l’ensemble des concepts du schéma modèle,
RCRP : est l’ensemble des relations existantes entres les concepts du modèle,
PCRP : est l’ensemble des propriétés appartenant aux concepts et aux relations.
EXEMPLE – La figure 2 formalise l’exemple de la figure 1 par notre modèle CRP. Dans
cette figure, des concepts, des relations et des propriétés apparaissent. L’identifiant de
département est nom (indiquée par un rond noir) et département possède aussi une
autre propriété localisation. Le losange, liant département et cours, indique qu’il existe
une relation (hiérarchique de type parent/child) entre ces deux concepts. L’identifiant
de cours est code, il possède aussi une propriété libelle qui n’est pas obligatoirement
unique. Chaque étudiant possède un identifiant (numéro), un nom et une adresse. La
relation entre cours et étudiant porte le nom cours_étudiant notée par abréviation ce.
*
departement
dc, 2
?
cours
nom
+
ce, 2
+
localisation
etudiant
code
libelle
numero
nom
adresse
Fig. 2. Représentation d’une structure de données par le modèle CRP.
3.1 Concept
Un concept dans le modèle CRP est équivalent à la notion d’entité dans le modèle
Entité-Relation, de classe dans le modèle objet, et d’élément dans les documents XML.
Traditionnellement, un concept est caractérisé par son nom et un ensemble de
propriétés que nous définirons plus précisément à la section 3.3. Un concept est lié à
un ou à plusieurs concepts via des relations. Nous représentons un concept dans le
modèle CRP par un rectangle portant son nom.
Définition 2 (Concept)
Un concept c∈ CCRP est représenté par le doublet 〈 cnom, ccontenu 〉
cnom : est le nom du concept,
ccontenu : est le contenu du concept.
Où PCRP(c), CCRP(c) sont respectivement l’ensemble des propriétés et des concepts
imbriqués dans le concept c, avec PS(c) ∪ CS(c)= ccontenu.
EXEMPLE – Nous considérons l’exemple où chaque étudiant possède un numéro, un
nom, une adresse et classe. Le numéro est son identifiant. La figure 3 représente le
concept étudiant, avec ses propriétés dans le modèle CRP. Donc, on aura
cnom=〈étudiant〉 et ccontenu=〈nom, adresse, classe〉.
Fig. 3. Représentation du concept étudiant.
3.2 Relation
Deux ou plusieurs concepts peuvent être connectés par une relation. Une relation dans
CRP représente une interconnexion (ou association) entre deux ou plusieurs concepts.
Chaque relation est caractérisée par son nom1. Elle possède également un degré qui
indique le nombre de concepts qu’elle relie. Une relation de degré 2 (e.g. relation
binaire) relie deux concepts, l’un des deux est le parent et l’autre est le fils. Les
contraintes d’occurrences (ou cardinalités) sont définies dans les relations par la
notation issue des modèles objets à savoir ?: zéro-à-un, * : zéro-à-plusieurs et + : unà-plusieurs. Une relation est représentée par un losange noir.
Définition 3 (Relation)
Une relation r∈ RCRP est représentée par le doublet 〈 rnom, rliaison 〉
rnom : est le nom de la relation,
rliaison : est l’ensemble des concepts reliés via r.
EXEMPLE – La figure 4 montre deux relations binaires entre le concept projet et le
concept membre, et entre membre et publication. La relation entre projet et membre est
notée « pm, 2, +, + » signifiant :
pm : son nom (projet_membre),
2 : son degré (entre les deux concepts projet et membre),
+ : un projet concerne au moins un membre voire plusieurs,
+ : un membre participe à au moins un projet voire plusieurs.
Fig.4. Représentation des relations implicites dans le modèle CRP.
1
Parmi les exemples illustrés dans cet article, les noms des relations sont abrégés afin de
simplifier la schématisation des figures en concaténant les premières lettres de chaque concept
intervenant dans la relation.
Les relations vues précédemment, définissent les relations implicites existantes dans
les sources de données semi-structurées (e.g. relation d’hiérarchie et d’imbrication
entre un concept-père et un concept-fils). Pour les relations explicites (structurelles de
type association) entre les concepts (e.g. relation ID/IDREF, key/keyref) dans les
schémas XML. Ces relations sont bidirectionnelles2, c’est pour cela que nous les
représentons par une paire d’arcs (pointillés) reliant les deux concepts en question.
EXEMPLE – Dans la figure 5, les deux concepts article et livre sont liés au concept
bibliothèque via deux relations implicites (ba et bl). Cependant, il existe une relation
explicite entre ces deux concepts article et livre spécifiant une association.
Fig. 5. Représentation des relations explicites dans le modèle CRP.
3.3 Propriété
Une propriété dans le modèle CRP est équivalente à la notion d’attribut dans le modèle
relationnel, objet, ou semi-structuré. Selon le schéma d’origine, les propriétés dans
CRP peuvent apparaître dans les concepts et/ou les relations. Sachant qu’une des
différences majeures entre les bases de données relationnelles et les données semistructurées est la contrainte de l’atomicité des attributs (cf. 1ère forme normale [6]),
nous donnons la possibilité de représenter une propriété par :
–
clé candidate : attribut à valeur unique pour toutes les instances du concept ;
–
clé composée : ensemble d’attributs définissants une valeur unique ;
–
clé primaire : parmi les clés candidate ;
–
propriété mono-valuée : possédant une seul valeur ;
–
propriété multivaluée : possédant un ensemble de valeurs ;
–
propriété à valeur required /optional / fixed/ ou default ;
–
propriété à structure inconnue : possédant différentes structures dans le schéma.
2
Afin de garder la compatibilité avec les relations implicites existantes et donc la cohérence
dans le modèle CRP.
Dans le modèle CRP, nous classifions deux classes de propriétés, à savoir :
⎯ Propriété clé : qui est représentée à partir d’une clé dans le schéma source ;
⎯ Propriété simple : qui n’est pas une propriété clé dans CRP et qui représente les
cas mono-valuée, multi-valuées et structure inconnu.
Une propriété est représentée par un cercle étiqueté par son nom. De plus, si cette
propriété est une clé (propriété clé), son cercle est noir. Si elle possède une structure
irrégulière (multi-structure), le cercle est discontinu. Si la propriété est multi-valuée,
nous rajoutons le signe * à l’intérieur du cercle. De même, en fonction des contraintes
qu’elle porte, nous rajoutons R pour required , O pour optional, F pour fixed, D pour
default.
Définition 4 (Propriété)
Une propriété p∈ PCRP est représentée par le triplet 〈 pnom, pcatégorie, pdomaine 〉
pnom : est le nom de la propriété,
pcatégorie : est le type de la propriété (clé ou simple),
pdomaine : est le domaine de définition de la propriété.
Où Pclé(c) et Psimple(c) sont respectivement l’ensemble des propriétés clés et
propriétés simples du concept c, avec Pclé(c) ∩ Psimple(c)=∅ et Pclé(c) ∪ Psimple(c)=
PCRP(c).
EXEMPLE – Nous considérons le modèle CRP de la figure 6. Le concept cours possède
les propriétés code (propriété clé), libellé (propriété simple) et une autre propriété avec
une structure irrégulière ou multiple (info.). Le concept étudiant possède aussi une
propriété clé définit par son numéro. Le nom de l’étudiant qui doit être toujours
renseigné ou requis ; en outre, hobbies est une propriété à valeurs multiples (un
étudiant peut avoir plusieurs hobbies).
Fig. 6. Représentation des propriétés dans le modèle CRP.
Visuellement, on peut remarquer que le modèle CRP ressemble au modèle EntitéRelation mais n’est pas identique. Cette représentation à l’avantage de paraître
familière à la communauté des bases de données relationnelles du fait que le modèle
ER est un modèle connu ; aussi, notre modèle CRP est aisément compréhensible et
facilement exploitable. Un autre avantage du modèle CRP est qu’il est capable de
représenter à la fois les différentes imbrications (hiérarchies) dans les données semistructurées De plus, il peut modéliser des attributs multi-valués et/ou à structure
inconnue qui ne peuvent pas être exprimés dans les autres modèles de données.
4 Mapping entre XSD/CRP : Implémentation et validation
Tout au long de ce papier, nous avons présenté le modèle CRP. Dans cette section, nous
exposons brièvement comment les informations sémantiques dans le modèle CRP
peuvent être dérivées et utilisées. Premièrement, nous montrons comment les schémas
de type XSDs peuvent être représentés dans CRP. Dans [18], nous avons défini un
ensemble de règles de mapping entre les schémas XML et le modèle CRP.
Premièrement l’élément racine (root element) du schéma XSD est défini par un
concept dans le modèle CRP. Ce concept représente l’agrégation ou le concpet-racine
de tous les autres concepts du modèle. Les éléments XSDs de type xsd:element
possédant d’autres éléments ou attributs (xsd:attribute), sont représentés par des
concepts dans le modèle CRP. Pareil pour les éléments dont la structure est complexe
(xsd:complexType) sont représentés par des concepts. Les éléments de type
xsd:attribute représentent les propriétés composées. Ainsi que les éléments avec le
type xsd:key représentent les propriétés clés, tandis que les éléments de type xsd:keyref
indiquent une référence entre concepts. Aussi les relations sont dérivées à partir des
relations hiérarchiques (implicites), et les différentes associations (explicites)
existantes. Les cardinalités des éléments et des attributs peuvent être aussi représentées
à partir des schémas XML.
Pour des besoins spécifiques, nous représentons le modèle CRP avec deux
représentations différentes à savoir : représentation arborescente (TREE) (voir figure
8(b)) et représentation graphique (GRAPH) (voir figure 8(c)). Dans un premier temps
nous chargeons les fichiers XSDs à transformer dans notre système3 (voir figure 8(a)).
Pour la génération automatique des modèles CRP4, nous récupérons l’ensemble des
informations structurelles et sémantiques propres aux différents éléments du schéma
XSD, ainsi que toute son arborescence. L’avantage de ces représentations permet de
mieux visualiser, parcourir et comparer des schémas XML hétérogènes, sans recourir à
la syntaxe elle-même, qui peut être incompréhensible par certains utilisateurs. Via le
modèle CRP généré, le concepteur ou l’expert du domaine peut modifier, supprimer, ou
mettre à jour directement des informations sur les concepts, les relations et les
propriétés du modèle (e.g., modifier le nom d’un concept, les cardinalités ou le
3
Les schémas XSDs passent préalablement par une phase de parsing afin de vérifier leur
validité. Pour cela, nous intégrons dans notre système un parseur validateur. Ce dernier se
lancera automatiquement dès qu’un schéma XSD est chargé dans le système.
4
Nous montrons exclusivement ici le mapping XSD/CRP. Notre système a été conçu pour
transformer divers schémas semi-structurées tels que, DTD, DSD.
domaine de définition d’une propriété, etc.). Ces modifications consistent à
l’enrichissement sémantique [17] semi-automatique des modèles CRP dans le but de
pallier à la pauvreté sémantique des sources de données semi-structurées.
(a) Aperçu d’un schéma XSD chargé dans notre système (vue "TEXT")
(b) Aperçu d’un modèle CRP (vue "TREE")
(c) Aperçu d’un modèle CRP (vue "GRAPH")
Fig. 8. Génération automatique des modèles CRP à partir des schémas XSD.
5 Conclusion
Jusqu’à l’avènement du langage XML, le monde de l’information se divisait en deux
parties complémentaires. D’un côté, il y avait le monde des bases de données
traditionnelles (hiérarchiques, relationnelles, objets), de l’autre, le monde de l’EDI
permettant l’échange des informations et des présentations. La plupart des systèmes
d’intégration actuels utilisent XML comme modèle commun. Sa structure irrégulière
permet de représenter toutes formes de données, mais présente l’inconvénient de
complexifier les algorithmes d’intégration des données de différentes sources,
notamment l’intégration des schémas.
Le travail présenté dans cet article s’insère dans le cadre des travaux liés à
l’intégration de données et plus particulièrement à l’intégration de schémas. Nous
avons défini un modèle CRP par l’utilisation d’un ensemble minimal de type
d’éléments (concept, relation, propriété), par l’emploi d’une notation claire et
facilement compréhensible, et par sa capacité à représenter à la fois la structure et la
sémantique des schémas hétérogènes. L’un des objectifs du modèle CRP est de
diminuer l’ambiguïté sémantique entre les différents types d’éléments.
Le modèle CRP peut être utilisé dans plusieurs voies de recherches telles que, le
stockage des structures issues des BDs XML natives, la conception de vues XML,
l’évaluation des requêtes, etc. Dans le cadre de nos recherches, nous exploitons le
modèle CRP pour la définition des schémas XML riche en sémantique, dans le cadre de
l’intégration de schémas sources hétérogènes. Dans un tel contexte, partager et
réutiliser des ressources existantes s’avère d’un intérêt incontestable, à la fois en
termes d’interopérabilité entre les applications et entre les différents utilisateurs.
Nous envisageons dans le futur, améliorer ce modèle en tenant compte d’autres
contraintes telles que les dépendances fonctionnelles, les formes normales, l’héritage,
etc. afin d’enrichir sémantiquement le modèle CRP. Ce qui permettra (i) d’étendre ce
formalisme conceptuel sur d’autres modèles tels que le relationnel ou même l’objet, et
(ii) de mieux représenter les schémas sources afin de produire des matching/mapping
corrects entre les ces derniers.
Références
1. Abiteboul, S., Buneman, P., Suciu, D.: Data on the Web: From Relations to Semistructured
Data and XML, Morgan Kaufmann, (1999)
2. Bergamaschi, S., Castano, S., Vinci, M.: Semantic integration of semistructured and
structured data sources, SIGMOD Record, (1999) 54-59
3. Bray, T., Paoli, J., Sperberg-McQueen, C.M., Maler, E.: Extensible markup language (xml)
1.0, second edition. http://www.w3.org/TR/2000/REC-xml-20001006, (2000)
4. Buneman, P., Susan, B., Davidson, D., Fernandez, M.F., Suciu, D.: Adding structure to
unstructured data, In Proceedings of the 6th International Database Theory Conference Theory
(ICDT’97), (1997) 336-350
5. Cluet, S., Delobel, C., Simeon, J., Smaga, K.: Your mediators need data conversion!, In
Proceedings ACM SIGMOD International Conference on Management of Data, ACM Press,
(1999) 177-188
6. Codd, E.F.: Relational Completeness of Databases Sublanguages, Prentice Hall, Englewood,
Cliffs, NJ, (1972)
7. Fernandez, M., Florescu, D., kang, J., Levy, A., Suciu, D.: Catching the boat with Strudel:
experiences with a web-site management system. In SIGMOD, (1998) 414-425
8. Garcia-Molina, H., Papakonstantinou, Y., Quass, D., Rajamaran A., Sagiv Y., Ullman, J.,
Vassalos, V., Windom, J.: The TSIMMIS Approach to mediation: Data Models and
Languages. Journal of Intelligent Information Systems, (1997)
9. Goldman, R., Widom, J.: Enabling query formulation and optimization in semistructured
databases, In Proceedings of 23rd International Conference on Very Large Data Bases
(VLDB’97), Morgan Kaufmann, (1997) 436-445
10. Lotus Development Corporation. Lotus development corporation. http://www.lotus.com/
11. Luddsher, B., Himmervder, R., Lausen, G., May, W, Schlepphorst, C.: Managing
semistructured data with FLORID: a deductive object-oriented perspective. Information
Systems, (1998) 589-613
12. McHugh, J., Abiteboul, S., Goldman, R., Quass, D., Widom, J.: Lore: A database
management system for semistructured data. SIGMOD Record, (1997) 54-66
13. Shanmugasundarm, J., Tufte, K., Zhang, C., He, G., DeWitt, J., Naughton J.F.: Relational
databases for quering XML documents: Limitations and opportunities. In Proceedings
VLDB’99, Morgan Kaufmann, (1999) 79-90
14. Tamino – An Internet Database System. http://www.tamino.com/
15.W3C-XML, Extensible Markup Language (XML) 1.0, W3C Recommendation,
http://www.w3.org/TR/REC-XML, (1998)
16.W3C-XSD, XML Schema Part 0: Primer, W3C Recommendation, 2001,
http://www.w3.org/TR/XmlSchema-0/, (2001)
17. Zerdazi, A., Lamolle, M.: Hyperschema XML: Un modèle d’intégration par enrichissement
sémantique de schémas XML, MajecSTIC’05, (2005) 143-150
18.Zerdazi, A., Lamolle, M.: Modélisation des schémas XML par adjonction de
métaconnaissances sémantiques, ASTI’05, (2005) 29-32