机房重构--数据库设计（二）

    在完成了机房收费系统数据库需求分析、ER图、关系模型的阶段之后，就该根据关系模型来设计数据库了，下面是我对这个阶段的一个总结。

    这次的关系模型有用户、学生、卡、基本数据、电脑、账单、工作记录、充值、退卡、上机共10个，要由这10个关系模型来设计数据库表，其中对于电脑（电脑名  系统时间  系统日期）这个关系，没有必要单独拿出来设计，其他的几个都需要转换成数据表，在确定了哪些关系模型需要转换为关系表之后，就需要分析的数据表字段的明确以及数据表三范式的规范的确定。

 先来重温下数据库设计三大范式：

    （一）数据表中的每个字段不能有多个值或者不能有重复的属性，符合原子性。

    （二）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性。

    （三）在1NF基础上，任何非主属性不依赖于其它非主属性[在2NF基础上消除传递依赖]。

     分析一张旧的数据表：

    像这张表OnLine_Info，主键CardNo，其他字段有：cardtype，studentname，Department，sex等，而这些信息完全是和Student_Info中的内容重复，So，完全可以通过主外键将两张表关联起来，这样这些重复的字段就不必要在不同的表里重复出现了。

    再看一张表Studetn_Info:

    当时的表名是Student_Info，可认真分析之后发现这完全就是学生信息和卡的信息的叠加，道理上一卡对应一个人，但是当修改或删除卡信息时，学生信息也有被修改的风险，同时由于这张表包含了太多的信息，导致查询学生信息需要这张表、查询卡信息需要这张表、结账算钱需要这张表，查看是否结账等也需要这张表，严重违背面向对象思想中“单一职责”原则，所以这次的设计必须改掉这些不足。

 对数据类型的研究

      这是在查阅资料后在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还是需要添加序列号的，便于查询时候的方便。