Data Warehouse

Sequence 1
Chapitre 1 : ................................................................................................................................. 3
Introduction aux entrepôts de données (ED) .......................................................................... 3
Définition d’un ED ................................................................................................................. 3
Les données du système d'information................................................................................... 4
Données orientées sujet ...................................................................................................... 4
L’avantage .......................................................................................................................... 5
Données intégrées .................................................................................................................. 5
Données historisées ................................................................................................................ 5
Données non volatiles ............................................................................................................ 5
Les classes de données ........................................................................................................... 5
Les données agrégées ......................................................................................................... 6
Les données détaillées ........................................................................................................ 6
Les métadonnées ................................................................................................................ 6
Les données historisées ...................................................................................................... 6
Architecture fonctionnelle d’un ED ........................................................................................... 6
Modélisation multidimensionnelle ......................................................................................... 6
La modélisation par sujet ................................................................................................... 6
La modélisation dimensionnelle......................................................................................... 6
Faits, indicateurs et dimensions ..................................................................................... 6
Additivités des indicateurs ............................................................................................. 7
Les dimensions ............................................................................................................... 7
Structure de la base de données.......................................................................................... 7
Le schéma en étoile ........................................................................................................ 8
Le schéma en flocon ....................................................................................................... 8
Les schémas en constellation de faits ............................................................................. 9
Alimentation, stockage, gestion et exploitation d’un ED................................................... 9
Découverte des données .......................................................................................... 9
Extraction des données ............................................................................................ 9
Transformation des données ................................................................................... 9
Domaines d’application des ED et « succès stories » ...................................................... 10
Domaines bancaire ....................................................................................................... 10
Domaines de la grande distribution .............................................................................. 10
Apports constatés : ................................................................................................... 11
 Domaines des télécommunications .............................................................................. 11
Domaines de l’assurance .............................................................................................. 11
Chapitre 2 : Analyse en ligne d’entrepôt : OLAP (On-Line Analytical Processing) ............... 12
Introduction et problématique de l’OLAP ........................................................................... 12
OLTP ................................................................................................................................ 12
OLAP ............................................................................................................................... 12
Entrepôt et OLAP, OLAP versus OLTP .......................................................................... 12
Opérations élémentaires OLAP ........................................................................................ 13
Opérations de restructuration (rotate, switch, split, nest, push, pull) ........................... 13
Rotate/pivot .............................................................................................................. 13
Switch ou permutation ............................................................................................. 13
Split ou division ....................................................................................................... 13
Nest ou l’emboîtement ............................................................................................. 14
Push ou l’enfoncement ............................................................................................. 14
Opérations de granularité ............................................................................................. 15
roll-up ou résumé ou cumul ..................................................................................... 15
drill-down ou zoom avant ........................................................................................ 15
Opérations liées au niveau de granularité des données : .............................................. 15
Dice ou couper en clés ............................................................................................. 15
Slice ou trancher ....................................................................................................... 16
Etude de cas .......................................................................................................................... 17
Modélisation en étoile ...................................................................................................... 17
Cas ................................................................................................................................ 17
Analyse. ........................................................................................................................ 17
Explications .............................................................................................................. 18
Il faut savoir : ........................................................................................................... 18
Conclusion ................................................................................................................ 18
Modélisation en flocon ..................................................................................................... 19
Conception d'entrepôts de données ...................................................................................... 20
Constellation..................................................................................................................... 20
Construire un entrepôt de données ................................................................................... 21
Top-Down .................................................................................................................... 21
Bottom-Up .................................................................................................................... 21
Middle-Out ................................................................................................................... 21
Reférences ............................................................................................................................ 22
Chapitre 1 :
Introduction aux entrepôts de données (ED)
Les décideurs d'une entreprise doivent pouvoir répondre à un certain nombre de question pour
diriger leur entreprise :
- Qui sont mes clients ?
- Pourquoi sont-ils mes clients ?
- Comment cibler ma clientèle ?
- Quel est l'évolution de tel produit ?
- Qui sont mes employés ?
- ...
L'objectif est donc d'apporter aux décideurs d'une entreprise les moyens de répondre à ces
questions.
Pour atteindre cet objectif, le concept d’entrepôt de données a été formalisé pour la première
fois en 1990 par Bill Inmon. Il s’agissait de constituer une base de données orientée sujet,
intégrée et contenant des informations historisées, non volatiles et exclusivement destinées aux
processus d’aide à la décision.

