前言：

關于數據庫范式，時常有聽說過，一直沒有詳細去了解。一般數據庫書籍或數據庫課程會介紹范式相關內容，范式也經常出現在數據庫考試題目中。不清楚你是否對范式有比較清晰的了解呢？本篇文章我們一起來學習下數據庫范式吧。

1.數據庫范式簡介

為了建立冗余較小、結構合理的數據庫，設計數據庫時必須遵循一定的規則。在關系型數據庫中這種規則就稱為范式。范式是符合某一種設計要求的總結。要想設計一個結構合理的關系型數據庫，必須滿足一定的范式。

范式的英文名稱是 Normal Form ，簡稱 NF 。它是英國人 E.F.Codd 在上個世紀70年代提出關系數據庫模型后總結出來的。范式是關系數據庫理論的基礎，也是我們在設計數據庫結構過程中所要遵循的規則和指導方法。

目前關系型數據庫有六種常見范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又稱完美范式）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎上進一步滿足更多規范要求的稱為第二范式（2NF），其余范式以次類推。

2.常用范式詳解

在設計數據庫時，會參考范式要求來做，但是并不是說遵循的范式等級越高越好，范式過高雖然具有對數據關系有更好的約束性，但是也會導致表之間的關系更加繁瑣，從而導致每次操作的表會變多，數據庫性能下降。通常，在關系型數據庫設計中，最高也就遵循到 BCNF ，普遍還是 3NF 。即一般情況下，我們使用前三個范式已經夠用了。下面我們來詳細了解下常用的前三個范式。

第一范式（1NF）

第一范式是最基本的范式。如果數據庫表中的所有字段值都是不可分解的原子值，就說明該數據庫表滿足了第一范式。簡單的講第一范式就是每一行的各個數據都是不可分割的，同一列中不能有多個值，如果出現重復的屬性就需要定義一個新的實體。

示例：假設一家公司要存儲其員工的姓名和聯系方式。它創建一個如下表：

兩名員工（Jon＆Lester）擁有兩個手機號碼，因此公司將他們存儲在同一表格中，如上表所示。那么該表不符合 1NF ，因為規則說“表的每個屬性必須具有原子（單個）值”，Jon＆Lester員工的 emp_mobile 值違反了該規則。為了使表符合 1NF ，我們應該有如下表數據：

第二范式（2NF）

第二范式在第一范式的基礎之上更進一層。第二范式需要確保數據庫表中的每一列都和主鍵相關，而不能只與主鍵的某一部分相關（主要針對聯合主鍵而言）。也就是說在一個數據庫表中，一個表中只能保存一種數據，不可以把多種數據保存在同一張數據庫表中。

+----------+-------------+-------+
| employee | department | head |
+----------+-------------+-------+
| Jones  | Accountint | Jones |
| Smith  | Engineering | Smith |
| Brown  | Accounting | Jones |
| Green  | Engineering | Smith |
+----------+-------------+-------+

上表描述了被雇傭者，工作部門和領導的關系。我們把能夠唯一表示數據庫中表的一行的數據成為這個表的主鍵。表中 head 列不和主鍵相關。因此，該表是不符合第二范式的，為了使上面的表符合第二范式，需要將它拆分為兩個表：

-- employee 為主鍵
+----------+-------------+
| employee | department |
+----------+-------------+
| Brown  | Accounting |
| Green  | Engineering |
| Jones  | Accounting |
| Smith  | Engineering |
+----------+-------------+

-- department 為主鍵
+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+

第三范式（3NF）

滿足 2NF 的前提下，非主鍵外的所有字段必須互不依賴，即需要確保數據表中的每一列數據都和主鍵直接相關，而不能間接相關。

簡而言之，第三范式（3NF）要求一個關系中不包含已在其它關系已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那么在員工信息表中列出部門編號后就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。如果不存在部門信息表，則根據第三范式（3NF）也應該構建它，否則就會有大量的數據冗余。

3.關于反范式

范式的優點是明顯的，它避免了大量的數據冗余，節省了存儲空間，保持了數據的一致性。范式化的表通常更小，可以更好地放在內存里，所以執行操作會更快。那么是不是只要把所有的表都規范為 3NF 后，數據庫的設計就是最優的呢？這可不一定。范式越高意味著表的劃分更細，一個數據庫中需要的表也就越多，用戶不得不將原本相關聯的數據分攤到多個表中。稍微復雜一些的查詢語句在符合范式的數據庫上都可能需要至少一次關聯，也許更多，這不但代價昂貴，也可能使一些索引策略無效。

所以我們在進行數據庫設計時，并不會完全按照范式要求來做，有時候也會進行反范式設計。通過增加冗余或重復的數據來提高數據庫的讀性能，減少關聯查詢時，join 表的次數。

以上就是詳解MySQL 數據庫范式的詳細內容，更多關于MySQL 數據庫范式的資料請關注腳本之家其它相關文章！