所謂范式，是關系型數據庫關系模式規范化的標準，從規范化的寬松到嚴格，分別為不同的范式，通常使用的有第一范式、第二范式、第三范式及BC范式等。范式是建立在函數依賴基礎上的。

函數依賴

定義：設有關系模式R(U)，X和Y是屬性集U的子集，函數依賴是形為X→Y的一個命題，對任意R中兩個元組t和s，都有t[X]=s[X]蘊t[Y]=s[Y]，那么FD X→Y在關系模式R(U)中成立。X→Y讀作‘X函數決定Y’，或‘Y函數依賴于X’。

通俗的講，如果一個表中某一個字段Y的值是由另外一個字段或一組字段X的值來確定的，就稱為Y函數依賴于X。

函數依賴應該是通過理解數據項和企業的規則來決定的，根據表的內容得出的函數依賴可能是不正確的。

第一范式（1NF）

定義：果關系模式R的每個關系r的屬性都是不可分的數據項，那么就稱R是第一范式的模式。簡單的說，每一個屬性都是原子項，不可分割。 1NF是關系模式應具備的最起碼的條件，如果數據庫設計不能滿足第一范式，就不稱為關系型數據庫。關系數據庫設計研究的關系規范化是在1NF之上進行的。

第二范式（2NF）

定義：如果關系模式R是1NF，且每個非主屬性完全函數依賴于候選鍵，那么就稱R是第二范式。簡單的說，第二范式要滿足以下的條件：首先要滿足第一范式，其次每個非主屬性要完全函數依賴與候選鍵，或者是主鍵。也就是說，每個非主屬性是由整個主鍵函數決定的，而不能由主鍵的一部分來決定。

舉個例子：

有股票日行情表的主鍵是股票代碼和交易日期組成。非主屬性中有收盤價和成交量等，都是由主鍵，即股票代碼和交易日期函數決定的，單獨的股票代碼或者交易日期都不能函數決定這些非主屬性。如果這個表中有非主屬性股票簡稱，則股票簡稱是可以由股票代碼來函數決定的，這樣股票簡稱這個非主屬性就不是完全函數依賴于候選鍵，這樣的設計就不滿足第二范式。

第三范式（3NF）

定義：如果關系模式R是2NF，且關系模式R（U，F）中的所有非主屬性對任何候選關鍵字都不存在傳遞依賴，則稱關系R是屬于第三范式。簡單的說，第三范式要滿足以下的條件：首先要滿足第二范式，其次非主屬性之間不存在函數依賴。由于滿足了第二范式，表示每個非主屬性都函數依賴于主鍵。如果非主屬性之間存在了函數依賴，就會存在傳遞依賴，這樣就不滿足第三范式。

舉個例子：

在股票基本情況表中，主鍵是股票代碼，有非主屬性所屬一級行業和所屬二級行業。根據業務規則，所屬二級行業能夠函數決定所屬一級行業，這就表示存在這樣一種關系：股票代碼函數決定所屬二級行業，所屬二級行業函數決定所屬一級行業，這就形成了傳遞依賴，這樣的設計就不符合第三范式。

不過在實際運用中，為查詢和使用的方便，有時也會違反第三范式。如上例，如果沒有所屬一級行業的屬性，需要查詢所屬一級行業的相關股票，需要查詢時使用函數來從二級行業中函數生成所屬一級行業，使用性能上會受影響。所以通常會加上所屬一級行業的屬性。

BC范式（BCNF）

BC范式是第三范式的增強版，不過也有人說是直接從1NF發展過來的，即每個屬性，包括主屬性或非主屬性，都完全依賴于候選鍵，并且不存在傳遞依賴情況。

|----------------------------------------------------------------------------------------|
                           版權聲明  版權所有 @zhyiwww
            引用請注明來源 http://m.tkk7.com/zhyiwww   
|----------------------------------------------------------------------------------------|