在做機房收費系統個人版的時候又一次的遇到了數據庫設計方面的內容,還記得第一次機房收費系統的時候,數據庫的設計基本上是邊敲邊設計的,搞得特別的亂,也不符合編程的規范。既然我們現在已經是專業人士了,那么就應該采取一些專業的手段來設計,并且一個
在做機房收費系統個人版的時候又一次的遇到了數據庫設計方面的內容,還記得第一次機房收費系統的時候,數據庫的設計基本上是邊敲邊設計的,搞得特別的亂,也不符合編程的規范。既然我們現在已經是專業人士了,那么就應該采取一些專業的手段來設計,并且一個數據庫設計的好壞直接影響到后臺數據,對軟件的運行效率也是密切聯系的。下面就分享下這次做數據庫的心得。
ER模型
在自學考試中,學習過有關ER模型方面的知識,這是被廣泛被采用的概念模型設計方法,就是所謂的圖形的方式來展示用戶需求中各方面的聯系,這與Use Case是不一樣,用例圖只是單一的展示了用戶的需求,沒有加入任何的關系操作,而ER模型在此基礎上引入了聯系的基本元素。
基本元素
實體:一個數據對象,指應用中可以區別的客觀存在的事物
聯系:表示多個實體間的關系
屬性:實體的某一特性
操作方法
1.分析需求
下面機房收費系統中用戶的描述
學生:可以上機,查看自己的余額,查看自己的上機記錄,還有自己的充值記錄,并且可以自己修改自己的密碼。
值班教師:我是機房的值班老師,由我來管理學生的上機情況,我的職責是負責同學上機,并且可以幫助
同學注冊,充值和退卡,也可以管理學生的上機情況。當然了也可以查看今天收取金額的情況。
管理員:我可以管理值班教師,比如添加和刪除值班教師,查看他們的工作記錄,并且我也可以
把近段時間來的金額進行匯總結賬,只能由我來設置學生上機消費的金額信息信息
2.設計局部ER模型
2.1 確定局部結構的范圍
我們從用戶的需求中,然后根據用戶的不同職責來劃分出范圍(學生、值班教師、管理員)
2.2 定義實體
這就需要從每一個局部的結構中概括出一些實體類型
比如學生這個職責范圍內的實體(學生、上機情況、余額情況、密碼等)
2.3 定義聯系
為實體與實體之間根據需求分析的結果,考察是否存在聯系
2.4 分配屬性
最后根據需求分析的結果,為每一個實體定義自己的特性,例如學生的屬性有——姓名、卡號、性別等
下面是學生ER圖的連接http://my.csdn.net/my/album/detail/1764165
3.設計全局ER模型
3.1 確定公共實體
當分別設計完局部的ER圖后,就可以把局部合并成為全局,在合并的過程中也要合并實體,因為不同
的類別范圍內查找的實體可能會重復。
3.2 合并局部ER模型
在確定完公共實體后,就可以根據公共的實體來合并局部的ER圖
下面是合并完后全局ER圖的連接http://my.csdn.net/my/album/show/274159
通過ER模型我們就能夠很清楚的了解到軟件項目中包括的實體,以及實體與實體之間的聯系,就能夠從宏觀上
把握軟件的架構。
關系模型
所謂的關系模型簡單的說就是我們數據庫中一張一張的表,當然了數據庫中的數據也有自己的設置規則
1.1 實體參照性規范
主鍵值不能為空,否則主鍵就起不到惟一標識的作用
1.2參照完整性原則
在數據表中的外鍵值不是空值就是定于其他表的主鍵值
1.3 用戶定義完整性規則
為了方便用戶的管理,用戶還可以自己制定相應的數據約束
ER模型到關系模型的轉變
在ER模型中有:實體、聯系和屬性,我們知道在數據庫中有記錄、字段和表名
這些都是相互對應的,下面就說一下如何來從ER模型來轉變為關系模型
轉變
1.1 實體轉換為模型
1.2 若實體間聯系是1:1,則可以在兩個實體間加入任何一個實體的主鍵值
1.3 若實體間聯系是M:N,則可以把兩個實體的主鍵提取出來重新組合成新的關系
最后機房收費系統后的關系模型如下:
教師(教工號、水平、年齡、性別、姓名、狀態) |
學生(卡號、學號、班級、年級、性別、姓名、系、密碼、狀態) |
退款記錄(學生卡號、教工號、值班教師、退款日期,退款金額,退款人員、退款時間) |
收取金額(學生卡號、教工號、值班教師,收取日期、收取金額、收款人) |
基本數據(教職工號、臨時用戶費用、遞增時間、至少上機時間、準備時間、最少金額) |
值班記錄(教工號、值班教師、值班日期、值班時間、下機日期) |
充值記錄(學生卡號、充值教師、充值金額、充值日期、充值時間) |
上機記錄(學生卡號、上機日期、上機時間、下機日期、下機時間) |
日結賬單(教工號、上次余額、本日消費金額、本日充值金額、本日退款金額、日期) |
周結賬單(教工號、上周余額、本期消費金額、本期充值金額、本期退款金額、日期) |
優化
1 消除重復
我們看到教師查看收取金額記錄和學生的充值記錄是重復的,所以需要去除重復來消除冗余。
2.三范式
1NF:表中的列是不可以在分的(原子性)
例如一張員工信息的表(姓名、住址、電話號碼),但是員工的電話號碼又分為住址號碼和手機號碼,所以就違反了1NF
要修改的話,要不就把電話號碼的屬性拆分為住址號碼和手機號碼,要不就強制員工直流一個號碼
2NF:表中不存在重復的記錄(即表中的行是不可以重復的)
我們就拿上面機房收費系統設計出來的表為例,學生信息表(學號、姓名、班級、系別)。如果這樣設計的話,我們可以知道一個系里面大概有1000多名學生,那么這個字段就會在這站張表中重復1000多次,而且還有班級這個字段也是同樣的道理
這樣做的話就會造成
數據冗余:一站表中多次出現了重復的記錄
更新異常:若要調整表中系別的字段的話,所有的系別都需要更新,有可能出現同一個學生出現在不同的系里面
插入異常:如果學校新開一個系別,如果沒有學生的話,那么這個系別無法保存進去
要改的話把系別和學生信息區別開來(系別號、系別)和(學號、系別號、姓名、性別),然后這兩張表通過系別號來進行連接
3NF:一個表中的列不依賴與另一個表中的非主鍵的列
其實數據庫的要求就是要遵從概念單一化"一事一地"原則,即一個關系模式描述一個實體或者實體間的一種聯系。通過三范式的約束后,我們來看一下最后的數據庫
教師(教工號、系別號、年齡、性別、姓名、狀態) |
系(系別號、系) |
學生(卡號、學號、班級、年級、性別、姓名、系、密碼、狀態) |
退款記錄(學生卡號、教工號、值班教師、退款日期,退款金額,退款人員、退款時間) |
基本數據(教職工號、臨時用戶費用、遞增時間、至少上機時間、準備時間、最少金額) |
值班記錄(教工號、值班教師、值班日期、值班時間、下機日期) |
充值記錄(學生卡號、充值教師、充值金額、充值日期、充值時間) |
上機記錄(學生卡號、上機日期、上機時間、下機日期、下機時間) |
日結賬單(教工號、上次余額、本日消費金額、本日充值金額、本日退款金額、日期) |
周結賬單(教工號、上周余額、本期消費金額、本期充值金額、本期退款金額、日期) |
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com