佳木斯湛栽影视文化发展公司

主頁 > 知識庫 > MySQL之范式的使用詳解

MySQL之范式的使用詳解

熱門標簽:Linux服務(wù)器 網(wǎng)站排名優(yōu)化 地方門戶網(wǎng)站 AI電銷 服務(wù)外包 鐵路電話系統(tǒng) 百度競價排名 呼叫中心市場需求

一、范式

范式的英文名稱是Normal Form,它是英國人E.F.Codd(關(guān)系數(shù)據(jù)庫的老祖宗)在上個世紀70年代提出關(guān)系數(shù)據(jù)庫模型后總結(jié)出來的。范式是關(guān)系數(shù)據(jù)庫理論的基礎(chǔ),也是我們在設(shè)計數(shù)據(jù)庫結(jié)構(gòu)過程中所要遵循的規(guī)則和指導(dǎo)方法。目前有跡可尋的共有8種范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。通常所用到的只是前三個范式,即:第一范式(1NF),第二范式(2NF),第三范式(3NF)。

第一范式(1NF)

第一范式其實是關(guān)系型數(shù)據(jù)庫的基礎(chǔ),即任何關(guān)系型數(shù)據(jù)庫都是符合第一范式的。簡單的將第一范式就是每一行的各個數(shù)據(jù)都是不可分割的,同一列中不能有多個值,如果出現(xiàn)重復(fù)的屬性就需要定義一個新的尸實體。
下面數(shù)據(jù)庫便不符合第一范式:

+------------+-------------------+
| workername | company      |
+------------+-------------------+
| John    | ByteDance,Tencent |
| Mike    | Tencent      |
+------------+-------------------+

上面描述的數(shù)據(jù)所表達的意思是,Mike在Tencent工作,而John同時在ByteDance和Tencent工作(假設(shè)這是可能的)。但是這種表達方式并不符合第一范式,即列的數(shù)據(jù)必須是不可分的,要滿足第一范式,必須是下面的這種形式:

+------------+-----------+
| workername | company  |
+------------+-----------+
| Mike    | Tencent  |
| John    | ByteDance |
| John    | Tencent  |
+------------+-----------+

第二范式(2NF)

首先,一個數(shù)據(jù)庫要滿足第二范式必須要先滿足第一范式。
我們先看一個表格:

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

這個表描述了被雇傭者,工作部門和領(lǐng)導(dǎo)的關(guān)系。這個表所表示的關(guān)系在現(xiàn)實生活中是完全可能存在的,現(xiàn)在讓我們考慮一個問題,如果Brown接任Accounting部門的領(lǐng)導(dǎo),我們需要怎樣對表進行修改?這個問題將會變得非常麻煩,因為我們會發(fā)現(xiàn)數(shù)據(jù)都耦合在一起了,你很難找到一個很好的能唯一確定每一行的判斷條件來執(zhí)行你的UPDATE語句。而我們把能夠唯一表示數(shù)據(jù)庫中表的一行的數(shù)據(jù)成為這個表的主鍵。 因此,沒有主鍵的表是不符合第二范式的,也就是說符合第二范式的表需要規(guī)定主鍵。

因此我們?yōu)榱耸股厦娴谋矸系诙妒剑枰獙⑺鸱譃閮蓚€表:

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

+-------------+-------+
| department | head |
+-------------+-------+
| Accounting | Jones |
| Engineering | Smith |
+-------------+-------+

在這兩個表中,第一個表的主鍵為employee,第二個表的主鍵為department。在這種情況下,完成上面的問題就顯得非常簡單了。

第三范式(3NF)

一個關(guān)系型數(shù)據(jù)庫要滿足第三范式必須要先滿足第二范式。
將第三范式前,我們同樣先看兩個表:

+-----------+-------------+---------+-------+
| 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,很顯然兩個表都符合第二范式。

但是我們會發(fā)現(xiàn)這兩個表有重復(fù)冗余的數(shù)據(jù)score。因此第三范式就是要消除冗余的數(shù)據(jù),具體到上面的情況,就是兩個表只有一個能夠存在score這一列數(shù)據(jù)。那么怎么將這兩個表聯(lián)系起來呢,這里就出現(xiàn)了外鍵。如果兩個表中有冗余重復(fù)的列,而且這個表中的一個非主鍵列在另一個表中是主鍵,那么我們?yōu)榱讼哂嗔锌梢园堰@個非主鍵列作為聯(lián)系兩個表的橋梁,也就是外鍵。 通過觀察可以發(fā)現(xiàn),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  |
+-----------+-----------+-------+

可以發(fā)現(xiàn)在設(shè)定了外鍵之后,第一個表即使刪除了score列,也可以通過studentid在第二個表中查找到相應(yīng)的score的值,這樣即消除了數(shù)據(jù)的冗余,又不會影響查找,滿足第三范式。

二、范式的優(yōu)點和缺點

范式的優(yōu)點

  • 范式化的更新操作通常要比反范式化要快。
  • 當數(shù)據(jù)較好地范式化時,就只有很少或者沒有重復(fù)的數(shù)據(jù),所以只需要修改更少的數(shù)據(jù)。
  • 范式化的表通常都比較小,可以更好的放在內(nèi)存中,所以執(zhí)行操作會更快。
  • 很少有多余的數(shù)據(jù)意味著檢索列表數(shù)據(jù)時更少需要DISTINCT或者GROUP BY語句。

范式的缺點

  • 范式化的缺點就是通常需要關(guān)聯(lián)。稍微復(fù)雜一些的查詢語句在符合范式的數(shù)據(jù)庫上都可能需要至少一次關(guān)聯(lián),也許更多,這不但代價昂貴,也可能使一些索引策略無效。

到此這篇關(guān)于MySQL之范式的使用詳解的文章就介紹到這了,更多相關(guān)MySQL 范式 內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

您可能感興趣的文章:
  • 數(shù)據(jù)庫 三范式最簡單最易記的解釋
  • 詳解MySQL 數(shù)據(jù)庫范式
  • 數(shù)據(jù)庫設(shè)計三大范式簡析
  • MySQL學習之三大范式詳解小白篇

標簽:仙桃 湖南 黃山 崇左 銅川 湘潭 衡水 蘭州

巨人網(wǎng)絡(luò)通訊聲明:本文標題《MySQL之范式的使用詳解》,本文關(guān)鍵詞  ;如發(fā)現(xiàn)本文內(nèi)容存在版權(quán)問題,煩請?zhí)峁┫嚓P(guān)信息告之我們,我們將及時溝通與處理。本站內(nèi)容系統(tǒng)采集于網(wǎng)絡(luò),涉及言論、版權(quán)與本站無關(guān)。
  • 相關(guān)文章
  • 收縮
    • 微信客服
    • 微信二維碼
    • 電話咨詢

    • 400-1100-266
    眉山市| 集贤县| 张家口市| 高雄县| 珲春市| 谷城县| 连州市| 建湖县| 屯昌县| 五华县| 伊宁县| 孟津县| 衡东县| 宿松县| 车致| 青阳县| 台安县| 高雄市| 合作市| 陇川县| 青岛市| 宜川县| 化隆| 友谊县| 鹤山市| 营山县| 大荔县| 山东| 秀山| 射阳县| 旌德县| 易门县| 尼木县| 丽江市| 章丘市| 聊城市| 西宁市| 宜宾县| 通河县| 华安县| 建水县|