数据库三范式

关系数据库设计范式介绍

1 第一范式（1NF）无重复的列

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性，就可能需要定义一个新的实体，新的实体由重复的属性构成，新实体与原实体之间为一对多关系。在第一范式（1NF）中表的每一行只包含一个实例的信息。简而言之，第一范式就是无重复的列。

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

12 第二范式（2NF）属性完全依赖于主键[消除部分子函数依赖]

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。第二范式（2NF）要求数据库表中的每个实例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。例如员工信息表中加上了员工编号（emp_id）列，因为每个员工的员工编号是惟一的，因此每个员工可以被惟一区分。这个惟一属性列被称为主关键字或主键、主码。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的惟一标识。简而言之，第二范式就是属性完全依赖于主键。

13 第三范式（3NF）属性不依赖于其它非主属性[消除传递依赖]

满足第三范式（3NF）必须先满足第二范式（2NF）。简而言之，第三范式（3NF）要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。例如，存在一个部门信息表，其中每个部门有部门编号（dept_id）、部门名称、部门简介等信息。那么在的员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表，则根据第三范式（3NF）也应该构建它，否则就会有大量的数据冗余。简而言之，第三范式就是属性不依赖于其它非主属性。

II、范式应用实例剖析

下面以一个学校的学生系统为例分析说明，这几个范式的应用。首先第一范式（1NF）：数据库表中的字段都是单一属性的，不可再分。这个单一属性由基本类型构成，包括整型、实数、字符型、逻辑型、日期型等。在当前的任何关系数据库管理系统（DBMS）中，傻瓜也不可能做出不符合第一范式的数据库，因为这些DBMS不允许你把数据库表的一列再分成二列或多列。因此，你想在现有的DBMS中设计出不符合第一范式的数据库都是不可能的。

首先我们确定一下要设计的内容包括那些。学号、学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话等信息。为了简单我们暂时只考虑这些字段信息。我们对于这些信息，说关心的问题有如下几个方面。

学生有那些基本信息

学生选了那些课，成绩是什么

每个课的学分是多少

学生属于那个系，系的基本信息是什么。

21 第二范式（2NF）实例分析

首先我们考虑，把所有这些信息放到一个表中(学号，学生姓名、年龄、性别、课程、课程学分、系别、学科成绩，系办地址、系办电话)下面存在如下的依赖关系。

（学号）→ (姓名, 年龄，性别，系别，系办地址、系办电话)

(课程名称) → (学分)

（学号，课程）→ (学科成绩)

211 问题分析

因此不满足第二范式的要求，会产生如下问题

数据冗余： 同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。

更新异常：

1)若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。

2)假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据库。

删除异常 ： 假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。

212 解决方案

把选课关系表SelectCourse改为如下三个表：

学生：Student(学号，姓名, 年龄，性别，系别，系办地址、系办电话)；

课程：Course(课程名称, 学分)；

选课关系：SelectCourse(学号, 课程名称, 成绩)。

22 第三范式（3NF）实例分析

接着看上面的学生表Student(学号，姓名, 年龄，性别，系别，系办地址、系办电话)，关键字为单一关键字"学号"，因为存在如下决定关系：

（学号）→ (姓名, 年龄，性别，系别，系办地址、系办电话)

但是还存在下面的决定关系

(学号) → (所在学院)→(学院地点, 学院电话)

即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

它也会存在数据冗余、更新异常、插入异常和删除异常的情况。 (数据的更新，删除异常这里就不分析了，可以参照211进行分析)

根据第三范式把学生关系表分为如下两个表就可以满足第三范式了：

学生：(学号, 姓名, 年龄, 性别，系别)；

系别：(系别, 系办地址、系办电话)。

总结

上面的数据库表就是符合I,II,III范式的，消除了数据冗余、更新异常、插入异常和删除异常。

第三范式指数据库中不能存在传递函数依赖关系。

简而言之， 第三范式（ 3NF） 要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。

所以第三范式具有如下特征：

1， 每一列只有一个值

2， 每一行都能区分。

3， 每一个表都不包含其他表已经包含的非主关键字信息。

例如， 帖子表中只能出现发帖人的 id， 而不能出现发帖人的 id， 还同时出现发帖人姓名，

否则， 只要出现同一发帖人 id 的所有记录， 它们中的姓名部分都必须严格保持一致， 这就是数据冗余。

范式

构造数据库必须遵循一定的规则在关系数据库中这种规则就是范式范式是符合

