Matérialisation des vues dans un modèle multidimensionnel contraint



Documents pareils
Fouille de Données : OLAP & Data Warehousing

Datawarehouse: Cubes OLAP. Marlyse Dieungang Khaoula Ghilani

et les Systèmes Multidimensionnels

Entrepôts de données multidimensionnelles NoSQL

Algèbre OLAP et langage graphique

Entrepôts de données. NEGRE Elsa Université Paris-Dauphine

Bases de données multidimensionnelles et mise en œuvre dans Oracle

Entrepôt de données 1. Introduction

Les Entrepôts de Données

Techniques d optimisation des requêtes dans les data warehouses

Démarche dirigée par les modèles pour la conception d entrepôts de données multidimensionnelles. F.Atigui, F.Ravat, O.Teste, G.

Approche de modélisation multidimensionnelle des. des données complexes : Application aux données médicales. 5èmes Journées

ETL Extract - Transform - Load

Lamia Oukid, Ounas Asfari, Fadila Bentayeb, Nadjia Benblidia, Omar Boussaid. 14 Juin 2013

Entreposage de données complexes pour la médecine d anticipation personnalisée

Généralisation contextuelle de mesures dans les entrepôts de données

Hervé Couturier EVP, SAP Technology Development

Cours Base de données relationnelles. M. Boughanem, IUP STRI

Rapport de DEA. Intégration de versions fonctionnelles dans les entrepôts de données multimédias au sein des systèmes OLAP. Anne-Muriel ARIGON

Construction graphique d entrepôts et de magasins de données

C-CUBE: Un nouvel opérateur d agrégation pour les entrepôts de données en colonnes

Systèmes d information et bases de données (niveau 1)

Évolution de schémas dans les entrepôts de données mise à jour de hiérarchies de dimension pour la personnalisation des analyses

Problèmes d additivité dus à la présence de hiérarchies

Oracle Décisionnel : Modèle OLAP et Vue matérialisée D BILEK

SQL. Oracle. pour. 4 e édition. Christian Soutou Avec la participation d Olivier Teste

Exemple accessible via une interface Web. Bases de données et systèmes de gestion de bases de données. Généralités. Définitions

BI = Business Intelligence Master Data-ScienceCours 3 - Data

Chapitre IX. L intégration de données. Les entrepôts de données (Data Warehouses) Motivation. Le problème

SQL Server 2012 Implémentation d'une solution de Business Intelligence (Sql Server, Analysis Services...)

LES OUTILS D ALIMENTATION DU REFERENTIEL DE DB-MAIN

La place de la Géomatique Décisionnelle dans le processus de décision

4. Utilisation d un SGBD : le langage SQL. 5. Normalisation

Datawarehouse and OLAP

Urbanisation des SI-NFE107

Modélisation d objets mobiles dans un entrepôt de données

Bases de Données. Plan

Evolution et personnalisation des analyses dans les entrepôts

Bases de Données Avancées

SQL Server 2012 et SQL Server 2014

Les Entrepôts de Données. (Data Warehouses)

Business Intelligence : Informatique Décisionnelle

Introduction à la B.I. Avec SQL Server 2008

ORACLE TUNING PACK 11G

SGBDR. Systèmes de Gestion de Bases de Données (Relationnelles)

OPEN DATA : CHALLENGES ET PERSPECTIVES D ENTREPOSAGE

Méthodes d évolution de modèle produit dans les systèmes du type PLM

Plan. Introduction Eléments de la théorie des systèmes d'informations Les entrepôts de données (Datawarehouse) Les datamart Architecture Modélisation

AVERTISSEMENT. D autre part, toute contrefaçon, plagiat, reproduction illicite de ce travail expose à des poursuites pénales.

Intelligence Economique - Business Intelligence

CONCEPTION ET REALISATION D'UN GENERATEUR DE TABLEAUX DE BORD PROSPECTIFS MULTIDIMENSIONNELS

Alimenter un entrepôt de données par des données issues de services web. Une approche médiation pour le prototype DaWeS

Personnalisation collaborative pour l enrichissement des analyses dans les entrepôts de données complexes

BUSINESS INTELLIGENCE. Une vision cockpit : utilité et apport pour l'entreprise

Modélisation Multidimensionnelle des Tableaux de Bord Prospectifs

LA GESTION DES VUES 1. INTRODUCTION

Mathématique et Automatique : de la boucle ouverte à la boucle fermée. Maïtine bergounioux Laboratoire MAPMO - UMR 6628 Université d'orléans

UNIVERSITÉ MOHAMMED V AGDAL. FACULTÉ DES SCIENCES Rabat THÈSE DE DOCTORAT. Présentée par ELhoussaine ZIYATI Discipline : Sciences de l ingénieur

Plan. Ce qu est le datawarehouse? Un modèle multidimensionnel. Architecture d un datawarehouse. Implémentation d un datawarehouse

Présentation du module Base de données spatio-temporelles

Introduction à Business Objects. J. Akoka I. Wattiau

Compétences Business Objects

Plan. Exemple: Application bancaire. Introduction. OCL Object Constraint Language Le langage de contraintes d'uml

Une proposition d extension de GML pour un modèle générique d intégration de données spatio-temporelles hétérogènes

UML (Diagramme de classes) Unified Modeling Language

Bases de Données OLAP

Bases de Données. Stella MARC-ZWECKER. Maître de conférences Dpt. Informatique - UdS

BI = Business Intelligence Master Data-Science

Le Guide Pratique des Processus Métiers

IFT2255 : Génie logiciel

2 Serveurs OLAP et introduction au Data Mining

Master Exploration Informatique des données DataWareHouse

Bases de données. Chapitre 1. Introduction

Définition et diffusion de signatures sémantiques dans les systèmes pair-à-pair

OASIS Date de publication

