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

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

我希望这会有所帮助。