當(dāng)前位置:
首頁 >
从第一范式到第二范式所做的操作是_给女同事讲解MySQL数据库范式与反范式,她直夸我“技术好”
發(fā)布時間:2023/12/19
55
豆豆
生活随笔
收集整理的這篇文章主要介紹了
从第一范式到第二范式所做的操作是_给女同事讲解MySQL数据库范式与反范式,她直夸我“技术好”
小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.
1 第一范式
該范式是為了排除 重復(fù)組 的出現(xiàn),因此要求數(shù)據(jù)庫的每個列的值域都由原子值組成;每個字段的值都只能是單一值。1971年埃德加·科德提出了第一范式。即表中所有字段都是不可再分的。
1.1 實例
重復(fù)組通常會出現(xiàn)在會計賬上,每一筆記錄可能有不定個數(shù)的值。
- 舉例來說:
“數(shù)量”就是所謂的重復(fù)組了,而在這種情況下這份資料就不符合第一范式。
- 再比如,如下聯(lián)系方式是一個復(fù)合屬性,就違反了該范式,在數(shù)據(jù)庫中是無法分離出來的。
1.2 解決方案
- 想要消除重復(fù)組的話,只要把每筆記錄都轉(zhuǎn)化為單一記錄即可:
- 簡單改動即可
即標(biāo)準(zhǔn)的二維表結(jié)構(gòu)。
2 第二范式
前提:標(biāo)準(zhǔn)的二維表,即第一范式成立
表中必須存在業(yè)務(wù)主鍵,并且非主鍵依賴于全部業(yè)務(wù)主鍵。
2.1 實例
如下博客表
- 用戶字段作為PK是否可行?
一個用戶會對應(yīng)多個博客記錄,且章節(jié)標(biāo)題也能為多個用戶所編輯,所以單列字段PK失效 - 的聯(lián)合PK
用戶積分字段只和用戶字段依賴,并不依賴整體的PK,依舊不符第二范式
2.2 解決方案
拆分將依賴的字段單獨成表
從上面可發(fā)現(xiàn):
- 若表的PK只有一個字段,那么它本就符合第二范式
- 若是多個字段組成,則需考慮是否符合第二范式
3 第三范式
表中的非主鍵列之間不能相互依賴
3.1 實例 - 課程表
一個字段的PK顯然符合第二范式,大部分字段也只依賴PK。然而對于職位字段其實依賴講師名,所以不符合第三范式。
3.2 解決方案
- 將不與PK形成依賴關(guān)系的字段直接提出單獨成表即可:
4 三范式評價
優(yōu)點
- 范式化的更新通常比反范式快
- 當(dāng)數(shù)據(jù)較好的范式化后,很少或者沒有冗余數(shù)據(jù)
- 范式化的數(shù)據(jù)比較小,放在內(nèi)存中操作較快
缺點
- 通常需要進(jìn)行關(guān)聯(lián)
畢竟阿里規(guī)范提到
5 反范式(空間換時間)
反范式的過程就是通過冗余數(shù)據(jù)來提高查詢性能,但冗余數(shù)據(jù)會犧牲數(shù)據(jù)一致性
優(yōu)點
- 所有的數(shù)據(jù)都在同一張表中,可以減少表關(guān)聯(lián)
- 更好進(jìn)行索引優(yōu)化
缺點
- 存在大量冗余數(shù)據(jù)
- 數(shù)據(jù)維護(hù)成本更高(刪除異常,插入異常,更新異常)
在企業(yè)中很好能做到嚴(yán)格意義上的范式成者反范式,一般需混合使用。
6 綜合案例
范式設(shè)計
- 用戶表
用戶ID、姓名、電話、地址、郵箱 - 訂單表
訂單ID、用戶ID、下單時間、支付類型、訂單狀態(tài) - 訂單商品表
訂單ID、商品 ID、商品價格 - 商品表
商品ID、名稱、描述、過期時間
反范式設(shè)計
- 用戶表
用戶ID、姓名、電話、地址、郵箱 - 訂單表
訂單ID、用戶ID、下單時間、支付類型、訂單狀態(tài)、訂單價格、用戶名、電話、地址 - 訂單商品表
訂單ID、商品 ID、商品數(shù)量、商品價格 - 商品表
商品ID、名稱、描述、過期時間
把用戶表的地址加到了訂單表,這樣查詢地址時,就不需要把用戶表和訂單表關(guān)聯(lián)
參考
- 第一范式
總結(jié)
以上是生活随笔為你收集整理的从第一范式到第二范式所做的操作是_给女同事讲解MySQL数据库范式与反范式,她直夸我“技术好”的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: “docker-app”实用工具分享,大
- 下一篇: nodejs redis 过期时间_别在