La rencontre du Big Data et du Cloud

et les Systèmes Multidimensionnels

A QUOI SERVENT LES BASES DE DONNÉES?

Une méthode d apprentissage pour la composition de services web

Structuration des décisions de jurisprudence basée sur une ontologie juridique en langue arabe

Développement d un interpréteur OCL pour une machine virtuelle UML.

Big Data et Graphes : Quelques pistes de recherche

arxiv: v1 [cs.db] 9 Jul 2007

Tout ce que vous avez toujours voulu savoir sur SAP HANA. Sans avoir jamais osé le demander

Le "tout fichier" Le besoin de centraliser les traitements des fichiers. Maitriser les bases de données. Historique

Les bases de données Page 1 / 8

INTRODUCTION AUX METHODES D INGENIERIE DES DONNEES DIRIGEE PAR LES MODELES

Les entrepôts de données

Business & High Technology

Bases de données - Modèle relationnel

L information et la technologie de l informationl

Ecole des Hautes Etudes Commerciales HEC Alger. par Amina GACEM. Module Informatique 1ière Année Master Sciences Commerciales

Information utiles. webpage : Google+ : digiusto/

Workflow/DataWarehouse/DataMining LORIA - Université d automne Informatique décisionnelle - L. Mirtain 1

TP 2 Réseaux. Adresses IP, routage et sous-réseaux

Techniques d analyse et de conception d outils pour la gestion du processus de segmentation des abonnés des entreprises de télécommunication

Langage SQL : créer et interroger une base

Big Data et Graphes : Quelques pistes de recherche

Université de Bangui. Modélisons en UML

Introduction au Système de Gestion de Base de Données et aux Base de Données

Transcription:

Matérialisation des vues dans un modèle multidimensionnel contraint Faïza Ghozzi Université Paul Sabatier - IRIT 118, Route de Narbonne 31062 Toulouse cedex 04 {ghozzi.@irit.fr} RÉSUMÉ. Les bases de données multidimensionnelles (BDM) ont émergé pour répondre aux besoins spécifiques des analyses OLAP. Les données des BDM sont visualisées au travers des cubes. Le cube a été introduit pour pré-calculer des vues agrégées, appelées vues matérialisées, dans le but d améliorer le temps d interrogation. Dans cet article, nous proposons une modélisation en constellation des BDM organisant les données en faits analysées selon différentes dimensions. Notre modèle permet d exprimer un ensemble de contraintes sémantique intra et inter dimensions. Afin d assurer la cohérence des données et d améliorer le processus de matérialisation des vues, nous intégrons ces contraintes lors de la construction du treillis multidimensionnel. Notre proposition est validée par le prototype GEDOOH qui permet d exprimer ces contraintes et de les intégrer dans l algorithme de construction du treillis. ABSTRACT. Multidimensional databases (MDB) were emerged to meet specific OLAP needs. Data in MDB were displayed using cube. Cube was introduced to pre-compute aggregate views, called materialised views, in order to improve response time of OLAP query. In this paper, we define a MDB model which organises data in a constellation of facts and multiple hierarchy dimensions. The model we describe provides a set of semantic intra- and interdimension constraints. In order to insure data consistence and to improve view materialisation process, we integrate these constraints during the multidimensional lattice construction. We validate our proposal by the prototype GEDOOH which can express these constraints into MDB model and integrate them in the lattice construction algorithm. MOTS-CLÉS : modèle multidimensionnel, contraintes, vue matérialisée, treillis multidimensionnel. KEYWORDS : multidimensional model, constraints, materialised view, multidimensional lattice.

1. Introduction Les entrepôts de données se sont développés afin de fournir aux décideurs des systèmes dédiés à l analyse des données et de pallier les insuffisances des systèmes transactionnels (OLTP OnLine Transactionnel Processing). Pour faciliter l accès aux données, plusieurs entrepôts ont adopté l approche des bases de données multidimensionnelles (BDM). Les BDM ont donc émergé pour répondre aux besoins spécifiques d analyse multidimensionnelle (OLAP On-Line Analytical Processing) (Codd, 1993). Les BDM sont généralement décrites selon un schéma multidimensionnel comportant des faits (regroupant les mesures d activité) et différents axes appelés dimensions (Kimball, 1996). Les dimensions regroupent les paramètres d analyse organisés selon des hiérarchies. Une hiérarchie décrit différents niveaux de granularité entre les paramètres. Cette structure hiérarchique permet d analyser les données au travers du cube multidimensionnel (Gray et al., 1996). Le cube comporte les valeurs des mesures d activités agrégées suivant les différentes combinaisons de paramètres. L agrégation de données provenant des différentes sources intégrées présente un coût très important qui diminue les performances du système OLAP. Ainsi, l interrogation du cube est souvent améliorée par la matérialisation des vues (Gupta et al., 1999). Contrairement à une vue classique qui est calculée à chaque consultation à partir de la base, une vue matérialisée est une vue dont les données sont stockées dans la base. Le choix de ces vues présente un problème ; une vue matérialisée permet de diminuer le temps d interrogation mais elle nécessite un coût de rafraîchissement et de stockage. L'objet de notre article est de fournir un modèle de représentation des données OLAP intégrant un ensemble de contraintes sémantiques pouvant être exploitées lors du calcul des pré-agrégats afin d éliminer des combinaisons incohérentes et ainsi réduire le coût de construction et de maintenance des bases multidimensionnelles. 1.1 Exemple et problématique Une société commerciale souhaite analyser ses ventes en tenant compte des points de vente, des produits et du temps. Ce besoin se traduit par la modélisation d'une BDM contenant un sujet d'analyse (fait VENTES) et trois axes d'analyses (dimensions TEMPS, PRODUITS et MAGASINS). En respectant le formalisme défini par (Golfarelli et al., 1998), nous obtenons le schéma suivant ; All Annee Mois Jour IdT TEMPS fait mesures hiérarchie VENTES Division Category Rayon Subcategory IdP PRODUITS dimension montant bénéfice Dept_n Dept lib Region attribut faible paramètre IdM All MAGASINS State Pays All ZoneG RaisonS Figure 1 Représentation graphique d'une BDM (Golfarelli et al., 1998).

