Fouille de Données : OLAP & Data Warehousing

Fouille de Données : OLAP & Data Warehousing Nicolas Pasquier Université de Nice Sophia-Antipolis Laboratoire I3S

Chapitre 2. Data warehousing Définition : qu est-ce que le data warehousing? Entrepôt de données vs. bases de données Modèle multi-dimensionnel des données Modélisation d un entrepôt de données Construction d un entrepôt de données Bases de données vs. data warehousing Data warehousing vs. data mining 2

Data warehouses & data warehousing Qu est-ce qu un data warehouse? «une collection de données orientées sujet, intégrées, historisées et persistantes, utilisée pour le support d un processus d aide à la décision.» W. H. Inmon Une base de données servant de support pour l aide à la décision qui est maintenue séparément de la base de données opérationnelle Contient un résumé des données opérationnelles, à un niveau élevé d abstraction, concernant une période étendue Objectif : l analyse multi-dimensionnelle des données Ex : comparer les ventes selon le pays, la ville, le client, le mois, etc. Qu est-ce que le data warehousing? Désigne les processus de construction et d utilisation des entrepôts de données 3

Une collection de données (1) Orientées sujets Organisées autours de sujets principaux (produits, clients, ventes, etc.) Pour la modélisation et l analyse des données pour l aide à la décision traitement quotidien des transactions ou opérations Fournit une vue simple et concise autour d un sujet particulier en excluant les données inutiles pour le processus d aide à la décision Intégrées Requiert une intégration de données sûres, consistantes et complètes Intégration de sources multiples et hétérogènes BD relationnelles, transactionnelles, orientées objets, flat files, applications dédiées, etc. Diverses sources (Ex : diverses services, agences, départements, etc.) Techniques de nettoyage et intégration des données Consistance entre les diverses sources des noms, des unités de mesure, etc. 4

Une collection de données (2) Historisées Point de vue de l entrepôt de données est plus étendu que celui de la BD opérationnelle BD opérationnelle : valeur actuelle de la donnée Entrepôt de données : valeurs d une perspective historique (ex : derniers 5 ans) Toutes les structures de clés d un entrepôt de données contiennent une référence à la date, explicitement ou implicitement Persistantes Stockage séparé en mémoire secondaire des données transformées de la BD opérationnelle Pas de mise à jour en ligne dans un entrepôt de données Pas besoin de mécanismes de traitement des transactions, récupération et contrôle d accès concurrents Opérations d accès : chargement initial des données, rafraîchissement des données et accès aux données 5

Entrepôts de données vs. bases de données OLTP : On-Line Transaction Processing Tâche principale des SGBD Traitement des opérations quotidiennes : enregistrements des opérations, gestion de stock, facturation, traitements de salaires, comptabilité, etc. Minimisation des redondances de données Contraintes d intégrité, concurrence d accès, résistance aux pannes OLAP : On-Line Analytical Processing Tâche principale des entrepôts de données Techniques d analyse des données ( généralisation, consolidation, agrégation, etc.) Visualisation des données selon différents angles de vues Grand volume de données et contraintes d efficacité des requêtes 6

Entrepôts de données vs. bases de données OLTP OLAP Utilisateurs Secrétaires, clients, employés Analystes, gestionnaires Fonction Opérations quotidiennes Aide à la décision Modélisation ER, orientée application Etoile/Flocon, orienté sujet Données Actuelles, à jour Détaillées, non abstraites Isolées Utilisation Répétitive Ad-hoc Historisées Résumés, multi-dimensionnelles Intégrées, consolidées Accès Lecture/écriture Accès concurrents Nombreux balayages Lecture seules Unité de travail Transactions atomiques Requêtes complexes # enreg. accédés Dizaines Millions # utilisateurs Centaines-milliers Dizaines-centaines Taille BD 100 MO - GO 100 GO - TO Métrique Traitement des transactions Temps de réponse (secondes) Traitement des requêtes Temps de réponse (minutes) 7

