Temporalité DWH Partie 3 : Sortir les timelines

Bien que dans de nombreux cas il ne soit pas nécessaire de sortir les timelines dans les rapports, il y a des cas où la sortie des timelines est importante. Exemples :

• Afficher l’historique d’un client (1d)

• Mettre en évidence les données modifiées ultérieurement pour identifier les fraudes et les corrections légitimes (2d)

• Comparaison flexible de différentes périodes pour comprendre les changements relatifs (3d)

Si vous n’avez pas encore entendu parler du 1d (Validité métier), 2d (Inscription Time) et 3d (Load Time), vous pouvez envisager de lire la première partie de cette série.

Sortir la timeline 1d : Exemple historique client

Vous pourriez vouloir descendre à un cas individuel dans des rapports qui montrent des valeurs agrégées. Pour comprendre le cas individuel, nous pourrions vouloir comprendre l’historique d’un client : quand a-t-il vécu dans quelle région et quand a-t-il changé de souscriptions. Un exemple : nous voyons que des clients existants annulent leur connexion DSL mais commandent ensuite une connexion en fibre optique. Pour comprendre ce qui s’est passé, il pourrait être utile de prendre quelques échantillons et de les analyser. C’est un historique 1d : la validité métier.

Comme nous l’avons appris dans la partie 2, vous pouvez stocker cela dans un Temporal Instance Hub en ajoutant la Valid From Date à la business key. Comme la granularité du hub et les données à sortir correspondent maintenant, je n’ai pas besoin de modifier la sortie. La seule chose à prendre en compte est qu’un décalage d’une tranche de temps sur l’axe 1d dans la source (changement du valid from time) est reconnu par le DWH comme une tranche supprimée et une nouvelle tranche, puisque le valid from time fait partie de notre clé. Cela signifie que nous devons marquer ou filtrer la version qui n’est plus valide d’une tranche de temps.

Nous y parvenons en mémorisant dans un satellite de tracking si une clé est toujours présente dans la source ou non. Important : cela ne fonctionne qu’avec des chargements complets. C’est indépendant de l’outil Datavault Builder et même indépendant de Data Vault. Si je ne reçois pas de message de suppression explicite de la source, je ne peux détecter implicitement les lignes supprimées que par un chargement complet. Cependant, ce chargement complet ne doit contenir que toutes les parties de la business key et pas tous les attributs. Il est donc possible de charger les attributs en delta et de ne charger que la clé et le valid from time complètement pour reconnaître de telles « suppressions ».

Timeline 2d : Détecter la fraude

Il y a quelques années, on m’a demandé de suivre certaines irrégularités dans les commissions de vente d’un client. Il y avait différentes règles pour quand un vendeur avait droit à une commission. Le premier jour de chaque mois, on regardait combien de nouveaux contrats un vendeur avait signés. Quelques vendeurs ont utilisé cela pour enregistrer des contrats le dernier jour d’un mois et les annuler rétroactivement le lendemain du calcul de la commission.

Cas 1 : 2d time stocké dans la source, mais sans historique

Comment dois-je traiter ces données ? Si le système source enregistre l’Inscription Time, mais ne garde pas d’historique de chaque changement, je dois créer la connaissance de l’historique 2d en utilisant l’historique 3d dans le DWH. Nous recommandons de simplement stocker les temps 2d comme attributs satellite. Cela signifie qu’au moment où vous stockez les données, vous n’avez pas besoin de comprendre toutes les règles métier sur la façon de les sortir.

La différence est que je ne peux pas seulement accéder aux dernières données sur l’historique 3d (as-now), mais que je dois évaluer la timeline sur la timeline 3d pour reconstruire la timeline 2d.

Dans la sortie suivante, nous avons déjà implémenté la première règle selon laquelle la valeur devient négative pour l’événement « Lost ». Mais nous pouvons déjà voir ici que S. Shady a été astucieux. Il a changé l’agent de vente pour que l’événement d’annulation ne lui soit pas crédité.

Nous introduisons donc une nouvelle règle qui prend l’agent de vente du dernier événement « Completed » :

Et ensuite les ventes de S. Shady en février seront réduites du contrat perdu. Mais cela ne fonctionne à son tour que pour les commissions linéaires. Sinon, il faut dériver la période pour laquelle la correction s’applique.

L’exigence de simplement jouer les données sous forme SCD type 2 telle que stockée dans le satellite sur l’axe 3d n’aide personne. C’est seulement en interprétant les événements sur les différents axes de temps que la connaissance utile est créée.

Cas 2 : 2d time stocké avec historique dans la source, pas d’historique 1d

Si nous recevons déjà un historique 2d de la source, nos données sources sont donc une table pré-historisée. Si la source contient maintenant l’historique 2d mais pas d’historique 1d, alors on peut supposer que l’historique 2d peut être assimilé à l’historique 1d puisque c’est probablement la meilleure approximation.

Cas 3 : 2d time stocké avec historique dans la source, combiné avec un historique 1d

Si nous avons déjà une source de données bi-temporelle avec historique 1d et 2d, alors nous sommes probablement dans une compagnie d’assurance. Pour nos amis du secteur de l’assurance sophistiqué : il y a deux façons de charger ces données sources dans le Data Vault.

• Combiner la business key avec le 1d Valid From timestamp et ajouter en plus le 2d timestamp

• Reprendre la clé technique de la source et la stocker comme Persistent Staging Load (PSA Load)

Sortir la timeline 3d : Reproduire et comparer les niveaux de connaissance

Un cas fréquemment cité pour sortir l’axe 3d est la reproductibilité des rapports. C’est une exigence très importante, par exemple si des rapports créés pour des raisons légales doivent être reproductibles à tout moment. Que ce soit pour Sarbanes-Oxley, Basel I, II ou III ou tout autre reporting. Cette exigence est absolument réelle, mais peut parfois être résolue par certaines bases de données avec des remèdes maison. Oracle propose le Flashback Archive pour ces requêtes à un certain moment. Snowflake propose une fonctionnalité similaire avec Time Travel.

Comparer les niveaux de connaissance

Mais est-ce que je veux donner à un rapport la possibilité d’appeler l’état de connaissance de chaque jour et de comparer 2 ou plusieurs états de connaissance ?

Si vous comprenez l’exigence de l’utilisateur métier et partagez son point de vue, alors vous devez créer une sortie SCD type 2 pour la timeline 3d. Je décris l’implémentation technique dans la quatrième partie de cette série.

Épilogue

Mon opinion personnelle : Dans le prochain article, je traiterai enfin de la création technique d’une sortie SCD Type 2 pour la timeline 3d. Ce qui m’importait dans tout le contexte jusqu’ici est de montrer que dans la plupart des entreprises, cela devrait être l’exception plutôt que la règle s’il y a un besoin du tout. Si vous utilisez un SCD Type 2 pour la timeline 3d par défaut, vous le faites probablement parce que vous le pouvez et parce que personne n’a correctement collecté et/ou analysé les besoins des utilisateurs métier.