「資料庫」讓我給你講清楚關系型資料庫設計三大範式

範式定義

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

人類語言: 範式可以了解為設計一張資料表的表結構，符合的标準級别、規範和要求。

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

範式的優點

采用範式可以降低資料的備援性。

為什麼要降低資料的備援性？

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

範式的缺點

範式的缺點是擷取資料時，需要通過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://developer.jdcloud.com/article/2707