數據倉庫設計/建模（基於數據挖掘教科書中的圖）

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 表分開，因為它們是兩個不同的業務實體並在中間實現關系表。

我希望這有幫助。