BI102

Conception et mise en oeuvre d'un
Data Warehouse
Philippe Aubert
phaubert.conseil@gmail.com
Sommaire
• Introduction et définitions
• L’approche Data Warehouse
• La démarche de mise en œuvre
• La modélisation dimensionnelle
• Cubes et agrégats
• Les optimisations physiques
• L’Architecture technique
• Les applications utilisateur
• Le Data Mining
• Synthèse
2
Introduction
• Informatique décisionnelle / Business Intelligence

 Besoin des entreprises
 accéder à toutes les données de l’entreprise
 regrouper les informations disséminées
 analyser et prendre des décisions rapidement
 Exemples d'applications concernées

 Grande distribution : marketing, maintenance, ...
• produits à succès, modes, habitudes d’achat
• préférences par secteurs géographiques
 Bancaire : suivi des clients, gestion de portefeuilles
• mailing ciblés pour le marketing
 Télécommunications : pannes, fraudes, mobiles, ...
• classification des clients, détection fraudes, fuites de clients
Introduction et définitions
3
Définitions
Datawarehouse
Système de Pilotage et
(Système d’Information Décisionnel - SID) OLAP Datamarts
Système d’Information Opérationnel - SIO

OLTP
Bases de données
de production
Système Opérant
4
Définitions
• Constat
 Les SI opérationnels sont déjà très sollicités
 Impossibilité de configurer un même système pour les
deux types de besoins :
Mode d’accès
Opérationnel Décisionnel
Type d’accès Lecture / Écriture Lecture simple

Structure des Complexe Simple
données
Nature des Non agrégées Agrégées ET détaillées
données
Requêtes Simples / Complexes / Peu
Nombreuses nombreuses
Volumes Faibles Importants
5
Définitions
• Data Warehouse (Entrepôt de données)
 Ensemble de données historisées variant dans le

temps, organisé par sujets, consolidé dans une
base de données unique, géré dans un
environnement de stockage particulier, aidant à la
prise de décision dans l’entreprise.
• Data Mart (Magasin de données)
 Entrepôt de données spécialisé pour un métier ou

un sujet donné : propre à un domaine fonctionnel.
 En aval du Data Warehouse ou… en amont.
6
Définitions
• OLTP : On Line Transaction Processing
 Techniquement associé aux SGBD Relationnels du marché :

Oracle, DB2, Sybase, SQL Server, PostgreSQL, MySQL,
etc.
• OLAP : On Line Analytical Processing
 Est plus un concept qu’une technologie.

 Une application décisionnelle peut s’appuyer sur technologie
relationnelle classique ou dédiée
(x-OLAP : Molap, Rolap, Dolap, Holap, WebOlap)
7
Sommaire
• Le Data Mining
• Synthèse
8
Générations des Systèmes Décisionnels
70’s
• Infocentre de
production
• Reporting
Mainframe
9
L’approche Infocentre de Production (ou
Centralisé)
Système Informatique de Gestion

Traitements
Aide à la
Infocentre
Décision
Données
Saisies et mises à jour des données

10
80 - 95’s
• Infocentre
relationnel
• Données de
production
70’s dupliquées dans
• Infocentre de une base dédiée
production
• Requêteurs Client-
• Reporting Serveur
Mainframe
11
L'approche Infocentre relationnel
Gestion Infocentre
Extraction Report OLAP
Traitements Activités
Sites Query Mining
Clients
Décisions
Données métier
Données
Administration des données

12
95 - 00’s
• Data
warehousing de
première
80 - 95’s génération
• Infocentre • Structuration
relationnel logique &
physique des
• Données de données
production
70’s dupliquées dans • Réflexion sur les
• Infocentre de une base dédiée méta-données &
production la sémantique
Mainframe
13
L'approche Data Warehouse
Collecte Intégration Distribution Présentation

DSA / ODS Report OLAP
Modélisatio
Transformation n
TEMPS Query Mining
Traitements Clients
Produits
Informations
Sites
Décisionnelles
Objets métier Décisions
Données Administration du référentiel

14
Aujourd’hui
• Data
95 - 00’s warehousing de
seconde
• Data génération
warehousing de
première • Système
80 - 95’s génération d’information
décisionnel
• Infocentre • Structuration d’entreprise
relationnel logique &
physique des • Référentiels
• Données de données d’entreprise
production
70’s dupliquées dans • Réflexion sur les • Business
• Infocentre de une base dédiée méta-données & Intelligence
production la sémantique Collaborative
Mainframe
15
Le système décisionnel au cœur du SI de
l’entreprise
Opérateurs Données SYSTÈME D’INFORMATION DECISIONNEL Front-Office (CRM)

Externes
Sales Force
Données
Automation
Institutionnelles
Gestion Réseau
Données Distribution
Métier
DATA
WAREHOUSE Outils Gestion
Back-Office Campagnes Mkg
E.R.P. Gestion Service

Finance, RH, Paie, Clients & Call Center
Logistique, etc.
Web & e-CRM
Applications Métier
Gestion Production, Gestion
Spécifiques Tableaux Exploration Reporting Requêtes Data
Collaboration
de bord multidim. ad hoc mining
Réf. Produits Réf. Réseaux Réf. Employés Réf. Tiers
16
Générations d’outils
Aujourd’hui
95 - 00’s
80 - 95’s
70’s
17
Architecture décisionnelle & Processus d’alimentation
Collecte des données Transformation Alimentation Restitution / Analyse
Gestion
Commerciale Datamart Requêtes ad hoc
Commerce
Comptabilité
Reporting
Datamart
Finance
Production DATA
WAREHOUSE
Tableaux de bord
Cube
Logistique Logs & Ctrl
Rejets Gestion
Exploration multidim.
SIRH Simulation
Datamart
Flux Marketing Data mining
Externe
Méta-Données
18
Administrateur Administrateur
Etats de Contrôles Reporting Qualité
Technique technico-fonctionnels Contrôle des Données Fonctionnel 18
DSA & ODS : Définition
• Data Stage Area (DSA – Espace de • Operational Data Store (ODS -

transit) : Espace de Transformation) :
 Espace dans lequel on stocke les  Espace dans lequel les données
données collectées dans les systèmes collectées dans le DSA sont
amonts. retravaillées afin de préparer leur
 Ensemble de table de la base de intégration dans le Data Warehouse.
données dont la structure est fidèle au  Les transformations opérées sont :
format des flux reçus.  Redressement de données
 Il est possible de conserver les flux  Transcodification
transitant pendant sur plusieurs mois  Réconciliation de flux
(pour reprise ou audit).  Agrégation
 Aucune transformation significative de  Complément de données
données n’est faite dans cet espace. manquantes
 Enrichissement
 A priori, les utilisateurs n’accèdent pas
 Etc.
directement au DSA.
 Cet espace contient
 Les tables nécessaires aux
différentes étapes de la préparation
des données
 Les tables de paramètrage
 Les tables de logs et rejets
 L’utilisateur final peut être amené à
consulter les logs fonctionnels ou
retraiter les rejets.
DATA
WAREHOUSE
19
Infocentre, Data Warehouse et Data Web
Infocentre Data Warehouse Data Web

• Projets tactiques • Projet stratégique • Projet d'entreprise
• Richesse fonctionnelle • Simplicité d'utilisation • Utilisation universelle
• Utilisateurs spécialisés • Utilisateurs banalisés • Déploiement globale
• Fonctions manquantes • Métadonnées élaborées • Données d'entreprise
du système de gestion • Plusieurs outils • Une seule interface
L’approche Data Warehouse 20

Aide à la décision : gestion de flux globale
• Les flux de collecte Gestion

Ajustement des paramètres de gestion
» Données de gestion ERP

» Données de gestion internes
» Données de gestion externes
» Intégration des métadonnées Information
• Les flux d'intégration
» Extraction des données de gestion
» Transformation en objets de métier
» Chargement des données décisionnelles
» Enrichissement des métadonnées
• Les flux de distribution Décision

» Distribution des informations
» Diffusion des métadonnées
» Gestion des accès utilisateurs
» Ajustement des paramètres de gestion Action
Les notions fondamentales
Données Les données du data warehouse sont
internes
• Orientées sujet
Data Warehouse
• Intégrées
• Non-volatiles
• Agrégées en
fonction du
Données temps
externes • Documentées

Données orientées sujet
• Le focus du système décisionnel change
• Les systèmes décisionnels existants sont
 Tactiques
 Elaborés autour des applications de production
• Le data warehousing est
 Une informatique décisionnelle d’entreprise
 Centré sur des préoccupations stratégiques
 Connaissance du client
 Maîtrise des coûts, des frais généraux
 Gestion des stocks
 ...

Données intégrées
• Les données proviennent des bases de

production
• Elles ne sont pas structurées à l'identique
• Elles doivent être rendues cohérentes
• Chaque donnée doit avoir
une seule description et un seul codage
 Il n’y a pas de vérité unique
 Des choix fonctionnels doivent être pris
 Un objectif : favoriser la communication

Données non-volatiles
• Les données sont datées
• Pas "d'annule et remplace"
• Historique des événements
 On conserve des données détaillées
avec un historique de plusieurs années
 Objectif : analyser les tendances
• Historique des «entités» majeures (client,
produit...)
 La nouvelle valeur d’une donnée
fait passer l'ancienne en historique
 Objectif : analyser à périmètre
fonctionnel stable
Données agrégées en fonction du temps
• Les données récentes

 Sont disponibles en ligne
 Sont détaillées au niveau le plus fin
 Concernent des utilisateurs experts et peu
nombreux
• Les données anciennes
 Ne sont plus forcément disponibles en ligne au
niveau de détail le plus fin, mais néanmoins
archivées
 Sont disponibles en ligne consolidées, agrégées
 Concernent la plupart des utilisateurs
Données documentées : Les métadonnées
• Le constat fonctionnel
 La donnée n’a pas de sens en elle-même
 La donnée est sujette à interprétation
• Le métadictionnaire
 Constitue le support de la démarche sémantique
 Vecteur de communication autour du data warehouse
 Documente le contenu du data warehouse
 Aide l’utilisateur dans la conception et la diffusion des
requêtes
 Evite l’interprétation
 Documente les flux d’alimentation
 Aide l’informaticien dans l’administration du data
warehouse
 Evite l’incohérence 27
L’approche Data Warehouse
Le modèle de données du Data Warehouse
• Performant pour
 pouvoir être accédé en temps réel
 optimiser son administration
• Intelligible pour
 rendre les utilisateurs autonomes
 faciliter son administration
• Evolutif pour
 intégrer les nouvelles demandes
 intégrer les nouvelles données
 intégrer de nouveaux domaines

Data Warehouse : signes distinctifs ...
• 4 grandes fonctions :
3. Administrer
1. Alimenter 4. Restituer
L’approche Data Warehouse 2. Fabriquer 29

• Un Data Warehouse est un "gros" projet :

 Par la volumétrie des données
 Par la puissance de traitement requise
 par la variété des besoins à couvrir
• Un projet de Data Warehouse né "gros" et se

trouve voué à grossir encore :
 en taille
 en fonctionnalités

• Exemple d'évolution :
 x 5 en 18 mois sur les données
 x10 en 2 ans sur les utilisateurs
 x n sur la CPU en 2 ans