Pourquoi un entrepôt de données séparé? Hautes performances des deux systèmes SGBD optimisés pour l OLTP : méthodes d accès, indexage, contrôle de concurrence d accès, récupération DW optimisés pour l OLAP : requêtes OLAP complexes, vues multidimensionnelles, consolidation des données Différentes fonctions et différentes données Données manquantes : aide à la décision requiers des données sur une longue durée non conservées dans les BD Consolidation : aide à la décision requiers la consolidation (agrégation, généralisation) des données de sources hétérogènes Qualité des données : sources différentes utilisent souvent des noms, formats, codes et mesures différents qui doivent être uniformisés 8

Modélisation d un entrepôt de données Basé sur un modèle multi-dimensionnel des données qui voit les données sous la forme d un data cube (cube de données) Modélisation d un entrepôt de données : dimensions et mesures Data cube : permet de modéliser et visualiser les données selon différentes dimensions Les dimensions constituent les points de vues depuis lesquels les données peuvent être observées Chaque dimension est représentée par une table Ex : Localisation (ville, département, pays, région), Produit (article, type, catégorie), Date (jour, semaine, mois, trimestre, année) Tables de dimensions peuvent être générées automatiquement selon la distribution des données 9

Modélisation d un entrepôt de données Thème central est représenté par une table de faits Table de faits contient les valeurs des mesures et des clés vers les tables de dimensions Valeur d une mesure : résultat d une opération d agrégation des données Ex : montant_ventes, quantité_vendue Les clés des tables de dimension sont en général construites automatiquement L ensemble des valeurs d une mesure pour une combinaison de valeur des dimensions constitue un cuboïde Ex : entrepôt de données des ventes électroniques d une société. Montants des ventes sur l année par type d article, par ville et par mois Une valeur est associée à chaque combinaison type ville mois 10

Exemple de cuboïde (1) Dimensions : Produit (type), Localisation (ville) et Date (mois) Produit Disques durs Processeurs Moniteurs Répondeurs Téléphones Janvier Février Mars Avril Mai Juin Date Juillet Août Septembre Octobre Novembre Décembre Localisation Paris Marseille Rome Milan 11

Exemple de cuboïde (2) Dimensions : Produit (type) et Date (trimestre) Localisation = «Londres» Produit Date Disque dur Moniteur Processeur Téléphone Répondeur Trimestre 1 Trimestre 2 Trimestre 3 Trimestre 4 605 425 311 156 75 680 512 346 162 81 812 523 385 184 86 927 638 421 203 105 12

Cube de données : un treillis de cuboïdes aucune 0-D (apex) cuboïd produit date localisation client 1-D cuboïd produit,date produit,localisation produit,client date,localisation date,client localisation,client 2-D cuboïd produit,date,localisation produit,date,client produit,localisation,client date,localisation,client 3-D cuboïd produit,dates,localisation,client 4-D (base) cuboïd 13

Les dimensions multi-niveaux Différents niveaux d abstraction / spécialisation pour chaque dimension Représentés par les tables de dimensions Granularité d une dimension : nombre de niveaux d abstraction Exemple : Date Produit Catégorie Type Article Localisation Ville Département Pays Région Semaine Année Semestre Trimestre Mois Jour 14

Hiérarchies de concepts d une dimension Concept : valeur correspondant à un niveau d abstraction Exemple : dimension Localisation Toutes Toutes Région Europe.. Amérique du nord Pays France.. Italie Etats-Unis.. Canada Ville Marseille.. Nice Rome Milan Boston Seattle Toronto.. Montreal 15

Trois catégories de mesures Distributives Le résultat dérivé de l application de la fonction à n valeurs agrégés est le même que celui dérivé de son application sur toutes les données sans partitionnement Ex : count(), sum(), min(), max() Algrébriques Peut être calculée par un fonction algébrique avec m arguments (m entier borné), chacun obtenu en appliquant une fonction d agrégation distributive Ex : avg() {sum(), count()}, standard_deviation() Hollistiques Pas de limite constante sur la taille de stockage nécessaire pour décrire un sous-agrégat Ex : median(), mode(), rank() Calcul efficace de valeurs approchées avec une marge d erreur bornée 16

Modélisation d un entrepôt de données Nécessite un modèle concis et orienté sujet modèle entités-relations Schéma en étoile Une table de faits centrale connectée à un ensemble de tables de dimensions Schéma en flocon Un raffinement du schéma en étoile où certaines hiérarchies de dimensions sont normalisés en un ensemble de tables de dimensions plus petites Schéma en constellation Plusieurs tables de faits qui partagent des tables de dimensions. Peut-être vu comme une collection d étoiles (schéma en galaxie ou constellation de faits) 17

