La modélisation multidimensionnelle

Jalal Tajeddine : Chef de projets Business Intelligence

Certifié Business Objects

Novembre 2012
Sommaire

 Chapitre 1 : La Business Intelligence

 Chapitre 2 : La modélisation multidimensionnelle

 Chapitre 3 : Les ETL (Principe, technique et exemple)

2
Business Intelligence
BI: Définition

La Business intelligence est un ensemble de moyens, des outils et des

méthodes qui permettent de collecter, consolider, modéliser et
restituer les données d’une entreprise en vue d’offrir une aide à la
décision et de permettre aux responsables d’avoir une vue d’ensemble
de l’activité traitée.
 BI: Apport

 Accroître les ventes

 Améliorer les relations avec le client
 Fabriquer de meilleurs produits
 Offrir de meilleurs services
 Rationaliser les opérations
 Réduire les coûts
 Prendre les meilleures décisions
 BI: Caractéristique

 Possibilité de poser une grande variété de questions au système,

certaines prévisibles et planifiées comme des tableaux de bord et
d'autres imprévisibles.

 Permettre à l'utilisateur d'effectuer les requêtes qu'il souhaite, par

lui-même, sans l'intervention de programmeur.

 Il sera souvent nécessaire de filtrer, d'agréger, de compter, sommer

et de réaliser des statistique (moyenne, écrat-type, ….)
 BI: Caractéristique

 Les transferts de données du système opérationnel Vers le système

décisionnel seront réguliers avec une périodicité bien choisie
dépendante de l'activité de l'entreprise.

 Chaque transfert sera contrôlé avant d'être diffusé.

 L'utilisation se résume donc à un chargement périodique, puis à des

interrogations non régulières, non prévisibles, parfois longues à
exécuter.
 Business Intelligence

Tout système d'information décisionnel (SI) telle que le

sont les data warehouses assurent quatre fonctions
fondamentales, à savoir la

 Collecte,
 L'intégration,
 La diffusion et
 La présentation des données.

À ces quatre fonctions s'ajoute une fonction de contrôle du SID lio

même (L’administration).
 Business Intelligence : Collecte

La collecte

La collecte des données (parfois appelée data pumping)

est l'ensemble des tâches consistant à détecter, à
sélectionner, à extraire et à filtrer les données brutes issues
des environnements pertinents compte tenu du périmètre
du SID.

Les sources de données internes et/ou externes étant souvent

hétérogènes tant sur le plan technique que sur le plan sémantique
(données complexes)

Elle s'appuie notamment sur des outils d'ETL (Extract-Transform-Load)

pour extraction, transformation et chargement de données.
 Business Intelligence : L’intégration

L’intégration

L’intégration des données, c'est-à-dire leur regroupement

en un ensemble technique, logique et sémantique
homogène approprié aux besoins de l'organisation ; elle
consiste à concentrer les données collectées dans un
espace unifié, dont le socle informatique essentiel est
l'entrepôt de données. Élément central du dispositif, il
permet aux applications décisionnelles de bénéficier
d'une source d'information commune, homogène,
normalisée et fiable, susceptible de masquer la diversité
de l'origine des données.
 Business Intelligence : Diffusion

La diffusion

La diffusion, ou la distribution d'informations élaborées à partir des

données dans des contextes appropriés aux besoins des individus ou
des groupes de travail utilisateurs. c'est-à-dire elle met les données à la
disposition des utilisateurs, selon des schémas correspondant au profil
ou au métier de chacun.
 Business Intelligence : Présentation

La présentation

Cette quatrième fonction, la plus visible pour l'utilisateur, régit les

conditions d'accès de l'utilisateur aux informations.

Elle assure le fonctionnement du poste de travail, le

contrôle d'accès, la prise en charge des requêtes, la
visualisation des résultats sous une forme ou une autre. Elle
utilise toutes les techniques de communication possibles
(outils bureautiques, requêteurs et générateurs d'états
spécialisés, infrastructure web, télécommunications
mobiles, etc.).
 Business Intelligence : Administration

L’administration

L’administration, qui gère le dictionnaire de données et le processus

d'alimentation de bout en bout, car le système
d’information décisionnelle doit être lui-même piloté. C'est
la fonction transversale qui supervise la bonne exécution
de toutes les autres. Elle pilote le processus de mise à jour
des données, la documentation sur les données (les méta
données), la sécurité, les sauvegardes, la gestion des
incidents.
 Business Intelligence

Remarque

En pratique, les fonctions de collecte et d'intégration sont étroitement

liées entre elles, et sont généralement associées au data warehouse.