Data Warehouse : conséquences pour réussir ...
• Concevoir et mettre en œuvre des solutions :

 évolutive,
 "scalable" (capable de croître par incréments successifs
sans remise en cause des ressources qui supportent la
solution : matériel et logiciel) :
 en volume de données
 en nombre d'utilisateurs
 en fonctionnalités

Les différents scénarios
Données de gestion
Transformation
Chargement
Extraction Data
Marts
Data Warehouse d'entreprise
Présentation
Distribution
Operational
COLLECTE
Intégration
Data Web
Data Store Data
Warehouse
Data
itératif
Marts
Tendances Data Warehouse
• Lotissement des gros projets

• Installation de serveurs décentralisés
• Montée en puissance de l’administration
• Intérêt croissant pour les notions de sécurité
• Apparition de modules décisionnels dans les
progiciels de gestion intégrés
• Emergence des suites décisionnelles
• Mariage du Web et du Data Warehouse
Source Data Warehousing Institute 34

Sommaire
• Le Data Mining
• Synthèse
35
Aborder l’analyse des besoins utilisateurs
• Reprise de l’existant et nouveaux besoins

 L’existant infocentre, un filon à ne pas sous-estimer
 La bureautique, une informatique décisionnelle pirate
• Approche pragmatique, orientée

(organisation des) informations
• Découpage des besoins utilisateurs

 Tableaux de bord
 Listes détaillées
 Ciblages, segmentations
 Analyses...
36
La démarche de mise en œuvre
Des besoins à la modélisation
Environnement Existant Nouveaux besoins Existant

Source Utilisateur Utilisateur Infocentre
Utilisation/Restitution
Indicateurs Axes d’analyse
des données
Modélisation Choix Technologiques
Choix d’architecture Requêteur

SGBDR / SGBDM Multidimensionnel
Suite décisionnelle Data Mining
BI Collabortatif Développement spécifique
37
Cycle de vie dimensionnel
Définition de Installation et
l’architecture sélection
technique des produits Maintenance
& Croissance
Conception
Planification Définitio Modélisation Conception du et dév.
du projet n des dimensionnelle modèle des Déploiement
besoins physique systèmes
ETL
Spécification de Développement
l’application de l’application
utilisateur utilisateur
Gestion du projet
38
Gestion et Planification du projet
• Définir le projet
• Evaluer votre aptitude au Data Warehouse
• Développer l’objectif préliminaire
• Elaborer la justification métier
• Planifier le projet
• Gérer le projet
• Développer le plan de communication
39
Définir le projet
• Origine de la demande?
 (Service) Utilisateur opérationnel isolé
 Pression des dirigeants pour obtenir une meilleure

information
 Pas de demande formulée…
40
Evaluer votre aptitude au Data Warehouse
5 critères :
• Trouver un sponsor / parrain au sein

de la Direction 60%
• Motivation de l’entreprise (stratégie) 15%
• Partenariat Informatique / Opérationnel 10%
• Culture analytique plutôt qu’intuition… 10%
• Faisabilité technique 15%
» D’après R. Kimball – Le Data Warehouse – Guide de conduite de Projet
41
Evaluer votre aptitude au Data Warehouse
Le cas échéant :
• Analyser en détail les besoins métier

• Hiérarchiser les besoins
• Apporter la preuve du concept (proof of
concept) par un démonstrateur
42
Développer l’objectif préliminaire
Définir le périmètre du projet
- Objectif significatif et maîtrisable

- De préférence issu d’un seul domaine source
- Nombre d’utilisateurs limité
Définir les critères de réussite
43
Elaborer la justification métier
Investissements & coûts financiers

 Licences logicielles & matérielles
 Maintenance
 Ressources internes et externes
 Formation
 Support
Retour sur investissement (quantitatif & qualitatif)

 Augmentation du CA, de la marge
 Amélioration du service client…
44
Planifier le projet
• Identifier le projet par un nom…
• Définir l’équipe de projet

 Direction : sponsors, chargés de projet, comité de pilotage
 Encadrement : Directeur de projet et chef de projet métier
 Equipe :
 Analyste fonctionnel
 Modélisateur de données
 Administrateur de bases de données
 Concepteur du système de préparation des données
 Développeur d’applications utilisateur
 Formateur
45
Planifier le projet
• Définir l’équipe de projet

 Equipe « spéciale »:
 Architecte technique et sécurité
 Experts techniques
 Gestionnaire du référentiel
 Responsable qualité
 Consultant(s) externe(s)
• Développer le planning du projet
 Ressources
 Tâches
 Délais
46
Planifier le projet
• Développer le plan de communication :

 Equipe de projet
 Sponsor et CP métier
 Utilisateurs
 Service Informatique
 Direction
47
Sommaire
• Le Data Mining
• Synthèse
48
Les objectifs de la modélisation
• Le modèle de données doit être intelligible

 Pour offrir l’autonomie aux utilisateurs
 Pour en faciliter l’administration
• Les performances ne doivent pas être un
facteur bloquant
 Performances d’accès et d’administration
• Le modèle de données doit offrir des garanties
d’évolutivité
• La quadrature du cercle...
49
La modélisation dimensionnelle
Modèle relationnel normalisé et Data Warehouse
• Un modèle pour le monde OLTP

 Suppression les incohérences et redondances
 Respect des Formes Normales
 La dénormalisation reste l’exception
• Les inconvénients
 Difficulté de navigation
 Informations noyées dans la masse
 Entités ne correspondant pas aux centres d’intérêt
 Résultats différents selon le chemin choisi
 Performances
 Jointures multiples
 L’accès à la colonne impose l’accès au «tuple»
 Le temps n’est pas pris en compte
 le modèle opérationnel gère l’état présent, rarement un
historique
 dès que les données évoluent dans le temps, les résultats
des requêtes sont non reproductibles
50
Modèle relationnel normalisé
 Basé sur la notion de Dépendance Fonctionnelle

(DF)
Rappel
Soit une relation R (x, y, z, …) : x  y

x détermine y ou y dépend fonctionnellement de x si la
connaissance d’une valeur de x détermine au plus une
valeur de y.
Exemple :
matricule  Nom Employé Nom Employé  matricule
matricule  Nom Service Nom Employé  Code Service
matricule  Code Service
Code Service  Nom Service
51
 Formes Normales (Normal Forms NF).
 1ère Forme Normale (1ère NF)
Une table est en 1ère NF si tous ses colonnes sont

atomiques.
Une colonne atomique contient une information
élémentaire ne pouvant être éclatée en plusieurs autres
colonnes.
 Exemple :
nom : colonne atomique
ville : colonne atomique résidence
adresse : colonne non atomique voie
décomposable en lieudit
code postal
localité
etc. 52
2ème Forme Normale (2nd NF)

Une table est en 2ème NF si :
- elle est en 1ère NF
- toute attribut non clé dépend de la clé entière et non d’une partie
seulement.
Exemple :
La table suivante T (a, b, c, d) contient les dépendances fonctionnelles
suivantes :
ab a, c  d
1) T est en 1ère NF.
53
b
a
c
d
La clé de T est : a, c
b dépend de la clé a, c mais aussi de a seul donc T n’est pas en

2nd NF.
54
3ème Forme Normale (3ème NF)

Une table T est en 3ème NF si :
- elle est en 2ème NF
- toute colonne non clé dépend uniquement de la clé et non d’une autre
colonne non clé.
Exemple :
T (a, b, c, d) contient les dépendances fonctionnelles suivantes :
ab ad bc
1) clé de T : a
2) T est en 2nde NF car a  b, c ,d
3) T (a, b, c, d) n’est pas en 3ème NF car b  c
55
56
• Dissocier technologie et modélisation

 Le modèle obtenu est indépendant des modèles
opérationnels existants et de leur technologie,
ainsi que de la technologie de SGBD cible
(OLTP ou OLAP)
• Structurer l’information pour permettre

son analyse naturelle
 Démarche intuitive de nombreux concepteurs de
bases de données (Group By à différents
niveaux d’agrégation à partir de données de
référence, en fonction des besoins utilisateurs)
57
• Décomposer une requête en paramètres

 Des indicateurs généralement numériques et
additifs
 Des axes d’analyse ou dimensions, points
d’entrée de l’entrepôt de données
 Une population
• Permettre la modification interactive de
ces paramètres
58
• Exemple : suivi d ’activité par région sur

plusieurs années
Dimension Temps Indicateurs
Année N Année N-1 Année N Année N-1 Année N

Nombre Nombre Nombre Nombre Objectif
clients clients clients actifs clients actifs région
Société Région A 10 8 6 5 50%
Région B 35 33 30 25 75%
Région C 25 12 15 10 60%
Valeurs des
Dimension Structure indicateurs
Géographique
Valeur des faits
59
• Les dimensions sont les axes d’analyse ou

critères métier permettant d ’analyser
l’information
 exemple : secteur géographique , temps , client
• Les indicateurs sont des variables de mesure

des performances métier, sur lesquelles
s’appuie l’analyse de l’information.
 Ils sont calculés à partir des données des systèmes
opérationnels
 exemple : nombre de clients actifs par région et par an
• La qualité d’un système décisionnel tient au

choix de ses indicateurs
60
Indicateurs
• Un indicateur ou fait est une observation

• Généralement un fait est numérique, il correspond à une
grandeur mesurable
• Les faits les plus intéressants sont additifs

 Faits additifs : chiffre d’affaire, nombre de clients actifs
 Faits non additifs : taux de retour
• Les faits sont toujours reliés à des dimensions

 Exemple : chiffre d’affaire par région et par an
• Les faits sont regroupés par « domaine métier » dans des

structures
 Exemple : ventes, ouvertures de comptes
61
Schéma en étoile (star schema)
• Une table de faits encadrées par N tables de dimensions
Produits
IDprod
Periodes Table de faits “ventes” description
couleur
IDper taille
année IDper
fournisseur
trimestre IDprod
mois Magasins
IDmag
jour
IDmag
unités_vendues nom
montant_ventes ville
département
taxes_ventes pays
62
Schéma en étoile (star schema) : terminologie
• Table de faits :
 Recèle les valeurs des indicateurs analysés selon les

dimensions reliées à la table de faits,
 ces valeurs sont numériques, continues, généralement
additives
 en théorie ne sont conservées que les données de détail
 Structure normalisée (3ème NF) composée de 2 types de
données : clés étrangères (Foreign keys) et indicateurs
63
Schéma en étoile (star schema) : terminologie
• Table de dimension :
 fournit le cadre de référence pour l'analyse des indicateurs
stockés dans les tables de fait
 recèle des données discrètes, le plus généralement alpha-
numériques,
 Enrichies par des propriétés descriptives, exemple :
couleur pour un produit
 Structure dénormalisée (2ème forme normale)
= axe d'analyse potentiel

64
Les hiérarchies dimensionnelles
• Les hiérarchies représentent, pour l’utilisateur, des

chemins de consolidation d’indicateurs
• Par exemple, dans le calendrier, on peut grouper des

jours en semaines, en mois, mais chacun de ces points
de groupement est situé sur une voie hiérarchique
distincte
• Leurs rôles :
 fournir grâce aux hiérarchies dont ils sont porteurs des règles de calcul
d'agrégats
 fournir pour l'analyse les cheminements dans l'information de la
synthèse vers le détail (zoom avant / arrière)
65
Modélisation Dimensionnelle
• Un seul schéma entité / relation se

