Business Intelligence

Chp1 – Introduction à l’Informatique Décisionnelle

Plan du Chapitre 2

Business Intelligence
◙ Définition de l’Informatique Décisionnelle

◙ Pourquoi construire un système décisionnel?

◙ Métriques d’aide à la décision

◙ Chaîne décisionnelle

◙ Utilisation des systèmes décisionnels

 3

Business Intelligence
Définition de l’Informatique Décisionnelle

CHAPITRE 1:
INTRODUCTION À L’INFORMATIQUE
DÉCISIONNELLE
Aide à la Décision: Mise en Situation 4

Business Intelligence
◙ Le chiffre d’affaires a baissé en octobre. Pour y remédier, des décisions sont à
prendre. Mais pour prendre la bonne décision, il faut savoir:
◙ Pourquoi le chiffre d’affaires 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 quel segment de distribution ?
◙ N’avait-on pas une baisse semblable en octobre chaque année ?
Business Intelligence: Définition (1) 5

Business Intelligence
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 afin d’améliorer
et d’optimiser les décisions et les performances.

Source : Gartner
Business Intelligence: Définition (2) 6

Business Intelligence
Un ensemble de solutions informatiques permettant l’analyse des données de
l’entreprise, afin d’en dégager les informations qualitatives nouvelles qui vont fonder
des décisions, qu’elles soient tactiques ou stratégiques.

Source : Smile (Open Source Solutions)

 Business Intelligence
Pourquoi construire un système décisionnel?

CHAPITRE 1:
INTRODUCTION À L’INFORMATIQUE
DÉCISIONNELLE
Pourquoi construire un système 8

décisionnel?

Business Intelligence
1. Servir une information considérée comme stratégique.
2. Quelques constats.
3. Les besoins justifiant un système décisionnel.
4. Les principaux défis des projets décisionnels.
 9
Pourquoi construire un système décisionnel?
1. Servir une information considérée comme stratégique

Business Intelligence
◙ 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.
◙ Le Système d'Information Décisionnel résulte d’un processus qui consiste à extraire les
données à partir des systèmes opérationnels et d’autres sources externes à l’entreprise,
de les transformer en information de pilotage et de les rendre accessibles aux
utilisateurs.
◙ La Base Décisionnelle est aujourd’hui reconnue comme un actif stratégique par
beaucoup d’entreprises.
 10
Pourquoi construire un système décisionnel?
2. Quelques constats

Business Intelligence
◙ L’information existante est souvent très riche mais il est difficile d’avoir une
vision globale homogène et cohérente des informations manipulées par
l’ensemble des départements.
◙ Il n’est pas facile accéder directement à l’information nécessaire : il existe
plusieurs sources utilisant des supports différents (papier, base de données,
fichiers Excel).
◙ Les données de gestion peuvent avoir des significations différentes selon
l’utilisation qui en est faite, exemples : la marge, le CA. Mais le reporting de
Direction Générale n’accepte qu’un seul sens à une valeur restituée.
 11
Pourquoi construire un système décisionnel?
3. Les besoins justifiant un système décisionnel.

Business Intelligence
1. Meilleur accès aux données 1 86%

2. Amélioration de la qualité des informations.

2 76%
3. Intégration des données provenant de systèmes
différents 3 72%

4. Définition commune des informations. 4 69%

5. Meilleur accès aux données historiques

5 63%

0% 20% 40% 60% 80% 100%

 12
Pourquoi construire un système décisionnel?

Business Intelligence
4. Les principaux défis d’un système décisionnel.

1. Compréhension des besoins utilisateurs

1 65%
2. Intégrité des données.

3. Coût des alimentations en données 2 59%

4. Définition du périmètre du projet 3 56%

5. Performances du système 4 55%

6. Règles de gestion commune
5 47%

6 45%

0% 10% 20% 30% 40% 50% 60% 70%

 13

Métriques d’aide à

Business Intelligence
la décision

CHAPITRE 1:
INTRODUCTION À L’INFORMATIQUE
DÉCISIONNELLE
Concepts Clefs 14

Business Intelligence
Sagesse

Connaissance

Information

Donnée
Concepts Clefs : Donnée 15

Business Intelligence
Donnée

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

◙ Exemple
◙ Le mois dernier, on a enregistré 1217 incidents au centre de services
◙ 10 nouveaux prestataires ont été employés à la direction informatique
Concepts Clefs : Information 16
Information

Business Intelligence
Donnée

◙ 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

◙ Exemple
◙ Le mois dernier, on a enregistré une augmentation de 240% du nombre
d’incidents par rapport au mois précédent
◙ L’emploi des 10 prestataires est lié à une augmentation temporaire de la
charge de travail
Concepts Clefs : Connaissance Connaissance
17
Information

Business Intelligence
Donnée

◙ Connaissance:
◙ Résultat d’une réflexion sur les informations analysées
◙ Se base sur les expériences, les idées, valeurs, avis des personnes consultées

◙ Exemple
◙ Les gestionnaire de changement peut établir une corrélation entre
l’arrivée des nouveaux prestataires et l’augmentation du nombre
d’incidents en ayant connaissance de certains éléments
Concepts Clefs : Sagesse Sagesse

Connaissance
18
Information

Business Intelligence
Donnée

◙ Sagesse:
◙ État d’esprit général de discernement final 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

