Virtuellement chaque table de faits possède une ou plusieurs clés étrangères liées à la dimension Temps. Les mesures sont prises à un moment précis et la plupart d'entre elles sont répétées au cours du temps.
La dimension de temps la plus courante et utile est la dimension Calendrier (ou date) avec une granularité au jour. Cette dimension à beaucoup d'attributs. Mais seulement peu d'entre eux (comme le nom du mois ou l'année) peuvent être générées directement par une fonction SQL. Les vacances, les jours ouvrés, les périodes fiscales, les numéros de semaines, l'indicateur de dernier jour du mois, et d'autres attributs de navigation doivent être présents dans cette dimension Calendrier et toutes les dates nécessaires à la navigation devraient être implémentées dans les applications en utilisant les attributs de la dimension. La dimension Calendrier possède quelques propriétés inutiles. C'est l'une des seules dimensions qui est complètement créée au début du projet d'entrepôt de données. Elle n'a pas de source de données conventionnelle. La meilleure façon pour créer la dimension Calendrier est de passer une après midi avec un tableur et de la créer à la main. Dix ans représente moins de 4 000 lignes.
Chaque dimension Calendrier a besoin d'un attribut de type Date et d'un attribut date complet. Ces deux champs forment la clé naturelle de la dimension. L'attribut de type Date a presque toujours la valeur "date" mais il doit y avoir au moins un enregistrement qui spécifie qu'une date n'est pas applicable nécessaire dans les situations où il n'y a pas de date connue, erronée, ou pas encore passée. La clé étrangère dans la table de faits dans ces cas doit pointer vers une date qui n'en est pas une dans la dimension Calendrier. Vous avez besoin d'au moins un de ces enregistrements spéciaux dans la dimension Calendrier, mais vous pourriez distinguer les différentes situations inhabituelles. Pour une data inapplicable, la valeur est "inapplicable" ou "NA". L'attribut date complet est un champ date-heure (ou timestamp), et prend la valeur nulle pour les champs spéciaux vus précédemment. Souvenez-vous que la clé étrangère dans une table de fait ne peut jamais être nulle, puisque cela violerait l'intégrité référentielle.
La clé primaire idéale pour le calendrier devrait être une clé de substitution sans aucun sens mais beaucoup d'équipes techniques ne peuvent résister à y mettre une clé intelligente comme 20040718 signifiant le 18 juillet 2004. Cependant, comme avec toutes les clés intelligentes, les quelques enregistrements spéciaux de la dimension Calendrier joueront quelques tours aux concepteurs qui utilisent ce type de clés. Par exemple, la clé intelligente pour une date qui n'est pas applicable devrait avoir une valeur qui n'a pas de sens comme 99999999, et les applications qui essaient d'interpréter la clé date directement sans utiliser la dimension Calendrier devraient toujours tester la valeur puisque ça n'est pas une date valide.
Dans certaines tables de faits, le temps est mesuré à un niveau inférieur au jour, à la minute ou à la seconde. Personne ne peut construire une dimension temps où chaque minute et chaque seconde de chaque jour est représenté. Il y a plus de 31 million de secondes dans une année. Nous voulons préserver la puissance de la dimension Calendrier et simultanément répondre aux demandes à la minute ou à la seconde. Nous pourrions aussi vouloir calculer des intervalles en comparant le temps exact entre deux enregistrements. Pour ces raisons, nous recommandons une modélisation avec une table de faits comprenant à la fois une clé étrangère vers la dimension Calendrier et un champs date-heure (timestamp). Nous intégrons ce champs date-heure directement dans la table de faits pour toutes les requêtes qui demandent une précision supplémentaire. Voyez cela comme un fait spécial, et non une dimension. Dans ce cas intéressant, il n'est pas utile de faire une dimension avec les minutes ou les secondes parce que le calcul de l'intervalle entre les enregistrements de la table de faits devient trop compliquée lorsque nous essayons de traiter avec les dimensions séparées Calendrier et Heure. Dans nos livres, nous avions recommandés de construire ce type de dimension avec les minutes et les secondes que contient une journée, mais nous avons réalisé que leur utilisation était trop difficile, particulièrement lorsque nous essayons de calculer des écart de temps. De plus, il y a peu d'attributs descriptifs associée à une minute ou une seconde.
Si l'entreprise a des attributs bien définis pour des intervalles de temps dans une journée, comme un changement de nom, ou une plage de publicité, une dimension supplémentaire Période_de_la_Journée peut être ajoutée à la conception où cette dimension est définie comme le nombre de minutes (ou même secondes) après minuit. Ainsi, cette dimension aura 1440 enregistrements si le grain est la minute ou 86 400 enregistrements si le grain est la seconde.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #51: Latest thinking on time dimension tables", publié le 1er février 2004.
Aucun commentaire:
Enregistrer un commentaire