Vous êtes sur la page 1sur 11

MODÉLISATION DIMENSIONNELLE 11

Classé dans : Aide à la décision — Sebastiao Correia 26 mai 2007 @ 22:26


 Imprimer ce billet

En général, lorsqu’il y a une relation de plusieurs-à-plusieurs entre deux groupes d’attributs de dimension, il est souhaitable
de séparer ces groupes dans deux dimensions distinctes. Cependant, lorsque le nombre de ligne est très petit, il est possible
de laisser ces groupes d’attributs dans une superdimension. Une superdimension est un peu une dimension fourre-tout. Cela
peut aussi s’avérer utiliser lorsque certains attributs renseignent sur la relation entre ces groupes d’attributs. C’est par
exemple le cas pour une superdimension regroupant un lieu d’origine et un lieu de destination. Plutôt que
faire deux vues sur une table lieu, une superdimension combinant l’origine et la destination permet d’ajouter l’information
sur la distance…

Concernant la gestion des calendriers par pays, une table Date déportée par pays est une façon de gérer les spécificités d’un
pays. Cette table est liée à une dimension conforme Date et à une clé primaire sur le pays.

L’heure peut être traitée comme un simple fait s’il n’y a pas de besoin d’analyser par période plus fine que la journée.

La gestion des fuseaux horaires nécessite de décrire les dates et heures dans un fuseau horaire de référence et dans le
fuseau horaire local.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 10
Classé dans : Aide à la décision — Sebastiao Correia 24 mai 2007 @ 20:47
 Imprimer ce billet

Le chapitre 10 propose de réviser un schéma existant. L’exercice est très instructif. Voici les points sur lesquels il faut être
attentif :

1. Trouver le niveau de granularité le plus bas, ce qui ne signifie pas la recherche des données les plus détaillées de
l’entreprise.
2. Vérifier que tous les faits additifs sont à la granularité définie pour la table de faits. Et éviter les cumuls car non
additifs.
3. Granularité des dimensions : chaque dimension associée à une table de faits doit prendre une seule valeur pour
chaque ligne de la table de faits. Chaque attribut de la dimension doit prendre une seule valeur par ligne de
dimension. Il faut dénormaliser les hiérarchies à l’intérieur de la dimension.
4. Dimension Date. Toujours bien préciser son rôle lorsqu’une table date générique est utilisée.
5. Éviter les colonnes représentant des périodes en dur dans la table de faits. Il vaut mieux avoir 12 lignes et une
dimension Mois plutôt que 12 colonnes les représentant.
6. Rechercher les dimensions qui devraient être dégénérées (cas d’une dimension ayant presque autant de ligne que
la table de faits).
7. Éviter les codes, utiliser des descriptions.
8. Utiliser des clés artificielles plutôt que les identifiants opérationnels pour toutes les dimensions.
9. Avoir un nombre de dimensions raisonnable, ni trop, ni trop peu.

La géographie peut être standardisée (adresse, point géographique x, y) et partagée en tant que dimension déportée. Il faut
cependant vérifier que le partage de cette table ait un intérêt (en diminuant le nombre de lignes par exemple) et que
l’utilisation des différentes vues sur cette dimension déportée restent performantes (cela dépendra du SGBD). Les outils de
SIG (Système d’Information Géographique) permettent de tirer un meilleur parti de ces données, en particulier en vue d’une
représentation sur une carte (des requêtes de type topologiques existent).

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 9
Classé dans : Aide à la décision — Sebastiao Correia 21 mai 2007 @ 21:35
 Imprimer ce billet

Ce chapitre se penche sur les services financiers.

Lorsque l’on a peu de dimensions, il faut vérifier que les dimensions suivantes sont présentes.

 L es dimensions causales telles que Promotion, Contrat, Affaires… qui renseignent sur la cause d’un événement.
 Les dimensions de dates multiples ou d’horodatage.
 Les dimensions dégénérées (DD) telles que N° de facture… qui identifient une ligne de la table de faits.
 Les dimensions à jeu de rôles qui apparaissent lorsqu’une dimension est utilisée plusieurs fois.
 Les dimensions d’état telles que l’état d’un compte, qui identifient l’état actuel d’une transaction ou d’un
instantané mensuel.
 Les dimensions audit pour suivre l’origine et la qualité des données
 Les dimensions fourre-tout qui regroupent indicateurs et drapeaux corrélés.

Ces dimensions peuvent être ajoutées au modèle sans rien perturber. Elles ne modifient pas les clés des dimensions
existantes ni les faits mesurés, ni le grain de la table de faits.

En fait, « tout attribut descriptif ayant une seule valeur pour différentes mesures de la table de faits est susceptible d’être
ajouté à une dimension existante ou de devenir lui-même une dimension. »

Les banques étudient les relations entre les comptes et les foyers. Pour cela elles peuvent utiliser des algorithmes complexes
de rapprochement. Pour autant, les comptes et les foyers sont séparés en deux dimensions distinctes (car ils sont variables
mais leur variation n’est pas trop corrélée). La relation entre comptes et foyers passe donc par la table de faits, ce qui évite
de gérer l’évolution de ces dimensions avec l’approche de type 2.

