數據倉庫設計：組合日期時間維度與單獨的日期和時間維度和時區
我們剛剛開始設計一個新的數據倉庫，我們正在嘗試設計我們的日期和時間維度將如何工作。我們需要能夠支持多個時區（可能至少 GMT、IST、PST 和 EST）。我們最初認為我們將有一個廣泛的組合日期時間維度，粒度可能低至 15 分鐘，這樣我們的事實表中有一個鍵，所有支持的時區的所有不同日期時間數據都在一個維度表中。（即日期鍵、GMT 日期、GMT 時間、IST 日期、IST 時間等…）
Kimball 建議從一天中的時間維度中分離出一天維度，以防止表變得太大（數據倉庫工具包第 240 頁），這聽起來不錯，但這意味著我們在每個時區的事實表中都有兩個鍵我們需要支持（一個用於日期，一個用於一天中的時間）。
由於我在這方面非常缺乏經驗，我希望有人知道這兩種方法之間的權衡，即性能與所有不同時區鍵的管理。也許還有其他方法，我見過一些人談論在每個時區的事實表中有一個單獨的行，但是如果您的事實表是數百萬行，那麼這似乎是一個問題，那麼您需要將其增加四倍以添加時區.
如果我們執行 15 分鐘的粒度，我們的日期時間維度表中每年將有 131,400 行（24 * 15 * 365）行，這聽起來對性能來說並不太可怕，但在我們測試一些之前我們不會確定原型查詢。在事實表中具有單獨的時區鍵的另一個問題是查詢必鬚根據所需的時區將維度表連接到不同的列，也許這是 SSAS 為您處理的事情，我不確定.
感謝您的任何想法，-馬特
將日期和時間分開將使您可以輕鬆地按時間進行聚合。例如：如果您想執行查詢以查找一天中最忙的時間段。這很容易使用單獨的時間維度來執行。
此外，您應該只有一個時間密鑰。確定 GMT/EST 時間 - 然後在事實表中使用它。如果您需要根據其他時區執行報告，只需在您的應用程序或查詢中進行轉換。
只是跟進我們如何決定實施我們的 DataWarehouse 以支持多個時區並儘可能高效：我們選擇創建一個時區表（id、名稱等）以及一個“時區”橋”表，如下所示：
time_zone_bridge --------------- date_key_utc time_key_utc timezone_id date_key_local time_key_local這樣我們可以保持我們正常的日期和時間維度表很小，我們所有的事實都連結到 UTC 日期/時間鍵，然後如果我們需要按不同的時區報告/分組，我們只需要通過時區橋表加入並將本地日期/時間鍵連結回日期和時間維度表。我們使用從 SSIS 呼叫的 C# 程式碼填充我們的時區橋接表，因為這比直接從 SqlServer 執行 TZ 操作要簡單得多。