3

我是新的維度建模我相信你們可以幫助我在下面的疑惑。自然的關鍵和事實表

在生產系統中,我有一個事務表,例如銷售表。唯一標識符是一個名爲SaleId的主鍵。 例子:

enter image description here

我的疑問是造型事實表時,應在SaleID包含在事實表作爲NaturalKey?

enter image description here

而且應該事實表有SurrogateKey?

請隨時給我任何鏈接作爲參考。 在此先感謝

回答

3

從技術上講,它可能不是一個自然的關鍵 - 它確實看起來系統生成。但是,有時將系統生成的ID存儲在事實中用作退化維度非常有效。通常情況下,這些商業用戶確實可以看到這個系統生成的ID(訂單號,發票號,採購訂單號等),或者沒有其他有用的方法來識別可以有用地分組在一起的某些行。

如果您的商務智能解決方案的用戶可能希望能夠深入瞭解信息並通過銷售查看信息,那麼SaleID可能是此治療的良好人選。想一想,是否有其他途徑可以讓他們達到這個水平 - 客戶可以在同一天與兩種不同的銷售聯繫在一起嗎?如果是這樣,您的用戶是否希望將它們看作兩個單獨的銷售?您可能需要與他們交談,以瞭解對他們有用的東西。如果由於某種原因你不能得到明確的答案,我會說保留它 - 幾乎沒有什麼傷害,如果它沒有被使用,你可以在以後刪除它。

這裏的金博爾組對退化維度取,如果你在所有不清楚他們是如何工作的:

http://www.kimballgroup.com/2003/06/design-tip-46-another-look-at-degenerate-dimensions/


至於事實表代理鍵 - 我總是用他們。正如Kimball的Design Tip #81所指出的那樣,它們有時是有用的,而且這是我最初希望放入的那種東西,而不是後來才意識到它會有用。第2點 - 您可能希望通過插入新行並刪除舊行來進行更新 - 當然適用於我所做的工作。

+1

我刪除了我的答案,因爲你提供了更多信息。我稍微修改它只是爲了刪除對我的引用,我希望你不介意。 –

+1

@MarekGrzenkowicz編輯很好,謝謝你讓我知道!我只是想把它應該歸功於哪裏,因爲你已經過了一些有效的分數。 –

4

事實表中主鍵的需求取決於事實表的類型。從不更新的交易事實並不需要它。定期快照可能不需要它,除非當前時段是迄今爲止的測量。積累快照肯定需要它。