Définition d’un ED
Un entrepôt de données est une collection de données thématiques, intégrées, non volatiles et
historisées pour la prise de décisions (Bill Inmon)
Les points clefs garantissant le succès d'un entrepôt de données sont les suivants :
- Les informations d'un entrepôt de données doivent être accessibles et fiables (de
qualité).
- La conception d'un entrepôt de données doit répondre à un besoin de ROI4 élevé.
- La réponse aux demandes très diverses des utilisateurs.
- L’entrepôt de données doit évoluer avec les besoins des utilisateurs et du système
d'information.
 -

Les données du système d'information

Les données permettant la prise de décisions diffèrent des données opérationnelles :

Tableau 1 : Différences entres les données opérationnelles et les données décisionnelles

Données orientées sujet

- Organisé autour des sujets majeurs et des métiers de l'entreprise.
- Les données sont organisées par thème, contrairement aux données des systèmes de
production, organisées par processus fonctionnels.
BD Production Employés Facturatio

Données Données Données

produit clients vendeurs
DW

L’avantage
- Réaliser des analyses sur des sujets transversaux aux structures fonctionnelles et
organisationnelles de l'entreprise. Et ainsi, de pouvoir analyser un processus dans le
temps à différentes étapes de sa conception au sein du SI.
- Analyses par itération, sujet après sujet.
L'intégration dans une structure unique est indispensable pour éviter aux données concernées
par plusieurs sujets d'être dupliquées. Dans la pratique il existe également des Datamart pouvant
supporter l'orientation sujet.

Données intégrées
Les données doivent êtres mises en forme et unifiées afin d'avoir un état cohérent. Pour parfaire
cette cohérence, l’intégration nécessite
- Une forte normalisation de données.
- Maîtrise de la sémantique,
- La prise en compte des contraintes référentielles et des règles de gestion.
Ces notions sont énoncées, détaillées et administrées au sein des métadonnées de l’entrepôt de
données.

Données historisées
- Suivre dans le temps l'évolution des différentes valeurs des indicateurs à analyser.
- Un référentiel temps doit être associé aux données afin de permettre l'identification dans
la durée de valeurs précises.

Données non volatiles

Afin de conserver la traçabilité des informations et des décisions prises, les informations
stockées au sein de l’entrepôt de données ne peuvent être supprimées.

Les classes de données

Un entrepôt de données peut se structurer en quatre classes de données organisées selon un axe
historique et un axe de synthèse.
Les données agrégées
Correspondent à des éléments d’analyse représentant les besoins des utilisateurs. Elles
constituent déjà un résultat d’analyse et une synthèse de l’information contenue dans le système
décisionnel, et doivent être facilement accessibles et compréhensibles.
Les données détaillées
Les données détaillées reflètent les événements les plus récents. Les intégrations régulières des
données issues des systèmes de production vont habituellement être réalisées à ce niveau.
Les métadonnées
Les métadonnées constituent l'ensemble des données qui décrivent des règles ou processus
attachés à d'autres données. Ces dernières constituent la finalité du système d'information.
Les données historisées
Chaque nouvelle insertion de données provenant du système de production ne détruit pas les
anciennes valeurs, mais créée une nouvelle occurrence de la donnée.

Architecture fonctionnelle d’un ED

Modélisation multidimensionnelle
La modélisation par sujet
Un entrepôt de données est généralement basé sur un SGBD relationnel. La modélisation par
sujet est une technique de conception logique qui vise à organiser et classifier les informations
des bases légataires en données classées par sujet fonctionnel. Elle est basée sur la modélisation
"Entité/Association" et est préliminaire à la modélisation dimensionnelle. Chaque sujet
correspond à une table gérée au sein de l’entrepôt. Il faut isoler les données stratégiques,
déterminer les informations de détails nécessaires (profondeur, granularité) et conserver les
métadonnées.
La modélisation dimensionnelle
La modélisation dimensionnelle (modèle multidimensionnel) souvent appelée modélisation
OLAP (Codd 1993) se présente comme une alternative au modèle relationnel. Elle correspond
mieux aux besoins du décideur tout en intégrant la modélisation par sujet. C’est une méthode
de conception logique qui vise à présenter les données sous une forme standardisée intuitive et
qui permet des accès hautement performants. Elle aboutit à présenter les données non plus sous
forme de tables mais de cube centré sur une activité. Un cube de dimension n (n > 3) est aussi
dit hyper cube.
Faits, indicateurs et dimensions
La table de faits est la clef de voûte du modèle dimensionnel où sont stockés les indicateurs de
performances. Le concepteur s’efforce de considérer comme indicateurs les informations d’un
processus d’entreprise dans un système d’information. Les indicateurs étant les données les plus
volumineuses d’un système d’information, on ne peut se permettre de les dupliquer dans
d’autres tables mais de les rationaliser au sein de la table de faits.
Exemple : La table de faits des ventes journalières
Ventes
Clé date (CE)
Clé produit (CE)
 Clé magasin (CE)
