Mise à jour incrémentale des agrégats

Mise à jour incrémentale des agrégats Cas des indicateurs ROLAP dans les entrepôts de données Mohamed Badri*, Véronique Heiwy* et Faouzi Boufarès** * CRIP5, IUT de Paris Descartes Département informatique 143 Avenue de Versailles 75016 Paris ** LIPN, IUT de Villetaneuse Département informatique 99, avenue Jean-Baptiste Clément 93430 VILLETANEUSE 143 Avenue de Versailles 75016 Paris {badri, heiwy}@univ-paris5.fr ; boufares@iutv.univ-paris13.fr Sections de rattachement : 27 Secteur : Tertiaire RÉSUMÉ. Les entrepôts de données subissent continuellement des mises à jour afin d intégrer de nouvelles données, ce qui implique l actualisation de son contenu et également celle des indicateurs qui sont gérés par des vues matérialisées. Les outils de gestion des entrepôts offrent des performances limitées en matière de maintenance des agrégats. Dans cet article, nous présentons une méthode de calcul incrémentale pour l actualisation des indicateurs décisionnels (agrégats) ROLAP stockés dans les vues matérialisées. ABSTRACT. The data warehouses are often updated to integrate new data wich implies aggregates updating. These aggregates are managed by materialized views. Warehouses tools offer limited performance in maintaining aggregates. In this paper, we present a method for incremental maintenance of ROLAP indicators (aggregates) stored in materialized views. MOTS-CLÉS : Maintenance incrémentale, indicateurs ROLAP, agrégats, entrepôt de données KEYWORDS: Incremental maintenance, ROLAP indicators, aggregates, data warehouse

1. Introduction Aujourd hui avec la mondialisation des marchés et des économies l entreprise évolue dans un environnement de plus en plus vaste, de plus en plus concurrentiel et doit faire face à des risques et des contraintes toujours plus grands. L entreprise collecte en permanence de nouvelles données, toujours en quête de nouvelles études et analyses. Toute cette masse de données est produite quotidiennement que ce soit par l entreprise elle même ou par son environnement. Pour aider et assister les décideurs dans leur processus de prise de décision, l entrepôt de données (ED) constitue de nos jours un élément incontournable. L objectif d un ED est d assembler toutes les "parties" qui constituent le système d information pour former ainsi une seule structure (masse) de données plus facile à manipuler, à exploiter et à gérer. L entrepôt est au coeur du système d information (SI) décisionnel [RAV 01]. L ED est une entité vivante, son contenu doit être alimenté et raffraîchi en continu. L actualisation des indicateurs d analyse est un facteur crucial pour la prise de décision. Dans certains domaines d application, des analyses sont réalisées plusieurs fois par semaine voire par jour. Où parfois un détail, une information donnée ou l évolution d un critère d analyse peut pèser sur la prise de décision (exemple de crise boursière ou de tension politique dans une région du monde). La maintenance a donc une place stratégique dans le dispositif de SI décisionnel, c est aussi un critère de performance pour un ED. En raison de l énorme masse de données manipulée et du temps de calcul important, dans ce type d application, la maintenance des ED est réalisée en mode différé (batch), généralement le soir ou pendant les week-ends. La lenteur du traitement est en réalité due à la méthode employée par les outils de gestion des entrepôts de données. En effet, l intégration de nouvelles données dans l ED est réalisée grâce à un recalcul complet de tous les indicateurs. Dans cet article, nous présentons une méthode de calcul incrémentale qui, à la suite à une mise à jour d un ED, permet de retrouver la nouvelle valeur d un indicateur sans avoir à le recalculer entièrement. Cette méthode a un côut moindre et s utilise à tout moment pour intégrer les flux de données entrant et actualiser en temps réel les indicateurs d analyse. Nous présentons vers la fin du papier des mesures de performance réalisées sur plusieurs instances d ED. Notre méthode de maintenance est comparée à celle du SGBD-OLAP Oracle 10g. 2. Les indicateurs dans les entrepôts de données Les indicateurs sont des instruments de mesure définis par l entreprise pour observer l évolution d un fait (prix de vente, prix de revient, cours d action, frais de mission, etc...) par rapport à un ensemble de dimensions (clients, produits, temps, magasins, fournisseurs, marchés, lieux, contrats, laboratoies, etc...). Dans le domaine des bases de données et des entrepôts de données, les indicateurs sont assimilés à des agrégats. Leur gestion est assurée par la couche (dite aussi moteur) OLAP (On-Line Analytical Processing) du système mis en place. Il peut s agir du ROLAP (Relational OLAP) où les agrégats sont alors stockés dans des relations appelées généralement vues matérialisées (VM) ou dans des tables spécifiques appelées Automatic Summary Tables (AST) dans certains systèmes (e.g. DB2 d IBM). Comme il peut s agir d une couche MOLAP (Multidimensional OLAP) où les agrégats sont stockés dans des structures 2

