關聯式資料庫設計 3：資料庫關聯完整性限制

上一篇關聯式資料庫設計 2 資料庫設計步驟、概念資料模型以及實體關係圖，說明了資料庫的設計步驟，以及什麼是概念資料模型還有實體關聯圖(ERD)，在開始本篇之前，先做簡單的複習。

資料庫設計步驟：

1. 確認需求：確認商業或使用者的資料需求，了解資料如何被使用
2. 概念資料模型：描繪資料庫的「整體」，但不標示細節，建立實體關聯圖 (Entitiy Relation Diagram)
3. 邏輯設計：將實體關係圖轉為帶有主鍵(Primary Key) 和外鍵，來定義資料表以及資料表之間的關係
4. 實體設計：為屬性定義資料型態以及定義效能所需的索引
5. 實作實體設計：選擇 RDBMS（關聯式資料庫管理系統）並使用 SQL 建立資料庫綱要（Schema）
6. 測試與實作
7. 維護與文件化

概念資料模型元素：

• 實體： 儲存所需資料的資料庫物件（即資料表）
• 屬性： 實體的特性或屬性（即資料表內的欄位）
• 關聯： 顯示實體之間是如何互相連結的
• 基數： 描述實體間連結關係的型態（例如一對一、一對多、多對多等）

但上述沒有說明一個「好的」資料庫設計應該具備什麼？本篇會介紹「關聯完整性限制」(Relational Integrity Constraints)，它的目的在於確保資料正確性、一致性以及邏輯嚴謹性。

---

關聯完整性限制（Relational Integrity Constraints）

定義域限制 (Domain Constraint)

規定欄位（屬性）只能填入符合該型態與規範的值。實務上例如當我們規範一筆資料的型態為 VARCHAR，那就必須確保資欄位不能存成文字以外的型態。

• ✅ age 設定成整數，並加上 CHECK (age >= 0)

• ❌ age 欄位型態為 INTEGER，但是欄位沒鎖好，導致允許 -5 或者 15歲

---

關聯鍵限制 (Key Constraint)

規範資料表中的鍵值（Super Key、Candidate Key、Primary Key、Alternate Key、Foreign Key）。確保資料具備唯一識別，並規範表格間的正確對應。

• ✅ customer_id 設定為 PK，資料庫會限制資料不得擁有一樣的 ID

• ❌ 沒有設定主鍵，導致共用了 customer_id

---

實體完整限制 (Entity Integrity Constraint)

主鍵（Primary Key）絕對不能為空值（NULL）。如果主鍵允許空值，資料庫就失去了一個能夠絕對識別某筆記錄的依據

• ✅ 將 order_id 設為主鍵，若有人試圖寫入 order_id 為 NULL 的資料，資料庫會報錯

• ❌ 新增一筆訂單，可能因為漏傳而讓 order_id 變成 NULL，以致無法查詢或修改

---

參考完整限制 (Referential Integrity Constraint)

為了防止產生「孤兒資料」（Orphaned Records），外來鍵（Foreign Key）若有填寫內容，就必須確實對應到另一個表格中存在的主鍵。

• ✅ 幫訂單表格內的 customer_id 建立外鍵(FK)，如果嘗試寫入不存在的 customer_id = 9999 會報錯

• ❌ 訂單內有一筆資料的 customer_id = 9999，這名客戶已經被刪除但訂單沒有刪，這可能會導致程式出錯

---

語意完整限制 (Semantic Integrity Constraint)

有時會因為專案特性，必須根據特定業務邏輯（Business Logic）所自定義的額外規則。可透過 CHECK 或程式邏輯來實踐。

• ✅ 在資料庫加入檢查條件： CHECK (discount_rate >= 0 AND discount_rate <= 1)（折扣只能在 0 到 1 之間），或 CHECK (shipping_date >= order_date)。

• ❌ 促銷活動的折扣 (discount_rate) 欄位被填了 1.5（代表打 150折），造成公司虧損，或者訂單的「出貨日期」早於「下單日期」。