Conseil 24: Conception dimensionnelle dans un entrepôt de données multinational

Si vous gérez un entrepôt de données multinational, vous pourriez avoir à faire face au problème de la présentation du contenu de l'entrepôt de données dans un certain nombre de langues différentes. Quelles parties de l'entrepôt ont besoin d'être traduites? Où stockez-vous les différentes traductions? Comment faites-vous pour intégrer de plus en plus de langues?

Conseil 22: Dimensions Client de profondeur variable

La dimension Client est probablement la dimension la plus compliquée d'un entrepôt de données. Dans une grande entreprise, la dimension Client peut être:

• profonde, avec des millions d'enregistrements
• large, avec des douzaines d'attributs
• avec des évolutions lentes, mais parfois des changements rapides

Pour aggraver les choses, dans les très grandes dimensions Clients nous avons souvent deux catégories de clients que j'appellerais Visiteurs et Clients.

Conseil 21: Définir la granularité

L'étape la plus importante de la conception dimensionnelle est de déclarer le grain de la table de faits. Définir la granularité veut dire exactement ce qu'un enregistrement de la table de faits représente. Souvenez-vous qu'un enregistrement d'une table de fait capture une mesure. Voici quelques exemples:

• un produit par ligne sur un ticket de caisse d'un client mesuré par un scanner
• un virement sur une police d'assurance
• une facture d'un médecin
• un billet d'avion individuel de quelqu'un prenant un vol

Conseil 20: Faits éparses et faits ayant une courte durée de vie

Les tables de faits sont construites autour de mesures numériques. Quand une mesure est prise, un enregistrement dans la table de fait est ajouté. La mesure peut être le montant d'une vente, la valeur d'une transaction, une balance en fin de mois, le rendement d'un processus de fabrication, ou encore une mesure classique de laboratoire. Si nous enregistrons plusieurs nombres au même moment, nous pouvons souvent les ajouter au même enregistrement.

Nous complétons la mesure avec toutes les chose que nous savons être vraies au moment précis où elle est prise. A coté de la date et de l'heure, nous connaissons souvent des choses comme les clients, les produits, les conditions du marché, les employés, les statuts, les fournisseurs, et bien d'autres entités qui dépendent du processus que nous mesurons.

Conseil 19: Répliquer des dimensions correctement

Le secret pour construire un entrepôt de données distribué est d'utiliser des dimensions conformes. Dans un entrepôt distribué plusieurs sources de mesures différentes sont maintenues par différentes directions. Ces mesures sont habituellement présentées dans des tables de faits. Une direction peut suivre le nombre de produits fabriqués, une autre le nombre de produits dans le stock. Une troisième peut vouloir le nombre de produits vendus, et une quatrième le nombre de commentaires et plaintes liés à un produit. Clairement, toutes ces équipes ont un intérêt commun pour "le produit". Ainsi, nous pouvons construire un entrepôt de données distribué si nous parvenons à une définition unique du produit partagée par toutes les directions.

Conseil 18: La métaphore de l'édition

Dans cet article, je veux partager avec vous un point de vue que je prends très au sérieux, et qui est, d'une certaine façon, la base de tout mon travail sur les entrepôts de données. C'est la métaphore de l'édition. 

Imaginez le scénario suivant: imaginez que vous avez été invité à prendre la tête d'un magazine de grande qualité. Vous avez été nommé rédacteur en chef et vous disposez d'une grande liberté pour gérer le contenu, le style et la distribution de ce magazine.

Conseil 17: Tables d'aides pour les hiérarchies

Cet article fait suite à l’article "Help for Hierarchies" de Ralph Kimball, publié en septembre 1998, qui traite des structures hiérarchiques de profondeur variable. Ces structures sont le plus souvent représentées dans les bases de données relationnelles comme des relations récursives.

Ci-dessous, la définition d’une dimension Entreprise simple qui contient ce type de relation récursive entre la clé étrangère PARENT_CLE et la clé primaire ENTREPRISE_CLE :

Create table ENTREPRISE(

ENTREPRISE_CLE       INTEGER NOT NULL,

ENTREPRISE                 VARCHAR2(50),

PARENT_CLE                INTEGER);

Bien que cela soit efficace pour stocker des informations sur les structures organisationnelles, il n'est pas possible de naviguer ou de cumuler des faits au sein de ces hiérarchies en utilisant le SQL généré par les outils d'interrogation du commerce. Pour résoudre ce problème, l’article original de Ralph décrit une table d'aide semblable à celle ci-dessous qui contient un enregistrement pour chaque chemin et pour chaque entreprise dans l'arbre de l'organisation elle-même et pour chaque filiale en dessous d’elle.

