终于，走到了机房收费系统重构的阶段……
之前的一遍机房收费系统的数据库是用的给的那个，只是把每个表都看了一下，当时也没有学习数据库原理那本书，然后就没有深究……
现在不一样了，我们进行机房收费系统重构，况且学习了数据库原理这本书，对数据库有了更深的认识。所以对于数据库要好好的设计，按照步骤走……
数据库技术是信息资源管理最有效地手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
数据库的设计的步骤和各阶段的主要内容如下：
在逻辑设计阶段要注意
将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) |
总结：数据库设计是很重要的一件事，但是我们不可能一次就将自己的数据库设计的完美，每次都严格按照规则走，只有实践的多了才能慢慢的设计出好的数据库。