Quantité vendue
Montant des ventes ($)
Tableau 2 : Modèle conceptuel d’une table de faits
Le terme de fait est utilisé pour représenter une mesure économique. Pour exemple, lors de la
vente de produits sur un marché, on comptabilise les types de produits vendus, leur quantité et
le montant de chaque vente au jour le jour et ce, pour chaque produit et pour chaque magasin.
La mesure des quantités et des prix est réalisée à l’intersection de toutes les dimensions (produit,
magasin, temps). Le nombre des dimensions détermine la finesse, la granularité de la table et
indique la portée de l’indicateur.
Additivités des indicateurs
Les indicateurs les plus utiles d’une table de faits sont numériques et additifs. L’additivité des
attributs d’une table de faits est cruciale pour les outils décisionnels. Les utilisateurs demandent
rarement l’analyse d’une seule ligne. Dans notre exemple, constater les ventes de produits sur
une année pour les magasins d’une région demande l'analyse de plusieurs milliers de lignes à
la fois. Pour autant, tous les attributs utiles ne sont pas additifs. Certains sont semi additifs et
ne peuvent être additionnés que pour certaines dimensions. D’autres sont non additifs et ne
peuvent pas être additionnés par dimensions. Pour cette dernière catégorie, on utilise des
fonctions d'agrégations tel que, le calcul de moyenne, le ratio ou le comptage de lignes.
Les dimensions
Les tables de dimensions sont les entités complémentaires à la conception de la table de faits.
Elles contiennent, autant que possible, des attributs sous forme de descriptions textuelles
permettant de qualifier ou d’expliquer l’activité.
Des attributs de dimensions, nombreux, permettent de varier les possibilités d’analyse. En
général, les tables de dimensions tendent à être peu profondes mais elles sont larges (l'inverse
de la table de faits), en d’autres termes elles ont peu de lignes mais beaucoup de colonnes.

"Produit"
Clé produit (CP)
Description du produit
Numéro US (clé naturelle)
Description de la marque
Description de la catégorie
Description du rayon
Description du type d'emballage
…autres attributs
Tableau 3 : Modèle conceptuel d’une table de dimension
Structure de la base de données
Au sein de l’entrepôt de données les données sont redondantes et dénormalisées, cela permet
de faciliter l’utilisation et d’améliorer les performances lors de l'analyse des données. Trois
types de schémas sont fréquemment rencontrés, le schéma en étoile, le schéma en flocon et le
schéma en constellation de faits.
Le schéma en étoile
Dans un schéma en étoile, une table centrale de faits contenant les faits à analyser, référence les
tables de dimensions par des clefs étrangères. Chaque dimension est décrite par une seule table
dont les attributs représentent les diverses granularités possibles.

Figure 1 : image d’un schéma en étoile

Exercice 1.
Une entreprise de fabrication de vaisselle jetable souhaite mettre en place un système
d’information décisionnel sous la forme d’un data mart (un mini entrepôt de données) pour
observer son activité de ventes au niveau des différents lieux de distributions de ses articles et
cela dans plusieurs villes. Ces lieux de distributions sont renseignés par leur enseigne, leur type
(en fonction de leur surface), leur adresse (code postal et ville), leur département, leur région.
Les ventes sont renseignées selon une période qui se décline en mois, en trimestre et année. Les
ventes sont observées par le nombre d’articles selon le type, et le chiffre d’affaire.
- Quel est le fait à observer ?
- Quels sont les axes d’analyse, et les mesures ?
- Construire le modèle en étoile de ce data mart.

