MySQL設計之三範式的理解

轉自：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的比例。可是反範式化必定要適度，而且在本來已知足三範式的基礎上再作調整的。