精华内容
下载资源
问答
  • MySQL三范式

    2020-12-14 16:17:06
    目录第一范式(1NF)第二范式(2NF)第三范式(3NF) 第一范式(1NF) 表的每一列都是不可分割的基本数据项 即表的列的具有原子性,不可再分解,即列的信息,不能分解, 只要数据库是关系型数据库(mysql/oracle/db2/...
  • 详解第一范式、第二范式、第三范式、BCNF范式

    万次阅读 多人点赞 2019-03-02 16:08:45
    文章目录第一范式定义以及分析:问题研究:第二范式必备知识点函数依赖:码:非主属性 :定义分析:解决办法:问题研究:第三范式:定义:分析:问题研究:BCNF范式分析问题研究小结: 第一范式 定义以及分析: 首先是...

    什么是”范式(NF)”

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

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

    1. 第一范式(1NF)

    符合1NF的关系(你可以理解为数据表。“关系模式”和“关系”的区别,类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你可以把”关系”理解为一张带数据的表,而“关系模式”是这张数据表的表结构。1NF的定义为:符合1NF的关系中的每个属性都不可再分表1所示的情况,就不符合1NF的要求。
    在这里插入图片描述
    表1
    实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中创建数据表的时候,如果数据表的设计不符合这个最基本的要求,那么操作一定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,一定是符合1NF的。如果我们要在RDBMS中表现表中的数据,就得设计为表2的形式:
    在这里插入图片描述
    表2

    但是仅仅符合1NF的设计,仍然会存在数据冗余过大,插入异常,删除异常,修改异常的问题,例如对于表3中的设计:
    在这里插入图片描述
    表3

    1. 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
    2. 假如学校新建了一个系,但是暂时还没有招收任何学生(比如3月份就新建了,但要等到8月份才招生),那么是无法将系名与系主任的数据单独地添加到数据表中去的 (注1)——插入异常
    • 注1:根据三种关系完整性约束中实体完整性的要求,关系中的码(注2)所包含的任意一个属性都不能为空,所有属性的组合也不能重复。为了满足此要求,图中的表,只能将学号与课名的组合作为码,否则就无法唯一地区分每一条记录。
    • 注2:码:关系中的某个属性或者某几个属性的组合,用于区分每个元组(可以把“元组”理解为一张表中的每条记录,也就是每一行)。
    1. 假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)。——删除异常

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

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

    2. 第二范式(2NF)

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

    2.1 函数依赖

    我们可以这么理解(但并不是特别严格的定义):若在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y。也就是说,在数据表中,不存在任意两条记录,它们在X属性(或属性组)上的值相同,而在Y属性上的值不同。这也就是“函数依赖”名字的由来,类似于函数关系 y = f(x),在x的值确定的情况下,y的值一定是确定的。
    例如,对于表3中的数据,找不到任何一条记录,它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号,写作 学号 → 姓名。但是反过来,因为可能出现同名的学生,所以有可能不同的两条学生记录,它们在姓名上的值相同,但对应的学号不同,所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如:

    系名 → 系主任学号 → 系主任
    (学号,课名) → 分数

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

    学号 → 课名
    学号 → 分数
    课名 → 系主任
    (学号,课名) → 姓名

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

    2.1.1完全函数依赖

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

    图1
    例如: 学号 F→ 姓名 (学号,课名) F→ 分数 (注:因为同一个的学号对应的分数不确定,同一个课名对应的分数也不确定)

    2.1.2 部分函数依赖

    假如 Y 函数依赖于 X,但同时 Y 并不完全函数依赖于 X,那么我们就称 Y 部分函数依赖于 X,记作 X P→ Y,如图2。

    图2
    例如:(学号,课名) P→ 姓名 传递函数依赖假如 Z 函数依赖于 Y,且 Y 函数依赖于 X (感谢 @百达 指出的错误,这里改为:『Y 不包含于 X,且 X 不函数依赖于 Y』这个前提),那么我们就称 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表示了表中所有的函数依赖关系:
    在这里插入图片描述
    图4
    这一步完成以后,可以得到,表3的码只有一个,就是 (学号、课名)

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

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

    第四步:
    对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 对码(学号,课名)的部分函数依赖。

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

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

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

    对于选课表,其码是(学号,课名),主属性是学号和课名,非主属性是分数,学号确定,并不能唯一确定分数,课名确定,也不能唯一确定分数,所以不存在非主属性分数对于码 (学号,课名)的部分函数依赖,所以此表符合2NF的要求。

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

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

    表4

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

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

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

    3. 第三范式(3NF)

    3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 如果存在非主属性对于码的传递函数依赖,则不符合3NF的要求。
    接下来我们看看表4中的设计,是否符合3NF的要求。
    对于选课表,主码为(学号,课名),主属性为学号和课名,非主属性只有一个,为分数,不可能存在传递函数依赖,所以选课表的设计,符合3NF的要求。
    对于学生表,主码为学号,主属性为学号,非主属性为姓名、系名和系主任。因为 学号 → 系名,同时 系名 → 系主任,所以存在非主属性系主任对于码学号的传递函数依赖,所以学生表的设计,不符合3NF的要求。
    为了让数据表设计达到3NF,我们必须进一步进行模式分解为以下形式:
    选课(学号,课名,分数)
    学生(学号,姓名,系名)
    系(系名,系主任)
    对于选课表,符合3NF的要求,之前已经分析过了。
    对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,所以符合3NF的要求。
    对于系表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),所以符合3NF的要求。。
    新的函数依赖关系如图6

    图6
    新的数据表如表5

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

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

    结论
    由此可见,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。当然,在实际中,往往为了性能上或者应对扩展的需要,经常 做到2NF或者1NF,但是作为数据库设计人员,至少应该知道,3NF的要求是怎样的。

    ==============时隔半年,终于决定把这个坑填上,来晚了 ===========
    BCNF范式
    要了解 BCNF 范式,那么先看这样一个问题:
    若:
    某公司有若干个仓库;每个仓库只能有一名管理员,一名管理员只能在一个仓库中工作;
    一个仓库中可以存放多种物品,一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
    那么关系模式 仓库(仓库名,管理员,物品名,数量) 属于哪一级范式?
    答:已知函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量
    码:(管理员,物品名),(仓库名,物品名)
    主属性:仓库名、管理员、物品名非主属性:数量
    ∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。
    ∴ 此关系模式属于3NF。
    基于此关系模式的关系(具体的数据)可能如图所示:

    好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?我们来看以下几种操作:
    先新增加一个仓库,但尚未存放任何物品,是否可以为该仓库指派管理员?——不可以,因为物品名也是主属性,根据实体完整性的要求,主属性不能为空。
    某仓库被清空后,需要删除所有与这个仓库相关的物品存放记录,会带来什么问题?——仓库本身与管理员的信息也被随之删除了。
    如果某仓库更换了管理员,会带来什么问题?——这个仓库有几条物品存放记录,就要修改多少次管理员信息。
    从这里我们可以得出结论,在某些特殊情况下,即使关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题,仍然不是 ”好“ 的设计。
    造成此问题的原因:存在着主属性对于码的部分函数依赖与传递函数依赖。(在此例中就是存在主属性【仓库名】对于码【(管理员,物品名)】的部分函数依赖。
    解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
    仓库(仓库名,管理员)
    库存(仓库名,物品名,数量)
    这样,之前的插入异常,修改异常与删除异常的问题就被解决了。
    以上就是关于 BCNF 的解释。

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

    答 :在“码”的定义中,除 K 之外的所有属性应该看成是一个集合 U(也就是一个整体),也就是说,只有 K 能够完全函数决定 U 中的每一个属性,那么 K 才是码。如果 K 只是能够完全函数决定 U 中的一部分属性,而不能完全函数决定另外一部分属性,那么 K 不是码。
    比如有关系模式 R (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 的要求。

    4. 小结

    搬运工觉得这个讲解对于初步学习的人比较好。
    数据库范式那些事
    总结:
    1NF: 字段是最小的的单元不可再分
    2NF:满足1NF,表中的字段必须完全依赖于全部主键而非部分主键 (一般我们都会做到)
    3NF:满足2NF,非主键外的所有字段必须互不依赖4NF:满足3NF,消除表中的多值依赖

    搬运自知乎如何解释关系数据库的第一第二第三范式?
    摘选刘慰胡永浩的回答

    展开全文
  • 数据库的三范式是什么? 第一范式:最基本要求,表中的每一列必须保证原子性,列不可在分割。 如有一个列,年级班级。然后存储数据为,一年级一班,一年级二班。那么这是错误的,应该年级和班级分开为单独列。 ...
  • 数据库 三范式最简单最易记的解释,整理一下方便大家记忆。
  • 第一范式、第二范式和第三范式

    千次阅读 2019-12-20 18:42:43
    数据库的范式 概念:设计数据库是,需要遵循的一些规范,要遵循后边的范式要求...目前关系型数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、BC范式、第四范式(4NF)、第五范式(5NF)。 ...

    数据库的范式

    概念:设计数据库是,需要遵循的一些规范,要遵循后边的范式要求,必须遵循前边的所有范式要求

    设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈梯次规范,越高的范式数据库冗余越小

    目前关系型数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、BC范式、第四范式(4NF)、第五范式(5NF)。

     

    分类:

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

    第二范式:在第一范式基础上,非码属性必须完全依赖于候选码(在第一范式基础上消除非主属性对主码的部分依赖)

    几个概念:

    1. 函数依赖:A-->B,如果通过A属性(属性组)的值,可以确定唯一B属性的值。则B依赖于A

    例如:学号-->姓名      (学号,课程名称) --> 分数

    1. 完全函数依赖:A->B  如果A是一个属性组,则B属性值得确定需要依赖于A属性组中的所有的属性值。

    例如:(学号,课程名称) --> 分数

    1. 部分函数依赖:A --> B,如果A是一个属性组,则B属性值得确定只需要依赖于A属性组中某一些值即可。

    例如:(学号,课程名称) --> 姓名

    1. 传递函数依赖:A --> B,B --> C ,如果A属性(属性组)的值,可以唯一确定B属性的值,在通过B属性(属性组)的值可以唯一确定C属性的值,则称C传递函数依赖于A

    例如:学号 --> 系别,系别-->系主任

    1. 码:如果在一张表中,一个属性或属性组,被其他所有属性完全依赖,则称这个属性(属性组)为该表的码。

    例如:该表中码为:(学号,课程名称)

    主属性:码属性组中的所有属性

    非主属性:除码属性组的属性

    第三范式:在第二范式基础上,任何非主属性不依赖于其它非主属性(在2NF基础上消除传递依赖)

     

     

     

    学号

    姓名

    课程名称

    分数

    系名

    系主任

    10010

    张无忌

    经济系

    张三丰

    高等数学

    95

    10010

    张无忌

    经济系

    张三丰

    英语

    93

    10010

    张无忌

    经济系

    张三丰

    计算机基础

    97

    10011

    令狐冲

    法律系

    任我行

    线性代数

    88

    10011

    令狐冲

    法律系

    任我行

    刑法

    87

    10012

    杨过

    艺术系

    小龙女

    家庭法

    88

    10012

    杨过

    艺术系

    小龙女

    唱歌

    99

    表一

    不满足第一范式

     

    学号

    姓名

    系名

    系主任

    课程名称

    分数

    10010

    张无忌

    经济系

    张三丰

    高等数学

    95

    10010

    张无忌

    经济系

    张三丰

    英语

    93

    10010

    张无忌

    经济系

    张三丰

    计算机基础

    97

    10011

    令狐冲

    法律系

    任我行

    线性代数

    88

    10011

    令狐冲

    法律系

    任我行

    刑法

    87

    10012

    杨过

    艺术系

    小龙女

    家庭法

    88

    10012

    杨过

    艺术系

    小龙女

    唱歌

    99

    表二

    第一范式

    存在的问题:

    1. 数据有大量冗余(重复)
    2. 数据添加存在问题,添加新开设的系和系主任时,数据不合法
    3. 数据存在问题:张无忌同学毕业了,删除数据,会将系的数据一起删除

     

     

     

    选课表

    学号

    课程名称

    分数

    10010

    高等数学

    95

    10010

    英语

    93

    10011

    计算机基础

    97

    10011

    线性代数

    88

    10012

    刑法

    87

     10012

    高等数学

    88

     

     

    学生表

    学号

    姓名

    系名

    系主任

    10010

    张无忌

    经济系

    张三丰

    10011

    令狐冲

    法律系

    任我行

    10012

    杨过

    艺术系

    小龙女

     

    第二范式

     

    存在问题:

    1、数据添加存在问题,添加新开设的系和系主任时,数据不合法

    2、数据存在问题:张无忌同学毕业了,删除数据,会将系的数据一起删除

     

     

     

     

     

     

    选课表

    学号

    课程名称

    分数

    10010

    高等数学

    95

    10010

    英语

    93

    10011

    计算机基础

    97

    10011

    线性代数

    88

    10012

    刑法

    87

     10012

    高等数学

    88

     

     

     

     

     

     

    学生表

    学号

    姓名

    10010

    张无忌

    10011

    令狐冲

    10012

    杨过

     

     

    系名

    系主任

    经济系

    张三丰

    法律系

    任我行

    艺术系

    小龙女

     

     

    第三范式

    存在的所有问题都被解决了

    展开全文
  • 数据库三范式 & 事务

    2020-12-14 16:09:10
    数据库三范式具体如下: 1、 第一范式(1st NF -列都是不可再分) 第一范式的目标是确保每列的原子性: 如果每列都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式(1NF) 2、第二范式(2nd NF -...
  • 三范式确保主键列之间没有传递函数依赖关系,也就是消除传递依赖。 本文将基于三大范式原则,结合具体的实例做简要分析,难度系数:基础。 2 第一范式 2.1 例子引入 根据如下场景设计出两种数据表,请分析两种数据...
  • 第一范式、第二范式、第三范式、BCNF范式详解

    千次阅读 多人点赞 2020-10-10 15:26:19
    范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。


    0. 范式(NF)

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

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

    1. 第一范式(1NF)

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

    表1

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

    表2

    但是仅仅符合1NF的设计,仍然会存在数据冗余过大,插入异常,删除异常,修改异常的问题,例如对于表3中的设计:
    在这里插入图片描述

    表3

    1. 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
    2. 假如学校新建了一个系,但是暂时还没有招收任何学生(比如3月份就新建了,但要等到8月份才招生),那么是无法将系名与系主任的数据单独地添加到数据表中去的 (注1)——插入异常
    • 注1:根据三种关系完整性约束中实体完整性的要求,关系中的码(注2)所包含的任意一个属性都不能为空,所有属性的组合也不能重复。为了满足此要求,图中的表,只能将学号与课名的组合作为码,否则就无法唯一地区分每一条记录。
    • 注2:码:关系中的某个属性或者某几个属性的组合,用于区分每个元组(可以把“元组”理解为一张表中的每条记录,也就是每一行)。
    1. 假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)。——删除异常

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

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

    2. 第二范式(2NF)

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

    2.1 函数依赖

    我们可以这么理解(但并不是特别严格的定义):若在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y。也就是说,在数据表中,不存在任意两条记录,它们在X属性(或属性组)上的值相同,而在Y属性上的值不同。这也就是“函数依赖”名字的由来,类似于函数关系 y = f(x),在x的值确定的情况下,y的值一定是确定的。
    例如,对于表3中的数据,找不到任何一条记录,它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号,写作 学号 → 姓名。但是反过来,因为可能出现同名的学生,所以有可能不同的两条学生记录,它们在姓名上的值相同,但对应的学号不同,所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如:

    系名 → 系主任学号 → 系主任
    (学号,课名) → 分数

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

    学号 → 课名
    学号 → 分数
    课名 → 系主任
    (学号,课名) → 姓名

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

    2.1.1完全函数依赖

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

    在这里插入图片描述

    图1

    例如: 学号 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表示了表中所有的函数依赖关系:
    在这里插入图片描述

    图4

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

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

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

    第四步:
    对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 对码(学号,课名)的部分函数依赖。

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

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

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

    对于选课表,其码是(学号,课名),主属性是学号和课名,非主属性是分数,学号确定,并不能唯一确定分数,课名确定,也不能唯一确定分数,所以不存在非主属性分数对于码 (学号,课名)的部分函数依赖,所以此表符合2NF的要求。

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

    图5

    表4表示了模式分解以后新的数据
    在这里插入图片描述

    表4

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

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

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

    3. 第三范式(3NF)

    3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 如果存在非主属性对于码的传递函数依赖,则不符合3NF的要求。
    接下来我们看看表4中的设计,是否符合3NF的要求。
    对于选课表,主码为(学号,课名),主属性为学号和课名,非主属性只有一个,为分数,不可能存在传递函数依赖,所以选课表的设计,符合3NF的要求。
    对于学生表,主码为学号,主属性为学号,非主属性为姓名、系名和系主任。因为 学号 → 系名,同时 系名 → 系主任,所以存在非主属性系主任对于码学号的传递函数依赖,所以学生表的设计,不符合3NF的要求。
    为了让数据表设计达到3NF,我们必须进一步进行模式分解为以下形式:
    选课(学号,课名,分数)
    学生(学号,姓名,系名)
    系(系名,系主任)
    对于选课表,符合3NF的要求,之前已经分析过了。
    对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,所以符合3NF的要求。
    对于系表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),所以符合3NF的要求。。
    新的函数依赖关系如图6
    在这里插入图片描述

    图6

    新的数据表如表5
    在这里插入图片描述

    表5

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

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

    结论
    由此可见,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。当然,在实际中,往往为了性能上或者应对扩展的需要,经常 做到2NF或者1NF,但是作为数据库设计人员,至少应该知道,3NF的要求是怎样的。

    4. BCNF范式

    要了解 BCNF 范式,那么先看这样一个问题:
    若:
    某公司有若干个仓库;每个仓库只能有一名管理员,一名管理员只能在一个仓库中工作;
    一个仓库中可以存放多种物品,一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
    那么关系模式 仓库(仓库名,管理员,物品名,数量) 属于哪一级范式?
    答:已知函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量
    码:(管理员,物品名),(仓库名,物品名)
    主属性:仓库名、管理员、物品名非主属性:数量
    ∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。
    ∴ 此关系模式属于3NF。
    基于此关系模式的关系(具体的数据)可能如图所示:
    在这里插入图片描述

    好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?我们来看以下几种操作:
    先新增加一个仓库,但尚未存放任何物品,是否可以为该仓库指派管理员?——不可以,因为物品名也是主属性,根据实体完整性的要求,主属性不能为空。
    某仓库被清空后,需要删除所有与这个仓库相关的物品存放记录,会带来什么问题?——仓库本身与管理员的信息也被随之删除了。
    如果某仓库更换了管理员,会带来什么问题?——这个仓库有几条物品存放记录,就要修改多少次管理员信息。
    从这里我们可以得出结论,在某些特殊情况下,即使关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题,仍然不是 ”好“ 的设计。
    造成此问题的原因:存在着主属性对于码的部分函数依赖与传递函数依赖。(在此例中就是存在主属性【仓库名】对于码【(管理员,物品名)】的部分函数依赖。
    解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
    仓库(仓库名,管理员)
    库存(仓库名,物品名,数量)
    这样,之前的插入异常,修改异常与删除异常的问题就被解决了。
    以上就是关于 BCNF 的解释。

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

    答 :在“码”的定义中,除 K 之外的所有属性应该看成是一个集合 U(也就是一个整体),也就是说,只有 K 能够完全函数决定 U 中的每一个属性,那么 K 才是码。如果 K 只是能够完全函数决定 U 中的一部分属性,而不能完全函数决定另外一部分属性,那么 K 不是码。
    比如有关系模式 R (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 的要求。

    5. 小结

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

    6. 参考文献

    数据库范式那些事

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

    展开全文
  • 文章目录 什么是”范式(NF)”1. 第一范式(1NF)2. 第二范式(2NF)2.1 函数依赖2.1.1完全函数依赖2.1.2 部分函数依赖 ... 第三范式(3NF)4. 小结 什么是”范式(NF)” 按照教材中的定义,范式是“...
     
    

    什么是”范式(NF)”

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

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

    1. 第一范式(1NF)

    符合1NF的关系(你可以理解为数据表。“关系模式”和“关系”的区别,类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你可以把”关系”理解为一张带数据的表,而“关系模式”是这张数据表的表结构。1NF的定义为:符合1NF的关系中的每个属性都不可再分表1所示的情况,就不符合1NF的要求。
    在这里插入图片描述
    表1
    实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如SQL Server,Oracle,MySQL中创建数据表的时候,如果数据表的设计不符合这个最基本的要求,那么操作一定是不能成功的。也就是说,只要在RDBMS中已经存在的数据表,一定是符合1NF的。如果我们要在RDBMS中表现表中的数据,就得设计为表2的形式:
    在这里插入图片描述
    表2

    但是仅仅符合1NF的设计,仍然会存在数据冗余过大,插入异常,删除异常,修改异常的问题,例如对于表3中的设计:
    在这里插入图片描述
    表3

    1. 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
    2. 假如学校新建了一个系,但是暂时还没有招收任何学生(比如3月份就新建了,但要等到8月份才招生),那么是无法将系名与系主任的数据单独地添加到数据表中去的 (注1)——插入异常
    • 注1:根据三种关系完整性约束中实体完整性的要求,关系中的码(注2)所包含的任意一个属性都不能为空,所有属性的组合也不能重复。为了满足此要求,图中的表,只能将学号与课名的组合作为码,否则就无法唯一地区分每一条记录。
    • 注2:码:关系中的某个属性或者某几个属性的组合,用于区分每个元组(可以把“元组”理解为一张表中的每条记录,也就是每一行)。
    1. 假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)。——删除异常

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

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

    2. 第二范式(2NF)

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

    2.1 函数依赖

    我们可以这么理解(但并不是特别严格的定义):若在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y。也就是说,在数据表中,不存在任意两条记录,它们在X属性(或属性组)上的值相同,而在Y属性上的值不同。这也就是“函数依赖”名字的由来,类似于函数关系 y = f(x),在x的值确定的情况下,y的值一定是确定的。
    例如,对于表3中的数据,找不到任何一条记录,它们的学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号,写作 学号 → 姓名。但是反过来,因为可能出现同名的学生,所以有可能不同的两条学生记录,它们在姓名上的值相同,但对应的学号不同,所以我们不能说学号函数依赖于姓名。表中其他的函数依赖关系还有如:

    系名 → 系主任学号 → 系主任
    (学号,课名) → 分数

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

    学号 → 课名
    学号 → 分数
    课名 → 系主任
    (学号,课名) → 姓名

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

    2.1.1完全函数依赖

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

    图1
    例如: 学号 F→ 姓名 (学号,课名) F→ 分数 (注:因为同一个的学号对应的分数不确定,同一个课名对应的分数也不确定)

    2.1.2 部分函数依赖

    假如 Y 函数依赖于 X,但同时 Y 并不完全函数依赖于 X,那么我们就称 Y 部分函数依赖于 X,记作 X P→ Y,如图2。

    图2
    例如:(学号,课名) P→ 姓名 传递函数依赖假如 Z 函数依赖于 Y,且 Y 函数依赖于 X (感谢 @百达 指出的错误,这里改为:『Y 不包含于 X,且 X 不函数依赖于 Y』这个前提),那么我们就称 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表示了表中所有的函数依赖关系:
    在这里插入图片描述
    图4
    这一步完成以后,可以得到,表3的码只有一个,就是 (学号、课名)

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

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

    第四步:
    对于(学号,课名) → 姓名,有 学号 → 姓名,存在非主属性 姓名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系名,有 学号 → 系名,存在非主属性 系名 对码(学号,课名)的部分函数依赖。
    对于(学号,课名) → 系主任,有 学号 → 系主任,存在非主属性 对码(学号,课名)的部分函数依赖。

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

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

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

    对于选课表,其码是(学号,课名),主属性是学号和课名,非主属性是分数,学号确定,并不能唯一确定分数,课名确定,也不能唯一确定分数,所以不存在非主属性分数对于码 (学号,课名)的部分函数依赖,所以此表符合2NF的要求。

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

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

    表4

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

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

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

    3. 第三范式(3NF)

    3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 如果存在非主属性对于码的传递函数依赖,则不符合3NF的要求。
    接下来我们看看表4中的设计,是否符合3NF的要求。
    对于选课表,主码为(学号,课名),主属性为学号和课名,非主属性只有一个,为分数,不可能存在传递函数依赖,所以选课表的设计,符合3NF的要求。
    对于学生表,主码为学号,主属性为学号,非主属性为姓名、系名和系主任。因为 学号 → 系名,同时 系名 → 系主任,所以存在非主属性系主任对于码学号的传递函数依赖,所以学生表的设计,不符合3NF的要求。
    为了让数据表设计达到3NF,我们必须进一步进行模式分解为以下形式:
    选课(学号,课名,分数)
    学生(学号,姓名,系名)
    系(系名,系主任)
    对于选课表,符合3NF的要求,之前已经分析过了。
    对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,所以符合3NF的要求。
    对于系表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),所以符合3NF的要求。。
    新的函数依赖关系如图6

    图6
    新的数据表如表5

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

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

    结论
    由此可见,符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题。当然,在实际中,往往为了性能上或者应对扩展的需要,经常 做到2NF或者1NF,但是作为数据库设计人员,至少应该知道,3NF的要求是怎样的。


    BCNF范式
    要了解 BCNF 范式,那么先看这样一个问题:
    若:
    某公司有若干个仓库;每个仓库只能有一名管理员,一名管理员只能在一个仓库中工作;
    一个仓库中可以存放多种物品,一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
    那么关系模式 仓库(仓库名,管理员,物品名,数量) 属于哪一级范式?
    答:已知函数依赖集:仓库名 → 管理员,管理员 → 仓库名,(仓库名,物品名)→ 数量
    码:(管理员,物品名),(仓库名,物品名)
    主属性:仓库名、管理员、物品名非主属性:数量
    ∵ 不存在非主属性对码的部分函数依赖和传递函数依赖。
    ∴ 此关系模式属于3NF。
    基于此关系模式的关系(具体的数据)可能如图所示:

    好,既然此关系模式已经属于了 3NF,那么这个关系模式是否存在问题呢?我们来看以下几种操作:
    先新增加一个仓库,但尚未存放任何物品,是否可以为该仓库指派管理员?——不可以,因为物品名也是主属性,根据实体完整性的要求,主属性不能为空。
    某仓库被清空后,需要删除所有与这个仓库相关的物品存放记录,会带来什么问题?——仓库本身与管理员的信息也被随之删除了。
    如果某仓库更换了管理员,会带来什么问题?——这个仓库有几条物品存放记录,就要修改多少次管理员信息。
    从这里我们可以得出结论,在某些特殊情况下,即使关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题,仍然不是 ”好“ 的设计。
    造成此问题的原因:存在着主属性对于码的部分函数依赖与传递函数依赖。(在此例中就是存在主属性【仓库名】对于码【(管理员,物品名)】的部分函数依赖。
    解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
    仓库(仓库名,管理员)
    库存(仓库名,物品名,数量)
    这样,之前的插入异常,修改异常与删除异常的问题就被解决了。
    以上就是关于 BCNF 的解释。

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

    答 :在“码”的定义中,除 K 之外的所有属性应该看成是一个集合 U(也就是一个整体),也就是说,只有 K 能够完全函数决定 U 中的每一个属性,那么 K 才是码。如果 K 只是能够完全函数决定 U 中的一部分属性,而不能完全函数决定另外一部分属性,那么 K 不是码。
    比如有关系模式 R (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 的要求。

    4. 小结

    下面这个讲解推荐给初步学习的人
    数据库范式那些事
    总结:
    1NF: 字段是最小的的单元不可再分
    2NF:满足1NF,表中的字段必须完全依赖于全部主键而非部分主键 (一般我们都会做到)
    3NF:满足2NF,非主键外的所有字段必须互不依赖4NF:满足3NF,消除表中的多值依赖

    搬运自知乎如何解释关系数据库的第一第二第三范式?

    关于规范性性能

    • 关联查询的表不要超过三张
    • 考虑到需求,用户体验,性能更加重要
    • 故意给一些表增加冗余字段,使查询从多表变为单表
    展开全文
  • 三范式

    2019-11-26 23:21:09
    三范式 范式的基本分类 范式严格上来说不属于某个数据库操作系统或者某个某种数据库,它是一个所有数据库进行建表中结构要去遵循的一个形式 更属于数据库这个技术门类中的概念性知识,不过,在...
  • 1.第一范式:数据库的字段是单一属性,不可再...第三范式:任何非关键字段不能传递依赖任一侯选关键字  非关键字字段必须直接依赖任一侯选关键字  非关键字段C不能依赖非侯选关键字B,因为样会形成传递依赖:侯选关
  • 三范式 在数据库设计中我们经常会遵循三范式的规则 1.第一范式(1NF) 在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。  所谓第一范式(1NF...
  • 通常认为 BCNFBCNFBCNF是修正的第三范式,有时也称为扩展的第三范式。 引入实例 仍然从一个例子来入手。关系模式 STJ(S,T,J)STJ(S,T,J)STJ(S,T,J)中, SSS表示学生, TTT表示教师, JJJ表示课程。 先来...
  • 文章系转载,通俗易懂,写了很久代码,数据库知识一直薄弱,学习中;...什么是”范式(NF)” 1. 第一范式(1NF) 2. 第二范式(2NF) 2.1 函数依赖 2.1.1完全函数依赖 2.1.2 部分函数依赖 2....
  • 第一范式,第二范式,第三范式,BCNF范式理解

    万次阅读 多人点赞 2018-03-25 23:37:32
    第一范式、第二范式、第三范式 参考了https://www.zhihu.com/question/24696366 https://www.cnblogs.com/lca1826/p/6601395.html 基础知识 实体:现实世界中客观存在并可以被区别的事物。比如“一个学生...
  • 数据建模三范式

    千次阅读 2019-08-20 07:19:30
    在关系模式R中的每一个具体关系r中,必须要有主键,并且每个属性值 都是不可再分的最小数据单位,则称R是第一范式的关系。 第二范式(2NF): 如果关系模式R中的所有非主属性都完全依赖于主关键字,则称关系R 是属于...
  • 三范式

    千次阅读 2020-07-15 09:43:44
    三范式. BC范式. 第四范式. 第五范式. 满足最低要求的叫第一范式,简称1NF. 在第一范式基础上进一步满足一些要求的为第二范式,简称2NF. 其余依此类推. 范式越高: 优点: 可以避免数据冗余. 缺点: 性能就会越差,...
  • 第一范式 字段不可分,保证字段的原子性,字段不能是集合、多个值。 下面第二行是违反第一范式的: 第二范式 有主键,非主键字段依赖主键。 第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式...
  • 数据库的设计范式是数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员...
  • 版权声明:本文转自小小呆原创文章 ... 第一范式 定义以及分析: 问题研究: ...第三范式: 定义: 分析: 问题分析: BCNF范式 分析 问题研究 小结: 参考文献 ...
  • 数据库三范式和BC范式

    千次阅读 2019-12-18 17:08:15
    范式 什么是范式 范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。...一般说来,数据库只需满足第三范式(3NF)就行了。 函数依赖 在学习范式前,我们还需要了解函数依赖。...
  • 数据库关系数据理论----范式范式原理笔记什么是(范式)---范式介绍范式发展1、第一范式2、第二范式3、第三范式4、BCNF(扩展第三范式) 什么是(范式)—范式介绍 官方介绍,数据库中的关系是要满足一定要求的,...
  • 范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系...通常所用到的只是前范式,即:第一范式(1NF),第二范式(2NF)...
  • 传递函数依赖第一范式第二范式第三范式 范式理论 何为范式,何为建模 范式理论和谁有关?和关系建模有关,通常我们说的三范式是啥东西,啥叫范式。 所谓的范式,就是我们在关系建模的时候所遵从的一些规范。 所谓的...
  • 数据库三范式简单理解

    万次阅读 2018-03-09 09:11:40
    数据库设计当中三范式是经常遇到的,如果实际项目数据库设计中能达到第三范式基本也就满足要求了,那么如何快速有效的理解三个范式,同时应用于实际项目中去呢?首先看看标准定义的三个范式:第一范式(1NF)所谓第一...
  • 1.1第一范式(1NF)无重复的列 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能...
  • ) 但是(仓库名)->(管理员) 不满足第二条 所以需要改成两种表: 第一张:仓库名,管理员 第二张:仓库名,物品名,数量 反范式化 一般说来,数据库只需满足第三范式(3NF)就行了。 没有冗余的数据库设计可以做到。...
  • 码创建符合2NF的表第二范式存在的问题第三范式总结(个人理解)如何拆分表,使其符合3NF?1.将符合1NF的表拆分成符合2NF的表。(即消除1NF表中的部分依赖问题)2.将符合2NF的表拆分成符合3NF的表。(即消除2NF表中的...
  • 【数据库】第一范式、第二范式、第三范式、BCNF详解 1、范式 是符合某一种级别的关系模式的集合。是关系数据库规范化过程中为不同程度的规范化要求设立的不同的标准或准则。不同的范式满足的要求不同。 基本思想...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 103,174
精华内容 41,269
关键字:

三范式