Intelligences Journal revue en intelligence économique
[English version]

Analyse multidimensionnelle des documents multistructures

Karim Djemal, Chantal Soulé-Dupuy et Nathalie Vallès-Parlangeau

Résumé

Avec l’émergence de la numérisation, le besoin d’outils de traitement automatique des documents s’est rapidement fait sentir par les entreprises. Au-delà de la gestion du document numérique se pose le problème de l’accès au contenu et de l’exploitation de ce contenu. Nous présentons dans ce papier un système décisionnel documentaire, offrant aux décideurs de ces entreprises une vision détaillée du document au sein de collections plus larges. Ce système s’appuie sur la structure des documents pour élaborer des analyses multidimensionnelles ; où éléments structurels et contenu sont transposés en sujet d’analyse (fait) et en axes d’analyse (dimensions). Or, un même document peut avoir plusieurs descriptions et donc plusieurs décompositions et plusieurs structures selon plusieurs contextes. Cette richesse de description doit être prise en compte dans la démarche d’analyse multidimensionnelle, permettant à la fois d’élargir les possibilités d’analyse et d’affiner les résultats. L’objectif précis de cet article est de présenter une démarche d’analyse multidimensionnelle des documents multistructurés. En se basant sur le modèle « MVDM », cinq types d’analyse sont envisageables à savoir analyse : par structure générique, par vue générique, par structure spécifique, par vue spécifique et par nœud générique. Ceci permet aux décideurs de plus amples possibilités d’analyse.

Mots-clés

système d’aide à la décision, analyse multidimensionnelle, documents multistructurés, modèle de documents

Texte intégral

Quelle que soit la nature des documents circulant dans l’entreprise, l’information qui leur est associée ainsi que leur contenu sont utilisés par les décideurs des entreprises. Les systèmes d’aide à la décision leur permettent de synthétiser ces informations afin de les assister dans leur tâche. La plupart des documents sont des documents numériques de nature très différente : compte-rendu de réunion, facture, article de presse,… De plus, un même document peut avoir plusieurs descriptions, donc plusieurs décompositions et par voie de conséquence plusieurs structures selon différents contextes. La prise en compte de cette multistructuralité a un double intérêt. Il permet d’élargir le champ d’exploitation du document en exploitant les informations des différentes structures. Il permet aussi d’affiner la recherche. En effet, la combinaison de contraintes sur plusieurs structures assure un résultat plus précis et une meilleure localisation des fragments documentaires pertinents. Les approches de la littérature traitant ces problématiques n’exploitent ces richesses que dans des processus d’interrogations de documents.

Dans cet article nous nous intéressons aux systèmes décisionnels. Dans ce cadre, les approches existantes ne considèrent pas le caractère multistructurel des documents. Ils ne considèrent qu’une seule structure, celle généralement donnée par la grammaire permettant de décrire le document. (Khrouf & Soulé-Dupuy, 2004) définissent une structure générique qui représente des documents structurellement similaires. Cette structure générique facilite l’accès au contenu des documents qui en dépendent afin d’assurer la restitution multidimensionnelle. Dans le même objectif, celui de l’accès au contenu des documents à structure similaire, (Golfarelli, Rizzi & Vrdoljak, 2001) et (Pokorný, 2001) se basent sur la DTD des documents XML lorsque (Vrdoljak, Banek & Skocir, 2006) utilise le schéma de ces documents.

Nous proposons dans cet article une démarche d’analyse multidimensionnelle permettant d’exploiter le caractère multistructurel des documents.

Dans un premier temps, après un état de l’art, nous présentons le modèle MVDM permettant de représenter des documents multistructurés. Ce modèle est caractérisé par deux niveaux : spécifique et générique. Le niveau spécifique représente les caractéristiques propres à un document multistructuré alors que le niveau générique représente une classe de documents. En se basant sur ce niveau générique, nous élaborons une démarche de restitution multidimensionnelle impliquant plusieurs structures d’un même document.

Etat de l’art

La problématique de la multistructuralité des documents a attiré l’attention de plusieurs chercheurs ces dernières années. La gestion de cette multistructuralité engendre différents axes de recherches liées à la modélisation des documents au travers de leurs structures connexes et concourantes, à leur stockage et à leur exploitation, et notamment à leur recherche et à leur restitution.

Pour résoudre les problèmes de représentation et de stockage, deux catégories d’approches ont été proposées :