Schéma en étoile Table de faits centrale connectée aux tables de dimensions Client NumClient NomClient TypeClient Date CléDate Jour Semaine Mois Trimestre Semestre Année Vente NumClient NumProduit CléDate CléLocalisation QuantitéVendue PrixTotal Produit NumProduit Article Type Catégorie PrixUnitaire Fournisseur Localisation CléLocalisation Ville Département Pays Région 18

Schéma en flocon Tables de dimensions normalisées (décomposées) Client NumClient NomClient TypeClient Date CléDate Jour Semaine Mois Trimestre Semestre Année Vente NumClient NumProduit CléDate CléLocalisation QuantitéVendue PrixTotal Produit NumProduit Article CléType PrixUnitaire Fournisseur Localisation CléLocalisation Ville Département CléPays Catégorie CléType Type Catégorie Pays CléPays Pays Région 19

Schéma en constellation de faits Plusieurs tables de faits reliées aux tables de dimensions Client NumClient NomClient TypeClient Date CléDate Jour Semaine Mois Trimestre Semestre Année Vente NumClient NumProduit CléDate CléLocalisation QuantitéVendue PrixTotal Produit NumProduit Article Type Catégorie PrixUnitaire Fournisseur Localisation CléLocalisation Ville Département Pays Région Transport NumProduit CléDate LocDépart LocArrivée Prix Quantité 20

Un exemple de cuboïde Ventes sur l année Dimensions Produit (catégorie) Localisation (ville) Date (trimestre) Informatique Paris 30 Marseille 25 Rome Milan 35 30 Téléphonie 30 20 15 30 25 20 20 1 er trimestre 15 25 25 20 20 25 2 e trimestre 10 30 45 45 45 35 35 40 40 35 35 3 e trimestre 30 25 35 40 4 e trimestre 21

Dimensions Produit (catégorie) Localisation (pays) Date (trimestre) Ventes en France au 1 er trimestre Ventes totales au 1 er trimestre Un autre exemple de cuboïde Total France Italie Total Informatique Téléphonie Valeur de la mesure est représentée pour chaque dimension 85 90 175 85 55 75 130 22 55 55 70 65 135 30 35 70 135 130 265 1 er trimestre 20 45 135 345 360 705 2 e trimestre 25 80 345 345 360 705 3 e trimestre 55 215 215 175 4 e trimestre 390 130 130 185 315 Tous, tous, tous Total

Opérations sur le data cube (1) Opérations de manipulation interactive des cuboïdes Slice : sélection sur une dimension du cube Ex : 3 ème trimestre sur la dimension Date pour visualiser les ventes par Localisation et Produit durant ce trimestre France Italie Total Informatique Total 70 65 135 Téléphonie 45 30 75 25 35 60 23

Opérations sur le data cube (2) Dice : définition d un sous-cube par sélection sur deux (ou plus) dimensions Ex : critère (Localisation = Paris Rome) (Date = 1 er trimestre 2 ème trimestre) (Produit = Informatique Téléphonie) Informatique Paris 30 Rome 35 Téléphonie 30 20 30 20 20 1 er trimestre 15 20 30 15 25 2 ème trimestre 24

Opérations sur le data cube (3) Pivot : présentation alternative du cube Transformation en une série de plans 2D Renversement du cube sur un ou plus axes pour une vision alternative Ex : renversement sur l axe Date Rome Téléphonie 35 Paris 35 25 20 25 1 er trimestre 15 15 25 2 ème trimestre Informatique 35 30 30 20 25

Opérations sur le data cube (4) Roll-up : généralisation du cube Supprimer une dimension Remonter dans une hiérarchie de concepts d une dimension Ex : remonter du niveau Trimestre au niveau Semestre pour Date Informatique Téléphonie 50 Paris 50 70 Marseille 40 35 70 1 er semestre 40 40 70 35 2 e semestre Rome 65 55 55 60 Milan 55 60 60 65 60 60 26

