Le Décisionnel :

-entrepôts de données

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
INTRODUCTION
 Trois générations des SGBD ont déjà vu le jour :
 1ère génération des années 70 : Modèles hiérarchiques et
réseau : IDS II, IMS , TOTAL et SOCRATE
 Seconde génération des années 80 : Modèle Relationnel
conduit par les produits : ORACLE, DB2, Informix, SYBASE
(SQL SERVER)
 3ème génération des années 90 : intégration de l’objet aux
systèmes relationnels et l’apparition des systèmes purs objets
tels que O2 ou Objet Store.

 L’enjeu aujourd’hui est l’intégration du décisionnel aux

systèmes transactionnels.
 Qu’est ce le transactionnel et Pourquoi le
décisionnel ???
3
 Le transactionnel (OLTP)
 Ses outils traditionnels de gestion et d’exploitation des
données sont du type transactionnel ou OLTP (On-Line
Transaction Processing) : SGBD

 Le transactionnel est basé sur un mode d’exploitation de

données axé la saisie, le stockage, la mise à jour, la
sécurité et l’intégrité des données.
 Le système transactionnel est généralement une
application avec une BD, stockant les données courantes
d’une organisation (Pb de gestion automatique des
archives dans les systèmes transactionnels)
 Le contexte du décisionnel
 Besoin d’accès rapide et simple à l’information stratégique
pour la prise de décisions alors qu’il y’a multitude de
sources de données
 Besoin de réactivité face à la concurrence
 Qui: les décideurs (non informaticiens)
Comment répondre aux demandes des décideurs?
Proposez les éléments de l’architecture du décisionnel –
Revoir processus de prise de décision

Qui sont mes

meilleurs
clients?
A combien
s’élèvent
mes ventes
journalières?
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

Solution décisionnelle :
Mettre en place un système d’information dédié aux
applications décisionnelles: un data warehouse
/ Les entrepôts de données 6
INFORMATIQUE DECISIONNELLE
 ID ou BI (Business Intelligence) désigne les moyens, les
outils et les méthodes qui permettent de collecter ,
consolider, modéliser et restituer les données en vue d’offrir
une aide à la décision
 Le but du ID / BI est d’apporter une vision globale des
données de l’entreprise afin de l’évaluer
 Population cible : les décideurs (non informaticiens)

Qui sont mes

meilleurs
clients?
A combien
s’élèvent
mes ventes
journalières? 7
Architecture des entrepôts
de données
 Une architecture d’entrepôt de données possède les
caractéristiques suivantes :
 les données sources sont extraites de systèmes, de bases
de données et de fichiers
 les données sources sont nettoyées, transformées et
intégrées avant d’être stockées dans l’entrepôt
 l’entrepôt est en lecture seulement et est défini
spécifiquement pour la prise de décision organisationnelle
 les usagers accèdent à l’entrepôt à partir d’interfaces et
d’applications (clients)
 Architecture d'entrepôt de données
BD
opérationnelle
(OLTP)

Extraction :
épuration, Analyse OLAP,
BD filtrage, fouille de
opérationnelle synthèse, Entrepôt de données données
(OLTP) transformation, (« data wharehouse ») (data mining)
fusion

Autre
source de
données

 Chaîne de traitements
 Extraction, transformation, chargement dans l’entrepôt
 Outils ETL (Extraction, Transformation, Loading)
 Analyses de données (intelligence d’affaire)
 Agrégats multi-dimensionnels (OLAP)
 Fouille de données (data mining)
9
ARCHITECTURE

10
Définition Classique d’un DW
 Bill Inmon (1996):
« Le data Warehouse est une collection de
données orientées sujet, intégrées, non
volatiles et historisées, organisées pour le
support d’un processus d’aide à la décision »
 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 autour des sujets majeurs de
l’entreprise pour disposer de l’ensemble des
informations utiles sur un sujet le plus souvent
transversal : (Clients, produits, ventes, …)
 Ne tiens pas compte de l’organisation fonctionnelle
des données
 Sujet = faits + dimensions
Ass. Vie Ass. Auto Ass. Santé

Client

Mais pas orientées processus : Paie, stocks, …. 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

Exemple : Une banque américaine s’est aperçue qu’un même

client était identifié dans des différentes appliations sous 13
numéros de compte, 8 noms différents et 7 adresses distinctes
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

