データウェアハウスを構築しています。それぞれの事実にはそれがありtimestampます。日、月、四半期ごとにレポートを作成する必要がありますが、時間ごとにも作成する必要があります。例を見ると、日付はディメンションテーブルに保存される傾向があることがわかります。（ソース：etl-tools.info）
しかし、私はそれが時間の意味をなさないと思います。ディメンションテーブルはどんどん大きくなります。一方、日付ディメンションテーブルを使用したJOINは、で日付/時刻関数を使用するよりも効率的ですSQL。
あなたの意見/解決策は何ですか？
（私はInfobrightを使用しています）
キンボールは、時間と日付のディメンションを別々にすることをお勧めします。
design-tip-51-latest-thinking-on-time-dimension-tables
以前のToolkitの本では、時間の分または秒のコンポーネントを毎日の深夜からのオフセットとしてこのようなディメンションを構築することを推奨していましたが、特に計算しようとすると、結果として得られるエンドユーザーアプリケーションが非常に困難になることに気付きました。期間。また、暦日のディメンションとは異なり、1日の特定の分または秒の説明的な属性はほとんどありません。企業がシフト名や広告タイムスロットなど、1日のタイムスライスに対して明確に定義された属性を持っている場合、このディメンションが分数（または数秒）真夜中過ぎ。したがって、この時刻ディメンションには、グレインが分または86の場合、1440レコードが含まれます。
私の推測では、それはあなたの報告要件に依存していると思います。あなたがのようなものが必要な場合
WHERE "Hour" = 10
つまり、毎日10:00:00から10:59:59の間の場合、時間ディメンションを使用します。これは、より高速であるためです。
WHERE date_part('hour', TimeStamp) = 10
date_part（）関数はすべての行に対して評価されるためです。次のように、日数の境界を超えて集計するには、タイムスタンプをファクトテーブルに保持する必要があります。
WHERE TimeStamp between '2010-03-22 23:30' and '2010-03-23 11:15'
これは、ディメンションフィールドを使用するときに厄介になります。
通常、時間ディメンションの解像度は1分なので、1440行です。
時間はデータウェアハウスのディメンションである必要があります。これは、時間について頻繁に集計する必要があるためです。スノーフレークスキーマを使用して、オーバーヘッドを減らすことができます。一般的に、コメントで指摘したように、時間は異常に高い解像度のように見えます。あなたがそれらを主張するならば、その日の時間を別の次元にすることは助けになるかもしれません、しかしこれが良いデザインであるかどうか私はあなたに言うことができません。
日付と時刻に別々のディメンションを設定することをお勧めします。日付ディメンションには、識別された有効な日付範囲の一部として、日付ごとに1つのレコードがあります。例：1980年1月1日から2025年12月31日。
また、86400レコードの時間の個別のディメンションで、1秒ごとにタイムキーで識別されるレコードがあります。
日付と時刻の両方が必要なファクトレコードでは、これらの適合ディメンションへの参照を持つ両方のキーを追加します。