MySQL之正規化的使用詳解
一、正規化
正規化的英文名稱是Normal Form，它是英國人E.F.Codd（關係資料庫的老祖宗）在上個世紀70年代提出關係資料庫模型後總結出來的。正規化是關係資料庫理論的基礎，也是我們在設計資料庫結構過程中所要遵循的規則和指導方法。目前有跡可尋的共有8種正規化，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三個正規化，即：第一正規化（1NF），第二正規化（2NF），第三正規化（3NF）。
第一正規化（1NF）
第一正規化其實是關係型資料庫的基礎，即任何關係型資料庫都是符合第一正規化的。簡單的將第一正規化就是每一行的各個資料都是不可分割的，同一列中不能有多個值，如果出現重複的屬性就需要定義一個新的屍實體。
+------------+-------------------+ | workername | company | +------------+-------------------+ | John | ByteDance,Tencent | | Mike | Tencent | +------------+-------------------+
上面描述的資料所表達的意思是，Mike在Tencent工作，而John同時在ByteDance和Tencent工作（假設這是可能的）。但是這種表達方式並不符合第一正規化，即列的資料必須是不可分的，要滿足第一正規化，必須是下面的這種形式：
+------------+-----------+ | workername | company | +------------+-----------+ | Mike | Tencent | | John | ByteDance | | John | Tencent | +------------+-----------+
第二正規化（2NF）
首先，一個數據庫要滿足第二正規化必須要先滿足第一正規化。
我們先看一個表格：
+----------+-------------+-------+ | employee | department | head | +----------+-------------+-------+ | Jones | Accountint | Jones | | Smith | Engineering | Smith | | Brown | Accounting | Jones | | Green | Engineering | Smith | +----------+-------------+-------+
這個表描述了被僱傭者，工作部門和領導的關係。這個表所表示的關係在現實生活中是完全可能存在的，現在讓我們考慮一個問題，如果Brown接任Accounting部門的領導，我們需要怎樣對錶進行修改？這個問題將會變得非常麻煩，因為我們會發現資料都耦合在一起了，你很難找到一個很好的能唯一確定每一行的判斷條件來執行你的UPDATE語句。而我們把能夠唯一表示資料庫中表的一行的資料成為這個表的主鍵。 因此，沒有主鍵的表是不符合第二正規化的，也就是說符合第二正規化的表需要規定主鍵。
因此我們為了使上面的表符合第二正規化，需要將它拆分為兩個表：
+----------+-------------+ | employee | department | +----------+-------------+ | Brown | Accounting | | Green | Engineering | | Jones | Accounting | | Smith | Engineering | +----------+-------------+ +-------------+-------+ | department | head | +-------------+-------+ | Accounting | Jones | | Engineering | Smith | +-------------+-------+
在這兩個表中，第一個表的主鍵為employee，第二個表的主鍵為department。在這種情況下，完成上面的問題就顯得非常簡單了。
第三正規化（3NF）
一個關係型資料庫要滿足第三正規化必須要先滿足第二正規化。
將第三正規化前，我們同樣先看兩個表：
+-----------+-------------+---------+-------+ | studentid | studentname | subject | score | +-----------+-------------+---------+-------+ | 1 | Mike | Math | 96 | | 2 | John | Chinese | 85 | | 3 | Kate | History | 100 | +-----------+-------------+---------+-------+ +-----------+-----------+-------+ | subjectid | studentid | score | +-----------+-----------+-------+ | 101 | 1 | 96 | | 111 | 3 | 100 | | 201 | 2 | 85 | +-----------+-----------+-------+
上面的兩個表格的主鍵分別為studentid和subjectid，很顯然兩個表都符合第二正規化。
但是我們會發現這兩個表有重複冗餘的資料score。因此第三正規化就是要消除冗餘的資料，具體到上面的情況，就是兩個表只有一個能夠存在score這一列資料。那麼怎麼將這兩個表聯絡起來呢，這裡就出現了外來鍵。如果兩個表中有冗餘重複的列，而且這個表中的一個非主鍵列在另一個表中是主鍵，那麼我們為了消除冗餘列可以把這個非主鍵列作為聯絡兩個表的橋樑，也就是外來鍵。 通過觀察可以發現，studentid在第一個表中是主鍵，在第二個表中是非主鍵，所以他就是第二個表的外來鍵。因此上述情況我們有了以下符合第三正規化的寫法：
+-----------+-------------+---------+ | studentid | studentname | subject | +-----------+-------------+---------+ | 1 | Mike | Math | | 2 | John | Chinese | | 3 | Kate | History | +-----------+-------------+---------+ +-----------+-----------+-------+ | subjectid | studentid | score | +-----------+-----------+-------+ | 101 | 1 | 96 | | 111 | 3 | 100 | | 201 | 2 | 85 | +-----------+-----------+-------+
可以發現在設定了外來鍵之後，第一個表即使刪除了score列，也可以通過studentid在第二個表中查詢到相應的score的值，這樣即消除了資料的冗餘，又不會影響查詢，滿足第三正規化。
二、正規化的優點和缺點
正規化的優點
- 正規化化的更新操作通常要比反正規化化要快。
- 當資料較好地正規化化時，就只有很少或者沒有重複的資料，所以只需要修改更少的資料。
- 正規化化的表通常都比較小，可以更好的放在記憶體中，所以執行操作會更快。
- 很少有多餘的資料意味著檢索列表資料時更少需要DISTINCT或者GROUP BY語句。
正規化的缺點
- 正規化化的缺點就是通常需要關聯。稍微複雜一些的查詢語句在符合正規化的資料庫上都可能需要至少一次關聯，也許更多，這不但代價昂貴，也可能使一些索引策略無效。
到此這篇關於MySQL之正規化的使用詳解的文章就介紹到這了,更多相關MySQL 正規化 內容請搜尋我們以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援我們！