Pour traiter les dimensions à valeurs multiples, il faut utiliser une table passerelle pour relier les diverses valeurs d’attribut à
la dimension. Par exemple, un compte bancaire peut avoir un ou plusieurs titulaires. La dimension client est liée à la
dimension compte par l’intermédiaire d’une table passerelle. Le compte lui est lié à la table de faits. La dimension client
évoluant rapidement, il est nécessaire de créer des mini-dimensions qui regroupent des attributs corrélés (notation
mensuelle de crédit, données démographiques…). Pour éviter un trop grand nombre de lignes dans les mini-dimensions, il est
conseillé d’utiliser des plages de valeurs d’attributs. Dans certains cas, on peut conserver la valeur exacte de l’attribut dans
la table de faits.

Pour créer des plages de valeurs d’attributs, on peut employer une table définissant ces plages avec : une clé pour le groupe
de plages, une clé pour l’ordre de tri du groupe, le nom du groupe, le nom de la plage de valeurs, la valeur inférieure et la
valeur supérieure. La jointure avec la table de faits est double (ex. : FAITS.solde >= PLAGE.valeur_inférieure AND
FAITS.solde < PLAGE.valeur_supérieure).

Lorsque l’on veut analyser des produits différents ; il est nécessaire d’avoir une table de faits centrale permettant l’analyse
indépendamment des produits (à partir de leurs caractéristiques communes) et des tables de faits sur mesure pour analyser
les faits selon les attributs spécifiques à des produits particuliers. On peut utiliser une table déportée de la dimension
produit pour stocker les attributs spécifiques et laisser les attributs communs à tous les produits dans la dimension produit.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 8
Classé dans : Aide à la décision — Sebastiao Correia 11 mai 2007 @ 14:28
 Imprimer ce billet

Gestion de ressources humaines.

Les questions que l’on peut se poser concernant les employés d’une entreprise peuvent être très complexes. Pour pouvoir y
répondre, il faut construire une table de faits au grain de la transaction employé. Cette table peut ne pas avoir de faits (i.e.
pas de valeur numérique).
La dimension Date et Heure est supposée suffisamment fine pour qu’une ligne de transaction soit identifiée par ses
dimensions (employé, type de transaction, date, heure).
Suite à une transaction employé, son profil change et le changement doit être répercuté dans la dimension Employé. Comme
chaque ligne de transaction ajoutera une ligne dans la dimension, il est plus judicieux de mettre les transactions dans la
dimension et d’oublier la table de faits.
Pour chaque ligne, il faut indiquer une date de fin de transaction qui permet de connaître facilement la période de validité
d’un profil. Il faut éviter de mettre null, il vaut mieux mettre une date dans le futur pour la dernière transaction et une
colonne supplémentaire avec un indicateur de validité actuelle permettant de trouver immédiatement le profil actuel.
Pour les dimensions à évolution lentes de type 2, il est conseillé d’horodater la prise d’effet et l’expiration et d’avoir un
indicateur de « ligne courante ».
La table de faits sera un instantané périodique mensuel dans lequel on peut cumuler le nombre de jours de congés acquis,
utilisés, le nombre de promotions…
A cette table de faits, on peut ajouter une dimension Audit qui nous dira pour chaque ligne la provenance des données, la
confiance dans les données. Cette dimension contient en fait des méta-données.

Pour grouper les employés selon leur compétence, on peut utiliser une table de dimension déportée stockant des mots-clés
représentant leur compétence.
Pour les employés à compétence multiple, le langage SQL ne permet pas simplement de gérer des contraintes sur plusieurs
lignes. Il faut donc utiliser UNION et INTERSECTION. UNION permet d’avoir les employés ayant l’une OU l’autre des
compétences. INTERSECTION donne ceux qui ont l’une ET l’autre des compétences.
Une autre façon d’obtenir ce résultat est de définir une seule ligne pour chaque groupe de compétences avec une colonne
contenant une liste des mots-clés concaténés séparés par \. Le SQL serait alors simplement

SELECT … WHERE liste_aptitudes LIKE ‘%unix%’


| OR |
| AND | liste_aptitudes LIKE ‘%linux%’
La recherche avec % en début de chaîne étant coûteuse, il faut éviter cette méthode sur de trop grandes tables.

Un questionnaire d’enquête a une table de faits contenant les réponses pour chaque (dimension) « date d’envoi du
questionnaire », « date de réception du questionnaire », employé évalué, employé répondant au questionnaire, type de
réponse.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 7
Classé dans : Aide à la décision — Sebastiao Correia 29 mars 2007 @ 22:14
 Imprimer ce billet

Ce chapitre porte sur la comptabilité générale.


En général, il faut deux tables de faits pour les transactions et les instantanés périodiques de clôture de période.

Instantané périodique.
Bien que semi-additif, le solde de fin de période doit figurer dans la table de faits pour éviter d’avoir à le recalculer en
remontant à l’origine des temps.
Par contre, les totaux sur une période à la date du jour doivent être calculés et non pas stockés dans la table de faits.

