Eduardo Almeida. Master Alma Université de Nantes

Transcription

1 Data Warehouse - OLAP Master Alma Université de Nantes {eduardo.almeida@univ-nantes.fr}

2 Objectif Présenter les concepts de base d'un Data Warehouse (DW) et On Line Analytical Processing (OLAP). Présenter des fonctions et outils pour construire un environment DW/OLAP.

3 Bibliographie Berson, Alex e Smith, Stephen J. Data Warehousing, Data Mining & OLAP Kimball, Ralph The Data Warehouse Toolkit Inmon, Willian H. Building the Data Warehouse Thomsen, Erik OLAP Solutions Wu and Alejandro P. Buchmann (1998) Encoded Bitmap Indexing for Data Warehouses Donsez, Didier (présentations) Université Joseph Fourier

4 Problèmes typiques Nous avons une grande quantité de données, mais nous ne pouvons pas les utiliser La pire chose pour un directeur est d'avoir deux personnes présentant le même rapport avec des résultats différents Montre-moi juste l'information la plus importante Nous voulons croiser les informations de toutes les façons possibles The Data Warehouse Toolkit - Ralph Kimball

5 Défi des entreprises Les décideurs Gestionnaires d'informatique Valeur Information correctes Format correct A l'heure Integration Passage à l'échelle et performance Flexibilité Coût Comment une entreprise peut atteindre les deux objectifs?

6 Définition de Bill Inmon (1996) «Le Data Warehouse est une collection de données orientées sujet, intégrées, non volatiles et historisées, organisées pour le support d un processus d aide à la décision.»

7 Data Warehousing OLE DB/ODBC Mainframe DB2 MVS, VSAM, CICS/IMS, NCR Teradata SQL Server Oracle Transformation Data Warehouse

8 Data Warehouse est... Orient é sujet UN ITES FINANCES Dat a Warehouse CLIEN T M ARCHE Nous pouvons développer des bases de données ciblées sur quelques sujets lim ités

9 Int é gr é Data Warehouse est... Ext ernal files Ext ernal files form at s DATA WAREH OUSE SGBDs OLTP ODBC and API s Intégration Sé mantique: les incompatibilités entre données de différent es sources Sources Hétérogè nes: il doit être possible d accéder à des données de plusieurs t ypes Chargem ent, Mise-a-jour, Net t oyage...

10 Data Warehouse est... Bas é sur le s t em ps P é riode 1 P é riode 2 P é riode 3 P é riode 4 Chargem ent inicial M ise à jour M ise à jour Dans un DW les données sont stockées en form e d'historique pour perm ettre une analyse tem porelle.

11 Data Warehouse est... Non Volat il INSERT UPD ATE AN Á LISE DE DADOS OLTP LOAD DW UPD ATE INSERT AN Á LISE DE DADOS Non volatil signifie que, une fois entrées dans l'entrepôt, les données ne doivent pas changer.

12 Principe Base de Données utilisée à des fins d analyse. Caractéristiques : orientation sujets («métiers») données intégrées données non volatiles données datées

13 DW versus OLTP Systèmes Opérationnels - OLTP (On Line Transaction Processing) : Les bases de données sont mises à jour en transactionnel SGBD Relationnels Centré sur la mise à jour ponctuelle de données Les transactions échangent de faibles quantités d informations avec l utilisateur et travaillent toujours sur les versions les plus récentes des données.

14 DW versus OLTP Systèmes Tactiques - OLAP (On Line Analysis Processing) Les bases de données décisionnelles sont consultées en interactif (spreadsheets) pour l'analyse des données (ex: histogrammes) Navigation dans la base selon diverses dimensions constituées par des attributs de tables Consultation des versions historiques de la base Les données proviennent des differentes sources (sites)

15 DW versus OLTP Caractéristiques OLTP DW Opérations typiques Mise à jour Analyse Type d accès Lecture et écriture Lecture Niveau d analyse Élémentaire Global Écrans Fixe Variable Quantité d info échang. Faible Importante Orientation Ligne Multidimensions Taille BD au niveau de GB au niveau de TB Ancienneté des données Récente Historique

16 DW versus OLTP OLTP structures de données complexes (3FN) DW structures de données multidimensionnelles peu indexes beaucoup beaucoup jointure quelques unes normalisées duplication dénormalisées rares agrégation fréquentes

17 La suite décisionnelle de base Extract, Transform and Load (ETL) OLAP

18 La suite décisionnelle (staging area) ETL OLAP

19 La suite décisionnelle (staging area and data marts) ETL OLAP

20 Extract, Transform and Load (ETL) Données de production SGBD et supports physiques hétérogènes Qualité inégale des données Représentations hétérogènes

21 Extract, Transform and Load (ETL) L'objectif est l'obtention de données : centralisées fiables interprétables

22 Extract, Transform and Load (ETL) Transformation : Filtrer Trier Homogénéiser Nettoyer...