◙ Exemple
◙ Le responsable sénior de l’organisation prend des décisions à long terme et des
décisions stratégiques pour l’organisation informatique.
Illustration d’un reporting imprécis 19

Business Intelligence
 20

En fait, l’important est dans la variation

Business Intelligence
 21
Mais une information peut en cacher une autre…

Business Intelligence
 22

Business Intelligence
CHAPITRE 1:
Chaîne Décisionnelle INTRODUCTION À L’INFORMATIQUE
DÉCISIONNELLE
La chaîne décisionnelle 23

Business Intelligence
 Les 5 grandes étapes:

Planification ETL Stockage Analyses Restitution

Planification 24

Planification ETL Stockage Analyses Restitution

Business Intelligence
◙ Pour mettre en place une plate-forme décisionnelle d'entreprise intégrée, la
première étape est donc la planification 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 25

Business Intelligence
Planification ETL Stockage Analyses Restitution

◙ ETL : Extract, Transform, Load

◙ Extraction des données à partir d’une ou plusieurs sources de données : fichier 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 ici incontournable car elle conditionne et influence la qualité
du projet par la suite.
Stockage 26
Planification ETL Stockage Analyses Restitution

Business Intelligence
◙ Plusieurs manières de stocker la donnée dans un data Warehouse.
◙ Chacune ayant ses avantages et ses inconvénients.
◙ L'administrateur des bases de données décisionnelles pourra notamment choisir
entre : DDS (Detail Data Store), les schémas en étoile, schéma en flocon…
Analyse 27

Planification ETL Stockage Analyses Restitution

Business Intelligence
 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 28
Planification ETL Stockage Analyses Restitution

Business Intelligence
◙ 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 29

Business Intelligence
L’alimentation est la part la plus 30

Business Intelligence
importante d’un projet
Pourquoi les alimentations sont-elles 31

difficiles?

Business Intelligence
◙ Sur le plan des données
◙ Définir 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, et traçabilité des données
◙ temps de chargement compatibles avec la fenêtre d'exploitation
Risques et facteurs de succès 32

Business Intelligence
◙ L’implication des utilisateurs est indispensable
 33

Business Intelligence
CHAPITRE 1:
Utilisation des systèmes décisionnels
INTRODUCTION À L’INFORMATIQUE
DÉCISIONNELLE
Les principaux risques d'un projet 34

décisionnel

Business Intelligence
◙ Orientation technologique du projet, plutôt qu’utilisateur
◙ Mise en cause de la fiabilité et/ou cohérence des informations
◙ Alimentations trop longues et irrégulières
◙ Outils et architecture technique inadaptés
◙ Fraîcheur insuffisante 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
Quelques facteurs clefs de succès 35

Business Intelligence
◙ Pour la conduite de projet :
◙ Adopter une démarche incrémentale avec des objectifs précis et quantifié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 :
◙ Préférer des états figés mais utiles à des analyses libres mais compliquées
◙ Raisonner en flux amont-aval et en échanges transverses entre utilisateurs
Quelques facteurs clefs de succès 36

Business Intelligence
◙ Dans la mise en œuvre technique :
◙ 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
◙ Pour la prise en compte des impacts organisationnels :
◙ 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
Utilisations du système décisionnel 37

Business Intelligence
◙ Mailing
◙ Banque, Assurance
◙ Commerce
◙ Logistique
◙ Santé
◙ Ressources Humaines
◙ Télécommunications : pannes, fraudes, mobiles, …
Business Intelligence
Chp2 – Les Entrepôts de Données (Data Warehouses)
Plan du Chapitre 39

Business Intelligence
◙ Problématique des données dans un système décisionnel

◙ Architecture fonctionnelle d’un système décisionnel

◙ Les entrepôts de données

 40

Business Intelligence
Problématique des données dans un
système décisionnel

CHAPITRE 2:
ENTREPÔTS DE DONNÉES – DATA WAREHOUSE
Systèmes 41

Opérationnels vs. Décisionnels

Business Intelligence
Systèmes opérationnels Systèmes décisionnels
◙ Appelés OLAP (On-Line Analytical
◙ Appelés OLTP (On-Line Transaction
Processing)
Processing) ou systèmes de gestion

◙ Dédiés à la gestion de l’entreprise pour

◙ Dédiés aux métiers de l’entreprise pour les
assister dans leurs tâches de gestion l’aider au pilotage de l’activité pour une
quotidiennes vision transversale de l’entreprise

◙ Utilisation des ERP pour la gestion des

◙ Utilisation des Entrepôts de données
données
Données 42

Opérationnelles vs. Décisionnelles

Business Intelligence
Données Opérationnelles Données Décisionnelles

◙ Données détaillées ◙ Données globalisées

◙ Données récentes ◙ Données historiques

◙ Structure compréhensible et optimisée ◙ Structure compréhensible par le décideur

pour l’informaticien
◙ Données centralisées, intégrées
◙ Données réparties et non homogènes
◙ Utilisateurs: Décideurs, analystes, peu
◙ Utilisateurs: Agents opérationnels, nombreux et non concurrents
nombreux, et concurrents
Charge du Serveur de Données 43

Business Intelligence
 Solutions 44

◙ Stockage de données : Data Warehouse

Business Intelligence
◙ Base de données unique - vocabulaire unique
◙ Contenu adapté aux besoins des décideurs
◙ Structure multidimentionnelle spéciale
◙ Niveau de détail bien étudié
◙ Données historiques