De même, diffusion et présentation sont des fonctions fortement

"orientées sujet", tournées vers l'utilisateur et son métier, manipulant
des contenus à forte valeur ajoutée informationnelle et non des
données brutes; elles sont donc fortement imbriquées logiquement et
techniquement
Business Intelligence : Schéma global
 Business Intelligence : Data Warehouse

« Le data Warehouse est une collection de données

orientées sujet, intégrées, non volatiles et historisées,
organisées pour le support d’un processus d’aide à
la décision »

Principe : Mettre en place une base de données dédiées

pour les analyses.
 Business Intelligence : Caractéristique du DW

Il existe 5 caractéristiques des DW

 Orientées sujet
 Données intégrées
 Données non volatiles
 Données datées ,et historisées
 Données multidimensionnelles
 Business Intelligence : Pré-requis du DW

 Besoins fonctionnels
Expectations sur les données, sources de données, entretiens
avec les utilisateurs finaux, limites et complexités
 « Data Profiling »
Qualité, périmètre, contexte des sources de données, données
manquantes ou nulles, intervention humaine, suppression des
données, planification de développement pragmatiques.
 Business Intelligence : Pré-requis du DW

 Pré requis de sécurité

 Un paradoxe:
Entrepôt de données: publier largement les données
Sécurité: restriction des données pour ceux qui en auront besoin
 Sécurité pour les développeurs .
 Business Intelligence : Pré-requis technique du DW

 Architecture
 Outil ETL vs. développement spécifiques
 Processus en batch vs. Streaming des données
 Automatiser l’ordonnancement
 Qualité des données/Nettoyage des données
 Métadonnées
 Sécurité
 « Staging »
 Business Intelligence : Données opérationnelles

Les données ne sont pas simplement extraites

Données des systèmes opérationnels sont sévèrement non-intègre
 Même données, noms différents
 Même noms, données différentes
 Différents clés, mêmes données
 Codification des données non standardisées(male/female, 0/1,
etc)
 Différentes mesures, et mesures à différents niveaux de détails
 Système technologique sources différentes (DB2, SQL Server,
OS/390 DB2, etc)
Premier chargement, Chargement des deltas
 Business Intelligence : Les Datamarts

 Sous-ensemble d’un entrepôt de données

 Destiné à répondre aux besoins d’un secteur ou d’une fonction

particulière de l’entreprise

 Point de vue spécifique selon des critères métiers

 Business Intelligence : OLTP vs DW

OLTP DW

Orienté transaction Orienté analyse

Orienté application Orienté sujet

Données courantes Données historisées

Données détaillées Données agrégées

Données évolutives Données statiques

Utilisateurs nombreux, Utilisateurs peu nombreux,

administrateurs/opérationnels manager

Temps d’exécution: court Temps d’exécution: long

 Business Intelligence: Générations

 1ère génération de système décisionnel (Années 90)

◦ Architecture
BD
Sources Fichiers (Texte, Tableaux)

Définition optionnelle
Entrepôt

Magasin Tableaux croisés dynamiques

Magasin

Tableur
 Business Intelligence: Générations

1ère génération de système décisionnel.

 Exemples d’analyses décisionnelles
 Analyse des quantités de ventes mensuelles
 Analyse du montant des ventes mensuelles par zone
 Analyse des ventes mensuelles et journalières (en valeur et
quantité) des employés de la société
 Analyse des quantités vendues par client et par ville
 …
Business Intelligence: Générations

1ère génération de système décisionnel.

Création ED par exportation de tables Access dans Excel

Inconvénients :
• Exportation de la totalité de la table
• Impossibilité de faire des jointures entre tables
 Importation de tableaux Excel dans Access
Définitions des index si nécessaire
Définition de la clé primaire
 Écriture de la requête de jointure
Exportation vers Excel
• Création MD (tableau croisé dynamique)
 Business Intelligence: Générations

Zone (Tous) Magasin 1

Somme Vente Mois
Employé 1 2 5 9 10 12 Total
1 45 70 120 120 85 40 480
2 30 30 5 10 30 105
3 5 20 40 60 90 120 335
4 85 40 5 10 30 50 220
Total 165 160 170 200 235 210 1140

Mois (Tous) Magasin 2

Somme Vente Client
Zone Employé A B C D E F Total
NORD 2 105 105
3 55 280 335
Somme NORD 160 280 440
SUD 1 120 260 100 480
4 115 105 220
Somme SUD 120 260 215 105 700
Total 120 260 215 105 160 280 1140

Employé Zone Client Date Mois Vente

