前言：

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

1.數(shù)據(jù)庫范式簡介

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

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

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

2.常用范式詳解

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

第一范式（1NF）

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

示例：假設一家公司要存儲其員工的姓名和聯(lián)系方式。它創(chuàng)建一個如下表：

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

第二范式（2NF）

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

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

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

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

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

第三范式（3NF）

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

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

3.關于反范式

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

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

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

最新評論