引言

? ?MySQL的庫表設(shè)計，在很多時候我們都是率性而為坦胶，往往在前期的設(shè)計中考慮并不全面透典，同時對于庫表結(jié)構(gòu)的劃分也并不明確，所以很多時候在開發(fā)過程中顿苇，代碼敲著敲著會去重構(gòu)某張表結(jié)構(gòu)峭咒，甚至大面積重構(gòu)多張表結(jié)構(gòu)，這種隨心所欲的設(shè)計方式纪岁，無疑給開發(fā)造成了很大困擾凑队。

[圖片上傳失敗...(image-9af152-1670572692821)]
? ?但實際上設(shè)計DB庫表結(jié)構(gòu)時，也有一些共同需要遵守的規(guī)范幔翰，這些規(guī)范在數(shù)據(jù)庫設(shè)計中被稱為“范式”漩氨，理解并掌握這些設(shè)計時的規(guī)范，能讓咱們在項目之初遗增，設(shè)計的庫表結(jié)構(gòu)更為合理且優(yōu)雅叫惊。數(shù)據(jù)庫范式中，聲名遠(yuǎn)揚(yáng)的有三大范式做修，但除此之外也有一些其他設(shè)計規(guī)范霍狰，如：

• ①數(shù)據(jù)庫三大范式（1NF抡草、2NF、3NF）
• ③第四范式(4NF）和第五范式：完美范式（5NF）
• ②巴斯-科德范式（BCNF）
• ④反范式設(shè)計

不過對于上述的幾種設(shè)計范式蔗坯，大部分小伙伴應(yīng)該僅了解過三范式康震，對于其他的應(yīng)該未曾接觸，那在本篇中會重點(diǎn)闡述庫表設(shè)計時宾濒，會用到的這些范式腿短。

一、數(shù)據(jù)庫三大范式

? ?范式(Normal Form)在前面也提到過鼎兽，它就是指設(shè)計數(shù)據(jù)庫時要遵守的一些原則答姥，而數(shù)據(jù)庫的三大范式，相信諸位在學(xué)習(xí)數(shù)據(jù)庫知識時也定然接觸過谚咬。三大范式之間鹦付，它們是遞進(jìn)的關(guān)系，也就是后續(xù)的范式都基于前一個范式的基礎(chǔ)上推行择卦，就好比下面這句話：

今天我要先炒菜敲长，然后吃飯，最后洗碗秉继。

炒菜祈噪、吃飯、洗碗三者也屬于遞進(jìn)關(guān)系尚辑，后者都建立在前者之上辑鲤，其順序不能顛倒，比如先吃飯再炒菜杠茬，這必然是行不通的月褥。數(shù)據(jù)庫的三大范式也一樣，第二范式必須建立在第一范式的基礎(chǔ)之上瓢喉，如若設(shè)計的庫表第一范式都不滿足宁赤，那定然是無法滿足第二范式的。

寫在前面的話：其實對于數(shù)據(jù)庫三范式相關(guān)的資料栓票，網(wǎng)上也有很多很多决左，但大部分資料都涉及了太多的概念，通篇看下來也很難讓人理解走贪，因此下述的三范式則會結(jié)合具體的設(shè)計實例來讓諸位徹底理解三范式佛猛。

1.1、第一范式（1NF）

? ?庫表設(shè)計時的第一范式坠狡，主要是為了確保原子性的挚躯，也就是存儲的數(shù)據(jù)具備不可再分性，這話咋理解呢擦秽？上個案例：

SELECT * FROM `zz_student`;
+----------------------+--------+-------+
| student              | course | score |
+----------------------+--------+-------+
| 竹子码荔，男漩勤，185cm      | 語文   |    95 |
| 竹子，男缩搅，185cm      | 數(shù)學(xué)   |   100 |
| 竹子越败，男，185cm      | 英語   |    88 |
| 熊貓硼瓣，女究飞，170cm      | 語文   |    99 |
| 熊貓，女堂鲤，170cm      | 數(shù)學(xué)   |    90 |
| 熊貓亿傅，女，170cm      | 英語   |    95 |
+----------------------+--------+-------+

在上述的學(xué)生表中瘟栖，其中有一個student學(xué)生列葵擎，這一列存儲的數(shù)據(jù)則明顯不符合第一范式：原子性的規(guī)定，因為這一列的數(shù)據(jù)還可以再拆分為姓名半哟、性別酬滤、身高三項數(shù)據(jù)，因此為了符合第一范式寓涨，應(yīng)該將表結(jié)構(gòu)更改為：

+--------------+-------------+----------------+--------+-------+
| student_name | student_sex | student_height | course | score |
+--------------+-------------+----------------+--------+-------+
| 竹子         | 男          | 185cm          | 語文   |    95 |
| 竹子         | 男          | 185cm          | 數(shù)學(xué)   |   100 |
| 竹子         | 男          | 185cm          | 英語   |    88 |
| 熊貓         | 女          | 170cm          | 語文   |    99 |
| 熊貓         | 女          | 170cm          | 數(shù)學(xué)   |    90 |
| 熊貓         | 女          | 170cm          | 英語   |    95 |
+--------------+-------------+----------------+--------+-------+

將student這一列數(shù)據(jù)盯串，分別拆分為姓名、性別戒良、身高三列体捏，然后分別存儲對應(yīng)的數(shù)據(jù)才合理，通過這樣的優(yōu)化后糯崎，此時zz_student這張表則符合了數(shù)據(jù)庫設(shè)計的第一范式译打。

那此刻思考一下：如果不去拆分列滿足第一范式，會造成什么影響呢拇颅？

• 客戶端語言和表之間無法很好的生成映射關(guān)系。
• 查詢到數(shù)據(jù)后乔询，需要處理數(shù)據(jù)時樟插，還需要對student字段進(jìn)行額外拆分。
• 插入數(shù)據(jù)時竿刁，對于第一個字段的值還需要先拼裝后才能進(jìn)行寫入黄锤。

簡單來說，如果按照原本那張形式去做業(yè)務(wù)開發(fā)食拜，顯然操作起來會更加麻煩且復(fù)雜一些鸵熟，但第一范式的原子性，除開對列級別生效之外负甸，行級別的數(shù)據(jù)也是同理流强，也就是每一行數(shù)據(jù)之間是互不影響的痹届，都是獨(dú)立的一個整體。

1.2打月、第二范式（2NF）

? ?上述的第一范式還是比較容易理解队腐，緊接著來看看第二范式，第二范式的要求表中的所有列奏篙，其數(shù)據(jù)都必須依賴于主鍵柴淘，也就是一張表只存儲同一類型的數(shù)據(jù)，不能有任何一列數(shù)據(jù)與主鍵沒有關(guān)系秘通，還是上面的那張表數(shù)據(jù)為例：

+--------------+-------------+----------------+--------+-------+
| student_name | student_sex | student_height | course | score |
+--------------+-------------+----------------+--------+-------+
| 竹子         | 男          | 185cm          | 語文   |    95 |
| 竹子         | 男          | 185cm          | 數(shù)學(xué)   |   100 |
| 竹子         | 男          | 185cm          | 英語   |    88 |
| 熊貓         | 女          | 170cm          | 語文   |    99 |
| 熊貓         | 女          | 170cm          | 數(shù)學(xué)   |    90 |
| 熊貓         | 女          | 170cm          | 英語   |    95 |
+--------------+-------------+----------------+--------+-------+

雖然此時已經(jīng)滿足了數(shù)據(jù)庫的第一范式为严，但此刻觀察course課程、score分?jǐn)?shù)這兩列數(shù)據(jù)肺稀，跟前面的幾列數(shù)據(jù)實際上依賴關(guān)系并不大第股，同時也由于這樣的結(jié)構(gòu)，導(dǎo)致前面幾列的數(shù)據(jù)出現(xiàn)了大量冗余盹靴，所以此時可以再次拆分一下表結(jié)構(gòu)：