23 Extract, Transform and Load (ETL) Chargement : Grande quantité Différents types de tableaux Gestion des structures spécialisées (materialized views and summary tables)...

24 Exemples d Applications Concernées Banque Il est important de pouvoir regrouper les informations concernant un client afin de répondre à ses demandes de crédit Grande Distribution Il est intéressant de regrouper les informations des ventes pour déterminer les produits à succès, mieux suivre les phénomènes de mode, détecter les habitudes d achats et les préférences par secteur géographique. Mailing Ciblés Doivent être rapidement élaborés à partir de toutes les informations disponibles sur un client lors de la commercialisation d un nouveau produit Télécommunications Analyser le trafic Etc

25 Exemple pratique (Télécommunications) Le système de télécommunication au Brésil a été privatisé. Le Brésil a été divisé en 4 parties: Région 1 (bleue) Région 2 (rouge) Région 3 (jaune) Région 4 (long distance) Mis en service d'une enterprise de télécommunication au Brésil Constructiuon d'un réseau Recherche de clients

26 Exemple pratique (Télécommunications) Où devons-nous construire le réseau? On a acheté des banques de données (master card, visa, banques, list, etc) On a utilisé un DW pour profiter de ses données

27 Exemple pratique (Télécommunications) On a généré des données pour les charger dans un système de geoprocessing

28 Exemple pratique (Télécommunications) La structure du DW SGBD : Oracle 8i -> 9i OLAP : Business Objects 5.5, Microstrategy 7 ETL : PowerMart OS : HP-UX 11 (sur une machine 32 proc.) Equipe : 12 personnes Chargement Tous les jours 17 systèmes (CRM, billing, traffic, etc) Quelques millions de tuples (8 mi dans la table de trafic) 14 heures pour terminer

29 Exemple pratique (Banque) Etude des fermetures de compte clients par mois Comment prévoir la fermeture d'un compte? Vérifier les attributs le plus importants Créer un cycle de vie client

30 Exemple pratique (Banque) Actions de marketing Nouveaux produits Fidélisation des clients Vente croisée Actions de crédit Réévaluation de crédit Telemarketing

31 Exemple pratique (Banque) La structure du DW SGBD : Sybase IQ 11 OLAP : Business Objects 4 ETL : Programmes (COBOL, C/C++, Java, etc) OS : IBM AIX Equipe : 30 personnes Chargement Tous les mois 67 systèmes (compte, assurances, investissements, etc.) 3 jours pour terminer

32 Conception du DW