(i) La première catégorie s’appuie sur des solutions d’ordre syntaxique. On peut distinguer deux catégories de travaux : ceux qui proposent d’étendre la syntaxe de XML ou SGML afin d’en garder la compatibilité (CONCUR (Fernandez, Malhotra, Marsh, Nagy & Walsh, 2007), XCONCUR (Hilbert, Schonefeld & Witt, 2005) et TEI (Sperberg-McQueen & Burnard, 2001)) et d’autres qui proposent de nouvelles syntaxes (LMNL (Tennison & Piez, 2002), MECS (Huitfeldt, 1998) et TexMECS (Huitfeldt, 2001)).Le document doit être d’une part, bien formé par rapport à chacune de ses structures et d’autre part, compatible avec les applications qui traitent les documents XML/SGML. Le cadre formel imposé par la définition de syntaxes présente l’avantage de structurer les documents de manière précise, concise et sans ambiguïté. En contrepartie, la difficulté est double : la représentation simultanée de l’ensemble des structures rend la grammaire difficilement lisible pour les utilisateurs et complexifie la définition des parseurs pour l’interrogation.

(ii) La deuxième catégorie d’approches regroupe les propositions se basant sur des modèles. Une première solution (Navarro, 1995) et (Chatti, Calabretto & Pinon, 2004) préconise l’utilisation d’une structure pivot autour de laquelle sont rattachées les différentes structures du document. Une deuxième solution consiste à modéliser les structures indépendamment les unes des autres (Mechkour, 1995), (Bruno & Murisasco, 2006), (Sperberg-McQueen & Huitfeldt, 2000) et (Lemaitre, 2006). Ces modélisations se basent sur une représentation en arbre ou en graphe des structures. Cela offre une vision concise et précise de sa composition en terme de nœuds et de structures. L’explicitation des structures permet une exploitation des documents plus aisée qu’avec les parseurs.

A notre connaissance, l’exploitation se limite à des interrogations. Compte tenu de la complexité de certains modèles de représentation, l’interrogation des structures multiples nécessite des traitements spécifiques : ces méthodes vont d’une extension de XQuery à la proposition de nouveaux mécanismes d’interrogation. (Bruno & Murisasco, 2006) proposent d’ajouter des fonctions et des opérateurs aux langages d’interrogations XQuery et XPath. Ils choisissent d’étendre la sémantique du filtre de XQuery pour interroger les structures concurrentes. Les documents MECS et TexMECS seront gérés au travers des structures GODDAG (Sperberg-McQueen & Huitfeldt, 2000). Ces structures sont définies par des graphes de nœuds orientés et acycliques. Pour gérer le chevauchement entre les différentes structures concurrentes, chaque nœud fils peut avoir plusieurs nœuds parents. Pour générer les structures GODDAG, (Dekhtyar & Iacob, 2005) ont élaboré un compilateur qui traduit les documents multistructurés représentés sous forme de DXD (Document XML distribué : ensemble de documents XML qui partagent la même racine et le même contenu). Toutefois, l’exploitation des documents multistructurés représentés selon le modèle GODDAG nécessite le développement de langage dédié. (Khrouf & Soulé-Dupuy, 2004) propose d’étendre le modèle MXD de XQuery et XPath (Fernandez et al, 2007) pour interroger des structures non arborescentes (GODDAG). Cette approche se base sur l’utilisation des « nœuds retard ». Un nœud retard est une représentation virtuelle d’une partie des nœuds selon une arborescence particulière. Cette représentation est décrite suivant une expression XQuery.

Modèle de documents multistructurés

En s’inscrivant dans la deuxième catégorie d’approche, nous formalisons une modélisation basée sur une technique de fragmentation « logique » qui nous permet de décrire séparément les différentes entités qui forment un document ainsi que leurs relations (éléments, attributs d’éléments, métadonnées et attributs de métadonnées).Cette fragmentation est dite logique du fait que le contenu du document n’est pas réellement fragmenté. Il est stocké sous forme d’un bloc de données et référencé par les différents nœuds et par conséquent par les différentes structures. Ainsi, un nœud et un contenu sont associés par un index qui détermine le début et la fin de chaque fragment de contenu. Cette indexation permet la gestion d’un contenu commun autour duquel s’articulent plusieurs structures. Ceci nous permet d’une part d’éviter la redondance de stockage et d’autre part d’assurer la gestion de recouvrement entre les nœuds de structures concurrentes.

Un document multistructuré est représenté par une structure spécifique. Cette dernière inclut l’ensemble des nœuds du document. Chacune des structures du document est encapsulée dans une vue spécifique. L’ensemble des vues d’un même document sont agrégées, via le partage de nœuds, à la structure spécifique de ce document.

L’originalité de notre modèle réside dans la définition d’un niveau générique. Ce niveau peut jouer le rôle d’un schéma qui définit la grammaire d’un document, mais aussi il assure la classification de documents. En effet, notre modélisation permet de regrouper, sous forme de classes, les documents ayant des structures similaires tout en préservant les informations spécifiques comme le contenu de ces documents. Ainsi, chaque structure (resp. vue) générique représente une collection de structures (resp. vue) spécifiques. Un exemple de deux vues génériques est illustré par laFigure 5.