1 SUD B 17/09/2002 9 70
1 SUD B 16/05/2002 5 90 Inconvénient : pas de
1 SUD B 02/02/2002 2 60 manipulation possible
ED 1 SUD B 04/01/2002 1 40
 Business Intelligence: Générations

 2ème génération de système décisionnel

◦ fin années 90
BD
Sources Fichiers (Texte, Tableaux)

BD relationnelle
Entrepôt

Magasin Magasin Environnement

spécifique
(vue) (univers BO,…)

Requêteur graphique
SQL (BO, Impromptu,
Discoverer…)
Business Intelligence: Générations
 2ème génération de système décisionnel
◦ Exemple d’univers Business Object
 Business Intelligence: Générations
 3ème génération de système décisionnel
◦ années 2000
BD
Sources Fichiers (Texte, Tableaux)

BD (R, OO, OR)

Entrepôt +
Historisation

Magasin Magasin BD multidimensionnelles

Environnement
spécifique Magasin Outils OLAP (Power Play, Express,…)

Requêteur graphique
 Business Intelligence: Générations
 Exemple de source (relationnel)
 Objectif : "Analyse mensuelle des ventes de produits aux clients"

LIGNES_FACT
PRODUITS refF#
codeP codeP#
description qte
CATEGORIES prix_unit
codeCa codeCa#
designation FACTURES
codeCaSup# refF
dateF (jj-mm-aa) CLIENTS
codeC# codeC
nom
prenom
adr_lib
adr_ville
 Business Intelligence: Générations
 Exemple de source (relationnel)
LIGNES_FACT
PRODUITS refF#
codeP codeP# ventes mensuelles ?
description qte
CATEGORIES prix_unit
codeCa codeCa#
designation FACTURES
évolutions des prix ? refF
codeCaSup#
dateF (jj-mm-aa) CLIENTS
jour inutile codeC# codeC
 Inadéquations : adresse nom
détaillée prenom
Absence de connaissance inutile adr_lib
Information inutile pays ? adr_ville
Forme inadaptée
Non mise en évidence des analyses possibles
 Business Intelligence: Générations
 Exemple d'entrepôt (relationnel)
LIGNES_FACT
évolutions
HISTO_PRIX PRODUITS refF#
des prix
codeP# codeP codeP#
date (jj-mm-aa) CATEGORIES description qte
prix_unit codeCa prix_unit montant
designation CodeCa#
codeCaSup# FACTURES
CLIENTS ventes refF
codeC mensuelles
PAYS suppression dateF (mm-aa)
codeP de l'adresse nom codeC#
pays prenom suppression
pays
ville du jour
 Inadéquations codeP#
Absence de connaissance
Information inutile
Forme inadaptée, mais nombreuses jointures
Non mise en évidence des analyses possibles
Modélisation multidimensionnelle
Plan
Modélisation dimensionnelle
Faits & Dimensions
Hiérarchies
Modèle en flocon
Assemblage des modèles dimensionnels
Dimensions à évolutions lentes
Méthode de conception
 Modélisation multidimensionnelle

 La modélisation consiste à transformer les données sources en

structures logiques décisionnelles finalisées.
 La modélisation dimensionnelle diffère de la modélisation
entité/relation.
 C’est la seule technique fiable permettant de fournir des données
aux utilisateurs finaux dans le cadre d’un système décisionnel.
 Modélisation E/R

 La modélisation entité/relation est adaptée aux système OLTP.

 Elle vise à éliminer les redondances
 Il est bien adapté aux transactions
 Le modèle E/R et les système décisionnels

 Il faut l’éviter dans les systèmes décisionnels !!

 L’utilisateur ne peut ni lire ni intégrer un tel modèle
 Le modèle E/R n’est pas interrogeable par voie logicielle
 L’adoption d’un modèle E/R pour un système décisionnel aura des
conséquences catastrophiques au niveau des performances
 Modélisation multidimensionnelle

On peut définir cinq axes de qualification d’un modèle de données

dimensionnelle

 Lisibilité pour l’utilisateur final

 Performance au chargement des données
 Performance à l’exécution des requêtes
 L’administration des données
 L ’Evolutivité du modèle
 Modélisation multidimensionnelle : Lisibilité pour l’utilisateur final

 L’utilisateur final (analyste) doit pouvoir facilement manipuler les

données.

 Les données doivent être simples à comprendre, mais permettre

plusieurs analyses différentes selon des critères différents (dimensions)

 Plus le modèle est lisible (intuitif) pour les utilisateurs, moins sera
long (coûteux) de définir une sur couche pour le rendre
compréhensible
 Modélisation multidimensionnelle : Performance au chargement des
