数据仓库建模是一种数据库建模方法，旨在为来自多个运营系统的数据提供长期的历史存储。它也是一种查看历史数据的方法，处理诸如审核、数据跟踪、加载速度和对更改的弹性等问题，并强调需要跟踪数据库中所有数据的来源。这意味着数据保管库中的每一行都必须附带记录源和加载日期属性，从而使审计员能够将值跟踪回源。

数据保管库建模不区分好数据和坏数据（“坏”是指不符合业务规则）。[1]数据保管库存储“事实的单一版本”（Dan Linstedt也将其表示为“所有数据，所有时间”）与其他数据仓库方法中存储“真理的单一版本”的做法不同[2]，其中不符合定义的数据被删除或“清除”。

通过显式地将结构信息与描述性属性分离，建模方法被设计成能够适应存储数据的业务环境的变化。[3]数据保险库被设计成尽可能支持并行加载，[4]这样非常大的实现就可以扩展而无需进行重大重新设计。

历史与哲学

在数据仓库建模中，有两个著名的竞争选项用于对存储数据的层进行建模。要么你按照拉尔夫·金博尔（Ralph Kimball）的标准化维度和企业数据总线建模，要么你按照比尔·因蒙（Bill Inmon）的标准化数据库（需要引用）建模。这两种技术在处理向数据仓库提供数据的系统的变化时都有问题[需要引用]。对于一致的维度，您还必须清理数据（以使其一致），这在许多情况下是不可取的，因为这将不可避免地丢失信息[需要引用]。数据保险库存储旨在避免或最小化这些问题的影响，方法是将它们移动到数据仓库中历史存储区域之外的区域（在数据集市中进行清理），并将结构化项（业务键和业务键之间的关联）与描述性属性分离。

该方法的创建者Dan Linstedt对生成的数据库进行了如下描述：

“数据保险库模型是一个面向细节、历史跟踪和唯一链接的规范化表集，支持一个或多个业务功能领域。它是一种混合方法，包含了第三范式（3NF）和星型模式之间的最佳品种。该设计灵活、可扩展、一致且可适应企业的需求“[5]

Data vault的理念是，所有数据都是相关数据，即使它不符合既定的定义和业务规则。如果数据不符合这些定义和规则，那么这是业务的问题，而不是数据仓库的问题。确定数据“错误”是对数据的一种解释，这种解释源于一种特定的观点，这种观点可能对每个人或在每个时间点都无效。因此，数据存储库必须捕获所有数据，只有在报告或从数据存储库提取数据时，才会解释数据。

data vault的另一个响应问题是，越来越多的人需要对数据仓库中的所有数据进行完全的可审计性和可跟踪性。由于美国的Sarbanes-Oxley要求和欧洲的类似措施，这是许多商业智能实现的相关主题，因此任何数据保险库实现的重点都是所有信息的完全可跟踪性和可审核性。

数据保险库2.0是一个新的规范，它是一个开放的标准。[6]新规范包含定义实现最佳实践、方法（SEI/CMMI、六西格玛、SDLC等）、体系结构和模型的组件。Data Vault 2.0专注于包含新组件，如大数据、NoSQL，同时也关注现有模型的性能。旧规范（这里大部分都有文档记录）高度关注数据保险库建模。这在书中有记录：用Data Vault 2.0构建一个可扩展的数据仓库。

为了使EDW和BI系统与当今企业的需求和愿望保持同步，有必要对规范进行改进，使其包括新的组件和最佳实践。

历史

Data vault建模最初是由Dan Linstedt在20世纪90年代构思的，2000年作为一种公共领域建模方法发布。在《数据管理通讯》的一系列五篇文章中，对数据存储方法的基本规则进行了扩展和解释。其中包括一个概述，[7]组件概述，[8]关于结束日期和联接的讨论，[9]链接表，[10]和一篇关于加载实践的文章。[11]

该方法的另一个（而且很少使用）名称是“通用基础集成建模体系结构”

数据保险库2.0[13][14]已于2013年面世，并带来了大数据、NoSQL、非结构化、半结构化无缝集成，以及方法、体系结构和实施最佳实践。

