數據庫設計範式1——三範式

一講到數據庫設計，大家很容易想到的就是三範式，但是第四、第五範式又是什麼，不是很清楚，三範式到底怎麼區分，也不清楚，作爲數據庫設計的基礎概念，我再講解下數據庫範式。

	Normal form	Brief definition
1NF	First normal form	Table faithfully represents a relation, primarily meaning it has at least one candidate key
2NF	Second normal form	No non-prime attribute in the table is functionally dependent on a proper subset of any candidate key
3NF	Third normal form	Every non-prime attribute is non-transitively dependent on every candidate key in the table. The attributes that do not contribute to the description of the primary key are removed from the table. In other words, no transitive dependency is allowed.
EKNF	Elementary Key Normal Form	Every non-trivial functional dependency in the table is either the dependency of an elementary key attribute or a dependency on a superkey
BCNF	Boyce–Codd normal form	Every non-trivial functional dependency in the table is a dependency on a superkey
4NF	Fourth normal form	Every non-trivial multivalued dependency in the table is a dependency on a superkey
5NF	Fifth normal form	Every non-trivial join dependency in the table is implied by the superkeys of the table
DKNF	Domain/key normal form	Every constraint on the table is a logical consequence of the table's domain constraints and key constraints
6NF	Sixth normal form	Table features no non-trivial join dependencies at all (with reference to generalized join operator)

第一範式 1NF First normal form

簡單說來就是每個表都應該有主鍵（唯一標識每一行），每個字段應該是原子的不可再分的。

比如以下表不符合第一範式，因爲沒有主鍵，我們無法區分第一行和第三行數據。

Name	Gender	Contact	Interest
Neil	M	Email:[email protected],phone:[phone]	Reading;Guitar
Devin	M	Email:[email protected],phone:[phone]	Swimming
Neil	M	Email:[email protected],phone:[phone]	Reading;Guitar

爲了區分每一行數據，所以需要添加主鍵UserId，這樣就能區分出每一行數據來。

UserId	Name	Gender	Contact	Interest
1	Neil	M	Email:[email protected],phone:[phone]	Reading;Guitar
2	Devin	M	Email:[email protected],phone:[phone]	Swimming

但是這個表仍然不符合第一範式，應該Contact字段不是不可再分的，該字段可以分爲Email和Phone兩個字段，所以我們表變爲：

UserId	Name	Gender	Email	Phone	Interest
1	Neil	M	[email protected]	1222456	Reading;Guitar
2	Devin	M	[email protected]	13934563456	Swimming

這樣做以後我們的表仍然是不符合第一範式的，應該Interest字段不是原子的，裏面包含了一組數據，對於這個字段，就不能像Contact一樣拆分成兩個字段，應該Interest字段裏面包含的對象是一樣的，而且一個用戶可以有無數多個興趣愛好。所以我們需要將該字段單獨出來，形成新的表：

UserId	Name	Gender	Email	Phone
1	Neil	M	[email protected]	1222456
2	Devin	M	[email protected]	13934563456

 

UserId	Interest
1	Reading
1	Guitar
2	Swimming

現在這兩個表才滿足第一範式。

第二範式 2NF Second normal form

簡單說來就是在滿足第一範式的情況下，非主鍵屬性應該完全依賴於候選鍵（候選關鍵字、唯一標識每一行數據的鍵，一個表存在多個候選鍵），而不應該依賴於候選鍵的部分。

比如以下的學生選課表，主鍵是學號和課程號，非主鍵屬性是選課的時間，系統確認的時間，所選課程的名字。

StudentId	CourseId	ChooseTime	ConfirmTime	CourseName
1	10	2013/8/26	2013/8/27	微積分
1	11	2013/8/27	2013/8/27	線性代數
2	10	2013/8/26	2013/8/27	微積分

這個表滿足第一範式，因爲StudentId+CourseId能夠唯一的標識每一行數據，而且每個屬性都是原子的，不可再分的。選課時間和系統確認時間完全依賴於主鍵，沒有問題。課程名稱只依賴於CourseId，不依賴於StudentId，所以不滿足第二範式，需要將課程名稱獨立出來：

StudentId	CourseId	ChooseTime	ConfirmTime
1	10	2013/8/26	2013/8/27
1	11	2013/8/27	2013/8/27
2	10	2013/8/26	2013/8/27

 

CourseId	CourseName
10	微積分
11	線性代數

第三範式 3NF Third normal form

簡單來說就是滿足第二範式的情況下，非主鍵屬性應該完全依賴於候選鍵，不應該依賴於其他非候選鍵。

比如以下的學生表，主鍵是學號，非主鍵屬性爲學生姓名、所在院系Id，所在院系名。

StudentId	Name	DepartmentId	DepartmentName
1	Neil	21	Math
2	Devin	22	Computer

首先這個表滿足第二範式，因爲主鍵就一個字段，所有非主鍵屬性都依賴於StudentId。但是該表不滿足第三範式，因爲院系名稱是依賴於院系ID的，院系ID在這個表中是非主鍵，依賴於學生ID，也就是傳遞依賴。

以上說的是數據庫設計中最基本的三範式，大部分數據庫設計時，只需要滿足這三個範式即可。接下來我還會寫一篇博客講解下更高級的範式。