在完成了机房收费系统数据库需求分析、ER图、关系模型的阶段之后，就该根据关系模型来设计数据库了，下面是我对这个阶段的一个总结。
这次的关系模型有用户、学生、卡、基本数据、电脑、账单、工作记录、充值、退卡、上机共10个，要由这10个关系模型来设计数据库表，其中对于电脑（电脑名 系统时间 系统日期）这个关系，没有必要单独拿出来设计，其他的几个都需要转换成数据表，在确定了哪些关系模型需要转换为关系表之后，就需要分析的数据表字段的明确以及数据表三范式的规范的确定。
先来重温下数据库设计三大范式：
（一）数据表中的每个字段不能有多个值或者不能有重复的属性，符合原子性。
（二）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。
（三）在1NF基础上，任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖]。
分析一张旧的数据表：
?
像这张表OnLine_Info，主键CardNo，其他字段有：cardtype，studentname，Department，sex等，而这些信息完全是和Student_Info中的内容重复，So，完全可以通过主外键将两张表关联起来，这样这些重复的字段就不必要在不同的表里重复出现了。
再看一张表Studetn_Info:
?
当时的表名是Student_Info，可认真分析之后发现这完全就是学生信息和卡的信息的叠加，道理上一卡对应一个人，但是当修改或删除卡信息时，学生信息也有被修改的风险，同时由于这张表包含了太多的信息，导致查询学生信息需要这张表、查询卡信息需要这张表、结账算钱需要这张表，查看是否结账等也需要这张表，严重违背面向对象思想中“单一职责”原则，所以这次的设计必须改掉这些不足。
?
对数据类型的研究
昨天在把关系模型对应到数据表的时候由于各种数据对应的类型需要分别考虑，比如说字符型、数值型、时间日期型、金钱型……，用到最多的还是字符型，那就对char(n)、nchar(n)、varchar(n)和nvarchar(n)进行一个简单的总结。
?
这是在查阅资料后在OneNote里做的图，总而言之，如果是Unicode数据类型（即含有中文或者中文英文结合）则选择varchar或者nvarchar，如果需要变长，则选择nchar或者nvarchar.比如当我们在登录窗体的时候用户名用char(10)定义之后，需要在代码中用Trim(UserID)来传入数据库，为了是避免空格，当然这样要求用户名中不能含有空格，但是在密码这个字段中，可能会涉及到空格，这里就不建议使用nchar，最好使用char(n)。
其次，这次的所有涉及到金钱类型的字段全部用到了money类型来表示，只要在代码中用decimal(m,n)的数据类型来对应就OK了。
数据表涉及展示
数据库名称：Restructurecharge
一共9张表：
（1）User_Info
?
（2）Card_Info
?
（3）Student_Info
?
（4）Recharge_Info
?
（5）Online_Info
?
（6）LogoffCard_Info
?
（7）Worklog_Info
?
（8）BasicDate_Info
?
（9）Bill_Info
?
这就是这次设计的9张表，比起之前的11张表少了2张，这次的表也去掉了那些10多个字段的冗余表，在设计过程中，对于CancelCard_Info是否需要继续使用进过了思想斗争后还是加上了，毕竟不多一张表的话对Card_Info的压力比较大，还是保证“单一职责”吧，其次有几张表类似Worklog_Info、Bill_Info还是需要添加序列号的，便于查询时候的方便。
这样，数据库的设计就完成了，虽然还有不符合第二、三范式的地方，但是和上次相比已经好多了，在代码的实现阶段，对数据类型的设计、字符的长短，是不是还是要回头看自己的总结的。