替代解释

根据Dan Linstedt的说法，数据模型的灵感来源于（或模式化的）对神经元、树突和突触的简单看法——神经元与中枢和中枢卫星相关联，链接是树突（信息的载体），其他链接是突触（相反方向的载体）。通过使用一组数据挖掘算法，可以用置信度和强度等级对链接进行评分。它们可以根据对目前不存在的关系的了解，在飞行中创建和删除。模型可以在使用和馈送新结构时自动变形、调整和调整。[15]

另一种观点认为，数据保险库模型提供了企业的本体论，因为它描述了企业领域（集线器）中的术语及其之间的关系（链接），并在必要时添加了描述性属性（卫星）。

将数据保险库模型视为图形模型的另一种方法。数据保险库模型实际上提供了一个“基于图”的模型，其中包含关系数据库世界中的集线器和关系。通过这种方式，开发人员可以使用SQL来获得基于图的关系以及次秒级响应。

基本概念

具有两个集线器（蓝色）、一个链路（绿色）和四颗卫星（黄色）的简单数据保险库模型

Data vault试图通过将业务键（由于它们唯一标识一个业务实体，所以不会经常发生变异）和这些业务键之间的关联与这些键的描述性属性分离，来解决处理环境变化的问题。

业务键及其关联是结构属性，构成数据模型的骨架。数据保险存储方法的一个主要原则是，真正的业务键只有在业务发生变化时才会发生变化，因此是从中派生历史数据库结构的最稳定的元素。如果将这些键用作数据仓库的主干，则可以围绕它们组织其余的数据。这意味着为集线器选择正确的键对于模型的稳定性至关重要。[16]键存储在表中，表中对结构有一些限制。这些关键表称为集线器。

集线器

集线器包含一个具有低更改倾向的唯一业务键列表。集线器还包含每个集线器项的代理项键和描述业务键来源的元数据。中心信息的描述性属性（例如键的描述，可能是多种语言）存储在称为附属表的结构中，下面将讨论这些结构。

集线器至少包含以下字段：[17]

• 代理项键，用于将其他结构连接到此表。
• 一个业务键，这个中心的驱动程序。业务键可以由多个字段组成。
• 记录源，可用于查看哪个系统首先加载了每个业务键。
• 也可以选择使用元数据字段，其中包含有关手动更新（用户/时间）和提取日期的信息。

一个集线器不允许包含多个业务键，除非两个系统传递相同的业务键，但具有不同含义的冲突。

• 集线器通常应该至少有一颗卫星

集线器示例

这是一个包含汽车的hub表的示例，称为“Car”（H_Car）。驾驶钥匙是车辆识别号。

Fieldname	Description	Mandatory?	Comment
H_CAR_ID	Sequence ID and surrogate key for the hub	No	Recommended but optional[18]
VEHICLE_ID_NR	The business key that drives this hub. Can be more than one field for a composite business key	Yes
H_RSRC	The record source of this key when first loaded	Yes
LOAD_AUDIT_ID	An ID into a table with audit information, such as load time, duration of load, number of lines, etc.	No

链接

业务键之间的关联或事务（例如通过购买事务将客户和产品的中心相互关联起来）使用链接表进行建模。这些表基本上是多对多联接表，带有一些元数据。

链接可以链接到其他链接，以处理粒度上的更改（例如，向数据库表添加新键将更改数据库表的粒度）。例如，如果客户和地址之间存在关联，则可以添加对产品和运输公司集线器之间链接的引用。这可能是一个称为“交付”的链接。在另一个链接中引用链接被认为是一种不好的做法，因为它引入了链接之间的依赖关系，这使得并行加载更加困难。由于指向另一个链接的链接与来自另一个链接的集线器的新链接相同，因此在这些情况下，在不引用其他链接的情况下创建链接是首选解决方案（有关详细信息，请参阅加载实践部分）。

