大多数数据库设计者通常从规范化的关系模型或维度星型模式入手，对于许多应用程序而言，这些方法都运作得非常顺利。但对于管理由多个源系统供数据的大型数据仓库的组织来说，往往会遇到瓶颈：模式变得脆弱，历史数据难以追踪，而接入新的数据源则意味着需要重新处理已经投入生产的表。Data Vault 2.0 正是为解决这些问题而专门设计的。本文将介绍它的定义、工作原理，以及如何在 Navicat Data Modeler 4 中使用它。
什么是 Data Vault 2.0？
Data Vault 2.0 是由 Dan Linstedt 开发的一种数据建模方法论，最初于 2000 年代初期推出，并于 2013 年左右得到了大幅扩展。与仅侧重于建模技术的第一版不同，2.0 版将范围扩展至架构模式、方法论，以及与敏捷开发、云计算和自动化等现代实践的集成。
其核心思想很简单：与传统维度表将身份、关系和描述性属性合并到一张表中不同，Data Vault 2.0 将它们分离为三种截然不同的结构类型。正是这种分离赋予了该方法论其韧性和灵活性。
三大基石
中心表代表了核心业务概念，并且只存储业务关键信息，即你的组织实际使用的自然标识符，例如客户编号、产品代码或订单号。因此，客户中心表将仅包含客户编号及其他无关信息。中心表的设计旨在保持稳定。因此，即使源系统发生变化，它们也不会随之改变，而且也不会存储任何可能过时的信息。
链接表记录了中心节点之间的关系。如果客户下单，链接表会通过存储客户中心节点和订单中心节点的哈希键来记录该关系。链接同样是只追加且不可变的，因此一旦关系被记录下来，便不会改变。这使得链接成为业务实体之间所有曾存在关联的可靠审计轨迹。
卫星表中存储着描述性属性及历史数据。连接到客户中心表（hub）的卫星表（satellite）可能会存储客户的姓名、地址和联系方式，以及显示这些属性各版本加载时间的时间戳。由于卫星表与中心表是分离的，因此可以在单个中心上部署多个卫星表——每个源系统一个，或按变更频率分配——而无需修改中心本身。这正是 Data Vault 在需要集成新数据源时如此灵活适应的原因。
何时使用 Data Vault 2.0（以及何时不使用）
当你构建一个需要集成多个源系统、处理频繁的模式变更，并完整记录数据来源及其随时间演变过程的企业级数据仓库时，Data Vault 2.0 的复杂性便显现出来。特别是受监管的行业——如金融、医疗保健和保险——能够从“中心表-链接表-卫星表”模型固有的可审计性中获益，因为每条数据都会按标准格式携带其加载时间戳和源系统信息。
对于较为简单的分析型数据库、建模资源有限的小型团队，或者在集成层上更重视查询简便性和性能而非灵活性的应用场景，Data Vault 并不十分适用。Data Vault 是一个集成层，而非消费层。因此，分析师应查询构建在其之上的呈现层（通常是星型模式或数据集市），而非 Data Vault 本身。那些忽略这一区别并直接查询 Data Vault 的团队，往往会发现多表连接难以驾驭。
使用 Navicat Data Modeler 构建 Data Vault 2.0 模型
Data Vault 2.0 支持在 Navicat Data Modeler 4 中引入，该版本于 2025 年 3 月以独立产品形式发布，同时也集成在 Navicat 17.2 中。它与该工具现有的关系型建模和维度建模方法论支持并存，意味着你可以在同一应用程序中同时使用这三种建模方法。
当你选择 Data Vault 2.0 作为建模方法时，画布和对象类型会根据该方法论进行定制。你可以原生地使用 Hub（中心表）、Link（链接表） 和 Satellite（卫星表） 这些构造，而无需使用通用表对象来近似模拟——这在设计阶段保证了清晰度，也能确保在准备部署时生成准确的 DDL。可视化环境让你能够清晰地看到模型的 Hub-and-Spoke（中心-辐射） 结构，从而更容易理解实体之间的连接方式，以及新的源系统应该接入何处。
Navicat Data Modeler 的更广泛功能集与 Data Vault 工作流非常契合。物理模型准备就绪后，同步模型到数据库命令会将模型与实时数据库进行对比，并为差异部分生成部署脚本——这与 Data Vault 2.0 所倡导的增量式、基于 Sprint 的开发风格天然吻合。导出模型到 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 支持，团队现在拥有了一个直接使用该方法论语言的可视化建模环境，从而减少了设计与实现之间的摩擦。