Conseil 16: Dimensions interchangeables

Le dix-huitième critère de la liste des critères dimensionnels sympas, définit une "dimension remplaçable à chaud" comme étant une dimension avec deux ou plusieurs versions alternatives. Si la dimension est interchangeable, alors n’importe laquelle des versions peut être choisie au moment de la requête.

Il existe un certain nombre de situations où l'usage des versions alternatives d’une même dimension peuvent être très utiles. En voici 3 :

Conseil 15: Combiner les différents types de dimensions à évolution lente

Il existe plusieurs techniques bien documentées pour traiter les attributs des dimensions à évolution lente.
En bref, avec les dimensions à évolution lente de type 1, la valeur de l'attribut est remplacée par la nouvelle valeur, effaçant l’historique des valeurs. Par exemple, lorsque l’emballage d’un produit change, l'attribut "Emballage" est simplement mis à jour avec la valeur actuelle.
Avec une dimension à évolution lente de type 2, un nouvel enregistrement avec les nouveaux attributs sont ajoutés à la dimension. Les enregistrements de la table de faits continuent de pointer vers l’ancienne clé de la dimension Produit avec l’ancienne valeur d’emballage, alors que les nouveaux enregistrements pointeront vers la nouvelle clé Produit, faisant référence au nouvel emballage. Ainsi l’historique est parfaitement partitionné.
Enfin, avec les dimensions à évolutions lentes de type 3, les attributs sont ajoutés à la dimension pour obtenir deux emballages simultanés - on peut imaginer avoir un champs "Emballage actuel" et un champ "Emballage précédent", ou bien "Emballage d'origine".

D'après mon expérience, les équipes en charge de l'entrepôt de données sont souvent appelés à conserver l'historique des attributs tout en maintenant la possibilité de croiser les données historiques avec les valeurs actuelles des attributs. Aucune des techniques d’évolution lente présentées ci-dessus ne répond, à elle seule, à cette exigence. Toutefois, en combinant ces techniques, vous pouvez élégamment répondre à ce besoin dans vos modèles dimensionnels.

Nous allons commencer par utiliser la technique de type 2 pour enregistrer les changements d'attribut. Lorsque l’emballage change, nous ajoutons un nouvel enregistrement dans la dimension avec une nouvelle clé de substitution.
Nous allons ensuite enrichir la dimension avec un attribut supplémentaire décrivant l'emballage actuel. Dans les enregistrements courants de la dimension Produit, la valeur de l'attribut "Emballage" sera identique à la valeur du nouvel attribut "Emballage actuel". Mais, pour tous les enregistrements précédents d’un produit donné, l'attribut "Emballage actuel" sera mis à jour pour refléter l'état actuel du produit; l'attribut "Emballage" ne changeant pas.
Si nous voulons voir des faits historiques basées sur l'emballage actuel, nous allons faire un filtre ou une agrégation sur le champs "Emballage actuel". Mais si nous voulons conserver la vue historique des emballages, nous utiliserons le champs "Emballage".

Nous avons décrit une approche hybride qui combine les 3 techniques de dimension à évolution lente. Nous avons créé de nouveaux enregistrements pour capturer les changements (type 2), puis ajouté un attribut pour refléter un point de vue différent (type 3), qui est ensuite mis à jour pour tous les enregistrements précédents d'un produit donné (type 1). Comme un étudiant l’a récemment suggéré, peut être que nous pouvons appeler cela le type 6 (2 + 3 + 1).

Source originale: www.kimballgroup.com

Article original "Kimball Design Tip #15: Combining SCD techniques", publié le 29 octobre 2000.

Conseil 14: Calculer le solde à une date donnée sur une table de faits de type transactionnelle

L’article précédent a montré comment joindre une dimension à évolution lente (la table des comptes clients dans une banque) avec une table de faits dont le volume augmente rapidement (les transactions des comptes clients). Nous avons vu comment la dimension à évolution lente était elle même une sorte de table de faits, puisqu'elle était également la cible d'un ensemble d'opérations qui modifiait les profils des comptes.

Dans cet article, nous allons nous concentrer sur la table de faits qui enregistre tout les mouvements qui ont lieu sur les comptes bancaires.