décompose en plusieurs tables de faits
• Chaque schéma dimensionnel correspond

à un processus métier
• Une dimension commune à différents

schémas est dite conforme
 par exemple : l ’axe Temps
66
Axe Temps
• Le système opérationnel se contente d’enregistrer des

dates d’événements
• En décisionnel, l ’axe Temps est essentiel
• L ’axe Temps se représente en général par une hiérarchie

dénormalisée
• Choisir la granularité : jour / semaine
• Inclure le nom des jours, le quantième, un indicateur jour

ouvrable …
67
Axe Temps
• Il peut contenir les données :

 Date complète
 Jour semaine
 N° jour dans mois
 N° jour dans année
 N° semaine dans année
 Mois
 Saison
 Trimestre
 Période Fiscale
 Indicateur Jour ouvrable
 Indicateur dernier jour du mois ….
68
Principe d’un modèle dimensionnel
Dimension conforme
Dimension 4
Dimension 1 Dimension 5
Faits 1 Faits 2
Dimension 2
Dimension 3 Dimension 6
Dimension conforme
69
Modèle en étoile
• Modélisation étoile (star model)

 création d’une seule entité par dimension,
condensant toute l’information de la dimension
• Avantages
 Peu de tables à gérer
 moins de jointures lors des requêtes
 simplification des relations
70
Modèle en étoile
Dimension Produit
Produit (CP)
Dimension Temps Libellé
Stock
Heure (CP)
Gamme
Date
Dimension
Jour Semaine
N° Semaine Table des faits ventes
Mois Dimension Client
Heure (CE)
Produit (CE) Client (CP)
Dimension Magasin Nom
Magasin (CE)
Magasin (CP) Adresse
Client (CE)
N° Magasin Profil
Employé (CE)
Enseigne Age
Promotion (CE)
Département
Montant ventes
Pays Dimension Promotion
Nbre Unités vendues
Dimension Employé Coût Promotion (CP)
Employé (CP) Libellé Promotion
Matricule Type Promotion
Nom Date début validité
Fonction Date fin validité
Service
71
Modèle en flocon
• Modélisation en flocon (snowflake model)

 création d’une entité distincte pour chaque
élément d’une dimension, avec ses propriétés
propres
 utilisation d’une clé unique par entité et de clés
externes pour la description des hiérarchies
• Avantages
 bonne visibilité des hiérarchies, meilleure
compréhension
 alimentation facilitée (un flux = une entité)
72
Modèle en flocon & Hiérarchies
Dimension Produit
Produit (CP)
Dimension Temps Libellé
Stock
Heure (CP)
Gamme
Date
Dimension
Jour Semaine
Mois Dimension Client
Heure (CE)
Dimension Magasin Nom
Magasin (CE)
Magasin (CP) Adresse
Client (CE)
N° Magasin Profil
Employé (CE)
Enseigne Age
Promotion (CE)
Département
Montant ventes
Pays Dimension Promotion
Nbre Unités vendues
Dimension Employé Coût Promotion (CP)
Employé (CP) Libellé Promotion
Matricule Type Promotion
Nom Date début validité
Fonction Date fin validité
Service
73
Modèle en flocon & Hiérarchies Gamme (CP)
Libl gamme
Dimension Produit
Dimension Temps Produit (CP)

Libellé
Mois (CP) Heure (CP) Stock
Libl mois Date Dimension
Jour Semaine
Dimension Client
Heure (CE)
Pays (CP) Nom
Magasin (CE)
Libl pays Adresse
Dpt (CP) Client (CE)
Libl dpt Employé (CE) Profil
Promotion (CE) Age
Dimension Magasin
Magasin (CP) Montant ventes
N° Magasin Nbre Unités vendues
Enseigne (CP) Coût Dimension Promotion
Libl enseigne
Promotion (CP)
Libellé Promotion
Employé (CP)
Type Promotion
Matricule
Date début validité
Nom
Date fin validité
Fonction
Service
74
Flocon ou Étoile ? (1/3)
• Les + d’un modèle en étoile :

 Performances : peu de jointures, gestion
transparente des données creuses
 Facilité de compréhension : peu de tables à gérer
 Évolutivité dans la structure des dimensions :
facilité de mise en œuvre d ’un nouveau concept
dans la dimension
• Les - d’un modèle en étoile :

 Redondances dans les tables de dimension
 Plus de volume
75
• Les + d’un modèle en flocon :

 Gain de volume
 Minimisation du nombre de lignes impliquées dans les
jointures
 Meilleure compréhension des hiérarchies des
dimensions
 Facilité d ’alimentation : souvent, une entité = un flux
source
• Les - d’un modèle en flocon :

 Présentation des informations plus complexes
 Plus de jointures : navigation ralentie
76
• Une solution mixte :

 Ne pas appliquer systématiquement le
« floconnage »
 Appliquer la solution la plus adaptée à chaque
dimension en se posant les questions :
 des volumes
 des flux d ’alimentation
 de la navigation parmi les attributs
• Exemple de solution : Modèle en flocon,

avec mise en place de dénormalisations
au niveau du MLD
77
Modèle dimensionnel dénormalisé
78
Avantages et inconvénients du modèle décisionnel
• Avantages :
 Donne une vision métier de l’information (1 fait = 1

processus)
 Facilité de navigation
 Performances (Limitation du nombre de jointures)
 Même si l’ensemble des modèles en étoile est
complexe, le traitement des requêtes est
prévisible
 Gestion aisée des agrégats
 Fiabilité des résultats
 Modification aisée (nouveaux faits, dimensions)
79
Avantages et inconvénients
• Inconvénients :
 Redondances dans les tables de dimensions

 Procédures d’alimentation complexes
 Ne résout pas le problème des « non faits »
(clients sans commandes, factures sans
règlement, etc.)
 Multiplicité des schémas (tables de faits)
80
Règles de modélisation (selon Jean-Marie Gouarné)
• Règle 1 : Il ne doit pas y avoir de dépendance fonctionnelle

entre 2 entités appartenant à des dimensions différentes
d’un même modèle
• Règle 2 : Tous les faits d’un modèle doivent être définis de

manière cohérente pour toutes les combinaisons
dimensionnelles de ce modèle
• Règle 3 : Tous les faits d’un modèle doivent être définis

pour la granularité de ce modèle
• Règle 4 : Le graphe de chaque dimension d’un modèle doit

être acyclique
81

• Exemple :
Produit
Pays Région Ville CA
Date
DF
Client
82

• Solution :
Produit
Pays Région Ville Client CA
Date
83
• Règle 2 : Tous les faits d’un modèle doivent être définis de

manière cohérente pour toutes les combinaisons
dimensionnelles de ce modèle
• Exemple :
Indicateur coût de Recherche et Développement.

 Compatible avec les dimensions temps et produit, mais pas avec
les dimensions magasin et client : Coût de R&D du magasin X en
janvier 2007?
 N’a pas de sens dans un modèle à vocation commerciale
84
• Règle 3 : Tous les faits d’un modèle doivent être définis

pour la granularité de ce modèle
Le grain est le niveau de détail le plus fin possible dans

chacune des dimensions du modèle.
Tout indicateur doit pouvoir être évalué à ce niveau.
• Exemple :
CA défini par jour, produit et client
Marge définie par mois et ville
 Incompatibilité
 Solution : mettre en œuvre un processus ETL permettant le calcul
de la marge au même niveau que le CA, ou séparer les indicateurs
en 2 tables de faits différentes
85

être acyclique
Division
commerciale
Agence Direction Régionale
Etablissement
• Problème : si une agence d’une division de la Direction

Régionale A est située dans un établissement de la
Direction Régionale B, résultats de requête différents!
86

être acyclique
Solution
Direction
Division
Commerciale
commerciale
Régionale
Agence
Direction
Etablissement Administrative
Régionale
87
Règles de définition des indicateurs
• L’additivité des indicateurs n’est pas une règle absolue
On distingue trois types :
Additifs : flux exprimés en montants absolus (chiffre d’affaires, quantité

produite, quantité vendue)
Semi-additifs : Situations en montants absolus (stock, etc.), additives

dans certaines dimensions mais rarement dans le temps (balance,
en-cours, surface de vente, etc.)
Non-additifs : Flux ou situations exprimés en montants relatifs, sous

forme de ratio ou variations (parts de marché, taux d’occupation,
indice des prix)
88
Règles complémentaires
• Importance du nommage des attributs

 Garant de la qualité du Data Warehouse
 Eviter les codes compris de quelques initiés seulement
 Noms littéraux (mots complets), descriptifs, complets … et sans
faute d’orthographe.
• Dimensions dégénérées
 Dimensions sans attributs ni hiérarchie, généralement importantes
dans le Système Opérationnel mais sans réel intérêt décisionnel :
Numéro de commande,Numéro de facture.
Elles peuvent être conservées dans les tables de faits, sans table
de dimension correspondante
89
Règles complémentaires
• Définition des clés

 Clés primaires : Ne pas utiliser les clés des systèmes de
production, mais générer des clés de substitution, strictement
anonymes (surrogate keys)
 Pemet de s’affranchir des contraintes opérationnelles
(changement de SIO, rotation des clés)
 Permet la gestion des clés nulles (« client inconnu » , « date
inconnue ») dans les dimensions
 Permet une gestion souple des dimensions changeantes
Une clé de type integer suffit à la majorité des besoins
 Clés étrangères : Déclaration des contraintes d’intégrité

référentielle facultative si le traitement de chargement des données
a pris en charge cette vérification
90
La dénormalisation
• Avantages de la normalisation ...

 suppression des redondances
 réduction des volumes
• … et inconvénients
 complexité de la navigation
91
La dénormalisation
• Se définit comme
 l’introduction de redondances pour faciliter les
requêtes et améliorer les performances
• S’applique :
 aux axes d ’analyse (dimensions)
 aux tables de faits
92
La dénormalisation :
Les axes d’analyse
• Dénormalisation des axes d’analyse

 Partition verticale des tables
 Dénormalisation par redondance des clés
 Dénormalisation par redondance de données
93
Exemple normalisé
Famille
Id Famille
Code Famille
Sous-Famille Nom Famille
Id Sous-famille
Code Sous-famille
Nom Sous-famille
Module Id Famille
Id Module
Code Module
Nom Module
Produit Id Sous-famille
Id Produit
Code Produit
Nom Produit
Id Module
94
Dénormalisation par redondance des clés
Famille
Id Famille
Code Famille
Id Sous-famille
Code Sous-famille
Nom Sous-famille
Module Id Famille
Id Module
Code Module
Nom Module
Produit Id Sous-famille
Id famille
Id Produit
Code Produit
Nom Produit Dénormalisations par redondance des clés
Id Module
Id Sous-famille
Id Famille 95
Dénormalisation par redondance des données
Famille
Id Famille
Code Famille
Id Sous-famille
Code Sous-famille
Nom Sous-famille
Module Id Famille
Id Module Nom Famille
Produit
Code Module
Id Produit Nom Module
Code Produit Id Sous-famille
Nom Produit Id famille
Id Module Nom Famille
Id Sous-famille Nom Sous-famille
Id Famille
Nom Famille Dénormalisations par redondance de données
Nom Sous-Famille
96
Nom Module
Les tables de faits
• Partition verticale des tables

 Elle est utilisée quand une table comporte de