33 Conception du DW Logique Phase conceptuelle et abstraite (la définition des types d'informations dont vous avez besoin) Organise une série de relations (dimensions et tables de fait) Schéma multidimensionnel (étoile et flocon)

34 Conception du DW Physique Conception physique Prise en considération des matériels et des E / S Parallélisme et de partitionnement Materialized Views

35 Conception logique

36 Conception logique Logique Dimensions et tables de faits Identifier les sujets ou domaines de données Il n'y a pas de règle (par exemple, 3FN) Identifier l'information qui appartient à une table de faits et ses dimensions associées

37 Table de Dimension Les attributs sont normalement descriptifs (valeurs textuelles) Ils permettent d'interpréter les faits Les dimensions couramment utilisées sont les clients, les produits et le temps. CLIENTS TEMPS PRODUITS FOURNISSEUR #id_client #id_temps #id_produit #id_fournisseur nom jour id_fournisseur fournisseur age moins produit adresse ville années prix_unitaire ville pays stock pays code_postal code_postal

38 Table de Faits Une table de faits a généralement deux types de colonnes: les faits numériques et les clés étrangères des dimensions. Une table de faits contient des faits au niveau de détail ou des faits qui ont été agrégés COMMANDE id_client id_produit id_temps date_comm date_envoi APPEL id_client id_temps num_appele debut_appel fin_appel OPERATION id_client id_temps id_operation valeur

39 Dimension x Faits Les tables de faits ont une grande quantité de données Les dimensions ont une petite quantité de données Les dimensions acceptent la redondance Normalement, les dimensions sont chargées dans la mémoire cache

40 Conception logique

41 Schéma étoile MAGASIN #id_magasin addresse num_tel ville Dimension CLIENTS #id_client nom age ville pays code_postal COMMANDE id_client id_produit id_magasin id_temps date_comm date_envoi quantite remise Table de Faits PRODUITS #id_produit fournisseur produit prix_unitaire stock Dimension TEMPS #id_temps jour mois année

42 Schéma étoile x ER Etoile ER

43 Schéma flocon MAGASIN #id_magasin addresse num_tel ville COMMANDE id_client id_produit PRODUITS #id_produit id_fournisseur id_gamme produit prix_unitaire FOURNISSEUR #id_fournisseur addresse ville num_tel id_magasin stock CLIENTS #id_client nom age ville pays code_postal id_temps date_comm date_envoi quantite remise TEMPS #id_temps jour mois GAMME #id_gamme description années

44 Schéma flocon Structure hiérarchique (plusieurs niveaux de dimensions). Plusieurs jointures pour la reconstruire. Dimensions plus petites.

45 Processus de conception Choisir le processus à modéliser Choisir les grains des faits Niveau de détails (transaction, récapitulatifs mensuels, etc) Choisir les dimensions (temps, clients, produits, etc) Choisir les mesures de faits De préférence des quantité numériques additives

46 Processus de conception D. Donsez, 2006

47 Conception physique

48 Passer de la conception logique à la physique Convertir les données recueillies au cours de la phase de conception logique dans une description physique Se concentrer sur la performance Les aspects de maintenance de la base de données

49 Passer de la conception logique à la physique

50 Structures physiques Tablespaces Tables and Partitioned Tables Views Integrity Constraints Dimensions Structures crées pour l'amélioration de la performance Indexes and Partitioned Indexes Materialized Views

51 Dimensions Dénormalisé create dimension fournisseur_dim LEVEL no_fournisseur IS (fournisseurs.no_fournisseur) LEVEL societe IS (fournisseurs.societe) LEVEL ville IS (fournisseurs.ville) LEVEL pays IS (fournisseurs.pays) HIERARCHY geog_rollup ( ville CHILD OF pays );

52 Dimensions Normalisé create dimension stock_dim LEVEL id_produit LEVEL produit LEVEL fournisseur LEVEL fournisseur_name HIERARCHY geog_rollup ( produit fournisseur CHILD OF IS (produits.ref_produit) IS (produits.nom_produit) IS (fournisseurs.no_fournisseur) IS (fournisseurs.societe) JOIN KEY (produits.no_fournisseur) REFERENCES FOURNISSEUR );

53 Indexes and Partitioned Indexes BITMAP index Reduced response time for large classes of ad hoc queries Reduced storage requirements compared to other indexing techniques Dramatic performance gains even on hardware with a relatively small number of CPUs or a small amount of memory Efficient maintenance during parallel DML and loads

54 Indexes and Partitioned Indexes BITMAP index simple CLIENTS... Ville... Nantes Paris Rennes Nantes Nantes Paris... BITMAP B_nantes B_paris B_rennes

55 Indexes and Partitioned Indexes BITMAP index encodé (Wu et Buchmann, 1998) CLIENTS... Ville... Nantes Paris Rennes Nantes Nantes Paris... BITMAP ENCODE B0 B Calculé par log2(n) n = domaine (par exemple, log2(3)=2) MAPPING Nantes 00 Paris 01 Rennes

56 Indexes and Partitioned Indexes BITMAP CREATE BITMAP INDEX ville_bm_ix ON fournisseurs(pays); Ex. select pays,count(*) from fournisseurs group by pays;

57 Indexes and Partitioned Indexes Sans BITMAP Elapsed: 00:00:00.04 Execution Plan SELECT STATEMENT Optimizer=ALL_ROWS (Cost=4 Card=16 Bytes=144) 1 0 SORT (GROUP BY) (Cost=4 Card=16 Bytes=144) 2 1 TABLE ACCESS (FULL) OF 'FOURNISSEURS' (TABLE) (Cost=3 Ca rd=29 Bytes=261) Avec BITMAP Elapsed: 00:00:00.02 Execution Plan SELECT STATEMENT Optimizer=ALL_ROWS (Cost=1 Card=16 Bytes=144) 1 0 SORT (GROUP BY NOSORT) (Cost=1 Card=16 Bytes=144) 2 1 BITMAP CONVERSION (COUNT) (Cost=1 Card=29 Bytes=261) 3 2 BITMAP INDEX (FULL SCAN) OF 'VILLE_BM_IX' (INDEX (BITMAP))

58 Materialized Views Vue agrégée qui améliore le temps d'exécution des requêtes Pré-calcul des jointures et des opérations d'agrégation antérieures au stockage Souvent appelée résumé.

59 Materialized Views L'optimiseur de requêtes reconnaît automatiquement quand une vue matérialisée peut et doit être utilisée pour satisfaire une demande.

60 Materialized Views Tout d'abord, les logs des vues matérialisées doivent être créés CREATE MATERIALIZED VIEW LOG ON fournisseurs WITH SEQUENCE, ROWID (NO_FOURNISSEUR,SOCIETE,VILLE,PAYS) INCLUDING NEW VALUES;

61 Materialized Views CREATE MATERIALIZED VIEW fournisseurs_pays BUILD IMMEDIATE REFRESH FAST ENABLE QUERY REWRITE AS select pays,count(*) from fournisseurs group by pays;

62 Materialized Views select pays,count(*) from fournisseurs group by pays; Elapsed: 00:00:00.00 Execution Plan SELECT STATEMENT Optimizer=ALL_ROWS (Cost=3 Card=16 Bytes=352) 1 0 MAT_VIEW REWRITE ACCESS (FULL) OF 'FOURNISSEURS_PAYS' (MAT _VIEW REWRITE) (Cost=3 Card=16 Bytes=352)