資料庫三大範式的學習與資料庫表設計的瞭解

內容簡單介紹

對於資料庫三大範式的理解以及一些設計表示要註意的方面

本章內容梳理圖

資料庫三大範式比較官方的定義

資料庫的三大範式（Normal Forms）是關係資料庫設計中用於確保數據結構化、減少數據冗餘、並提高數據完整性的指導和規則。

以下是三大範式的簡述：

1. 第一範式（1NF）
   • 定義：如果關係模式R的每個屬性都是不可分的數據項，則R∈1NF。簡單來說，就是表中的每個欄位都是最基本的單元，不可再分。
   • 目的：消除欄位中的重覆組和確保每個欄位的原子性。
   • 註意：在現代的關係型資料庫管理系統中，通常都預設滿足第一範式。
2. 第二範式（2NF）
   • 前提：滿足第一範式。
   • 定義：如果關係模式R∈1NF，且每一個非主屬性都完全函數依賴於任何一個候選鍵，則R∈2NF。
   • 目的：消除部分函數依賴，即非主屬性不應僅依賴於主鍵的一部分（在複合主鍵的情況下）。
   • 做法：通常通過拆分表來實現，確保非主屬性完全依賴於整個主鍵。
3. 第三範式（3NF）
   • 前提：滿足第二範式。
   • 定義：如果關係模式R中不存在非主屬性對主屬性的傳遞依賴，則稱R在第三範式。
   • 目的：消除傳遞依賴，確保非主屬性不依賴於其他非主屬性。
   • 註意：有時為了查詢效率，可能會故意違反第三範式，但這需要權衡冗餘和查詢效率之間的關係。

資料庫三大範式個人簡要理解版

第一範式：每個屬性都是不可分割的，原子性的，例如地址這個欄位，它還可以分為省、市、區或縣

第二範式：在滿足一範式的情況下，所有非主鍵屬性必完全依賴於主鍵，這裡完全是指非主鍵屬性依賴於主鍵的所有部分（會有複合主鍵），而非主鍵屬性之間存在依賴則不是第二範式關心的重點，這是第三範式的重點內容，第二範式的重點是非主鍵屬性與主鍵有無直接完全依賴關係。要是非主鍵屬性依賴於主鍵的一部分或者非主鍵屬性與主鍵無直接完全依賴，那麼需要拆分成多個表進行滿足第二範式

第三範式：在滿足二範式的情況下，非主鍵不能有傳遞依賴，傳遞依賴是指a依賴於b，而b又依賴於主鍵，這就是a間接依賴於主鍵，比如某一屬性依賴於另一屬性，然後另一屬性依賴於主鍵，這就是傳遞依賴，出現這種情況的話，需要根據實際進行拆分成多個表來完成滿足第三範式

資料庫三大範式個人詳細理解版

資料庫第一範式的理解

這裡要理解這個不可分割的原子項，這個主要指一個欄位所表達的內容是單一的，不可在分割，例如省份，就是指山西省、河北省等，這種從內容上不能夠分割的，要是地址的話就可以分為國家、省份、市、區縣、鄉村，這樣就達到不可分割的原子項了，再來說一下另一種情況，先來舉個例子吧

學生ID、學生姓名、課程1、課程2、課程3，這是一個表，看是否滿足第一範式，答案是滿足的，每一列都是不可分割的原子項，但是我們設計表得遵循資料庫表設計規範，而三大範式只是一部分，按照表設計規範的話，上方的表示不滿足的，有以下幾個點考慮：

1. 可擴展性問題：每個學生只能記錄三門課程，如果需要記錄更多或更少的課程，表結構就需要調整。
2. 數據冗餘：如果多個學生選修了同一門課程，那麼該課程的名稱將在表中多次出現，違反了避免數據冗餘的原則。
3. 更新和維護困難：如果課程名稱需要更改，那麼所有相關的課程欄位（課程1、課程2、課程3）都需要更新，這增加了維護的複雜性。
4. 查詢困難：查詢特定學生選修的所有課程或查詢選修了特定課程的所有學生都變得更加困難，因為課程信息分散在不同的欄位中。

所以在考慮上方四個問題的話，我們將上方的表設計為

• 學生表：包含學生ID和學生姓名。
• 課程表：包含課程ID和課程名稱。
• 學生課程關聯表：包含學生ID、課程ID和可能的其他相關信息（如成績）

此做法消除了數據冗餘，提高了可擴展性，並簡化了更新和查詢操作，而且還要註意的是那個個學生課程關聯表這種做法非常常見，儘量去學習一下

這就是資料庫第一範式學習與理解

資料庫第二範式的理解

這裡要理解所謂的依賴，像我自己想的就是：我們在資料庫中使用sql語句查詢不就是非主鍵依賴於主鍵嗎，這其實是不正確的，雖然有一定的關係，但我們要分清主次，就是第二範式這個依賴，主要是基於業務邏輯的關係，比如學生學號與學生姓名等其他學生信息這種含有關聯的業務邏輯，我們要看非主鍵與主鍵是否符合這種業務邏輯關係，而且還得必須是完全符合，接著拿一個例子來說明一下這個判斷過程

