Comme la plupart des choses dans la vie, le changement est inévitable, même avec les attributs des dimensions. La plupart de nos lecteurs sont familiers avec les trois techniques de dimension à évolution lente (SCD):
- Type 1: Remplacement d'attribut
- Type 2: Ajout d'une autre ligne dans la dimension
- Type 3: Ajout d'un autre attribut dans la dimension
Quand des attributs de dimensions changent, nous sommes souvent sollicités pour conserver leurs valeurs précédentes, ainsi que pour fournir la possibilité de croiser les faits historiques avec les valeurs courantes des attributs. La demande pour cette aptitude augmente au fur et à mesure que les utilisateurs mûrissent leurs analyses. Il y a vingt ans, les analystes étaient satisfaits d'avoir des tables de dimensions qui étaient rafraîchies (écrasé) avec les valeurs d'attributs courantes à chaque chargement. Puis le mouvement c'est inversé pour capturer avec précision tous les changements en utilisant les dimensions à évolution lente de type 2. Maintenant, plus de gens veulent avoir le beurre et l'argent du beurre.
Nous avions discuté d'une approche hybride pour répondre à cette exigence il y a plusieurs années avec le conseil 15: "Combiner les différents types de dimensions à évolution lente". Dans cet article, nous avions utilisés des lignes de type 2 pour capturer l'historique des modifications des valeurs d'attributs, avec un ou plusieurs attributs "Actuels" complémentaires de type 3 sur chaque ligne. L'attribut de type 3 est écrasé (traité comme un type 1) sur l'enregistrement de type 2 reflétant l'état actuel ainsi que pour tous les enregistrements précédents, afin que les analystes puissent requêter soit sur des attributs historiquement précis, soit sur leurs valeurs courantes. Cette approche hybride fournit plus de flexibilité mais est plus complexe.
Physiquement, cette technique pourrait être mise en œuvre dans une table de dimension unique avec deux colonnes ("Historique" et "Actuelle") pour chaque attribut nécessitant cette flexibilité. Sinon, vous pouvez gérer tous les attributs courants dans une table séparée jointe à la clef naturelle de la dimension principale (telles que l'ID de l'employé), par opposition à la clé de substitution de la dimension. La table séparée contient qu'une seule ligne de données, avec les valeurs actuelles, pour chaque clé naturelle de la table de dimension. Les attributs sont écrasés à chaque fois qu'un changement se produit. La même clé naturelle est présente sur plusieurs lignes de la dimension de type 2 avec des clés de substitution uniques. Afin d'en faciliter l'utilisation, la dimension principale et la table dédiée aux valeurs actuelles peuvent apparaître comme unique via une vue, mais cette approche est inacceptable si la performance est impactée négativement.
Si vous avez une grande table de dimension avec une centaine d'attributs nécessitant un suivi des valeurs historiques et actuelles, les techniques ci-dessus peuvent devenir onéreuses. Dans cette situation, vous devriez envisager d'inclure la clé naturelle de la dimension en tant que clé étrangère supplémentaire dans la table de faits. Vous avez maintenant deux tables de dimensions semblables, mais très différentes associées aux faits. Tout d'abord, la clé de substitution de la dimension pointe vers une dimension de type 2 typique avec des données historiques exactes. Ces attributs filtrent ou groupent les faits en fonction des valeurs des attributs en vigueur lorsque les faits ont été chargés. D'autre part, la clé de dimension naturelle (ou une clé de référence statique) pointe vers une table de dimension de type 1 contenant seulement les valeurs actuelles des attributs. Les noms des colonnes dans cette table doivent être précédés de "Actuel" pour réduire le risque de confusion pour l'utilisateur. Ces attributs de dimension sont utilisés pour résumer ou pour filtrer des faits basés sur l'état actuel, quel que soit les valeurs en vigueur au moment où l'enregistrement a été chargé.
Dans toutes les situations décrites ci-dessus, les données renvoyées par une requête peuvent être très différentes selon les attributs choisis pour filtrer ou regrouper. Différents résultats sont inévitables parce que différentes questions ont été posées. Toutefois, étant donné la vulnérabilité de l'erreur ou de mauvaise interprétation, cette conception est souvent réservée aux utilisateurs qui comprennent ces différentes interprétations.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #54: Delivering both historical and current perspectives", publié le 18 may 2004.
Aucun commentaire:
Enregistrer un commentaire