ER Diagram (Entity Relationships Diagram) 是數據庫設計中常用的圖形化表示方法，幫助設計師和開發人員理解和規劃數據庫結構。
作為自動化測試工程師，學會閱讀 ER Diagram 可以知道各 Table 之間的關係，能更準確的取得所需資料。也可以在 Developer 設計數據庫的過程幫忙檢驗設計上的漏洞。又或是可用來釐清大家對需求的理解，畢竟 Database 的設計都是根據需求設計出來的。
Entity (實體)，根據 Table 產生的實體 （相似於 Class & Object 的概念)
每個 實體 在數據表中通常對應一個記錄，而每個記錄包含了該實體的相關數據。
而 Entity Relationship 是在表示 Entity 之間的關係。
在兩個或多個表格之間的關聯中，Cardinality 描述了關聯的型態和數量。常見的關聯基數包括:
一對一（One-to-One）：
一個實體在一個表格中 只關聯 到另一個表格中的一個實體。
例子： 一個學生只有一份學生資料
一對多（One-to-Many）：
一個實體在一個表格中 關聯 到另一個表格中的多個實體。
例子： 客戶可以有多張訂單
多對一（Many-to-One）：
多個實體在一個表格中 關聯 到另一個表格中的一個實體。
承上的例子：多張訂單可屬於一個客戶。
多對多（Many-to-Many）：
多個實體在一個表格中關聯到另一個表格中的多個實體。
例子： 學生可以註冊多個課程，而課程也有很多學生
在 Many-To-Many 的關係，必與要有 Mapping Table 去記錄 2 個 Entity 之間的關係，因為它們的關聯可能不唯一。
在數據庫設計中，了解 Cardinality 是非常重要的，因為它有助於確定如何建立關聯和設計表格之間的關係，從而確保數據庫的正確性和一致性。
在數據庫設計和關聯式數據模型中，Optionality 指的是一個關聯中一方對另一方的參與程度，即一方是否可以存在於關聯中，或者是否可以是空的。
強制性參與（Mandatory Participation）：
這表示一個表格的記錄在關聯中必須有相應的匹配記錄，不能是空的。
例如，如果有一個 "訂單" 表格和一個 "顧客" 表格，並且每個訂單必須關聯到一個顧客，那麼 "訂單" 表格的參與是強制性的。
非強制性參與（Optional Participation）：
這表示一個表格的記錄在關聯中可以有相應的匹配記錄，也可以是空的，不需要有相對應的關聯記錄。
例如，如果有一個 "訂單" 表格和一個 "送貨地址" 表格，訂單可以有關聯的送貨地址，也可以沒有，這是 "送貨地址" 表格的參與是可選的。
是一種視覺化工具，用於描述數據庫中不同實體（Entities）之間的關係，以及這些實體之間如何相互作用和聯繫。
當中包括 2 個重要的資訊：
上圖的意思是 Entity A 有多個 Entity B，但也可以沒有。
而 Entity B 只會有一個 Entity A，而且是一定存在的。
例： 客戶可以下很多訂單，也可以一張都沒有，而訂單一定對應到一個客戶
當 Cardinality 跟 Optionality 合作一起標記，意思如下：
來嘗試解讀下圖，來驗收是否真的學會 ERD 了
每位教授 Professor 可以到在很多班 Class 授課，也可以不帶班。每個班都一定要有一位教授。
每個課程 Course 都可以分配到多個班 Class，但不一定存在於每班。每個班都一定有課程。
每個課室 Room 都可以分配到多個班 Class，也可以沒有。每個班都一定要有課室。
學生與班是 Many-To-Many 關係，中間會有 Mapping Table “Enroll” 記錄學生修讀哪個班必記錄在該班的成續。
咦？ 有沒有發現哪裡怪怪的？若果有，恭喜你發現 Student 和 Enroll 的關係畫反了！那代表你有學會 ERD 囉。
接下來，可以拿公司的 Database，抽幾個有關係的 Table 練習畫畫看它們的 ER Diagram，這個過程會讓你更了解系統的設計。在日後 Developer 要新增 / 修改 Database 的設計時，更容易透過 ER Diagram 看見全貌，知道怎樣作修改。
iThome鐵人賽
看影片追技術