关系模式规范化举例理解：第一范式、第二范式、第三范式

参考：http://wenku.baidu.com/link?url=KzN3v3voao4ovz_izsiujMN8vMZMiArzgYbrue8tVL5L_ydc1B_6_1eEy7vfoSiO2-ORTXAXzVBxzWAaXJxiR68z6g4GMD_1AlZWzx46MSG

第一范式（1NF）：关系中的所有分量不可再分，即数据库表中的字段都是单一属性的，不可再分。

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系型数据库。

例如，这样是符合的：Student（id，name，age，class）

而这样就不符合：Student（id，（first name， last name），age，class）

第二范式（2NF）：如果关系模式R属于1NF，且每一个非主属性都完全依赖于主码，则称关系R是属于第二范式的，记作R属于2NF。

第二范式是在第一范式的基础上建立的。

例如，

假定选修课关系表为SelectCourse(学号，姓名，年龄，课程名称，成绩，学分)，关键字为组合关键字（学号，课程名称），因为存在如下决定关系：

（学号，课程名称）->（姓名，年龄，成绩，学分）

这个数据库表不满足第二范式，因为存在如下决定关系：

（课程名称）->（学分）

（学号）->（姓名，年龄）

即存在学分和姓名，年龄部分依赖于主关键字。

修改，我们将设计修改了一下，把选课关系表SelectCourse改为如下三个表：

学生：Student（学号，姓名，年龄）

课程：Course（课程名称，学分）

选课关系：SelectCourse（学号，课程名称，成绩）

注意：所有的单关键字的数据库表都符合第二范式，因为不可能存在组合关键字，也就不可能存在非主属性部分依赖于主关键字了。

第三范式（3NF）：关系中非主属性必须直接依赖于主码，而不能通过其他非主属性传递依赖于主码。

传递依赖，如：A依赖于B，B依赖于C，那么，A传递依赖于C。

假定学生关系表为Student（学号，姓名，年龄，所在学院，学院地点，学院电话），关键字为单一的学号，所以肯定符合第二范式，但是因为存在非关键字学院地点和学院电话依赖于所在学院，即传递依赖于学号，所以此关系表不符合第三范式。同样会导致数据冗余，DDL操作异常等问题。

所以我们可以对其进行修改：

学生：（学号，姓名，年龄，所在学院）

学院：（学院，地点，电话）

这样的数据库表就符合第三范式了。

在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。

规范化过程：