實體關係圖（ERD）是資料庫架構的藍圖。然而，即使經驗豐富的設計師在將商業邏輯轉換為資料模型時，仍會遇到困難。這種模糊性通常源於術語重疊以及結構元素之間的細微差異。本指南解決了關於鍵、共現性與關係最常見的疑問。
理解這些概念可防止資料重複並確保查詢效能。我們將逐一解析15個常見的困惑點，將其分解為清晰且可執行的定義。每個部分都包含實用範例與視覺描述，以釐清背後的運作機制。
1. 實體與屬性之間的差別是什麼？ 🏷️
一個實體代表一個資料庫中儲存資料的現實世界物件或概念。通常以矩形表示。範例包括客戶, 產品，或訂單.
一個屬性描述實體的一種特性。通常以與實體相連的橢圓表示。例如，客戶姓名或產品價格都是上述實體的屬性。
- 實體： 名詞（誰／什麼）。
- 屬性： 形容詞（描述它的內容）。
當屬性包含多個資訊項目時，常會產生混淆。如果地址是屬性，則可能更適合拆分成街道, 城市，以及郵遞區號以實現更好的資料正規化。
2. 主鍵與唯一鍵有何不同？ 🔑
兩者都能確保資料完整性，但其使用方式有所不同。
- 主鍵： 唯一識別資料表中的每一列。一張資料表只能有一個主鍵。它不能包含空值。
- 唯一鍵： 確保欄位中的所有值都是唯一的。一張資料表可以有多個唯一鍵。空值通常被允許（取決於實作方式）。
將主鍵想像成記錄的社會安全號碼。唯一鍵則像護照號碼——同樣是唯一的，但一個人可能有多個唯一的識別碼可用。
3. 什麼是外鍵？它如何連結資料表？ 🔗
一個外鍵 是一張資料表中的欄位（或欄位集合），指向另一張資料表的主鍵。它在兩張資料表之間建立連結。
考慮一個訂單資料表。它需要知道是哪一位客戶下訂單。客戶編號在訂單資料表中就是外鍵。
| 資料表 | 欄位 | 角色 |
|---|---|---|
| 客戶 | 客戶編號 | 主鍵 |
| 訂單 | 客戶ID | 外鍵 |
此關係允許資料庫強制執行參考完整性，確保不存在沒有有效客戶的訂單。
4. 什麼時候是「一對一」關係？ 🤝
當Table A中的單一記錄與Table B中的單一記錄相對應，反之亦然時，就會出現一對一（1:1）關係。
- 範例： 一 人 和一個 護照.
- 實作方式：通常透過將其中一個表格的主鍵設為另一個表格的外鍵來實作。
當為了優化效能或安全性而拆分實體時，這種做法很常見。例如，將像 社會安全號碼 之類的敏感資料移至一個獨立的、以 1:1 連結的表格中。
5. 一對多關係是如何運作的？ 📦
這是最常見的關係類型。Table A 中的單一記錄會與 Table B 中的多個記錄相關聯，但 Table B 中的記錄僅與 Table A 中的一個記錄相關聯。
- 範例： 部門 到 員工.
- 方向：一個部門擁有許多員工。
在實體關係圖中，這是以一條連接兩個實體的線來表示。標示「多」的一側會接收外鍵。
6. 為什麼多對多關係會造成問題？ ⚖️
當Table A中的多個記錄與Table B中的多個記錄相關聯時，就會出現多對多（M:N）關係。在關係型資料庫中，若無橋接表，無法直接實作此類關係。
- 問題：你無法僅簡單地在一個表格中加入外鍵，因為單一資料列需要儲存多個ID。
- 解決方案： 建立一個關聯表（關聯實體）。
對於學生 和 課程，建立一個註冊表格，包含學生編號 和 課程編號。這會將 M:N 轉換為兩個 1:多 的關係。
7. 什麼是基數與模態的差別？ ⚖️
這些術語描述關係的約束，由於符號相似，常被混淆。
- 基數： 最大實例數量。（例如：一對多）。
- 模態： 最小實例數量。（例如：強制或可選）。
範例：一名員工必須擁有一個部門（模態：強制/1）。一個部門可以沒有任何員工（模態：可選/0）。
8. 識別性關係與非識別性關係 🧩
兩者的差別在於子實體的依賴性。
- 識別： 子實體無法在沒有父實體的情況下存在。外鍵是子實體主鍵的一部分。通常以實線表示。
- 非識別： 子實體可以獨立存在。外鍵不是主鍵的一部分。通常以虛線表示。
考慮一個發票（父實體）和發票明細項目（子實體）。明細項目是識別的，因為沒有發票，項目就毫無意義。
9. 什麼是遞歸關係？ 🔄
當實體與自身相關時，就會發生遞歸關係。這在階層資料中很常見。
- 範例：一個員工資料表，其中一名員工是其他人的經理。
- 實作： 同一資料表中的外鍵，指向同一資料表的主鍵。
此結構支援組織架構圖或具有子類別的產品分類。
10. 弱實體與強實體有何不同？ 🌱
一個強實體擁有獨立於其他實體的主鍵。一個弱實體若無父實體的主鍵，則無法被唯一識別。
- 視覺呈現： 弱實體通常以雙重矩形繪製。
- 依賴關係： 它們依賴於識別關係。
範例：一個 受撫養者（配偶/子女）在公司系統中。受撫養者記錄通常沒有自己的唯一識別碼；它依賴於 員工編號來識別。
11. 何時應使用複合鍵？ 🧩
一個 複合鍵由兩個或更多欄位組成，共同唯一識別一列資料。當單一欄位無法提供唯一性時使用。
- 情境： 一個 學生課程 表。
- 鍵： 學生編號 + 課程編號.
在此情境下，任一ID本身均不具唯一性，但兩者組合則具有唯一性。需留意，複合鍵可能使其他表格中的外鍵關係變得複雜。
12. 虛擬鍵與自然鍵：該選擇哪一種？ 🔢
這是一個策略性的設計決策。
- 自然鍵： 實際世界中的屬性（例如：電子郵件、社會安全號碼）。優點：具有意義。缺點：可能變更，長度可能較長，或包含敏感資訊。
- 虛擬鍵： 系統產生的識別碼（例如：自動遞增的整數）。優點：穩定、短小、快速。缺點：無業務意義。
最佳實務通常傾向於在內部表格結構中使用虛擬鍵，而自然鍵在搜尋與報表中仍具實用性。
13. 正規化如何影響實體關係圖？ 📉
正規化是組織資料以減少冗餘的過程。隨著正規化進行，實體關係圖也會演變。
- 第一正規化（1NF）： 消除重複的資料群組。
- 第二範式： 移除部分依賴。
- 第三範式： 移除傳遞依賴。
更高的規範化通常會增加表和關係的數量。雖然這能提升資料完整性，但可能會使查詢變得複雜。應在規範化程度與查詢效能需求之間取得平衡。
14. 鴿足符號與陳氏符號：哪一種是標準？👣
符號指的是關係如何以視覺方式呈現。
- 鴿足符號： 在線條末端使用線條、十字和圓圈等符號。在現代工具中非常常見。
- 陳氏： 使用菱形表示關係，矩形表示實體。更偏向學術用途。
鴿足符號通常更適合用於實現，因為它能更直接地對應到 SQL 約束。然而，陳氏符號在高階概念建模方面表現出色。
15. 資料實體圖（ERD）與資料流程圖（DFD）📊
它們在系統設計週期中扮演不同的角色。
- ERD： 關注於 資料結構 和儲存。關係的靜態視圖。
- DFD： 關注於 資料流動 和處理程序。資料如何在系統中流動的動態視圖。
不要混淆兩者。ERD 告訴你有哪些資料存在，DFD 則告訴你這些資料是如何被處理的。兩者對於完整的系統規格都是必需的。
關鍵概念摘要 📝
| 概念 | 核心要點 |
|---|---|
| 主鍵 | 用於識別資料列的唯一識別碼。不允許為空值。 |
| 外鍵 | 連結到另一張表的主鍵。 |
| 基數 | 最大關係數（1，1..N）。 |
| 交集表 | 解決多對多關係。 |
掌握這些區別可實現穩健的資料庫設計。目標是清晰性、完整性與可擴展性。請根據這些要點檢視您的圖表，以確保您的模型準確反映業務現實。
透過解決這15個常見的混淆，您將建立一個易於維護與擴展的系統基礎。專注於資料語義，技術實現將自然跟隨。
