本文主要是介绍机房重构--数据库设计（一），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
这一次的机房收费系统需要做的详细一点，一步一步按着软件工程的思想去设计系统，这篇文章主要是我对数据库设计过程的总结。
机房收费系统由于之前有给定的十期师姐的demo，有自己做过一次系统的经验，所以再次做机房的时候难免会受之前的影响，于是我这次的设计是抛开之前的旧观点，从零开始。
Step1:规划
规划阶段，虽然没有进行实地的考察，把自己当做开发人员的同时还当做了用户，对于系统的目标：设计一个可以用来实现网吧或图书馆通用的学生上机的系统。
同时对于旧系统的一些不足做了剖析，需要改进的地方做了标记，比如之前在结账的时候选项卡有一个“临时用户”的选项，其实临时用户的钱就是包含在充值项里的，这次的设计中就可以省略掉这一项，这是个鸡肋项（自己的观点，欢迎交流）；旧的系统中数据表student_Info中既包含学生信息又包含卡的信息，将二者捆在一起，难免有些臃肿，这次将其分开，更多的是考虑到卡和学生是两个不同的实体，对实体的操作在调用表的时候更加鲜明。还有就是“收取金额查询”和“充值记录查询”二者之前的关系，通过“结账”功能看出这一点有点“画蛇添足”的意思，该优化。
Step2:需求分析
根据面向对象的思想，将系统中实体分为最重要的三类：卡、学生、用户（操作员、管理员、一般用户）然后对各自的实体进行业务分析。
对学生：查看学生信息（要求组合查询）
学生信息维护（主要是修改学生信息）
对用户：修改密码
增加、删除用户
基本数据设定
工作记录查询
正在值班教师记录查询
对卡： 注册
充值-----充值记录查询
退卡-----退卡记录查询
上下机-----上机记录查询------上机状态查询
结账
账单查询
这三个实体的提取既可以把整个系统的功能分析出来，从学生、用户、卡这个次序，功能复杂程度越来越大，对于系统功能逻辑的理解在这个阶段先有简单的认识即可。
其次是对重要功能业务流程图的分析：
（1）这是用户如何操作系统的一个简单过程分析：
（2）这是对于卡来说的如何上机的一个简单描述：
Step3：概念设计
（1）进行数据抽象，设计局部概念模型
系统抽象出的实体有：用户、卡、学生、电脑、账单、工作记录、基本数据
（2）将局部概念模型综合成全局概念模型
这张图是整个系统的ER模型图，其间经过和贾丽敏、赵寒、孟浩杰的讨论，得出了这个模型，数据库设计过程中有几点还是不能完全满足ER图的需求，比如M:N的比例设计，有一个在关系模型图中的表现不出来，我觉得抽象的已经很到位了，但是还是稍有问题。
（3）评审
这个过程，即消除冲突，找浩杰帮忙评审的。
Step4:逻辑设计
由于已经实现了ER图的绘制，这一阶段主要工作即实现关系模型的描绘，在ER图中有7个实体，8个关系（仅对其中的一些进行绘制）绘制结果如下：
用户（ID号码 用户名 密码 级别 注册人 电脑名）
学生（学号 姓名 性别 系别 年级 班级 注释 日期 时间 注册人 卡号）
卡（卡号 注册金额 类型 余额 结账状态 是否使用 注册人 注册日期 注册时间）
基本数据（会员金额 临时金额 单位时间 准备时间 至少上机时间 限制金额 操作者 日期 时间）
电脑（电脑名 系统时间 系统日期）
账单（账单编号 上期余额 充卡的钱 消费金额 退卡金额 当前总金额 日期）工作记录（ID号码 上机日期 上机时间 下机日期 下机时间 状态 电脑）
充值（卡号 充值金额 充值日期 充值时间 用户名）
退卡（卡号 退卡日期 退卡时间 退卡金额 结账状态 用户名）
上机（卡号 上机日期 上机时间 下机日期 下机时间 用户ID 电脑名 结账状态 使用状态）
这个过程的问题也是最大的，我认为如果对整个系统的功能了解不够透彻，无法在关系模型中全面的体现出各个实体的属性，相应在最终数据表中有些字段也就不明确，不过，这个过程也是一个慢慢修改完善的过程。
Step5:物理设计
对于这个阶段，我的认识不是很深刻，希望大家能够给出帮助，我的理解，就是为从关系模型到数据表的准备工作，需要考虑数据类型、长度、数据表的名称、那些记录放在一张表……
欢迎大家就这个阶段的任务发表自己的看法。
Step6:数据库实现
对数据库的实现，仍需要考虑数据库设计的三范式，同时限于篇幅的限制，这一步分在下一篇博客中拿出来主要分析。
这样，我的数据库设计的雏形也就出来了，开始不知道怎么走这个过程，上来就画ER图，显然是不对的，按着软工设计规矩走，我觉得设计出的东西更规范、合理。
这篇关于机房重构--数据库设计（一）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
