我設計和星型模式建立銷售事實表,我似乎無法找出如何去以下問題:維度數據倉庫的客戶擁有多個帳戶
客戶可以有1或2個賬戶,但一個賬戶只能屬於1個客戶。所以這是一對多的關係。
我應該爲客戶和帳戶創建維度,並將它們與橋錶鏈接起來嗎?
在最後的事實表我會爲例行:
| date_id | cust_id | Acc_id | count(sales) |
| 1 | 150 | 25 | 1 |
| 1 | 150 | 26 | 1 |
我設計和星型模式建立銷售事實表,我似乎無法找出如何去以下問題:維度數據倉庫的客戶擁有多個帳戶
客戶可以有1或2個賬戶,但一個賬戶只能屬於1個客戶。所以這是一對多的關係。
我應該爲客戶和帳戶創建維度,並將它們與橋錶鏈接起來嗎?
在最後的事實表我會爲例行:
| date_id | cust_id | Acc_id | count(sales) |
| 1 | 150 | 25 | 1 |
| 1 | 150 | 26 | 1 |
只需創建賬戶和客戶維度。 不要用外鍵鏈接它們 - 如果你要創建一個完全標準化的模式,而不是星型模式,那麼你會這樣做。客戶與客戶之間的鏈接保存在事實表中 - 因爲您有一行數據與Acc_Id 25一起保存Cust_Id 150,另一行數據與Acc_Id 26保持相同的Cust_Id,所以在任何OLAP層你建立它是相關的。
請注意,您也可以只擁有一個帳戶維度,並將該客戶的詳細信息保存爲該帳戶的屬性。儘管不知道模型的其餘部分,但無法分辨這是否是更合適的解決方案。
你的第一個建議很有意義。謝謝!我寧願將它們分開,以免重複客戶詳細信息。此外還有一些帳戶特定的細節可以存儲在帳戶維度中。感謝您澄清我不需要鏈接它們。 – 2015-04-24 01:30:58
@GrantMcKinnon很高興幫助!請記住,在星型模式中,您不應該擔心數據重複(只要它是有意的數據重複,就像我們正在討論的類型一樣)。事實和維度都應該由穀物決定 - 所以如果你有一個以客戶爲穀物的事實表,那麼你需要一個客戶維度。如果沒有,單獨維度沒有真正的收益。需要一段時間才能習慣這種心態,我發現! – 2015-04-24 07:01:49
創建一個客戶表,與CUST_ID作爲主鍵。使用Acct_ID作爲主鍵並將Cust_ID作爲外鍵創建帳戶表。每個帳戶必須有且僅有一個客戶,但客戶可以在多個帳戶中列出。
什麼是「銷售事實表」?你想跟蹤訂單嗎?
數據倉庫中星型模式的事實表。我認爲你指的是關係數據庫,這些數據已經存儲在關係表中。我將它合併到一個總銷售額作爲總體功能和客戶和賬戶維度的模式中。事實表的每一行對應於一個銷售給一個客戶的賬戶。銷售只能是一個賬戶和客戶,但是Im堅持的是如何連接客戶和賬戶維度 – 2015-03-25 04:16:42
ACC_ID獨一無二嗎?這不是一個CUST_ID或任何類似這樣的複合關鍵字, – APC 2015-03-25 05:07:28
是的,它的唯一 – 2015-03-25 05:14:21
是否有可能爲賬戶和客戶設置不同的維度,並且在賬戶維度中有一個外鍵鏈接回客戶維度 – 2015-03-25 05:15:59