之前第一遍机房收费的时候,用的数据库是别人的,认知也只能建立在别人的基础上,等自考中《数据库系统原理》这本书学完了之后,再去看以前的数据库,发现数据库真的还需要进一步的优化,下面是我设计数据库的一些见解,希望大家多提些意见。
数据库设计
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)
好了一定看看是够符合三范式的要求:
第一范式:属性不可分,其实这个很容易就可以看出来,属性值只能是多个单值属性。
第二范式:消除部分依赖,这一条很容易被功能打乱,因为很多人都是根据功能来安排属性的,这里可以这么做,做好了之后,检查一下,有没有存在局部依赖,去掉就行了。
第三范式:消除传递依赖,这个得好好看看了,向之前的student表和card表合为一个表其实里面存在着传递依赖,分开就对了。
设计数据库:
最主要的是注意数据类型吧,这个还是需要看看代码的,我第一版的系统中d所有的日期时间,都是用的DateTime这样的数据类型,在vb.net中一定要看看是不是会出问题。
综上,我们要学会应用我们学习到了知识,我学的数据库太浅,很多还是建立在原来数据库的基础上的,但是我相信,当我们努力学习,大胆尝试,还是很快就会有所收获的,上面的数据库只是个人的一些想法,有更好的,大家一起分享,交流。
VB.NET版机房收费系统—数据库设计,布布扣,bubuko.com