Base de Dupont Paris Dupont Marseille

production
Durand Lyon Durand Lyon

1 Dupont Paris
Entrepôt
de 1 2005 Mai 1 Durand Lyon
données 2 2006 Juillet
2 Dupont Marseille 15
Domaines d’utilisation des DW
 Banque
Bancaire : suivi des clients
 Santé
 Commerce
 Ciblage de clientèle
 Déterminer des promotions
 Grande distribution : marketing, maintenance
 Télécommunications : pannes, fraudes, mobiles, ...
classification des clients, détection fraudes, fuites de
clients

16
 Trois fonctions essentielles :
 collecte de données de bases existantes et chargement
 gestion des données dans l’entrepôt
 analyse de données pour la prise de décision

17
 Architecture générale : 3 zones
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

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

 Utilise connecteurs :
 ODBC,
 SQL,
 Fichiers plats

19
Transformation
 Rendre cohérentes les données des différentes
sources
 Transformer, nettoyer, trier 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

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

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

22
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

23
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 24
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

25
 Recap : Entrepôts de données
 Sujets touchant une organisation :
 Par exemple, les ventes et les produits
 Données intégrées :
 Proviennent de différentes sources : systèmes
transactionnels, systèmes d’archivage, sources
externes à l’organisation
 Données qui varient dans le temps :
 Données courantes et données historiques
 Données non-volatiles :
 Aucune mise à jour, seulement des ajouts
 Données qui servent à supporter les processus
de décision :
 Serviront à l’analyse
Entrepôts de données
 L’entrepôt de données réfère aux bases de données
