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

Bases de données multidimensionnelles et mise en œuvre dans Oracle 1 Introduction et Description générale Les bases de données relationnelles sont très performantes pour les systèmes opérationnels (ou transactionnels) qui constituent ce qu on appelle les systèmes OLTP (On-Line Transactional Processing). Ces bases de données sont destinées à des systèmes effectuant de nombreuses requêtes pas très complexes et très répétitives touchant une quantité faible de données (en nombre de tables), par exemple pour gérer un stock. De très nombreux opérateurs ont alors accès à ces requêtes de mise à jour (par exemple l ensemble des employés du magasin dont on gère le stock). Ces systèmes de production ne permettent pas d effectuer efficacement des analyses de données. On distingue alors ces premiers sytèmes OLTP des stystèmes OLAP (On-Line Analytical Processing) proposés par Codd (1993) qui sont eux destinés à peu de personnes (dirigeants, analystes) effectuant de manière moins fréquente des requêtes complexes d analyse mettant en jeu de très gros volumes de données stockés dans des entrepôts de données. Ces analyses sont dites multidimensionnelles puisqu elles permettent l analyse d un fait (par exemple les ventes) en fonction de dimensions (par exemple la ville, le produit et le mois de vente). Si les systèmes relationnels sont efficaces pour l OLTP (robustes, performants et sécurisés), ils se sont révélés insuffisants pour les systèmes OLAP. Se sont alors développés des systèmes de gestion de bases de données multidimensionnelles. Cependant, ces systèmes ne permettaient pas de gérer de très gros volumes de données de manière aussi efficace que les SGBD classiques relationnels, on se dirige donc maintenant de plus en plus vers des systèmes relationnels-olap. Pour résumer : OLTP OLAP (transactions) (analyse) Taille des données concernées faible (quelques n-uplets) importante (millions de n-uplets) Fréquence des requêtes souvent peu souvent Utilisateurs agents opérationnels (nombreux) analystes/décideurs (peu nombreux) Granularité détail résumé Requêtes simples et répétitives complexes et non prévisibles Accès lecture/écriture lecture Optique production et mise à jour optique décisionnelle Le lien entre OLTP et OLAP se fait dans le processus général de vie des données. Les requêtes OLAP se font sur les données stockées (dans l entrepôt de données) alimentées par des données sources produites par des requêtes OLTP, comme le montre la figure 1. Les outils E.T.L. correspondent à: Extract : accès aux données sources. Le langage de requêtes est différent selon le type de données (données structurées BD relationnelles, non structurées, semi-structurées XML). Transform : transformation pour homogénéiser (formatage, nettoyage des données, par exemple pour exprimer toutes les distances dans la même unité) 1

Figure 1: Processus complet. OLTP-OLAP Load : chargement dans l entropôt La mise à jour de l entropôt (refresh) est coûteuse et se fait de manière régulière, par exemple toutes les nuits. Elle peut être incrémentale ou nécessiter le recalcul de tout l entrepôt. On appelle magasin de données un sous-ensemble de données sur un sujet particulier. Par exemple, si l entrepôt de données décrit l ensemble des données d une entreprise, on pourra proposer un magasin pour le service facturation, un pour le service du personnel, etc. Ces magasins servent à analyser les données à travers différents techniques, comme par exemple le reporting (édition de rapports d analyses statistiques), la fouille de données (data mining), la visualisation, ou encore les requêtes what if qui décrivent ce qui se passerait si telle ou telle action était entreprise (par exemple si on augmentait les salaires de 2%). Quand Codd a proposé le modèle OLAP (1993), il a décrit règles qu un tel système soit permettre : 1. modèle (multi)dimensionnel 2. transparence du serveur pour l utilisateur 3. accessibilité des données 4. performances d accès stables 5. architecture client-serveur 6. dimensionnalité générique 7. gestion des données éparses 8. multi-utilisateurs 9. opérations sur les dimensions 2

