大家好，我是張哲，是一位在互聯網上不愿透露姓名的小學員。

概念：

在設計數據庫的基礎上會存在各種各樣的問題，因此有些專門的設計規則來避免一些問題，這些設計規則被統稱為范式(NF)。

目前關系數據庫中有六大范式：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

下面我將會針對一張表用范式一層一層的分離

分類：

1、第一范式：保證數據是最小原子項。每一份數據都是不可在分的。

我們先看系這一項，很明顯，系可以繼續分兩項：系名和系主任。

此時我們會發現這么幾個問題：

數據冗余：學號、姓名、系名、系主任重復的數據太多，這就會帶來兩個影響：

浪費存儲空間。

更新異常：我們如果將張三豐修改為：張倆豐，則必須將所有的張三豐修改為張倆豐，一個字：麻煩。額，好像是兩個字哈哈

數據添加時存在問題：比如僅僅是新添加個系名和系主任，但正常情況下：學號、姓名是不為NULL的，所以就無法之添加系名和系主任會導致數據不合法。

數據刪除時存在問題：比如張無忌同學畢業了，把他的數據刪掉會導致系名、系主任、課程名稱都被刪掉。此操作不合理。

2、第二范式：在第一范式的基礎上令表中的數據完全依賴于主屬性。

這里我們要明白5個概念：

函數依賴：A --> B 通過A屬性(屬性組)的值可以確定B屬性的唯一的值

舉例：通過學號可以確定唯一的姓名，通過學號+課程名稱可以確定唯一的分數。

完全函數依賴：A --> B 通過A屬性組的所有值才可以確定B屬性的唯一的值

舉例：通過學號+課程名稱可以確定唯一的分數。

部分函數依賴：A --> B 通過A屬性組中的某些屬性值就可以確定B屬性的唯一的值

舉例：通過學號+課程名稱的學號就可以確定唯一的姓名。

傳遞函數依賴：A --> B ，B --> C 通過A屬性(屬性組)的值可以確定唯一的B屬性的值，再通過確定的B屬性的值可以確定唯一的C屬性的值。

舉例：通過學號可以確定唯一的系名，在通過系名可以確定唯一的系主任是誰。

碼：一張表中，某屬性(屬性組)的數據被其他列的數據完全依賴，則稱此屬性(屬性組)為候選碼，簡稱：碼，該表中的碼為：學號+課程名稱。

主屬性：碼中的所有屬性

非主屬性：除了碼中屬性組中的所有屬性。

關于第二范式百度的解釋：非碼屬性必須完全依賴于候選碼，實體的屬性完全依賴于主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性，如果存在，那么這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，新實體與原實體之間是一對多的關系。為實現區分通常需要為表加上一個列，以存儲各個實例的唯一標識。簡而言之，第二范式就是在第一范式的基礎上屬性完全依賴于主鍵。

分析：要做到非主屬性必須完全依賴于主屬性。此時表中主屬性為：學號+課程名稱。則分數是完全依賴于主屬性的，而姓名、系名、系主任是部分依賴于主屬性的，因此按著第二范式的規則要將姓名、系名、系主任分離出去。

按著第二范式的要求給它分離成兩張表：

我們再去回想一下之前第一范式遇到的問題：

數據冗余、數據添加時存在問題、數據刪除時存在問題。

我按著第二范式分離之后發現：數據已經冗余的負面問題了。但是當數據添加時比如：僅僅是添加一個系名和系主任還會有姓名必須不為NULL的不合法問題。當刪除數據時：張無忌畢業了，刪除它的數據則會連帶著系名跟系主任一同刪除。此操作還是不合理。

3、第三范式：在第二范式的基礎上更近一層，確保每個屬性和主屬性都直接相關，而不是間接相關。

分析：姓名和系名是直接相關的，系名和系主任是直接相關的，但是姓名和系主任是間接相關的。因此就有了第三張表。

此時繼續來看第二范式沒解決的添加數據和刪除數據的問題：添加數據時：添加系名和系主任此時不會在影響到學員的姓名，刪除數據時：張無忌畢業了，刪除它的數據時并不會將系名+系主任刪除。

總結：

第一范式是為了保證每個數據項都是不可分割的最小原子項。

第二范式是為了在第一范式的基礎上消除部分函數依賴。

第三范式是為了在第二范式的基礎上消除傳遞依賴。

數據庫設計時雖然有六大范式，但只要滿足前三個范式我們的數據庫設計就會非常的合理。

總結

以上是生活随笔為你收集整理的java三大范_Java深度学习系列——数据库的三大范式的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。