1. 编程号首页

第一范式第二范式第三范式的定义_第一范式第二范式第三范式的定义

编程小号 • • 未分类

第一范式第二范式第三范式的定义_第一范式第二范式第三范式的定义第一范式、第二范式、第三范式、BCNF范式详解：函数依赖，完全，部分，传递，码，主和非主属性

  • 建议从文章3开始看，写的不错的。

文1：第一范式、第二范式、第三范式、BCNF（BC范式）

范式原理笔记
数据库关系数据理论—-范式
范式原理笔记
什么是（范式）—范式介绍
范式发展
基础知识
五元组
函数依赖
平凡函数依赖
非平凡函数依赖
完全函数依赖
非完全函数依赖
1、第一范式
2、第二范式
3、第三范式
4、BCNF（扩展第三范式）
————————————————
版权声明：本文为CSDN博主「gussu-毛虫」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/weixin_46897073/article/details/110091939

什么是（范式）—范式介绍

官方介绍，数据库中的关系是要满足一定要求的，满足不同程度要求的为不同范式。

  • 满足最低要求的叫第一范式，简称1NF；

  • 在第一范式中满足进一步要求的为第二范式，其余的一次类推。

  • [normal form](javascript:😉

还不懂？

那么简单来说范式是一种标准，也就是你设计表结构是要符合规范。就好像是你装修自己的房子，你按照的标准越高，那么你的房子就更加的牢固安全。

所谓“第几范式”原本就是表示关系的某一级别，所以常称为某一关系模式R为第几范式。把这个范式这个概念理解为符合某一种级别的关系模式的集合，即R为第几范式就可以写为R∈xNF。
对各种范式之间的关系有：5NF⊂4NF⊂BCNF⊂3NF⊂2NF⊂1NF

一个低一级范式的关系模式 通过 模式分解 可以转换为 若干个高一级的范式的关系 模式的集合，这种过程就叫规范化。
各种范式之间的关系

范式发展

（此部分可忽略）
有关范式理论的研究主要是E.F.Codd做的工作。1971-1972年Codd系统的提出了1NF、2NF、3NF的概念，讨论了规范化的问题。1974年，Codd和Boyce共同提出了一个新范式，即BCNF。1976年Fagin提出了4NF。后来又有研究人员提出5NF。

基础知识

为了更好的了解范式，需要先了解一些定义：

五元组
R(U,D,DOM,F)
1、关系名R是符号化的元组语义。
2、U为一组属性。
3、D为属性组U中的属性所来自的域。
4、DOM为属性到域的映射。
5、F为属性组U上的一组数据依赖。
由于D、DOM本篇内容关系不大，因此只需理解其余三条即可。

那就形成了三元组： R<D,F>
数据依赖是一个关系内部属性与属性之间的一种约束关系。这种约束关系是通过属性间值的相等于否体现出来的数据间相关关系。

函数依赖
定义：设R(U)是属性集U上的关系模式，X，Y是U的子集。若对R(U)的任意一个可能关系r,r中不可能存在两个元组在X上的属性相等，而在Y上的属性不等，则称X函数确定Y或Y函数依赖于X，记作X->Y。
例如：姓名->年龄这个函数依赖只有在该部门没有同名的条件下成立。如果允许有同名人，责年龄就不在函数依赖于姓名了。

平凡函数依赖

X->Y，但是Y⊈X，则称X->Y是非平凡函数依赖

非平凡函数依赖

X->Y，但是Y⊆X，则称X->Y是平凡函数依赖

完全函数依赖

在R(U)中，如果X->Y，并且对于X的任何一个真子集X’，都有X’不函数依赖于Y，称Y对X完全函数依赖。

非完全函数依赖

若X->Y，但Y不完全函数依赖于X，则称Y对X部分函数依赖。

1、第一范式

​ 第一范式是最基本的标准，作为一个二维表，要符合的最基本的条件：每一个分量必须是不可再分的数据项。满足了这个条件的关系模式就属于第一范式。
我们从一个表来理解一下第一范式的意思：
表1：

img

这里表一是不符合第一范式的，第范式规定：第一范式的所有属性都不能再分。这里进货这一属性又分为数量和单价。
那么该怎么测能使这个表符合第一范式那？我们只需要将进货属性与其子属性变成两个属性即可。
表2：

img

eg:
建立一个描述学校教务的数据库，该数据库设计对象包括

  • 学生学号（Sno）、
  • 所在系Sdept、
  • 系主任姓名Mname、
  • 课程号和Cno
  • 成绩Grade。

利用一个单一的关系模式Student来表示，则该关系模式的属性集合为
U={Sno,Sdept,Mname,Cno,Grade}

  1. 一个系有若干学生，但是一个学生只属于一个系。
    1. Sno->Sdept
  2. 一个系只有一个负责人。
    1. Sdept->Mname
  3. 一个学生可以选修很多门课，每门课程与若干学生选修。
  4. 每个学生学习每门课程有一个成绩。
    1. (Sno,Cno)->Grade

于是得到属性组U上的一组函数依赖F

于是得到属性组U上的一组函数依赖F。
F={Sno->Sdept,Sdept->Mname,(Sno,Cno)->Grade}
如只考虑函数依赖一种数据依赖，可得到一个描述学生的关系模式Student<U，F>。表3则是关系模式Student的一个实例。

表3：

img

但是，这个关系模式存在数据冗余、更新异常、插入异常和删除异常的问题。

数据冗余
系主任的姓名大量出现，重复的次数与该系学生所有课程成绩出现次数相同。
更新异常
因为数据冗余所以，系统要付出大量的代价来维护数据库的完整性。同时如果要更改系主任，需要更改该系中每一个学生的信息。
插入异常
如果新建立一个系，因为没有学生，则无法把系主任输入到数据库中。
删除异常
如果一个系中的全部学生毕业了，则在删除学生信息的同时，该系和系主任的信息也删除了。
因此可得出一个结论：Student模式并不是一个好模式。一个较好的模式应当不会发生更新异常、插入异常和删除异常，数据冗余应尽可能的少。
所以如果只符合第一范式并不能满足需求，下面我们开始了解第二范式。

  • 第二范式

定义：若R∈1NF，且每一个非主属性完全函数依赖与任何一个候选码，则R∈2NF。

一个关系不属于第二范式就会出现一下几个问题：

  • 插入异常、删除异常、修改异常

文2：【数据库】第一范式、第二范式、第三范式、BCNF详解

https://blog.csdn.net/Kzj_19/article/details/116308277

目录

1、范式

2、第一范式（1NF）

3、第二范式（2NF）

4、第三范式（3NF）

5、BCNF

6、小结

1、范式

是符合某一种级别的关系模式的集合。是关系数据库规范化过程中为不同程度的规范化要求设立的不同的标准或准则。不同的范式满足的要求不同。

基本思想：消除关系模式中的数据冗余，消除数据依赖中的不合适的部分， 解决数据插入、删除与修改时发生的异常现象。

已定义的范式：

1NF
↓消除非主属性对码的部分函数依赖

2NF
↓消除非主属性对码的传递函数依赖

3NF
↓消除主属性对码的部分和传递函数依赖

                 1NF、2NF、3NF、BCNF：基于函数依赖的范式

                         4NF：基于 多值依赖 的范式

                         5NF：基于 连接依赖 的范式

2、第一范式（1NF）

定义：如果一个关系模式R的所有属性都是不可分的基本数据项，则R∈1NF**。**

在任何一个关系数据库系统中，第一范式是对关系模式的一个最起码的要求。（最基本的要求！！）

不满足第一范式的数据库模式不能称为关系数据库。

姓名 部门 薪水
基本工资 提成

在表1中，我们可以发现薪水被分为基本工资和提成，所以这里的数据是不符合第一范式的要求。

例如，关系模式：**学生（学号、系部、学生住处、课程号、成绩），*码为（学号、课程号）*—后面举例时都会用到这个关系模式

但是满足第一范式的关系模式并不一定是一个好的关系模式。

存在的问题：

  • 插入异常：假如要插入一个已知学号、系别、学生住处，但还未选课的学生，也就是这个学生没有课程号，这样的元组不能插入到学生关系中。因为插入时必须给定码值，但是此时码值的一部分为空，因而学生的信息无法插入。

  • 删除异常：假如某个学生只选修了一门课，如学号为2104011的学生只选修了3号课程。现在他连3号课程也不想选了，那么课程号为3的这个数据项就要删除。但是课程号是主属性，删除了课程号3，整个元组都不能存在了，也必须跟着删除，从而删除了210411学生的其他信息，产生了删除异常，也就是把不该删除的信息也删除了。

  • 数据冗余度大：如果一个学生选修了10门课程，那么他的系部和学生住处值就要重复存储10次。

  • 修改复杂：如果一个学生转系了，本只用修改此学生的系部、学生住处。如果这个学生选修了K门课程，当数据更新时需无遗漏地修改K个元组中全部的系部、学生住处信息，这就造成了修改的复杂化。

不想看了

文3：第一范式、第二范式、第三范式、BCNF范式详解

https://blog.csdn.net/WHEgqing/article/details/108997240

文章目录

  • 0. 范式(NF)
  • 1. 第一范式（1NF）
  • 2. 第二范式（2NF）
    • 2.1 函数依赖
      • 2.1.1完全函数依赖
      • 2.1.2 部分函数依赖
      • 2.1.3 传递函数依赖
    • 2.2 码
    • 2.3 非主属性
  • 3. 第三范式（3NF）
  • 4. BCNF范式
  • 5. 小结
  • 6. 参考文献

0. 范式(NF)

按照教材中的定义，范式是“符合某一种级别的关系模式的集合，表示一个关系内部各属性之间的联系的合理化程度”。很晦涩吧？实际上你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别。就像家里装修买建材，最环保的是E0级，其次是E1级，还有E2级等等。数据库范式也分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。

接下来就对每一级范式进行一下解释。

1. 第一范式（1NF）

符合1NF的关系（你可以理解为数据表。“关系模式”和“关系”的区别，类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例，你可以把”关系”理解为一张带数据的表，而“关系模式”是这张数据表的表结构。1NF的定义为：符合1NF的关系中的每个属性都不可再分。表1所示的情况，就不符合1NF的要求。

img

实际上，1NF是所有关系型数据库的最基本要求，你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么操作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。如果我们要在RDBMS中表现表中的数据，就得设计为表2的形式：

img

但是仅仅符合1NF的设计，仍然会存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于表3中的设计：

  • 学号 姓名
  • 系名 系主任
  • 课名 分数

img

  1. 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大

  2. 假如学校新建了一个系，但是暂时还没有招收任何学生（比如3月份就新建了，但要等到8月份才招生），那么是无法将系名与系主任的数据单独地添加到数据表中去的 （注１）——插入异常

    • 注１：根据三种关系完整性约束中实体完整性的要求，关系中的码（注２）所包含的任意一个属性都不能为空，所有属性的组合也不能重复。为了满足此要求，图中的表，只能将学号与课名的组合作为码，否则就无法唯一地区分每一条记录。
      • 注２：码：关系中的某个属性或者某几个属性的组合，用于区分每个元组（可以把“元组”理解为一张表中的每条记录，也就是每一行）。

  3. 假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常

  4. 假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。

正因为仅符合1NF的数据库设计存在着这样那样的问题，我们需要提高设计标准，去掉导致上述四种问题的因素，使其符合更高一级的范式（2NF），这就是所谓的“规范化”。

2. 第二范式（2NF）

在关系理论中的严格定义我这里就不多介绍了（因为涉及到的铺垫比较多），只需要了解2NF对1NF进行了哪些改进即可。其改进是，2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。接下来对这句话中涉及到的四个概念——“函数依赖”、“码”、“非主属性”、与“部分函数依赖”进行一下解释。

2.1 函数依赖

我们可以这么理解（但并不是特别严格的定义）：若在一张表中，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。

  • X 推出了 Y，Y依赖与 X

也就是说，在数据表中，不存在任意两条记录，它们在X属性（或属性组）上的值相同，而在Y属性上的值不同。这也就是“函数依赖”名字的由来，类似于函数关系 y = f(x)，在x的值确定的情况下，y的值一定是确定的。

例如，对于表3中的数据，找不到任何一条记录，它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。但是反过来，因为可能出现同名的学生，所以有可能不同的两条学生记录，它们在姓名上的值相同，但对应的学号不同，所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如：

系名 → 系主任学号 → 系主任

  • 一个系 对应一个系主任，系主任学号

（学号，课名） → 分数

  • 学号，的 课，考了 多少 分

但以下函数依赖关系则不成立：

学号 → 课名

  • 一个学号，可以有多个 课名

学号 → 分数

  • 学号，会有 多个课名的分数

课名 → 系主任

  • 没关系

（学号，课名） → 姓名

  • 学号，可以推出姓名。课名 没必要。

从“函数依赖”这个概念展开，还会有三个概念：

2.1.1完全函数依赖

在一张表中，若 X → Y，且对于 X 的任何一个真子集（假如属性组 X 包含超过一个属性的话），X ’ → Y 不成立，那么我们称 Y 对于 X 完全函数依赖，记作 X F→ Y。（那个F应该写在箭头的正上方，没办法打出来……，正确的写法如图1）

img

例如： 学号 F→ 姓名 （学号，课名） F→ 分数 （注：因为同一个的学号对应的分数不确定，同一个课名对应的分数也不确定）

  • 学号 推出 姓名
  • 学号 和 课名，推出分数。分数 完全依赖 与学号和课名

2.1.2 部分函数依赖

假如 Y 函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X，记作 X P→ Y，如图2。
在这里插入图片描述

图2

例如：（学号，课名） P→ 姓名

  • 只 通过学号，就能推出 姓名

2.1.3 传递函数依赖

假如 Z 函数依赖于 Y，且 Y 函数依赖于 X ，那么我们就称 Z 传递函数依赖于 X ，记作 X T→ Z，如图3。
在这里插入图片描述

图3

  • 姓名—系主任—系主任编号

2.2 码

设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K（这个“完全”不要漏了），那么我们称 K 为候选码，简称为码。

  • 在实际中我们通常可以理解为：假如当 K 确定的情况下，该表除 K 之外的所有属性的值也就随之确定，那么 K 就是码。
  • 一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）
    • 例如：对于表3，（学号、课名）这个属性组就是码。该表中有且仅有这一个码。（假设所有课没有重名的情况）

2.3 非主属性

包含在任何一个码中的属性成为主属性。

例如：
对于表3，主属性就有两个，学号 与 课名。

终于可以回过来看2NF了。首先，我们需要判断，表3是否符合2NF的要求？根据2NF的定义，判断的依据实际上就是看数据表中

  • 是否存在非主属性对于码的部分函数依赖。若存在，则数据表最高只符合1NF的要求，若不存在，则符合2NF的要求。判断的方法是：

第一步：找出数据表中所有的码。
第二步：根据第一步所得到的码，找出所有的主属性。
第三步：数据表中，除去所有的主属性，剩下的就都是非主属性了。
第四步：查看是否存在非主属性对码的部分函数依赖。

对于表3，根据前面所说的四步，我们可以这么做：

第一步：

  1. 查看所有每一单个属性，当它的值确定了，是否剩下的所有属性值都能确定。
  2. 查看所有包含有两个属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。
  3. ……
  4. 查看所有包含了六个属性，也就是所有属性的属性组，当它的值确定了，是否剩下的所有属性值都能确定。

看起来很麻烦是吧，但是这里有一个诀窍，就是假如 A是码，那么所有包含了A的属性组，如（A，B）、（A，C）、（A，B，C）等等，都不是码了（因为作为码的要求里有一个“完全函数依赖”）。
图4表示了表中所有的函数依赖关系：

img

  • 学号 推出 姓名

  • 学号 推出 系名，系主任

  • 学号 课名 推出 分数。

这一步完成以后，可以得到，表3的码只有一个，就是 （学号、课名） 。

第二步：主属性有两个：学号 与 课名

第三步：非主属性有四个：姓名、系名、系主任、分数

第四步：
对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。

  • 学号 可以推出 系主任

所以表3存在非主属性对于码的部分函数依赖，最高只符合1NF的要求，不符合2NF的要求。

为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表，在拆分的过程中，要达到更高一级范式的要求，**这个过程叫做”模式分解“。**模式分解的方法不是唯一的，以下是其中一种方法：
选课（学号，课名，分数）
学生（学号，姓名，系名，系主任）

我们先来判断以下，选课表与学生表，是否符合了2NF的要求？

对于选课表，其码是（学号，课名），主属性是学号和课名，非主属性是分数，

  • 学号确定，并不能唯一确定分数，课名确定，也不能唯一确定分数，
  • 所以不存在非主属性分数对于码 （学号，课名）的部分函数依赖，所以此表符合2NF的要求。

对于学生表，其码是学号，主属性是学号，非主属性是姓名、系名和系主任，因为码只有一个属性，所以不可能存在非主属性对于码 的部分函数依赖，所以此表符合2NF的要求。
图5表示了模式分解以后的新的函数依赖关系

img

  • 学号 课名 推出分数
  • 学号，推出 姓名，系名，系主任

表4表示了模式分解以后新的数据

img

（这里还涉及到一个如何进行模式分解才是正确的知识点，先不介绍了）
现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？

  1. 李小明转系到法律系
    只需要修改一次李小明对应的系的值即可。——有改进
  2. 数据冗余是否减少了？
    学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进
  3. 删除某个系中所有的学生记录
    该系的信息仍然全部丢失。——无改进
  4. 插入一个尚无学生的新系的信息。
    因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进

所以说，仅仅符合2NF的要求，很多情况下还是不够的，而出现问题的原因，在于**仍然存在非主属性系主任对于码学号的传递函数依赖。**为了能进一步解决这些问题，我们还需要将符合2NF要求的数据表改进为符合3NF的要求。

  • 学号 推出 系名，系名 推出 系主任
    • 系主任 对于学号是 传递函数依赖

3. 第三范式（3NF）

3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。也就是说， 如果存在非主属性对于码的传递函数依赖，则不符合3NF的要求。
接下来我们看看表4中的设计，是否符合3NF的要求。
对于选课表，主码为（学号，课名），主属性为学号和课名，非主属性只有一个，为分数，不可能存在传递函数依赖，所以选课表的设计，符合3NF的要求。
对于学生表，主码为学号，主属性为学号，

  • 非主属性为姓名、系名和系主任。
  • 因为 学号 → 系名，同时 系名 → 系主任，所以存在非主属性系主任对于码学号的传递函数依赖，所以学生表的设计，不符合3NF的要求。

为了让数据表设计达到3NF，我们必须进一步进行模式分解为以下形式：
选课（学号，课名，分数）
学生（学号，姓名，系名）
系（系名，系主任）
对于选课表，符合3NF的要求，之前已经分析过了。
对于学生表，码为学号，主属性为学号，非主属性为系名，不可能存在非主属性对于码的传递函数依赖，所以符合3NF的要求。
对于系表，码为系名，主属性为系名，非主属性为系主任，不可能存在非主属性对于码的传递函数依赖（至少要有三个属性才可能存在传递函数依赖关系），所以符合3NF的要求。。
新的函数依赖关系如图6

img

新的数据表如表5

img

表5

现在我们来看一下，进行同样的操作，是否还存在着之前的那些问题？

  1. 删除某个系中所有的学生记录
    该系的信息不会丢失。——有改进
  2. 插入一个尚无学生的新系的信息。
    因为系表与学生表目前是独立的两张表，所以不影响。——有改进
  3. 数据冗余更加少了。——有改进

结论
由此可见，符合3NF要求的数据库设计，基本上解决了数据冗余过大，插入异常，修改异常，删除异常的问题。当然，在实际中，

  • **往往为了性能上或者应对扩展的需要，经常 做到2NF或者1NF，**但是作为数据库设计人员，至少应该知道，3NF的要求是怎样的。

4. BCNF范式

要了解 BCNF 范式，那么先看这样一个问题：
若：

  • 某公司有若干个仓库；每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；

  • 一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？

答：已知函数依赖集：

  • 仓库名 → 管理员，管理员 → 仓库名，
  • （仓库名，物品名）→ 数量

码：

  • （管理员，物品名），
  • （仓库名，物品名）

主属性：仓库名、管理员、物品名

  • 主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

非主属性：数量

∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。
∴ 此关系模式属于3NF。

基于此关系模式的关系（具体的数据）可能如图所示：

img

好，既然此关系模式已经属于了 3NF，那么这个关系模式是否存在问题呢？我们来看以下几种操作：

  • 先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。

  • 某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。

  • 如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。

从这里我们可以得出结论，在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题，仍然不是 ”好“ 的设计。

造成此问题的原因：存在着 主属性 对于 码的部分函数依赖 与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

  • 仓库（仓库名，管理员）
  • 库存（仓库名，物品名，数量）

这样，之前的插入异常，修改异常与删除异常的问题就被解决了。
以上就是关于 BCNF 的解释。

范式总结为：

1NF： 字段是最小的的单元不可再分
2NF：满足1NF,表中的字段必须完全依赖于全部主键而非部分主键 (一般我们都会做到)
3NF：满足2NF,非主键外的所有字段必须互不依赖

BCNF：主键通常为一个。如果主键为多个，不能 存在部分或传递依赖。

4NF：满足3NF,消除表中的多值依赖

1NF：关系中的每个属性都不可再分
↓

2NF：消除非主属性对码的部分函数依赖（消除后，变为2NF）
↓

3NF：消除非主属性对码的传递函数依赖
↓

BCNF：消除主属性对码的部分和传递函数依赖

再次重复一遍：

  • 1NF，属性不可再分
  • 2NF，消除 非主属性 部分函数依赖
  • 3NF，消除 非主属性 传递函数依赖
  • BCNF，消除 主属性 对码的 部分和传递 依赖。

问：关于码的定义，如果除K之外的所有属性都完全函数依赖于K时才能称K为码，那么在判断2NF时又怎么会存在非主属性对码的部分函数依赖这种情况？

答 ：在“码”的定义中，除 K 之外的所有属性应该看成是一个集合 U（也就是一个整体），

  • 这个集合 U 里面的，也可能存在 函数依赖呢 （比如上面例子：系名 系主任）

也就是说，只有 K 能够完全函数决定 U 中的每一个属性，那么 K 才是码。如果 K 只是能够完全函数决定 U 中的一部分属性，而不能完全函数决定另外一部分属性，那么 K 不是码。

比如有关系模式 R (Sno, Sname, Cno, Cname, Sdept, Sloc, Grade)，

  • 学号 Sno
  • 姓名 Sname
  • 系编号 Cno
  • 系主任 Cname
  • 系名 Sdept
  • 课名？系地址？ Sloc
  • 分数 Grade

其中函数依赖集为 F= {

  • Sno → Sname, 学号 推出 姓名
  • Sno → Sdept, 学号 推出 系名
  • Sdept → Sloc， 系名 推出 系地址
  • Sno → Sloc, 系编号 推出 系地址
  • Cno → Cname, 系编号 推出系主任
  • (Sno, Cno) → Grade，学号+系编号，推出 分数？？
  • }

那么 R 中的码只能是 (Sno, Cno)，Sno 或 Cno 并不能完全函数决定除 Sno / Cno 之外的所有其他属性（其实就是不能决定 Grade )，所以单独的 Sno 与 Cno 并不能作为码。
所以可得到主属性：Sno, Cno
非主属性：Sname, Cname, Sdept, Sloc, Grade
R 中存在非主属性 Cname 对于码 (Sno, Cno) 的部分函数依赖 (Cno → Cname) 。（还有很多别的例子就不一一列举了）。所以 R 不符合 2NF 的要求。

  • 系编号——>系名

6. 参考文献

数据库范式那些事

详解第一范式、第二范式、第三范式、BCNF范式

今天的文章第一范式第二范式第三范式的定义_第一范式第二范式第三范式的定义分享到此就结束了，感谢您的阅读。

版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
如需转载请保留出处：https://bianchenghao.cn/83629.html

赞 (0)
编程小号编程小号
0

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注