链接有时会将集线器链接到本身不足以构建集线器的信息。当链接关联的一个业务键不是真正的业务键时，就会发生这种情况。例如，以“订单号”为键的订单，以及用半随机数键控的订单行使其唯一。比如说，“唯一的数字”。后一个键不是真正的业务键，因此它不是集线器。但是，我们确实需要使用它来保证链接的正确粒度。在这种情况下，我们不使用具有代理键的集线器，而是将业务键“唯一编号”本身添加到链接中。只有在不可能将业务键用于另一个链路或用作卫星中属性的键时，才能执行此操作。丹·林斯特德（Dan Linstedt）在他（现在已经失效）的论坛上把这个结构称为“钉腿链接”。

链接包含链接的集线器的代理项键、它们自己的链接代理项键和描述关联来源的元数据。关联信息的描述性属性（如时间、价格或金额）存储在称为附属表的结构中，下面将讨论这些结构。

链接示例

这是汽车（HúCAR）和人（HúPERSON）两个集线器之间的链接表的示例。该链接称为“Driver”（L_Driver）。

Fieldname	Description	Mandatory?	Comment
L_DRIVER_ID	Sequence ID and surrogate key for the Link	No	Recommended but optional[18]
H_CAR_ID	surrogate key for the car hub, the first anchor of the link	Yes
H_PERSON_ID	surrogate key for the person hub, the second anchor of the link	Yes
L_RSRC	The recordsource of this association when first loaded	Yes
LOAD_AUDIT_ID	An ID into a table with audit information, such as load time, duration of load, number of lines, etc.	No

卫星

集线器和链接构成了模型的结构，但没有时间属性，也没有描述性属性。它们分别存储在称为卫星的表中。它们包括将它们链接到其父集线器或链接的元数据、描述关联和属性起源的元数据，以及带有属性开始和结束日期的时间线。当集线器和链路提供模型的结构时，卫星提供模型的“肉”，即集线器和链路中捕获的业务流程的上下文。这些属性既与事件的细节有关，也与时间线有关，范围从相当复杂（描述客户完整配置文件的所有字段）到相当简单（链接上只有有效指示器和时间线的卫星）。

通常，属性按源系统在卫星中分组。但是，诸如大小、成本、速度、数量或颜色等描述性属性可以以不同的速率更改，因此您还可以根据这些属性的更改速率将它们拆分到不同的卫星中。

所有的表都包含元数据，至少至少描述了源系统和此条目生效的日期，给出了数据进入数据仓库时的完整历史视图。

卫星示例

这是一个关于汽车和人的枢纽之间的司机连接的卫星的例子，称为“司机保险”（S_Driver_insurance）。这颗卫星包含特定于汽车与驾驶人之间关系保险的属性，例如，指示这是否是主要驾驶员，这辆车和人的保险公司名称（也可以是一个单独的枢纽）以及涉及这类车辆和驾驶员组合的事故数量摘要。还包括对一个名为R_RISK_CATEGORY的查找或引用表的引用，该表包含被视为属于该关系的风险类别的代码。

Fieldname	Description	Mandatory?	Comment
S_DRIVER_INSURANCE_ID	Sequence ID and surrogate key for the satellite on the link	No	Recommended but optional[18]
L_DRIVER_ID	(surrogate) primary key for the driver link, the parent of the satellite	Yes
S_SEQ_NR	Ordering or sequence number, to enforce uniqueness if there are several valid satellites for one parent key	No(**)	This can happen if, for instance, you have a hub COURSE and the name of the course is an attribute but in several different languages.
S_LDTS	Load Date (startdate) for the validity of this combination of attribute values for parent key L_DRIVER_ID	Yes
S_LEDTS	Load End Date (enddate) for the validity of this combination of attribute values for parent key L_DRIVER_ID	No
IND_PRIMARY_DRIVER	Indicator whether the driver is the primary driver for this car	No (*)
INSURANCE_COMPANY	The name of the insurance company for this vehicle and this driver	No (*)
NR_OF_ACCIDENTS	The number of accidents by this driver in this vehicle	No (*)
R_RISK_CATEGORY_CD	The risk category for the driver. This is a reference to R_RISK_CATEGORY	No (*)
S_RSRC	The recordsource of the information in this satellite when first loaded	Yes
LOAD_AUDIT_ID	An ID into a table with audit information, such as load time, duration of load, number of lines, etc.	No

