Fouille de Données : OLAP & Data Warehousing

(1)

Fouille de Données :

OLAP & Data Warehousing

Nicolas Pasquier

Université de Nice Sophia-Antipolis

Laboratoire I3S

(2)

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

(3)

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

(4)

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.

(5)

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

(6)

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

(7)

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

Historisées

Résumés, multi-dimensionnelles Intégrées, consolidées

Utilisation Répétitive Ad-hoc

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)

(8)

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 multi- dimensionnelles, 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

(9)

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

(10)

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

(11)

Mars Avril

Exemple de cuboïde (1)

 Dimensions : Produit (type), Localisation (ville) et Date (mois)

Décembre

Rome Milan Marseille Paris

MoniteursProcesseurs

Janvier Téléphones

Répondeurs Disques durs

Localisation

Produit Date

Juin Février

Mai

Juillet Août

Septembre Octobre

Novembre

(12)

Exemple de cuboïde (2)

 Dimensions : Produit (type) et Date (trimestre)

Trimestre 1 Trimestre 2 Trimestre 3 Trimestre 4

Date Disque dur Moniteur Processeur Téléphone Répondeur

605 425 311 156 75

680 512 346 162 81

812 523 385 184 86

927 638 421 203 105

Produit Localisation = « Londres »

(13)

Cube de données : un treillis de cuboïdes

client

produit date localisation

produit,date produit,localisation produit,client date,localisation date,client localisation,client aucune

date,localisation,client produit,date,localisation produit,date,client produit,localisation,client

produit,dates,localisation,client

0-D (apex) cuboïd

1-D cuboïd

2-D cuboïd

3-D cuboïd

4-D (base) cuboïd

(14)

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 :

Année

Semestre Trimestre

Mois Semaine

Jour

Date

Ville Département

Pays

Localisation

Catégorie Type Article

Produit

Région

(15)

Hiérarchies de concepts d’une dimension

 Concept : valeur correspondant à un niveau d’abstraction

 Exemple : dimension Localisation

Ville Pays Région

Marseille Rome Milan

France

Nice

Italie Europe

Toutes

…..

Boston Toronto Montreal

Etats-Unis

Seattle

Canada Amérique du nord

…..

….. …..

Toutes

(16)

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

(17)

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)

(18)

Schéma en étoile

 Table de faits centrale connectée aux tables de dimensions

NumClient NomClient TypeClient

Client

NumProduit Article

Type Catégorie PrixUnitaire Fournisseur

Produit

CléDate Jour Semaine Mois Trimestre Semestre Année

Date

CléLocalisation Ville

Département Pays

Région

Localisation Vente

NumClient NumProduit CléDate

CléLocalisation QuantitéVendue PrixTotal

(19)

Schéma en flocon

 Tables de dimensions normalisées (décomposées)

Client

NumProduit Article

CléType PrixUnitaire Fournisseur Produit

Date

Localisation NumClient

NumProduit CléDate

CléType TypeCatégorie

Catégorie

CléPays PaysRégion

Pays CléLocalisation

Ville

Département CléPays Vente

(20)

Schéma en constellation de faits

 Plusieurs tables de faits reliées aux tables de dimensions

Client

NumProduit Article

Type Catégorie PrixUnitaire Fournisseur Produit

Date

Localisation

NumProduit CléDate LocDépart LocArrivée Prix

Quantité Transport

CléLocalisation Ville

Département PaysRégion

Vente NumClient NumProduit CléDate

(21)

 Ventes sur l’année

 Dimensions

● Produit (catégorie)

● Localisation (ville)

● Date (trimestre)

Un exemple de cuboïde

Rome

Milan Marseille Paris Inform

atique

Téléphonie 1^er trimestre

2^e trimestre

3^e trimestre

4^e trimestre 30

20

15

25

10

45 30 30

20

25 45 45

30 25

15

20

35 35

25 35

30

20

40 40

35 30

25

35 35

40

(22)

 Dimensions

● Produit (catégorie)

● Localisation (pays)

● Date (trimestre)

 Valeur de la mesure

Un autre exemple de cuboïde

Total

Total Italie France

Total Inform

atique

Téléphonie 55

30

35

20

45

25

85

55

70

345

215

130

705

390

315 80

55 1^er trimestre

2^e trimestre

3^e trimestre

