关系模型原理的核心是“规范化”，规范化是把数据库组织成在保持存储数据完整性的同时最小化冗余数据的结构过程。规范化的数据库是符合关系模型规则的数据库，通常把这些规则称为范式。
范式是符合某一种级别的关系模式的集合，关系数据库中的关系必须满足一定的要求即满足不同的范式。
下面主要讲的的是三范式。
第一范式
第一范式是指数据表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。第一范式包括下列指导原则：
- 数组的每个属性只能包含一个值
- 关系中的每个数组必须包含相同的数量的值
- 关系中的每个数组一定不能相同
举例：
从上图一眼就可以看出可怕的合并问题，当然，我举的例子有点夸张了。
要满足第一范式就得改成如下：将日期和时间分开，将系别、年级还有班级分开，还有一些情况，如将省市县分开，将合并的情况分开。
第二范式
如果一个数据表已经满足第一范式，而且该数据表中的任何一个非主键字段的数值都依赖于该数据表的主键字段，那么该数据表满足第二范式。
也就是说，假如给出一个学号（09110241005），就能推测出与该学生对应的学生姓名是巨亚红，也能推测出对应的性别是女，以及他的年级，班级等。如果该表中存在音乐老师姓名，还有音乐老师所属院系音乐学院这一字段，那么就出现了问题。老师所属院系并不依赖我们的学号，而是依赖音乐老师这一字段，因此虽然此表符合第一范式，但是并不符合第二范式，所以可以将此表拆分出一个教师表。
其实，在此次机房收费系统的数据库设计阶段，我也遇到了差不多的问题。有一个学生表，还有一个学生正在上机表，按范式的要求，学生表存储学生信息，正在上机表存储上机信息就可以了，比如说上机日期、时间，学生卡号和姓名、机器号，我认为不应该再加上学生的所属系别和性别，因为加上这些就使正在上机表的中心涣散了。
正在上机功能展示：
原来的数据表：
因此，在实现代码的时候，需要根据根据卡号查询Student表（学生信息表）来获取StudentNo，StudentName，Department，Sex以及Cash信息，显示在界面中，并存储在正在上机表中。但是在查询正在上机状态的时候，只是需要以下信息：
所以，在记录上机信息的时候本没有必要加入一些学生的基本信息如学生系别、姓名等，将来如果程序中需要这些查询更详细的信息时，本可以用视图来完成的。
因此，后来把正在上机记录表中的StudentNo、Department、Sex字段删掉。
以上只是自己在做系统时的一点小想法，如果可以有更好的数据库安排，希望能得到指导，感激不尽。
第三范式
如果一个数据表已经满足第二范式，而且该数据表中的任何两个非主键字段的数值之间不存在函数信赖关系，那么该数据表满足第三范式。
感觉第三范式是最好理解的一个范式，所谓函数信赖关系，就是其中一个字段通过计算能得出另一个字段，那么另一个字段就没有必要加在数据表中了，就会出现数据冗余，有时候为了效率而放弃三范式的要求也是可以理解的，正如师兄师姐们说的，适合自己的，才是最好的。这些都需要自己去平衡。
有关于Sql Server的学习还在继续。因为好的数据库设计，就会为系统搭构好的地基。完成了好的设计，整个系统的工作就完成了百分之七十。