資料庫中的第一二三正規化
以前在學校做專案時，用到資料庫時，就CRUD.以為資料真簡單，也就查詢語句有點小複雜，多看看查詢語句就好了，實在不會上網查查，現在想想還是太年輕了。最近來看資料庫，發現好多東西都記不住了。今天在這複習一下，並且寫進部落格，方便以後查閱複習。
知識點
設計關係資料庫時，遵從不同的規範要求，設計出合理的關係型資料庫，這些不同的規範要求被稱為不同的正規化，各種正規化呈遞次規範，越高的正規化資料庫冗餘越小。
目前關係資料庫有六種正規化：第一正規化（1NF）、第二正規化（2NF）、第三正規化（3NF）、巴斯-科德正規化（BCNF）、第四正規化(4NF）和第五正規化（5NF，又稱完美正規化）`。
滿足最低要求的正規化是第一正規化（1NF）。在第一正規化的基礎上進一步滿足更多規範要求的稱為第二正規化（2NF），其餘正規化以次類推。一般說來，資料庫只需滿足第三正規化(3NF）就行了。
今天只瞭解前三個正規化，但是我資料庫學的差，先了解一波關於正規化的資料庫基礎知識。
一定要看下，有助於下面的理解
實體：現實世界中客觀存在並可以被區別的事物。比如“一個學生”、“一本書”、“一門課”等等。值得強調的是這裡所說的“事物”不僅僅是看得見摸得著的“東西”，它也可以是虛擬的，不如說“老師與學校的關係”。
- 還是不理解？其實就是對應資料庫的表，一個實體對應一張表，但是有的時候，有些表不是實體，是實體與實體之間的關係的體現，比如說“老師與學生的關係”。
屬性：教科書上解釋為：“實體所具有的某一特性”，由此可見，屬性一開始是個邏輯概念，比如說，“性別”是“人”的一個屬性。在關係資料庫中，屬性又是個物理概念，
屬性可以看作是“表的一列”，還有一個名稱“欄位”。元組：表中的一行就是一個元組，
對應一張表的一條記錄。分量：元組的某個屬性值。在一個關係資料庫中，它是一個操作原子，即關係資料庫在做任何操作的時候，屬性是“不可分的”。否則就不是關係資料庫了。
碼：表中可以唯一確定一個元組的某個屬性（或者屬性組），如果這樣的碼有不止一個，那麼大家都叫 候選碼，我們從候選碼中挑一個出來做老大，它就叫主碼。
全碼：如果一個碼包含了所有的屬性，這個碼就是全碼。
主屬性：一個屬性只要在任何一個候選碼中出現過，這個屬性就是主屬性。
非主屬性：與上面相反，沒有在任何候選碼中出現過，這個屬性就是非主屬性。
外碼：一個屬性（或屬性組），它不是碼，但是它別的表的碼，它就是外碼。
候選碼： 若關係中的某一屬性或屬性組的值能唯一的標識一個元組，而其任何真子集都不能再標識，則稱該屬性組為（超級碼）候選碼。
關係模式的規範化
如果不進行資料規範化，會產生一些問題：（面試可能會問到）
資料冗餘：一樣的資料一直出現，多餘的資料。
插入異常：如果由於某些原因主鍵暫時還沒有或者還沒全，其他資料也不能插入。
刪除異常：如果一些記錄刪了其他的與之無關的記錄也會被跟著刪掉。
更新異常：一個數據進行了修改需要將所有與該資料有關的元組的該資料全改了，容易出現錯誤。
函式依賴
- 若在一張表中，
在屬性（或屬性組）X的值確定的情況下，必定能確定屬性Y的值，那麼就可以說Y函式依賴於X，寫作 X → Y。
先給個圖，方便以後自己回想。
第一正規化（1NF——不可再分割 ）
定義：資料庫表的每一列都是不可分割的原子資料項，而不能是集合，陣列，記錄等非原子資料項。如果實體中的某個屬性有多個值時，必須拆分為不同的屬性。
通俗點講，就是列不可再分，而且在我們用的資料庫建立的表，都滿足第一正規化，這樣說還是很懵？。比如說一個表：學生表（姓名，性別，電話（行動電話，家庭電話）），可以看到這張表裡有一個屬性電話有兩個值：行動電話，家庭電話，該列就可分的。所以不滿足1NF，為什麼說資料庫的已建立的表滿足1NF就是這個原因，你不可能在一個列裡面建立兩個屬性。
注:這裡說的資料庫指的是**關係型資料**庫
第二正規化 （2NF——無部分依賴 ）
定義：滿足第一正規化前提，且每一個非主屬性完全函式依賴於碼
只有當一個表中，主碼由兩個或以上的屬性組成的時候，才會出現不符合第二正規化的情況。
滿足第一正規化。即滿足列的原子性，不可再分。
表中的每一個非主屬性，必須完全依賴於本表碼。
第三點，要注意了，即沒有包含在主鍵中的列或者說屬性必須完全依賴於主鍵，而不能只依賴於主鍵的一部分。
比如說一個表如下（ 不符合 第二正規化）：
| 學號 | 課程號 | 成績 | 課程名 |
|---|
(錯誤示例)
主鍵：學號、課程號
為啥不滿足第二正規化呢，這個表有兩個非主屬性（成績、課程名）。
- （學號、課程號）—>成績
- （課程號）—>課程名
可以看出課程名依賴課程號，即出現了部分依賴的情況，所有不滿足第二正規化。
所以出現上面這個情況，應該讓怎麼做呢才能滿足第二正規化呢？，我們應該把這個屬性和主關鍵字的這一部分應該分離出來形成一個新的實體，即一張表，這是新實體與原實體之間是一對多的關係。
| 學號 | 課程號 | 成績 |
|---|
分離出這個新的表
| 課程號 | 課程名 |
|---|
第二正規化（2NF）要求實體的屬性完全依賴於主關鍵字。 換句話說，第二正規化就是在第一正規化的基礎上屬性完全依賴於主鍵。
第三正規化（3Nf——無傳遞依賴）
定義：在滿足第二正規化的基礎上，且每一個非主屬性既不部分依賴於碼也不傳遞依賴於碼。
滿足第二正規化
不能出現，非主鍵列 A 依賴於非主鍵列 B，非主鍵列 B 依賴於主鍵的情況。
ep：
| 學號 | 系別 | 系主任 |
|---|
主鍵：學號
該示例是不滿足第三正規化，其中有如下關係：
系主任可以有系別確定，系別也可以由學號確定。即
學號—>系別—>系主任
出現傳遞依賴，所有不滿足第三正規化。符合3NF要求的資料庫設計，基本上解決了資料冗餘過大，插入異常，修改異常，刪除異常的問題。
補充
BCNF正規化(來自知乎解答)
要了解 BCNF 正規化，那麼先看這樣一個問題：
ep：
- 某公司有若干個倉庫；
- 每個倉庫只能有一名管理員，一名管理員只能在一個倉庫中工作；
- 一個倉庫中可以存放多種物品，一種物品也可以存放在不同的倉庫中。每種物品在每個倉庫中都有對應的數量。
那麼關係模式 倉庫（倉庫名，管理員，物品名，數量） 屬於哪一級正規化？
已知函式依賴集：倉庫名 → 管理員，管理員 → 倉庫名，（倉庫名，物品名）→ 數量
碼：（管理員，物品名），（倉庫名，物品名） 主屬性：倉庫名、管理員、物品名 非主屬性：數量
不存在非主屬性對碼的部分函式依賴和傳遞函式依賴。∴ 此關係模式屬於3NF。
| 倉庫名 | 管理員 | 物品名 | 數量 |
|---|
既然此關係模式已經屬於了 3NF，那麼這個關係模式是否存在問題呢？
我們來看以下幾種操作：
先新增加一個倉庫，但尚未存放任何物品，是否可以為該倉庫指派管理員？——不可以，因為物品名也是主屬性，根據實體完整性的要求，主屬性不能為空。
某倉庫被清空後，需要刪除所有與這個倉庫相關的物品存放記錄，會帶來什麼問題？——倉庫本身與管理員的資訊也被隨之刪除了。
如果某倉庫更換了管理員，會帶來什麼問題？——這個倉庫有幾條物品存放記錄，就要修改多少次管理員資訊。
從這裡我們可以得出結論，在某些特殊情況下，即使關係模式符合 3NF 的要求，仍然存在著插入異常，修改異常與刪除異常的問題，仍然不是 ”好“ 的設計。
造成此問題的原因：存在著主屬性對於碼的部分函式依賴與傳遞函式依賴。
（在此例中就是存在主屬性【倉庫名】對於碼【（管理員，物品名）】的部分函式依賴。
解決辦法就是要在 3NF 的基礎上消除主屬性對於碼的部分與傳遞函式依賴。
倉庫（倉庫名，管理員）
| 倉庫名 | 管理員 |
|---|
庫存（倉庫名，物品名，數量）
| 倉庫名 | 物品名 | 數量 |
|---|
這樣，之前的插入異常，修改異常與刪除異常的問題就被解決了。
這裡通俗點的講下自己的理解。
BCNF：滿足3NF，且滿足主屬性不依賴主屬性
即：BCNF既判斷非主屬性，又判斷主屬性。當只判斷非主屬性時，就成了第三正規化。
還可以這麼說：若一個關係達到了第三正規化，並且它只有一個候選碼，或者它的每個候選碼都是單屬性(非多個屬性組合而成的候選碼)，則該關係自然達到BCNF。
先總結到這裡。