淺談數據庫設計要符合的三個范式和關鍵字
數據庫設計是應用程序開發過程中非常重要的一個環節。一個好的數據庫設計不僅能讓我們實現軟件時得心應手，對軟件后期的維護，升級也是至關重要的。本文我們給出了數據庫設計三個范式和關鍵字的知識，并通過一個實例--教務管理系統來對其進行詳細的說明，接下來我們就一起來了解一下這一過程。
對數據庫的設計，主要是依賴界面設計來做的。界面反映了用戶的直接需求.把這些需求轉換成數據庫中的表.再為這些表添加主鍵,外鍵等約束.以確保數據關系的合理性.然后再根據業務的流程去梳理數據庫數據的流向是否得當。
對數據庫字段的確定,主要是依賴界面中需要添加那些信息,需要處理那些信息,將對應信息分類到相應的表中.這里不說如何確定和提取字段了,因為自己感覺也說不清楚,當你見得數據庫多了,你就會自然而然的把他們分出來。
對數據庫三范式的理解和應用
***范式：數據庫表中的字段都是單一屬性的，不可再分。
對于***范式,還是比較好理解的,說白了就是說一個列不能有多個值,每一個字段都是不可拆分的.比如數據庫有這樣一個字段:父母.顯然這是不行的.因為父母屬于兩個獨立的個體,完全可以拆分.如果把他們設置為一個字段.結果就是對于這個字段來說,我們是不方便應用的.因為父母可能有原因只有一個或者其他情況,這樣對于數據庫來說,一個字段就是不完整的.對于數據的查詢,顯示都是有問題。
***范式：比較容易理解,一般人不會犯這樣的錯誤.
第二范式：數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些字段決定非關鍵字段的情況），也即所有非關鍵字段都完全依賴于任意一組候選關鍵字。
對關鍵字的說明
超關鍵字 ：二維表中，能夠惟一確定記錄的一個字段或幾個字段的組合被稱為“超關鍵字”。“超關鍵字”雖然能***確定記錄，但是它所包含的字段可能是有多余的。
候選關鍵字：如果一個超關鍵字去掉其中任何一個字段后不再能***地確定記錄，則稱它為“候選關鍵字”（Candidate Key）。候選關鍵字既能***地確定記錄，它包含的字段有是最精煉的。也就是說候選關鍵字是最簡單的超關鍵字。
比如：在一個學生選課表中
學號 姓名 性別 課程名稱 成績 學分
這里的關鍵字為組合關鍵字，（學號 課程名稱）
出現的問題就是有：
１：姓名 性別 依賴于學號這個候選關鍵字。
２：學分 依賴于課程名稱這個候選關鍵字。
顯然是不符合第二范式的。
那么不符合第二范式會產生什么結果呢？ 一般說來，不符合數據庫三范式會引起插入異常，更新異常，刪除異常．
１：插入異常：比如要新開一門課程，如果沒有人選的話，這么課程就插入不到數據庫，因為它沒有學號，姓名，性別這些信息．
２：更新異常：如果要修改一門課程的學分，那么所有的學分字段都要修改，否則出現同一課程不同學分的情況.
３：刪除異常：如果某門課程取消了，要刪除課程的時候，這個學生的信息也會被刪除．
當然，不合理的數據庫設計會造成大量的數據允余，比如某個學生選擇了ｎ門課程，學生的姓名，性別就會重復ｎ次．
如果把這個表拆分成三個：
學號 姓名 性別
課程 學分
學號 課程 成績
這樣就不違反第二范式，也就是說，也肯定不會違反第二范式，因為他們沒有組合關鍵字，可以看出，有組合關鍵字的可能違反第二范式．
第二范式也可以理解為：主鍵確定一條***記錄，也就是說關鍵字在數據庫表中***出現一次．
第三范式：在第二范式的基礎上，數據表中如果不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴則符合第三范式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系．
比如：學號 姓名 所在學院 學院名稱
這里的學院名稱完全依賴于學院，和關鍵字學號沒有關系．這樣就是傳遞依賴
違反第三范式也會產生數據庫異常和允余．這里就不再分析．
在基礎信息的數據庫設計中，***次設計很多違反了第三范式，這些主要是對界面的過分依賴造成的．也就是說，你看到的界面信息，很可能是來自不同的數據庫，如果你把他們放到一個數據庫，就會違反數據庫三范式．
關于數據庫設計過程中的三個范式和關鍵字方面的知識我們就介紹到這里，希望能夠給您帶來一些收獲吧，謝謝！
【編輯推薦】