Opérations sur le data cube (5) Drill-down : spécialisation du cube Ajouter une dimension Ex : dimension TypeClient Descendre dans une hiérarchie de concepts Ex : descendre du niveau Catégorie au niveau Type pour Produit Disques durs Paris Marseille Rome Milan Processeurs Moniteurs 20 15 25 20 20 15 25 20 25 20 Répondeurs Téléphones 25 15 25 20 25 20 25 25 25 20 20 25 20 10 30 20 15 15 15 1 er semestre 10 10 30 10 25 15 45 15 50 2 e semestre 27

Conception d un entrepôt de données Approche haut-bas, bas-haut ou une combinaison des deux Haut-bas : débuter par le planning et la conception du modèle (mature) Bas-haut : débuter par des essais et des prototypes (rapide) Du point de vue de l ingénierie du logiciel Cascade : analyse structurée et systématique lors de chaque étape avant de passer à la suivante Spirale : génération rapide de systèmes fonctionnels croissants ; modifications rapides et adaptation du modèle facile Processus de conception d un entrepôt de données Choix du processus à modéliser, ex : commandes, ventes, livraison Choix du grain (niveau de détail des données) pour le processus Choix des dimensions pour chaque table de faits Choix des mesures stockées dans les tables de faits 28

Trois modèles d entrepôts de données Entrepôt global Contient des données concernant l ensemble des composantes de l organisation Plusieurs BDs opérationnels et sources extérieures ; plusieurs thèmes Data mart Un sous-ensemble de l entrepôt global concernant un groupe spécifique d utilisateurs Ex : data mart du service commercial, data mart concernant le transport Data mart dépendant ou indépendant de l entrepôt de données Entrepôt virtuel Un ensemble de vues construites sur la BD opérationnelle Matérialisation de certaines vues, les autres sont dérivées des premières Surcharge le serveur de BD 29

Architectures des serveurs OLAP (1) ROLAP : Relational OLAP Utilisation de SGBD relationnel pour stocker et gérer les données de l entrepôt Avantages : souplesse, évolutions faciles Architecture de loin la plus populaire Ex : MetaCube de Informix et DSS server de Microstrategy MOLAP : Multi-dimensional OLAP SGBD multi-dimensionnels dédiés aux calculs de cubes de données multi-dimensionnels Data cubes implantés comme des matrices à plusieurs dimensions Techniques de compression pour les matrices creuses / éparses Avantage : efficacité de traitement des requêtes Ex : Essbase de Arbor 30

Architectures des serveurs OLAP (2) HOLAP : Hybrid OLAP Données de bas niveau stockées dans BD relationnelle Données agrégées stockées séparément dans des matrices Avantages : équilibre entre la facilité d évolution et la rapidité de traitement des requêtes Ex : Microsoft SQL Server 7.0 OLAP services Serveur SQL spécialisés Serveurs SQL spécialisés implantent des opérateurs pour des requêtes OLAP complexes Requêtes SQL sur les schémas en étoiles et flocons accédés en lecture seulement Ex : Redbrick de Informix 31

Matérialisation des cubes de données Les temps de réponse des requêtes de support pour l aide à la décision doivent être faibles, de l ordre de quelques minutes Solution : matérialisation des données et indexage Matérialisation complète : tous les cuboïdes Espace mémoire nécessaire important (redondances) Aucune matérialisation : cuboïde de base (le plus général) seul Autres cuboïdes sont calculés à partir du cuboïde de base Temps de réponse longs (calculs) Matérialisation partielle : certains cuboïdes Sélectionner les cuboïdes : selon la taille, la fréquence d accès, etc. Exploiter les cuboïdes matérialisés durant le traitement des requêtes Mise à jour efficace des cuboïdes matérialisés 32

Matérialisation des index : vecteurs de bits Indexage sur un attribut (colonne) d une table Associe à chaque valeur de l attribut la liste des tuples correspondants n valeurs de l attribut : n vecteurs de bits Ex : attributs Région et TypeClient de la table Client Table Client Index sur Région Index sur TypeClient RID Région TypeClient RID Asie Europe Amérique RID Détaillant Grossiste 1 2 3 4 5 Asie Europe Asie Amérique Europe Détaillant Grossiste Grossiste Détaillant Grossiste 1 2 3 4 5 1 0 1 0 0 0 1 0 0 1 0 0 0 1 0 1 2 3 4 5 1 0 0 1 0 0 1 1 0 1 Taille d un vecteur de bits : nombre d enregistrements Domaines à haute cardinalité : techniques de compression des bitmaps Efficacité des opérations (intersection, union, jointure et agrégation) 33