données

 Les entrepôts de données sont constitués de grosses quantités de

données.

 Les données sont souvent de sources hétérogènes

 Il est assez simple de charger dans une structure simple. Le

chargement nécessite souvent une transformation/filtrage des données
sources
 Modélisation multidimensionnelle : Performance à l ’exécution des
requêtes

 L ’exécution des requête doit être rapide pour les analystes

 On estime généralement 30 secondes comme un maximum

 Il est généralement nécessaire de créer des agrégations de données

et/ou des redondances
 Modélisation multidimensionnelle : L’administration des données

 L’administration du système est fondamentale

 La difficulté n’est pas tant de construire l’entrepôt mais de le faire

vivre.

 Maîtrise et industrialisation de l’extraction des données

 Modélisation multidimensionnelle : L ’Evolutivité du modèle

 Le développement de l’entrepôt est bien plus incrémental

qu’itératif.

 Chaque projet ne doit pas déboucher sur un modèle d’information

isolé des autres.
Modèle dimensionnel ou Schéma en étoile
 Table de faits

Une table de faits est une table qui contient les données à analyser.

Une table de fait est souvent reconnaissable par sa taille. En effet,

lorsqu'on visualise un schéma, c'est celle qui est au centre et
qui est la plus grande.

Ce type de table est aussi facilement reconnaissable car elle comporte
un grand nombre de clés étrangères afin de la lier avec des
tables de dimensions.
 Finesse ou grain de la table de faits

L'unité de temps la plus petite est appelée le grain/finesse de la table de

faits.

 Dans notre exemple, le grain est journalier.

 Pour connaître celui-ci, il suffit de consulter la table de dimension

Temps et de regarder la plus petite valeur (jour_de_semaine).
 Les faits

La table de faits peut aussicontenir des champs qui ne sont pas des clés
étrangères. Ce sont les faits (ou mesures).

 Une mesure est un indicateur d’analyse de type numérique et

cumulable
Les faits doivent être valorisés de façon continues et être additifs.

 Certains faits sont dérivés de faits élémentaires, on les nomme des

faits calculés.

 Ils doivent être pris en compte lors de la modélisation

 Ils peuvent être physiquement stockés ou non dans la tables
de faits.
 Faits semi-additifs et non additifs

 Il peut exister des faits semi-additifs et non additifs.

 Les faits semi-additifs peuvent être additionnés pour

certaines dimensions seulement

 Les faits non additifs ne peuvent être ajoutés.

Concepts de base

 Propriétés des mesures

 Additivité : somme sur toutes les mesures
• Exemple : CA ; Quantité vendue, ...
 Semi-additivité : somme sur certaine dimensions
• Exemple : nbre de contacts clients, Etats des stocks, ...
 Non-additivité : pas de somme , recalculer
• Exemple : encours moyen fin de mois, plus grand CA pour
l’ensemble des magasins
 Table de dimensions

 Dans un schéma, les tables qui entourent la table de fait sont

appelées tables de dimensions.

Une dimension est un axe d’analyse selon lequel sont visualisées les
mesures d’activité d’un sujet d’analyse.

 Ces tables sont composées d'attributs qui sont souvent de type

caractère.

 Ces attributs servent à stocker la description des dimensions et

sont utilisés comme source de contraintes et d'en-têtes de lignes
dans le jeu de réponses de l'utilisateur.
Table de dimensions : Exemple
 Modélisation possible dans un OLTP

SELECT *
FROM Locations, States, Countries
where Locations.State_Id = States.State_Id
AND Locations.Country_id=Countries.Country_Id
AND Country_Name='USA'
 Dimension de la zone géographique

Dim_id Loc_cd Name State_NM Country_NM

1001 IL01 Chicago Illinois USA
Loop
1002 IL02 Arlington Illinois USA
1003 NY01 Brooklyn New York USA
1004 TO01 Toronto Ontario Canada
1005 MX01 Mexico Distrito Mexico
City Federal

SELECT *
FROM Location_dim
where Country_Name='USA' Redondance
 Attributs ou Faits

Il est important de bien comprendre la différence entre un attribut et un

fait afin de placer ceux-ci dans les bonnes tables (dimensions|| faits).
On peut s ’inspirer des règles simples suivantes.
Relation entre schéma et reporting
 Dimension Temps

 Le DW est une série temporelle

 Conceptuellement nous n’avons pas besoin d ’une table de

dimension temps, les hiérarchies peuvent être obtenues avec des
fonctions à partir de date/heure.

 Pour des questions de performance il est préférable de créer une

