关系数据库范式 数据库三大范式

大家好，如果您还对关系数据库范式不太了解，没有关系，今天就由本站为大家分享关系数据库范式的知识，包括数据库三大范式的问题都会给大家分析到，还望可以解决大家的问题，下面我们就开始吧！

如何深入理解关系型数据库的三大范式

二、数据库范式分类

目前关系数据库有六种范式：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。满足最低要求的范式是第一范式（1NF）。在第一范式的基础上进一步满足更多规范要求的称为第二范式（2NF），其余范式以次类推。一般来说，数据库只需满足第三范式(3NF）就行了。

三、数据库三大范式剖析

3.1第一范式（1NF）

第一范式强调每一列都是不可分割的原子数据项。

说到原子这个词，肯定有小伙伴就先到了原子性问题，其实这么想也是没有错的。那就让我带你们去剖析一下第一范式。

首先，我用Excel表格模拟数据库中的表，并在表中填入了一些数据。如下：

image-20200613164428707

当你看到这些数据的时候，是否有些数据让你感到不适？我的答案，是的。当我看到系名/系主任这一列数据的时候感觉这并不合符我们数据库的设计理念，因为它完全可以拆分为两个列的。其实每一个人的思想中的已经有了这个范式要求的概念，只是你并不知道这个概念叫做第一范式。

如果有的小伙伴说，这些数据都让感到不适，那我就在这里夸上你一句，你很聪明。但是请你跟紧我的思路，我会一步一步的将数据落实到范式中！

表1显然不遵循第一范式，那我们就把它修改一下，让其遵循第一范式的要求。

image-20200613164455095

将系名/系主任的列拆分成了两个列系名和系主任后，很明显改数据已经遵循的第一范式的要求。再来看看这张表2，聪明的你是不是第一眼又发现了问题呢？

存在的问题：

存在非常严重的数据冗余，姓名、系名、系主任

添加数据问题：当在数据表中添加一个新系和系主任时，比如：在数据表中添加高主任管理化学系。你会发现添加之后，在一个数据表中就会多出来了高主任和化学系，而这两个数据并没有对应哪个学生，显然这时不合法的数据。

删除数据问题：如果Jack同学毕业多年了，我们数据表中没有必要在留Jack相关的数据了，就会想到把Jack相关的删除掉。当你在表2的表结构中删除了Jack相关数据，你会发现整个刘主任和管理系以及会计和酒店管理都消失了，难道数据表中没有这些数据就证明这个学校没有它们吗？显然这更加离谱了！

了解了只遵循第一范式带来的麻烦，我们就需要去看一下第二范式是怎么定义的，是否能解决第一范式留下来的问题！

3.2第二范式（2NF）

第二范式在1NF的基础上，非属性码的属性必须完全依赖于主码。（在1NF基础上消除非属性码的属性对主码的部分函数依赖）

看到第二范式的概念，现在你应该是一个不懂的状态。那让我带你了解几个概念吧，这样你就会懂了！

函数依赖（完全、部分、传递）

函数依赖： A-> B，如果通过A属性（或属性组）的值可以确定唯一B属性的值，则可以成为B依赖于A（->符号是确定关系）。例如：可以通过学号来确定姓名，可以通过学号和课程来确定该课程的分数等等

完全函数依赖： A-> B，如果A是一个属性组，则B属性的确定需要依赖A属性组中的所有属性值。例如：分数的确定需要依赖于学号和课程，而学号和课程可以称为一个属性组。如果有学号没有课程，我们只知道是谁的分数，而不知道是那一学科的分数。如果有课程没有学号，那我们只知道是哪一个学科的分数，而不知道是谁的分数。所以该属性组的两个值是必不可少的。这就是完全函数依赖。

部分函数依赖： A-> B，如果A是一个属性组，则B属性的确定需要依赖A属性组中的部分属性值。例如：如果一个属性组中有两个属性值，它们分别是学号和课程名称。那姓名的确定只依赖这个属性组中的学号，于课程名称无关。简单来说，依赖于属性组的中部分成员即可成为部分函数依赖。

传递函数依赖： A-> B-> C，传递函数依赖就是一个依赖的传递关系。通过确定A来确定B，确定了B之后，也就可以确定C，三者的依赖关系就是C依赖于B，B依赖于A。例如：我们可以通过学号来确定这位学生所在的系部，再通过系部来确定系主任是谁。而这个三者的依赖关系就是一种传递函数依赖。

候选码、主属性码与非属性码

码：如果在一张表中，一个属性或属性组，被其他所有属性所完全函数依赖，则称这个属性（或属性组）为该表的候选码，简称码。然而码又分为主属性码和非属性码。例如：分数的确定没有学号和课程是不行的，所以分数完全函数依赖于课程和学号。

主属性码：主属性码也叫主码，即在所有候选码挑选一个做主码，这里相当于是主键。例如：分数完全函数依赖于课程和学号。该码属性组中的值就有课程、学号和分数，所以我们要在三个候选码中，挑选一个做主码，那就可以挑选学号。

非属性码：除主码属性组以外的属性，叫做非属性码。例如：在分数完全函数依赖于课程和学号时，其中学号已经让我们选为主码。那么我们就可以确定，除了学号以外的属性值，其他的属性值都是非属性码。也就是说在这个完全函数依赖关系中，课程和分数是非属性码。

当我们了解这些概念后，回过头来再看2NF的概念：在1NF的基础上，非属性码的属性必须完全依赖于主码（在1NF基础上消除非属性码的属性对主码的部分函数依赖）

我们还使用分数完全函数依赖于学号和课程这个函数依赖关系。此关系中非属性码为：课程和分数，主码为学号。梳理清楚关系后，遵循在1NF基础上，非属性码的属性必须完全依赖于主码的第二范式。就需要继续修改表结构了。遵循1NF和2NF的表结构如下：

image-20200613170300513

image-20200613170326468

正如你所看到的，我们把表2根据1NF和2NF拆分成了表3和表4。这时候你再看表3，表3中的分数就完全函数依赖于表3中的学号和课程。表4中也挑选学号做主码。虽然解决了数据冗余问题，但是仅仅这样还是不够的，上述问题中其他的两个问题并没有得到解决！

存在的问题：

数据删除问题

数据添加问题

注意：在第二范式中存在的这两个问题，就是在第一范式中存在问题的其中两个并没有得到解决。

既然第一范式和第二范式都没有解决这两个问题，那第三范式帮你解决！

3.3第三范式（3NF）

第三范式在2NF基础上，消除传递依赖。

说到传递依赖，那我们的数据表中还有哪些传递依赖呢？这时候你会发现表4中含有传递依赖的。表4中的传递依赖关系为：姓名->系名->系主任。该传递依赖关系为系主任传递依赖于姓名。再根据此传递依赖关系分析我们添加和删除问题就漏洞百出了。消除传递依赖的办法还是将表4进行拆分。拆分后的表结构如下：

image-20200613172237233

image-20200613172303711

当我们把表4拆分成表5和表6时，你再来分析添加和删除问题就会有不一样的结果。假设在数据表中添加高主任管理的化学系时，该数据只会添加到表6中，不会发生传递依赖而影响其他数据。那假设Jack同学毕业了，要将Jack同学的相关数据从表中删除，这时我们需要删除表6中的学号3数据和表3中的学号3数据即可，它们也没有传递依赖关系，同样不会影响到其他数据。

四、范式的表设计

在这里我详细讲解了数据库的三大范式，为什么一般我们只研究三大范式而不去延申至六大范式呢？在上面数据库范式概念的时候，我也有讲过。这里我还需要强调一下！

数据库六大范式，一级比一级要求得严格。各种范式呈递次规范，越高的范式数据库冗余越小。范式即是对数据库表设计的约束，约束越多，表设计就越复杂。表数据过于复杂，对于我们后期对数据库表的维护以及扩展、删除、备份等种种操作带来了一定的难度。所以，在实际开发中我们只需要遵循数据库前面的三大范式即可，不需要额外延申扩展。

注意：在剖析三大范式的时候，最终版本的表结构就是表3+表5+表6。我需要在这里说明一个问题，其实这样设计表是可以的，但并不是很合理。因为我们在建表的时候是有主键和外键约束的。这三张表中，第一列的表默认为主键，其中主键为学号还可以接收，如果主键为系名那就占用的空间变大了。在表的级联查询中会损耗性能。所以，一般我们在设计表的时候，是需要主外键约束的，而其主外键基本是都是占用内容空间很小的数字。当你的表结构和需求满足主键递增时，则可以通过设置auto_increment参数来完成！

这里如果不了解MySQL主外键约束的小伙伴，可以参考此文章MySQL基础来查补缺漏知识点。

如何深入理解关系型数据库的三大范式

标签：title就是break知识点bordernear从表maxval

数据库五大范式是什么

第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话和一个家里电话号码）规范成为1NF有三种方法：

一是重复存储职工号和姓名。这样，关键字只能是电话号码。

二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性

三是职工号为关键字，但强制每条记录只能有一个电话号码。

以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。

第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R是属于第二范式的。

例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE为成绩，CREDIT为学分。由以上条件，关键字为组合关键字（SNO，CNO）

在应用中使用以上关系模式有以下问题：

a.数据冗余，假设同一门课由40个学生选修，学分就重复40次。

b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。

c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。

d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。

原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。

解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系

第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。

例：如S1（SNO，SNAME，DNO，DNAME，LOCATION）各属性分别代表学号，

姓名，所在系，系名称，系地址。

关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。

原因：关系中存在传递依赖造成的。即SNO-> DNO。而DNO-> SNO却不存在，DNO-> LOCATION,因此关键辽 SNO对 LOCATION函数决定是通过传递依赖 SNO-> LOCATION实现的。也就是说，SNO不直接决定非主属性LOCATION。

解决目地：每个关系模式中不能留有传递依赖。

解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）

注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。

例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件

a.一个仓库有多个职工。

b.一个职工仅在一个仓库工作。

c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。

d.同一种型号的配件可以分放在几个仓库中。

分析：由以上得 PNO不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO）-> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）-> ENO。因为一个职工仅在一个仓库工作，有ENO-> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有（ENO，PNO）-> QNT。

找一下候选关键字，因为（WNO，PNO）-> QNT，（WNO，PNO）-> ENO，因此（WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。

分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而P->WNO，故（ENO，PNO）-> WNO也是传递依赖。

虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。

解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO

缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO丢失了,因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。

一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。

1NF直到BCNF的四种范式之间有如下关系：

BCNF包含了3NF包含2NF包含1NF

数据库范式是什么意思

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

一、区别

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

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

二、举例

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

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

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

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

扩展资料

数据库范式概念引入原因

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

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

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

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

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

END，本文到此结束，如果可以帮助到大家，还望关注本站哦！