重構機房收費系統——資料庫設計

標籤：style   blog   http   color   strong   ar   資料   2014   log   

           曾記得，第一次編寫機房收費系統的文件範本，整整有12個文檔需要編寫，僅僅花了兩三天的時間就讓師傅驗收，完結項目，就這樣囫圇吞棗的文檔編寫完成了。 要知道：欠下的賬，終究是要還的。現在到了機房收費系統個人版重構階段，
（1）進行資料抽象，設計局部概念性模型；
（2）將局部概念性模型綜合成全域概念性模型   
（3）就可以按要求繪製機房收費系統資料庫概念設計模型——ER關係圖。
可以說，之前的資料庫的概念設計給我奠定了一丟丟的設計基礎，外加《資料庫系統原理》中的三範式定理，本著求知好學、虛心請教的理念，於是乎發表這篇部落格，希望大家多多指正。


            在資料庫設計中，理清ER關係圖是尤為重要的。但往往是，我們根本理不清，有一種剪不斷，理還亂的感覺有木有……有木有。
先睹為快：      

1、第一範式1NF
定義：資料庫表中的欄位都是單一屬性的，不可再分。
通俗簡單的說，每一個屬性都是原子項，不可分割。

如：地址這個屬性就必須拆分為 省、區、街、鄉、道這幾個單值屬性。

2、第二範式2NF
定義：如果關係模式R是1NF，且每個非主屬性完全函數依賴於候選索引鍵。

通俗簡單的說，在滿足第一範式的前提下，當某張表中的非主鍵資訊不是由整個主鍵函數來決定時，即存在依賴於該表中不是主鍵的部分或者依賴於主鍵一部分的部分時，這就不滿足2NF的關係模式

如：原版的機房收費系統學生表，可以拆成 學生資訊表 和 卡表。這樣就滿足了第二範式。

3、第三範式3NF
定義：如果關係模式R是1NF，且每個非主屬性都不傳遞依賴於R的候選索引鍵。

通俗簡單的說，消除沒有直接依賴於第一範式和第二範式形成的表的主鍵的屬性，為沒有與表的主鍵關聯的所有資訊建立了一張新表。每張新表儲存了來自原表的資訊和它們所依賴的主鍵。

如：管理員的層級【Level】由使用者名稱稱【UserID】決定，而【UserID 】由上網的學生的【StudentNo】和【CardNo】來判斷，由此產生了傳遞依賴，第三範式往往就是消除傳遞的依賴的作用。

實踐是檢驗真理的唯一標準。這話說的真沒錯，自己冥思苦想半天，不如動手一畫來得快，畫著著畫著，之間的關係就越來越明確了。

再次看一下張機房收費系統——ER 圖吧（申明：本人的圖必有瑕疵……小的望大爺大神們多多海涵，小的真在努力學習ing）

從我的ER圖中可以清晰的觀察到各個實體間的關係和實體的屬性，以及實體間的聯絡。從而可以轉換成關聯式模式。如何轉換自己百度一下吧。

個人機房重構才剛剛開始……這開頭路似乎有點太是艱難了，歸宗與自己造的孽，打碎牙也只能往肚子裡咽，一步一步走下去，一定能行的。

重構機房收費系統——資料庫設計