dashboarding &

data visualisation
pour l’entreprise

2023- ensias- bi&a - l.ben hiba

 61

data warehousing
Data Modeling

3. Identification des dimensions

• Les dimensions décrivent le “qui, quoi, où, quand, comment et pourquoi” d’un
processus métier.

• Les dimensions contiennent les attributs descriptifs utilisés par l’application BI

pour le filtrage et le groupements des faits

• Exemples de dimension: Temps, employé, article etc.

 62

data warehousing
Data Modeling

3. Identification des dimensions

• Structure table dimension: Clé primaire (== clé étrangère dans les tables de faits) +
attributs

• La clé primaire != clé métier (A part pour la dimension Temps)

Parfois la clé métier change également dans le temps. Dans ce cas, on a recours
à une clé durable (Durable super natural Key)
 63

data warehousing
Data Modeling

3. Identification des dimensions

• Dimensions dénormalisées: hiérarchies many-to-one à profondeur fixe sont

aplaties en une ligne de dimension

• Dimensions flocon: structure multi-niveau représentant la hiérarchie de la

dimension. La table de dimension de niveau hiérarchique le plus bas, dont la
granularité est la plus fine, est reliée à la table de fait

La dénormalisation permet une meilleure performance : simplicité et rapidité

Normalisation vs. Dénormalisation: meilleurs cas d’utilisation?

 64

data warehousing
Data Modeling

3. Identification des dimensions

• Dimensions dégénérées: N’est représentée que par une clé primaire au niveau de
la table de fait. Cette clé fait généralement référence à un identifiant de la
transaction dans la base opérationnelle ou ODS
 65

data warehousing
Data Modeling

3. Identification des dimensions

Dimension dégénérée : attributs dans la table

de faits == identifiant non cumulatif relatif à
un processus métier non couvert par le
modèle en question
 66

data warehousing
Data Modeling

3. Identification des dimensions

Dimension dégénérée
utilisée quand la
combinaison des clé
étrangères n’est pas unique
 67

data warehousing
Data Modeling

3. Identification des dimensions

• Dimension Temps: Généralement construite à l’avance. Elle est rattachée aux

tables de faits et permet la navigation selon la date, la semaine, le mois, la période
fiscale etc. (Granularité selon le besoin métier)

• La dimension temps a deux colonnes obligatoires: une clé primaire (généralement

sous forme d’un Integer YYYYMMDD) et la date complète (forme Date, utilisé par
l’ETL comme colonne look-up pour assigner les clés étrangères aux lignes de la
table de fait).
 68

data warehousing
Data Modeling

3. Identification des dimensions

• Dimension d’Audit: contient la métadata sur les chargements ETL effectués. Elle
permet de suivre la qualité des données (Erreurs etc.), les variables de
l’environnement, les versions du code ETL, timestamp de l’exécution etc.

• Une dimension audit est généralement attachée à chaque table de fait. Elle est
la dernière dimension à être mise-à-jour au niveau du processus ETL
 69

data warehousing
Data Modeling

3. Identification des dimensions

• La dimension Audit contient des variables d’environnement et des variables

relatives à la qualité des données

White Paper: An architecture for Data Quality

 70

data warehousing
Data Modeling

3. Identification des dimensions

• Slowly changing dimensions:

• Type 0: Nouvelle valeur écrase l’ancienne

• Type 1: Ajouter une nouvelle ligne (3 colonnes ajoutées)
• Type 2: Ajout d’un nouvel attribut gardant la version précédente (-1) de la
valeur
 71

data warehousing
Data Modeling

3. Identification des dimensions

Type 0

R. Sherman - Business Intelligence Guidebook From Data Integration to Analytics

 72

data warehousing
Data Modeling

3. Identification des dimensions

Type 1

R. Sherman - Business Intelligence Guidebook From Data Integration to Analytics

 73

data warehousing
Data Modeling

3. Identification des dimensions

Type 2

R. Sherman - Business Intelligence Guidebook From Data Integration to Analytics Présenter les autres types de SCD avec des exemples
 74

data warehousing
Data Modeling

3. Identification des dimensions

Les abréviations, les flags, les indicateurs opérationnels doivent être traduits dans
les tables de dimensions en des attributs textes significatifs

Les valeurs “NULL” dans les attributs de dimensions devront être remplacées par
un texte descriptif “Non-applicable” ou “Inconnu” afin d’éviter toute inconsistence
du traitement lors du groupement…
 75

data warehousing
Data Modeling

3. Identification des dimensions

• Dimensions choisies:
• Date
Quelles dimensions
• Article
• Magasin
choisir?
• Promotion
• Caissier
• Méthode of paiement
 76

data warehousing
Data Modeling

4. Identification des faits

• “Que mesure le processus métier étudié?” -> correspond à un événement

physique observable

• Les faits identifiés doivent avoir la granularité choisie dans l’étape 2.

• Les faits numériques peuvent être soit :

• additifs (e.g. Quantité commandée),
• semi-additifs: ne sont pas additifs par toutes les dimensions (e.g. montant des
comptes),
• non-additifs: ne sont additif sur aucune dimension (e.g. prix unitaire)
 77

data warehousing
Data Modeling

4. Identification des faits

