概要 

     早就听说三范式了,记得第一次做机房收费系统的时候,只是为了简单的完成数据的增删改查,并没有去想数据库如何设计,现在不同了,第二遍设计数据库,要求提高了嘛，我们需要的是根据需求来更加合理的设计数据库,要遵循数据库的基本原则三范式,三范式刚开始听起来觉得懵懂,后来通过学习渐渐的明朗起来,首先介绍一下三范式的大致内容:

三范式的目的

     为了建立合理结构的数据库，减少数据冗余，设计数据库必须要遵循一定的规则，在关系型数据库中这种规则叫做范式，想设计一个结构合理的关系型数据库，必须要满足一定的范式，我们把一个项目中用到的数据库分别建立多个表并建立表中间的关系，可以消除很多错误或者垃圾数据并减少我们的工作量、减少数据的不完整性，是数据库设计的更加规范。

详细剖析

     范式达到五个，但是对于我们来说，三个范式已经很高了，（后期再逐渐的深入学习）

第一范式（1NF）：就是能分就分，分到不能分为止（所有字段值都是不可分解的原子值）

    第一范式（1NF），（一个字段不能包含多个列，即每个列和记录包含一个仅包含一个值的表）在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

    所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。 第一范式的合理遵循需要根据系统的实际需求来定

例如：实例1

    不满足第一范式，学院、年级、班都是还可以再往下分的

改进后：

第二范式（2NF）：要求实体的属性完全依赖于主关键字（函数不能部分依赖）。

    第二范式在第一范式的基础上，要保证数据库表中的每一列都和主键相关，完全依赖主键，所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是非主属性非部分依赖于主关键字（一种表只能保存一种数据，不可以把多种数据保存在同一张数据库表中）

    对于自己第一遍的机房收费系统数据库学生信息表，当时就是为了表减少,调用方便现在现在看起来很是冗余。例如下图：