案例研究：如何透過複雜的ER圖解決遺留系統遷移中的資料重複問題

在資料架構領域，很少有挑戰比遺留系統中的資料重複問題更為持久。當組織致力於現代化其基礎設施時，大量重複、不一致且孤立的資料往往成為主要瓶頸。本案例研究探討了一個真實情境，其中詳細的實體-關係圖（ERD）作為解決重大遷移專案期間關鍵資料完整性問題的藍圖。

目標非常明確：從碎片化、基於平面檔案的遺留環境，轉向穩健的關聯式資料庫，同時不損失資料的準確性，也不引入新的不一致。解決方案並不在遷移工具本身，而在於在移動任何位元之前，對資料進行視覺化建模與邏輯結構化。我們將探討此方法的實施過程、所遇到的具體正規化挑戰，以及嚴謹的資料結構設計方法所帶來的實際成果。

🔍 遺留資料結構的挑戰

遺留系統往往在數十年間累積了資料債務。它們是根據當時的特定需求建構而成，更重視開發速度而非長期的可維護性。在本案例分析中，來源系統結合了層級結構與平面檔案結構，這些結構經過多年逐步更新後被拼湊在一起。

遺留狀態的主要特徵包括：

• 硬編碼邏輯：業務規則直接嵌入應用程式程式碼中，而非在資料庫層級強制執行。
• 非正規化儲存：由於缺乏現代索引技術，為提升讀取效能，資料經常在多個資料表中重複儲存。
• 缺乏參考完整性：外鍵約束很少被強制執行，導致孤立記錄大量產生。
• 命名規範不一致：識別符變化極大，導致在無人為介入的情況下，自動映射幾乎不可能實現。

這種環境造成了極高的風險，例如更新異常。若客戶地址變更，必須在數十個不同的資料表中更新。若未能更新所有實例，將導致資料不一致。此外，插入異常會阻止新增資料，除非複製現有記錄，且刪除異常在刪除無關記錄時，可能導致關鍵資訊遺失。

🛠️ 實體-關係圖的角色

實體-關係圖不僅僅是一張圖表，更是資料與消費它的應用程式之間的邏輯合約。在此次遷移中，ERD扮演了唯一真實來源的角色。它迫使團隊在實際實施之前，明確定義關係、識別主鍵，並建立基數規則。

為何ERD對此專案至關重要？

• 可視化複雜性：遺留資料關係是模糊不清的。圖表使隱藏的依賴關係變得清晰可見。
• 正規化強制執行：該模型要求團隊應用正規化規則，系統性地消除重複資料。
• 映射指南：它為將遺留欄位映射至新的正規化資料表提供了清晰路徑。
• 利害關係人溝通：它讓業務分析師能夠根據現實世界的業務流程來驗證邏輯。

📂 案例研究情境：零售銀行整合

在本次分析中，我們考慮一家零售銀行從主機時代的系統遷移至基於雲端的關係型資料庫。舊系統管理客戶帳戶、交易和貸款記錄。然而，由於系統年代久遠，客戶資訊在交易日誌中被重複儲存。

ERD分析之前：

表格名稱	主要鍵	重複資料	問題
TXN_LOG	TXN_ID	客戶姓名、地址	地址變更需要更新數千列資料。
ACCT_HIST	HIST_ID	分行代碼、分行位置	分行關閉導致資料衝突。
LOAN_DETL	LOAN_ID	客戶編號、帳戶編號	連結經常遺漏或重複。

此結構違反了資料庫設計的基本原則。ERD流程要求將這些表格拆分為原子且獨立的實體。

🧩 步驟 1：識別實體與關係

遷移的第一階段涉及從舊系統中提取每一張表格和欄位。團隊隨後將這些項目對應到邏輯實體。目標是識別業務領域中的獨立物件。

• 客戶： 一個持有帳戶的獨特個人或實體。
• 帳戶： 客戶持有的特定金融產品。
• 交易： 與帳戶相關的資金移動。
• 分支： 一個實際的銀行運作地點。

實體定義完成後，便建立了關係。ERD顯示，一個客戶可以擁有多个帳戶。一個帳戶可以有多筆交易。一筆交易會與特定分支相關聯。這些關係通常表示為：

• 一對多 (1:N)： 一個客戶對應多個帳戶。
• 一對多 (1:N)： 一個帳戶對應多筆交易。
• 多對一 (M:1)： 多筆交易對應一個分支。

透過視覺化地繪製這些連結，團隊識別出資料重複的位置。例如，客戶姓名出現在 TXN_LOG 表格中。在規範化模型中，交易表格應僅儲存對客戶表格的參考（外鍵），而非資料本身。

📐 步驟 2：應用規範化規則

規範化是組織資料以減少冗餘並提升完整性的一種過程。ERD模型引導團隊完成標準的規範形式。

第一範式 (1NF)

舊系統包含重複群組。例如，舊客戶表格中的一行可能在單一欄位中儲存多個電話號碼（例如：「555-0199, 555-0200」）。

• 問題： 這使得查詢特定電話號碼變得困難，並違反了原子性。
• ERD 解決方案： 建立一個獨立的 Contact_Information 實體，與客戶實體連結。此新表格中的每一列僅儲存一個電話號碼。

第二範式 (2NF)

2NF 要求表格必須處於 1NF，且所有非鍵屬性必須完全依賴於主鍵。舊系統的 TXN_LOG 表格具有複合鍵 TXN_ID 和 DATE。然而，客戶詳情僅依賴於 客戶編號，而不是交易日期。

• 問題：客戶資料在每次交易中重複出現，導致更新異常。
• ERD 解決方案： 從交易表中移除客戶詳細資料。將其儲存在專用的客戶表中，並透過外鍵進行連結。

