NSY 107 Année 2009-2010 Entrepôts de données (data warehouses) F.-Y. VILLEMIN! CNAM-CEDRIC! f-yv@cnam.fr PLAN! 1." Introduction 2." Limites du relationnel et du transactionnel 3." Bases multidimensionnelles 4." Analyse en ligne (OLAP) 5." Opérations de base 6." Métadonnées 7." Architectures serveurs 8." Architectures internes 9." Tables de choix! 10." Exemples 2! Définitions Quelques définitions pas très rigoureuses des entrepôts de données (ou data warehouse) :!!Une base de données d aide à la décision qui est maintenue séparément de la base opérationnelle de l organisation!! Un entrepôt de données est une collection de données concernant un sujet particulier, qui varie dans le temps, qui est non volatile et où les données sont intégrées. (W. H. Inmon) Introduction! Différence entre donnée et information :!donnée: fait brut, non interprété!information porte une signification, rassemblant des données interprétées dans un contexte particulier Information = ensemble de trois éléments:!une entité: l'être, l'objet ou le concept concerné!un attribut: un élément de la description de l'entité!une mesure: une valeur associée à l'attribut Information apporte une connaissance:!renseignement au sujet d'une entité jouant un rôle de formation ou de transformation de la représentation de l'entité Distinction entre:!le signifiant (le support) et!le signifié (la sémantique ou le sens donné) 3! 4!
Problèmes:! Introduction (1) La quantité de données double tous les 20 mois: Introduction Volume de données Vendeur 1970 1980 1990 2000 (2) Trop de données, pas assez d'informations Achats Activité 5! 6! Entrepôt de données! Nature des données: Systèmes opérationnels et informationnels opérationnel" informationnel" Pour opérations courantes! Pour besoins de décision! Détaillées! Synthétiques! Valeur instantanée! Valeur dans le temps! Modifiées en permanence! Très rarement modifiées! Origine: transaction! Origine: analyse! Orientées performance! Orientées lisibilité! Disponibilité immédiate! Disponibilité difficile! Redondance minimale! Redondance acceptée! Structure fixe (contenu variable)! Structure flexible! Nombreuses petites transactions! Peu de transactions! Faible quantité de données par transaction! Parfois de très grosses données! Données externes Besoins des utilisateurs finaux: (1) accès direct, autonome aux données de l'entreprise (2) des moyens de navigation et d'agrégation des données (3) des moyens d'explication des données (informations)! Datamining 7! 8!
Limites du relationnel et du transactionnel! OLTP (On-line Transaction Processing) pour décrire des applications consistant en de très nombreuses transactions relativement simples qui :!!Traitent un nombre restreint d'enregistrements!!font appel à des relations simples entre les tables!!utilisent des données opérationnelles, détaillées et non redondantes!!utilisent les données actuelles!!consultent et mettent à jour les données Bases de données relationnelles (et outils OLTP) inadaptés aux besoins :!!Gestion inefficace des relations à n entités!!modèle relationnel basé sur un modèle physique à 2 dimensions (les tables)!!données multidimensionnelles " nombre de tables important à relier avec jointures!!requêtes complexes avec des performances catastrophiques (risques d'erreur)!!fonctions d'analyse insuffisantes:! outils frontaux (Query, Infocentre...) = calculs sur le poste client, trafic sur le réseau Difficulté avec SQL: Limites du relationnel et du transactionnel!!sommer ou effectuer la moyenne de certains champs pour certaines lignes et pas pour d'autres dans la même requête!!créer des expressions faisant référence à ensemble de lignes d'une même table (ex: pour chaque magasin, différence du chiffre d'affaires par rapport à la moyenne de la région)!!sommer ou détailler selon les lignes sélectionnées dans la même requête... Dénormalisation:!!réduction du nombre de jointure, calcul des agrégats...!!demande des traitements complexes!!conduit à des grosses tables qui occupent beaucoup de mémoire (disque): "!redondance des données "!index supplémentaires "!colonnes vides (renseignées que dans certains cas)!!entraîne performances dégradées 9! 10! Bases multidimensionnelles! Peut être visualisée comme une ensemble de cubes de données, contenant eux-mêmes d'autres cubes; chaque face du cube représentant une dimension Chaque dimension représente une catégorie de données, comme un type de produit, une lieu, le temps... Les dimensions peuvent être hiérarchisées (Région, département, ville...). On parle alors d'attributs (ou "membres") hiérarchisés de la dimension Chaque cellule de la structure multidimensionnelle représente la consolidation d'une donnée numérique (montant des ventes, quantité de produits vendus, marge moyenne...) pour l'intersection entre chaque attribut de chaque dimension Cette consolidation peut être simple (somme, moyenne) ou complexe (fonctions statistiques, financières...) Les données consolidées sont appelées "mesures" Transactions dépenses Bases multidimensionnelles date! numéro! description! quantité! prix unit.! prix total! n site! 18-03-97! 175022! imprimante! 1! 2499,50! 2499,50! 11! 18-03-97! 147467! crayon! 50! 2,50! 125,00! 16! 18-03-97! 045127! répondeur! 1! 2499,50! 2499,50! 19! 18-03-97! 558721! papier! 20! 75,00! 1500,00! 16! 18-03-97! 118854! copieur! 1! 6449,00! 6449,00! 23! 18-03-97! 023485! chaise! 3! 750,00! 2250,00! 16! 18-03-97! 254687! téléphone! 1! 99,50! 99,50! 19! 18-03-97! 356498! disquette! 10! 17,50! 175,00! 23! Transactions salaires num. empl.! n site! date! mode! sal.brut! déduction! payé! 0175! 16! 31-03-97! chèque! 12000! 2400! 9600! 1423! 11! 31-03-97! virement! 19500! 2750! 16750! 0279! 19! 31-03-97! virement! 11200! 2350! 8850! 0157! 23! 31-03-97! virement! 17500! 2650! 14850! 1136! 16! 31-03-97! chèque! 18450! 2700! 15750! 1254! 11! 31-03-97! virement! 17500! 2650! 14850! 11! 12!
Bases multidimensionnelles! Bases multidimensionnelles Table relationnelle Type de dépense! site! Total (KF)! salaire! Paris! 155! salaire! Lyon! 45! salaire! Rennes! 33! fournitures! Paris! 12,5! fournitures! Lyon! 0,9! fournitures! Rennes! 0,7! matériel! Paris! 45,5! matériel! Lyon! 11,2! matériel! Rennes! 14,5! téléphone! Paris! 31,9! téléphone! Lyon! 11,6! téléphone! Rennes! 9,5! Table multidimensionnelle Structure Physique:!!!Les données dans une base multidimensionnelle sont dynamiquement structurées et compressées (optimisation de place disque)!!exemple: données "denses" (grand nombre de dimensions) stockées séparément données "dispersées" (grand nombre de cellules vides)!!index gardés en mémoire Constitution de la base de données:!!extraction des données provenant de SGBD ou de fichiers!!décomposition des données en dimensions, attributs et mesures!!calculs des consolidations!!chargement de l'hyper-cube selon la structure dimensionnelle fixée Paris! Lyon! Rennes! salaire! 155! 45! 33! Aucun standard de base de données multidimensionnelle fournitures! 12,5! 0,9! 0,7! matériel! 45,5! 11,2! 14,5! téléphone! 31,9! 11,6! 9,5! 13! 14! Bases multidimensionnelles Données intégrées!!construite en intégrant plusieurs sources de données possiblement hétérogènes: bases relationnelles, fichiers plats, Première génération Outils de recherche PC EIS Autonome 1993! deuxième génération Moteur OLAP client/serveur!!les techniques d intégration et de nettoyage des données sont utilisées pour garantir :!!la consistance des conventions de nommage (les attributs Nom et Nom_Famille dans BD1 et BD2 désignent la même chose)!!les structures de codage (l attribut Nom est sur 15 char sur BD1 et 20 char sur BD2; NSS est une chaîne dans BD1 et est un entier long dans BD2),!!les domaines des attributs (ex: cm vs pouce), etc.!!les données sont traduites au moment où elles sont copiées dans l'entrepôt de données 15! 16!
Varie dans le temps Données intégrées La portée temporelle des données dans un entrepôt de données est plus longue que celle des bases opérationnelles!!base opérationnelle: valeur courante des données.!!entrepôt de données: fournit des infos sous une perspective historique (ex: 5 à 10 dernières années) Dans un entrepôt de données, en général, chaque donnée fait référence au temps!!mais dans une base opérationnelle les données peuvent ne pas faire référence au temps Données intégrées Un entrepôt de données est non-volatile!!un support de stockage séparé!!les mises à jour de la base opérationnelle n ont pas lieu au niveau de l'entrepôt de données "!N a pas besoin de modules de gestion de transactions (concurrence, reprise sur panne ) "!N a besoin que de deux opérations pour accéder aux données, chargement initial des données et interrogation (lecture) 17! 18! Trois Catégories de mesures Hiérarchie de la dimension "lieu" distributives: si le résultat obtenu par une fonction à n valeurs calculées est le même que le résultat de la fonction sur toutes les valeurs : tous Tout count(), sum(), min(), max()! algébriques: si elle peut être calculée par une fonction à M arguments chacun obtenu par une fonction distributive : avg(), min_n(), standard_deviation()! continent pays France Europe...... Allemagne Amérique Canada... Mexique holistique: s'il n'y a pas de limite constante sur la taille nécessaire pour décrire un composant : ville Paris... Vancouver... Toronto median(), mode(), rank()! magasin J. Doe... M. Lee 19! 20!
Cubes de données Un entrepôt de données est basé sur un modèle multidimensionnel où les données sont vues comme des cubes de données (ou cuboïdes) Un cube de données (exemple: ventes) permet de voir les données selon plusieurs dimensions!!les tables de dimension exemple: item (nom_item, marque, type), ou temps (jour, semaine, mois, trimestre, année)!!la table de faits contient des mesures (exemple: unités_vendues) et les clés externes faisant référence à chaque table de dimension Un cube de dimension n est un treillis des cubes de dimension <n. Produit Données multidimensionnelles Montant des ventes comme une fonction des paramètres produit, mois, région Dimensions: Produit, Lieu, Temps Chemins de consolidation hiérarchiques Industrie Région Catégorie Pays Année Trimestre Produit Ville Mois Semaine Mois Magasin Jour 21! 22! Un exemple de cube" Treillis de cubes Date 1Trim 2Trim 3Trim 4Trim sum 100 200 300 100 700 Total annuel des ventes de TV aux U.S.A Tout! U.S.A! Canada! Pays tout produit date pays produit,date produit,pays date, pays Cube (ou apex) Cubes D!" Cubes D!# Mexique! Cubes (de base) D-3 sum! produit, date, pays TV Partout! 23! 24!
Cube: Un treillis de cuboïdes tous! temps! item! lieu! fournisseur! temps,item! temps,lieu! item,lieu! Temps, fournisseur! temps,lieu, fournisseur! temps,item,lieu! item,fournisseur! Lieu, fournisseur! D=0 cube D!$ cubes D!$ cubes D!$ cubes Analyse en ligne (OLAP) OLAP (On-line Analytical Processing)!!créé en 1993 par Edgar F. Codd!!invoque des requête interactives pour alimenter un processus de décision!!but: rechercher des relations complexes entre les données et les analyser pour en extraire des informations (de manière itérative): modèles, tendances, conditions d'exceptions... Temps, item, fournisseur! item,lieu, fournisseur! D!$ cubes Temps, item,lieu,fournisseur! 25! 26! Analyse en ligne (OLAP)! 12 règles de Codd pour définir les requêtes OLAP (extrait):!!font appel à de très grands volumes de données (giga octets)!!analysent les relations entre de nombreux types d'éléments différents!!ont besoin de données agrégées!!comparent des données agrégées hiérarchiquement dans le temps (semaine, mois, trimestre...)!!présentent les données selon différentes perspectives (multidimensions)!!effectuent des calculs complexes!!doivent répondre vite aux requêtes des utilisateurs, sans altérer les performances du système d'information opérationnel!!présentent les données sous forme de tableaux croisés facilement manipulables, pour que toute l'attention de l'utilisateur se porte sur le processus d'analyse et non sur l'outil fournissant les informations;!!consultent les données sans les modifier Les 12 règles de Codd 27! 28!
Analyse en ligne (OLAP)! Analyse en ligne (OLAP) Base de données Métadonnées Requête Base ou entrepôt de données" Reporting Graphique Slice Dice Chemin de recherche de l'utilisateur" 29! 30! Analyse en ligne (OLAP) Requête Analyse Opérations de l OLAP Roll up : consolider (résumer) les données!!passer à un niveau supérieur dans la hiérarchie d une dimension Drill down : l inverse du Roll-up!!descendre dans la hiérarchie d une dimension Slice et Dice:!!Projection et sélection du modèle relationnel Pivot (rotate):!!réoriente le cube pour visualisation Reporting 31! 32!
Opérations de l OLAP Consolidation:!!données agrégées selon des dimensions hiérarchiques (temps, localisation, produits...)!!peut être basée sur une expression (simple ou complexe) mettant en jeu des relations entre les données Exemples:!!pourcentage par rapport à un montant cumulé par région!!fonctions financières!!fonctions personnalisées... "Drill-down" (zoom avant): À partir d'une donnée agrégée, l'utilisateur doit pouvoir très simplement (par double-clique) visualiser les données de niveau de détail comprises dans cette donnée agrégée!!doit être possible selon toute la hiérarchie de la dimension considérée (exemple: année puis semestre, trimestre, mois...)!!navigation nécessaire dans le sens inverse Opérations de l OLAP "Slicing and dicing" (permutation des axes par "glisser-déplacer") manipulations pour permuter ces axes: simple "Glisser-Déplacer" d'une tête de colonne change l'axe d'analyse Exemple de données visualisées selon différentes perspectives: "!ventes par région et canal de distribution "!puis ventes par canal de distribution et type de produit "!puis marges par produit... "slicing and dicing" implanté à partir de Excel (>5) avec les "tableaux croisés dynamiques" 33! 34! Métadonnées! (1) chaque donnée est bornée dans le temps mais elle est aussi "marquée" par une description complète (données sur les données ou modèles de données: "métadonnées" (2) on sait toujours où se trouve les méta-données et on est sûr de les trouver sous une forme standard et accessible:!!chaque colonne de chaque table devient la clé d'une ligne de description et d'explication qui contient tout ce qu'il faut savoir sur la colonne!!sa signification (sémantique)!!son origine (base de production d'origine et procédure ou le programme qui a servi à la transformer)!!son historique (forme initiale, formes successives, date des versions)!!ses créateurs (nom des intervenants aux différents niveaux) Métadonnées CWM (Common Warehouse Metamodel) (ex OIM) est le langage de modélisation définissant les application de type datawarhouse Le méta-modèle étant celui d UML avec un grand nombre des méta-classes spéciales, comme par exemple pour modéliser une base de données relationneles Ce standard vise à spécifier les bases de données relationnelles, structurelles, OLAP, XML, Datamining, Multidimentionnel Les méta-modèles de CWM sont décrits avec MOF Meta Data Coalition (fin 1995): Arbor Software, IBM, Cognos, Business Objects, Evolutionary Technology, Platinum Technology, TI Software et Meta Group et d autres éditeurs, qui a depuis fusionné avec l'omg but: interface standard pour l accès aux métadonnées CWM MOF Version 1.3 (courante,) Mai 200, disponible à http://www.omg.org/technology/cwm/ 35! 36!
Métadonnées CWM Le CWM (ex OIM) est décrit en UML et implanté en XML. Interopérabilité via CWM 37! 38! CWM CWM Indépendance des applications et des données : les applications sont développées autour des sources de données. Application 1 Application 2 Données 1 Données 2 Outils de Nettoyage P R O D U C T E U R Entrepôt données Relationel META-DONNEES Common Warehouse Meta-modèle Repositories services C O N S O M A T E U R Outil final d'utilisateur Outil final d'utilisateur CWM Méta-modèles Ressources et Analyses Outils de Transformation RDBMS Outil final d'utilisateur Pages 39-45 : reprises de Jean Bézivin, Equipe ATLAS, INRIA & IRIN, Nantes 39! 40!
CWM CWM paquetages de haut niveau M!a!n!a!g!e!m!e!n!t! W!a!r!e!h!o!u!s!e!P!r!o!c!e!s!s! W!a!r!e!h!o!u!s!e!O!p!e!r!a!t!i!o!n! CWMFoundation A!n!a!l!y!s!i!s! T!r!a!n!s!f!o!r!m!a!t!i!o!n! O!L!A!P! D!a!t!a!M!i!n!i!n!g! I!n!f!o!r!m!a!t!i!o!n! B!u!s!i!n!e!s!s! V!i!s!u!a!l!i!s!a!t!i!o!n! N!o!m!e!n!c!l!a!t!u!r!e! R!e!s!o!u!r!c!e! O!b!j!e!c!t!M!o!d!e!l! R!e!l!a!t!i!o!n!a!l! R!e!c!o!r!d! M!u!l!t!i!d!i!m!e!n!s!i!o!n!a!l! X!M!L! WarehouseDeployment F!o!u!n!d!a!t!i!o!n! B!u!s!i!n!e!s!s! D!a!t!a!T!y!p!e!s! E!x!p!r!e!s!s!i!o!n!s! K!e!y!s!a!n!d! T!y!p!e! S!o!f!t!w!a!r!e! I!n!f!o!r!m!a!t!i!o!n! I!n!d!e!x!e!s! M!a!p!p!i!n!g! D!e!p!l!o!y!m!e!n!t! C!o!r!e! B!e!h!a!v!i!o!r!a!l! R!e!l!a!t!i!o!n!s!h!i!p!s! I!n!s!t!a!n!c!e! Relationel RecordOriented MMDB XML Le méta-modèle CWM est fortement structuré # 22 paquetages : 204 classes & 154 associations Transformation OLAP WarehousProcess WarehouseOperation 41! 42! CWM CWM -/contraint ChekContraint -deferrability : DeferrabilityType * 0..* 0..* -/contraintelement -/contraint Column CoumnSet -/owner -/feature 0..1 0..* -precision : Integer -sca le : Integer -isnul lable : Nul lab let ype -length : Integer -col lationnam e : String -characterse tname : S tring -/ o p tionscopeco lumnset : NamedColum nset -/ referencedt ablet yp e : SQLStructuredT ype -structuralfeature -/type * * SQLDataType -typenumber : integer NemedColomnSet * -/ o p tionscopeco lumn : Column -/ type : SQLStructu redt ype -/ u singt rigger : T rigger -{ordred} Qu eryc olum nset -query : QueryExpression SQLDistinctType -length : Integer -presision : Integer -scale : Integer -/ sqlsimpletype : SQLSimpleTipe SQLSimpleType T able View * -sqldi stinctt ype -sqlsim plet ype 1 -charactermaximumlength : Integer -characterocte tlength : Integer -num ericprecisio n : Integer -num ericprecisionradix : Integer -num ericsca le : Integer -datet imeprecisio n : Integer Business Information Model Tables, colonnes et types de données 43! 44!
ETL : ExtractionTransformation Loading CWM Possibilité d extraire, de transformer, et de charger les données des ressources opérationnelles dans un entrepôt de données. L'extraction, la transformation et le chargement sont considérés comme des transformations, représentées par des modèles de transformations. Source Data TF Entrepôt de données Cible Source Data Sources opérationnelles de données ETL Cible Source Data Méta-données de transformations Cible 45! Exemple de document CWM 46! Modélisation conceptuelle des entrepôts de données Exemple de schéma en étoile Dimensions & mesures!!schéma en étoile: Au milieu, une table de faits connectée à un ensemble de tables de dimensions!!schéma flocon de neige (snowflake): Un raffinement du précédent où certaines tables de dimensions sont normalisées (donc décomposées)!!constellation de faits: Plusieurs tables de faits partagent quelques tables de dimension (constellation d étoiles) temps Id_temps jour Jour_semaine mois trimestre année branche Id_branche Nom_branche Type_branche Table de faits ventes id_time id_item id_branche id_lieu unités_vendues montant_ventes moyenne_ventes lieu item Id_item Nom_item marque type Type_fournisseur Id_lieu rue ville département pays Mesures 47! 48!
Exemple de schéma Snowflake Exemple de constellation de faits temps Id_temps jour Jour_semaine mois trimestre année branche Id_branche Nom_branche Type_branche Mesures Table de faits Vente Id_temps Id_item Id-branch Id_lieu unités_vendues montant_vente moyenne_vente item Id_item Nom_item Marque type Id_fournisseur lieu Id_lieu rue Id_ville fournisseur Id_fournisseur Type_fournisseur ville Id_ville ville département pays 49! temps Id_temps jour Jour_semaine mois trimestre année branche Id_branche Nom_branche Type_branche Mesures Table de faits Vente Id_temps Id_item Id-branche Id_lieu unités_vendues montant_vente moyenne_vente lieu item Id_item Nom_item marque type Id_fourniseur Id_lieu rue ville département pays Table de faits Transport Id_temps Id_item Id_transporteur id_départ id_arrivée coût Unités_transportées transporteur Id_Transporteur Nom_transporteur Id_lieu Type_transporteur 50! Entreprise warehouse Modèles d'entrepôts de données!!collecte de toutes les informations concernant les sujets traités au niveau de l organisation Data Mart!!Un sous ensemble d un entreprise warehouse. Il est spécifique à un groupe d utilisateurs (ex: data mart du marketing) Data warehouse virtuel!!un ensemble de vues définies à partir de la base opérationnelle!!seulement un sous ensemble des vues sont matérialisées Architecture des serveurs OLAP Relational OLAP (ROLAP)!!Utilise un SGBD relationnel pour stocker les données ainsi qu un middle-ware pour implémenter les opérations spécifiques de l OLAP Multidimensional OLAP (MOLAP)!!Basé sur un stockage par tableaux (techniques des matrices creuses)!!indexation rapide de données calculées 51! 52!
Utilitaires Extraction :!!Récupérer les données à partir des sources Nettoyage :!!détecter les erreurs et les corriger si possible Transformation :!!Convertir les formats Charger:!!Trier, consolider, calculer des vues, vérifier des contraintes, construire des index, vérifier des contraintes Rafraîchir!!Propager les mises à jour des sources sur l'entrepôts de données Entrepôts de données vs. SGBD hétérogènes Traditionnellement, l intégration de bases hétérogènes se fait par le biais de :!! Wrappers/mediateurs au dessus des bases hétérogènes!! Approche orientée requête "!Quand une requête est posée par un site client, un métadictionnaire est utilisé pour la traduire en plusieurs requêtes appropriées à chacune des bases. "!Le résultat est l intégration des réponses partielles "!L exécution des requêtes demande donc beaucoup de ressources Entrepôt de données : Approche orientée mise à jour!! Les infos sont intégrées et stockées pour une interrogation directe!!plus efficace en coût d exécution des requêtes 53! 54! Entrepôt de données vs. base opérationnelle OLTP (On-Line Transaction Processing)!!Exécution en temps réel des transactions, pour l enregistrement des opérations quotidiennes: inventaire, commandes, paye, comptabilité!!par opposition aux traitements en batch OLAP (On-Line Analytical Processing)!!Traitement efficace des requêtes d analyse pour la prise de décision qui sont par défaut assez complexes (bien qu a priori, elles peuvent être réalisées par les SGBD classiques) OLTP vs. OLAP :!!Données: courantes, détaillées vs. historiques, consolidées!!conception : modèle ER + application vs. Modèle en étoile + sujet!!vue : courante, locale vs. évolutive, intégrée SGBD et entrepôt de données Les 2 systèmes sont performants!!sgbd calibrés pour l OLTP: méthodes d accès, index, contrôle de concurrence, reprise!!warehouse calibrés pour l OLAP: requêtes OLAP complexes, vue multidimensionnelle, consolidation. Fonctions et données différentes:!!données manquantes: l aide à la décision a besoin des données historiques qui ne se trouvent pas dans les BD s opérationnelles!!consolidation: l AD a besoin de données consolidées (agrégats) alors qu elles sont brutes dans les BD s opérationnelles!!modes d accès: mise à jour vs. Lecture seule mais requêtes complexes 55! 56!
Schéma d'alimentation d'un entrepôt de données OLTP vs. OLAP Caractéristiques! Structure normalisée! Type abstrait! Parallélisme! Structure multidimensionnelle! Drill down! Rotation! Opération donnée-dépendante! Relationnelle! Multidimensionnelle! Objet! OLTP OLAP utilisateurs Tout le monde décideurs fonction Opérations journalières Aide à la décision DB design Orienté applications Orienté sujet data courante, à jour, relationnel plat usage répétitive ad-hoc historiques, résumés, multidimensionnelle intégrées accès read/write Beaucoup de scans index/hash sur clés Unité de travail Transactions courtes Requêtes complexes # enregistrement dizaines millions # utilisateurs Centaine(s) Dizaine(s) Taille BD 100MB-GB 100GB-TB métrique Exécution des transactions Temps de réponse aux requêtes 57! 58! Tables de choix Tables de choix Outil Question exemple utilisateur Requête et Qu'est il arrivé? ventes du mois, besoin de données reporting histoire des historique, peu de OLAP Qu'est il arrivé et pourquoi? inventaires ventes du mois comparées aux changement de prix technicité "slicing et dicing",très haute technicité EIS Que dois je savoir? tableau de bord besoin de données très synthétiques, peu de technicité Datamining Qu'il y a t'il d'intéressant?,que va t'il arriver? modèles prédictifs besoin d'extraire des connaissances cachées, très haute technicité Besoins! Utilisateurs! Système! Architecture! Serveur! DBMS! Site: département! But: analyse données! Site: département! But: recherche information! Site: entreprise! But: recherche information! Site: département! But: exploration! 1 endroit,! peu nombreux! dispersé,! très nombreux! dispersé,! très nombreux! quelques sites,! peu nombreux! PC + mini! consolidée! Classique ou SMP! multidimensionnelle! PC + mini! à 3 niveaux! SMP! multidimensionnelle! mainframe! centralisée! SMP! Objet! mainframe! centralisée! MPP! relationnelle! 59! 60!
Exemples! Exemples Wal*Mart (3000 hypermarchés aux USA)!! suivi des commandes!! établissement des prix,!! établissement des promotions... Teradata sur NCR 3600 (360 processeurs) et 2,7 TO Kraft Jacobs Suchard (KJS): confiserie, café, chocolat...!! suivie des ventes quotidienne,!! performance des vendeurs!! évolution des linéaires,!! analyse de l'activité Essbase avec 4 GO Agapes (165 restaurants: Flunch, Pic Pain...)!! attirer et fidéliser les clients!! améliorer les marges!! détecter produits à faible rotation... Essbase avec 10 GO Casino!!480 Giga-octets!!1000 magasins!!historique sur 25 mois!!mémorisation "!réceptacle de données "!data repository "!référentiel produit #!200 000 codes produits #!jusqu'à 450 données associées "!puissance de calcul!!futur data mining "!analyse des tickets de caisse "!carte de fidélité 61! 62! Principaux produits Business Objects version 4.0 (et >) : solution d'interrogation, d'analyse et de reporting des informations multidimensionnelles, dans un environnement indépendant de la base OLAP choisie Marchés Cognos Suite : suite décisionnelle, analyse avec Powerplay (outil OLAP), découverte avec Scenario et reporting avec Impromptu Essbase d'arbor Software (aujourd'hui Hyperion), fondateur du concept OLAP. Le produit Essbase est le plus répandu actuellement Express, offre multidimensionnelle d'oracle, comprend un moteur de base de données disponible à la fois sur site central ou sur PC, plus des outils client en environnement graphique permettant la consultation des données ou le développement d'applications spécifiques. SQL Server 200X, offre intégrée de Microsoft, contient un composant OLAP 63! Source :http://www.olapreport.com/ 64!
Références http://www.olapreport.com/ http://www.ondelette.com/olap/dwbib.html Site de Bernard LUPIN (Oracle Express) : http://perso.wanadoo.fr/bernard.lupin "Le data warehouse Guide de conduite de projet", Ralph Kimball, Laura Reeves, Margy Ross, Warren Thornthwaite (Eyrolles) Open Source Bizgres : www.bizgres.org/home.php, Data Warehouse sous PostgreSQL Palo : www.opensourceolap.org, un serveur OLAP (MOLAP) en Open source avec Add-in Excel Mondrian : mondrian.sourceforge.net, un serveur OLAP écrit en JAVA freeolap : http://freeolap.com, un serveur OLAP écrit en JAVA sous MySQL freeanalysis : http://sourceforge.net/projects/freeolap 65! 66!