Si différentes devises sont utilisées, il faut ajouter la dimension Monnaie et mettre dans la table de faits les montants dans la
monnaie locale et dans la monnaie officielle de l’entreprise.

Transactions de journaux de comptabilité générale.


Les faits sont les crédits et débits. Cette table peut avoir besoin de plusieurs calendriers comptables, si les filiales ne se
basent pas sur les mêmes périodes comptables par exemple.

Budget.
Pour gérer le budget et pouvoir le comparer avec les dépenses, on créé une table de faits (additifs) donnant le montant
budgété net et ses changements (relatifs pour rester additifs) éventuels en cours d’année. Les dimensions peuvent être la
Date d’effet, le compte de comptabilité générale, la ligne d’articles de buget, la hiérarchie de l’entreprise…
Le livre « Data Warehouse Design Solutions » (Wiley, 1998) de Chris Adamson et Mike Venerable est recommandé pour son
étude complète sur la chaîne budgétaire.

Table de faits consolidés (ou tables de faits de second niveau).


Ces tables de faits permettent de rapprocher des faits différents dans une même table. La contrainte est que la granularité
est définie par le plus petit grain commun aux différents faits. De même les dimensions d’une table de faits consolidés
doivent être les dimensions communes aux différents faits.
Il ne faut pas chercher à rendre des faits plus fins que prévus, ni à ajouter des dimensions artificielles pour forcer à garder
un grain fin. Il peut s’avérer nécessaire d’agréger des données en supprimant des dimensions ou en passant à un grain plus
gros.

Pour l’analyse financière, il existe des produits OLAP bien adaptés, mais leur intégration dans un entrepôt de données global
nécessite toujours une mise en conformité des dimensions.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 6
Classé dans : Aide à la décision — Sebastiao Correia 17 février 2007 @ 23:44
 Imprimer ce billet

Le chapitre 6 traite de la relation client qui est devenue centrale pour l’entreprise ces dernières années. La GRC (Gestion
des Relations Client) ou CRM (Customer Relationship Management) nécessite de définir précisément une dimension client
conforme. Il existe des solutions GRC clés en main, mais celles-ci doivent s’intégrer à l’informatique de l’entreprise si on ne
veut pas qu’elle devienne simplement une source supplémentaire d’informations incohérentes.

La dimension client est généralement très complexe. Elle peut être énorme : plusieurs centaines de milliers de lignes et
plusieurs milliers d’attributs.

Concernant les noms et adresses, ceux-ci doivent être stockés à l’aide des « briques » les plus élémentaires possibles (par ex.
: n° de rue, nom de rue, type de voie, boite postale, bâtiment…). La gestion de l’internationalisation est très complexe. Elle
est traitée par Toby Atkinson dans « Merriam Webster’s Guide to International Business Communications » (Merriam-Webster,
1999).

Les clients ont également beaucoup d’attributs date (date de 1er achat, date de dernier achat, date de naissance…) qui
doivent utiliser la dimension Date déjà vue, à l’aide de copies. La dimension Date jointe à la dimension Client est une
dimension dite déportée, qui se justifie du fait de la taille de la dimension Client.

Parmi les attributs des clients, on trouve les attributs de segmentation (sexe, âge, score indiquant le comportement,…), les
attributs représentant des faits agrégés (total des dépenses…).

Une autre dimension déportée comme la géographie peut aussi être justifiée par la relative indépendance par rapport au
client. On obtient alors un modèle en flocons de neige.

Les dimensions Client sont souvent des « grandes dimensions à changement rapide ». Pour gérer ce type de dimension, on
crée une ou plusieurs minidimensions, chargées de stocker les attributs variant souvent ou fréquemment analysés, comme
l’âge, le salaire… Concernant les attributs variant de façon continue, comme le salaire, il faut stocker dans la minidimension
des tranches de salaire seulement, quitte à laisser le salaire exact dans la table de faits. La table de faits se voit ajouter une
clé étrangère pointant sur la minidimension. S’il y a besoin d’analyser les clients en fonction d’attributs de la minidimension,
alors on peut faire une dimension déportée (en faisant une jointure avec la table client) en plus d’une minidimension (jointe
sur la table de faits). Cependant la clé externe dans la dimension Client doit être de type 1 (i.e. écrasée à chaque
changement).
Les minidimensions doivent éviter de dépasser les 100.000 lignes.
Dans le cas où les clients ont une structure hiérarchique récursive de profondeur variable, il est possible d’utiliser une table
passerelle gérant les liens entre les clients.

Cette approche permet d’utiliser le SQL standard pour les groupements et cumuls, mais il est souhaitable d’utiliser des outils
OLAP non relationnels pour simplifier les requêtes. « Cette approche tente de rapprocher deux structures intrinsèquement
différentes, [... cela] revient à mélanger de l’huile et de l’eau. »

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 5
Classé dans : Aide à la décision — Sebastiao Correia 7 décembre 2006 @ 23:19
 Imprimer ce billet

