實體-關係圖基礎：初學者視覺指南

實體-關係圖（通常簡稱為 ERD）是資料庫設計的藍圖。它以視覺化方式呈現資料在系統內如何結構化、組織與相互關聯。對於任何進入資料庫管理或軟體架構領域的人而言，理解這些圖表至關重要。本指南將不依賴特定工具，剖析核心元件、符號風格與最佳實務。

什麼是實體-關係圖？ 🤔

ERD 是資訊系統的圖形化表示。它呈現實體、屬性及其之間的關係。可將其視為資料的地圖。如同城市地圖顯示道路、建築物與公園，ERD 則顯示資料表、欄位與連結。

ERD 的主要目的是促進利益相關者之間的溝通。開發人員、業務分析師與專案經理在撰寫任何程式碼之前，利用這些圖表來達成對資料需求的一致意見。這能減少開發週期後段的錯誤與重做。

使用 ERD 的主要優勢

• 視覺清晰度：複雜的資料結構在繪製出來後會變得更容易理解。

• 標準化：為技術與非技術團隊提供共同的語言。

• 效率：能早期識別如資料重複等潛在問題。

• 文件化：可作為未來維護與擴展的參考依據。

ERD 的核心元件 🔧

每個圖表都由三個基本構成要素組成。理解這些要素是建立穩固資料結構的第一步。

1. 實體 🏢

實體代表需要儲存資料的現實世界物件或概念。在資料庫情境中，實體通常對應到一張資料表。

• 強實體：它們獨立存在。例如，“客戶”資料表的存在不依賴於其他資料表。

• 弱實體：它們的存在依賴於另一個實體。若無“發票”，則“發票項目”可能毫無意義。

實體通常以矩形表示。矩形內的名稱為複數形式，表示其所對應的資料表。

2. 屬性 🏷️

屬性描述實體的性質或特徵。它們對應於資料庫資料表中的欄位。

• 主要鍵：每筆記錄的唯一識別碼。對於客戶而言，這可能是「客戶編號」。

• 外來鍵：連結到另一張資料表主要鍵的欄位。

• 簡單屬性： 一個不可分割的值，例如「電話號碼」。

• 組合屬性： 一個可以再細分為子部分的屬性，例如「地址」（街道、城市、郵遞區號）。

• 多值屬性： 一個可包含多個值的屬性，例如「電子郵件地址」。

• 衍生屬性： 由其他屬性計算得出的值，例如從「出生日期」推算出的「年齡」。

3. 關係 🔗

關係定義了實體之間如何互動。它們描述了資料點之間的連結。

• 關聯關係： 這些連結兩個或多個實體。

• 標識關係： 這些定義了弱實體的存在。

在圖表中，關係通常以菱形或連接實體的線條表示。關係的類型由基數決定。

基數與模態性 📏

基數定義了一個實體的實例與另一個實體的實例之間可以或必須建立的關係數量。模態性則定義了關係是強制性的還是可選的。

基數的類型

基數	描述	範例情境
一對一（1:1）	一個實例僅與另一個實例相關聯。	一個人擁有一本護照。
一對多（1:N）	一個實例與另一個實體的多個實例相關聯。	一個部門擁有多名員工。
多對多（M:N）	多個實例與另一個實體的多個實例相關聯。	學生選修多門課程；課程也包含多名學生。

理解模態性

模態表示關係是否為強制性的。這通常以垂直線或圓圈等符號來表示。

• 可選（0）：實體可以在沒有關係的情況下存在。

• 強制（1）：實體必須參與此關係。

例如，在「客戶下訂單」的關係中：

• 客戶必須至少下一個訂單（強制）。

• 一個訂單可以由訪客下訂單（對客戶而言為可選）。

符號風格 🎨

繪製實體關係圖（ERD）有不同的方法。雖然概念相同，但符號有所不同。

陳氏符號

以實體關係模型創始人彼得·陳命名。它使用矩形表示實體，菱形表示關係，橢圓表示屬性。