SELECT * FROM `zz_student`;
+------------+--------+------+--------+--------------+--------------+
| student_id | name   | sex  | height | department   | dean         |
+------------+--------+------+--------+--------------+--------------+
|          1 | 竹子   | 男   | 185cm  | 計算機(jī)系     | 竹子老大     |
|          2 | 熊貓   | 女   | 170cm  | 金融系       | 熊貓老大     |
+------------+--------+------+--------+--------------+--------------+

SELECT * FROM `zz_course`;
+-----------+-------------+
| course_id | course_name |
+-----------+-------------+
|         1 | 語文        |
|         2 | 數(shù)學(xué)        |
|         3 | 英語        |
+-----------+-------------+

SELECT * FROM `zz_score`;
+----------+------------+-----------+-------+
| score_id | student_id | course_id | score |
+----------+------------+-----------+-------+
|        1 |          1 |         1 |    95 |
|        2 |          1 |         2 |   100 |
|        3 |          1 |         3 |    88 |
|        4 |          2 |         1 |    99 |
|        5 |          2 |         2 |    90 |
|        6 |          2 |         3 |    95 |
+----------+------------+-----------+-------+

經(jīng)過上述結(jié)構(gòu)優(yōu)化后炸茧，之前的一張表此時被我們拆分成學(xué)生表、課程表稿静、成績表三張梭冠，每張表中的id字段作為主鍵，其他字段都依賴這個主鍵改备。無論在那張表中控漠，都可以通過id主鍵確定其他字段的信息。

主鍵可以不用id悬钳，但最好是自增的主鍵ID盐捷，這跟索引有關(guān)，后續(xù)索引篇詳細(xì)講解默勾。

此時再將目光看到先后兩張學(xué)生表碉渡，原本的學(xué)生表有六條學(xué)生記錄，其中有四條是冗余數(shù)據(jù)母剥，此時的學(xué)生表則只有兩條數(shù)據(jù)滞诺，同時這張學(xué)生表中只存儲學(xué)生信息相關(guān)的數(shù)據(jù)。經(jīng)過本次結(jié)構(gòu)優(yōu)化后环疼，每張表的業(yè)務(wù)屬性都具備“唯一性”习霹，也就是每張表都只會描述了“一件事情”，不會存在一張表中會出現(xiàn)兩個業(yè)務(wù)屬性（例如之前的學(xué)生表包含了學(xué)生信息和課程成績）炫隶。

1.3淋叶、第三范式（3NF）

? ?前面已經(jīng)對第一范式、第二范式進(jìn)行了直觀闡述伪阶，接下來聊一聊數(shù)據(jù)庫的第三范式煞檩，第三范式要求表中每一列數(shù)據(jù)不能與主鍵之外的字段有直接關(guān)系处嫌，怎么理解呢？基于上述的例子：

+------------+--------+------+--------+--------------+--------------+
| student_id | name   | sex  | height | department   | dean         |
+------------+--------+------+--------+--------------+--------------+
|          1 | 竹子   | 男   | 185cm  | 計算機(jī)系     | 竹子老大     |
|          2 | 熊貓   | 女   | 170cm  | 金融系       | 熊貓老大     |
+------------+--------+------+--------+--------------+--------------+

