曾记得。第一次编写机房收费系统的文档模板，整整有12个文档须要编写，只花了两三天的时间就让师傅验收，完结项目。就这样囫囵吞枣的文档编写完毕了。

要知道：欠下的账，终究是要还的。如今到了机房收费系统个人版重构阶段，
（1）进行数据抽象，设计局部概念模型；
（2）将局部概念模型综合成全局概念模型   
（3）就能够按要求绘制机房收费系统数据库概念设计模型——ER关系图。
能够说，之前的数据库的概念设计给我奠定了一丢丢的设计基础。外加《数据库系统原理》中的三范式定理，本着求知好学、虚心请教的理念，于是乎发表这篇博客，希望大家多多指正。


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

先睹为快：      

1、第一范式1NF

定义：数据库表中的字段都是单一属性的。不可再分。

通俗简单的说，每个属性都是原子项，不可切割。

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

2、第二范式2NF

定义：假设关系模式R是1NF，且每一个非主属性全然函数依赖于候选键。

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

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

3、第三范式3NF

定义：假设关系模式R是1NF，且每一个非主属性都不传递依赖于R的候选键。

通俗简单的说，消除没有直接依赖于第一范式和第二范式形成的表的主键的属性。为没有与表的主键关联的全部信息建立了一张新表。

每张新表保存了来自原表的信息和它们所依赖的主键。

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

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

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

从我的ER图中能够清晰的观察到各个实体间的关系和实体的属性。以及实体间的联系。从而能够转换成关系模型。

怎样转换自己百度一下吧。

个别房重建工作才刚刚开始……这是道路的起点似几乎有点过于强硬，改革并提出了自己的罪，残破的牙齿只能够往肚子里咽，走一步看一步。你能行的。