是在Data 2.0中将销售事务建模为集线器还是链接？

Question

我是数据仓库的新手，所以请原谅我的无知。目前，我正在使用Data 2.0并行地提升和建模原始数据库。我几乎没有什么假设，需要帮助来验证它们。

1)为下列各中心建立了模型：

a)产品(持有pk-Product，BK，元数据)，

b)客户(持有pk-Customer_Hkey、BK、元数据)，

c)存储(持有pk-Store_Hkey、BK、元数据)。现在，涉及上述所有业务对象的销售Txn应该建模为Link

d)链接表-Sales_Link(持有pk- Sales _Hkey、Sales Txn ID、Product_Hkey(fk)、Customer_Hkey(fk)、Store_Hkey(fk)、元数据)和卫星需要关联到包含有关链接的描述性数据的链接表。上述方法有效吗？

我的上述链接表的理由是，我认为销售Txn ID是一个非BK&因此，销售Txn的必须托管在一个链接，而不是集线器。

2)业务数据有不同类型的客户(零售、专业)。所有客户(不知道类型)都应该在一个集线器中建模&这种客户类型的区别应该通过建模不同的卫星(一个是零售卫星，一个是专业卫星)连接到客户中心。以上内容有效吗？

我已经研究了在线技术论坛，但有相互矛盾的理论，所以我在这里张贴。

这里没有适用的代码。

Answer 1

• ​
  1. 我建议把销售建模为集线器，如果你对下面的点没意见，其他链接是非常好的设计。

    - **Sales transaction as a hub (Sales\_Hub) :**
    - Whats business key? Can you consider "Sales Txn ID"(unique number) as a BK.
    - Is this hub or the same BK used in another Link (except Sales\_Link) i.e. link on link.
    - Are you ok with Sales\_Link with no satellite, since all the descriptive exists in Sales\_Hub.
    - Also it will store same BK+Audit metadata info in two places (Hub/Link) and addition joins to fetch data from Hub-satellite.

​

​

• ​
  1. 是有效的。

    - Customer information (retail,professional..etc) stored in separate tables at source(s) system.
    - You should model a satellite if the data is coming thru single source table then you apply soft rules to bifurcate them into their type in Business data vault.

​

​