nombreuses colonnes et que l’on peut les séparer
selon leur usage.
• Fusion de plusieurs tables de faits

 Possible si les dimensions sont communes aux
deux tables de faits
97
les + et les -
• Avantages
 simplification des requêtes (moins de jointures)
• Inconvénients
 augmentation du volume
 propagation des changements d ’attributs
• Conclusion : trouver le bon compromis

 à réserver aux dimensions stables
 tenir compte des volumes
98
L’architecture en bus décisionnel
• Historiquement…
 Data Warehouse = ensemble des données de
détail
 Data Marts = sous-ensembles fortement agrégés,
constitués à partir de l’entrepôt
• Aujourd’hui…
 Construction de l’entrepôt de données étape par
étape, sous forme de datamarts successifs,
détaillés ou agrégés
 Évite la planification du data warehouse en une seule
opération, irréalisable dans la plupart des cas
 Contrainte importante pour la conception des
dimensions et faits communs à toute l’entreprise
99
• Attention
 La démarche itérative de constitution du data
warehouse ne doit pas faire l’impasse sur la
structure conceptuelle de l’entreprise
 Risque = data marts indépendants, ne pouvant
communiquer entre eux (Tuyau de poêle –
Stovepipes)
• Solution : le bus décisionnel
100
Achats
Inventaire magasin
Ventes Magasin
Date Produit Magasin Promotion Entrepôt Fournisseur Transporteur
101
• Dimension conforme
(conformed dimension)
 Dimension ayant la même signification dans tous

les domaines de l’entreprise, et donc dans les
tables de faits qui lui sont liées
 Leur définition est une tâche majeure de la conception du
Data Warehouse
 Décision politique nécessitant la validation de la
Direction Générale
 Exemples de dimensions conformes type :
 Produit, Client, Temps, Offre (Promotion)
102
• Fait conforme
 Même principe que pour les dimensions, même si

les tables de faits ne sont a priori pas partagées
entre les data marts de différents domaines
 Permet d’avoir une terminologie commune
 Exemples :
 Chiffre d’affaires, bénéfice, prix standard…
 En cas de désaccord,donner des noms différents :

CA facturé, CA encaissé, etc.
103
• Limites de la quête des dimensions

conformes…
 Groupe gérant plusieurs entreprises dans des
secteurs d’activité différents, avec des lignes de
produits différentes et/ou des clients différents
(particuliers, grosses entreprises)
Pas d’intérêt à définir :

 des dimensions conformes
 Un Data Warehouse?
104
Data Mart et niveau de détail
• Dimensions conformes :
 Niveau de détail atomique
 Permet une meilleure réactivité au changement
• Autres dimensions
 Agrégation moins problématique, mais détail
conseillé
• Faits
 Stockage sous forme dimensionnelle au niveau
atomique
 Mise à disposition en fonction des besoins
utilisateur (agrégat)
105
DIAGRAMME DE DETAIL DE LA DIMENSION TEMPS
Année fiscale Année calendaire
Trimestre fiscal Trimestre calendaire
Mois fiscal Mois calendaire
Semaine fiscale Semaine calendaire
Jour de la semaine
Granularité actuelle Jour
Granularité future possible Heure
DIAGRAMME DE DETAIL DE LA DIMENSION CLIENT
Pays
Attributs changeants
Département
Ville
Revenu moyen du foyer
Ménage
Date de naissance Statut familial
Sexe Client Niveau de formation
Sommaire
• Le Data Mining
• Synthèse
108
Rapports et modèle dimensionnel
en France
Années
sur 5 ans
Produits
Clients
Chiffres d'Affaires
et positions
le Top 10 % CA Total = 20/80 ?

109
Cubes et agrégats
Rapports et modèle dimensionnel
Critères Dimension 2
Dimension 3
Dimension 1
Indicateurs
Filtres Résultats
110
Cubes et agrégats
Vision multidimensionnelle : Cube de données
Date
NumFou 2002 350 600 300
2001 300 500 400
NumPro 2000 250 200 F2

F1
P1 P2 P3
111
Cubes et agrégats
Représentation d’un cube
112
Le data cube et les dimensions
Axe d'analyse: La géographie

(Pays - région - ville)
Variables analysées:
Nb unités, CA, marge...
Axe d'analyse: Les produits

(classe, produit)
Axes d'analyse: dimensions

Axe d'analyse: Le temps Variables analysées: indicateurs
(Année, trimestre, mois, semaine)
113
Cubes et agrégats
Exemple
• Montant des ventes fonction de (Mois, région, Produit)
Granularité des dimensions :
Type Région Année
Catégorie Pays Trimestre

Produit
Produit Ville Mois Semaine
Magasin Jour
Mois
114
Cubes et agrégats
La navigation multidimensionnelle
Projection en 2 dimensions Coupe d ’un cube

Produits Produits
pour une région donnée
CA CA
Région
Temps en semaines
Réduction selon 1 dimension
Produits Zoom selon une dimension
France
CA Est Sud Ouest
Temps en mois Lyon Marseille Nice

115
Cubes et agrégats
Opérations d’analyse multidimensionnelle
• Drill up / Drill Down : désigne la faculté d’aller du niveau global vers le niveau
détaillé, et inversement.
Drill Up 2005 2006 2007

Equipement
800 1200 1800
Drill Down ménager Dimension Temps
1S05 2S05 1S06 2S06 1S07 2S07

2005-2007 2005 2006 2007
Téléviseur 300 200 400 500 600 500
Téléviseur 2500 Téléviseur 500 900 1100
Réfrigérateur 1300 Réfrigérateur 300 300 700 Réfrigérateur 100 200 100 200 300 400
Dimension Produit
2005 2006 2007 Drill Up

Téléviseur 500 900 1100
Micro-onde 100 200 300
…… …… …… ……
300 300 700 Drill Up
Réfrigérateur
2005 2006 2007 2005 2006 2007

Téléviseur 500 900 1100 France 300 600 800
Réfrigérateur 300 300 700 Chine 250 200 900
• Rotate : désigne la rotation du tableau d’analyse croisée en remplaçant une

dimension par une autre
116
Opérations d’analyse multidimensionnelle (2)
• Slicing : désigne la possibilité de faire pivoter dynamiquement les axes du

tableau d’analyse croisée et en fixant la valeur d’un axe afin de se focaliser sur
une vue cernée (la tranche).
2005 2006 2007 2007
Téléviseur France 10 50 70 Téléviseur France 70
Réfrigérateur France 30 50 60 Réfrigérateur France 60
Téléviseur Chine 40 100 120 Téléviseur Chine 120
Réfrigérateur Chine 50 70 65 Réfrigérateur Chine 65
2005 2006 2007 2007

Téléviseur France 10 50 70 Téléviseur France 70
Réfrigérateur France 30 50 60 Réfrigérateur France 60
Téléviseur Chine 40 100 120
Réfrigérateur Chine 50 70 65
• Scope : désigne la possibilité de fixer les valeurs de plusieurs axes d’analyse

afin de se focaliser sur une vue cernée (carotte, cellule ou dé).
117
L'algèbre des cubes
• Remonter (Roll up, Drill Up) :

 Agréger selon une dimension
 Semaine  Mois
• Forer (Drill down) :
 Détailler selon une dimension (descente dans la hiérarchie)
 Mois  Semaine
• Slice et Dice:
 Sélection et projection selon 1 axe
 Mois = 04-2006 ; Projeter(Région, Produit)
• Pivoter (pivot/swap) :
 Tourne le cube pour visualiser une autre face (changement de
dimension)
 (Région,Produit)(Région, Mois)
• Forer latéralement (drill-across) :
 Permet de passer d’une mesure à l’autre. Ex. visualiser la quantité
vendue au lieu du chiffre d’affaires
118
Cubes et agrégats
Les vues d'un cube
• Partant d'un cube 3D, il est possible d'agréger selon une

dimension tournante
• On obtient un treillis de vues (calculable en SQL)
NumPro, NumFou, Date
NumPro, NumFouNumPro, DateNumFou, Date
NumPro NumFou Date
119
Cubes et agrégats
Extension de SQL
• ROLLUP: • CUBE:
 SELECT <column list>  SELECT <column list>
 FROM <table…>  FROM <table…>
 GROUP BY
 GROUP BY
ROLLUP(column_list);
CUBE(column_list);
• Crée des agrégats à
n+1 niveaux, n étant le • Crée 2n combinaisons
nombre de colonnes d'agrégats, n étant le
de groupage nombre de colonnes
 n, n-1, n-2,…0 colonnes de groupage
120
Cubes et agrégats
Exemple CUBE
Animal Lieu Quantite Animal Lieu Quantite

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

Chien Paris 12 Chat Paris 18
Chat Paris 18 Chat Naples 9
Tortue Rome 4
Chat - 27
Chien Rome 14
Chat Naples 9
Chien Paris 12
Chien Naples 5 Chien Naples 5
Tortue Naples 1 Chien Rome 14
Chien - 31
• SELECT Animal, Lieu, Tortue Naples 1
SUM(Quantite) as Quantite Tortue Rome 4
FROM Animaux Tortue - 5
GROUP BY Animal,Magasin - - 63
WITH ROLLUP
122
Cubes et agrégats
La navigation dans les dimensions
Région
Concession
Année
Vendeur
Marque
Mois
Modèle
Jour
Journées Véhicule
de ventes
123
Cubes et agrégats
La navigation dans les dimensions
Région
Concession
Année
Vendeur
Marque
Mois
Modèle
Ventes mensuelles
Jour des Concessions
par Modèle Véhicule
124
Cubes et agrégats
Les 12 règles multidimensionnelles OLAP
• Vue multidimensionnelle sur les données
• Transparence pour les utilisateurs, de l’hétérogénéité des sources de données
• Accessibilité
• Performances stables et indépendantes de la complexité dimensionnelle des
contextes d’analyse
• Architecture Client-Serveur
• Traitement générique des dimensions, c’est-à-dire possibilité d’effectuer le
même type d’opération sur toutes les dimensions
• Gestion dynamique efficace des matrices creuses, c’est-à-dire aptitude à ne
pas encombrer la mémoire de la machine avec les cellules correspondant à
des combinaisons dimensionnelles nulles
• Possibilité d’accès simultané à un même contexte d’analyse pour plusieurs
utilisateurs
• Possibilité d’effectuer, sans restriction technique, des calculs sur toutes les
combinaisons possibles de dimensions et de niveaux hiérarchiques
• Manipulation intuitive des données
• Flexibilité des restitutions
• Absence de limite a priori dans le nombre de dimensions et dans le nombre de
niveaux hiérarchiques par dimension 125
Les hiérarchies OLAP
Hiérarchie
Segmentations Total
G1 G2
L1 L2 Ln
P1 P2 Pn
S1 Sn
Axe d'analyse
P1 P2 Pn L1 Ln G1 G2 Total
segments
126
Cubes et agrégats
Les axes d’analyse OLAP...
Hyper-cube
Axe d'analyse
Valeur
S1 (S1,S2,S3)
S3 Axe
d'analyse
S2
Axe
d'analyse
127
Cubes et agrégats
Modèles star et snowflake : transposition du
modèle multidimensionnel
Dim 2
Indicateur
Dim 1
Faits
Dim 3
OLAP OLTP
128
Cubes et agrégats
Modèles star et snowflake : transposition du
modèle multidimensionnel
Axe 1
Hiérarchie 1
Axe 2
Gamme
Famille
Faits
Produit
Axe 1
Hiérarchie 1
Axe 3
Cubes et agrégats
OLAP OLTP 129
Mise en œuvre du modèle dimensionnel
• Un modèle dimensionnel peut être implémenté