第三範式（3NF）

3NF 要求所有屬性僅依賴於主鍵，不得存在傳遞依賴。在舊系統中，分行的名稱和地址儲存在帳戶表中，但它們依賴於分行編號，而非帳戶編號.

• 問題：如果分行更換地點，所有與該分行相關的帳戶記錄都必須更新。
• ERD 解決方案： 建立一個獨立的分行表。現在帳戶表僅儲存分行編號.

🔄 步驟 3：遷移執行策略

在定義新的 ERD 後，遷移計畫即以新資料結構為基礎進行規劃。此過程並非簡單的複製貼上，而是一次轉換。

1. 資料提取：原始資料從舊系統提取至暫存區。
2. 清洗：根據ERD中定義的業務金鑰，識別並合併重複記錄。
3. 轉換：撰寫腳本，根據第一範式（1NF）、第二範式（2NF）和第三範式（3NF）的規則，將非規範化的欄位拆分至新表格中。
4. 映射：產生外鍵以連結新表格。使用代理鍵（系統產生的ID）以確保穩定性，不受舊系統業務金鑰影響。
5. 載入：資料依照特定順序插入目標資料庫，以確保參考完整性（父表優先於子表）。

ERD在此至關重要，它決定了載入順序。例如，客戶表格必須在帳戶表格之前載入，而該表格又必須在交易表格之前載入。若以其他順序載入，將導致約束違規。

✅ 步驟4：驗證與測試

遷移後的驗證工作非常全面。目標是確保資料總量保持不變，即使結構已改變。團隊利用ERD定義資料的預期狀態。

完整性檢查

• 參考完整性：確保客戶ID在帳戶表格中存在於客戶表格中。
• 完整性：確認轉換過程中沒有記錄遺失。
• 唯一性：確認主鍵具有唯一性，且新表格中不存在重複資料。

對比指標

以下指標用於比較來源系統與目標系統：

驗證指標	目標標準	方法
記錄數量	來源數量 = 目標數量	每個標準化實體的列數
數值總和	來源總餘額 = 目標總餘額	數值欄位的聚合
空值檢查	NOT NULL 欄位中無意外的零空值	查詢限制
重複檢查	主鍵上無重複	GROUP BY 分析

📉 冗餘減少的影響

從傳統結構轉向標準化的ERD模型，帶來了可衡量的效能與維護改善。

• 儲存效率： 透過移除重複的客戶地址與分支細節，儲存需求降低了約35%。
• 查詢效能： 以往需要掃描大型非標準化表格的查詢，現在透過連結較小且已索引的表格而變得更快。
• 更新速度： 更新客戶地址現在只需在 客戶 表格中進行單一資料列更新，而非在交易記錄中進行數千次更新。
• 資料一致性： 透過強制執行單一可信來源，消除了衝突資料的風險（例如，同一客戶有兩個不同的地址）。

🛡️ 處理邊界情況與歷史資料

遺留系統遷移中最困難的方面之一，是處理不符合新模型的歷史資料。ERD協助定義了如何優雅地處理這些例外情況。

• 孤兒記錄： 與源系統中已不存在的客戶相關的交易已被標記。團隊決定將這些記錄存檔於一個歷史_遺留 表中，以維持審計追蹤，同時不破壞新的關係。
• 遺失的金鑰： 當遺留系統中缺少客戶ID時，遷移腳本會生成一個暫時的占位符ID，並將該記錄標記為需人工審核。
• 軟刪除： 並非物理刪除記錄，新架構包含了is_active 標誌。這保留了歷史記錄，同時確保活躍報表僅查詢當前資料。

🚀 為未來做好準備的資料結構

ERD並非僅為當前遷移而設計；它是為應對未來的增長而構建的。透過遵循規範化原則，資料結構變得足夠靈活，可在不進行結構性重構的情況下支援新功能。

• 可擴展性： 實體的分離允許水平擴展。例如，交易 表可按日期進行分片，而不會影響客戶 表。
• 可擴展性： 若新增一種產品類型（例如房貸），可連結至現有的客戶 和帳戶 實體，而無需更改核心資料結構。
• 文件化： ERD作為動態文件。新開發人員可透過檢視圖示立即理解資料模型，從而縮短入職時間。

💡 數據架構師的關鍵教訓

此案例研究突顯了執行類似遷移的團隊應汲取的幾項關鍵教訓。

• 遷移前先建模： 在未經過驗證的資料結構設計前，絕不要嘗試將資料移入新系統。ERD就是藍圖。
• 透過規範化解決冗餘問題： 不要害怕資料標準化。這是防止資料不一致的首要防線。
• 持續驗證： 測試應在遷移的每個階段進行，而不僅僅在最後階段。
• 記錄關係： 理解基數。了解關係是 1:1 還是 1:N，可避免資料模型中的邏輯錯誤。
• 保存歷史： 遷移不僅僅是關於當前資料；更是為了保存過去的完整性。

🔗 數據完整性總結

從傳統系統過渡到現代資料庫很少只是簡單的搬移與放置。這需要對資料組織方式進行根本性的重新思考。實體-關係圖在此過程中被證明是最寶貴的資產。它提供了必要的清晰度，以拆解冗餘結構並以完整性重建它們。

透過優先考慮邏輯設計而非立即實施，該組織達成了穩定、可擴展且一致的資料環境。冗餘的減少消除了重大營運風險，並為未來的分析與商業智慧計畫奠定了穩固的基礎。

資料冗餘不僅是儲存問題；更是一種商業風險。透過嚴謹的建模來解決此問題，可確保資料持續成為決策的可靠資產，而非阻礙進展的負擔。