multidimentionnelles (hypercubes). A noter que d autres techniques existent aussi comme le H-OLAP (Hybrid-OLAP) ou le S-OLAP (Spatial-OLAP). Nous invitons le lecteur à voir [THO 02] pour plus de détails. Nous nous intéressons dans le cadre de ce travail au cas ROLAP. Un système décisionnel OLAP est constitué d un entrepôt de données et d une couche d analyse OLAP. Les mises à jour apparues au niveau source sont transférées vers l ED qui met à jour son contenu. Cette mise à jour de l entrepôt est par la suite véhiculée vers la couche OLAP où les indicateurs sont actualisés. Dans le cas du ROLAP, cette maintenance d indicateurs revient à maintenir les vues matérialisées. Ces structures sont largement utilisées dans les systèmes décisionnels relationnels aussi bien pour le stockage des données au niveau entrepôt que pour le stockage des indicateurs au niveau OLAP [BAD 06a, HAM 07]. La méthode présentée dans cet article porte sur la maintenance des indicateurs. Ces indicateurs OLAP sont généralement présentés graphiquement aux décideurs sous forme de tableaux à deux dimensions ou de cubes multidimentionnels. Ceci n a pas d incidence sur leur maintenance. 3. Calcul incrémental des fonctions d agrégats 3.1. Notions Les fonctions d agrégats appartiennent à des catégories différentes et ne sont pas toutes actualisées de la même manière. Dans la littérature [PAL 02, CHO 04] les auteurs les classent en trois groupes : - Les fonctions d agrégats distributives : Une fonction f est distributive si pour un groupe G, f(g) peut être calculée à partir des valeurs de f(g s ) où les groupes G s sont des sous-groupes de G. Exemple de fonctions distributives : COUNT ALL, MAX, MIN, SUM. - les fonctions d agrégats algébriques : Une fonction f est algébrique si pour un groupe G, f(g) peut être calculée à partir d un nombre connu d agrégats intermédiaires établis sur les sous-groupes G s. Dans les systèmes relationnels, les données supplémentaires sont généralement stockées dans des vues auxiliaires. Exemple de fonctions algébriques : AVG (Moyenne), VARIANCE, STDDEV (écart type). - et les fonctions d agrégats holistiques : Le nombre d agrégats intermédiaires n est pas connu. Et il n existe aucune méthode pour calculer ces agrégats de manière incrémentale. La seule méthode possible est celle qui explore les lignes de données. Ce type de fonction ne sera pas étudié dans le cadre de ce travail. Exemple de fonctions hotlistiques : COUNT DISTINCT, RANK (rang). En effet, étant donné deux ensembles A et B de valeurs entières la moyenne(a B) moyenne(moyenne(a), moyenne(b)) alors que max(a B) = max(max(a), max(b)). Notre objectif est de montrer comment réaliser certains calculs pour retrouver le résultat d une fonction d agrégats. Etant donnée un entrepôt de données w issu d une ou de plusieurs sources de données DB s avec s [1..b], soit T une serie de mises à jour provonant d une ou de plusieurs sources. Les composants de l ED (c 1, c 2,..., c n ) sont répartis sur une ou plusieurs relations (faits et dimensions) obtenus par notre algorithme de génération d ED [HAM 07]. L application de cet algorithme sur T donne w. Il s agit de la mise à jour de l entre- 3

