快捷導(dǎo)航

MySQL之范式的使用詳解

更新時間：2020年10月21日 11:05:07 作者：超人不會飛

這篇文章主要介紹了MySQL之范式的使用詳解，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧

一、范式

范式的英文名稱是Normal Form，它是英國人E.F.Codd（關(guān)系數(shù)據(jù)庫的老祖宗）在上個世紀(jì)70年代提出關(guān)系數(shù)據(jù)庫模型后總結(jié)出來的。范式是關(guān)系數(shù)據(jù)庫理論的基礎(chǔ)，也是我們在設(shè)計數(shù)據(jù)庫結(jié)構(gòu)過程中所要遵循的規(guī)則和指導(dǎo)方法。目前有跡可尋的共有8種范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三個范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

第一范式（1NF）

第一范式其實是關(guān)系型數(shù)據(jù)庫的基礎(chǔ)，即任何關(guān)系型數(shù)據(jù)庫都是符合第一范式的。簡單的將第一范式就是每一行的各個數(shù)據(jù)都是不可分割的，同一列中不能有多個值，如果出現(xiàn)重復(fù)的屬性就需要定義一個新的尸實體。
下面數(shù)據(jù)庫便不符合第一范式：

+------------+-------------------+
| workername | company      |
+------------+-------------------+
| John    | ByteDance,Tencent |
| Mike    | Tencent      |
+------------+-------------------+

上面描述的數(shù)據(jù)所表達(dá)的意思是，Mike在Tencent工作，而John同時在ByteDance和Tencent工作（假設(shè)這是可能的）。但是這種表達(dá)方式并不符合第一范式，即列的數(shù)據(jù)必須是不可分的，要滿足第一范式，必須是下面的這種形式：

+------------+-----------+
| workername | company  |
+------------+-----------+
| Mike    | Tencent  |
| John    | ByteDance |
| John    | Tencent  |
+------------+-----------+

第二范式（2NF）

首先，一個數(shù)據(jù)庫要滿足第二范式必須要先滿足第一范式。
我們先看一個表格：

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

這個表描述了被雇傭者，工作部門和領(lǐng)導(dǎo)的關(guān)系。這個表所表示的關(guān)系在現(xiàn)實生活中是完全可能存在的，現(xiàn)在讓我們考慮一個問題，如果Brown接任Accounting部門的領(lǐng)導(dǎo)，我們需要怎樣對表進(jìn)行修改？這個問題將會變得非常麻煩，因為我們會發(fā)現(xiàn)數(shù)據(jù)都耦合在一起了，你很難找到一個很好的能唯一確定每一行的判斷條件來執(zhí)行你的UPDATE語句。而我們把能夠唯一表示數(shù)據(jù)庫中表的一行的數(shù)據(jù)成為這個表的主鍵。因此，沒有主鍵的表是不符合第二范式的，也就是說符合第二范式的表需要規(guī)定主鍵。

因此我們?yōu)榱耸股厦娴谋矸系诙妒剑枰獙⑺鸱譃閮蓚€表：

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

+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+

在這兩個表中，第一個表的主鍵為employee，第二個表的主鍵為department。在這種情況下，完成上面的問題就顯得非常簡單了。

第三范式（3NF）

一個關(guān)系型數(shù)據(jù)庫要滿足第三范式必須要先滿足第二范式。
將第三范式前，我們同樣先看兩個表：

+-----------+-------------+---------+-------+
| 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，很顯然兩個表都符合第二范式。

但是我們會發(fā)現(xiàn)這兩個表有重復(fù)冗余的數(shù)據(jù)score。因此第三范式就是要消除冗余的數(shù)據(jù)，具體到上面的情況，就是兩個表只有一個能夠存在score這一列數(shù)據(jù)。那么怎么將這兩個表聯(lián)系起來呢，這里就出現(xiàn)了外鍵。如果兩個表中有冗余重復(fù)的列，而且這個表中的一個非主鍵列在另一個表中是主鍵，那么我們?yōu)榱讼哂嗔锌梢园堰@個非主鍵列作為聯(lián)系兩個表的橋梁，也就是外鍵。通過觀察可以發(fā)現(xiàn)，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  |
+-----------+-----------+-------+

可以發(fā)現(xiàn)在設(shè)定了外鍵之后，第一個表即使刪除了score列，也可以通過studentid在第二個表中查找到相應(yīng)的score的值，這樣即消除了數(shù)據(jù)的冗余，又不會影響查找，滿足第三范式。

二、范式的優(yōu)點和缺點

范式的優(yōu)點