終于,走到了機房收費系統重構的階段……
之前的一遍機房收費系統的資料庫是用的給的那個,隻是把每個表都看了一下,當時也沒有學習資料庫原理那本書,然後就沒有深究……
現在不一樣了,我們進行機房收費系統重構,況且學習了資料庫原理這本書,對資料庫有了更深的認識。是以對于資料庫要好好的設計,按照步驟走……
資料庫技術是資訊資源管理最有效地手段。資料庫設計是指對于一個給定的應用環境,構造最優的資料庫模式,建立資料庫及其應用系統,有效存儲資料,滿足使用者資訊要求和處理要求。
資料庫的設計的步驟和各階段的主要内容如下:
在邏輯設計階段要注意
将E-R圖轉換為關系模型實際上就是要将實體、實體的屬性和實體之間的聯系轉化為關系模式,這種轉換一般遵循如下原則:
(1)一個實體型轉換為一個關系模式。實體的屬性就是關系的屬性。實體的碼就是關系的碼。
(2)一個m:n聯系轉換為一個關系模式。與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。 而關系的碼為各實體碼的組合。
(3)一個1:n聯系可以轉換為一個獨立的關系模式,也可以與n端對應的關系模式合并。如果轉換為一個獨立的關系模式,則與該聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性,而關系的碼為n端實體的碼。
(4)一個1:1聯系可以轉換為一個獨立的關系模式,也可以與任意一端對應的關系模式合并。
(5)三個或三個以上實體間的一個多元聯系轉換為一個關系模式。與該多元聯系相連的各實體的碼以及聯系本身的屬性均轉換為關系的屬性。而關系的碼為各實體碼的組合。
(6)同一實體集的實體間的聯系,即自聯系,也可按上述1:1、1:n和m:n三種情況分别處理。
(7)具有相同碼的關系模式可合并。
(8)還有就是我們常說的三範式(确定資料依賴。消除備援的聯系):
第一範式(1NF):關系模式R中每一個原子都是不可分割的原子值。
第二範式(2NF):關系模式R是1NF,每個非主屬性完全依賴于候選鍵(都可以用來做主鍵的字段),就是滿足第二範式。
第三範式(3NF):關系模式R是1NF,每個非主屬性都不傳遞依賴于R的候選鍵。
首先我根據原來的資料庫進行了再次設計,将原來臃腫的表有的分開,有的減少東西……畫了一個ER圖:
根據ER圖設計出了資料庫中每個表:
使用者資訊表(User_Info):
UsrID | 使用者名(主鍵) | Char(10) |
Password | 密碼 | Char(10) |
Level | 級别 | Char(10) |
UserName | 真實姓名 | Char(10) |
Holder | 開戶人 | Char(10) |
學生資訊表(Student_Info):
StudentID | 學号(主鍵) | Char(10) |
StudentName | 姓名 | Char(10) |
Sex | 性别 | Char(2) |
Department | 系别 | Char(10) |
grade | 年級 | Char(10) |
Class | 班級 | Char(10) |
卡資訊表(card_Info):
CardID | 卡号(主鍵) | Char(10) |
studentID | 學号 | Char(10) |
Status | 使用狀态 | Bit |
Account | 餘額 | Decimal(10,4) |
Type | 卡類型 | Char(10) |
registDate | 注冊日期 | Date |
registTime | 注冊時間 | Time |
checkstatus | 結賬狀态 | Bit |
UserID | 使用者名 | Char(10) |
由于學生和卡是兩個不同的實體,是以将它們有關的資訊分開記錄,防止資料備援,防止表的臃腫。
充值記錄表(Recharge):
cardID | 卡号 | Char(10) |
rechargeMoney | 充值金額 | Decimal(10,4) |
RechargeDate | 充值日期 | Date |
RechargeTime | 充值時間 | Time |
userID | 使用者名 | Char(10) |
checkstatus | 結賬狀态 | Bit |
退卡記錄表(Cancelcard):
cardID | 卡号 | Char(10) |
returnMoney | 退還金額 | Decimal(10,4) |
CancelcardDate | 退卡日期 | Date |
CancelcardTime | 退卡時間 | Time |
UserID | 使用者名 | Char(10) |
checkstatus | 結賬狀态 | Bit |
上下機記錄表(OnOffLineRecord):
cardID | 卡号 | Char(10) |
OnDate | 上機日期 | Date |
Ontime | 上機時間 | Time |
OffDate | 下機日期 | Date |
Offtime | 下機時間 | Time |
OffWay | 下機方式 | Char(10) |
ConsumeMoney | 消費金額 | Decimal(10,4) |
ConsumeTime | 消費時間 | Time |
UserID | 使用者名 | Char(10) |
checkstatus | 結賬狀态 | Bit |
Computer | 機器名 | Char(10) |
基本資料表(BasicData):
Leasttime | 至少上機時間 | Time |
Unittime | 機關遞增時間 | Time |
Rate | 固定每小時費用 | Decimal(10,4) |
Tmprate | 臨時每小時費用 | Decimal(10,4) |
Limitcash | 最少金額 | Decimal(10,4) |
date | 日期 | Date |
Time | 時間 | Time |
UserID | 使用者名 | Char(10) |
賬單(check):
LastcardMoney | 上期儲值卡金額 | Decimal(10,4) |
CurrentrechargeMoney | 本期儲值卡金額 | Decimal(10,4) |
CurrentcancelcardMoney | 本期退卡金額 | Decimal(10,4) |
CurrentconsumeMoney | 本期消費金額 | Decimal(10,4) |
CurrentcardMoney | 本期儲值卡金額 | Decimal(10,4) |
Date | 日期 | Date |
Time | 時間 | Time |
UserId | 使用者名 | Char(10) |
工作記錄表(workLog):
UserID | 使用者名 | Char(10) |
Ondate | 登入日期 | Date |
Ontime | 登入時間 | Time |
Offdate | 登出日期 | Date |
Offtime | 登出時間 | Time |
Status | 狀态 | Bit |
Computer | 機器名 | Char(10) |
總結:資料庫設計是很重要的一件事,但是我們不可能一次就将自己的資料庫設計的完美,每次都嚴格按照規則走,隻有實踐的多了才能慢慢的設計出好的資料庫。