table de dimension

 Avec un grain journalier, 10 ans d’exploitation -> ~3653 tup.

Dimension Temps

Dim_id Month Month- Quarter Quarter- Year

Name Name
1001 1 Jan 1 Q1 2005
1002 2 Feb 1 Q1 2005
1003 3 Mar 1 Q1 2005
1004 4 Apr 2 Q2 2005
1005 5 May 2 Q2 2005
 Dimension Produit

Prod_id Prod_cd Name Category

1001 STD Short-Term-Disability Disability
1002 LTD Long-Term Disability Disability
1003 GUL Group Universal Life Life
1004 PA Personal Accident Accident
1005 VADD Voluntary Accident Accident
Schémas en étoiles
 Schémas en étoiles

Sélectionner les mesures

SELECT P.Name, SUM(F.Sales)

JOIN la table de FAIT avec les Dimensions

FROM Sales F, Time T, Product P,
Location L
WHERE F.TM_Dim_Id = T.Dim_Id
AND F.PR_Dim_Id = P.Dim_Id
AND F.LOC_Dim_Id = L.Dim_Id

Filtrer les Dimensions

AND T.Month='Jan' AND T.Year='2003'
AND L.Country_Name='USA'

Avantages: ‘Group by' les niveaux d’agrégation

-Simple à comprendre
GROUP BY P.Category
-Plus performant
-extensible
Schémas en étoiles : Avantages et inconvénients

 Schéma en étoile
 Avantages
Facilité de navigation
Performances : nombre de jointures limité ; gestion des
données creuses.
Gestion des agrégats
Fiabilité des résultats
Simple à comprendre & extensible
 Inconvénients
Toutes les dimensions ne concernent pas les mesures
Redondances dans les dimensions
Alimentation complexe.
 Dimensions et hiérarchies

 Une dimension est un ensemble de valeur décomposable.

 Les valeurs d'une dimension sont généralement organisées à

l'intérieur d'une hiérarchie.
 Ex: jours, mois, trimestre, semestre, année, …

 L’accès au niveau supérieur dans une hiérarchie est appelé "rolling

up" et au niveau inférieur "drilling down"
 Exemple de hiérarchies

 Dimension de production
 Catégories,
 Département, etc.

 Dimension géographique,
 Villes
 Région
 Pays, etc.

 Dimension temporelle
 Années
 Trimestre
 Mois, etc.
Hiérarchie simple ou multiple
Exemple pour un suivi des ventes
Exemple pour une analyse des ventes
Exemple pour le pilotage des ventes
 Forage vers le haut ou vers le bas

A remarquer que le forage se fait dans une Hiérarchie

Si l’outil d’analyse du cube ne supporte pas les hiérarchies multiples, il

faudra créer autant de hiérarchies simples qu’il y a de hiérarchies dans la
hiérarchie multiple
 Exemple

Exemple

S = ('VAnalyse', F, < D1, D2, D3>)

F = ('VENTES', {montant, qte})
D1 = ('TEMPS', {codeT, num_mois, lib_mois, annee}, <H1>)
D2 = ('PRODUITS', {codeP, description, prix_unit, sous_categ, categorie},
<H2>)
D3 = ('CLIENTS', {codeC, nom, prenom, ville, pays}, <H3>)
H1 = ('H_AN', <codeT, num_mois, annee>, {(num_mois, lib_mois)})
H2 = ('H_PROD', <codeP,sous_categ, categorie>, {(codeP, description)})
H3 = ('H_CLI', <codeC, ville, pays>, {(codeC, nom),(codeC, prenom)})

 Merci de créer le modèle dimensionnel

Réponse
 Modélisation : Démarche à suivre

Schéma en étoile : modélisation conceptuelle spécifique

 Démarche de modélisation conceptuelle
 Définition de la structure du schéma
 Identification du fait
 Identification des dimensions

 Définition détaillée du fait : identification des mesures

(code, désignation, formule d’extraction…)

 Définition détaillée de chaque dimension :

 Identification des paramètres (nom, type…)
 Spécification des hiérarchies
 Connaissance précise d’un domaine (géographie…)
 Analyse des valeurs des sources (gamme, catégorie de
produits)

 Association des attributs faibles aux paramètres des hiérarchies

 Stockage des hiérarchies

 Une dimension hiérarchisée peut être stockée dans une table unique.

 Des attributs seront répétés, non respect des formes normales.

 On a un schéma en étoile
 Une dimension hiérarchisée peut être stockée dans n tables en
relation père-fils

 On parle de schéma en flocon