某一种级别的关系模式的集合关系数据库中的关系必须满足一定的要求即满足不同的

范式目前关系数据库有六种范式第一范式1NF 第二范式2NF 第三范式3NF

第四范式4NF 第五范式5NF 和第六范式6NF 满足最低要求的范式是第一

范式1NF 在第一范式的基础上进一步满足更多要求的称为第二范式2NF 其余

范式以次类推一般说来数据库只需满足第三范式3NF 就行了下面我们举例介绍

第一范式1NF 第二范式2NF 和第三范式3NF

第一范式1NF

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

范式1NF 的数据库就不是关系数据库

所谓第一范式1NF 是指数据库表的每一列都是不可分割的基本数据项同一列中

不能有多个值即实体中的某个属性不能有多个值或者不能有重复的属性如果出现重复

的属性就可能需要定义一个新的实体新的实体由重复的属性构成新实体与原实体之

间为一对多关系在第一范式1NF 中表的每一行只包含一个实例的信息例如对

于图3-2 中的员工信息表不能将员工信息都放在一列中显示也不能将其中的两列或多

列在一列中显示员工信息表的每一行只表示一个员工的信息一个员工的信息在表中只

出现一次简而言之第一范式就是无重复的列

第二范式2NF

第二范式2NF 是在第一范式1NF 的基础上建立起来的即满足第二范式2NF

必须先满足第一范式1NF 第二范式2NF 要求数据库表中的每个实例或行必须可

以被惟一地区分为实现区分通常需要为表加上一个列以存储各个实例的惟一标识如

图3-2 员工信息表中加上了员工编号emp_id 列因为每个员工的员工编号是惟一的

因此每个员工可以被惟一区分这个惟一属性列被称为主关键字或主键主码

第二范式2NF 要求实体的属性完全依赖于主关键字所谓完全依赖是指不能存在

仅依赖主关键字一部分的属性如果存在那么这个属性和主关键字的这一部分应该分离

出来形成一个新的实体新实体与原实体之间是一对多的关系为实现区分通常需要为表

加上一个列以存储各个实例的惟一标识简而言之第二范式就是非主属性非部分依赖

于主关键字

第三范式3NF

满足第三范式3NF 必须先满足第二范式2NF 简而言之第三范式3NF

要求一个数据库表中不包含已在其它表中已包含的非主关键字信息例如存在一个部门

信息表其中每个部门有部门编号dept_id 部门名称部门简介等信息那么在图3-2

的员工信息表中列出部门编号后就不能再将部门名称部门简介等与部门有关的信息再加

入员工信息表中如果不存在部门信息表则根据第三范式3NF 也应该构建它否则

就会有大量的数据冗余简而言之第三范式就是属性不依赖于其它非主属性

范式是数据库中的关于关系模式的分类，是越来越严苛的分类。

一、区别

1、第三范式指表中的所有数据元素不但要能唯一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。第三范式就是在第二范式的基础上再消除表中有可能存在某些数据元素依赖于其他非关键字数据元素的现象。

2、BC范式是指对于关系模式R，若 R为第一范式，且每个属性都不部分依赖于候选键也不传递依赖于候选键。BC比第三范式更严苛的条件是：要求R为第二范式且非键属性不传递依赖于R的候选键，而BC范式则是对R的每个属性都做要求。即决定因素为候选码。

二、举例

以下关系模式满足第三范式

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 地点, 电话)。

其中的关系函数为：学号->姓名、学号->年龄、学号->学院、学院->地点、学院->电话。可以看出所有的关系函数均为一候选码为决定因素（函数的前半部分）那么可以说此关系模式满足BCNF。

扩展资料

数据库范式概念引入原因

规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小。便于插入、删除和更新。

遵从概念单一化“一事一地”原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。

一个关系模式接着分解可以得到不同关系模式集合，也就是说分解方法不是惟一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空问，避免数据不一致性，提高对关系的 *** 作效率，同时满足应用需求。

实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

参考资料来源：百度百科-数据库范式

首先你的问题是错误的：

X→Y表示Y函数依赖于X，而X可以是码与非主属性的集合。

第三范式（3NF）的定义是：非主属性不传递函数依赖于码，既非主属性都直接函数依赖于码。

举一个例子：

关系模式S-L(Sno,Dept,Loc)

以上就是关于数据库三范式全部的内容，包括:数据库三范式、数据库的第三范式是什么意思、数据库中3NF的含义等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！