Le modèle « MVDM » (Multi View Document Model) (Cf.Figure 1) (Djemal, Soulé-Dupuy et Valles-Parlangeau, 2008) intègre donc deux niveaux :

  • le niveau spécifique est décrit par les métaclasses : « StrSpé », « NœudSpé », « RelationSpé » et « VueSpé ». Il contient également deux autres métaclasses propres à un document : la métaclasse « Document » qui désigne un document spécifique et la métaclasse « Déclaration » qui permet de garder l’information concernant les caractéristiques des documents telles que par exemple leurs versions. Dans le niveau spécifique, nous détaillons aussi les types de nœuds spécifiques afin de représenter leurs propres caractéristiques. Une métaclasse est conçue pour chaque type ;

  • le niveau générique est décrit par les métaclasses : « StrGén », « NœudGén », « RelationGén » et « VueGén ». La structure générique « StrGén » représente la structure globale d’une collection de documents. Elle est définie par un ensemble de nœuds génériques « NœudGén ». Les relations génériques « RelationGén » caractérisent le lien qui existe entre-deux nœuds génériques selon une vue particulière. Une vue générique « VueGén » référence une sous-structure de la structure générique. Chaque sous-structure désigne une représentation particulière d’une classe de documents.

Agrandir Image1

Figure 1 : Le modèle « MVDM » selon UML.

Analyse Multidimensionnelle

Nous décrivons dans cette section, la technique d’analyse multidimensionnelle que nous souhaitons appliquer aux informations documentaires intégrées dans une base de documents organisée selon le modèle « MVDM ». Cette technique d’analyse multidimensionnelle consiste en une structuration des données selon plusieurs axes d’analyse pouvant représenter des notions variées. Ces données peuvent être, selon le modèle proposé, des éléments spécifiques, des attributs d’éléments spécifiques, des métadonnées spécifiques ou des attributs de métadonnées spécifiques.

Afin d’analyser d’une manière multidimensionnelle le contenu de la base de documents, une première opération consiste à construire et alimenter des magasins. Il s’agit d’un extrait d’informations organisé de manière adéquate à des fins décisionnelles. Les données extraites sont alors adaptées à un usage particulier.

Dans le cadre de nos travaux, nous avons adopté les tables multidimensionnelles afin de visualiser le contenu des magasins générés (Gyssens & Lakshmanan, 1997) puisque la représentation sous forme de tableau est la vision la plus simple et la plus intuitive pour l’utilisateur.

La démarche proposée pour restituer les informations contenues dans la base d’une manière multidimensionnelle se base sur l’ensemble des structures et des vues génériques représentées dans le modèle MVDM. Ces éléments génériques sont utilisés comme index pour faciliter l’accès aux éléments spécifiques. Ceci nous permet d’avoir plusieurs points d’accès au contenu des documents. La démarche proposée peut-être schématisée comme l’indique la Figure 2. Ce processus se compose de trois phases :

  • construction des schémas des magasins : cette phase nécessite l’intervention de l’utilisateur pour préciser le sujet (fait) et les axes d’analyse (dimensions) ;

  • génération des magasins de documents : au cours de cette phase, le magasin doit être généré de manière automatique et transparente vis-à-vis de l’utilisateur. Ainsi, il est nécessaire d’accéder à la base afin de récupérer les valeurs et instancier les magasins ;

  • visualisation des tables multidimensionnelles : une fois le magasin construit, cette phase permet de visualiser automatiquement son contenu selon une table multidimensionnelle.

Agrandir Image2

Figure 2 : Démarche d’analyse multidimensionnelle.

Démarche de construction des schémas des magasins

La première phase du processus d’analyse multidimensionnelle consiste à générer, à partir de la base, le schéma du magasin de documents désiré.

La construction des schémas des magasins (Cf. Figure 3) se compose de quatre étapes, à savoir : 1. choix du type d’analyse, 2. sélection des composants d’analyse (Fait/Dimension), 3.filtrage et 4. visualisation du schéma.

Agrandir Image3

Figure 3 : Démarche de construction des schémas des magasins.