Schéma flocon
Schéma flocon
 Modèle en flocon

 Avantages
 Plus propre, respect de la 3NF
 Gain de place de stockage (!)
 Inconvénients
 Plus complexe pour l ’utilisateur final
 Plus de jointures, donc plus lent
 Selon les spécialistes :
 Evitez le « floconage » des dimensions, même si elles sont
grandes, car les performances seront mauvaises !
 Modèle dimensionnel et E/R

 Il est important de comprendre qu’un modèle E/R se décompose en

plusieurs schémas dimensionnels.

 On créera un modèle en étoile pour chaque « sujet » à analyser.

 Un entrepôt de données est constitué de plusieurs schémas en étoile

avec des dimensions communes

 Schéma en constellation
 Assemblage des modèles dimensionnels

 Une des questions critiques de la construction d’un système

décisionnel complet est la planification de la construction de l’entrepôt.

 Deux tendances extrémistes :

 Perspective centralisée et monolithique

 Construction de zones thématiques distinctes selon les besoins
ponctuels
 Perspective centralisée et monolithique

 Cette approche à peu de chances d’aboutir

 Le temps de développement d’un entrepôt est souvent de plusieurs

années/hommes !!

 Le résultat obtenu a beaucoup de chance de ne pas satisfaire les

utilisateurs.

 Effet « tuyau de poêle »

Construction de zone thématiques distincts selon les besoins ponctuels
 Approche itérative

 La pratique à démontré qu’une approche architecturale par étape est

la plus efficace.

 Les datamarts permettent d’éviter de devoir planifier tout l’entrepôt

de données, qui est une tâche quasi insurmontable.

 La création de l’entrepôt datamart par datamart risque de créer une

structure dimensionnelle incohérente.

 Il faut intégrer les datamarts dans l’entrepôt en définissant des

dimensions conformes et des faits standards
 Schéma constellation

 B . Schémas multidimensionnels
 Schéma en Constellation
n sujet d’analyse (Faits)
n axes d’analyse (Dimensions) pouvant être , partagés entre
les différents faits.
Avantages:
• Facilite les corrélation entre les différents sujets d’analyse
• Simplifie la modélisation avec la possibilité de partager les
dimensions.
Schéma en constellation
 Schéma constellation

Schéma en constellation :
 Généralisation des schémas en étoile
 Plusieurs faits et dimensions partagées ou non
 Consolidation des datamarts

 Une fois les datamarts recensés, il faut les consolider pour déterminer
les dimensions conformes et les faits standards

 L’utilisation d’une matrice permet d’identifier les dimensions

conformes, et celles qui sont importantes pour l’entrepôt.

 Matrice de l’architecture en bus de l’entrepôt

 Consolidation des datamarts

 On appel une dimension conforme, une dimension qui a la même

signification dans touts les tables de faits avec lesquelles elle peuvent
être liées.

 La responsabilité essentielle de la conception d’un entrepôt de

données consiste à établir, diffuser, maintenir et appliquer les dimensions
conformes.

 une dimension conforme est souvent un amalgame de

données provenant de plusieurs systèmes opérationnels, voir de
données externes
 Faits conformes

 Il est également nécessaire d’établir des faits (mesures) conformes

pour l’entrepôt.

 Par exemple un fait comme recette, bénéfice ou prix doit être

identique dans chaque datamart

 Même contexte dimensionnel

 Même unité de mesure

 Unités monétaires (Francs, Euro, monnaies étrangères !!)

 Attention par exemple, au conditionnement, boite, douzaine, kilo,…

 Dimension à évolution lente

 Chaque dimension est indépendante de toutes les autres, mais

parfois le contenu d'une dimension peut changer par rapport au temps.

 Le concepteur, doit admettre que les dimensions sont constantes

pour conserver une structure dimensionnelle indépendante.

 Cependant, il est parfois nécessaire de procéder à des ajouts

mineurs afin de se rendre compte du caractère évolutif de cette
dimension.

 Ces dimensions quasi constantes sont appelées "dimensions à

évolution lente".
 SCD : Slowly Changing Dimensions
 Dimension à évolution lente du premier type (SCD1)

Les anciennes valeurs ne sont pas conservées. La nouvelle valeur

remplace simplement l'ancienne.
 Dimension à évolution lente du second type (SCD2)

On conserve la situation initiale ainsi que la situation actuelle. On créera

alors un second enregistrement de la dimension avec la nouvelle valeur.

Ce deuxième tuple comporte évidemment une nouvelle clé.

 Dimension à évolution lente du troisième type (SCD3)

 Ajout de nouveaux champs pour l'attribut concerné. Il est aussi

