一、范式

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

第一范式（1NF）

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

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

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

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

第二范式（2NF）

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

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

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

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

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

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

第三范式（3NF）

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

+-----------+-------------+---------+-------+| 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 |+-----------+-----------+-------+

上面的兩個(gè)表格的主鍵分別為studentid和subjectid，很顯然兩個(gè)表都符合第二范式。

但是我們會(huì)發(fā)現(xiàn)這兩個(gè)表有重復(fù)冗余的數(shù)據(jù)score。因此第三范式就是要消除冗余的數(shù)據(jù)，具體到上面的情況，就是兩個(gè)表只有一個(gè)能夠存在score這一列數(shù)據(jù)。那么怎么將這兩個(gè)表聯(lián)系起來(lái)呢，這里就出現(xiàn)了外鍵。如果兩個(gè)表中有冗余重復(fù)的列，而且這個(gè)表中的一個(gè)非主鍵列在另一個(gè)表中是主鍵，那么我們?yōu)榱讼哂嗔锌梢园堰@個(gè)非主鍵列作為聯(lián)系兩個(gè)表的橋梁，也就是外鍵。 通過(guò)觀察可以發(fā)現(xiàn)，studentid在第一個(gè)表中是主鍵，在第二個(gè)表中是非主鍵，所以他就是第二個(gè)表的外鍵。因此上述情況我們有了以下符合第三范式的寫法：

+-----------+-------------+---------+| 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è)定了外鍵之后，第一個(gè)表即使刪除了score列，也可以通過(guò)studentid在第二個(gè)表中查找到相應(yīng)的score的值，這樣即消除了數(shù)據(jù)的冗余，又不會(huì)影響查找，滿足第三范式。

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

范式的優(yōu)點(diǎn)

范式化的更新操作通常要比反范式化要快。 當(dāng)數(shù)據(jù)較好地范式化時(shí)，就只有很少或者沒(méi)有重復(fù)的數(shù)據(jù)，所以只需要修改更少的數(shù)據(jù)。 范式化的表通常都比較小，可以更好的放在內(nèi)存中，所以執(zhí)行操作會(huì)更快。 很少有多余的數(shù)據(jù)意味著檢索列表數(shù)據(jù)時(shí)更少需要DISTINCT或者GROUP BY語(yǔ)句。

范式的缺點(diǎn)

范式化的缺點(diǎn)就是通常需要關(guān)聯(lián)。稍微復(fù)雜一些的查詢語(yǔ)句在符合范式的數(shù)據(jù)庫(kù)上都可能需要至少一次關(guān)聯(lián)，也許更多，這不但代價(jià)昂貴，也可能使一些索引策略無(wú)效。

到此這篇關(guān)于MySQL之范式的使用詳解的文章就介紹到這了,更多相關(guān)MySQL 范式 內(nèi)容請(qǐng)搜索好吧啦網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持好吧啦網(wǎng)！