詳解MySQL 數(shù)據(jù)庫(kù)范式

前言：

關(guān)于數(shù)據(jù)庫(kù)范式，時(shí)常有聽說過，一直沒有詳細(xì)去了解。一般數(shù)據(jù)庫(kù)書籍或數(shù)據(jù)庫(kù)課程會(huì)介紹范式相關(guān)內(nèi)容，范式也經(jīng)常出現(xiàn)在數(shù)據(jù)庫(kù)考試題目中。不清楚你是否對(duì)范式有比較清晰的了解呢？本篇文章我們一起來學(xué)習(xí)下數(shù)據(jù)庫(kù)范式吧。

1.數(shù)據(jù)庫(kù)范式簡(jiǎn)介

為了建立冗余較小、結(jié)構(gòu)合理的數(shù)據(jù)庫(kù)，設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí)必須遵循一定的規(guī)則。在關(guān)系型數(shù)據(jù)庫(kù)中這種規(guī)則就稱為范式。范式是符合某一種設(shè)計(jì)要求的總結(jié)。要想設(shè)計(jì)一個(gè)結(jié)構(gòu)合理的關(guān)系型數(shù)據(jù)庫(kù)，必須滿足一定的范式。

范式的英文名稱是 Normal Form ，簡(jiǎn)稱 NF 。它是英國(guó)人 E.F.Codd 在上個(gè)世紀(jì)70年代提出關(guān)系數(shù)據(jù)庫(kù)模型后總結(jié)出來的。范式是關(guān)系數(shù)據(jù)庫(kù)理論的基礎(chǔ)，也是我們?cè)谠O(shè)計(jì)數(shù)據(jù)庫(kù)結(jié)構(gòu)過程中所要遵循的規(guī)則和指導(dǎo)方法。

目前關(guān)系型數(shù)據(jù)庫(kù)有六種常見范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又稱完美范式）。滿足最低要求的范式是第一范式（1NF）。在第一范式的基礎(chǔ)上進(jìn)一步滿足更多規(guī)范要求的稱為第二范式（2NF），其余范式以次類推。

2.常用范式詳解

在設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí)，會(huì)參考范式要求來做，但是并不是說遵循的范式等級(jí)越高越好，范式過高雖然具有對(duì)數(shù)據(jù)關(guān)系有更好的約束性，但是也會(huì)導(dǎo)致表之間的關(guān)系更加繁瑣，從而導(dǎo)致每次操作的表會(huì)變多，數(shù)據(jù)庫(kù)性能下降。通常，在關(guān)系型數(shù)據(jù)庫(kù)設(shè)計(jì)中，最高也就遵循到 BCNF ，普遍還是 3NF 。即一般情況下，我們使用前三個(gè)范式已經(jīng)夠用了。下面我們來詳細(xì)了解下常用的前三個(gè)范式。

第一范式（1NF）

第一范式是最基本的范式。如果數(shù)據(jù)庫(kù)表中的所有字段值都是不可分解的原子值，就說明該數(shù)據(jù)庫(kù)表滿足了第一范式。簡(jiǎn)單的講第一范式就是每一行的各個(gè)數(shù)據(jù)都是不可分割的，同一列中不能有多個(gè)值，如果出現(xiàn)重復(fù)的屬性就需要定義一個(gè)新的實(shí)體。

示例：假設(shè)一家公司要存儲(chǔ)其員工的姓名和聯(lián)系方式。它創(chuàng)建一個(gè)如下表：

兩名員工（Jon＆Lester）擁有兩個(gè)手機(jī)號(hào)碼，因此公司將他們存儲(chǔ)在同一表格中，如上表所示。那么該表不符合 1NF ，因?yàn)橐?guī)則說“表的每個(gè)屬性必須具有原子（單個(gè)）值”，Jon＆Lester員工的 emp_mobile 值違反了該規(guī)則。為了使表符合 1NF ，我們應(yīng)該有如下表數(shù)據(jù)：

第二范式（2NF）