比如這張學(xué)生表形娇，目前即符合第一范式锰霜，也符合第二范式，但看最后的兩個字段桐早，department表示當(dāng)前學(xué)生所屬的院校癣缅，dean則表示這個院系的院長是誰。一般來說哄酝，一個學(xué)生的院長是誰友存，首先是取決于學(xué)生所在的院系的，因此最后的dean字段明顯與department字段存在依賴關(guān)系陶衅，因此需要進(jìn)一步調(diào)整表結(jié)構(gòu)：

SELECT * FROM `department`;
+---------------+-----------------+-----------------+
| department_id | department_name | department_dean |
+---------------+-----------------+-----------------+
|             1 | 計算機(jī)系        | 竹子老大        |
|             2 | 金融系          | 熊貓老大        |
+---------------+-----------------+-----------------+

SELECT * FROM `zz_student`;
+------------+--------+------+--------+---------------+
| student_id | name   | sex  | height | department_id |
+------------+--------+------+--------+---------------+
|          1 | 竹子   | 男   | 185cm  |             1 |
|          2 | 熊貓   | 女   | 170cm  |             2 |
+------------+--------+------+--------+---------------+

經(jīng)過進(jìn)一步的結(jié)構(gòu)優(yōu)化后屡立，又將原本的學(xué)生表拆為了院系表、學(xué)生表兩張搀军，學(xué)生表中則是只存儲一個院系ID膨俐，由院系表存儲院系相關(guān)的所有數(shù)據(jù)。至此罩句，學(xué)生表中的每個非主鍵字段與其他非主鍵字段之間焚刺，都是相互獨(dú)立的，之間不會再存在任何依賴性门烂，所有的字段都依賴于主鍵乳愉。

那這里為什么要調(diào)整呢？不調(diào)整不行嗎屯远？還真不行蔓姚，來簡單思考一下不調(diào)整結(jié)構(gòu)的情況下會發(fā)生什么問題：

• ①當(dāng)一個院系的院長換人后，需要同時修改學(xué)生表中的多條數(shù)據(jù)慨丐。
• ②當(dāng)一個院長離職后坡脐，需要刪除該院長的記錄，會同時刪除多條學(xué)生信息房揭。
• ......

也就是如果設(shè)計的表結(jié)構(gòu)备闲，無法滿足第三范式，在操作表時就會出現(xiàn)異常崩溪，使得整個表較難維護(hù)。

1.4斩松、數(shù)據(jù)庫三范式小結(jié)

? ?到這里就已經(jīng)將庫表設(shè)計的三范式做了直觀闡述伶唯，總結(jié)如下：

• 第一范式：確保原子性，表中每一個列數(shù)據(jù)都必須是不可再分的字段惧盹。
• 第二范式：確保唯一性乳幸，每張表都只描述一種業(yè)務(wù)屬性瞪讼，一張表只描述一件事。
• 第三范式：確保獨(dú)立性粹断，表中除主鍵外符欠，每個字段之間不存在任何依賴，都是獨(dú)立的瓶埋。

經(jīng)過三范式的示例后希柿，數(shù)據(jù)庫中的表數(shù)量也逐漸多了起來，似乎設(shè)計符合三范式的庫表結(jié)構(gòu)养筒，反而更加麻煩了對嗎曾撤？答案并非如此，因為在沒有按照范式設(shè)計時晕粪，會存在幾個問題：

• ①整張表數(shù)據(jù)比較冗余挤悉，同一個學(xué)生信息會出現(xiàn)多條。
• ②表結(jié)構(gòu)特別臃腫巫湘，不易于操作装悲，要新增一個學(xué)生信息時，需添加大量數(shù)據(jù)尚氛。
• ③需要更新其他業(yè)務(wù)屬性的數(shù)據(jù)時诀诊，比如院系院長換人了，需要修改所有學(xué)生的記錄怠褐。

但按照三范式將表結(jié)構(gòu)拆開后畏梆，假設(shè)要新增一條學(xué)生數(shù)據(jù)，就只需要插入學(xué)生相關(guān)的信息即可奈懒，同時如果某個院系的院長換人了奠涌，只需要修改院系表中的院長就行，學(xué)生表中的數(shù)據(jù)無需發(fā)生任何更改磷杏。

因此溜畅，經(jīng)過三范式的設(shè)計優(yōu)化后，整個庫中的所有表結(jié)構(gòu)极祸，會顯得更為優(yōu)雅慈格，靈活性也會更強(qiáng)。

二遥金、巴斯-科德范式與第四浴捆、五范式

? ?第一階段中，簡單了解了庫表設(shè)計時最基本的三大范式稿械，但除此之外還有另外三種設(shè)計范式选泻，即巴斯-科德范式與第四、第五范式，這后續(xù)三種范式可能有很多小伙伴沒接觸過页眯，但當(dāng)你嘗試從網(wǎng)上去了解時梯捕，相信絕大部分能看到的資料你都看不懂，例如：
[圖片上傳失敗...(image-437eda-1670572692821)]
觀察上圖中的描述窝撵，這一眼望過去幾乎不是給人看的（沒有詆毀的意思傀顾，單純感慨~），其中涉及的碼碌奉、完全函數(shù)依賴等名詞短曾，至少剛接觸的小白是讀不懂的，因此接下來則依舊采用上面那種案例+大白話的模式道批，簡單闡述一下這三種設(shè)計范式错英。

