Data Warehouse - Comment stocker created_time, created_date, complete_time, complete_date

Question

Ma table de tâches a 4 colonnes à stocker created_time, created_date, completed_time, completed_date.

Lorsque je convertis cette table en OLAP, dois-je les stocker sous la dimension Date Time ou est-il autorisé à les conserver dans la table Fact.

Quelqu'un peut-il expliquer s'il vous plaît. Je vous remercie.

Answer 1

En supposant que vous utilisez un schéma en étoile, une dimension de date agit généralement plus qu'une simple table de correspondance. Il contient habituellement un bon nombre de colonnes décrivant la date précise dans la table de faits, comme un jour férié, quel trimestre est-il, quel est le trimestre fiscal, etc.

Construit de cette façon, l'entreprise peut posez des questions telles que le nombre de tâches accomplies au 1er trimestre (sans avoir à entrer les dates exactes de début et de fin de ce 1er trimestre).

La réponse à votre question dépend du type de requêtes que vous vous attendez à ce que l'utilisateur vous pose. Si une requête comme celle ci-dessus est probable, alors oui, créez une dimension de date complète pour stocker les informations sur les dates.

Bien sûr, cela fait que vos requêtes utilisent des FK (ou des colonnes de pointeurs pour la dimension de date) et vous feront utiliser des jointures. Les jointures pourraient ralentir légèrement les performances pour les très grandes tables. Cependant, le schéma en étoile est basé sur ce concept.

La dimension de date doit être initialisée avec certaines lignes de données couvrant habituellement 1 ou 2 ans en plus de l'année en cours (ou peut-être plus).

Maintenant, nous parlons de colonnes de temps. Il n'est pas recommandé de créer l'heure dans la dimension de date (voir lien). Si vous créez du temps dans la dimension de date, la dimension de date sera inutilement énorme.

Je vous recommande de placer les colonnes de temps uniquement dans la table de faits, que vous utilisiez ou non une dimension temporelle. Je vous recommande également d'inclure des colonnes calculées dans le fait, telles que la durée totale en jours, mois, années et heures dans la table de faits (en supposant que cette information serve des requêtes telles que combien de tâches ont duré 5 heures). Vous devez effectuer les calculs pendant ETL. Vous ne pouvez pas simplement soustraire l'heure de fin de l'heure de début sans avoir les dates. Vous ne voulez pas non plus entrer dans de tels calculs pendant l'heure de la requête, sinon les requêtes seraient complexes.

Ce type de dénormalisation peut être acceptable par beaucoup dans le modèle de schéma en étoile et présente un inconvénient mineur de rendre le fait plus long. Il existe des moyens de rendre virtuelles les colonnes calculées, mais vous pouvez décider de conserver les colonnes calculées. Dans un tel cas, si votre fait est long et vous avez un grand nombre de tables de faits, vous pouvez décider de créer une table de faits spéciaux qui est associée en relation avec le fait principal pour accélérer le traitement, ce fait nouveau sera plus petit et plus rapide à charger. Cependant, ce n'est probablement pas le cas dans de nombreuses applications, c'est-à-dire que 1 fait le travail très bien.

Cela peut également aider: Kimball-Latest Thinking On Time Dimension Tables.