Les entrepôts de données

BOUKIL – STID 2020

1
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Le marché du décisionnel
 Démonstration
2
Le contexte
 Besoin: prise de décisions stratégiques et tactiques
 Pourquoi: besoin de réactivité
 Qui: les décideurs (non informaticiens)
 Comment: répondre aux demandes d’analyse des données, dégager
des informations qualitatives nouvelles
Pourquoi et
Qui sont mes
comment le
meilleurs
chiffre d’affaire
clients?
a baissé?

A combien
Quels clients
s’élèvent mes
consomment
ventes
beaucoup de
journalières?
poisson?
3
Les données utilisables par les décideurs
 Données opérationnelles (de production)
 Bases de données (Oracle, SQL Server)
 Fichiers, …
 Paye, gestion des RH, gestion des commandes…

 Caractéristiques de ces données:

 Distribuées: systèmes éparpillés
 Hétérogènes: systèmes et structures de données différents
 Détaillées: organisation des données selon les processus
fonctionnels, données surabondantes pour l’analyse
 Peu/pas adaptées à l’analyse : les requêtes lourdes peuvent
bloquer le système transactionnel
 Volatiles: pas d’historisation systématique
4
Problématique
 Comment répondre aux demandes des décideurs?
 En donnant un accès rapide et simple à l’information
stratégique
 En donnant du sens aux données

Mettre en place un système d’information dédié aux

applications décisionnelles:
un data warehouse

5
Le processus de prise de décision

Champs d’application des

systèmes décisionnels

Définir le Rassembler Analyser les Établir des Décider

problème les données données solutions

Temps de prise d’une décision

6
Le processus de prise de décision

Prise de
décision

Bases de Data Base multi - Prédiction /

production warehouse dimensionnelle simulation

7
Domaines d’utilisation des DW
 Banque
 Risques d’un prêt, prime plus précise
 Santé
 Épidémiologie
 Risque alimentaire
 Commerce
 Ciblage de clientèle
 Déterminer des promotions
 Logistique
 Adéquation demande/production
 Assurance
 Risque lié à un contrat d’assurance (voiture)
 …
8
Quelques métiers du décisionnel
 Strategic Performance Management
 Déterminer et contrôler les indicateurs clé de la performance de
l’entreprise
 Finance Intelligence
 Planifier, analyser et diffuser l’information financière. Mesurer et
gérer les risques
 Human Capital Management (gestion de la relation avec les employés)
 Aligner les stratégies RH, les processus et les technologies.
 Customer Relationship Management (gestion de la relation client)
 Améliorer la connaissance client, identifier et prévoir la
rentabilité client, accroitre l’efficacité du marketing client
 Supplier Relationship Management (gestion de la relation fournisseur)
 Classifier et évaluer l’ensemble des fournisseurs. Planifier et
9
piloter la stratégie Achat.
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Le marché du décisionnel
 Démonstration
10
Définition d’un DW
 William. H. 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 »

 Principe: mettre en place une base de données

utilisée à des fins d’analyse

11
Les 4 caractéristiques des data warehouse

1. Données orientées sujet:

 Regroupe les informations des différents métiers
 Ne tiens pas compte de l’organisation fonctionnelle
des données

Ass. Vie Ass. Auto Ass. Santé

Client
Police

12
Les 4 caractéristiques des data warehouse

2. Données intégrées:
 Normalisation des données
 Définition d’un référentiel unique
h,f

1,0 h,f

homme, femme

DRM
EUR
LIR

USD 13
Les 4 caractéristiques des data warehouse

3. Données non volatiles

 Traçabilité des informations et des décisions prises
 Copie des données de production

Bases de production Entrepôts de données

Ajout
Suppression

Accès
Modification Chargement

14
Les 4 caractéristiques des data warehouse

4. Données datées
 Les données persistent dans le temps
 Mise en place d’un référentiel temps
Image de la base en Mai 2005 Image de la base en Juillet 2006
Répertoire Répertoire
Base de Nom Ville Nom Ville
production
Dupont Paris Dupont Marseille
Durand Lyon Durand Lyon

Calendrier Répertoire
Entrepôt Code Année Mois
Code Année Mois
de
1 2005 Mai 1 Dupont Paris
données
2 2006 Juillet 1 Durand Lyon
15
2 Dupont Marseille
 SGBD et DW
OLTP: On-Line Service Service Service
Transactional commercial Financier livraison
Processing BD prod BD prod BD prod
(traitement Clientèle
transactionnel
en ligne)
H
I
Data Warehouse S
OLAP: On-Line T
Analytical O
Processing R
Clientèle I
(traitement Q
analytique en U
16
ligne) E
OLTP VS DW
OLTP
Orienté transaction
Orienté application
Données courantes
Données détaillées
Données évolutives
Utilisateurs nombreux,
administrateurs/opérationnels
Temps d’exécution: court
DW
Orienté analyse
Orienté sujet
Données historisées
Données agrégées
Données statiques
Utilisateurs peu nombreux,
manager
Temps d’exécution: long

17
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Le marché du décisionnel
 Démonstration
18
Datamart
 Sous-ensemble d’un entrepôt de données
 Destiné à répondre aux besoins d’un secteur ou
d’une fonction particulière de l’entreprise
 Point de vue spécifique selon des critères métiers