Notion de jeux de rôles : si la date apparaît plusieurs fois dans une ligne de la table de faits, il faut créer des vues
différentes de la table Date, en prenant soin de nommer différemment à la fois la table et les colonnes (par ex. « jour de
commande » et « jour de livraison »…).

Concernant la dimension Produit qui est très courante, ses caractéristiques sont :

 un grand nombre de colonnes de texte descriptives.


 une ou plusieurs hiérarchies en plus d’un grand nombre d’attributs non hiérarchisés.

Cette dimension peut posséder plusieurs milliers de lignes et quelques précautions doivent être prises lors de la création de
cette table à partir d’un fichier maître.

 Faire correspondre à la clé Produit opérationnelle une clé Produit artificielle.


 Insérer des séquences de texte lisibles remplaçant ou complétant les codes numériques du fichier maître Produit
opérationnel.
 Contrôler tous les champs de texte pour éviter les erreurs d’orthographe, de valeurs impossibles ou des versions
différentes du même attribut.
 Documenter les définitions, les interprétations et les sources des attributs des produits dans les métadonnées de
l’entrepôt.

La dimension adresse de livraison.

Il est normal d’avoir plusieurs hiérarchies indépendantes dans cette table. Une hiérarchie naturelle est la hiérarchie
géographique avec le pays, la région, le département, la ville, le lieu. Une autre hiérarchie possible est une hiérarchie par
entreprise (une adresse de facturation peut regrouper plusieurs adresses de livraison). Les différentes hiérarchies peuvent
avoir différents niveaux. Il peut arriver que la relation entre adresse de facturation et de livraison ne soit pas strictement
hiérarchique (i.e. plusieurs factures pour une livraison). Dans ce cas, le grain de la table de dimension peut être affiné au
niveau de la combinaison adresse de facturation/adresse de livraison, si cette relation non strictement hiérarchique reste
exceptionnelle.

Sinon, il est préférable de définir une dimension supplémentaire « Adresse de facturation ». Il est inutile de créer une table
portant les relations entre les deux dimensions, la table de faits porte déjà cette relation et répond efficacement à la
question des corrélations entre dimensions.

La dimension dégénérée du numéro de commande n’est reliée à aucune table de dimension (c’est le propre d’une
dimension dégénérée) car toutes les informations de la commande sont conservées dans les autres dimensions. Par contre,
elle peut servir à regrouper les articles commandés ensembles. D’une façon générale, les dimensions dégénérées sont
réservées à l’identification des transactions. Elles ne doivent surtout pas servir à stocker un code sans que sa réelle
signification soit décrite dans une autre table.

La dimension fourre-tout (junk dimension) sert à stocker les différents indicateurs et drapeaux (flags) trouvés dans les
données opérationnelles. Eventuellement, si le nombre de lignes est conséquent, on pourra créer plusieurs dimensions
fourre-tout. Cette dimension soulage la table de faits et évite aussi la création d’un trop grand nombre de dimensions pour
gérer ces indicateurs. On peut aussi créer une dimension fourre-tout pour stocker les commentaires trouvés dans les
données.

Les devises multiples peuvent être gérées facilement à l’aide d’une table de conversion stockant les changes chaque jour et
en ajoutant une dimension Monnaie (par pays).

Les faits de granularité différente ne doivent jamais être mélangés dans une même table de faits. Ou bien il faut répartir
les faits de plus haut niveau au niveau le plus fin, ou bien il faut les mettre dans des tables de faits séparées. La première
solution est la meilleure car elle permet la navigation entre les niveaux ; mais elle nécessite de définir les modalités
d’allocation (activity based costing). Cette allocation sur le niveau de détail devrait être faite par une équipe dédiée plus
fonctionnelle et non par les développeurs de l’entrepôt.

La facturation est le processus idéal pour commencer un entrepôt de données dans les sociétés qui expédient des produits ou
vendent des services. Une table de faits detransactions de facturation est une des tables les plus puissantes de l’entreprise.
Elle combine les clients, les produits et les composantes de la rentabilité.

Une table de faits des instantanés récapitulatifs voit ses lignes régulièrement mises à jour, contrairement aux autres tables
de faits. Ce type de table de faits est mieux adapté aux processus de courte durée de vie ayant un identifiant du début à la
fin.
Gestion des unités de mesure : s’il existe différentes unités de mesure comme par exemple le nombre de produits, le
nombre de cartons, le nombre de palettes, etc. alors il est conseillé de stocker les différents facteurs de conversion dans la
table de faits directement et non dans une dimension. La gestion des changements de facteur s’en trouve simplifiée.

Il me semble qu’il est aussi possible de stocker directement les quantités (dans les différentes unités de mesure) plutôt que
les facteurs. Mais alors l’étude des changements de facteurs (qui représentent des changements de conteneurs) est plus
difficile. Le facteur de conversion apparaît donc plus fondamental ici.

Comparaison des 3 types de table de faits.

Grain de Grain de l’instantané Grain de l’instantané


