Database normalization 是關係型數據庫設計很重要的概念，通常會要求理解到 3NF (第三正規化)。
我個人是不擅長，也不想背 theory 的, 所以要問我 3NF 到底在説什麼，我還是得 Google 找答案。儘管説不出，但設計 Tables 時，會有「理所當然要這樣才對呀，不然會很奇怪啊」的感覺，所以想的話也有信心能滿足 3NF 的。
雖然真的設計時不會追求要達成幾 NF 之類的。
很多時候講求的是簡單方便，需要些 denormalization 的取捨。
另外不同於 OLTP 系統，在 Data warehouse 這類 OLAP 的系統，設計是偏向 dimensional model, 而不是 normalization.
不少系統 (最佳例子仍是 Data warehouse) 需要做 ETL 定期接收外部系統的 data (e.g. interface file), 而接收時往往會先暫存在 staging tables 裡。這些 tables 的設計往往是照抄 interface file 的 data definition 而來的，別人給我什麼，我便照單吃下，不會做無意義的 normalization。
不過嘛，還是重溫一下 3NF, 簡單地做下筆記。
1 NF: Remove multivalued attributes
2 NF: 1NF + remove partial dependencies
3 NF: 2NF + remove transitive dependencies
1NF
- 每一個 record 都是 unique, 沒有重復的 rows
- 每一個 cell 只有一個 value (atomic).
2NF
- 滿足 1 NF
- 沒有 partial dependencies. 視乎 Primary key 由多少個 column 組成：
- 1 個的話，自動符合
- 多個的話，即 composite primary key. 那所有 non-key columns 必須 dependent on entire primary keys (若不是完全依賴，便存在 partial dependencies)
例如有個 成績表：
| student_id (PK) | course_id (PK) | student_name | grading |
|---|
這裡 student_id (PK) 和 course_id (PK) 組成了 composite primary key。
但當中 non-key column student_name 只是 depends on student_id (PK), 而沒有 depends on course_id (PK) 。
因其不是 dependent on entire primary keys, 所以存在 partial dependencies, 不符合 2NF 要求。
解決方法是拆 student_name 去 student table 裡。
3NF
- 滿足 2NF
- 沒有 transitive dependencies, 即 non-key columns 不能 depend on 其他 non-key columns.
例如一個上課課表：
| lesson_id (PK) | room_id | start_time | end_time | instructor_id | instructor_name |
|---|
因為 instructor_id 和 instructor_name 這兩個 non-key columns depend on each other, 所以不符合 3NF。
解決方法是拆 instructor_name 去 instructor table 裡。
目前這個 Blog 都是盡可能用中文書寫。但因所學所用時是英文，若翻譯成中文會因水平所限，顯得相當彆扭。加上「行」「列」在不同地區有歧義。所以便放棄了，只為自己重溫方便。