• 優點：對關係和屬性非常明確。

• 缺點：在複雜系統中容易變得混亂。

烏鴉足符號

巴赫曼符號的一種變體。它使用末端帶符號的線條來表示基數。

• 單線：表示「一個」。

• 烏鴉足（三叉）：表示「多個」。

• 圓圈：表示「可選」。

• 垂直線：表示「強制」。

UML 類別圖

統一建模語言圖表經常在軟體工程中使用。它們看起來類似於實體關係圖，但包含了更多物件導向的概念，例如繼承和方法。

功能	陳氏符號	烏鴉足符號
實體形狀	矩形	矩形
關係形狀	菱形	帶符號的線
屬性形狀	橢圓	文字清單
可讀性	概念上高	實作上高

設計資料庫結構 🛠️

建立實體關係圖不僅僅是畫出形狀。它需要邏輯思考資料如何流動與互動。遵循以下步驟，建立穩固的基礎。

步驟 1：識別實體

檢視業務需求。哪些物件需要被追蹤？將它們列出來。

• 誰是參與者？（使用者、客戶、員工）

• 哪些是項目？（產品、訂單、發票）

• 哪些是地點？（倉庫、分支機構）

步驟 2：識別屬性

針對每個實體，列出所需的詳細資訊。判斷哪些屬性是唯一識別碼。

• 針對「產品」：名稱、價格、SKU、描述。

• 針對「使用者」：使用者名稱、電子郵件、密碼雜湊值、加入日期。

步驟 3：識別關係

實體之間如何連結？提出類似問題：「產品能否在沒有分類的情況下存在？」或「訂單能否在沒有客戶的情況下存在？」

步驟 4：定義基數

為每個關係分配正確的基數。明確區分強制性與可選性約束。

步驟 5：資料正規化

正規化是組織資料以減少冗餘的過程。雖然 ERD 展示了關係，但底層的資料結構應遵循正規化規則。

• 第一正規化形式（1NF）：確保值為原子性。單元格中不得包含清單。

• 第二正規化形式（2NF）：移除部分依賴。所有屬性必須依賴於整個主鍵。

• 第三正規化形式（3NF）：移除傳遞依賴。屬性不應依賴於其他非鍵屬性。

常見陷阱須避免 ⚠️

即使經驗豐富的設計師也會犯錯。了解常見錯誤有助於提升圖表的品質。

• 過度正規化：創建過多的資料表會導致查詢變慢。需在正規化與效能需求之間取得平衡。

• 忽略資料類型：ERD 是邏輯性的，但實際實現需要明確的資料類型（整數、字串、日期）。

• 遺漏約束：未標記強制欄位可能導致後續資料完整性問題。

• 複雜關係：避免在沒有關聯表的情況下使用多對多關係。多對多關係暗示存在第三個實體。

範例：多對多關係的解決方式

如果你有「學生」和「課程」，不能直接用一條線連接。你必須引入一個「註冊」實體。

• 學生 (1) —- (N) 註冊

• 課程 (1) —- (N) 註冊

這會產生兩個一對多關係，資料庫能更高效地處理。

維護的最佳實務 📝

圖表建立後，便是一個持續更新的文件。隨著系統擴展，它也必須不斷演進。

• 版本控制：追蹤模式隨時間的變更。

• 審查會議： 定期與開發團隊一起審查圖表。

• 命名一致性： 為資料表和欄位使用清晰且一致的命名規則。

• 文件說明： 在圖表上直接添加註解，說明複雜的邏輯或業務規則。

結論 🏁

掌握實體關係圖是資料庫設計中至關重要的技能。它彌補了抽象業務需求與具體技術實現之間的差距。透過理解實體、屬性和關係，你可以建立可擴展、易維護且高效的系統。

請記住，清晰才是目標。圖表應讓專案中的任何參與者都能輕鬆閱讀。使用標準符號，遵守基數規則，並始終優先考慮資料完整性。經過練習，製作這些視覺指南將自然地融入你的工作流程中。