設計一個穩健的資料庫是任何軟體應用的基礎。若無結構化的規劃，資料將變得零散，難以查詢，且容易出錯。實體關係圖（ERD）即是此結構的藍圖。它能視覺化資料實體之間的互動，確保在撰寫任何程式碼之前就維持資料完整性。本指南將帶您一步步建立第一個ERD，專注於核心概念、符號表示與實際步驟。
理解實體關係圖 📊
ERD是資料庫結構的視覺化表示。它標示出實體、它們的屬性以及彼此之間的關係。可將其視為資料的地圖。如同道路地圖幫助您從A點導航至B點，ERD也能幫助您的資料庫管理系統掌握表格之間的關係。
這為什麼重要？
- 資料完整性： 它確保資料在系統中保持一致且準確。
- 溝通： 它為開發人員、資料庫管理員與利害關係人提供了一種共通語言。
- 效率： 它能幫助早期識別重複資料，節省實作階段的時間。
- 可擴展性： 良好的設計架構可讓資料庫在不需全面重構的情況下持續擴展。
ERD的核心組成元件
在繪製線條與方框之前，您必須先了解基本構成要素。每個圖表都依賴這三個基本元素。
- 實體： 一個現實世界中儲存資料的物件或概念。範例包括顧客, 訂單，或產品.
- 屬性： 實體的特定性質或特徵。對於一個顧客，屬性可能包括姓名, 電子郵件，以及電話號碼.
- 關係：兩個或多個實體之間的關聯。這定義了某個實體中的資料如何與另一個實體中的資料相連。
常見的實體關係圖符號與標記 🛠️
這些元件有不同方式可以視覺化呈現。最常見的兩種風格是陳氏標記法與烏鴉足標記法。陳氏標記法使用矩形和菱形，而烏鴉足標記法則使用矩形與具有特定末端的線條。大多數現代資料庫建模工具都使用烏鴉足標記法的變體。
| 符號 | 含義 | 使用範例 |
|---|---|---|
| 矩形 | 代表一個實體 | 標籤為學生 |
| 橢圓 | 代表一個屬性 | 與學生標籤為ID |
| 菱形 | 代表一個關係 | 連接學生與課程 |
| 帶有烏鴉足的線條 | 表示「多個」（M） | 一名學生可以選修多門課程 |
| 帶單勾的線條 | 表示「一個」(1) | 一門課程只有一位講師 |
| 圓形 | 表示可選參與 | 一位學生可能尚未被分配學號 |
逐步指南：建立你的第一個ERD 🚀
建立ERD是一個邏輯過程。你不需要知道最終的程式碼就可以開始。你需要理解業務需求。遵循以下步驟，建立穩固的基礎。
步驟 1：識別實體 📦
第一項任務是列出系統中每個獨特的物件。檢視你的業務需求文件，或與利害關係人進行訪談，以找出名詞。這些名詞通常是你的實體。
- 尋找名詞： 如果你正在建立圖書館系統，請尋找 Book、Member、Loan 和 Fine 之類的詞彙。
- 過濾掉不相關的項目： 不是每個名詞都是實體。像 處理 或 檢查 通常都是動作，而不是實體。
- 保持細緻度： 避免將多個概念合併成一個方框。一個 CustomerAddress 實體最終可能需要拆分成 顧客 和 Address 如果你需要追蹤多個地址的話。
範例清單：
- 產品
- 供應商
- 訂單
- 顧客
步驟 2：定義屬性 🏷️
一旦識別出實體，您必須確定需要儲存哪些資訊。屬性是您最終資料庫表格中的欄位。
- 主要鍵：每個實體都需要一個唯一的識別符。這通常是一個 ID 欄位（例如，
CustomerID,ProductID）。它必須為每個記錄都唯一。 - 描述性屬性： 這些用來描述實體。對於一個Product，這包括Name, Price，以及StockQuantity.
- 外來鍵： 這些將在關係步驟中稍後識別，但請注意資料將連結到其他表格的位置。
最佳實務： 避免將計算值儲存為屬性（例如，TotalPrice）。在執行階段計算這些值，以避免資料不一致。
步驟 3：確定關係 🔗
現在您將實體連結起來。這一步定義了資料如何互動。請問類似問題：一個客戶能否擁有多个訂單？一個訂單能否屬於多個客戶？
- 識別關聯： 在您的需求中尋找動詞。Places, 包含, 供應.
- 定義方向：判斷關係是單向還是雙向。
- 檢查傳遞性：確保關係是直接的。如果A與B有關聯，且B與C有關聯，請檢查A是否需要與C有直接連結。
步驟4：建立基數與參與度 📏
基數定義了一個實體的實例與另一個實體的實例之間的關聯數量。這對於定義外鍵約束至關重要。
基數的類型
- 一對一（1:1）：實體A的一個實例僅與實體B的一個實例相關聯。範例：一名員工擁有一張員工證。
- 一對多（1:N）：實體A的一個實例與實體B的多個實例相關聯。範例：一名經理監督多名員工。
- 多對多（M:N）：實體A的多個實例與實體B的多個實例相關聯。範例：多名學生選修多門課程。
參與約束
- 強制性：實體必須參與此關係。每個訂單都必須有對應的客戶。
- 可選性：實體不必參與。如果客戶僅在店內付款，則可能沒有配送地址。
關於多對多的注意事項：大多數關係型資料庫無法直接儲存多對多關係。您必須透過建立聯結表（或橋接表）來解決此問題。針對學生與課程，請建立一個名為註冊的資料表，用以連結學生編號與課程編號。
步驟5：檢視與規範化 🧹
繪製完連結後，請檢視您的圖表是否存在結構上的瑕疵。規範化是組織資料以減少冗餘並提升完整性的一個過程。
- 第一範式（1NF）：確保每一欄都包含原子值。單元格中不得包含清單或陣列。
- 第二範式（2NF）： 確保所有非鍵屬性都完全依賴於主鍵。移除部分依賴。
- 第三範式（3NF）： 確保不存在傳遞依賴。移除依賴於其他非鍵屬性的屬性。
雖然大多數應用程式不需要超過3NF，但確保設計遵循這些規則可以防止資料異常。
常見的陷阱，應避免 ⚠️
即使經驗豐富的設計師也會犯錯。了解常見錯誤可以幫助您避免日後進行重大重構。
- 遺漏主鍵： 永遠不要在沒有唯一識別符的情況下建立表格。這會讓更新和刪除記錄幾乎變得不可能。
- 錯誤的資料類型： 確保屬性與資料相符。不要將日期儲存為文字。如果需要分，就不要將價格儲存為整數。
- 過度規範化： 雖然規範化是好的，但太多表格會使查詢變慢且複雜。應在資料完整性與效能之間取得平衡。
- 忽略大小寫敏感性： 尽早決定您的系統是否區分大小寫。[email protected] 不應被視為與 [email protected].
- 硬編碼值： 避免儲存像
1或2且沒有參考表格。對於像 啟用, 停用, 待處理.
命名慣例的最佳實踐 📝
命名的一致性使您的實體關係圖（ERD）和生成的資料庫對所有參與者都具有可讀性。混淆的名稱會導致程式碼中的混亂。
- 使用單數名詞： 以單數形式命名資料表（例如，Customer 而不是 Customers).
- 使用底線： 使用底線分隔單詞以提高可讀性（例如，
customer_name而不是customername). - 避免保留字： 不要使用像 Order, User、或 Group 作為資料表名稱而不做修改，因為它們可能會與 SQL 語法衝突。
- 具描述性： 使用清晰的名稱。
cust_id還可以，但customer_id更有利於清晰表達。 - 統一前綴： 如果使用特定的資料庫結構，請保持前綴（例如：
tbl_或ref_).
視覺化資料流程 🔄
完成您的圖表後，請視覺化資料在系統中的流動方式。這有助於理解應用程式的邏輯。
- 插入： 新資料是如何進入主要實體的？（例如：新增一筆客戶資料）。
- 修改： 資料是如何更新的？（例如：變更地址）。
- 刪除： 當一筆記錄被刪除時，相關資料會發生什麼情況？（例如：級聯刪除 vs. 限制刪除）。
- 查詢： 您將如何取得資料？（例如：將訂單與客戶資料表進行連接）。
圖示繪製工具 🖥️
雖然您可以在紙上繪製，但數位工具具有版本控制和自動產生 SQL 程式碼等優勢。選擇工具時，請尋找支援標準 ERD 表示法的功能。
- 協作： 是否允許多個使用者同時編輯圖表？
- 匯出選項： 是否可以匯出為 SQL 指令碼、PNG 或 PDF 格式？
- 驗證： 該工具是否會檢查資料庫正規化規則或循環依賴？
- 整合： 它是否能與您現有的工作流程或專案管理工具整合？
常見問題 ❓
以下是初學者在開始資料庫設計時經常提出的常見問題及其解答。
1. 在製作 ERD 之前，我需要先了解 SQL 嗎？
不需要。ERD 是一種設計工具。您可以在不撰寫 SQL 的情況下建立邏輯結構。圖表能幫助您理解最終需要撰寫哪些 SQL。
2. ERD 後續可以更改嗎？
是的，但應該盡量減少。在資料庫已填入資料後再更改ERD可能會造成高昂成本與風險。最好在部署前就完成設計。
3. 邏輯ERD與物理ERD之間有什麼差異？
- 邏輯ERD：專注於實體與關係，而不需考慮特定資料庫軟體的細節。
- 物理ERD：包含特定資料庫管理系統所需的特定資料類型、索引與限制。
4. 多少張表格算是太多？
並沒有固定的數字。這取決於複雜度。然而，如果你發現為一個簡單的應用程式創建了太多表格，可能表示你過度規範化了。
5. 我應該包含非關聯資料嗎？
標準的ERD僅適用於關聯資料。如果你正在設計文件儲存或圖形資料庫，概念上會略有不同。本指南專注於關聯模型。
最後的想法 🎯
建立你的第一個ERD需要耐心與細心。這不僅僅是畫出形狀，更是在將現實世界的邏輯轉化為結構化格式。遵循上述步驟，可確保你的資料庫具備可擴展性、高效性與易於維護的特性。
從小處著手。先規劃一個簡單的系統。練習辨識實體與關係。隨著經驗累積，你會發現設計複雜系統變得自然而然。請記住，良好的資料庫設計對使用者而言是看不見的，卻對應用程式的成功至關重要。
在規範化階段請放慢腳步。這是流程中最技術性的部分，但能大幅提升資料品質。使用這裡討論的符號與規範，讓你的圖表保持清晰。擁有穩固的ERD後，你便準備好進入實作階段。