0


数据仓库—建模方法论—Data Vault 建模

数仓建模方法论—Data Vault 建模

除了 Kim ball 的维度建模理论, Data Vault 也是数据仓库建模的一种方法,最早由Dan Linstedt在20世纪90年代提出,主要应用于企业级数据仓库建模。

不同于三范式数据仓库模型、维度模型,Data Vault模型主要用于存储来自多个业务系统的完整的历史数据。它不区分数据在业务层面的准确与否,装载数据也不做验证和清洗。

Data Vault建模方法显式地将结构信息和属性信息分离, 能够还原业务环境的变化。 Data Vault允许并行数据装载,不需要重新设计就可以实现扩展。Data Vault是面向细节的,可追踪历史的,一组有连接关系的规范化的表的集合。 这些表可以支持一个或多个业务功能。

它是一种综合了第三范式(3NF)和星型模型优点的建模方法。 其设计理念是要满足企业对灵活性、 可扩展性、 一致性和对需求的适应性要求, 是一种专为企业级数据仓库量身定制的建模方式

Data Vault 模型定义

按照Dan Linstedt的定义,Data Vault模型是面向细节的、可追踪历史的、一组有连接关系的规范化的表的集合。它综合了三范式建模和星型模型的优点,其设计理念是满足企业对数据模型灵活性、可扩展性、一致性和对需求的适应性要求,是专门针对企业级数据仓库需要的一套建模方法。

Data Vault模型只按照业务数据的原始状态存储数据,不做任何过滤、清洗、转换,比如:同一客户在不同系统有不同地址,Data Vault模型会存储多个不同版本的客户地址数据。

Data Vault 模型特点

  • 与源系统完成独立。
  • 所有数据基于时间戳,即便数据质量很低,也不能清洗掉数据。
  • 可以适应源数据的各种变化,并可以灵活的实现模型扩展。
  • 数据的来源可以完全追踪,并且数据处理作业可以支持重载。

Data Vault 模型体系

Data Vault模型由中心表、链接表、附属表三部分构成,其核心是中心表,用于存储业务主键,链接表用于存储业务关系,附属表用于存储业务描述。

中心表

中心表用于存储企业每个业务实体的业务主键,业务主键需要能够唯一标识一个业务实体。按此定义,中心表与源系统无关,即无论业务主键是否用于多个业务系统,其在Data Vault模型中也只有一份数据。出于设计上的考虑,中心表一般由主键、业务主键、装载时间戳、数据来源系统四个字段构成,其中主键根据业务主键唯一分配,一般是与业务无关的序列数值。

链接表

链接表是不同中心表之间的关系链接,链接表一般由一组外键字段构成,表示一种业务关系,比如:交易表、客户关联账户等。链接表主要包括主键、外键1、······、外键n、装载时间戳、数据来源系统等字段构成,其中主键对应多个外键的唯一组合,一般是与业务无关的序列数值。

链接表的目的是为了灵活性和易扩展,通过链接表可以在不改变原有的构架和转载条件下进行扩展。在Data Vault模型中所有的 关系和事件都是通过链接表来表示。在DV模型中,中心表没有外键,对于中心表间的连接是通过链接表。所以链接表至少要有两个中心表

附属表(卫星表Satellite)

附属表用于保存中心表和链接表的描述属性,包含了所有历史变化数据,附属表有且仅有一个唯一外键关联到中心表或链接表。附属表主要包括主键、外键、属性1、······、属性n、是否失效、时效时间戳、装载时间戳、数据来源系统,主键用于唯一标识附属表中的一行记录,一般是与业务无关的序列数值。

Data Vault 模型设计

根据Data Vault模型体系构成,Data Vault模型设计也由此分成三大部分。

img

中心表设计
  • 明确模型需要覆盖的业务范围。
  • 按业务范围划分若干原子业务实体,比如:客户、产品、投资品种等。
  • 从业务实体中抽象业务主键,业务主键必须是可唯一标识业务实体且不会发生变化。
  • 按照业务主键生成中心表。

中心表的表结构:
字段说明hub_key代理主键,通过对业务主键进行MD5计算所得business_key业务主键,唯一标识业务主键,来之源系统load_dts数据第一次转载的时间,只记录第一次转载时间rec_src数据源系统

链接表设计
  • 分析业务实体间的业务关系,并识别对应的中心表,这些业务关系可以是一对一、一对多、多对多多种关系。
  • 按业务关系涉及的中心表,提取中心表主键,组成构成链接表的外键,并确定链接表的主键。

说明:链接表内可以保存交易数据,也可以用附属表描述交易数据。

链接表表结构:
字段说明link_key代理主键,使用相关的父Hub表的业务主键拼接后计算MD5值hub_keyshubs的代理键hub_business_keyshubs的业务主键load_dts第一次装载数据的时间rec_src源系统信息

附属表(卫星表Satellite)设计

附属表的设计相对比较简单,主要是从中心表、链接表出发,提取与中心表、链接表相关的上下文描述信息。由于同一业务实体的各类描述信息可能会经常变化、变化频率也不尽相同,因此需要按变化频率将不同属性信息分隔,建立多个附属表。

为了访问数据的方便,可能需要设计PIT表,PIT表不是必须的,但如果一个中心表有多个附属表,就有可能用到PIT表。PIT表的主键是有附属表关联的中心表提取而来,有几个附属表就会有几个字段用于记录附属表的变化时间戳。

在这个表中也捕获数据的变化,所以这种表有点像维度模型中的渐变维度表。 一个附属表总有一个且唯一一个外键引用到中心表或链接表。
字段说明sta_key代理主键,相关的hub或link表的主键和数据载入时间的MD5值hub_or_link_key父hub或Link的代理主键attribute_columns属性数据列hash_diff各列拼接后的MD5值计算sat_load_dts数据装载时间sat_rec_src数据来源信息

Data Vault建模的优点

  • 灵活性:Vault建模支持灵活的数据变化和增量调整,能够快速适应业务需求的变化。
  • 易于扩展:Vault建模支持在不影响现有结构的情况下添加新的实体和关系。
  • 历史数据保留:Vault建模能够轻松管理和保留历史数据,支持数据追溯和历史查询。
  • 数据一致性:通过Hub和Link的设计,Vault建模可以确保数据的一致性和准确性。

需要注意的是,Vault建模并不适用于所有场景,特别是对于较小的数据集或简单的数据需求,可能会显得过于复杂。因此,在选择建模方法时,需要根据具体的业务需求和数据特征进行权衡。

总结

Data Vault的每一行数据都需要包含来源系统和装载时间戳,用于审计和跟踪数据来源的源系统。
表关键字作用Hubs中心表business_key业务主键使其以业务为导向, 并允许跨系统集成Links链接表Associations/Transactions关联和转换提供了在无需重新设计的情况下吸收结构和业务规则更改的灵活性Satellites附属表Descriptors描述性信息提供在任何想要的时间间隔内记录历史记录的适应性, 以及对源系统的无可争辩的可审核性和可追溯性


本文转载自: https://blog.csdn.net/2401_84052244/article/details/137368712
版权归原作者 猫猫姐 所有, 如有侵权,请联系我们删除。

“数据仓库—建模方法论—Data Vault 建模”的评论:

还没有评论