我刚刚阅读了Data Vault modeling，据我所知，集线器只包含密钥（和记录源）。 所以我想知道为什么我应该创建这些中心表，只存储记录源？仅拥有卫星和链接是不够的？
顺便说一下：我正在寻找数据库形式的简单mysql表来下载和播放。
答案 0 :(得分：2)
Data Vault建模的一个主要概念是业务密钥的分离，卫星的详细数据和连接集线器的链接。
示例
Employee
--------
Personnel Number
Name
Surname
Street
City
Department
--------
ID
Shortcode
Name
Employee Number
想象一下，一个部门只有一名员工。
业务键
现在需要识别业务对象员工和部门的业务标识符。这将是员工的人员编号和部门的短代码。
为什么不部门的 ID ？嗯，ID很可能是数据库内部ID。在此示例中，短代码类似DEP_A1613，内部也用于标识部门。
<强>建模
员工的集线器仅包含人员编号字段和部门的集线器 Shortcode
这意味着Data Vault建模中的Hub用于存储仅的业务键。当然，还需要Data Vault字段，如记录源，加载日期等。两个集线器也将具有相应的卫星用于描述数据。在没有集线器的情况下将卫星链接在一起将违反Data Vault建模技术。它也没有意义：您需要某种通用标识符来保存您的卫星数据，如果您省略Hub，它就不会存在。
<强>结论
所以回答你的问题：你应该为业务键建模Hubs。绝对。实际上，集线器是Data Vault建模的基本要素。链接仅连接到集线器，而不连接到卫星。
想象一下员工软件的变化。所有其他字段现在都存储在Employee卫星中。使用新的源Employee软件时，您可以将所有数据存储在新的卫星中，同时使用相同的Hub和业务键。
只是为了完成此示例：该链接将员工和部门从部门连接到员工编号。
修改
所以例如结构看起来像这样。 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
答案 1 :(得分：0)
集线器是应用多个源的被动集成的地方。您将拥有一个数据源列，并记录每个密钥首次到达集线器时的所有实例。例如，如果我有CRM系统和ERP系统，并且我首先从CRM系统同步数据，那么ERP数据就可用了。我将添加来自CRM系统的所有密钥，数据源列值为＆＃34; CRM＆＃34;。然后，当我引入ERP系统时，假设我具有相同的表格键结构，我只会添加仅存在于ERP系统中的新密钥，其中包含＆＃34; ERP＆＃34;的数据源。如果密钥不同，则必须添加来自两个系统的所有数据。关键是您要保留所有正在运行的系统中的所有数据。当您转移到下一层（无论是商业数据保险库还是数据集市）时，您将根据＆＃34;业务规则＆＃34;对业务逻辑应用业务逻辑。在适用的情况下获取两个系统的单个结果行。如果在将转换存储到此中间状态之前使用转换，则会失去审计能力，并且能够在以后更改业务规则。有意义吗？