Datamarts du
service Marketing

Datamart du
DW de l’entreprise service Ressources
Humaines 19
Intérêt des datamart
 Nouvel environnement structuré et formaté en
fonction des besoins d’un métier ou d’un usage
particulier
 Moins de données que DW
 Plus facile à comprendre, à manipuler
 Amélioration des temps de réponse
 Utilisateurs plus ciblés: DM plus facile à définir

20
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Le marché du décisionnel
 Démonstration
21
 Architecture générale
Zone de
Zone de préparation Zone de stockage présentation

E
X
C
T H
R A
Transformations: Data Requêtes
A R
Nettoyage warehouse Rapports
C G
T Standardisation Visualisation
E
I … Data Mining
M
O …
E
N
N
Sources de Datamart
T
données

22
Les flux de données
 Flux entrant
 Extraction: multi-source, hétérogène
 Transformation: filtrer, trier, homogénéiser, nettoyer
 Chargement: insertion des données dans l’entrepôt
 Flux sortant:
 Mise à disposition des données pour les utilisateurs
finaux

23
Les différentes zones de l’architecture
 Zone de préparation (Staging area)
 Zone temporaire de stockage des données extraites
 Réalisation des transformations avant l’insertion dans le DW:
 Nettoyage

 Normalisation…

 Données souvent détruites après chargement dans le DW

 Zone de stockage (DW, DM)
 On y transfère les données nettoyées
 Stockage permanent des données
 Zone de présentation
 Donne accès aux données contenues dans le DW
 Peut contenir des outils d’analyse programmés:
 Rapports

 Requêtes…
24
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Le marché du décisionnel
 Démonstration
25
Modélisation Entité/Association
 Avantages:
 Normalisation:
 Éliminer les redondances

 Préserver la cohérence des données

 Optimisation des transactions

 Réduction de l’espace de stockage
 Inconvénients pour un utilisateur final:
 Schéma très/trop complet:
 Contient des tables/champs inutiles pour l’analyse

 Pas d’interface graphique capable de rendre

utilisable le modèle E/A
26
 Inadapté pour l’analyse
Exemple
Mode
Transporteur
d’expédition

Produit
Contrat Commande
client
Type de Groupe de
contrat Client produits
Magasin

Famille de
Employé Région de produits
Stock ventes

Fonction Division
Fournisseurs 27
de ventes
Modélisation des DW
 Nouvelle méthode de conception autour des
concepts métiers
 Ne pas normaliser au maximum
 Introduction de nouveaux types de table:
 Table de faits
 Table de dimensions
 Introduction de nouveaux modèles:
 Modèle en étoile
 Modèle en flocon
28
Table de faits
 Table principale du modèle dimensionnel
 Contient les données observables (les faits) sur le sujet
étudié selon divers axes d’analyse (les dimensions)

Table de faits des ventes

Clés étrangères Clé date (CE)
vers les Clé produit (CE)
dimensions Clé magasin (CE)
Quantité vendue
Faits Coût
Montant des ventes
29
Table de faits (suite)
 Fait:
 Ce que l’on souhaite mesurer
 Quantités vendues, montant des ventes…
 Contient les clés étrangères des axes d’analyse
(dimension)
 Date, produit, magasin
 Trois types de faits:
 Additif
 Semi additif
 Non additif
30
Typologie des faits
 Additif: additionnable suivant toutes les dimensions
 Quantités vendues, chiffre d’affaire
 Peut être le résultat d’un calcul:
 Bénéfice = montant vente - coût
 Semi additif: additionnable suivant certaines
dimensions
 Solde d’un compte bancaire:
 Pas de sens d’additionner sur les dates car cela
représente des instantanés d’un niveau
Σ sur les comptes: on connaît ce que nous possédons

en banque
 Non additif: fait non additionnable quelque soit la
dimension
 Prix unitaire: l’addition sur n’importe quelle dimension donne
un nombre dépourvu de sens 31
Granularité de la table de faits
 Répondre à la question :
 Que représente un enregistrement de la table de
faits?
 La granularité définit le niveau de détails de la
table de faits:
 Exemple: une ligne de commande par produit, par
client et par jour

- Précision des analyses

+ Finesse
Taille de l’entrepôt

32
Table de dimension
 Axe d’analyse selon lequel vont être étudiées les données
observables (faits)
 Contient le détail sur les faits

Dimension produit
Clé de substitution Clé produit (CP)
Code produit
Description du produit
Attributs de la Famille du produits
dimension Marque
Emballage
Poids 33
Table de dimension (suite)
 Dimension = axe d’analyse
 Client, produit, période de temps…
 Contient souvent un grand nombre de colonnes
 L’ensemble des informations descriptives des faits
 Contient en général beaucoup moins
d’enregistrements qu’une table de faits

34
Notion de dimension
C’est une catégorie linguistique selon laquelle les
données sont organisées:
 Nom d’un attribut
 Valeur d’un attribut.

35
Représentation de dimension

36
La dimension Temps
 Commune à l’ensemble du Dimension Temps
DW Clé temps (CP)
 Reliée à toute table de Jour
faits Mois
Trimestre
Semestre
Année
Num_jour_dans_année
Num_semaine_ds_année

37
Granularité d’une dimension
 Une dimension contient des membres organisés