Matérialisation des index : jointures Indexage entre les tables de dimensions et la table de faits Associe à chaque tuple de la table de dimension la liste des RID des tuples de la table de faits joints Efficacité des jointures (opérations coûteuses) Limite les accès aux tuples des tables Ex : jointures entre les tables de dimensions Produit et Localisation, et la table de faits Vente Vente Produit R57 Localisation R238 LCD-15 Moniteur Informatique Paris France Europe P4-700 Process. Informatique R666 R2041 Rome Italie Europe R8451 34

Matérialisation des index : jointures composites Index de jointure composites : jointures multi-dimensionnelles Associe à une combinaison de tuples des tables de dimensions la liste des RID des tuples de la table de faits joints Ex : index de jointure entre la table Vente et les dimensions Localisation et Produit Table Vente Index sur Localisation / Produit RID Ville Article Localisation Produit RID 57 238 666 2041 8451 Paris Paris Rome Paris Rome LCD-15 LCD-15 P4-700 P4-700 LCD-15 Paris Paris Rome LCD-15 LCD-15 LCD-15 57 238 8451 Index de jointure peuvent être matérialisés par vecteurs de bits Problème : quels index matérialiser? 35

Matérialisation des données Les problèmes : Quelles vues matérialiser? Comment mettre à jour efficacement les vues matérialisées? Comment utiliser efficacement les vues matérialisées? Optimisation des requêtes sur le cube de données Cube de données des ventes par Produit, Localisation et Date Cuboïde 1 : {article, ville, année} Cuboïde 2 : {catégorie, pays, année} Cuboïde 3 : {catégorie, département} Cuboïde 4 : {article, département} pour année = 2000 Question : Comment calculer efficacement le cuboïde {catégorie, département} pour année = 2000? A partir des cuboïdes 1, 3 ou 4 Selon les index, le nombre de sous-concepts de chaque concept, etc. 36

Matérialisation des données : relations multi-niveaux Comment matérialiser les vues? Tuples généralisés dans la table de faits de base Tables de dimensions multi-niveaux Champ «Niveau» indique le degré d abstraction du tuple Table des faits de base et généralisés Article P4-700 P4-700 P4-700 P4-700 Jour 01 Mois Année Quantité Février 2001 20 16 Février 2001 12 All Février 2001 45 All All 2001 520 Date Faits de Vente Localisation Clé Jour Mois Année RID Niveau Quantité Clé Ville Pays Région D1 01 01 2001 51 1 5 L1 Paris France Europe D16 All 01 2001 347 2 26 L10 All France Europe 5265 4 487 D87 All All 2001 7023 5 1025 L98 All All Europe 37

Calcul de cubes : requêtes SQL Base cuboïde : Vente (Date,Produit,Localisation,Client) select CléDate, NumProduit, CléLocalisation, NumClient, sum(quantitévendue) from Vente group by CléDate, NumProduit, CléLocalisation, NumClient Data cube de n dimensions : union de 2 n requêtes select CléDate, NumProduit, CléLocalisation, NumClient, sum(quantitévendue) from Vente group by CléDate, NumProduit, CléLocalisation, NumClient union all select CléDate, NumProduit, CléLocalisation,, sum(quantitévendue) from Vente group by CléDate, NumProduit, CléLocalisation union all union all select,,,, sum(v.quantitévendue) from Vente Base cuboïde avec regroupement par mois select d2.clédate, v.numproduit, v.clélocalisation, v.numclient, sum(v.quantitévendue) from Vente v, Date d1, Date d2 where v.clédate = d1.clédate and d1.mois = d2.mois and d2.jour = all group by d1.mois, v.numproduit, v.clélocalisation, v.numclient 38

