關聯式資料庫設計 2：資料庫設計步驟、概念資料模型以及實體關係圖

學習關聯式資料庫的設計步驟、概念資料模型以及實體關係圖

August 28, 2026
database
RDBMS
relational database

上一篇關聯式資料庫設計 1 複習了關聯式資料庫的設計原則跟目標，本篇主要複習設計步驟、概念資料模型以及實體關係圖。

如同上一篇，這篇也整理了台灣繁體中文翻譯跟英文對照

英文台灣繁體中文
Conceptual Data Modeling概念資料模型 (概念資料建模)
ERD (Entitiy Relation Diagram)實體關聯圖
Entity實體
Data Schema資料綱目
Attribute屬性
Cardinality基數
Junction Table中間表
Forieng key外鍵
Primary key主鍵
Junction Table關聯表
Associative Entity中介表
Composite Primary Key複合主鍵
UNIQUE Constraint唯一限制條件

資料庫設計步驟

不論是前端、後端或雲端，在規劃商業服務或者業務邏輯，最基本的前提就是需要知道商業以及使用者需求，資料庫設計也是基於這樣的前提。

步驟一：商業或使用者使用情境需求

  • 確認商業或使用者的資料需求
  • 了解資料將會被如何使用
  • 定義商業限制，例如：資安、條款和效能需求

步驟二：概念資料模型

  • 描繪資料庫的「整體」，但不標示細節
  • 建立實體關聯圖 (Entitiy Relation Diagram)
  • 定義實體以及定義各實體間的關係與屬性

步驟三：邏輯設計

  • 將實體關係圖轉為帶有主鍵(Primary Key) 的定義資料表
  • 定義外鍵來表示資料表與資料之間的關係
  • 透過套用正規形式（Normal Forms）來將資料庫正規化

步驟 4：實體設計

  • 為每個屬性（Attribute）定義適當的資料型態（Data Type）
  • 定義效能所需的任何索引（Indexes）

步驟 5：實作實體設計

  • 選擇 RDBMS（關聯式資料庫管理系統）並使用 SQL 建立資料庫綱要（Schema）
  • 設定所需的鍵值（Keys）與約束條件／限制條件（Constraints）
  • 透過寫入範例資料進行測試

在台灣多數人會直接說 Schema，不會特地將這個字改成中文，但依照國家教育研究院字典， schema 在電子計算機領域中翻譯為「綱目」，因此本篇也依循這個翻譯。

步驟 6：測試與實作

  • 使用真實的資料測試特定的使用者情境
  • 識別效能瓶頸
  • 必要時持續微調約束條件、索引及資料庫綱要

步驟 7：維護與文件化

  • 撰寫資料庫綱要的文件
  • 規劃後續的變更與擴充
  • 適時進行檢視與評估，以適應不斷變化的業務需求

概念資料模型

「概念資料模型」(Conceptual Data Modeling) 可以想成是以上帝視角來看整個商業需求中的資訊，就像藍圖一樣協助利害關係人可以一致地使用這些定義好的資料。 這個階段所定義的資料代表著業務流程以及該資料如何支援業務規則和需求。

概念資料模型元素

一個基本的概念資料模型具備：

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

實體關聯圖 (ERD)

ERD（實體關聯圖）是用來建立資料庫的結構模型，有以下要點：

  • 比概念模型更為詳細
  • 就像概念模型一樣，規劃出實體、關聯以及基數
  • 同時包含每個實體的屬性（即資料表內的欄位）
  • 包含額外的資料表資訊，例如主鍵、外鍵以及索引

基數

「基數」是指用來定義兩個資料表之間的資料列對應上限

關聯類型縮寫說明範例
一對一 (One-to-One)1:1A 表的一筆資料只能對應 B 表的一筆資料使用者與身分證字號
一對多 (One-to-Many)1:N / 1:MA 表的一筆資料可對應 B 表的多筆資料；但 B 表的一筆只能對應 A 表的一筆。客戶與訂單（一個客戶可以有多筆訂單）
多對多 (Many-to-Many)N:MA 表的一筆資料可對應 B 表的多筆，反之亦然。通常需要「中間表」來拆解。學生 與 課程（一個學生選多門課，一門課有多個學生）

基數 / 參與性

有四種型態（由上到下）：

  1. 0 或 1
  2. 0 或更多
  3. 1 或更多
  4. 1

基於這四種，可以延伸出三種主要類別：

  • 一對一 (One to One)
  • 一對多 (One to Many)
  • 多對多 (Many to Many)

一對一 (One to One) / 1:1

