SQL基礎隨記3 范式 鍵
什么是范式？哈，自己設計會使用但是一問還真說不上來，遂將不太明晰的概念整體下
什么是 & 分類
范式（NF），一種規范，設計資料庫模型時對關系內部各個屬性之間的聯系的合理化程度的不同等級的規范要求，
分類：
- 1NF、2NF、3NF、BCNF（巴斯科德范式）、4NF、5NF（完美范式）
低階范式是高階范式的基礎，范式等級越高冗余度越低，使用時越容易進行join
鍵
- 超鍵：能唯一表示元組（元組也就是一行資料，一條記錄）的屬性的集合，超鍵可能包含多余屬性，如身份證號+學生id+姓名
- 候選鍵：不包含多余屬性的超鍵，候選鍵可能不唯一，身份證號或學生id都可以當做候選鍵，
- 主鍵
- 外鍵
屬性
- 主屬性：任意候選鍵的屬性就是主屬性
- 非主屬性
依賴
- 依賴：一個或一組屬性的值決定其他屬性的值
- 完全依賴：某個非主屬性于所有主屬性
- 部分依賴
- 傳遞依賴：若存在 "A>>B>>C"的依賴關系，則C傳遞依賴于A
Each NF
-
1NF：表中任何屬性都是原子性的（不可拆分的），所有 RDBMS都滿足，
-
2NF：任意一個非主屬性都要與
主屬性/候選鍵完全依賴，消除非主屬性對候選碼的部分依賴，若不滿足2NF會造成
-
資料冗余
-
增刪改例外
不滿足2NF舉例
球員id決定球員姓名等球員個人資訊
比賽id決定比賽時間、比賽場地等比賽資訊
若將上述所有屬性放在一張表中就會造成
-
資料冗余：例外比賽有n個球員參加，那么記錄該場比賽n個球員資訊時，對應的比賽資訊就多余了n-1次
-
增刪改例外：僅根據球員id或比賽id進行操作時，
增：不知道另一個主屬性導致無法插入
刪：會洗掉另一個主屬性以及其對應的資訊
改：修改資訊時，有改資訊的所有記錄都要修改
-
-
-
3NF：在第二范式的基礎上，任意一個非主屬性都不傳遞依賴于候選鍵
不滿足3NF但滿足2NF舉例
表1：球員id、球員姓名、球隊名稱、主教練姓名
球員姓名、球隊名稱、主教練姓名都可以由球員id決定
但是主教練姓名也可以通過球隊名稱決定，這就出現了傳遞依賴
如果我們將表1拆分成
表2：球員id、球員姓名、球隊名稱
表3：球隊名稱、主教練名稱
則滿足3NF
致命總結
在第一范式的基礎上，根據"非主完全依賴主屬性"對所有屬性進行劃分并給每張表加id就滿足第二范式，再細分屬性消除傳遞依賴加上FOREIGN KEY就滿足第三范式
BCNF、4NF、5NF查詢效率極低，很少用到，開發效率和查詢效率都很感人，
1NF + 消去非主屬性對鍵的部分函式依賴 = 2NF，即2NF中，非主屬性完全依賴于主關鍵字；
2NF + 消去非主屬性對鍵的傳遞函式依賴 = 3NF，即3NF中，屬性不依賴于其它非主屬性，傳遞函式依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函式依賴于A；
3NF + 消去主屬性對鍵的傳遞函式依賴 = BCNF，BCNF是3NF的改進形式，即在3NF的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函式依賴則符合BCNF，
反范式
一般情況下，業務界面會顯示用戶姓名而不是用戶ID，因此常常需要將user表與其他表連接查詢，因此當資料量較大時可以將user id 與 use name 在其他常用表中“冗余"，這樣可以只進行單表掃描，而不用在大資料量的情況下再連接查詢，
反范式在OLAP場景比較常用，詳見此處，另見此處
反范式設計與資料倉庫
資料倉庫與資料庫的區別：
- 資料庫用于捕獲資料，資料倉庫用于分析資料
- 資料庫對增刪改實時性要求強，需要存盤在線的用戶資料，資料倉庫一般是歷史資料
- 資料庫要盡量避冗余，資料倉庫的設計上更偏向反范式設計，因為歷史資料往往很多，連接查詢會大幅度拖慢速度，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/16381.html
標籤：MySQL
上一篇：更新多張表中同樣欄位內的值
下一篇：MySQL學習筆記（10）：視圖