范式：
范式是符合某一种级别的关系模式的集合，关系数据库的规范化理论认为：关系数据库的每一个关系都要满足一定的要求，满足不同程度要求的为不同范式。
第一范式（1NF）：
当关系模式R的所有属性都不能在分解为更基本的数据单位时，称R是满足第一范式的，简记为1NF。满足第一范式是关系模式规范化的最低要求，否则，将有很多基本操作在这样的关系模式中实现不了。在第一范式中，数据表的每一列只能存储实体的一个属性。例如：对于学生信息，不可以将学生实体的两个或多个属性信息（学号、性别、年龄等）放在一个列中显示，学生实体的每一个属性信息都要放在一个列中显示。
学号 姓名 性别 年龄 班级
9527 东方延续 女 23 计算机系3班
上面的表格中班级列中包含了系别和班级两个属性信息，这样班级列的信息就不是单一的，是可以再分的，就不符合第一范式，我们可以将其拆分成下表的形式，使其满足第一范式。
学号 姓名 性别 年龄 班级 系别
9527 东方延续 女 23 3班 计算机系
第二范式（2NF）：
第二范式(Second Normal Form,2nd NF)是指每个表必须有一个数据元素为主关键字(Primary key),其他数据元素与主关键字一一对应。通常称这种关系为函数依赖(Functional dependence)关系，即表中其他数据元素都依赖于主关键字,或称该数据元素惟一地被主关键字所标识。第二范式是数据库规范化中所使用的一种正规形式。它的规则是要求数据表里的所有非主属性都要和该数据表的主键有完全依赖关系；如果有哪些非主属性只和主键的一部份有关的话，它就不符合第二范式。同时可以得出：如果一个数据表的主键只有单一一个字段的话，它就一定符合第二范式(前提是该数据表符合第一范式)
若关系模式R∈1NF（即R符合第一范式），并且每一个非主属性都完全依赖于R的主码，则R∈2NF（即R符合第二范式）。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，理解了完全依赖和部分依赖，就很容易理解第二范式，下面举例说明一下。例如以下实例中的关系模式，就是不符合2NF的一个典型例子。
货物类型 货物ID 货物名称 注意事项
瓷碗 1 白色瓷碗 易碎品
瓷碗 2 青花瓷碗 易碎品
瓷碗 3 雕花瓷碗 易碎品
三合板 1 普通三合板 易燃物品，注意防火
在该表中主键为（货物类型，货物ID），货物名称字段完全依赖于这个主键，换句话说，货物的名称完全是取决于这个主键的值的。但“注意事项”这一列，仅依赖于一个主键中”货物类型“这一个属性。简单地说，第二范式要求每个非主属性完全依赖于主键，而不是仅依赖于其中一部分属性。那么，既然表中存在一个对主键不是完全依赖的字段，那么我们就可以确定，该表不符合第二范式。
符合第二范式的例子
货物类型 货物ID 货物名称
瓷碗 1 白色瓷碗
瓷碗 2 青花瓷碗
瓷碗 3 雕花瓷碗
三合板 1 普通三合板
在该表中的主键依然是（货物类型、货物ID），非主键字段“货物名称”，完全依赖于这两个主键，那么我们就可以说，该表是符合数据库第二范式的。
第三范式（3NF）
数据不能存在传递函数依赖，即每个属性都跟主键有直接关系而不是间接关系。像：a-->b-->c 属性之间含有这样的关系，是不符合第三范式的。
员工编号 员工姓名 年龄 部门编号 部门经理
01223 罗辑 102 联合政府面壁部 理查德
在该关系表中，隐含着如下决定关系：
（员工编码）——>(决定) （部门编码）——>(决定) (部门经理)
上面的关系表存在着非关键字段“部门经理”对关键字段“员工编码”的传递函数依赖，因此不符合第三范式。对于上面这种关系，可以把这个关系表（EMPLOYEE）
更改为如下两个关系表，便能符合第三范式。
1、员工信息表：EMPLOYEE（员工编码，员工姓名，年龄，部门编码）。
2、部门信息表：DEPARTMENT(部门编码，部门经理)。
网友评论