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

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 表分开，因为它们是两个不同的业务实体并在中间实现关系表。

我希望这有帮助。