de 2 manières :
• Technologie traditionnelle relationnelle, dite OLTP

(Oracle, SQL Server, Sybase (Sybase IQ),
PostgreSQL, MySQL, etc.) avec requêtes SQL ou
outil d’interrogation spécialisé
• Technologie matricielle OLAP (Essbase, Analysis

Services, Oracle OLAP)
130
Cubes et agrégats
Cubes OLAP
• Les cubes OLAP sont basés sur des données collectées et agrégées au sein
des entrepôts de données.
• La technologie OLAP utilise des algorithmes d’agrégation et de compression

des données dans le but de garantir toutes les combinaisons utiles au sein du
cube.
• Un cube est défini par un certain nombre de dimensions ou axes d’observation.

Au croisement de ces axes se trouvent des mesures ou indicateurs.
• Les utilisateurs accèdent aux cubes OLAP grâce à des outils d’analyse offrant
ainsi la capacité de réaliser à la volée des tableaux de synthèse et rapports
graphiques.
• Une solution de type OLAP regroupe deux familles d’outils

 Les outils de conception / paramétrage destinés à la structuration des cubes (par un
administrateur ou une équipe de développement) : Alimentation du cube, définition des faits,
des dimensions et des hiérarchies
 Les outils d’exploration et restitution destinés aux utilisateurs finaux
131
La technologie matricielle : hypercube & OLAP
• Permet une vision des données sous la forme de

matrices (hypercubes) à deux ou plusieurs
dimensions.
• Manipulation intuitive
• Pas de jointure
• Traitements des agrégats transparent
132
Cubes et agrégats
Composantes OLAP
• L’architecture OLAP consiste en trois services :

Base de données :
 Doit supporter les données agrégées ou résumées
 Doit posséder une structure multidimensionnelle (SGDB
multidimensionnel ou relationnel)
Serveur OLAP :
 Gère la structure multidimensionnelle dans le SGBD
 Gère l’accès aux données de la part des usagers
Module client :
 Permet aux usagers de manipuler et d’explorer les données
 Affiche les données sous forme de graphiques statistiques et de
tableaux
• Selon le type de base de données accédé, plusieurs
configurations sont possibles : multidimensionnelle,
relationnelle ou hybride
133
Cubes et agrégats
MOLAP (OLAP Multidimensionnel)
• Les données détaillées de base ainsi que les

données agrégées de l’entrepôt sont stockées
dans une base de données multidimensionnelle
(souvent appelée cube ou hypercube)
• Une base de données multidimensionnelle
utilise une structure propriétaire au logiciel
utilisé ( matrice)
• Le serveur MOLAP extrait les données de
l’hypercube et les présente directement au
module client
134
Cubes et agrégats
MOLAP (OLAP Multidimensionnel)
Base de données Serveur MOLAP Client OLAP

multidimensionnelle
(hypercube)
135
Cubes et agrégats
ROLAP (OLAP Relationnel)
• Les données détaillées de base ainsi que les

données agrégées de l’entrepôt sont stockées
sous forme de tables dans une base de
données relationnelle
• La base de données relationnelle doit être
structurée selon un modèle particulier (étoile,
flocon, …)
• Le serveur extrait les données par des requêtes
SQL et interprète les données selon une vue
multidimensionnelle avant de les présenter au
module client
136
Cubes et agrégats
ROLAP (OLAP Relationnel)
Serveur ROLAP
Client OLAP
Base de données
relationnelle Vue
(étoile ou flocon) multidimensionnelle
137
Cubes et agrégats
HOLAP (OLAP Hybride)
• Architecture qui consiste en un croisement des

architectures MOLAP et ROLAP
• Les données détaillées de base de l’entrepôt
sont stockées dans une base de données
relationnelle et les données agrégées sont
stockées dans une base de données
multidimensionnelle
• Le serveur HOLAP accède deux bases de
données et les présente au module client, selon
une vue multidimensionnelle dans le cas des
données de la BD relationnelle
138
Cubes et agrégats
HOLAP (OLAP Hybride)
139
Cubes et agrégats
MOLAP vs ROLAP vs HOLAP
Critère de ROLAP MOLAP HOLAP

comparaison
Stockage des BD relationnelle BD BD relationnelle

multidimensionnelle
données de base
(détaillées)
Stockage des BD relationnelle BD BD

multidimensionnelle multidimensionnelle
agrégations
Performance des Le moins performant Le plus performant Performance moyenne
requêtes
(habituellement)
140
Cubes et agrégats
Moteur OLTP vs OLAP
OLTP OLAP
(On-line transaction processing) (On-line analytical processing)
 Outil de requête tributaire de la  Absence d’outil de requête i.e.
structure de données (un usager l’usager interagit directement avec
doit connaître la structure de la les données
base de données pour l’interroger
efficacement).
 Requêtes principalement du type
 Requêtes “non-agrégatives” i.e. “agrégatif” i.e. calculs de totaux,
visitent peu d’enregistrements, variance, maxima et minima, etc…
mais mettent à contribution les
techniques d’indexation pour
retourner un nombre relativement
restreint d’enregistrements
répondant à certains critères.
141
Cubes et agrégats
Moteurs OLAP
Editeur Moteur Remarque
Applix Inc Applix iTM1 La nouvelle référence MOLAP temps réel
Databeacon Analyse & Reporting Web Solution Web M-OLAP Java, Orienté PME-PMI
Oracle
(ex-Hyperion) Essbase Le moteur M-OLAP le plus répandu
Microsoft Analysis Services Fourni avec SQL Server depuis 1998
MicroStrategy MicroStrategy 7i moteur R-OLAP

La référence pour les très gros volumes de
NCR Corporation Teradata données
Oracle Corporation Oracle Option Oracle Olap depuis la version 9i
SAP BW décisionnel H-OLAP
142
Cubes et agrégats
Modèle décisionnel : problème ...
• La volumétrie de la table de fait : plusieurs

millions d'enregistrements
 Peu d'inconvénients a priori en accès grâce aux
techniques d'indexation, mais problématique en réalité
en raison de la fréquence des requêtes manipulant
des données de détail / des données agrégées
(GROUP BY)
 Difficultés d'exploitation et de structuration liées à la
concentration du volume
• D’où le besoin de production des agrégats ...
143
Cubes et agrégats
L’agrégation (1/4)
• La granularité d’un fait représente la précision

la plus fine ; elle se définit par référence aux
axes dimensionnels
 niveau unitaire : transaction, instantané quotidien
unitaire, ligne de commande, de facture
 niveau intermédiaire : ticket de caisse (n articles)
 niveau agrégé : montant des achats pour un rayon par
jour
• Il est essentiel de la définir dès le départ avec

l’utilisateur pour chaque table de faits
144
Modèles star et snowflake :
la production des agrégats ...
Gamme Groupe
Famille Fournisseur
Pays
Rayon
Région
Ventes
Produit
Département
Magasin
Niveau de détail conservé 145
Cubes et agrégats
Modèles star et snowflake :
la production des agrégats ...
Gamme Groupe
Famille Fournisseur
Pays
Rayon
Région
Ventes
Produit
Département
Magasin
Niveau de la demande utilisateur 146
Cubes et agrégats
Principe ...
Gamme Groupe
Famille Fournisseur
Pays
Rayon
Région
Ventes
Produit
Département
N tables de faits chacune constituant
un plancher à partir duquel peuvent Magasin
être produits des agrégats
147
Cubes et agrégats
Mise en œuvre ...
• La constitution des agrégats s'opère en 2 temps

2 - lecture et
production des
agrégats à partir de
Niveau à ce niveau plancher
constituer
dynamiquement
1 - identification de
la table de fait
"plancher" grâce à
Ventes un dictionnaire
148
Cubes et agrégats
• Construire des données agrégées à partir

des données de détail ...
 Évite l’accès systématique aux données de détail
 Principalement sur les tables lourdes
 Agréger à un niveau hiérarchique d ’une dimension
bénéficie à tous les niveaux supérieurs
 Permet d ’améliorer considérablement les
performances
 Attention à trouver le bon compromis entre
 l ’optimisation des performances,
 et le volume de stockage supplémentaire.
149
• Choisir les agrégats :

 Examiner les requêtes les plus courantes,
 Étudier les regroupements : quels sont les attributs
les plus couramment employés ?
 Considérer le nombre de valeurs que peuvent
prendre ces attributs
• Le choix des agrégats n’est pas définitif :

un agrégat peut être supprimé ou construit
par la suite.
150
• Où les positionner ?
 Dans les datamarts
 Dans l’entrepôt
 s’ils sont utiles dans plusieurs datamarts, compte tenu
du coût de fabrication et de maintenance
• Stabilité des agrégats

 Attention aux agrégats qui utilisent l’axe temps : le
résultat calculé au jour j peut s’avérer différent de celui
fait à j+n pour les mêmes axes
 annulations de commandes, retours
 des événements connus en retard
 Problématique des dimensions changeantes
151
Modéliser les agrégats…
• Connaître à l’avance les besoins des

utilisateurs
• S’appuyer sur
 Les hiérarchies dans les dimensions
 Les attributs de dimensions porteurs
• Dupliquer la table des faits
 Agrégations sur l’axe temporel
 Agrégations sur l’axe des dimensions
 Sélection des métriques
 Calculs de nouvelles métriques
• Dupliquer les dimensions
 Le modèle en flocon
152
Types d’agrégats
• Agrégat simple
 Exploite une hiérarchie dans une dimension
 Exploite isolément un attribut «porteur» d’une dimension
 Somme des données numériques
• Agrégat sur l’axe temps

 S'appuie sur un niveau de consolidation de l’axe temps
 Met en œuvre une fonction d’agrégation (moyenne,
comptage...)
• Agrégat complexe
 Recalcule les données semi additives
 Applique une règle de calcul «métier»
153
Modèle en flocon et agrégats
Version normalisée
VENTES
CALENDRIER JOURNALIERES STRUCTURE DE
Date du jour PAR GAMME GAMME
Année Date du jour Code Gamme
Mois Code Implantation Libellé gamme
Jour de la semaine Code Gamme
Quantité Vendue
Chiffre d’affaires
Marge
VENTES PRODUIT
JOURNALIERES Code Produit
Date du jour Code Gamme
IMPLANTATION
Code Implantation Nom Produit
Code Implantation
Code Produit Packaging
Code Région
Quantité Vendue Unité de prix
Date ouverture
Chiffre d’affaires Code chef de produit
Enseigne
Marge
Devise
VENTES
ANNUELLES
REGIONALES
REGION
PAR GAMME
Code Région
Année
Nom Région
Code Région
Code Gamme
Quantité Vendue
Marge
154
Modèle en flocon et agrégats
Version dénormalisée
VENTES
CALENDRIER JOURNALIERES STRUCTURE DE
Date du jour PAR GAMME GAMME
Année Date du jour Code Gamme
Mois Code Implantation Libellé gamme
Jour de la semaine Code Gamme
Quantité Vendue
Marge
VENTES PRODUIT
JOURNALIERES Code Produit
Date du jour Code Gamme
IMPLANTATION
Code Implantation Nom Produit
Code Implantation
Code Produit Packaging
Code Région
Quantité Vendue Unité de prix
Date ouverture
Chiffre d’affaires Code chef de produit
Enseigne
Marge
Devise
VENTES
ANNUELLES
REGIONALES
REGION
PAR GAMME
Code Région
Année
Nom Région
Code Région
Code Gamme
Quantité Vendue
Marge
155
Agrégats : Avantages / Inconvénients
• L‘avantage
 Gains de performances importants (sur les agrégats)
