數據庫范式設計
在最近開發系統的過程中,感覺收獲最大的也是關于數據庫的操作。最初開發機房收費系統的時候,由于沒有經驗,而且懂得的知識也非常少,數據庫的設計根本談不上,就是感覺到數據庫中缺少某些字段的時候,直接在數據庫表中去修改字段。這樣就為自己徒增了很多工作量,相關的代碼需要一處一處去修改。
開發.NET版機房收費系統的數據庫設計明顯好多了,由于充分了解了需求,數據庫設計當然比上一次好上很多。不過回頭去看,數據庫的設計還是存在很多的缺陷。表中仍然存在著大量的冗余字段,增刪改后也會出現發生一些異常。
在牛腩新聞發布系統中,由于系統非常小,對于數據庫的操作也就那兩下子,復雜也到不了哪里去。不過盡管如此,感覺牛老師的數據庫設計還是非常規范的。類別、評論、新聞分別放在三個表中,完全沒有冗余數據。
廢話太多了,開始步入正題了。良好的設計能夠使程序員的工作事半功倍。
首先,先來看官方解釋:
第一范式是指數據庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即是實體的某個屬性不能有多個值或者不能有重復的屬性。
第二范式是指數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴。
第三范式數據庫表中不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴。
簡單來說,第一范式是講數據庫表中數據的原子性,數據不可再分,只要是關系型數據庫都必須首先滿足第一范式。看下圖例子:圖1中三個字段不可再分,故滿足第一范式;圖2將專業、年級、班級三個字段放在一個字段里面,就不符合第一范式了。
下面再來看機房收費系統中的一個表設計——學生基本數據表。
圖A
圖A中由于每一個字段都不可再分,故它是滿足第一范式的。然而這樣的設計就會產生大量的冗余字段。如果一個學生注冊兩個卡,那么該學生的信息就需要重復兩次。
第二范式就解決了上述問題。它強調其屬性必須完全依賴主鍵,實體的屬性不能僅僅依賴主關鍵字的一部分屬性。如果存在部分依賴關系,那么這個屬性和主關鍵字相應部分應該分離出來形成一個新的實體,實體與原始體之間是一對多的關系。
像上面例子中,很顯然主鍵是卡號和學號聯合做主鍵,其中姓名、性別、系別、專業、年級、班級都只與學號有關,只依賴學號,而不依賴卡號,這樣就不符合第二范式了。
我們的根據第二范式的要求,將其與學生相關的信息分離出來,修改后,我們可得一下兩個表:
圖B
然而,僅僅滿足第二范式的數據庫是遠遠不夠的,滿足第二范式,仍然可能會出現傳遞依賴。圖B學生表中系別與專業存在傳遞關系。假如小紅和小明的系別都是數信學院,專業都是數學專業,那么這樣數據庫中系別就重復了兩次,增加了冗余字段。
圖C
下面給出圖C的數據庫關系圖:
好的數據庫設計,是軟件開發中非常重要的一步。三范式設計只是一個標準,對于基本表的設計,建議大家盡量按照三范式的要求進行設計;而對于臨時表的設計,我們可以適量的增加一些冗余字段,畢竟單一表的查詢檢索速度比較快,提高了系統性能。
posted on 2012-04-26 09:34 順其自然EVO 閱讀(216) 評論(0) 編輯 收藏 所屬分類: 數據庫