10. manipulation intuitive des données 11. souplesse d affichage et d édition. dimensions et niveaux multiples Cependant, ces règles sont faussées par le fait que Codd travaillait pour un éditeur de système OLAP et qu elle décrivent donc ce système commercial! On peut donc se référer au modèle FASMI : Fast Analysis of Shared Multidimensional Information. Les réponses doivent donc être rapides, le système doit fournir des outils d analyse numériques et statistiques, l architecture doit être multi-utilisateurs et offrir une vue multidimensionnelle des données, quels que soient leur volume et leur mode de stockage. Jusqu à présent, il n existe aucun consensus, pas de modèle ou de langage standard. Bibliographie : http://www.olapreport.com http://www.billinmon.com Codd, Providing OLAP (On-Line Analytical Processing) to User-Analysts: An IT Mandate, Arbor Software White Paper, 1993. R. Kimball, The Datawarehouse Toolkit, John Wiley & Sons, 1996. 2 Entrepôts de données Pour Inmon, un entrepôt de données (Data Warehouse - DW) est : subject-oriented, integrated, time-variant, and non volatile collection of data in support of management decision making process. Les données sont donc historisées, maintenues et matérialisées (stockées physiquement). Cette collection de données constitue un ensemble homogène (à partir de données hétérogènes, très nombreuses et distribuées), exploitable (pour un processus de décision). Pour R. Kimball, un entrepôt de données est a copy of transaction data specifically structured for query and analysis. Il existe deux schémas principaux possibles pour la modélisation de l entrepôt : le schéma en étoile et le schéma en flocon. Quel que soit le modèle considéré, on distinguera la table des faits qui contient l information à analyser (par exemple les ventes) des tables de dimensions qui contiennent les informations sur les dimensions d analyse (par exemple le lieu, le temps, la description du produit). 2.1 Schéma étoile (Star Schema) Ce type de schéma est décrit sur la figure 2. La table des faits contient les clés étrangères vers les tables de dimension. L ensemble de ces clés étrangères forment la clé primaire, la table des faits étant en BCNF. Les tables de dimension quant à elles ne sont pas normalisées. Un exemple est donné sur la figure 3. 2.2 Schéma en flocon (Snowflake Schema) Dans ce modèle, les tables de dimensions sont normalisées pour constituer une structure hiérarchique (c.f. figure 4). Ceci a pour avantage de faciliter la maintenance des tables de dimension et de réduire la redondance, cependant il faudra calculer des jointures coûteuses. Un exemple est donné sur la figure 5. 3

Figure 2: Schéma en étoile Figure 3: Schéma en étoile : exemple 4

Figure 4: Schéma en flocon 5

Figure 5: Schéma en flocon : exemple 6

Figure 6: Cube de données 3 Cubes de données Figure 7: Hiérarchies simple et multiple Le modèle multidimensionnel sur lequel s appuie OLAP permet la définition d hypercubes de données (appelés cubes par abus de langage) afin de faire valoir la représentation dimensionnelle des données. À partir des schémas étoile et flocon, on construit les cubes de données, comme indiqué figure 6. Pour des raisons évidentes de visualisation, cet hypercube n a que trois dimensions, il faut l imaginer en k dimensions. Une base de données multidimensionnelle est un ensemble d hypercubes définis le long de dimensions. Ces dimensions peuvent être munies de hiérarchies. On distingue alors les hiérachies simples des hiérarchies multiples, comme indiqué sur la figure 7. Le niveau ALL correspond à l agrégation totale, comme illustré sur la figure 8. La mesure désigne le contenu des cellules de l hypercube. La mesure peut être additive, semi-additive ou non additive : Mesure non additive : on ne peut pas sommer les valeurs des cellules en conservant un sens. Par exemple, si le cube contient des moyennes de ventes par mois, produit et ville, il n y a pas de sens à sommer les valeurs des cellules des villes pour les regrouper en départements. 7

Figure 8: Hiérarchies : niveau ALL Figure 9: Treillis des cuboïdes pour les 4 dimensions A, B, C, D Mesure semi-additive : on peut sommer sur certaines dimensions en gardant un sens mais pas sur toutes. Par exemple, si on considère un cube décrivant l état des stocks par ville, produit et mois, il est possible de faire la somme sur les dimensions ville et produit pour connaître l état global des stocks pour toutes les villes ou pour tous les produits, mais il n y a aucun sens à sommer sur la dimension temporelle des mois. Mesure additive : on peut sommer sur toutes les dimensions tout en conservant un sens. Par exemple, si l on considère les sommes des ventes par produits, villes et mois, on peut faire la somme des valeurs des cellules tout en conservant un sens aux données. La construction des hypercubes nécessite : le choix des dimensions d analyse, le choix de la fonction d agrégation, et la définition de la requête. On parle du treillis des cuboïdes pour décrire l ensemble des cubes qu il est possible de construire à partir d un modèle ayant plusieurs dimensions. La figure 9 décrit l ensemble des hypercubes qu il est possible de construire à partir de quatre dimensions A, B, C et D. La fonction d agrégation pour la construction des cubes est l une des fonctions classiques comme AVG, SUM, MIN, MAX,... Le niveau d agrégation doit être soigneusement déterminé. En effet, il indique le niveau de détail auquel les utilisateurs pourront accéder sans qu il soit nécessaire de réaccéder aux données sources. Mais un niveau trop détaillé entraîne un cube volumineux. La requête de construction est de la forme suivante : 8