1. La première étape doit permettre à l’utilisateur de choisir un type d’analyse. En se basant sur le modèle « MVDM », cinq types d’analyse sont envisageables :

  • analyse par structure générique : cette analyse s’applique sur un ensemble de documents rattachés à une même structure générique. Dans ce cas, les composantes d’analyse seront choisies indépendamment des vues associées,

  • analyse par vue générique : cette analyse admet le même principe que la précédente. Cependant, les analyses se focalisent sur une seule vue associée à une structure générique d’un ensemble de documents,

  • analyse par nœuds génériques : les deux premières propositions peuvent être, dans certains cas restrictives puisqu’il est possible qu’un nœud générique soit utilisé par plusieurs structures génériques. Cette proposition consiste alors à analyser les documents par nœuds génériques pouvant appartenir à plusieurs structures génériques,

  • analyse par structure spécifique : ce quatrième type consiste à analyser le contenu d’un et d’un seul document en se basant sur sa structure spécifique. A cette fin, il est nécessaire de se référer à sa structure générique afin de déterminer son schéma,

  • analyse par vue spécifique : ce dernier type consiste à analyser le contenu d’un document en se focalisant sur une et une seule vue spécifique.

Ces différents types permettront à l’utilisateur de se focaliser sur une ou plusieurs structures, sur un domaine bien défini ou même sur un document, selon ses besoins d’analyse ;

2. Au cours de la deuxième étape, l’utilisateur doit sélectionner les composants d’analyse, à savoir un fait (sujet d’analyse) et ses dimensions (axes d’analyse). L’utilisateur doit indiquer aussi l’ordre des dimensions et la fonction d’agrégation pour la mesure (indicateur d’analyse) du fait (Compte, Somme, Maximum, Minimum, Moyenne, contenu). Dans le cas d’une analyse par nœuds génériques, la sélection de composants se fait au travers des listes, puisque ce type d’analyse nécessite l’utilisation de plusieurs arborescences. Pour les autres types d’analyse, la sélection de composants se fait à partir de la structure générique ou de la vue générique choisie au préalable par l’utilisateur ;

3. La troisième étape, celle de filtrage, doit permettre à l’utilisateur de sélectionner des valeurs précises afin d’affiner ses analyses. Nous distinguons deux types de filtrage :

  • pour une dimension, l’utilisateur doit choisir, parmi toutes ses valeurs, celles qu’il veut intégrer dans le magasin,

  • pour le fait, nous proposons deux types de filtre. Lorsque la valeur du fait est sous forme numérique, nous proposons un filtrage qui permet de fixer des critères de sélection, en utilisant des opérateurs classiques de comparaison arithmétique (<, >, =, <>, < =, > =). Pour les valeurs textuelles, nous proposons d’utiliser les techniques de filtrage par mots-clés éventuellement liés par les opérateurs logiques (+ : et, - : pas, | : ou).

4. La dernière étape, celle de visualisation, consiste à afficher à l’utilisateur le schéma du magasin de documents selon une représentation graphique afin d'illustrer ses choix d'analyse avant de générer les magasins qui sont la base des tables multidimensionnelles.

Démarche génération des magasins de documents

Cette phase consiste à générer le magasin d’une manière automatique afin de récupérer les informations de la base. Cette génération se déroule en deux étapes (Cf. Figure 4) à savoir : 1. génération d’une vue pour chaque composant d’analyse (que se soit dimension ou fait) et 2. jointure et regroupement des différentes vues générées lors de la première étape.

Agrandir Image4

Figure 4 :Démarche de génération de magasins.

Génération d’une vue pour chaque composant d’analyse

Pour chaque dimension, nous devons générer une vue. Les vues que nous manipulons dans cette section sont les vues utilisées dans les bases de données et non pas les vues modélisées dans le modèle « MVDM ». Une vue dans une base de données représente une synthèse d'une requête d'interrogation de la base. Ainsi, elle peut être considérée comme une table virtuelle définie par une requête.

Le nom de la vue crée aura la forme suivante : « Dim_n » ; où n désigne le numéro d’ordre de la dimension. Cette vue englobe également un bloc d’attributs « Anc_x » et un champ « Nœud ». Le nombre d'attributs « Anc_x » dépend du nombre de dimensions qui seront utilisées pour effectuer l’analyse multidimensionnelle. Ces attributs correspondent aux numéros (identifiants) des premiers ancêtres communs entre le paramètre en cours et chacun des autres paramètres. Le dernier champ « Nœud » de la vue correspond aux nœuds spécifiques qui héritent du nœud générique sélectionné comme paramètre d’analyse.

Pour le nœud jouant le rôle du fait, le système doit générer une vue dont le nom est « Fact », englobant aussi un bloc d'attribut, « Anc_x » et un champ « Nœud ».

D’autres contraintes doivent être ajoutées aux vues générées :

  • si le type d’analyse est par vue générique (resp. structure générique), tous les nœuds spécifiques doivent appartenir aux vues spécifiques (resp. structures spécifiques) des documents rattachés à la vue générique (resp. structure générique) choisie ;

  • si le type d’analyse est par vue spécifique (resp. structure spécifique), tous les nœuds spécifiques doivent appartenir uniquement à la vue spécifique (resp. la structure spécifique) du document choisi par l’utilisateur ;

  • si l’utilisateur exige des valeurs spécifiques pour une dimension ou pour un fait (opération de filtrage), des conditions doivent être ajoutées pour ne prendre en compte que ces valeurs.