Le schéma en flocon
Dans un schéma en flocon, cette même table de faits, référence les tables de dimensions de
premier niveau, au même titre que le schéma en étoile. La différence réside dans le fait que les
dimensions sont décrites par une succession de tables (à l’aide de clefs étrangères) représentant
la granularité de l'information. Ce schéma évite les redondances d’information mais nécessite
des jointures lors des agrégats de ces dimensions.
Les schémas en constellation de faits
Dans un schéma en constellation, plusieurs modèles dimensionnels se partagent les mêmes
dimensions, c'est-à-dire, les tables de faits ont des tables de dimensions en commun. Pour
conclure, les différences entre ces trois modèles sont faibles et ne peuvent donner lieu à des
comparaisons de performance. Ce sont des schémas issus de la modélisation dimensionnelle
utilisés par les outils décisionnels.

Alimentation, stockage, gestion et exploitation d’un ED

L'alimentation des données à partir des bases de production est une phase primordiale d'un
datawarehouse. Des outils logiciels sont alors nécessaires pour intégrer les données dans le
datawharehouse. On parle d'ELT (Extract, Transform, Load). Les phases de l'alimentation d'un
datawarehouse sont les suivantes :
Découverte des données
Il s'agit d'identifier dans les systèmes sources les données à importer dans le datawarehouse. Il
faut prendre les données les plus judicieuses. Un mauvais choix peut considérablement
compliquer les phases suivantes de l'alimentation.
Extraction des données
Il s'agit de collecter les données utiles dans les systèmes de production. Il faut identifier les
données ayant été modifiées afin d'importer le minimum de données dans le datawarehouse.
Transformation des données
Il faut rendre les données cohérentes avec la structure du datawarehouse. On applique alors des
filtres sur les données. Il peut être nécessaire de convertir le format des données (EBCDIC vers
ASCII par exemple) ou d'harmoniser les formats de dates (jj/mm/aaaa). Il faut également
associer les champs source avec les champs cibles. Un champ source « adresse » pourra ainsi
par exemple être décomposé en « numéro », « rue », « code postal » , « ville » ou l'inverse.
Enfin des données des systèmes de production doivent être agrégées ou calculées avant leur
chargement.

m, f

0, 1 m, f

male, female

fcfa

$ €

char(10)

Numeric(10)
Dec(10,2)

Numeric(8)

Figure 2 : Intégration des données

Domaines d’application des ED et « succès stories »
Domaines bancaire
- Pour une banque, il est important de pouvoir regrouper les informations relatives à un
client afin de répondre à ses demandes de crédit par exemple
- Des mailings ciblés doivent aussi être rapidement élaborés à partir de toutes les
informations disponibles sur un client lors de la commercialisation d’un nouveau
produit
- L’utilisation de cartes de crédit nécessite des contrôles à posteriori, par exemple pour la
recherche de fraudes : la mémorisation des mouvements peut rendre de grands services
- Les échanges d’actions et de conseils de courtages sont facilités par une mémorisation
de l’histoire et une exploitation par des outils décisionnels avancés par exemple pour
déterminer des tendances de marchés
Domaines de la grande distribution
- Intéressant de regrouper les informations de ventes pour déterminer les produits à
succès, mieux suivre les modes, détecter les habitudes d’achats, les préférences des
clients par secteur géographique
- La fouille de données (Data Mining) a permis de développer des techniques
sophistiquées d’exploitation de données qui aident à mettre en évidence les règles de
consommation
- Explorer le panier de la ménagère est devenu un exercice d’école : il s’agit de trouver à
partir de l’enregistrement des transactions quelles sont les habitudes d’achats, plus
précisément quels sont les produits achetés en même temps
Apports constatés :
- Augmentation des ventes grâce à un meilleur marketing
- Amélioration des taux de rotation de stocks
- Élimination des produits obsolètes
- Réduction des rabais, remises, ristournes
- Meilleure négociation des achats
Domaines des télécommunications
- Grande masse de données concernant les abonnés et les appels est enregistrée
- Plusieurs mois de description détaillée des appels comprenant, pour chaque appel
appelant, appelé, heure et durée sont disponibles chez les opérateurs
En respectant les lois de sécurité et liberté, que peut-on faire de telles données ?
Couplées ou non avec des informations comptables, l’exploitation de ces données regroupées
en ED par des techniques d’analyse et d’exploration permet :
- D’analyser le trafic,
- De mieux cerner les besoins des clients,
- De classer les clients par catégories,
- De comprendre pourquoi certains changent d’opérateurs et mieux répondre à leurs
besoins

