歡迎來到資料庫設計！打好紮實基礎
各位未來的電腦科學家好！這一章非常重要。設計資料庫就像規劃摩天大樓的結構一樣——如果地基不穩，整棟建築最終都會倒塌！
在這裡，我們將學習如何利用資料表（Tables）、欄位（Fields）和特殊的「鍵」（Keys）來高效地組織數據，確保資料準確且易於管理。別擔心，「鍵」和「關係」這些術語聽起來很複雜，我們會透過簡單、日常生活的例子來拆解它們。
為什麼良好的設計很重要？
一個設計良好的資料庫可以節省空間、確保準確性，並讓你快速找到所需的資訊。我們設計的主要目標就是消除資料冗餘（Data Redundancy）。
重點筆記： 良好的設計 = 高效率 + 高準確度。
1. 構建基石：資料表與欄位
關聯式資料庫（Relational Databases）將資訊儲存在資料表（Tables）中（有時也稱為實體 Entities）。你可以把資料表想像成某個特定的類別，例如「學生」、「書籍」或「訂單」。
欄位（屬性 Fields / Attributes）
資料表中的每一列標題都稱為欄位（Field）（或屬性 Attribute）。欄位定義了我們想要儲存關於該實體的具體資訊。
- 範例資料表： 學生（Students）
- 範例欄位： 學生ID (StudentID)、名字 (FirstName)、姓氏 (LastName)、出生日期 (DateOfBirth)、住址 (HomeAddress)
記錄（元組 Records / Tuples）
資料表中的每一列都是關於某個特定項目或人員的一組完整數據。這稱為記錄（Record）或元組（Tuple）。
快速回顧：組成元件
- 資料表 (Entity)： 整個類別（例如：*客戶 Customer*）。
- 欄位 (Attribute)： 直行；特定的資料片段（例如：*姓名 Name*）。
- 記錄 (Tuple)： 橫列；關於某個項目的所有資料（例如：*客戶編號 #45 的具體詳細資料*）。
2. 必要的安全系統：鍵（Keys）
為了連結不同的資料表並確保每筆記錄都是唯一的，我們會使用特殊的欄位，稱為鍵（Keys）。這可以說是資料庫設計中最核心的概念！
A. 主鍵（Primary Key, PK）
主鍵（Primary Key, PK）是一個欄位（有時是多個欄位的組合），用來唯一識別資料表中的每一筆記錄。任何兩筆記錄都不能有相同的主鍵值，且主鍵不能為空（必須是 NOT NULL）。
- 類比： 主鍵就像你的護照號碼或學生證號碼。沒有人會跟你有一樣的號碼，而你需要它來證明你的身份。
- 範例： 在「產品」資料表中，主鍵可能是 ProductID。在「學生」資料表中，則會是 StudentID。
你知道嗎？ 如果一個主鍵由兩個或多個欄位組成，我們稱之為複合鍵（Composite Key）。
B. 外鍵（Foreign Key, FK）
外鍵（Foreign Key, FK）是資料表中的一個欄位，它引用（或「借用」）另一個資料表的主鍵。外鍵是連結不同資料表、建立關係的核心橋樑。
別擔心，如果這聽起來很棘手，試著這樣想：
- 我們有一個班級（Classes）資料表（主鍵是 ClassID）。
- 我們有一個學生（Students）資料表（主鍵是 StudentID）。
- 為了標示學生屬於哪個班級，我們必須將 ClassID 放入學生資料表中。
- 在學生資料表中，ClassID 現在就是外鍵（FK）。
記憶小撇步：
Primary Key = Personal（個人的），保持唯一性。
Foreign Key = For Konnecting（用於連結）到另一個資料表。
3. 建立連結：資料庫關係
使用外鍵的全部目的在於定義不同資料表中的資料如何互相關聯。這對於避免冗餘至關重要。
A. 一對一（One-to-One, 1:1）
資料表 A 中的一筆記錄只對應資料表 B 中的一筆記錄，反之亦然。
- 範例： 一名員工被分配到唯一一台公司配車。
- 如何建立： 將其中一個資料表的主鍵包含在另一個資料表作為外鍵。（這種關係較少見，因為如果資料真的是 1:1，通常直接放在同一個資料表即可。）
B. 一對多（One-to-Many, 1:M）
這是最常見也最重要的關係。資料表 A 中的單一記錄可以對應到資料表 B 中的多筆記錄。
- 範例： 一位客戶可以下達多個訂單。（客戶是「一」的一方；訂單是「多」的一方）。
- 如何建立： 將「一」的一方的主鍵（例如 CustomerID）放入「多」的一方的資料表中作為外鍵（例如訂單資料表）。
常見錯誤警示！外鍵要放在哪裡？
學生常會搞混在 1:M 關係中該把外鍵放在哪裡。
規則： 外鍵永遠放在關係的「多」的一方。
思考一下：訂單需要知道是哪位客戶下的，但客戶記錄不需要列出他們曾經下過的所有訂單（那會導致冗餘！）。
C. 多對多（Many-to-Many, M:M）
資料表 A 中的一筆記錄可以對應到資料表 B 中的多筆記錄，而資料表 B 中的一筆記錄也可以對應到資料表 A 中的多筆記錄。
- 範例： 多名學生可以選修多門課程，而多門課程中也有多名學生。
- 問題： 你不能直接在兩個資料表之間建立 M:M 關係，因為這會導致大量的資料重複。
逐步解決方案：連結資料表（Linking Table）
為了處理 M:M 問題，我們必須引入第三個資料表，通常稱為連結資料表（Linking Table）或橋接資料表（Junction Table）。這個資料表將 M:M 關係拆解為兩個獨立的 1:M 關係。
- 建立資料表 A（學生）和資料表 B（課程）。
- 建立一個新的連結資料表（例如：選課 Enrolment）。
- 連結資料表必須包含兩個欄位：StudentID（來自學生資料表的外鍵）和 CourseID（來自課程資料表的外鍵）。
- 連結資料表的主鍵由這兩個外鍵組合而成（即複合鍵）。
結果： 學生（1）對應到選課（M）。課程（1）對應到選課（M）。問題解決！
4. 處理糟糕的設計：資料冗餘
設計連結資料表的資料庫，其主要目的就是避免資料冗餘（Data Redundancy）。
什麼是資料冗餘？
資料冗餘是指在資料庫中多次儲存同一份資料。
- 錯誤範例： 如果你有一個「訂單」資料表，並在每一筆訂單記錄中都寫入客戶的全名和地址。
冗餘帶來的問題
如果你允許冗餘存在，資料庫將會面臨幾個嚴重的問題，統稱為資料異常（Data Anomalies）：
1. 浪費空間：
為同一個客戶重複儲存同一個地址 500 次，所佔用的儲存空間遠大於在「客戶」資料表只存一次，並在「訂單」資料表中重複使用 500 次外鍵（CustomerID）。
2. 更新異常（不一致）：
這是最危險的問題。如果客戶搬家了，你必須在數百個地方（所有他們的訂單）更新地址。如果你漏掉了任何一筆，資料就會變得不一致——同一人的不同記錄顯示不同的地址。
當資料表正確連結時（使用外鍵），你只需要在一個地方（客戶資料表）更新地址，所有連結的訂單記錄就會自動使用正確且已更新的資訊。
3. 插入異常：
有時在沒有相關資料的情況下，你無法加入新的重要資料。
重點筆記： 良好的資料庫設計會利用關係（PK/FK）確保資料只儲存一次，防止不一致性。這就是資料完整性（Data Integrity）的定義。
章節總結：資料庫設計檢查清單
現在你已經掌握了資料庫設計的基本知識！在建構資料表時，請務必記住這些核心概念：
- 識別你的實體（資料表）。
- 確定每個實體所需的具體資訊（欄位）。
- 確保每個資料表都有唯一的主鍵（Primary Key, PK）。
- 使用外鍵（Foreign Key, FK）來連結資料表，確保 FK 永遠指向另一個資料表的主鍵。
- 盡可能將關係結構化為一對多（1:M），並將 FK 放在「多」的一方。
- 使用連結資料表來處理多對多（M:M）關係。
- 目標是消除資料冗餘並確保高資料完整性。
你做到了！帶著你已經理解強大資料庫所需結構的信心，繼續邁向下一章吧。