développées afin d’analyser un grand volume de
données (très grande base de données (TGBD en anglais VLDB)
 Le contenu est fait des données actuelles et
d’archives
 Les données sont agrégées ou résumées
 Aucune mise à jour n’est effectuée, mais l’ajout de
nouvelles données est possible
 Un système global existe dans les grandes
organisations
Résumé des concepts

Systèmes Entrepôts de données Marchés de données

transactionnels (ST)
Construit pour les Construit pour l'analyse Construit pour l'analyse
transactions (OLTP)
Données détaillées Données détaillées et Données détaillées et
résumées résumées
Intégré selon les Intégré pour l'entreprise Intégré par sujet ou
applications département
Mis à jour continuellement Jamais mis à jour, Jamais mis à jour,
seulement ajout de seulement ajout de
nouvelles données nouvelles données
Données actuelles Données actuelles et Données actuelles et
d’archive d’archive
Source originale des Données importées des Données importées des
données ST ST et/ou d’entrepôts
Structure normalisée Structure dénormalisée* Structure dénormalisée*
 OLAP
« Il s’agit d’une catégorie de logiciels axés sur
l’exploration et l’analyse rapide des données selon
une approche multidimensionnelle à plusieurs
niveaux d’agrégation » (Caron, 1998)

29
 Composantes OLAP
L’architecture OLAP consiste en trois services :


Base de données :
 Doit supporter les données agrégées ou résumées
 Doit posséder une structure multidimensionnelle (SGDB
multidimensionnel ou relationnel)
Serveur OLAP :
 Gère la structure multidimensionnelle dans le SGBD
(Permet d’associer une ou plusieurs valeurs (appelées
« mesures ») à chaque croisement de dimensions
 ex. nombre d’articles vendus, total des ventes
 Gère l’accès aux données de la part des usagers
Module client :
 Permet aux usagers de manipuler et d’explorer les
données
 Affiche les données sous forme de graphiques
statistiques et de tableaux
 MOLAP
(OLAP Multidimensionnel)
 Les données détaillées de base ainsi que les données agrégées
de l’entrepôt sont stockées dans une base de données
multidimensionnelle (souvent appelée cube ou hypercube)
 Le terme « cube » de données est la version allégée de
« hypercube » de données car le nombre de dimensions N
est souvent supérieur à 3
 Une base de données multidimensionnelle utilise une structure
propriétaire au logiciel utilisé ( matrice)
 Le serveur MOLAP extrait les données de l’hypercube et les
présente directement au module client
 MOLAP
(OLAP Multidimensionnel)

Base de données Serveur MOLAP Client OLAP

multidimensionnelle
(hypercube)
 ROLAP (OLAP Relationnel)
 Les données détaillées de base ainsi que les données agrégées
de l’entrepôt sont stockées sous forme de tables dans une BD-R
 La base de données relationnelle doit être structurée selon un
modèle particulier (étoile, flocon, …)
 Le serveur extrait les données par des requêtes SQL et
interprète les données selon une vue multidimensionnelle
avant de les présenter au module client
 ROLAP (OLAP Relationnel)

Serveur ROLAP
Client OLAP
Base de données
relationnelle Vue
(étoile ou flocon) multidimensionnelle
 HOLAP (OLAP Hybride)
 Architecture qui consiste en un croisement des architectures
MOLAP et ROLAP
 Les données détaillées de base de l’entrepôt sont stockées
dans une BDR et les données agrégées sont stockées dans une
BD multidimensionnelle
 Le serveur HOLAP accède deux bases de données et les
présente au module client, selon une vue multidimensionnelle
dans le cas des données de la BD relationnelle
HOLAP (OLAP Hybride)
MOLAP vs ROLAP vs HOLAP

Critère de ROLAP MOLAP HOLAP

comparaison

Stockage des BD relationnelle BD BD relationnelle

données de base multidimensionnelle
(détaillées)

Stockage des BD relationnelle BD BD

agrégations multidimensionnelle multidimensionnelle

Performance des Le moins Le plus performant Performance

requêtes performant moyenne
(habituellement)
SGBD et DW
Service Service Service
OLTP: On-Line commercial Financier livraison
Transactional BD prod BD prod BD prod
Processing
Clientèle

H
I
Data Warehouse S
T
OLAP: On-Line O
Analitical R
Clientèle I
Processing
Q
U
38
E
OLTP VS OLAP
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
OLAP
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

39
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

BD R (Relation et Tables ) : BI
Tables Dimension et Faits 40
Faits et Dimensions
 Fait:
 Ce que l’on souhaite mesurer
 Quantités vendues, montant des ventes…
 Dimension = axe d’analyse
 Dimension Client,
 Dimension produit,
 Dimension période de temps…

41
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)
 Contient les clés étrangères des axes d’analyse
(dimension) : Date, produit, magasin
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
42
Table de dimension
 Axe d’analyse selon lequel vont être étudiées les données
observables (faits)
 Contient le détail sur les faits
 Contient souvent un grand nbre de colonnes et moins
d’enregistrements/ table fait
Dimension produit
Clé de substitution Clé produit (CP)
Code produit
Description du produit
Attributs de la Groupe de produits
dimension Marque
Emballage
Poids 43
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

44
Les types de modèles

Modèle en étoile Modèle en flocon

45
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
46
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
…. … 47
Modèle en flocon
 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.
 Avantages:
 Normalisation des dimensions
 Économie d’espace disque
 Inconvénients:
 Modèle plus complexe (jointure)
 Requêtes moins performantes
48
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 49
adresse
….
…
Exemple
Sachant que qu’on veut avoir les ventes par produit , par
période et par magasin et que le schèma de la BD
relationnelle est :
Produits(IDprod, description, couleur, taille, …)
Magasins(IDmag, nom, ville, dept, pays)
Periodes(IDper, année, trimestre, mois, jour)
 Présenter un schèma décisionnel et préciser latable des
faits et les tables de dimension

50
 Schémas en étoile
 Une table de faits encadrées par N tables de dimensions

Produits
Periodes Table de faits “ventes” IDprod
description
IDper periode couleur
année taille
produit
trimestre fournisseur
mois magasin
jour Magasins
unités_vendues
IDmag
montant_ventes
nom
taxes_ventes ville
département
Conception DW pays
 Schémas en flocons
 Raffinement du schéma étoile avec des tables normalisées
par dimensions

Produits Fournisseurs
IDprod IDfour
Ventes description description
couleur type
taille Adresse
 Avantages IDfour
 Évite les redondances
 Conduit aux constellations (plusieurs tables de faits à dimensions
partagées)

Conception DW
 Démarche Conception du schéma intégré

 Isoler les faits à étudier

 Schéma des tables de faits
 Définir les dimensions
 Axes d'analyse
 Normaliser les dimensions
 Éclater en plusieurs tables liés par contraintes référentielles
 Intégrer l'ensemble
 Plusieurs tables de faits partagent quelques tables de dimension
(constellation d’étoiles)

Conception DW
54
Pb : Dénormalisation

55
56
RECAP

57
 Langage de requêtes
 Comme SQL pour les bases de données relationnels,
il existe des langages de requêtes pour l’utilisation
des OLAP :

 MDX Multidimensional Expression de Microsoft SQL

intégré à SQL Server.

 OLAP DML (Data Manipulation Language) langage

spécialisé pour traitement OLAP intégré à Oracle « «
‘10g’.

58
 Manipulation des données
multidimensionnelles
MDX (Multidimensional Expression)
 Langage d’expression OLAP pour MS SQL Server
 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

59
 Extension de SQL
 ROLLUP:
 SELECT <column list>
 FROM <table…>
 GROUP BY
ROLLUP(column_list);
 Crée des agrégats à
n+1 niveaux, n étant le
nombre de colonne de
groupage
 n, n-1, n-2,…0 colonnes
Implémentation
 CUBE:
 SELECT <column list>
 FROM <table…>
 GROUP BY
CUBE(column_list);
 Crée 2n combinaisons
d'agrégats, n étant le
nombre de colonne de
groupage
Regroupements multidimensionnels (CUBE et
ROLLUP SQL:1999 )
GROUP BY SQL

SQL>
2
SELECT noClient,noArticle,SUM(montant)
FROM Vente
noArticle
3 GROUP BY noClient,noArticle
4 /
10 20 40 50 60
NOCLIENT NOARTICLE SUM(MONTANT)
---------- ---------- ------------
1 10 500 1 500 200 100 200 200
1 20 200
1 40 100
1 50 200 noClient 2 700 300 0 0 400
1 60 200
2 10 700
2 20 300 3 1000 400 100 200 0
2 60 400
3 10 1000
3
3
20
40
400
100
4 300 0 0 0 500
3 50 200
4 10 300
4 60 500

Tableau croisé
61
Clause CUBE SQL:1999
SQL> SELECT noClient,noArticle,SUM(montant)
2 FROM Vente
3 GROUP BY CUBE(noClient,noArticle)
4 /

NOCLIENT NOARTICLE SUM(MONTANT)

---------- ---------- ------------
1 10 500
1 20 200
1 40 100
1 50 200
1 60 200
1 1200
2 10 700
2 20 300
2 60 400
2 1400
3 10 1000
3 20 400
3 40 100
3 50 200
3 1700
4 10 300
4 60 500
4 800
10 2500
20 900
40 200
50 400
60 1100
5100

62
Clause ROLLUP SQL:1999
SQL> SELECT noClient,noArticle,SUM(montant)
2 FROM Vente
3 GROUP BY ROLLUP(noClient,noArticle)
4 /

NOCLIENT NOARTICLE SUM(MONTANT)

---------- ---------- ------------
1 10 500
1 20 200
1 40 100
1 50 200
1 60 200
1 1200
2 10 700
2 20 300
2 60 400
2 1400
3 10 1000
3 20 400
3 40 100
3 50 200
3 1700
4 10 300
4 60 500
4 800
5100

63
Quelques solutions commerciales

64
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)
http://eric.univ-lyon2.fr/~kaouiche/inf9002/mdx.html
SpagoBI
65
Le Décisionnel (BI) avec SQL Server @2003
 SQL SERVER présente 3 plateformes pour réaliser