4^e trimestre

135 90

75

65

130 360 175

130

135

265

175

185 215

130

345 345

705 360 85

55

70

135

Ventes totales au 1^er trimestre Ventes en France au 1^er trimestre

(23)

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

30

35

75

60

Total Italie France

Total Inform

atique

Téléphonie

45

25

70 65

135

(24)

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)

Rome Paris Inform

atique

Téléphonie 1^er trimestre

2^èm^e trimestre 30

20 20

15

30

20 35

30

20

30

15

25

(25)

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

Informatique Téléphonie

Rome

Paris 1^er trimestre

2^èm^e trimestre 35

20 25

15

35

25 35

30

25

30

15

20

(26)

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

Rome

Milan Marseille Paris Inform

atique

Téléphonie 1^er semestre

2^e semestre 50

35

70

40

50

70 40

55 65

60 55

60

70

55

60

40

35

60

65

(27)

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

Rome

Milan Marseille Paris

Disques durs

Moniteurs

1^er semestre

2^e semestre

20

15 25

25 20

25 15

20 25

25 20

20

25

20

25

20

25

20

25 Processeurs

Téléphones

20

15

30

25

45

50

10

15

15 15

20 25

30 10

10 Répondeurs

(28)

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

(29)

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

(30)

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

(31)

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

(32)

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

(33)

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

 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)

Table Client

Région TypeClient Asie

Europe Asie Amérique Europe

Détaillant Grossiste Grossiste Détaillant Grossiste

RID

Index sur Région 1

23 45

Asie 1 01 00

Europe 0 10 01

Amérique 0 00 10

Index sur TypeClient Détaillant

1 00 10

Grossiste 0 11 01 RID

1 23 45

RID 1 23 45

(34)

 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

Matérialisation des index : jointures

Produit Localisation

Vente

R238 R666 R57

Moniteur Paris France

LCD-15 Informatique Europe

Rome Italie Europe Process.

P4-700 Informatique

R2041

(35)

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

 Index de jointure peuvent être matérialisés par vecteurs de bits

 Problème : quels index matérialiser ?

RID

Table Vente Ville Article 57

238666 20418451

Paris Paris Rome Paris Rome

LCD-15 LCD-15 P4-700 P4-700 LCD-15

RID Index sur Localisation / Produit

57 238… 8451… Produit

Localisation Paris Paris

… Rome…

LCD-15 LCD-15

… LCD-15

…

……

(36)

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.

(37)

 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

Matérialisation des données : relations multi-niveaux

D16

Date

Clé Mois Année

D1 01 2001

01 2001

D87 All 2001

Jour 01 All All

Localisation

L1 Paris France Clé Ville Pays

L10 All France

L98 All All

Europe Région

Europe Europe Jour

01

Table des faits de base et généralisés

Mois Année Quantité

Février 2001 20

16 Février 2001 12

Article P4-700 P4-700

All Février 2001 45

P4-700

All All 2001 520

P4-700

Faits de Vente

Quantité RID

26 347

1025 7023

5 51

Niveau 1 2

5

487

5265 4

(38)

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

ⁿ

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’

(39)

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)

(40)

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)

(41)

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)

(42)

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

(43)

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 »

(44)

Architecture multi-tiers

BDs opérationnelles

Sources externes

Sources de

Extraire Nettoyer Transformer

Charger Rafraîchir

Bottom-tiers : Middle-tiers : Top-tiers :

Data marts Entrepôt de données Méta-données

Requêtes &

Rapports

Analyses

Data mining Servir

Serveur OLAP Serveur

OLAP

(45)

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

(46)

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

(47)

Approche de conception recommandée

Définir un modèle général de l’entrepôt de données

Raffinement du modèle

Data mart

Data mart Entrepôt de

données global Entrepôt de données

multi-tiers Data mart

distribué

Raffinement du modèle

(48)

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.)

(49)

Intégration, nettoyage

Architecture OLAM

Base de

données Base de

données Entrepôt

de données Consolidation

API Base de données Base de données

multi-dimensionnelle

Méta- données API Cube de données

API GUI

Moteur OLAM Moteur OLAP

Requête DM Résultat DM

Dépôt de données BD multi- dimensionnelle OLAP/OLAM

Interface utilisateur

Intégration & filtrage Filtrage

(50)

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

(51)

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