en hiérarchie :
 Chacun des membres appartient à un niveau
hiérarchique (ou niveau de granularité) particulier
 Granularité d’une dimension : nombre de niveaux
hiérarchiques

38
Évolution des dimensions
 Dimensions à évolution lente
 Dimensions à évolution rapide

39
Évolution des dimensions
 Dimensions à évolution lente
 Un client peut se marier, avoir des enfants…
 Un produit peut changer de noms ou de
formulation:
 « WANA » en « INWI »

 « MACRO » en « ATACADAO »

 Gestion de la situation, 3 solutions:

 Écrasement de l’ancienne valeur

 Versionnement

 Valeur d’origine / valeur courante

40
Dimensions à évolution lente (1/3)
 Écrasement de l’ancienne valeur :
 Correction des informations erronées

 Avantage:
 Facile à mettre en œuvre

 Inconvénients:
 Perte de la trace des valeurs antérieures des attributs
 Perte de la cause de l’évolution dans les faits mesurés

Clé produit Description du produit Groupe de produits

12345 FREE-FIRE Logiciel
Jeux en ligne
41
Dimensions à évolution lente (2/3)
 Ajout d’un nouvel enregistrement:
 Utilisation d’une clé de substitution

 Avantages:
 Permet de suivre l’évolution des attributs
 Permet de segmenter la table de faits en fonction de
l’historique
 Inconvénient:
 Accroit le volume de la table

Clé produit Description du produit Groupe de produits

12345 FREE-FIRE Logiciel
25963 FREE-FIRE Jeux en ligne
42
Dimensions à évolution lente (3/3)
 Ajout d’un nouvel attribut:
 Valeur origine/valeur courante
 Avantages:
 Avoir deux visions simultanées des données :
 Voir les données récentes avec l’ancien attribut
 Voir les données anciennes avec le nouvel attribut
 Voir les données comme si le changement n’avait pas eu lieu
 Inconvénient:
 Inadapté pour suivre plusieurs valeurs d’attributs intermédiaires

Clé produit Description du Groupe de Nouveau groupe

produit produits de produits
12345 FREE-FIRE Logiciel Jeux en ligne 43
Évolution des dimensions
 Dimensions à évolution lente
 Dimensions à évolution rapide
 Subit des changements très fréquents (tous les
mois) dont on veut préserver l’historique
 Solution: isoler les attributs qui changent
rapidement

44
Dimensions à évolution rapide
 Changements fréquents des attributs dont on veut garder
l’historique
 Clients pour une compagnie d’assurance
 Isoler les attributs qui évoluent vite

45
Dimensions à évolution rapide (suite)
Dim client

Faits Clé_client
Dim client
Nom Faits
Clé_client Clé_client
… Prénom Clé_client
Nom
Adresse Clé_démog
Prénom
Date_naissance
Adresse
…
Date_nais
… Dim_démographique
Revenus Clé_démog
Niveau_étude Revenus
Nb_enfants Niveau_étude
Statut_marital Nb_enfants
Profil_financier Statut_marital
Profil_achat Profil_financier 46

Profil_achat
 Les types de modèles

Modèle en étoile Modèle en flocon

NB: architecture centralisée et fédérée/ marche de données 47
Modèle en étoile
 Une table de fait centrale et des dimensions
 Les dimensions n’ont pas de liaison entre elles
 Avantages:
 Facilité de navigation
 Nombre de jointures limité
 Inconvénients:
 Redondance dans les dimensions
 Toutes les dimensions ne concernent pas les
mesures
48
Modèle en étoile
Dimension Temps
ID temps
année
mois
jour Dimension produit
… ID produit
Dimension Magasin
ID magasin nom
description code
Table de faits Achat prix
ville
ID client poids
surface
ID temps groupe
…
ID magasin famille
ID région …
ID produit
Quantité achetée
Dimension Region Dimension Client
Montant des achats
ID région ID client
pays nom
description prénom
district vente adresse
…. … 49
Modèle en flocon
 Raffinement du schéma étoile avec des tables normalisées
par dimensions.
 Une table de fait et des dimensions décomposées en sous
hiérarchies, On a un seul niveau hiérarchique dans une
table de dimension
 La table de dimension de niveau hiérarchique le plus bas
est reliée à la table de fait. On dit qu’elle a la granularité la
plus fine
 Avantages:
 Normalisation des dimensions
 Économie d’espace disque
 Inconvénients:
 Modèle plus complexe (jointure) 50

 Requêtes moins performantes

Modèle en flocon Dimension produit
ID produit
Dimension Temps ID groupe
ID temps nom
annee code
mois prix
Dimension Magasin jour poids Dimension groupe
ID magasin … … ID groupe
description ID famille
ville Table de faits Achat nom
surface ID client …
… ID temps
ID magasin
Dimension Region ID région
ID région Dimension Famille
ID produit
ID division vente ID famille
Quantité achetée
pays nom
Montant des achats
description …
….
Dimension Client
Dimension
ID client
Division vente
nom
ID division vente
prénom
description 51
adresse
….
…
Méthodologie: 9 étapes de Kimball
1. Choisir le sujet
2. Choisir la granularité des faits (Niveau de détails des
dimensions)
3. Identifier et adapter les dimensions (Typiquement: le
temps, le client, le produit, le magasin...)
4. Choisir les faits (quantités numériques additives)
5. Stocker les pré-calculs
6. Établir les tables de dimensions
7. Choisir la durée de la base
8. Suivre les dimensions lentement évolutives
9. Décider des requêtes prioritaires, des modes de
52
requêtes
Exemple: un DW dans les télécoms