Calcul de cubes : requêtes SQL étendu (1) Extensions cube, grouping sets et rollup du group by Simplifient la syntaxe d écriture et optimisent les calculs (accès aux tables) Data cube de n dimensions : une requête cube select CléDate, NumProduit, CléLocalisation, NumClient, sum(quantitévendue) from Vente group by cube (CléDate, NumProduit, CléLocalisation, NumClient) Data cube partiel : une requête grouping sets select CléDate, NumProduit, CléLocalisation, NumClient, sum(quantitévendue) from Vente group by grouping sets ((CléDate, NumProduit), (CléDate, CléLocalisation), (CléDate, NumClient)) Cuboïdes (Date,Localisation), (Date,Client), (Produit,Localisation), (Produit,Client) select CléDate, NumProduit, CléLocalisation, NumClient, sum(quantitévendue) from Vente group by grouping sets (CléDate, NumProduit), grouping sets (CléLocalisation, NumClient) Cuboïdes (Date,Localisation), (Date,Client), (Produit,Localisation), (Produit,Client) 39

Calcul de cubes : requêtes SQL étendu (2) Data cube avec regroupement par mois select d2.clédate, v.numproduit, v.clélocalisation, v.numclient, sum(v.quantitévendue) from Vente v, Date d1, Date d2 where v.clédate = d1.clédate and d1.mois = d2.mois and d2.jour = all group by cube (d1.mois, v.numproduit, v.clélocalisation, v.numclient) Data cube partiel : une requête grouping sets select CléDate, NumProduit, CléLocalisation, NumClient, sum(quantitévendue) from Vente group by rollup (CléDate, NumProduit, CléLocalisation, NumClient) n+1 cuboïdes : (Date,Produit,Localisation,Client), (Date,Produit,Localisation), (Date,Produit), (Date), ( ) Permet la création de vues multi-niveau select Jour, Mois, Annee, sum(quantitévendue) from Vente v, Date d where v.clédate = d.clédate group by rollup (Jour, Mois, Annee) 40

Création de dimensions en SQL étendu Exprimer des contraintes d intégrité intra-table Ex : Mois df Trimestre, Pays df Région Dimension Date create dimension Date_dim level Jour is Date.Jour level Semaine is Date.Semaine level Mois is Date.Mois level Trimestre is Date.Trimestre level Année is Date.Année hierarchy Date_rollup {Jour child of Mois child of Trimestre child of Année} hierarchy Sem_rollup {Jour child of Semaine child of Année} attribute Jour determines (NomJour, NumJourDansMois) attribute Semaine determines (NumSemaineDansAnnée) attribute Mois determines (NomMois, NombreJours) attribute Année determines (Bissextile) 41

Nouvelles fonctionnalités de SQL étendu Nouveaux opérateurs structurels partition : partitionne une table en regroupant les tuples partageant les valeurs d une ou plusieurs colonnes create materialized view : vue multi-niveaux avec pré-agrégation stockées indépendamment Nouveaux opérateurs de mesure rank, top_n, bottom_n, variance, stddev, etc. Optimisation de requêtes Query rewriting : ré-écriture de requêtes pour optimiser les temps de calcul Utilisation des vues multi-niveaux matérialisées et des dimensions 42

Construction d index bitmaps Indexage sur le Pays de Localisation pour la table Vente create bitmap index Vente-LocalisationPays on Vente(Localisation.Pays) from Vente, Localisation where Vente.CléLocalisation = Localisation.CléLocalisation Un vecteur de bits pour chaque valeur de l attribut Pays Taille de chaque vecteur : nombre de tuple dans Vente Optimisation des requêtes select sum(quantitévendue) from Vente, Localisation where Vente.CléLocalisation = Localisation.CléLocalisation and Localisation.Pays = France Utilise seulement la table Vente et le bitmap pour le Pays «France» 43

Architecture multi-tiers Sources externes Extraire Nettoyer Transformer Charger Rafraîchir Méta-données Entrepôt de données Serveur OLAP Servir Requêtes & Rapports Analyses BDs opérationnelles Data marts Serveur OLAP Data mining Sources de données Bottom-tiers : Serveur DW Middle-tiers : Moteur OLAP Top-tiers : GUI 44

