一、范式
范式的英文名稱是Normal Form，它是英國人E.F.Codd（關系數據庫的老祖宗）在上個世紀70年代提出關系數據庫模型后總結出來的。范式是關系數據庫理論的基礎，也是我們在設計數據庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三個范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。
第一范式（1NF）
第一范式其實是關系型數據庫的基礎，即任何關系型數據庫都是符合第一范式的。簡單的將第一范式就是每一行的各個數據都是不可分割的，同一列中不能有多個值，如果出現重復的屬性就需要定義一個新的尸實體。
下面數據庫便不符合第一范式：
+------------+-------------------+
| workername | company |
+------------+-------------------+
| John | ByteDance,Tencent |
| Mike | Tencent |
+------------+-------------------+
上面描述的數據所表達的意思是，Mike在Tencent工作，而John同時在ByteDance和Tencent工作（假設這是可能的）。但是這種表達方式并不符合第一范式，即列的數據必須是不可分的，要滿足第一范式，必須是下面的這種形式：
+------------+-----------+
| workername | company |
+------------+-----------+
| Mike | Tencent |
| John | ByteDance |
| John | Tencent |
+------------+-----------+
第二范式（2NF）
首先，一個數據庫要滿足第二范式必須要先滿足第一范式。
我們先看一個表格：
+----------+-------------+-------+
| employee | department | head |
+----------+-------------+-------+
| Jones | Accountint | Jones |
| Smith | Engineering | Smith |
| Brown | Accounting | Jones |
| Green | Engineering | Smith |
+----------+-------------+-------+
這個表描述了被雇傭者，工作部門和領導的關系。這個表所表示的關系在現實生活中是完全可能存在的，現在讓我們考慮一個問題，如果Brown接任Accounting部門的領導，我們需要怎樣對表進行修改？這個問題將會變得非常麻煩，因為我們會發現數據都耦合在一起了，你很難找到一個很好的能唯一確定每一行的判斷條件來執行你的UPDATE語句。而我們把能夠唯一表示數據庫中表的一行的數據成為這個表的主鍵。 因此，沒有主鍵的表是不符合第二范式的，也就是說符合第二范式的表需要規定主鍵。
因此我們為了使上面的表符合第二范式，需要將它拆分為兩個表：
+----------+-------------+
| employee | department |
+----------+-------------+
| Brown | Accounting |
| Green | Engineering |
| Jones | Accounting |
| Smith | Engineering |
+----------+-------------+
+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+
在這兩個表中，第一個表的主鍵為employee，第二個表的主鍵為department。在這種情況下，完成上面的問題就顯得非常簡單了。
第三范式（3NF）
一個關系型數據庫要滿足第三范式必須要先滿足第二范式。
將第三范式前，我們同樣先看兩個表：
+-----------+-------------+---------+-------+
| studentid | studentname | subject | score |
+-----------+-------------+---------+-------+
| 1 | Mike | Math | 96 |
| 2 | John | Chinese | 85 |
| 3 | Kate | History | 100 |
+-----------+-------------+---------+-------+
+-----------+-----------+-------+
| subjectid | studentid | score |
+-----------+-----------+-------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+-----------+-------+
上面的兩個表格的主鍵分別為studentid和subjectid，很顯然兩個表都符合第二范式。
但是我們會發現這兩個表有重復冗余的數據score。因此第三范式就是要消除冗余的數據，具體到上面的情況，就是兩個表只有一個能夠存在score這一列數據。那么怎么將這兩個表聯系起來呢，這里就出現了外鍵。如果兩個表中有冗余重復的列，而且這個表中的一個非主鍵列在另一個表中是主鍵，那么我們為了消除冗余列可以把這個非主鍵列作為聯系兩個表的橋梁，也就是外鍵。 通過觀察可以發現，studentid在第一個表中是主鍵，在第二個表中是非主鍵，所以他就是第二個表的外鍵。因此上述情況我們有了以下符合第三范式的寫法：
+-----------+-------------+---------+
| studentid | studentname | subject |
+-----------+-------------+---------+
| 1 | Mike | Math |
| 2 | John | Chinese |
| 3 | Kate | History |
+-----------+-------------+---------+
+-----------+-----------+-------+
| subjectid | studentid | score |
+-----------+-----------+-------+
| 101 | 1 | 96 |
| 111 | 3 | 100 |
| 201 | 2 | 85 |
+-----------+-----------+-------+
可以發現在設定了外鍵之后，第一個表即使刪除了score列，也可以通過studentid在第二個表中查找到相應的score的值，這樣即消除了數據的冗余，又不會影響查找，滿足第三范式。
二、范式的優點和缺點
范式的優點
- 范式化的更新操作通常要比反范式化要快。
- 當數據較好地范式化時，就只有很少或者沒有重復的數據，所以只需要修改更少的數據。
- 范式化的表通常都比較小，可以更好的放在內存中，所以執行操作會更快。
- 很少有多余的數據意味著檢索列表數據時更少需要DISTINCT或者GROUP BY語句。
范式的缺點
- 范式化的缺點就是通常需要關聯。稍微復雜一些的查詢語句在符合范式的數據庫上都可能需要至少一次關聯，也許更多，這不但代價昂貴，也可能使一些索引策略無效。
到此這篇關于MySQL之范式的使用詳解的文章就介紹到這了,更多相關MySQL 范式 內容請搜索腳本之家以前的文章或繼續瀏覽下面的相關文章希望大家以后多多支持腳本之家！
您可能感興趣的文章:- 數據庫 三范式最簡單最易記的解釋
- 詳解MySQL 數據庫范式
- 數據庫設計三大范式簡析
- MySQL學習之三大范式詳解小白篇
