範式是關係型資料庫設計的基石，解決資料冗餘、更新異常與刪除異常。本文以通俗語言解析前三範式核心原則。
定義： 關係模式的每個屬性都是不可分割的基本資料項（原子值）。
三大準則：
| 學號 | 姓名 | 課程 (違反：多值) | 電話 (違反：多值) |
|---|---|---|---|
| S001 | 張三 | 數學,英文,物理 | 0912-345678, 02-23456789 |
修正： 拆分為學生表、選課表、電話表，每欄位僅存單一原子值。
前提： 必須滿足 1NF。
定義： 非主鍵屬性必須完全依賴於主鍵（而非部分依賴）。
核心判斷： 若主鍵為複合鍵 (K1, K2)，非主鍵屬性 A 不能僅依賴 K1 或 K2 的一部分。
| 學號 (PK) | 課程號 (PK) | 學生姓名 | 課程名稱 | 學分 | 成績 |
|---|---|---|---|---|---|
| S001 | C01 | 張三 | 數學 | 3 | 90 |
| S001 | C02 | 張三 | 英文 | 2 | 85 |
問題：
| 學生表 | 課程表 | 選課表 | |||||
|---|---|---|---|---|---|---|---|
| 學號 (PK) | 姓名 | 課程號 (PK) | 課程名稱 | 學分 | 學號 (FK) | 課程號 (FK) | 成績 |
非主鍵屬性現在完全依賴各自表的主鍵。
前提： 必須滿足 2NF。
定義： 非主鍵屬性不得對候選鍵產生傳遞函數依賴（即：非主鍵屬性不依賴於其他非主鍵屬性）。
口訣： 「非主鍵不依賴非主鍵」
| 員工號 (PK) | 姓名 | 部門號 | 部門名稱 | 部門地點 |
|---|---|---|---|---|
| E001 | 李四 | D01 | 研發部 | 台北 |
| E002 | 王五 | D01 | 研發部 | 台北 |
依賴鏈： 員工號 → 部門號 → (部門名稱, 部門地點)
| 員工表 | 部門表 | ||||
|---|---|---|---|---|---|
| 員工號 (PK) | 姓名 | 部門號 (FK) | 部門號 (PK) | 部門名稱 | 部門地點 |
嚴格遵循 3NF 會導致查詢需多表 JOIN，影響效能。實務上常見策略：
| 場景 | 策略 | 風險控管 |
|---|---|---|
| 高頻 JOIN 查詢 | 保留冗餘欄位 (如部門名稱在員工表) | 觸發器/應用層同步更新、定期一致性檢查 |
| 歷史快照/報表 | 維度建模 (星型/雪花模型) | 接受受控冗餘，ETL 保證一致性 |
| 核心交易系統 | 嚴格 3NF/BCNF | 資料完整性優先，效能靠索引/分區優化 |
3NF 的強化版：每個決定因素都必須是候選鍵。處理「主鍵屬性對主鍵屬性的部分/傳遞依賴」極端情況。實務中 3NF 通常已足夠。