Un cube multidimensionnel (Gray et al., 1996) permet de visualiser les données d une BDM. Il présente les mesures de l analyse agrégées en fonction des différentes combinaisons des paramètres des dimensions. Il peut être représenté par un treillis (Harinarayan et al., 1996). Chaque nœud du treillis est une combinaison de paramètres des dimensions. Chaque lien pointe du nœud i vers le nœud j si j peut être calculé à partir de i. Par exemple, à partir d un nœud regroupant les ventes par magasin et par produit (IdM, IdP) nous pouvons calculer le nœud qui regroupe les ventes par magasin (IdM) (figure 2). All IdM IdT IdP IdM,IdT IdM, IdP IdM, IdT, IdP IdT, IdP Figure 2 Treillis du fait VENTES (Harinarayan et al, 1996) La construction de ce treillis est une étape préliminaire qui permet par la suite de sélectionner l ensemble des vues à matérialiser (Harinarayan et al., 1996) (Baralis et al., 1997). Dans notre exemple, la dimension MAGASINS est organisée selon trois hiérarchies ; "h_zone", "h_géo_fr" et "h_géo_us". La dimension PRODUITS est organisée en deux hiérarchies "h_nom_fr" et "h_nom_us" décrivant respectivement la nomenclature des produits français et celle des produits américains. La combinaison de ces deux dimensions hiérarchisées permet de construire un treillis qui combine deux à deux les hiérarchies des deux dimensions (Gupta et al., 1997) (Harinarayan et al., 1996). Cette combinaison donnera lieu à la définition de vues matérialisées incohérentes tel que la vue combinant le paramètre SubCategory caractérisant les produits américains et le paramètre Département caractérisant un magasin français. A notre connaissance, ce problème n a pas été traité par aucun des travaux antérieurs. 1.2 Travaux existants Dans le cadre de la modélisation des BDM, plusieurs travaux ont proposé des schémas multidimensionnels qui se basent sur les concepts de fait et de dimension (Kimball, 1996). Les faits sont composés de mesures d'activité et les dimensions comportent des paramètres organisés en hiérarchies. Certains modèles intègrent une représentation explicite des hiérarchies (Li et al., 1996) (Lehner, 1998). D'autres modèles prennent en compte des objets à structures complexes avec des hiérarchies multiples (OOLAP) (Pedersen et al., 1999) et intègrent la gestion du temps (Mendelzon et al., 2000). Cependant, aucun de ces modèles ne gèrent les incohérences qui peuvent survenir sur les données de la BDM. A notre connaissance, seul (Hurtabo et al., 02) propose d intégrer un ensemble de contraintes entre les hiérarchies d une même dimension résolvant partiellement le problème des incohérences qui peuvent exister entre les hiérarchies de différentes dimensions.

Au niveau de l implantation des BDM, plusieurs travaux se focalisent sur le problème de sélection des vues matérialisées. (Harinarayan et al., 1996) propose un algorithme qui sélectionne un ensemble de vues à matérialiser dans le but de minimiser le coût total d interrogation. Il introduit la notion de treillis multidimensionnel. (Gupta et al., 1999) étend ces travaux par l introduction des index qui permettent d optimiser le calcul des requêtes. (Baralis et al., 1997) propose un algorithme qui intègre explicitement la structure hiérarchique des dimensions. (Theodoratos et al., 1999) suggère d intégrer les facteurs de qualité dans le processus de construction des BDM. (Kotidis et al, 2001) propose le système Dynamat qui sélectionne dynamiquement l'ensemble optimal des vues à matérialiser. L évolution de ces vues est en fonction des requêtes OLAP et de l espace disponible. 1.3 Contributions et organisation de l article Notre contribution est structurée en deux points : l extension de la définition du schéma multidimensionnel en intégrant l expression des contraintes sémantiques afin d offrir une information fiable aux décideurs manipulant la BDM (Hurtabo et al., 2002) (Ghozzi et al., 2003), l intégration de ces contraintes dans le processus de sélection des vues matérialisées afin de ne garder dans le processus de sélection que les vues cohérentes qui ne violent pas l intégrité des contraintes sémantiques exprimées dans le modèle. Cet article s articule autour de trois sections. Une première section présente les concepts inhérents à notre modèle multidimensionnel et les contraintes sémantiques intégrées dans ce modèle. Une deuxième section présente l approche des vues matérialisées basée sur le concept de treillis multidimensionnel ainsi que l intégration des contraintes sémantiques dans le processus de construction de ce treillis. Une dernière section présente notre implantation du modèle multidimensionnel contraint et l apport de l intégration des contraintes sémantiques dans la construction du treillis. 2. Modèle multidimensionnel contraint Nous avons proposé un modèle multidimensionnel conceptuel à contraintes dans le cadre d un schéma en constellation (Ghozzi et al., 2003). Une constellation regroupe plusieurs sujets d'analyse (faits) étudiés selon différents axes d'analyses (dimensions) éventuellement partagés. Notre schéma en constellation intègre l expression de contraintes sémantiques inhérentes au modèle multidimensionnel.