2.1、巴斯-科德范式（BCNF）

? ?在了解后續(xù)這些范式之前隆豹，首先得弄明白一個概念椭岩，一般在一張表中，可以用于區(qū)分每行數(shù)據(jù)的一個列璃赡，通常會被咱們設(shè)為主鍵判哥，例如常用的ID字段就是如此，這類主鍵通常被稱為單一主鍵碉考，即一個列組成的主鍵塌计。但除此之外，還有一個聯(lián)合主鍵的概念侯谁，也就是由多個列組成的主鍵锌仅，相信這點(diǎn)大家在學(xué)習(xí)數(shù)據(jù)庫的時候也接觸過。

? ?巴斯-科德范式也被稱為3.5NF墙贱，至于為何不稱為第四范式热芹，這主要是由于它是第三范式的補(bǔ)充版，第三范式的要求是：任何非主鍵字段不能與其他非主鍵字段間存在依賴關(guān)系惨撇，也就是要求每個非主鍵字段之間要具備獨(dú)立性伊脓。而巴斯-科德范式在第三范式的基礎(chǔ)上，進(jìn)一步要求：任何主屬性不能對其他主鍵子集存在依賴魁衙。

對于上述的范式定義大家估計有些暈报腔，那用大白話說簡單一點(diǎn)，也就是規(guī)定了聯(lián)合主鍵中的某列值剖淀，不能與聯(lián)合主鍵中的其他列存在依賴關(guān)系纯蛾，相信這樣講大家更加容易理解。當(dāng)然纵隔，還是結(jié)合一個案例闡述翻诉。

先來看一張表：

+-------------------+---------------+--------+------+--------+
| classes           | class_adviser | name   | sex  | height |
+-------------------+---------------+--------+------+--------+
| 計算機(jī)-2201班     | 熊竹老師      | 竹子   | 男   | 185cm  |
| 金融-2201班       | 竹熊老師      | 熊貓   | 女   | 170cm  |
| 計算機(jī)-2201班     | 熊竹老師      | 子竹   | 男   | 180cm  |
+-------------------+---------------+--------+------+--------+

例如這張學(xué)生表帆卓，此時假設(shè)以classes班級字段、class_adviser班主任字段米丘、name學(xué)生姓名字段，組合成一個聯(lián)合主鍵糊啡，在這里我們可以通過聯(lián)合主鍵拄查，確定學(xué)生表中任何一個學(xué)生的信息，比如：

熊竹老師管的計算機(jī)-2201班棚蓄，哪個竹子同學(xué)有多高岸榉觥？
對于這個問題梭依，可以通過上述的聯(lián)合主鍵精準(zhǔn)定位到表中第一條數(shù)據(jù)稍算，并且最終能夠給出答案為185cm。

當(dāng)然役拴，在這里有小伙伴有疑惑糊探，為什么這三個字段可以組成聯(lián)合主鍵，和其他字段河闰，例如身高科平、性別就不行呢？因為主鍵一般都是用于區(qū)分不同行數(shù)據(jù)的姜性，必須要確保唯一性瞪慧，假設(shè)以「班級、班主任部念、性別」三個字段作為聯(lián)合主鍵弃酌，此時能通過這個聯(lián)合主鍵精準(zhǔn)定位到每一條數(shù)據(jù)嗎？答案是NO儡炼，上個例子理解：

熊竹老師管的計算機(jī)-2201班妓湘，哪個男同學(xué)有多高啊射赛？

現(xiàn)在以這個聯(lián)合主鍵還能精準(zhǔn)定位到每一條數(shù)據(jù)嗎多柑？不行的，因為表中有兩位男同學(xué)楣责，所以會掃描到多條數(shù)據(jù)竣灌，最終會得到185cm、180cm兩個答案秆麸，顯然「班級初嘹、班主任、性別」這三個字段具備重復(fù)性沮趣，不適合作為主鍵屯烦。

到這里，咱們分析一下，假設(shè)以「班級驻龟、班主任温眉、學(xué)生姓名」三個字段組成聯(lián)合主鍵，當(dāng)前這張表是否符合前面的三大范式呢翁狐？

• 第一范式：表中每列數(shù)據(jù)都不可再分类溢，具備原子性，滿足露懒。
• 第二范式：表中每行數(shù)據(jù)都僅描述了學(xué)生信息這一種業(yè)務(wù)屬性闯冷，具備唯一性，滿足懈词。
• 第三范式：除主鍵外蛇耀，表中非主鍵字段之間都不存在依賴關(guān)系，具備獨(dú)立性坎弯，滿足纺涤。

經(jīng)過上述分析后，當(dāng)前這張表也符合前面聊到的三大范式抠忘，但沒有問題了嗎洒琢？有的，在這張表中褐桌，一條學(xué)生信息中的班主任衰抑，取決于學(xué)生所在的班級，比如「竹子同學(xué)荧嵌、子竹同學(xué)」在「計算機(jī)-2201班」呛踊，所以它們的班主任都是「熊竹老師」，因此班主任字段其實也依賴于班級字段啦撮。那會造成什么問題呢谭网？

• ①當(dāng)一個班級的班主任老師換人后，需要同時修改學(xué)生表中的多條數(shù)據(jù)赃春。
• ②當(dāng)一個班主任老師離職后愉择，需要刪除該老師的記錄，會同時刪除多條學(xué)生信息织中。
• ③想要增加一個班級時锥涕，同時必須添加學(xué)生姓名數(shù)據(jù)，因為主鍵不允許為空狭吼。