◙ Interrogation des données :

◙ Outil interactif, convivial
◙ Outil offrant des fonctions d’analyse
◙ Tri des données
◙ Roll-up, Drill-down
◙ Calcul et comparaison
◙ Analyse des tendances, relations et exceptions
◙ Simulation
OLTP vs. OLAP 45

Business Intelligence
◙ OLTP : On Line Transaction Processing
◙ Système destiné à offrir le moyen à une application d’utiliser de façon transactionnelle un serveur de base
de données. C’est un ensemble logiciel 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 reflé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 46
OLTP OLAP

Business Intelligence
Conception - Orientée application (Application de production, - Orientée sujet (Client, produit, vendeur…)
de facturation…) - Structure évolutive (en étoile, en flocon)
- Structure statique (E/R)

Données - Détaillées, non agrégées - Résumées, recalculées, agrégées

- Récentes, mises à jour - Historiques
- Accessibles de façon individuelle - Accessibles de façon ensembliste
- Normalisées - Dénormalisées

Vue - Relationnelle - Multidimensionnelle

Requêtes/ - Simples, nombreuses, régulières, prévisibles, - Complexes, peu nombreuses, irrégulières, non
Utilisation répétitives prévisibles
- Sensibles aux performances (réponses - Non sensibles aux performances (réponses moins
immédiates) rapides)
- Accès à beaucoup de données - Accès à beaucoup d’informations

Utilisateurs - Agents opérationnels - Managers / Analystes

- Nombreux (par milliers) - Peu (par dizaines, centaines)
- Concurrents - Non concurrents

Accès - Lecture / Écriture - Lecture

Taille de la base - 100 MB à 1 GB - 100 GB à 1 TB
 Technologies 47

Business Intelligence
Stockage et Gestion Entrepôt de Données
Efficace des Gros (Data Warehouse)
Volumes

Traitements Serveur OLAP

Complexes sur ces
Volumes

Application Cliente Fouille de Données

(Data Mining)
Structure d’un Système Décisionnel 48

Business Intelligence
 49

Structures de Stockage de Données

Business Intelligence
dans un Système Décisionnel

CHAPITRE 2:
ENTREPÔTS DE DONNÉES – DATA
WAREHOUSE
Structures de Stockage de Données dans un Système Décisionnel

50
Data Mining

Business Intelligence
(Extraction de données)

Data Marts
(Magasins de données)
Synthèse

Data Warehouse
(Entrepôt de données)
Alimentation
Transformation
ODS
(Operational Data Store)
Extraction
Systèmes
Opérationnels
Définitions 51

◙ ODS: Operational Data Store

Business Intelligence
◙ 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
◙ Data Warehouse
◙ Entrepôt de données spécifique 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
◙ 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
◙ Ensemble d’outils, méthodes et technologies d’analyse mises en œuvre pour définir des tendances, pour
segmenter l’information ou pour établir des corrélations entre les données
Data Warehouse vs. ODS 52

Business Intelligence
◙ Data Warehouse
◙ 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 modifier 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 ces données et les afficher
Data Warehouse vs. Data Mart 53

Business Intelligence
◙ Data Warehouse
◙ Dépôt de données au niveau entreprise
◙ Combinaison de plusieurs Data Marts
◙ Contient toutes les mesures et dimensions nécessaires
◙ Assure l’intégrité de ces mêmes dimensions à travers tous les Data Marts
◙ Data Mart
◙ Ensemble de dimensions et mesures limitées
◙ Utilisées pour des thèmes métier spécifiques
◙ 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…
 54

Business Intelligence
Les Entrepôts de Données

CHAPITRE 2:
ENTREPÔTS DE DONNÉES – DATA
WAREHOUSE
Pourquoi ne pas utiliser un SGBD? 55

Business Intelligence
◙ SGBD et DW
◙ Ont des objectifs différents et font des traitement différents
◙ Stockent des données différentes
◙ Font l’objet de requêtes différentes
 Besoin d’une organisation différente des données
 Doivent être physiquement séparés
◙ SGBD
◙ Mode de travail transactionnel (OLTP)
◙ Permettent d’insérer, modifier, interroger des informations rapidement, efficacement et en sécurité

Objectifs:
1. Sélectionner, ajouter, mettre à jour et supprimer des tuples
2. Opérations rapides, faites par plusieurs utilisateurs simultanément
Entrepôt de Données : Objectifs 56

Business Intelligence
◙ Regrouper, organiser des informations provenant de sources diverses
◙ Les intégrer et les stocker pour donner à l’utilisateur une vue orientée métier
◙ Retrouver et analyser l’information selon plusieurs critères
◙ Transformer un système d’information qui avait une vocation de production en un
SI décisionnel
◙ Doit contenir des informations cohérentes
◙ 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.
Entrepôt de Données : Définition 57

(Bill Inmon)

Business Intelligence
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.
 Caractéristiques d’un DW 58
Données Orientées Sujet

Business Intelligence
 Le DW est orienté sujets, ce qui signifie que les données collectées doivent être orientées
métier, et donc triées par thème

Bases de données Entrepôt de données

Caractéristiques d’un DW 59
Données Intégrées

Business Intelligence
 Le DW est composé de données intégrées, c’est à dire qu’un « nettoyage » préalable des
