從已經實現 SCD 的規範化源中設計維度 DB
我已經建構了一個 SSIS ETL 來將各種數據源（一個來自 MySQL，兩個來自 SQL Server）集成到一個 SQL Server 關係和規範化數據庫中，我稱之為
$$ NDS $$. SSIS ETL 處理類型 2 更新，因此
$$ NDS $$生成代理鍵和 SCD 表包括$$ _EffectiveFrom $$時間戳和一個可為空的$$ _EffectiveTo $$列，並且將所有數據連結在一起的自然鍵和漂亮的外鍵存在約束。 現在，我想用它建構一個 SSAS 維度數據庫，沒過多久我就意識到我正在為自己設置一個雪花模式：
所以我正在考慮添加一個新的
$$ DDS $$（關係）數據庫，以創建實際的維度和事實表，這些表將為 SSAS 數據庫的 DSV 提供數據。 這
$$ DDS $$數據庫將盡可能地非規範化，以便“扁平化”事實和維度（例如，$$ OrderHeaders $$+$$ OrderDetails $$成一個$$ Orders $$事實表，以及$$ CustomerStores $$+$$ Customers $$+$$ SalesReps $$進入一些$$ Customers $$維度表）——這樣做不僅可以讓我更容易地在 SSAS 中建構維度層次結構，還應該更容易提出實際的星型模式。 不過我有幾個問題：
- 我可以重複使用現有代理鍵的子集嗎？我正在考慮將現有密鑰用於最細粒度的級別並將其設為維度密鑰。這是一個好方法，還是我應該忽略$$ NDS $$代理鍵並使$$ DDS $$（關係數據庫）生成一組新的代理鍵？
- 如何處理 SCD？例如，“材料”和“供應商”將在$$ NDS $$當源系統中的某些特定欄位發生更改時…我想我必須設計 SSIS ETL 以僅將“最後一個圖像”記錄載入到$$ DDS $$db，然後在該過程中重新實現類型 2 更新，即處理$$ NDS $$作為保留歷史的“源系統”，同時複製其中的所有內容$$ DDS $$數據庫。但是，為什麼我需要將歷史記錄在$$ NDS $$ 和_$$ DDS $$? 顯然有些不對勁。
我是在為 Big Mess™ 做好準備，還是走在正確的軌道上？
如您所見，Kimball Dimensional Modeling 的好處之一是數據倉庫設計本質上是您的 SSAS 設計。雖然總是有例外，但您通常可以在 DSV 中選擇一個表並立即轉到層次結構設計、多維數據集關係等。
**我建議您轉向 DDS，但要注意逐步淘汰 NDS。**出於您提到的 SCD Type II 的簡單原因 - 沒有理由複制所有這些數據、ETL 和程式碼庫。保持兩者都會導致解決方案過於復雜，需要大量維護和風險——這是您需要避免的主要 Big Mess™。
這是理由：
- DDS 聽起來像 Kimball 尺寸設計，任何新員工和承包商都可以輕鬆理解和維護
- 有許多經過驗證的模式和 ETL 設計與之相伴，使其更易於設計和維護
- 通過事實分區和列儲存索引等選項更容易處理大量數據
- 將來為您自己和高級使用者更輕鬆地進行 DW 查詢
- 整體設計更簡單
僅當您擁有少量數據、沒有顯著增加的預期並且沒有切換到數據倉庫的能力時，我才會建議替代設計。這個建議最終包括了很多原本會進入 DW 的設計工作，因此類似於保留 NDS 並創建 DDS：
您可以使用顯示為視圖或硬編碼到 DSV 中的查詢來創建多維數據集。
聽起來您克服了很多障礙，並使用 NDS 創建了一個功能強大的解決方案。不幸的是，它沒有做的是維度建模提供的兩件重要的事情：簡單的查詢模式和輕鬆轉換為多維分析。值得慶幸的是，許多 ETL 設計可能用作載入不同表結構的模板或起點。