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

一講到數據庫設計，大家很容易想到的就是三范式，但是第四、第五范式又是什么，不是很清楚，三范式到底怎么區分，也不清楚，作為數據庫設計的基礎概念，我再講解下數據庫范式。 Normal form Brief definition 1NF First normal form Table faithfully repres

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

第一范式 1NF First normal form

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

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

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

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

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

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

第二范式 2NF Second normal form

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

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

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

第三范式 3NF Third normal form

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

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

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

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

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com