d’entrepôt s de documents XML
Fatma Abdelhédi
1,2, Landry Ntsama
1, Gilles Zurfluh
11. IRIT - Université de Toulouse Capitole
2 rue du Doyen Gabriel Marty 31042 Toulouse, France prénom.nom@irit.fr
2. CBI² - Société Trimane, 57 rue de Mareil 78100 Saint-Germain-en-Laye, France prénom.nom@gmail.com
RÉSUMÉ. Les systèmes OLAP basés sur des entrepôts de données sont aujourd’hui bien intégrés dans les organisations, ils facilitent le traitement et l’analyse de l’information pour la prise de décision. Le développement du web a conduit à l’accroissement du volume de données traité, ainsi qu’à la diversification des sources de l’information. Ce problème de diversification a été en partie résolu grâce au langage XML qui permet en effet le traitement et l’échange de données complexes et hétérogènes. Mais ce format s’adapte mal aux systèmes OLAP et d’entrepôts classiques et il n’existe à ce jour aucun standard permettant de répondre à cette problématique. Nous avons donc développé un modèle multidimensionnel qui utilise le formalisme orienté objet UML pour décrire un entrepôt de documents XML orientés- document. Le schéma de cet entrepôt (appelé StarCD) représente la structure des documents à analyser sous une forme adaptée à la perception du décideur. Dans cet article nous présentons un nouveau langage d’analyse OLAP destiné aux décideurs ; il permet d’exprimer des requêtes complexes sur un entrepôt de documents XML décrit par un StarCD.
ABSTRACT. OLAP systems based on data warehouses are nowadays well integrated into organizations and they ease the process of information analysis for decision-making. The Web expansion led to increase the volume of the data handled, as well as the sources diversification. This problem was partially solved thanks to the XML language, which indeed allows processing and exchanging complex and heterogeneous data. Only, this format does not fit for classic OLAP systems and warehouse, furthermore there is not an existing standard allowing solving this issue. So we developed a multidimensional model which uses the object oriented model UML to describe a XML Document Warehouse (XDW). The warehouse schema (named StarCD) represents the documents structure in the source, such as it is known by the decision-maker. And we present in this article a new OLAP analysis language intended for decision-makers, which allows them to express complex query on a XDW described by its StarCD.
MOTS-CLÉS : OLAP, modélisation multidimensionnelle, XQuery, entrepôt de documents XML.
KEYWORDS: OLAP, multidimensional modeling, XQuery, XML documents warehouse.
DOI:10.3166/DN.1.19.39-57 © Lavoisier 2016
1. Introduction
Depuis une vingtaine d’années, les entrepôts de données et les systèmes OLAP associés ont été développés afin de répondre aux exigences de la prise de décision.
L’évolution rapide des nouvelles technologies, notamment du web, a fait naître de nouvelles problématiques liées à l’exploitation de données complexes et hétérogènes. Le format XML (W3C Consortium, 2015) permet le traitement et l’échange de ce type de données à travers le web. Son exploitation dans les systèmes décisionnels nécessite la définition de nouveaux modèles (Pérez et al., 2008).
L’intégration des documents XML dans les entrepôts a fait l’objet de nombreux travaux, dont la majeure partie concerne les documents XML « orientés-données » (Golfarelli et al., 2001 ; Pérez et al., 2008 ; Pokorny, 2001). D’autres travaux ont traité de l’intégration des documents « orientés-document » (Nassis et al., 2005 ; Tseng and Chou, 2006), en proposant de nouveaux modèles multidimensionnels (par exemple le modèle en galaxie) et en étendant les langages d’analyse existants (SQL, MDX ou XQuery) pour l’analyse OLAP de ces entrepôts. Certains de ces modèles proposent de déstructurer le document afin de le représenter dans le schéma multidi- mensionnel, rendant ainsi la structure méconnaissable pour l’utilisateur. De plus, le décideur étant non-informaticien, la manipulation d’un langage comme XQuery (W3C Consortium, 2014) dans le contexte d’un entrepôt XML peut s’avérer délicate.
Notre solution consiste à créer un entrepôt de documents XML (orientés- document) à partir d’une source contenant une collection de documents thématiques (dont les structures sont unifiées). Pour l’élaboration du schéma multidimensionnel, nous avons étendu le modèle en étoile classique (Golfarelli et al., 1998), les faits, dimensions et mesures sont extraits des XML-Schémas (XSchémas) (W3C Consortium, 2001) décrivant les documents de la source. La structure hiérarchique des documents est donc préservée et facilite la compréhension du schéma multidimensionnel par les décideurs. Mais la contribution principale de cet article est la définition d’un langage d’analyse OLAP qui permet à des décideurs d’analyser un entrepôt de documents XML. C’est un langage dont la syntaxe relativement simple repose sur les principes développés dans les langages de requêtes pour objets complexes (Cattell et al., 1997).
L’article est organisé comme suit. La section 2 présente notre problématique sur les entrepôts de documents ainsi qu’un exemple qui permet d’illustrer les concepts et les cas abordés. La section 3 est consacrée à un état de l’art relatif à cette problématique. La section 4 présente une définition du modèle multidimensionnel de documents. La section 5 propose un langage d’analyse OLAP pour la manipulation de cubes de documents. Enfin, la section 6 présente les caractéristiques du prototype qui a permis d’expérimenter nos propositions.
2. Problématique et exemple
Les documents auxquels nous nous intéressons sont des objets multimédias représentés selon le format XML et contenant des données peu ou pas structurées,
principalement du texte. Le standard d’échange de données XML permet de représenter le contenu d’un document et de l’associer à sa structure appelée DTD ou XSchema. La structure décrit les composants d’un document sous la forme d’éléments juxtaposés ou imbriqués ; chaque élément étant caractérisé par son type de données et encadré par des balises d’identification. L’entreposage et l’analyse OLAP de tels documents représentent un élément fondamental pour l’informatique décisionnelle. Nos travaux s’inscrivent dans ce contexte et traitent de l’entreposage des documents XML. Ils doivent permettre à des décideurs d’analyser des collections de documents sans avoir à prédéfinir les modes d’accès et les critères d’analyse qui pourront être mis en œuvre. Nous traitons des collections homogènes de documents XML, c’est-à-dire qu’une collection regroupe des documents partageant un même XSchéma (Abdelhédi, 2014).
Les travaux dans le domaine de la recherche d’information ont permis de développer des mécanismes pour la recherche de documents XML sur le contenu (mots-clés) en utilisant des techniques basées sur des thésaurus ou des ontologies.
Mais ces travaux exploitent peu la structure des documents et n’ont pas recours à des langages de requêtes OLAP pour réaliser des analyses. D’autres types de travaux ont proposé des processus capables de créer un entrepôt à partir d’une source de documents XML. Ces processus visent à élaborer un entrepôt de données classiques en offrant des techniques d’analyse ROLAP ; mais les possibilités d’analyses des documents s’en trouvent limitées.
Un exemple qui illustre bien notre problématique est celui d’une bibliothèque d’articles scientifiques produits dans un laboratoire et accessibles via le web. Ces articles sont des objets « orientés documents », stockés dans le format XML. Ils sont accessibles à des publics de toutes origines (étudiants, enseignants, chercheurs, …) mais aussi aux décideurs du laboratoire. Ces derniers interrogent les articles pour effectuer des analyses, notamment sur la typologie des publications, les référencements, des indicateurs portant sur les auteurs, etc.
Actuellement, on constate que les laboratoires suivent leur propre stratégie en matière de gestion de bibliothèques d’articles de recherche. On demande généralement aux auteurs d’une part, de stocker l’intégralité d’un article dans un fichier au format PDF et d’autre part, de saisir et d’enregistrer dans une base de données relationnelle des caractéristiques prédéfinies de l’article : titre, coordonnées des auteurs, mots-clés, nom de la conférence, date de publication, etc. Ces descripteurs, extraits par les auteurs du contenu des articles, permettront des recherches ou des analyses ultérieures. On voit bien dans cet exemple la lourdeur du processus liée à la saisie des descripteurs (processus qui peut cependant être partiellement automatisé) ainsi que les limites de l’analyse réduite aux seuls descripteurs prédéfinis. Appliqué à cet exemple, nos travaux doivent permettre aux auteurs d’effectuer une seule opération en stockant uniquement (et simplement) leurs articles dans le format XML ; l’analyse OLAP par les décideurs pourra ensuite se dérouler sans être précédée d’une intervention humaine visant à préparer l’analyse. D’autre part, nous faisons l’hypothèse que la multiplicité des collections de documents sur le web et l’évolutivité des besoins des décideurs sont une justification de la recherche de nouveaux modes d’analyse des documents, plus
simples et plus performants que ceux qui existent aujourd’hui. Ainsi, nous considérons que les décideurs doivent être autonomes pour élaborer un entrepôt (Abdelhédi et Zurfluh, 2013) ; ceci induit que l’on propose des mécanismes accessibles à des non-informaticiens.
3. État de l'art
Dans (Pujolle et al., 2011), les auteurs proposent un nouveau modèle multidimensionnel pour l’analyse des documents XML « orientés documents ». Ce modèle dit « en galaxie » permet d’élaborer un schéma sous la forme d’un graphe qui utilise l’unique concept de « dimension ». Les dimensions de la galaxie sont liées entre elles par un ou plusieurs nœuds exprimant la compatibilité des concepts et c’est au moment de l’interrogation de l’entrepôt que les faits sont désignés parmi les dimensions. Ainsi, une dimension dans un schéma en galaxie représente à la fois un axe et un sujet d’analyse. Ce schéma est élaboré selon une démarche ascendante à partir d’une source XML ; les documents sont déstructurés, c’est-à-dire décomposés en dimensions (distinctes et liées par des liens d’usage) afin de faciliter les analyses. Mais ceci induit la disparition des liens sémantiques entre les dimensions ; ainsi tous les types d’analyse ne sont pas permis : par exemple, il n’est pas possible d’effectuer une agrégation sur les auteurs d’articles et une agrégation sur les auteurs cités en bibliographie.
Dans (Nassis et al., 2005), les auteurs ont proposé de décrire un entrepôt de documents XML en utilisant le modèle des diagrammes de classes d’UML. Dans le schéma de l’entrepôt, les documents sont représentés par un fait lié à des dimensions virtuelles. Les auteurs mettent l’accent sur l’aspect modélisation, sans définir d’approche concrète pour l’analyse OLAP via leur modèle. Ils présentent brièvement un algorithme de requête basé sur XQuery pour analyser un entrepôt. Le modèle de données proposé dans l’article permet de décrire un entrepôt de documents, en termes de faits et dimensions, grâce à des classes d’objets distinctes liées entre elles et organisées suivant les besoins de l'utilisateur. Ainsi la structure des documents, telle qu’elle apparaît dans la source, n’est pas conservée dans l’entrepôt. Or cette structure est connue par des décideurs qui souhaitent analyser des documents.
Dans (Park et al., 2005), les auteurs proposent un modèle de données identique au précédent pour modéliser un entrepôt. Ils étendent le langage MDX qui est à la base un langage de requête OLAP pour les entrepôts de données classiques. Ce langage étendu (XML-MDX) intègre une série d’opérateurs pour la manipulation d’un cube XML en permettant notamment l’analyse de contenus textuels. Le langage XQuery est utilisé lors la création du cube XML pour le calcul des mesures et la définition des dimensions. Tout comme dans l’approche présentée par (Nassis et al., 2005), la structure des documents à analyser ne se retrouve pas dans le schéma de l’entrepôt. De plus, le langage défini pour l’analyse OLAP s’avère complexe car il nécessite que le décideur ait des connaissances informatiques en manipulation de fichier XML (XQuery) ainsi qu’en analyse OLAP (MDX). Or le décideur est par essence un non-informaticien. Ces travaux apportent une contribution significative à
la problématique de la modélisation des entrepôts de documents XML. Mais les solutions proposées ne permettent pas à des décideurs d’appréhender aisément le schéma de l’entrepôt et de le mettre en relation avec la structure des documents qu’ils souhaitent analyser.
D’autres travaux de recherche ont été menés pour spécifier de nouveaux langages capables d’analyser des entrepôts. Nous présentons ci-dessous les travaux concernant la manipulation OLAP des entrepôts de données et de documents XML.
De nombreux travaux ont repris et étendu les opérateurs de l’algèbre relationnelle à la manipulation de cubes (Agrawal et al., 1997 ; Gray et al., 1997). Des opérateurs spécifiques ont été proposés (Abelló et al., 2003 ; Cabibbo and Torlone, 1998 ; Pedersen et al., 2001 ; Yin and Pedersen, 2004).
Les travaux présentés dans (Ravat et al., 2007) ont défini un langage algébrique de manipulation OLAP complet. De nouveaux opérateurs ont été aussi définis sur les entrepôts de documents. Ainsi, dans (Ravat et al., 2007, 2008), les auteurs ont proposé deux fonctions d’agrégation qui s’appliquent sur le texte ; TOP_KWk
permet d’agréger un ensemble de documents en ses k termes les plus représentatifs et AVG_KW permet de résumer les mots-clés issus d’un vocabulaire contrôlé par un ensemble limité en termes plus généraux.
Les approches présentées ci-dessus concernent (1) les entrepôts « orientés données » qui sont implantés au format XML : dans ce cas les opérations OLAP classiques s’appliquent ; (2) les entrepôts « orientés documents » : dans ce cas les opérations OLAP doivent être redéfinies pour s’appliquer à de nouvelles structures de données. Dans notre approche, nous supposons que les décideurs connaissent ou, du moins, ont accès à la structure des documents qu’ils désignent dans la source pour être analysés. Ils retrouveront cette structure dans le schéma de l’entrepôt et c’est cette structure qui leur permettra d’exprimer des requêtes d’analyse.
4. Définition du modèle multidimensionnel 4.1. Définition
Le modèle que nous présentons dans cette section permet de décrire un entrepôt de documents XML sous la forme d’un schéma en constellation contenant plusieurs étoiles, nommé StarCD. Ce modèle repose sur le formalisme UML (Object Management Group (OMG), 2015) pour représenter le fait et ses mesures ainsi que les dimensions. Il est élaboré à partir de l’analyse d’une source de documents XML décrits par un même schéma XML (XSchéma) et sert de support pour l’élaboration des requêtes d’analyse par les décideurs.
Un StarCD est défini à partir du XSchéma décrivant les documents XML sous forme d’arbres :
StarCD : {E1, E2,…En}
Chaque étoile Ei est représentée par un arbre n-aire où le nœud racine correspond au fait et les nœuds fils définissent les mesures et les dimensions. Une étoile Ei est définie comme suit :
Ei = (Fi, Xi) où :
–
Fi correspond au fait, c’est-à-dire à l’élément racine du XSchéma définissant la classe de documents à analyser.–
Xi est une forêt de sous arbres n-aires fils de Fi (représentant les mesures et les dimensions). Le lien qui relie Fi et chacun de ses sous arbres de la forêt appartient à l’un des deux types suivants :–
Un lien de composition qui associe le fait à des mesures imbriquées dans les documents.–
Un lien d’association « By » qui lie le fait à une dimension d’analyse.Figure 1. Des sous-arbres de mesures et de dimensions
Dans un sous-arbre de mesures, seules les feuilles correspondent à des mesures de fait et sont associées à une fonction d’agrégation ; un nœud intermédiaire indique le niveau d’imbrication d’une mesure conformément à la structure des documents.
Une des originalités de notre modèle est de permettre la définition de mesures à partir d’attributs situés dans les éléments imbriqués dans le fait.
Dans un sous-arbre de dimensions, chaque nœud correspond à un paramètre dans une hiérarchie. Une particularité de notre modèle consiste à reprendre l’organisation des éléments de la source. Ceci est un aspect important dans notre proposition puisque nous souhaitons préserver la structure de documents dans le schéma multidimensionnel de l’entrepôt. Les décideurs peuvent ainsi appréhender aisément les éléments du schéma multidimensionnel à partir de leurs connaissances structurelles des documents. Une conséquence de cette contrainte est de proposer
des hiérarchies inversées pour représenter la structure originelle des documents ; c’est le cas de la dimension CoAuthors dans la Figure 2. Un exemple de StarCD.
Figure 2. Un exemple de StarCD
Nous utilisons le langage UML pour décrire les faits et dimensions dans le StarCD. L’élaboration du StarCD est un processus semi-automatique qui extrait les faits, mesures et dimensions du SourceCD. Les décideurs interviennent dans un second temps pour préciser leurs besoins. Le processus d’intervention du décideur ne sera pas présenté dans cet article.
À partir de ce schéma multidimensionnel, le décideur pourra analyser le fait en fonction de la mesure P_Nb (nombre d’articles) en fonction des dimensions Publication et/ou CoAuthors (groupe d’auteurs) et/ou PubliDate. La mesure RankAvg contient la moyenne des rangs des articles pour chaque regroupement.
« By »
« By »
« By »
4.2. Étude de cas
Pour illustrer notre démarche, nous disposons d’une collection d’articles scientifiques de même thématique que nous souhaitons analyser. Nous allons utiliser cette collection pour construire un entrepôt de documents. La source est décrite par un XSchéma (figure 3) représentant l’ensemble des documents. La figure 2 représente un exemple de StarCD contenant le fait, les dimensions et les mesures que nous avons sélectionnés pour cette analyse.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name = "Paper">
<xs:complexType>
<xs:sequence>
<!--Types simples -->
<xs:element name="Title" type="xs:string"/>
<!--Types complexes -->
<xs:element name = "CoAuthors">
<xs:complexType>
<xs:sequence>
<xs:element name="Author" maxOccurs="unbounded">
<xs:complexType>
<xs:sequence>
<xs:element name = "Name" type="xs:string"/>
<xs:element name = "FirstName" type="xs:string"/>
<xs:element name = "Affiliation" type="xs:string" minOccurs="0"/>
<xs:element name = "Mail" type="xs:string" minOccurs="0"/>
</xs:sequence>
<!--Attributs auteur -->
<xs:attribute name = "H-Index" type="xs:integer" use ="required"/>
</xs:complexType>
</xs:element>
<xs:element name = "AffiliationGroup" type="xs:string" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Abstract" type="xs:string" minOccurs="0"/>
<xs:element name="Résumé" type="xs:string" minOccurs="0"/>
< !-- -->
Figure 3. XSchéma partiel de la classe de documents Paper
Le fait et les mesures correspondent à l’arborescence de la racine Paper et sont situés dans la partie basse, avec la couleur verte, du StarCD. Les dimensions quant à elles figurent dans la partie haute, avec la couleur rouge. Comme pour les mesures, la structure hiérarchique des documents sources se retrouve dans la forêt des dimensions. Ceci contraint un sens particulier des liens hiérarchiques entre
paramètres (hiérarchie inversée). Ainsi dans la figure 2, la classe CoAuthors est directement liée au fait Paper parce qu’il s’agit d’un élément de premier niveau dans le XSchéma décrivant les documents sources ; les paramètres de cette dimension sont donc inversés par rapport au sens classique. De plus, d’après (Bordawekar et Lang 2005), tout élément XML peut être analysé soit comme une dimension soit comme une mesure. Ceci est dû à la classification entre les dimensions et les mesures qui n’est pas rigide, comme c’est le cas pour les données plates. Nous retrouvons cette propriété dans notre modèle où chaque élément identifié comme dimension peut aussi être identifié comme mesure (par exemple la classe KWord dans la figure 2). L’élément PubliDate est néanmoins utilisé exclusivement comme dimension.
5. Langage d’analyse OLAP 5.1. L’algèbre OLAP
Un modèle de données permet de définir d’une part les structures des objets autorisées et d’autre part l’ensemble des opérations applicables à ces objets.
Nous avons donc repris les opérations sur les entrepôts de données classiques (Pedersen and Jensen, 1999 ; Ravat et al., 2006) et nous les avons adaptées aux structures de données que nous avons définies. Nous avons donc retenu trois opérations OLAP : l’extraction, le forage et la sélection pour montrer les capacités de notre langage d’analyse.
5.1.1 L’extraction
Cette opération permet d’obtenir une ou plusieurs mesures d’un entrepôt E selon le niveau courant des dimensions spécifiées ; les autres dimensions (non précisées dans l’expression) ont pour paramètre All. Pour une dimension de E, le niveau courant de granularité correspond à la racine du graphe des paramètres. Cette opération produit un nouvel entrepôt (noté Rx) contenant les dimensions et les mesures spécifiées.
Rappelons que l’opérande E peut correspondre à l’entrepôt manipulé ou bien au résultat d’une opération précédente.
Exemples
L’opération suivante s’applique sur l’entrepôt IRIT et retourne un nouvel entrepôt R1. Seule la dimension Publication est utilisée ; elle est fixée à sa valeur courante et associée à l’attribut faible Acronym. Ainsi, pour chaque publication représentée par son acronyme, le fait contient un nombre d’articles (mesure P_Nb).
Dans l’exemple suivant, l’opération Extract s’applique toujours sur le fait Paper mais permet d’extraire deux mesures dont la seconde figure dans la classe KWord imbriquée dans la classe-fait Paper. L’expression de calcul associée à la mesure W_Nb est donc appliquée sur le résultat de la jointure des classes Paper et KWord.
-- Mesure du fait Paper (
-- Mesure imbriquée ) ;
-- Dimension
Dans l’opération R3, l’extraction du nombre d’articles est effectuée selon la dimension CoAuthors (dont le paramètre éponyme est implicite) au niveau du paramètre Author ; ceci nécessite une jointure des classes Paper, CoAuthors et Author.
R3 Extract (IRIT ; Paper.P_Nb ; (Paper ⨝ CoAuthors ⨝ Authors).FirstName)) 5.1.2. Opérateurs de forage
Dans un entrepôt, les valeurs des mesures dépendent fonctionnellement d’une valeur du produit cartésien de l’ensemble des dimensions (chaque dimension étant représentée par un paramètre). L’opération de forage permet de calculer de nouvelles valeurs des mesures en sélectionnant des paramètres sur les hiérarchies des dimensions. En effet toute dimension est associée à un graphe de paramètres.
Pour un StarCD comportant q dimensions, chaque dimension est associée à un nombre quelconque de paramètres noté s et chaque paramètre est lui-même associé à t attributs ; l’opération Roll s’exprime alors comme suit.
Dans un StarCD, les hiérarchies peuvent être inversées. Par conséquent, le choix d’un paramètre va déterminer soit un forage vers le bas (Drill-down) soit un forage vers le haut (Roll-up) sur une dimension.
Exemple
L’opération suivante modifie les paramètres courants des dimensions CoAuthors et PubliDate. Les mesures du fait Paper sont recalculées dans R4 selon les nouveaux paramètres ; les autres dimensions restent inchangées.
L’opération Roll permet de choisir les dimensions, les paramètres et les attributs dans le StarCD. Par conséquent, les opérations de rotation (F-Rotate, D-Rotate et H-Rotate) peuvent être simulées sans introduire de nouvelles opérations.
5.1.3. Opérateurs de sélection
Cette opération consiste à restreindre les valeurs des mesures ou des attributs de paramètres. Dans l’expression suivante, une mesure est notée m, une dimension d et un attribut d’un paramètre a ; nous considérons également des prédicats portant sur des mesures ou ceux portant sur des attributs.
Exemple
L’opération Select suivante restreint l’entrepôt IRIT :
– en limitant les mesures aux seuls articles écrits par des auteurs belges (au moins un Belge par article),
– en restreignant la dimension PubliDate (paramètre Year) aux années supérieures à 2010.
⨝ ⨝ elge ⨝ ⨝
5.2. Syntaxe et sémantique
Le langage de requêtes XQuery (W3C, 2013d) a été développé et standardisé par le W3C et permet d’interroger des documents XML. Toutefois sa syntaxe est complexe et l’expression des requêtes parfois difficile. En effet, il nécessite une bonne connaissance d’une part, du langage de sélection XPath (W3C, 2013b) permettant de naviguer dans la structure d’un document et, d’autre part, de la structure des fichiers. Nous décrivons dans cette section un nouveau langage OLAP pour analyser un entrepôt de documents décrit par un StarCD. Ce langage est complet au regard de l’algèbre multidimensionnelle présentée (partiellement) dans la section 5.1. Il s’inspire de la syntaxe du langage OQL qui a été développé pour manipuler des objets complexes et qui a été standardisé par l’ODMG (Date, 1999).
Comme pour le langage SQL qui a été initialement créé pour des utilisateurs occasionnels (Date, 1999), le langage que nous proposons est déclaratif et est destiné à l’usage des décideurs. Sa sémantique formelle peut être facilement décrite. La syntaxe du langage est simple au regard des requêtes de type XQuery nécessaires pour manipuler des documents XML. Cependant on peut penser que la mise au point d’un langage graphique sera une prochaine étape pour obtenir un langage plus
convivial et mieux adapté à des non-informaticiens (voir section 7. Conclusion et perspectives). Toute requête d’analyse s’exprime sous la forme suivante :
Analyse <mesures>
From <classes>
Where <predicat>
By <dimensions>
Une requête comporte les clauses suivantes :
1. La clause Analyse qui contient les mesures à évaluer selon les dimensions de la clause y et les fonctions d’agrégation figurant dans le StarCD.
2. La clause From spécifie chaque classe du StarCD utilisée dans la requête (fait et dimensions) en lui associant une variable de désignation (alias) ; celle-ci est utilisée dans les deux autres clauses.
3. La clause Where (optionnelle) donne les critères ou les filtres permettant de gérer le résultat.
4. La clause By (optionnelle) contient les dimensions permettant d’évaluer les mesures.
Une requête est une fonction qui s’applique à un entrepôt de documents et qui renvoie un entrepôt dont la structure est déduite des paramètres contenus dans la requête. Les exemples de requêtes que nous présentons s’appliquent sur le StarCD de la figure 2 qui décrit l’entrepôt intitulé IRIT ; ils montrent les capacités d’analyse de notre langage.
LA REQUÊTE 1 calcule le nombre d’articles et le nombre de mots-clés associés à chaque publication. Le parcours dans le graphe des mesures est effectué grâce aux variables de désignation.
R1 Analyse p.P_Nb, w.W_Nb
From p in Paper, w in p.KWord, pu in Publication By pu.Acronym
En langage algébrique, cette requête s’exprime avec l’opération d’extraction comme suit :
⨝
LA REQUÊTE 2 renvoie, pour chaque publication, le nombre moyen des co-auteurs qui ont rédigé les articles.
R2 Analyse a.Nb_Avg
From p in Paper, c in p.CoAuthors, a in c.Author, pu in Publication By pu.Acronym
En termes algébriques, la requête R2 correspond à une opération d’extraction ; elle chemine dans le graphe des mesures en réalisant deux jointures sur les trois classes Paper, CoAuthors et Author.
⨝ ⨝
LA REQUÊTE 3 calcule le nombre d’articles pour chaque auteur et pour chaque année de publication. Elle utilise deux dimensions : CoAuthors et PubliDate dont les hiérarchies sont inversées ; les paramètres choisis (Author et Year) sont situés sur les hiérarchies respectives.
R3 Analyse p.P_Nb
From p in Paper, c in CoAuthors, a in c.Author, --dimension 1 d in PubliDate, m in d.Month, y in m.Year -- dimension 2 By a.FirstName, y.Year
La figure 4 permet de visualiser le résultat de la R3.
Paper Paper.Nb
PubliDate
Year 2010 2011 2012 2013
CoAuthors
FirstName
Author 1 7 21 15 7
Author 2 11 12 11 7
Author 3 13 10 14 5
Author 4 11 15 18 8
Figure 4. Résultat de la R3
La requête équivalente en langage algébrique s’écrit comme suit :
Nous avons décrit la syntaxe de toute requête d’analyse OLAP à l’aide de la grammaire BNF (métalangage comportant des métasymboles, des termes terminaux et non terminaux). La syntaxe de nos requêtes est représentée comme suit.
<OLAP_Query> :: = Analyse <Measure>
From (<var> in <class> “,”)+
[Where <predicat()> ] By <var>.<attribute>
<Measure> :: = "(" ["a"-"z"]|"_"|["0"-"9"]|""|["A"-"Z"] ")"
<predicat()> :: = <var> <signe><var>
…
Toute requête OLAP fait l’objet de trois opérations successives : – une analyse lexicale et syntaxique,
– une analyse sémantique utilisant le schéma multidimensionnel (StarCD) au format XML : vérification du typage et contrôle de conformité avec la grammaire BNF,
– la traduction en XQuery en utilisant le schéma XML de l’entrepôt.
6. Expérimentation
6.1. Processus de traduction 6.1.1. La requête OLAP
Le traducteur XQuery prend en entrée la requête OLAP après vérification lexico- syntaxique (par rapport à la grammaire BNF) et sémantique (par rapport au schéma StarCD). Cette requête est organisée sous la forme d’un arbre afin d’être traitée plus aisément par l’algorithme. La racine de l’arbre représente le fait d’où émanent deux types d’arcs : les arcs de mesures et les arcs de dimensions. Comme le montre la figure 5, on peut donc distinguer des sous-arbres liés au fait et correspondant aux chemins menant aux mesures et aux dimensions de l’entrepôt.
Figure 5. L’arbre générique d’une requête OLAP et une instanciation
6.1.2. L’entrepôt
Pour transformer la requête OLAP en une requête XQuery, le traducteur utilise le schéma de l’entrepôt physique ; celui-ci représente les structures de données XML telles qu’elles sont implantées. L’entrepôt est stocké dans un document XML unique. Les dimensions et leurs paramètres ainsi que le fait et ses mesures sont distingués par des balises spécifiques.
Les mesures ne sont pas pré-calculées ; il y a donc autant d’instances du fait que de documents dans la source. Bien entendu, le volume de chaque instance est limité à quelques kilo-octets correspondant uniquement au stockage des opérandes de
mesures et aux liens. L’intérêt de ce mode de stockage où les chaque instance du fait correspond à un document, réside dans la possibilité de répondre à certaines requêtes, notamment les analyses OLAP faisant intervenir des sélections sur les mesures.
Bien que stockées dans le format XML, les données de l’entrepôt peuvent se décrire par des structures de table d’objets (acceptant des attributs multivalués). Les objets sont associés à des identificateurs d’objet correspondant à des numéros d’ordre dans une table. Comme dans les SG D objet, ces identificateurs sont utilisés à la fois pour identifier les objets et pour établir des liens. L’entrepôt comporte trois parties (éléments dans XML) distinctes : un répertoire, les dimensions et paramètres ainsi que le fait et ses mesures.
Figure 6. Le XSchéma de l’entrepôt
Le « répertoire » contient l’ensemble des données exploitables extraites des sources et présentant un intérêt décisionnel : nombres et chaînes de caractères uniquement (à l’exclusion des textes, images, figures, etc.). Ce répertoire contient autant de tables que de classes dans le StarCD (à l’exclusion des hiérarchies liées aux dates). Ces tables sont indépendantes les unes des autres, c’est-à-dire non liées entre elles.
La partie « Dimensions et paramètres » contient les valeurs des paramètres pour chaque dimension. Ces valeurs sont stockées sous la forme de tables ayant pour attributs :
– un identificateur de paramètres,
– un lien vers les tables du répertoire contenant les valeurs de chaque attribut faible,
– le cas échéant, un lien (multivalué) pointant sur le paramètre de niveau supérieur.
La partie « Fait et mesures » correspond au stockage du fait et de l’ensemble de ses mesures. Les données sont enregistrées dans une table unique contenant une instance par document source. Le schéma de cette table est le suivant :
– un identificateur du fait,
– un lien (atomique ou multivalué) vers les tables du « Répertoire » contenant les valeurs de chaque opérande de mesure,
– un lien atomique vers des tables de la partie « Dimensions et paramètres », c’est-à-dire chaque dimension du StarCD.
6.2. L’algorithme
La figure 7 présente l’algorithme général du traducteur qui a été programmé en Java. L’algorithme se déroule en deux étapes : le parcours de l’arbre d’analyse et l’élaboration de la requête XQuery.
Durant la première étape, nous récupérons l’ensemble de valeurs qui servira pour la deuxième étape. À partir de la requête OLAP qui lui est soumise, le traducteur parcours l’arbre correspondant à la requête d’analyse ; il extrait les feuilles liées aux mesures, aux dimensions et aux conditions. En partant de la racine et pour chaque feuille, l’algorithme extrait les nœuds intermédiaires qui représentent le chemin de chaque mesure, dimension et condition.
La deuxième étape élabore la requête XQuery. L’expression de chaque clause de la requête (For, Let, Where, OrderBy et Return) est construite à partir des valeurs extraites dans la première étape.
Algorithm : Traducteur
Input : TAQ, SourceCD -- Requête d’analyse, SourceCD Output : OLAPXQuery -- Requête XQuery
MList nil DList nil DPathList nil CList nil CPathList nil -- première étape
R TAQ.root While (R.filsG ¬ nil)
L R.filsG for i 1 to L.size() Do
if (h(Ni) ¬ nil) then P Ni.LeafNode else P Ni
end if
- IsMeasure est une fonction qui retourne vrai si le nœud courant est une mesure if IsMeasure (P) then
MList P
-- IsDimension est une fonction qui retourne vrai si le nœud courant est une dimension
else if IsDimension (P) then DList P
else
CList P end if
end if end for -- deuxième étape OLAPXQuery nil
ForClause DPathList
LetClause assignation de chaque valeur des dimensions dans une variable WhereClause CList
OrderBy DList Return { for rd 1 to DList.size()
<Dimensionrd> DList(rd) </Dimensionrd>
for me 1 to MList.size()
<Measureme>MList(me)<Measureme>
}
Figure 7. L’algorithme du traducteur XQuery
7. Conclusion et perspectives
Les systèmes OLAP actuels ne permettent pas le traitement et l’analyse des documents XML issus du web. Or le format XML est devenu un standard pour le traitement et l’échange de données massives et hétérogènes.
Nous avons proposé dans cet article une approche de modélisation et d’analyse multidimensionnelles pour les entrepôts de documents XML natifs. Nous avons défini un langage d’analyse OLAP pour les décideurs, qui s’applique sur un modèle multidimensionnel décrit à l’aide du formalisme UML. Ce modèle permet de représenter la structure XML des documents à analyser à l’aide de faits, mesures et dimensions, facilitant l’expression des requêtes par les décideurs. Le langage permet aux décideurs de pouvoir exprimer des requêtes complexes à partir du schéma de l’entrepôt StarCD. Ces requêtes sont traduites en XQuery pour être appliquées sur un entrepôt de documents matérialisé. Nous avons à cet effet développé un module logiciel qui assure la traduction automatique des requêtes.
Actuellement, nous cherchons à optimiser d’une part le processus de traduction afin de gagner du temps sur le traitement des requêtes et d’autre part l’affinage des résultats. Par ailleurs, l’adoption de ce langage devra passer par le développement d’une interface homme-machine rendant plus ergonomiques les requêtes exprimées par les décideurs dans ce nouveau langage OLAP.
Bibliographie
Abdelhédi F. (2014). Conception assistée d’entrepôts de données et de documents XML pour l’analyse OLAP. Thèse en informatique, université de Toulouse.
Abelló A., Samos J., and Saltor F. (2003). Implementing operations to navigate semantic star schemas. In Proceedings of the 6th ACM International Workshop on Data Warehousing and OLAP, (ACM), pp. 56–62.
Agrawal R., Gupta A., and Sarawagi S. (1997). Modeling multidimensional databases. In Data Engineering, 1997. Proceedings. 13th International Conference on, (IEEE), pp.
232–243.
Cabibbo L., and Torlone R. (1998). From a procedural to a visual query language for OLAP.
In Scientific and Statistical Database Management, 1998. Proceedings. Tenth International Conference on, (IEEE), pp. 74–83.
Cattell R.G.G., Barry D.K., Bartels D., Berler M., Eastman J., Gamerman S., Jordan D., Springer A., Strickland H., and Wade D. (1997). The object database standard: ODMG 2.0 (Morgan Kaufmann Publishers San Mateo).
Date C. (1999). An Introduction to Database Systems (Introduction to Database Systems, 7th ed).
Golfarelli M., Maio D., and Rizzi S. (1998). Conceptual design of data warehouses from E/R schemes. In System Sciences, 1998., Proceedings of the Thirty-First Hawaii International Conference on, (IEEE), pp. 334–343.
Golfarelli M., Rizzi S., and Vrdoljak B. (2001). Data warehouse design from XML sources.
In Proceedings of the 4th ACM International Workshop on Data Warehousing and OLAP, pp. 40–47.
Gray J., Chaudhuri S., Bosworth A., Layman A., Reichart D., Venkatrao M., Pellow F., and Pirahesh H. (1997). Data cube: A relational aggregation operator generalizing group-by, cross-tab, and sub-totals. Data Min. Knowl. Discov. 1, 29–53.
Nassis V., Rajagopalapillai R., Dillon T.S., and Rahayu W. (2005). Conceptual and systematic design approach for XML document warehouses. Int. J. Data Warehouse.
Min. 1, 63–87.
Object Management Group (OMG) (2015). Unified Modeling Language (UML).
Park B.-K., Han H., and Song I.-Y. (2005). XML-OLAP: a multidimensional analysis framework for XML warehouses. In Data Warehousing and Knowledge Discovery, (Springer), pp. 32–42.
Pedersen T.B., and Jensen C.S. (1999). Multidimensional data modeling for complex data. In Data Engineering, 1999. Proceedings, 15th International Conference on, (IEEE), pp. 336–
345.
Pedersen T.B., Jensen C.S., and Dyreson C.E. (2001). A foundation for capturing and querying complex multidimensional data. Inf. Syst. 26, 383–423.
Pérez J.M., Berlanga R., Aramburu M.J., and Pedersen T.B. (2008). Integrating data warehouses with web data: A survey. Knowl. Data Eng. IEEE Trans. On 20, 940–955.
Pokorny J. (2001). Modelling stars using XML. In Proceedings of the 4th ACM International Workshop on Data Warehousing and OLAP, (ACM), pp. 24–31.
Pujolle G., Ravat F., Teste O., Tournier R., and Zurfluh G. (2011). Multidimensional database design from document-centric XML documents. In Data Warehousing and Knowledge Discovery, (Springer), pp. 51–65.
Ravat F., Teste O., and Zurfluh G. (2006). Algèbre OLAP et langage graphique. In Congrès Informatique Des Organisations et Systèmes d’Information et de Décision-INFORSID’06, pp. 1039–1054.
Ravat F., Teste O., Tournier R., and Zurfluh G. (2007). Graphical Querying of Multidimensional Databases. In Advances in Databases and Information Systems, Y.
Ioannidis B. Novikov, and B. Rachev, eds. (Springer Berlin Heidelberg), pp. 298–313.
Ravat F., Teste O., Tournier R., and Zurfluh G. (2008). Top_Keyword: An Aggregation Function for Textual Document OLAP. In Data Warehousing and Knowledge Discovery, I.-Y. Song, J. Eder, and T.M. Nguyen, eds. (Springer Berlin Heidelberg), pp. 55–64.
Tseng F.S., and Chou A.Y. (2006). The concept of document warehousing for multi- dimensional modeling of textual-based business intelligence. Decis. Support Syst. 42, 727–744.
W3C Consortium (2001). W3C XML Schema.
W3C Consortium (2014). XQuery 3.0: An XML Query Language.
W3C ConsortiumW3C Consortium (2015). Extensible Markup Language (XML).
Yin X., and Pedersen T.B. (2004). Evaluating XML-extended OLAP queries based on a physical algebra. Proceedings of the 7th ACM International Workshop on Data Warehousing and OLAP, (ACM), pp. 73–82.
