VB.NET版机房收费系统—数据库设计

之前第一遍机房收费的时候，用的数据库是别人的，认知也只能建立在别人的基础上，等自考中《数据库系统原理》这本书学完了之后，再去看以前的数据库，发现数据库真的还需要进一步的优化，下面是我设计数据库的一些见解，希望大家多提些意见。

数据库设计

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,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,OnlienDateTim,OutlineDateTime,ConsumeTime,Consume,Status)

T_Recharge（CardNo,DateTime,Ischeck）

好了一定看看是够符合三范式的要求：

第一范式：属性不可分，其实这个很容易就可以看出来，属性值只能是多个单值属性。

第二范式：消除部分依赖，这一条很容易被功能打乱，因为很多人都是根据功能来安排属性的，这里可以这么做，做好了之后，检查一下，有没有存在局部依赖，去掉就行了。

第三范式：消除传递依赖，这个得好好看看了，向之前的student表和card表合为一个表其实里面存在着传递依赖，分开就对了。

设计数据库：

最主要的是注意数据类型吧，这个还是需要看看代码的，我第一版的系统中d所有的日期时间，都是用的DateTime这样的数据类型，在vb.net中一定要看看是不是会出问题。

综上，我们要学会应用我们学习到了知识，我学的数据库太浅，很多还是建立在原来数据库的基础上的，但是我相信，当我们努力学习，大胆尝试，还是很快就会有所收获的，上面的数据库只是个人的一些想法，有更好的，大家一起分享，交流。