数据保险库模型：集线器有什么用？答案

【问题标题】：Data vault model: what are hubs good for?数据保险库模型：集线器有什么用？
【发布时间】：2016-11-04 01:15:17
【问题描述】：

我刚刚阅读了有关Data Vault modeling 的信息，据我了解，集线器仅包含键（和记录源）。所以我想知道为什么我应该创建那些集线器表，只是为了存储记录源？难道只有卫星和链接就够了吗？

顺便说一句：我正在寻找数据保险库形式的简单 mysql 表以供下载和使用。

【问题讨论】：

标签： mysql data-warehouse modeling data-vault

【解决方案1】：

Data Vault 建模的主要概念之一是分离业务密钥、详细数据的卫星和连接集线器的链接。

示例

Employee
--------
Personnel Number
Name
Surname
Street
City

Department
--------
ID
Shortcode
Name
Employee Number

假设一个部门只有一名员工。

业务密钥

现在需要识别业务对象 Employee 和 Department 的业务标识符。这将是 Employee 的 Personnel Number 和 Department 的简码。

部门为什么不用ID？那么，ID 很可能是数据库内部 ID。在此示例中，短代码类似于 DEP_A1613，在内部也用于标识部门。

建模

Employee 的中心仅包含字段 Personnel Number，Department 的中心仅包含 Shortcode .

这意味着 Data Vault 建模中的 Hub 仅用于存储业务密钥。当然，Record Source、Load Date 等 Data Vault 字段也是需要的。两个集线器也将具有用于描述数据的相应卫星。在没有集线器的情况下将卫星连接在一起将违反 Data Vault 建模技术。这也没有任何意义：您需要为您的 Satellite 数据提供某种通用标识符，如果您省略 Hub，则不会存在该标识符。

结论

所以回答您的问题：您应该为业务密钥建模集线器。绝对地。集线器实际上是 Data Vault 建模的基本元素。链接只连接到集线器，不连接到卫星。

想象一下 Employee 软件的变化。所有其他字段现在都存储在 Employee 卫星中。当使用新的源 Employee 软件时，您可以将所有数据存储在一个新的卫星中同时使用相同的 Hub 和业务密钥。

只是为了完成这个示例：该链接会将 Department 中的 Employee 和 Department 与 Employee Number 连接起来。

编辑

例如，结构看起来像这样。 Data Vault 特定字段标有 [DV]：

Hub Employee
------------
Employee Hash Key [DV]
Load Date [DV]
Record Source [DV]
Personnel Number

Sat Employee
------------
Employee Hash Key [DV]
Load Date [DV]
Load End Date [DV]
Record Source [DV]
Hash Diff [DV]
Name
Surname
Street
City

Link Employee Department
------------------------
Employee Department Hash Key [DV]
Employee Hash Key [DV]
Department Hash Key [DV]

Hub Department
--------------
Department Hash Key [DV]
Load Date [DV]
Record Source [DV]
Shortcode

Sat Department
--------------
Department Hash Key [DV]
Load Date [DV]
Load End Date [DV]
Record Source [DV]
Hash Diff [DV]
ID
Name

【讨论】：

非常感谢您的详细解答。但我必须承认我仍然不明白这一点。只包含部门的集线器表有什么用？短代码？由于短代码也必须在卫星中，我认为没有理由阅读集线器表！？
这不是真的：短代码不会驻留在卫星中。卫星中没有业务密钥或链路密钥。卫星将使用业务密钥的哈希密钥连接到集线器。
好的，所以集线器将部门简码与卫星中的数据分开。短代码是卫星有什么缺点？
第一，这不是建模技术的一部分。您将希望避免将卫星加入卫星，这可能使高级用户能够这样做。第二个集线器将业务密钥与描述卫星数据分开。第三个枢纽是通过链接（DV 的驱动因素之一）加入以嵌入新资源的地方。这不适用于卫星中的业务密钥。考虑一下并行化，没有哈希键是不可能的。
@tobi6 快速附加问题：为什么记录源在中心？假设一条记录来自多个来源（例如，在客户的情况下，假设有一个 CRM 来源、一个销售来源和一个保修来源）？在大多数情况下，您不会有 3 颗卫星，每颗卫星都连接到一个源。如果是这样，源信息不应该在卫星中吗？）谢谢！

【解决方案2】：

集线器是应用多个源的被动集成的地方。您将有一个数据源列，并在每个键首次到达您的集线器时记录它的所有实例。例如，如果我有一个 CRM 系统和一个 ERP 系统，并且我先从 CRM 系统同步数据，那么 ERP 数据就可用了。我将添加来自 CRM 系统的所有键，数据源列值为“CRM”。然后当我引入 ERP 系统时，假设我有相同的表键结构，我只会添加仅存在于 ERP 系统中的新键，数据源为“ERP”。如果密钥不同，则必须添加来自两个系统的所有数据。关键是您保留了来自所有正在运行的系统的所有数据。当您移动到下一层时，无论是业务数据保险库还是数据集市，您都将根据“业务规则”对集线器和卫星应用业务逻辑，以便在适用的情况下获得两个系统的单个结果行。如果您在将其存储在此中间状态之前使用转换，您将失去审计能力，以及在以后更改业务规则的能力。有意义吗？

【讨论】：

当不同系统采购同一个 Hub 时，业务密钥看起来相似非常重要。如果不是这种情况，则应使用 Same-As-Links。这还将从 Business Vault 层（业务规则）中取出逻辑，并为 Hub 提供所需的单个条目。我不会在下一层应用逻辑。