之前第一遍机房收费的时候，用的数据库是别人的，认知也仅仅能建立在别人的基础上。等自考中《数据库系统原理》这本书学完了之后。再去看曾经的数据库。发现数据库真的还须要进一步的优化，以下是我设计数据库的一些见解，希望大家多提些意见。
数据库设计
E-R模型：
在观念模型设计阶段。一个系统都是建立在ER模型上的，设计好ER模型。非常重要。
我设计的ER图：
系统中的实体：非常简单，就是将系统中的名词都抽象出来，再详细了就是转换为数据库的逻辑设计时才要考虑的。
系统中的联系：在图中能够看得非常清楚，这里我要重点说的是：
（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中一定要看看是不是会出问题。
综上。我们要学会应用我们学习到了知识，我学的数据库太浅，非常多还是建立在原来数据库的基础上的，可是我相信，当我们努力学习。大胆尝试，还是非常快就会有所收获的，上面的数据库仅仅是个人的一些想法，有更好的。大家一起分享。交流。