在Data Vault 2.0中将销售交易建模为集线器还是链接

Question

我是Data Vault的新秀，请原谅我的无知。我目前正在使用Data Vault 2.0并行进行Raw Data Vault建模和建模。我的假设很少，需要帮助验证它们。

1）单个集线器的建模方式为：

a）产品（持有pk-Product_Hkey，BK，元数据），

b）客户（拥有pk-Customer_Hkey，BK，元数据），

c）存储（保存pk-Store_Hkey，BK，元数据）。 现在，涉及上述所有业务对象的Sales Txn应该建模为链接表

d）链接表-Sales_Link（包含pk-Sales_Hkey，Sales Txn ID，Product_Hkey（fk），Customer_Hkey（fk），Store_Hkey（fk），元数据）和一个Satellite需要与保存一些描述性数据的Link表关联关于链接。 以上方法有效吗？

我对上述链接表的理由是因为 我认为Sales Txn ID是非BK，因此 Sales Txn必须托管在Link（而不是集线器）中。

2）运营数据具有不同类型的客户。（零售，专业）。所有客户（与类型无关）都应在一个中心中建模，而对客户类型的区分应通过对与客户中心绑定的不同卫星（一个用于零售，一个用于专业）进行建模来实现。 以上有效吗？

我研究了在线技术论坛，但理论相矛盾，所以我将其发布在这里。

这里没有适用的代码

Answer 1

• 1. 如果您满意以下几点，我建议将销售建模为集线器，否则链接将是一个很好的设计。

     • 将销售交易作为枢纽（Sales_Hub）：

     • 什么是业务关键？您能否将“销售Txn ID”（唯一编号）视为BK。

     • 此集线器或另一个Link（Sales_Link除外）中使用的同一BK，即链接上的链接。
     • 您可以接受没有卫星的Sales_Link，因为所有描述都存在于Sales_Hub中。
     • 它还将在两个位置（集线器/链接）中存储相同的BK +审计元数据信息，并添加连接以从Hub-satellite获取数据。

• 1. 何时有效

     • 客户信息（零售，专业等）存储在源系统的单独表中。

     • 如果数据来自单个源表，则应该对卫星进行建模，然后应用软规则将其分为业务数据仓库中的类型。