轉自：https://blog.csdn.net/wangqyoho/article/details/52900585

設計關系數據庫時，遵從不同的規范要求，設計出合理的關系型數據庫，這些不同的規范要求被稱為不同的范式，各種范式呈遞次規范，越高的范式數據庫冗余越小。但是有些時候一昧的追求范式減少冗余，反而會降低數據讀寫的效率，這個時候就要反范式，利用空間來換時間。

目前關系數據庫有六種范式：

第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF，又稱完美范式)。滿足最低要求的范式是第一范式(1NF)。在第一范式的基礎上進一步滿足更多規范要求的稱為第二范式(2NF)，其余范式以次類推。一般說來，數據庫只需滿足第三范式(3NF)就行了。所以這里就只記錄三范式相關的知識。

三范式

1NF:字段不可分;

2NF:有主鍵，非主鍵字段依賴主鍵;

3NF:非主鍵字段不能相互依賴;

解釋:

1NF:原子性 字段不可再分,否則就不是關系數據庫;

2NF:唯一性 一個表只說明一個事物;

3NF:每列都與主鍵有直接關系，不存在傳遞依賴;

第一范式(1NF)

即表的列的具有原子性,不可再分解，即列的信息，不能分解, 只要數據庫是關系型數據庫(mysql/oracle/db2/informix/sysbase/sql server)，就自動的滿足1NF。數據庫表的每一列都是不可分割的原子數據項，而不能是集合，數組，記錄等非原子數據項。如果實體中的某個屬性有多個值時，必須拆分為不同的屬性?。通俗理解即一個字段只存儲一項信息。

關系型數據庫: mysql/oracle/db2/informix/sysbase/sql server

非關系型數據庫: (特點: 面向對象或者集合)

NoSql數據庫: MongoDB/redis(特點是面向文檔)

第二范式(2NF)

第二范式(2NF)是在第一范式(1NF)的基礎上建立起來的，即滿足第二范式(2NF)必須先滿足第一范式(1NF)。第二范式(2NF)要求數據庫表中的每個實例或行必須可以被惟一地區分。為實現區分通常需要我們設計一個主鍵來實現(這里的主鍵不包含業務邏輯)。

即滿足第一范式前提，當存在多個主鍵的時候，才會發生不符合第二范式的情況。比如有兩個主鍵，不能存在這樣的屬性，它只依賴于其中一個主鍵，這就是不符合第二范式。通俗理解是任意一個字段都只依賴表中的同一個字段。(涉及到表的拆分)

第三范式(3NF)

滿足第三范式(3NF)必須先滿足第二范式(2NF)。簡而言之，第三范式(3NF)要求一個數據庫表中不包含已在其它表中已包含的非主鍵字段。就是說，表的信息，如果能夠被推導出來，就不應該單獨的設計一個字段來存放(能盡量外鍵join就用外鍵join)。很多時候，我們為了滿足第三范式往往會把一張表分成多張表。

即滿足第二范式前提，如果某一屬性依賴于其他非主鍵屬性，而其他非主鍵屬性又依賴于主鍵，那么這個屬性就是間接依賴于主鍵，這被稱作傳遞依賴于主屬性。?通俗解釋就是一張表最多只存兩層同類型信息。

反三范式

沒有冗余的數據庫未必是最好的數據庫，有時為了提高運行效率，提高讀性能，就必須降低范式標準，適當保留冗余數據。具體做法是： 在概念數據模型設計時遵守第三范式，降低范式標準的工作放到物理數據模型設計時考慮。降低范式就是增加字段，減少了查詢時的關聯，提高查詢效率，因為在數據庫的操作中查詢的比例要遠遠大于DML的比例。但是反范式化一定要適度，并且在原本已滿足三范式的基礎上再做調整的。

總結

以上是生活随笔為你收集整理的mysql三范式_MySQL设计之三范式的理解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。