首頁 > 軟體

MySQL 資料庫正規化化設計理論總結

2022-04-22 10:00:03

一、設計正規化

問題: 什麼是正規化化設計,為什麼需要反規範化設計 ?

正規化來自來自英文Normal From 。開發過程中要設計一個好的資料庫邏輯關係,必須滿足一定的約束條件,此約束條件形成了開發正規化,分成幾個等級,一級比一級嚴格。

滿足這些正規化理論上可以讓我們的資料庫邏輯結構更加簡潔、清晰。

以下是常見的四種正規化:

  • 第一規格化(1NF)
  • 第二正規化(2NF)
  • 第三正規化(3NF)
  • 第四規格化(BCNF)

1.第一規格化(1NF)

  • 每一列都是不可再分的屬性值,確保每一列的原子性;
  • 兩列的屬性相近或者相似或者一樣,儘量合併屬性一樣的列,確保不產生冗餘資料;
  • 單一屬性的列為基本資料型別構成;
  • 設計出來的表都是簡單的二維表。

舉例:使用者收貨地址 反例:

姓名電話地址
張三138000000北京市-朝陽區-酒仙橋街道

正例:

姓名電話街道
張三138000000-北京市朝陽區酒仙橋街道

總結:每列都是不可再分的原子值(一個列不可再分,比如通訊地址和省、市、區)

2.第二正規化(2NF)

  • 第二正規化(2NF)是在第一規格化的基礎上建立起來的。
  • 第二正規化(2NF)要求實體的屬性完全依賴與主鍵關聯。所謂完成依賴是指不能存在與存在依賴關鍵字的部分屬性,如果存在那麼這個屬性和關鍵字部分應該分離出來形成一個新的實體,新實體與原實體是一對多的關係。

反例:

產品 ID使用者ID產品名稱使用者姓名購買數量下單時間
1001微波爐 A102王麻子12022-08-08

正例: 訂單表

產品 ID使用者ID購買數量下單時間
100112022-08-08

產品表

產品 ID產品名稱
100微波爐 A102

使用者表

使用者ID使用者姓名
1王麻子

總結:消除列對主鍵的部分函數依賴(對於組合主鍵的部分依賴,比如:產品ID + 使用者ID 為主鍵,存在使用者名稱稱,產品名稱等部分主鍵依賴欄位)

3.第三正規化 (3NF)

  • 滿足第三正規化(3NF)必須滿足第二正規化(2NF)。
  • 第三正規化(3NF) 要求一個資料表中不包含已在其他表中包含的非主鍵關鍵字資訊,即資料不能存在傳遞關係,即每個屬性都跟主鍵有關係直接關係而不是間接關係。

反例:

訂單ID使用者ID產品ID產品名稱產品廠家
11100微波爐 A102美的
22200變頻空調 B101海爾

正例: 訂單表

訂單ID使用者ID產品ID
11100
22200

商品資訊表

產品ID產品名稱產品廠家
100微波爐 A102美的
200變頻空調 B101海爾

總結:消除欄位對非主鍵的傳遞依賴(就是需要取消訂單中比如商品名稱、商品地址等冗餘資訊)。

二、正規化化設計

在真正的資料庫規範定義上,非常的嚴謹,比如第二正規化(2NF)的定義“若某關係 R 術語第一規格化,且每個非主屬性完全函數依賴於候選碼,則關係 R 屬於第二正規化”。

結論:並不是說完全符合規範化理論的設計是最完美的設計,而是要看具體的業務場景反覆實踐總結最合適的設計。

三、反規範化設計

所謂反規範化設計,就是針對規範化而言的。 1、為了效能和讀取效率而適當的違反對資料庫正規化設計的要求; 3、為了查詢的效能,允許存在部分(少量)冗餘資料。換句話說,反規範化設計就是直接用空間換時間。

  • 商品資訊
ID商品名稱商品價格商品描述商品圖片地址
1微波爐 A101$100.99可以加熱食物的微波爐tupian.baidu.com
  • 分類資訊
分類 ID分類名稱
1電器
  • 商品分類對應關係表
商品ID分類ID
11
  • 商品資訊反規範化設計
ID商品名稱分類名稱商品價格商品描述商品圖片地址
11電器$100.99可以加熱食物的微波爐tupian.baidu.com

四、設計總結

  • 資料庫的規劃化正規化設計,在邏輯結構上可以讓結構更加細粒度,容易理解。
  • 但是我們在實際的開發過程中,需要考慮效能和時間成本,往往或多或少,會允許資料冗餘(反規範化設計),通常可以達到 2NF。

到此這篇關於MySQL 資料庫正規化設計理論總結的文章就介紹到這了,更多相關MySQL 資料庫設計內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com!


IT145.com E-mail:sddin#qq.com