Sujets :
 Suivi du marché: lignes installées/ désinstallées,
services et options choisis, répartition
géographique, répartition entre public et différents
secteurs d'organisations
 Comportement de la clientèle
 Comportement du réseau
Historique
 5 ans pour le suivi du marché
 1 an pour le comportement de la clientèle
 1 mois pour le comportement du réseau
53
Exemple: un DW dans les télécoms

Sources
 Fichiers clients élaborés par les agences
 Fichiers de facturation
Requêtes
 Comportement clientèle
 Nombre moyen d'heures par client, par mois et
par région
 Durée moyenne d'une communication urbaine par
ville
 Durée moyenne d'une communication
internationale
54
Exemple d’application

Une entreprise de fabrication de vaisselle jetable souhaite

mettre en place un système d’information décisionnel sous la
forme d’un data mart (un mini entrepôt de données) pour
observer son activité de ventes au niveaux des différents
lieux de distributions de ses articles et cela dans plusieurs
villes. Ces lieux de distributions sont renseignés par leur
enseigne, leur type (en fonction de leur
surface), leur adresse (code postal et ville), leur
département, leur région. Les ventes sont
renseignées selon une période qui se décline en mois, en
trimestre et année.
Les ventes sont observées par le nombre d’articles selon le
type, et le chiffre d’affaire. 55
 Exemple d’application
- Quel est le fait à observer ?
- Quels sont les axes d’analyse, et les mesures ?
- Construire le modèle en étoile de ce data mart.

56
Exemple d’application

57
Exemple d’application

Il s’agit de modéliser Le DW des ventes d’une entreprise

commerciale. Cette entreprise vend des produits regroupés
par familles de produits.

Une vente correspond à un produit et un seul;

La vente est effectuée par l’un des vendeurs du service de

vente spécialisé dans le produit.

Le DW doit pouvoir fournir le chiffre d’affaires des ventes

d’un produit, par date, client, et vendeur, ainsi que toutes les
sommations possibles de chiffre d’affaires.
58
Exemple d’application

Les objets Du DW sont les suivants:

- produit, caractérisé par : code_produit, code_famille,
etc…
- client, caractérisé par : code_client, nom, CSP (catégorie
socio-professionnelle), etc …
- vente, caractérisée par : code_date, code_produit,
code_client, code_vendeur, Chiffre d’affaires
- vendeur, caractérisé par : code_vendeur, nom,
code_service, etc…
- date, caractérisée par : code_dat, semaine, mois, année,
etc…

59
Exemple d’application

1. Tracer le schéma en étoile dimensionnel du DW, en

précisant pour chaque table sa nature dimensionnelle
(table de faits ou table de dimension), ses clés, ainsi que
la nature des champs.

2. Tracer un autre schema en flocon dimensionnel du DW ,

en respectant les memes consignes.

60
61
Exemple d’application : DW d’EST

L’EST cherche à étudier les facteurs influant sur la réussite de

ses étudiants aux examens. Pour cela elle décide de construire
un Datawarehouse.
Elle souhaite pouvoir répondre aux questions suivantes:
- Quel est le nombre de réussites aux examens par cours,
pour l’année 2018?
- Quel est le nombre de réussites aux examens d’un cours
obligatoire, pour l’année 2018?
- Quel est le nombre de réussites aux examens par sexe
(féminin, masculin), pour l’année 2018?
- Combien d’étudiants ayant un âge de 19 ans ont réussi
leurs examens de probabilités et statistiques?
- Quel est le nombre de réussites aux examens pendant le
dernier semestre de 2017? 62
Exemple d’application : DW d’EST

Pour cela elle dispose des données suivantes:

Pour chaque examen passé, on connaît l’âge et le sexe de
l’étudiant, le nom du cours (les cours peuvent être
regroupés en cours obligatoire et cours à option), la
date de l’examen, la note obtenue et si l’examen est réussi
ou non.
1. Proposez un modèle en étoile pour cette application.
2. Recherchez tout d’abord les différentes
dimensions et proposez une hiérarchie pour ces
dimensions.

63
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Le marché du décisionnel
 Démonstration
64
Alimentation/ mise à jour de l’entrepôt
 Entrepôt mis à jour régulièrement
 Besoin d’un outil permettant d’automatiser les chargements
dans l’entrepôt

Utilisation d’outils ETL (Extract, Transform, Load)

65
Définition d’un ETL
 Offre un environnement de développement
 Offre des outils de gestion des opérations et de
maintenance
 Permet de découvrir, analyser et extraire les données
à partir de sources hétérogènes
 Permet de nettoyer et standardiser les données
 Permet de charger les données dans un entrepôt

66
Extraction
 Extraire des données des systèmes de production
 Dialoguer avec différentes sources:
 Base de données,
 Fichiers,
 Bases propriétaires

 Utilise divers connecteurs :

 ODBC,
 SQL natif,
 Fichiers plats

67
Transformation
 Rendre cohérentes les données des différentes