通過上述分析可以明顯得知层坠，如果聯(lián)合主鍵中的一個字段依賴于另一個字段，同樣也會造成不小的問題刁笙，使得整張表的維護(hù)性變差破花，因此這里需要進(jìn)一步調(diào)整結(jié)構(gòu)：

SELECT * FROM `zz_classes`;
+------------+-------------------+---------------+
| classes_id | classes_name      | class_adviser |
+------------+-------------------+---------------+
|          1 | 計算機(jī)-2201班     | 熊竹老師      |
|          2 | 金融-2201班       | 竹熊老師      |
+------------+-------------------+---------------+

SELECT * FROM `zz_student`;
+------------+--------+------+--------+
| classes_id | name   | sex  | height |
+------------+--------+------+--------+
|          1 | 竹子   | 男   | 185cm  |
|          2 | 熊貓   | 女   | 170cm  |
|          1 | 子竹   | 男   | 180cm  |
+------------+--------+------+--------+

經(jīng)過結(jié)構(gòu)調(diào)整后谦趣，原本的學(xué)生表則又被拆為了班級表、學(xué)生表兩張座每，在學(xué)生表中只存儲班級ID前鹅，然后使用classes_id班級ID和name學(xué)生姓名兩個字段作為聯(lián)合主鍵。

實際情況中峭梳，學(xué)生表應(yīng)該有學(xué)生ID字段作為主鍵嫡纠，因為同一個班級中也有可能會出現(xiàn)重名的現(xiàn)象，但這里是為了舉例說明延赌，不要糾結(jié)細(xì)節(jié)~

此時經(jīng)過調(diào)整后，目前的學(xué)生表也滿足了巴斯-科德范式叉橱，同時對于前面列出的三個問題傻寂，調(diào)整結(jié)構(gòu)后也不復(fù)存在富稻，比如換班主任后只需要更改班級表，無需修改學(xué)生表中的學(xué)生信息；增加班級時到千，只需要在班級表中新增數(shù)據(jù)，也不會影響學(xué)生表井誉。

在這里更專業(yè)的做法贡歧，應(yīng)該是對于班級表中的班主任老師信息，再進(jìn)一步抽象出一張教師表探膊。畢竟班主任字段還依舊與班級字段存在依賴關(guān)系杠愧，但班級表中的主鍵卻是班級ID，所以非主鍵字段之間存在關(guān)聯(lián)逞壁，是不滿足第三范式的（但這里大家清楚就好啦流济，我就不做了！）腌闯。

OK绳瘟，經(jīng)過上述一個案例的剖析后，大家對巴斯-科德范式也有了全面的認(rèn)知姿骏，至于它為何被叫做3.5范式糖声，相信大家也能夠想清楚答案，因為巴斯-科德范式并沒有定義新的設(shè)計規(guī)范分瘦，僅是對第三范式的做了補(bǔ)充及完善蘸泻，修正了第三范式。

第三范式只要求非主鍵字段之間嘲玫，不能存在依賴關(guān)系蟋恬，但沒要求聯(lián)合主鍵中的字段不能存在依賴，因此第三范式并未考慮完善趁冈，巴斯-科德范式修正的就是這點(diǎn)歼争。

2.2拜马、第四范式（4NF）

? ?認(rèn)識了巴斯-科德范式后，再來看看數(shù)據(jù)庫的第四范式沐绒，第四范式是基于BC范式之上的俩莽，但在理解第四范式之前，首先得理解“多值依賴”的概念乔遮，先貼一下學(xué)術(shù)論文中常見的定義：
[圖片上傳失敗...(image-fbeca0-1670572692821)]

論文來源于：《道客巴巴-多值依賴》扮超，大部分網(wǎng)上資料的描述也都來自于這些學(xué)術(shù)論文。

能看明白嘛蹋肮？看不明白就對了出刷，對于這種概念看起來確實令人頭大，沒有相關(guān)的技術(shù)知識儲備坯辩，就算撓破頭皮也看不懂這段描述馁龟，因此簡單說一下什么叫做多值依賴：

一個表中至少需要有三個獨(dú)立的字段才會出現(xiàn)多值依賴問題，多值依賴是指表中的字段之間存在一對多的關(guān)系漆魔，也就是一個字段的具體值會由多個字段來決定坷檩。

這樣寫出來似乎比前面好理解一些了，但相對來說還是很繞改抡，那就再上個例子：

SELECT * FROM `zz_user_role_permission`;
+-----------+----------+-------+------------+
| user_name | user_sex | role  | permission |
+-----------+----------+-------+------------+
| 竹子      | 男       | ROOT  | *          |
| 熊貓      | 女       | ADMIN | BACKSTAGE  |
| 竹子      | 男       | ADMIN | BACKSTAGE  |
| 熊貓      | 女       | USER  | LOGIN      |
| 竹子      | 男       | USER  | LOGIN      |
| 子竹      | 男       | USER  | LOGIN      |
+-----------+----------+-------+------------+

上述是一個經(jīng)典的業(yè)務(wù)矢炼，也就是一張用戶角色權(quán)限表，先簡單介紹一下表中各字段的信息：

• user_name字段 -- 用戶名
• role字段 -- 角色信息：
  • USER：普通用戶角色阿纤。
  • ADMIN：管理員角色句灌。
  • ROOT：超級管理員角色。
• permission字段 -- 權(quán)限信息：
  • *：超級管理員擁有的權(quán)限級別欠拾，*表示所有涯塔。
  • BACKSTAGE：管理員擁有的權(quán)限級別，表示可以操作后臺清蚀。
  • LOGIN：普通用戶擁有的權(quán)限級別匕荸，表示可以登錄訪問平臺。

