弄完了三层的例子后，机房重构早就该开始了，但是自己一直不想动，万事开头难，机房收费的重构，先是数据库的设计问题，开始包括ER图的设计。然后设计数据库，设计表.......

现在想想自己数据库的设计。首先先想一想上下机的整个流程，一个学生拿着卡来到老师面前，老师讲学生的卡激活，学生在拿着卡去找机子上机，假如学生没有卡，老师可以给学生注册新卡，如果卡里没有钱，也可以给学生充值，如果学生不想要卡了，还有注销等等，而学生和卡之间就是拥有的关系。最后就是学生上完机，然后再拿着卡去找老师下机，老师在从基本数据表中得到数据计算学生的消费金额，让学生下机。当然还有一个可以记录用户工作记录的表。

下图是自己设计的数据ER图

在数据库ER图转换成关系模型的时候，我们要遵循三范式。

第一范式：关系模式中的每一个属性不可以在细分。比如一个关系模式有一个地址属性，属性可以从中国――>河北省――>廊坊市等等，这样属性不是单一的，就不满足第一范式。

第二范式：关系模式R在满足1NF后，每个非主属性完全依赖于候选键。其实就是不存在局部依赖。比如现在有一个关系模式R（StudentNO、CourseNO、Score、TeacherNO、Title）的属性分别代表学生的学号、课程号、分数、教师号、教师的职称。显然里面的候选键是（StudentNO、CourseNO），他俩就可以将这个关系模式中所有的属性信息都能推出来，但是在候选键CourseNO中，它可以将（TeacherNO，Title）推出来，这就叫存在非主属性对候选键的局部依赖。用一个比喻来说，小两口过得好好的，但是其中有一个有了外遇。

第三范式：每个非主属性都不传递依赖关系模式R的候选键。前提是R满足1NF和2NF。比如关系模式R中，A是候选键，A――>B 、B――>C、 A――>C，最后一个就是一个传递依赖的例子。这样就不满足3NF。

小结

机房重构让我回头复习了数据的设计，数据库的三范式等等知识，回头看看挺好的，学习嘛就是一个反复的过程。万事开头难，给自己加油吧！！