II.9. TABLE DE DIMENSION
Les tables de dimension sont des tables servant d'axes
d'analyse. On peut par exemple analyser les ventes (table de fait) suivant
l'axe des temps (table de dimension) pour indiquer par exemple pendant quel
trimestre de l'année les ventes ont explosé [5].
II.10. LES MESURES
Une mesure est une quantité présente dans la
table de fait qui permet de mesurer les faits. Par exemple, nombre de vente ou
prix unitaire sont des exemples des mesures, en outre les mesures sont en fait
les critères ou indicateurs que l'on veut étudier en fonction de
différents axes ou dimensions [5].
Mémoire KIAKA MUSITU Héritier Page 36
Conception d'un Datamart pour le pilotage du système de
gestion des impôts (cas de la DGI)
Page 37 sur 91
II.11. MODELES DE CONCEPTION D'UN ENTREPOT DE
DONNEES
II.11.1. 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.
La modélisation en étoile découle
naturellement du tableau ci-dessus, il en résulte le schéma
suivant:
Figure N°10 Modélisation en Etoile
Dans une modélisation 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 nos
analyses, on
Mémoire KIAKA MUSITU Héritier Page 37
Conception d'un Datamart pour le pilotage du système de
gestion des impôts (cas de la DGI)
Page 38 sur 91
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 montant des
ventes par vendeur, par client, ou le kilométrage pour un vendeur pour
un client donnée (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.
|