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 Etat de l’art........................................................................3
1. 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
Références................................................................................................................................21
Bibliographie............................................................................................................................23
1
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.
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).

2
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.
3
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] :
!" 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).

4
[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.
Fig. 1 : Architecture des bases de données fédérées
1.2 Notre approche
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.
1.2.1 Les bases de données documentaires
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 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).
BD
JDBC
fichier
Connecteurs aux données
WEB
Mediateur1 Mediateur3 Mediateur2
Niveau Présentation
Niveau Médiation
Niveau Adaptation
Sources de données
5
b) Signature
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).
c) Matrice de fréquence relative
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).
Mot clé Fréquence Lien
Base
Données
Relationnelle
3
2
2
5
7
5
Doc1
Doc2
Doc3
Doc4
Doc3
Doc2
Fig. 2 : Structure d’une liste inversée
u
ni
o
n
Un texte à
analyser en un
ensemble de
mots
significatifs
Texte
Analyser
Ensemble
mot
significatif
0000000010
0000000100
0000001000
0000010000
0000100000
0000111110
analyse hachage
Signature
du document D1
D1
Fig. 3 : Structure d’une signature de document