在上學的時候,資料庫之中就講過資料庫範式,現在突然想複習下,就上網查了下發現還是自己親自理一遍比較清晰
先引用百度百科中的一段話:
關聯式資料庫中的關係必須滿足一定的要求,即滿足不同的範式。
目前關聯式資料庫有六種範式:第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、第四範式(4NF)、第五範式(5NF)和第六範式(6NF)。滿足最低要求的範式是第一範式(1NF)。在第一範式的基礎上進一步滿足更多要求的稱為第二範式(2NF),其餘範式以次類推。一般說來,資料庫只需滿足第三範式(3NF)就行了。
好傢夥,竟然一共有6種範式- -汗,以前只知道第一第二第三範式,好吧,貌似一二三也足夠解決問題了,那也就從一二三開始吧:
第一範式(1NF)無重複的列
所謂第一範式(1NF)是指資料庫表的每一列都是不可分割的基本資料項目,同一列中不能有多個值,即實體中的某個屬性不能有多個值或者不能有重複的屬性。如果出現重複的屬性,就可能需要定義一個新的實體,新的實體由重複的屬性構成,新實體與原實體之間為一對多關聯性。在第一範式(1NF)中表的每一行只包含一個執行個體的資訊。簡而言之,第一範式就是無重複的列。
說明:在任何一個關聯式資料庫中,第一範式(1NF)是對關係模式的基本要求,不滿足第一範式(1NF)的資料庫就不是關聯式資料庫。
從上面這句話可以看出只要是能存進關係型資料庫的關係都算是滿足第一範式,比方說有個欄位是地址,網上很多人說這就不滿足資料庫第一範式,我覺得這是曲解了第一範式的原意,那究竟是什麼樣的情況下會違反這神奇的第一範式呢?
id |
name |
address |
1 |
Jim |
上海市虹口區XX號 |
2 |
Hanson |
北京市 |
朝陽區XX號 |
能把以上的表存入關係型資料庫中嗎?顯然不行,所以第一範式是防範以上情況的
第二範式(2NF)屬性
完全依賴於主鍵 [消除非主屬性對主碼的部分函數依賴]
第二範式(2NF)是在第一範式(1NF)的基礎上建立起來的,即滿足第二範式(2NF)必須先滿足第一範式(1NF)。
第二範式(2NF)要求實體的屬性完全依賴於主關鍵字。所謂完全依賴是指不能存在僅依賴主關鍵字一部分的屬性,如果存在,那麼這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體,新實體與原實體之間是一對多的關係。為實現區分通常需要為表加上一個列,以儲存各個執行個體的唯一標識。簡而言之,第二範式就是屬性完全依賴於主鍵。
從上面可以看出來如果你的表如果只有一個主鍵的話,那就一定滿足第二範式,因為不存在部分函數依賴的限制
假設有如下的實體表:
此中DepartmentDescription欄位只是依賴與DepartmentName欄位,跟EmployeeId欄位沒啥關係,所以違反了第二範式,那麼怎麼改呢?
第三範式(3NF)屬性
不依賴於其它非主屬性[消除傳遞依賴]
滿足第三範式(3NF)必須先滿足第二範式(2NF)。第三範式(3NF)要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。簡而言之,第三範式就是屬性不依賴於其它非主屬性。
在上面的Employee表中還有JobDescription依賴於Job欄位,所以不滿足第三範式,應作如下改變:
好了 資料庫三大範式大功告成。至於剩下的第四第五第六那都是浮雲……
說一下,範式的好處還是減少資料冗餘,並使結構更加清晰,以至於後期維護起來很容易,這我感覺是最重要的,因為如果你的資料庫設計得很爛的話,一些輕微的改動都沒法完成或付出很大的代價,那是很不值得的
至於到底要採用哪種範式,我覺得還是得看業務需求,如果比較嚴謹的系統,對資料要求比較高,那麼相應的提高範式的等級,但是如果是一些小系統,其實第二範式就可以了,沒必要非要追求高範式,因為企業還是得考慮成本等等因素,特別是如上面例子中僅僅是有一個欄位傳遞依賴,在不重要的情況下完全可以忽略。