什麼時候Data Vault模型是數據倉庫的正確模型？

Question

我最近發現對'Data Vault Modeling'的引用作爲數據倉庫的模型。我之前見過的模特是Inmon和Kimball。作者提到由於所需連接而可能出現的性能問題。它看起來像一個很好的模型，但我想知道這個問題。有沒有在線的經驗報告？

Answer 1

你可以找到我的博客上一大堆更多的信息：http://danLinstedt.com，並在datavaultinstitute點com

但給你一個快速/簡短的回答你的問題的論壇：

的陷阱是如下所示：

1）必須接受將原始數據加載到數據倉庫的概念 2）瞭解Data Vault通常不允許由於模型而導致「最終用戶」直接訪問。

可能還有一些，但好處大於缺點。

隨時檢查博客，它是免費註冊/關注。

乾杯， 丹Linstedt

Answer 2

我們一直在使用一個土生土長的修改Data Vault了數年，名爲「Link建模」，其中只有實體和鏈接;從neo4j繪製原理，但是在SQL數據庫中實現。

鏈接建模和數據保險庫對Kimball/Inmon模型的思維方式有很大的不同。

我在下面的評論涉及到使用以下結構構建的系統：一個臨時臨時數據庫，一個DWH，然後是一些DWH構建的集市。還有其他方法可以構建DWH解決方案，但這是非常典型的。

隨着金博爾/ Inmon

• 數據被清潔的方式進入DWH，但有時施加在途中到臨時數據庫
• 業務規則和MDM是（通常）所施加的之間Staging數據庫和數據倉庫
• 的集市是特定往往受到區域

隨着數據保險庫/鏈路建模

• 數據以分期
• 這些數據是通過傳遞到DWH也未清洗降落不變，而是存儲在實體/鏈接形式
• 數據清理，MDM和商業規則適用於DWH和市場之間。
• 集市基於特定領域的需求（與上述相同）。
• 對於我們來說，我們經常（但並非總是）建立Kimball Star Schema風格的市場，因爲最終用戶很容易理解這些風格的數據結構。

的場合鏈路模型化DWH進入自己的，有以下幾種（使用金博爾術語來表達的問題）

• 經之際，將有來自用戶的要求的查詢爲什麼一個具體的數字具有這個值？'。在傳統的Kimball/Inmon中，數據在清理過程中沒有辦法知道原始值是什麼。鏈接模型在DWH中具有原始數據。
• 當沒有鏈接多個維度並且需要能夠報告全套數據的交易記錄時，例如，問一些問題，比如「某家經紀商出售的保險單有多少沒有支付索賠交易？」。
• MDM在類型2 Kimball或Inmon DWH中的應用可能會導致大量類型2更改記錄被寫入Dimensions，這些記錄通常包含所有數據值，因此存在大量數據重複。使用鏈接模型/數據倉庫，新的維度值只會導致在鏈接表中創建新的類型2鏈接，該鏈接表只包含實體表的外鍵。這在Kimball DWH中通常具有緩慢變化的尺寸和fast changing dimension，這是一個公平的解決方法。
• 在保險和其他需要能夠生產'截至日期'報告的行業中，事實表也會慢慢發生變化，類型2維度跟蹤對2型事實記錄是一場噩夢。
• 從發展的角度來看，向大型Kimball維度添加新列需要謹慎完成，考慮回填是重要的，但通過鏈接模型向實體添加額外的列相對來說並不重要。

在金博爾的方法論中，這些方法總是存在的，但是他們需要一些細心的思考，有時需要跳過一些箍環。

從我們的角度來看，鏈路建模幾乎沒有什麼壞處。

我與任何營銷/生產Kimball/Inmon或Data Vault方法的公司沒有關係。