之前第一遍机房收费的时候，用的数据库是别人的。认知也仅仅能建立在别人的基础上，等自考中《数据库系统原理》这本书学完了之后，再去看曾经的数据库，发现数据库真的还须要进一步的优化。以下是我设计数据库的一些见解。希望大家多提些意见。
数据库设计
E-R模型：
在观念模型设计阶段，一个系统都是建立在ER模型上的，设计好ER模型，非常重要。
我设计的ER图：
系统中的实体：非常easy，就是将系统中的名词都抽象出来，再详细了就是转换为数据库的逻辑设计时才要考虑的。
系统中的联系：在图中能够看得非常清楚，这里我要重点说的是：
（1）我将T_student表和T_card表分开。是由于之前的设计违反了第三范式，学生和卡号为什么是一对一的关系呢？由于我的设计思想是：一个学生仅仅能有一张卡能够正常使用。其它的，比方说，学生丢了卡了，之前的那张卡不能够使用了。可是卡表里面还是会保存这张不在使用的卡的信息。因此，卡表和学生表分开。但一个学生仅仅能使用一张卡。
（2）这次设计，将曾经的line表和online表和为一张表T_online表，图1所看到的；将曾经的onWork和wordlog表合为一张表T_WordLog表。图2所看到的。将CheckWeek表删除（由于和CheckDay表一样，仅仅是查询条件不同罢了。
）
设计后的T_line表：
图1
设计后的T_WordLog表：
图2
ER的联系：系统ER图中，能够非常清楚的看到他们之间的联系。有1对1。1对多。多对1。多对多的，这个关系一定要理清，就算你的和别人的不一样。没有关系。由于设计的时候，想法不一样，就会产生不同的效果。
ER的属性：详见后面关系模型。
综上就是ER图的设计，事实上。ER设计出来的时候，非常多人都有不同的想法，比方，有的人说我的学生表和卡表分开就会非常乱，注冊的时候。要分开注冊，非常复杂。我认为大家能够各自尝试一下，仁者见仁、智者见智嘛！
仅仅要别人问的时候。给自己一个说法即可了。
关系模型：
ER图中的主要成分是实体类型和联系类型。转换算法就是怎样把实体类型、联系类型转换成联系模式。
ER实体类型转换：（ER图中矩形框的都为实体，可建表）：
T_BasicData（Rate,TmpRate,unitTime,leastTime,PrePareTime,limitCash,Head）
T_Card(CardNo,RegisterDateTime,CacncelDateTime,Cash,Head,Type,status) T_Student(studentNo,CardNo,StudentName,Age,Sex,Department,Grade,Class,Date,Time,Explain）
T_User(UserID，serName，Level，Password。Computer，Head)
T_CheckDay(LastCash,Head,Recharge,CancelCash,ConsumeCash,nowCash，Computer，Status) T_WordLog(UserID,Level,LoginDate,LoginTime,LogoutDate,LogoutTime,Computer,Status)
ER关系转换：
对于1比1关系，T_student表中能够增加CardNo的字段（StudentNo为主键，CardNo为外键）。
对于1：N关系，能够适当的增加属性值。
对于N:M关系。关系就是一个模式（蓝色菱形 T_Line和T_Recharge）
T_Line(Cardno,Head,OnlienDateTim,OutlineDateTime,ConsumeTime,Consume,Computer,Status)
T_Recharge（CardNo,Head,Recharge,DateTime,Ischeck）
好了一定看看是够符合三范式的要求：
第一范式：属性不可分。事实上这个非常easy就能够看出来。属性值仅仅能是多个单值属性。
第二范式：消除部分依赖，这一条非常easy被功能打乱。由于非常多人都是依据功能来安排属性的，这里能够这么做，做好了之后。检查一下，有没有存在局部依赖。去掉即可了。
第三范式：消除传递依赖，这个得好好看看了。向之前的student表和card表合为一个表事实上里面存在着传递依赖，分开就对了。
设计数据库：
最基本的是注意数据类型吧。这个还是须要看看代码的，我第一版的系统中d全部的日期时间。都是用的DateTime这种数据类型。在vb.net中一定要看看是不是会出问题。
综上，我们要学会应用我们学习到了知识，我学的数据库太浅，非常多还是建立在原来数据库的基础上的。可是我相信，当我们努力学习。大胆尝试，还是非常快就会有所收获的，上面的数据库仅仅是个人的一些想法，有更好的。大家一起分享，交流。