données est nécessaire dans un souci de rationalisation et de normalisation

Bases de données Entrepôt de données

Caractéristiques d’un DW 60
Données Historisées et Non Volatiles

Business Intelligence
 Les données du DW sont non volatiles, ce qui signifie qu’une donnée entrée dans l’entrepôt
l’est pour de bon et n’a pas vocation à être supprimée
 Les données du DW doivent être historisées, donc datées

Bases de données Entrepôt de données

Data Warehouse : ETL 61

Business Intelligence
 Outils d’alimentation pour BD BD BD
 Extraire
 Transformer Extraction
les données sources
 Charger dans un DW
Transformation

Chargement

DW
ETL : Extraction 62

Business Intelligence
◙ 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 BD BD BD

◙ Attention: Extraction

Transformation
◙ L’extraction ne doit pas perturber l’activité de production
Chargement

DW
ETL : Transformation BD BD

Extraction
BD
63
Transformation

Business Intelligence
◙ Intégration des données Chargement

◙ Homogénéisation du vocabulaire, structures, valeurs DW

◙ Suppression et fusion des redondances

◙ Épuration des données (suppression des données incohérentes)
◙ Transformation des données dans un format cible
ETL : Chargement 64

Business Intelligence
◙ 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é BD BD BD

Extraction
◙ Conservation des données détaillées
Transformation
◙ Possibilité d’agrégation des données pour la synthèse
Chargement

DW
DW : Métabase de Données 65
BD BD BD

Business Intelligence
Extraction

Transformation

◙ Existence d’une métabase de données ou catalogue de métadonnées: Chargement

◙ Contient des métadonnées du DW DW

◙ Idéalement: Lieu de stockage unique des informations qui pilotent des processus dans
l’entrepôt
◙ Détails sur :
◙ Les données entreposées, leur format, leur signification, 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
 DW : Structure (1/3)
BD BD BD

Extraction 66
Transformation

Business Intelligence
Chargement

1. Directe simple : DW

 On fait des mises à jour du

datawarehouse avec des laps de
temps importants.
 DW : Structure (2/3)
BD BD BD

Extraction 67
Transformation

Business Intelligence
Chargement

2. Cumul simple : DW

◙ On stocke les données de

chaque mise à jour, les mises à
jour étant fréquentes (par
exemple tous les jours) on a un
espace occupé important, mais
on ne perd pas d’information.
 DW : Structure (3/3)
BD BD BD

Extraction 68
Transformation

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

Business Intelligence
Chp3 – Modélisation des Données Décisionnelles

M/C [Link]
2017-2018
Modélisation des Données Décisionnelles 70

Business Intelligence
◙ Utilisation de concepts pour :
◙ Optimiser la restitution de données selon les axes métiers de l’entreprise
◙ Gérer et visualiser les données de manière rapide et intuitive
◙ Retrouver et analyser rapidement les données à partir de diverses sources
◙ Intégrer plusieurs bases de données
◙ Extraire, grouper, organiser et corréler et transformer les données
◙ Deux types de modélisations: Entité-Relation et Multidimensionnelle
 71

Business Intelligence
Modèles de Données
Plan du Chapitre 72

Business Intelligence
◙ Modélisation Entité-Relation
◙ Modélisation Multidimensionnelle
◙ Conception des Data Warehouses : Etapes et Exemple
◙ Modèles d’un Data Warehouse
◙ Aspects Fondamentaux de la Modélisation Multidimensionnelle
 73

Business Intelligence
Modélisation Entité-Relation
CHP3: MODÉLISATION DES DONNÉES DÉCISIONNELLES
Modélisation Entité-Relation 74

◙ Discipline permettant d’éclairer les relations microscopiques entre les données

Business Intelligence
◙ Supprimer la redondance des données
◙ Simplifier le traitement des transactions
◙ Aider le concepteur dans la répartition des propriétés entre les entités
◙ Principes
◙ Notion d’identifiant
◙ Dépendance fonctionnelle
◙ Décomposition
◙ Formes normales
Normalisation dans les BDR 75

Business Intelligence
◙ Forme normale :
◙ Type de relation particulier entre les entités
◙ Permet d’éviter les anomalies transactionnelles dues à une mauvaise modélisation des
données
◙ Permet de vérifier la robustesse de la conception des modèles de données pour éviter
les problèmes de redondance et de mise à jour du contexte
◙ Dans le modèle OLTP, il existe 8 formes normales
◙ Elles s’emboitent les unes dans les autres
◙ Le respect d’une FN de niveau supérieur implique le respect des FN des niveaux
inférieurs
◙ On va présenter les 3 premières (les plus utilisées)
Première Forme Normale (1FN) 76

◙ Relation dont tous les attributs :

