Vous êtes sur la page 1sur 240

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

Introduction et définitions
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

Introduction et définitions
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.
Introduction et définitions
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)

Introduction et définitions
7
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

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
Générations des Systèmes Décisionnels

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

Saisies et mises à jour des données


12
Générations des Systèmes Décisionnels

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
• Requêteurs Client-
• Reporting Serveur
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

Saisies et mises à jour des données


14
Générations des Systèmes Décisionnels

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
• Requêteurs Client-
• Reporting Serveur
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
L’approche Data Warehouse 21
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

L’approche Data Warehouse 22


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
 ...

L’approche Data Warehouse 23


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

L’approche Data Warehouse 24


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
L’approche Data Warehouse 25
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
L’approche Data Warehouse 26
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

L’approche Data Warehouse 28


Data Warehouse : signes distinctifs ...

• 4 grandes fonctions :
3. Administrer

1. Alimenter 4. Restituer

L’approche Data Warehouse 2. Fabriquer 29


Data Warehouse : signes distinctifs ...

• 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

L’approche Data Warehouse 30


Data Warehouse : signes distinctifs ...

• 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

L’approche Data Warehouse 31


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

L’approche Data Warehouse 32


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
L’approche Data Warehouse 33
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

• 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

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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
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
La démarche de mise en œuvre
Planifier le projet

• Développer le plan de communication :


 Equipe de projet
 Sponsor et CP métier
 Utilisateurs
 Service Informatique
 Direction

47
La démarche de mise en œuvre
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

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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
Modèle relationnel normalisé

 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é
La modélisation dimensionnelle
etc. 52
Modèle relationnel normalisé

 Formes Normales (Normal Forms NF).

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
La modélisation dimensionnelle
Modèle relationnel normalisé

 Formes Normales (Normal Forms NF).

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
La modélisation dimensionnelle
Modèle relationnel normalisé

 Formes Normales (Normal Forms NF).

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
La modélisation dimensionnelle
Modèle relationnel normalisé

56
La modélisation dimensionnelle
La modélisation dimensionnelle

• 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
La modélisation dimensionnelle
La modélisation dimensionnelle

• 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
La modélisation dimensionnelle
La modélisation dimensionnelle

• 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
La modélisation dimensionnelle
La modélisation dimensionnelle

• 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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
Modèle en flocon & Hiérarchies
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
73
La modélisation dimensionnelle
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
N° Semaine Table des faits ventes
Dimension Client
Heure (CE)
Produit (CE) Client (CP)
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
Flocon ou Étoile ? (2/3)

• 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
La modélisation dimensionnelle
Flocon ou Étoile ? (3/3)

• 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
La modélisation dimensionnelle
Modèle dimensionnel dénormalisé

78
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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

• Exemple :

Produit

Pays Région Ville CA

Date
DF
Client

82
La modélisation dimensionnelle
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

• Solution :

Produit

Pays Région Ville Client CA

Date

83
La modélisation dimensionnelle
Règles de modélisation (selon Jean-Marie Gouarné)

• 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
La modélisation dimensionnelle
Règles de modélisation (selon Jean-Marie Gouarné)

• 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
La modélisation dimensionnelle
Règles de modélisation (selon Jean-Marie Gouarné)

• Règle 4 : Le graphe de chaque dimension d’un modèle doit


ê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
La modélisation dimensionnelle
Règles de modélisation (selon Jean-Marie Gouarné)

• Règle 4 : Le graphe de chaque dimension d’un modèle doit


être acyclique

Solution

Direction
Division
Commerciale
commerciale
Régionale
Agence
Direction
Etablissement Administrative
Régionale

87
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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 modélisation dimensionnelle
La dénormalisation

• Avantages de la normalisation ...


 suppression des redondances
 réduction des volumes

• … et inconvénients
 complexité de la navigation

91
La modélisation dimensionnelle
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 modélisation dimensionnelle
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
Dénormalisation par redondance des clés

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 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
Sous-Famille Nom 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
La dénormalisation :
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
La modélisation dimensionnelle
La dénormalisation :
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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
L’architecture en bus décisionnel

• 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
La modélisation dimensionnelle
L’architecture en bus décisionnel

Achats

Inventaire magasin

Ventes Magasin

Date Produit Magasin Promotion Entrepôt Fournisseur Transporteur

101
La modélisation dimensionnelle
L’architecture en bus décisionnel

• 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
La modélisation dimensionnelle
L’architecture en bus décisionnel

• 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
La modélisation dimensionnelle
L’architecture en bus décisionnel

• 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
La modélisation dimensionnelle
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
La modélisation dimensionnelle
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

La modélisation dimensionnelle
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

La modélisation dimensionnelle
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

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
L’agrégation (2/4)

• 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
L’agrégation (3/4)

• 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
L’agrégation (4/4)

• 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
Chiffre d’affaires
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
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
Chiffre d’affaires
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

• 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

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 optimisations physiques
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
Les optimisations physiques
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
Les optimisations physiques
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
Les optimisations physiques
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
Les optimisations physiques
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

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

Niveau Niveau Data Niveau DataMart Niveau


source Warehouse restitution

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 ...

Niveau Niveau Data Niveau DataMart Niveau


source Warehouse restitution
• 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

L’Architecture technique 167


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’Architecture technique 168


Alimentation et fabrication :
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

L’Architecture technique 169


Alimentation et fabrication :
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

L’Architecture technique 170


Alimentation et fabrication :
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
L’Architecture technique 172
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
L’Architecture technique 173
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

L’Architecture technique 174


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)

L’Architecture technique 175


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
L’Architecture technique 176
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)
L’Architecture technique 178
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’Architecture technique 179


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.

L’Architecture technique 180


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
L’Architecture technique 181
Les outils de transformation de données ETL

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
L’Architecture technique 182
Les outils de transformation de données ETL

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

L’Architecture technique 183


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

L’Architecture technique 185


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

L’Architecture technique 186


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

L’Architecture technique 187


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
Chargement incrémental & rollback :
T2 – Chargement flux « Compta »

Collecte des données Transformation Alimentation / Distribution Restitution /


Analyse

Datamart
Engagement
Requêtes ad hoc
Infos Prêt
BusinessObjects

Datamart
Infos Tenue DATA Float
ODS Informations
Cpte WAREHOUSE
Comptables

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
189
Chargement incrémental & rollback :
T3 – Chargement flux « Prêt »

Collecte des données Transformation Alimentation / Distribution Restitution /


Analyse

Datamart
Engagement
Requêtes ad hoc
Infos Prêt
BusinessObjects
Informations
Prêt Datamart
Infos Tenue DATA Float
ODS Informations
Cpte WAREHOUSE
Comptables

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
190
Chargement incrémental & rollback :
T4 – Rollback du chargement flux « Compta »

Collecte des données Transformation Alimentation / Distribution Restitution /


Analyse

Datamart
Engagement
Requêtes ad hoc
Infos Prêt
BusinessObjects
Informations
Prêt Datamart
Infos Tenue DATA Float
DSA ODS
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
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

L’Architecture technique 192


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.
L’Architecture technique 193
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

L’Architecture technique 195


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
 ….

L’Architecture technique 196


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

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
Les applications utilisateur
Implémentation

• Outil spécialisé C/S (BO, Cognos,


Reporting Services, etc.)
• Interface personnalisée (API)
• Tableur
• Approche WEB….

200
Les applications utilisateur
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

• 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

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

• 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

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