un projet BI :
 Intégration Services (SSIS): permet d’intégrer des données
provenant des différentes sources des données dans
l’entrepôt de données (ETL) . Successeur de DTS de SQL
SERVER 2000
 Analyses Services (SSAS): assure les données agrégées
grâce à des fonctions d’analyse mutidimensionnelle
 Reporting Services (SSRS) : crée, gère et publie des
rapports résultant des analyses réalisées
BI SQL SERVER

67
 ESPACE DE TRAVAIL (SSIS)
-IS fournit un environnement de travail sous forme de package fonctionne grâce
au principe de « glisser-déposer » et doté d’un espace de travail (central)
divisé en 4 parties sous forme d'onglet et une boite à outils correspondant :
 Le Control Flow ou flux de contrôle : permet de contrôler, d'ordonner les
tâches à réaliser par le package, il assure donc l’enchaînement des tâches .
 Le Data Flow ou flux de données : permet de contrôler, d'ordonner les
flux de données à traiter. C'est à cette étape que la connexion, la sélection,
la transformation et l'insertion des données sont réalisées.
 L'Event Handlers ou gestionnaire d'évènements qui peuvent être
associés aux éléments du package.
 Le Package Explorer ou explorateur de package : décrit d’une façon
arborescence tous les éléments qui composent le package.
 Le Décisionnel (BI) avec SQL Server
