之前一段时间都在弄论文,但是敲论文的时候一个很小的问题,都让我很灰心,苦于找不到很好的解决方法,参考了很多书,还是不得要领,不想在论文上在耽误时间了,所以决定向机房进发,重构机房如果遇到问题好歹还能问问身边的小伙伴们,机房搞定了,论文就简单了。汲取第一次机房的教训,这次遇到问题一定要好好的总结,找一个切入口,迅速进入状态,把工程化成一小步一小步去做,一个功能一个功能的去实现,不要想一口吃个胖子,也不要一直犹豫不决,逃避困难。这次对自己的要求只有一个,遇到困难,找到方法,解决困难,打死不拖延。计划一个月之内搞定机房(貌似时间也不短),下个月20号是我的生日,如果没能在生日之前完成这项任务,我就请所有十二期同学吃蛋糕。。。
我的计划是先设计数据库,然后修正文档的设计阶段和UML图,之后才是真正的编码阶段。今天就来总结一下数据库设计方面的问题。
数据库生命期包括:规划——设计——实现——维护——被新系统取代,这几个阶段,今天具体的说一下设计阶段,机房的功能就不过多阐述了,大家比我更明白其中的逻辑关系。
概念设计的第一步是进行数据抽象,设计出局部概念模型。所谓的抽象两个词概括“聚集”加“概括”,相同特性的事物聚集到一起,对他们进行概括,抽象出一个实体。就拿机房收费系统来说,很多同学来机房上课,他们可能属于不同院系,选择不同时间来上机,但是他们有一个共同的特性——他们都是学生;使用这个系统的老师很可能有很多,李老师,王老师,张老师...但是他们都是老师。我们要把不同的个体聚集起来,概括出一个统一“称呼”,这就是抽象。
局部设计分为以上四步,如何确定范围呢?有两种方法,第一种:依据系统当前用户进行自然划分,比如机房可以分出使用者(学生)和操作者(用户)两个局部模型;第二种是根据系统数据库提供的服务进行划分,机房可以提供如下服务:
我使用的是第一种方法,而且系统较小,所以直接画的全局的模型,画出来的E-R图(不包含属性)如下:
因为是重新设计的,所以我对于原来关系,做了如下微小调整:
将E-R图转化成关机模型:
学生(学号,姓名,年龄,性别,系别,专业,年级,班级,备注)
用户(用户名,密码,级别,状态,head)
卡(卡号,学号,用户名,注册日期,余额,类型,状态)
基础数据(固定用户价格,普通用户价格,累加时间,最少上机时间,准备时间,最低消费,head)
充值记录(卡号,用户名,充值金额,充值日期,充值时间,是否结账)
注销记录(卡号,用户名,退还金额,注销日期,注销时间,是否结账)
上下机记录(卡号,用户名,上机日期,上机时间,下机时间,花费时间,花费金额,机号,是否结账)
账单(注册金额,充值金额,上机金额,退卡金额,全部金额,结账日期,结账时间,head)
工作记录(用户名,登录日期,登录时间,登出时间,机号,状态)
将关系模型转化成数据库中的表:
这次设计对于数据类型设定更加精准一些:
1.拿我们学校举例,学号一般都是11位,所以设定的是char(11),卡号一般长一点,设定的是16位的空间
2.学生的年龄,使用的是tinyint,比smallint范围更小的一个数据类型,是最小的整数类型,而且他只占用一个字节(smalint占用两个,而int占用四个字节),如果字段设置为UNSIGNED,那么只能存储0~255的整数,如果不设置,范围是-128~127
3.对于状态的字段,设置为bit类型,这是看到一个师姐的博客学来的,上机或者下机,登录或者未登录,都可以用0或1来表示这个状态的情况,所以一个bit类型就可以应付了。程序读取数据库出来之后的表现形式是true或者false,但是保存在数据库中的结构类型是0或者1,它也只占一个字节。
通过这次重新设计数据库,将数据库的知识通过实践又温习了一遍,当将理论的知识上升到实际时,你就会根据实际的情况,考虑很多具体的问题,在这个过程中,就会更好的理解这些步骤的具体含义,这些概念具体对应现实生活中的什么东西,数据类型到底应该怎么应用,而不再只是文字给予我们的认知,学习是个多维的过程,书本是一个维度,实践是另一个维度,和别人讨论同样是一个维度,越来越开始享受学习这个过程了