BI TYPES DE DIMENSIONS MODÉLISATION DIMENSIONNELLE 5

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 quefaire 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)



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).


Commentaires (0)

http://s.correia.free.fr/wordpress/?p=95&print=1




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.


Commentaires (0)



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.


Commentaires (0)


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.


Commentaires (0)


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. »



Commentaires (0)


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.

CaractéristiquesGrain de transaction

Grain de l’instantané périodique

Grain de l’instantané récapitulatif

Periode de temps représentée

Point dans le temps

Intervalles réguliers prévisibles

Durée indéterminée, généralement courte

GrainUne ligne par événement

Une ligne par périodeUne ligne pour la vie de l’entité

Chargement de la table de faits

Insertion Insertion Insertion et mise à jour

Mises à jour de la table de faits

Pas de mise à jour

Pas de mise à jourmise à jour pour chaque activité

Dimension dateDate de la transaction

Date de la fin de périodeDates multiples pour des étapes standard

FaitsActivité de la transaction

Performance dans un intervalle prédéfini

Performance sur une 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 ».


Commentaires (0)


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 dimensionsIl 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.


Commentaires (0)



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.


Commentaires (0)



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.


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.

CaractéristiquesGrain de transaction

Grain de l’instantané périodique

Grain de l’instantané récapitulatif

Periode de temps représentée

Point dans le temps

Intervalles réguliers prévisibles

Durée indéterminée, généralement courte

GrainUne ligne par événement

Une ligne par périodeUne ligne pour la vie de l’entité

Chargement de la table de faits

Insertion Insertion Insertion et mise à jour

Mises à jour de la table de faits

Pas de mise à jour

Pas de mise à jourmise à jour pour chaque activité

Dimension dateDate de la transaction

Date de la fin de périodeDates multiples pour des étapes standard

FaitsActivité de la transaction

Performance dans un intervalle prédéfini

Performance sur une 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 ».


Commentaires (0)

Documents

BI TYPES DE DIMENSIONS MODÉLISATION DIMENSIONNELLE 5