文章目錄
- 範式理論
-
-
-
- 何為範式，何為模組化
- 函數依賴
-
- 1. 完全函數依賴
- 2. 部分函數依賴
- 3. 傳遞函數依賴
- 第一範式
- 第二範式
- 第三範式
-
-
範式理論
何為範式，何為模組化
範式理論和誰有關？和關系模組化有關，通常我們說的三範式是啥東西，啥叫範式。
所謂的範式，就是我們在關系模組化的時候所遵從的一些規範。
所謂的模組化，就是意思是，你要建哪些表，每張表與每張表的關系是什麼樣的。每張表裡大概又哪些字段，這就是所謂的資料庫模組化。
而關系型資料庫設計時，遵照一定的規範要求，目的在于降低資料的備援性。
為什麼要降低資料備援性？
優點：
😀😀😀😀😀😀😀
（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，但是我們的資料備援确實沒有了。