一個訂單表：訂單ID、產品ID、產品名稱、產品價格、訂單數量、客戶ID和客戶姓名，看一下這個表是否滿足第二範式

我們假設這個訂單表主鍵為訂單ID，訂單在業務上與產品有關聯的，這個訂單是買的啥產品了，並不是那種直接的業務邏輯關係，產品名稱只是依賴於產品ID，所以不是依賴於訂單ID，雖然按這樣設計表，通過查詢訂單ID可以得出產品名稱來，這是在查詢中的一種關係吧，而這裡的時候要滿足業務邏輯這個依賴的，所以不滿足第二範式的，那麼改進為

將訂單表拆分為三個表：訂單表、產品表和客戶表。訂單表包含訂單ID、產品ID、訂單數量和客戶ID欄位；產品表包含產品ID、產品名稱和產品價格欄位；客戶表包含客戶ID和客戶姓名欄位

對了除了滿足這種依賴的話，第二範式是非主鍵完全依賴主鍵，註意這裡的完全，是指非主鍵要依賴於主鍵的所有，有可能主鍵的話就是複合主鍵，要是我們把上方例題的表的主鍵假設為（訂單ID、產品ID），產品名稱僅依賴於產品ID，只是一部分，所以不滿足第二範式，改進結果與上方一致

還有比較重要的點就是：第二範式是基於第一範式的基礎上來進行判斷與改進的，另一個關註點就是第二範式主要看非主鍵與主鍵的關係，不用關註非主鍵之間的關係

這就是第二範式的學習與理解

資料庫第三範式的理解

這裡主要理解的就是一個非主鍵有依賴於另一個非主鍵，然後另一個非主鍵直接依賴於主鍵這種情況，這樣就構成了一個非主鍵對主鍵的傳遞依賴，要滿足第三範式就得消除這種依賴，請看下方的例子實操

一個員工表：員工ID、員工姓名、部門ID、部門名稱和部門經理，看一下是否滿足第三範式

一般員工表的主鍵為員工ID，所以我們假設主鍵為員工ID，我們看一下有沒有傳遞依賴的情況，部門名稱和部門經理就可以依賴於部門ID，然後再依賴於員工ID，就形成了傳遞依賴，那我們需要拆分表

將員工表拆分為兩個表：員工表和部門表。員工表包含員工ID、員工姓名和部門ID欄位；部門表包含部門ID、部門名稱和部門經理欄位。確保每個表中的非主鍵列都只直接依賴於主鍵列

這其實分析挺矛盾的，第三範式是基於第二範式的情況下判斷，員工表第二範式並未滿足，你用第二範式來做這個題其實直接就可以得出最終結果了，而且也滿足第三範式的，但是題又讓你分析，確實是存在依賴關係的，所以你要根據第三範式的主要點是否有傳遞依賴來分析，這也第三範式的重點

這就是第三範式的學習與理解

總結

三大範式是設計表的基礎，要是滿足這三大範式的話，表的查詢性能等其他方面也會下降，所以本章只是介紹三大範式的用法，實際設計表還得考慮很多因素，這裡列出一些：

1. 業務需求理解：
   • 在設計資料庫表之前，必須充分理解業務需求。這包括瞭解需要存儲哪些數據、數據之間的關係、數據的訪問模式等。
2. 數據完整性：
   • 確保數據的準確性和一致性。這包括使用主鍵、外鍵、唯一約束、檢查約束等來維護數據的完整性。
3. 性能優化：
   • 考慮查詢性能、數據插入、更新和刪除的性能。可能需要創建索引、視圖、存儲過程等來提高性能。
4. 安全性：
   • 確保只有授權的用戶可以訪問和修改數據。這包括使用適當的身份驗證和授權機制。
5. 可擴展性：
   • 設計資料庫表時，應考慮未來的增長和變化。這可能包括使用分區表、歸檔舊數據等策略。
6. 規範化與反規範化：
   • 根據需要平衡規範化和反規範化的程度。規範化有助於減少數據冗餘和提高數據一致性，但可能導致查詢性能下降。反規範化則可以提高查詢性能，但可能增加數據冗餘和維護複雜性。
7. 數據類型選擇：
   • 為每個欄位選擇合適的數據類型，以確保數據的準確性和存儲效率。
8. 命名規範：
   • 使用清晰、有意義的命名規範來命名錶、欄位、索引等資料庫對象，以提高可讀性和可維護性。
9. 文檔化：
   • 為資料庫表設計提供充分的文檔，包括表結構、欄位說明、關係說明、索引說明等，以便於其他開發人員理解和維護。
10. 備份與恢復策略：
    • 設計資料庫時應考慮備份和恢復策略，以確保在發生故障時可以恢複數據。
11. 併發控制：
    • 在多用戶環境中，需要考慮併發控制機制，如樂觀鎖、悲觀鎖等，以防止數據衝突和不一致。
12. 遵循最佳實踐和標準：
    • 遵循資料庫設計的最佳實踐和行業標準，如使用三大範式、避免使用保留字等。