從自然鍵映射到基於整數的鍵的最佳實踐是什麼？(ETL)
這個問題更多源於“企業架構”的觀點。（原因是，我們公司才剛剛開始涉足數據管理，並且實際上擁有 DBA——我知道，可怕的是花了這麼長時間才進入數據管理和擁有 DBA，但請耐心等待）。
我先介紹一下背景。
我正在研究如何將數據從遺留系統移動到我們正在建構的新替換系統。與我所說的“業務”、“客戶”或“域”數據（如果有意義的話）相比，這些數據是更多的“查找”數據。我想我的想法是，這是為最終使用者提供選擇的數據，然後與其他類型的數據相關聯。
挑戰在於，在我們推出遺留系統之前，我們不希望在兩個系統中維護（遺留）數據。我們將需要在新系統中維護無法與舊系統一起使用的新數據（因此從這個意義上說，我們將進行雙重維護）。但是我們希望最初從遺留系統中推送或拉取的常見數據。
這意味著某種形式的 ETL，無論是手動編碼，還是我們使用產品。（從程式碼的角度來看，這對我們來說意味著要麼是 RPG——因為遺留系統是 iSeries 和 DB2 for i——要麼是 Java——因為新系統是基於 Java EE 和 AIX 上的 DB2）。從產品的角度來看，這可能意味著 IBM InfoSphere DataStage（因為這是我們選擇用於 ETL 進行倉儲的產品）。
現在到我的問題的實際點：遺留系統在依賴自然鍵的非規範化表中具有數據。新系統在規範化的表格中，在他們的設計中看起來更加“物件導向”（因為大量使用了 Hibernate）。這些表更多地依賴於傳統的基於整數的主鍵。
我想知道，一個最好的系統如何從具有自然鍵的系統映射到具有基於整數的鍵的系統？您如何維護此映射，以便知道何時更新記錄以及何時將新記錄插入基於整數的系統。
一般有什麼建議或最佳實踐嗎？
然後作為附加：任何特定於 RPG、Java 或 InfoSphere DataStage 的東西？
任何想法都會受到讚賞，因為這些想法可能會被納入我們公司正在嘗試建立的最佳實踐中。
我發現在舊（自然）和新（整數）鍵之間建立關係表在這樣的轉換過程中效果很好。整數鍵是使用數據庫的標準自動增量方法建構的。在新表中形成自然鍵的數據上維護唯一鍵。
開發一種可重複的數據同步方法，該方法可以根據需要多次應用。根據您的需要，這可以是每天、每週、每月或按需。使同步模組化，以便可以根據需要進行更新。在某些開發過程中，您最終可能會從新系統回饋回舊系統。
在您開發和部署系統時，跟踪哪個系統是哪個數據的記錄系統。盡可能將控制權轉移到新系統。您可能希望或需要流程來辨識和處理在非記錄系統的系統上發生的更改。
管理從舊系統到新系統的轉換。如果可能，在記錄系統更改為新系統時禁用舊系統中的更新。這將需要從新系統到舊系統的饋送。