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. 

Conseil 13: Lorsqu'une table de faits est utilisée comme dimension

Les tables de faits sont principalement de trois types:

• le grain d'une table de faits peut être une transaction individuelle où un enregistrement représente un instant dans le temps 
• le grain peut être une période, représentant une durée de temps comme une semaine ou un mois. 
• le grain peut être une agrégation, représentant toute l'histoire de quelque chose 

J'ai discuté de ces trois types en détail dans un article que vous pouvez trouver ici.

Conseil 12: Compter correctement avec une dimension enrichie

Dans l’article précédent, nous avons abordé le sujet des calculs basés sur une dimension. Nous pouvons ajouter encore plus de valeur à ces résultats lorsque nous introduisons une table séparée, contenant des attributs supplémentaires et qui croise la table de dimension.

Nous avons récemment eu un exemple simple de ce genre de table complémentaire qui lie les codes postaux à une zone commerciale. Les personnes du marketing voulaient connaitre la répartition des clients par zone commerciale par rapport à l’ensemble de la population. En d'autres termes, nous voulions savoir où avions-nous une forte pénétration géographique, et où celle-ci était moins bonne. Si cette information supplémentaire s'avère précieuse pour l'organisation, nous devrions l'ajouter dans la dimension Client sous la forme d’un nouvel attribut. Mais auparavant, nous avons besoin de faire quelques requêtes pour nous assurer que cela en vaille la peine.