sources
 Transformer, nettoyer, trier, unifier les données
 Exemple: unifier le format des dates
(MM/JJ/AA JJ/MM/AA)
 Etape très importante, garantit la cohérence et la
fiabilité des données

68
Chargement
 Insérer ou modifier les données dans l’entrepôt
 Utilisation de connecteurs:
 ODBC,
 SQL natif,
 Fichiers plats

69
Aperçu d’un ETL

70
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Accès à l’information
 Démonstration
71
OLTP VS OLAP
Produits Pays
oranges
Produit poires
Espagne
PK id_produit
pommes Allemagne
Libellé
Famille
Achat France
PK id_achat
FK id_client
id_produit Vente de
client janvier avril pommes en
Quantité
PK id_client Allemagne
février
Temps en avril
Nom
adresse
72
ROLAP
 Relational OLAP
 Données stockées dans une base de données
relationnelles
 Un moteur OLAP permet de simuler le
comportement d’un SGBD multidimensionnel
 Plus facile et moins cher à mettre en place
 Moins performant lors des phases de calcul
 Exemples de moteurs ROLAP:
 Mondrian est un serveur Olap écrit en langage JavaIL utilise le
langage d'interrogation MDX. Mondrian, précurseur du décisionnel
Open source, est désormais intégré au projet Pentaho 73
MOLAP
 Multi dimensional OLAP:
 Utiliser un système multidimensionnel « pur » qui
gère les structures multidimensionnelles natives
(les cubes)
 Accès direct aux données dans le cube
 Plus difficile à mettre en place
 Formats souvent propriétaires
 Conçu exclusivement pour l’analyse
multidimensionnelle
 Exemples de moteurs MOLAP:
 Microsoft Analysis Services
74

 Hyperion
HOLAP
 Hybride OLAP:
 tables de faits et tables de dimensions stockées
dans SGBD relationnel (données de base)
 données agrégées stockées dans des cubes
 Solution hybride entre MOLAP et ROLAP
 Bon compromis au niveau coût et performance

75
Le cube
 Modélisation multidimensionnelle des données
facilitant l’analyse d’une quantité selon différentes
dimensions:
 Temps
 Localisation géographique
 …
 Les calculs sont réalisés lors du chargement ou
de la mise à jour du cube

76
Manipulation des données
multidimensionnelles
 Opération agissant sur la structure
 Rotation (rotate): présenter une autre face du cube

05 06 07 05 06 07
Œuf 221 263 139 Idf 101 120 52
Viande 275 257 116 Ain 395 400 203

77
Manipulation des données
multidimensionnelles
 Opération agissant sur la structure
 Tranchage (slicing): consiste à ne travailler que sur une
tranche du cube. Une des dimensions est alors réduite à une
seule valeur
05 06 07 06
Œuf Idf 220 265 284 Œuf Idf 265
Ain 225 245 240 Ain 245
Viande Idf 163 152 145 Viande Idf 152
Ain 187 174 184 Ain 174

78
Manipulation des données
multidimensionnelles
 Opération agissant sur la structure
 Extraction d’un bloc de données (dicing): ne travailler que
sous un sous-cube
05 06 07
Œuf Idf 220 265 284 05 06 07
Ain 225 245 240 Œuf Idf 220 265 284
Viande Idf 163 152 145 Ain 225 245 240
Ain 187 174 184

79
Manipulation des données
multidimensionnelles
 Opération agissant sur la granularité
 Forage vers le haut (roll-up): « dézoomer »
 Obtenir un niveau de granularité supérieur
 Utilisation de fonctions d’agrégation
 Forage vers le bas (drill-down): « zoomer »
 Obtenir un niveau de granularité inférieur
 Données plus détaillées

80
 Drill-up, drill-down
Roll up
05 06 07
Dimension
Roll up Alim. 496 520 255 Temps

05-07 05 06 07 1S05 2S05 1S06 2S06 1S07

Fruits 623 Fruits 221 263 139 Fruits 100 121 111 152 139
Viande 648 Viande 275 257 116 Viande 134 141 120 137 116

05 06 07
Drill down
Pomme 20 19 22
… … … …
Boeuf 40 43 48 Drill down
Dimension
Produit 81
MDX (Multidimensional Expressions)
 Langage permettant de définir, d'utiliser et de récupérer
des données à partir d'objets multidimensionnels
 Permet d’effectuer les opérations décrites précédemment
 Equivalent de SQL pour le monde OLAP
 Origine: Microsoft

82
MDX, exemple
 Fournir les effectifs d’une société pendant les années 2004
et 2005 croisés par le type de paiement

SELECT {([Time].[2004]), ([Time].[2005])} ON COLUMNS,

{[Pay].[Pay Type].Members} ON ROWS
Dimensions,
FROM RH Cube
axes d’analyse
WHERE ([Measures].[Count])

2004 2005
Heure 3396 4015
Jour 3678 2056 83
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Le marché du décisionnel
 Démonstration
84
Le marché du décisionnel

85
Quelques solutions commerciales

86
Quelques solutions open source
ETL Entrepôt OLAP Reporting Data Mining
de données
Octopus MySql Mondrian Birt Weka
Kettle Postgresql Palo Open Report R-Project
CloverETL Greenplum/Biz Jasper Report Orange
Talend gres JFreeReport Xelopes

