在上一篇文章中我討論了 DATA VAULT 的基礎知識，描述了 DATA VAULT 的主要元素及其用途。這並不是 DATA VAULT 主題的結束；我們需要討論 DATA VAULT 發展的下一階段。
在本文中，我將重點介紹 DATA VAULT 的開發以及向 BUSINESS DATA VAULT 或簡稱 BUSINESS VAULT 的過渡。
商業資料庫出現的原因
需要注意的是，DATA VAULT 雖然有一定的優勢，但並非沒有缺點。其中一個缺點是寫分析查詢很困難。查詢具有大量的 JOIN，程式碼又長又繁瑣。此外，進入 DATA VAULT 的資料不會經過任何轉換，因此，從商業角度來看，純粹形式的 DATA VAULT 沒有絕對價值。
正是為了消除這些缺陷，DATA VAULT 方法論已擴展，包含以下內容：
- PIT（時間點）表；
- 橋接表；
- 預定義的推導。
讓我們仔細看看這些元素的用途。
PIT 表
通常，一個業務對象（HUB）可以包含具有不同更新率的數據，例如，如果我們談論的是表徵一個人的數據，我們可以說有關電話號碼、地址或電子郵件的信息比全名、護照數據、婚姻狀況或性別具有更高的更新率。
因此，在確定衛星時，應該記住其更新頻率。為什麼這很重要？
如果將具有不同更新頻率的屬性儲存在同一個表中，則每次更新最常變更的屬性時都必須在表中新增一行。結果，磁碟空間量增加，執行請求所需的時間也增加。
現在我們已經按刷新率劃分了衛星，並且可以獨立地將資料載入到其中，我們需要確保能夠獲得最新的資料。最好不要使用不必要的 JOIN。
讓我解釋一下，例如，您需要從具有不同更新頻率的衛星獲取當前（按上次更新日期）資訊。為此，您不僅需要進行 JOIN，還需要建立多個巢狀查詢（針對每個包含資訊的衛星），並選擇最大更新日期 MAX（更新日期）。隨著每個新的 JOIN，這樣的程式碼就會成長並且很快變得難以理解。
PIT 表旨在簡化此類查詢； PIT 表與 DATA VAULT 中新資料的記錄同時填入。 PIT表：
因此，我們掌握了每個時間點所有衛星資料相關性的資訊。透過使用 PIT 表的 JOIN，我們可以完全消除嵌套查詢，當然，前提是 PIT 每天都被填滿並且沒有間隙。即使 PIT 中存在差距，也只需對 PIT 本身使用嵌套查詢即可獲得最新資料。一個巢狀查詢比對每個衛星的巢狀查詢速度更快。
橋
BRIDGE 類型表也用於簡化分析查詢。然而，與 PIT 的不同之處在於簡化和加速不同樞紐、連結及其衛星之間的請求的方法。
此表包含查詢中經常使用的所有衛星的所有必要鍵。此外，如果需要分析金鑰名稱，則可以使用文字形式的金鑰來補充雜湊的業務金鑰。
關鍵在於，如果不使用 BRIDGE，在取得位於不同樞紐的衛星中的資料的過程中，不僅需要 JOIN 衛星本身，還需要 JOIN 連接樞紐的連結。
BRIDGE的存在與否取決於儲存配置和最佳化查詢執行速度的需要。很難想出一個通用的 BRIGE 例子。
預定義推導
讓我們更接近業務資料庫的另一個物件是包含預先計算指標的表。這些表格對於業務來說非常重要，它們包含根據給定規則匯總的信息，並且允許相對輕鬆地存取這些資訊。
從架構上來說，預定義派生只不過是某個樞紐的另一個衛星。它與常規衛星一樣，包含業務金鑰和衛星中記錄的建立日期。然而，相似之處僅止於此。這種「專業化」衛星的進一步屬性組成是由商業用戶根據最受歡迎的、預先計算的指標來決定的。
例如，包含有關員工資訊的中心可能包括帶有以下指標的衛星：
- 最低工資；
- 最高工資；
- 平均工資；
- 應計工資等的累計總額
在同一中心的 PIT 表中包含 PREDEFINED DERIVATIONS 是合乎邏輯的，然後您可以輕鬆取得特定選定日期的員工資料切片。
結論
實踐表明，商業用戶使用 DATA VAULT 有些困難，原因如下：
- 查詢程式碼複雜、繁瑣；
- JOIN 的豐富程度影響查詢的效能；
- 編寫分析查詢需要對倉庫結構有出色的了解。
為了簡化資料訪問，DATA VAULT 擴展了附加物件：
- PIT（時間點）表；
- 橋接表；
- 預定義的推導。
下一個 我打算告訴從事 BI 工作的人我認為最有趣的事情。我將介紹基於DATA VAULT建立事實表和維度表的方法。
本文資料依據如下：
- 上 Kenta Graziano，除了詳細描述外，還包含模型圖；
- 書籍：「使用 DATA VAULT 2.0 建置可擴充資料倉儲」；
- 文章 .
來源： www.habr.com