• Structure de la table de faits: Clés étrangères des dimensions + mesures

• Il est possible d’avoir recours à une clé primaire spécifique à la table de faits (entier
automatiquement généré). Elle est utile pour retrouver les lignes de la table au cas
d’un processus de chargement interrompu, ou quand on veut remplacer les
updates de la table de faits en des insertions/suppressions, ou si la table de faits
contient des lignes qui sont parents de lignes dans une autre table de faits de
granularité plus fine.
 78

data warehousing
Data Modeling

4. Identification des faits

• Table de faits de transaction: repose sur la transaction du système opérationnel.

L’unicité de l'occurrence est marquée par l'unicité de son contexte (ensemble des
clés de dimensions)

• Table de faits périodique: image d'une table de faits de transaction à un moment

donné ou synthèse d'une table de faits de transaction à travers l'agrégation des
mesures sur ses dimensions.
 79

data warehousing
Data Modeling

4. Identification des faits

• Table de faits récapitulatif ou cumulée: contient les clés étrangères de dimensions

choisies et/ou réduites ainsi que des faits créés en sommant des mesures à partir
de tables de faits plus atomiques

Différences entre ces trois types de tables de fait et cas d’utilisation?

 80

data warehousing
Data Modeling

4. Identification des faits

• Les valeurs “NULL” doivent être évitées. Si le cas se pose, les dimensions devront
introduire des clés dummy représentant l’inconnu ou le non-applicable

Pour des besoins de comparaisons, les faits ayant le même nom doivent être
conformes sur l’ensemble du modèle (même définition technique)

• Il est possible d’avoir une table de faits sans faits (Factless Fact table). Celle-ci est
utilisée pour enregistrer qu’un événement s’est produit
 81

Source: Kimball & Ross (2002)

 82

data warehousing
Data Modeling

4. Identification des faits

• Faits choisis:
• Quantité vendue
• Prix par unité
Quelles
• Réduction
faits choisir?
• Prix payé Net
• Montant Réduction “étendue” = Quantité x
Réduction
• Montant Ventes “étendu” = Quantité x Prix payé
Net
 83

data warehousing
Data Modeling

Source: Kimball (2013)

 84

data warehousing
Data Modeling

Source: Kimball (2013)

 85

data warehousing
Data Modeling

Etablir la matrice multidimensionnelle

-> Modèle des données
 86

Source: Kimball (2013)

 87

Source: Kimball (2013)

 88

data warehousing
Data Modeling

Source: Kimball (2013)

 89

data warehousing
Etude de cas - Data Modeling
 90

data warehousing
Data Modeling

Règles d’Or

• Règle #1: Charger des données atomiques détaillées dans les structures
dimensionnelles

• Règle #2: Structurer les modèles dimensionnels autour des processus métier

• Règle #3: S’assurer que chaque table de fait a une dimension Temps qui y est
associée

The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence
 91

data warehousing
Data Modeling

Règles d’Or

• Règle #4: S’assurer que tous les faits d’une table de fait ont la même granularité ou
niveau de détail.
• Règle #5: Résoudre les problèmes des relations n-à-n entre la table de fait et les
dimensions

The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence
 92

data warehousing
Data Modeling

The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence
 93

data warehousing
Data Modeling

The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence
 94

data warehousing
Data Modeling

Règles d’Or

• Règle #4: S’assurer que tous les faits d’une table de fait ont la même granularité ou
niveau de détail.
• Règle #5: Résoudre les problèmes des relations n-à-n entre la table de fait et les
dimensions
• Règle #6: Résoudre les problèmes des relations n-à-1 dans les tables de
dimensions
• Règle #7: Stocker les labels utiles pour les rapports et filtrer les valeurs du domaine
dans les tables de dimension
The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence
 95

data warehousing
Data Modeling

Règles d’Or

• Règle #8: S’assurer que les tables de dimension utilisent des clés de substitution.

• Règle #9: Créer des dimensions conformes pour intégrer les données dans
l’ensemble de l’entreprise

• Règle #10: Equilibrer en continu les exigences métiers et les réalités pour livrer une
solution DW/BI acceptée par les utilisateurs finaux et qui supporte leur processus
de prise de décision

The Kimball Group Reader: Relentlessly Practical Tools for Data Warehousing and Business Intelligence
 96

data warehousing
Data Modeling

Cubes

Les cubes OLAP, structures dimensionnelles implémentées dans des BD multi-

dimensionnelles, sont optimisés pour un accès direct par les utilisateurs aux
mesures précalculées (précalcul des multiples combinaisons de valeurs des
dimensions et des faits)

• Avantages: vitesse et feedback instantané (slice/dice, drill-up/down)

• Limites: croissance exponentielle de la taille -> Problème de scalabilité,
compétences en MDX requises (vs. SQL)
 97

data warehousing
Data Modeling

Cubes

• Les cubes OLAP sont généralement établis lors de la dernière étape du

déploiement d’un système BI/DW

• Plusieurs configurations sont possibles:

• Schéma en étoile pour stocker les données atomiques, le cube joue le rôle
d’un datamart
• Schéma en étoile joue le rôle du data warehouse ou data mart et les cubes
ajoutent une couche pour “high-performance reporting”