理解各字段的值后枷邪，假設(shè)以「用戶名榛搔、角色、權(quán)限」三個字段作為聯(lián)合主鍵东揣，先來分析一下這張表是否滿足之前的范式：

• 表中每列數(shù)據(jù)都不可再分践惑，具備原子性，滿足第一范式嘶卧。
• 表中數(shù)據(jù)都僅描述了用戶權(quán)限這一種業(yè)務(wù)屬性尔觉，具備唯一性，滿足第二范式芥吟。
• 除主鍵外侦铜，表中其他字段不存在依賴關(guān)系专甩，具備獨(dú)立性，滿足第三范式钉稍。
• 聯(lián)合主鍵中的用戶涤躲、角色、權(quán)限都為獨(dú)立字段贡未，不存在依賴性种樱，滿足BC范式。

因為表中除開聯(lián)合主鍵外俊卤，就剩下了一個性別字段嫩挤，因此非主鍵字段必然是獨(dú)立的，所以滿足第三范式消恍，但對于BC范式僅是勉強(qiáng)滿足岂昭，因為「用戶、角色哺哼、權(quán)限」之間存在一些依賴關(guān)系，不過這里先不管叼风，畢竟是舉例說明取董，因此假設(shè)是滿足BC范式。

上述的表結(jié)構(gòu)介紹清楚后无宿，現(xiàn)在來聊聊什么叫做多值依賴茵汰。

此時假設(shè)我們需要新增一條數(shù)據(jù)，那表中的權(quán)限字段究竟填什么孽鸡？這個值是需要依賴多個字段決定的蹂午，權(quán)限來自于角色，而角色則來自于用戶彬碱。也就是說豆胸，一個用戶可以擁有多個角色，同時一個角色可以擁有多個權(quán)限巷疼，所以此時咱們無法單獨(dú)根據(jù)用戶名去確定權(quán)限值晚胡，權(quán)限值必須依賴用戶、角色兩個字段來決定嚼沿，這種一個字段的值取決于多個字段才能確定的情況估盘，就被稱為多值依賴。

到這里是不是就理解了多值依賴骡尽？再舉個例子遣妥，也就是網(wǎng)上經(jīng)典的例子。

SELECT * FROM `zz_course_scheduling`;
+--------+------------+--------------+---------------------------+
| course |   classes  | teacher      | book                      |
+--------+------------+--------------+---------------------------+
| 語文   | 計算機(jī)一班 | 竹熊老師     | 人教版-新課標(biāo)教材         |
| 語文   | 計算機(jī)二班 | 黑竹老師     | 人教版-現(xiàn)行教材           |
| 語文   | 計算機(jī)三班 | 竹熊老師     | 北師大版教材              |
| 數(shù)學(xué)   | 計算機(jī)一班 | 熊竹老師     | 人教版-新課標(biāo)教材         |
| 英語   | 計算機(jī)一班 | 黑熊老師     | 人教版-新課標(biāo)教材         |
+--------+------------+--------------+---------------------------+

上述是一張教師排課表攀细，分別有課程箫踩、班級爱态、老師、教材四個字段班套，一個課程會有多位老師授課肢藐，同時一個課程也會有多個版本的教材，此時就無法只根據(jù)課程吱韭、班級吆豹、老師任一字段決定教材字段的值，而是要結(jié)合班級理盆、課程痘煤、老師三個字段，才能確定教材字段的值猿规，比如計算機(jī)一班的語文課程衷快，竹熊老師來上，用的是人教版-新課標(biāo)教材姨俩，因此目前教材字段也存在多值依賴的問題蘸拔，依賴于班級、課程环葵、老師三個字段调窍。

再經(jīng)過一個案例的熏陶后，是不是對多值依賴的概念理解更深刻啦~

到這里為止张遭，多值依賴的概念就講清楚了邓萨，也正是由于多值依賴的情況出現(xiàn)，又會導(dǎo)致表中出現(xiàn)時數(shù)據(jù)冗余菊卷、新增缔恳、刪除異常等問題出現(xiàn)。

因此第四范式的定義就是要消除表中的多值依賴關(guān)系洁闰。怎么做呢歉甚？拿前面的權(quán)限表舉例。

SELECT * FROM `zz_users`;
+---------+-----------+----------+----------+---------------------+
| user_id | user_name | user_sex | password | register_time       |
+---------+-----------+----------+----------+---------------------+
|       1 | 熊貓      | 女       | 6666     | 2022-08-14 15:22:01 |
|       2 | 竹子      | 男       | 1234     | 2022-09-14 16:17:44 |
|       3 | 子竹      | 男       | 4321     | 2022-09-16 07:42:21 |
+---------+-----------+----------+----------+---------------------+

SELECT * FROM `zz_roles`;
+---------+-----------+---------------------+
| role_id | role_name | created_time        |
+---------+-----------+---------------------+
|       1 | ROOT      | 2022-08-14 15:12:00 |
|       2 | ADMIN     | 2022-08-14 15:12:00 |
|       3 | USER      | 2022-08-14 15:12:00 |
+---------+-----------+---------------------+

SELECT * FROM `zz_permissions`;
+---------------+-----------------+---------------------+
| permission_id | permission_name | created_time        |
+---------------+-----------------+---------------------+
|             1 | *               | 2022-08-14 15:12:00 |
|             2 | BACKSTAGE       | 2022-08-14 15:12:00 |
|             3 | LOGIN           | 2022-08-14 15:12:00 |
+---------------+-----------------+---------------------+

