機房收費系統的資料庫設計

2021-09-08 08:11:16 字數 1293 閱讀 3729

這次機房收費系統的資料庫設計與上一次有很大不同,之所以會引起不同,是因為遵循了資料庫設計第三正規化。

什麼是資料庫設計第三正規化在我以前的文章中有所體現,《資料庫設計第三正規化》

我們先來看看前後的不同之處:

第一次共有10張表:結賬資訊,基本資料,上下機記錄,退卡資訊,正在上機資訊,正在工作老師資訊,

充值記錄,學生資訊,使用者資訊,工作記錄。

而第二次,精簡到了9張表:

合併正在上機資訊表和上下機記錄表,合併了正在值班老師資訊表和工作記錄表,將學生資訊表分為學生基本資訊表和上機卡資訊表

減少了冗餘資訊。

到底怎麼減少了冗餘資訊,舉個例子:

原來的上下機記錄字段包括:

序號,卡號,學號,學生姓名,學院,年級,性別,上機日期,上機時間,下機日期,下機時間,消費時間,消費金額,餘額,卡狀態,機器號

學生資訊包括:

學號,姓名,卡號,學院,年級,性別,餘額,操作員,卡狀態,是否結賬,註冊日期,註冊時間

正在上機資訊表字段包括:卡號,學號,學生姓名,學院,年級,性別,上機日期,上機時間,機器號

我們看到:

序號,卡號,學號,學生姓名,學院,年級,性別這些資訊是重複的,而且學生資訊中,學生資訊和上機卡資訊是混合在一起的。這些明顯不符合資料庫設計第三正規化。

在本次資料庫設計中,

正在上機資訊表和上下機記錄表合併為上下機記錄表,包括字段:

卡號,上機日期,上機時間,下機日期,下機時間,消費時間,消費金額,操作員,機器號,卡狀態,是否結賬

將學生資訊分解為卡資訊和學生資訊

卡資訊表字段:卡號,註冊日期,註冊時間,學號,餘額,操作員,是否結賬,卡狀態

學生資訊表字段:學號,姓名,學院,年級,班級,性別

對比兩次設計,我們明顯可以看到,減少了資料冗餘,學生表和卡資訊表之間有外來鍵約束,而卡資訊與上下機記錄是一對多的關係。如果以後機房收費系統的學生資訊要和教務系統的學生資訊掛鉤,那麼只需替換掉學生資訊一張表就可以搞定。反觀第一種設計,會發現,整個資料庫設計必須重新推倒

事物往往具有多面性,設計正規化也會帶來一定的麻煩:操作查詢困難,因為需要聯絡多個表才能得到所需要資料,而且正規化越高效能就會越差。

打個比方:查詢上下機記錄需要顯示,學號,卡號,學生姓名,上下機資訊相關字段。

第一次的設計,只需要查詢一張表就可以搞定

而遵循資料庫第三正規化的設計,卻要查詢三張表。

所以使用多高的正規化需要權衡利弊,一般在專案中,使用到第三正規化也就足夠了,效能好而且方便管理資料。

機房收費系統的資料庫設計

這次機房收費系統的資料庫設計與上一次有很大不同,之所以會引起不同,是因為遵循了資料庫設計第三正規化。什麼是資料庫設計第三正規化在我以前的文章中有所體現,資料庫設計第三正規化 我們先來看看前後的不同之處 第一次共有10張表 結賬資訊,基本資料,上下機記錄,退卡資訊,正在上機資訊,正在工作老師資訊,充值...

機房收費系統的資料庫設計

這次機房收費系統的資料庫設計與上一次有很大不同,之所以會引起不同,是因為遵循了資料庫設計第三正規化。什麼是資料庫設計第三正規化在我以前的文章中有所體現,資料庫設計第三正規化 我們先來看看前後的不同之處 第一次共有10張表 結賬資訊,基本資料,上下機記錄,退卡資訊,正在上機資訊,正在工作老師資訊,充值...

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

弄完了三層的例子後,機房重構早就該開始了,但是自己一直不想動,萬事開頭難,機房收費的重構,先是資料庫的設計問題,開始包括er圖的設計。然後設計資料庫,設計表.現在想想自己資料庫的設計。首先先想一想上下機的整個流程,乙個學生拿著卡來到老師面前,老師講學生的卡啟用,學生在拿著卡去找機子上機,假如學生沒有...