Caractéristiques
transaction périodique récapitulatif
Periode de temps Point dans le Intervalles réguliers Durée indéterminée,
représentée temps prévisibles généralement courte
Une ligne par Une ligne pour la vie de
Grain Une ligne par période
événement l’entité
Chargement de la
Insertion Insertion Insertion et mise à jour
table de faits
Mises à jour de la Pas de mise à mise à jour pour chaque
Pas de mise à jour
table de faits jour activité
Date de la Dates multiples pour des
Dimension date Date de la fin de période
transaction étapes standard
Activité de la Performance dans un Performance sur une
Faits
transaction intervalle prédéfini durée de vie limitée

Les tables de transactions seules ne peuvent pas offrir des modèles dimensionnels efficaces. Elles stockent toutes les
transactions.

Les tables de faits instantanés périodiques résument les faits à la fin d’une période (la journée souvent). Elles facilitent le
suivi de l’évolution de l’activité.

Les tables de faits instantanés récapitulatifs couvrent un laps de temps indéterminé, correspondant à la durée de vie de la
transaction de produit. Cette table possède souvent une colonne « date de mise à jour de la ligne ».

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 4
Classé dans : Aide à la décision — Sebastiao Correia 30 novembre 2006 @ 23:17
 Imprimer ce billet

Le chapitre 4 aborde les questions à se poser pour modéliser la ou les tables de faits et présente différentes façons de gérer
les changements dans les dimensions.

Comment choisir s’il est utile ou non de créer plusieurs tables de faits ? Les questions suivantes peuvent orienter le choix :

 Quels sont les besoins d’analyse de l’utilisateur ?


 Les processus sont-ils distincts ou n’y a-t-il qu’un processus ?
 Les données proviennent-elles de plusieurs applications ?
 Les dimensions sont-elles différentes selon les types de fait ?
Prise en considération de l’évolution lente des dimensions
Il y a 3 techniques et 2 approches hybrides :

1. Ecraser la valeur de l’attribut ayant été modifié. Cette solution est valable pour des modifications de type
correction. Elle ne conserve aucune trace du changement. Attention, elle nécessite un recalcul des agrégats
éventuels.
2. Ajouter une ligne dans la table dimension avec une clé artificielle différente (mais conservant le code identifiant la
dimension, par ex. le code produit dans le cas d’une dimension produit). C’est la principale technique permettant
de suivre correctement les attributs des dimensions à évolution lente. Il est possible d’ajouter une date d’effet
et/ou une date d’expiration de la ligne, mais elles ne sont pas nécessaires. Grâce à un calcul de CRC, il est
possible d’enregistrer automatiquement les changements d’une ligne sans avoir à comparer dans le détail chaque
champ. Cette technique est cependant difficilement applicable si la table de dimension a déjà plus d’un million de
lignes.
3. Ajouter une colonne de dimension contenant l’état antérieur à la modification. Cette solution est intéressante si
on veut pouvoir coparer l’effet du changement avec l’ancien état (cas d’un changement de secteur vendeur par
ex.). Mais elle n’est pas adaptée s’il y a beaucoup de changements.

Outre ces 3 techniques, il y a 2 autres techniques hybrides utilisables lors de

1. changements prévisibles. Dans ce cas et si l’on souhaite calculer les états selon les différents changements mais
sans la segmentation temporelle (par ex. étudier les effets des différentes définitions des secteurs vendeurs), alors
il faut ajouter une colonne selon la technique 3 pour chaque changement.
2. changements imprévisibles avec application aux données antérieures de la version actuelle de l’attribut modifié.
L’intérêt est de préserver la vision exacte du passé en gardant la possibilité de présenter les données antérieures
selon les valeurs actuelles de l’attribut modifié. Cette approche mélange les techniques 1, 2 et 3.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 3
Classé dans : Aide à la décision — Sebastiao Correia 23 novembre 2006 @ 21:32
 Imprimer ce billet

On s’intéresse ici à la chaîne de valeur, aux différents modèles de stocks et à l’architecture de bus entre autres choses.

La chaîne de valeur décrit le flux logique des activités principales d’une organisation. Par exemple, pour un ditributeur, on
peut avoir la chaîne de valeur suivante :

Commande émise par le détaillant -> livraison à l’entrepôt du détaillant -> stock de l’entrepôt du détaillant -> livraisons aux
mag. de détail -> stock du mag. de détail -> ventes mag. de détail.

Alors que le chapitre 2 du livre traitait des ventes de produits (à l’aide de faits additifs), le présent chapitre traite de la
gestion de stocks. Dans ce processus, les stocks d’hier ne sont pas nécessairement complètement différents des stocks
d’aujourd’hui. Dans un instantané de stocks, les faits de stock (par ex. valeur au coût en euros) sont dits semi-additifs, car
ils ne sont pas additifs selon toutes les dimensions.

Toutes les mesures enregistrant un niveau à un moment donné (niveaux de stock, solde de compte et mesures d’intensité
telles que des températures) sont intrinsèquement non additives sur les dimensions date et éventuellement sur d’autres
dimensions. De telles mesures peuvent être agrégées utilement dans le temps, par exemple, en faisant la moyenne des
différentes périodes.