Les méta-données Méta-données : données qui définissent l entrepôt de données Description de la structure du DW Schéma, dimensions, hiérarchies, définitions des données, et localisation et contenu des data marts Méta-données d administration Historique de construction et transformation des données, statistiques d utilisation et rapports d erreurs Algorithmes de généralisation Calculs des mesures, agrégations, partition., requêtes et rapports prédéfinis Méta-données d intégration BDs sources et leurs contenus, description des passerelles, règles d extraction, nettoyage et transformation des données, règles de rafraîchissement et sécurité Données liées aux performances Index, vues, algorithmes de compression et accès aux données, règles de planification des mises-à-jour 45

Outils des entrepôts de données Extraction des données Récupération depuis plusieurs sources hétérogènes internes et externes Nettoyage des données Détection et gestion des erreurs, des valeurs manquantes ou incertaines Transformation des données Conversion du format source au format de l entrepôt de données Outils de chargement Trient, résument, consolident, calculent les vues, construisent les index et les partitions, et vérifient l intégrité des données Rafraîchissement Propagation des mises-à-jours des données source vers l entrepôt de données 46

Approche de conception recommandée Data mart distribué Entrepôt de données multi-tiers Data mart Data mart Entrepôt de données global Raffinement du modèle Raffinement du modèle Définir un modèle général de l entrepôt de données 47

De l OLAP à l OLAM OLAM : On-Line Analytical Mining Intégration des techniques de l OLAP et du data mining Data mining multi-niveaux sur des données multi-dimensionnelles Pourquoi? Pour les performances! Interfaces nombreuses autour des entrepôts de données ODBC, OLE DB, passerelles, outils OLAP, etc. Inutile d exporter les données pour les traiter par un moteur de data mining externe Pourquoi? Pour la qualité de l analyse! Données de qualité dans les DW (intégrées, consistantes et nettoyées) L analyse fournie par l OLAP n est pas approfondie Étendre les types de connaissances extraites (hiérarchies de concepts, multi-dimensions, etc.) 48

Architecture OLAM Requête DM API GUI Résultat DM Interface utilisateur Moteur OLAM Moteur OLAP OLAP/OLAM API Cube de données Base de données multi-dimensionnelle Métadonnées BD multidimensionnelle Base de données Intégration & filtrage API Base de données Base de données Intégration, nettoyage Consolidation Filtrage Entrepôt de données Dépôt de données 49

Résumé Data warehouse ou entrepôt de données Collection de données orientées sujet, intégrées, historisées et persistantes utilisées pour le support de l aide à la décision OLTP (interroger, enregistrer) vs. OLAP (résumer, analyser) vs. Data mining (explorer, contraster, découvrir) Basé sur un modèle multi-dimensionnel des données Schéma en étoile, en flocon, en constellation Un cube de données est défini par ses dimensions et mesures Opérations OLAP : drilling, rolling, slicing, dicing et pivoting Serveurs OLAP : ROLAP, MOLAP, HOLAP Efficacité des requêtes Aucune matérialisation vs. matérialisation complète vs. partielle Index par vecteurs de bits et index de jointure 50

Références bibliographiques S. Chaudhuri, U. Dayal. An overview of data warehousing and OLAP technology. ACM SIGMOD Record, 26:65-74. Mars 1997. G. Gardarin. Internet, Intranet et bases de données. Data web, data média, data warehouse, data mining. Eyrolles. Avril 2000. J. Gray, S. Chaudhuri, A. Bosworth, A. Layman, D. Reichart, M. Venkatrao, F. Pellow, H. Pirahesh. Data cube: a relational aggregation operator generalizing group-by, cross-tab and sub-totals. Data Mining and Knowledge Discovery, 1:29-54. 1997. V. Harinarayan, A. Raiaraman, J. D. Ullman. Implementing data cubes efficiently. SIGMOD conference, pages 205-216, 1996. W. H. Inmon. Building the data warehouse. Jhon Wiley. 1992. M. Jarke, M. Lenzerini, Y. Vassiliou, P. Vassiliadis. Fundamentals of data warehouses. Springer-Verlag. 2000. E. Thomsen. OLAP solutions: building multidimensional information systems. John Wiley & Sons editors. 1997. OLAP Council. MDAPI specification version 2.0. 1998. http://www.olapcouncil.org/research/apily.htm 51