Dans le cas d’une analyse par nœud générique, le système doit déterminer dans un premier temps, les structures génériques contenant tous les nœuds fixés comme composants d’analyse. Pour chaque structure générique déterminée, le système doit générer une vue selon l'approche que nous venons de détailler. Enfin, une opération d'union, entre les vues générées, sera établie.

La vue d’une dimension admet la forme générique suivante :

CREATE VIEW Dim_i (Doc, Anc_1, {Anc_2, Anc_3}, nœud) AS
SELECT n.Doc, n.Anc_1, {n.Anc_2, n.Anc_3}, n
FROM V1Dim_i n
{UNION …
UNION
SELECT n.Doc, n.Anc_1, {n.Anc_2, n.Anc_3}, n
FROM VmDim_i n} ;

Jointure et regroupement des différentes vues générées

Cette étape consiste à joindre et regrouper toutes les vues générées lors de l'étape précédente. Ainsi, une nouvelle vue est établie par une jointure sur les attributs « Anc_x » de toutes les vues créées. Nous rappelons qu’à ce niveau, nous manipulons encore que des nœuds spécifiques.

La nouvelle vue aura alors la forme suivante:

CREATE VIEW Jointure (nœud_d1, {nœud_d2, nœud_d3}, nœud_f) AS
SELECT d1.nœud, {d2.nœud, d3.nœud}, f.nœud
FROM Dim_1 d1, {Dim_2 d2, Dim_3 d3}, Fact f
WHERE d1.Anc_1 = f.Anc_1 {AND d1.Anc_2 = d2.Anc_2}
{AND d1.Anc_3 = d3.Anc_2} {AND d2.Anc_1 = f.Anc_2}
{AND d2.Anc_3 = d3.Anc_3} {AND d3.Anc_1 = f.Anc_3} ;

Une fois la vue jointure créée et avant d’appliquer la fonction d’agrégation choisie par l’utilisateur, il est nécessaire de transformer les nœuds par leur contenu tout en gérant les éventuels chevauchements de contenu. En effet, la définition de plusieurs structures sur un même contenu favorise le chevauchement de certaines parties de ce dernier. De ce fait, le système doit sauvegarder au préalable une liste « NœGénChe » pour chaque structure générique. Cette liste représente la liste des nœuds génériques représentant des nœuds spécifiques dont le contenu est susceptible d’être chevauché. Lors de la restitution du contenu, le système retient les valeurs des nœuds de type attribut (d’élément ou de métadonnée) et le contenu des nœuds de type élément ou métadonnée pour les différentes dimensions sélectionnées. Quant au fait, il est nécessaire de calculer le chevauchement de contenu entre les nœuds spécifiques qui le représente afin d’en retenir que la partie commune de ce contenu. Le calcul de chevauchement s’effectue entre tous les nœuds de type élément ou métadonnée qui appartiennent à une même ligne de la vue « Jointure » et qui figurent, eux ou un de leurs nœuds descendants, sur la liste « NœGénChe ». Les nœuds de type attribut (d’élément ou de métadonnée) seront pris en compte également dans le calcul de chevauchement. Ils seront représentés par leur nœud père.

Ces manipulations et en particulier la gestion de chevauchement engendrent la modification de contenu de certains nœuds retenus dans la vue « Jointure ». De ce fait, les contenus dont le chevauchement est gérés, seront stockées dans une nouvelle table « JointureT ». Cette table admet une structure qui ne diffère de celle de la vue « Jointure » que par la nature des éléments stockés. En effet, les éléments de type nœud se transforment en élément de type chaine de caractères afin de stocker le contenu ou les marques de début et de fin du contenu dans le cas des métadonnées.

Une fois la table « JointureT » est créée, il est nécessaire d’effectuer une opération de regroupement afin d’appliquer la fonction d’agrégation choisie par l’utilisateur tout en prenant en compte la fonction de filtrage imposée sur le fait. Cette dernière vue générée représente le contenu du magasin. Elle aura la forme suivante:

CREATE VIEW Vue (j.nœud_d1, {j.nœud_d2, j.nœud_d3}, j.nœud_f) AS
SELECT j.nœud_d1, {j.nœud_d2, j.nœud_d3,} Fonction(j.nœud_f)
FROM JointureT j
GROUP BY j.nœud_d1 {, j.nœud_d2, j.nœud_d3}
{HAVING Fonction(j.nœud_f)= X} {HAVING Fonction(j.nœud_f) > X}
{HAVING Fonction(j.nœud_f) < X} {HAVING Fonction(j.nœud_f) <> X}
{...} ;

Visualisation des tables multidimensionnelles