Domaines de l’assurance
- L’exercice de base de l’assureur est de déterminer le facteur de risque d’un assuré
- Celui d’un producteur pharmaceutique est de détecter l’impact d’un médicament
- Plus généralement, le suivi des informations relatives à la liaison produit-client sur un
ED est souvent synonyme de gains importants : meilleure connaissance des produits,
détection des défauts, meilleure connaissance des clients, détection de rejets, ciblage du
marketing, etc
- Le couplage aux technologies du Web ouvre aussi des horizons nouveaux pour le suivi
des produits, des clients, des concurrents : notion émergente de « Data Webhouse »
Chapitre 2 : Analyse en ligne d’entrepôt : OLAP (On-Line Analytical
Processing)
Introduction et problématique de l’OLAP
En réalité SGBD et datawarehouse ont des objectifs différents. Ils stockent les données de
manière différentes et font l'objet de requêtes différentes. Ils sont ainsi basés sur deux systèmes
différents : OLTP et OLAP
OLTP
OLTP ( On Line Transaction Processing) est le modèle utilisé par les SGBD. Le mode de travail
est transactionnel. L'objectif est de pouvoir insérer, modifier et interroger rapidement et en
sécurité la base. Ces actions doivent pourvoir être effectuées très rapidement par de nombreux
utilisateurs simultanément. Chaque transaction travail sur de faibles quantités d'informations,
et toujours sur les versions les plus récentes des données.
OLAP
Les datawarehouses eux reposent sur le système OLAP (On Line Analytical Processing). Ce
système travail en lecture seulement. Les programmes consultent d'importantes quantités de
données pour procéder à des analyses. Les objectifs principaux sont regroupés, organiser des
informations provenant de sources diverses, les intégrer et les stocker pour donner à l’utilisateur
une vue orientée métier, retrouver et analyser l’information facilement et rapidement. Cela
nécessite de consulter des versions historiques de la base et peut se permettre d'ignorer
temporairement les dernières mises à jour.
Ces bases sont souvent d'un ordre de grandeur nettement supérieur à celle des bases OLTP, du
fait de la conservation de l'historique.
Entrepôt et OLAP, OLAP versus OLTP
Tableau récapitulatif des différences entre OLTP et OLAP :

Caractéristiques OLTP OLAP

Utilisation SGBD (base de Datawarehouse
production)
Opération typique Mise à jour Analyse
Type d'accès Lecture écriture Lecture
Niveau d'analyse Elémentaire Global
Quantité d'information Faible Importante
échangées
Orientation Ligne Multidimension
Taille BD Faible (max qq GB) Importante (pouvant
aller à plusieurs TB).
Ancienneté des données Récente Historique
L'objectif des bases OLTP est de pouvoir répondre rapidement à des réponses simples, exemple
: les ventes du produit X. Les bases OLAP permettent des requêtes plus complexes : les ventes
du produit X par vendeur, région et par mois.
Opérations élémentaires OLAP
Opérations de restructuration (rotate, switch, split, nest, push, pull)
Rotate/pivot
Effectue au cube une rotation autour d’un de ses 3 axes passant par le centre de 2 faces opposées,
de façon à présenter un ensemble de faces différent (sélection de faces)

Permet un changement de points de vue selon différentes dimensions : opérations liées à la

structure, manipulation et visualisation du cube.
Switch ou permutation
consiste à interchanger la position des membres d’une dimension :

Split ou division
consiste à présenter chaque tranche du cube et de passer de sa présentation tridimensionnelle à
sa présentation sous la forme d’un ensemble de tables
Nest ou l’emboîtement
permet d’imbriquer des membres à partir du cube. L’intérêt de cette est qu’elle permet de
grouper sur une même représentation bi-dimensionnelle toutes les informations (mesures et
membres) d’un cube quel que soit le nombre de ses dimensions. nest(pièces, région) :

Push ou l’enfoncement
Consiste à combiner les membres d’une dimension aux mesures du cube, i.e. de faire passer des
membres comme contenu de cellules.
Opérations de granularité
roll-up ou résumé ou cumul
On effectue un roll-up1 lorsqu’on souhaite obtenir moins de détails, ou qu’on souhaite obtenir
une vue d’ensemble. On peut d’abord faire un roll-up à même une dimension qui dispose d’une
hiérarchie. Prenons l’exemple des données suivantes :
France 5
Espagne 2
Suisse 47
Canada 30
E.-U. 10
Cameroun 9

La dimension lieu est présentée à la granularité Pays. Si on juge que cela fournit trop de détails
inutiles, on peut demander un roll-up vers le continent :
Europe 54
Amérique du 40
Nord
Afrique 9
drill-down ou zoom avant
Exercice2 Proposer une table représentant un drill-down par rapport à la table précédente

