資料是任何現代資訊系統的骨幹。然而，沒有結構的資料僅僅是雜訊。為了將原始資訊轉化為可執行的智慧，我們依賴結構化的資料模型。實體關係圖（ERD）為這些結構提供了建築藍圖。它彌補了抽象商業需求與具體技術實現之間的差距。本指南探討資料模型的運作機制，專注於如何準確地將運營邏輯轉譯為資料結構定義。
🏗️ 理解核心元件
實體關係圖由三個基本構成要素組成。每個要素代表資料儲存與關聯的特定面向。掌握這些元件，才能建構出符合組織需求的穩固資料庫。
- 實體： 這些代表資料收集所針對的物件或概念。在商業情境中，這些通常是名詞，例如客戶, 訂單，或產品。在資料結構中，實體會轉化為資料表。
- 屬性： 這些描述實體的特性。範例包括名稱, 價格，或日期。屬性會轉化為對應資料表中的欄位。
- 關係： 這些定義實體之間的關聯。關係表示一個實體的實例如何與另一個實體的實例相連。在資料庫中，關係通常透過索引來強制執行。
🔄 將商業規則轉譯為資料結構元件
資料模型中最關鍵的步驟是轉譯階段。商業利害關係人以流程與政策來表達，工程師則以資料表與約束來溝通。模型設計者必須扮演這兩種語言之間的翻譯者。
考慮一個商業規則：「一名員工可以管理多個專案，但每個專案必須至少有一名經理。」這要如何轉化為資料結構？
- 識別實體： 員工與專案.
- 識別關係： 管理.
- 定義基數： 一名員工對應多個專案（1:N）。一個專案至少對應一名員工（1:1 或 1:N，視解釋而定）。
- 強制選擇性： 專案 必須 有一名經理。這會成為外鍵上的 NOT NULL 約束。
此過程需要仔細分析業務使用者提供的自然語言。模糊性是資料完整性的敵人。如果一項規則指出 “顧客可以下訂單”，這是否意味著他們 可以 下零個訂單，還是必須至少下一個？此區別會改變外鍵的實作方式。
📏 基數與選擇性
基數定義了一個實體的實例與另一個實體的每個實例之間可以或必須關聯的數量。這是關係的數學基礎。
一對一（1:1）
當一個表格中的單一記錄與另一個表格中的單一記錄相關聯時，就會發生這種關係。這在為了安全或效能考量而拆分表格時很常見，但在一般商業邏輯中較不常見。
- 範例： 一個人擁有一本護照。一本護照屬於一個人。
- 實作： 其中一個表格中的外鍵，參考另一個表格的主鍵。
一對多（1:N）
這是關係資料庫中最常見的關係類型。Table A 中的一筆記錄與 Table B 中的多筆記錄相關聯。Table B 擁有外鍵。
- 範例： 一個部門有許多員工。一名員工屬於一個部門。
- 實施： 這 員工 表包含一個 部門編號 欄位。
多對多 (M:N)
表 A 中的兩個記錄可以與表 B 中的多個記錄相關聯，反之亦然。在標準關係模式中，若無中間步驟，無法直接實現此類關係。
- 範例： 學生註冊課程。一名學生選修多門課程。一門課程有許多學生。
- 實施： 建立一個聯結表（關聯實體），其中包含來自兩個父表的外鍵。
| 關係類型 | 視覺符號（概念） | 模式實施 | 常見使用案例 |
|---|---|---|---|
| 一對一 (1:1) | |—| | 任一表中的外鍵 | 個人 ↔ 护照 |
| 一對多 (1:N) | |—<<< | 「多」端表中的外鍵 | 部門 ↔ 員工 |
| 多對多 (M:N) | <<<—<<< | 包含兩個外鍵的聯結表 | 學生 ↔ 課程 |
🧩 正規化原則
一旦實體和關係被定義，模式必須進行正規化。正規化是一種系統化的方法，用於組織資料以減少冗餘並提升資料完整性。它涉及將表格分解為更小、結構更清晰的元件。
第一範式 (1NF)
每個欄位必須包含原子值。單元格內不應有重複的群組或陣列。每一列必須是唯一的。
- 違反： 一 技能 欄位包含 「SQL、Python、Java」 在一個單元格中。
- 修正： 將技能拆分到一個由關係連結的獨立表格中。
第二範式 (2NF)
表格必須符合 1NF，且所有非鍵屬性必須完全依賴於主鍵。這可消除部分依賴。
- 情境： 一個結合 訂單 和 訂單項目 其中 產品名稱 僅依賴於 項目ID，而非 訂單ID.
- 修正： 移動 產品名稱 到一個 項目 表格中。
第三範式（3NF）
該表格必須處於第二範式（2NF），且不得存在傳遞依賴。非鍵屬性不應依賴於其他非鍵屬性。
- 情境： 一 顧客 表格包含 城市 和 國家，其中 國家 由 城市.
- 修正： 建立一個 地點 表格來儲存城市與國家資料。
🛡️ 處理約束與完整性
資料結構的品質取決於保護它的規則。約束確保資料能長期保持準確與一致。
主鍵
每個表格都必須有一個唯一識別符。這確保沒有兩列完全相同，並能精確地檢索資料。在許多系統中，這是一個自動遞增的整數。在其他系統中，可能是 UUID 或自然鍵。
外鍵
外鍵維持參照完整性。它確保子表格中的記錄無法在沒有對應父表格記錄的情況下存在。這可防止出現孤立資料。
- 刪除時級聯： 如果刪除父記錄，子記錄會自動刪除。
- 刪除時限制： 若存在子記錄，則禁止刪除父記錄。
- 刪除時設為空值： 刪除父記錄，但將子記錄的外鍵設為空值。
檢查約束
這些約束會直接在資料庫內強制執行特定的商業邏輯。範例包括確保價格大於零，或一個開始日期在結束日期.
⚠️ 資料模型設計中的常見陷阱
即使經驗豐富的架構師也可能忽略關鍵細節。了解常見錯誤有助於設計出更具彈性的系統。
- 過度規範化：過度拆分表格會導致複雜的連接操作，進而降低查詢效能。有時，針對讀取密集型的工作負載，允許一定程度的非規範化是可接受的。
- 忽略軟刪除：商業規則通常需要保留歷史資料。永久刪除記錄會導致審計追蹤中斷。通常需要一個IsDeleted旗標。
- 假設唯一性：僅僅因為商業規則暗示唯一性（例如電子郵件）並不表示資料庫會強制執行。必須明確定義唯一性約束。
- 忽略時間：大多數商業資料都具有時間維度。記錄資料何時被建立或更新，對於審計與除錯至關重要。
- 硬編碼值：在 SQL 查詢中使用特定值，而非參考查閱表，會使系統變得僵化且難以維護。
🔄 迭代式設計流程
資料模型設計很少是線性的過程。它是一個迭代的過程。最初的圖表只是一種假設，必須根據實際使用模式和反饋來驗證。
- 概念設計：專注於高階實體與關係。忽略資料類型等技術細節。
- 邏輯設計： 添加屬性，定義資料類型，並建立鍵。標準化結構。
- 物理設計： 適應特定資料庫引擎進行優化。考慮索引策略、分割與儲存方式。
- 檢視： 與利害關係人共同驗證模型。確保其能支援未來的業務成長。
在檢視階段，常會發現某個關係被誤解。例如，一個多對多關係實際上可能是層級結構，或是一連串的一對多關係，一旦提出更深入的問題後便會顯現。設計階段的彈性可大幅減少實作階段的耗費。
📈 擴展與演進
資料結構會演進，需求會改變。今天適用的，明天可能不再適用。一個設計良好的ER圖能預見成長。
- 可擴展性： 避免將特定功能硬編碼至資料結構中。對於高度動態的需求，適當地使用通用表格或屬性模式（如EAV）。
- 版本控制： 記錄資料結構的變更。遷移腳本應與應用程式程式碼一同進行版本控制。
- 文件化： 圖表就是文件。若圖表與資料庫不符，應信任資料庫，但立即更新圖表。
🔍 結構完整性總結
資料庫結構的品質直接影響依賴它的應用程式的可靠性。ER圖不僅僅是一張圖，更是商業邏輯與技術基礎設施之間的合約。透過嚴謹地將商業規則映射至技術結構，確保適當的標準化，並維持嚴格的完整性約束，我們才能建立具韌性且高效能的系統。
專注於圖表的清晰度。使用標準符號，確保任何工程師都能理解設計。應優先考慮資料完整性，而非短期的效能提升，因為後期修復完整性問題的成本遠高於早期優化查詢。目標是建立一個既能支援當前業務，也能適應未來變化的結構。