SELECT * FROM `zz_users_roles`;
+----+---------+---------+
| id | user_id | role_id |
+----+---------+---------+
|  1 |       1 |       1 |
|  2 |       1 |       2 |
|  3 |       1 |       3 |
|  4 |       2 |       2 |
|  5 |       2 |       3 |
|  6 |       3 |       3 |
+----+---------+---------+

SELECT * FROM `zz_roles_permissions`;
+----+---------+---------------+
| id | role_id | permission_id |
+----+---------+---------------+
|  1 |       1 |             1 |
|  2 |       2 |             2 |
|  3 |       3 |             3 |
+----+---------+---------------+

觀察上述的五張表扑眉，如果有做過權(quán)限設(shè)計铃芦，或用過Shiro框架的小伙伴應(yīng)該會感到額外的親切，這個正是大名鼎鼎的權(quán)限五表襟雷，將原本的用戶角色權(quán)限表刃滓，拆分成了用戶表、角色表耸弄、權(quán)限表咧虎、用戶角色關(guān)系表、角色權(quán)限關(guān)系表计呈。經(jīng)過這次拆分之后砰诵，一方面用戶表征唬、角色表、權(quán)限表中都不會有數(shù)據(jù)冗余茁彭，第二方面無論是要刪除亦或新增一個角色总寒、權(quán)限時，都不會影響其他表理肺。

后面的兩張關(guān)系表摄闸，主要是為了維護(hù)用戶、角色妹萨、權(quán)限三者之間的關(guān)系年枕。

對于前面的教師排課表，就不再拆分啦乎完，大家如若想要鍛煉一下掌握程度熏兄，可自行將其拆分成符合第四范式的表結(jié)構(gòu)。

2.3树姨、第五范式（5NF）/完美范式

? ?了解了第四范式后摩桶，再來看看第五范式，這個范式也被稱為完美范式帽揪，先來說一下第五范式的定義：建立在4NF的基礎(chǔ)上硝清，進(jìn)一步消除表中的連接依賴，直到表中的連接依賴都是主鍵所蘊(yùn)含的台丛。等等耍缴，連接依賴又是個啥砾肺？
[圖片上傳失敗...(image-8c2edc-1670572692821)]

看不懂對不挽霉？說實話我也看著迷糊，大概能確定的是：多值依賴也屬于連接依賴的一種变汪，而連接依賴也包含了多值依賴侠坎，大家可以參考一下《這個》。

第五范式解決的是無損連接問題裙盾，但對于第五范式我自個兒也沒理解透徹实胸，因此不再講解第五范式了，防止誤導(dǎo)諸位番官，同時如若有對這塊十分了解的大佬庐完，可以留言指點(diǎn)一下。

2.4徘熔、六大范式小結(jié)

? ?經(jīng)過一系列的闡述后门躯，其實不難發(fā)現(xiàn)，越到后面的范式酷师，越難令人理解讶凉，同時為了讓表滿足更高級別的范式染乌，越往后付出代價也越大，而且拆分出的表數(shù)量也會越多懂讯，所以一般實際開發(fā)中荷憋，對于庫表的設(shè)計最高滿足BC范式即可，再往后就沒意義了褐望，因為表數(shù)量一多勒庄，查詢也好，寫入也罷譬挚，性能會越來越差锅铅。

同時，由于后面的幾種范式在實際項目中應(yīng)用較少减宣，因此關(guān)于這塊的資料也會較少盐须，后續(xù)的幾種范式也僅有一些學(xué)術(shù)機(jī)構(gòu)在琢磨，所以當(dāng)我們試圖去窺探時漆腌，能看到的也是一堆學(xué)術(shù)詞匯贼邓。

除開聊到的六大范式外，還有一種范式名為域鍵范式闷尿，也被稱之為終極范式塑径，但目前也僅有學(xué)術(shù)機(jī)構(gòu)在研究，在生產(chǎn)環(huán)境中實際的用途也不大填具，諸位有興趣可以自己看看统舀，最后再上一個各范式之間的遞進(jìn)關(guān)系圖：
[圖片上傳失敗...(image-f18359-1670572692821)]

• 第一范式：原子性，每個字段的值不能再分劳景。
• 第二范式：唯一性誉简，表內(nèi)每行數(shù)據(jù)必須描述同一業(yè)務(wù)屬性的數(shù)據(jù)。
• 第三范式：獨(dú)立性盟广，表中每個非主鍵字段之間不能存在依賴性闷串。
• 巴斯范式：主鍵字段獨(dú)立性，聯(lián)合主鍵字段之間不能存在依賴性筋量。
• 第四范式：表中字段不能存在多值依賴關(guān)系烹吵。
• 第五范式：表中字段的數(shù)據(jù)之間不能存在連接依賴關(guān)系。
• 域鍵范式：試圖研究出一個庫表設(shè)計時的終極完美范式桨武。

三肋拔、數(shù)據(jù)庫反范式設(shè)計

? ?遵循數(shù)據(jù)庫范式設(shè)計的結(jié)構(gòu)優(yōu)點(diǎn)很明顯，它避免了大量的數(shù)據(jù)冗余呀酸，節(jié)省了大量存儲空間凉蜂，同時讓整體結(jié)構(gòu)更為優(yōu)雅，能讓SQL操作更加便捷且減少出錯。但隨著范式的級別越高跃惫，設(shè)計出的結(jié)構(gòu)會更加精細(xì)化叮叹，原本一張表的數(shù)據(jù)會被分?jǐn)偟蕉鄰埍碇写鎯Γ淼臄?shù)量隨之越來越多爆存。

