Dimensions à évolution lente : écraser, ajouter une ligne ou ajouter une colonne

Ce que c'est

Les attributs de dimension changent lentement et de façon irrégulière, et un entrepôt doit décider si un fait enregistré l'année dernière doit être rapporté sous la valeur d'attribut de l'année dernière ou sous celle d'aujourd'hui. Les pages de technique du Kimball Group (citées) définissent les réponses de base. Type 1 : l'ancienne valeur d'attribut dans la ligne de dimension est écrasée par la nouvelle, si bien que l'attribut reflète toujours la dernière affectation et que l'historique est détruit ; les agrégats construits sur l'ancienne valeur doivent être recalculés. Type 2 : une nouvelle ligne de dimension est ajoutée avec les valeurs mises à jour et une nouvelle clé primaire de substitution, que les lignes de faits référencent à partir du moment du changement ; la page exige au moins trois colonnes supplémentaires, une date d'effet de ligne, une date d'expiration de ligne et un indicateur de ligne courante. Le type 3 ajoute un attribut qui préserve l'ancienne valeur pendant que l'attribut principal est écrasé, de sorte que les rapports puissent grouper soit par la valeur actuelle, soit par l'ancienne ; la page décrit cette technique comme relativement peu utilisée. Les instantanés dbt (cités) implémentent le type 2 sur des tables sources mutables, en ajoutant dbt_valid_from et dbt_valid_to à chaque version ; une stratégie par horodatage détecte le changement via une colonne updated_at, une stratégie par vérification en comparant une liste de colonnes, et une configuration décide si les lignes supprimées à la source sont ignorées, invalidées ou enregistrées comme une nouvelle version.

Pourquoi c'est important

Sans politique définie, le même rapport donne des réponses différentes selon le moment où il s'exécute, et personne ne peut dire si « ventes par région » utilise la région du client au moment de l'achat ou aujourd'hui. Le type 2 répond aux deux questions, mais multiplie les lignes de dimension et exige que chaque chargement de faits recherche la clé de substitution valide au moment de l'événement.

Comment l'appliquer

• Décider par attribut, pas par table : les corrections d'erreurs de saisie sont de type 1 ; les changements réels du monde que les rapports doivent attribuer de façon historique sont de type 2.
• Conserver la clé naturelle sur chaque ligne de type 2 et indexer (clé naturelle, valid_from) pour les recherches à une date donnée ; utiliser une sentinelle ouverte ou NULL de façon cohérente pour la ligne courante, et documenter laquelle.
• Exécuter les instantanés au moins aussi souvent que la période de rapport la plus fine ; les changements survenus entre deux instantanés s'effondrent en une seule version.
• Charger les faits en joignant sur la clé naturelle avec la plage de validité qui contient l'horodatage de l'événement, pas sur la ligne courante.

Pièges

Les changements de dimension arrivant en retard exigent de rattacher à une nouvelle clé les faits déjà chargés. Le type 2 sur des attributs à forte rotation (dernière connexion) rend la dimension plus grande que les faits ; déplacer de tels attributs vers la table de faits ou vers une mini-dimension séparée.