範式理論
何爲範式，何爲建模
範式理論和誰有關？和關係建模有關，通常我們說的三範式是啥東西，啥叫範式。
所謂的範式，就是我們在關係建模的時候所遵從的一些規範。
所謂的建模，就是意思是，你要建哪些表，每張表與每張表的關係是什麼樣的。每張表裏大概又哪些字段，這就是所謂的數據庫建模。
而關係型數據庫設計時，遵照一定的規範要求，目的在於降低數據的冗餘性。
爲什麼要降低數據冗餘性？
優點：
😀😀😀😀😀😀😀
（1）十幾年前，磁盤很貴，爲了減少磁盤存儲。
（2）以前沒有分佈式系統，都是單機，只能增加磁盤，磁盤個數也是有限的
（3）一次修改，需要修改多個表，很難保證數據一致性
缺點：
😭😭😭😭😭😭😭
範式的缺點是獲取數據時，需要通過Join拼接出最後的數據。
分類：
目前業界範式有：第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)、第五範式(5NF)。
我們通常說的遵循三範式，就是遵循第一範式，第二範式，第三範式。
遵循三範式優缺點是什麼？
可以降低數據冗餘，但是表結構變的比較複雜，表會被拆成比較細碎的小表，查詢數據的時候會涉及到多表Join，這樣一來，我們肯定要走Shuffle。然後效率會變低。因爲比較損耗性能。
現在條件好了，很多公司也並沒有嚴格的遵循三範式。現在關係型數據庫也遵循分庫分表等操作，也支持類似集羣的搭建了。擴展能力增強，不講究什麼冗餘不冗餘。冗餘了，就不用拆表了，就可以減少一部分的Join。查詢性能得到很大的提高。所以允許部分冗餘的存在。
函數依賴
函數依賴，三範式中用到的，非常重要的理論。這裏的函數，就是數學當中函數的概念。關係型模型，裏面是有數學理論基礎的，來，補個課吧，啥叫函數。廢話不多，直接上圖。
這叫正常函數，一個X只能映射到一個Y。
這就不叫我們熟知的函數了，可能叫醜函數。長的那麼醜，三里屯門都不讓進。這一個X對應了多個Y。
看錶，我們來簡單理解下以下的概論。
| 學號 | 姓名 | 系名 | 系主任 | 課名 | 分數 |
|---|---|---|---|---|---|
| 202099999 | 小李 | 公關 | 張三 | 喝酒 | 90 |
| 202088888 | 小王 | DJ | 李四 | 打碟 | 95 |
1. 完全函數依賴
通過學號，課程，就可以推出分數，但是，分數反向獲取，獲取不到對應的值，我知道分數，我也不知道誰得的這個分數，這個分數是哪個課程的分數，但是我通過學號就知道，我們就說分數，完全依賴於學號和課程。
2. 部分函數依賴
通過學號和課程，可以推出姓名，啥意思？通過學號和課程，我可以找到是誰。其實我直接通過學號也可以找到姓名，用不着再知道課程，這時，我們就說姓名，部份依賴於學號、課程。
3. 傳遞函數依賴
通過學號推出系名，通過系名推出系主任。但是通過系主任推不出學號，系主任主要依賴的是系名，這種情況，系主任傳遞依賴於學號。
爲什麼會給大家說這個函數依賴關係。
如果在我們的表中，出現了部份函數依賴，或者是傳遞函數依賴，那麼我們的數據就會冗餘。只有我們的表中是完全依賴關係的時候，我們的數據纔不會冗餘。
第一範式
第一範式1NF核心原則就是：屬性不可切。
第一範式，沒有用到我們上面的函數依賴關係。這裏所謂的屬性，就是我們表中的字段，字段內容是不可切的，字段必須是原子性的，我們舉個例子。
上圖這張表明顯不符合第一範式的標準，爲什麼呢，因爲我們有的字段還可以拆啊，商品字段底下，它將商品的數量和種類放在了一起。這很顯然就不是原子性的了，想變成原子性怎麼辦？拆開就好了。看下圖
在Mysql還有Oracle、SQL Server中如果數據庫的表不符合這個最基本的要求，那麼，操作時一定不能成功的，也就是說，在RDBMS中存在的表，一定符合1NF的。
第二範式
第二範式2NF核心原則就是：不能存在部分函數依賴
在我們的表中，我們的X和我們的Y分別指的時誰呢？X指的時我們這張表的主鍵，Y指的就是非主鍵字段，那麼我們剛纔的那句核心的話，我們翻譯過來就是，不能存在非主鍵字段不能出現部份函數依賴於主鍵字段。
我們看下面這張表。
我們尋找以下非主鍵字段與主鍵字段依賴關係，我們得先明確誰時主鍵，想到學號的，都太年輕，爲啥不能是學號，學號要是主鍵是不是不能重複啊。那麼是什麼呢？答案是聯合主鍵，學號和課名一起作爲聯合主鍵，學號和課名加一起能夠唯一標識我們的一行數據，比如：學號和課名加一起，可以找到分數。
我們找一下依賴關係，我們的學號和課名應該作爲X，剩下的字段都可以作爲Y，那麼，我們學號和課名加一起，可不可以找到姓名？可以的，可不可以找到系主任，也是可以的。那麼這個是部份函數依賴，我通過學號一個就可以找到姓名。那麼我們呢第二範式要求是不能存在部份函數依賴的。所以，我們要變成下面這張表。把它切了。
我之所以這麼切，是不是因爲我通過學號就可以推出系主任、姓名啥的。那麼這個是不是就不是部份函數依賴了。而且我同樣的信息只出現了一次。但是我們還是沒有消除徹底，但是我們達到了第二範式的要求。
第三範式
第三範式3NF核心原則：不能存在傳遞函數依賴
我們的表，經過了第一範式、第二範式、第三範式之後只剩下了完全函數依賴，最終，我們的表中只能剩下完全函數依賴，不能有傳遞，不能有部份。
不能傳遞函數依賴，我們給他補充完整就是，表裏面不能存在非主鍵字段傳遞依賴於主鍵字段，X還是主鍵，Y還是非主鍵。看下面這張表。
這張表中，很鮮明還是有數據冗餘現象，但是我們已經滿足第二範式了，那肯定不是第二範式的事了，是第三範式，我們現在就看一看，把它變成第三範式，那麼我們怎麼從一張表中去找，所謂的傳遞函數依賴，照這個要麻煩一些，涉及到傳遞了，我們應該把表中的所有的函數依賴全部找到，才能發現傳遞的關係，所以我們得找到他們，我們這裏說的並不僅僅是我們的聯合主鍵或者主鍵，其他字段也要找。
我們看一下，學號能推出姓名，系名，系主任，下一步，我們以姓名爲自變量。
我們拿到姓名，能拿到它的學號麼？這個其實是不能的，我們要考慮到重名的現象，好比給我們好幾個叫關羽的，那麼會不會返回多個學號？這是不是相當於一個X對應多個Y了，連函數都不是，更別提函數依賴這回事，姓名同樣也推不出來系名，系主任。
那我們再看一下，我們的系名能不能推出系主任，假定我們一個系只有一個系主任的情況下，這種情況下是能推出的，給我們一個系名，我們就可以完全的確定一個系主任，所以這個是存在函數依賴關係的。
那我們再看一下以系主任作爲X自變量，那麼系主任有重名，有重名就不能作爲X。
那麼我們尋找一下依賴關係，學號和系名，系名和系主任，很顯然是一個傳遞依賴關係。我們的要求是不能存在這種關係，怎麼辦？拆！
最終拆成上面的這種情況，我們由一張表，最後拆成了三張表，我們如果像查詢數據，就得三張表進行Join，但是我們的數據冗餘確實沒有了。