2.1 Concepts de base Dans ce paragraphe, nous rappelons brièvement les définitions des concepts de base de notre modèle multidimensionnel. Définition.1 Une constellation C est définie par (N C, F C, D C, Star C, Cons C ) où N C est le nom de la constellation, F C est un ensemble de faits, D C est un ensemble de dimensions, Star C : F C 2 DC est une fonction associant les faits aux dimensions afin de spécifier les sujets d'analyses et les axes d'étude associés, Cons C représente l ensemble des contraintes associées à la constellation. L exemple de la figure 1 présente une constellation comportant un seul fait VENTES analysé selon trois dimensions : TEMPS, MAGASINS et PRODUITS. Définition.2 Un fait F est défini par (N F, M F, I F ) où N F est le nom du fait, M F est un ensemble de mesures, I F est l'ensemble des instances de F. Une instance est définie par le n-uplet [a 1 :v 1, a 2 :v 2,, a w :v w ] où k [1..w], a k M F v k est une valeur. Dans notre exemple, le fait VENTES regroupe les mesures d activité montant et bénéfice. Définition 3. Une dimension D est définie par (N D, P D, H D, I D ) où N D est le nom de la dimension, P D est un ensemble de paramètres, H D est un ensemble de hiérarchies et I D est l'ensemble des instances de D. Une instance est définie par le n- uplet [a 1 :v 1, a 2 :v 2,, a u :v u ] tel que k [1..u], a k P D v k est une valeur. Nous pouvons compléter la représentation graphique de la dimension MAGASINS (figure 1), par la définition suivante (schéma et 2 instances) : ( MAGASINS, {IdM, Dept_n, Dept_lib, Region, State, Pays, ZoneG, RaisonS, All}, {h_geo_fr, h_geo_us, h_zone}, {I MAGASINS 1, I MAGASINS 2}) avec I MAGASINS 1=[IdM : oid2, Dept_n : 31, Dept_lib : Hte-Garonne, Region : Midi- Pyrénées, State : NULL, Pays : France, ZoneG : SO, RaisonS : magasin 1, All : all ], I MAGASINS 2=[IdM : oid7, Dept_n : NULL, Dept_lib : NULL, Region : NULL, State : Texas, Pays : USA, ZoneG : SE, RaisonS : magasin 2, All : all ]. Définition 4. Une hiérarchie h D i est un chemin élémentaire acyclique débutant par Id et se terminant par All et se définit par (N h, Param h, Suppl h, Cond h ) où N h est le nom de la hiérarchie, Param h : P P (P P D ) est une fonction décrivant la hiérarchie des attributs, Suppl h : P 2 PD-P est une fonction décrivant l'ensemble des attributs faibles associés à chaque paramètre, Cond h est une expression booléenne définissant la condition d'appartenance des instances de la dimension à une hiérarchie. Les trois hiérarchies de la dimensions MAGASINS sont définies ainsi : h_geo_fr=( géo. française, (Param h_geo_fr (IdM) = Dept_n, Param h_geo_fr (Dept_n) = Region, Param h_geo_fr (Region) = Pays, Param h_geo_fr (Pays) = All),

(Suppl h_geo_fr (IdM) = {RaisonS}, Suppl h_geo_fr (Dept_n) = {Dept_lib}), dom(pays) { France }), h_geo_us=( géo. américaine, (Param h_geo_us (IdM) = State, Param h_geo_us (State) = Pays, Param h_geo_us (Pays) = All), (Suppl h_geo_us (IdM) = {RaisonS}), dom(pays) { USA }), h_zone=( géo. en zones, (Param h_zone (IdM) = ZoneG, Param h_zone (ZoneG) = Pays, Param h_zone (Pays) = All), (Suppl h_zone (IdM) = {RaisonS}), dom(zoneg) {'S', 'E', 'O', 'N', 'C', 'SO', 'SE', 'NO', 'NE'}). La spécificité de multi-instanciation de notre modèle réside dans l intégration d une condition d appartenance des instances de la dimension aux hiérarchies. Ainsi, l instance {I MAGASINS 1} appartient à "h_geo_fr" tandis que {I MAGASINS 2} appartient à "h_geo_us" et {I MAGASINS 1, I MAGASINS 2} appartiennent à "h_zone". 2.2 Contraintes multidimensionnelles Dans le cadre des BDM, plusieurs types de contraintes peuvent êtres identifiés ; les contraintes de démarche, les contraintes d accès, les contraintes syntaxiques et sémantiques liées au modèle. Cet article se focalise sur les contraintes sémantiques. Ces contraintes agissent sur les processus d interrogation et de manipulation des données. Les contraintes sémantiques sont liées à la structure hiérarchique des dimensions et au contexte d analyse. Ces contraintes sont définies lors de la construction d un modèle multidimensionnel. Nous définissons deux familles de contraintes sémantiques selon la portée de ces contraintes : Contraintes sur les instances d une dimension : Contrainte d exclusion : L'exclusion entre deux hiérarchies h 1 et h 2 de D traduit qu'une instance de D appartenant à h 1 n'appartient pas à h 2 et réciproquement. Exemple: L exclusion entre les hiérarchies "h_géo_us" et "h_géo_fr", implique que les instances de la dimension MAGASINS appartenant à la première hiérarchie ne vérifient pas la condition d appartenance à "h_géo_fr". Contrainte d inclusion : L'inclusion d'une hiérarchie h 1 de D dans h 2 de D indique que toutes les instances de h 1 appartiennent à h 2. Exemple: L inclusion de la hiérarchie "h_géo_fr" dans "h_zone", indique que toute les instances vérifiant la condition d appartenance à "h_géo_fr" sont impérativement des instances de la hiérarchie "h_zone". Contrainte de totalité : La totalité entre deux hiérarchies h 1 et h 2 de D traduit qu'une instance de D appartient à h 1 ou à h 2. (Ou inclusif). Elle indique que toutes les instances de la dimension sont des instances de l une des hiérarchies. Exemple: La totalité entre les hiérarchies "h_géo_us" et "h_géo_fr", implique que l union des instances de ces deux hiérarchies forment la totalité des instances de la dimension MAGASINS.

