啥是數據庫範式

前言：

關於數據庫範式，時常有據說過，一直沒有詳細去了解。通常數據庫書籍或數據庫課程會介紹範式相關內容，範式也常常出如今數據庫考試題目中。不清楚你是否對範式有比較清晰的瞭解呢？本篇文章咱們一塊兒來學習下數據庫範式吧。

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 表的次數。

參考：

• http://www.javashuo.com/article/p-tswvfwne-vd.html
• https://www.zhihu.com/question/24696366
• https://en.wikipedia.org/wiki/Database_normalization