Une fois la dernière vue générée, son contenu sera affiché via plusieurs tables assez simples à manipuler et à interpréter. Ces tables permettent de mieux apprécier le contenu des magasins de documents. Elles organisent les données en les classant suivant les dimensions, déjà choisies par l’utilisateur. Ainsi, les colonnes représentent la première dimension, les lignes représentent la deuxième dimension et les plans représentent la troisième dimension. Alors que les valeurs des mesures des faits sont représentées à l’intérieur des tables sous forme d’interrelation entre les différentes valeurs des dimensions.

Etant donné que chaque plan de la table multidimensionnelle correspond à une seule valeur de la troisième dimension, le passage de la dernière vue générée par le système en une table multidimensionnelle se fait par génération de vues en effectuant une sélection sur chacune des valeurs de la troisième dimension. Chacune des nouvelles vues contient trois colonnes: (1) la première dimension, (2) la deuxième dimension et (3) le fait.

A partir de chacune de ces vues, le système doit:

  • récupérer toutes les valeurs possibles de la première dimension, ces valeurs seront affichées dans les colonnes du plan correspondant ;

  • récupérer toutes les valeurs possibles de la deuxième dimension, ces valeurs seront affichées dans les lignes du plan correspondant ;

  • restituer pour chaque couple (une colonne i et une ligne j) la mesure correspondante à partir de la troisième colonne de la vue (le fait). Cette mesure sera affichée dans la case correspondante (intersection entre i et j).

Exemple

Afin d’illustrer cette démarche de restitution multidimensionnelle des documents multistructurés, nous présentons un exemple d’analyse par structure générique. Nous considérons une structure générique « Séquence audio » (Cf. Figure 5). Cette structure générique est basée sur deux vues génériques : « locuteur » et « thème ». A partir de ces vues, nous choisissons trois dimensions : « NomL », « NomT » et « Séquence » ; et un fait : « Parole ».

Agrandir Image5

Figure 5 : Exemple de structure générique basée sur deux vues génériques.

Pour la première dimension « NomL », le système doit générer la vue suivante :

CREATE VIEW Dim_1 ("Doc", "Anc_1", "Anc_2", "Anc_3", "NomL") AS
SELECT n.sondoc.numdoc, r1.noeudpere.numns, r2.noeudpere.numns, r1.noeudpere.numns, ref(n)
From noeudspe n, relationspe r1, relationspe r2, relationspe r3
WHERE n.herite.nomng='NomL'
AND n.sondoc.appartient.nomsg='séquence_audio'
AND n.numns=r3.noeudfils.numns AND r3.herite.savuegen.nomvg='locuteur'
AND r3.noeudpere.numns= r1.noeudfils.numns AND r1.herite.savuegen.nomvg='locuteur'
AND r1.noeudpere.numns=r2.noeudfils.numns AND r2.herite.savuegen.nomvg='locuteur';

Pour la deuxième dimension « NomT », le système doit générer la vue suivante :

CREATE VIEW Dim_2 ("Doc", "Anc_1", "Anc_2", "Anc_3", "NomT") AS
SELECT n.sondoc.numdoc, r1.noeudpere.numns, r2.noeudpere.numns, r1.noeudpere.numns, ref(n)
From noeudspe n, relationspe r1, relationspe r2, relationspe r3
WHERE n.herite.nomng='NomT'
AND n.sondoc.appartient.nomsg='séquence_audio'
AND n.numns=r3.noeudfils.numns AND r3.herite.savuegen.nomvg='Thème'
AND r3.noeudpere.numns= r1.noeudfils.numns AND r1.herite.savuegen.nomvg='Thème'
AND r1.noeudpere.numns=r2.noeudfils.numns AND r2.herite.savuegen.nomvg='Thème';

Pour la troisième dimension « Séquence », le système doit générer la vue suivante :

CREATE VIEW Dim_3 ("Doc", "Anc_1", "Anc_2", "Anc_3", "Séquence") AS
SELECT n.sondoc.numdoc, n.numns, n.numns, n.numns, ref(n)
From noeudspe n,
WHERE n.herite.nomng='Séquence'
AND n.sondoc.appartient.nomsg ='séquence_audio' ;

Pour le fait « Parole », le système doit générer la vue suivante :

CREATE VIEW Fact ("Doc", "Anc_1", "Anc_2", "Anc_3", "Parole") AS
SELECT n.sondoc.numdoc, n.numns, n.numns, r1.noeudpere.numns, ref(n)
From noeudspe n, relationspe r1
WHERE n.herite.nomng='Séquence'
AND n.sondoc.appartient.nomsg='séquence_audio'
AND n.numns=r1.noeudfils.numns AND r1.herite.savuegen.nomvg='Thème';