Contrainte de partition : La partition entre deux hiérarchies h 1 et h 2 de D traduit qu'une instance de D appartient obligatoirement soit à h 1 soit à h 2. (Ou exclusif). L obligation traduit une contrainte de totalité puisque toutes les instances de la dimension appartiennent à l une des deux hiérarchies. Exemple: Une contrainte de partition entre les hiérarchies "h_géo_us" et "h_géo_fr", implique que l intersection des instances des deux hiérarchies est vide (exclusion) et que l union de ces instances forme la totalité des instances de la dimension MAGASINS (totalité). Contraintes sur les instances du fait : Contrainte d exclusion : L'exclusion entre deux hiérarchies h 1 d'une dimension D 1 et h 2 d'une dimension D 2 indique qu'une instance du fait (relié à D 1 et à D 2 ) ne peut être associée simultanément aux instances de h 1 et h 2. Exemple : L exclusion entre les hiérarchies "h_nom_us" et "h_géo_fr", implique que les instances du fait VENTES reliées à la première hiérarchie ne sont pas en relation avec les instances de la hiérarchie "h_géo_fr". Contrainte d inclusion : L inclusion d une hiérarchie h 1 d'une dimension D 1 dans une hiérarchie h 2 de D 2 indique que les instances du fait (relié à D 1 et D 2 ) manipulées au travers de h 1 sont un sous-ensemble des instances du fait associées à h 2. Exemple : L inclusion de la hiérarchie "h_nom_us" dans la hiérarchie "h_zone", implique que les instances du fait VENTES reliées à la première hiérarchie sont en relation avec les instances de la hiérarchie "h_zone". Contrainte de totalité : La totalité entre deux hiérarchies h 1 d'une dimension D 1 et h 2 d'une dimension D 2 indique que chaque instance du fait (relié à D 1 et à D 2 ) est associée aux instances de h 1 ou à celles de h 2 (ou inclusif). Exemple : La contrainte totalité entre la hiérarchie "h_nom_us" et la hiérarchie "h_géo_fr, implique que l union des instances du fait VENTES reliées à la première hiérarchie et celles reliées à la deuxième hiérarchie représente la totalité des instances du fait. Contrainte de partition : La partition entre deux hiérarchies h 1 d'une dimension D 1 et h 2 d'une dimension D 2 indique que chaque instance du fait est associée soit aux instances de h 1 soit à celles de h 2 (ou exclusif). Une contrainte de partition est l union des deux contraintes exclusion et totalité. Exemple : Entre les hiérarchies "h_nom_us" et "h_géo_fr", nous avons défini deux contraintes d exclusion et de totalité. Ces deux contraintes réunies expriment une contrainte de partition. 3. Treillis multidimensionnel et contraintes Une vue est une relation dérivée (virtuelle) construite à partir d autres relations de la base de données. Une vue définie ainsi est calculée à chaque fois qu elle est

appelée. Une vue matérialisée est une vue dont les données sont stockées dans la base. Dans nos travaux, l objectif d une vue matérialisée est d effectuer un calcul de pré agrégats afin d obtenir de meilleures performances en matière de temps de réponse. Une gestion dynamique de ces vues permet d ajouter ou d enlever des vues matérialisées ; leur stockage est temporaire en fonction de l évolution de l analyse. Un treillis de type ET, défini sur l ensemble des vues V, est un graphe acyclique dont les nœuds sont les vues v de V. Un Lien part de l ensemble des nœuds v 1, v 2, v n, vers le nœud v i si v i peut être calculé à partir de l ensemble v 1, v 2, v n et cette dépendance est présentée par un demi-cercle à travers les liens (v i, v 1 ), (v i, v 2 ) (v i, v n ), appelée arc ET. Un treillis de type ET-OU, est un graphe acyclique dont les nœuds sont les vues v de V. Chaque nœud peut avoir un ou plusieurs Arc ET qui le relie aux autres nœuds à partir des quels il peut être calculé. 3.1 Treillis multidimensionnel Soit V l ensemble des vues possibles en combinant les paramètres des dimensions d un fait. Pour chaque fait de notre constellation, nous pouvons définir un treillis multidimensionnel de vues v V de type ET-OU. Nous proposons de construire le treillis en se basant sur la structure hiérarchique (Harinarayan et al., 1996) afin d inclure la sémantique des hiérarchies. La construction du treillis multidimensionnel est basée sur la notion de dépendance fonctionnelle (DF) entre les paramètres d une hiérarchie. En effet, si nous considérons deux attributs ai et aj et que aj dépend fonctionnellement de ai, notée ai aj, (ai détermine aj) alors le regroupement des données selon ai donne le même résultat que le regroupement selon le couple (ai, aj). Par exemple, regrouper les ventes par région et par pays donne le même résultat qu un regroupement par région puisque une région détermine le pays. Ainsi, un nœud du treillis est défini comme suit : Définition 5 Un nœud N P appartenant au treillis multidimensionnel, représentant une vue v, est défini par l ensemble de ses paramètres P comportant les attributs de regroupement de la vue v et tel qu il n existe pas de dépendance fonctionnelle entre les paramètres de P. En se basant sur cette définition, l algorithme de construction du treillis simplifie les nœuds combinant des attributs de la même hiérarchie. Algorithme ConstructionTreillis Entrée : Ax : un nœud du treillis Avec : Structure Nœud : Racine : liste des paramètres, LFils = liste des fils du nœud. LPere_ET : pères reliés par un arc ET. ListeNoeud : Liste des nœuds déjà construits. Sortie : Liste des nœuds du treillis construit Pour chaque Pi Ax.Racine Faire Lp Ax.Racine - {Pi}; Lp Lp + Param (Pi) ; Lp Epurer (Lp) ; Az ChercheNoeud (Lp,ListeNœud) Si (Az= nul) Alors