Des quantités non additives ne sont pas stockées dans la table de faits. Par exemple le retour de marge brute sur stock
(RMBSS) qui mesure la qualité de l’investissement de l’entreprise dans ses stocks n’est pas stocké dans la table de faits, mais
les informations permettant de le calculer sont stockées.

Une autre façon de modéliser les stocks est via une table de transactions de stock. Seule une table de faits au grain de la
transaction permet de répondre à des questions très fines comme celles portant sur le nombre de produits mis dans un casier
puis prélevés le même jour ou encore les produits renvoyés au fournisseur…
Cependant, ce type de table ne suffit pas pour toutes les analyses même si en théorie, il est possible de retrouver les cumuls
des stocks.

Un 3ième type de table de faits de stock est l’instantané récapitulatif. La table de faits a de multiples clés externes basées
sur des dates dans une ligne qui récapitule la vie du produit.
Un bus d’entreprise est indispensable à la construction d’un entrepôt de données. Il permet de réaliser les différents
marchés d’infos à différents moments par différentes équipes de développement.
La matrice de bus est le document le plus important de la phase amont de la réalisation d’un entrepôt. Les lignes de cette
matrice sont les processus de l’entreprise, les colonnes sont les dimensions. En lisant une ligne, on a toutes les dimensions
d’un processus. En lisant une colonne, on a les dimensions partagées entre les processus et donc les interactions entre
processus. Ce document peut servir en fait à la conception de l’ensemble de l’entrepôt, à la gestion du projet et à la
communication.
Sans ce document pour assurer une cohérence globale, il est fort probable que chaque marché d’infos devienne incompatible
avec les autres.

Le forage transverse (drill accross) devient possible lorsque plusieurs tables de faits partagent des dimensions.
Pour être partagée entre différents marchés d’infos, une dimension doit être conformes, i.e. « identique à la dimension la
plus granulaire et la plus détaillée » (ou un sous-ensemble strict de cette dernière) avec les mêmes clés de dimension et les
mêmes noms de colonnes d’attributs. Pour partager des dimensions, l’organisation doit définir un groupe de personnes
(une autorité de dimension) pour gérer et diffuser les dimensions conformes (à l’aide d’une publication de type push pour
garantir la cohérence au sein de l’entreprise).

Outre cette mise en conformité des dimensions (qui représente 90% du travail), il y a aussi la mise en conformité des faits.
En particulier, il est crucial que des faits conformes aient le nom si et seulement s’ils ont la même interprétation.

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

MODÉLISATION DIMENSIONNELLE 2
Classé dans : Aide à la décision — Sebastiao Correia 21 novembre 2006 @ 23:48
 Imprimer ce billet

Nous allons voir maintenant le processus de modélisation dimensionnelle en 4 étapes.

1. Sélectionner le processus d’entreprise à modéliser. Le but étant de servir l’utilisateur et que celui-ci utilise
l’entrepôt de données pour ses questions, le premier modèle dimensionnel à construire doit répondre aux questions
les plus pressantes de l’utilisateur et les données doivent être les plus faciles à extraire.
2. Déclaration du grain. Il faut utiliser les données les plus atomiques à notre disposition. Ne pas agréger les données
en faisant des sommes et en perdant de la finesse et de l’information. Le but n’est pas de présenter à l’utilisateur
tous les détails du processus, mais de lui offrir la possibilité d’analyser aussi facilement que possible selon diverses
manières, à l’aide de coupes en tranches et en dés du cube de données.
3. Identification des dimensions. « L’énoncé précis du grain détermine les dimensions principales de la table de
faits. » D’autres dimensions peuvent être ajoutées si elles ne prennent qu’une seule valeur pour chaque
combinaison des dimensions élémentaires.
4. Identifications des faits. Les faits sont des quantités numériques généralement additives. Les pourcentages, les
ratios sont des données non additives.et doivent être stockées dans la table de faits en séparant numérateur et
dénominateur pour n’avoir que des quantités additives.

La dimension date apparaît dans quasiment tous les entrepôts de données. Si la table contient les jours des 10 ans à venir,
son nombre de lignes est de 3650 seulement. C’est donc une dimension relativement petite. Ses attributs peuvent être : une
clé primaire entière, la date, la description textuelle de la date, le jour de la semaine, les n° de jour, de semaine et de mois
dans l’époque, les n° de jour dans le mois calendrier, dans l’année calendrier, le nom du mois, le n° du mois dans l’année,
le trimestre, l’année, des indicateurs de jour férié, de jour de semaine, une saison particulière pour l’entreprise, un
événement majeur…

Pour gérer l’heure de la journée, il est préférable d’ajouter une table de dimension supplémentaire, et de ne pas les
mettre dans la table date qui aurait alors 5 256 000 lignes !