2008 (Solution Microsoft)
 SQL SERVER présente 3 plateformes pour
réaliser un projet BI :
 Intégration Services : permet d’intégrer des données
provenant des différentes sources des données dans
l’entrepôt de données (ETL)
 Analyses Services : assure les données agrégées grâce à
des fonctions d’analyse mutidimensionnelle
 Reporting Services : crée, gère et publie des rapports
résultant des analyses réalisées

Services BI

Moteur BD IS AS RS
 MS VISUAL STUDIO
Créer un nouveau projet : Fichier / Nouveau
 FLUX DE DONNEES
Organisée en 3 parties : les composants
source, les composants transformation et
les composants destination.

Divers types de composants source :

les fichiers Excel, les fichiers plats , XML,
etc.

Plusieurs composants de transformations

Diverses destinations tels que des fichiers

plats, excel ou encore SQL Server.
 FLUX DE CONTROLE

 Organisée en 2 parties avec divers contrôles ou tâches sont pré-

existants comme les tâches de flux de données, de nettoyage
d'historique ou encore de sauvegarde de base de données, etc
 ETUDE DE CAS
 Réaliser un package pour importer les données
d’un fichier plat vers une BD moyennant SSIS

73
Le cube
 Modélisation multidimensionnelle des données facilitant l’analyse
d’une quantité selon différentes dimensions:
 Temps , Localisation géographique

Produits Pays
oranges
Espagne
poires
pommes Allemagne

France

Vente de
janvier avril pommes en
Allemagne
février
Temps en avril
74
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

75
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

76
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

77
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

78
 SQL SERVER ANALYSE
SERVICES
-Lancer par MS Visual Studio

79
 SQL SERVER ANALYSE SERVICES
-Création d’un projet :
après le lancement du visual studio, on choisit un projet de type SSAS , la
fenêtre suivante sus-après avec : Des barres à outils, barre de menus, un
espace concepteur, explorateur de solutions

80
 SQL SERVER ANALYSE SERVICES
-On définit une source de données : Choix du mode de définition de la
connexion (basée sur une nouvelle connexion ou une connexion existente)
-Pour une nouvelle connexion on définit : Fournisseur de connexion, connexion
au fournisseur, type de connexion (SQL Server) et connexion à la BD

81
Connexion à la BD AventureWorksDW

82
 SQL SERVER ANALYSE SERVICES
-Définition d’une vue de source de données à partir de la source de données
-Sélection des objets de la source de données

83
SQL SERVER ANALYSE SERVICES
-Définition d’une vue de la source de données

84
 SQL SERVER ANALYSE SERVICES
Visualisation de données sous forme de :
Tables
Tableau croisé dynamique
Graphique
Graphique croisée dynamique
Cube

85
Etude de cas
 Créer un projet de type SSAS en lui donnant le
nom SalesTrends
 Utiliser la BD AventureWorksDW et réaliser un
cube avec les dimensions Produit et time et
comme dimension de votre choix si Pb au niveau
de la Bd exemple créer votre Bd personnelle et
faire le travail
 Utiliser le cube par excel

86
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 87
 Article Article

Client
Client
D D
at at
e e

Article Article Article Article

Client
Client
Client

Client
Hiérarchie de cuboïdes

D D D D
at at at at
e e e e

Article Article
Client
Client

D D
at at
e e
88
Implémentation OLAP

 SGBD relationnel
 OLAP relationnel (ROLAP )

 SGBD spécialisé
 OLAP multidimensionnel (MOLAP)

 SGBD relationnel avec des extensions OLAP

 OLAP hybride (HOLAP)
 Nouveaux opérateurs GROUP BY CUBE,….

89
MOLAP Oracle
 Analytical Workspace (AW)
 tableau multidimensionnel
 OLAP DML
 langage spécialisé pour traitement OLAP
 Stocké dans la BD sous forme LOB
 Passerelle avec SQL par l’intermédiaire d’une
couche relationnelle-objet au dessus du AW

90
Modèle en flocon

91
Aperçu d’un ETL

92
 Architecture type

Introduction DW
 Le data cube et les dimensions

