Les entrepôts de données sont généralement construits autour de l'hypothèse idéale que l'activité mesurée (les enregistrements des faits) arrive dans l'entrepôt de données en même temps que le contexte qui lui est associé (les enregistrements des dimensions). Lorsque nous avons à la fois les enregistrements des faits et ceux des dimensions corrects, nous avons le luxe de comptabiliser les clés de la dimension en premier, puis d'utiliser celles-ci dans les enregistrements de la table de faits qui l'accompagne.
Fondamentalement, trois choses peuvent se produire quand nous comptabilisons les enregistrements de la dimension.
- Si l'entité de la dimension (par exemple Client) est un nouveau membre de la dimension, nous attribuons une nouvelle clé de substitution dans la dimension.
- Si l'entité de la dimension est une version révisée d'un client, nous utilisons la technique de la dimension à évolution lente de type 2 pour attribuer une nouvelle clé de substitution et stocker la description du client qui a été mis à jour dans un nouvel enregistrement de la dimension.
- Enfin, si le client est un élément familier et inchangé de la dimension, nous utilisons simplement la clé de la dimension que nous avons déjà pour ce client.
Depuis plusieurs années, nous avons eu connaissance de modifications particulières dans ces procédures pour traiter des faits qui arrivent tardivement, à savoir des enregistrements de faits qui entrent dans l'entrepôt très en retard. Il s'agit d'une situation chaotique parce que nous devons rechercher dans l'historique à l'intérieur de l'entrepôt de données pour trouver comment affecter les bonnes clés de la dimension qui étaient en vigueur lorsque l'activité a eu lieu à ce moment précis dans le passé.
Si nous avons des faits qui arrivent en retard, est-il possible d'avoir des faits qui arrivent en avance? Comment est-ce possible? Y a-t-il des situations où cela est important?
Un fait qui arrive en avance a lieu lorsque la mesure de l'activité arrive dans l'entrepôt de données sans son contexte complet. En d'autres termes, les états des dimensions attachés à la mesure de l'activité sont ambigus ou inconnus pendant une certaine période de temps. Si nous sommes dans un mode de mise à jour conventionnel comprenant un ou plusieurs jours de latence, nous pouvons habituellement juste attendre que les dimensions nous soient signalés. Par exemple, l'identification du nouveau client peut entrer dans une alimentation séparée retardé de plusieurs heures. Nous pouvons simplement être en mesure d'attendre que la dépendance soit résolue.
Mais si nous sommes dans une situation d'entrepôt de données en temps réel dans lequel l'enregistrement du fait doit être visible tout de suite, mais que nous ne savons pas quand le contexte dimensionnel arrivera, nous avons quelques choix intéressants. Notre comptabilité en temps réel doit être revue, en utilisant encore la dimension Client comme source du problème.
1) Si la clé Client naturelle dans le nouvel enregistrement du fait peut être reconnue, alors nous attachons provisoirement la clé de substitution existante la plus récente de ce client à la table de faits, mais nous laissons également ouvert la possibilité d'avoir une version révisée de ce client qui nous sera signalé à une date ultérieure. À ce moment là, nous 2) ajoutons l'enregistrement Client révisé dans la dimension avec une nouvelle clé de substitution, puis modifions la clé étrangère de l'enregistrement de la table de faits pour la table Client. 3) Enfin, si nous pensons que le client est nouveau, nous attribuons une nouvelle clé de substitution Client avec un ensemble de valeurs d'attributs factices dans un nouvel enregistrement de la dimension Client. Nous reviendrons alors à cet enregistrement de dimension factice à une date ultérieure et ferons un changement de type 1 (écrasement) sur ses attributs lorsque nous aurons des informations plus complètes à propos du nouveau client. Au moins cette étape évite toute modification destructive des clés de la table de faits.
Il n'existe aucun moyen d'éviter une période provisoire où les dimensions ne sont "pas tout à fait exactes." Mais ces étapes tentent de minimiser l'impact des mises à jour inévitables des clés et d'autres champs. Si ces enregistrements en avance sont tous stockés dans une "partition à chaud" dans la mémoire, alors les enregistrements d'une table de faits agrégée ne devraient pas être nécessaires. Ce n'est que lorsque la partition à chaud est traditionnellement chargée dans les tables de l'entrepôt de données statique à la fin de la journée (et quand les dimensions ont rattrapé les faits) que vous avez besoin de construire les agrégats.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #57: Early arriving facts", publié le 2 août 2004.
Aucun commentaire:
Enregistrer un commentaire