• Les inconvénients
 Assurer la transparence pour les outils clients
 Sélection dynamique et transparente de la table
d’agrégats
 Evolution de l’offre : Microstrategy, Sagent
 Nécessite un suivi strict de l’usage du data warehouse
 Impose des contraintes en termes d’administration
 Les données sont dupliquées
 Les procédures de chargement sont plus complexes
 Explosion de la volumétrie
156
Sommaire
• Le Data Mining
• Synthèse
157
Les optimisations physiques
• Gestion des index : B-tree classiques et

index bitmap
• Partitionnement des données, des index
lorsque c’est possible
• En règle générale, les règles classiques
d’optimisation d’une base de données
restent valables, mais leur importance est
accrue en raison du volume manipulé
158
Les index bitmap
• Les index bitmap

• Une technique d'index adaptée aux
requêtes décisionnelles portant sur des
éléments peu discriminants
• Rapport de performances (pour Sybase IQ)
 Jusqu’à 500 fois plus rapide
qu’un SGBD/R Unix classique (© Sybase)
 Jusqu’à 250 fois plus rapide
que DB2/MVS (© Sybase)
 Jusqu’à 1 000 fois plus rapide
(© Un prospect français)
159
Un principe : l’association des critères
Valeurs de la table Index Index Index

Sexe Marié Nbr enfants Sexe Marié Nbr Enfts
H F O N 1 2 3 4+
H O 0 1 0 1 0 0 0 0 0
F N 1 0 1 0 1 1 0 0 0
F O 2 0 1 1 0 0 1 0 0
H N 3 1 0 0 1 0 0 1 0
F O 4 0 1 1 0 0 0 0 1
H O 5 1 0 1 0 0 0 0 1
• Combien de femmes mariées avec 3

enfants ?
 Recherche dans l'index de la valeur : 0 1 1 0 0 0 1 0
160
Importance des index
• Approche ensembliste adaptée aux données

discrètes (nombre fini de valeurs)
 Sexe, secteur d’activité, Nb d’enfants, oui/non
