精华内容
下载资源
问答
  • 详解第一范式、第二范式第三范式、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范式理解

    万次阅读 多人点赞 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.没有任何属性完全函数依赖于非码的任何一组属性。

    如上表

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

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

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

    所以需要改成两种表:

    第一张:仓库名,管理员

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

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

    千次阅读 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

    杨过

     

     

    系名

    系主任

    经济系

    张三丰

    法律系

    任我行

    艺术系

    小龙女

     

     

    第三范式

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

    展开全文
  • 范式(2NF):数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖(部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况),也即所有非关键字段都完全依赖于任意一组候选关键字。
  • 第三范式

    千次阅读 2020-07-15 09:43:44
    第三范式. BC范式. 第四范式. 第五范式. 满足最低要求的叫第一范式,简称1NF. 在第一范式基础上进一步满足一些要求的为第二范式,简称2NF. 其余依此类推. 范式越高: 优点: 可以避免数据冗余. 缺点: 性能就会越差,...

    关系数据库中的关系必须满足一定的要求。
    数据库的 范式 是数据库设计所需要满足的规范。
    只有理解数据库的范式,才能设计出高效率、优雅的数据库,否则可能会设计出错误的数据库.

    主要有六种范式:


    第一范式.
    第二范式.
    第三范式.
    BC范式.
    第四范式.
    第五范式.


    满足最低要求的叫第一范式,简称 1NF . 在第一范式基础上进一步满足一些要求的为第二范式,简称 2NF . 其余依此类推.

    范式越高:
    优点: 可以避免数据冗余.
    缺点: 性能就会越差, 需要联系多个表才能得到所需要数据, 并且操作会 更困难.

    权衡利弊, 一般项目会使用 第三范式.
    数据冗余小, 且 方便管理.

    1NF是关系模式应具备的 最起码的条件,如果数据库设计不能满足第一范式,就不称为关系型数据库.

    定义:如果 关系模式R 的每个 关系r 的属性都是不可分的数据项,那么就称R是第一范式的模式.
    例如 (学生信息表):

    学生编号姓名性别联系方式
    0001张某email:zm@126.com,phone:123456
    0002李某email:lm@126.com,phone:456789

    以上的表就不符合,第一范式:联系方式字段可以再分.
    满足 第一范式(1NF) 的表结构应该如下:

    学生编号姓名性别电子邮件电话
    0001张某zm@126.com123456
    0002李某lm@126.com456789

    第二范式(2NF)

    定义:如果 关系模式R 是 1NF,且每个 非主属性 完全函数依赖于 候选键,那么就称R是第二范式.

    例如 (产品流水凭证模板表), 产品代码 和 交易类型 是联合 主键:

    产品代码交易类型产品名称凭证模板代码差额凭证模板代码
    p1666产品At1tt1
    p2777产品Bt2tt1
    p1888产品At1tt1

    通过 产品代码 大专栏  第三范式和 交易类型 可以确定 凭证模板代码, 差额凭证模板代码, 产品名称, 所以 可以把 (产品代码, 交易类型) 作为主键.
    但是, 产品名称 并不完全 依赖于 (产品代码, 交易类型), 只要 产品代码 就能确定 产品名称, 这种依赖叫 不完全依赖 (或部分依赖).

    第二范式 不能有 不完全依赖 .

    修改后, 满足第二范式:

    产品代码交易类型凭证模板代码差额凭证模板代码
    p1666t1tt1
    p2777t2tt1
    p1888t1tt1
    产品代码产品名称
    p1产品A
    p2产品B

    第三范式(3NF)

    定义: 首先要满足第二范式,其次 非主属性 之间不存在函数依赖.

    由于满足了第二范式,表示每个 非主属性 都函数依赖于 主键。如果 非主属性 之间存在了 函数依赖,就会存在 传递依赖,这样就不满足第三范式。

    例如 (产品流水凭证模板表), 产品代码 和 交易类型 是联合 主键:

    产品代码交易类型凭证模板代码差额凭证模板代码差额凭证模板名称
    p166t1tt1差额A
    p2777t2tt1差额A
    p1888t1tt1差额A

    差额凭证模板代码 依赖于 主键 (产品代码, 交易类型), 差额凭证模板名称 依赖于 差额凭证模板 代码, 这就存在 传递依赖, 不满足第三范式.

    修改 使其满足 第三范式 :

    产品代码交易类型凭证模板代码差额凭证模板代码
    p166t1tt1
    p2777t2tt1
    p1888t1tt1
    差额凭证模板代码差额凭证模板名称
    tt1差额A
    展开全文
  • 范式:   列1唯一确定列2、列3、列4…,即列不能再分成其它几列。   假设列1:订单名,列2:商品名,一个订单名里可以有多个商品名,所以这样就不符合范式范式:   首先符合1NF,另外包含两...
  • 它构建在第三范式的基础上,如果关系模型R是第一范式,且每个属性都不传递依赖于R的候选键,那么称R为BCNF的模式。 假设仓库管理关系表(仓库号,存储物品号,管理员号,数量),满足一个管理员只在一个仓库工作;一个...
  • 第一范式、第二范式第三范式、BCNF范式详解

    千次阅读 多人点赞 2020-10-10 15:26:19
    范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”。
  • 范式: 一个表中,每个【列的值是不能再分割的】. 例如:我们设计的表中有一个列是:爱好 这个列的值可能会是这样:足球篮球乒乓球 但是这值是可以再分割的:足球、篮球、乒乓球 所以这种设计是不满足范式 ...
  • 文章目录 什么是”范式(NF)”1. 第一范式(1NF)2. 第二范式(2NF)2.1 函数依赖2.1.1完全函数依赖2.1.2 部分函数依赖 ... 第三范式3NF)4. 小结 什么是”范式(NF)” 按照教材中的定义,范式是“...
  • 范式(1NF)无重复的列  所谓范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要...
  • 1.第一范式(1NF):所有属性都...第三范式3NF):任何非主属性不依赖于其它非主属性,目的是实体拆分。 4. BC (The Boyce-Codd Normal Form) 范式3NF 的基础上消除主属性对于码的部分与传递函数依赖。 ...
  • 数据库关系数据理论----范式范式原理笔记什么是(范式)---范式介绍范式发展1、第一范式2、第二范式3第三范式4、BCNF(扩展第三范式) 什么是(范式)—范式介绍 官方介绍,数据库中的关系是要满足一定要求的,...
  • 数据库|第一范式、第二范式第三范式、BC范式、第四范式简单理解 在设计数据库的时候,虽说将我们要的数据正确完整导入数据库是很关键的,但是对于数据库的设计者来说,如何将大量数据合理有效正确地导入数据库中也...
  • 1.1范式(1NF)无重复的列 所谓范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能...
  • ) 但是(仓库名)->(管理员) 不满足第二条 所以需要改成两种表: 第一张:仓库名,管理员 第二张:仓库名,物品名,数量 反范式化 一般说来,数据库只需满足第三范式3NF)就行了。 没有冗余的数据库设计可以做到。...
  • 范式:英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系...通常所用到的只是前范式,即:范式(1NF),范式(2NF)...
  • 网络上已经有人介绍第二范式第三范式之间的区别,但是我看了之后觉得甚是模糊,很不清晰.为此特意写了这篇博客再来解释一下第二范式第三范式之间的区别. 直接给结论:第二范式要求非主键属性与所有主键相关(针对...
  • 一、范式 理论: 1.范式的目标是确保每列的原子性。 2.如果每列都是不可再分的最小数据单元(也称为最小的原子单元),则满足范式(1NF:First Normal Form)。 举例说明: 不满足范式: 满足范式...
  • 范式:英文名称是 Normal Form,它是...通常所用到的只是前三个范式,即:第一范式(1NF),第二范式(2NF),第三范式3NF)。下面就简单介绍下这三个范式。 ◆ 第一范式(1NF):强调的是列的原子性,即列不能够再..
  • 1、范式(1NF):同列中不能有多个值。下图所示此表不是范式 2、范式(2NF):要求实体的属性完全依赖于主关键字。 一个订单明细表:【OrderDetail】(OrderID,ProductID,UnitPrice,Discount,...
  • 先来看看范式范式是数据库关系模式的基础,换句话说,起码必须满足范式才是正确的,那么什么是范式呢? 范式就是在一个关系模式内,不能存在还可以再分的属性,即所有属性都必须是简单属性(不...
  • [数据库] 第一范式、第二范式第三范式、BC范式

    万次阅读 多人点赞 2017-02-23 19:30:33
    数据描述术语对应表 关键码 完全依赖、部分依赖、传递依赖 第一范式、第二范式第三范式
  • 版权声明:本文转自小小呆原创文章 ... 第一范式 定义以及分析: 问题研究: 第二范式 ...第三范式: 定义: 分析: 问题分析: BCNF范式 分析 问题研究 小结: 参考文献 ...
  • 文章系转载,通俗易懂,写了很久代码,数据库知识一直薄弱,学习中;本文能够很好帮助理解,谢谢原作者... 范式(1NF) 2. 范式(2NF) 2.1 函数依赖 2.1.1完全函数依赖 2.1.2 部分函数依赖 2....
  • 一般的数据库设计都需要满足三范式,这是最基本的要求的,最高达到6NF,但是一般情况下3NF达到了就可以 一:1NF一范式的理解: 1NF是关系型数据库中的最基本要求,就是要求记录的属性是原子性,不可分,就是属性不...
  • 范式 1NF 属性的原子性,及属性中无重复的列 所谓的范式就是数据库中的每一列都是不可分割的基本数据...范式是在范式的基础上建立起来的,即满足范式必须先满足范式范式要求数据库...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 95,532
精华内容 38,212
关键字:

第三范式