※ Schema 設計
● 什麼是Schema？
Schema 是用來描述資料庫內的表格結構、欄位格式以及表格之間的關聯。它定義了資料庫的邏輯結構，確保資料的組織和存取方式一致。
思考點：資料以什麼「形式」保存在資料庫？
資料在資料庫中以多種形式保存，主要包括以下幾種：- 表格 (Tables)：資料以行和列的形式存放，每一行代表一條記錄，每一列代表一個欄位。
- 檔案 (Files)：資料可以以檔案的形式儲存，常見於檔案式資料儲存系統。
- 區塊 (Blocks)：資料被切成固定大小的區塊，常見於企業級儲存系統。
- 物件 (Objects)：資料以物件的形式儲存，每個物件都有唯一的識別碼，適合雲端儲存和網頁應用程式。
實務上用一個簡單的小方格表來代表一個table。說明table名稱是User，包含以下欄位：
- id：整數型別 (int)，並且是主鍵 (PRIMARY KEY)。
- name：可變長度字串 (varchar)，最大長度為 255 字元。
- email：可變長度字串 (varchar)，最大長度為 255 字元。
這樣的圖示在 Schema 設計時非常有用，可以清楚地表示 table 的結構和欄位類型。這種視覺化的表示方式有助於理解和溝通資料庫設計。
● 為什麼不能把所有資料塞進一個欄位（column）裡面？
- 資料查詢不方便，效率變慢：如果所有資料都存在一個欄位裡，查詢特定資料會變得非常困難。例如，假設我們將
id、name和email都存在一個data欄位中，查詢特定email的使用者時，我們需要解析每一行的data欄位，這樣會大大降低查詢效率。
SELECT *FROM user WHERE？
- 資料修改不方便：更新資料也會變得非常麻煩。假設我們需要更新某個使用者的
email，我們需要先解析出data欄位中的所有資料，然後再進行更新，這樣不僅繁瑣，而且容易出錯。
UPDATE user SET data = ? WHERE ?
- 資料完整性和一致性：將不同類型的資料混合在一個欄位中，會使得資料的完整性和一致性難以維護。這樣的設計違反了資料庫的正規化原則，容易導致資料冗餘和異常。
● 總結：
Schema 設計的好壞，影響系統效能和開發方便。
左圖的設計比較簡單，但在開發和效能上會造成不便。右圖則利用更多的欄位來儲存資料，這樣在查詢和開發上會更方便。因此在後端開發前，應花時間設計一個完整的 Schema 是非常重要的。這樣可以確保資料庫結構合理，查詢效率高，並且在未來的開發和維護中減少問題。良好的 Schema 設計可以提高系統的可擴展性和可維護性，讓開發過程更加順利。
※ Normal Forms（正規式）
● 在Schema設計上應該遵守的規則：
在設計 Schema 時，遵守 Normal Forms（正規式）的規則是非常重要的。這些規則是前輩們總結出來的最佳實踐，能夠幫助我們設計出高效且易於維護的資料庫結構。
● 第一正規式 (1NF)：
- 每個欄位只保存一個值：這意味著每個欄位應該是單一的，不能包含多個值或重複的資料。這樣可以確保資料的完整性和一致性。
- 每個欄位的值必須是不可分割的：例如，不能在一個欄位中存儲多個電話號碼或地址。這樣可以讓資料庫更容易查詢和維護。
- 任兩條 Row 的內容不可以完全相同：用主鍵（Primary Key）來確保每一行資料是唯一的，這樣可以避免重複資料。主鍵是一個或多個欄位的組合，用來唯一標識每一行資料。
● 第二正規式 (2NF)：
- 符合第一正規式 (1NF)。
- 消除部分依賴：所有在資料表中，不是主鍵（Primary Key）的一部分的欄位必須完全依賴於主鍵。如果主鍵是由多個欄位組成的複合鍵，那麼每個非鍵屬性必須依賴於整個複合鍵，而不是只依賴其中的一部分。
● 第三正規式 (3NF)：
- 符合第二正規式 (2NF)。
- 消除傳遞依賴：欄位(Column)之間不能存在傳遞關係。這意味著非鍵屬性不能依賴於其他非鍵屬性。換句話說，所有非鍵屬性必須直接依賴於主鍵，而不是通過其他非鍵屬性間接依賴於主鍵。
● Boyce–Codd Normal Form（BCNF）：
- 符合第三正規式 (3NF)。
- 消除所有候選鍵的傳遞依賴：在 BCNF 中，任何候選鍵（可以作為主鍵的欄位或欄位組合）之間不能存在傳遞依賴。這意味著每個非鍵屬性必須完全依賴於候選鍵，而不是通過其他非鍵屬性間接依賴於候選鍵。
● 第四正規式 (4NF)：
- 符合BCNF。
- 消除多值依賴：在 4NF 中，資料表中的欄位之間不能存在多值依賴。這意味著在同一行(ROW)中，不能有一對多的關係。
左邊的圖示在同一行(ROW)中有一對多的關係，而右邊的圖示則沒有這種關係。因此，右邊的圖示符合 4NF 的要求。
