1 第一范式

該范式是為了排除 重復組 的出現，因此要求數據庫的每個列的值域都由原子值組成；每個字段的值都只能是單一值。1971年埃德加·科德提出了第一范式。即表中所有字段都是不可再分的。

1.1 實例

重復組通常會出現在會計賬上，每一筆記錄可能有不定個數的值。

舉例來說：

“數量”就是所謂的重復組了，而在這種情況下這份資料就不符合第一范式。

再比如，如下聯系方式是一個復合屬性，就違反了該范式，在數據庫中是無法分離出來的。

1.2 解決方案

想要消除重復組的話，只要把每筆記錄都轉化為單一記錄即可：

簡單改動即可

即標準的二維表結構。

2 第二范式

前提：標準的二維表，即第一范式成立

表中必須存在業務主鍵，并且非主鍵依賴于全部業務主鍵。

2.1 實例

如下博客表

用戶字段作為PK是否可行?

一個用戶會對應多個博客記錄，且章節標題也能為多個用戶所編輯，所以單列字段PK失效

的聯合PK

用戶積分字段只和用戶字段依賴，并不依賴整體的PK，依舊不符第二范式

2.2 解決方案

拆分將依賴的字段單獨成表

從上面可發現:

若表的PK只有一個字段，那么它本就符合第二范式

若是多個字段組成，則需考慮是否符合第二范式

3 第三范式

表中的非主鍵列之間不能相互依賴

3.1 實例 - 課程表

一個字段的PK顯然符合第二范式，大部分字段也只依賴PK。然而對于職位字段其實依賴講師名，所以不符合第三范式。

3.2 解決方案

將不與PK形成依賴關系的字段直接提出單獨成表即可：

4 三范式評價

優點

范式化的更新通常比反范式快

當數據較好的范式化后，很少或者沒有冗余數據

范式化的數據比較小，放在內存中操作較快

缺點

通常需要進行關聯

畢竟阿里規范提到

5 反范式(空間換時間)

反范式的過程就是通過冗余數據來提高查詢性能，但冗余數據會犧牲數據一致性

優點

所有的數據都在同一張表中，可以減少表關聯

更好進行索引優化

缺點

存在大量冗余數據

數據維護成本更高(刪除異常，插入異常，更新異常)

在企業中很好能做到嚴格意義上的范式成者反范式，一般需混合使用。

6 綜合案例

在一個網站實例中， 這個網站允許用戶發送消息，井且一些用戶是付費用戶。現在想查看付費用戶最近的10條信息。在user表 和message表中都存儲用戶類型(account type)，而不用完全的反范式化。這避免了完全反范式化的插入和刪除問題，因為即使沒有消息的時候也不會丟失用戶信息。這樣也不會把user_message表搞得太大，有助高效獲取數據

另一個從父表冗余些數據到子表的理由是排序的需要

緩存衍生值也是有用的。如果需要顯示每個用戶發了多少消息(類似論壇)，可以每次執行一個昂貴的子查詢來計算并顯示它；也可以在user表中建個num_messages列，每當用戶發新消息時更新這個值。

范式設計

用戶表

用戶ID、姓名、電話、地址、郵箱

訂單表

訂單ID、用戶ID、下單時間、支付類型、訂單狀態

訂單商品表

訂單ID、商品 ID、商品價格

商品表

商品ID、名稱、描述、過期時間

SELECT b.用戶名, b.電話, b.地址, a.訂單ID,

SUM(c.商品價價*C.商品數量) as 訂單價格

// 上面這就需要三張表的關聯了,可能效率就很低了

FROM‘訂單表` a

JOIN‘用戶表’b ON a用戶ID=b.用戶ID

JOIN `訂單商品表` C ON c.訂單ID= b.訂單ID

GROUP BY b.用戶名，b.電話b.地址,a.訂單ID

反范式設計

用戶表

用戶ID、姓名、電話、地址、郵箱

訂單表

訂單ID、用戶ID、下單時間、支付類型、訂單狀態、訂單價格、用戶名、電話、地址

訂單商品表

訂單ID、商品 ID、商品數量、商品價格

商品表

商品ID、名稱、描述、過期時間

SELECT a.用戶名,a.電話.a.地址

,a.訂單ID

,a.訂單價格

FROM `訂單表` a

把用戶表的地址加到了訂單表，這樣查詢地址時，就不需要把用戶表和訂單表關聯

參考

第一范式

總結

以上是生活随笔為你收集整理的mysql范式与反范式_给女同事讲解MySQL数据库设计范式与反范式，她夸我“技术好”...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。