Business Intelligence

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Business Intelligence La Chaîne Décisionnelle Data Warehouse Aspects Fondamentaux Conclusion
Formation Business Intelligence
Ou comment intégrer de l’intelligence au métier ?
Dr. Lilia SFAXI
Institut National des Sciences Appliquées et de Technologie (INSAT)
Laboratoire LIP2
Novembre 2015
L. SFAXI Formation Business Intelligence 1 / 91

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Objectifs de la formation
Comprendre les notions de :
• Informatique décisionnelle
• OLAP et Cubes
• ETL, Entrepôt de données, data mining
Prérequis :
• Connaissances en bases de données relationnelles

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
/me
Lilia SFAXI ep. YOUSSEF
• Docteur/Ingénieur en Informatique
• Maître-Assistant à l’Institut National des Sciences Appliquées
et de Technologie (INSAT)
• Chercheuse au laboratoire LIP2

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Programme
Jour 1
Introduction à la chaîne BI, besoins et étapes
Exemple d’une chaîne BI avec les outils Jaspersoft

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Programme
Jour 1
Introduction à la chaîne BI, besoins et étapes
Exemple d’une chaîne BI avec les outils Jaspersoft
Jour 2
Conception du Datawarehouse : Aspects Fondamentaux
Exemple simple de conception de Datawarehouse et de Data
Mining avec Mondrian

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sommaire
Business Intelligence : Besoins et Étapes
Introduction au BI
Risques et Facteurs de Succès
La Chaîne Décisionnelle
Étapes de la Chaîne Décisionnelle
Architectures et Technologies
Structures de Stockage
Phases de la Chaîne Décisionnelle
Les Entrepôts de Données (Datawarehouse)
Systèmes Opérationnels vs. Systèmes Décisionnels
Modélisation Multi-Dimensionnelle
Caractéristiques de la Modélisation Multidimensionnelle
Aspects Fondamentaux de la Modélisation Multidimensionnelle
Modèles d’un Entrepôt de Données
Aspects Fondamentaux de la MMD
Opérations OLAP
Modèles de Stockage
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sommaire
Introduction au BI
Risques et Facteurs de Succès
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Aide à la Décision : Mise en Situation
• Le chiﬀre d’aﬀaires a baissé en octobre. Pour y remédier, des
décisions sont à prendre.
• Pour prendre les bonnes décisions, il faut savoir :
• Pourquoi le CA a-t-il baissé ?
• Comment a-t-il baissé ?
• Dans quelle gamme de produits ?
• Dans quels pays, quelles régions ?
• Dans le portefeuille de clientèle de quels commerciaux ?
• Dans quels segments de distribution ?
• N avait-on pas une baisse semblable en octobre chaque année ?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Déﬁnition de l’Informatique Décisionnelle
Terme générique qui englobe les applications, l’infrastructure, les
outils et les meilleures pratiques permettant l’accès et l’analyse de
l’information aﬁn d’améliorer et d’optimiser les décisions et les
performances.
Source : GARTNER

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Pourquoi Construire un Système Décisionnel ?
• Un des actifs les plus importants des sociétés, c’est leur
capital d’informations qu’elles collectent au jour le jour
• Généralement, la plupart de ces informations sont
inaccessibles, ou réparties dans une multitude de systèmes
• Besoin de :
• Avoir une vision globale homogène et cohérente des
informations manipulées par les diﬀérents départements
• Accéder directement à l’information nécessaire
• Donner un sens unique aux données de gestion (marge, CA...)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Pourquoi Construire un Système Décisionnel ?
• Le Système d’Information Décisionnel (SID) résulte d’un
processus qui consiste à :
• extraire les données à partir des systèmes opérationnels et
d’autres sources externes à l’entreprise
• les transformer en information de pilotage
• les rendre accessibles aux utilisateurs
• La Base Décisionnelle est aujourd’hui reconnue comme un
actif stratégique par beaucoup d’entreprises.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Métriques d’Aide à la Décision
Figure : Les Concepts Clef

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Donnée
• Résultat direct d’une mesure
• Peut être collectée par un outil de mesure, ou peut être
présente dans une base de données
• Ne permet pas de prendre de décision sur une action à lancer

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Information
• Donnée à laquelle un sens et une interprétation ont été donnés
• Permet au responsable de prendre une décision sur une action

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Connaissance
• Résultat d’une réﬂexion sur les informations analysées
• Se base sur les expériences, les idées, valeurs, avis de
personnes consultées

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sagesse
• État d’esprit général de discernement ﬁnal sur le contenu et
de jugement de bon sens
• Permet de lancer des actions d’adaptation de l’organisation,
des personnes, des processus et outils

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Risques d’un Projet Décisionnel
• Orientation technologique du projet, plutôt qu’utilisateur
• Mise en cause de la ﬁabilité et/ou cohérence des informations
• Alimentations trop longues et irrégulières
• Outils et architecture technique inadaptés
• Fraîcheur insuﬃsante des informations
• Pas d’administrateur du système
• Surenchère fonctionnelle concernant les analyses et les outils à
utiliser par rapport aux réels enjeux métiers

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Facteurs Clefs de Succès
Pour la Conduite de Projet
• Adopter une démarche incrémentale avec des objectifs précis
et quantiﬁés à l’avance
• Miser dès le départ sur un socle informatique stable, puis
coordonner des itérations courtes avec des résultats tangibles
Dans la Conception Fonctionnelle
Pour la Mise en œuvre Technique
Dans la Prise en compte des Impacts Organisationnels

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• Préférer des états ﬁgés mais utiles à des analyses libres mais
compliquées
• Raisonner en ﬂux amont-aval et en échanges transverses entre
utilisateurs

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• S’assurer de l’évolutivité de la solution technique
• Privilégier les solutions paramétrables par un administrateur
fonctionnel
• Insérer dans la recette technique des tests de montée en
charge

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• Préparer le changement et l’insérer dans le plan de projet
• Fonder et associer le plus tôt possible le futur administrateur
du système

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sommaire
Étapes de la Chaîne Décisionnelle
Architectures et Technologies
Structures de Stockage
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Les 5 grandes étapes :

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Planiﬁcation
• Pour mettre en place une plate-forme décisionnelle
d’entreprise intégrée, la première étape est donc la
planiﬁcation de ce projet
• Un tel projet nécessite une administration solide
• Exemple : les ressources humaines
• Un responsable peut voir le salaire des personnes de son équipe
• Mais ne peut pas voir celui de son chef
⇒ Nécessité d’une stratégie de sécurité rigoureuse

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ETL
• ETL : Extract, Transform, Load
• Extraction des données à partir d’une ou plusieurs sources de
données : ﬁchiers texte, Excel, base de données...
• Transformation des données agrégées
• Chargement des données dans la banque de données de
destination (datawarehouse)
⇒ La phase d’ETL est incontournable car elle conditionne et
inﬂuence la qualité du projet par la suite

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Stockage
• Plusieurs manières de stocker la donnée dans un
datawarehouse
• Chacune ayant ses avantages et ses inconvénients
• L’administrateur des bases de données décisionnelles pourra
notamment choisir entre plusieurs modèles (en étoile, en
ﬂocon...)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Analyse
• Regroupement de l’ensemble des techniques de statistique,
d’économétrie, de Data Mining, et de recherche opérationnelle
• Demande souvent des compétences statistiques avancées
• Néanmoins certaines solutions embarquent ces fonctionnalités
pré-paramétrées à des cas de figures bien définies, afin d’offrir
leur valeur ajoutée à des personnes fonctionnelles

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Restitution
• La génération de tableau de bord, est la partie émergée de
l’iceberg : l’informatique décisionnelle.
• C’est la partie que voient la plupart des utilisateurs.
• Ce sont généralement de jolies interfaces intuitives permettant
à un utilisateur lambda, en fonction de ses droits, de consulter
des rapports, des tableaux de bord, de les annoter, voire de les
créer lui-même

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Architecture d’un Système Décisionnel
À votre avis, quelle partie de la chaîne est la plus importante et la
plus coûteuse ?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
L’Alimentation !
• Sur le plan des données
• Déﬁnir un langage commun
• Localiser les données utiles dans les systèmes sources
• Harmoniser les nomenclatures
• Sur le plan technique
• Les règles d’alimentation changent sans cesse
• Développements modulaires auto-documentés, traçabilité des
données
• Temps de chargement compatibles avec la fenêtre
d’exploitation

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Structure d’un Système Décisionnel

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Structures de Stockage des Données

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Déﬁnitions
ODS(Operational Data Store)
• Collection de données orientées sujet,
volatiles, organisées pour le support d’un
processus de décision ponctuel, en support à
une activité opérationnelle particulière
• Donne la vision immédiate et intégrée de
l’état d’un ou plusieurs systèmes opérants
Datawarehouse
Data Mart
Data Mining

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Déﬁnitions
Datawarehouse
• Entrepôt de données spéciﬁque au monde
décisionnel, destiné principalement à analyser
les leviers business potentiels
• 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
Data Mart
Data Mining

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Déﬁnitions
Datawarehouse
Data Mart
• Magasin de données orienté sujet, non
volatile, mis à la disposition des utilisateurs
dans un contexte décisionnel décentralisé,
ciblé pour un usage particulier
Data Mining

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Déﬁnitions
Datawarehouse
Data Mart
Data Mining
• Ensemble d’outils, méthodes et technologies
d’analyse mises en œuvre pour déﬁnir des
tendances, pour segmenter l’information ou
pour établir des corrélations entre les données

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Datawarehouse vs. ODS
• Datawarehouse
• Intégration des données hors ligne
• ODS
• Intégration des données en ligne
• Sauvegarde des données récentes
• Utilisé quand les données sont dispersées sur plusieurs supports
de stockage, et on a besoin de les rassembler
• Exemple
• On veut avoir une vue unique sur un patient, qu’on pourra
modiﬁer en ligne
• Les données de ce patient sont disposées dans plusieurs bases
de données (liste des hospitalisations, liste des diagnostics, liste
des achats pharmaceutiques...)
• ODS peut être utilisé pour extraire les données et les aﬃcher

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Datawarehouse vs. Data Mart
• Datawarehouse
• Dépôt des données au niveau entreprise
• Combinaison de plusieurs Data Marts
• Contient toutes les mesures et dimensions nécessaires
• Assure l’intégrité de ces dimensions à travers tous les Data
Marts
• Data Mart
• Ensemble de dimensions et mesures limitées
• Utilisées pour des thèmes métier spéciﬁques
• Construites à partir des données des entrepôts
• Exemple
• Dans une entreprise, il existe un seul entrepôt de données mais
plusieurs magasins de données : Finance, Vente...

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Entrepôts de Données
Objectifs
• Regrouper, organiser des informations provenant de sources
diverses

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Objectifs
diverses
• Les intégrer et les stocker pour donner à l’utilisateur une vue
orientée métier

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Objectifs
diverses
orientée métier
• Retrouver et analyser l’information selon plusieurs critères

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Objectifs
diverses
orientée métier
• Transformer un système d’information qui avait une vocation
de production en un SI décisionnel

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Objectifs
diverses
orientée métier
• Doit contenir des informations cohérentes

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Objectifs
diverses
orientée métier
• Les données doivent pouvoir être séparées et combinées au
moyen de toutes les mesures possibles de l’activité

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Objectifs
diverses
orientée métier
• Les données doivent pouvoir être séparées et combinées au
moyen de toutes les mesures possibles de l’activité
• Le DW ne contient pas uniquement des données, mais aussi
un ensemble d’outils de requêtes, d’analyse et de présentation
de l’information.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Déﬁnition
Le Data Warehouse est une collection de données orientées sujet,
intégrées, non volatiles et historisées, organisées pour la prise de
décision.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Données Orientées Sujet
Les données collectées doivent être orientées métier, donc triées
par thème.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Données Intégrées
Un nettoyage préalable des données est nécessaire dans un souci de
rationalisation et de normalisation.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Données Historisées et Non Volatiles
Non Volatiles : une donnée entrée dans un entrepôt l’est pour de
bon et n’a pas vocation à être supprimée.
Historisées : les données sont datées, et un historique est conservé.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ETL : Extract, Transform, Load
• Outils d’alimentation pour :
• Extraire les données sources
• Transformer les données sources
• Charger ces données dans le DW

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Extraction
• Extraction des données de leur
environnement d’origine (base de données
relationnelles, fichiers plats...)
• Besoin d’outils spécifiques pour accéder aux
bases de production (requêtes sur des BD
hétérogènes)
• Besoin d’une technique appropriée pour
n’extraire que les données nécessaires
• Données créées ou modifiées depuis la dernière
opération d’extraction
• Attention : L’extraction ne doit pas perturber
l’activité de production

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Transformation
• Homogénéisation du vocabulaire, structures,
valeurs
• Suppression et fusion des redondances
• Épuration des données (suppression des
données incohérentes)
• Transformation des données dans un format
cible

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Chargement
• Opérations de calcul et d’agrégation des
données
• Remplacement de certaines bases si aucune solution
d’extraction satisfaisante n’est possible
• Mise en place de procédures de chargement
(nocturne ?) et de restauration (en cas de
problème)
• Envisager la mise en place de systèmes redondants si
la disponibilité du système ne peut être interrompue
• Prise en compte de la notion de granularité
• Conservation des données détaillées
• Possibilité d’agrégation des données pour la synthèse

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Structure de l’Entrepôt
Directe Simple :
On fait des mises à jour de l’entrepôt avec des laps
de temps importants

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Cumul Simple :
On stocke les données de chaque mise à jour, les
mises à jour étant fréquentes (par ex. tous les
jours). On a un espace occupé important, mais on
ne perd pas d’information.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Résumé Déroulant :
À chaque mise à jour, on stocke des données
détaillées et on synthétise les données anciennes en
fonction de leur âge. Plus une donnée est vieille,
moins elle est détaillée.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sommaire
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Systèmes Opérationnels
• OLTP (On-Line Transaction
Processing)
• Dédiés aux métiers de l’entreprise
pour les assister dans leurs tâches de
gestion quotidienne
• Utilisation des ERP pour la gestion
des données
• Utilisateurs : Agents opérationnels,
nombreux et concurrents
• Données :
• Détaillées
• Récentes
• Réparties
• Non homogènes
Systèmes Décisionnels
• OLAP (On-Line Analytical
Processing)
• Dédiés à la gestion de l’entreprise
pour l’aider au pilotage de l’activité
pour une vision transversale de
l’entreprise
• Utilisation des entrepôts de données
• Utilisateurs : Décideurs, peu
nombreux et non concurrents
• Données
• Globalisées
• Historiques
• Centralisées
• Intégrées

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
OLTP vs. OLAP
OLTP : On-Line Transactional Processing
• Système destiné à oﬀrir le moyen à une application d’utiliser de façon
transactionnelle un serveur de base de données.
• Ensemble de logiciels que l’utilisateur peut employer de façon interactive pour
accéder aux données de la manière la plus rapide et simple possible.
• Exemple : Le 15/01/2012 à 13h12, le client X a retiré 500dt du compte Y
OLAP : On-Line Analytical Processing
• Catégorie de technologie logicielle permettant aux analystes, managers et
décideurs d’accéder de manière rapide, consistante et interactive à une large
variété d’information, transformée pour reﬂéter la dimension réelle d’une
entreprise.
• Exemple : Quel est le volume des ventes par produit et par région durant le
deuxième trimestre de 2012 ?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
OLTP vs. OLAP

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Charge sur le Serveur de Données

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modélisation Entité/Relation
• Discipline permettant d’éclairer les relations microscopiques
entre les données (Suppression des redondances, simpliﬁcation
des transactions...)
• Principes
• Notion d’identiﬁant
• Dépendance fonctionnelle
• Formes normales

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• Il existe 8 formes normales
• Exemples :
FN1 : Les attributs d’une table doivent contenir une valeur scalaire,
non répétitives et constante dans le temps

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• Exemples :
FN2 : Les attributs d’une relation sont divisés en deux groupes : La
clé (une ou plusieurs)et les autres attributs (éventuellement vides).
Tout attribut du deuxième groupe ne peut pas dépendre que d’un
sous-ensemble (strict) d’attribut(s) du premier groupe.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• Exemples :
FN3 : Tout attribut du deuxième groupe ne peut pas dépendre que
d’un sous-ensemble (strict) d’attribut(s) du deuxième groupe.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Limites de la Modélisation Entité/Relation
• Modèle complexe : plusieurs tables et jointures
• Risque de dégradation des performances
• Pas de compréhension par l’utilisateur
• Données historiques diﬃcilement représentées
• Contraire aux objectifs du DataWarehouse

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Notions de Base
• Méthode de conception logique qui vise à présenter les
données sous une forme standardisée, intuitive, qui permet des
accès hautement performants
• Permet de considérer un sujet analysé comme point dans un
espace à plusieurs dimensions
• Les données sont organisées de manière à mettre en évidence :
• Le sujet ⇒ Le Fait
• Les perspectives de l’analyse ⇒ Les Dimensions

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Les Faits
• Un fait
• Sujet d’analyse
• Grain de mesure de l’activité
• Résultat d’une opération d’agrégation des données
• Valeur d’une mesure, telle que : Chiﬀre d’aﬀaires, ventes,
gain, nombre de transactions
• En général, une valeur numérique
• Une table des faits
• Clé composite référençant les clés primaires des tables de
dimension
• Contient les valeurs des mesures et des clefs vers les tables des
dimensions
• Plusieurs tables de fait dans un datawarehouse
• A en général plusieurs lignes et peu de colonnes

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Les Faits
Fait : Montant des ventes, chaque jour pour chaque produit dans
chaque magasin.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Les Dimensions
• Une Dimension
• Thème ou axe selon lequel les données sont analysées
• En général sous forme textuelle
• Parfois discrète (ensemble de valeurs)
• Une table des dimensions
• Représente le point d’entrée de l’entrepôt de données
• Contient une clef primaire unique qui correspond à l’un des
composants de la clef multiple de la table des faits
• A en général plusieurs colonnes et peu de lignes

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Les Dimensions

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Vue
• Représentation d’une ou plusieurs requêtes de l’utilisateur du
SID
• À une requête correspond une et une seule vue
• À une vue peuvent correspondre plusieurs requêtes
• Une vue correspond également à un hyper-cube dont :
• Chaque dimension est décrite par une entité dont le contenu
est décrit par l’association de ces entités
• Les propriétés de l’association sont des faits ou mesures
• Les propriétés des entités intervenant dans la vue sont des
conditions
• Les combinaisons des conditions sont les coordonnées qui
déterminent des valeurs de faits
• Un fait n’est pas seulement un élément du résultat de la
requête, mais il doit être déterminé par l’association des
conditions

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Exemples de Vue
Exp1 : Quelles ont été les marges sur les ventes du produit ’P023’
pour le client "Ahmed Ben Salah" à Hammamet durant le mois de
janvier ?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Exemples de Vue
Exp2 : Quels ont été les revenus sur les ventes de la marque
’Teams’ en Tunisie durant l’année 2011 ?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Exemples de Vue
Exp3 : Quels ont été les quantités vendues de la gamme ’G006’
durant le Trimestre 2 pour la région du nord ?

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Domaine et Contexte
Domaine
• Concerne un utilisateur ou un ensemble cohérent d’utilisateurs
• Implique un vocabulaire commun et une manière commune
d’appréhender l’information
Contexte
• Ensemble de faits et dimensions assemblées selon des critères
sémantiques formels de cohérence
• Caractérisé par une association unique, groupant tous les faits
relevés dans les vues

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Exemple de Contexte

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Hiérarchie
• Élément fondamental dans la structure d’un contexte
• Représente pour l’utilisateur des chemins de consolidation
d’indicateurs (faits)
• Chaque niveau est représenté par une entité
• Certaines entités sont rattachées à d’autres par des liens
d’appartenance ou de regroupement hiérarchique
• Certains de ces chemins sont connus (Jour, Mois, Année),
d’autres doivent être repérés par une analyse précise du
vocabulaire des utilisateurs (Produit, Gamme, Marque)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Hiérarchie

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Granularité
• Le "grain" d’une dimension est le niveau de sélection le plus
fin possible de cette dimension
• Le grain de la dimension Temps est Mois
• Le grain de la dimension Territoire est Région
• L’intégration de chaque nouvelle vue est donc susceptible de
modifier le grain sur une ou plusieurs dimensions
• Le grain d’un contexte découle de la combinaison des grains
de toutes les dimensions. Il définit le niveau de détail pouvant
être obtenu par la requête la plus sélective et la plus fine
possible mettant en jeu toutes les dimensions.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Granularité
• Grain du contexte : combinaison Produit-Mois-Client-Région
• S’applique à tous les faits
• Règle : Tous les faits d’un contexte doivent être déﬁnis pour
le grain de ce contexte
• Si les 3 indicateurs marge, revenu et quantité sont dans le
contexte, alors ils ont un sens à tous les niveaux
• Exemple : si la marge n’est déﬁnie que par Pays et par Mois,
alors que les autres le sont par Région et par Trimestre, il y
aurait décalage de grain entre les faits
• Décalage de grain : les faits n’appartiennent pas tous au même
contexte ⇒Facteur d’incohérence !

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Granularité

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• Lisibilité
• Performances (chargement + exécution des requêtes)
• Évolutivité
• Redondances envisageables
• Pas de mise à jour en ligne (chargement uniquement)
• Pas de problème d’intégrité des données (contrôles à
l’acquisition)
• Privilégier l’accessibilité plutôt que la normalisation
• Requêtes ensemblistes, portant sur de gros volumes de
données
• Projections, restrictions, regroupements, agrégations
• Adaptation du modèle pour des requêtes ad-hoc
• Techniques d’optimisation basées sur les chemins d’accès
• Pré-calcul de certains agrégats + dé-normalisation

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Avantages de la Modélisation Multidimensionnelle
• Structure prévisible et standardisée
• Diminution du nombre de tables et de jointures
• Modèle évolutif qui peut être modifié sans peine :
• Ajout de nouveaux faits non prévus initialement, à partir du
moment où ils sont cohérents avec la granularité de la table
des faits existante
• Ajout de nouvelles dimensions, à partir du moment où une
seule valeur de la dimension est définie pour chaque
enregistrement factuel existant
• Ajout d’attributs dimensionnels nouveaux
• Changement de granularité : Décomposition des
enregistrements d’une dimension existante en un niveau de
détail plus fin à partir d’une date déterminée

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Inconvénients de la Modélisation Multidimensionnelle
• Tables plus volumineuses
• Fréquence d’accès très variable aux contenus des tables

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Règles d’Élaboration et d’Intégration des Vues
• La structure des vues externes se déduit directement des
requêtes des utilisateurs, non des connexions possibles entre
les entités
• Dans un domaine, il existe un ou plusieurs sous-ensembles de
vues liées entre elles par des critères de cohérence sémantique
et structurelles. ⇒ Contextes
• La liste exhaustive des vues n’est jamais ﬁgée
• La normalisation du MDD permet d’anticiper et d’intégrer
automatiquement dans chaque contexte le plus grand nombre
possible de vues probables d’après la structure vue connues.
• Entre deux entités intervenant dans une vue, il doit exister un
et un seul chemin de navigation sémantique et ce chemin doit
être le plus court possible

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Normalisation des Contextes
• Un contexte regroupant un nombre élevé de dimensions a peu
de chances de correspondre à une réalité et serait d’un
maniement trop complexe
• En général, le nombre de dimensions d’un contexte varie entre
4 et 12 dimensions
• Au delà de ce nombre, la probabilité de redondance
dimensionnelle devient de plus en plus importante
• Un contexte est dit cohérent lorsque toutes les vues qu’il
autorise ont une signiﬁcation dans le domaine de l’utilisateur

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Règle I
• Il ne doit pas y avoir de dépendance fonctionnelle entre deux
entités appartenant à des dimensions diﬀérentes d’un même
contexte
• Conséquence : Regroupement des entités dépendantes dans
une même dimension
• Exemple : Si les produits sont organisés par région, on doit
intégrer l’entité Région dans la dimension Produit

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Règle II
• Tous les faits d’un contexte doivent être déﬁnis d’une manière
cohérente pour toutes les combinaisons dimensionnelles de ce
contexte
• Conséquence : Les faits qui ne sont valables que pour
certaines dimensions nécessitent l’éclatement du contexte
• Exemple :

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Règle III
• Tous les faits d’un contexte doivent être déﬁnis pour le grain
de ce contexte
• Le grain d’un contexte découle de la combinaison des grains
de toutes les dimensions
• Le grain d’une dimension est le niveau de sélection le plus ﬁn
possible de cette dimension

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Règle IV
• Le graphe de chaque dimension doit être acyclique
• Conséquence : Il faut rompre les cycles

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sommaire
Aspects Fondamentaux de la MMD
Opérations OLAP
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modèle en Étoile
• Une (ou plusieurs) table(s) de faits comprenant une ou
plusieurs mesures
• Plusieurs tables de dimension dé-normalisées : descripteurs des
dimensions.
• Les tables de dimension n’ont pas de lien entre elles.
• Avantages
• Facilité de navigation.
• Performances : nombre de jointures limité ; gestion des
données creuses.
• Gestion des agrégats
• Inconvénients
• Redondances dans les dimensions.
• Alimentation complexe..

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modèle en Étoile

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modèle en Flocon de Neige
• Dérivé du schéma en étoile où les tables de dimensions sont
normalisées
• La table des faits reste inchangée
• Chacune des dimensions est décomposée selon sa (ou ses)
hiérarchie(s)
• Exemple : Commune, Département, Région, Pays, Continent
• Utilisé lorsque les tables sont très volumineuses
• Avantages
• Réduction du volume
• Permettre des analyses par pallier (drill down) sur la dimension
hiérarchisée
• Inconvénients
• Navigation diﬃcile
• Nombreuses jointures

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modèle en Flocon de Neige

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modèle en Constellation
• Fusionner plusieurs modèles en étoile qui utilisent des
dimensions communes
• Un modèle en constellation comprend donc :
• Plusieurs tables des faits
• Des tables de dimension communes ou non à ces tables de faits

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modèle en Constellation

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Synthèse
• Modèle en étoile
• Taille de dimension plus grosse
• Modèle en ﬂocon de neige
• Jointures pour reconstruire
⇒ Modèle en étoile << Modèle en ﬂocon

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Aspects Fondamentaux
Dimension
• Une dimension peut être déﬁnie comme un thème, ou un axe
(attributs), selon lequel les données seront analysées.
• Ex : Temps, Découpage administratif, Produits.
• Une dimension contient des membres organisés en hiérarchie :
• Chacun des membres appartient à un niveau hiérarchique (ou
niveau de granularité) particulier
• Exemple : pour la dimension Temps : année - semestre - mois -
jour

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Dimensions : Vocabulaire
Dimension
• Temps, Produit, Géographie, ...
Niveau : hiérarchisation des dimensions
• Temps : Année, Semestre, Trimestre, Mois, Semaine, ...
• Produit : Rayon, Catégorie, Nature,...
• Géographie : Région, Département, Ville, Magasin, ...
Membres d’un Niveau
• Produit ::Rayon : Frais, Surgelé, Liquide
• Produit ::Rayon.Catégorie : Frais.Laitage, Liquide.Jus
• Produit ::Rayon.Catégorie.Nature : Frais.Laitage.Yaourt, Liquide.Jus.Orange
Cellule
• Intersection des membres des diﬀérentes dimensions
Formule
• Calcul, expression, règle, croisement des dimensions
• Exemple : Somme(Qte*PrixVente), Moyenne(Qte*(PrixVente-PrixAchat))...

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Dimension Temps
• Commune à tout entrepôt
• Reliée à toute table de fait
• 2 choix d’implantation
• Type SQL DATE
• Calendrier + Table Temps + Informations supplémentaires
• Évènement (match de ﬁnale de coupe du monde)
• Jours fériés, vacances, période ﬁscale,
• Saison haute ou basse,...

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Fait
Mesure
• Élément de donnée sur lequel portent les analyses, en fonction
des diﬀérentes dimensions
• Exemple : coût des travaux, nombre d’accidents, ventes
Fait
• Valeur d’une mesure, mesurée ou calculée, selon un membre
de chacune des dimensions
• Exemple : ń 250 000 euros ż est un fait qui exprime la valeur
de la mesure ń coût des travaux ż pour le membre ń 2002 ż
du niveau année de la dimension ń temps ż et le membre ń
Versailles ż du niveau ń ville ż de la dimension ń découpage
administratif ż

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Faits : Vocabulaire
Fait Additif
• Additionnable suivant toutes les dimensions
• Exemples : quantité vendue, chiﬀre d’aﬀaires, coût
Fait Semi-Additif
• Additionnable selon certaines dimensions
• Exemples : Niveau de stock (excepté sur la dimension temps),
Nombre de transactions, de clients (excepté sur la dimension
produit)
Fait Non-Additif
• Non additionnable
• Exemple : attribut ratio (marge brute = 1- Coût/CA)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Métabase de Données
• Existence d’une Métabase de données ou Catalogue de
métadonnées :
• Contient les métadonnées du DW
• Idéalement : Lieu de stockage unique des informations qui
pilotent les processus dans l’entrepôt
• Détails sur :
• Les données entreposées,leur format, leur signiﬁcation, leur
degré d’exactitude
• Les processus de récupération/extraction dans les bases
sources
• La date du dernier chargement de l’entrepôt
• L’historique des données sources et de celles de l’entrepôt

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Opérations OLAP
• Drill-up / Drill-down
• Rotate
• Slicing
• Scoping

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Opérations OLAP
Drill-Up / Drill-Down

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Opérations OLAP
Rotate

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Opérations OLAP
Slicing

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Opérations OLAP
Scoping

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
• ROLAP : Relational OLAP
• MOLAP : Multi-Dimentional OLAP
• HOLAP : Hybrid OLAP
• DOLAP : Desktop OLAP

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ROLAP (Relational OLAP)
• OLAP relationnel
• Données obtenues à partir de tables relationnelles et de
jointures entre celles-ci
• En fonction de la granularité, la requête générée est plus ou
moins complexe
• À chaque consultation, la requête est recalculée
• Les résultats ne sont pas stockés
• Langage : SQL
Avantages
• Faible coût (car tire partie des ressources existantes)
Inconvénients
• Temps de réponse long car sollicitation de la base à chaque
relance d’un rapport

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
MOLAP (Multi-Dimentional OLAP)
• OLAP multi-dimentionnel (Plus de relationnel !)
• Données stockées dans une base de données
multi-dimensionnelle appelée CUBE (Exemple : Essbase)
• Tous les croisements possibles sont pré-calculés =>
Restitution des données instantanée
• Langage : MDX
Avantages
• Temps de réponse très court (tout est stocké)
Inconvénients
• Coût élevé des licences pour les bases multi-dimensionnelles
• Coût élevé de développement des cubes
• Diﬃcile à mettre en place pour les gros volumes de données, à
cause de tous les résultats précompilés

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
HOLAP (Hybrid OLAP)
• Association du ROLAP et du MOLAP
• Concept de Drill-Through
• Accès aux données agrégées avec MOLAP (Cube)
• Accès aux détails avec le ROLAP (tables relationnelles)
• Étapes :
• Données agrégées stockées dans une table multi-dimensionnelle
• Restitution de ces données à partir d’un outil de reporting
• Aﬃchage des données agrégées extraites à partir des tables
multi-dimensionnelles
• Aﬃchage des détails des opérations issus des bases
relationnelles
Avantages
• Temps de réponse assez court
• Moins coûteux que MOLAP car moins de développement
Inconvénients
• Ne pourra pas être utilisé si les rapports sont trop complexes et font trop de
croisements de données

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
DOLAP (Desktop OLAP)
• Ce n’est pas une technologie de stockage, mais un mode de
fonctionnement.
• Base de donnée OLAP limitée en taille
• Permet à l’utilisateur d’enregistrer une partie de la base de
données multi-dimensionnelle en local

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Sommaire
Conclusion

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusion
Réfléchis avec lenteur,
mais exécute rapidement tes
décisions.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Références Bibliographiques
Jacky Akoka et Isabelle Comyn-Wattiau (Univ. de Versailles).
Le data warehouse et les systèmes multidimentionnels.
Fatma Baklouti (INSAT).
Data warehouse.
Didier Donsez (Université Joseph Fourier).
Conception de bases décisionnelles.
Ralph Kimball.
Concevoir et déployer un Data Warehouse.
Eyrolles edition, 2000.
E. Grislin-Le Strugeon (Univ. de Valenciennes).
Systèmes d’information décisionnels (data warehouse/ data
mining).
Open Source Solutions Smile.

Business Intelligence

Contenu connexe

Tendances

En vedette

Similaire à Business Intelligence

Plus de Lilia Sfaxi

Business Intelligence