MySQL數據庫范式化設計的方法

這篇文章主要講解了“MySQL數據庫范式化設計的方法”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“MySQL數據庫范式化設計的方法”吧！

一、設計范式

問題： 什么是范式化設計，為什么需要反規范化設計 ？

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

滿足這些范式理論上可以讓我們的數據庫邏輯結構更加簡潔、清晰。

以下是常見的四種范式：

• 第一范式（1NF）

• 第二范式（2NF）

• 第三范式（3NF）

• 第四范式（BCNF）

1.第一范式（1NF）

• 每一列都是不可再分的屬性值，確保每一列的原子性；

• 兩列的屬性相近或者相似或者一樣，盡量合并屬性一樣的列，確保不產生冗余數據；

• 單一屬性的列為基本數據類型構成；

• 設計出來的表都是簡單的二維表。

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

正例：

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

2.第二范式（2NF）

• 第二范式（2NF）是在第一范式的基礎上建立起來的。

• 第二范式（2NF）要求實體的屬性完全依賴與主鍵關聯。所謂完成依賴是指不能存在與存在依賴關鍵字的部分屬性，如果存在那么這個屬性和關鍵字部分應該分離出來形成一個新的實體，新實體與原實體是一對多的關系。

反例：

正例： 訂單表

產品表

用戶表

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

3.第三范式 （3NF）

• 滿足第三范式（3NF）必須滿足第二范式（2NF）。

• 第三范式（3NF） 要求一個數據表中不包含已在其他表中包含的非主鍵關鍵字信息，即數據不能存在傳遞關系，即每個屬性都跟主鍵有關系直接關系而不是間接關系。

反例：

正例： 訂單表

商品信息表

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

二、范式化設計

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

結論：并不是說完全符合規范化理論的設計是最完美的設計，而是要看具體的業務場景反復實踐總結最合適的設計。

三、反規范化設計

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

• 商品信息

• 分類信息

• 商品分類對應關系表

• 商品信息反規范化設計

感謝各位的閱讀，以上就是“MySQL數據庫范式化設計的方法”的內容了，經過本文的學習后，相信大家對MySQL數據庫范式化設計的方法這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！