Intégré
Pentaho (Kettle, Mondrian, JFreeReport, Weka)
SpagoBI

87
Plan
 Introduction
 Les entrepôts de données
 Les datamart
 Architecture
 Modélisation
 Alimentation
 Les bases de données multidimensionnelles
 Accès à l’information
 Démonstration
88
Exemples
 Rapports
 Sales by customer
 Dashboard
 Analyse

89
Etude de cas
 Cas d’une banque
 Une banque distribue une carte de paiement «
carte de crédit » à ses clients. Elle décide de
réaliser un Datawarehouse (DW) afin de faire le
suivi des paiements suivants effectués avec la
carte :
a. Voyages en avion,
b. Locations de voiture,
c. Hôtellerie.
90
 Etude de cas
 Elle veut faire un suivi indépendant de chacun des
paiements a, b ou c, mais aussi avoir la possibilité
d’un suivi global.
 A chaque déplacement en avion, la compagnie
aérienne lui envoie un fichier contenant les éléments
suivants:
 identification de la carte de paiement, coordonnées
du client et de la compagnie aérienne;
 ville de départ, ville d’arrivée, n° du vol, date du vol,
n° du billet, classe du siège, distance parcourue,
91
 Etude de cas
 date d’achat et prix payé.
 Les loueurs de véhicule transmettent après chaque
location: identification de la carte de paiement,
coordonnées du client et de la société de location de
véhicules, catégorie du véhicule, date de début de location,
date de fin de location, nombre de jours, distance
parcourue, date de réservation et prix payé.
 L’hôtel transmet à chaque séjour: identification de la carte
de paiement, coordonnées du client et de l’hôtel, catégorie
de chambre, date de début de séjour, date de fin de séjour,
nombre de nuitées, date de réservation, prix de
l’hébergement et prix de la restauration.
92
Etude de cas
1. Un premier DW ne concerne que les
déplacements en avion.
 Etablir le modèle dimensionnel. Faire clairement
apparaître les dimensions et les indicateurs. Ce
DW doit permettre de répondre aux questions
suivantes : quel est le chiffre d’affaires (CA) par
client, par date de voyage (et par mois, trimestre
et année), par compagnie aérienne, par ville de
destination?

93
Etude de cas
2. De même, établir deux autres modèles
dimensionnels, l’un pour les locations de
voiture, l’autre pour l’hôtellerie.
 Dans le cas de la location de voiture, on souhaite
éditer le CA, le nombre de jours de location, et le
kilométrage pour chaque: client, date de
réservation, ville, loueur, et catégorie de véhicule.
Dans le cas de l’hôtellerie, on veut des tableaux de
bord par client, hôtel, ville, date de début de
séjour, catégorie de chambre, faisant apparaître le
nombre de nuitées, le prix total payé. 94
Etude de cas
3. On veut maintenant regrouper ces trois DW en un
seul, afin de répondre aux questions supplémentaires
suivantes :
Quel est le CA total induit par un déplacement en avion ?
Quelle est la durée du séjour ? Quel est le CA en location de
voiture ? En hôtellerie ? On désire ici pouvoir éditer les détails
de CA par période de temps et par client, ville de destination,
ville de location (si différente), ville d’hébergement (si
différente), compagnie aérienne, loueur et hôtelier, et faire
tous les regroupements utiles.
Figurer le modèle dimensionnel d’un tel DW, en faisant
clairement apparaître les dimensions et les indicateurs.
95
Modélisation des données d’un Data
warehouse
3 concepts fondamentaux:
 Les faits mesurent l ’activité. Les faits sont
toujours numériques. Les faits les plus importants
et les plus utiles sont valorisés de façon continue
et additifs.
 Les dimensions sont les axes d ’analyse. Elles
peuvent être organisées en hiérarchies telles que
la géographie, le temps…
 Les attributs des dimensions qualifient celles-ci.
Typiquement, les attributs sont textuels et discrets
(par opposition aux faits). 96
Modélisation logique des données d’un DW
L’approche MAP (Akoka-Prat)
Une dimension est une donnée élémentaire
permettant d’identifier un objet (ex : code d ’un produit).
C’est l ’axe d ’analyse
Une variable permet de gérer les données
multidimensionnelles. Elle représente une quantité
mesurable, un fait observé. Elle peut être
monodimensionnelle ou multidimensionnelle (ex : des
unités consommées peuvent être dimensionnées par un
consommateur, un produit...)
Une relation caractérise un lien existant entre les
dimensions, deux ou plus (ex : lien entre le code d ’un97

média et le type du média correspondant)

 Modélisation logique des données d’un DW
L’approche MAP (Akoka-Prat)
LA DEMARCHE
 effectuer la modélisation conceptuelle à l ’aide du modèle
entité-association
 simplifier le schéma entité-association ainsi obtenu en :
1. éliminant les associations d’ordre supérieur à 3
2. éliminant les associations réflexives
 traduire le schéma ainsi simplifié en schéma multidimensionnel
à l’aide des règles de transformation suivantes :
1. l’identifiant de chaque entité E-A devient une dimension dans le schéma
logique multidimensionnel
2. les propriétés portées par une entité (autres que son identifiant) deviennent
des variables monodimensionnelles liées à la dimension de cette entité
98
 Modélisation logique des données d’un DW