pôt. Soit w t (respectivement w t) une version (respectivement la mise à jour) de l ED w à un instant t donné. L actualisation d un ED consiste à calculer un nouvel entrepôt (une nouvelle version) : w t = w t 1 w t. Les schémas logiques de l ED et de son évolution sont : w(c 1, c 2,..., c n ) et w (c 1, c 2,..., c n ). Considérons qu une vue matérialisée v, définie sur l entrepôt w, soit le résultat d une fonction de calcul d agrégats (i.e. indicateurs) sur w avec v = f(w). On peut donc calculer v (la VM issue de w ) de la même manière : v = f(w ). Soient : W = {w i, i 1} l ensemble des entrepôts calculés et V = {v i, i 1} celui de toutes les vues matérialisées calculées à partir de W. V A V est l ensemble de toutes les vues matérialisées appelées vues auxilaires. Soit f une fonction d agrégats définie par : f : W V ; f(w t ) = v t Sachant que : w t = w t 1 w t ; on peut donc écrire f(w t ) = f(w t 1 w t) = v t Selon les définitions données plus haut on peut écrire : - Il existe pour toute fonction distributive f : une fonction h : V V V ; h(v t 1, v t) = v t tel que f(w t 1 w t) = h(f(w t 1 ), f(w t)) f(w t ) = f(w t 1 w ) = h(f(w t 1 ), f(w t)) = h(v t 1, v t) = v t - Il existe pour toute fonction algébrique f : une fonction d agrégats g A : W V A ; g A (w t ) = vt A et une fonction h : V A V A V avec h(vt 1, A v t A ) = v t tel que f(w t 1 w t) = h A (g(w t 1 ), g(w t)) f(w t ) = f(w t 1 w ) = h(g A (w t 1 ), g A (w t)) = h(vt 1, A v t A ) = v t Dans la suite, nous démontrons ces égalités et donnons pour chaque opérateur d agrégat (comptage, moyenne, max, min, variance, etc...) la méthode de calcul incrémentale correspondante (c est-à-dire les fonctions g A et h). 3.2. Calcul des fonctions Soit un ensemble E i d éléments discrets tel que : E i = {x i1, x i2, x i3,..., x ipi } avec E i = p i sa cardinalité et X i sa moyenne arithmétique. n n n Et soit l ensemble E = E i, avec E i = et E = p i = P. f f(e) f(w t ) = h(f(w t 1 ), f(w t )) = h(v t 1, v t ) Count Count(E) = count(e i ) Count(w t ) = Sum(Count(w t 1 ), Count(w t )) = Sum(v t 1.a count, v t.a count) Min Min(E) = Min n (Min(E i)) Min(w t ) = Min(Min(w t 1 ), Min(w t )) (or Max) = Min(v t 1.a Min, v t.a Min ) Sum Sum(E) = Sum(E i ) Sum(w t ) = Sum(Sum(w t 1 ), Sum(w t )) Tableau 1. Exemples de calcul de fonctions distributives = Sum(v t 1.a Sum, v t.a Sum ) 4