（*）至少有一个属性是必需的。（**）如果需要在同一集线器或链路上强制多个有效卫星的唯一性，则序列号将成为必需的。

参考表

参考表是正常的数据保险库模型的正常部分。它们是为了防止重复存储大量引用的简单引用数据。更正式地说，Dan Linstedt定义参考数据如下：

用于解析代码中的描述或以一致的方式将键翻译为（sic）所需的任何信息。这些字段中的许多在本质上是“描述性的”，它们描述了其他更重要信息的特定状态。因此，参考数据与原始数据保险库表位于不同的表中。[19]

引用表是从卫星引用的，但从不与物理外键绑定。参考表没有规定的结构：使用在特定情况下最有效的结构，从简单的查找表到小型数据存储库甚至星星。它们可以是历史的，也可以是没有历史的，但是在这种情况下，建议您坚持使用自然键，而不要创建代理键。[20]通常情况下，数据保险库有很多引用表，就像任何其他数据仓库一样。

参考示例

这是一个带有车辆驾驶员风险类别的参考表示例。它可以从数据保险库中的任何卫星上引用。目前，我们从卫星S U驱动程序保险公司处获得参考。参考表为风险类别。

Fieldname	Description	Mandatory?
R_RISK_CATEGORY_CD	The code for the risk category	Yes
RISK_CATEGORY_DESC	A description of the risk category	No (*)

（*）至少有一个属性是必需的。

装载实践

更新数据保险库模型的ETL相当简单（请参见数据保险库系列5-加载实践）。首先必须加载所有集线器，为任何新的业务键创建代理ID。这样做之后，如果查询集线器，现在可以将所有业务键解析为代理ID。第二步是解析集线器之间的链接，并为任何新关联创建代理项ID。同时，还可以创建连接到集线器的所有卫星，因为可以将键解析为代理项ID。使用代理项键创建所有新链接后，可以将卫星添加到所有链接。

由于集线器除了通过链接之外没有相互连接，因此可以并行加载所有集线器。由于链接不是直接相互连接的，因此也可以并行加载所有链接。由于卫星只能连接到集线器和链路，因此也可以并行加载这些集线器和链路。

ETL非常简单，易于自动化或模板化。只有与其他链接相关的链接才会出现问题，因为解决链接中的业务键只会导致另一个链接也必须解决。由于这种情况等同于连接到多个集线器，因此可以通过重新设计这种情况来避免这种困难，这实际上是建议的做法。[11]

除非在加载数据时出现技术错误，否则不会从数据保管库中删除数据。

数据仓库与维度建模

数据保险库建模层通常用于存储数据。它没有针对查询性能进行优化，也不容易通过知名的查询工具（如Cognos、SAP Business Objects、Pentaho等）进行查询，因为这些最终用户计算工具希望或希望其数据包含在维度模型中，所以通常需要进行转换。

为此，可以将这些集线器上的集线器和相关卫星视为尺寸，将这些链路上的链路和相关卫星视为尺寸模型中的事实表。这使您能够使用视图从数据保管库模型中快速创建维度模型的原型。出于性能原因，维度模型通常在批准后在关系表中实现。

请注意，虽然将数据从数据保管库模型移动到（干净的）维度模型相对简单，但考虑到维度模型事实表的非规范化性质（与数据保管库的第三种正常形式有根本不同），反向移动就不那么容易了。

数据仓库方法

数据仓库方法基于SEI/CMMI 5级最佳实践。它包括CMMI级别5的多个组件，并将它们与六西格玛、TQM和SDLC的最佳实践相结合。特别是，它关注的是Scott Ambler的构建和部署敏捷方法。数据保险库项目有一个短的、范围受控的发布周期，应该每2到3周发布一次产品版本。

使用data vault方法的团队应该很容易适应CMMI级别5预期的可重复、一致和可测量的项目。流经EDW数据保险库系统的数据将开始遵循长期以来从BI（商业智能）项目中丢失的TQM（全面质量管理）生命周期。

 

讨论：请加入知识星球【首席架构师圈】