精华内容
下载资源
问答
  • 范式 1NF 属性的原子性,及属性中无重复的列 所谓的范式就是数据库中的每一列都是不可分割的基本数据...范式是在范式的基础上建立起来的,即满足范式必须先满足范式范式要求数据库...

    第一范式 1NF 

    属性的原子性,及属性中无重复的列

    所谓的第一范式就是数据库中的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性,如果出现重复的属性则需要重新构建实体,新的实体由重复的属性构成。

     

    第二范式 2NF

    属性完全依赖于主键

    第二范式是在第一范式的基础上建立起来的,即满足第二范式必须先满足第一范式,第二范式要求数据库的每个实例或行必须可以被唯一的区分,即表中要有一列属性可以将实体完全区分,这个属性就是主键,即每一个属性完全依赖于主键,在员工管理中,员工可以通过员工编号进行唯一区分,
    完全依赖概念:即非主属性不能依赖于主键的部分属性,必须依赖于主键的所有属性
     

    第三范式 3NF 

    属性不依赖与其他非主属性

    满足第三范式必须先满足第二范式,第三范式要求一个数据库表中不包含已在其他表中已包含的非主关键字信息, 例如 存在一个课程表,课程表中有课程号(Cno),课程名(Cname),学分(Ccredit),那么在学生信息表中就没必要再把课程名,学分再存储到学生表中,这样会造成数据的冗余, 第三范式就是属性不依赖与其他非主属性,也就是说,如果存在非主属性对于码的传递函数依赖,则不符合第三范式
     

    展开全文
  • 数据库第三范式

    千次阅读 2014-02-24 15:00:51
    第三范式(3NF):如果关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递信赖,则称关系R是属于第三范式的。 当然,这里要把1、2、3、4范式都讲一下。 第一范式(1NF):在关系模式R中的每一个...

    第三范式(3NF):如果关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递信赖,则称关系R是属于第三范式的。


    当然,这里要把1、2、3、4范式都讲一下。

    第一范式(1NF):在关系模式R中的每一个具体关系r中,如果每个属性值 都是不可再分的最小数据单位,则称R是第一范式的关系。例:如职工号,姓名,电话号码组成一个表(一个人可能有一个办公室电话 和一个家里电话号码) 规范成为1NF有三种方法:
    一是重复存储职工号和姓名。这样,关键字只能是电话号码。
    二是职工号为关键字,电话号码分为单位电话和住宅电话两个属性
    三是职工号为关键字,但强制每条记录只能有一个电话号码。
    以上三个方法,第一种方法最不可取,按实际情况选取后两种情况。 

    职工号 姓名 办公电话 家里号码
           


    第二范式(2NF):如果关系模式R(U,F)中的所有非主属性都完全依赖于任意一个候选关键字,则称关系R 是属于第二范式的。
    例:选课关系 SCI(SNO,CNO,GRADE,CREDIT)其中SNO为学号, CNO为课程号,GRADEGE 为成绩,CREDIT 为学分。 由以上条件,关键字为组合关键字(SNO,CNO) 

    学号 课程号 成绩 学分
           

    在应用中使用以上关系模式有以下问题:
    a.数据冗余,假设同一门课由40个学生选修,学分就 重复40次。
    b.更新异常,若调整了某课程的学分,相应的元组CREDIT值都要更新,有可能会出现同一门课学分不同。
    c.插入异常,如计划开新课,由于没人选修,没有学号关键字,只能等有人选修才能把课程和学分存入。
    d.删除异常,若学生已经结业,从当前数据库删除选修记录。某些门课程新生尚未选修,则此门课程及学分记录无法保存。
    原因:非关键字属性CREDIT仅函数依赖于CNO,也就是CREDIT部分依赖组合关键字(SNO,CNO)而不是完全依赖。
    解决方法:分成两个关系模式 SC1(SNO,CNO,GRADE),C2(CNO,CREDIT)。新关系包括两个关系模式,它们之间通过SC1中的外关键字CNO相联系,需要时再进行自然联接,恢复了原来的关系。

    学号 课程号 成绩
         

    课程号 学分
       


    第三范式(3NF):如果关系模式R(U,F)中的所有非主属性对任何候选关键字都不存在传递信赖,则称关系R是属于第三范式的。
    例:如S1(SNO,SNAME,DNO,DNAME,LOCATION) 各属性分别代表学号,
    姓名,所在系,系名称,系地址。 

    学号 姓名 所在系 系名称 系地址
             

    关键字SNO决定各个属性。由于是单个关键字,没有部分依赖的问题,肯定是2NF。但这关系肯定有大量的冗余,有关学生所在的几个属性DNO,DNAME,LOCATION将重复存储,插入,删除和修改时也将产生类似以上例的情况。
    原因:关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在,DNO -> LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说,SNO不直接决定非主属性LOCATION。
    解决目地:每个关系模式中不能留有传递依赖
    解决方法:分为两个关系 S(SNO,SNAME,DNO),D(DNO,DNAME,LOCATION)
    注意:关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

    学号 姓名 所在系
         

    所在系 系名称 系地址
         


    BCNF:如果关系模式R(U,F)的所有属性(包括主属性和非主属性)都不传递依赖于R的任何候选关键字,那么称关系R是属于BCNF的。或是关系模式R,如果每个决定因素都包含关键字(而不是被关键字所包含),则RCNF的关系模式。
    例:配件管理关系模式 WPE(WNO,PNO,ENO,QNT)分别表仓库号,配件号,职工号,数量。有以下条件
    a.一个仓库有多个职工。
    b.一个职工仅在一个仓库工作。
    c.每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件。
    d.同一种型号的配件可以分放在几个仓库中。
    分析:由以上得 PNO 不能确定QNT,由组合属性(WNO,PNO)来决定,存在函数依赖(WNO,PNO) -> ENO。由于每个仓库里的一种配件由专人负责,而一个人可以管理几种配件,所以有组合属性(WNO,PNO)才能确定负责人,有(WNO,PNO)-> ENO。因为 一个职工仅在一个仓库工作,有ENO -> WNO。由于每个仓库里的一种配件由专人负责,而一个职工仅在一个仓库工作,有 (ENO,PNO)-> QNT。
    找一下候选关键字,因为(WNO,PNO) -> QNT,(WNO,PNO)-> ENO ,因此 (WNO,PNO)可以决定整个元组,是一个候选关键字。根据ENO->WNO,(ENO,PNO)->QNT,故(ENO,PNO)也能决定整个元组,为另一个候选关键字。属性ENO,WNO,PNO 均为主属性,只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的,并且是直接依赖,所以该关系模式是3NF。
    分析一下主属性。因为ENO->WNO,主属性ENO是WNO的决定因素,但是它本身不是关键字,只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字(ENO,PNO)的部 分依赖,因为(ENO,PNO)-> ENO但反过来不成立,而P->WNO,故(ENO,PNO)-> WNO 也是传递依赖。
    虽然没有非主属性对候选关键辽的传递依赖,但存在主属性对候选关键字的传递依赖,同样也会带来麻烦。如一个新职工分配到仓库工作,但暂时处于实习阶段,没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全,则在删除配件的同时该职工也会被删除。
    解决办法:分成管理EP(ENO,PNO,QNT),关键字是(ENO,PNO)工作EW(ENO,WNO)其关键字是ENO
    缺点:分解后函数依赖的保持性较差。如此例中,由于分解,函数依赖(WNO,PNO)-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此,分解之后的关系模式降低了部分完整性约束。

    一个关系分解成多个关系,要使得分解有意义,起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身,而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度,但是分解的同时必须考虑两个问题:无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性,又完全保持函数依赖。需要根据需要进行权衡。

    1NF直到BCNF的四种范式之间有如下关系:
    BCNF包含了3NF包含2NF包含1NF

    小结:
    目地:规范化目的是使结构更合理,消除存储异常,使数据冗余尽量小,便于插入、删除和更新
    原则:遵从概念单一化 "一事一地"原则,即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
    方法:将关系模式投影分解成两个或两个以上的关系模式。
    要求:分解后的关系模式集合应当与原关系模式"等价",即经过自然联接可以恢复原关系而不丢失信息,并保持属性间合理的联系。

    注意:一个关系模式结这分解可以得到不同关系模式集合,也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间,避免数据不一致性,提高对关系的操作效率,同时满足应用需求。实际上,并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高,查询频度极高的数据库系统更是如此。

    在关系数据库中,除了函数依赖之外还有多值依赖,联接依赖的问题,从而提出了第四范式,第五范式等更高一级的规范化要求。在此,以后再谈。

    各位朋友,你看过后有何感想,其实,任何一本数据库基础理论的书都会讲这些东西,考虑到很多网友是半途出家,来做数据库。特找一本书大抄特抄一把,各位有什么问题,也别问我了,自已去找一本关系数据库理论的书去看吧,说不定,对各位大有帮助。说是说以上是基础理论的东西,请大家想想,你在做数据库设计的时候有没有考虑过遵过以上几个范式呢,有没有在数据库设计做得不好之时,想一想,对比以上所讲,到底是违反了第几个范式呢?
    我见过的数据库设计,很少有人做到很符合以上几个范式的,一般说来,第一范式大家都可以遵守,完全遵守第二第三范式的人很少了,遵守的人一定就是设计数据库的高手了,BCNF的范式出现机会较少,而且会破坏完整性,你可以在做设计之时不考虑它,当然在ORACLE中可通过触发器解决其缺点。以后我们共同做设计之时,也希望大家遵守以上几个范式。

    那些数据库的书介绍的数据库范式,实在是晦涩难懂,我在这里给出一个通俗的描述:

    1NF:一个table中的列是不可再分的(即列的原子性)

    2NF:一个table中的行是可以唯一标示的,(即table中的行是不可以有重复的)

    3NF:一个table中列不依赖以另一个table中的非主键的列,还是不通俗!巨寒!!

            举个例子吧:有一个部门的table,我们叫它tbl_department, 它有这么几列(dept_id(pk),dept_name,dept_memo...) 有一个员工table,我们叫它tbl_employee,在这个table中有一列dept_id(fk)描述关于部门的信息,若tbl_employee要满足3NF,则在tbl_employee中就不得再有除dept_id列的其它有关部门信息的列!

    一般数据库的设计满足3NF即可!(个人觉得应该尽可能的满足3NF,一家之言^_^)

    BCNF:通常认为BCNF是修正的第三范式,它比3NF又进一步!

    4NF:

    5NF:将一个table尽可能的分割成小的块,以排除在table中所有冗余的数据

    展开全文
  • 1 概述  一般地,在进行数据库设计时,应遵循三大原则,也就是我们通常说的三大范式,即第一范式要求确保...第三范式确保主键列之间没有传递函数依赖关系,也就是消除传递依赖。  本文将基于三大范式原则,结合...

    1   概述

           一般地,在进行数据库设计时,应遵循三大原则,也就是我们通常说的三大范式,即第一范式要求确保表中每列的原子性,也就是不可拆分;第二范式要求确保表中每列与主键相关,而不能只与主键的某部分相关(主要针对联合主键),主键列与非主键列遵循完全函数依赖关系,也就是完全依赖;第三范式确保主键列之间没有传递函数依赖关系,也就是消除传递依赖。

          本文将基于三大范式原则,结合具体的实例做简要分析,难度系数:基础。

    2   第一范式

     2.1 例子引入

         根据如下场景设计出两种数据表,请分析两种数据表的合理性。

    1问题:需求描述:数据库系统中需要一个实体表,该表用来存储用户信息,其中“地址”这个属性,要求查询到省份、城市和详细地址。

    2

    3具体例子:

    4姓名:张红欣;  性别:男; 年龄:26岁; 联系电话:0378-23459876;省份:河南省;城市:开封; 详细地址:朝阳区新华路23号;

    5姓名:王艳;    性别:女; 年龄:25岁; 联系电话:021-2348768; 省份:贵州省;城市:贵阳市;详细地址:南明区南明区狮峰路6号;

    6姓名:汪梅;    性别:女; 年龄:21岁; 联系电话:0571-3876450;省份:浙江省;城市:杭州市;详细地址:滨江区滨康路352号;               

    第一种表设计

     第二种表设计

     2.2  分析

    第一种表设计不满足第一范式,为什么不满足第一范式?因为region列不具有原子性,能拆分成省份、市和具体地址;

    3   第二范式

    3.1 例子引入

         根据如下场景设计出两种数据表,请分析两种数据表的合理性。

    1  需求描述:设计一个订单信息表,订单有多种商品,将订单编号和商品编号作为联合主键。

    第一种表设计

    第二种表设计

     3.2 分析

     第一种表设计不满足第二范式 ,订单编号和商品编号作为联合主键,由于商品名称,单位,价格这几列只与商品编号有关,与订单编号无关,因此与主键(联合主键)无关,违反范式第二原则;

    第二种表设计满足第二范式,把第一种设计表进行拆分,把商品信息分离到另一个表中,把订单项目表也分离到另一个表中。

    4    第三范式

    4.1  例子引入

    根据如下场景设计出两种数据表,请分析两种数据表的合理性。

    1需要在数据库中存储如下信息:

    2    学生编号;学生卡号;用户ID号;操作员级别;操作日期;操作时间;

    第一种表设计

    第二种表设计

    4.2 分析

    第一种表设计不满足第三范式,在表中,一个UserID能确定一个UserLevel。这样,UserID依赖于StudentNo和CardNo,而UserLevel又依赖于UserID,这就导致了传递依赖,3NF就是消除这种依赖。

    第二种表设计满足第三范式,将第一种表格拆分成成两个表格。

     

    展开全文
  • 文章目录 什么是”范式(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,消除表中的多值依赖

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

    关于规范性性能

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

    千次阅读 2018-08-28 15:43:56
    数据库设计准则(第一、第二、第三范式说明) I、关系数据库设计范式介绍1.1 第一范式(1NF)无重复的列 所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的...
  • 所谓范式(NF),是数据库的设计规范,设计数据库时要满足这些规范,以使数据库能满足正常的创建,正常的操作(增删改查)以及数据...第三范式: 某个非主属性,若在其中一张表中已经出现过,则在其它表中就不应再出现...
  • 国内绝大多数院校用的王珊的《数据库系统概论》这本教材,某些方面并没有给出很详细很明确的解释,与实际应用联系不那么紧密,你有这样的疑问也是挺正常的。我教《数据库原理》这门课有几年了,有很多学生提出了和你...
  • 数据库第三范式的定义,是这样的:A table is in a third normal form when the following conditions are met -It is in second normal form.All nonprimary fields are dependent on the primary key.简单翻译过来...
  • 数据库中的范式 ...目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式...
  • 范式: 一个表中,每个【列的值是不能再分割的】. 例如:我们设计的表中有一个列是:爱好 这个列的值可能会是这样:足球篮球乒乓球 但是这值是可以再分割的:足球、篮球、乒乓球 所以这种设计是不满足范式 ...
  • 基础知识 实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸...在一个关系数据库中,它是一个操作原子,即关系数据库在做
  • 数据库中的范式,在数据库开发实际应用和面试中是常见的问题。 1、范式  英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪70年代提出关系数据库模型后总结出来的,范式是关系...
  • 数据库 数据库三范式

    2018-10-18 12:53:24
    数据库三范式 1.一范式(1NF)所谓一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。如果出现重复的属性,就可能需要...
  • 这两个范式之间容易搞混。但是看到订单表的例子后 ... 我自己总结出一点,希望可以说到点子上。。。...第二范式,就是防止...第三范式就是防止出现横向冗余,或者叫列冗余。意思是有多列的信息都应该放在其他表查询 ...
  • 所谓的范式就是数据库中的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性,如果出现重复的属性则需要重新构建实体,新的实体由重复的属性构成。...
  • 数据库设计三范式

    2021-05-16 17:53:16
    第三范式:建立在第二范式的基础之上,要求所有的非主键字段直接依赖主键,不要产生传递依赖。 (声明:三范式很重要,所有一定要熟记在心!) 设计数据库表的时候,按照以上的范式进行,可以避免表中数据的冗余,...
  • Normal Form前言在数据库设计的关系模式设计中,缺少范式,经常会使我们的表出现插入异常,删除异常,添加异常和代码冗余。范式的出现正是为了解决这一问题。这是范式作用的通俗解释。然后我们来看一下范式的定义:...
  • 数据库的第一范式、第二范式、第三范式,BCNF范式四大范式的基本概念名词解释范式优化实例一个特别糟糕的关系模式第一范式第二范式第三范式BCNF范式 此文章用于本人期末复习,适合对数据库范式分析还有一点记忆的...
  • 概述数据库三范式属于数据库设计过程中。设计一个新的数据库系统需要关注广泛的问题,对于一般的数据库设计来说,大体上是下面的步骤:数据库设计最初阶段需要完整刻画未来数据库用户的数据需求,为了完成这个任务...
  • 数据库三范式

    2019-10-30 09:48:10
    数据库的三范式 三范式是数据库的一种规范 第一范式 行不重复,列不可再分 第二范式 表必须符合第一范式 非主依主,非主键列必须依赖主键列 ...第三范式 非主独立,非主键列之间不能有依赖关系 ...
  • 范式 【定义】 如果一个关系模式R的所有属性都是不可分的基本数据项,则R∈1NF。简单的说,就是每一个列(属性),不能再分割成多个列(属性)。 【理解】 一范式较好理解,不过多阐述。就是简单地说,属性...
  • 数据库(第一范式,第二范式,第三范式
  • [数据库] 第一范式、第二范式、第三范式、BC范式

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

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 6,947
精华内容 2,778
关键字:

数据库第三范式