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

Question

我发现在谷歌图片的模式（见下文），可以说明我的数据仓库设计有我一个问题：

我的设计是不同的，但这是我能找到的最简单的数字来表达我的问题，它给出了这个图，我想知道架构如何适应以下情形：如果产品具有由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 
... 

当然这些都需要正确的秀场到正确的销售组织。取决于你的报告工具，这可能或多或少困难。例如，如果您手动编写查询，则只需在选择中放入正确的列。

另一种可能性是有一个产品/ sales_org表，结合产品和Sales_Org一个表：

Product_Sales_Org_id 
Product_id 
Sales_Org_id 
Product_SO_number 
... 

该表将两个维度表和事实表，你的孩子将有Product_Sales_Org_id列。根据产品和销售组织，Product_SO_number将返回每个SO的正确数字。

如果你想有这样的星型模式结构，你可以把产品/ Sales_Org/Product_Sales_Org在一起，就像只有一个表：

Product_Sales_Org_id 
Product_id 
Sales_Org_id 
Product_desc 
Sales_Org_desc 
Product_SO_number 
... 

真诚我会去的第二个解决方案，保持产品和Sales_Org表分开，因为它们是两个不同的业务实体，并在中间实施关系表。

我希望这会有所帮助。