Une fois ces quatre vues créées, le système génère une nouvelle vue « Jointure » :

CREATE VIEW Jointure ("NomL", "NomT", "Séquence", "Parole") AS
SELECT Dim_1.NomL, Dim_2.NomT, Dim_3.Séquence, Fact.Parole
From Dim_1, Dim_2, Dim_3, Fact
WHERE Dim_1.Anc_1= Dim_2.Anc_1 AND Dim_1.Anc_2= Dim_3.Anc_1
AND Dim1.Anc_3= Fact.Anc_1 AND Dim_2.Anc_2= Dim_3.Anc_2
AND Dim_2.Anc_3= Fact.Anc_2 AND Dim_3.Anc_3= Fact.Anc_3;

Les nœuds « Thème » et « Locuteur » sont marqués sur la liste « NœGénChe ». Le calcul de chevauchent concerne donc ces nœuds ainsi que leur nœud parent Dans notre exemple, les nœuds concernés sont « Séquence » et « Parole ». Les nœuds « NomL » et « NomT » sont de type attribut ; elles sont prises en compte dans le calcul de chevauchement au travers de leur nœud père. Par conséquent, la valeur finale du fait est le résultat de l’intersection du contenu des quatre nœuds « Thème », « Locuteur », « Séquence » et « Parole ». Dans la Figure 6, nous présentons le calcul de chevauchement effectué sur la première ligne de la vue « jointure ». Le contenu étant une séquence audio, il sera traduit par des marques de début et de fin exprimées en seconde.

Image6

Figure 6 : Gestion du chevauchement.

Après la gestion du chevauchement, une nouvelle table « JointureT » est créée. Une opération de regroupement est effectuée sur cette table afin d’appliquer la fonction d’agrégation. Ainsi, une nouvelle vue qui représente le contenu du magasin est établie. A partir de cette dernière vue, le système génère la table multidimensionnelle telle que présentée dans la Figure 7.

Image7

Figure 7 : Table multidimensionnelle.

Bilan et conclusion

L’approche que nous avons choisie pour effectuer des analyses multidimensionnelles sur des informations issues des documents se base sur les structures. A partir de ces structures, les nœuds et le contenu sont transposés en sujet d’analyse (fait) et en axes d’analyse (dimensions). Les nœuds choisis peuvent appartenir à une seule structure du document comme ils peuvent dépendre plusieurs structures du même document. Ceci permet à l’analyste d’avoir des résultats plus précis. Cette précision est assurée d’une part par l’ajout de nouveaux paramètres d’analyse et d’autre part, par la gestion de chevauchement entre les nœuds définis sur un même contenu. Par exemple, si nous ne considérons qu’une seule structure au niveau de l’exemple présenté dans la section précédente, nous aurons alors moins de nœuds qui structurent le contenu et par conséquent moins de paramètres d’analyse. Dans ce cas, les analyses possibles ne peuvent plus intégrer des paramètres tenant compte des thèmes et des locuteurs en même temps. La gestion du chevauchement permet d’ajuster le résultat suivant le contenu des deux nœuds qui se chevauchent. Dans l’exemple de la Figure 6, nous montrons comment la mesure du premier fait passe de (89_123) à (89_99). Ceci permet à l’analyste une meilleure localisation des fragments répondant aux paramètres d’analyse choisis.

D’une façon générale, les systèmes d’aide à la décision qui intègrent des informations documentaires offrent plus de données à l’analyste. Selon (Tseng & Chou, 2006), seuls 20 % des données sont exploitées par des techniques OLAP. Ces 20 % représentent des données transactionnelles. Les 80 % restants sont encapsulés dans les documents.

Certes un processus d’analyse multidimensionnelle nécessite des traitements complexes. Quoique, en le comparant à un système de recherche d’informations, il présente quelques avantages notamment au niveau de l’exploitation documentaire. En effet, dans un SRI, le nombre de documents restitués peut être trop élevé. Ainsi, retrouver efficacement l’information pertinente, celle contenant effectivement l’information recherchée, entraine une perte de temps considérable. D’autre part, la restitution des résultats générés via un SRI, concerne l’intégralité des documents et non pas des passages bien précis (ce qui peut devenir intéressant sur des documents longs).

Nous implantons actuellement un prototype « MDocRep » basé d’une part, sur le SGBD « Oracle 10g2 » pour le stockage des structures et des contenus des documents selon le modèle « MVDM » et d’autre part, sur une interface client « Java 1.5 » afin de présenter un outil graphique qui facilite le choix des composantes d’analyse, la génération automatique des requêtes et la visualisation des résultats.

Nous envisageons dans nos futurs travaux d’appliquer cette démarche d’analyse multidimensionnelle dans la gestion des versions de documents. En effet, nous envisageons étendre le modèle « MVDM » afin d’élargir la notion de version à celle de structure et par conséquent à celle de vue.

