Intégration de données en provenance du web

École Doctorale d’Informatique et Information pour la Société
DEA Extraction des Connaissances à partir des Données
Mémoire de DEA
Intégration de données en provenance du web
dans un entrepôt de données
Réalisé par
Sami Miniaoui
Directeur de Recherche
Jérôme Darmont
Laboratoire ERIC, Équipe BDD
Juillet 2001
Remerciements
Je tiens à remercier mon directeur de recherche M. Jérôme Darmont pour son
aide précieuse et ses conseils judicieux.
Mes remerciements s’adressent aussi aux membres du groupe Bases de Données
Décisionnelles et particulièrement à M. O. Boussaid et Melle F. Bentayeb pour
leurs encouragements incessants.
Je tiens aussi à remercier tout les membres du laboratoire ERIC pour leur
accueil bienveillant et chaleureux.
A tous ceux qui ont aidé de près ou de loin à l’élaboration de ce travail.
Résumé
Dans un processus d’entreposage de données, la phase de préparation de données est
essentielle. La maîtrise de cette phase améliore en performance une ultérieure phase de data
mining ou d’analyse multidimensionnelle (OLAP).De plus, un entrepôt de données peut
nécessiter des données externes. Dans ce contexte, le Web représente une source essentielle
de données, mais ces dernières sont hétérogènes. Nous proposons un modèle de données
unifié UML permettant d'intégrer des données hétérogènes: textes libres ou balisés (HTML,
XML, SGML...), images, son, vidéo, données issues de bases de données, etc. Nous avons
utilisé XML pour représenter ces données diverses et hétérogènes au sein d’un format unifié.
La définition du schéma grâce à XML fournit les métadonnées indispensables dans un
contexte d’entreposage de données. De plus, nous tirons avantage de la souplesse et
l’extensibilité de XML tout en conservant la possibilité d’intégrer des documents XML dans
une base de données si nécessaire.
Mots clés : Données multiformes, Entrepôts de données, Data mining, Intégration,
Modélisation UML, XML
Abstract
In a data warehousing process, the data preparation phase is crucial. Mastering this phase
allows substantial gains in terms of time and performance when performing a
multidimensional analysis or using data mining algorithms. Furthermore, a data warehouse
can require external data. The Web is a prevalent data source in this context, but the data
broadcasted on this medium are very heterogeneous. We propose a UML model for a complex
object representing a superclass of any useful data source (databases, plain texts, HTML and
XML documents, images, sounds, video clips…). The implementation of this model is
achieved with XML, which helps integrating all these diverse, heterogeneous data into a
unified format, and whose schema definition provides first-rate metadata in a data
warehousing context. Moreover, we benefit from XML’s flexibility, extensibility and from
the richness of the semi-structured data model, but we are still able to map XML documents
into a database if more structuring is needed.
Keywords: Multiform data, Data warehousing, Data Mining, Integration, UML Modeling,
XML
Sommaire
Introduction ...............................................................................................................................1
CHAPITRE 1
1.
Etat de l’art ........................................................................3
Approches d’intégration -------------------------------------------------------- 3
1.1 Les bases de données fédérées......................................................................................3
1.2 Notre approche .............................................................................................................4
2. Le langage XML ----------------------------------------------------------------- 6
2.1 Définition......................................................................................................................7
2.2 Modèle de données .......................................................................................................8
2.3 Mapping XML..............................................................................................................8
CHAPITRE 2
Méthodologie .....................................................................10
1 Modèle conceptuel UML---------------------------------------------------------10
2. Modèle logique XML -------------------------------------------------------------12
2
Mise en œuvre -------------------------------------------------------------------13
3.1
Extraction des attributs .........................................................................................13
3.2 Génération du fichier XML .......................................................................................13
CHAPITRE 3
Discussion .....................................................................17
1. Modèle conceptuel ----------------------------------------------------------------17
2. Implémentation--------------------------------------------------------------------17
2.1 Traitement des modalités manquantes........................................................................17
2.2 Traitement des valeurs manquantes............................................................................18
2.4 Amélioration du traitement du texte...........................................................................18
Conclusions et Perspectives.....................................................................................................20
1. Bilan--------------------------------------------------------------------------------- 20
2. Perspectives ----------------------------------------------------------------------- 20
Introduction
L’évolution du commerce électronique a poussé les grandes entreprises à capitaliser leurs
données au sein de grandes bases de données ou d’entrepôts de données. Cette modélisation
centralisée permet, en utilisant les outils OLAP et/ou des techniques d’extraction de
connaissances à partir des données (ECD), d’analyser, de comprendre et de prédire le
comportement des clients et l’évolution des ventes de leurs produits par exemple. La
connaissance extraite à l’aide de ces techniques d’analyses constitue un support pour l’aide à
la décision.
Nous appelons ces bases de données dédiées à l’aide à la décision «les bases de données
décisionnelles» (BDD). La phase de gestion de données dans une base de données
décisionnelle consiste à alimenter en premier lieu la base par des données provenant de
différentes sources et, en second lieu, à créer des espaces d’analyses (cubes
multidimensionnels, tableaux, vues relationnelles, magasins de données) en agrégeant des
attributs.
L’application d’algorithmes de data mining et d’outils OLAP se fait généralement sur des
données bien structurées (cubes multidimensionnels, tableaux, vues relationnelles). Or les
bases de données décisionnelles peuvent nécessiter des données externes. Par exemple, une
entreprise souhaitant faire de la vaille concurrentielle ne peut pas se contenter d’analyser
uniquement ses propres bases de production. Dans ce contexte, le Web est une source de
données prépondérante.
Néanmoins, comme les données diffusées sur ce médium sont hétérogènes cela rend leur
intégration dans une BDD difficile. Pourtant, les concepts d’entreposage de données [CHA97]
demeurent valides dans cette approche. Les mesures, bien que pas nécessairement
numériques, restent les indicateurs pour l’analyse, qui est toujours appliqué selon différentes
perspectives représentées par les dimensions. Les gros volumes de données considérés et leur
historisation sont d’autres arguments en faveur de cette approche [KIM00a].
Notre objectif est d’utiliser le Web comme une source de données à part entière pour les
BDD, de façon transparente. Cela soulève plusieurs problèmes:
•
Structuration de données multiformes en provenance du Web (bases de données,
textes, données multimédia, données structurées)dans une base de données;
•
Intégration de ces données dans l’architecture particulière d’un entrepôt de données
(Faits, dimensions, magasins,…);
•
Réorganisation physique des données pour l’optimisation des performances des
requêtes.
Références ................................................................................................................................21
Bibliographie............................................................................................................................23
Notre travail concerne le premier point. Nous proposons un modèle de données unifié pour un
objet complexe représentant une super classe des données multiformes que nous souhaitons
intégrer dans une BDD. Notre objectif n’est pas seulement de stocker des données, mais aussi
de les préparer véritablement à l’analyse. En ce sens, ce n’est pas une simple tâche d’ETL
(Extraction, Transforming and Loading).
1
Ce mémoire est organisé comme suit : nous présentons un état de l’art des approches
d’intégration de données, puis notre modèle conceptuel UML ainsi que le modèle logique
XML. Nous présentons ensuite notre prototype ainsi que notre algorithme de transformation,
nous discutons les résultats ainsi que les améliorations à apporter à notre travail et nous
finissons par un bilan et des perspectives.
CHAPITRE 1
Etat de l’art
Nous présentons rapidement dans ce chapitre les différentes approches d’intégration de
données et justifions notre propre approche d’intégration. Nous présentons ensuite le langage
XML qui nous sert à définir un format unifié de données et énumérons les possibilités
d’intégration de documents XML dans une base de données (mapping).
1.
Approches d’intégration
La première génération d’outils d’intégration s’est développée autour du modèle relationnel
et de SQL qui a servi de langage d’échange de données.
L’approche CORBA (Common Object Request Broker Architecture) peut être perçue comme
la deuxième génération de solution d’intégration, mais souffre de l’absence d’interface
réellement standard avec les bases de données et de son côté statique qui ne facilite pas les
évolutions (c’est une approche essentiellement compilée).
Une nouvelle génération prometteuse d’outil d’intégration est constituée des bases de données
fédérées qui ont convergé vers un standard proposé par DARPA et Gio Widerhold :
l’architecture I3.
1.1 Les bases de données fédérées
Le concept de base de données fédérée a émergé du fait que pour pouvoir alimenter un
entrepôt de données, on est mené à se connecter à plusieurs sources de données qui
constituent un grande base de données hétérogène. [GAR99b] définit les bases de données
fédérées comme suit :
« Une base de données fédérée est une base de données repartie hétérogène constituée de
sources de données de natures variées : fichiers HTML, XML ». L’élaboration d’une base de
données fédérée nécessite donc une architecture qui permet la communication entre les
différentes sources de données.
Cette architecture s’articule en trois niveaux [BER01, BUS99] :
2
!"
un niveau présentation formé de composants qui permettent de formuler des
requêtes dans le langage de la base de données fédérée ;
!"
un niveau médiation formé de médiateurs qui se chargent de collecter les demandes
des utilisateurs déjà collectées par les composants de présentation et de les traduire
dans le langage de chaque source de données ;
!"
un niveau adaptation formé de composants qui permettent la communication entre
une source de données et les médiateurs (Fig. 1).
3
[GAR99b] propose une implémentation de base de données fédérée en utilisant des
composants de connexion aux sources de données et de communication entre les utilisateurs
et les sources de données.
Mot clé
Base
Niveau Présentation
Données
Niveau Médiation
Mediateur1
Mediateur2
Mediateur3
Relationnelle
Fréquence
3
Lien
Doc1
2
Doc2
2
Doc3
5
Doc4
7
Doc3
5
Doc2
Fig. 2 : Structure d’une liste inversée
Niveau Adaptation
JDBC
Connecteurs aux données
b) Signature
Sources de données
fichier
BD
Les mots les plus fréquents dans le document sont extraits et « hachés » pour obtenir une liste
dont l’union (sommation binaire) aboutit à une signature, qui est une chaîne de bits (Fig. 3).
WEB
Fig. 1 : Architecture des bases de données fédérées
Un texte à
D1 analyser en un
ensemble de
mots
significatifs
analyse
Texte
Analyser
Ensemble
mot
significatif
hachage
0000000010
0000000100
0000001000
0000010000
0000100000
1.2 Notre approche
union
Signature
0000111110
du document D1
Notre approche s’inspire de celle sous-jacente aux bases de données fédérées (concept de
médiateur), mais s’appuie également sur les travaux existants dans les domaines de bases de
données documentaires et multimédia, en raison des données que nous manipulons.
Fig. 3 : Structure d’une signature de document
1.2.1 Les bases de données documentaires
c) Matrice de fréquence relative
Les bases de données documentaires sont destinées à stocker et manipuler des documents
textuels. Elles utilisent plusieurs stratégies d’indexation [RAK95, GAR99a].
a) Listes inversées
Il s’agit de créer une matrice F qui contient tout les mots qui figurent dans les documents.
L’intersection du mot Mi avec le document Di indique sa fréquence d’apparition dans le
document. La matrice F est généralement de très grande taille du fait de la multitude des mots
qu’elle peut contenir (Fig. 4).
Il s’agit de construire une liste d’entrées indiquant pour chaque mot significatif la liste des
identifiants de documents contenant ce mot et sa fréquence dans chaque document (Fig. 2).
4
5
D1
D2
D3
D4
D5
D6
D7
.
.
.
.
.
.
.
.
.
.
.
.
.
.
XML, ou « eXtensible Markup Language » [AND98], est un méta-langage proposé par le
W3C (World Wide Web Consortium) pour l’échange de données sur le Web.
.
.
.
.
.
.
.
XML a introduit la séparation de la structure et la présentation pour permettre :
M4
.
.
.
.
.
.
.
M5
.
.
.
.
.
.
.
M1
M2
M3
Fig. 4 : Matrice de fréquence F
1.2.2 Les bases de données multimédia
Les bases de données multimédia contiennent des données diverses (image, son, vidéo…).
Elles offrent plusieurs stratégies d’indexation. Par exemple, à partir des mots clés qui
décrivent les images ou les vidéos (généralement, la description est manuelle), est générée une
signature pour chaque objet multimédia.
En ce qui concerne les images, il est possible d’extraire :
!"
un vecteur distribution de couleurs (rouge, bleu, jaune…) ;
!"
un vecteur de distribution de texture ;
!"
un vecteur distribution de luminosité
2.1 Définition
!"
des recherches intelligentes par le contenu,
!" s présentations sur différents supports (Web, papier).Les éléments (balises) qui
forment un document XML sont sous forme d’une arborescence (Fig. 5).
<!DOCTYPE BOOKLIST SYSTEM “booklist.dtd”>
<BOOKLIST>
<LIVRE genre=“Lettres”>
<AUTEUR>
<NOM>Camus</NOM><PNOM>Albert</PNOM>
</AUTEUR>
<TITRE>L’étranger</TITRE>
<EDITION>1980</EDITION>
<LIVRE genre=“Sciences” couverture=“Cartonnée”>
<AUTEUR>
<NOM>Gray</NOM><PNOM>Jim</PNOM>
</AUTEUR>
<TITRE>Transactions Processing</TITRE>
</LIVRE>
</BOOKLIST>
Fig. 5 : Exemple de fichier XML – FICHIER_LIVRES.xml
qui servent à l’indexation.
Il est évident que la recherche par contenu dans une base de données multimédia reste un
problème sans une solution satisfaisante.
2. Le langage XML
Le développement d’Internet a révélé les lacunes du langage HTML (pages statiques,
présentation mélangée à la forme). Le langage SGML (Standard Generalized Markup
Langage) est abandonné vu sa difficulté à écrire des documents publiables sur le Web, d’où
l’apparition d’un nouveau langage qui est XML.
Le langage XML vient alléger les contraintes imposées par SGML pour l’écriture de
documents publiables sur le Web et se montre plus performant que HTML en termes de
structuration et de dynamicité des données.
6
Le W3C a également introduit la notion de grammaire (DTD), afin de contrôler la validité
d’un document XML. Une DTD (Document Type Definition) permet de définir la structure
interne du document XML à lequel elle est associée. Elle est comparable à un schéma de base
de données (Fig. 6).
<!ELEMENT BOOKLIST (LIVRE)*>
<!ELEMENT LIVRE (AUTEUR, TITRE, EDITION?)>
<!ELEMENT AUTEUR (NOM, PNOM)>
<!ELEMENT NOM (#PCDATA)>
<!ELEMENT PNOM (#PCDATA)>
<!ELEMENT TITRE (#PCDATA)>
<!ELEMENT EDITION (#PCDATA)>
<!ATTLIST LIVRE genre (Sciences|Lettres) #REQUIRED>
<!ATTLIST LIVRE couverture(Normale|Cartonné) “Normale”>
Fig. 6: DTD relative à FICHIER_LIVRES.xml
7
2.2 Modèle de données
Un modèle de données pour les documents XML a été proposé par le W3C. Le modèle OEM
(Object Exchange Model), également adopté par [GAR99b], représente un document XML en
graphe orienté étiqueté (Fig. 7) où :
#"les sommets sont les types de données,
[BOO99] génère un modèle UML relatif au schéma XML d’un document XML, mais
$"
l’implémentation de ce modèle dans un système de gestion de base de données(objet
ou relationnel-objet) n’est pas accomplie.
[MCH97] propose un système de gestion de base de données natif XML : LORE, qui
$"
est utilisé avec son propre langage de requête : LOREL. Il existe d’autres produits
adoptant un système de gestion de base de données native XML: TAMINO [GRA99],
Xhive [XHI01], TEXTML [IXI00], NATIX [ABI01].
#"les arcs sont les classes ou les objets,
#"les feuilles sont les données.
LIVRE
AUTEUR
TITRE
Etranger
NOM
Albert
PNOM
EDITION
AUTEUR
1980
COUVERTURE
TITRE
TRANSACTION
PROCESSING
NOM
Camus
Jim
Cartonnée
PNOM
Gray
Fig. 7: Graphe OEM du fichier FICHIER_LIVRES.xml
2.3 Mapping XML
Le mapping est la représentation de documents XML dans une base de données, qu’elle soit
relationnelle, orientée-objet, relationnelle objet ou «native XML». Les approches de mapping
suivantes ont été proposées dans la littérature :
[KAP00] opte pour une approche relationnelle pour stocker les documents XML et
$"
propose un algorithme de transformation d’un document XML en tables relationnelles
en générant un schéma UML qui spécifie le mapping entre la DTD du document XML
et le schéma relationnel de la base de données.
8
9
CHAPITRE 2
Méthodologie
Nous avons mis en œuvre une approche de conception classique pour atteindre notre
objectif :
!"
modèle conceptuel UML
!"
modèle logique XML
!"
modèle physique dépendant du contexte (document XML ou base de données).
1 Modèle conceptuel UML
Les données que nous souhaitons modéliser forment une hiérarchie. Le langage UML
est par conséquent bien adopté à leur description (Fig. 8).
Nam e
D a te
S o u rce
L AN G U AG E
Les documents textes sont subdivisés en textes ordinaires et textes balisés (les documents
HTML, XML, ou SGML). Un texte balisé est de plus associé à un certain nombre de liens.
Puisqu'une page Web peut référencer des données externes (d'autres pages, des images, des
données multimédia ...), ces liens aident à associer ces données à la page qui les référence.
Name
*
*
0 ..1
*
S U B D O C U ME N T
*
*
Nam e
Typ e
S ize
L o ca tio n
TE XT
TAG G E D TE XT
K E YW O R D
*
*
R E L ATI O NA L VI E W
IMAG E
Q u e ry
*
Fo rm a t
C o m p re s s io n
W id th
L e n g th
R e s o lu tio n
*
Te rm
TE MP O R AL
D u ra tio n
Speed
P LAI N TE X T
SOU N D
C o n te n t
V ID E O
*
*
*
Les vues relationnelles sont extraites de partir de n'importe quel type de base de données
(relationnelle, objet, objet-relationnelle | nous supposons qu'une vue peut être extraite depuis
n'importe quel modèle de données) pour être matérialisées dans l'entrepôt de données. Une
vue relationnelle est un ensemble d'attributs (colonnes, caractérisées par leur nom et leur
domaine) et un ensemble de tuples (lignes). A l’intersection des tuples et des attributs se
trouve une valeur. Dans notre modèle, ces valeurs apparaissent en tant qu’ordinaux, mais dans
la pratique elles peuvent être du texte ou des BLOBs contenant des données multimédia. La
requête qui a permis d’établir la vue est également enregistrée. Selon le contexte, toutes les
données peuvent être enregistrées, seulement la requête et l'intention (définition des attributs)
ou les deux. Par exemple, il pourrait être inadéquat de dupliquer des quantités énormes de
données, particulièrement si la source d'émission n'est pas régulièrement mise à jour. Par
contre, si des instances successives d'une vue sont nécessaires, les données devront être
enregistrées.
ATTR IB U TE
TU P L E
*
LI N K
La classe langage est importante pour les algorithmes de text mining et la recherche
d’information puisqu’elle caractérise les documents et les mots clés. Par suite les mots clés
sont une représentation sémantique d’un document. Ils sont des Meta données qui décrivent
l’objet à intégrer (image médicale, article de presse) ou bien son contenu. Ils sont essentiels
pour l'indexation. Les mots-clés sont en générale obtenues manuellement, mais il serait très
intéressant de les extraire automatiquement à l'aide des techniques de text mining, d'image
mining, ou de XML mining (détection de balises).
Toutes les classes suivantes sont des sous-classes de la classe sous-document. Elles
représentent les types de données et/ou les documents de base que nous voulons intégrer.
C O MP L E X O B JE C T
N b _ ch a r
N b _ lin e s
données. Notons que notre but ici est de proposer une structure générale pour les données. La
liste des attributs de chaque classe de ce diagramme n’est pas exhaustive.
Un objet complexe est caractérisé par son nom et sa source. L’attribut date représente la
notion des versions successives dans le temps qui est cruciale dans les entrepôts de données.
Chaque objet complexe se compose de plusieurs sous documents. Chaque sous-document est
identifié par son nom, son type, sa taille et son emplacement (son adresse physique). Le type
de document (texte, image …) est indispensable pour pouvoir ultérieurement choisir l’outil
d’analyse approprié (text mining, par exemple).
*
*
Nam e
D o m a in
URL
ATO MIC VAL U E
Va lu e
Fig. 8 : Modèle de données multiformes
Les types de données (texte, multimédia, image..), qu’on se propose d’intégrer dans un
entrepôt de données, contiennent tous des caractéristiques qui peuvent servir pour
l’indexation. Le diagramme UML représente un objet complexe généralisant tout type de
10
Les images contiennent deux types d'attributs : certains sont habituellement trouvés dans
l'entête du fichier image (format, taux de compression, taille d'un pixel, résolution) et d’autres
doivent être extraits par programme, comme des distributions de couleur ou de texture.
Pour terminer, les sons et les vidéos font partie d'une même classe parce qu'ils partagent les
attributs temporels (vitesse de défilement, durée) qui sont absents des autres types de données
que nous considérons. A notre connaissance, ces types de données (vidéo, son) ne sont pas
actuellement analysés par les algorithmes de data mining, mais ils contiennent de la
connaissance. C'est pourquoi nous les prenons en considération, anticipant ainsi l’apparition
des techniques de " multimédia mining ".
11
2. Modèle logique XML
2 Mise en œuvre
Dans un entrepôt de données, les données sont accompagnées par des métadonnées qui
décrivent leur origine, les règles de transformations qu’elles ont éventuellement subies et des
informations concernant leur utilisation. De même, des données multiformes modélisées en
tant qu'objets complexes peuvent être visualisées comme des documents. Il est alors
nécessaire de considérer deux types de données : les données elles-mêmes et des données qui
représentent l'information décrivant leur sémantique.
L'utilisation de XML comme un outil d’implémentation pour des données multiformes (c.-àd., objets complexes) perçus comme des documents semble naturel. Ce langage permet en
effet de représenter à la fois la description et le contenu de n'importe quel document. Dans un
processus de modélisation, la traduction des classes UML représentant des données
multiformes en XML constitue une phase de formalisation logique. Le modèle logique obtenu
(Fig. 9 ) peut être aussi bien « mappé » dans une base de données relationnelle ou
relationnelle- objet qu’être directement stocké dans une base de données native XML.
<!ELEMENT COMPLEX_OBJECT (OBJ_NAME, DATE, SOURCE, SUBDOCUMENT+)>
<!ELEMENT OBJ_NAME PCDATA #REQUIRED>
<!ELEMENT DATE PCDATA #REQUIRED>
<!ELEMENT SOURCE PCDATA #REQUIRED>
<!ELEMENT SUBDOCUMENT (DOC_NAME, TYPE, SIZE, LOCATION, LANGUAGE?,
KEYWORD*, (TEXT | RELATIONAL_VIEW | IMAGE | TEMPORAL))>
<!ELEMENT DOC_NAME PCDATA #REQUIRED>
<!ELEMENT TYPE PCDATA #REQUIRED>
<!ELEMENT SIZE PCDATA #REQUIRED>
<!ELEMENT LOCATION PCDATA #REQUIRED>
<!ELEMENT LANGUAGE PCDATA #REQUIRED>
<!ELEMENT KEYWORD PCDATA #REQUIRED>
<!ELEMENT TEXT (NB_CHAR, NB_LINES, (PLAIN_TEXT | TAGGED_TEXT))>
<!ELEMENT NB_CHAR PCDATA #IMPLIED>
<!ELEMENT NB_LINES PCDATA #IMPLIED>
<!ELEMENT PLAIN_TEXT PCDATA #REQUIRED>
<!ELEMENT TAGGED_TEXT (CONTENT, LINK*)>
<!ELEMENT CONTENT PCDATA #REQUIRED>
<!ELEMENT LINK PCDATA #REQUIRED>
<!ELEMENT RELATIONAL_VIEW (QUERY?, ATTRIBUTE+, TUPLE*)>
<!ELEMENT QUERY PCDATA #REQUIRED>
<!ELEMENT ATTRIBUTE (ATT_NAME, DOMAIN)>
<!ELEMENT ATT_NAME PCDATA #REQUIRED>
<!ELEMENT DOMAIN PCDATA #REQUIRED>
<!ELEMENT TUPLE (ATT_NAME_REF, VALUE)+>
<!ELEMENT ATT_NAME_REF PCDATA #REQUIRED>
<!ELEMENT VALUE PCDATA #IMPLIED>
<!ELEMENT IMAGE (COMPRESSION, FORMAT, RESOLUTION, LENGTH, WIDTH)>
<!ELEMENT COMPRESSION PCDATA #IMPLIED>
<!ELEMENT FORMAT PCDATA #IMPLIED>
<!ELEMENT RESOLUTION PCDATA #IMPLIED>
<!ELEMENT LENGTH PCDATA #IMPLIED>
<!ELEMENT WIDTH PCDATA #IMPLIED>
<!ELEMENT TEMPORAL (DURATION, SPEED, (SOUND | VIDEO))>
<!ELEMENT DURATION PCDATA #IMPLIED >
<!ELEMENT SPEED PCDATA #IMPLIED>
<!ELEMENT SOUND PCDATA #IMPLIED>
<!ELEMENT VIDEO PCDATA #IMPLIED>
Fig. 9 : DTD XML
12
Nous développons actuellement une application Java (langage choisi pour sa portabilité)
permettant de prendre en entrée toute source de données Web, de la décrire à l’aide de notre
modèle et de produire le document XML correspondant. L’algorithme de transformation
comporte deux phases :
!"
extraction des attributs de l’objet complexe sélectionné par l’utilisateur,
!"
génération du document XML.
3.1 Extraction des attributs
En fonction du type du document (texte, image …), on procède à un traitement particulier.
Pour un texte, par exemple, le nombre de lignes, le nombre de caractères, la langue dans
laquelle le texte est écrit et les mots clés sont extraits. Pour extraire les caractéristiques de
n’importe quel type de données (texte libre, HTML, image, son, vidéo …) afin de générer le
fichier XML correspondant on fait appel à :
la saisie manuelle de l’utilisateur (détection du type du document …),
$"
des méthodes et bibliothèques standard Java (getWidth, getSize …),
$"
des algorithmes d’ECD (reconnaissance de langues …).
$"
La liste des attributs et de la méthode employée pour les instancier est donnée dans la Table 1.
3.2 Génération du fichier XML
L’algorithme de génération du fichier XML (Fig. 10) exploite la DTD de la Figure 6. Son
principe est de parcourir la DTD, de lire les éléments qu’elle décrit et de les écrire à la volée
dans le document XML de sortie avec la valeur associée extraite dans la phase précédente.
Lorsqu’une ligne de la DTD est lue, l’élément courant auquel nous nous referons est celui qui
est décrit, par exemple TEXT dans la ligne< !ELEMENT TEXT (NB_CHAR, NB_LINES,
(PLAIN_TEXT| TAGGED_TEXT))>. Nous supposons également que les sous-élément XML
sont définis dans le même ordre que dans leur déclaration dans leur élément parent. Les
valeurs manquantes sont actuellement traitées par l’insertion d’un élément vide, mais d’autres
stratégies pourrait être employées pour résoudre ce problème (manuelles ou automatiques).
Actuellement, notre prototype traite les textes, les images et les données multimédia. Les
figures 11 et 12 illustrent comment les données multiformes (ici, une image et un texte balisé
en SGML) sont transformées suivant notre approche.
Attributs
NAME
DATE
SOURCE
Classe
COMPLEX_OBJECT
13
Méthode d’obtention
getname( )
système
Manuelle
Remarques
NAME_SD
TYPE
SIZE
LOCATION
LANGUAGE
KEYWORD
CREATION DATE
NB_CHAR
NB_LINES
CONTENT
URL
ATT_NAME
DOMAIN
VALUE
FORMAT
RESOLUTION
LENGTH
WIDTH
DURATION
SPEED
SUBDOCUMENT
TEXT
TAGGED TEXT
LINK
RELATIONAL_VIEW
IMAGE
getname( )
Manuelle
GetSize( )
GetPath( )
Algo
Manuelle
système
Algo
Algo
Algo
Algo
JDBC
JDBC
JDBC
Extension(getname( ) )
Non implémenté
Non implémenté
Non implémenté
Non implémenté
Non implémenté
Non implémenté
Finsi
Finpour
Sinon
Ecrire tag fin élément // fermer élément composé
Finsi
Finfaire
getPixelSize( )
getHeigth( )
getWidth( )
FIN
Fig. 10 : Algorithme de génération d’un document XML
Non implémenté
Non implémenté
TEMPORAL
// si sous-élément n’appartient pas à une sélection
du type (PLAIN_TEXT | TAGGED_TEXT)
Empiler sous-élément
Sinon //nouvelle ligne
Si (sous-élément est le type choisi )alors
// si type de document dans la DTD correspond
au type de document fourni par l’utilisateur
TEXT, IMAGE…)
Empiler sous-élément
Finsi
Finsi
Finpour
image
Modèle XML
<?XML version=1.0?>
<!DOCTYPE MultiformData SYSTEM "mlfd.dtd">
Table 1 : Méthodes d’obtention des attributs
procédure générer_fichier_xml( )
Début
// Initialisation
lire ligne DTD
Empiler élément racine
//Boucle principale
Tant que pile_pleine( )
faire
dépiler élément
se positionner sur la description de l’élément courant
Tant que élément non trouvé dans la DTD et non EOF(DTD)
faire
lire ligne DTD
Fin faire
Si (élément trouvé) alors
Pour chaque valeur de l’élément faire //pour les éléments de
cardinalité + ou *
Si (élément est atomique) alors
Ecrire (début de tag élément ,valeur d’élément, fin de tag élément)
Sinon // élément composé
Ecrire (début de tag élément)
Empiler élément // Nécessaire pour écrire fin de tag élément)
Pour chaque sous-élément (en ordre inverse) faire
Si (sous-élément n’appartient pas à une sélection) alors
14
Mots clés de l’utilisateur :
noir, blanc et ciseaux
< COMPLEX_OBJECT>
<NAME> ciseaux_image </NAME>
<DATE> 15/06/2001</DATE>
<SOURCE> locale</SOURCE>
<SUBDOCUMENT>
<SUB_NAME>ciseaux </SUB_NAME>
<TYPE> image </TYPE>
<SIZE> 6.206</SIZE>
<LOCATION> ciseaux.bmp </LOCATION>
<LANGUAGE/>
<KEYWORD>noir</KEYWORD>
<KEYWORD>blanc</KEYWORD>
<KEYWORD>ciseaux</KEYWORD>
< IMAGE>
<COMPRESSION> pas de compression</COMPRESSION>
<FORMAT>bmp </FORMAT>
<RESOLUTION> 100 dpi</RESOLUTION>
<LENGTH>192 </LENGTH>
<WIDTH> 256</WIDTH>
<IMAGE>
</SUBDOCUMENT>
</COMPLEX_OBJECT>
Fig. 11 : Transformation d’une image en un document XML
15
Document SGML
Modèle XML
<!DOCTYPE lewis SYSTEM "lewis.dtd">
<REUTERS TOPICS="YES"
LEWISSPLIT="TRAIN"
CGISPLIT="TRAINING-SET" OLDID="12509"
NEWID="326">
<DATE>2-MAR-1987 06:41:06.17</DATE>
<PLACES><D>france</D></PLACES>
<COMPANIES>SNCF</COMPANIES>
<TEXT>
<TITLE>SNCF ISSUING THREE BILLION
FRANC
DOMESTIC BOND</TITLE>
<DATELINE>PARIS, March 2</DATELINE>
<BODY>The French state railway company, the
Ste Nationale des Chemins de Fer Francaise
(SNCF), is issuing a three billion French
franc domestic bond in two tranches, the
bond issuing committee said. Details of
the issue will be announced later and it
will be listed in the Official Bulletin
(BALO) of March 9.
The issue will be co-led by Banque Nationale
de Paris, Caisse Nationale de Credit Agricole
and the Societe Marseillaise de Credit.
REUTER</BODY> </TEXT>
</REUTERS>
<?XML version=1.0?>
<!DOCTYPE MultiformData SYSTEM
"mlfd.dtd">
<COMPLEX_OBJECT>
<NAME>Reuters Press Release</NAME>
<DATE>May 15, 2001</DATE>
<SOURCE>Reuters</SOURCE>
<SUBDOCUMENT>
<NAME>SGMLdoc</NAME>
<TYPE>SGML</TYPE>
<SIZE>820 Bytes</SIZE>
<LOCATION>SGMLfile.sgml</LOCATION>
<LANGUAGE>English</LANGUAGE>
<KEYWORD>France</KEYWORD>
<KEYWORD>SNCF</KEYWORD>
<TEXT>
<NB_CHAR>790</NB_CHAR>
<NB_LINES>12</NB_LINES>
<TAGGED_TEXT>
<CONTENT>The document could be reproduced
here as a CDATA.</CONTENT>
</TAGGED_TEXT>
</TEXT>
</SUBDOCUMENT>
</COMPLEX_OBJECT>
Fig. 12 : Exemple de modèle logique pour un texte balisé
CHAPITRE 3
Discussion
1. Modèle conceptuel
Nous avons conçu un modèle conceptuel UML représentant toute donnée multiforme en un
objet complexe composé d’un ou de plusieurs sous documents de types variés : texte, image,
vidéo, vue relationnelle. Pour traduire ce modèle conceptuel en un modèle logique, nous
avons utilisé XML dans la perspective de stocker les données multiformes dans des tables
relationnelles ou relationnelles-objet ou natives XML. La souplesse et la puissance de XML
permettent de décrire aisément les données multiformes considérées comme des documents.
La DTD représente une véritable grammaire traduisant les données et les méta données du
document. Ces dernières sont utiles lors du stockage des documents XML dans une base de
données ou lors de leur intégration dans un entrepôt de données. Cependant la diversité des
types des données multiformes nécessite un typage fort et varié démontrant ainsi la limite de
l’usage des DTD actuelles. Or la norme XML Schema [CHA01] introduit des notions
supplémentaires comme l’héritage entre éléments et un typage fort des éléments (entier,
vecteur, son…). XML Schema est appelé à remplacer la DTD à court terme.
Nous envisageons de remplacer la DTD actuelle de notre modèle par un XML Schema nous
permettant de mieux exploiter la notion d’héritage véhiculée par notre modèle conceptuel
UML qui va nous permettre de traduire plus facilement notre modèle conceptuel (diagramme
de classes UML) en un schéma XML. D’autre part, nous pourrions recourir à un typage varié
des éléments nécessaires à l’instanciation du contenu des balises.
Par ailleurs, nous pourrions également tirer avantage de la méthode XMI [OMG99] qui
permet de traduire un modèle UML en XML Schema. Notons que dans notre cas nous avons
opté pour une DTD du fait que la traduction du modèle UML en document XML nécessite
une simple méthode procédurale pour la réaliser.
2. Implémentation
2.1 Traitement des modalités manquantes
Actuellement, notre prototype est capable de traiter des textes non balisés, des images et des
vidéos. Afin de traiter tout type de donnée multiforme nous envisageons d’étendre ce
prototype pour reconnaître les types « vue relationnelle » et « texte balisé ». Pour le type
« vue relationnelle » nous sommes amenés soit à stocker le résultat de la requête (table
relationnelle) dans le document XML correspondant soit à donner une référence vers la table
qui contient le résultat de la requête. Concernant le type « texte balisé », un découpage de ce
dernier en types simples (texte, image, vidéo,…) peut nous aider à le manipuler et à le
stocker.
Par ailleurs, le type de données « multimédia » nécessite également plus d’attention. Par
exemple, les seuls attributs vitesse et durée ne permettent pas d’extraire des connaissances à
partir du type de données vidéo. Il serait intéressant de s’appuyer sur la norme MPEG7
[MAR99] qui introduit des éléments concernant le découpage d’une vidéo en scènes. Nous
16
17
pourrions donc bénéficier de nouveaux attributs caractérisant les vidéos et qui peuvent être
pertinents pour une future analyse.
titres et les sous titres du document texte) et des résultats plus intéressants lors de l’application
des algorithmes d’apprentissage (Fig. 13 et 14).
2.2 Traitement des valeurs manquantes
TITRE
Dans notre algorithme, les valeurs d’attributs qui ne sont pas disponibles sont associées à un
élément vide dans le document XML de sortie. L’utilisation de techniques de data mining
(text mining, par exemple) peut nous aider à évaluer la valeur de ces attributs. Les algorithmes
de classification (clustering) permettent, en travaillant sur une base de documents tests,
d’extraire des connaissances permettant de prédire des valeurs probables pour les attributs
manquants. Nous envisageons intégrer ces algorithmes de data mining dans notre algorithme
afin d’obtenir des documents XML qui soient les plus complets possible et qui permettent une
analyse ultérieure la plus pertinente possible. 2.3 Utilisation des bibliothèques XML de Java
Actuellement, notre algorithme de génération procède à l’écriture de balises dans un
document texte (auquel on donne une extension « .xml ») pour fournir en sortie un document
XML. Notre algorithme ne profite donc pas de la structure interne du document XML
(arborescence d’éléments). Il serait intéressant d’utiliser des bibliothèques Java (Document
Object Modelisation) qui reconnaissent le type de données XML (Fig. 13) et permettent de
manipuler un document XML en tant qu’objet. Cette modélisation objet du document XML
va permettre d’instancier le contenu des balises en accédant aux feuilles et aux racines de
l’objet XML.
class DomDocument
properties:
version
encoding
standalone
type
methods:
root()
children()
add_root( $node )
dtd()
dumpmem()
class DomNode
properties:
name
content
type
methods:
lastchild()
children()
parent()
new_child($name,$content )
getattr( $name )
setattr( $name,$value )
attributes()
Modélisation DOM d’un
document XML
Modélisation DOM d’un nœud dans
un document XML
Fig. 13 : Classes Domdocument et DomNode de la bibliothèque DOM de Java
2.4 Amélioration du traitement du texte
Titre1
1-Type de clavier
Azerty blablablablabla
Qwerty blablablablabla
1-2 Codes
ASCII blablablablabla
UTF-8 blablablablabla
…
2-Ecrans
17 pouces blablablabla
21pouces blablablablabl
Transformation
d’un document
texte en un
document XML
Fichier PC.txt
Fichier Pctext.xml
Fig. 13 : Transformation d’un document texte en un document XML
Mot clé
Type de clavier
Référence
PC.txt
Doc1
Codes
PC.txt
Doc2
Ecrans
PC.txt
Doc3
Fig. 14 : Indexation d’un document XML
Pour le type de données texte, notre algorithme n’extrait que le nombre de lignes et le nombre
de caractères, alors qu’il peut bien extraire des mots significatifs qui peuvent servir d’index.
Pour cela, il serait plus intéressent de transformer un document texte en un document XML
dont les balises représentent les titres et les sous titres de notre texte d’entrée. Ainsi nous
pourrions indexer les documents XML par les balises qui sont dans ce cas significatives (les
18
<?xml version=«1.0»?>
<!DOCTYPE multiformData
SYSTEM « mlfd.dtd »>
<TITRE>
<Titre1>
<Type de clavier>
Azerty blablablablabla
Qwerty blablabablabla
<Codes >
ASCII blablablablabla
UTF-8 blablablablabla
</Codes >
…
</Type de clavier>
<Ecrans>
17 pouces blablablabla
21pouces blablablabla
</Ecrans>
</Titre1>
…
</ TITRE>
19
Conclusions et Perspectives
Références
1. Bilan
Nous avons conçu un modèle conceptuel d’un objet complexe qui généralise les différentes
données multiformes présentes sur le Web qui sont intéressantes à intégrer dans un entrepôt
de données en tant que sources externes. Notre modèle permet l’unification de ces différentes
données dans un cadre unique à des fins de stockage, mais aussi, et c’est le plus important,
pour préparer la phase d’analyse. Les données doivent en effet être formatées de façon
appropriée avant que l’on puisse leur appliquer des techniques OLAP ou de fouille de
données.
Notre modèle conceptuel UML a ensuite été directement traduit en une DTD XML et
instancié en document XML.Nous envisageons ces deux éléments comme une partie d’un
modèle logique dans notre processus classique d’analyse. XML est un format de choix pour à
la fois stocker et décrire les données. La DTD représente en effet les métadonnées à importer
dans un entrepôt. XML est également très intéressent en raison de sa souplesse et de son
extensibilité. Un document XML peut de surcroît être directement intégré dans une base de
données conventionnelle si une meilleure structuration ou une plus grande efficacité
d’interrogation sont nécessaires à des fins d’analyse.
Ces travaux ont donné lieu à une publication [MIN01].
[ABI01] S. Abiteboul, “A Dynamic Warehouse for the XML data of the Web”, INRIA et
Xyleme SA, http://www-rocq.inria.fr/verso/xyleme/XylemeAll/sld001.htm, janvier 2001.
[AND00] R. Anderson, M. Birbeck, M. Kay, S. Livingstone, B. Loesgen, D. Martin, S. Mohr,
N. Ozu, B. Peat, J. Pinnock, P. Stark, K. Williams, “Professional XML Databases”, Wrox
Press, 2000.
[AND98] P. Andries, S. Cuny, F. Yergeau, “Langage de balisage extensible (XML) 1.0”,
Recommandation du W3C, http://babel.alis.com/web_ml/xml/REC-xml.fr.html, février 1998.
[BER01] E. Bertino, B. Catania, G.P. Zarri, “Intelligent Database Systems”, Addison Wesley,
2001.
[BOO99] G. Booch, M. Christerson, M. Fuuchs, J. Koistinen, “UML for XML schema
mapping specification”, Technical report, Rational Software, 1999.
[BUS99] S. Busse, R. Kutsche, U. Leser, H. Weber, “Federated Information systems:
Concepts, Terminology and Architectures”, Forschungsberichte des Fachbereichs Informatik
99(9), 1999.
[CHA01] G. Chazalon, XML Schema, W3C, http://www.W3.org/TR/xmlschema-0/, mai
2001.
2. Perspectives
Les perspectives ouvertes par ce travail sont de deux ordres.
Premièrement, notre objectif est de stocker des données multiformes dans un entrepôt de
données. Il s’agit donc d’intégrer les documents produits par notre application dans un
entrepôt. En supposant que le « mapping » d’un document XML dans une base de données
relationnelle ou relationnelle-objet ne pose pas de problème en utilisant les techniques
présentées dans [AND00], notre formalisation XML demeure néanmoins un premier niveau
de modélisation logique. Le second niveau est constitué d’une représentation
multidimensionnelle des données (avec faits et dimensions) qui permettrait l’entreposage de
nos données multiformes. Il sera nécessaire de le mettre en œuvre pour atteindre notre
objectif.
Deuxièmement, nous n’envisageons pas la fouille de données comme un outil uniquement
frontal. Nous pensons qu’intégrer des données multiformes dans un entrepôt de données
nécessite plus que ce que fournit un ETL classique. Nous voulons introduire de « l’intelligence »
dans la préparation des données en utilisant des techniques de fouille de données pour extraire
des informations utiles au stockage (indexation), à l’analyse multidimensionnelle ou à la fouille de
données elle-même. Par exemple, nous pourrions automatiquement construire une liste de motsclés pour un document donné, que ce soit un texte ou un objet multimédia, ou encore extraire
des caractéristiques comme les distributions de couleurs, de texture ou de luminosité d’une image.
Le pré-traitement de ces caractéristiques ferait gagner du temps lors des phases d’analyses
ultérieures. Des techniques de classification pourraient également être utilisées comme de
nouveaux types d’agrégation des données multiformes dans un contexte d’analyse
multidimensionnelle.
20
[CHA97] S. Chaudhuri, U. Dayal, “An overview of
technology”, ACM SIGMOD, 1997.
data warehousing and OLAP
[GAR99a] G. Gardarin, “Internet et bases de données”, Eyrolles, 1999.
[GAR99b] G. Gardarin, F. Sha, T.D. Ngoc, “XML-based components for federating multiple
heterogeneous data sources”, LNCS 1728, 506–519, 1999.
C.
Gray,
“XML
Information
Server”,
Software
AG,
[GRA99]
http://www.softwareag.com/tamino/references/Butler_about_tamino.htm, novembre 1999.
Ixiasoft,
IXIASOFT
white
paper,
[IXI00]
http://www.ixiasoft.com/products/textmlserver.asp, décembre 2000.
IXIASOFT,
[KAP00] G. Kappel, E. Kapsammer, W. Retschitzegger, “X-Ray – Towards Integrating XML
and Relational Database Systems”, 19th International Conference on Conceptual Modeling,
339–353, 2000.
[KIM00a] R. Kimball, L. Reeves, M.Ross, W.Thornthwaite “Concevoir et Déployer un Data
Warehouse”, Edition Eyrolles, 2000.
[MAR99] J.M. Martínez, “Overview of the MPEG-7 Standard”, International Organisation
for Standarisation, http://www.cselt.stet.it/mpeg/standards/mpeg-7/mpeg-7.htm , 2001.
21
[MCH97] J. McHugh, S. Abiteboul, R. Goldman, D. Quass, J. Widom, “Lore: A Database
Management System for Semistructured Data”, SIGMOD Record 26(3), 54–66, septembre
1997.
[MIN01] S. Miniaoui, J. Darmont, O. Boussaid, "Web data modeling for integration in data
warehouses", International Workshop on Multimedia Data and Document Engineering
(MDDE 01), Lyon, France, juillet 2001.
[OMG99] Object Management Group, “XML Metadata Interchange (XMI) Version 1.1”,
OMG Document, OMG, octobre 1999.
Bibliographie
[ABI97] S. Abiteboul, “Querying Semistructured Data”, ICDT, 1-18, 1997.
[DEU99] A. Deutch, M. Fernadez, D.Suciu, “Storing Semistructured Data with STORED”,
SIGMOD, 431-442, 1999.
[RAK95] T.C. Rakow, E.J. Neuhold, M. Löhr, “Multimedia Database Systems – The Notions
and the Issues”, Datenbanksysteme in Büro, Technik und Wissenschaft BTW, GI-Fachtagung,
Dresden, 1–29, 1995.
[DYR99] C. E. Dyreson, M. H. Böhlen, C. S. Jensen, “Capturing and querying multiple
aspects of semistructured data”, VLDB, 1999.
[WU97] M.C. Wu, A.P.Buchmann, “Research Issue in Data warehousing”, BTW, mars 1997.
[GAR01] G. Gardarin, “Les Data Webhouses arrivent”, Laboratoire PriSM et e-XMLMedia,
2001.
[XHI01] Xhive, “X-Hive/DB 1.1 Product Fact Sheet”, Xhive white paper, Xhive,
http://www.xhive.com, juin 2001.
[HUG99] J. McHugh, J. Widom, “Query optimisation for XML”, VLDB, 315-326, 1999.
[KIM00b] R. Kimball, R. Mertz, “The Data Webhouse: Building the Web-enabled Data
Warehouse”, John Wiley & Sons, 2000.
[SHA99] J. Shanmugasundaram, K. Tufte, G. He, C. Zhang, D. DeWitt, J. Naughton,
“Relational Databases for Querying XML Documents: Limitations and Opportunities”,
VLDB 1999.
22
23