Temporalité DWH Partie 2 : Réduire la complexité

À propos de la « Temporalité » dans le Data Vault

Se débarrasser de la complexité temporelle

En tant que fabricant du logiciel d’automatisation Datavault Builder, on nous demande fréquemment comment cartographier les changements dans le temps dans notre outil et/ou dans le Data Vault en général. Souvent sous la forme : comment puis-je rapporter du SCD Type 2 ? Cependant, il n’est pas toujours clair de quel axe temporel nous parlons. Voici donc une tentative de clarifier cela. C’est le deuxième article d’une série de trois.

• Le premier article a défini le défi auquel nous sommes confrontés avec la temporalité dans le DWH

• Cet article définit les possibilités de simplifier la complexité temporelle si possible

• Le troisième article discute des exigences métier pour sortir les timelines

Il y a différentes approches de la temporalité dans le data vault. Je recommande donc de lire les textes de Dirk Lerner, Christian Kaul et Lars Rönnbäck. Je présente ici une variante de la façon de représenter ou de simplifier les diverses lignes de temps de telle sorte qu’elles puissent être maîtrisées. Comme défini dans le premier article, je discute seulement de 3 lignes de temps et j’utilise les raccourcis suivants :

• 1d pour Valid Time

• 2d pour Inscription Time

• 3d pour Load Time

La première dimension (1d) est la validité métier. Cette timeline est spéciale dans le sens où une nouvelle tranche de temps sur la timeline ne signifie pas que l’ancienne entrée est invalide : si je vis à Bâle au lieu de Zurich, l’information selon laquelle j’ai vécu à Zurich n’est pas incorrecte.

Axe 1d : Toutes les informations sont valides mais seule une entrée est actuelle.

La deuxième dimension (2d) est l’inscription time dans le système source. C’est pertinent parce que sur l’axe 1d on peut aussi entrer de nouvelles entrées pour le futur et des corrections pour la tranche de temps actuelle et/ou passée. Dans certaines industries et départements, cela peut être utilisé pour commettre des fraudes. C’est aussi la raison de la première simplification : je suggère de stocker la timeline 2d dans un satellite simplement comme un attribut dans une première étape afin qu’aucune information ne soit perdue.

1ère simplification / stratégie : stocker les temps 2d comme attribut satellite normal

Cela signifie que dans l’espace tridimensionnel, nous ne considérons qu’un plan bidimensionnel.

La troisième dimension (3d) est le moment où l’information a été chargée dans le data warehouse. L’axe 3d est spécial en ce qu’il est sous le contrôle de l’équipe DWH. Et beaucoup de ceux qui travaillent dans ce domaine depuis longtemps savent que nous ne faisons confiance à aucun système source :)

Axe 3d : Une information remplace l’autre implicitement (oui, Petr est l’orthographe correcte de mon nom)

De quoi parlons-nous / corrections vs vraie histoire

Si nous supposons maintenant que le chargement dans le DWH est très proche de l’acquisition dans la source, nous stockons simplement le temps 2d comme attribut dans le satellite et l’ignorons dans une première étape. Donc quand nous parlons de SCD type 2 : est-ce 1d ou 3d ? Ce n’est pas toujours clair et dépend en partie de l’industrie. Dans l’assurance, par exemple, il est obligatoire de garder une histoire 1d pour de nombreux objets dans la source.

Dans certaines entreprises c’est tellement courant qu’aucune distinction n’est faite entre 1d et 3d.

Vraie histoire vs histoire pertinente

Mais même s’il y a une vraie histoire : si c’est non pertinent pour mon modèle métier de connaître le nom passé d’une personne (sauf si je vends des mugs avec son nom) : pourquoi mettrais-je cette information dans un rapport ?

En fait, dans de nombreux cas, il est plus logique de fournir une vue à un instant donné (selon les besoins métier) dans les rapports, car cela facilite l’utilisation des rapports et diminue le risque d’évaluer quelque chose de manière erronée.

Comment modéliser l’histoire 1d dans le DWH

Il y a quelques différences fondamentales : est-ce que j’interprète le temps avant de le charger dans le Data Vault, ou est-ce que je charge d’abord tout ce qui vient de la source dans le Raw Vault, même si nous avons des tranches de temps qui se chevauchent. Nous avons choisi la deuxième approche.

2ème « simplification » / stratégie : créer un temporal instance hub en concaténant la business key avec le business valid from time

Cela signifie que nous recevons plusieurs entrées valides pour une business key, comme un numéro de contrat, même si elles ne sont pas actuelles. La solution est soit d’utiliser un Multi-Active Satellite, soit de changer la granularité du hub. J’appelle cela un temporal instance hub.

Exemple : En assurance, j’ai une police avec une couverture définie. Cependant, cette couverture peut être ajustée dans le temps. Important : ce n’est normalement pas une correction, mais établit une nouvelle instance de la police.

S’il y a maintenant une correction parce qu’en janvier 2019 quelqu’un découvre que la couverture a été saisie incorrectement, le hub temporal instance a un avantage clair ici : si une seule tranche de temps est modifiée, elle sera correctement mise à jour dans la timeline 3d avec un pattern de chargement standard.

Pour ces raisons, nous supportons l’approche temporal instance hub dans notre outil.

Et qu’en est-il des attributs dimensionnels pertinents : instanciation

Bien que j’aie décrit ci-dessus que certains changements d’attributs ne sont pas pertinents pour de nombreuses évaluations, il y a certainement des changements qui sont centraux.

Un exemple est l’un de nos clients qui a la possibilité de produire ou d’acheter certains produits lui-même avant de les vendre à ses clients. Pour des raisons d’assurance qualité, il est significatif que le produit ait été vendu et livré par le client ou par une entreprise externe.

Donc, nous avons le cas où un axe temporel 3d est utilisé comme approximation pour la vue 1d. En modélisation Data Vault, il y a une façon très simple de procéder : nous pouvons transférer cet attribut du hub produit au hub ligne de commande de vente. C’est fait en mettant en place un Business Vault Load au moment où la transaction est chargée dans le Raw Vault, qui fait un lookup as-of-now sur l’attribut produit puis le stocke dans un satellite Business Vault sur la transaction. J’appelle cette procédure instanciation d’un attribut sur un autre grain.

3ème simplification / stratégie : instancier les attributs à un certain moment sur les transactions

Si nous sortons maintenant la commande de vente, nous pouvons aussi sortir l’attribut Business Vault sur ce grain de la transaction. Chaque utilisateur comprend que cet attribut est quelque chose au moment de la transaction.

Court résumé

Avec ces trois simplifications / stratégies,

• stocker 2d juste comme un attribut dans le satellite

• inclusion du temps 1d dans la clé du hub

• instanciation des attributs sur la transaction

je prétends que nous pouvons couvrir la plupart des exigences pour une sortie historicisée dans la plupart des industries. Dans un troisième article, je discuterai des cas où cela n’est pas suffisant et quelles sont les solutions techniques pour de telles exigences.