Il y a plusieurs intérêts à prendre une clé primaire entière : étant utilisée dans la jointure avec la table de faits, plus la clé
est petite, plus on économise de la place dans la table de faits (4 octets économisés sur 1 milliard de lignes fait 4Go
d’économie !). Cela permet aussi de traiter l’absence de date avec une clé particulière plutôt qu’une valeur nulle. D’une
façon générale, il faut éviter les clés null dans la table de faits. Pour indiquer qu’une dimension ne s’applique pas à un fait,
il est conseillé d’ajouter une ligne particulière dans la table dimension (ex. : ajouter une ligne pas de promotion dans la
dimension promotion).
Les tables dimensions étant de petites tailles, leurs attributs doivent être autant que possible des champs en texte clair et
non des codes (qu’il faut ensuite décodés ou que l’utilisateur doit connaître et se souvenir). Il n’y a aucun besoin d’économie
de place dans les tables dimensions.
Pour analyser ses données, l’utilisateur pratique le forage (datamining). Un forage vers le bas dans un marché d’informations
consiste à ajouter des intitulés (valeurs de champ) de la table de dimension dans la requête. Le forage vers le haut est
l’inverse : retirer des intitulés. Le forage permet une navigation dans une hiérarchie.

« Il est courant de représenter de multiples hiérarchies dans une table de dimension. »

Dimension dégénérée : cette notion apparaît lorsqu’un champ de la table de faits permettant d’identifier de façon unique
une ligne (ex. n° de facture ou de commande). Ces numéros d’identification opérationnels sont les clés de dimensions vides,
c-à-d ne pointant pas sur une table de dimension. La dimension engendrée par ces clés est dite dégénérée.

Voici différents cas d’extension du modèle dimensionnel :

1. Ajout de nouveaux attributs de dimension (nouvelles colonnes dans la table dimension). Les applications
existantes requêtant sur l’entrepôt de données ne sont pas impactées. Si ces nouveaux attributs ne sont
disponibles qu’à partir d’une date donnée, il convient de mettre un libellé particulier (par ex . « non disponible »)
pour les anciens enregistrements.
2. Ajout de nouvelles dimensions. Cela implique d’ajouter une nouvelle clé étrangère dans la table de faits.
3. Ajout de nouveaux faits. Si ces faits sont au même grain que les faits existants, il suffit d’ajouter autant de
colonnes dans la table de faits. S’ils n’apparaissent qu’à partir d’une certaine date, il suffit de mettre la
valeur null dans les lignes de faits antérieurs. S’ils ne sont pas au même grain, il est fortement conseillé de les
mettre dans une table de faits à part.
4. Si une dimension devient plus granulaire, la table de faits devient probablement aussi plus granulaire et elle doit
être reconstruite. Les applications existantes ne seront cependant pas impactées.
5. Ajout d’une nouvelles source de données avec les dimensions existantes et de nouvelles dimensions imprévues.
Dans ce cas, il faut créer une nouvelle table de faits et conserver l’ancienne.

Modèle dimensionnel en flocons de neige. Ce modèle résulte de la normalisation en 3ième forme normale des dimensions.
Il est déconseillé de normaliser les tables de dimension pour plusieurs raisons :

1. La multiplication des tables de dimension peut perturber les utilisateurs.


2. Les SGDB auront un traitement moins optimisé.
3. L’économie d’espace réalisée est négligeable comparée à la taille de la table de faits.
4. La navigation à l’intérieur d’une dimension est plus difficile.
5. Les flocons de neige empêchent l’utilisation des index sous forme de bitmaps (utiles pour les champs de faible
cardinalité).

Les tables de dimensions doivent donc rester plates.

A éviter également : dépasser 25 dimensions. En général, on peut s’en sortir avec moins de 15 dimensions.

Toute jointure entre des tables de dimension et des tables de faits doit se baser sur des clés entières artificielles sans
signification. Eviter les codes opérationnels qui prennent plus de place et peuvent ne pas être pérennes. Aussi l’absence
d’une dimension n’a pas de code opérationnel associé. De plus les clés entières permettent de meilleures performances.

MODÉLISATION DIMENSIONNELLE 5
Classé dans : Aide à la décision — Sebastiao Correia 7 décembre 2006 @ 23:19
 Imprimer ce billet

Notion de jeux de rôles : si la date apparaît plusieurs fois dans une ligne de la table de faits, il faut créer des vues
différentes de la table Date, en prenant soin de nommer différemment à la fois la table et les colonnes (par ex. « jour de
commande » et « jour de livraison »…).

Concernant la dimension Produit qui est très courante, ses caractéristiques sont :

 un grand nombre de colonnes de texte descriptives.


 une ou plusieurs hiérarchies en plus d’un grand nombre d’attributs non hiérarchisés.

Cette dimension peut posséder plusieurs milliers de lignes et quelques précautions doivent être prises lors de la création de
cette table à partir d’un fichier maître.
 Faire correspondre à la clé Produit opérationnelle une clé Produit artificielle.
 Insérer des séquences de texte lisibles remplaçant ou complétant les codes numériques du fichier maître Produit
opérationnel.
 Contrôler tous les champs de texte pour éviter les erreurs d’orthographe, de valeurs impossibles ou des versions
différentes du même attribut.
 Documenter les définitions, les interprétations et les sources des attributs des produits dans les métadonnées de
l’entrepôt.

La dimension adresse de livraison.