L’approche MAP (Akoka-Prat)
LA DEMARCHE
 les propriétés portées par les associations du schéma conceptuel
deviennent des variables multidimensionnelles dont les dimensions
sont les identifiants des entités liées à l’association
 (un lien d’héritage entre deux entités est traduit par une relation
dans le schéma logique multidimensionnel)
 une association dont une des cardinalités maximales au moins est
égale à 1 est traduite par une relation dans le modèle logique
multidimensionnel
 toute autre association est traduite au moyen d’une variable
multidimensionnelle liée à l’identifiant de chacune des entités
impliqués dans l ’association, sauf si l ’association est porteuse d ’au
moins une propriété dont la valeur est toujours définie.
99
 Modélisation logique des données d’un DW -
Le modèle en étoile
Le modèle en étoile se compose de deux type de table :
 les tables de dimensions qui représentent les axes d ’analyse.
Chaque table de dimension possède un ensemble d’attributs
permettant de décrire les aspects importants de cette
dimension. Chaque table est identifiée par une clé
 la table de faits concerne l’ensemble des mesures de l’activité.
Les enregistrements de cette table sont identifiés par une clé
composée de la concaténation des clés des tables de
dimension

100
Modélisation logique des données d’un
DW - Le modèle en étoile
Il s ’agit d ’un modèle dénormalisé. Les tables de dimension
sont plates. Il existe une grande redondance des données

101
 Modélisation logique des données d’un DW -
Le modèle en étoile
Règles de passage ER vers un modèle en étoile
 Règle 1 : Toute association binaire M-N ou ternaire ou plus
porteuse de propriétés devient une table de faits identifiée par
les clés des entités participantes.
 Règle 2 : Toute entité participant à une association de la règle
1 devient une table de dimensions reliée à la table de faits.
 Règle 3 : Toute entité E1 reliée à une entité E2 de la règle 2
par une relation 1:N est transcrite dans la table de dimension
de E2.
 Règle 4 : Toute entité E1 reliée à une entité E2 de la règle 2
par un chemin de relations 1:N est transcrite dans la table de
dimensions de E2.
102
Modélisation logique des données d’un DW -
Le modèle en flocon
Ce modèle est dérivé de celui en étoile. Toutefois, les tables de
dimensions sont normalisées et les redondances éliminées
exemple : Cas média-planning (partiel)

103
 Modélisation logique des données d’un
DW - Le modèle en flocon
Règles de passage ER vers un modèle en Flocon
 Règle 1 : Toute association binaire M-N ou ternaire ou plus
porteuse de propriétés devient une table de faits identifiée par
les clés des entités participantes.
 Règle 2 : Toute entité participant à une association de la règle
1 devient une table de dimensions reliée à la table de faits.
 Règle 3 : Toute entité E1 reliée à une entité E2 de la règle 2
par une relation 1:N devient une sous-table de dimensions
reliée à la table issue de la règle 2.
 Règle 4 : Toute entité E1 reliée à une entité E2 traduite en une
sous-table de dimension en devient une sous-table de
dimensions.
104
 Modélisation logique des données d’un DW –
M. en étoile vs M. en flocon
Le modèle en flocon offre une vue plus claire de la structure de
l’information permettant notamment de déceler une hiérarchie
 la normalisation de ce modèle permet de plus de diminuer la
redondance, en réduisant la taille des tables de dimension. A
noter que Kimball a évalué le gain de place disque à 1 % de
l’espace disque total
 Kimball préfère le modèle en étoile sur la base de deux
arguments :
1. la dénormalisation permet d ’améliorer les performances du
système lors de l ’exécution des requêtes
2. le modèle est plus facile à apprendre par l ’utilisateur non
informaticien
105
 Modélisation logique des données d’un DW –
M. en étoile vs M. en flocon
Le modèle en flocon offre une vue plus claire de la structure de
l’information permettant notamment de déceler une hiérarchie
 la normalisation de ce modèle permet de plus de diminuer la
redondance, en réduisant la taille des tables de dimension. A
noter que Kimball a évalué le gain de place disque à 1 % de
l’espace disque total
 Kimball préfère le modèle en étoile sur la base de deux
arguments :
1. la dénormalisation permet d ’améliorer les performances du
système lors de l ’exécution des requêtes
2. le modèle est plus facile à apprendre par l ’utilisateur non
informaticien
106
MDX
 La syntaxe de MDX ressemble à celle de SQL
par ses mots clé SELECT, FROM, WHERE, mais
leurs sémantiques sont différentes :
 SQL construit des vues relationnelles
 MDX construits des vues
multidimensionnelles des données

107
MDX
Structure générale d’une requête :
 SQL : SELECT column1, column2, …, columnn
FROM table
 MDX : SELECT axis1 ON COLUMNS, axis2 ON
ROWS FROM cube

Clause FROM spécifie la source de données :

 en SQL : une ou plusieurs tables
 en MDX : un cube
108
MDX
La clause SELECT indique les résultats que l’on souhaite
récupérer par la requête :

en SQL :
une vue des données en 2 dimensions : lignes (rows) et colonnes
(columns)
les lignes ont la même structure définie par les colonnes
en MDX :
nb quelconque de dimensions pour former les résultats de la
requête
terme d’axe pour éviter confusion avec les dimensions du cube
pas de signification particulière pour les rows et les columns,
mais il faut définir chaque axe : axe1 définit l’axe horizontal et axe2
définit l’axe vertical 109
MDX