Business Intelligence
◙ Contiennent une valeur scalaire (les valeurs ne peuvent pas être divisées en plusieurs
sous-valeurs dépendant également individuellement de la clé primaire)
◙ Contiennent des valeurs non répétitives (le cas contraire consiste à mettre une liste
dans un seul attribut).
◙ Sont constants dans le temps (utiliser par exemple la date de naissance plutôt que
l'âge).

Problème Solution
Produit Fournisseur Produit Fournisseur
Téléviseur Vidéo SA, Hitek LTD Téléviseur Vidéo SA
Téléviseur Hitek LTD
Deuxième Forme Normale (2FN) 77

◙ Les attributs d'une relation sont divisés en deux groupes :

◙ Le premier groupe est composé de la clé (une ou plusieurs).
◙ Le deuxième groupe est composé des 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.
◙ « Un attribut non clé ne dépend pas que d'une partie de la clé »

Problème Solution
Pdt Fournisseur Adresse Fournisseur Produit Fournisseur Fournisseur Adresse
Télé Vidéo SA 13 rue Midi Télé Vidéo SA Vidéo SA 13 rue Midi
Ecran Vidéo SA 13 rue Midi Ecran Vidéo SA Hitek LTD 25 rue Bond
Télé Hitek LTD 25 rue Bond Télé Hitek LTD
Troisième Forme Normale (3FN) 78

Business Intelligence
◙ Les attributs d'une relation sont divisés en deux groupes :
◙ Le premier groupe est composé de la clé (une ou plusieurs).
◙ Le deuxième groupe est composé des 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 deuxième groupe.
◙ « Un attribut non clé ne dépend pas d'un ou plusieurs attributs ne participant pas à la clé ».

Problème Solution
Fournisseur Adresse Ville Pays Fournisseur Adresse Ville Ville Pays
Vidéo SA 13 rue Midi Paris France Vidéo SA 13 rue Midi Paris Paris France
Hitek LTD 25 rue Bond London England Hitek LTD 25 rue Bond London London England
Modélisation Entité-Relation 79

Business Intelligence
◙ Le succès du traitement des transactions dans les BDR est essentiellement dû à
l’apport de la modélisation entité/relation
◙ Exemple
◙ La transaction qui consiste à mettre à jour une adresse client peut ainsi se résumer à
une simple recherche dans une table principale d'adresses clients.
◙ Cette recherche est contrôlée par une clé d'adresse client, qui définit l'unicité de
l'enregistrement et permet une recherche indexée extrêmement rapide.
◙ Le respect des formes normales fait que cette mise à jour soit faite en une itération,
sans risque d’oublier des enregistrements
Limites de la Modélisation E/R 80

Business Intelligence
◙ Modèle complexe
◙ Plusieurs tables et jointures mises en œuvre
◙ Risque de dégradation des performances
◙ Pas de compréhension pour l’utilisateur
◙ Données historiques difficilement représentées
◙ Contraire aux objectifs du DW
 81

Business Intelligence
Modélisation Multidimensionnelle
CHP3: MODÉLISATION DES DONNÉES DÉCISIONNELLES
Modélisation Multidimensionnelle : 82

Notions de Base

Business Intelligence
◙ Méthode de conception logique qui vise à présenter les données sous une forme
standardisée, intuitive et 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  La table des dimensions
Faits – Table des Faits 83

Business Intelligence
◙ Fait
◙ Sujet d’analyse
◙ Grain de mesure de l’activité
◙ Résultat d’une opération d’agrégation des données
◙ Exemple: Chiffre d’affaires, nombre de vente, gain, nombre de transaction… en général : une valeur numérique
◙ Les mesures sont stockées dans la table des faits
◙ Table des faits
◙ Clé composite référencent des clés primaires des tables de dimensions
◙ Contient les valeurs des mesures et des clefs vers les tables de dimensions  traduit une relation (n,m) entre les
dimensions
◙ Plusieurs tables de fait dans un DW
◙ Les faits les plus utiles d’une table des faits sont numériques et additifs
Faits – Table des Faits 84

Business Intelligence
◙ Exemple:
◙ Fait: Montant des ventes, chaque jour pour chaque produit dans chaque magasin
◙ A en général plusieurs lignes et peu de colonnes

Ventes Journalières Table des Faits

Date
Magasin
Clé Date
Clé Produit
Dimensions Produit Clé Magasin
Quantité vendue
Montant des ventes Faits
Table des Dimensions 85

Business Intelligence
◙ Contient une clé primaire unique qui correspond à l’un des
composants de la clé multiple de la table des faits
Produit
◙ Les tables dimensionnelles sont les points d’entrée de l’entrepôt de
données
◙ Les dimensions Clé Produit
Description produit
◙ Thème (ou axe) selon lequel les données sont analysées Description marque
Description catégorie
◙ En général sous forme textuelle Description type emballage
Taille emballage
◙ Parfois discrète (ensemble limité de valeurs): couleurs, parfums Poids
Unité de mesure du poids
◙ A en général plusieurs colonnes et peu de lignes Type de stockage
Type de durée rayon
Largeur sur étagère
Hauteur sur étagère
Profondeur sur étagère
Vue 86

◙ Représentation d’une ou plusieurs requêtes de l’utilisateur du SID

Business Intelligence
◙ À 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,
comme une combinaison de valeurs numériques peut déterminer la position d’un point dans
l’espace
◙ 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
Vue 87

Business Intelligence
◙ Exemple 1:
◙ Requête: Quels sont les frais de déplacement et le kilométrage des commerciaux de la
région nord ayant des véhicules de 10 à 14 CV en avril 2004?
◙ Vue:
◙ Frais de déplacement
Faits Région
◙ Kilométrage
◙ Par Employé (fonction) Employé
Clé Employé
◙ Par Véhicule (puissance)
Nom Clé Véhicule
◙ Par Région Fonction
Clé Région Mois
◙ Par Mois Véhicule Clé Mois
Frais de déplacement
Marque Kilométrage
Puissance
Vue 88

Business Intelligence
◙ Exemple 2:
◙ Requête: Quelles ont été les marges sur les ventes du produit ‘P023’ pour le client Ben
Salah Ahmed à Hammamet durant le mois de Janvier?

Client Région
◙ Vue:
Nom
◙ Marge Fonction
◙ Produit Vue 1
◙ Client Produit Mois
Marge
◙ Région Nom
◙ Mois
Vue 89

Business Intelligence
◙ Exemple 3:
◙ Requête: Quels ont été les revenus sur les ventes de la marque ‘Teams’ en Tunisie
durant l’année 2011?

Marque
◙ Vue: Vue 2
◙ Revenu Année
◙ Marque
Pays
◙ Pays Revenu
◙ Année
Vue 90

Business Intelligence
◙ Exemple 4:
◙ Requête: Quels ont été les quantités vendues de la gamme ‘G006’ durant le Trimestre 2
pour la région du nord ?

◙ Vue: Gamme
◙ Quantité
Vue 3
◙ Gamme Trimestre
◙ Trimestre
Région
◙ Région Quantité
Domaine et Contexte 91

Business Intelligence
◙ 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
Contexte : Activité des Ventes 92

Business Intelligence
◙ En opérant une relation superficielle entre les trois vues des exemples 2, 3 et 4, on
détecte deux sortes d’éléments de rapprochement
◙ Certaines informations (entités ou faits) se retrouvent dans plusieurs vues
◙ Certaines entités, appartenant à des vues différentes, sont fonctionnellement liées les
unes aux autres.
◙ On peut intégrer ces vues en un seul contexte comportant une association porteuse des
faits: Marge, Revenu, Quantité, qui comporte neuf entités distinctes
Contexte : Activité des Ventes 93

◙ Contexte : Activité des Ventes

Client Région
Vue 1
Année

Trimestre
Produit Mois
Marge
Mois Client
Marque

Vue 2
Année Marge
Revenu
Produit Région
Pays Quantité
Revenu
Gamme Pays
Gamme

Vue 3 Marque
Trimestre

Région
Quantité
Hiérarchie 94

Business Intelligence
◙ É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 : Activité des Ventes 95

Business Intelligence
Mois Trimestre Année

… Temps

Produit Gamme Marque

… Produit

Région Pays

… Territoire

Client Catégorie

… Client
 Granularité 96

◙ Le « grain » d’une dimension est le niveau de sélection le plus fin possible de cette dimension

Business Intelligence
◙ 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é (Exemple) 97

Business Intelligence
◙ 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éfinis 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éfinie 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  les faits n’appartiennent pas tous au même contexte  facteur
d’incohérence
Grain du contexte Vente 98

Business Intelligence
Temps
Année
Trimestre Client
Catégorie

Mois Client
Produit
Région
Mois
Client
Produit Marge Région
Revenu
Gamme Quantité Pays

Marque

Territoire

Produit
Modélisation Multidimensionnelle: 99

Caractéristiques

Business Intelligence
◙ 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
Modélisation Multidimensionnelle: 100

Avantages

Business Intelligence
◙ 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
Modélisation Multidimensionnelle: 101

Inconvénients

Business Intelligence
◙ Tables plus volumineuses

◙ Fréquence d’accès très variable aux contenus des tables

Règles d’Élaboration et d’Intégration des 102

Vues

Business Intelligence
◙ 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 figé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
Démarche de Synthèse des Vues- 103

Contextes

Business Intelligence
◙ Identifier les faits de l’association
◙ Identifier les liens de dépendance entre les entités
◙ Regrouper les entités dépendantes dans une même dimension
◙ Nommer les dimensions
◙ Les dimensions pour lesquelles on trouve facilement un nom sont dites « Dimensions
fortes »
◙ Celles pour lesquelles on doute du nom associé sont dites « Dimensions douteuses »
◙ La structure d’une dimension douteuse peut varier à terme
Normalisation des Contextes 104

Business Intelligence
◙ 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
signification dans le domaine de l’utilisateur
Règles de Normalisation Dimensionnelle 105

Business Intelligence
◙ Règle 1:
◙ Il ne doit pas y avoir de dépendance fonctionnelle entre deux entités appartenant à des dimensions diffé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
Produit Produit
Id_produit Id_produit
Id_produit
Id_région Id_produit
Id_mois région
Id_mois Id_client
Id_client Marge
Marge Région
Revenu
Revenu Quantité
Quantité
Règles de Normalisation Dimensionnelle 106

Business Intelligence
◙ Règle 2:
◙ Tous les faits d’un contexte doivent être définis 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: Produit
Mois Id_produit
Id_région Id_produit
Id_mois
La marge des achats ne correspond
Id_client
pas à un client et région. Il faut donc
Marge_ventes
Client Région l’intégrer dans un autre contexte
Marge_achats
Revenu
Quantité
 Règles de Normalisation Dimensionnelle 107

Business Intelligence
◙ Règle 3:
◙ Tous les faits d’un contexte doivent être définis 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 fin possible de cette dimension
◙ Règle 4:
◙ Le graphe de chaque dimension doit être acyclique
◙ Conséquence: Il faut rompre les cycles

Gamme Marque Gamme Marque Pays

Produit
Produit
Id_produit Id_produit
Région Pays Région Pays
Forme Dimensionnelle Normale 108

Business Intelligence
◙ Le MDD correspond à un domaine qui se présente sous forme d’une constellation
ou galaxie dans laquelle chaque étoile correspond à un contexte

◙ Une même entité ou un même fait peut appartenir à plus d’un contexte, à
condition de conserver une définition unique

◙ Pour ces raisons pratiques, il est préférable de représenter les contextes sous une
forme déconnectée
 109

Business Intelligence
Modèles d’un Data Warehouse
CHP3: MODÉLISATION DES DONNÉES DÉCISIONNELLES
Modèles d’un DataWarehouse 110

Business Intelligence
◙ Modèle en étoile

◙ Modèle en flocon de neige

◙ Modèle en constellation
Modèle Étoile 111

Business Intelligence
◙ 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 - Exemple 112

Business Intelligence
Produit
Ventes
Code_pdt
Description Magasin
Couleur Code_produit
Marque Code_période
Créateur Code_mag
Code_Magasin Nom_mag
Période Ville
Téléphone
Unités_vendues Manager
Code_per Montant_ventes
Année
Trimestre
Montant_coût
Mois
Jour
Modèle en Flocon de Neige 113

Business Intelligence
◙ 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 difficile
◙ Nombreuses jointures
 Modèle en Flocon de Neige - Exemple 114

Business Intelligence
Marque
Produit
Code_marque Ventes
Nom
Description Code_pdt
Créateur Description Magasin
Couleur Code_produit
Code_marque
Code_période
Code_mag
Code_Magasin Nom_mag
Ville
Période Unités_vendues Téléphone
Manager
Montant_ventes
Code_per Montant_coût
Année
Trimestre
Mois
Jour
Constellation 115

Business Intelligence
◙ Fusionner plusieurs modèles en étoile qui utilisent des dimensions communes

◙ Un modèle en constellation comprend donc :

◙ Plusieurs tables de faits
◙ Des tables de dimensions communes ou non à ces tables de faits.
 Modèle en Constellation - Exemple 116

Business Intelligence
Produit
Fournisseur
Achats Ventes
Code_pdt
Code_four
Nom
Description Magasin
Adresse Code_produit Couleur Code_produit
Marque Code_période
Catégorie Code_période Code_mag
Créateur
Code_fournisseur Code_Magasin Nom_mag
Ville
Période
Téléphone
Unités_achetées Unités_vendues Manager
Code_per Montant_ventes
Montant_achats Année
Montant_remises Trimestre
Montant_coût
Mois
Jour
Synthèse 117

Business Intelligence
 Modèle en étoile
 Taille de dimension plus grosse
 Modèle en flocon de neige
 Jointures pour reconstruire
 Modèle en étoile >> Modèle en flocon
 car tables de dimension << tables de fait
 118

Business Intelligence
Aspects Fondamentaux de la
Modélisation MultiDimensionnelle
CHP3: MODÉLISATION DES DONNÉES DÉCISIONNELLES
Dimension 119

Business Intelligence
◙ Une dimension peut être définie 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
◙ Ex : pour la dimension Temps: année –semestre – mois – jour
Dimensions - Caractéristiques 120
◙ Dimension

Business Intelligence
◙ 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::[Link]́gorie : [Link], ... , [Link]
◙ Produit::[Link]́[Link] : [Link], ... , [Link]
◙ Cellule
◙ Intersection des membres des différentes dimensions
◙ Formule
◙ calcul, expression, règle, croisement des dimensions
◙ Somme(Qte), Somme(Qte*PrixVente), Moyenne(Qte*(PrixVente-PrixAchat)), ...
Faits 121

Business Intelligence
◙ Une mesure est un élément de donnée sur lequel portent les analyses, en fonction des
différentes dimensions
◙ Ex : coût des travaux, nombre d’accidents, ventes
◙ Un fait représente la 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 – Table des Faits 122

Business Intelligence
◙ Fait additif :
◙ Additionnable suivant toutes les dimensions
◙ Exemples: quantité vendue, chiffre d’affaire, 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)
 Dimension Temps 123

