資料庫架構隨著應用程式的複雜度而演進。在開發初期，單一資料庫通常足以處理所有資料操作。然而，隨著系統擴展，初始的資料結構經常成為瓶頸。這種狀態通常被稱為單體架構模式。其特徵包括緊密耦合的資料表、重複的資料以及僵化的約束，這些都會妨礙可擴展性。為了解決此問題，工程師會進行結構性重設計。實體關係模型（ERM）提供了理論框架，可有效視覺化並組織這些變更。本指南探討了使用 ERM 原則重構單體架構模式的技術流程，以實現更具韌性的資料層。
理解單體架構模式的問題 📉
單體架構模式通常源自自然成長，而非刻意規劃。功能被逐步加入，資料表也為了滿足即時需求而建立，卻未考慮未來的分離。長期下來，這會導致多項技術負債的指標：
- 亂麻般的關係：外鍵連結無關的實體，造成循環依賴。
- 資料重複：相同資訊儲存在多個資料表中，導致更新時出現一致性問題。
- 緊密耦合：應用程式邏輯無法解耦，因為資料庫結構強制要求緊密結合。
- 效能瓶頸：包含混合資料類型的大資料表需要複雜的查詢，導致讀取操作變慢。
- 部署風險：更動單一資料表通常需要同時修改多個應用程式服務。
識別這些症狀是改善的第一步。目標不僅僅是重新組織資料表，更要讓資料結構與企業的邏輯領域保持一致。
實體關係模型的角色 📐
實體關係模型是資料庫設計的藍圖。它以視覺化且邏輯化的方式定義實體（資料表）、屬性（欄位）和關係（外鍵）。在重構過程中，ERM 充當控制機制，確保新結構保持一致。
ERM 的核心元件
- 實體：代表獨立的物件或概念，例如使用者 或 訂單。在資料結構中，這些會轉化為資料表。
- 屬性：描述實體的屬性，例如電子郵件 或 價格。這些對應到欄位。
- 關係： 定義實體之間的互動方式，例如一對一或一對多。
- 基數： 指定參與關係的實例數量的最小值和最大值。
在重構過程中使用ERM，可讓團隊在將變更套用至生產環境前進行模擬。這有助於在過程中早期識別孤立資料、遺漏的約束條件以及正規化問題。
重構前評估階段 🔍
在修改任何現有表格之前，必須進行全面審查。此階段可確保轉換過程中不會遺失任何業務邏輯。
- 現有表格清單： 記錄系統中目前存在的每一張表格、欄位、索引和約束條件。
- 分析查詢模式： 識別執行頻率最高的查詢，以及被讀取次數最多的表格。
- 繪製資料依賴關係： 追蹤資料如何從資料庫流至應用程式，再返回資料庫。
- 識別重複的欄位： 尋找在多張表格中儲存相同資訊的欄位。
- 檢視外鍵： 判斷關係是在資料庫層級強制執行，還是由程式碼管理。
此評估建立了一個基準。若無此步驟，重構可能引入難以追蹤的隱性錯誤。
重構流程：逐步進行 🔄
將單一結構的資料庫模式轉換為模組化結構，需要採取系統性的方法。以下步驟概述了使用實體關係模型進行資料庫模式重構的標準工作流程。
1. 領域驅動設計（DDD）對齊
首先根據業務領域對表格進行分組。這通常稱為有界上下文。不要根據功能來組織表格（例如所有報表相關的表格），而應根據功能能力來組織（例如計費相關的表格、驗證相關的表格）。這種分離可降低系統中無關部分之間的耦合度。
2. 正規化
正規化可減少資料冗餘並提升資料完整性。此過程涉及將大型表格拆分為較小且邏輯相關的表格。
- 第一正規化形式（1NF）： 確保值為原子性。每個欄位應僅包含單一值。
- 第二正規化形式（2NF）： 移除部分依賴。所有非鍵屬性必須依賴於整個主鍵。
- 第三正規化形式（3NF）： 移除傳遞依賴。非鍵屬性不應依賴於其他非鍵屬性。
雖然 3NF 是標準目標，但某些性能需求可能需要進行受控的反規範化。此決定必須被記錄下來。
3. 定義新關係
一旦表格被拆分，關係必須重新建立。這包括為多對多關係建立新的外鍵和關聯表。例如，如果一個 產品 可以屬於多個 類別，則需要關聯表來連結它們。
4. 數據遷移策略
將數據從舊架構移動到新架構是風險最高的階段。策略包括：
- 快照遷移： 停止寫入，匯出數據，轉換後匯入新架構。需要停機時間。
- 雙寫： 在過渡期間同時寫入舊架構和新架構。
- 基於日誌的複製： 從資料庫交易日誌中捕獲變更，並應用到新結構中。
常見陷阱需避免 🛑
重構會引入複雜性。某些錯誤可能損害系統的完整性。
- 忽略資料類型： 將欄位從 整數 改為 字串 而不驗證下游邏輯，可能會導致應用程式程式碼失效。
- 過度規範化： 建立太多表格會導致過多的連接操作，降低查詢效能。
- 約束遺失： 將約束從資料庫移至應用程式層，若多個服務同時寫入相同資料，可能導致資料損壞。
- 忽略索引： 新表格需要新的索引。若未為新的外鍵建立索引，將會減慢連接操作。
驗證與測試策略 ✅
模式重新設計後，驗證至關重要。自動化測試應確保資料完整性在新的邊界之間得到維持。
- 資料一致性檢查：執行查詢，以確保所有新關係中的參考完整性得以維持。
- 效能基準測試：比較重構前後的查詢執行時間。
- 資料列數驗證：確保記錄總數保持不變（排除遷移期間產生的重複資料）。
- 應用程式回歸測試：針對新的資料庫結構執行完整的應用程式測試套件。
對比：單體式與模組化模式
下表概述了傳統單體式結構與重構後的模組化方法之間的差異。
| 功能 | 單體式模式 | 重構後的模式 |
|---|---|---|
| 表格結構 | 大型、多功能的表格 | 專用、領域特定的表格 |
| 資料冗餘 | 高 | 透過正規化最小化 |
| 可擴展性 | 難以分片 | 可依領域更輕鬆地分割 |
| 部署 | 全域模式變更 | 局部模式更新 |
| 查詢複雜度 | 大型表格上的複雜連接 | 小型表格上的優化連接 |
過渡至微服務架構 🚀
重構資料庫結構通常是採用微服務的前奏。一個清晰的實體關係模型能讓為特定資料指定特定服務的所有權變得更容易。當每個服務都管理自己的資料庫時，資料庫結構就成為服務之間的合約，而非共用資源。
這種轉變需要謹慎處理資料一致性問題。系統不再使用跨多個資料庫的交易，而是可能依賴最終一致性模式。實體關係模型有助於明確界定這些邊界，確保沒有服務會假設其不負責管理的資料的所有權。
長期健康性的最終考量 🛡️
維持健康的資料庫結構需要持續的紀律。只要新增或修改任何資料表，文件都必須同步更新。版本控制應應用於資料庫結構定義，而不僅僅是應用程式程式碼。應定期安排審查，以在新增功能時識別出新的耦合情況。
實體關係建模並非一次性任務。它是一項持續進行的實務，確保資料庫始終與業務需求保持一致。透過遵循這些結構化步驟，組織能夠降低與傳統資料結構相關的風險，並建立能支援未來成長的穩固基礎。
從單一結構的資料庫轉向模組化設計是一項重大挑戰。這需要耐心、嚴謹的測試，以及對資料關係的深入理解。然而，其結果是建立一個更易維護、擴展更快、更能抵禦變動的系統。在建模上投入的努力，將在長期內帶來營運穩定性與開發者效率的回報。