軟考詳解---三範式，軟考---範式

軟考詳解---三範式，軟考---範式

       關係型資料庫是現在廣泛應用的資料庫類型，對關係型資料庫的設計就是對資料進行組織化和結構化的過程。對於小規模的資料庫我們處理起來還是比較輕鬆，但是隨著資料庫規模的擴大我們將發現使用者操控資料庫的SQL語句將變得笨拙、複雜。更糟糕的是很有可能導致資料不完整，不準確。所以我們有必要將資料設計的更加符合規範。怎樣使我們的資料庫更加規範呢，在資料庫的世界裡一共總結了五個範式，常用的有三個，今天小編就簡單的總結一下三範式，三範式的內容也是軟考中必考內容，希望對小夥伴們有協助，小編會首先簡單的介紹一個各個範式的概念，接著舉一個小例子對各個範式進行講解說明。

        第一範式

       首先，我們來看第一範式的定義：（1NF）是指資料庫表的每一列都是不可分割的基本資料項目，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重複的屬性。我們來看一個例題：

        例題：職工號、姓名、電話號碼組成一個表（一個人可能有一個辦公室電話和一個家裡電話號碼），如何將其規範為1NF。我們來分析一下這個例題，職工號、姓名、電話號碼組成一個表，一個人可能有一個辦公室電話和家裡電話號碼，我們要把這個表規範為第一範式，有三種方法，首先我們需要提出的是，這個表是不符合第一範式的，為什麼nie，他的電話號碼還分了子項，電話號碼分了辦公室電話和家裡電話號碼，這樣電話號碼這個項他就不是一個不可分割的項，要把這個表規範為第一範式，我們有三種方法，第一種是重複儲存職工號和姓名，即每個人的一個電話號碼佔用 一條記錄，這樣，關鍵字只能是電話號碼。第二種方法，以職工號為關鍵字，電話號碼分為單位號碼和住家電話。第三種是以職工號為關鍵字，但強制每條記錄只能有一個電話號碼，三種方法，可以將其規範為第一範式，第一種方法最不可取，按實際情況可選取後兩種情況。我們再來看一個關於規範第一範式的例題，如所示：

        

       如上的資料表有系名稱和進階職稱人數這兩個欄位，而進階職稱人數又分了兩個，顯然不符合第一範式，因為存在了可分割的資料項目，我們要對其規範的話，我們可以對資料項目進行拆分，把進階職稱人數直接分為教授和副教授兩個屬性即可，如下所示：

       

       第二範式

       我們來看第二範式的概念：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，如下所示：

        

        小編寄語：該博文小編主要簡單的介紹了一下三範式的相關內容，對於三範式的內容，小編早早的在自考資料庫系統原理中已經相遇過了，但是對於三範式一直是稀裡糊塗的，這次在軟考中，再次遇見了資料庫的三範式的相關內容，小編把相關的知識總結成博文，希望對有需要的小夥伴有協助，然考之路，未完待續......