Intégration de données en provenance du web
Transcription
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