select dim1,..., dimk, AGREGATION from table_faits, table_dim1,..., table_dimk where [jointure] Group By dim1,..., dimk [Having...] ; Par exemple, la construction du cube de la figure 6 serait la suivante : select Mois, Ville, Produit, SUM(Quantite) from vente, TMois, TLieu, TProduit where Vente.IDProduit = TProduit.IDProduit AND Vente.IDLieu = TLieu.IDLieu AND Vente.IDDate = TMois.IDDate Group By Mois, Ville, Produit ; 4 Opérations sur les cubes de données Les hypercubes sont munis de différentes opérations réparties selon qu elles ont trait à : la visualisation des données (aucune modification sur le contenu), la navigation le long des hiérarchies de dimensions, la sélection des données On rappelle qu il n existe pas de modèle consensuel et donc pas d ensemble d opérations défini pour tous les systèmes. Cependant, il existe un certain nombre d opérations couramment admises comme étant essentielles décrites ci-dessous. 4.1 Visualisation des données On considère ici les deux opérations principales : la rotation et l inversion. La rotation (rotate/pivot) permet d examiner le cube selon un autre angle (voir figure 10)). Un cube de dimension n a n(n 1) vues. Par exemple un cube de dimension 3 a 6 faces. PIVOT/ROTATE 35 18 37 35 16 3 (rotation) Figure 10: rotation L inversion (switch) consiste à inverser l ordre de certaines valeurs (figure 11). Certaines informations se retrouvent alors placées l une à côté de l autre, ce qui facilite la découverte d un phénomène. 9