Business Intelligence
◙ 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 finale de coupe du monde)
◙ Jours fériés, vacances, période fiscale,
◙ saison haute ou basse, …
Opérations OLAP 124

Business Intelligence
◙ Drill Up / Drill Down
◙ Rotate
◙ Slicing
◙ Scoping
Opérations OLAP - Drill Up/Drill Down 125

Business Intelligence
Opérations OLAP - Rotate 126

Business Intelligence
Opérations OLAP - Slicing 127

Business Intelligence
Opérations OLAP - Scoping 128

Business Intelligence
Stockage 129

Business Intelligence
◙ ROLAP : Relational OLAP

◙ MOLAP : Multi-Dimentional OLAP

◙ HOLAP : Hybrid OLAP

◙ DOLAP : Desktop OLAP

ROLAP (Relational OLAP) 130

Business Intelligence
◙ 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
◙ A 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) 131

Business Intelligence
◙ OLAP multi-dimentionnel
◙ Données stockées dans une base de données multi-dimentionnelle appelée CUBE
◙ Exemple : Essbase…
◙ Plus de relationnel!
◙ Tous les croisements possibles sont précalculés
◙ Restitution des données instantanée
◙ Langage : MDX
◙ Avantages
◙ Temps de réponse très court (toutes les données et résultats sont stockés)
◙ Inconvénients
◙ Coût élevé des licences pour les bases multi-dimentionnelles
◙ Coût élevé de développement des cubes
◙ Difficile à mettre en place pour les gros volumes de données, à cause de tous les résultats précompilés
 HOLAP (Hybrid OLAP) 132
