參考文章：
三正規化是對關係型資料庫表結構設計的一種規範制約，設計出的資料表如果滿足正規化的標準，則稱某資料庫表滿足第一（二、三）正規化。數字越大，標準越嚴格。且第一正規化、第二正規化、第三正規化是乙個遞進的過程，滿足第一正規化後，才能去
評價是否滿足第二正規化。
每乙個屬性都是不可再分割的，這是構成資料庫表的必要條件。換句話說，能放進資料庫裡的表，都滿足第一正規化。
摘乙個圖過來
這種就不滿足第一正規化。進貨不能作為屬性，需要拆分成進貨表，銷售也同樣如此。
滿足一正規化後，就可以將你抽象的設計具體化，可以將你的想法付諸實踐，形成具體的表結構，存進資料庫了。現有表結構：學生表，學生表的內容為
可以發現，每人每門課的成績，都會不厭倦地帶上繫名、系主任等資訊，很累贅、很繁瑣。
這樣設計表結構會給業務帶來什麼影響呢？
1、資料冗餘
2、插入異常——現在學校決定新建乙個系了，還沒來及的招收學生，便無法將系資訊單獨的插進去。
3、刪除異常——如果此時決定將一批學生的成績資訊全部刪除，那麼同時也將會刪除該學生所在系的相關資訊，這不是我們想看到的。
4、修改異常——如果此時，李明想要轉系了，那麼只要是關於李明的成績記錄。都需要修改系資訊。
這個時候，我們就需要引入第二正規化的概念了。
在第一正規化的基礎上，清除了非主屬性對於碼的部分函式依賴。
如果a屬性的值確定，那麼b屬性的值也確定，稱作b依賴於a。這樣來看可能有點繞，按照我們思維習慣，可以這麼理解，a決定了b，所以a有主導權，b就依賴a。
上述表有哪些函式依賴呢？
姓名 依賴於 學號 （學號知道了，姓名也就知道了）
系主任 依賴於 學號 （學號知道了，系主任自然知道了）
分數 依賴於 （學號、課名） （知道課名，學號，必然知道分數了）
分數依賴於（學號、課名），只要在知道學號和具體哪一門課的前提下，才能知道分數，缺一不可，這就是完全依賴。
表面上姓名部分依賴於（學號，課名），但其實姓名只依賴於學號，這就叫部份依賴。
x 依賴於y， y依賴於 z，在 y不依賴於x的前提下， x依賴於z
碼可能是乙個屬性，也可能是乙個屬性組（多個屬性的組合）。如果碼確定了，那麼屬性也確定了。哎~，這不就是主鍵嗎？
並不能這麼說，比如一張表裡有身份證、學號， 學號和身份證都能表示唯一性，知道任意乙個，就可以鎖定到這個學生。
我們在選擇主鍵的時候，身份證和學號並不會都用，只會選擇其一。所以我們所說的主鍵其實是碼的乙個子集。
碼的乙個成員
不是碼的成員。
現在可以來理解第二正規化的定義了：是否存在非主屬性對碼的部分函式依賴。
判斷是否滿足第二正規化，需要經過一下幾個步驟：
找到表中的碼，（學號、課名）
主屬性：學號、課名
非主屬性：姓名、系名、系主任、分數
分析非主屬性是否對碼有部份依賴
姓名，只依賴於學號，有部分依賴
系名，只依賴於學號，有部份依賴
系主任，只依賴於學號，有部份依賴
分數，依賴於學號、課程，沒有部份依賴
目前的表結構，並不滿足第二正規化，姓名、系名、系主任，這些非主屬性居然對碼有部分依賴，注定是要被踢出來的。
改造分數表
學生表分析：我們從第二正規化的定義入手，分析表屬性，將一張表拆分成了兩張表。仔細一看，從業務上將，無非就是將學生資訊與學生成績拆分下來。
可是拆分的並不徹底，還是存在一些問題。
如果刪除了某個系所有學生資訊，那麼這個系的資訊也會消失。系資訊與學生資訊耦合在一起。我們將一步改造這張表，使其滿足第三正規化。
第三正規化在第二正規化的基礎上，消除了非主屬性對於碼的傳遞函式依賴。
成績表已經沒有耦合，除了主碼，就剩乙個分數字段了，且對碼沒有部份依賴，不需要改造。那我們重點分析一下成績表
分析主碼：學號
主屬性：學號
非主屬性：姓名、系名、系主任
學號知道了，系名就知道了；系名知道了，系主任就知道了。
系主任依賴系名，系名依賴學號。存在非主屬性對於碼的傳遞依賴。
因此學生表不符合第三正規化，進一步拆分：
學生表係表
在經過多次拆分後，現有的三張表分別是：成績表、學生表、係表。解決了冗餘、插入一場、修改異常、刪除異常等多種問題。
bcnf正規化的目的在於，消除主屬性對於碼的部分和傳遞函式依賴。
舉例：某公司有若干倉庫，需要派人管理，乙個管理員只能管理乙個倉庫，各個倉庫可以存放相同的物品。（原文中用的是管理員名，但是名字可能會重複，所以把它換成工號。）
碼：（管理員工號，物品名）、（物品名，倉庫名）
主屬性：倉庫、管理員工號、物品名
非主屬性：數量
不存在非主屬性對碼的傳遞依賴、部份依賴，滿足第三正規化。但是依然存在問題：
雖說乙個倉庫只有乙個管理員，且乙個管理員只能管理乙個倉庫，但是這個管理員可能會有變動，如果哪一天某個倉庫換了個管理員，那麼這個倉庫有幾條物品記錄，就需要修改多少條資料。究其根本，還是因為耦合的問題。
bcnf正規化，要求消除主屬性對於碼的部份依賴和傳遞依賴。倉庫名是乙個主屬性，依賴於管理員工號，也依賴於物品名。那麼就將倉庫和倉庫管理員拆分出來。
倉庫表庫存表
正規化是一種規範，一種約束。但是在實際專案中，可能會出現各種各樣的情況，我們不必死守規範，而應當靈活變通。
按照正規化來設計資料表，本質上就是一種解耦的過程。正規化的好處就是，明確定義了這個耦合的程度，以及我們如何降低這個耦合。一正規化，二正規化、三正規化是解耦的過程。bcnf正規化是第
二、第三正規化的一種補充。
多說幾句，如果在工作中，我可能不會從正規化的角度入手，而是從業務本身來設計資料表，例如第乙個例子，有哪些是很少變化的，有哪些是經常變化的。系名、系主任這是繫結在一起的，是乙個整體的概念，代表「系」，且很少變化。其次就是學生，學生除非跨年級、畢業，一般也不會變化，是乙個整體的概念。最後是成績，學生可能有好幾門課，每門課都可以被多個人選，是多對多的概念，所以抽象出成績表，將學生與課程關聯起來。
不管是學習還是工作中，設計資料庫的時候可能會從常識的角度，或者從業務需求的角度入手。在我們設計出表後，需要進一步考慮其合理性，這個時候就可以換乙個思維，從正規化的角度來看這些表，結合實際情況做優化。
如有錯誤，懇請指出。
資料庫三正規化理解
1.第一正規化 1nf 資料庫列不可再分，即資料庫的字段不可再下分，如進貨包含有單價和數量那麼資料庫設計時應設計為兩列 進貨數量 進貨單價 2.第二正規化 2nf 資料庫表中的每個例項或行必須可以被唯一的區分，且非主屬性需要完全依賴於主鍵，如果存在不依賴於主鍵的屬性，這些屬性應該分離出來形成乙個新的...
資料庫 三正規化理解
第一正規化 原子性，每乙個字段不可再分 每一字段資訊應該能分就分，分到不可再分為止 例如 第二正規化 唯一性，不可以把多種資料儲存在同一張表中，即一張表只能儲存 一種 資料。表內資料各管各的，不能互相影響 不符合第二正規化的表 學號,姓名,年齡,課程名稱,成績,學分 可能會存在問題 正確做法 學生 ...
資料庫三正規化理解
在談資料庫正規化之前，我們要明白一些關於資料庫的基本概念，具體有一下幾個 元組 tuple 是關聯式資料庫中的基本概念，關係是一張表，表中的每行即資料庫中的一條記錄，就是乙個元組，每列就是乙個屬性。超鍵 super key 能夠唯一決定乙個元組的屬性集合。可以是乙個屬性也可以是多個屬性，都叫做超鍵。...