維度表是否必須具有主鍵？

我有一個問題給大家。我首先搜索了任何現有的相同問題，但只找到相關的問題，但並不針對我的問題。所以在這裏：維度表是否必須具有主鍵？

重要的是我的維度表有一個主鍵？我問這是因爲我設計數據倉庫的方式是我在Normalized Data Store上管理我的代理鍵。然後，代理鍵只傳遞給昏暗的表格。來自源系統的任何更新都將首先反映NDS（類型1或覆蓋）。所以基本上，我沒有跟蹤規範化數據存儲的歷史值。但是，我會跟蹤維度數據存儲上的更改。

因此，暗表上的代理鍵不由數據庫管理。如果源系統發生更改，則使用相同代理鍵的新行與除我選擇的類型2更改的字段/列之外的其他所有行相同。

由於在暗表上沒有主鍵，因此在事實表上將不存在FK約束。當使用數據集市（事實和暗淡的表格沒有PK/FK約束）時，這會如何影響數據倉庫的性能？

這裏是我的樣本數據的截圖：

這是好嗎？

2012-09-03 erwin

如何將您的維度加入事實數據表而無需密鑰？我想你實際上的意思是沒有*約束*的關鍵。實施約束會更好。數據完整性應始終在可能的情況下聲明執行。像星型連接優化和其他優化的DBMS功能取決於關鍵約束的存在。 – sqlvogel

感謝您的回覆。但是，由於上面強調的原因，我無法在暗淡表格上創建主鍵約束。 PK是唯一的權利？如果是這樣，則無法在暗淡表格上創建一個表格，因此，事實表格上的FK約束條件是不可能的。 – erwin

在星型模式圖層中生成替代品更爲常見 - 許多ETL工具可自動管理替代鍵的創建，並自動緩慢更改尺寸，無需編碼。如果維度上沒有主鍵約束，您如何知道沒有創建重複項，從而導致報告不準確？ – Steve

是的，你需要在維度表中有一個主鍵。

我猜NDS只是使用代理鍵設計模式來管理不同源系統中的實體。這並不罕見...... here's Thomas Kejser撰寫的一篇很好的文章，涵蓋了一些出現的問題。底線，如果您的NDS只跟蹤1型變化，並且您需要跟蹤數據集市中的2型（歷史）更改，那麼您需要爲混合添加額外的代理鍵。

2012-09-09 13:01:00

回答