一、Data Vault简介

1.1 历史

    在数据仓库建模中，有两个著名的方法用于对存储数据进行建模。可以根据Ralph Kimball建模，具有一致性和企业数据总线，或者根据Bill Inmon建模，实现数据库标准化。在处理为数据仓库提供数据的系统中的变化时，这两种技术都存在问题。为了保持一致性，必须进行数据清理，但会不可避免地丢失信息 。Data Vault旨在通过将数据仓库移动到历史存储区域之外的数据仓库区域（清理在数据集市中完成）并通过分离结构项（业务键和业务键）来避免或最小化这些问题的影响。 

1.2 定义

DataVault2.0是一个商业智能系统，创始人Dan Linstedt将Data Vault描述为：

    Data Vault 模型是一个面向细节的，历史追溯的并且唯一链接的规范化表集，能够支持一个或者多个业务功能区。

    从建模风格上看，它采用了一种由第三范式（3NF）方法与维度建模方法混合而成的方式，以二者的独特组合来满足企业需求。

1.2 组件

1. 建模：对模型性能和可扩展性的更改

2. 方法论：遵循Scrum和敏捷最佳实践

3. 架构：包括NoSQL系统和大数据系统

4. 实施：基于模型、自动化生成能力成熟度模型集成（capacity maturity model integration，CMMI）第五层级

二、Data Vault建模

2.1 模型组件

1. 中心表（Hubs）：以横向方式贯穿企业的实际业务键或者主密钥集合

2. 链接表（Links）：企业中存在于业务键之间的关系和联系

3. 卫星表（Satellites）：真正的数据仓库

2.2 DV建模实例

    例如一个订单销售的普通场景，共有省、市、客户、产品类型、产品、订单、订单明细7个表，图示为实体关系模型（ERD）

将上述ERD转换为DV模型

1.转换中心表

（1）确定中心实体：客户、产品类型、产品、订单、订单明细是订单销售业务的中心实体，省、市等地理信息表是参考数据，不能算是中心实体，实际上是附属表

（2）有入边的实体转换为中心表：客户、产品类型、产品、订单

（3）没有入边只有一条出边的实体：本例无

2.转换链接表

（1）没有入边且有两条或两条以上出边的实体：订单明细

（2）除第一步以外的外键关系：订单和客户之间建立链接表，产品和产品类型之间建立链接表

3. 转换附属表

附属表为中心表和链接表补充属性

2.3 基本规则

1. 业务键是按照粒度和语义内涵进行分割的

2. 关系、事件和跨多个业务键的交叉关系要放到链接结构中

3. 链接结构没有开始或结束日期，只是对数据到达数仓那一刻关系的一种表达

4. 卫星表是按照数据类型以及变更的类型和速度进行分割的

5. 不允许也不提供合规性理念，也不能处理超类型，由Business Vault模型（另一种形式的DV建模，可作为信息交付层）解决

2.4 为什么需要多对多链接结构

源系统表达的关系通常都是对业务规则或者当日业务执行情况的反映，关系定义会随时间变化，若要表达历史数据和未来数据（不重新构建模型和装载程序），就有必要使用多对多关系表

2.5 散列键代替顺序号

原因：要连接异构数据环境（如Hadoop）；消除依赖性

散列函数采用MD5，唯一性概率达99.8%

好处：1. 装载：释放依赖；2. 查询：支持迟加入，易实现

三、Data Vault架构

3.1组成

基于三层数据仓库架构，分为集结区（登陆区）、数据仓库、信息交付层（数据集市）

3.2 目标

1. 无缝连接已有的RDBMS和新的NoSQL平台

2. 使业务用户参与进来，并且为托管式SSBI提供空间（对数据回写或直接控制）

3. 为了实现数据实时到达数仓，不再强制要求数据先进入集结区数据表

4. 为了支持敏捷开发，将经常变更的业务规则从静态的数据对准规则中分离出来

四、Data Vault方法论

方法论中主要介绍了企业项目最佳实践的工程标准，感兴趣可自行翻阅《大数据、数据仓库以及Data Vault》

参考文献

1. 《大数据、数据仓库以及Data Vault》

2. https://en.wikipedia.org/wiki/Data_vault_modeling

3. https://blog.csdn.net/wzy0623/article/details/50222269