重构机房收费系统数据库设计

曾记得，第一次编写机房收费系统的文档模板，整整有12个文档需要编写，仅仅花了两三天的时间就让师傅验收，完结项目，就这样囫囵吞枣的文档编写完成了。 要知道：欠下的账，终究是要还的。现在到了机房收费系统个人版重构阶段， （1）进行数据抽象，设计局部

曾记得，第一次编写机房收费系统的文档模板，整整有12个文档需要编写，仅仅花了两三天的时间就让师傅验收，完结项目，就这样囫囵吞枣的文档编写完成了。 要知道：欠下的账，终究是要还的。现在到了机房收费系统个人版重构阶段，
（1）进行数据抽象，设计局部概念模型；
（2）将局部概念模型综合成全局概念模型
（3）就可以按要求绘制机房收费系统数据库概念设计模型——ER关系图。
可以说，之前的数据库的概念设计给我奠定了一丢丢的设计基础，外加《数据库系统原理》中的三范式定理，本着求知好学、虚心请教的理念，于是乎发表这篇博客，希望大家多多指正。

在数据库设计中，理清ER关系图是尤为重要的。但往往是，我们根本理不清，有一种剪不断，理还乱的感觉有木有……有木有。
先睹为快：

1、第一范式1NF
定义：数据库表中的字段都是单一属性的，不可再分。
通俗简单的说，每一个属性都是原子项，不可分割。

如：地址这个属性就必须拆分为 省、区、街、乡、道这几个单值属性。

2、第二范式2NF
定义：如果关系模式R是1NF，且每个非主属性完全函数依赖于候选键。

通俗简单的说，在满足第一范式的前提下，当某张表中的非主键信息不是由整个主键函数来决定时，即存在依赖于该表中不是主键的部分或者依赖于主键一部分的部分时，这就不满足2NF的关系模式

如：原版的机房收费系统学生表，可以拆成 学生信息表 和 卡表。这样就满足了第二范式。

3、第三范式3NF
定义：如果关系模式R是1NF，且每个非主属性都不传递依赖于R的候选键。

通俗简单的说，消除没有直接依赖于第一范式和第二范式形成的表的主键的属性，为没有与表的主键关联的所有信息建立了一张新表。每张新表保存了来自原表的信息和它们所依赖的主键。

如：管理员的级别【Level】由用户名称【UserID】决定，而【UserID 】由上网的学生的【StudentNo】和【CardNo】来判断，由此产生了传递依赖，第三范式往往就是消除传递的依赖的作用。

实践是检验真理的唯一标准。这话说的真没错，自己冥思苦想半天，不如动手一画来得快，画着着画着，之间的关系就越来越明确了。

再次看一下张机房收费系统——ER 图吧（申明：本人的图必有瑕疵……小的望大爷大神们多多海涵，小的真在努力学习ing）

从我的ER图中可以清晰的观察到各个实体间的关系和实体的属性，以及实体间的联系。从而可以转换成关系模型。如何转换自己百度一下吧。

个人机房重构才刚刚开始……这开头路似乎有点太是艰难了，归宗与自己造的孽，打碎牙也只能往肚子里咽，一步一步走下去，一定能行的。