Az.Racine Lp ; ListeNœud ListeNœud + Az ; ListeNœud ConstructionTreillis (Az, ListeNœud); FinSi Ax.LFils Ax.LFils +Az ; Retourner (ListeNœud) FinConstructionTreillis Param (Paramètre : p) récupère la partie droite des dépendances fonctionnelles p a. ChercheNoeud (Lp, ListeNœud) Cherche le nœud de racine Lp dans ListeNœud Algorithme Epurer Entrée : Liste de paramètres. Sortie : Liste de paramètres épurés. Pour chaque Pi Lp Faire Pour chaque Pj Lp- Pi Faire Si (Pj Dépend(Pi)) Alors Lp Lp Pi ; Retourner (Lp) ; FinEpurer Dépend(Pi) récupère les paramètres qui dépendent fonctionnellement de Pi. Figure 3 Algorithme de création d un treillis sans contrainte Dans l exemple de la figure 1, nous avons combiné les paramètres de la dimension MAGASINS. Le treillis généré sans intégration des contraintes (Baralis et al., 1997) est présenté par la figure 4. Dans ce treillis, la combinaison entre les différents paramètres pour réaliser les vues multidimensionnelles ne tient pas compte des contraintes entre les hiérarchies. Les vues visualisant les ventes selon les paramètres Depart et State ou Région et State ne peuvent pas exister car une contrainte d exclusion est définie entre la hiérarchie de la géographie française et celle de la géographie américaine. Région Depart Depart, Zone_G Région, Zone_G All Pays State Depart, State IdM Région, State Depart, State, Zone_G Zone_G State, Zone_G Région, State, Zone_G Figure 4 Treillis des Ventes selon la dimension Magasin (Baralis et al, 1997 En outre, la vue qui décrit les montants des ventes pour chaque pays peut être extraite à partir des vues matérialisées regroupant les montants des ventes par région, état ou zone géographique. Sans considération des contraintes entre les instances des hiérarchies, nous n aurons pas d informations sur la complétude de cette vue. En effet, regrouper les montants des ventes par pays à partir du paramètre région ne donne qu une partie des instances de la dimension, puisque le paramètre région ne concerne que les ventes réalisées en France. Par contre, le passage du paramètre zone vers pays permet de calculer les montants des ventes pour toutes les instances de la dimension MAGASINS. L introduction des contraintes sur les instances de la dimension permet d enlever cette ambiguïté.

3.2 Intégration des contraintes Pour intégrer les contraintes, nous modifions l algorithme de construction de treillis en validant chaque nœud avant de l insérer dans le treillis. La validation est basée sur les contraintes définies sur les instances des faits et des dimensions. Définition 6. Un Nœud N P est Valide en considérant l ensemble des contraintes C, s il n existe pas un couple de paramètres (pi, pj) appartenant à P x P qui sont en exclusion. Définition 7. Deux paramètres Pi et Pj P sont en exclusion si toutes les hiérarchies h n passant par Pi sont en exclusion (ou en partition) avec toutes les hiérarchies h m passant par Pj. Algorithme ValiderNœud Entrée : Un nœud Ax Sortie : Vraie si le nœud est valide, sinon faux. Lp Ax.Racine ; Valide Vraie ; i 0 ; Tant que Valide et i< taille (Lp) Faire Pi Lp[i]; j i+1 ; Tant que (Valide et j< taille(lp)) Faire Pj Lp[j] ; Valide ExclusionP (Pi, Pj); Retourner (Valide) ; FinValiderNœud Algorithme ExclusionP Entrée : Deux paramètres Pi et Pj Sortie : Vraie si Pi et Pj sont en exclusion, sinon faux. Vraie ou faux. Lhi les hiérarchies passant par Pi ; Lhj les hiérarchies passant par Pj ; p 0 ; Valide = Faux ; Tantque non Valide et p< taille (Lhi) Faire hp Lhi [p] ; q 0 ; Tant que non Valide et q <taille (Lhj) Faire hq Lhj [q] ; Si ((Exclusion(hq, hp)) = Faux) Alors Valide Vraie; retourner (Valide) ; FinExclusionP Figure 5 Algorithme de validation des contraintes des nœuds du treillis Ce premier algorithme (figure 5) permet d enlever de "ListeNoeud" les nœuds représentant des vues qui ne respectent pas les contraintes de validité. Dans l exemple que nous avons présenté, nous proposons de modifier le treillis afin de tenir compte des contraintes sur les instances de la dimension MAGASINS. Pour obtenir le treillis valide, il faut enlever les liens vers les nœuds fils supprimés du treillis et les remplacer par des liens qui pointent vers des nœuds fils valides.

Algorithme ValiderLiens Entrée : Liste des nœuds du treillis Sortie : Treillis avec des liens valides. Pour chaque nœud Ax ListeNœud Faire Pour chaque nœud Af Ax.LFils Faire Si Af ListeNœud Alors Ax.LFils Ax.LFils Af ; Ax.LFils Ax.LFils + Af.LFils ; FinSi Pour chaque nœud Ax ListeNœud Faire Pour chaque Af1 Ax.LFils Faire Pour chaque Af2 Ax.LFils Af1 Faire Si Af2 petitfils(af1) Alors Ax.LFils Ax.LFils Af2; Si Af1 petitfils(af2) Alors Ax.LFils Ax.LFils Af1; //Construction des arcs ET. Pour chaque Ap1 Pere(Ax) Faire Pour chaque Ap2 Pere(Ax) Ap1 Faire Si (ExclusionN(Ap1, Ap2) ) Alors Ajouter {Ap1, Ap2} à Ax.LPere_ET; FinSi FinValiderLiens Algorithme ExclusionN Entrée : Deux nœuds Ni et Nj. Sortie : Vraie si Ni et Nj sont en exclusion, sinon faux. Li Ni.Racine ; Lj Nj.Racine ; Valide Vraie ; i 0 ; Tant que Valide et i< taille(li) Faire Pi Li[i] ; j 0 ; Tant que Valide et j< taille (Lj) Faire Pj Lj[j]; Valide ExclusionP (Pi, Pj); Retourner(Valide) ; FinExclusionN petitfils(af) : récupère les petits fils du nœud Af dans le treillis. Pere(Ax) :récupère les nœuds pères de Ax. Figure 6 Algorithme de reconstruction des liens intégrant les contraintes Le deuxième algorithme (figure 6) permet de reconstruire les liens entre les nœuds valides du treillis multidimensionnel et d ajouter les arcs ET. La figure 7 décrit les différentes étapes du reconstruction des liens par cet algorithme. All Pays All Pays All Pays Région State Zone_G ET Depart Région, Zone_G Région, State State, Zone_G Région State Zone_G Région State Zone_G Depart, Zone_G Depart, State Région, State, Zone_G Depart Région, Zone_G State, Zone_G Depart Région, Zone_G State, Zone_G Depart, State, Zone_G Depart, Zone_G Depart, Zone_G IdM IdM IdM Figure 7 Treillis de la dimension MAGASIN intégrant les contraintes

La vue regroupant les ventes par pays est calculée soit à partir de la vue regroupant les ventes par ZoneG soit à partir de l union des ventes par State et par Région. La notation ET indique que l union de ces deux vues permet de retrouver la vue globale regroupant les ventes par pays. Ce treillis intègre la contrainte d exclusion entre les hiérarchies Géographique américaines et française, ainsi, il ne combine pas les deux paramètres State et Depart en une seule vue (de même pour State et Région). La combinaison entre les paramètres Depart et ZoneG, d un coté, et State et ZoneG, de l autre, est permise donnant lieu à deux nouvelles vues possibles pour les ventes. Le traitement que nous avons réalisé au niveau d une seule dimension est applicable au niveau d un fait entre les hiérarchies de différente dimensions. Dans notre exemple (figure 1), deux contraintes d exclusion sont définies entre les hiérarchies h_nom_fr et h_géo_us, d une part, et les hiérarchies h_nom_us et h_géo_fr, d autre part. L intégration de ces contraintes dans le treillis des ventes selon les dimensions MAGASINS et PRODUITS permet d enlever 92 nœuds invalides (voir figure 9). 4. Implantation du treillis multidimensionnel Le problème fondamental de la sélection des vues est de trouver l ensemble des vues à matérialiser qui maximise les performances de la bases de données multidimensionnelles lors de l interrogation. Le but de cette analyse est de comparer le résultat réalisé en construisant le treillis de vues à matérialiser sans considération des contraintes sémantiques avec celui obtenu en intégrant ces contraintes. En effet, les vues qui ne satisfont pas les contraintes sémantiques du modèle multidimensionnel n apportent pas de gain au temps d interrogation des requêtes OLAP. Prenons l exemple de la vue v combinant les ventes par département français et états américains. En respectant la contrainte d exclusion entre la hiérarchie de la géographie française et celle de la géographie américaine, la vue v est vide. Supposons que cette vue contient des données, alors la BDM est incohérente car la contraintes d exclusion n est pas satisfaite. L élimination de ces vues réduit considérablement la taille du treillis multidimensionnel sur lequel se base les techniques d optimisation de la sélection des vues matérialisées (Baralis et al., 1997) (Gupta et al., 1999) et de réécriture de requêtes OLAP (Park et al., 2001). La taille du treillis T dépend du nombre d attributs dans les dimensions et plus particulièrement dans les hiérarchies. Sans considération des contraintes T est calculée comme suit : T = Π h i=1 n i Avec n i le nombre d attributs dans la hiérarchie i et h le nombre de hiérarchies combinées dans le treillis. L intégration des contraintes réduit cette taille en enlevant les combinaisons incohérentes.

4.1 Implantation des contraintes Afin de valider nos propositions, nous avons développé un prototype, appelé GEDOOH. Il comporte une interface graphique qui permet à l administrateur de définir les schémas des BDM et produit automatiquement au travers du générateur les scripts de création et d alimentation de ces BDM. Pour ce faire, l ensemble des définitions sont entreposées dans un référentiel de méta-données. Après avoir défini les composants d un schéma de la BDM, l administrateur peut spécifier les contraintes intra- et/ou inter-dimensions. Cette définition est réalisée en sélectionnant l option de création d une contrainte afin d obtenir la boîte de dialogue de la figure 8 ; l administrateur doit sélectionner ensuite les hiérarchies et la contrainte appliquée. Figure 8 Interface de définition d'une contrainte d'exclusion intra-dimension La définition d une contrainte sur les hiérarchies induit une mise à jour du référentiel et une vérification des conflits possibles entre les contraintes ; cette vérification permet par exemple d interdire la création d une contrainte d exclusion et d une contrainte d inclusion entre les mêmes hiérarchies. 4.2 Treillis multidimensionnel intégrant les contraintes Le prototype intègre les contraintes sémantiques, stockées dans le référentiel de méta données, dans l algorithme de construction du treillis multidimensionnel. Nous avons pris l exemple de la BDM exposée dans la figure 1. Dans cet exemple, nous avons construit les treillis multidimensionnels en combinant les différentes dimensions sans intégrer les contraintes afin de relever le nombre de vues de chaque treillis. Puis, nous avons intégré les contraintes à l aide de notre interface et nous avons construit de nouveau l ensemble des treillis possibles (voir figure 9). Taille du treillis multi dimensionnel PRODUITS MAGASINS TEMPS PRODUITS, MAGASINS PRODUITS, TEMPS MAGASINS, TEMPS PRODUITS, MAGASINS, TEMPS Sans contraintes 10 14 5 140 50 70 700 Avec contraintes 6 10 5 48 30 50 240 Figure 9 Tableau comparatif de la taille du treillis multidimensionnel.

La diminution du nombre de vues dans le treillis multidimensionnel simplifie sa manipulation. La recherche d un nœud représentant une vue à matérialiser devient moins coûteux et plus facile. Si nous reprenons l exemple du treillis combinant les ventes selon les dimensions PRODUITS et MAGASINS, nous passerons d un treillis de 140 nœuds sans considérer les contraintes (figure 10 (a)) vers un treillis de 48 nœuds après intégration des contraintes sémantiques (figure 10 (b)). (a) avant intégration des contraintes (b) après intégration des contraintes Figure 10 Treillis combinants les dimensions PRODUITS et MAGASINS

5. Conclusion Cet article étudie l intégration des contraintes sémantiques dans les treillis multidimensionnels. Ces contraintes sont définies dans un modèle de données en constellation qui assure une plus grande cohérence des données par sa propriété de multi-instanciation. Nous distinguons les contraintes intra-dimension qui portent sur les hiérarchies d une même dimension, des contraintes inter-dimensions qui s appliquent entre les hiérarchies de dimensions distinctes. L intégration de ces contraintes dans le processus de construction des treillis multidimensionnels permet d enlever toutes les vues incohérentes, ne satisfaisant pas les contraintes, et de réduire la taille de ces treillis. L intégration de ces contraintes dans le modèle multidimensionnel est réalisée à l aide de notre prototype GEDOOH, développé au sein de notre équipe. Une extension de ce prototype a permis d utiliser les contraintes lors de la construction des treillis multidimensionnels. L intégration des contraintes a permis de tenir compte de la sémantique de la BDM et de réduire la taille de ces treillis. Nous envisageons de poursuivre cette étude en analysant l implication des contraintes dans le processus d interrogation des requêtes OLAP. Pour cela nous envisageons de proposer un ensemble d opérateurs multidimensionnels qui intègrent la sémantique des contraintes et d utiliser le treillis multidimensionnel pour répondre à ces requêtes. 6. Bibliographie (Baralis et al, 1997) Baralis E., Paraboschi S., Teniente E., «Materialized Views Selection in a Multidimensional Database», Proceedings of the 23rd VLDB Conference Athens, Greece, 1997. (Codd, 1993) Codd E.F., «Providing OLAP (on-line analytical processing) to user-analysts : an IT mandate», Technical Report, E.F. Codd and Associates, 1993. (Ghozzi et al, 2003)Ghozzi F., Ravat F., Teste O., Zurfluh G., «Modèle Multidimensionnel à Contraintes», Revue des Sciences et Technologies de l'information, Série RIA-ECA, Volume 17, n1-2-3/2003. (Golfarelli et al, 1998) Golfarelli M., Maio D., Rizzi S., «Conceptual design of Data Warehouse from E/R Schemas», Proceeding of the 31 st Hawaii International Conference on System Sciences, Kona (Hawaii, USA), 1998. (Gray et al, 1996) Gray J., Bosworth A., Layman A., Pirahesh H., «Datacube: A Relational Operator Generalizing Group-By, Cross-Tab and Sub-Total», Proceeding of the 12 International Conference on Data Engineering, pp 152-159, 1996. (Gupta et al, 1997) Gupta H., Harinarayan V, Rajaraman A., «Index selection for OLAP», 13th International Conference on Data Engineering Birmingham, U.K April 07-11, 1997..

(Gupta et al, 1999) Gupta H., Mumick I., S., «Selection of view to materialize under a maintenance cost constraint», 7th International Conference Database Theory - ICDT '99, Jerusalem, Israel, January 10-12, 1999. (Harinarayan et al, 1996) Harinarayan V., Rajaraman A., Ullman J. «Implementing Data Cubes Efficiently» Proceedings of the 1996 ACM SIGMOD Conference, Monreal 1996. (Hurtabo et al, 2002) Hurtado C., Mendelzon A., «OLAP Dimension Constraints», PODS 2002, Madison, June 2002 (Kimball, 1996) Kimball R., «The data warehouse toolkit», John Wiley and Sons, 1996. (Kotidis et al, 2001) Kotidis Y., Roussopoulos N., «A case for dynamic view management», Database Systems journal, volume 26 n 4, p 388-423, 2001. (Lehner, 1998) Lehner W., «Modeling Large Scale OLAP Scenarios», 6th International Conference on Extending Database Technology (EDBT'98), Valence (Espagne), 23-27 Mars 1998. (Li et al, 1996) Li C., Wang X. S., «A Data Model for Supporting On-Line Analytical Processing», 5th International Conference on Information and Knowledge Management -ACM CIKM'96, Novembre 1996. (Mendelzon et al, 2000) Mendelzon A, Vaisman A., «Temporal Queries in OLAP», VLDB 2000, Caire (Egypte), Septembre 2000. (Park et al, 2001) Park C. S., Kim M. H., Lee Y. J. «Rewriting OLAP Queries Using Materialized Views and Dimension Hierarchies in Data Warehouses», 17th International Conference on Data Engineering, April 02-06, 2001 Heidelberg, Germany. (Pedersen et al, 1999) Pedersen T. B., Jensen C. S., «Multidimensional Data Modeling for Complex Data», ICDE' 99. (Theodoratos et al, 1999) Theodoratos D., Bouzeghoub M., «Data Currency Quality Factors in Data Warehouse Design», Proceedings of the International Workshop on Design and Management of Data Warehouses (DMDW 99), Heidelberg, Germany, 14. - 15.6. 1999.