關系型數據庫是現在廣泛應用的數據庫類型，對關系型數據庫的設計就是對數據進行組織化和結構化的過程。對於小規模的數據庫我們處理起來還是比較輕松，但是隨著數據庫規模的擴大我們將發現用戶操控數據庫的SQL語句將變得笨拙、復雜。更糟糕的是很有可能導致數據不完整，不准確。所以我們有必要將數據設計的更加符合規范。怎樣使我們的數據庫更加規范呢，在數據庫的世界裡一共總結了五個范式，常用的有三個，今天小編就簡單的總結一下三范式，三范式的內容也是軟考中必考內容，希望對小伙伴們有幫助，小編會首先簡單的介紹一個各個范式的概念，接著舉一個小例子對各個范式進行講解說明。
第一范式
首先，我們來看第一范式的定義：（1NF）是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。我們來看一個例題：
例題：職工號、姓名、電話號碼組成一個表（一個人可能有一個辦公室電話和一個家裡電話號碼），如何將其規范為1NF。我們來分析一下這個例題，職工號、姓名、電話號碼組成一個表，一個人可能有一個辦公室電話和家裡電話號碼，我們要把這個表規范為第一范式，有三種方法，首先我們需要提出的是，這個表是不符合第一范式的，為什麼nie，他的電話號碼還分了子項，電話號碼分了辦公室電話和家裡電話號碼，這樣電話號碼這個項他就不是一個不可分割的項，要把這個表規范為第一范式，我們有三種方法，第一種是重復存儲職工號和姓名，即每個人的一個電話號碼占用 一條記錄，這樣，關鍵字只能是電話號碼。第二種方法，以職工號為關鍵字，電話號碼分為單位號碼和住宅電話。第三種是以職工號為關鍵字，但強制每條記錄只能有一個電話號碼，三種方法，可以將其規范為第一范式，第一種方法最不可取，按實際情況可選取後兩種情況。我們再來看一個關於規范第一范式的例題，如下圖所示：
vczK2rrNuLG9zMrawb249sr00NS8tL/Jo6zI58/Cy/nKvqO6PC9wPgo8cD4gICAgICAgPGltZyBzcmM9"http://www.2cto.com/uploadfile/Collfiles/20150518/2015051809330334.png" alt="\">
第二范式
我們來看第二范式的概念：2NF，當且僅當實體E是第一范式，且每一個非主屬性完全依賴主鍵（沒有不完全依賴時），則稱實體E是第二范式。我們來看一個例子：
選課關系SC1(SNO，CNO，GRADE，CREDIT)中SNO為學號，CNO為課程號，GRADEGE為成績，CREDIT為學分，由以上條件的關鍵字為組合關鍵字（SNO，CNO），我們來分析一下上面的這個問題，有一個選課關系sc1，裡面有四個字段，這個關系的主鍵是sno和cno的組合，也就意味著這個組合可以確定成績和學分，我們寫出所有函數依賴SNO CNO ---GRADE/CREDIT，除此之外，是不是還有其他的呢，我們可以發現GREDIT是學分，然而一門課程的學分只要課程號確定了學分肯定能確定，因為課程的學分是固定的，所以還有一個函數依賴，cno可以確定credit，所以這裡存在部分函數依賴，因為主鍵的一部分就可以確定credit這個屬性，這樣就產生了部分函數依賴，在實際應用中，這樣一個關系存在問題，如下所示：
我們再來看一個例題，如下所示：
分析一下數據的內部結構，這個表中包含四個屬性，倉庫號和設備號有可能是這個表中的主鍵，我們發現倉庫號有重復的元素，所以她不能夠是主鍵，設備號也存在這種情況，所以只能將二者拼合作為主鍵，我們發現其中沒有重復的數據項了，並且每一個項能夠確定數量和地點，所以我們選定這兩個組合作為數據表的主鍵，我們在看其他的對應關系，這樣才能判斷是否滿足第二方式，倉庫號和地點之間是否有關聯，發現比如wh1所對應的地點都是北京，我們可以得到一個函數依賴，倉庫號對應著地點，產生了部分函數依賴，我們剛才已經確定了倉庫號和設備號的拼和是主鍵，這個時候有出現了倉庫號可以確定地點號，所以不滿足第二范式，so
第三范式
首先我們來一起了解一下第三范式的概念：當且僅當實體E是第二范式，且E中沒有非主屬性傳遞依賴於碼時，則稱實體E是第三范式，我們來看一個例題：
如S1(SNO、SNAME、DNO、DNAME、LOCATION）各屬性分別代表學號、姓名、所在系、系名稱、系地址。關鍵字SNO決定各個屬性，由於是單個關鍵字，沒有部分依賴的問題，肯定是2NF，但這關系會有大量的冗余，有關學生所在系的幾個屬性DNO、DNAME、LOCATION將重復存儲，在插入和刪除、修改時也將產生類似於上例的情況。我們來分析一下這個問題，如果某個關系模式他的關鍵字，他的主鍵是單關鍵字，而不是多個關鍵字的組合，那麼這一個關系模式至少是第二范式，原因就是他是單屬性，所以不存在部分函數依賴。
產生上述錯誤的原因：關系中存在傳遞依賴造成的，即SNO-->DNO，而DNO-->SNO卻不存在，DNO-->LOCATION，因此關鍵字SNO對LOCATION函數決定是通過函數依賴SNO-->LOCATION實現的，也就是說，SNO不直接決定非主屬性LOCATION。原因是關系中存在傳遞依賴造成的，比如說，在這樣一個數據表中，sno確定dno，這是因為非主屬性依賴於我們知道一個學生的學號以後，可以知道他所在系的，、系號，但是我們知道一個系號卻不能夠確定學生的學號，因為一個系有多個人，同時系號能夠確定系所在的位置，這樣一些條件組合起來，就滿足了傳遞函數依賴的一個條件，所以就形成了sno到loction的一個傳遞的函數依賴，也就是說Sno不直接決定非主屬性location，這樣這個關系模式他就不符合第三
范式了。現在我們來尋求一種解決方法，消除數據冗余，以及插入、刪除、修改有可能出現的錯誤，要解決這個問題，必須要把所有的傳遞函數依賴給消除掉，我們可以把這個關系模式拆分為兩個，應該是這個樣子滴：S（SNO，SNAME，DNO），D（DNO、DNAME、LOCATION）這樣兩個關系模式都符合第三范式了，但是我們需要注意的是，關系S中不能沒有外關鍵字DNO，否則兩個關系之間會失去聯系，在關系數據庫中，除了函數依賴之外還有多值屬性，聯接依賴的問題，從而提出了第四范式，第五范式等更高一級的規范化要求。我們再來看一個例題，如下所示：
我們來分析一下，有四個字段，這一個倉庫表中，有哪些函數依賴關系呢，我們來看，一個所在省，一個所在城市，他們之間是有關聯的，如果我知道了所在城市就能夠確定所在省，這是唯一確定的，然而我們知道倉庫號的話，要能夠知道倉庫所在的城市，這樣子也產生了一個，但是你知道倉庫所在的城市，你不一定知道倉庫號，因為所在城市所在城市武漢就有三條記錄，但是武漢這個城市就有三個倉庫，這樣的話，所在城市是不夠確定倉庫號的，綜合這些條件，產生了一個傳遞函數依賴，就是所在省傳遞依賴函數倉庫號，我們要將其規范為第三范式就要打破這種局面，我們要怎麼做nie，如下所示：
系統原理中已經相遇過了，但是對於三范式一直是稀裡糊塗的，這次在軟考中，再次遇見了數據庫的三范式的相關內容，小編把相關的知識總結成博文，希望對有需要的小伙伴有幫助，然考之路，未完待續......
