數據倉庫 - 如何存儲created_time，created_date，complete_time，complete_date

Question

我的任務表有4列存儲created_time, created_date, completed_time, completed_date。

當我將該錶轉換爲OLAP時，我是否希望將它們存儲在日期時間維下，或者可以將它們保留在事實表中。

有人可以請解釋。謝謝。

Answer 1

假設您使用星型模式，日期維度通常不僅僅是查找表。它通常包含很多描述事實表中特定日期的欄目，例如是假期，哪個季度是關閉的，哪個財政季度是關閉的等。

以這種方式構建，業務可以提出問題，比如第一季度完成了多少任務（無需輸入第一季度的確切開始日期和結束日期）。

您的問題的答案取決於您希望用戶詢問您的查詢類型。如果像上面這樣的查詢可能，那麼是的，創建一個全面的日期維度來存儲日期信息。

當然這會使您的查詢使用FK（或指向日期維度的指針列），並且會使您使用連接。對於非常大的表格，連接可能會使性能略微下降。然而，星型模式是基於這個概念。

日期維度必須用一些數據行進行初始化，這些數據行除了當前年份（或者更多）之外通常會覆蓋1或2年。

現在我們來談談時間專欄。不建議在日期維度中創建時間（請參閱鏈接）。如果您在日期維度中構建時間，那麼日期維度將不必要地巨大。

我建議您只將時間列放在事實表中，無論您是否使用時間維度。我還建議您在事實表中包含計算列，例如事實表中以天，月，年和小時計的總持續時間（假設此信息用於查詢，例如完成5個小時需要多少個任務）。您需要在ETL期間進行計算。你不能只從開始時間中減去結束時間而沒有日期。在查詢期間，您也不希望進行這種計算，否則查詢將變得複雜。

這種類型的非規範化可能被星型模式模型中的許多人接受，並且具有使事實更長的小缺點。有多種方法可使計算列虛擬化，但您可以決定堅持計算列。在這種情況下，如果你的事實很長，並且你有大量的事實表，你可以決定創建一個特殊的事實表，這個事實表與主事務關係1-1以加快處理速度，新事實將會是更小，並更快加載。然而，在很多應用中這可能不是這種情況，這是事實將會很好地完成這項工作。

這也有助於：Kimball-Latest Thinking On Time Dimension Tables。