110
MDX
 Measures : Unit Price, Quantity, Discount,
SalesAmount, Freight
 Dimension : Time
hierarchy : Year > Quarter > Month > with members :
Year: 2010, 2011, 2012, 2013, 2014
Quarter: Q1, Q2, Q3, Q4
Month: January, February, March, …
 Dimension : Customer
•hierarchy : Continent > Country > State > City with members
City: Paris, Lyon, Berlin, Köln, Marseille, Nantes State: Torino
Country: Austria, Belgium, Danmark, France, ... 111

Continent level: Europe, North America, Sud America, Asia

MDX
 Dimension : Product
hierarchy : Category > Subcategory > product with members

Category : Food, Drink …

Food category: Baked_food …

112
MDX
3 catégories d’opérations élémentaires :
 Restructuration : concerne la représentation, permet un changement de
points de vue selon différentes dimensions : opérations liées à la structure,
manipulation et visualisation du cube :
1.Rotate/pivot
2.Switch
3.Split, nest, push, pull
 Granularité : concerne un changement de niveau de détail : opérations
liées au niveau de granularité des données :
1.roll-up,
2.drill-down
 Ensembliste : concerne l’extraction et l’OLTP classique :
1.slice, dice
2.selection, projection et jointure (drill-across) 113
MDX
 Syntaxe générale d’une requête MDX (forme de Backus-
Naur):
SELECT [<specification d’un axe>
[, <spécification d’un axe>...]] FROM [<spécification d’un cube>]
[WHERE [<spécification d’un filtre (slicer)>]]
Parenthèses en MDX :
 { } : Ensemble des éléments servant à la création d’une
dimension du résultat de la requête
 ( ) : Sélection de tuples dans la clause WHERE
 [ ] : Représentation d’espaces, de caractères spéciaux et
d‘interprétation non numérique de chiffres.
114
MDX
SELECT - description des axes du cube résultat
Chaque dimension du résultat :
 est associée à un rôle correspondant à sa représentation
dans le tableau retourné par la requête MDX :
Ex : ON COLUMNS, ON ROWS, ON PAGES, ON SECTIONS,
ON CHAPTERS

 sur un ou plusieurs niveaux de la hiérarchie :

Ex1 : {Paris, Berlin} de la dimension Lieu, niveau Ville
Ex2 : {[1er trimestre], [2nd trimestre].CHILDREN} de la
dimension Temps, niveaux trimestre et mois.
115
 MDX
FROM - Spécification du/des cube/s de départ
 Ensemble de cubes nécessaires à la création du cube
résultat
 Si plusieurs cubes nécessaires, cela implique une jointure
multidimensionnelle : chaque paire de cubes doit alors
posséder au moins une dimension concordante.

WHERE - Restriction sur le/s cube/s de départ

 Restrictions sur le/s cube/s de départ de la clause
FROM.
 Spécification des restrictions par une liste de noeuds de
la hiérarchie d’une dimension nommée « slicer- 116

dimension »
MDX
 En MDX les mesures sont des éléments d’une dimension
spéciale nommée « Measures » (ces mesures peuvent
être utilisées aussi dans les clauses WHERE et FROM).
 Les dimensions des axes dans la clause SELECT
 Si le cube est vu comme une structure à n dimensions, cette clause
spécifie les arêtes du cube a retourner. La structure de base de la
clause SELECT est :
SELECT set ON axis_name,
set ON axis_name,
set ON axis_name
où axis_name peut être COLUMNS ou ROWS

117
MDX
 Les filtres (Slicers) dans la clause WHERE
Les dimensions de filtrage contiennent les seuls membres avec lesquels
le cube est filtré ou « sliced »
Le contenu des axes :
 Un membre (Member) = est un item dans une dimension et
correspond à un élément spécifique de donnée :
[Time].[2012]
[Customers].[All Customers].[Mexico].[Mexico]
[Product].[All Products].[Drink]
 Un tuple = une collection de membres de différentes dimensions :
([Time].[2012], [Product].[All Products].[Drink])
(2012, Drink)
(2012, [Customers].[All Customers].[Mexico].[Mexico])
 Un set = une collection de tuples : 118

{[Time].[ 2012], [Time].[ 2013], [Time].[ 2014]} {2012, 2013, 2014}

MDX
 MDX Functions and Expressions:
Function refers to a specific operation being performed on
some set of data (Sum(), TopCount()). Expression describe
syntax in which the function is placed after the cube
parameter ([2012].children, [Products].DefaultMember).
The .Members Expression
 This expression is used to retrieve a set of enumerated
members from a dimension, hierarchy, or level. For
example:
 dimension.Members
 hierarchy.Members
 level.Members 119
MDX
 The CrossJoin() Function:
 The CrossJoin() function is used to generate the
cross-product of two input sets. If 2 sets exists in 2
independent dimensions, the CrossJoin operator
creates a new set. consisting of all of the
combinations of the members in the two
dimensions as follows: crossjoin (set1, set2)
 The TopCount() and BottomCount() Functions:
 Order (set, string expression [, ASC | DESC |
BASC | BDESC]) …
120