數據庫範式

數據庫範式:　

　 　設計關係數據庫時，聽從不一樣的規範要求，設計出合理的關係型數據庫，這些不一樣的規範要求被稱爲不一樣的範式，各類範式呈遞次規範，越高的範式數據庫冗餘越小。

　　目前關係數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。

 

範式簡介:　

　　設計關係數據庫時，聽從不一樣的規範要求，設計出合理的關係型數據庫，這些不一樣的規範要求被稱爲不一樣的範式，各類範式呈遞次規範，越高的範式數據庫冗餘越小。

　　目前關係數據庫有六種範式：第一範式（1NF）、第二範式（2NF）、第三範式（3NF）、巴斯-科德範式（BCNF）、第四範式(4NF）和第五範式（5NF，又稱完美範式）。知足最低要求的範式是第一範式（1NF）。在第一範式的基礎上進一步知足更多規範要求的稱爲第二範式（2NF），其他範式以次類推。通常說來，數據庫只需知足第三範式(3NF）就好了。

各種範式:

　　第一範式（1NF）

 

　　所謂第一範式（1NF）是指在關係模型中，對域添加的一個規範要求，全部的域都應該是原子性的，即數據庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。即實體中的某個屬性有多個值時，必須拆分爲不一樣的屬性。在符合第一範式（1NF）表中的每一個域值只能是實體的一個屬性或一個屬性的一部分。簡而言之，第一範式就是無重複的域。

　　說明：在任何一個關係數據庫中，第一範式（1NF）是對關係模式的設計基本要求，通常設計中都必須知足第一範式（1NF）。不過有些關係模型中突破了1NF的限制，這種稱爲非1NF的關係模型。換句話說，是否必須知足1NF的最低要求，主要依賴於所使用的關係模型。

 

　　第二範式（2NF）

 

　　在1NF的基礎上，非碼屬性必須徹底依賴於候選碼（在1NF基礎上消除非主屬性對主碼的部分函數依賴）

　　第二範式（2NF）是在第一範式（1NF）的基礎上創建起來的，即知足第二範式（2NF）必須先知足第一範式（1NF）。第二範式（2NF）要求數據庫表中的每一個實例或記錄必須能夠被惟一地區分。選取一個能區分每一個實體的屬性或屬性組，做爲實體的惟一標識。例如在員工表中的身份證號碼便可實現每一個一員工的區分，該身份證號碼即爲候選鍵，任何一個候選鍵均可以被選做主鍵。在找不到候選鍵時，可額外增長屬性以實現區分，若是在員工關係中，沒有對其身份證號進行存儲，而姓名可能會在數據庫運行的某個時間重複，沒法區分出實體時，設計闢如ID等不重複的編號以實現區分，被添加的編號或ID選做主鍵。（該主鍵的添加是在ER設計時添加，不是建庫時隨意添加）

　　第二範式（2NF）要求實體的屬性徹底依賴於主關鍵字。所謂徹底依賴是指不能存在僅依賴主關鍵字一部分的屬性，若是存在，那麼這個屬性和主關鍵字的這一部分應該分離出來造成一個新的實體，新實體與原實體之間是一對多的關係。爲實現區分一般須要爲表加上一個列，以存儲各個實例的惟一標識。簡而言之，第二範式就是在第一範式的基礎上屬性徹底依賴於主鍵。

 

 

　　第三範式（3NF）

 

　　在2NF基礎上，任何非主屬性不依賴於其它非主屬性（在2NF基礎上消除傳遞依賴）

　　第三範式（3NF）是第二範式（2NF）的一個子集，即知足第三範式（3NF）必須知足第二範式（2NF）。簡而言之，第三範式（3NF）要求一個關係中不包含已在其它關係已包含的非主關鍵字信息。例如，存在一個部門信息表，其中每一個部門有部門編號（dept_id）、部門名稱、部門簡介等信息。那麼在員工信息表中列出部門編號後就不能再將部門名稱、部門簡介等與部門有關的信息再加入員工信息表中。若是不存在部門信息表，則根據第三範式（3NF）也應該構建它，不然就會有大量的數據冗餘。簡而言之，第三範式就是屬性不依賴於其它非主屬性，也就是在知足2NF的基礎上，任何非主屬性不得傳遞依賴於主屬性。

 

 

　　巴斯-科德範式（BCNF）

 

　　Boyce-Codd Normal Form（巴斯-科德範式）

　　在3NF基礎上，任何非主屬性不能對主鍵子集依賴（在3NF基礎上消除對主碼子集的依賴）

　　巴斯-科德範式（BCNF）是第三範式（3NF）的一個子集，即知足巴斯-科德範式（BCNF）必須知足第三範式（3NF）。一般狀況下，巴斯-科德範式被認爲沒有新的設計規範加入，只是對第二範式與第三範式中設計規範要求更強，於是被認爲是修正第三範式，也就是說，它事實上是對第三範式的修正，使數據庫冗餘度更小。這也是BCNF不被稱爲第四範式的緣由。某些書上，根據範式要求的遞增性將其稱之爲第四範式是不規範，也是更讓人不容易理解的地方。而真正的第四範式，則是在設計規範中添加了對多值及依賴的要求。

　　定義：關係模式R<U,F>∈1FNF,若X→Y且Y不是X的子集時X必含有碼，則R<U,F>∈BCNF。也就是說，關係模式R<U,F>中，若每個決定因素都包含碼，則R<U,F>∈BCNF。

　　由BCNF的定義能夠獲得結論，一個知足BCNF的關係模式有：

　　　　-全部非主屬性對每個碼都是徹底函數依賴。

　　　　-全部主屬性對每個不包含它的碼也是徹底函數依賴。

　　　　-沒有任何屬性徹底函數依賴於非碼的任何一組屬性。

　　　　若R∈BCNF，按定義排除了任何屬性對碼的傳遞依賴與部分依賴，因此R∈3NF

　　　　通常關係型數據庫設計中，達到BCNF就能夠了！

 

範式應用實例:

　　下面以一個學校的學生系統爲例分析說明，這幾個範式的應用。

 

　　第一範式（1NF）

 

　　數據庫表中的字段都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。在當前的任何關係數據庫管理系統（DBMS）中，傻瓜也不可能作出不符合第一範式的數據庫，由於這些DBMS不容許你把數據庫表的一列再分紅二列或多列。所以，你想在現有的DBMS中設計出不符合第一範式的數據庫都是不可能的。

　　首先咱們肯定一下要設計的內容包括那些。學號、學生姓名、年齡、性別、課程名稱、課程學分、系別、學科成績，系辦地址、系辦電話等信息。爲了簡單咱們暫時只考慮這些字段信息。咱們對於這些信息，所關心的問題有以下幾個方面。

學生有那些基本信息？

　　學生選了那些課，成績是什麼？

　　每一個課的學分是多少？

　　學生屬於那個系，系的基本信息是什麼？

 

 

　　第二範式（2NF）

 

　　首先咱們考慮，把全部這些信息放到一個表中（學號，學生姓名、年齡、性別、課程、課程學分、系別、學科成績，系辦地址、系辦電話）下面存在以下的依賴關係。

　　(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)

　　問題分析

　　所以不知足第二範式的要求，會產生以下問題：

數據冗餘：同一門課程由n個學生選修，"學分"就重複n-1次；同一個學生選修了m門課程，姓名和年齡就重複了m-1次。

更新異常：

　　1）若調整了某門課程的學分，數據表中全部行的"學分"值都要更新，不然會出現同一門課程學分不一樣的狀況。

　　2）假設要開設一門新的課程，暫時尚未人選修。這樣，因爲尚未"學號"關鍵字，課程名稱和學分也沒法記錄入數據庫。

刪除異常 ：假設一批學生已經完成課程的選修，這些選修記錄就應該從數據庫表中刪除。可是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會致使插入異常。

　　解決方案

　　把選課關係表SelectCourse改成以下三個表：

學生：Student（學號，姓名，年齡，性別，系別，系辦地址、系辦電話）；

課程：Course（課程名稱,學分）；

選課關係：SelectCourse（學號，課程名稱，成績）。

 

 

　　第三範式（3NF）

 

　　接着看上面的學生表Student（學號，姓名，年齡，性別，系別，系辦地址、系辦電話），關鍵字爲單一關鍵字"學號"，由於存在以下決定關係：

（學號）→ （姓名，年齡，性別，系別，系辦地址、系辦電話

　　可是還存在下面的決定關係：

（學號） → (系別）→（系辦地點，系辦電話）

即存在非關鍵字段"系辦地點"、"系辦電話"對關鍵字段"學號"的傳遞函數依賴。

它也會存在數據冗餘、更新異常、插入異常和刪除異常的狀況。

　　根據第三範式把學生關係表分爲以下兩個表就能夠知足第三範式了：

學生：（學號，姓名，年齡，性別，系別）；

系別：（系別，系辦地址、系辦電話）。

上面的數據庫表就是符合I，Ⅱ，Ⅲ範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。