Data Vault

转载: 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如果是事件级别,粒度过细,如何安排聚合表?

参考与资源:

 

©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页