關聯式資料模型

很久很久以前，當恐龍還很大隻的時候……呃，其實是 1970 年，有個叫 Edgar Codd 的人覺得資料的混亂已經不是什麼「有創意的亂」了，根本就是個黑洞，狂吃時間跟資源。Edgar 想了很久，終於想出一個整理一切的方法，順便也為一個全新的世界打下基礎——在這個世界裡，資料都被排成整齊的 table，就像完美圖書館裡的書一樣。row、column、順序——沒有什麼「這樣也可以啦」或「反正大家都懂」這種事。

關聯式模型 的核心就是把資料用 table 來表示，每個 table 都有 row 跟 column。直覺來說很簡單：row 就是一筆紀錄，column 就是這筆紀錄的屬性或 attribute。這種做法讓資料的處理跟操作都變得超簡單。

想像一下你在網路商店下單。為了讓這個訂單能順利處理跟送達，系統要考慮很多細節：你是誰（買家）、你選哪個物流、要送去哪裡、還有怎麼追蹤包裹狀態。

如果這些資訊全都塞在一個超大 table 裡，肯定會亂成一團：資料會重複、很難更新、更難快速找到你要的東西。關聯式的做法就是把資訊拆成不同的 table，然後讓它們可以互相交換資料，這樣一切就有條理多了。

下面這張圖就是一個追蹤物流的資料組織範例：

• 買家 - 這裡存每個客戶的資訊——有個獨一無二的 買家編號。
• 物流服務 - 這個 table 裡有所有可以配送的物流公司清單，每個都有自己的 服務編號。
• 訂單配送 - 這是核心的關聯 table。每一 row 就是一筆配送紀錄。它有自己的 配送編號，還會連到買家、物流服務，也可能連到某個訂單、日期跟目前狀態。

箭頭表示 訂單配送 table 的紀錄怎麼跟 買家 跟 物流服務 table 的紀錄連在一起。

訂單配送 table 的範例：

這種做法的好處：

• 客戶或物流服務的資訊只存一次，不會每筆配送紀錄都重複一堆。
• 透過獨特的編號（也就是 key）來連結，可以保證不會有「配送給不存在的客戶」或「用不存在的物流」這種事。
• 很容易把不同 table 的資料組合起來，做複雜報表或查詢。
• 只要在一個地方改資料，所有相關操作馬上都能用到最新的（比如物流電話換了）。

關聯式資料庫的結構

關聯式資料庫的核心就是 table。每個 table 都有：

• 名稱 (Table Name) 讓我們可以認得它——比如 customers。
• 一組 column (Columns/Attributes)，定義這個物件的屬性。
  • 命名當作唯一編號（primary key）的 column 時，常用 名稱_id 這種格式。_id 這個 suffix 就是「identifier」的意思。舉例：買家編號 就會變成 customer_id。
  • 比如 customers 這個 table：可能有 customer_id、first_name、email 等等。
• row 裡的資料 (Rows/Records) - customers table 的一 row 就是某個買家的完整資訊（101, Alex Song 等等）。

來看個 customers table 的例子：

table 的 key

為了唯一標識 table 裡的每一 row，要用 主鍵 (Primary Key, PK)。這是一個（或多個）column，每 row 的值都不一樣，不能是空的。你可以把它想像成每筆紀錄的獨立編號，比如 customer_id 在 customers table 裡：可以明確辨識每個買家。

主鍵就像護照號碼一樣，每個物件都獨一無二。這樣就不會有重名 row 的問題。

要讓 table 之間有關聯，就要用 外鍵 (Foreign Key, FK)。這是在一個 table 裡的 column，指向另一個 table 的主鍵。外鍵就是 table 之間的「橋樑」。通常外鍵的 column 名稱會跟它指向的主鍵一樣。比如 deliveries table 裡的 customer_id 就是外鍵，存的是 customers table 的 customer_id，這樣就把配送跟買家連起來了。

這就是我們熟悉的架構，不過現在更貼近實際情況。

• customers table 存客戶資訊；主鍵是 customer_id。
• delivery_services table 存物流服務資料；主鍵是 service_id。
• orders table（為了完整性，因為 order_id 被配送 table 參照）是存訂單資訊的，主鍵是 order_id。
• deliveries table 是追蹤配送操作的核心。它有：
  • 自己的主鍵：delivery_id。
  • 三個外鍵來建立關聯：
    • customer_id (FK)：把配送連到 customers table 的某個買家。
    • service_id (FK)：把配送連到 delivery_services table 的某個物流。
    • order_id (FK)：把配送連到 orders table 的某個訂單。
  • created_date 欄位記錄配送紀錄的建立日期和時間。

這樣用主鍵跟外鍵就能確保 資料完整性。系統不會讓你新增一筆配送紀錄，如果 customer_id 或 order_id 在對應的 table 裡不存在，而且也能 彈性查詢所有關聯資料。

關聯式模型的優點

關聯式模型有很多超強的優點，讓它成為眾多資料庫設計的霸主：

1. 結構簡單。table 跟 column、row 一看就懂。
2. 資料操作彈性高。要加新資料或改資料都很方便，不會破壞資料完整性。
3. 支援複雜查詢。用 SQL 可以從很多 table 撈資料、組合、篩選，幾乎你想得到的都能做。比如找出所有有報名某課程的學生——超 easy！
4. key 保證資料完整性。用主鍵跟外鍵就能確保資料一致。比如不能讓學生報名不存在的課程。

關聯式資料模型就是 現代資料庫的基礎。它簡單、強大，非常適合存結構化資料。正如 Edgar Codd 說的：「要嘛整理好，不然就等死！」（雖然他原話不是這樣，不過意思差不多啦……）。下一堂課我們會聊聊關聯式模型跟其他資料庫（像 NoSQL）有什麼不同，還有什麼時候該用哪一種。