關系型資料庫設計三大范式-有解無憂

作者：鄭龍飛

范式定義

百度百科:設計關系資料庫時，遵從不同的規范要求，設計出合理的關系型資料庫，這些不同的規范要求被稱為不同的范式，各種范式呈遞次規范，越高的范式資料庫冗余越小，

人類語言: 范式可以理解為設計一張資料表的表結構，符合的標準級別、規范和要求，

而通常我們用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要講的“三大范式”，

范式的優點

采用范式可以降低資料的冗余性，

為什么要降低資料的冗余性？

十幾年前，磁盤很貴，為了減少磁盤存盤，
以前沒有分布式系統，都是單機，只能增加磁盤，磁盤個數也是有限的，
一次修改，需要修改多個表，很難保證資料一致性，

范式的缺點

范式的缺點是獲取資料時，需要通過Join拼接出最后的資料，

目前范式的分類

目前業界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)，

什么是函式依賴？

百度百科:函式依賴簡單點說就是：某個屬性集決定另一個屬性集時，稱另一屬性集依賴于該屬性集，

人類語言:以下面表格為例，通俗易懂的解釋，什么是函式依賴，

學號	姓名	系名	系主任	科名	分數
001	張三	計算機系	李雷	高等數學	87
001	張三	計算機系	李雷	大學英語	88
001	張三	計算機系	李雷	資料庫設計	89
002	李四	計算機系	李雷	高等數學	86
002	李四	計算機系	李雷	java程式設計	90
002	李四	計算機系	李雷	大學英語	98
003	王五	財務系	韓梅梅	高等數學	96
003	王五	財務系	韓梅梅	財務基礎	95

完全函式依賴

官方定義:設X，Y是關系R的兩個屬性集合，X’是X的真子集，存在X→Y，但對每一個X’都有X’!→Y，則稱Y完全函式依賴于X，

人類語言:比如通過，(學號，課程) 推出分數，但是單獨用學號推斷不出來分數，那么就可以說：分數完全依賴于(學號，課程) ，

總結:即：通過A B能得出C，但是A B單獨得不出C，那么說C完全依賴于AB，

部分函式依賴

官方定義:假如 Y函式依賴于 X，但同時 Y 并不完全函式依賴于 X，那么我們就稱 Y 部分函式依賴于 X，

人類語言:比如通過，(學號，課程) 推出姓名，因為其實直接可以通過，學號推出姓名，所以：姓名部分依賴于 (學號，課程)，

總結:通過AB能得出C，通過A也能得出C，或者通過B也能得出C，那么說C部分依賴于AB，

傳遞函式依賴

官方定義:傳遞函式依賴：設X，Y，Z是關系R中互不相同的屬性集合，存在X→Y(Y !→X),Y→Z，則稱Z傳遞函式依賴于X，

人類語言:比如：學號推出系名，系名推出系主任，但是，系主任推不出學號，系主任主要依賴于系名，這種情況可以說：系主任傳遞依賴于學號，

總結:即：通過A得到B，通過B得到C，但是C得不到A，那么說C傳遞依賴于A，

三范式的區別

第一范式

第一范式1NF核心原則：屬性不可切割，

舉例說明:

學號	姓名	系名	系主任	科名	分數	學籍資訊
001	張三	計算機系	李雷	高等數學	87	本科，大二
002	李四	計算機系	李雷	大學英語	88	研究生,研三

很明顯上面表格設計是不符合第一范式的，學籍資訊列中的資料不是原子資料項，是可以進行分割的，因此對表格進行修改，讓表格符合第一范式的要求，修改結果如下圖所示：

學號	姓名	系名	系主任	科名	分數	學歷	所在年級
001	張三	計算機系	李雷	高等數學	87	本科	大二
002	李四	計算機系	李雷	大學英語	88	研究生	研三

實際上，1NF是所有關系型資料庫的最基本要求 ,你在關系型資料庫管理系統（RDBMS），例如SQL Server，Oracle，MySQL中創建資料表的時候，如果資料表的設計不符合這個最基本的要求，那么操作一定是不能成功的，也就是說，只要在RDBMS中已經存在
的資料表，一定是符合1NF的，

第二范式

第二范式2NF核心原則：不能存在“部分函式依賴”，

舉例說明:

學號	姓名	系名	系主任	科名	分數
001	張三	計算機系	李雷	高等數學	87
001	張三	計算機系	李雷	大學英語	88
001	張三	計算機系	李雷	資料庫設計	89
002	李四	計算機系	李雷	高等數學	86
002	李四	計算機系	李雷	java程式設計	90
002	李四	計算機系	李雷	大學英語	98
003	王五	財務系	韓梅梅	高等數學	96
003	王五	財務系	韓梅梅	財務基礎	95

以上表格明顯存在，部分依賴，比如，這張表的主鍵是 (學號，課名），分數確實完全依賴于(學號，課名），但是姓名并不完全依賴于(學號，課名）,讓表格符合第二范式的要求，修改結果如下圖所示：

學號	科名	分數
001	高等數學	87
001	大學英語	88
001	資料庫設計	89
002	高等數學	86
002	java程式設計	90
002	大學英語	98
003	高等數學	96
003	財務基礎	95

學號	姓名	系名	系主任
001	張三	計算機系	李雷
002	李四	計算機系	李雷
003	王五	財務系	韓梅梅

以上符合第二范式，去掉部分函式依賴依賴，

第三范式

第三范式 3NF核心原則：不能存在傳遞函式依賴，

舉例說明:

學號	姓名	系名	系主任
001	張三	計算機系	李雷
002	李四	計算機系	李雷
003	王五	財務系	韓梅梅

在上面這張表中，存在傳遞函式依賴：學號->系名->系主任，但是系主任推不出學號，

上面表需要再次拆解：

學號	姓名	系名
001	張三	計算機系
002	李四	計算機系
003	王五	財務系

系名	系主任
計算機系	李雷
計算機系	李雷
財務系	韓梅梅

反三范式

沒有冗余的資料庫未必是最好的資料庫，有時為了提高運行效率，就必須降低范式標準，適當保留冗余資料，具體做法是：在概念資料模型設計時遵守第三范式，降低范式標準的作業放到物理資料模型設計時考慮，降低范式就是增加欄位，減少了查詢時的關聯，提高查詢效率，因為在資料庫的操作中查詢的比例要遠遠大于DML的比例，但是反范式化一定要適度，并且在原本已滿足三范式的基礎上再做調整的，

總結

參考知乎大佬對范式的理解:

資料庫設計應該也是分為三個境界的：

第一個境界，剛入門資料庫設計，范式的重要性還未深刻理解，這時候出現的反范式設計，一般會出問題，

第二個境界，隨著遇到問題解決問題，漸漸了解到范式的真正好處，從而能快速設計出低冗余、高效率的資料庫，

第三個境界，再經過N年的鍛煉，是一定會發覺范式的局限性的，此時再去打破范式，設計更合理的反范式部分，

轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/540326.html

標籤：其它

上一篇：實踐丨GaussDB(DWS)資源管理排隊原理與問題定位

下一篇：MySQL中WHERE后跟著N多個OR條件會怎樣...