一對一相較於一對多或者多對多來說，在一般業務系統比較少，有以下幾個特點：

  • 一個實體中的每筆資料只能對應另外一個實體的一筆資料
  • 關聯可以是 1...1 或者 0...1 / 1...0 (如圖示)
  • 實作時會將外鍵放在依賴的一邊 (Dependent Table)，並指向主要實體的主鍵
  • 為了真正地限制成一對一，外鍵通常要加上 UNIQUE Constraint 或讓外鍵同時作為主鍵 (PK + FK)
  • 設計一對一時先問：兩個實體是否需要拆成兩張表？
  • 常見的拆分理由：
    • 資料為可選
    • 生命週期不同
    • 權限/安全性隔離
    • 責任領域不同
    • 資料存取不同

一對多 (One to Many) / 1:M

  • 一個實體中的一筆資料，可以對應另一個實體中的多筆資料；但多方的每筆資料通常只對應一方中的一筆資料
  • 關聯可以是可選0..N或必須1..N，取決於商業規則。
  • 實作時，通常會將外鍵放在 M 的一方，並指向 1 的一方的主鍵
  • 外鍵是否允許 NULL，取決於這個關係是否為可選地；若每筆子資料都必須屬於父資料，通常設定為 NOT NULL。
  • 一對多是關聯式資料庫中最常見的關聯之一
  • 設計一對多時，要特別確認最小基數：是 0..N 還是 1..N

多對多 (Many to Many) / M:N

  • 一個實體中的一筆資料，可以對應另一個實體中的多筆資料；反過來，另一個實體中的一筆資料也可以對應多筆資料。
  • 雙方都可能是 0..N 或 1..N，實際最小基數取決於商業規則。
  • 在關聯式資料庫中，通常不直接實作 M:N 關係，而是建立一個關聯表／中介表來連結。
  • 關聯表通常包含兩邊實體的外鍵，將原本的 M:N 拆成兩個 1:N。
  • 關聯本身如果具有資料，例如數量、價格、角色、加入時間、狀態等，這些屬性通常放在關聯表中。
  • 關聯表可以使用兩個主鍵組成複合主鍵，也可以另外建立獨立的主鍵；如何選擇要看實際需求。
  • 設計時應確認同一組關聯是否允許重複；若不允許，即使使用獨立主鍵，通常仍應對兩個外鍵的組合建立 UNIQUE Constraint

實作

練習情境：簡易線上書店系統 (Gemini 提供)

我們需要為一個小型線上書店建立資料庫，系統範圍包含：

  • 顧客： 記錄基本聯絡資料。
  • 書籍： 記錄書名、價格與庫存。
  • 訂單： 顧客可以下訂單，一筆訂單可以包含多本書籍，並且需要記錄訂購數量。

請根據上面的情境，畫出概念模型

  1. 列出你想到的實體
  2. 找出實體之間的關聯與基數
解答

1. 列出實體

這個情境的實體主要有

  • 顧客 (Customer)
  • 書籍 (Book)
  • 訂單 (Order)
  • 訂單品項 (Order Item)：作為書籍和訂單的關聯表

實體通常以單數命名

2. 找出實體之間的關聯與基數

顧客和書籍

顧客和書籍的關係是很單純的一對多，一個顧客可以擁有 0 本或者多本書；0 本的情境則是在剛建立使用者資料後成立。

等等，這裡可能有個問題

這個情境需要顧客跟書籍以及顧客跟訂單的表嗎？ 一開始我的直覺的確是顧客跟書籍以及顧客跟訂單是兩種不同的資料，但我是以一個使用者角度去看他們之間的關係，但是就業務邏輯來說，一個顧客擁有幾本書是透過「購買(成立訂單)」來看，而關聯表「訂單品項」就可以呈現顧客買了多少書，這樣一來就不需要額外多一張顧客跟書籍的表了。

顧客和訂單

上述提到可以透過顧客跟訂單的關係來取得顧客與書籍的關聯，而一個顧客可以有很多張訂單，但是一張訂單有沒有可能有很多顧客呢？實務上來說應該是不可能的，所以這邊我們確立了顧客與訂單的關係 —— 「一對多」。

在畫概念資料模型時，可以加上「動詞」來表達資料之間的商業關係。

書籍和訂單

這裡需要梳理一下可能的關係，以下兩種都是可以成立的：

  • 一本書建立多筆訂單
  • 多本書建立多筆訂單

上述提到多對多的情況下，不直接實作 M:N 表，而是用另外一個關聯表來連結兩者關係，以這個情境來說，就是「訂單品項」，如果用「訂單品項」作為關聯表來關聯書籍跟訂單的話，關係如下：

  • 一張訂單建立多個訂單品項
  • 一本書建立 0 個或多個訂單品項 (書本剛上架，沒有成立訂單過，所以沒有訂單品項)

ERD 必須要有完整的主鍵、外鍵跟屬性，但本篇篇幅已經有點冗長了，就留到下一篇吧！

回到部落格 🏃🏽‍♀️