possible d'ajouter un champ "Date d'effet".

 La valeur du nouvel attribut est écrasée et la valeur du champ

(Date d'effet) est mise à jour. Le contenu du champ d'origine
n'est jamais modifié.
 Dimension à évolution lente du troisième type (SCD3)

 Ajout de nouveaux champs pour l'attribut concerné. Il est aussi

possible d'ajouter un champ "Date d'effet".

 La valeur du nouvel attribut est écrasée et la valeur du champ

(Date d'effet) est mise à jour. Le contenu du champ d'origine
n'est jamais modifié.
 Grandes dimensions

 Il est possible qu’une dimension atteigne une très grande taille.

» Ex : Dimension humaine pour un pays : ~ 100’000’000
» Ex : Clients pour télécom : ~10’000’000
 Doit être particulièrement performante
 Navigation rapide dans la dimension
 Ne pas pénaliser la navigation dans la table de fait
 Pas de doublons

 La majorité des attributs sont moyennement intéressants pour

l’entrepôt.
 Nom ou prénom de clients ??
 Mini dimensions

 On peut éviter pas mal de problèmes des grandes dimensions et/ou

des dimensions à évolution lente par l’ajout de mini dimensions.

Par exemple :

 Etat civil, Sexe, niveaux d’âges,..

» Devraient être dans la dimension « client » mais bien

plus efficace si elles sont dans une (des) dimension(s)
séparée(s)
 Cas particulier : Table de fait sans faits

 Chaque table de faits comporte plusieurs champs de clés suivis de

champs de faits numériques, valorisés de façon continues et additifs.

 Il existe dans certains cas des tables de faits dans lesquelles il n'y a
pas de faits mesurés !

 Ces tables sont appelées table de faits sans fait.

 Tables de suivi d'événements
 Table de suivi d ’évènements

 Afin de pouvoir construire une situation il est nécessaire d'enregistrer

les occurrences de plusieurs dimensions simultanément

 Les événements sont souvent créés à partir de tables de faits

comportant un certains nombres de clés. Chaque clé représente la
participation de la dimension à l'événement.

 Ces tables d'événements n'ont généralement pas de faits

numériques évidents qui leur sont associés. C'est pour cette raison
qu'elles sont appelées tables de faits sans fait.
 Processus de conception

 Détermination du processus d’activité à modéliser

» C ’est le processus opérationnel de l ’organisation.

 Détermination du grain du processus d’activité

» Le grain est le niveau de détail atomique des données

 Détermination des dimensions applicables

» Le choix des dimension s ’accompagne des libellés

 Détermination des faits mesurés

 Principes de modélisation

 La première étape de la conception consiste à choisir les processus

d’activité à modéliser, sur la base d’une connaissance de l ’activité et des
sources de données disponibles.

 La modélisation doit transformer l’expression des besoins en un

schéma dimensionnel
 Définition du grain, étape 2

 La seconde étape de la conception est le choix du grain de la table de

faits pour chaque processus d’activité

 Un entrepôt de données exige presque toujours des

informations exprimées dans le grain le plus bas possible pour
chaque dimension.
 Normalisation

 La table de faits atteint naturellement un haut degré de normalisation

 Tout effort de normalisation des tables d ’une base de données
dimensionnelle afin d ’économiser l ’espace disque est une perte de
temps

Les tables de dimension ne doivent pas être normalisées mais rester des
tables plates

Des tables de dimensions normalisées ne sont plus navigables.

 Les dix décisions majeures

 Les processus , et partant, l ’identité des tables de faits

 Le grain de chaque table de faits
 Les dimensions de chaque table de faits
 Les faits, y compris les faits calculés
 Les attributs des dimensions,
» Avec des descriptions complètes et la terminologie adéquate
 Comment suivre les dimensions à évolution lente
 Les agrégats, et les mini-dimensions,
 Les modes de requêtes et autres décisions de stockages
 L ’étendue historique de la base de données
 Le délai pour le chargement et l’extraction des données
 Les interviews

 Interview des utilisateurs finaux

 Spécification des attentes des utilisateurs finaux.
 Prise de conscience des utilisateurs de la construction de
l’entrepôt.

 Interview des DBA

 Confrontation aux réalités des thèmes qui surgissent lors des
interview avec les utilisateurs finaux

 Analyse des structures et de la qualité effective des données

 Création de modèles réalistes

 Il est fondamental de se rappeler que l’entrepôt s’alimente par le

système OLTP.

 Il faut disposer de la source de données pour chaque attribut ou fait

du modèle

 C’est au moment de la modélisation qu’il faut s’assurer de la

disponibilité de ces données
Mapping
Business Intelligence
Sommaire
Outils ETL
Techniques
Méthodologies
Meilleurs pratiques
Alimentation des tables de dimension dans l’entrepôt de données
 Caractéristiques désirées pour une solution ETL

Un outil ETL est un outil qui lie les données d’une ou plusieurs sources,
transforme les données de façon à être compatible avec la destination, et
charge les données vers cette destination
 Solution ETL

 Exécution des procédures stockées à la source, avec possibilité de

filtrage
 Stocker les données extraites dans des tables temporaires à la source
 Génération de fichiers à partir de données source temporaire
 Transférer le fichier vers une destination
 Charger les données dans des tables temporaire dans la destination
 Exécuter des procédures stockées
 Injecter dans l’entrepôt les nouvelles valeurs.
 Support d’un nettoyage de données simple
 Logs warning/erreurs
 Acheter ou construire

 Les éditeurs d’ETL favorisent le processus de standardisation, réutilisation des

composants et des fonctions prédéfinis, minimisant le temps et le coût de
développement.

 Les outils ETL auto documentent les flux de chargement

 Plusieurs outils peuvent se connecter à une variété de sources (SGBD

relationnel, non relationnel, différent OS, ERP, PeopleSoft, etc) avec transparence
pour le développeur ETL.

 Outils ETL traitent les changements dans les systèmes sources, ce qui permet
une réduction dans l’effort du processus ETL et de sa maintenance

Les outils ETL rendent les processus d’extraction et de transformation plus

rigoureux

 Les prix des outils ETL n’ont pas vraiment chuté durant les dernières années,
mais ils permettent plus de fonctionnalités et de performances
 To stage or not to stage

Un conflit entre:

 Faire une extraction rapide des données des systèmes
opérationnels
 Avoir la possibilité de recommencer sans répéter le processus du
début
Raisons pour le « Staging »
 Tolérance aux fautes: « stage » les données dés qu’elles sont
extraites des systèmes sources et immédiatement après des
transformations majeures (nettoyage, transformation, etc).
 Backup: Permet de recharger l’entrepôt de données sans utiliser le
système source.
 Audit: lignage entre les données sources et les transformations
avant le chargement dans l’entrepôt de données
 Règles pour extraction

Utilisation des colonnes indexés

Prendre seulement les données dont on a besoin

Utilisation de « DISTINCT » avec modération

Utilisation de « SET » avec modération

Ne pas utiliser « NOT »

Ne pas utiliser les fonctions dans les clauses « where »

Ne pas utiliser les sous requêtes

 Règle générale

Quand une dimension est peuplée par plusieurs systèmes distincts, il est
important d'inclure l’identificateur unique de chacun de ces systèmes
dans la dimension cible de l'entrepôt de données. Ces identificateurs
peuvent être visualisées par des utilisateurs pour leur assurer que la
dimension reflète leurs données du système transactionnel.
Table Dimension
 Génération des clés pour les dimensions

 A travers les triggers dans le SGBD

 Lire la dernière valeur, générer une nouvelle clé, et créer
l’enregistrement
 Inconvénient de performances

 A travers un processus ETL , un outil ETL, ou une application tierce

 Une clé par dimension
 Maintenir une intégrité des clés à travers les environnements dev,
test et prod

 Utilisation des Smart Keys

 Concaténation des clés naturelles de la dimension à la sources
avec l’estampille de l’enregistrement à la source
 Granularité de la dimension

 Que représente la dimension

 Challenge: analyser les systèmes sources de façon à ce que un
ensemble de champs représente la dimension
 Vérifier qu’une source de données contient la granularité de la
dimension
 Rien ne doit être retourné par cette requête
 Si des valeurs sont retournés, les champs A, B, C ne représente pas
la dimension

select A, B, C, count(*)
from DimensionTableSource
group by A, B, C
having count(*) > 1
 Dimension date

Clé naturelle: un type de jour et une date complète

 Type de jour: type de date et de non-date tel les dates
inapplicables, corrompues ou même des dates futures
 Table de fait doit toujours pointer vers une date valide dans la
dimension, donc on doit avoir une date valide « NA »
Comment générer la clé?
 Entier?
 ou “20051010”  “10 Oct., 2005”? ( en réservant 9999999 pour
« NA »?)
 Même les entiers sont utilisées, avec les nombres triées (pour
permettre le partitionnement de la table de fait par temps)
 Sites Web

TDWI: http://www.tdwi.org/

Inmon: http://www.inmoncif.com/home/

Kimball: http://www.ralphkimball.com/