数据仓库设计/建模（基于数据挖掘教科书中的图）

Question

我在Google图片中找到了一个架构（见下文），可以说明我在数据仓库设计中遇到的问题：

我的设计不同，但这是我能找到的最简单的数字来表达我的问题，给出了图，我想知道模式如何适应以下情况：如果产品分配了一个唯一编号它由SalesOrg（salesOrg_product_number）...例如，salesOrg销售食品并为相同类型的所有食品分配相同的唯一salesOrg_product_number。对于该类型的产品，不同的salesOrg将具有不同的salesOrg_product_number。

我倾向于将salesOrg_product_number属性放在Product维度表中，但我认为它应该在salesOrg维度表中。我想知道在数据仓库（非关系数据库）设计中哪一个是正确的方法来维护星型模式？

Answer 1

在一个完美的世界中，维度表的主键应该只是代理键，对业务没有任何意义。对于最终用户，表ID应该是不可见的，但业务代码当然应该可用。

可能的解决方案是使产品表具有如下结构：

Product_id
Product_desc
Product_SO1_number
Product_SO2_number
...

当然，这需要向正确的销售组织显示正确的字段。根据您的报告工具，这可能或多或少有困难。例如，如果您手动编写查询，则只需将右列放在选择中即可。

另一种可能性是拥有product / sales_org表，一个将Product和Sales_Org组合在一起的表：

Product_Sales_Org_id
Product_id
Sales_Org_id
Product_SO_number
...

此表将是二维表的子表，在事实表上将包含Product_Sales_Org_id列。根据产品和销售组织，Product_SO_number将返回每个SO的正确数字。

如果您想在星型模式结构中使用它，可以将Product / Sales_Org / Product_Sales_Org放在一个表中，如：

Product_Sales_Org_id
Product_id
Sales_Org_id
Product_desc
Sales_Org_desc
Product_SO_number
...

真诚地，我会选择第二个解决方案，将Product和Sales_Org表分开，因为它们是两个不同的业务实体，并在中间实现关系表。

我希望这会有所帮助。