SWITCH (inversion) 35 18 37 18 35 37 35 35 16 3 16 3 Figure 11: Inversion 4.2 Navigation le long des hiérarchies La généralisation (roll-up décrite figure revient à généraliser les valeurs d un attribut à des concepts de niveau supérieur (passage au granule supérieur). On peut par exemple calculer la moyenne sur plusieurs valeurs de dimensions. Le roll-up(*) ou roll-up global calcule l agrégation sur toutes les valeurs, on n a plus qu une cellule contenant, par exemple, la moyenne générale 1. La spécification (drill-down), à l inverse du roll-up, est une opération de spécialisation (passage au granule inférieur). 35 18 37 16 35 3 ROLL-UP 21 17,7 20 (generalisation) 21 17,7 20 Figure : Roll Up 4.3 Sélection Il existe deux types de sélection : sur les cellules et sur les dimensions. 4.3.1 Sélection sur les cellules (Slice) La restriction (figure 13) consiste à extraire de l information résumée pour une certaine dimension. On ne retient alors que les valeurs correspondant à un certain critère, par exemple toutes les valeurs inférieures à 15. 4.3.2 Sélection sur les dimensions (Dice) Il s agit d une restriction sur les dimensions et non plus par rapport à un critère sur la mesure (voir figure 14). 1 La fonction d agrégation peut tout aussi bien être la somme, la médiane... ou une fonction plus complexe 10

SLICE (restriction) 35 18 37 35 16 3 3 35 18 37 16 35 5 Stockage physique Figure 13: Sélection sur les cellules 3 DICE (projection) Figure 14: Sélection sur les dimensions Le principal problème posé pour le stockage des cubes de données est leur nature peu dense, éparse (sparsity), de très nombreuses cellules étant vides. Il existe trois stratégies de stockage physique : le stockage sous la forme relationnelle (ROLAP), sous la forme multidimensionnelle (MOLAP) ou une solution hybride (HOLAP) combinant ces deux première approches. 5.1 ROLAP On nomme ROLAP l approche Relationnel OLAP. Les données sont stockées sous la forme de tables relationnelles. Elles sont modélisées sous la forme de schémas en étoile ou flocon. Les requêtes multidimensionnelles doivent alors être traduites en requêtes relationnelles (SQL). Ce modèle est excellent vis à vis de la capacité de stockage, mais les requêtes sont difficiles à définir et à mettre en œuvre et sont coûteuses. 5.2 MOLAP On nomme MOLAP l approche Multidimensionnelle OLAP. La technologie de stockage est multidimensionnelle. Les données sont stockées sous la forme de tableaux multidimensionnels, des index multidimensionnels sont définis. Cette tecnologie de stockage nécessite donc des techniques de compression face à la faible densité des données (sparsity). La taille des données pouvant être ainsi stockées est faible par rapport à la solution ROLAP. Cependant, les requêtes sont écrites de manière intuitive et efficace. Toutefois, il faut redéfinir un langage de manipulation des données alors qu il n existe aucun consensus ni technologie reconnue et vraiment établie. 5.3 HOLAP On nomme HOLAP l approche Hybride OLAP. Cette technologie combine les deux solutions précédentes. Les données détaillées sont stockées dans une base de données relationnelle, et les données agrégées dans une base multidimensionnelle. 35 16 18 18 35 35 11

5.4 Systèmes commerciaux Produit Editeur Type Essbase Arbor Software MOLAP DB2 OLAP Server IBM ROLAP/MOLAP Metacube Informix ROLAP SQL Server (2000) Microsoft ROLAP Express Server Oracle MOLAP 9i OLAP Oracle ROLAP/MOLAP 5.5 Précalcul des agrégats Il est possible, selon les systèmes, de calculer les agrégats à différents niveaux de granularié dans les hypercubes. Ne rien précalculer constitue bien évidemment un gain de place mais réduit considérablement les performances. A l inverse, tout stocker rend le système performant mais nécessite un espace de stockage très important. Un stockage partiel peut alors être envisagé, mais il pose le problème du choix judicieux des précalculs à effectuer. 6 Mise en œuvre dans Oracle Historiquement, Oracle s est lancé dans les systèmes OLAP à travers le logiciel ORACLE Express suite au rachat d Hyperion. Ce système, très orienté MOLAP et externe au noyau oracle 8i, a nécessité la définition d un langage de définition, d un langage de manipulation et d un système de stockage multidimensionnel. Des outils d analyse et de programmation étaient fournis. Même si la manipulation des données était facile et efficace, Oracle Express ne permettait le stockage de données volumineuses. Avec la version Oracle 9i, Oracle a décidé d intégrer les fonctionnalités OLAP au sein du noyau du SGBD. Des fonctionnalités liées aux entrepôts de données (vues matérialisées de gros volumes de données modélisés sous la forme d un schéma en étoile ou flocon) sont présentes. Il est possible de créer des dimensions, des cubes. Ces cubes sont interrogés entre autres via un langage de manipulation OLAP propriétaire (OLAP DML). Les bases de données multidimensionnelles sont des Analytic Workspaces qui contiennent un ou plusieurs cubes, des méta-données (dimensions, hiérarchies),... Les cubes y sont persistants ou calculés seulement pour la durée d une session. Les informations sont stockées dans le OLAP CATALOG. L accès aux données multidimensionnelles est possible via SQL à travers des vues, via le langage OLAP DML, ou via la Java OLAP API. Les clauses GROUP BY CUBE, GROUP BY GROUPING SETS et GROUP BY ROLLUP permettent de construire des cubes en ayant le détail des agrégats. La fonction SUM est utilisée pour agréger les données. SELECT... GROUP BY... {CUBE ROLLUP GROUPING SETS} (dimension_column) ; ROLLUP calcule des sous-totaux ainsi que le total général, toutes données confondues. Il est possible d effectuer des ROLLUP partiels. GROUP BY expr1, ROLLUP(expr2, expr3); CUBE calcule tous les sous-totaux des combinaisons possibles des colonnes. Si n attributs sont spécifiés dans la clause CUBE, il y aura 2 n combinaisons de sous-totaux calculés. CUBE calcule plus de sous-totaux que ROLLUP. De même que précédemment, il est possible d effectuer un GROUP BY CUBE partiel.

GROUP BY expr1, CUBE(expr2, expr3) La fonction RATIO TO REPORT calcule le ratio d une valeur par rapport à une somme d un ensemble de valeurs. Une valeur NULL est traitée comme un zéro pour le calcul de la somme. RATIO_TO_REPORT ( expr ) OVER ( [query_partition_clause] ) Exemple : SELECT ch.channel_desc, TO_CHAR(SUM(amount_sold), 9,999,999 ) AS SALES, TO_CHAR(SUM(SUM(amount_sold)) OVER (), 9,999,999 ) AS TOTAL_SALES, TO_CHAR(RATIO_TO_REPORT(SUM(amount_sold)) OVER (), 9.999 ) AS RATIO_TO_REPORT FROM sales s, channels ch WHERE s.channel_id=ch.channel_id AND s.time_id=to_date( 11-OCT-2000 ) GROUP BY ch.channel_desc; CHANNEL_DESC SALES TOTAL_SALE RATIO_ -------------------- ---------- ---------- ------ Direct Sales 14,447 23,183.623 Internet 345 23,183.015 Partners 8,391 23,183.362 Les fonctions RANK et DENSE RANK permet de retourner le rang d une valeur parmi une liste de valeurs. On peut alors par exemple retourner les n meilleurs (requêtes Top-N) ou les n moins bons (requêtes Bottom-N). La différence entre RANK et DENSE RANK est que DENSE RANK ne laisse pas de trous dans les rangs quand il y a des ex-aequo. RANK ( ) OVER ( [query_partition_clause] order_by_clause ) DENSE_RANK ( ) OVER ( [query_partition_clause] order_by_clause ) Exemple : SELECT channel_desc, TO_CHAR(SUM(amount_sold), 9,999,999,999 ) SALES$, RANK() OVER (ORDER BY SUM(amount_sold)) AS rang, FROM sales, products, customers, times, channels, countries WHERE... [jointure]... GROUP BY channel_desc; CHANNEL_DESC SALES$ RANG -------------------- -------------- ------------ Direct Sales 2,443,392 3 Partners 1,365,963 2 Internet 467,478 1 Il est possible de créer des vues matérialisées : CREATE MATERIALIZED VIEW [schema.]materialized_view options [USING INDEX index_options] [REFRESH [refresh_options]] [FOR UPDATE] [{ENABLE DISABLE} QUERY REWRITE] 13

Les options de rafraîchissement permettent de définir si le rafraîssement se fait ou non automatiquement, et s il se fait automatiquement à quels moments il doit s effectuer. Par exemple : CREATE MATERIALIZED VIEW Vue_OLAP REFRESH START WITH SYSDATE NEXT SYSDATE+1 ENABLE QUERY REWRITE AS SELECT..., COUNT(*) FROM... WHERE... GROUP BY... ; On force le rafraîchissement de la manière suivante : begin dbms_mview.refresh( olapv_emp ); end; / La création de dimensions est possible : CREATE DIMENSION [schema.]dimension level_clause(s) [hierarchy_clause(s) attribute_clause(s)]; Il doit y avoir au moins une clause hiérarchie ou attribut. La clause LEVEL a la forme suivante : LEVEL level IS (table.column,...) La clause hiérarchie a la forme suivante : HIERARCHY hier (child_level CHILD OF parent_level,... [join_clause]) La clause attribut a la forme suivante : ATTRIBUTE level DETERMINES (dependent_column,...) La clause join a la forme suivante : JOIN KEY (child_key_column,...) REFERENCES parent_level Par exemple : CREATE DIMENSION customers_dim LEVEL customer IS (customers.cust_id) LEVEL city IS (customers.cust_city) LEVEL state IS (customers.cust_state_province) LEVEL country IS (countries.country_id) LEVEL subregion IS (countries.country_subregion) LEVEL region IS (countries.country_region) HIERARCHY geog_rollup ( customer CHILD OF city CHILD OF state CHILD OF 14

country CHILD OF subregion CHILD OF region JOIN KEY (customers.country_id) REFERENCES country ) ATTRIBUTE customer DETERMINES (cust_first_name, cust_last_name, cust_gender, cust_marital_status, cust_year_of_birth, cust_income_level, cust_credit_limit) ATTRIBUTE country DETERMINES (countries.country_name) ; On peut vérifier la validité de la dimension créée : EXEC DBMS_OLAP.validate_dimension( customers_dim,user,false,false); SELECT table_name, dimension_name, relationship, bad_rowid FROM mview$_exceptions; 15