Il est normal d’avoir plusieurs hiérarchies indépendantes dans cette table. Une hiérarchie naturelle est la hiérarchie
géographique avec le pays, la région, le département, la ville, le lieu. Une autre hiérarchie possible est une hiérarchie par
entreprise (une adresse de facturation peut regrouper plusieurs adresses de livraison). Les différentes hiérarchies peuvent
avoir différents niveaux. Il peut arriver que la relation entre adresse de facturation et de livraison ne soit pas strictement
hiérarchique (i.e. plusieurs factures pour une livraison). Dans ce cas, le grain de la table de dimension peut être affiné au
niveau de la combinaison adresse de facturation/adresse de livraison, si cette relation non strictement hiérarchique reste
exceptionnelle.

Sinon, il est préférable de définir une dimension supplémentaire « Adresse de facturation ». Il est inutile de créer une table
portant les relations entre les deux dimensions, la table de faits porte déjà cette relation et répond efficacement à la
question des corrélations entre dimensions.

La dimension dégénérée du numéro de commande n’est reliée à aucune table de dimension (c’est le propre d’une
dimension dégénérée) car toutes les informations de la commande sont conservées dans les autres dimensions. Par contre,
elle peut servir à regrouper les articles commandés ensembles. D’une façon générale, les dimensions dégénérées sont
réservées à l’identification des transactions. Elles ne doivent surtout pas servir à stocker un code sans que sa réelle
signification soit décrite dans une autre table.

La dimension fourre-tout (junk dimension) sert à stocker les différents indicateurs et drapeaux (flags) trouvés dans les
données opérationnelles. Eventuellement, si le nombre de lignes est conséquent, on pourra créer plusieurs dimensions
fourre-tout. Cette dimension soulage la table de faits et évite aussi la création d’un trop grand nombre de dimensions pour
gérer ces indicateurs. On peut aussi créer une dimension fourre-tout pour stocker les commentaires trouvés dans les
données.

Les devises multiples peuvent être gérées facilement à l’aide d’une table de conversion stockant les changes chaque jour et
en ajoutant une dimension Monnaie (par pays).

Les faits de granularité différente ne doivent jamais être mélangés dans une même table de faits. Ou bien il faut répartir
les faits de plus haut niveau au niveau le plus fin, ou bien il faut les mettre dans des tables de faits séparées. La première
solution est la meilleure car elle permet la navigation entre les niveaux ; mais elle nécessite de définir les modalités
d’allocation (activity based costing). Cette allocation sur le niveau de détail devrait être faite par une équipe dédiée plus
fonctionnelle et non par les développeurs de l’entrepôt.

La facturation est le processus idéal pour commencer un entrepôt de données dans les sociétés qui expédient des produits ou
vendent des services. Une table de faits detransactions de facturation est une des tables les plus puissantes de l’entreprise.
Elle combine les clients, les produits et les composantes de la rentabilité.

Une table de faits des instantanés récapitulatifs voit ses lignes régulièrement mises à jour, contrairement aux autres tables
de faits. Ce type de table de faits est mieux adapté aux processus de courte durée de vie ayant un identifiant du début à la
fin.

Gestion des unités de mesure : s’il existe différentes unités de mesure comme par exemple le nombre de produits, le
nombre de cartons, le nombre de palettes, etc. alors il est conseillé de stocker les différents facteurs de conversion dans la
table de faits directement et non dans une dimension. La gestion des changements de facteur s’en trouve simplifiée.

Il me semble qu’il est aussi possible de stocker directement les quantités (dans les différentes unités de mesure) plutôt que
les facteurs. Mais alors l’étude des changements de facteurs (qui représentent des changements de conteneurs) est plus
difficile. Le facteur de conversion apparaît donc plus fondamental ici.

Comparaison des 3 types de table de faits.

Grain de Grain de l’instantané Grain de l’instantané


Caractéristiques
transaction périodique récapitulatif
Periode de temps Point dans le Intervalles réguliers Durée indéterminée,
représentée temps prévisibles généralement courte
Une ligne par Une ligne pour la vie de
Grain Une ligne par période
événement l’entité
Chargement de la
Insertion Insertion Insertion et mise à jour
table de faits
Mises à jour de la Pas de mise à mise à jour pour chaque
Pas de mise à jour
table de faits jour activité
Date de la Dates multiples pour des
Dimension date Date de la fin de période
transaction étapes standard
Activité de la Performance dans un Performance sur une
Faits
transaction intervalle prédéfini durée de vie limitée

Les tables de transactions seules ne peuvent pas offrir des modèles dimensionnels efficaces. Elles stockent toutes les
transactions.

Les tables de faits instantanés périodiques résument les faits à la fin d’une période (la journée souvent). Elles facilitent le
suivi de l’évolution de l’activité.

Les tables de faits instantanés récapitulatifs couvrent un laps de temps indéterminé, correspondant à la durée de vie de la
transaction de produit. Cette table possède souvent une colonne « date de mise à jour de la ligne ».

Source : Ralph Kimball et Margy Ross, « Entrepôts de données, guide pratique de modélisation dimensionnelle« , 2ième
édition.

Commentaires (0)

Vous aimerez peut-être aussi