為什麼要更了解 MySQL

在進入 OLAP 的設計探討之前，我想先再多聊聊 MySQL 關聯式資料庫的核心概念，你必須先掌握 OLTP 遇到了什麼問題，才能客觀評估是不是真的需要導入 OLAP 、要導入到什麼程度？

另外在打造線上資料服務時，也經常會把後端需要即時存取的資料回存到 MySQL，對於資料表的設計可能就要涉略一些了。

接下來，我們分成資料表設計、查詢與效能優化兩個主題來聊聊。

以下我們用一個簡化的用戶情境來輔助說明：

我們要打造一個學習管理系統，在國小的學校中，老師會有導師、科任老師，導師會帶一個班級，一
班大約有30-35個學生，科任老師的話就會同時教好幾個班。
每天看老師上課進度而有回家作業，老師希望能把這些學生學習的紀錄都留存下來，讓他好
追蹤學生的學習狀況，老師通常每天會去批改作業，看看學生是不是都完成了，還有答對多
少，每個月也會檢視一下學生在每一個科目的學習表現。

資料表需求訪談與設計

ERD (Entity Relationship Model) 及如何轉換成資料表

實體關係模式，用來將真實世界的需求進行功能性分析以後，透過圖像化的方式，把需求轉換成資料種類和其關係，便於我們和需求方溝通，也方便後續轉換成資料表的設計，其中元件可以分成實體(Entity) 和關係(Relationship)。

實體

一個 實體 代表一個事物，實體會包含 屬性 ，像是老師的姓名、生日等等，或是學習記錄有對應的科目、學習的時間，需要額外注意的是屬性可能會有多值（但這裡求簡單介紹，就不深入）。

關係

關係可以分成一對一、一對多以及多對多，這裡的關係類型，就會決定後續如何轉換成資料表。

圖像表示法

1. 實體：用長方形框框代表
2. 屬性：用橢圓形代表
3. Key 值：用來識別資料的唯一值，會加上底線
4. 關係：用菱形代表，並在兩邊線加上 1:1, 1:N, N:M 來代表關係

ERD 關係轉換成資料表設計的案例實作

ERD 的實體與屬性的表示在上圖可以看到，接著我們花一點點篇幅來介紹不同數量關係，是怎麼被轉換成資料表設計的：

老師可能是導師、科任老師，可能教一個班級，也可能可以教多個班級，我們剛好拿這個情境來分別舉例 一對一、一對多以及多對多

1. 一對一：假設我們的系統中，老師只有導師，只能教一個班級，一個班級也只有一個導師。一對一的實體關係建立很簡單，『任選一個你覺得適合，把 key 放到另一張表上作為 Foreign Key 外部鍵』，就完成對應。
   ** 註記: 為了跟一對多做出區別介紹，這邊選擇將 class_id 放到 teacher上。**

2. 一對多：老師是導師，但考慮老師每年都會帶班，所以從系統角度，一個導師會帶多個班，但每個班級只有一個導師。
   一對多的實體關係，『將一個數量實體 key 放到多個數量實體上作為 Foreign Key 外部鍵』，就完成對應。（結果看起來可能會跟一對一的一樣）

3. 多對多：我們希望簡化系統設計，把導師、科任老師都先歸類在老師，一個老師可以教多個班級，每個班級也會有多個老師

資料表設計的正規化

接著我們來聊聊正規化(Normalization)，正規化的目的是為了讓關聯式資料庫的效率更好，也避免幾個問題發生：

1. 實體意義不明
2. 資料重複儲存
3. 很多空值

正規化分成五個等級，1NF, 2NF 一直到5NF，基本上只要滿足1~3NF 即可。

1NF: 每個屬性都是簡單而且單值

簡單來說，就是一個欄位就是一個值，不該存多個值。

2NF:完全函數相依，不該儲存不屬於該實體的資料

這比較偏概念，你怎麼定義兩個實體概念一樣或是不一樣，例如：老師和班級就是不一樣，不該把班級的資訊，放在老師的資料表中。
看似簡單，但是實務上蠻常見的問題，可能是

1. 分不清楚兩個實體要不要分開存，沒考慮好未來的使用情境，
2. 有時候求快不想多一次JOIN拿資料，就直接把新增的欄位加在既有資料表上，就是長期累積的技術債。

3NF:不該存在遞移相依，也就是 X->Y, Y->Z 的關係存在

遞移關係的存在，必須透過資料表去建立出來，如果同時存在同一張表上，就會產生非常多的重複資料。

小結

今天我們聊完了MySQL 關聯式資料庫從需求訪談，到轉換成資料表，最後到如何檢查自己的資料關係設計是沒問題的，這個過程會一直來來回回去做調整，但也確保你接下來的系統邏輯層會在一個可靠的資料層上去工作，下一篇我們來聊聊 MySQL 的SQL效能優化。
這篇算是非常簡潔的帶過了設計的概念，如果真的想實務操作，建議深入閱讀中山大學資管系黃三益教授的著作《資料庫的核心理論與實務》，也有較舊版的線上內容可以先行參考，非常推薦！
https://www.mis.nsysu.edu.tw/db-book/home.htm