SQL基礎隨記3 範式 鍵 什麼是範式？哈，自己設計會使用但是一問還真說不上來。遂將不太明晰的概念整體下 什麼是 & 分類 範式（NF），一種規範，設計資料庫模型時對關係內部各個屬性之間的聯繫的合理化程度的不同等級的規範要求。 分類： 1NF、2NF、3NF、BCNF（巴斯科德範式）、4NF、5NF ...
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查詢效率極低，很少用到，開發效率和查詢效率都很感人。
反範式
一般情況下，業務界面會顯示用戶姓名而不是用戶ID，因此常常需要將user表與其他表連接查詢。因此當數據量較大時可以將user id 與 use name 在其他常用表中“冗餘"，這樣可以只進行單表掃描。而不用在大數據量的情況下再連接查詢。
反範式設計與數據倉庫
數據倉庫與資料庫的區別：
- 資料庫用於捕獲數據，數據倉庫用於分析數據
- 資料庫對增刪改實時性要求強，需要存儲線上的用戶數據。數據倉庫一般是歷史數據
- 資料庫要儘量避冗餘，數據倉庫的設計上更偏向反範式設計，因為歷史數據往往很多。連接查詢會大幅度拖慢速度。