第二范式在第一范式的基礎(chǔ)之上更進(jìn)一層。第二范式需要確保數(shù)據(jù)庫(kù)表中的每一列都和主鍵相關(guān)，而不能只與主鍵的某一部分相關(guān)（主要針對(duì)聯(lián)合主鍵而言）。也就是說在一個(gè)數(shù)據(jù)庫(kù)表中，一個(gè)表中只能保存一種數(shù)據(jù)，不可以把多種數(shù)據(jù)保存在同一張數(shù)據(jù)庫(kù)表中。

+----------+-------------+-------+
| employee | department | head |
+----------+-------------+-------+
| Jones  | Accountint | Jones |
| Smith  | Engineering | Smith |
| Brown  | Accounting | Jones |
| Green  | Engineering | Smith |
+----------+-------------+-------+

上表描述了被雇傭者，工作部門和領(lǐng)導(dǎo)的關(guān)系。我們把能夠唯一表示數(shù)據(jù)庫(kù)中表的一行的數(shù)據(jù)成為這個(gè)表的主鍵。表中 head 列不和主鍵相關(guān)。因此，該表是不符合第二范式的，為了使上面的表符合第二范式，需要將它拆分為兩個(gè)表：

-- employee 為主鍵
+----------+-------------+
| employee | department |
+----------+-------------+
| Brown  | Accounting |
| Green  | Engineering |
| Jones  | Accounting |
| Smith  | Engineering |
+----------+-------------+

-- department 為主鍵
+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+

第三范式（3NF）

滿足 2NF 的前提下，非主鍵外的所有字段必須互不依賴，即需要確保數(shù)據(jù)表中的每一列數(shù)據(jù)都和主鍵直接相關(guān)，而不能間接相關(guān)。

簡(jiǎn)而言之，第三范式（3NF）要求一個(gè)關(guān)系中不包含已在其它關(guān)系已包含的非主關(guān)鍵字信息。例如，存在一個(gè)部門信息表，其中每個(gè)部門有部門編號(hào)（dept_id）、部門名稱、部門簡(jiǎn)介等信息。那么在員工信息表中列出部門編號(hào)后就不能再將部門名稱、部門簡(jiǎn)介等與部門有關(guān)的信息再加入員工信息表中。如果不存在部門信息表，則根據(jù)第三范式（3NF）也應(yīng)該構(gòu)建它，否則就會(huì)有大量的數(shù)據(jù)冗余。

3.關(guān)于反范式

范式的優(yōu)點(diǎn)是明顯的，它避免了大量的數(shù)據(jù)冗余，節(jié)省了存儲(chǔ)空間，保持了數(shù)據(jù)的一致性。范式化的表通常更小，可以更好地放在內(nèi)存里，所以執(zhí)行操作會(huì)更快。那么是不是只要把所有的表都規(guī)范為 3NF 后，數(shù)據(jù)庫(kù)的設(shè)計(jì)就是最優(yōu)的呢？這可不一定。范式越高意味著表的劃分更細(xì)，一個(gè)數(shù)據(jù)庫(kù)中需要的表也就越多，用戶不得不將原本相關(guān)聯(lián)的數(shù)據(jù)分?jǐn)偟蕉鄠€(gè)表中。稍微復(fù)雜一些的查詢語句在符合范式的數(shù)據(jù)庫(kù)上都可能需要至少一次關(guān)聯(lián)，也許更多，這不但代價(jià)昂貴，也可能使一些索引策略無效。

所以我們?cè)谶M(jìn)行數(shù)據(jù)庫(kù)設(shè)計(jì)時(shí)，并不會(huì)完全按照范式要求來做，有時(shí)候也會(huì)進(jìn)行反范式設(shè)計(jì)。通過增加冗余或重復(fù)的數(shù)據(jù)來提高數(shù)據(jù)庫(kù)的讀性能，減少關(guān)聯(lián)查詢時(shí)，join 表的次數(shù)。

以上就是詳解MySQL 數(shù)據(jù)庫(kù)范式的詳細(xì)內(nèi)容，更多關(guān)于MySQL 數(shù)據(jù)庫(kù)范式的資料請(qǐng)關(guān)注腳本之家其它相關(guān)文章！