大多數資料庫設計師在起步時，不是採用正規化的關聯式模型，就是採用維度星狀結構描述，而在許多應用場景中，這些方法都非常有效。然而，當企業組織開始管理由多個來源系統供給的大型資料倉儲時，往往會面臨瓶頸：結構描述變得脆弱、歷史資料難以追蹤，且每當要引入新的資料來源時，就必須重新修改已在生產環境中的資料表。Data Vault 2.0 正是為了徹底解決這些問題而設計的。本文將為你剖析什麼是 Data Vault 2.0、其運作原理，以及如何在 Navicat Data Modeler 4 中加以應用。
什麼是 Data Vault 2.0？
Data Vault 2.0 是由 Dan Linstedt 所研發的一套資料建模方法論，最初於 2000 年代初期推出，並在 2013 年左右進行了重大擴展。第一版純粹聚焦於建模技術，而 2013 年發布的 2.0 版本則將範疇擴大，納入了架構模式、方法論，以及與現代實踐（如敏捷開發、雲端運算和自動化）的整合。
其核心概念非常直接：與傳統維度資料表將標識、關係和描述屬性合併到單一資料表中不同，Data Vault 2.0 將它們分離成三種不同的結構類型。正是這種分離賦予了該方法論強大的適應性和靈活性。
三大核心建置要素
中心資料表代表核心業務概念，只儲存業務鍵，即貴組織實際使用的自然識別碼，例如客戶 ID、產品代碼或訂單號。因此，客戶中心資料表只包含客戶 ID，不包含其他任何內容。中心的設計目標是保持穩定。因此，即使來源系統發生變化，中心也不會隨之改變，並且不會儲存任何可能過時的資訊。
連結資料表負責記錄各中心資料表之間的關聯性。例如，如果客戶下了訂單，連結資料表就會透過儲存來自客戶中心資料表與訂單中心資料表的雜湊鍵來記錄該段關係。連結資料表同樣屬於僅允許附加且不可變的結構，關聯一旦記錄便永久保存。這使得連結資料表成為業務實體之間所有關聯關係的可靠審計追蹤。
衛星資料表是存放描述性屬性和歷史記錄的地方。連接到客戶中心資料表的衛星可能儲存客戶的姓名、地址和聯絡方式，以及顯示每個屬性版本載入時間的時間戳記。由於衛星表與中心表相互獨立，因此你可以在單一中心上掛載多個衛星（例如每個來源系統一個衛星，或按資料變動頻率分開）而無需修改中心本身。這正是當需要整合新資料源時，Data Vault 能展現極高適應力的原因。
何時該用（以及何時不該用）
當你正在建置一個需要整合眾多來源系統、處理頻繁結構描述變更，並需對資料的到達與演進過程維持完整稽核軌跡的企業級資料倉儲時，Data Vault 2.0 雖然帶來了複雜性，但絕對物有所值。特別是受到嚴格監管的產業——如金融、醫療與保險——能從中心-連結-衛星（Hub-Link-Satellite）模型固有的可審計性優勢尤為顯著，因為每筆資料在標準配置下都包含載入時間戳記與來源系統標記。
相反地，它較不適合簡單的分析型資料庫、建模資源有限的小型團隊，或是那些比起靈活性、更看重整合層查詢便利性與效能的應用場景。必須明確的是，Data Vault 是一個「整合層」，而非「消費層」。因此，分析師應該去查詢建置於其之上的表現層（通常是星狀架構或資料集市），而非直接查詢 Data Vault 本身。忽略這一差異而直接查詢 Data Vault 的團隊通常會發現多資料表聯結操作非常繁瑣。
在 Navicat Data Modeler 中進行 Data Vault 2.0 建模
Navicat Data Modeler 4於 2025 年 3 月（作為獨立產品，並同時整合於 Navicat 17.2 中）正式引入了對 Data Vault 2.0 的支援。該功能與工具現有的關聯式及維度建模方法論並存，這意味著你可以在同一個應用程式中同時運用這三種方法。
當你選擇 Data Vault 2.0 作為建模方法時，畫布與物件類型都會自動調整以契合該方法論。你可以直接使用中心資料表、連結資料表與衛星資料表結構，而無需使用通用資料表物件進行模擬，這不論在設計階段的清晰度上，還是在準備部署時產生準確的 DDL 方面都至關重要。視覺化環境能讓你清晰看見模型的軸輻式結構，從而更容易理解實體之間的連接方式以及新來源系統應連接到的位置。
Navicat Data Modeler 更廣泛的功能集也與 Data Vault 工作流程相得益彰。一旦實體模型準備就緒，「同步到資料庫」功能會將模型與即時資料庫進行比較，並針對差異處產生部署指令碼，這與 Data Vault 2.0 所倡導的增量式、迭代式開發風格自然契合。而「將模型匯出到 SQL 或指令碼檔案」功能則可產生建模結構描述的完整 DDL，隨時可提交至版本控制或交付給遷移工具。此外，由於 Navicat Data Modeler 支援多種資料庫，包括 MySQL、PostgreSQL、SQL Server、Oracle、MariaDB、MongoDB、SQLite 與 Snowflake，因此無論你的資料倉儲底層使用哪種引擎，都能套用完全相同的建模工作流程。
總結
Data Vault 2.0 並非適用於所有專案，但對於正在建置企業級資料倉儲、且需要靈活吸納變更並維持可靠稽核軌跡的組織而言，它提供了傳統方法難以企及的韌性。這套方法論的學習曲線較為陡峭，但其底層原則——將身分識別與關聯性分開、將關聯性與描述分開，並讓一切皆可被稽核——只要邏輯貫通後就會變得極其清晰。隨著Navicat Data Modeler 4 帶來原生 Data Vault 2.0 支援，團隊現在擁有了一個能直接使用該方法論語言的視覺化建模環境，從而大幅減少了從設計到實作之間的摩擦。