Bibliographie

Bruno E., Murisasco E., MSXD: a formal model for concurrent structures defined over the same textual data, DEXA 2006 (LNCS), 2006, p. 172-181

Chatti N., Calabretto S., Pinon J-M, Vers un environnement de gestion de documents à structures multiples, Base de Données Avancées, BDA’2004, Montpellier, octobre 2004

Dekhtyar A., Iacob E., A framework for management of concurrent XML markup, Data and Knowledge Engineering, 2005, p. 185-208

Djemal K., Mbarki M., Vallés-Parlangeau N., Une approche multi-vues pour la gestion des documents multistructurés, Document numérique, Hermès, Numéro spécial Entreposage de documents et données semi-structurées, 2007, vol. 10, N. 2, p 37-61

Djemal K., Soulé-Dupuy C., Vallés-Parlangeau N., Formal Modeling of Multistructured Documents, International Conference on Research Challenge in Information Science (RCIS 2008), Marrakech, Morocco, 03/06/2008-06/06/2008, IEEE, p 227-236

Fernandez M., Malhotra A., Marsh J., Nagy M., Walsh N., XQuery 1.0 and XPath 2.0 Data Model (XDM), W3C CandidateRecommendation, 2007

Golfarelli M., Rizzi S., Vrdoljak B., Data Warehouse Design from XML Sources, Fourth ACM International Workshop on Data Warehousing and OLAP, November 9, 2001, Atlanta, Georgia, USA, p 40-47

Gyssens M., Lakshmanan L.V.S., A Foundation for Multi-dimensional Database, International Conference on Very Large DataBases (VLDB’97), Athens, Greece, August 1997, p. 106-115

Hilbert M., Schonefeld O., Witt A., Making CONCUR work Dans Extreme Markup Languages, Montreal, 2005

Huitfeldt C., MECS - A Multi-Element Code System, Working Papers from the Wittgenstein Archives at the University of Bergen, Version 3, October 1998

Huitfeldt C., Sperberg-McQueen C. M. et TexMECS: An experimental markup meta-language for complex documents, Rev., 17 February 2001

Khrouf K., Soulé-Dupuy C., A Textual Warehouse Approach: a Web Data Repository, Chapter VII, Intelligent Agents for Data Mining and Information Retrieval, Idea Group Publishing, p. 101-124, 2004

LeMaitre J., Representing multistructured XML documents by means of delay nodes, Proceedings of the 2006 ACM Symposium on Document Engineering, Amsterdam, The Netherlands, October 2006.

Mechkour M., A multifacet formal image model for information retrieval, MIRO final workshop, Glasgow, UK, 1995, p. 18-20.

Navarro G., A language for queries on structure and contents of textual databases, Thèse de Doctorat, Université de Chili, 1995

Pokorný J., Modelling Stars Using XML, Fourth ACM International Workshop on Data Warehousing and OLAP, November 9, 2001, Atlanta, Georgia, USA, p 24-31

Sperberg-McQueen C. M., Huitfeldt C., GODDAG: A Data Structure for Overlapping Hierarchies, DDEP/PODDP, 2000, p 139-160

Sperberg-McQueen C. M., Burnard L., Guidelines for Electronic Text Encoding and Interchange, Chicago and Oxford, TEI P4, 2001

Tennison J. et Piez W., The Layered Markup and Annotation Language (LMNL), Proceeding of Extreme Markup Languages Conferences, Montreal, Quebec, Canada, 2002.

Tseng F. S. C. Chou, A. Y. H., The concept of document warehousing for multi-dimensional modeling of textual-based business intelligence, Decision Support Systems 42, no. 2 (2006): 727-744.

Vrdoljak B., Banek M., Skocir Z., Integrating XML Sources into a Data Warehouse, DEECS 2006, San Francisco, CA, USA, p 133-142

Pour citer ce document

Karim Djemal, Chantal Soulé-Dupuy et Nathalie Vallès-Parlangeau, «Analyse multidimensionnelle des documents multistructures», Intelligences Journal [En ligne], Numéros en texte intégral , Numéro 1 , URL : http://lodel.irevues.inist.fr/isj/index.php?id=145

Auteurs

Karim Djemal
IRIT, Equipe SIG/D2S2, Université de Toulouse, 118, route de Narbonne, F-31062 Toulouse cedex4, France
Chantal Soulé-Dupuy
IRIT, Equipe SIG/D2S2, Université de Toulouse, 118, route de Narbonne, F-31062 Toulouse cedex4, France
Nathalie Vallès-Parlangeau
IRIT, Equipe SIG/D2S2, Université de Toulouse, 118, route de Narbonne, F-31062 Toulouse cedex4, France