精华内容
下载资源
问答
  • 详解第一范式、第二范式、第三范式、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,消除表中的多值依赖

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

    展开全文
  • BCNF范式判断和分解

    千次阅读 2021-05-13 15:19:23
    首先,怎么判断一个关系是不是BCNF范式? 简单来说,对于一个关系R,每个函数依赖X→Y的左侧都包含关系R的码,也就是说每个函数依赖的左侧都是关系R的一个超码,那么这个关系R是BCNF范式的。 另一种判断方式是,对...

    首先,怎么判断一个关系是不是BCNF范式?

    简单来说,对于一个关系R,每个函数依赖X→Y的左侧都包含关系R的码,也就是说每个函数依赖的左侧都是关系R的一个超码,那么这个关系R是BCNF范式的。

    另一种判断方式是,对每个函数依赖X→Y的左侧求闭包,如果对于每一个函数依赖,左侧的闭包包含关系R中的所有属性,那么这个关系R是BCNF范式的。

    反之,用以上方法判断时,如果出现函数依赖不满足以上条件,那么就存在违背BCNF范式的情况, 这个关系R就不是BCNF范式的。

     

    现在,我们有一个关系R和它一个函数依赖集合S,那么我们怎么把R分解成BCNF范式的关系呢?

    1.  首先根据以上办法判断R是不是BCNF范式,如果是的话,那么以下步骤不需要。

    2. 如果存在违背BCNF的函数依赖,任取其中一个,假设我们取X→Y, 计算X的闭包X+(本文中的+都应该是上角标),则R1=X+, R2=X∪(R-X+)。

    3. 分别计算R1和R2的函数依赖集合S1和S2。

    4. 判断R1和R2 是不是BCNF范式,如果不是,根据其对应的函数依赖集合,重复2,3,4步骤,继续进行分解,直到分解后的关系遵循BCNF范式。

     

    下面,我们以一个例子来说明以上这个BCNF分解算法怎么使用?

    假设我们有一个关系表R={A,B,C,D,E,F,G},它的函数依赖集合为S={A→B, C→E,CD→F, F→G}。

    {A,C,D} 是这个表的码。

    A 姓名B 系C 课程D 年份E 学分F 教师G 办公室
    小明计算机系数据库20215张三B123
    小明计算机系C语言20205张三B123
    小红电子系网络基础20205李四A123
    小花软件系数据库20205王五A112
    小花软件系网络基础20215李四A123
    小白电子系高等数学20202赵六C123
    小胖计算机系C语言20195周七B112
    小强软件系高等数学20202赵六C123
    小林计算机系英语20205田八D123

    按照以上步骤对R进行分解:

    1. 首先对每一个函数依赖的左侧求闭包,找出违反BCNF的依赖。 

    S={A→B, C→E,CD→F, F→G}

    A→B: {A}+={A,B}

    C→E:{C}+={C,E}

    CD→F:{CD}+={C,D,E,F,G}

    F→G:{F}+={F,G}

    可以看出,这四个依赖都违反了BCNF,任取其中一个进行下面的步骤,这里以CD→F为例。

    2. R1={CD}+={C,D,E,F,G},R2={C,D}∪{R-{CD}+}={A,B,C,D} .

    3.找出R1 和R2的 函数依赖集合S1和S2, 这是由原关系R的函数依赖集合S得到的。

    对于R1={C,D,E,F,G}, S1={C→E, CD→F, F→G}

    对于R2={A,B,C,D}, S2={A→B}

    4. 对S1和S2,重复步骤1,判断R1和R2是不是遵循BCNF范式。

    这里,R2违反了BCNF范式。所以我们取它的A→B,进一步求出它分解得到的两个关系。

    R3={A}+={A,B}, R4={A}∪{R-{A}+}={A,C,D}

    5. 判断R3和R4是不是符合BCNF, 对于R4,不存在任何的函数依赖,这也可以说明R4是BCNF范式的。

    所以R={A,B,C,D,E,F,G},我们分解成了R1={C,D,E,F,G},R3={A,B}, R4={A,C,D}。

    到此所有分解后的关系都遵循BCNF,可以结束分解,否则需要继续重复以上步骤。

     

    另外,如果不做以上过程,想要直接得出分解后的结果,有一个非常容易的小技巧。

    如果R不遵循BCNF范式,只需任取一个违反BCNF的函数依赖,分解后的关系R1包含这个函数依赖的所有属性(箭头左右都包括),R2包括R中除掉这个函数依赖右侧属性的其他所有属性。再继续对R1和R2分解直至所有的表都是BCNF的。这个过程和上一个方法可能不一样,但是最终结果的所有表都是一样的。

    希望能够将步骤写的尽可能详细,可能有些啰嗦,如果能够理解分解过程,就会容易很多。 

    如有错误,欢迎指正。

     

     

    展开全文
  •   觉得下面这篇文章总结的很好, 逻辑清晰,实例演示。 在此记录一下,方便以后查看。 点击下方文字跳转 关系数据库的三大范式以及BCNF范式

      觉得下面这篇文章总结的很好, 逻辑清晰,实例演示。 在此记录一下,方便以后查看。

    点击下方文字跳转

    关系数据库的三大范式以及BCNF范式

    展开全文
  • 版权声明:本文转自小小呆原创文章 https://blog.csdn.net/gui951753/article/details/79609874 第一范式 定义以及分析: 问题研究: ...BCNF范式 分析 问题研究 小结: 参考文献 ...
         版权声明:本文转自小小呆原创文章       
         https://blog.csdn.net/gui951753/article/details/79609874  
    

    第一范式

    定义以及分析:

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

    表1

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

    编号品名进货数量进货单价销售数量销售单价备注

    表2

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

    问题研究:

    但是表三中的设计我们能看到许多的问题,以下:

    • 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
    • 假如学校新建了一个系,但是暂时还没有招收任何学生(比如3月份就新建了,但要等到8月份才招生),那么是无法将系名与系主任的数据单独地添加到数据表中去的 (注1)——插入异常

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

    • 假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)。——删除异常
    • 假如李小明转系到法律系,那么为了保证数据库中数据的一致性,需要修改三条记录中系与系主任的数据。——修改异常。

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

    第二范式

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

    必备知识点

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

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

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

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

    由函数依赖,我们引出下面的一些概念
    部分函数依赖:设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。

    例1:

    学号身份证号姓名

    表4
    上表中(学号,身份证号,姓名)当然学号属性取值是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号).
    例2:

    snogradecno

    表5
    在上表中,因为Sno不能函数决定Grade,Cno也不能函数决定Grade,但(Sno,Cno)可以唯一地函数决定Grade,所以(Sno,Cno)→Grade是完全函数依赖。因为Sno可以函数决定Sage,所以(Sno,Cno)→Sage是部分函数依赖。
    例3:

    SnoSnameSageSdept

    表6
    在上表中,函数依赖的决定方是Sno,是单属性,所以Sno→(Sname,Sage,Sdept)是完全函数依赖,不存在着部分函数依赖。
    由此,我们知道。只有当函数依赖的决定方是组合属性时,讨论部分函数依赖才有意义,当函数依赖的决定方是单属性时,只能是完全函数依赖。
    完全函数依赖:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。

    例子:学生基本信息表R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级);

    传递函数依赖:在关系模式R(U)中,设X,Y,Z是U的不同的属性子集,如果X确定Y、Y确定Z,且有X不包含Y,Y不确定X,(X∪Y)∩Z=空集合,则称Z传递函数依赖(transitive functional dependency) 于X。
    例子:

    学号宿舍费用
    062201A900
    062230B1200
    062240B1200

    表7
    学号确定宿舍、宿舍确定费用,且有学号不包含宿舍,宿舍不确定学号,符合传递函数依赖条件。

    所以以上关系R存在添加异常(建了C宿舍但是没人住无法添加了)删除异常(学生062201退学了宿舍A也删除掉)如果存在传递函数依赖,如下更改:将上表拆解为两个表

    学号宿舍
    062201A
    062230B
    062240B

    表8

    宿舍费用
    A900
    B1200
    B1200

    表9
    码:设 K 为某表中的一个属性或属性组,若除 K 之外的所有属性都完全函数依赖于 K(这个“完全”不要漏了),那么我们称 K 为候选码,简称为码。在实际中我们通常可以理解为:假如当 K 确定的情况下,该表除 K 之外的所有属性的值也就随之确定,那么 K 就是码。一张表中可以有超过一个码。(实际应用中为了方便,通常选择其中的一个码作为主码) 例如:对于表3,(学号、课名)这个属性组就是码。该表中有且仅有这一个码。(假设所有课没有重名的情况)
    非主属性
    包含在任何一个码中的属性成为主属性。除了主属性以外的就是非主属性。例如:对于表3,主属性就有两个,学号 与 课名。

    定义

    第二范式(Second Normal Form,2nd NF)是指每个表必须有一个(而且仅有一个)数据元素为主关键字(Primary key),其他数据元素与主关键字一一对应。通常称这种关系为函数依赖(Functional dependence)关系,即表中其他数据元素都依赖于主关键字,或称该数据元素惟一地被主关键字所标识。第二范式是数据库规范化中所使用的一种正规形式。它的规则是要求数据表里的所有非主属性都要和该数据表的主键有完全依赖关系;如果有哪些非主属性只和主键的一部份有关的话,它就不符合第二范式。同时可以得出:如果一个数据表的主键只有单一一个字段的话,它就一定符合第二范式(前提是该数据表符合第一范式)

    分析:

    根据2NF的定义,判断的依据实际上就是看数据表中是否存在非主属性对于码的部分函数依赖。若存在,则数据表最高只符合1NF的要求,若不存在,则符合2NF的要求。判断的方法是:

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

    对于表3,根据前面所说的四步,我们可以这么做:
    第一步:

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

    小技巧:就是假如A是码,那么所有包含了A的属性组,如(A,B)、(A,C)、(A,B,C)等等,都不是码了(因为作为码的要求里有一个“完全函数依赖”)。
    我们根据第一个步骤确定出函数依赖关系,并画图如下(表3的函数关系)
    这里写图片描述
    图1
    由此可以得到,表3的码只有一个,就是(学号、课名)。
    第二步:
    主属性有两个:学号 与 课名
    第三步:
    非主属性有四个:姓名、系名、系主任、分数
    第四步:

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

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

    解决办法:

    为了让表3符合2NF的要求,我们必须消除这些部分函数依赖,只有一个办法,就是将大数据表拆分成两个或者更多个更小的数据表,在拆分的过程中,要达到更高一级范式的要求,这个过程叫做”模式分解“。
    模式分解部分,很难,参考很多文献不得甚解。希望后来者能答疑解惑
    大概觉得相关的具体操作可以从以下几点来考量:

    1.码(码就是候选码)是多个的时候,一般每一个码需要进行分解,基于每一个候选码的函数依赖要归并到与当前候选码一致的分解中去。
    2.码中有多个元素的时候,并且存在基于该码的部分函数依赖的时候,将其进行分解
    3.根据函数依赖分解完属性组之后进行化简,去掉每一个分组的重复选项
    4.尝试将化简之后的分组重新进行连接操作,对比分解之前的关系模式是不是一致
    5.一致则可以认为这种化简是有效的
    我们根据以上准则对表3进行分解
    1.码只有一个(学号,课号),无需分解
    2.码中有部分函数依赖,将其进行分解,分解为两个模式。如下图所示
    这里写图片描述
    图2
    3.无重复项,无需分解
    4.重新连接,对比分析前,关系一致。
    5.该模式分解有效。

    分解后的表的形式如下
    这里写图片描述
    表10

    问题研究:

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

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

    第三范式:

    定义:

    第三范式(Third Normal Form,3rd NF)就是指表中的所有数据元素不但要能惟一地被主关键字所标识,而且它们之间还必须相互独立,不存在其他的函数关系。也就是说,对于一个满足2nd NF 的数据结构来说,表中有可能存在某些数据元素依赖于其他非关键字数据元素的现象,必须消除。
    通俗的说,第三范式(3NF)3NF在2NF的基础之上,消除了非主属性对于码的传递函数依赖。也就是说, 如果存在非主属性对于码的传递函数依赖,则不符合3NF的要求。

    分析:

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

    问题分析:

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

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

    BCNF范式

    分析

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

    问题研究

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

    • 先新增加一个仓库,但尚未存放任何物品,是否可以为该仓库指派管理员?
      ——不可以,因为物品名也是主属性,根据实体完整性的要求,主属性不能为空。
    • 某仓库被清空后,需要删除所有与这个仓库相关的物品存放记录,会带来什么问题?
      ——仓库本身与管理员的信息也被随之删除了。
    • 如果某仓库更换了管理员,会带来什么问题?
      ——这个仓库有几条物品存放记录,就要修改多少次管理员信息。

    从这里我们可以得出结论,在某些特殊情况下,即使关系模式符合 3NF 的要求,仍然存在着插入异常,修改异常与删除异常的问题,仍然不是 ”好“ 的设计。
    造成此问题的原因:存在着主属性对于码的部分函数依赖与传递函数依赖。(在此例中就是存在主属性【仓库名】对于码【(管理员,物品名)】的部分函数依赖。解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。
    仓库(仓库名,管理员)库存(仓库名,物品名,数量)
    这样,之前的插入异常,修改异常与删除异常的问题就被解决了。
    以上就是关于 BCNF 的解释。

    小结:

    至今为止没有亲自设计过数据库,最多也就是在课堂上做过数据库课程设计。将来如果自己设计数据库了,再回头看这一篇博客。修改修改。本文中大量内容和案例,来自于知乎上刘老师,后文附有参考链接。

    参考文献

    展开全文
  • 第一范式、第二范式、第三范式、BCNF范式详解

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

    千次阅读 2020-11-21 16:34:05
    什么是”范式(NF)”1. 第一范式(1NF)2. 第二范式(2NF)2.1 函数依赖2.1.1完全函数依赖2.1.2 部分函数依赖 2.2 码2.3 非主属性 3. 第三范式(3NF)4. 小结 4.1 三大范式总结 4.2 完全&部分函数依赖 4.3 ...
  • 什么是”范式(NF)”1. 第一范式(1NF)2. 第二范式(2NF)2.1 函数依赖2.1.1完全函数依赖2.1.2 部分函数依赖 2.2 码2.3 非主属性 3. 第三范式(3NF)4. 小结 什么是”范式(NF)” 按照教材中的定义,范式是“....
  • 复习下数据库的范式。 第一范式 第一范式列不能再分。如一张表里有一个字段是高级职称,但是在高校里高级职称包括副教授和教授,这属于可分的,所以不符合第一范式。 第二范式 第二范式(2NF)是在第一范式(1NF)...
  • 文章系转载,通俗易懂,写了很久代码,数据库知识一直薄弱,学习中;...什么是”范式(NF)” 1. 第一范式(1NF) 2. 第二范式(2NF) 2.1 函数依赖 2.1.1完全函数依赖 2.1.2 部分函数依赖 2....
  • 首先要明白”范式(NF)”是什么意思。按照教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各...数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。一般在我们设计关系型数据库的时候,最多...
  • 首先要明白”范式(NF)”是什么意思。按照教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各...数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF。一般在我们设计关系型数据库的时候,最多...
  • 数据库BC范式BCNF判断和分解

    千次阅读 多人点赞 2020-05-13 12:33:49
    若X→Y且Y不包含X时X必含有码,则R〈U,F〉∈BCNF。 也就是说,关系模式R〈U,F〉中,若每一个决定因素都包含码,则R〈U,F〉∈BCNF。 由关系模式的定义可以得到如下结论,若R属于BCNF,则R有: 1.所有非主属性对每一个码...
  • title: 关系数据库设计(F+闭包、候选码求解、范式判断及BCNF分解) date: 2018-11-12 21:46:32 tags: SQL ...文章目录F+闭包怎么求关系模式的候选码怎么求范式判断分解成(无损连接的)BCNF范式 F+闭包...
  • 范式判断的三个步骤 假设我们有关系模式R(A,B,C),函数依赖F={AB->C} 1.检查R中元素的闭包,也就是哪些元素或者元素组合可以根据F中函数依赖关系得到完整的R,这些元素或者元素组合就是候选码。这里AB的闭包是ABC...
  • 范式BCNF,3NF的判断方法

    千次阅读 2020-06-26 22:54:15
    2、根据BCNF和3NF的定义进行判断。 例题1 Consider the following relational schema R(A,B,C). suppose that the only dependencies (functional or multivalued) that hold on the relation in this schema are BC...
  • BCNF与反范式设计BCNF(巴斯范式)反范式设计反范式存在的问题和适用场景数据仓库和数据库在使用上的区别总结 反范式设计是什么,有了范式设计,为什么还需要反范式设计。反范式设计适用的场景是什么?存在什么问题 3...
  • 范式判断

    2020-03-21 17:27:52
    在3NF的基础上,关系R中,主属性对码没有部分函数以来,则满足BCNF,通常BCNF可以消除数据冗余、插入异常、删除异常、更新异常,但在一些关系依然有缺陷,在满足3NF的基础上,消除多值依赖,则满足4NF ...
  • 如何判断范式(1NF、2NF、3NF、BCNF

    千次阅读 多人点赞 2020-05-16 18:23:39
    同样在这里不提及过多的概念、原理,直接讲如何判断范式 ps.关于如何求候选码见我的另一篇博客https://blog.csdn.net/m0_37345402/article/details/106162563
  • 一图了解范式判断

    千次阅读 2020-09-13 20:28:10
    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyce - Codd范式(BCNF)、第四范式(4NF)和第五范式(5NF)。 满足最低要求的范式是第一范式(1NF)。 在第一范式的基础上进一步满足更多要求的...
  • 数据库 范式判断

    2020-06-20 19:31:20
    1NF 如果一个关系模式R的所有属性都是不可分的基本数据项,则R为...第一范式,虽然BD- >A,但是存在B->A,存在部分函数依赖 3NF 属性不依赖于其他非主属性 例如:学生档案表(学号,姓名,年龄,生源地编号,.
  • 【数据库】第一范式、第二范式、第三范式BCNF详解 1、范式 是符合某一种级别的关系模式的集合。是关系数据库规范化过程中为不同程度的规范化要求设立的不同的标准或准则。不同的范式满足的要求不同。 基本思想...
  • 这里总结一下1NF,2NF,3NF和BCNF 1.第一范式(1NF) 定义 (1NF, Normal Form) 如果一个关系模式R中的每个属性A的域值都是原子的,即属性值是不可再分的,则关系模式R属于第一范式,简记为R ∈ 1NF。若数据库模式...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 2,234
精华内容 893
关键字:

bcnf范式判断