Temporalité DWH Partie 1 : Le défi

Au cours des dernières années, j’ai été confronté à la demande de créer un reporting avec des dimensions SCD type 2. Mais comme il y a généralement 3 lignes de temps ou plus dans le data warehouse, j’ai dû clarifier encore et encore quelle était l’exigence métier réelle. Ici, j’essaie de mettre de l’ordre dans mes réflexions et de vous donner un guide pour de telles discussions.

L’article est divisé en trois parties : - Définition des différentes timelines - Création de rapports faciles à utiliser en réduisant les timelines incluses dans la sortie DWH - Quels cas d’usage rendent nécessaire la sortie des différentes timelines

Dans un monde simple, il n’y a que ce ici et maintenant : le présent. Si je veux enregistrer le développement dans le temps, j’ai besoin d’une timeline.

Qu’est-ce qu’une dimension temporelle (timeline) ? Qu’est-ce qu’une tranche de temps ? Qu’est-ce que SCD Type 2 ? Quelle est la relation avec as-is, as-was, as-of ?

Dans un monde simple, il n’y a que ce ici et maintenant. Donc le présent. Si je veux enregistrer le développement dans le temps, j’ai besoin d’une timeline.

Je peux transformer une timeline en un point dans le temps en la coupant à n’importe quel endroit.

Mais si je vais maintenant corriger ma timeline, je peux entrer les heures de changement à nouveau sur une timeline séparée.

Si j’enregistre ces deux barres de temps à un angle de 90 degrés l’une par rapport à l’autre, j’obtiens une surface temporelle.

Je peux réduire cette surface temporelle à tout moment à une barre de temps si je coupe ma surface temporelle à n’importe quel point parallèlement à l’une ou l’autre des barres.

Je peux donc réduire une surface temporelle à une timeline et celle-ci à nouveau à un point dans le temps.

Ces coupes sont appelées vues as-of. Il y a une coupe spéciale, à savoir celle au moment actuellement valide (qui n’est pas toujours la fin d’une timeline) : as-is. Et une autre coupe spéciale qui représente la combinaison d’informations au moment d’un événement : as-was.

Dans cet exemple simplifié, je peux choisir la validité métier comme timeline et le moment où cette information a été enregistrée dans un système IT comme deuxième timeline. Nous avons ainsi une surface temporelle.

Dans le data warehousing, cependant, une troisième barre de temps est ajoutée dans chaque cas : quand le data warehouse a-t-il appris des informations nouvelles ou modifiées. Si vous dessinez maintenant cette troisième timeline perpendiculairement à la surface temporelle existante, vous obtenez un cube. C’est la raison pour laquelle j’aime parler de dimensions temporelles.

Pour éviter les différents problèmes avec les différentes terminologies, j’aime l’approche selon laquelle les différentes timelines, si elles peuvent être comprises comme des dimensions arrangées dans un cube, sont adressées avec des numéros de dimension.

• 1d : quand une entrée était valide d’un point de vue métier. Selon Snodgrass cité par Kaul « capturer l’histoire d’une réalité changeante » : Valid Time.

• 2d : Capture Time / System Time / Logged Time / Inscription Time / Approximation pour Assertion Time dans le système IT source.

• 3d : Acquisition Time / System Time / Logged Time / Load Time / Inscription Time / Approximation pour Assertion Time dans le système DWH.

Tranche de temps

Une tranche de temps est une section sur une timeline dans laquelle les attributs pour un objet spécifique et identifiable ne changent pas. Une tranche de temps peut être explicitement décrite avec une date de début et de fin, ou implicitement une tranche de temps peut être considérée comme terminée par définition dès qu’une nouvelle commence.

Avec les timelines 2d et 3d, en revanche, on suppose que le moment d’une nouvelle entrée signifie automatiquement la fin de la précédente.

Mes favoris personnels : 1d : Valid Time 2d : Inscription Time 3d : Load Time

Le point est que nous n’avons pas du tout besoin de nous mettre d’accord sur les noms, dès que tout le monde sait quelle timeline signifie quoi.

Maintenant, que signifie SCD Type 2 ?

SCD type 2 est une procédure pour documenter une nouvelle timeline à partir d’informations reçues à différents moments.

Habituellement, le terme est utilisé comme synonyme de la création de la timeline 3d dans le data warehouse. Le moment de chargement dans le DWH est généralement utilisé pour démarrer une nouvelle tranche de temps. Implicitement, le moment de chargement du jeu de données suivant pour la même clé est utilisé pour terminer la période d’assertion de l’entrée précédente.

Le problème est qu’il y a des implémentations de data warehouse et aussi des modélisateurs qui ne se demandent même pas : quelle timeline représentons-nous ici ? Cette timeline est-elle même appropriée pour répondre aux exigences de notre reporting ? Avons-nous même besoin de cette timeline pour nos évaluations ? Les changements enregistrés sont-ils seulement des corrections ou enregistrons-nous vraiment des changements dans le monde réel ?

De mon point de vue personnel, ce manque d’analyse des exigences métier conduit à des implémentations mal pensées dans lesquelles toutes les dimensions sont sorties sous forme SCD Type 2 dans tous les rapports.

Dans la suite de cette série, j’essaierai d’expliquer que dans certains cas, ce n’est pas seulement superflu mais peut aussi être faux dans certains cas. En même temps, je voudrais offrir des solutions alternatives sur la façon de gérer le temps dans le Data Vault (et le Data Warehouse) en général.