这次的机房重构是在师哥指导下一步步按着项目的开发流程来的，从开始的画图到数据库设计然后到现在的代码实现，画图主要是包图、类图、用例和时序图，从三层到加上工厂和外观的七层，师哥也可谓是循循善诱，尤其时序图，开始的两天一点头绪也没有，后来也就那么画出来，因为好多方法的参数和返回值真的不知道怎么定义，所以代码实现的时候还会改动；然后就是数据库这次不要使用人家的，可以借鉴，但每张表怎么抽象，每个字段有什么作用要有自己的理解。

因为之前做过一遍，业务了解的也差不多，看网上对数据库设计流程也很多，我这次参考了自考数据库原理中的三范式。数据库设计范式通常要求在实践中把数据库分为两张或多张表并定义表之间的关系以做到数据的隔离，添加删除修改某个字段时只需在一张表中进行，接着可以通过定义的关系传递到数据库中剩余的表中（和分层的意义有些相似），这样可以减少一些不必要的信息出现的机会，减轻更新信息所需工作量，但是有时一些操作需要涉及多张表才能完成，而且范式越高性能越差，一般在项目中也就使用到第三范式。

1. 每张表中字段都是单一属性，不可再分；

比如职工有职工号、姓名、性别、住址属性，在这里就不符合第一范式，因为住址还可以分成*市*区*路*号

2. 不能存在非关键字段对候选关键字段的部分函数依赖，或者说当某张表中的非主键信息不是由整个主键函数来决定时，即存在依赖于该表中不是主键的部分或者依赖于主键一部分的部分时，通常会违反2NF；

比如机房中学生表字段：卡号、学号、姓名、性别、系别、年级、班级、余额、类型、用户名，在这里学号和卡号作为主键，但是余额并不 完全依赖于主键，只要卡号就可以确定了，出现了部分依赖

3. 不能存在非关键字段对候选关键字段的传递函数依赖；

比如学生表中学号、卡号、用户名、级别，学号和卡号对应用户名，而一个用户名对应一个级别，导致传递依赖

有了这几条规范，变化最大的就是将卡从学生表中抽象出来（2NF)，还一点就是将日结和周结合在一起，查询时根据日期选择就好了，系统用户工作产生工作，对卡的充值、退卡操作分别产生相应的记录，学生上机是会有上机记录，还有就是管理员对学生下机结账的数据设定，对操作员结账的数据。这样就找出所需实体，开始将正在值班老师和工作日志合为一张表，在工作日志中添加一字段为状态，后来师哥说查询时候还需要设置条件，其实建表不是越少越好，应该说怎么方便、高效然后再是简洁。下面是我表中的字段：

还有一点也是我没有想到的就是隐藏字段，不能直接从窗体中看到，比如用户表只能看到前4字段，开户人和状态通过业务得到，比如删除用户后可以标记为不使用，因为还有可能没有结账。其实真正在建数据库时需要对需求反复分析讨论，中间也会改进完善，但可能因为系统原型和原来数据库存在会限制我们的思考，有不合理的地方还请指教。