|
什么是范式？哈，自己設(shè)計(jì)會使用但是一問還真說不上來。遂將不太明晰的概念整體下
什么是 & 分類
范式（NF），一種規(guī)范，設(shè)計(jì)數(shù)據(jù)庫模型時對關(guān)系內(nèi)部各個屬性之間的聯(lián)系的合理化程度的不同等級的規(guī)范要求。
分類：
- 1NF、2NF、3NF、BCNF（巴斯科德范式）、4NF、5NF（完美范式）
低階范式是高階范式的基礎(chǔ)，范式等級越高冗余度越低，使用時越容易進(jìn)行join
鍵
- 超鍵：能唯一表示元組（元組也就是一行數(shù)據(jù)，一條記錄）的屬性的集合。超鍵可能包含多余屬性。如身份證號+學(xué)生id+姓名
- 候選鍵：不包含多余屬性的超鍵。候選鍵可能不唯一，身份證號或?qū)W生id都可以當(dāng)做候選鍵。
- 主鍵
- 外鍵
屬性
依賴
- 依賴：一個或一組屬性的值決定其他屬性的值
- 完全依賴：某個非主屬性于所有主屬性
- 部分依賴
- 傳遞依賴：若存在 "A>>B>>C"的依賴關(guān)系，則C傳遞依賴于A
Each NF
-
1NF：表中任何屬性都是原子性的（不可拆分的），所有 RDBMS都滿足。
-
2NF：任意一個非主屬性都要與主屬性/候選鍵完全依賴，消除非主屬性對候選碼的部分依賴。
若不滿足2NF會造成
-
數(shù)據(jù)冗余
-
增刪改異常
不滿足2NF舉例
球員id決定球員姓名等球員個人信息
比賽id決定比賽時間、比賽場地等比賽信息
若將上述所有屬性放在一張表中就會造成
-
數(shù)據(jù)冗余：異常比賽有n個球員參加，那么記錄該場比賽n個球員信息時，對應(yīng)的比賽信息就多余了n-1次
-
增刪改異常：僅根據(jù)球員id或比賽id進(jìn)行操作時，
增：不知道另一個主屬性導(dǎo)致無法插入
刪：會刪除另一個主屬性以及其對應(yīng)的信息
改：修改信息時，有改信息的所有記錄都要修改
-
3NF：在第二范式的基礎(chǔ)上，任意一個非主屬性都不傳遞依賴于候選鍵
不滿足3NF但滿足2NF舉例
表1：球員id、球員姓名、球隊(duì)名稱、主教練姓名
球員姓名、球隊(duì)名稱、主教練姓名都可以由球員id決定
但是主教練姓名也可以通過球隊(duì)名稱決定，這就出現(xiàn)了傳遞依賴
如果我們將表1拆分成
表2：球員id、球員姓名、球隊(duì)名稱
表3：球隊(duì)名稱、主教練名稱
則滿足3NF
致命總結(jié)
在第一范式的基礎(chǔ)上，根據(jù)"非主完全依賴主屬性"對所有屬性進(jìn)行劃分并給每張表加id就滿足第二范式，再細(xì)分屬性消除傳遞依賴加上FOREIGN KEY就滿足第三范式
BCNF、4NF、5NF查詢效率極低，很少用到，開發(fā)效率和查詢效率都很感人。
1NF + 消去非主屬性對鍵的部分函數(shù)依賴 = 2NF。即2NF中，非主屬性完全依賴于主關(guān)鍵字；
2NF + 消去非主屬性對鍵的傳遞函數(shù)依賴 = 3NF。即3NF中，屬性不依賴于其它非主屬性。傳遞函數(shù)依賴，指的是如果存在"A → B → C"的決定關(guān)系，則C傳遞函數(shù)依賴于A；
3NF + 消去主屬性對鍵的傳遞函數(shù)依賴 = BCNF。BCNF是3NF的改進(jìn)形式，即在3NF的基礎(chǔ)上，數(shù)據(jù)庫表中如果不存在任何字段對任一候選關(guān)鍵字段的傳遞函數(shù)依賴則符合BCNF。
反范式
一般情況下，業(yè)務(wù)界面會顯示用戶姓名而不是用戶ID，因此常常需要將user表與其他表連接查詢。因此當(dāng)數(shù)據(jù)量較大時可以將user id 與 use name 在其他常用表中“冗余"，這樣可以只進(jìn)行單表掃描。而不用在大數(shù)據(jù)量的情況下再連接查詢。
反范式在OLAP場景比較常用，詳見此處，另見此處
反范式設(shè)計(jì)與數(shù)據(jù)倉庫
數(shù)據(jù)倉庫與數(shù)據(jù)庫的區(qū)別：
- 數(shù)據(jù)庫用于捕獲數(shù)據(jù)，數(shù)據(jù)倉庫用于分析數(shù)據(jù)
- 數(shù)據(jù)庫對增刪改實(shí)時性要求強(qiáng)，需要存儲在線的用戶數(shù)據(jù)。數(shù)據(jù)倉庫一般是歷史數(shù)據(jù)
- 數(shù)據(jù)庫要盡量避冗余，數(shù)據(jù)倉庫的設(shè)計(jì)上更偏向反范式設(shè)計(jì)，因?yàn)闅v史數(shù)據(jù)往往很多。連接查詢會大幅度拖慢速度。
|