◙ Association du ROLAP et du MOLAP

Business Intelligence
◙ 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-dimentionnelle
◙ Restitution de ces données à partir d’un outil de reporting
◙ Affichage des données agrégées extraites à partir des tables multi-dimentionnelles
◙ Affichage 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) 133

Business Intelligence
◙ 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-

dimentionnelle en local
H-OLAP 134
◙ Nouvelles fonctions pour SQL

Business Intelligence
◙ BREAK BY (SAS)
◙ RANK : Rang d’une ligne par rapport à un agrégat
◙ TOP / BOTTOM : Requête de type « Top Ten » (les dix meilleurs, les dix moins bons)
◙ Extension du Group By (SQL99)
◙ Grouping Sets : Partitionnement selon plusieurs dimensions
◙ Rollup: réduire progressivement
◙ Cube : Partitionnement selon tous les sous-ensembles possibles de Grouping Sets
◙ MS MDX
◙ Langage d’expression OLAP pour MS SQL Server
◙ Exemples
◙ SELECT NON EMPTY {[Time].[1997], [Time].[1998]} ON COLUMNS, [Promotion Media].[Media
Type].Members ON ROWS FROM Sales
 135

Business Intelligence
Conception d’un Data Warehouse:
Étapes et Exemples
CHP3: MODÉLISATION DES DONNÉES DÉCISIONNELLES
Conception d’un Data Warehouse 136