Opérations liées au niveau de granularité des données :

Opérations ensemblistes (slide, dice, jointure (drill-across), data cube

terme anglais traduction

usuel possible
slice trancher
dice couper en clés
concerne l’extraction et l’OLTP classique
Dice ou couper en clés
Une opération de type dice consiste à générer une nouvelle table, qui
comporte autant de dimensions et les mêmes valeurs de mesures, mais
où l’on restreint certaines des dimensions à quelques mesures. Prenons
l’exemple de cette table, qui comprend à la fois des pays et des
couleurs. Imaginons que nous voulions éliminer la couleur orange et

ne conserver que les pays européens :

Slice ou trancher
L’opération slice, quant à elle, réduit le nombre de dimensions (comme une opération roll-up)
mais, tout comme l’opération dice, elle laisse les valeurs de mesures inchangées, se contentant
d’omettre une partie des données.
Imaginons que dans l’exemple des pays et des couleurs, nous nous intéressions qu’a la couleur
rouge. Dans un tel cas, nous pourrions extraire les enregistrements correspondants dans la table

de faits :
Etude de cas
Modélisation en étoile
Nous allons utiliser un exemple pour expliquer la modélisation en étoile. L'important en BI est
de toujours garder à l'esprit que ce que nous faisons est différent des bases de données
traditionnelles. Le schéma créé sera accessible par les utilisateurs et doit donc être le plus simple
et explicite possible !
Cas
On souhaite créer un data Mart (une étoile) pour l'analyse de l'activité des représentants d'une
entreprise de vente d'imprimantes. Le chef d'entreprise veut savoir ce qui se passe pour ses
vendeurs. Les employés font-ils leur travail, quelle est la zone de couverture des vendeurs, à
quels endroits les vendeurs sont le moins efficaces, quelle est la moyenne de ventes des
représentants, etc. L'entreprise possède un système de gestion de ressources humaines, un
système de gestion des ventes et des feuilles de route avec des informations concernant les
vendeurs : kilomètres parcourus, litres d'essence utilisée, frais de voyage, ventes, promesses de
vente, etc.
Analyse.
Notre objectif est d'analyser l'activité des représentants. Il semble que nous ayons toutes les
informations pour ce faire… Mais dans différents systèmes.
Le but du jeu est de déceler les axes d'analyses (les dimensions) avec leurs attributs ainsi que
les éléments à analyser (les faits). La meilleure façon de ce faire, est l'étude approfondie de ce
qui se passe dans l'entreprise : documents échangés, rapports périodiques, interviews des
personnes clés, étude des besoins. Il faut faire un travail d'acteur, et rentrer dans la peau de
chaque utilisateur, savoir comment les analystes organisent leurs raisonnements, savoir ce que
voient les décideurs avant de décider, connaître les indicateurs de bonne santé de l'entreprise et
de la concurrence. Un vrai travail de fourmi.
Les techniques d'acquisition d'information et d'analyse des besoins étant un sujet à eux seuls, je
passerais la main pour ce point … Nous supposerons que tout a été fait selon les règles de l'art
et nous nous contenterons de compiler
Une manière très pratique de modéliser un cas en BI se fait comme suit :
Zone
Date Vendeur Produit Client
géographique

Années Nom Catégorie Pays Nom

Mois Prénom Type Province Adresse

Jours Salaire Groupe Ville Pays

Heures

Analyse : consommation d'essence, Qte

commandée, Qte précommandée,
kilométrage, nombre de visites, etc.

Tableau d’analyse
Explications
Le tableau suivant a été rempli pendant la phase d'analyse, en posant des questions aux
décideurs du type :
- Que voulez-vous analyser (la dernière ligne du tableau) ?
- Quels sont vos critères d'analyse (la première ligne du tableau) ?
- Jusqu’à quel niveau de détail voulez-vous aller (les cellules è l'intérieur) ?
La structure d'un entrepôt étant plus rigide que les systèmes conventionnels (se basent sur des
ETL, des validations créées par l'homme, etc.), il est capital d'avoir une analyse des besoins
exhaustive et conforme aux attentes des décideurs.
Il faut savoir :
- D’où provient chaque champ ?
- Comment transite l'information ?
- Où trouver l'information voulue ?
Se poser des questions du type :
- Ai-je assez de données pour répondre aux besoins ?
- Sinon, qu'est-ce que cela impliquerait de les créer ?
- Comment alimenter mes dimensions ?
- Comment alimenter mes faits ?
- Comment valider mes chargements ?
- Etc.
Vous pouvez penser que c'est de la paranoïa (comme certains clients) et croire que tous ces
problèmes n'apparaîtront pas forcément. Mais rappelez-vous qu'un entrepôt, ça coûte très cher,
et qu'un entrepôt avec des données incomplètes, invalides ou non conformes à la demande est
tout simplement à mettre à la poubelle…
Conclusion
La modélisation en étoile découle naturellement du tableau d’analyse ci-dessus, il en résulte le
schéma suivant :
Schéma en étoile

On comprend maintenant pourquoi on appelle ce schéma « modèle en étoile ». Toutes les

dimensions sont directement reliées à la table de faits, qui contient les données à analyser.
Plusieurs remarques sont à faire pour ce schéma.
- La table de fait contient se qu'on appelle des « mesures », des champs (numériques pour
la plupart) sur lesquels on va faire les analyses, on peut y trouver le montant des ventes
nettes, les quantités vendues, les kilomètres parcourus, les quantités en pré commande,
etc. La table de faits est reliée aux dimensions par des relations (1, n). Pour analyser une
ligne de fait par client par exemple, il faut qu'il y ait une relation entre cette ligne et la
dimension client.
- Les tables de dimension contiennent les éléments qu'utiliseront les décideurs pour voir
la table de faits. Les utilisateurs pourront ainsi apprécier les montants des ventes par
vendeur, par client, ou le kilométrage pour un vendeur pour un client donné (pour voir
si ce client est rentable), calculer le coût de revient d'un produit par rapport aux activités
des vendeurs, etc.
- On n'utilise JAMAIS la clé d'un système de production comme clé de dimension : pour
préserver l'historique des modifications dans l'entrepôt de données
- La granularité des tables de dimensions et de faits doit être la même : imaginez que la
table de faits regroupe les informations par heures et que la table de dimension du temps
gère les minutes, il ne sera pas possible de lier la dimension temps et la table de faits
(multi détermination).
- Chaque ligne de la table de faits doit avoir une relation avec chacune des tables de
dimensions : dans le cas contraire, on aurait perte d'information ou analyse erronée.
- Il n'existe de relations qu'entre les dimensions et les tables de faits. Il sera beaucoup trop
compliqué de gérer et d'utiliser des dimensions liées entre elles. N'oubliez pas que le
schéma doit être assimilable par des non-informaticiens pour pouvoir l'exploiter.
N'ayons pas peur de créer des doublons !
Modélisation en flocon
La modélisation en flocon étant une variante de la modélisation en étoile, nous prendrons le
même cas avec la même analyse. Il faut savoir que la modélisation en flocon existe pour des
raisons de performances. En effet, des dimensions de plusieurs millions de lignes peuvent poser
des problèmes de lenteur lors de l'exploitation des données. Le principe de la modélisation en
flocon est de créer des hiérarchies de dimensions, de telle manière à avoir moins de lignes par
dimensions. Cela semble contredire la dernière remarque de la modélisation en étoile, c’est vrai
mais la performance ici prime sur la structure. C'est la seule façon trouvée pour avoir des
résultats clairs et rapides actuellement. Le schéma d'une modélisation en flocon pourrait être
comme suit :
Modélisation en flocon
Conseil : ne pas adopter cette modélisation à tort et à travers. En effet, pour garder une structure
simple, gérable et compréhensible, utilisez le plus possible la modélisation en étoile. La
modélisation en flocon n'intervenant que lorsque des problèmes de performances apparaissent
ou sont facilement prédictibles. Une règle informelle en BI préconise de floconner que si l'on a
la relation (1-1000). C'est-à-dire que si l'on réussit à créer une hiérarchie de deux dimensions
avec une ligne de la dimension père (groupe produit par exemple) faisant référence à plus de
1000 lignes de la dimension fille (produit par exemple). Dans ce cas, il est peut-être temps de
penser aux flocons.

Conception d'entrepôts de données

Un entrepôt de données, selon la définition officielle, est une vue complète et centralisée des
données de l'entreprise. La modélisation en étoile ou en flocon, ne s'intéresse qu'à la conception
d'un sous-ensemble d'entrepôt, une seule table de fait. On ne peut même pas dire qu'une étoile
ou un flocon représente un data Mart, car une fonction de l'entreprise peut comporter plusieurs
tables de faits. La fonction commerciale d'une entreprise peut comporter une étoile pour les
ventes, un flocon pour les commandes, une autre étoile pour les retours, etc.
Un entrepôt de données est l'ensemble de ces étoiles et/ou flocons. Mais comment organiser
tout ça ?
Constellation
Vous remarquez que tous ces termes sont empruntés à l'astronomie et à la météo : étoile, flocon,
constellation. Une constellation est une série d'étoiles ou de flocons reliés entre eux par des
dimensions. Il s'agit donc d'étoiles avec des dimensions en commun. Un environnement
décisionnel idéal serait une place ou il serait possible de naviguer d'étoile en étoile, de
constellation en constellation et de DataMart en DataMart à la recherche de l'information. Un
des indicateurs clés d'une bonne conception d'entrepôt est la grosseur des constellations. En
effet, plus la constellation est grosse, plus cela veut dire que vous avez réutilisé vos dimensions,
et qui dit réutilisation de dimension, dit dimensions complètes, centralisées et avec une vue
orientée entreprise.
En conception d'entrepôt, dès qu'une dimension existante ne correspond pas parfaitement aux
besoins d'une nouvelle étoile, on en crée une autre, même si elle est « presque » comme la
dimension que nous allions utiliser. C'est pour cela qu'il faut créer, autant que possible, des
dimensions génériques et qui soient vraies tout le temps, pour toutes les fonctions de
l'entreprise. Ces dimensions pourront être réutilisées et assurer une pérennité des données. Et si
de telles dimensions ne peuvent pas être créées, il faut créer des dimensions similaires, mais
adaptées aux besoins de la nouvelle étoile. Mais si vous voyez que dans chaque étoile vous êtes
obligés de créer une nouvelle dimension « client » par exemple, posez-vous des questions sur
votre conception.
Construire un entrepôt de données
Récapitulons, nous avons vu comment créer une étoile ou un flocon, nous avons vu que les data
marts sont des étoiles regroupées par fonction ou par utilité dans l'entreprise et nous savons
qu'un entrepôt est l'ensemble de tous les data marts de l'entreprise. Nous savons faire une étoile,
mais comment les regrouper pour mettre en œuvre un entrepôt de données ? Et bien trois
méthodes s'offrent à nous :
Top-Down
C’est la méthode la plus lourde, la plus contraignante et la plus complète en même temps. Elle
consiste en la conception de tout l'entrepôt (i.e. : toutes les étoiles), puis en la réalisation de ce
dernier. Imaginez le travail qu'une telle méthode implique : savoir à l'avance toutes les
dimensions et tous les faits de l'entreprise, puis réaliser tout ça… Le seul avantage que cette
méthode comporte est qu'elle offre une vision très claire et très conceptuelle des données de
l'entreprise ainsi que du travail à faire ;
Bottom-Up
C’est l'approche inverse, elle consiste à créer les étoiles une par une, puis les regrouper par des
niveaux intermédiaires jusqu'à obtention d'un véritable entrepôt pyramidal avec une vision
d'entreprise. L'avantage de cette méthode est qu'elle est simple à réaliser (une étoile à la fois),
l'inconvénient est le volume de travail d'intégration pour obtenir un entrepôt de données ainsi
que la possibilité de redondances entre les étoiles (car elles sont faites indépendamment les unes
des autres) ;
Middle-Out
C’est l'approche hybride, et conseillée par les professionnels du BI. Elle consiste en la
conception totale de l'entrepôt de données (i.e. : concevoir toutes dimensions, tous les faits,
toutes les relations), puis créer des divisions plus petites et plus gérables et les mettre en œuvre.
Cela équivaut à découper notre conception par éléments en commun et réaliser les découpages
un par un. Cette méthode tire le meilleur des deux précédentes sans avoir les contraintes. Il faut
juste noter que cette méthode implique, parfois, des compromis de découpage (dupliquer des
dimensions identiques pour des besoins pratiques).
Reférences
Bernard ESPINASSE Professeur : Entrepôts de données et analyse en ligne OLAP (On-Line
Analytical Processing) ,Aix-Marseille Université (AMU) Ecole Polytechnique Universitaire de
Marseille
https://grim.developpez.com/cours/businessintelligence/concepts/conception-datawarehouse/
Conception d'un entrepôt de données (Data Warehouse) Accédé le 11/12/2021