数据库六大范式详解

版权声明:本文为CSDN博主「小九的博客」的原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_43433032/article/details/89293663

 

百科上对三大范式的解释是:

第一范式(1NF):

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

第二范式(2NF):

第二范式(2NF)要求数据库表中的每个实例或行必须可以被唯一地区分。 为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。

第三范式(3NF):

 简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。 例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。

 

以下是正文:

**

数据库六大范式详解
**

关系数据库中的关系满足一定要求的,满足不同程度要求的为不同的范式。满足最低要求的叫第一范式,简称1NF;在第一范式的基础上满足进一步要求的称为第二范式,简称2NF,其余范式以此类推。对于各种范式之间有如下关系:

如下图所示:

 

1. 第一范式 1NF

定义: 属于第一范式关系的所有属性都不可再分,即数据项不可分。

理解: 第一范式强调数据表的原子性,是其他范式的基础。如下图所示数据库就不符合第一范式:

上表将商品这一数据项又划分为名称和数量两个数据项,故不符合第一范式关系。改正之后如下图所示:

上表就符合第一范式关系。

但日常生活中仅用第一范式来规范表格是远远不够的,依然会存在数据冗余过大、删除异常、插入异常、修改异常的问题,此时就需要引入规范化概念,将其转化为更标准化的表格,减少数据依赖。

规范化: 一个低一级的关系模式通过模式分解可以转化为若干个高一级范式的关系模式的集合,这个过程叫做规范化。

 

2. 第二范式 2NF

定义: 若某关系R属于第一范式,且每一个非主属性完全函数依赖于任何一个候选码,则关系R属于第二范式。

此处我们需要理解非主属性、候选码和完全函数依赖的概念。

候选码: 若关系中的某一属性组的值能唯一地标识一个元组,而其子集不能,则称该属性组为候选码。若一个关系中有多个候选码,则选定其中一个为主码。

以下所有内容中,主码或候选码都简称为码。

例如下图所示的学生表中,学号和姓名都可以唯一标识一个元组,故该表的候选码为学号和姓名,主码我们可以随便选定其中一个,则选学号为主码。

学号   姓名    年龄    性别
101    刘晨     19     女
102    王琪     21     男
103    张宇     20     男
104    李琛     19     女
105   欧阳慧    20     女

主属性: 所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性。

在上面的学生表中,学号和姓名就是该关系的主属性,年龄和性别就是非主属性。

函数依赖: 设R(U)是属性集U上的关系模式,X、Y是U的子集。若对于R(U)的任意一个可能的关系r,r中不可能存在两个元组在X上的属性值相等,而在Y上的属性值不等,则称Y函数依赖于X或X函数确定Y。

完全函数依赖: 设R(U)是属性集U上的关系模式,X、Y是U的子集。如果Y函数依赖于X,且对于X的任何一个真子集X’,都有Y不函数依赖于X’,则称Y对X完全函数依赖。记作:如果Y函数依赖于X,但Y不完全函数依赖于X,则称Y对X部分函数依赖。


理解: 第二范式是指每个表必须有一个(有且仅有一个)数据项作为关键字或主键(primary key),其他数据项与关键字或者主键一一对应,即其他数据项完全依赖于关键字或主键。由此可知单主属性的关系均属于第二范式。

判断一个关系是否属于第二范式:

1.找出数据表中的所有码;
2.找出所有主属性和非主属性;
3.判断所有的非主属性对码的部分函数依赖。

以上面的学生表为例,表中的码为学号(码可以为学号或者姓名,此处假定码为学号),非主属性为性别、年龄(其余都为主属性),当学号确定时,性别、年龄也都惟一的被确定为,故学生表的设计满足第二范式(学生表为单主属性的关系)。

下面举一个不满足第二范式的关系。
有关系模式S-L-C(Sno, Sdept, Sloc, Cno, Grade),其中Sno, Sdept, Sloc, Cno, Grade依次表示学生的学号、所在的系、住处、课程号、班级,并且每个系的学生住在同一个地方。可知S-L-C的码为(Sno, Cno),则存在以下函数依赖:

可以看到,非主属性Sloc、Sdept并不完全函数依赖于码,因此关系模式S-L-C(Sno, Sdept, Sloc, Cno, Grade)不符合第二范式。

 

3. 第三范式 3NF

定义: 非主属性既不传递依赖于码,也不部分依赖于码。

首先我们要理解传递函数依赖的概念。

理解: 第三范式要求在满足第二范式的基础上,任何非主属性不依赖于其他非主属性,即在第二范式的基础上,消除了传递依赖。

在下图S-L关系中,Sloc对Sno传递函数依赖,故该关系不属于第三范式。

 

4. BC范式 BCFN

定义: 关系模式R<U,F>中,若每一个决定因素都包含码,则R<U,F>属于BCFN。

理解: 根据定义我们可以得到结论,一个满足BC范式的关系模式有:

1.所有非主属性对每一个码都是完全函数依赖;
2.所有主属性对每一个不包含它的码也是完全函数依赖;
3.没有任何属性完全函数依赖于非码的任何一组属性。

例如有关系模式C(Cno, Cname, Pcno),Cno, Cname, Pcno依次表示课程号、课程名、先修课。可知关系C只有一个码Cno,且没有任何属性对Cno部分函数依赖或传递函数依赖,所以关系C属于第三范式,同时Cno是C中的唯一决定因素,所以C也属于BC范式。

 

5. 第四范式 4NF

定义: 限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。

理解: 显然一个关系模式是4NF,则必为BCNF。也就是说,当一个表中的非主属性互相独立时(3NF),这些非主属性不应该有多值,若有多值就违反了4NF。

 

6. 第五范式 5NF

第五范式有以下要求:
(1)必须满足第四范式;
(2)表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。

第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况,而第五范式则处理相互依赖的多值情况。

   还没有人评论 到此为止 | 继续阅读 >>