Axe d'analyse: La géographie

(Pays - région - ville)

Variables analysées:
Nb unités, CA, marge...

Axe d'analyse: Les produits

(classe, produit)

Axes d'analyse: dimensions

Axe d'analyse: Le temps Variables analysées: indicateurs
(Année, trimestre, mois, semaine)
Le multidimensionnel
 Exemple CUBE

Animal Lieu Quantite Animal Lieu Quantite

Chien Paris 12 Chat Paris 18
Chat Paris 18 Chat Naples 9
Tortue Rome 4 Chat - 27
Chien Rome 14 Chien Paris 12
Chat Naples 9 Chien Naples 5
Chien Naples 5 Chien Rome 14
Tortue Naples 1 Chien - 31
Tortue Naples 1
 SELECT Animal, Lieu, Tortue Rome 4
SUM(Quantite) as Quantite Tortue - 5
- - 63
FROM Animaux
- Paris 30
GROUP BY Animal, Magasin - Naples 15
WITH CUBE - Rome 18
Implémentation
 Exemple ROLLUP

Animal Lieu Quantite Animal Lieu Quantite

Chien Paris 12 Chat Paris 18
Chat Paris 18 Chat Naples 9
Tortue Rome 4
Chat - 27
Chien Rome 14
Chat Naples 9
Chien Paris 12
Chien Naples 5 Chien Naples 5
Tortue Naples 1 Chien Rome 14
Chien - 31
Tortue Naples 1
 SELECT Animal, Lieu,
Tortue Rome 4
SUM(Quantite) as Quantite Tortue - 5
FROM Animaux - - 63
GROUP BY Animal,Magasin
WITH ROLLUP
Implémentation
 Quelques outils OLAP
 Oracle
 OLAP API = Datacube
 Express = Analyse
 Report = Reporting
 Business Object
 BusinessQuery = Requêtage
 BusinessObject =
Requêtage + Analyse +
Reporting
 WebIntelligence = Datacube
Implémentation
 Cognos
 Impromptu = Reporting
 Powerplay = Datacube
 Query = Requêtage
 Hyperion
 ESS Base = Base MOLAP
 ESS Analysis= Analyse +
Datacube
 GROUP BY GROUPING SETS

 Partitionnement selon plusieurs dimensions

 Exemple
 SELECT #Client, #Produit, SUM(Montant) FROM
Ventes
 GROUP BY GROUPING SETS ((#Client),
(#Produit))
 est équivalent à
 (SELECT #Client, NULL, SUM(Montant) FROM
Ventes GROUP BY #Client) UNION
 (SELECT NULL, #Produit, SUM(Montant) FROM
Ventes GROUP BY #Produit) 98
 GROUP BY ROLLUP
 Réd u ire prog ressivement
 Exemple
 SELECT #Client, #Produit, SUM(Montant) FROM Ventes
 GROUP BY ROLLUP (#Client, #Produit)
 est équivalent à
 (SELECT #Client, #Produit, SUM(Montant) FROM Ventes GROUP BY
#Client,
 #Produit)
 UNION
 (SELECT #Client, NULL, SUM(Montant) FROM Ventes GROUP BY
#Client)
 UNION
 (SELECT NULL, NULL, SUM(Montant) FROM Ventes)

99
 GROUP BY CUBE
 Partitionnement selon tous les sous-ensembles possibles de
Grouping Sets
 SELECT #Client, #Produit, #Fournisseur, SUM(Montant) FROM
Ventes GROUP BY CUBE (#Client, #Produit, #Fournisseur)
 est équivalent à
 SELECT #Client, #Produit, SUM(Montant) FROM Ventes GROUP
BY GROUPING SETS (
 (), -- total des ventes
 (#Client), -- total des ventes par Client
 (#Fournisseur),-- total des ventes par Forunisseur
 (#Produit), -- total des ventes par Produit
 (#Client, #Fournisseur) -- total des ventes par Client et par
Fournisseur
 (#Client, #Produit), -- total des ventes par Client et par Produit
 (#Produit, #Fournisseur), -- total des ventes par Produit et par
Fournisseur
 (#Client, #Produit, #Fournisseur) –
 total des ventes par Client, Produit et Fournisseur )
Le marché du décisionnel

101
 6. Le marché

BI= Business Intelligence

Data PRO Users Survey

Conclusion