數據庫的三大范式


1、范式的基本介紹

設計關系數據庫時,遵從不同的規范要求,設計出合理的關系型數據庫,這些不同的規范要求被稱為不同的范式,各種范式呈遞次規范,越高的范式數據庫冗余越小。目前關系數據庫有六種范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又稱完美范式)。

范式級別越高越規范,想達到高范式,必先達到低范式的要求。 一個低一級的關系模式通過模式分解可以轉化為若干個高一級范式的關系模式的集合,這個過程叫做規范化。一般達到第三范式就可以滿足要求。

 

2、第一范式

所謂第一范式(1NF)是指在關系模型中,數據庫表的每一列都是不可分割的原子數據項,而不能是集合,數組,記錄等非原子數據項。

屬於第一范式關系的所有屬性都不可再分,即數據項不可分。 第一范式強調數據表的原子性,是其他范式的基礎。

如下圖所示數據庫就不符合第一范式:

上表將商品這一數據項又划分為名稱和數量兩個數據項,故不符合第一范式關系。改正之后如下圖所示:

 

第一范式的合理遵循需要根據系統的實際需求來定。比如某些數據庫系統中需要用到“地址”這個屬性,本來直接將“地址”屬性設計成一個數據庫表的字段就行。但是如果系統經常會訪問“地址”屬性中的“城市”部分,那么就非要將“地址”這個屬性重新拆分為省份、城市、詳細地址等多個部分進行存儲,這樣在對地址中某一部分操作的時候將非常方便。這樣設計才算滿足了數據庫的第一范式,如下表所示。

 

 

上表所示的用戶信息遵循了第一范式的要求,這樣在對用戶使用城市進行分類的時候就非常方便,也提高了數據庫的性能。

 

2.1、第一范式存在的問題

僅用第一范式來規范表格是遠遠不夠的,仍然會存在以下問題:

  1. 數據冗余
  2. 數據添加異常:存在刪除異常、插入異常、修改異常的問題。

 

3、第二范式(消除了部分函數依賴)

第二范式的概念:在1NF的基礎上,非碼屬性必須完全依賴於候選碼(在1NF基礎上消除非主屬性對主碼的部分函數依賴)。

第二范式需要確保數據庫表中的每一列都和主鍵相關,而不能只與主鍵的某一部分相關(主要針對聯合主鍵而言)。如果滿足第一范式,並且主鍵只有一個屬性的那就一定是第二范式,因為如果主鍵只有一個屬性值那就意味着已經消除了部分函數依賴。

比如:一個表中有學號、課程號、成績、學分。學號+課程號組成主鍵,成績完全依賴主鍵,而學分部分依賴主鍵,因為課程號就能確定學分,所以不符合第二范式。

 

3.1、第二范式存在的問題

第二范式仍會存在數據更新異常、插入異常、刪除異常的問題。

 

4、第三范式(在第二范式基礎上消除了傳遞函數依賴)

在2NF基礎上,任何非主屬性不依賴於其它非主屬性(在2NF基礎上消除傳遞依賴)。滿足第二范式,並且非主屬性沒有傳遞依賴於主鍵時,就是第三范式。

比如:學號、姓名、系號、系名、系樓層,學號是主鍵,此時就不滿足第三范式,因為學號確定系號,系號又確定系名、系樓層,此時存在傳遞依賴。也就是非主屬性全部都是直接依賴於主鍵,而不是間接依賴於主鍵。

滿足第三范式的表可以解決數據冗余、更新異常、插入異常、刪除異常的問題。

 

5、BCNF(BC范式)

也就是說把所有的依賴集都列出來,而左邊的部分必定是候選鍵的就滿足BC范式。

例題:

候選鍵有SJ和TJ,所有的依賴集有:SJ -> T,T -> J,而依賴集所有的左邊部分SJ是候選鍵,但T不是候選鍵,所以不滿足BC范式。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM