Il n'est pas exceptionnel d'identifier des douzaines de dates différentes, chacune ayant un sens métier qui doit être pris en compte dans la conception dimensionnelle. Par exemple, dans un établissement financier, vous pouvez avoir affaire à la date de dépôt, la date de retrait, la date de financement, consulter la date d'écriture, la date de traitement, la date d'ouverture de compte, la date de validité d'une carte, la date de lancement d'un produit, la date de début d'une promotion, la date de naissance d'un client, une plage de dates pour les chargements et l'état du mois.
La première chose à savoir est que toutes les dates ne sont pas créées et traitées de la même manière. Beaucoup de dates finissent comme clés étrangères de la dimension Date dans les tables de faits. La plupart des dates restantes deviennent des attributs d'autres dimensions. Enfin, certaines dates sont inclues dans la conception pour faciliter le traitement ETL et/ou les capacités d'audit.
Supposons que notre établissement financier conçoit une table de faits qui enregistre les opérations des comptes, telles que les transactions effectuées par dépôts, chèques ou distributeurs automatique. Chaque enregistrement de la table de faits comprend une dimension "Type de transaction" pour identifier la transaction qu'elle représente, ainsi qu'une dimension "Date de la transaction". Le sens métier de la date est définie par la dimension "Type de transaction". Dans ce cas, nous ne devrions pas inclure trois dates distinctes dans la table de faits puisqu'une seule serait valable pour une ligne donnée.
Dans d'autres situations, une seule transaction représentée par une ligne dans la table de faits peut être définie par plusieurs dates, telles que la date d'évênement de la transaction et la date de prise en compte de la transaction. Dans ce cas, deux dates seront inclues comme clés étrangères distinctes de la dimension Date. Nous utilisons la technique des jeux de rôle pour construire physiquement une dimension Date et des vues, basées sur celle-ci, pour représenter logiquement les dimensions Date distinctes liées aux clés étrangères de la table de faits.
Un client à récemment "généralisé" son schéma de transaction pour inclure toutes les transactions issues de plusieurs processus métier. Ce schéma exploite un certain nombre de dimensions Date dans la table de faits ayant une valeur nulle ou non applicable. Dans le cas de notre établissement financier, toutes les transactions, - qu'elles soient de contrôle, de carte de crédit, d'épargne ou hypothécaires - seraient traitées de manière identique dans une seule table de faits.
Toutes ces lignes de faits représentent des transactions au sens général, mais elles proviennent de mesures de processus métier différents. Souvenez-vous, nous conseillons de concevoir vos schémas par processus métier, couramment une table de faits par processus. Les transactions de contrôle sont très différentes des transactions de prêts hypothécaires. Ces deux processus ont des indicateurs et des dimensions uniques, résultant de tables de faits séparées, chacune avec ses propres dates.
De toute évidence, nous incluons aussi une dimension Date dans un schéma de type instantané périodique qui reflète la période de la ligne, comme l'instantané au mois. Ce sont des sous ensembles agrégés de la dimension Date, conformes à la dimension Date de base.
De nombreuses dates métiers seront inclues comme attributs dans des tables de dimensions. La date d'ouverture de compte pourrait se trouver dans la dimension Compte. De même, la date de naissance du client, la date de lancement d'un produt et la date de début d'une promotion appartiendraient à leurs dimensions respectives à savoir Client, Produit et Promotion.
Lorsque des dates sont des attributs de dimension, nous devons faire attention à leur utilisation dans les rapports et analyses. Est ce suffisant de connaitre la date d'ouverture d'un compte ou devons-nous inclure des attributs pour l'année, le mois et la période d'ouverture du compte? Ces attributs supplémentaires améliorent la capacité qu'a l'utilisateur à mener ses analyses en regroupant les comptes par année et/ou période à laquelle ceux-ci furent ouverts.
Afin de mener des analyses plus détaillées basées sur ces attributs de dimension, vous pouvez joindre une dimension Date pour prolonger la table de dimension. Dans ce cas, nous enregistrons la clé de substitution de la date dans notre dimension plutôt que la date elle-même, puis nous utilisons une vue pour définir des labels de colonnes uniques. Cette technique permet d'utiliser les attributs de notre dimension Date de base dans l'analyse. Toutefois, n'oubliez pas que l'utilisation abusive de dimensions étendues peut en compromettre la facilité d'utilisation ainsi que la performance. De plus, veillez à ce que toutes les dates se situent dans l'échantillon de dates stockées dans la table de dimension Date de base.
Il existe d'autres dates pour aider l'équipe de l'entrepôt de données à gérer les processus ETL et mener des audits sur les données. Des dates comme la date effective de l'enregistrement, la date d'expiration, la date de chargement ou celle de la dernière mise à jour peuvent être inclues dans chaque table de dimension. Bien que ces dates n'aient pas besoin d'être accessibles par l'utilisateur, elles peuvent s'avérer précieuses pour l'équipe de l'entrepôt de données.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #61: Handling all the dates", publié le 28 octobre 2004.
Aucun commentaire:
Enregistrer un commentaire