我應該在我的事實中雪花還是複制它？
我正在建立一個數據倉庫，供 SSAS 用來在其上創建多維數據集，並且我在兩種可能的模式之間進行辯論。在我的倉庫中，我有兩個不同的事實表來跟踪美元價值的每日變化。這些事實表中的每個實體都有一個與之相關的基礎銷售訂單和行。這些 SO 和 Lines 還有其他相關的維度，例如客戶、產品等。到目前為止，總共有大約 12 個子維度。
我的問題是我是否應該將所有這些子維度直接滾動到事實表中，或者我是否應該在我的倉庫中使用一點雪花，並讓它們從銷售訂單和行維度分支出來。
第一個選項顯然更好地遵循星型模式模型。但是，如果進行更改（例如添加額外的維度），則需要更多維護，基本上必須為每個事實表執行兩次 ETL，而不僅僅是在 SO 維度上執行一次。同樣，如果添加了與銷售訂單相關的新事實，我將不得不再次完成整個過程。
由於這是我的第一個 DW/OLAP 項目，我不熟悉雪花上應該在哪裡畫線，其他人的想法將不勝感激。
“標題 - 詳細資訊”模式在銷售交易領域非常常見。
為了回答你的問題，有很多你沒有討論過的因素會起作用。例如：
- 如果您的 DW 基礎架構有大量 RAM 並且在 SSD 儲存上，那麼在這種情況下讀取成本很低，因此為了可用性而對某些維度進行非規範化可能是有意義的。
- 數據的案例是什麼？在這種情況下，我可能會做出假設——這是銷售數據。它將用於會計、執行報告、預測分析、客戶服務以及您能想像到的幾乎所有可能的臨時查詢。
在決定是對維度進行雪花化還是簡單地將其值包含在事實表中時，我使用的一個一般原則是：
- 如果維度有許多可能對報告有用的屬性（或者如果只有該維度上的報告），我會為它創建一個維度。
範例：考慮
CUSTOMER維度。銷售訂單有一個客戶，但還有其他屬性屬於CUSTOMER您可能要報告的維度，例如客戶位置、客戶年齡/性別/婚姻狀況、客戶類型、客戶創建日期等，以及許多其他客戶相關的屬性。我不會將所有這些都放在事實表中，因此在這種情況下，我會“雪花”到客戶維度，因為還有更多相關的屬性CUSTOMER可能與您的銷售事實數據相關。可能還會有僅依賴於CUSTOMER維度的報告——例如“按月新客戶”報告。您不會期望這會出現在事實數據中。PRODUCT維度是另一個我幾乎總是放在它自己的維度中的維度。
- 如果維度是一個沒有其他有用屬性的單一值，我可以考慮將其包含在事實表中。
範例：我們可能有一個名為“Order Source Channel”的屬性 - 它可能是描述銷售訂單來源的單個值，例如它可能具有
eCommerce、Kiosk、Point-of-Sale、等值Phone-In。它是單個值，不存在其他相關屬性對於這個實體。在這種情況下，我很想將其留在事實表中，而不是創建單一屬性維度並要求我的使用者進行額外的連接等。記住：
- 以上是概括性的，我不認為這是一個硬性規則
- 數據建模既是一門藝術，也是一門科學。有很多場景可以走任何一條路，只有經驗會幫助你決定走哪條路。
- DWH 結構的可用性應該與性能一樣重要。我盡量不要創建一個數據模型，它要求我的高級使用者編寫具有 15 個或更多連接的 SQL 查詢只是為了獲取銷售數據。這將導致有人編寫不正確的 SQL（它總是這樣）。這有時會被誤認為是“壞數據”。這是您作為 DWH 開發人員不希望發生的事情。
您看不到“應該在哪裡畫線”的原因是“雪花”的概念已經破產（無論它寫了多少）。
最簡單的方法是最好的：在 BCNF 中獲取您的設計並開始使用它。添加正確性約束、方便視圖、健全程序和速度索引。不要假設性能會成為問題，或者連接會導致性能問題。等到他們這樣做——如果他們這樣做了——然後解決他們。最多，您需要實現那個漂亮的視圖，或者可能在一夜之間將其寫入輔助表。
有一個巨大的迷思，即數據倉庫有一些特別之處。那沒有。如果您的表被規範化，您可能會驚訝於伺服器“匯總您的維度”的能力，這在其他地方被稱為“執行您的查詢”。