關係型資料庫設計三大正規化

作者：鄭龍飛

正規化定義

百度百科:設計關聯式資料庫時，遵從不同的規範要求，設計出合理的關係型資料庫，這些不同的規範要求被稱為不同的正規化，各種正規化呈遞次規範，越高的正規化資料庫冗餘越小。

人類語言: 正規化可以理解為設計一張資料表的表結構，符合的標準級別、規範和要求。

而通常我們用的最多的就是第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF），也就是本文要講的“三大正規化”。

正規化的優點

採用正規化可以降低資料的冗餘性。

為什麼要降低資料的冗餘性？

1. 十幾年前，磁碟很貴，為了減少磁碟儲存。
2. 以前沒有分散式系統，都是單機，只能增加磁碟，磁碟個數也是有限的。
3. 一次修改，需要修改多個表，很難保證資料一致性。

正規化的缺點

正規化的缺點是獲取資料時，需要透過Join拼接出最後的資料。

目前正規化的分類

目前業界正規化有：第一正規化(1NF)、第二正規化(2NF)、第三正規化(3NF)、巴斯-科德正規化(BCNF)、第四正規化(4NF)、第五正規化(5NF)。

什麼是函式依賴？

百度百科:函式依賴簡單點說就是：某個屬性集決定另一個屬性集時，稱另一屬性集依賴於該屬性集。

人類語言:以下面表格為例，通俗易懂的解釋，什麼是函式依賴。

完全函式依賴

官方定義:設X，Y是關係R的兩個屬性集合，X’是X的真子集，存在X→Y，但對每一個X’都有X’!→Y，則稱Y完全函式依賴於X。

人類語言:比如透過，(學號，課程) 推出分數 ，但是單獨用學號推斷不出來分數，那麼就可以說：分數 完全依賴於(學號，課程) 。

總結:即：透過A B能得出C，但 是A B單獨得不出C，那麼說C完全依賴於AB。

部分函式依賴

官方定義:假如 Y函式依賴於 X，但同時 Y 並不完全函式依賴於 X，那麼我們就稱 Y 部分函式依賴於 X。

人類語言:比如透過，(學 號，課程) 推出姓名，因為其實直接可以透過，學號推出姓名，所以：姓名 部分依賴於 (學號，課程)。

總結:透過AB能得出C，透過A也能得出C，或者透過B也能得出C，那麼說C部分依賴於AB。

傳遞函式依賴

官方定義:傳遞函式依賴：設X，Y，Z是關係R中互不相同的屬性集合，存在X→Y(Y !→X),Y→Z，則稱Z傳遞函式依賴於X。

人類語言:比如：學號 推出 系名 ， 系名 推出 系主任， 但是，系主任推不出學號，系主任主要依賴於系名。這種情況可以說：系主任 傳遞依賴於 學號 。

總結:即：通 過A得 到B，通 過B得 到C，但 是C得不到A，那 麼說C傳遞依賴於A。

三正規化的區別

第一正規化

第一正規化1NF核心原則：屬性不可切割。

舉例說明:

很明顯上面表格設計是不符合第一正規化的，學籍資訊列中的資料不是原子資料項，是可以進行分割的，因此對錶格進行修改，讓表格符合第一正規化的要求，修改結果如下圖所示：

實際上 ，1NF是所有關係型資料庫的最基本要求 ,你在關係型資料庫管理系統（RDBMS），例如SQL Server，Oracle，MySQL中建立資料表的時候，如果資料表的設計不符合這個最基本的要求，那麼操作一定是不能成功的。也就是說，只要在RDBMS中已經存在
的資料表，一定是符合1NF的。

第二正規化

第二正規化2NF核心原則：不能存在“部分函式依賴”。

舉例說明:

以上表格明視訊記憶體在，部分依賴。比 如，這張表的主鍵是 (學號，課名），分數確實完全依賴於(學號，課名），但是姓名並不完全依賴於(學號，課名）,讓表格符合第二正規化的要求，修改結果如下圖所示：

以上符合第二正規化，去掉部分函式依賴依賴。

第三正規化

第三正規化 3NF核心原則：不能存在傳遞函式依賴。

舉例說明:

在上面這張表中，存 在傳遞函式依賴：學號->系 名->系主任，但是系主任推不出學號。

上面表需要再次拆解：

反三正規化

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

總結

引用知乎大佬對正規化的理解:

資料庫設計應該也是分為三個境界的：

第一個境界，剛入門資料庫設計，正規化的重要性還未深刻理解。這時候出現的反正規化設計，一般會出問題。

第二個境界，隨著遇到問題解決問題，漸漸瞭解到正規化的真正好處，從而能快速設計出低冗餘、高效率的資料庫。

第三個境界，再經過N年的鍛鍊，是一定會發覺正規化的侷限性的。此時再去打破正規化，設計更合理的反正規化部分。