机房收费系统的数据库设计

这次机房收费系统的数据库设计与上一次有很大不同,之所以会引起不同,是因为遵循了数据库设计第三范式。
 
什么是数据库设计第三范式在我以前的文章中有所体现，《数据库设计第三范式》
 
我们先来看看前后的不同之处：
 
第一次共有10张表：结账信息，基本数据，上下机记录，退卡信息，正在上机信息，正在工作老师信息，
充值记录，学生信息，用户信息，工作记录。
 
而第二次，精简到了9张表：

合并正在上机信息表和上下机记录表，合并了正在值班老师信息表和工作记录表，将学生信息表分为学生基本信息表和上机卡信息表

减少了冗余信息。
 
到底怎么减少了冗余信息，举个例子：
原来的上下机记录字段包括：

序号，卡号，学号，学生姓名，学院，年级，性别，上机日期，上机时间，下机日期，下机时间，消费时间，消费金额，余额，卡状态，机器号

学生信息包括：

学号，姓名，卡号，学院，年级，性别，余额，操作员，卡状态，是否结账，注册日期，注册时间
 
正在上机信息表字段包括：卡号，学号，学生姓名，学院，年级，性别，上机日期，上机时间，机器号
 
我们看到：

序号，卡号，学号，学生姓名，学院，年级，性别这些信息是重复的，而且学生信息中，学生信息和上机卡信息是混合在一起的。这些明显不符合数据库设计第三范式。
 
在本次数据库设计中，
正在上机信息表和上下机记录表合并为上下机记录表，包括字段：

卡号，上机日期，上机时间，下机日期，下机时间，消费时间，消费金额，操作员，机器号，卡状态，是否结账

将学生信息分解为卡信息和学生信息
卡信息表字段：卡号，注册日期，注册时间，学号，余额，操作员，是否结账，卡状态
学生信息表字段：学号，姓名，学院，年级，班级，性别
 
对比两次设计，我们明显可以看到，减少了数据冗余，学生表和卡信息表之间有外键约束，而卡信息与上下机记录是一对多的关系。如果以后机房收费系统的学生信息要和教务系统的学生信息挂钩，那么只需替换掉学生信息一张表就可以搞定。反观第一种设计，会发现，整个数据库设计必须重新推倒
 
事物往往具有多面性，设计范式也会带来一定的麻烦：操作查询困难，因为需要联系多个表才能得到所需要数据，而且范式越高性能就会越差。
打个比方：查询上下机记录需要显示，学号，卡号，学生姓名，上下机信息相关字段。
第一次的设计，只需要查询一张表就可以搞定
而遵循数据库第三范式的设计，却要查询三张表。
 
所以使用多高的范式需要权衡利弊，一般在项目中，使用到第三范式也就足够了，性能好而且方便管理数据。

转载于:https://www.cnblogs.com/javaspring/archive/2011/11/08/2656590.html