在進入 OLAP 的設計探討之前,我想先再多聊聊 MySQL 關聯式資料庫的核心概念,你必須先掌握 OLTP 遇到了什麼問題,才能客觀評估是不是真的需要導入 OLAP 、要導入到什麼程度?
另外在打造線上資料服務時,也經常會把後端需要即時存取的資料回存到 MySQL,對於資料表的設計可能就要涉略一些了。
接下來,我們分成資料表設計、查詢與效能優化兩個主題來聊聊。
以下我們用一個簡化的用戶情境來輔助說明:
我們要打造一個學習管理系統,在國小的學校中,老師會有導師、科任老師,導師會帶一個班級,一
班大約有30-35個學生,科任老師的話就會同時教好幾個班。
每天看老師上課進度而有回家作業,老師希望能把這些學生學習的紀錄都留存下來,讓他好
追蹤學生的學習狀況,老師通常每天會去批改作業,看看學生是不是都完成了,還有答對多
少,每個月也會檢視一下學生在每一個科目的學習表現。
實體關係模式,用來將真實世界的需求進行功能性分析以後,透過圖像化的方式,把需求轉換成資料種類和其關係,便於我們和需求方溝通,也方便後續轉換成資料表的設計,其中元件可以分成實體(Entity) 和關係(Relationship)。
一個 實體 代表一個事物,實體會包含 屬性 ,像是老師的姓名、生日等等,或是學習記錄有對應的科目、學習的時間,需要額外注意的是屬性可能會有多值(但這裡求簡單介紹,就不深入)。
關係可以分成一對一、一對多以及多對多,這裡的關係類型,就會決定後續如何轉換成資料表。
ERD 的實體與屬性的表示在上圖可以看到,接著我們花一點點篇幅來介紹不同數量關係,是怎麼被轉換成資料表設計的:
老師可能是導師、科任老師,可能教一個班級,也可能可以教多個班級,我們剛好拿這個情境來分別舉例 一對一、一對多以及多對多
接著我們來聊聊正規化(Normalization),正規化的目的是為了讓關聯式資料庫的效率更好,也避免幾個問題發生:
正規化分成五個等級,1NF, 2NF 一直到5NF,基本上只要滿足1~3NF 即可。
簡單來說,就是一個欄位就是一個值,不該存多個值。
這比較偏概念,你怎麼定義兩個實體概念一樣或是不一樣,例如:老師和班級就是不一樣,不該把班級的資訊,放在老師的資料表中。
看似簡單,但是實務上蠻常見的問題,可能是
遞移關係的存在,必須透過資料表去建立出來,如果同時存在同一張表上,就會產生非常多的重複資料。
今天我們聊完了MySQL 關聯式資料庫從需求訪談,到轉換成資料表,最後到如何檢查自己的資料關係設計是沒問題的,這個過程會一直來來回回去做調整,但也確保你接下來的系統邏輯層會在一個可靠的資料層上去工作,下一篇我們來聊聊 MySQL 的SQL效能優化。
這篇算是非常簡潔的帶過了設計的概念,如果真的想實務操作,建議深入閱讀中山大學資管系黃三益教授的著作《資料庫的核心理論與實務》,也有較舊版的線上內容可以先行參考,非常推薦!
https://www.mis.nsysu.edu.tw/db-book/home.htm