一、設(shè)計范式

問題： 什么是范式化設(shè)計，為什么需要反規(guī)范化設(shè)計 ？

范式來自來自英文Normal From 。開發(fā)過程中要設(shè)計一個好的數(shù)據(jù)庫邏輯關(guān)系，必須滿足一定的約束條件，此約束條件形成了開發(fā)范式，分成幾個等級，一級比一級嚴格。

滿足這些范式理論上可以讓我們的數(shù)據(jù)庫邏輯結(jié)構(gòu)更加簡潔、清晰。

以下是常見的四種范式：

• 第一范式（1NF）
• 第二范式（2NF）
• 第三范式（3NF）
• 第四范式（BCNF）

1.第一范式（1NF）

• 每一列都是不可再分的屬性值，確保每一列的原子性；
• 兩列的屬性相近或者相似或者一樣，盡量合并屬性一樣的列，確保不產(chǎn)生冗余數(shù)據(jù)；
• 單一屬性的列為基本數(shù)據(jù)類型構(gòu)成；
• 設(shè)計出來的表都是簡單的二維表。

舉例：用戶收貨地址 反例：

正例：

總結(jié)：每列都是不可再分的原子值（一個列不可再分，比如通訊地址和省、市、區(qū)）

2.第二范式（2NF）

• 第二范式（2NF）是在第一范式的基礎(chǔ)上建立起來的。
• 第二范式（2NF）要求實體的屬性完全依賴與主鍵關(guān)聯(lián)。所謂完成依賴是指不能存在與存在依賴關(guān)鍵字的部分屬性，如果存在那么這個屬性和關(guān)鍵字部分應(yīng)該分離出來形成一個新的實體，新實體與原實體是一對多的關(guān)系。

反例：

正例： 訂單表

產(chǎn)品表

用戶表

總結(jié)：消除列對主鍵的部分函數(shù)依賴（對于組合主鍵的部分依賴，比如：產(chǎn)品ID + 用戶ID 為主鍵，存在用戶名稱，產(chǎn)品名稱等部分主鍵依賴字段）

3.第三范式 （3NF）

• 滿足第三范式（3NF）必須滿足第二范式（2NF）。
• 第三范式（3NF） 要求一個數(shù)據(jù)表中不包含已在其他表中包含的非主鍵關(guān)鍵字信息，即數(shù)據(jù)不能存在傳遞關(guān)系，即每個屬性都跟主鍵有關(guān)系直接關(guān)系而不是間接關(guān)系。

反例：

正例： 訂單表

商品信息表

總結(jié)：消除字段對非主鍵的傳遞依賴（就是需要取消訂單中比如商品名稱、商品地址等冗余信息）。

二、范式化設(shè)計

在真正的數(shù)據(jù)庫規(guī)范定義上，非常的嚴謹，比如第二范式（2NF）的定義“若某關(guān)系 R 術(shù)語第一范式，且每個非主屬性完全函數(shù)依賴于候選碼，則關(guān)系 R 屬于第二范式”。

結(jié)論：并不是說完全符合規(guī)范化理論的設(shè)計是最完美的設(shè)計，而是要看具體的業(yè)務(wù)場景反復(fù)實踐總結(jié)最合適的設(shè)計。

三、反規(guī)范化設(shè)計

所謂反規(guī)范化設(shè)計，就是針對規(guī)范化而言的。 1、為了性能和讀取效率而適當(dāng)?shù)倪`反對數(shù)據(jù)庫范式設(shè)計的要求； 3、為了查詢的性能，允許存在部分（少量）冗余數(shù)據(jù)。換句話說，反規(guī)范化設(shè)計就是直接用空間換時間。

• 商品信息

• 分類信息

• 商品分類對應(yīng)關(guān)系表

• 商品信息反規(guī)范化設(shè)計

四、設(shè)計總結(jié)

• 數(shù)據(jù)庫的規(guī)劃化范式設(shè)計，在邏輯結(jié)構(gòu)上可以讓結(jié)構(gòu)更加細粒度，容易理解。
• 但是我們在實際的開發(fā)過程中，需要考慮性能和時間成本，往往或多或少，會允許數(shù)據(jù)冗余（反規(guī)范化設(shè)計），通常可以達到 2NF。

到此這篇關(guān)于MySQL 數(shù)據(jù)庫范式設(shè)計理論總結(jié)的文章就介紹到這了,更多相關(guān)MySQL 數(shù)據(jù)庫設(shè)計內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！