精华内容
下载资源
问答
  • 详解第一范式、第二范式、第三范式、BCNF范式

    万次阅读 多人点赞 2019-03-02 16:08:45
    首先是第一范式1NF)。符合1NF的关系(你可以理解为数据表。“关系模式”和“关系”的区别,类似于面向对象程序设计中”类“与”对象“的区别。”关系“是”关系模式“的一个实例,你可以把”关系”理解...

    什么是”范式(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范式理解

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

    第一范式、第二范式、第三范式

    参考了https://www.zhihu.com/question/24696366
    https://www.cnblogs.com/lca1826/p/6601395.html

    基础知识

    实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,比如说“老师与学校的关系”。

    属性:教科书上解释为:“实体所具有的某一特性”,由此可见,属性一开始是个逻辑概念,比如说,“性别”是“人”的一个属性。在关系数据库中,属性又是个物理概念,属性可以看作是“表的一列”。

    元组:表中的一行就是一个元组。

    分量:元组的某个属性值。在一个关系数据库中,它是一个操作原子,即关系数据库在做任何操作的时候,属性是“不可分的”。否则就不是关系数据库了。

    码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。

    全码:如果一个码包含了所有的属性,这个码就是全码。

    主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。

    非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。

    外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。

    第一范式

    第一范式列不能再分。

    第二范式

    第二范式建立在第一范式的基础上,非主属性完全依赖于码。
    简单说:消除部分依赖。

    (什么是码?) 表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。主码可以包含多个属性。

    要理解第二第三范式需要理解完全函数依赖、部分函数依赖、传递函数依赖。


    完全函数依赖

    定义:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。

    比如通过学号->姓名


    部分函数依赖

    定义:设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。

    需要借用知乎刘慰教师的例子用一下,自己也理解了很长时间。

    码用(学号+课程),为什么要加课程呢?因为不同课程成绩是通过学号查不出来的。

    不过用(学号+课程)当作码是不是有些问题?

    (学号+课程)->姓名,但是学号->姓名

    (学号+课程)->系名,但是学号->系名

    (学号+课程)->系主任,但是学号->系主任

    这个就是部分依赖,说实话我看定义一脸懵逼。

    要是上面那张表符合第二范式。需要将表拆分为两张表。

    一张是 学号、课程、分数表

    另外一张是 学号、姓名、系名、系主任表


    传递函数依赖

    设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。

    https://blog.csdn.net/rl529014/article/details/48391465

    采用这位大佬的例子
    在关系R(学号 ,宿舍, 费用)中,(学号)->(宿舍),宿舍!=学号,(宿舍)->(费用),费用!=宿舍,所以符合传递函数的要求

    第三范式

    满足第二范式的条件下不存在传递函数依赖。

    要满足第三范式,在分成两张表的时候第二张表还是有问题?

    学号->系名,系名->系主任 传递依赖。

    需要将系名和系主任另外新建一张表。

    总结:

    第一范式:简单说 列不能再分

    第二范式:简单说 建立在第一范式基础上,消除部分依赖

    第三范式:简单说 建立在第二范式基础上,消除传递依赖。


    码:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。

    主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。

    非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。

    BCNF范式

    https://www.2cto.com/database/201404/290140.html

    BCNF是3NF的改进形式

    一个满足BCNF的关系模式的条件:

    1.所有非主属性对每一个码都是完全函数依赖。

    2.所有的主属性对每一个不包含它的码,也是完全函数依赖。

    3.没有任何属性完全函数依赖于非码的任何一组属性。

    如上表

    (仓库名,管理员)->(物品名,数量)

    (管理员,物品名)->(仓库名,数量)

    但是(仓库名)->(管理员) 不满足第二条

    所以需要改成两种表:

    第一张:仓库名,管理员

    第二张:仓库名,物品名,数量

    展开全文
  • [数据库] 第一范式、第二范式、第三范式、BC范式

    万次阅读 多人点赞 2017-02-23 19:30:33
    数据描述术语对应表 关键码 完全依赖、部分依赖、传递依赖 第一范式、第二范式、第三范式

    要搞清楚常见范式,需得先了解以下概念

    数据描述术语对应表
    这里写图片描述

    关键码
    1) 超键:在关系中能唯一标识元组的属性或属性集称为关键模式的超键。
    2) 候选键:不含有多余属性的超键称为候选键。也就是在候选键中在删除属性就不是键了。
    3) 主键:用户选作元组标识的候选键称为主键。一般不加说明,键就是指主键。
    4) 外键:如果模式R中属性K是其他模式的主键,那么K在模式R中称为外键。

    完全依赖、部分依赖、传递依赖
    部分函数依赖:设X,Y是关系R的两个属性集合,存在X→Y,若X’是X的真子集,存在X’→Y,则称Y部分函数依赖于X。
    举个例子:学生基本信息表R中(学号,身份证号,姓名)当然学号属性取值是唯一的,在R关系中,(学号,身份证号)->(姓名),(学号)->(姓名),(身份证号)->(姓名);所以姓名部分函数依赖与(学号,身份证号);
    完全函数依赖:设X,Y是关系R的两个属性集合,X’是X的真子集,存在X→Y,但对每一个X’都有X’!→Y,则称Y完全函数依赖于X。
    例子:学生基本信息表R(学号,班级,姓名)假设不同的班级学号有相同的,班级内学号不能相同,在R关系中,(学号,班级)->(姓名),但是(学号)->(姓名)不成立,(班级)->(姓名)不成立,所以姓名完全函数依赖与(学号,班级);

    传递函数依赖:设X,Y,Z是关系R中互不相同的属性集合,存在X→Y(Y !→X),Y→Z,则称Z传递函数依赖于X。
    例子:在关系R(学号 ,宿舍, 费用)中,(学号)->(宿舍),宿舍!=学号,(宿舍)->(费用),费用!=宿舍,所以符合传递函数的要求;

    1NF 一言以蔽之:“第一范式的数据表必须是二维数据表”,第一范式是指数据库的每一列都是不可分割的基本数据项,强调列的原子性,试题中某一属性不能拥有几个值。比如数据库的电话号码属性里面不可以有固定电话和移动电话值,如下图:
    违反第一范式的示例

    说明:在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。

    2NF 第二范式建立在第一范式的基础上,即满足第二范式一定满足第一范式,第二范式要求数据表每一个实例或者行必须被唯一标识。除满足第一范式外还有两个条件,一是表必须有一个主键;二是没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。

    每一行的数据只能与其中一列相关,即一行数据只做一件事。只要数据列中出现数据重复,就要把表拆分开来。

    举例来说:当数据表中是联合主键,但是有的列只依赖联合主键中的一个或一部分属性组成的联合主键,此时需要拆表才能复合第二范式。

    3NF 若某一范式是第二范式,且每一个非主属性都不传递依赖于该范式的候选键,则称为第三范式,即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。

    举例来说:Employee(emp_id,emp_name,emp_age,dept_id,dept_name,dept_info),当员工表中emp_id能够唯一确定员工员工信息,但是dept_name可由dept_id唯一确定,此时,该表不符合第三范式,此时可以删除除了dept_id之外的其他部门信息,把所有部门信息单独建立一张部门表。

    BCNF 在第三范式的基础上,数据库表中如果不存在任何字段对任一候选关键字段的传递函数依赖则符合第三范式。

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

    R属于3NF,不一定属于BCNF,如果R属于BCNF,一定属于3NF。

    假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:

    (仓库ID, 存储物品ID) →(管理员ID, 数量)

    (管理员ID, 存储物品ID) → (仓库ID, 数量)

    所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

    (仓库ID) → (管理员ID)

    (管理员ID) → (仓库ID)

    即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。

    展开全文
  • 1.第一范式1NF):所有属性都是不可分割的原子值。 2.第二范式(2NF):在第一范式的基础上,要求非主属性都要和码有完全依赖关系 第三范式(3NF):任何非主属性不依赖于其它非主属性,目的是...

    1.第一范式(1NF):所有属性都是不可分割的原子值。 

    https://img-blog.csdn.net/20170413152947394?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRG9VVW5kZXJzdGFuZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast

    https://img-blog.csdn.net/20170413154051744?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRG9VVW5kZXJzdGFuZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast


    2.第二范式(2NF):在第一范式的基础上,要求非主属性都要和码有完全依赖关系 

    部分依赖:第2张表

     

    https://img-blog.csdn.net/20170413155426235?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRG9VVW5kZXJzdGFuZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast

     

    https://img-blog.csdn.net/20170413161635121?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRG9VVW5kZXJzdGFuZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast

    https://img-blog.csdn.net/20170413165738596?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast


    第三范式(3NF):任何非主属性不依赖于其它非主属性,目的是实体拆分。

    传递依赖:系名->系主任

    https://img-blog.csdn.net/20170413171742835?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRG9VVW5kZXJzdGFuZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast

    https://img-blog.csdn.net/20170413171809809?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRG9VVW5kZXJzdGFuZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast

     

    4. BC (The Boyce-Codd Normal Form) 范式在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。 

    https://img-blog.csdn.net/20170526195923708?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvRG9VVW5kZXJzdGFuZA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast

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

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

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

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

    所以,(仓库号,存储物品号)和(管理员号,存储物品号)都是仓库管理关系表的候选码,表中唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

    (仓库号)——>(管理员号)

    (管理员号)——>(仓库号)

    仓库(仓库名,管理员) 

    库存(仓库名,物品名,数量)这样,之前的插入异常,修改异常与删除异常的问题就被解决了。

    5、4NF(第四范式)

    设R是一个关系模型,D是R上的多值依赖集合。如果D中存在凡多值依赖X->Y时,X必是R的超键,那么称R是第四范式的模式。

     

    例如,职工表(职工编号,职工孩子姓名,职工选修课程),在这个表中,同一个职工可能会有多个职工孩子姓名,同样,同一个职工也可能会有多个职工选修课程,即这里存在着多值事实,不符合第四范式。如果要符合第四范式,只需要将上表分为两个表,使它们只有一个多值事实,例如职工表一(职工编号,职工孩子姓名),职工表二(职工编号,职工选修课程),两个表都只有一个多值事实,所以符合第四范式。

    还有:

     

    例如:
    课程代码     老师      教科书
    001              Tom      A
    001              Tom      B
    001              Jim        A
    001              Jim        B
    教科书和老师都是多值属性,所以分出来
    课程-老师(课程代码,老师)
    课程-教科书(课程代码,教科书)
    展开全文
  • 第一范式第二范式第三范式

    千次阅读 2014-06-26 10:46:21
    关系数据库中的关系必须满足一定的要求。满足不同程度要求的为不同范式。数据库的设计范式是数据库设计...满足最低要求的叫第一范式,简称1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称2NF。其余依此类推
  • 第一范式 1NF 属性的原子性,及属性中无重复的列 所谓的第一范式就是数据库中的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性,如果出现重复的属性...
  • 第一范式 属性的原子性 所谓的第一范式就是数据库中的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性,如果出现重复的属性则需要重新构建实体,新的...
  • 第一范式、第二范式和第三范式

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

    千次阅读 多人点赞 2014-09-03 10:29:41
    如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF(即R符合第一范式)。 第二范式 若关系模式R∈1NF(即R符合第一范式),并且每一个非主属性都完全依赖于R的码,则R∈2NF(即R符合第二范式)。 第...
  • 说明:在任何一个关系数据库中,第一范式1NF)是对关系模式的基本要求,不满足第一范式1NF)的数据库就不是关系数据库。 第二范式建立在第一范式的基础上,即满足第二范式一定满足第一范式,第二范式要求数据...
  • 1.第一范式的目标是确保每列的原子性。 2.如果每列都是不可再分的最小数据单元(也称为最小的原子单元),则满足第一范式(1NF:First Normal Form)。 举例说明: 不满足第一范式: 满足第一范式: 二、第二范式 理论...
  • 第一范式 第二范式 第三范式理解

    热门讨论 2019-08-01 15:01:34
    数据库中设计一个好的标准化范式能大大减少数据冗余,...第二范式:在第一范式的基础上,必须消除局部依赖也就是说,非主键(非主属性)必须完全依赖主键(码)不能只依赖主键的一部分。例如:x 除x本身所有属性全...
  • 数据库(第一范式,第二范式,第三范式
  • 第一范式: 非规范化表格和规范化表格: 第二范式: 第三范式
  • 数据库部分函数依赖 完全函数依赖 传递函数依赖 第一范式、第二范式、第三范式、BCNF范式区别 在理解函数依赖之前,先来看一下函数依赖分析: 在关系中,包括在任何候选码中的属性称为主属性;不包括在任何候选...
  • 第一范式: 一个表中,每个【列的值是不能再分割的】. 例如:我们设计的表中有一个列是:爱好 这个列的值可能会是这样:足球篮球乒乓球 但是这值是可以再分割的:足球、篮球、乒乓球 所以这种设计是不满足第一范式 ...
  • 先利用企业来总结一下各个范式的定义:第一范式:一人一岗 ;第二范式:普通员工和单个领导之间不存在从属关系;第三范式:普通员工之间不存在从属关系;BCNF范式:单个领导与单个领导之间不存在从属关系 。详细解释...
  • 先来看看第一范式第一范式是数据库关系模式的基础,换句话说,起码必须满足第一范式才是正确的,那么什么是第一范式呢? 第一范式就是在一个关系模式内,不能存在还可以再分的属性,即所有属性都必须是简单属性(不...
  • 第一范式 存在非主属性对码的部分依赖关系 R(A,B,C) AB是码 C是非主属性 B-->C B决定C C部分依赖于B 第一范式 定义:如果关系R 中所有属性的值域都是单纯域,那么关系模式R是第一范式的 那么符合第一模式的特点...
  • 第一范式 第一范式:所有属性都是不可分割的原子值。 也就是每个属性都是不可再分的。 例如下图就不符合第一范式的要求 实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS),例如...
  • 1.1第一范式1NF)无重复的列 所谓第一范式1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能...
  • 数据库的第一范式、第二范式、第三范式,BCNF范式四大范式的基本概念名词解释范式优化实例一个特别糟糕的关系模式第一范式第二范式第三范式BCNF范式 此文章用于本人期末复习,适合对数据库范式分析还有一点记忆的...
  •   假设列1:订单名,列2:商品名,一个订单名里可以有多个商品名,所以这样就不符合第一范式。 第二范式:   首先符合1NF,另外包含两部分内容,一是表必须有一个(及以上)主键;二是没有包含在主键中的列必须...
  • 第一范式1NF)2. 第二范式(2NF)2.1 函数依赖2.1.1完全函数依赖2.1.2 部分函数依赖 2.2 码2.3 非主属性 3. 第三范式(3NF)4. 小结 什么是”范式(NF)” 按照教材中的定义,范式是“...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 98,419
精华内容 39,367
关键字:

第一范式