f(e) Avg(E) = Sum(E i) count(e i ) V ar(e) = Count(E i) (V ar(e i) + Avg(E i) 2 ) Count(E i) 0 12 Sum(E i ) B @ C A Count(E i) f(w t) = h(g A (w t 1), g A (w t )) = h(va t 1, v A t ) Avg(w t) = Sum(Sum(w t 1), Sum(w t )) Sum(Count(w t 1 ), Count(w t )) = Sum(vA t 1.a sum, v A t.a sum) Sum(vt 1 A.a count, v t A.a count) V ar(w t) = X «2 1 X3 X 2 X 4 where : X 1 = Sum(Count(w t 1 )(V ar(w t 1 ) + Avg(w t 1 ) 2 ), Count(w t )(V ar((w t )) + Avg(w t )2 )) = Sum(v A t 1.acount(vA t 1.avar + va t 1.a2 avg ), v A t.a count(v A t.a var + v A t.a2 avg )) X 2 = Sum(Count(w t 1 ), Count(w t )) = Sum(v A t 1.a count, v A t.a count) X 3 = Sum(Sum(w t 1), Sum(w t )) = Sum(v A t 1.asum, v A t.asum) X 4 = Sum(Count(w t 1), Count(w t )) = Sum(v A t 1.a count, v A t.a count) Tableau 2. Exemples de calcul de fonctions algébriques 4. Expérimentations Nous avons utilisé Oracle 10g sous Linux Ubuntu 7.10 sur une machine AMD Athlon XP 1500 Mhz 512 Mo de RAM. D abord sans aucun chemin d accès rapide aux données, puis en créant des index (bitmap et b-tree) et des partitions horizontales. 4.1. Exemple d application : L entrepôt Gescom Etant données les deux sources d une entreprise de distribution pour sa gestion commerciale : Gescom1 une base de données relationnelle gérée avec le SGBD DB2 et Gescom2 une BD relationnelle-étendue gérée avec Oracle. Elles sont décrites par les schémas relationnels ci-dessous. Remarquons que les types de données ne sont pas les mêmes et que l attribut catégorie du client n existe pas dans Gescom2. Gescom1 : PRODUITS(REFART,NOMART,PVART,QTSTKART); CLIENTS(CODCLI,CIVCLI,CATCLI,ADNCLI,ADRCLI,CPCLI,VILCLI,PAYSCLI); COMMANDES(NUMCOM,#CODCLI,#CODSITE,DATCOM); LIGNE_CDE(NUMCOM,REFART,QTCOM,PUART,REMISE); SITES(CODSITE,ADRSITE,VILLESITE,PAYSSITE); 5

Gescom2 : ARTICLES(REFART,NOMART,PVART); CLIENTS(CODCLI,CIVCLI,NOMCLI,PRENCLI,ADNCLI,ADRCLI,ADVCLI); COMMANDES(NUMCOM,#CODCLI,#CODMAG,DATCOM); DETAILCOM(NUMCOM,REFART,QTCOM,PUART); MAGASINS(CODMAG,NOMMAG,ADNMAG,ADRMAG,ADVMAG); L ED devra permettre d analyser les ventes (chiffre d affaires, nombre d articles, Quantités vendues, moyenne,...) par catégorie de clients, par ville et par période. Les composants de l ED sont CATEGORIE, VILLE, PAYS, NOMARTICLE, FAMILLEART, DATCOM, SEMAINE, MOIS, ANNEE, QUANTITE, PRIXU. Les clés primaires et étrangères (CODCLI, REFART, NUMCOM) sont implicites. L objectif étant de faire de l analyse multi-dimentionnelle. Le script de création de l ED, produit par l algorithme ConstruitVue de notre prototype HDI (Heterogeneous Data Integration) présenté dans [HAM 07], donne le schéma relationnel ci-dessous. Les tables de dimensions : W_D_CLIENTS (CODCLI, CATEGORIE, VILLE, PAYS) W_D_ARTICLES (REFART, NOMART, FAMILLEART) W_D_COMMANDES (NUMCOM, DATCOM, SEMAINE, MOIS, ANNEE). La table de faits : W_F_VENTE (CODCLI,REFART,NUMCOM,QUANTITE,PRIXU). 4.2. Création des VM Nous avons créé plusieurs vues matérialisées avec différentes expressions de regroupement en utilisant Group by Cube, Group by Rollup et Group by Grouping sets. Dans le cadre de ce papier nous ne présentons que les résultats du calcul la VM Group by Cube. Les fonctions suivantes ont été calculées et stockées dans cette VM : Sum, Avg, Min, Max, Variance, Stddev, Count. Vue matérialisée d agrégats gérée par Oracle : CREATE MATERIALIZED VIEW VM_ORA REFRESH COMPLETE ON DEMAND as SELECT CATEGORIE, VILLE, K.ANNEE, SUM(QUANTITE*PRIXU) SOMME, AVG(QUANTITE*PRIXU) MOY, MIN(QUANTITE*PRIXU) MINI, MAX(QUANTITE*PRIXU) MAXI, VARIANCE(QUANTITE*PRIXU) VARIANCE_PU, stddev(quantite*prixu) ECART_TYPE_PU, COUNT(all K.NUMCOM) C_ALL FROM W_D_CLIENTS C, W_D_COMMANDES K, W_F_VENTE F WHERE C.CODCLI = F.CODCLI AND K.NUMCOM = F.NUMCOM GROUP BY CUBE(CATEGORIE, VILLE, K.ANNEE); Table d agrégats gérée par notre outil HDI : CREATE TABLE VM_HDI as SELECT ID- CATEGORIE VILLE ANNEE as CLE, CATEGORIE, VILLE, ANNEE, SUM(QUANTITE*PRIXU) SOMME, AVG(QUANTITE*PRIXU) MOY, MIN(QUANTITE*PRIXU) MINI, MAX(QUANTITE*PRIXU) MAXI, VARIANCE(QUANTITE*PRIXU) VARIANCE_PU, stddev(quantite*prixu) ECART_TYPE_PU, COUNT(all F.NUMCOM) C_ALL, COUNT(*) N FROM W_D_CLIENTS C, W_D_COMMANDES K, W_F_VENTE F WHERE C.CODCLI = F.CODCLI AND K.NUMCOM = F.NUMCOM GROUP BY CUBE(CATEGORIE, VILLE, ANNEE); Notre table d agrégats est équivalente à la VM d Oracle. Nous calculons en plus des agrégats demandés, des valeurs intérmédiaires nécessaires à notre méthode incrémentale (e.g. pour calculer la moyenne on a besoin de connaître la somme et le compte). Nous intégrons un identifiant pour chaque ligne composé des valeurs de l expression 6

de regroupement. Cet identifiant sera utilisé au niveau de la jointure entre v et v-prim Les VM ont été créées à partir de deux instances différentes de l ED W_Gescom. Une première avec 1 million de lignes (faits) et une autre avec 7 millions. Les mêmes VM et les mêmes tests ont été réalisés sur les deux instances pour évaluer les résultats. Les mesures de performance sont représentées par les courbes des figures 1 et 2. 4.3. Mise à jour des VM Les mises à jour sources sont répercutées au niveau de l entrepôt selon notre algorithme ConstuitVue [HAM 07]. Ainsi un "nouvel" entrepôt, issu de ces mises à jour, est construit : w-prim. Ce dernier est calculé à partir des tables/fichiers-log qui constituent les mises à jour. Par la suite, et à partir de cet entrepôt, la vue v-prim est créée. Les deux vues v et v-prim contiennent des agrégats intermédiaires calculés respectivement à partir de w et de w-prim. Ces calculs serviront dans la mise à jour des agrégats de la VM v à l aide des formules présentées dans la section 3. Notre démarche a été comparée à celle du SGBD Oracle (10g) qui ne propose qu un rafraîchissement complet et sur demande. Les limites de la maintenance des VM sous Oracle sont détaillées dans [BAD 06b]. Les mises à jour que nous avons traités (de 1 000 jusqu à 1 million de lignes) montrent que notre démarche incrémentale est beaucoup plus performante (c.f. figures 1 et 2). Exemple A : Démarche de rafraîchissement sous Oracle. Le rafraîchissement de la vue est fait quel que soit le nombre de lignes sources mises à jour avec la procédure prédéfinie : dbms_mview.refresh( VM_ORA ). Exemple B : Démarche de maintenance avec notre outil HDI. Suite à la mise à jour de l entrepôt W nous calculons v-prim à partir de w-prim comme suit : CREATE TABLE VM_HDI_PRIM as SELECT ID- CATEGORIE VILLE ANNEE as CLE, COUNT(*) N CATEGORIE, VILLE, ANNEE, SUM(QUANTITE*PRIXU) SOMME, AVG(QUANTITE*PRIXU) MOY, MIN(QUANTITE*PRIXU) MINI, MAX(QUANTITE*PRIXU) MAXI, VARIANCE(QUANTITE*PRIXU) VARIANCE_PU, stddev(quantite*prixu) ECART_TYPE_PU, COUNT(all F.NUMCOM) C_ALL FROM W_D_CLIENTS_PRIM C, W_D_COMMANDES_PRIM K, W_F_VENTE_PRIM F WHERE C.CODCLI = F.CODCLI AND K.NUMCOM = F.NUMCOM GROUP BY CUBE(CATEGORIE, VILLE, ANNEE); Nous pouvons maintenant procéder aux calculs des nouvelles valeurs des agrégats de VM_HDI. La jointure gauche externe (full outer join) donne la possibilité de prendre en compte toutes les valeurs de v et celles correspondantes de v [PAL 02]. Cependant, le calcul des agrégats basé sur les valeurs de faits associées à de nouvelles valeurs de dimensions n est pas pris en compte. Prenons un exemple : si dans une des sources, une nouvelle catégorie de client a été enregistrée, alors elle sera répercutée sur w en calculant w w. Par contre la jointure externe gauche ne prendra pas en compte cette nouvelle donnée et la valeur de l agrégat correspondant ne sera pas intégrée à la vue matérialisée. En appliquant les formules présentées dans la section 3 nous obtenons : CREATE MATERIALIZED VIEW VM_NEW as SELECT decode(v.cle,null,v_prim.cle,v.cle) as CLE, decode(v.cat,null, V_PRIM.CAT, V.CAT) as CAT, decode(v.vil,null,v_prim.vil,v.vil) as VIL, decode(v.d,null,v_prim.d,v.d) as D, decode(v.maxi,null,v_prim.maxi, decode(v_prim.maxi,null,v.maxi, decode(abs(v_prim.maxi-v.maxi), 7

V_PRIM.Maxi-V.Maxi, V_PRIM.Maxi, V.Maxi))) as Maxi, decode(v_prim.moy,null,v.moy, decode(v.moy,null,v_prim.moy, (V_PRIM.S + V.S)/(V_PRIM.N + V.N))) as Moy, from VM_HDI full V outer join VM_HDI_PRIM V_PRIM on V.CLE=V_PRIM.CLE; Temps (s) 160 140 120 100 80 60 40 20 Maintenance de VM calculee sur un ED de 1 million de lignes Oracle HDI Temps (s) 600 500 400 300 200 100 Maintenance de VM calculee sur un ED de 1 million de lignes Oracle HDI 0 1 000 10 000 100 000 1 000 000 Taille des mises a jour (Nombre de lignes) 0 1 000 10 000 100 000 1 000 000 Taille des mises a jour (Nombre de lignes) Figure 1. Maintenance d une VM issue d un DW à 1 million de lignes 5. Conclusion Figure 2. Maintenance d une VM issue d un DW à 7 millions de lignes Dans le cadre de travaux réalisés par les étudiants de l IUT de Paris et de Paris 13, nous avons réalisé des tests sur plusieurs VM issues de différentes instances de BD. La maintenance incrémentale de ces VM selon notre méthode donne des résultats nettement plus performants que le rafraîchissement proposé par Oracle 10g. Nous travaillons actuellement sur l impact de la mise à jour des structures de l ED sur la gestion des agrégats. La partie implentation de ces travaux fait l objet d un projet pluridisciplinaire (PPD) au sein de l IUT de Paris. L intégration d autres structures de données pour gérer les VM ainsi que leur mise à jour constituent nos travaux futurs. 6. Bibliographie [BAD 06a] BADRI M., BOUFARÈS F., DUCATEAU C., HAMDOUN S., «Maintenance des entrepôts de données hétérogènes», MCSEAI 9th Maghrebian Conference on Software Engineering and Artificial Intelligence, décembre 2006, p. 152-158. [BAD 06b] BADRI M., BOUFARÈS F., DUCATEAU C., NEFOUSSI R., «Maintenance des vues matérialisées hétérogènes sous Oracle», Workshop SID Systèmes d Information Décisionnels, dans INFORSID 2006, june 2006, p. 8-14. [CHO 04] CHOU P., ZHANG X., «Computing Complex Iceberg Cubes by Multiway Aggregation and Bounding», DaWaK, 2004, p. 108-117. [HAM 07] HAMDOUN S., BOUFARÈS F., BADRI M., «Construction et maintenance des entrepôts de données hétérogènes», Revue e-ti,, n o 4, 2007. [PAL 02] PALPANAS T., SIDLE R., COCHRANE R., PIRAHESH H., «Incremental Maintenance for Non-Distributive Aggregate Functions.», VLDB, 2002, p. 802-813. [RAV 01] RAVAT F., TESTE O., ZURFLUH G., «Modélisation multidimensionnelle des systèmes décisionnels», EGC, 2001, p. 201-212. [THO 02] THOMSEN E., OLAP Solutions Building Multidimensional Information Systems, Wiley, second édition, 2002. 8