转载： http://datawarehou.se/knowledge/data-vault/#comment-146

 

Data Vault

前言：Data Vault这个词对我来说非常陌生，一次和Vincent的邮件交流中他提到这个概念。查了下资料，总结如下。

Data Vault是一种新的针对企业级数据仓库的数据建模方法，该概念主要面向数据架构师、数据建模人员和数据库管理员。

——————————————————————————–

Data Vault的定义：

Data Vault是面向细节，可追踪历史的，它将那些支持了一个或多个业务功能单元的规范的表集合相连接，它是一种混合了包括第三范式（3NF）和星型模型在内的建模方法。其设计理念是要满足企业对灵活性、可扩展性、一致性和对需求的适应性要求，它是一种专为企业级数据仓库量身定制的建模方式。

Data Vault并不是一个新鲜事物，早在20年前就已经有所尝试，只不过并没有系统化、程式化。在Data Vault的理念中，错误的数据往往不是由于技术原因造成，而是业务的错误造成（数据的错误），所以，所有数据（包括错误数据）都是有用的、相关的，必须可追溯、可审计。

Data Vault要解决的问题：

在对数据仓库的建模方法中，有Kimball主张的维度建模，也有Inmon提倡的3NF建模，但二者各有优缺点。

对于维度建模，可能会造成孤立的主题域，数据大量冗余，不一致的查询结构，扩展问题，粒度不一致造成的难以与事实表连接，近实时同步问题等。在做维度建模的时候，需要从原有系统进行大量的转换、统一才能形成维度-事实。

对于3NF建模，基于日期的主键会造成父子关系越来越复杂，级联变更的影响也很大，很难进行实时装载，查询存取要关联多表，下钻分析问题等。

Data Vault的实施：

主要思想：将业务主键与属性分离，业务主键常常是业务的本质，他们很少变化，而属性可能会经常变化，Data Vault从变化中提取不常变的部分，并将二者相关联。

提取出的属性按照业务组分到不同的卫星表（Satellites）中，而业务主键放置在称为枢纽表（Hubs）的地方。业务主键之间的关联或事件（如客户Hub和产品Hub之间的“购买”事件）由连接表（Link）来构建模型，并通过卫星表来描述这种联系。从另一种角度来说，卫星表提供了Hub和Link的上下文。

在Data Vault中，所有表都是多对多关系。

总结：

• Data Vault，Vault意为拱顶、撑杆跳等，在这里确不知该翻译成什么合适，觉得这模型更像天文模型
• 所有数据，无论对错，全部保留，历史信息完全可追溯，Data Vault中没有“删”
• 三种类型的表：Hub保存了业务主键，这些东西通常不发生变化；Satellite保存了业务属性，与Hub以多对多形式关联以提供描述信息、上下文；Link表是事件，通过Link将Hub关联起来，一个事件可以对应多个Hub
• 所有物理表以多对多形式连接

几个问题：

1. 如何将业务主键提取出来，如果它们发生了变化怎么办？
2. 怎么确定哪些属于键，哪些属于属性？
3. 从Data Vault模型到维度模型的转换，是否要在建模初期进行考虑，如果是，哪些问题需要确定？
4. 查询性能，钻取效率如何？
5. Link如果是事件级别，粒度过细，如何安排聚合表？

参考与资源：

• Wikipedia – Data Vault Modeling
• Data Vault Series 1 -  Series 2 – Series 3 – Series 4 – Series 5(注：文章分为5部分，作者是Data Vault的倡导者Dan Linstedt)
• Data Vault Basics (Dan Linstedt的blog上的文章)
• 关于Data Vault的图书《The Business of Data Vault Modeling》
• E learning: http://learndatavault.com/