Business Intelligence
◙ Étape 1
◙ Choisir le processus à modéliser
◙ Étape 2
◙ Choisir le grain des faits
◙ Décider de ce que représente une ligne de la table de faits
◙ Niveau de détail : transactions individuelles, récapitulatifs journaliers, mensuels…
◙ Étape 3
◙ Identifier les dimensions qui s’appliquent aux lignes de la table des faits
◙ Typiquement le temps, le client, le foyer, le produit, magasin, agence, compte…
◙ Étape 4
◙ Identifier les mesures de fait qui renseignent la table de faits
◙ De préférence des quantités numériques additives
Conception d’un Data Warehouse 137

Exemple : La Distribution

Business Intelligence
◙ Processus :
◙ Comprendre les achats des clients saisis aux Terminaux Points de Vente (TPV)
◙ Modéliser les ventes au niveau des TPV
◙ Etape 1 : Le premier modèle dimensionnel
◙ Doit répondre aux questions les plus pressantes de l’utilisateur
◙ Ses données doivent être les plus faciles à extraire

◙  Quels produits se vendent dans quel magasin, à quel prix, quand, dans quelles
conditions de promotion?
Conception d’un Data Warehouse 138

Exemple : La Distribution

Business Intelligence
◙ Etape 2 :
◙ Quel niveau de détail doit être disponible dans le modèle?
◙ Principe: Obtenir un schéma basé sur les données les plus atomiques

◙  Donnée atomique : une ligne individuelle de transaction saisie sur un TPV pour
mieux anticiper les requêtes ad-hoc des utilisateurs
Conception d’un Data Warehouse 139

Exemple : La Distribution

Business Intelligence
◙ Etape 3 :
◙ Choix des dimensions
◙ Principe: l’énoncé précis du grain détermine les dimensions principales
◙ Les dimensions supplémentaires qui peuvent être ajoutées doivent prendre une valeur
unique pour chaque combinaison de valeurs des dimensions principales
Faits de Transaction TPV Magasin

◙ Dimensions principales Date Clé magasin

Clé date Attributs
◙ Temps Clé Date Clé Produit
Attributs
◙ Produit Clé Magasin Promotion
Produit Clé Promotion
◙ Magasin
… Clé Promo
◙ Promotion Clé Produit Attributs
Attributs
Conception d’un Data Warehouse 140

Exemple : La Distribution

Business Intelligence
Produit
◙ Etape 3 (Suite):
◙ Dimension Produit
Clé Produit
◙ Attributs obtenus à partir du fichier Produits de l’application Description produit
opérationnelle Description marque
Description catégorie
Description type emballage
Taille emballage
Poids
Unité de mesure du poids
Type de stockage
Type de durée rayon
Largeur sur étagère
Hauteur sur étagère
Profondeur sur étagère
…
Conception d’un Data Warehouse 141

Exemple : La Distribution

Business Intelligence
◙ Etape 4 : Identifier les faits
◙ Quantité vendue, montant de la vente en euros, coût standard en euro
◙ Questions: stocker le bénéfice? La marge brute?
◙ Principe: pourcentage et ratios sont non-additifs  Ne pas les stocker, mais stocker le numérateur et dénominateur
Faits de Transaction TPV Magasin

Date Clé magasin

Clé date
Attributs
Clé Date Clé Produit
Attributs Clé Magasin
Clé Promotion Promotion
Produit
Numéro de trans. TPV Clé Promo
Clé Produit Quantité vendue Attributs
Attributs Montant des ventes
Coût
Bénéfice Brut
DATA SOURCES

E.T.L

DataWareHouse
Extraction
DataMart 1 DataMart2

Transformation
Référentiel
Data

Chargement