Voici la modélisation d'une dimension Temps qu'un consultant nous a récemment proposé. Celle-ci semble assez différente de celles que nous concevons habituellement.
La structure de cette dimension Temps est la suivante :
Date_Clé varchar2 (8)
Date_Début date ou datetime
Date_Fin date ou datetime
Et voici un exemple de son contenu :
Date_Clé Date_Début Date_Fin
xmas99 25Nov99 06Jan00
1qtr99 01Jan99 31Mar99
newyrsdy 01Jan00 01Jan00
01Jan00
01Jan00 01Jan00
Quel est votre point de vue sur cette structure? Pour quel type de scénario l'envisageriez vous comme une bonne solution et une alternative viable?
Voici ma réponse :
Je n’aime pas beaucoup cette dimension Temps... si c'est effectivement une dimension.
J’attends d’une dimension Temps qu’elle décrive le contexte temporel d'une mesure exprimée dans
une table de faits. En termes de base de données, il faut une clé étrangère pour chaque enregistrement de la table de faits qui fasse référence à un enregistrement spécifique de la dimension Temps.
Il est très
important pour la simplicité d’utilisation que la table de faits soit de
granularité uniforme. En d'autres termes, tous les enregistrements de la table de faits devraient représenter des mesures prisent au niveau quotidien, au niveau hebdomadaire, ou au niveau mensuel, par exemple.
Votre proposition de dimension Temps a des enregistrements de différentes granularités, et il semble qu'elles se chevauchent. Si vous avez une mesure qui se produit à une date donnée, et que ces enregistrements de la dimension Temps se chevauchent, alors lequel des enregistrements choisissez-vous pour un enregistrement de la table de faits
particulier?
Dans une table de faits ayant un grain uniforme, vous pouvez utiliser la dimension Temps
associée pour représenter de manière simple les différentes plages de temps. Une table de dimension Temps avec des enregistrements pour chaque jour est très souple,
car vous pouvez représenter simultanément tous les groupements de temps auxquels
vous pouvez penser.
Une dimension Temps classique, avec une granularité au jour, pourrait avoir la structure
suivante :
Clé_Temps (clé de substitution; entiers compris entre 0 to N)
Type_De_Temps (Normal, Pas_Applicable, Pas_Encore_Arrivé...)
SQL_Timestamp (timestamp pour le type “Normal”, sinon Null)
Numéro_Du_Jour_Dans_Mois (1..31)
Numéro_Du_Jour_Dans_Année (1..366)
Numéro_Du_Jour_Dans_Epoque (un entier, positif or négatif)
Numéro_De_Semaine_Dans_Année (1..53)
Numéro_De_Semaine_Dans_Epoque (un entier, positif or négatif)
Numéro_Du_Mois_Dans_Année (1..12)
Numéro_Du_Mois_Dans_Epoque (un entier, positif or négatif)
Nom_Mois (Janvier, ..., Décembre)
Année
Trimestre (1Q, ..., 4Q)
Semestre (1H, 2H)
Période_Fiscale (nom ou numéro, dépend du service financier)
Vacances_Civiles (Nouvel an, 14 juillet, ..., Noel)
Jour_Travaillé (Y, N)
Jour_Ouvrable (Y, N)
Saison_De_Vente (solde, rentrée des classes, Période de Noel)
Catastrophe_Naturelle (érruption, tornade, ..., tremblement
de terre)
Dans cette
table de temps vous avez un enregistrement pour chaque jour de l'année et vous remplissez chaque champ avec les valeurs correspondantes pour ce jour-là. Tous les champs spéciaux de navigation tel que Période_Fiscale et Saison_De_Vente vous permettent de définir des plages de temps spécifiques pour chacun de ces items. Par exemple, vous pouvez définir le champ Saison_De_Vente avec la valeur "rentrée des classe" et qui serait automatiquement associée à tous les jours du 15 août au 10 septembre.
Dans la
modélisation que vous proposez, vous utilisez des clés avec des valeurs comme "xmas99" et "1qtr99". Ce sont des clés intelligentes. Ce type de clé est dangereux dans une table de dimension d’un entrepôt de données pour plusieurs raisons. La génération de celles-ci est prise en otage par les règles imposées pour leur syntaxe. Il est tentant d'écrire des applications et des interfaces utilisateur qui rendraient ces clés visibles par tous.
S'il y a un "1qtr99" êtes-vous sûr de garantir qu'il y a également un "2qtr99"? Et que faites-vous quand vous avez besoin du type "non-applicable" pour une date ?
S'il y a un "1qtr99" êtes-vous sûr de garantir qu'il y a également un "2qtr99"? Et que faites-vous quand vous avez besoin du type "non-applicable" pour une date ?
Nous avons
déjà discuté de l’affectation de clés de substitution dans d’autres forums, mais nous pensons vraiment ce qui est dit ici: les clés de la dimension Temps ne doivent pas avoir de signification particulière. Ce sont juste des entiers avec lesquels vous ne pouvez rien faire.
Ajouté le 21 mai 2000
Je voudrais partager avec vous quelques commentaires utiles que j'ai reçu à propos de cet article, où j'ai présenté une conception pour une dimension Temps, et ai dit que la clé primaire de cette dimension ne devrait être qu'un simple entier, et non un timestamp.
Plusieurs personnes, d'accord avec cette approche, ont déclaré que, néanmoins, il peut être très utile pour les clés de substitution (1,2,3, ..., N) d'être affectée dans l'ordre exact correspondant à la date indiquée dans l’enregistrement de la dimension Temps
associée. Ceci permet à toute table de faits d'être physiquement partitionnée sur la base de la clé de temps de substitution. Partitionner physiquement une grande table de faits sur la base du temps est une approche très naturelle dans tous les cas, car cela permet à des données anciennes d’être supprimées proprement, et permet aux nouvelles données d’être ré-indexées et ajoutées sans déranger le reste de la table de fait si vous utilisez les fonctions de partitionnement de votre base de données.
Source originale: www.kimballgroup.com
Article original "Kimball Design Tip #5: Surrogate keys for the Time dimension", publié le 19 mars 2000.
Aucun commentaire:
Enregistrer un commentaire