? ?但隨之而來的不僅僅只有好處蛉顽，也存在一個致命問題，也就是當(dāng)同時需要這些數(shù)據(jù)時先较，只能采用聯(lián)表查詢的形式檢索數(shù)據(jù)携冤，有時候甚至為了一個字段的數(shù)據(jù)，也需要做一次連表查詢才能獲得闲勺。這其中的開銷無疑是花費(fèi)巨大的曾棕，尤其是當(dāng)連接的表不僅兩三張而是很多張時，有可能還會造成索引失效菜循，這種情況帶來的資源翘地、時間開銷簡直是一個噩夢，這會嚴(yán)重地影響整個業(yè)務(wù)系統(tǒng)的性能癌幕。

因此衙耕，也正是由于上述一些問題，在設(shè)計庫表結(jié)構(gòu)時勺远，我們不一定要100%遵守范式準(zhǔn)則橙喘。這種違反數(shù)據(jù)庫范式的設(shè)計方法，就被稱之為 反范式設(shè)計胶逢。

? ?遵循范式設(shè)計也好厅瞎，反范式設(shè)計也罷，本身兩者之間并沒有優(yōu)劣之分初坠，只要能夠?qū)I(yè)務(wù)更有利和簸，那就可以稱之為好的設(shè)計方案。范式的目的僅在于讓我們設(shè)計的結(jié)構(gòu)更優(yōu)雅合理某筐，有時候在表中多增加一個字段比搭，從數(shù)據(jù)庫的角度來看冠跷，數(shù)據(jù)會存在冗余問題南誊，會讓表結(jié)構(gòu)違反范式的定義，但如若能夠在實際情況中減少大量的連表查詢蜜托，這種設(shè)計自然也是可取的抄囚。

也就是說，在設(shè)計時千萬不要拘泥于規(guī)則之內(nèi)橄务，一定要結(jié)合實際業(yè)務(wù)考慮幔托，遵循業(yè)務(wù)優(yōu)先的原則去設(shè)計結(jié)構(gòu)。

當(dāng)然，對于反范式設(shè)計也無需再用更多的語言去描述了重挑，因為本質(zhì)上就是一個概念詞嗓化，也就是不遵循數(shù)據(jù)庫范式設(shè)計的結(jié)構(gòu)，就被稱為反范式結(jié)構(gòu)谬哀。不過要牢記的一點(diǎn)是：不是所有不遵循數(shù)據(jù)庫范式的結(jié)構(gòu)設(shè)計都被稱為反范式刺覆，反范式設(shè)計是指自己知道會破壞范式，但對業(yè)務(wù)帶來好處大于壞處時史煎，刻意設(shè)計出破壞范式的結(jié)構(gòu)谦屑。

隨意設(shè)計出的結(jié)構(gòu)，不滿足范式要求篇梭，同時還無法給業(yè)務(wù)上帶來收益的氢橙，這并不被稱為反范式設(shè)計，反范式設(shè)計是一種刻意為之的思想恬偷。

四悍手、庫表設(shè)計篇總結(jié)

? ?在本篇中詳細(xì)闡述了DB庫表設(shè)計時的一些思想，也就是范式與反范式設(shè)計理論袍患，這些理論僅僅只是一套方法論谓苟，實際開發(fā)過程中，還是需要根據(jù)業(yè)務(wù)來設(shè)計出最合適的結(jié)構(gòu)协怒。在文中提及了六種范式涝焙，但一般項目中僅需滿足到第三范式或BC范式即可，因為這個度剛剛好孕暇，再往后就會因為過于精細(xì)化設(shè)計仑撞，導(dǎo)致整體性能反而下降⊙希控制到第三范式的級別隧哮，一方面數(shù)據(jù)不會有太多冗余，第二方面也不會對性能影響過大座舍。

同時沮翔，如若打破范式的設(shè)定能對業(yè)務(wù)更有利，那也可以違背范式原則去設(shè)計曲秉。

? ?不過雖說這些屬于方法論采蚀，但認(rèn)真看下來之后，相信諸位在之后設(shè)計庫表結(jié)構(gòu)應(yīng)該會潛意識的遵循一些范式原則承二，也會盡量的將表結(jié)構(gòu)設(shè)計的更為優(yōu)雅榆鼠，從而也能讓咱們在開發(fā)過程中，減少調(diào)整庫表結(jié)構(gòu)的次數(shù)和帶來的影響亥鸠。

一般而言妆够，庫表結(jié)構(gòu)設(shè)計的是否合理识啦，區(qū)別如下：

• 不合理的結(jié)構(gòu)設(shè)計會造成的問題：
  • 數(shù)據(jù)冗余，會浪費(fèi)一定程度上的存儲空間
  • 不便于常規(guī)SQL操作（例如插入神妹、刪除）颓哮，甚至?xí)霈F(xiàn)異常
• 合理的結(jié)構(gòu)設(shè)計帶來的好處：
  • 節(jié)省空間，SQL執(zhí)行時能節(jié)省內(nèi)存空間鸵荠，數(shù)據(jù)存儲時能節(jié)省磁盤空間
  • 數(shù)據(jù)劃分較為合理题翻，DB性能整體較高，并且數(shù)據(jù)也非常完整
  • 結(jié)構(gòu)便于維護(hù)和進(jìn)行常規(guī)SQL操作