E-R 圖基礎建模實戰：從業務場景到關係模型的完整轉化過程

E-R 圖基礎建模實戰：從業務場景到關係模型的完整轉化過程

實體-關係（E-R）圖是數據庫設計的藍圖。本文以「教學管理系統」為例，演示如何從業務需求提取實體、屬性、關係，繪製 E-R 圖，並轉化為關係模式（建表 SQL），幫助初學者建立規範建模思維。

案例背景：教學管理系統

業務描述：講師負責授課，學生選課學習，課程在教室進行。需記錄講師、學生、課程、教室、選課記錄等信息。

第一步：識別實體與屬性

第二步：識別實體間關係

• 講師 1:N 課程：一位講師可授多門課，一門課由一位講師主講。
• 學生 M:N 課程：通過「選課」關係實體轉化為兩個 1:N（學生 1:N 選課，課程 1:N 選課）。
• 課程 1:N 教室（排課）：一門課程某學期佔用一間教室，一教室可安排多門課（不同時段）。
• 學生 N:1 班級：每生屬一班，一班含多生。

第三步：繪製 E-R 圖（文本描述）

[講師] 1──授課──N [課程]
[學生] N──選課──M [課程]  -->  引入關係實體 [選課]
[學生] N──所屬──1 [班級]
[課程] 1──使用──N [教室]  (含時間段屬性)

實際繪圖請使用 Visio、Draw.io、MySQL Workbench 等工具，矩形表實體，菱形表關係，橢圓表屬性，雙線表弱實體/標識關係。

第四步：轉化為關係模式（建表 SQL）

-- 講師表
CREATE TABLE teacher (
  teacher_id VARCHAR(20) PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  gender CHAR(1),
  title VARCHAR(30),
  dept_id VARCHAR(20)
);

-- 學生表
CREATE TABLE student (
  stu_id VARCHAR(20) PRIMARY KEY,
  name VARCHAR(50) NOT NULL,
  gender CHAR(1),
  birth_date DATE,
  major_id VARCHAR(20),
  class_id VARCHAR(20)
);

-- 課程表
CREATE TABLE course (
  course_id VARCHAR(20) PRIMARY KEY,
  name VARCHAR(100) NOT NULL,
  credit DECIMAL(3,1),
  pre_course_id VARCHAR(20),  -- 自關聯外鍵
  college_id VARCHAR(20),
  teacher_id VARCHAR(20),
  FOREIGN KEY (teacher_id) REFERENCES teacher(teacher_id)
);

-- 教室表
CREATE TABLE classroom (
  room_id VARCHAR(20) PRIMARY KEY,
  building VARCHAR(30),
  capacity INT,
  type ENUM('多媒體','普通')
);

-- 選課表（關係實體）
CREATE TABLE enrollment (
  stu_id VARCHAR(20),
  course_id VARCHAR(20),
  term VARCHAR(20),
  score DECIMAL(5,2),
  enroll_time DATETIME DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (stu_id, course_id, term),
  FOREIGN KEY (stu_id) REFERENCES student(stu_id),
  FOREIGN KEY (course_id) REFERENCES course(course_id)
);

-- 排課表（課程-教室-時間段）
CREATE TABLE schedule (
  course_id VARCHAR(20),
  room_id VARCHAR(20),
  term VARCHAR(20),
  week_day TINYINT,  -- 1-7
  start_time TIME,
  end_time TIME,
  PRIMARY KEY (course_id, term, week_day, start_time),
  FOREIGN KEY (course_id) REFERENCES course(course_id),
  FOREIGN KEY (room_id) REFERENCES classroom(room_id)
);

第五步：範式檢查與優化

1. 1NF：所有屬性不可再分，滿足。
2. 2NF：非主屬性完全依賴主鍵。選課表中成績依賴完整主鍵，滿足。
3. 3NF：無傳遞依賴。若「專業名」放在 student 表會依賴 major_id，應拆出 major 表。
4. BCNF：若講師職稱決定部門，teacher 表需拆分。

建模黃金法則

1. 先理解業務，再畫圖，最後建表。
2. 命名規範：表名單數、小寫、下劃線；主鍵統一 id 或 表名_id。
3. 外鍵約束在高並發系統中可由應用層維護，但設計階段必須明確關係。
4. E-R 圖隨項目迭代同步更新，作為團隊溝通共識。

熟練掌握 E-R 建模，是成為優秀數據庫設計師的入場券。