• Adapté aux données
 Stables (temps de constitution de l'index)
 Au nombre de valeurs limitées (taille de l'index)
• Génération spécifique
 Mode annule et remplace
 Une table de bits par colonne indexée
 Les tables d’index restent en mémoire
• Transparence totale côté utilisateur
161
Autres éléments d’administration / optimisation
• Réorganisation périodique
• Mise en œuvre des contraintes d’intégrité

référentielle facultative
• Bonne gestion des index lors des phases

de chargement si gros volumes
(suppression / chargement des données /
re-création)
162
Sommaire
• Le Data Mining
• Synthèse
163
Data Warehouse : les structures de données ...
vues par l'utilisateur final
Niveau Niveau Data Niveau DataMart Niveau

source Warehouse restitution
OLAP
Utilisateur
OLTP
OLTP
L’Architecture technique 164

Data Warehouse : les structures de données ...
vues par le concepteur du SI

OLAP
Utilisateur
BASE
Méta données
META DONNEES un poste de pilotage au

L’Architecture technique cœur de la solution 165
Data Warehouse : les produits ...

• EIS
• TDB papier
• Query
OLAP • Investigation
OLAP
• Datamining
• Groupware
BASE
Méta données Utilisateur
• Outils de transformation et de réplication

L’Architecture technique
• Moteurs de stockage OLTP et OLAP
166
Alimentation du modèle en étoile
Processus de transformation
des événements et paramètres
Présentation des informations

de gestion en faits ou indicateurs
Calendrier
Collecte des données
Evénements
Gestion de gestion
Indicateurs
DSA
Paramètres A Temps
Info de gestion
Dimension Indicateurs
centre
A
B C
Dimension
Données de
Sources référence B
externes Dimension
C
Processus de transformation
des données de référence
en dimensions ou axes d'analyse

Alimentation et fabrication :
l'origine du problème ...
• Pour l'alimentation :
 les sources sont multiples (plusieurs dizaines) :
 internes
 externes
 les référentiels sont hétérogènes
 les sources ne sont pas synchrones
 les sources sont concurrentes en mise à jour (des règles
de priorités doivent être gérées)
 les règles de gestion sont multiples pour chaque flux
(contrôle, filtrage, formatage, calcul, ...)

l'origine du problème ...
• Pour la fabrication :
 les besoins en données de synthèse :
 agrégats de premier niveau (obtenus en exploitant les liens
hiérarchiques sur les axes d'analyse)
 formes de présentation dans le temps (flux, cumul, moyenne)
 agrégats de second niveau (obtenus par application d'une
formule de calcul)
 le volume des données stockées
 les traitements de diffusion des données

les pistes d'optimisation...
• Pour l'alimentation :
 la recherche d'une mutualisation des traitements communs
 exemple : les contrôles de nature référentielle
Données de référence "stables" valeurs de la période
Contrôles d'intégrité, Contrôles de

traduction, vraisemblance,
filtrage, formatage, conversion,
formatage calcul

les pistes d'optimisation...
• Pour la fabrication :
 la recherche d'une mutualisation des traitements
communs
 la recherche du stockage optimum par un choix judicieux
de répartition données / traitements
Je pré-calcule et stocke tous les agrégats
Choix de répartition données / traitements

Tendance
L’Architecture technique
Je ne stocke aucun agrégat 171
Restitution : l'origine du problème ...
• Les données à restituer à l'utilisateur sont

nombreuses et riches de contenu
• Certaines sont calculées à la volée
• Sans oublier de mettre en œuvre les règles de
confidentialité
Présentation
Donnée 5 Donnée 1
Calcul
Donnée 2
Lecture
Donnée 4
Donnée 3
Confidentialité
Donnée n
Restitution : les contraintes les plus fortes ...
• Sur la performance d'accès aux données :

 la volumétrie
 la modélisation retenue
• Sur les calculs à la volée : le choix de répartition
données / traitements
Présentation
Donnée 5 Donnée 1
Calcul
Donnée 2
Lecture
Donnée 4
Donnée 3
Confidentialité
Donnée n
Les modèles du Data Warehouse
Données Données
du système externes
d'information
Documentation fonctionnelle
Documentation technique
Modèle(s) de collecte
Modèle d'intégration
Modèle(s) de distribution
Modèle(s) de présentation

Les modèles de l’architecture
• Modèle de collecte : acquisition des données

• Modèle d’Intégration : BD relationnelle
normalisée, contenant les données issues des
SIO après transformation
• Modèle de Distribution (ou de Diffusion) : BD
dimensionnelle (Data Warehouse & Data Marts)
• Modèle de Présentation : masque recouvrant le
MD, en fonction des outils client (Ex : Univers BO)

Les différents scénarios
Données de gestion
Transformation
Chargement
Extraction Data
Marts
Data Warehouse d'entreprise
Présentation
Distribution
Operational
COLLECTE
Intégration
Data Web
Data Store Data
Warehouse
Data
itératif
Marts
Applications de gestion
Collecte des données
Zone de production
Intégration
Axes
d’analyse
de gestion
de gestion
Indicateurs
Paramètres
Schéma d’architecture général
Bases de données
Zone technique
Zone de référence
Distribution
Zone de Data Warehouse
Zone de chargement des données
Data Warehouse
Présentation des informations
Outils de restitution
177
La zone de chargement des données
(Data Staging Area – DSA)
• La zone de chargement des données est l’atelier du

Data Warehouse.
• Elle recoit l’ensemble des informations issues des

systèmes opérationnels
• Elle centralise les processus de transformation et de

chargement du Data Warehouse et des Data Marts
• C’est un environnement technique distinct du Data

Warehouse et des systèmes opérationnels
• Elle n’est pas interrogeable directement par les

utilisateurs finaux (sauf ODS)
La zone de chargement des données
(Data Staging Area – DSA)
• On peut distinguer 4 zones, plus ou moins

matérialisées
 Zone de production : contient l'ensemble des tables
permettant de charger le résultat des extractions. La
structure des tables est conforme à chacun des flux,
sauf si l'on souhaite tracer chacun des enregistrements
en entrée pour la gestion des rejets.
 zone de référence : contient les tables de nomenclature utilisées
lors des opérations de transformation lorsque les sources de
données sont multiples et hétérogènes.
 zone technique : lorsque la procédure d'alimentation est complexe,
permet d'isoler les tables de travail et d'administration (rejets et
journal).
 zone de Data Warehouse : permet un préchargement des données
dans des tables à l'image de celles du Data Warehouse
(dimensions, faits, agrégats).

L’Operational Data Store
• L’Operational Data Store (ODS) est une base

de données conçue pour centraliser les
données issues de sources hétérogènes afin
de faciliter les opérations d'analyse et de
reporting.
• A l’origine, base de données relationnelle

jouant le rôle de point d’intégration pour les
systèmes opérationnels.

Les outils de transformation de données ETL
Outils du marché :
indispensables sur de gros projets, ils assurent une
amélioration de la productivité à long terme, mais
nécessitent un temps de mise en œuvre et
d’apprentissage élevé
Fonctions :
1. Extraction
l Sources multiples
l Génération de code
l Types d’extraction multiples (chargements incrémentaux,
événements transactionnels, actualisation)
l Réplication
2. Transformation
l Intégration (clés de substitution, codes en libellés, etc.)
l Gestion des méta-données
l Maintenance de dimensions changeantes
l Intégrité référentielle
l Dénormalisation / renormalisation
l Nettoyage, déduplication, fusion et purge
l Conversion de types de données (EBCDIC – ASCII, dates,
etc.)
l Calcul, dérivation, affectation
l Création d’agrégats
l Contrôle du contenu des données
l Traçabilité
l Gestion des valeurs nulles
l Appel à des outils externes
3. Chargement
l Cibles multiples (data marts OLTP, OLAP)
l Gestion du processus et optimisation du chargement
• Services de contrôle des tâches de préparation

l Planification
l Surveillance
l Journalisation
l Gestion des anomalies (exceptions) : seuil de tolérance,
recyclage
l Gestion des erreurs (restauration)
l Notifications

Les outils d’ETL du marché
Produit Editeur Commentaires
Ab Initio Ab Initio Software Corporation
Advantage Data Transformer Computer Associates Issu du rachat de Platinum

Amadea ISoft Editeur français
Business Information Warehouse SAP
Data Flow Sagent Group 1 Software

Data Integrator Business Objects Issu du rachat d'Acta Works en 2002
DataStudio DATA
ETI Extract ETI
ETL Manager Information Builders
Hummingbird ETL Hummingbird Issu du rachat de Genio à Léonard Logics
Hyperion Hyperion Solutions
MyReport Report One
Pervasive Pervasive
PowerCenter ETL Manager Informatica

SAS9 SAS
SQL Server Integration Services (SSIS) Microsoft ETL intégré à SQL Server 2005 (successeur de DTS)
Oracle Data Integrator (ex Sunopsis) Oracle
Talend Open Studio talend open source
Transformation Server Data Mirror
Warehouse Builder Oracle Corporation
Websphere Datastage IBM Rachat d'Ascential en 2005

184
L’importance du rôle du « Data Manager »
• Profil clé :
 Compréhension globale du système décisionnel
 Connaissances métiers (sans être un expert !)
 Maîtrise des processus d’exploitation
• Rôle :
 Contrôler la qualité des flux échangés et des données
stockées dans l’entrepôt
 Identifier et diagnostiquer les incidents et les
problèmes
 Coordonner les actions correctrices
 Côté Exploitation
 Côté Etudes

La politique de sauvegarde
• Le système d’information décisionnel est une ressource clé

du SI de l’entreprise  il doit être intégré à la politique de
sauvegarde
• Contraintes :
 Volumes importants
 Disponibilité d’espace libre sur les supports de backup
 Disponibilité d’une fenêtre temporelle d’exploitation (le plus souvent la
nuit)
 Complexité particulière à gérer si les utilisateurs sont répartis sur
plusieurs fuseaux horaires.
• Il faut estimer le coût de l’intégration du SID dans la

politique de sauvegarde de l’entreprise
 Attention aux coûts marginaux

Reprise et continuité d’activité
• La plus part du temps, les système décisionnel ne

fait pas partie des applications critiques pour la
survie de l’entreprise suite à un désastre
majeur…
• … Mais les désastres majeurs sont rares et les
aléas quotidiens de l’exploitation n’en font pas
partie !
• Il est indispensable de garantir aux utilisateurs la

disponibilité des outils d’aide à la décision :
 Optimiser les processus d’alimentation (et donc la
modélisation) pour réduire le temps global de chargement.
Ceci permettra de pouvoir le rejouer facilement en cas de
problème.
 Favoriser la « reprise après incident » par des processus
d’alimentation atomiques et des mécanismes de rollback

Chargement incrémental & rollback :
T1 – Chargement flux « Tenue de Compte »
Collecte des données Transformation Alimentation / Distribution Restitution /

Analyse
Datamart
Engagement
Requêtes ad hoc
Infos Prêt
BusinessObjects
Datamart
Infos DATA Float
ODS
Tenue Cpte WAREHOUSE
Informations TC Datamart
Infos Client Tdb
Compta Excel
Méta-données
Administrateur Reporting Reporting Administrateur

Qualité « Technique » Qualité « Fonctionnel »
Technique Collecte de méta-données Fonctionnel
188
T2 – Chargement flux « Compta »

Analyse
Datamart
Engagement
Requêtes ad hoc
Infos Prêt
BusinessObjects
Datamart
Infos Tenue DATA Float
ODS Informations
Cpte WAREHOUSE
Comptables
Infos Client Tdb
Compta Excel
Méta-données

189
T3 – Chargement flux « Prêt »

Analyse
Datamart
Engagement
Requêtes ad hoc
Infos Prêt
BusinessObjects
Informations
Prêt Datamart
ODS Informations
Cpte WAREHOUSE
Comptables
Infos Client Tdb
Compta Excel
Méta-données

190
T4 – Rollback du chargement flux « Compta »

Analyse
Datamart
Engagement
Requêtes ad hoc
Infos Prêt
BusinessObjects
Informations
Prêt Datamart
DSA ODS
Cpte WAREHOUSE
Infos Client Tdb
Compta Excel
Méta-données

191
Méta-données : Définition
• Les Méta-données sont des données qui

décrivent l’Entrepôt lui-même
• Elles ont 4 rôles principaux :

 Dictionnaire des données,
 Qualimétrie,
 Administration
 Suivi des usages

Que contiennent les méta-données ?
• La définition sémantique (Dictionnaire) • Des informations sur l’alimentation du

 Documentation des informations de Data Warehouse et des Datamarts
l’entrepôt  Suivi et analyse des chargements
 Technique : tables sources, modes  Traitement des rejets
d’alimentation...
 Fonctionnel : définition des données...  Identification des anomalies et
 Dimensionnel : Axes et hiérarchies, faits... déclenchement des actions correctives
 Traçabilité des données  Ces données sont stockées dans l’entrepôt
 Sources des données
et sont consultables par tout type de reports.
 Règles de transformation
 La mise à jour du dictionnaire sémantique se
fait dans l’atelier de conception de l’entrepôt • Des indicateurs sur les usages faits du
(Ex : PowerAMC) système décisionnel
 Ce dictionnaire peut être mis à disposition  Suivi de l’utilisation fait du système à travers
sur un intranet ou accédé depuis l’outil de les outils de restitution (taux et fréquence
restitution. d’accès aux données)
 Ces données sont stockées dans l’entrepôt
• Des indicateurs sur la qualité des et sont consultables par tout type de reports.
données du système décisionnel
 Analyse des données chargées et
comparaison avec des normes
fonctionnelles
 Dénombrement « métier » des objets
contenus dans la base
 Ces données sont stockées dans l’entrepôt
et sont consultables par tout type de reports.
Méta-dictionnaire : Alimentation
Base
Modélisation
de Données
Dictionnaires Fonctionnel, Dictionnaire Technique
Dimensionnel, Technique Administration
Méta-
Dictionnaire
Outil Outil
d ’Alimentation de restitution
Dictionnaire Technique Suivi des usages
Administration 194
Méta-dictionnaire : Modèles
L ’interconnexion entre les modèles se fait par des tables communes
Base de Données Outil de Restitution

Tables Systèmes Tables Internes
Méta-Modèle
Modèle de données spécifique
ETL
Tables Internes Outil de Modélisation
Tables Internes
La production de la documentation se fait par un outil de restitution

Méta-dictionnaire : Plus-Values
• Plus-values pendant la mise en place, en

plus des plus-values liées aux fonctions
pendant l ’exploitation :
 Lors de la définition des besoins
 Production de documents sur les flux sources
 Lors du déploiement
 Production d ’une partie des spécifications
d ’alimentation : mapping des données sources /
données cibles
 Production de document de travail pour la validation
des modèles
 ….

Sommaire
• Le Data Mining
• Synthèse
197
Les applications utilisateur (Front room)
Nature de Type d’utilisateur Interface d’information Avantages

l’utilisation
Stratégique Utilisateurs Outils de développement Exemples et point de
chevronnés de requêtes personnalisées référence assurance qualité
Utilisateurs Applications Actualisation des documents

presse-bouton utilisateur
Utilisateurs Génération d’états

Opérationnel d’états opérationnels
standard
198
Les applications utilisateur
Les applications utilisateur (Front room)
• Rôle fondamental : EST la vision du

Data Warehouse pour l’entreprise
• Doit permettre de tirer partie du Data
Warehouse aussi bien pour les
utilisateurs non habitués aux outils
informatiques que pour les
utilisateurs chevronnés
(remplacement des développements
Excel, Access, etc….)
199
Implémentation
• Outil spécialisé C/S (BO, Cognos,

Reporting Services, etc.)
• Interface personnalisée (API)
• Tableur
• Approche WEB….
200
Terminologie & Exemples
Terme Définition Exemple d’application
Tableau de bord de Reporting très synthétique présentant • Balanced scorecard

pilotage des indicateurs à portée stratégique, • Tableau de bord « Direction Générale »
parfois agrémenté de mises en forme
graphique favorisant l’interprétation
des résultats.
Tableau de bord Reporting dynamique permettant à • Cube d’analyse des ventes
exploratoire l’utilisateur de modifier à la volée la
granularité des indicateurs et les
axes d’analyses.
Simulation / Planning Application spécifique permettant de • Application d’élaboration budgétaire &
collecter des résultats suivi de l’atterrissage en fin d’exercice
(performances) ou de réaliser des • Définition des objectifs commerciaux et
projections chiffrées. collecte des prévision de réalisation
• Simulation de l’évolution de la masse
salariale.
Data mining Utilisation de méthodes et outils • Calcul d’un score d’appétence
statistiques pour décrire une d’abonnés d’un opérateur de téléphonie
population, analyser des mobile pour une option spécifique.
comportements, déduire des • Segmentation de la clientèle en
modèles mathématiques permettant fonction du potentiel d’affaire restant à
de la prédiction. développer 201
Exemple de tableau de bord de pilotage
202
Exemple de tableau de bord de pilotage
203
Sommaire
• Le Data Mining
• Synthèse
204
Data Mining
• Par analogie à la recherche des pépites

d’or dans un gisement, le data mining
(fouille de données) vise :
 à extraire des informations cachées par analyse
globale
 à découvrir des modèles (“patterns”) difficiles à
percevoir car:
 le volume de données est très grand
 le nombre de variables à considérer est important
 ces “patterns” sont imprévisibles (même à titre
d ’hypothèse à vérifier)
205
Le Data Mining
Définition
• Data mining
 ensemble de techniques d'exploration de données
afin d'en tirer des connaissances (la signification
profonde) sous forme de modèles présentés à
l ’utilisateur averti pour examen
Données Data
entrepôt mining Connaissances
Découverte de Compréhension
modèles Prédiction
206
Le Data Mining
Connaissances
• Knowledge Discovery in Databases (KDD)

 Processus complet d’Extraction de Connaissance des
Données (ECD)
 Comprend plusieurs phases dont le data mining
• Exemples
 analyses (distribution du trafic en fonction de l ’heure)
 scores (fidélité d ’un client), classes (mauvais payeurs)
 règles (si facture > 10000 et mécontent > 0.5 alors départ à
70%)
207
Le Data Mining
Mécanismes de base
• Déduction : base des systèmes experts

 schéma logique permettant de déduire un
théorème à partir d'axiomes
 le résultat est sûr, mais la méthode nécessite la
connaissance de règles
• Induction : base du data mining
 méthode permettant de tirer des conclusions à
partir d'une série de faits
 généralisation un peu abusive
 indicateurs de confiance permettant la pondération
208
Le Data Mining
Domaines d'application
• De plus en plus de domaines

 explosion des données historisées
 puissance des machines support
 nombreux datawarehouses
 OLAP limité
 nécessité de mieux comprendre
 rapports sophistiqués, prédictions
 aide efficace aux managers
209
Le Data Mining
Quelques domaines réputés
• Analyse de risque (Assurance)

• Marketing
• Grande distribution
• Médecine, Pharmacie
• Analyse financière
• Gestion de stocks
• Maintenance
• Contrôle de qualité
210
Le Data Mining
Churn Analysis
• Application de télécom
• Bases de données des clients et des
appels
• Fichiers des réclamations
• Qui sont les clients le plus susceptibles de
partir ?
• Application de techniques de DM
• Fichiers de 1000 clients les plus risqués
• 600 ont quittés dans les 3 mois
211
Le Data Mining
Trading Advisor
• Application boursière
 conseil en achat / vente d'actions
• Données de base
 historique des cours
 portefeuille client
• Analyse du risque
• Analyse technique du signal
• Conseils d'achat – vente
• Mise à disposition sur portail Web
212
Le Data Mining
Principales Techniques
• Dérivées
 des statistiques (e.g., réseaux bayésiens)
 de l'analyse de données (e.g., analyse en composantes)
 de l'intelligence artificielle (e.g., arbres de décision, réseaux
de neurones)
 des bases de données (e.g., règles associatives)
• Appliquées aux grandes bases de données
• Difficultés :
 passage à l'échelle et performance
 fonctionnement avec échantillon > qq milliers
 présentation et validation des résultats
213
Le Data Mining
Quelques produits
• Intelligent Miner d'IBM • Oracle 9.i

 modélisation prédictive
(stat.), groupage,
segmentation, analyse
d'associations, détection de • OLE/DB for DM
déviation, analyse de texte
libre
• SAS de SAS • DB2 V8
 Statistiques, groupage,
arbres de décision, réseaux
de neurones, associations,
...
• SPSS de SPSS
 statistiques, classification,
réseaux de neurones
214
Le Data Mining
Sommaire
• Le Data Mining
• Synthèse
215
Data Warehouse : les méthodes traditionnelles
ne sont pas adaptées ...
Projet classique Projet DW
 Les Spécifications peuvent  Contenu fonctionnel évolutif

être gelées et traduire  l'outil crée le besoin
l'expression d'un besoin  le besoin suscite de
stable nouveau besoins
 les changements doivent
être "acceptés" et non
rejetés sur la foi de
spécifications validées
216
Synthèse
Data Warehouse : les méthodes traditionnelles
ne sont pas adaptées ...
Projet classique Projet DW
 l'application peut être  Le périmètre de besoin

développée en une est trop large est évolutif
seule fois pour construire
 ce développement peut l'application en une fois
un jour être considéré  L'application évolue de
"achevé" manière continue
La démarche de mise en œuvre d'un

DW doit être itérative, incrémentale...
217
Synthèse
Data Warehouse : exemple de démarche de mise
en oeuvre ...
Enjeux Métier Architecture palier 1
 Objectifs et  Fonctionnelle
priorités  applicative
 valeur  technique
ajoutée /
délai
 stratégie de
découpage
mise en oeuvre
6 à 8 semaines 8 à 10 incrémentale,
semaines
4 à 6 mois par itération
218
Synthèse
Data Warehouse : où sont les difficultés dans la
mise en œuvre ...
20 %
Restituer Alimenter
60 %
• Répartition
par fonction
de la charge Alimenter
de travail 80 % 20 %
fabriquer
fabriquer
administrer 20 % fonction
administrer des moyens et
outils
219
Synthèse
Data Warehouse : où sont les difficultés dans la
mise en oeuvre ...
• 50 % de la charge de travail est consacrée à

l'intégration du Data Warehouse avec les
systèmes d'information existants au travers les
process d'alimentation :
 extraction
 nettoyage
 transformation
220
Synthèse
Data Warehouse : pourquoi l'intégration est-elle
si difficile ...
• Au plan des données :

 les sources sont multiples (plusieurs dizaines)
 internes
 et externes (notamment pour le marketing)
 les référentiels sont hétérogènes
 les sources ne sont pas synchrones
 les sources sont concurrentes en mise à jour (laquelle est
prioritaire)
 les règles de gestion ne sont pas à jour
221
Synthèse
Data Warehouse : pourquoi l'intégration est-elle
si difficile ...
• Au plan technique :
 les environnements techniques sont multiples
 les structures et formats de stockages sont multiples
 les langages et outils de développement sont multiples
 la compétence technique n'existe plus ou n'est pas
disponible
 les performances de chargement sont critiques dans la
fenêtre d'exploitation
222
Synthèse
Eléments de solution d'architecture DW...
• Risques, dans l'intégration avec les systèmes

d'information, inhérents aux choix d'architecture
• Compatibilité de la solution avec la logique de

"scalabilité"
223
Synthèse
Data Warehouse : où est le problème ...
• La construction du DW nécessite des efforts

importants
• peut coûter cher
• est longue à mettre en oeuvre (18 mois en
moyenne)
• s'avère complexe au plan technique
comment dégager plus rapidement de la

valeur ajoutée ...
... en commençant par les Datamarts
224
Synthèse
Le Datamart indépendant ...
Niveau Niveau DataMart Niveau

source restitution
OLTP
Utilisateur
• Périmètre et coûts
réduits
• mise en oeuvre
simplifiée Mais les difficultés
Synthèse • délai raccourci apparaissent vite ... 225
La multiplication des Datamart ...
Niveau Niveau DataMart Niveau

source restitution
OLTP
Niveau DataMart
Utilisateur
OLTP
N sources, N xM process
M Datamart d'alimentation 226
Synthèse
Conséquence de la multiplication
des Datamarts ...
• multiplication des alimentations

• problème de cohérence sur les données
• Scalabilité de la solution technique
• maintenabilité
227
Synthèse
La solution...
Niveau source Niveau DataMart 1. Démarrer avec

une "architecture 2
tiers".
OLTP
Niveau source Niveau DW Niveau DataMart 2 .Evoluer vers une

"architecture 3 tiers"
optimisée au plan
de l'intégration avec
l'amont
OLTP OLTP
228
Synthèse
La première étape de la mise en oeuvre...
Démarrer sur une petite plate-forme

Instaurer d'emblée le principe du Datamart dépendant
d'un mini Data Warehouse (dimensions & faits

conformes).
Niveau source Mini DW DataMart
229
Synthèse
Evoluer progressivement ...
 En grossissant le mini Data Warehouse devient un

