EDW中的代理鍵和參照完整性

Question

問題概述
在采用Inmon樣式的3NF企業數據模型時，有哪些處理代理鍵和引用完整性的常用技術？ 以我為例，我必須填充一個3NF數據模型，該模型提供幾個事務處理系統的“企業視圖”。 此外，每個OLTP都是分布式的，因此每個國家/地區只有一個實例。 因此，我目前面臨的挑戰是將每個源系統整合為一個統一的數據模型。

實際問題
因為每個國家都有自己的“本地” PK，所以當將沖突合並到EDW中時，我需要一種處理沖突的策略。 在這種情況下，簡單地創建復合鍵是否最常見？ 例如source_id + source_country還是在這里生成替代密鑰的更好實踐？

例如：

foob​​ar
ID
描述
...

富巴
ID
描述
...

會成為：

EDW.foobar
ID
foob​​ar_id
source_country
描述

因此，在合並數據模型中，我們最終得到一個新的替代鍵（id），該鍵唯一地標識每個源記錄（foobar_id + source_country）。 這似乎合乎邏輯，但由於某種原因感到不對。 再者，因此，我的問題是，這將對處理EDW中的參照完整性產生什么影響？ 即，如果我們在源3NF和EDW 3NF之間生成新的代理密鑰，則在整個EDW模式中引用這些新密鑰會增加復雜性。 就ETL實現而言，這意味着必須通過現有FK（源系統）查找新生成的代理密鑰，然后將其替換為新的FK。 這意味着在EDW中維護多個FK（一個用於查找新的代理密鑰和新的代理密鑰本身），這似乎很困難。

如果有人對這個問題有經驗，那么我很感謝您的建議，因為我認為我目前的方法行不通。 還有一些必然的主題，例如版本控制和歷史化，以及EDW 3NF和數據集市之間的cdc，也都在這里發揮作用，但我稍后會再講。

NB
我進行的大多數研究都專門針對填充Kimball樣式的數據集市，而不是Inmon的3NF企業數據模型。 此外，我一直在努力尋找關於整合基礎數據庫相同的分布式數據庫這一主題的有用信息。

Answer 1

生成代理密鑰是處理這種情況的最常用方法。 因此，您將擁有代理密鑰（這將為您提供密鑰穩定性並通常具有更好的數據庫性能），但仍將維護您的業務密鑰（因為這就是您將在業務層上顯示的內容）。

這將對處理EDW中的參照完整性產生什么影響？

它不應該有任何東西。 當然，如果這是一個現有倉庫，而您要引入代理密鑰，則必須進行重構以在整個倉庫中傳播代理密鑰，但這應該是一次性的。 在倉庫內，所有物品都應參考代理鑰匙。

這里是關於代理密鑰與業務密鑰的舊討論，非常值得一讀： 代理密鑰與自然/業務密鑰

Answer 2

如果您的國家/地區表中有一個非常好的PK，並且您有另一個與國家/地區形成1-1關系的實體，那么也一定要使用國家/地區PK作為該實體的PK。 它也可以作為FK參考國家表。 這形成了身份關系。 也就是說，一個國家與另一個實體之間的關系是如此牢固，國家的身份也構成了這個實體的身份。

不要養成在創建的每個表上都使用代理鍵的習慣。 即使大多數表都以代理鍵結尾，這樣做的習慣也會自動使設計變得懶惰，並在代理鍵不是最佳選擇時隱藏那些時間。