精华内容
下载资源
问答
  • 2020-08-06 10:25:33

    目录

    关系型数据库的范式

    一,第一范式

    1,描述

    2,例子

    二,第二范式

    1,描述   

    2,例子

    三,第三范式

    1,描述   

    2,例子

    四,BCNF范式

    1,描述   

    2,例子  

    五,第四范式

    1,描述

    2,例子

    六,第五范式

    1,描述

    2,例子

    七,完全函数依赖

    1,描述  

    2,例子   

    八,总结

    合理使用范式和反范式

    一,范式和反范式的优缺点

    二,案例

    1,社交软件的朋友圈社交软件的朋友圈的点赞,评论,转发数量。

    2,商城软件的订单信息查询


    关系型数据库的范式

          范式是关系型数据库的设计标准,范式分别有第一范式,第二范式,第三范式,BCNF范式(是在第三范式的补充和修订),第四范式和第五范式,

    一,第一范式

    1,描述

          数据库表中的字段都是单一属性的,不可再分。这个单一属性可以是数据库中任何一种基本数据类型。如整型,字符型,日期型等。只要是关系型数据库都会满足第一范式(列不可再分)。

    2,例子

    例如:一个产品信息表,描述产品信息的字段有产品编号,产品名称,产品数量,产品价格,产品描述。

    字段名

    数据类型

    产品编号

    整型

    产品名称

    字符型

    产品数量

    整型

    产品价格

    实型

    产品描述

    字符型

    二,第二范式

    1,描述   

         第二范式是在第一范式的基础上进一步对关系型数据库进行规范,数据库表汇总不存在非关键字段对任一后选关键字段的部分函数依赖。意思就是说在第二范式中组合主键(AB)里面的A或B与其他字段不能存在组合重复。常用的做法是单加一个逐渐ID列,不使用组合主键(不存在传递依赖)。

    如果不按照第二范式要求设计表,就会出现以下4个问题:

          1)数据冗余

          同一个产品由N个顾客购买,“产品类型”就重复N-1次;通一个顾客购买了多件产品,那么久会多次记录顾客的个人信息。

          2)更新异常

          若调整某个产品类型。数据表中所有行的“产品类型”值都要更新,否则会出现同一种产品不同类型的情况。

          3)插入异常

          假设新进一个产品,暂时还没有人购买。这样,由于没有人购买,产品的名称和类型也无法记录到数据库中。

          4)删除异常

          假设一批顾客把已经购买完的产品退货,这些产品信息就从数据库表中删除了。但是与此同时,产品名称和产品类型等信息也被删除了,这就导致了删除异常。

    2,例子

          为了消除数据冗余,更新异常,插入异常和删除异常,可以把现有的表拆分为3张表:

    购物信息表(客户编号,产品名称,产品数量,产品类型,产品价格,客户类型)

    客户编号

    客户类型

    产品名称

    产品数量

    产品类型

    产品价格

    客户1

    会员

    产品1

    1

    零食

    11

    客户1

    会员

    产品2

    2

    粮油

    12

    客户1

    会员

    产品3

    3

    水果

    13

    客户2

    非会员

    产品1

    1

    零食

    11

    客户2

    非会员

    产品2

    2

    粮油

    12

    客户2

    非会员

    产品3

    3

    水果

    13

    把购物信息表分解为三个表:

    产品类型表(产品类型,产品名称)

    客户信息表(客户编号,客户类型)

    产品信息表(产品名称,产品类型,产品价格,产品数量)

    产品类型表:产品类型,产品名称。

    产品类型

    产品名称

    零食

    产品1

    粮油

    产品2

    水果

    产品3

    客户信息表:客户编号,客户类型。

    客户编号

    客户类型

    客户1

    会员

    客户2

    非会员

    产品信息表:产品名称,产品类型,产品价格,产品数量。

    产品名称

    产品类型

    产品价格

    产品数量

    产品1

    零食

    11

    1

    产品2

    粮油

    12

    2

    产品3

    水果

    13

    3

    三,第三范式

    1,描述   

          第三范式是在第二范式的基础上对数据库设计进行规范,要求是数据表中不存在非关键字段对任一后选关键字段的传递函数依赖。所谓传递函数依赖,指的是如果存在A决定B,B决定C的决定关系,则C传递函数依赖于A(表中其他列值必须唯一依赖于主键)。

    2,例子

          因此,满足第三范式的数据库表应该不存在依赖关系,假定员工信息表(员工编号,姓名,年龄,所在部门,部门电话),使用员工编号作为管用信息的主键,那么久存在决定关系,员工编号就决定了姓名,年龄,所在部门,部门电话这些字段。

    员工信息表(员工编号,姓名,年龄,所在部门,部门电话)

    员工编号

    姓名

    年龄

    所在部门

    部门电话

    员工1

    员工1

    1

    部门1

    电话1

    员工2

    员工2

    2

    部门2

    电话2

          从上面关系可以看出,在表中有一个主键,数据表的设计符合第二范式,但不符合第三范式的要求,因为存在决定关系;员工编号就决定了所在部门,所在部门又决定了所在部门的电话;那么久存在了传递函数依赖关系,即员工编号决定部门电话,那么也会出现不满足第二范式时的数据冗余和更新,插入,删除异常的情况,为了满足第三范式的要求,必须把员工信息表插入分成如下两个数据表;

    员工表(员工编号,姓名,年龄,所在部门)

    员工编号

    姓名

    年龄

    所在部门

    员工1

    员工1

    1

    部门1

    员工2

    员工2

    2

    部门2

    部门表(部门名称,部门电话)

    部门名称

    部门电话

    部门1

    电话1

    部门2

    电话2


     

    四,BCNF范式

    1,描述   

          除了上面三种范式以外,还有一种经常使用的鲍依斯-科得范式(BCNF)。

    它说明,建立在第三范式的基础上,如果数据库表中不存在任何字段对任一后选关键字点的传递函数依赖,那么就符合BCNF范式,BCNF的条件有:

          1)所有非主属性对每一个候选键都是完全函数依赖;

          2)所有主属性对每一个不包含它的候选键,也是完全函数依赖;

          3)没有任何属性完全函数依赖于非候选键的任何一组属性。

    解决第三范式的问题:数据冗余度大;插入操作复杂;删除操作复杂;修改操作复杂。

    2,例子  

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

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

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

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

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

    仓库管理关系表(仓库ID,存储物品ID,管理员ID,数量)

    仓库ID

    存储物品ID

    管理员ID

    数量

    仓库A

    物品A

    管理员A

    1

    仓库A

    物品B

    管理员A

    2

    仓库B

    物品A

    管理员B

    1

    仓库B

    物品B

    管理员B

    2

    把仓库管理关系表分解为二个关系表:

    仓库管理表:(仓库ID,管理员ID);

    仓库表:(仓库ID,存储物品ID,数量)。

    仓库管理表:(仓库ID,管理员ID);

    仓库ID

    管理员ID

    仓库A

    管理员A

    仓库B

    管理员B

    仓库表:(仓库ID,存储物品ID,数量)。

    仓库ID

    存储物品ID

    数量

    仓库A

    物品A

    1

    仓库A

    物品B

    2

    仓库B

    物品A

    1

    仓库B

    物品B

    2

    五,第四范式

    1,描述

          设关系R(X,Y,Z),其中X,Y,Z是成对的、不相交属性的集合。

    符合第三范式和BCNF之后,消去其中不是函数依赖的非平多值依赖。就是多对多

    2,例子

    一个用户有多个表空间,多个表

    用户资源表1(用户名,表空间,表名称)

    用户名

    表空间

    表名称

    Sys

    tablespace1

    table1

    Sys

    tablespace1

    table2

    用户资源表2(用户名,名称,种类)

    用户名

    名称

    种类

    Sys

    table1

    table

    Sys

    table1

    table

    Sys

    tablespace1  

    tablespace

    Sys

    tablespace1  

    tablespace

    六,第五范式

    1,描述

          消除了第四范式中的连接依赖。

    2,例子

          我们在上述例子上进行修改,分成表空间的表和用户拥有表的表,我们可以回想一下,oracle貌似就是这么做的。

    表空间的表(用户名,表空间)

    用户名

    表空间

    Sys

    tablespace1

    Sys

    tablespace2

    用户拥有表(用户名,表名称)

    用户名

    表名称

    Sys

    table1

    Sys

    table2

    七,完全函数依赖

    1,描述  

          完全函数依赖:在一个关系中,若某个非主属性数据项依赖于全部关键字称之为完全函数依赖。如果非主属性B函数依赖于构成某个候选关键字的一组主属性A,而且A的任何一个真子集不能被B函数依赖,则称B完全函数依赖于A;反之,若B函数能依赖于A的真子集,则称B部分函数依赖于A。

    2,例子   

    成绩表(学号,课程号,成绩)关系中,

    完全函数依赖:(学号,课程号)→ 成绩,学号 -\→ 成绩,课程号 -\→ 成绩,所以(学号,课程号)→ 成绩 是完全函数依赖

    八,总结

         不能说规范化程度越高的关系模式就越好,在设计数据库模式结构时,必须对现实世界的实际情况和用户需求做进一步分析,确定一个合适的、能够反映现实世界的模式。范式就是在数据库表设计时移除数据冗余的过程。随着范式级别的提升,数据冗余越来越少,但数据库的效率也越来越低。一般情况下,数据库设计满足第三范式即可。上面的规范化步骤可以在其中任何一步终止。规范化的过程可概括如下:

    (1)取原始的1NF关系投影,消去非主属性对键的部门函数依赖,从而产生一组2NF关系。

    (2)取2NF关系的投影,消去非主属性对键的传递函数依赖,产生一组3NF关系。

    (3)取这些3NF的投影,消去决定因素不是键的函数依赖。产生一组BCNF关系。

    (4)取这些BCNF关系的投影,消去其中不是函数依赖的非平多值依赖,产生一组4NF关系。

    (5)取这些4NF的投影,消除了4NF中的连接依赖,产生一组5NF关系。

    合理使用范式和反范式

    范式的目的是为了减少数据冗余,但实际做开发中,往往需要部分数据冗余来提高我们的检索(索引,排序)的效率,所以需要混合使用来满足我们的实际开发,约定大于规范,空间换时间。

    一,范式和反范式的优缺点

    范式和反范式的优缺点
    优点缺点
    范式   

    1,更新通常比反范式更快;

    2,当数据较好的范式化后,很少或者么有重复数据;

    3,范式化的数据比较小,可以放在内存中,操作比较快。

    通常需要进行关联
    反范式

    1,所有数据都在同一张表中,可以避免关联;

    2,可以设计有效的索引;

    表格内的冗余较多,删除数据时会造成表有些有用信息丢失

    二,案例

    1,社交软件的朋友圈社交软件的朋友圈的点赞,评论,转发数量。

    可以在主表加对应的 num1,num2,num3分别表示点赞,评论,转发的数量。在相应的操作后可以用触发器对对应的数量字段进行更新,就避免了多表count。

    范式设计

    动态表          动态ID     用户ID       动态内容  
    
    点赞表          点赞ID     动态ID       用户ID
    
    评论表          评论ID     评论内容     动态ID      用户ID
    
    
    SELECT   
    
    dt.用户ID , dt.动态内容 ,  dz.点赞数量 , pl.评论数量
    
    FROM    ‘动态表’  dt   
    
    LEFT JOIN 
    (SELECT   动态ID , count(动态ID) 点赞数量 FROM '点赞表' GROUP BY 动态ID) dz 
    ON dt.动态ID  =  dz.动态ID
    
    LEFT JOIN 
    (SELECT   动态ID , count(动态ID) 评论数量 FROM '评论表' GROUP BY 动态ID) pl   
    ON  pl.动态ID =  dz.动态ID

    反范式设计

    动态表       动态ID     用户ID        动态内容     点赞数量   评论数量
    
    点赞表       点赞ID     动态ID        用户ID
       
    评论表       评论ID     评论内容      动态ID       用户ID
    
    
    SELECT   
    
    dt.用户ID , dt.动态内容 ,  dt.点赞数量 , dt.评论数量
    
    FROM    ‘动态表’  dt   

    2,商城软件的订单信息查询

    范式设计

    用户信息表         用户ID      姓名     电话       地址       年龄
    
    订单表             订单ID      用户ID   下单时间   支付类型   订单状态
    
    订单详情表         订单详情ID  商品ID   数量       价格
    
    商品表             商品ID      商品名称   
    
    
    
    SELECT    
    
    user.用户名称 , user.地址 , user.电话 , dd.订单ID , SUM(sp.价格  *  sp.商品数量)订单价格
    
    FROM   '订单表 '  dd
    
    JOIN  '用户信息表'  user  ON dd.用户ID = user.用户ID
    
    JOIN  '订单商品表'  sp ON sp . 订单ID = dd. 订单ID
    
    GROUP BY   user .用户名,user.电话,user.地址,dd.订单ID

    反范式设计

    用户信息表   用户ID  姓名    电话   地址  年龄
    
    订单表       订单ID  用户ID  姓名   地址  电话  下单时间  订单价格  支付类型 订单状态  
    
    订单详情表   详情ID  商品ID  数量   价格
    
    商品表       商品ID  商品名称   
    
    
    
    SELECT   
      
    dd.用户名称 , dd.地址 , dd.电话 , dd.订单ID , dd.订单价格
    
    FROM   '订单表 '  dd

    更多相关内容
  • 数据库四大范式判断

    千次阅读 2022-02-25 11:51:40
    1NF,2NF,3NF,BCNF范式判断方法 判断方法如下图所示,关键是找出候选键和非键属性(下面会详细介绍)。 部分依赖: AB->C B->C;即C部分依赖AB 传递依赖:C传递依赖于A 一、求出候选键和非键 候选键定义:若...

    1NF,2NF,3NF,BCNF范式判断方法

    判断方法如下图所示,关键是找出候选键和非键属性(下面会详细介绍)。
    在这里插入图片描述

    部分依赖:

    AB->C  B->C;即C部分依赖AB
    

    传递依赖:C传递依赖于A
    在这里插入图片描述

    一、求出候选键和非键

    候选键定义:若关系中的某一属性组的值能唯一地标识一个元组,则称该属性组为候选键。候选键的闭包为U。
    求出候选键步骤:
    (1)找出只在左边出现的项(如果没有跳到步骤2)并判断是否能导出所有项。如果可以则这个项为候选键不进行步骤(2)。
    (2)找出在左右两边都出现的项与(1)找出的项组合并判断是否能导出所有项,能导出所有项的成为候选键。
    非键属性:不包含在候选键中的属性为非主属性。
    注意:候选键不唯一

    **例子**:F={B->D,D->B,AB->C} 
    步骤1:找出A,A无法导出所有项所以进行步骤2
    步骤2:找出B,D与A组合成AB,AD。因AB,AD能导出所有项,即AB,AD为候选键。
    C为非键属性
    
    **例子**:F={A->B,B->C}
    步骤1:找出A,A能导出所有项即A为候选键。
    

    二、例题

    1.F={B->D,D->B,AB->C}

    1°:候选键为AB和AD,非键为C;
    2°:C完全依赖于AB符合2NF;
    3°:C不具备传递依赖候选键符合3NF;
    4°:依赖项的左边不全是候选键,即最高范式为3NF;

    2.F={A->B,B->A,A->C}

    1°:候选键为A和B,非键为C;
    2°:C完全依赖于A符合2NF;
    3°:C不具备传递依赖候选键符合3NF;
    4°:依赖项的左边全是候选键,即最高范式为BCNF;

    展开全文
  • 数据库三大范式详解

    千次阅读 多人点赞 2021-06-01 09:58:52
    文章目录数据库三大范式一、范式的定义二、第一范式 (1NF)1. 关系和关系模式的概念2. 第一范式的概念3. 第一范式存在的问题三、第二范式 (2NF)1. 理解几个概念1.1 函数依赖1.2 完全函数依赖1.3 部分函数依赖1.4 传递...

    数据库三大范式

    一、范式的定义

    • 设计数据库表时所要遵循的某种规范的级别
    • 比如家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等
    • 数据库范式也分为1NF,2NF,3NF,BCNF,4NF,5NF,一般在设计关系型数据库的时候,最多考虑到BCNF足够,为了性能上或者应对扩展的需要,达到1NF或者2NF即可
    • 符合高一级范式的设计,必定符合低一级范式,如符合2NF的关系模式,必定符合1NF

    二、第一范式 (1NF)

    1. 关系和关系模式的概念

    • 关系可以理解为一张带数据的
    • 关系模式是这张数据表的表结构
    • 二者的关系类似于面向对象程序设计中”类“与”对象“的区别,”关系“是”关系模式“的一个实例

    2. 第一范式的概念

    • 1NF的定义为:符合1NF的关系中的每个属性都不可再分

      • 通俗的理解为,数据库表的每一列都是不可再分的原子列,如下图所示就不符合1NF的要求

        image-20210420095902085
    • 1NF是所有关系型数据库的最基本要求

      • 也就是说,只要在关系型数据库中已经存在的数据表,一定是符合1NF的,如下图所示就符合1NF的要求

        image-20210420100036069

    3. 第一范式存在的问题

    以下面这张stu表来说明存在的问题

    image-20210420100612290
    • 数据冗余过大

      • 每一名学生的学号、姓名、系名、系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次
    • 插入异常

      • 假如学校新建了一个系,但是暂时还没有招收任何学生,那么添加数据时,会将系名与系主任的数据单独地添加到数据表中,而没有添加学生列的数据,数据添加不合法
    • 删除异常

      • 删除时会将整行的数据删除,假如将某个系中所有学生相关的记录都删除,那么所有系与系主任的数据也就随之消失了(一个系所有学生都没有了,并不表示这个系就没有了)
    • 修改异常

      • 假如李勇转系到法律系,那么为了保证数据库中数据的一致性,需要修改三条记录中系与系主任的数据

    三、第二范式 (2NF)

    1. 理解几个概念

    1.1 函数依赖

    • 类似于函数关系 y = f(x),在x确定的情况下,y一定是确定且唯一的,此时称为y函数依赖于x
    • 对应到数据库中,函数依赖指的是若在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y
    • 对应到上图的stu表中,可以说姓名函数依赖于学号,写作 学号 → 姓名。但是反过来,因为可能出现同名的学生,所以有可能不同的两条学生记录它们在姓名上的值相同,但对应的学号不同,所以不能说学号函数依赖于姓名

    1.2 完全函数依赖

    • 写法为 X F→ Y,Y的确定需要依赖于X属性组中的所有值

      image-20210420155006206
    • 对应到上图的stu表中,完全函数依赖如下所示:

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

    1.3 部分函数依赖

    • 写法为 X P→ Y,Y的确定需要依赖于X属性组中的某些值

      image-20210420155021850
    • 对应到上图的stu表中,部分函数依赖如下所示:

      • (学号,课名) P→ 姓名

    1.4 传递函数依赖

    • 如果X→Y,Y→Z,则称Z传递函数依赖于X,写法为 X T→ Z

      image-20210420155633303
    • 举一个传递函数依赖的例子:

      • 系号→系名,系名→系主任,则系主任 T → 系号

    1.5 码

    • 设 K 为某表中的一个属性或属性组,若除 K 之外的所有属性都完全函数依赖于 K,则称 K 为候选码,简称为
      • 通俗的可以理解为,假如当 K 确定的情况下,该表除 K 之外的所有属性的值也就随之确定,那么 K 就是码
    • 一张表中可以有多个码,实际应用中为了方便,通常选择其中的一个码作为主码
    • 对应到上图所示的stu表中,(学号、课名)这个属性组就是码

    1.6 主属性

    • 包含在任意一个码中的属性称为主属性
    • 对应到上图所示的stu表中,主属性只有两个,学号课名

    1.7 非主属性

    • 不包含在任何一个码中的属性称为非主属性
    • 对应到上图所示的stu表中,除 学号课名 之外,其余的属性都是非主属性

    2. 第二范式的概念

    • 2NF在1NF的基础上,消除了非主属性对于码的部分函数依赖

    • 判断是否满足第二范式的步骤如下:

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

      • 假如A是码,那么所有包含了A的属性组,如(A,B)、(A,C)、(A,B,C)等等,都不是码了
      • 原因是作为码的要求里有一个“完全函数依赖”,其他属性仅依赖A就可以确定值了,没必要依赖B或C等,不满足完全函数依赖
    • 对应到上图所示的stu表中,判断过程如下:

      • 第一步,确定了表中的为(学号、课名),且只有这一个码

      • 第二步,确定了主属性为学号课名

      • 第三步,确定了非主属性有四个:姓名系名系主任分数

      • 第四步

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

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

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

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

    3. 1NF转换为2NF的方式

    • 将1NF转换为2NF只有一个办法,就是将大数据表拆分成两个或者更多个更小的数据表,这个过程叫做模式分解

    • 模式分解的方法不是唯一的,对于上图的stu表采用一种模式分解方法如下:

      • 将stu表分成选课表学生表

        • 选课(学号,课名,分数)
        • 学生(学号,姓名,系名,系主任)
      • 选课表和学生表如下图所示:

        image-20210420164121463 image-20210420164137220
    • 判断选课表是否满足2NF的要求

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

      • 对于学生表,其码是学号,主属性是学号,非主属性是姓名、系名系主任
      • 因为码只有一个属性,所以不可能存在非主属性对于的部分函数依赖,所以此表符合2NF的要求

    4. 第二范式存在的问题

    • 观察改进后满足第二范式的stu表是否还存在第一范式的问题:
      • 李勇转系到法律系
        只需要修改一次李勇对应的系的值即可。——有改进
      • 数据冗余是否减少了?
        学生的姓名、系名与系主任,不再像之前一样重复那么多次了。——有改进
      • 删除某个系中所有的学生记录
        该系的信息仍然全部丢失。——无改进
      • 插入一条暂无学生的新系的记录
        因为学生表的码是学号,不能为空,所以此操作不被允许。——无改进
    • 所以说,仅仅符合2NF的要求,很多情况下还是不够的,而出现问题的原因在于仍然存在非主属性系主任对于学号的传递函数依赖

    四、第三范式 (3NF)

    1. 第三范式的概念

    • 3NF在2NF的基础之上,消除了非主属性对码的传递函数依赖
      • 通俗的理解为,如果存在非主属性对码的传递函数依赖,则不符合3NF的要求
    • 判断学生表是否符合3NF的要求
      • 对于选课表,主码为(学号,课名),主属性为学号课名,非主属性只有一个,为分数,不可能存在传递函数依赖,所以选课表的设计符合3NF的要求
    • 判断选课表是否符合3NF的要求
      • 对于学生表,主码为学号,主属性为学号,非主属性为姓名系名系主任。因为 学号 → 系名,同时 系名 → 系主任,所以存在非主属性系主任对于码学号的传递函数依赖,所以学生表的设计不符合3NF的要求

    2. 2NF转换为3NF的方式

    • 为了让数据表满足3NF的要求,必须进一步进行模式分解为以下形式:

      • 选课(学号,课名,分数)
      • 学生(学号,姓名,系名)
      • 系(系名,系主任)
    • 新的数据库表如下图所示:

      image-20210420165601135 image-20210420165608828 image-20210420165618411
    • 对于选课表,符合3NF的要求,之前已经分析过了

    • 对于学生表,码为学号,主属性为学号,非主属性为系名,不可能存在非主属性对于码的传递函数依赖,所以符合3NF的要求

    • 对于表,码为系名,主属性为系名,非主属性为系主任,不可能存在非主属性对于码的传递函数依赖(至少要有三个属性才可能存在传递函数依赖关系),所以符合3NF的要求

    3. 第三范式的优势

    • 判断3NF是否存在2NF存在的问题

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

      • 符合3NF要求的数据库设计,基本上解决了数据冗余过大,插入异常,修改异常,删除异常的问题
    展开全文
  • 数据库范式概念以及范式分解详解

    千次阅读 2021-01-03 15:50:49
    ) 三范式分解为保持函数依赖的分解 步骤如下: 例题: 设R,其中: U={C, T, H, R, S, G, X, Y, Z}, F={C→T, CS→G, HR→C,HS→ R, TH→ R, C→X}, ​ 将R 分解为3NF,且保持函数依赖。 解: 求F的最小函数依赖集...
    1. 几个重要知识点

      • 平凡函数依赖与非平凡函数依赖

        • X→Y,但Y⊈X则称X→Y是非平凡的函数依赖。
        • X→Y,但Y⊆X 则称X→Y是平凡的函数依赖。
      • 完全函数依赖与部分函数依赖

        在R(U)中,

        • 如果X→Y,并且对于X的任何一个真子集X’, 都有 X’ ↛ Y, 则称Y对X完全函数依赖,记作X → Y。
        • 若X→Y,但Y不完全函数依赖于X,则称Y对X部分函数依赖,记作X → Y
      • 候选码

        设K为R<U,F>中的属性或属性组合。若K → U,则K称为R的一个候选码(Candidate Key)。

        千万需要记住的是候选码与超码之间的区别

      • 超码

        如果U部分函数依赖于K,即K → U,则K称为超码(Surpkey)。

        候选码是最小的超码,即K的任意一个真子集都不是候选码。

      • 主码

        主码是候选码中的任意一个

      • 主属性与非主属性

        • 包含在任何一个候选码中的属性 ,称为主属性(Prime attribute)
        • 不包含在任何码中的属性称为非主属性(Nonprime attribute)或非码属性(Non-key attribute)
      • 全码

        整个属性组是码,称为全码(All-key)

    2. 范式

      • 第一范式

        每个属性不可分割

      • 第二范式

        若关系模式R∈1NF,并且每一个非主属性完全函数依赖于任何一个候选码,则R∈2NF

      • 第三范式

        消除非主属性对于码的传递依赖
        若R中不存在这样的码X、属性组Y及非主属性Z(Z ⊇ Y), 使得X→Y,Y→Z成立,Y ↛ X不成立,则称R<U,F> ∈ 3NF。

        三范式分解

      • BC范式

        消除主属性对码的部分和传递函数依赖

        判断:在关系模式R<U,F>中,如果每一个决定属性集都包含候选码,则R∈BCNF。

      1. 无损连接与保持函数依赖性

        • 无损连接

      在这里插入图片描述

      无损连接判断

      • 保持函数依赖性

      在这里插入图片描述

      一个无损连接的分解不一定具有依赖保持性,反之亦然 !

      1. 三范式分解(范式分解最终的答案并非是唯一的,和分解的顺序有关!)

        • 三范式分解为保持函数依赖的分解

          步骤如下:

        在这里插入图片描述

        例题:

        设R<U, F>,其中:
        U={C, T, H, R, S, G, X, Y, Z},
        F={C→T, CS→G, HR→C,HS→ R, TH→ R, C→X},

        ​ 将R 分解为3NF,且保持函数依赖。

        解:

        1. 求F的最小函数依赖集

          该函数依赖集已经是最小化的

          1. 查看是否有一个函数依赖X->A,且XA=R。

          可以很清楚的看到,并没有这种函数依赖。

        2. 查看R中的某些属性是否并不在F中出现过

          可以很清楚的看到有YZ

        3. 将最小函数依赖集中的每一个依赖左右两边放到一起

          则分解为ρ ={YZ, CTX, CSG, HRC, HSR, THR}
          注:这里的CTX放到一起时因为C → \rightarrow T,C → \rightarrow X

        • 三范式分解既具有无损连接性又能保持函数依赖的分解

          非常简单!在原来的基础上加上候选码中的任意一个即可。

          例如此题中的候选码为HS

          那么在原来的ρ中添加HS即可,但是此处需要注意

          ∵ HS⊆ HSR
          ∴ τ= ρ ={CTX, CSG, HRC, HSR, THR, YZ}为满足要求的分解

      2. BCNF分解(范式分解最终的答案并非是唯一的,和分解的顺序有关!)

        • 如何判定BCNF范式呢?

          很简单!就是看每个函数依赖的左边是否包含候选码,如果其中有一个不含候选码,则不为BCNF范式。

        • 将关系模式转换为BCNF 的无损连接的分解

          ​ 递归下去,直到出现 Φ \Phi Φ或者出现最终的一个依赖符合BCNF约束则停止分解

          ​ 例子1:
          ​ 已知 R (A, B, C), AB为码, 且B->C存在
          ​ 可知:R不满足BCNF
          ​ 设 α \alpha α = B, β \beta β = C
          ​ 则 R 可分解为:
          ​ ( α \alpha α ⋃ \bigcup β \beta β) = (B, C)
          ​ (R – ( β \beta β − - α \alpha α)) = (A, B)

          ​ 例子2:
          在这里插入图片描述

    展开全文
  • 数据库4范式

    2022-03-14 15:55:54
    示例:pandas 是基于NumPy 的一种工具,该工具是为了解决数据分析任务而创建的。 二、使用步骤 1.引入库 代码如下(示例): import numpy as np import pandas as pd import matplotlib.pyplot as plt import ...
  • 数据库设计的三范式超详细详解

    千次阅读 2021-02-20 12:04:42
    目录 写在前面 第一范式(1NF):原子性(存储的数据应该具有“不可再分性”) 第二范式(2NF):唯一性...范式,就是规范,就是指设计数据库需要(应该)遵循的原则。 每个范式,都是用来规定某种结构或数据要求—
  • 前置:数据库表之间的关联关系 1.一对一的关系:学生和身份证是一一对应的 可以在任意一方添加 “唯一” 外键指向另一方主键 2.一对多的关系:一个部门...正文:数据库范式 据百度原文:目前关系数据库有六种...
  • 数据库——范式判断类 题型、解题的套路、步骤

    千次阅读 多人点赞 2019-12-31 21:46:14
    关系数据库中的关系是要满足一定要求的,满足不同程度要求的为不同范式; 什么是规范化? 一个低一级范式关系模式通过模式分解,可以转换为若干个高一级的范式的关系模式的集合,这个过程就叫做规范化; 什么...
  • 数据库——范式判断实例

    千次阅读 多人点赞 2020-01-03 14:46:03
    看了上篇CSDN的小伙伴们,这篇我们来具体做几个题目练习一下 明确俩个概念: ⑴ 平凡函数依赖: 当关系中属性集合Y是属性集合X的子集时,存在函数依赖X–>... 因为在做范式判断题的时候,往往在第一问当你...
  • 数据库范式的理解

    2018-09-05 16:58:46
    规范化是一些步骤的序列,通过这些步骤创建和改进关系数据库模型,规范化过程中的步骤序列称为范式。 为什么要规范化 ? 规范化可简化复杂的数据建模过程 第一范式概念: 如果一个关系模式R的所有属性都是不可分...
  • 数据库入门(一)范式理解:1NF,2NF,3NF,BCNF,4NF详析引言范式种类第一范式(1NF)符合1NF的关系中的每个属性都不可再分存在问题第二范式(2NF)在1NF基础上消除了非主属性对码的部分函数依赖二范式判断步骤优缺点第...
  • 数据库原理之范式判断

    千次阅读 2020-04-06 19:30:43
    判断范式步骤: 如何确定候选键 判断3NF有两个条件,例如:X为主属性,Z为非主属性,有X→Y,Y→Z,Y→X, 则第一个条件X→Y,Y→Z满足,第二个条件Y不能推出X,不满足,所以不满足3NF。 也就是说满足X→Y,Y→Z且Y...
  • 数据库设计的主要步骤是什么发布时间:2020-08-12 10:00:24来源:亿速云阅读:141作者:小新这篇文章给大家分享的是有关数据库设计的主要步骤是什么的内容。小编觉得挺实用的,因此分享给大家做个参考。一起跟随小编...
  • 数据库设计三大范式

    万次阅读 多人点赞 2019-02-26 22:51:35
    除了数据库设计三大范式之外,事务处理也是保证数据完整性的重要手段。事务是单独的工作单元,该单元可以包含多个操作以完成一个完整的任务。锁是在多用户环境中对数据访问的限制。事务和锁确保了数据的完整性。 ...
  • 数据库BC范式(BCNF)判断和分解

    万次阅读 多人点赞 2020-05-13 12:33:49
    那么关系模式 dep(D,M,G,N)中D表示仓库名,M表示管理员,G表示货物名,N表示货物的数量 已知函数依赖集:D → M,M → D,(D,G)→ N 将其分为BC范式: 主属性:D,M,G 候选码:(D,G),(M,G) D → M...
  • 文章目录范式判断的步骤第一步第二步...根据1NF、2NF、3NF、BCNF的定义判断范式属于哪一个类型 1NF>每一个元素不可分割 2NF>消除非主属性对候选码的部分依赖:假设BC是候选码,现在有一个非主属性D,如果存在B–&
  • 数据库的ACID和三范式

    2019-10-28 10:49:32
    第二范式依赖第一范式,所以第二范式必须符合第一,然后第二范式需要确保数据库表中的每一列都和主键相关 3NF: 在第二范式的基础上更进一层,目标是确保每列都和主键列直接相关,而不是间接相关(另外非主键列必须直接...
  • 数据库范式是数据库设计中必不可少的知识,没有对范式的理解,就无法设计出高效率、优雅的数据库。甚至设计出错误的数据库。而想要理解并掌握范式却并不是那 么容易。教科书中一般以关系代数的方法来解释数据库范式...
  • 1、SQL Server数据库是小型关系数据库管理系统(DBMS) 2、关系就是二维表,属性就是字段 3、数据完整性: 实体完整性(必须有主键,唯一性和不能为空), 参照完整性(外键必须与主表中的主键一致,外键值...
  • 数据库设计范式

    2019-03-16 10:19:14
    对于数据库分析方法,常见的就是数据库范式设计 所有的设计范式,都是作为一种参考,在初期可以根据范式进行设计,但之后几乎所有的范式都被打破 我们在数据库设计的时候,根据业务的需要尽可能的减少多表复杂...
  • 1.需求分析:全面了解产品设计的存储需求 存储需求:数据库需要存储什么样的数据,数据具有什么样特点 数据处理需求:我们需要如何对数据库进行读取或修改以完成产品设计的功能,已经对数据处理的响应时间有什么...
  • 数据库设计的一般步骤

    万次阅读 多人点赞 2019-06-13 20:03:58
    数据库的设计按照以下步骤: (1)了解功能需求 在设计数据库之前,设计人员必须要先了解系统的功能需求。这里可以通过阅读产品需求规格说明书,与项目相关人员(比如项目经理、客户等)进行充分沟通。 (2)定义...
  • (1)需求分析阶段:需求收集和分析,得到数据字典和数据流图。 (2)概念结构设计阶段:对用户需求综合、归纳与抽象,形成概念模型,用E-R图表示。 (3)逻辑结构设计阶段:将概念结构转换为某个DBMS所...
  • 数据库——判断范式的方法及转换 给定关系模式和FD集,判断关系模式所属范式的解题步骤: 1.求候选码(请看上一章内容),确定主属性和非主属性(包含在候选码中的属性是主属性,不包含其中的属性是非主属性); 2....
  • 数据库范式(如何拆分符合第三范式的表)

    千次阅读 多人点赞 2020-10-24 14:52:42
    文章目录数据库范式(如何拆分3NF的表)分类第一范式概念第一范式存在的问题第二范式几个概念1.函数依赖2.完全函数依赖3.部分函数依赖4.传递函数依赖5.码创建符合2NF的表第二范式存在的问题第三范式总结(个人理解)...
  • 版权声明:本文转自小小...第一范式 定义以及分析: 问题研究: 第二范式 必备知识点 定义 分析: 解决办法: 问题研究: 第三范式: 定义: 分析: 问题分析: BCNF范式 分析 问题研究 小结: 参考文献 ...
  • 数据库范式

    千次阅读 2015-11-26 16:33:30
    第一范式( 1NF ):属性不可分; 第二范式(2NF):符合1NF,并且,非主属性完全依赖于主键,而不是依赖于部分主键属性; 第三范式(3NF):符合2NF,并且,消除传递依赖; BC范式(BCNF):符合3NF,并且,主属性...
  • 数据库范式属于数据库设计过程中。设计一个新的数据库系统需要关注广泛的问题,对于一般的数据库设计来说,大体上是下面的步骤数据库设计最初阶段需要完整刻画未来数据库用户的数据需求,为了完成这个任务...
  • 数据库范式是数据库设计中必不可少的知识,没有对范式的理解,就无法设计出高效率、优雅的数据库。甚至设计出错误的数据库。而想要理解并掌握范式却并不是那 么容易。教科书中一般以关系代数的方法来解释数据库范式...
  • 1、数据库设计的基本步骤

    千次阅读 2020-10-08 12:03:40
    本节主要介绍数据库设计的基本步骤。 在了解数据库设计步骤之前,我们先来了解一下软件项目的开发周期,如下: 需求分析 概要设计 逻辑设计/详细设计 代码编写 软件测试 安装部署 其中,项目开始的第一步都是根据...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 21,221
精华内容 8,488
关键字:

数据库分析范式类型步骤