tiers à part entière de l'architecture
Le choix d'une plate-forme technique plus puissante et
"scalable" peut-être fait
Niveau source DW DataMart
DataMart
DataMart
230
Synthèse
Restent toutefois quelques points sensibles...
Quels outils choisir pour bien

gérer les process d'alimentation
...
Niveau DW DataMart
source DataMart
DataMart
231
Synthèse
Outils ...
 Logiciels de réplication :
Pour propager les mises à jour effectuées
dans une base source vers une ou des bases
cibles
 Logiciels de transformation :
pour assurer la fabrication de données cibles
à partir de données sources en leur
appliquant des règles de transformation
232
Synthèse
Leur utilité... au niveau de la source
• Capacité à extraire les données ...

• conservées dans des formats et structures de
stockage multiples ...
• sur des plates-formes techniques multiples ...
• en une ou plusieurs séquences ...
• en leur appliquant des règles de gestion...
• en respectant des mécanismes déclenchant
externes ou internes.
233
Synthèse
Leur utilité... la transformation
• Capacité à filtrer les données,

• à les formater,
• à les restructurer,
• à les synchroniser,
• à fabriquer des données de synthèse par
calcul ou agrégation,
• à mettre en oeuvre des mécanismes
spécifiques,
• en application de règles de gestion
multiples.
234
Synthèse
Leur utilité... au niveau de la cible
• Capacité à injecter les données ...

• dans des formats et structures de stockage
multiples ...
• sur des plates-formes techniques multiples ...
• en une séquence ...
• en leur appliquant des règles de gestion...
235
Synthèse
Les apports escomptés
• Productivité
• Normalisation
• Evolutivité et maintenabilité (documentation,
référencement des processus, traçabilité, étude
d'impact, ...)
• Performance
• Qualité et Fiabilité des produits finis
• Indépendance vis à vis des structures de
stockage
• ...
236
Synthèse
Data Warehouse et performance ...
• Voir grand mais commencer petit
• Adresser la problématique de la volumétrie et de

la performance dès la première heure
... et sur des données réelles
237
Synthèse
Bibliographie (1/2)
• The data warehouse toolkit (Ralph Kimball)

1996, ISBN 0-471-15337-0
Entrepôts de Données - Guide pratique du

concepteur de data warehouse
Traduction de Claude Raimond,
éditions International Thomson Publishing France
• Dans l’œil du cyclone (Geoffrey A. Moore)
First Editions, 1997, ISBN 2-87691-359-3
• Le data mining (René Lefébure, Gilles Venturi)
Eyrolles, 1998, ISBN 2-212-08981-3
• Le projet décisionnel (Jean-Marie Gouarné)
Eyrolles, 1998, ISBN 2-212-05012-7
238
Bibliographie (2/2)
• Le data warehouse, le data mining (J.M. Franco)

Eyrolles, 1997
• Data mining (M.J.A. Berry & G. Linoff)
Masson
• Building the data warehouse (W.H. Inmon)
• Using the data warehouse (W.H. Inmon & R.D.
Hackathorn)
• Building the operational data store (W.H. Inmon)
• Le Data Warehouse – Guide de Conduite de
Projet (R. Kimball, L. Reeves, M. Ross, W.
Thornthwaite)
Eyrolles 2005
239
Adresses Internet
• Ralph Kimball
http://www.ralphkimball.com
• Decideo
http://www.decideo.fr
• Wikipedia
http://fr.wikipedia.org/wiki/Entrepôt de données/
240

BI102

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

BI102

Загружено:

Авторское право:

Доступные форматы

Conception et mise en oeuvre d'un

• Informatique décisionnelle / Business Intelligence

 Exemples d'applications concernées

Système d’Information Opérationnel - SIO

Type d’accès Lecture / Écriture Lecture simple

• Data Warehouse (Entrepôt de données)

 Ensemble de données historisées variant dans le

• Data Mart (Magasin de données)

 Entrepôt de données spécialisé pour un métier ou

• OLTP : On Line Transaction Processing

 Techniquement associé aux SGBD Relationnels du marché :

• OLAP : On Line Analytical Processing

 Est plus un concept qu’une technologie.

Système Informatique de Gestion

Saisies et mises à jour des données

Extraction Report OLAP

Administration des données

Saisies et mises à jour des données

Collecte Intégration Distribution Présentation

Objets métier Décisions

Données Administration du référentiel

Saisies et mises à jour des données

Opérateurs Données SYSTÈME D’INFORMATION DECISIONNEL Front-Office (CRM)

E.R.P. Gestion Service

Réf. Produits Réf. Réseaux Réf. Employés Réf. Tiers

Collecte des données Transformation Alimentation Restitution / Analyse

• Data Stage Area (DSA – Espace de • Operational Data Store (ODS -

Infocentre Data Warehouse Data Web

L’approche Data Warehouse 20

• Les flux de collecte Gestion

» Données de gestion ERP

• Les flux de distribution Décision

L’approche Data Warehouse 22

L’approche Data Warehouse 23

• Les données proviennent des bases de

L’approche Data Warehouse 24

• Les données récentes

L’approche Data Warehouse 28

L’approche Data Warehouse 2. Fabriquer 29

• Un Data Warehouse est un "gros" projet :

• Un projet de Data Warehouse né "gros" et se

L’approche Data Warehouse 30

L’approche Data Warehouse 31

• Concevoir et mettre en œuvre des solutions :

L’approche Data Warehouse 32

Data Warehouse d'entreprise

• Lotissement des gros projets

Source Data Warehousing Institute 34

• Reprise de l’existant et nouveaux besoins

• Approche pragmatique, orientée

• Découpage des besoins utilisateurs

Environnement Existant Nouveaux besoins Existant

Modélisation Choix Technologiques

Choix d’architecture Requêteur

 (Service) Utilisateur opérationnel isolé

 Pression des dirigeants pour obtenir une meilleure

 Pas de demande formulée…

• Trouver un sponsor / parrain au sein

• Analyser en détail les besoins métier

Définir le périmètre du projet

- Objectif significatif et maîtrisable

Définir les critères de réussite

Investissements & coûts financiers