三正規化

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）要求資料庫表中的每個例項或行必須可以被惟一地區分。為實現區分通常需要我們設計一個主鍵來實現(這裡的主鍵不包含業務邏輯)。

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

看下面的學生選課表：

學號	課程	成績	課程學分
10001	數學	100	6
10001	語文	90	2
10001	英語	85	3
10002	數學	90	6
10003	數學	99	6
10004	語文	89	2

表中主鍵為 （學號，課程），我們可以表示為 (學號，課程) -> (成績，課程學分)， 表示所有非主鍵列 (成績，課程學分)都依賴於主鍵 (學號，課程)。 但是，表中還存在另外一個依賴：（課程）->(課程學分）。這樣非主鍵列 ‘課程學分‘ 依賴於部分主鍵列 '課程‘， 所以上表是不滿足第二正規化的。

我們把它拆成如下2張表：

學生選課表：

學號	課程	成績
10001	數學	100
10001	語文	90
10001	英語	85
10002	數學	90
10003	數學	99
10004	語文	89

課程資訊表：

課程	課程學分
數學	6
語文	3
英語	2

那麼上面2個表，學生選課表主鍵為（學號，課程），課程資訊表主鍵為（課程），表中所有非主鍵列都完全依賴主鍵。不僅符合第二正規化，還符合第三正規化。

再看這樣一個學生資訊表：

學號	姓名	性別	班級	班主任
10001	張三	男	一班	小王
10002	李四	男	一班	小王
10003	王五	男	二班	小李
10004	張小三	男	二班	小李

上表中，主鍵為：（學號），所有欄位 （姓名，性別，班級，班主任）都依賴與主鍵（學號），不存在對主鍵的部分依賴。所以是滿足第二正規化。

第三正規化（3NF）

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

即滿足第二正規化前提，如果某一屬性依賴於其他非主鍵屬性，而其他非主鍵屬性又依賴於主鍵，那麼這個屬性就是間接依賴於主鍵，這被稱作傳遞依賴於主屬性。 通俗解釋就是一張表最多隻存兩層同類型資訊。

反三正規化

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

以上就是本文的全部內容，希望對大家的學習有所幫助，也希望大家多多支援我們。