Sql-Server
數據倉庫建模：銷售訂單費用
我有兩個數據庫系統，我正在嘗試對銷售訂單業務進行維度建模。兩個運營數據儲存都有一個銷售訂單標題和明細表。但是，其中一個具有附加費用的附加表，這些費用可以在銷售訂單抬頭級別或行級別進行調整。表之間的關係是：
- 標題到詳細資訊 = 1 到多個
- 收費標頭 = 1 到多個
- 費用明細 = 1 到多
我有一些相互競爭的維度模型設計思想：
- 創建一個銷售訂單標題 + 行級粒度事實表，然後創建一個單獨的事實表進行調整。這樣可以保持粒度乾淨，但可能會在兩個表之間重複許多維度鍵列。
- 將所有三個表扁平化為一個事實表（具有分配的度量），用於其中一個源，然後將與收費相關的列集留空以用於另一個源。從技術上講，這在單個事實表中包含不同的粒度，這是一個很大的 Kimball 禁忌。
- 另一種選擇可能是創建某種橋接表，也許？認為這會使收費充當一個維度而不是一個可能不是很有效的事實……
有人可以指導我這些選項中哪一個是最合適的設計嗎？
有人可以指導我這些選項中哪一個是最合適的設計嗎？
有趣的是，這個問題確實有答案：不，沒有人可以。
維度建模始終與您想要回答的問題有關，並且通常需要消除轉換中的一些資訊。您可以做出許多建模決策，但在它們之間進行選擇的唯一方法是比較回答有關您的業務問題的難易程度和性能。
請注意，您沒有考慮簡單地使用Periodic Snapshot事實，您將在其中計算有趣的度量，例如（day、org、product）。這將為您提供一個非常簡單的維度模型，該模型可能無法回答所有最後一個問題，但您可以將其與儲存完整交易詳細資訊相結合，以用於需要它的場景。