精华内容
下载资源
问答
  • 2022-04-01 12:50:34

    目录

    概述

    巴斯范式

    1.案例

    2.是否符合三范式

    3.存在的问题

    4.问题解决

    第四范式(了解即可)

    第五范式、域键范式(了解即可)

    小结


    概述

    之前我们讲过数据库设计范式的第一范式,第二范式以及第三范式,以及还说了在实际业务需求中如何使用反范式优化我们的查询。这篇文章我们来谈一下巴斯范式以及第四范式和第五范式。

    巴斯范式

    人们在三范式的基础上进行了改进,提出巴斯范式,也叫做巴斯-科德范式。巴斯范式被认为没有新的设计加入,仅仅是对第三范式中的设计规范要求更强,使得数据库冗余度更小。所以,称为是修正的第三范式或扩充的第三范式,不被称为第四范式。

    若一个关系达到第三范式,并且它只有一个候选键或者它的每个候选键都是单属性,则该关系自然就达到巴斯范式。

    1.案例

    我们分析如下表的范式情况:

     在这个表中,一个仓库只有一个管理员,同时一个管理员也只是管理一个仓库,我们先来梳理下这些属性之间的依赖关系。

    仓库名决定了管理员,管理员也决定了仓库名,同时(仓库名,物品名)的属性集合可以决定数量这个属性。这样我们可以找到数据表的候选键了。

    候选键:是(管理员,物品名)和(仓库名,物品名),然后我们从候选键选择一个作为主键,比如(仓库名,物品名)。

    主属性:包含在任一候选键中的属性,也就是仓库名,管理员和物品名

    非主属性:数量这个属性

    2.是否符合三范式

    如何判断一张表的范式呢?我们需要根据范式的等级,从低到高来进行判断。

    首先,数据表每个属性都是原子性的,符合第一范式要求。

    其次,数据表中的非主属性 数量这个字段都与候选键全部依赖。因此符合第二范式。

    最后,数据表中的非主属性不传递依赖于候选键,符合第三范式。

    3.存在的问题

    既然数据表已经符合了三范式要求,是不是就不存在问题了呢?我们来看下面的情况:

    1.增加一个仓库,但是还没有存放任何物品。根据数据表实体完整性约束主键不能有空值,因此会插入异常。

    2.如果仓库更换了管理员,我们可能会修改数据表中的多条记录。

    3.如果仓库管理的商品被卖空了,那么此时仓库名称和对应的管理员名称也会随之被删除。

    4.问题解决

    首先我们需要确认造成异常的原因:主属性仓库名对于候选键(管理员,物品名)是部分依赖关系,这样就有可能导致上面的异常情况。因此引入巴斯范式,它在三范式基础上清除了主属性对候选键的部分依赖或者传递依赖关系。

    如果在关系R中,U作为主键,A属性是主键的一个属性,若存在A->Y,Y为主属性,则该关系不属于巴斯范式。

    根据巴斯范式的要求,我们需要把仓库管理关系表拆成如下:

     这样就不存在主属性对候选键而部分依赖,上面的表就符合巴斯范式。

    第四范式(了解即可)

    多值依赖关系的概念:

    • 多值依赖,即属性之间的一对多关系,即为k→→A。
    • 函数依赖,事实上是单质依赖,所以不能表达属性之间的一对多关系。
    • 平凡的多值依赖,全集U=K+A,一个K可以对应于多个A,也可以对应于多个B,A与B互相独立,即K→→A,K→→B。整个表有多组一对多关系,且有:一部分是相同的属性集合,多部分是相互独立属性集合。

    第四范式即在满足巴斯范式基础上,消除非平凡函数依赖的多值依赖,即把同一表内的多对多关系删除。

    第五范式、域键范式(了解即可)

    除了第四范式我们还有更高级的第五范式和域键范式

    在满足第四范式的基础上消除不是由候选键索蕴含的连续依赖。如果关系模式R中每一个连接依赖均由R的候选键蕴含 则称此关系模式符合第五范式。

    函数依赖是多值依赖的一种特殊情况,而多值依赖实际上是连接依赖的一种特殊情况。但连接依赖不像是函数依赖和多值依赖可以由语义直接导出,而是在关系连接运算时才反映出来。存在连接依赖关系模式仍可能遇到数据冗余插入、修改、删除异常等问题。

    第五范式处理的是无损连接问题,这个范式基本没有实际意义,因为无损连接很少出现,而且难以察觉。而域键范式试图定义一个终极范式,该范式考虑所有依赖和约束类型,但是实用价值是最小的,只存在理论研究中。

    小结

    我们在实际开发中一般只考虑第一到第三范式即可或者再加上一个巴斯范式。因为越往后拆的表就越多从而导致查询的连接就越多。

    更多相关内容
  • 数据库设计之三范式

    2022-02-05 11:09:57
    1. 数据库设计之三范式的介绍 范式: 对设计数据库提出的一些规范,目前有迹可寻的共有8种范式,一般遵守3范式即可。 范式(1NF): 强调的是列的原子性,即列不能够再分成其他几列。 范式(2NF): 满足 1NF,...

    1. 数据库设计之三范式的介绍

    范式: 对设计数据库提出的一些规范,目前有迹可寻的共有8种范式,一般遵守3范式即可。

    第一范式(1NF): 强调的是列的原子性,即列不能够再分成其他几列。
    第二范式(2NF): 满足 1NF,另外包含两部分内容,一是表必须有一个主键;二是非主键字段 必须完全依赖于主键,而不能只依赖于主键的一部分。
    第三范式(3NF): 满足 2NF,另外非主键列必须直接依赖于主键,不能存在传递依赖。即不能存在:非主键列 A 依赖于非主键列 B,非主键列 B 依赖于主键的情况。

    2. 第一范式的介绍

    如图所示的表结构:

    在这里插入图片描述

    说明:

    这种表结构设计就没有达到 1NF,要符合 1NF 我们只需把列拆分,即:把 contact 字段拆分成 name 、tel、addr 等字段。

    3. 第二范式的介绍

    如图所示的表结构:

    在这里插入图片描述

    说明:

    这种表结构设计就没有达到 2NF,因为 Discount(折扣),Quantity(数量)完全依赖于主键(OrderID),而 UnitPrice单价,ProductName产品名称 只依赖于 ProductID, 所以 OrderDetail 表不符合 2NF。
    我们可以把【OrderDetail】表拆分为【OrderDetail】(OrderID,ProductID,Discount,Quantity)和【Product】(ProductID,UnitPrice,ProductName)这样就符合第二范式了。

    4. 第三范式的介绍

    如图所示的表结构:

    在这里插入图片描述

    说明:

    这种表结构设计就没有达到 3NF,因为 OrderDate,CustomerID,CustomerName,CustomerAddr,CustomerCity 等非主键列都完全依赖于主键(OrderID),所以符合 2NF。不过问题是 CustomerName,CustomerAddr,CustomerCity 直接依赖的是 CustomerID(非主键列),而不是直接依赖于主键,它是通过传递才依赖于主键,所以不符合 3NF。
    我们可以把【Order】表拆分为【Order】(OrderID,OrderDate,CustomerID)和【Customer】(CustomerID,CustomerName,CustomerAddr,CustomerCity)从而达到 3NF。

    5. E-R模型的介绍

    E-R模型即实体-关系模型,E-R模型就是描述数据库存储数据的结构模型。

    E-R模型的使用场景:

    对于大型公司开发项目,我们需要根据产品经理的设计,我们先使用建模工具, 如:power designer,db desinger等这些软件来画出实体-关系模型(E-R模型)
    然后根据三范式设计数据库表结构
    E-R模型的效果图:

    在这里插入图片描述

    说明:

    实体: 用矩形表示,并标注实体名称
    属性: 用椭圆表示,并标注属性名称,
    关系: 用菱形表示,并标注关系名称
    一对一
    一对多
    多对多
    一对一的关系:

    在这里插入图片描述

    说明:

    关系也是一种数据,需要通过一个字段存储在表中
    1对1关系,在表A或表B中创建一个字段,存储另一个表的主键值
    一对多的关系:

    在这里插入图片描述

    说明:

    1对多关系,在多的一方表(学生表)中创建一个字段,存储班级表的主键值
    多对多的关系:

    在这里插入图片描述

    说明:

    多对多关系,新建一张表C,这个表只有两个字段,一个用于存储A的主键值,一个用于存储B的主键值

    5. 小结

    范式就是设计数据库的一些通用规范。
    1NF强调字段是最小单元,不可再分
    2NF强调在1NF基础上必须要有主键和非主键字段必须完全依赖于主键,也就是说 不能部分依赖
    3MF强调在2NF基础上 非主键字段必须直接依赖于主键,也就是说不能传递依赖(间接依赖)。
    E-R模型由 实体、属性、实体之间的关系构成,主要用来描述数据库中表结构。
    开发流程是先画出E-R模型,然后根据三范式设计数据库中的表结构


    例: Student(Sno, Sname, Ssex, Sage, Sdept)
    假设不允许重名,则有:
    Sno → Ssex, Sno → Sage , Sno → Sdept,
    Sno ←→ Sname, Sname → Ssex, Sname → Sage
    Sname → Sdept
    但Ssex -\→ Sage
    若 X → Y,并且 Y → X, 则记为 X ←→ Y。
    若 Y 不函数依赖于 X, 则记为 X -\→ Y。
    在关系模式R(U)中,对于U的子集X和Y,
    1.如果 X → Y,但 Y 不为 X 的子集,则称 X → Y 是非平凡的函数依赖
    例:在关系SC(Sno, Cno, Grade)中,
    非平凡函数依赖: (Sno, Cno) → Grade。
    2.若 X → Y,但 Y 为 X 的子集, 则称 X → Y 是平凡的函数依赖
    平凡函数依赖: (Sno, Cno) → Sno ,(Sno, Cno) → Cno。
    3.若 x → y 并且,存在 x 的真子集 x1,使得 x1 → y, 则 y 部分依赖于 x。
    例:学生表(学号,姓名,性别,班级,年龄)关系中,
    部分函数依赖:(学号,姓名)→ 性别,学号 → 性别,所以(学号,姓名)→ 性别 是部分函数依赖。
    4.若 x → y 并且,对于 x 的任何一个真子集 x1,都不存在 x1 → y 则称y完全依赖于x。
    例:成绩表(学号,课程号,成绩)关系中,
    完全函数依赖:(学号,课程号)→ 成绩,学号 -\→ 成绩,课程号 -\→ 成绩,所以(学号,课程号)→ 成绩 是完全函数依赖。
    5.若x → y并且y → z,而y -\→ x,则有x → z,称这种函数依赖为传递函数依赖。
    例:关系S1(学号,系名,系主任),
    学号 → 系名,系名 → 系主任,并且系名 -\→ 学号,系主任 -\→ 系名,所以学号 → 系主任为传递函数依赖。

    展开全文
  • 2.2 范式的分类 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。各范式之间的联系如下: 如下图所示: ...

    前言

    笔者遇到范式是在数据仓库建模时,以前对范式的理解比较浅显,且只了解前三范式,对后面三个范式并不了解,趁此机会和大家一起把其他范式学习下。

    1. 基础概念

    在了解范式之前我们需要对其中的一些基本概念进行了解。

    1.1 候选码

    某一属性组的值能唯一标识一个元组,而其子集不能,则称该属性组为候选码。若一个关系中有多个候选码,则选定其中一个为主码。
    例如下图所示的学生表中,学号和姓名都可以唯一标识一个元组,故该表的候选码为学号和姓名,我们可以随便选定其中一个作为主码。
    在这里插入图片描述

    1.2 主属性

    所有候选码的属性称为主属性。不包含在任何候选码中的属性称为非主属性或非码属性
    在上面的学生表中,学号和姓名就是该关系的主属性,年龄和性别就是非主属性。

    1.3 函数依赖

    在这里插入图片描述
    设R为任一给定的关系,如果对于R中属性X的每一个值,R中的属性Y只有唯一值与之对应,则称X函数决定Y或Y函数依赖于X,记作X——>Y。其中X称为决定因素。
    通俗一点,就是给定一个X都有唯一的Y。可以理解为函数y=f(x);对于 任意的x 都有一个y,且y的取值有x决定。

    例如:学号可以唯一确定一个学生的年龄、姓名等信息。

    1.4 完全函数依赖

    如果存在 X 属性组(注意是组,说明是联合主键)决定 唯一的 Y ,但 X 中的任一子集却不能决定唯一的 Y,则 Y 完全依赖于 X。
    例如:学生的成绩由学生与课程共同决定。所以成绩完全依赖于学生与课程。

    1.5 部分函数依赖

    与完全函数依赖相反:如果存在 X 属性组(注意是组,说明是联合主键)决定 唯一的 Y ,且 X 中的任一子集都能能决定唯一的 Y,则 Y 部分依赖于X。
    例如:在没有同名的情况下,学号与姓名都可以决定一个学生的年龄、性别等信息。

    1.6 传递函数依赖

    设 R 为任一给定关系, X Y Z 为其不同的属性子集,若 X —> Y 且 Y —>Z,则有 X —>Z,称为 Z 传递函数依赖于 X
    例如:学号可以唯一确定一个系部,且系部可以唯一确定一个系主任。

    2. 范式

    2.1 什么是范式?

    范式来自英文Normal form,简称NF。要想设计—个好的关系,必须使关系满足一定的约束条件,此约束已经形成了规范,这就是我们俗称的范式。范式分成几个等级,一级比一级要求得严格。各种范式呈递次规范,越高的范式数据库冗余越小。在设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,没有冗余的数据库未必是最好的数据库, 有时为了提高运行效率,就必须降低范式标准,适当保留冗余数据。

    2.2 范式的分类

    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。各范式之间的联系如下:
    在这里插入图片描述
    如下图所示:
    在这里插入图片描述
    满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多规范要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

    2.2.1 第一范式(1NF)(针对具体某一列)

    所谓第一范式(1NF)是指在关系模型中,对域添加的一个规范要求,所有的域都应该是原子性的,即数据库表的每一列都是不可分割的原子数据项,而不能是集合,数组,记录等非原子数据项。即实体中的某个属性有多个值时,必须拆分为不同的属性。在符合第一范式(1NF)表中的每个域值只能是实体的一个属性或一个属性的一部分。简而言之,第一范式就是无重复的域。

    • 不符合:
      在这里插入图片描述
    • 符合:
      在这里插入图片描述

    实例:
    例:下面这个表中张三其实是一个人,如果在一个java程序中应该是一个实体类,但是在数据库中记录成两条记录,因为tel列中包含了手机和宅电两个属性。

    idnametel
    1张三18656565656
    2张三36522323

    正确的方式是下面这样

    idnametelphone
    1张三3652232318656565656

    2.2.2 第二范式( 2NF )(针对某一列与复合主键的一部分有关)

    • 定义:
      所谓第二范式,是指所有的非主属性都完全依赖于关键字。
    • 理解:
      第二范式必须满足第一范式。
      第二范式是指每个关系必须有一个(有且仅有一个)数据项作为主键,其他数据项与主键一一对应,即其他数据项完全依赖于主键。由此可知单主属性的关系均属于第二范式。
    • 判断一个范式是否符合第二范式
      在这里插入图片描述

    实例:
    例:假定选课关系表为SelectCourse(学号,姓名,年龄,课程名称,成绩,学分),关键字为组合关键字(学号,课程名称),因为存在如下决定关系:

    stuIdnameagekemuscorexuefen
    1张三16数学89100
    2张三16语言90100

    age、name是由stuId决定的,与kemu无关;xuefen是由kemu决定的,与stuId无关;score是由stuId和kumu共决定的;即存在组合关键字中的字段决定非关键字的情况。由于不符合2NF,这个选课关系表会存在如下问题:

    1. 数据冗余:
      同一门课程由n个学生选修,"学分"就重复n-1次;同一个学生选修了m门课程,姓名和年龄就重复了m-1次。
    2. 更新异常:
      若调整了某门课程的学分,数据表中所有行的"学分"值都要更新,否则会出现同一门课程学分不同的情况。
    3. 插入异常:
      假设要开设一门新的课程,暂时还没有人选修。这样,由于还没有"学号"关键字,课程名称和学分也无法记录入数据库。
    4. 删除异常:
      假设一批学生已经完成课程的选修,这些选修记录就应该从数据库表中删除。但是,与此同时,课程名称和学分信息也被删除了。很显然,这也会导致插入异常。
      把选课关系表SelectCourse改为如下三个表:
      学生:Student(学号,姓名,年龄);
      课程:Course(课程名称,学分);
      选课关系:SelectCourse(学号,课程名称,成绩)。
      这样的数据库表是符合第二范式的, 消除了数据冗余、更新异常、插入异常和删除异常。

    另外,所有单关键字的数据库表都符合第二范式,因为不可能存在组合关键字。

    2.2.3 第三范式(3NF)(针对某一列与主键无关,但是与某一非主键列有关)

    • 定义:
      每一个非主属性既不部分依赖于也不传递依赖于关键字,也就是在第二范式的基础上消除传递依赖(A>B>C)。
    • 理解:
      即在第二范式的基础上,消除了非主属性对码的传递依赖。

    实例:
    例如,存在一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。
    在这里插入图片描述

    2.2.4 BCNF(针对某一列与复合主键中的某一列有关,而与其他主键无关)

    • 定义:
      BCNF,是指在第三范式的基础上进一步消除主属性对于码的部分函数依赖和传递依赖。BCNF需要符合3NF,并且,主属性不依赖于主属性。所有属性都完全依赖于码,每一个决定因素都包含码。
    • 理解: 一个满足BC范式的关系模式有:
    1. 所有非主属性对每一个码都是完全函数依赖;
    2. 所有主属性对每一个不包含它的码也是完全函数依赖;
    3. 没有任何属性完全函数依赖于非码的任何一组属性。

    例如有关系模式C(Cno, Cname, Pcno),Cno, Cname, Pcno依次表示课程号、课程名、先修课。可知关系C只有一个码Cno,且没有任何属性对Cno部分函数依赖或传递函数依赖,所以关系C属于第三范式,同时Cno是C中的唯一决定因素,所以C也属于BC范式。

    实例:
    假设仓库管理关系表为StorehouseManage(仓库ID,存储物品ID,管理员ID,数量),且有一个管理员只在一个仓库工作;一个仓库可以存储多种物品。这个数据库表中存在如下决定关系:
      
      (仓库ID,存储物品ID) →(管理员ID,数量)
      
      (管理员ID,存储物品ID) → (仓库ID,数量)
      
    所以,(仓库ID,存储物品ID)和(管理员ID,存储物品ID)都是StorehouseManage的候选关键字,表中的唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

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

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

    即存在关键字段决定关键字段的情况,所以其不符合BCNF范式。它会出现如下异常情况:

    1. 删除异常:
      当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。
    2. 插入异常:
      当仓库没有存储任何物品时,无法给仓库分配管理员。
    3. 更新异常:
      如果仓库换了管理员,则表中所有行的管理员ID都要修改。
      把仓库管理关系表分解为二个关系表:
      仓库管理:StorehouseManage(仓库ID,管理员ID);
      仓库:Storehouse(仓库ID,存储物品ID,数量)。

    这样的数据库表是符合BCNF范式的,消除了删除异常、插入异常和更新异常。

    又如,有这样一个配件管理表WPE(WNO,PNO,ENO,QNT),其中WNO表示仓库号,PNO表示配件号,ENO表示职工号,QNT表示数量。

    有以下约束要求:

    1. 一个仓库有多名职工;

    2. 一个职工仅在一个仓库工作;

    3. 每个仓库里一种型号的配件由专人负责,但一个人可以管理几种配件;

    4. 同一种型号的配件可以分放在几个仓库中。

    分析表中的函数依赖关系,可以得到:

    1. (ENO)->WNO;

    2. (WNO,PNO)->QNT

    3. (WNO,PNO)->ENO

    4. (ENO,PNO)->QNT

    可以看到,候选键有:(ENO,PNO);(WNO,PNO)。所以,ENO,PNO,WNO均为主属性,QNT为非主属性。显然,非主属性是直接依赖于候选键的。所以此表满足第三范式。

    而我们观察一下主属性:(WNO,PNO)->ENO;ENO->WNO。显然WNO对于候选键(WNO,PNO)存在传递依赖,所以不符合BCNF.

    解决这个问题的办法是分拆为两个表:管理表EP(ENO,PNO,QNT);工作表EW(ENO,WNO)。但这样做会导致函数依赖(WNO,PNO)->ENO丢失。

    虽然,不满足BCNF,也会导致一些冗余和一致性的问题。但是,将表分解成满足BCNF的表又可能丢失一些函数依赖。所以,一般情况下不会强制要求关系表要满足BCNF。

    2.2.5 4NF(第四范式)

    • 定义:
      第四范式,从理论层面来讲是,关系模式R∈1NF,如果对于R对于R的每个非平凡多值依赖X→→Y(Y不属于X),X都含有候选码,则R∈4NF。4NF就是限制关系模式的属性之间不允许有非平凡且非函数依赖的多值依赖。显然一个关系模式是4NF,则必为BCNF。
    • 理解:
      显然一个关系模式是4NF,则必为BCNF。也就是说,当一个表中的非主属性互相独立时(3NF),这些非主属性不应该有多值,若有多值就违反了4NF。

    实例:
    有这样一个用户联系方式表TELEPHONE(CUSTOMERID,PHONE,CELL)。CUSTOMERID为用户ID,PHONE为用户的固定电话,CELL为用户的移动电话。

    本来,这是一个非常简单的第3范式表。主键为CUSTOMERID,不存在传递依赖。但在某些情况下,这样的表还是不合理的。比如说,用户有两个固定电话,两个移动电话。这时,表的具体表示如下:

    CUSTOMERIDPHONECELL
    10008828-1234149088888888
    10008838-1234149099999999

    由于PHONE和CELL是互相独立的,而有些用户又有两个和多个值。这时此表就违反第四范式。

    在这种情况下,此表的设计就会带来很多维护上的麻烦。例如,如果用户放弃第一行的固定电话和第二行的移动电话,那么这两行会合并吗?等等

    解决问题的方法为,设计一个新表NEW_PHONE(CUSTOMERID,NUMBER,TYPE).这样就可以对每个用户处理不同类型的多个电话号码,而不会违反第四范式。

    显然,第四范式的应用范围比较小,因为只有在某些特殊情况下,要考虑将表规范到第四范式。所以在实际应用中,一般不要求表满足第四范式。

    2.2.6 5NF(第五范式)

    • 第五范式(5NF):是最终范式。消除了4NF中的连接依赖。

    • 第五范式有以下要求:

    1. 必须满足第四范式
    2. 表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。

    第五范式是在第四范式的基础上做的进一步规范化。第四范式处理的是相互独立的多值情况,而第五范式则处理相互依赖的多值情况。

    实例:
    有一个销售信息表SALES(SALEPERSON,VENDOR,PRODUCT)。SALEPERSON代表销售人员,VENDOR代表供和商,PRODUCT则代表产品。
    在某些情况下,这个表中会产生一些冗余。可以将表分解为PERSON_VENDOR表(SALEPERSON,VENDOR);PERSON_PRODUCT表(SALEPERSON,PRODUCT);
    VENDOR­_PRODICT表(VENDOR,PRODUCT)
    在这里插入图片描述

    展开全文
  • mysql数据库设计规范之数据库设计范式

    为什么需要数据库设计

    1. 我们在设计数据表的时候要考虑很多问题问题,比如:

    • 用户都需要什么数据?需要在数据表中保存哪些数据?
    • 如果保证数据表中数据的正确性,当插入、删除、更新的时候该进行怎么样的约束检查?
    • 如何降低数据表的数据冗余,保证数据表不会因为用户量的增长而迅速扩张?
    • 如何让负责数据库维护的人员更方便使用数据库?
    • 使用数据库的应用场景各不相同,可以说针对不同的情况设计出来的数据表可能千差万别。

    2. 现实情况中面临的场景

    当数据库运行一段时间之后我们才发现数据表设计有问题。重新调整数据表结构就需要做数据的迁移,还有可能影响程序的业务逻辑,以及网站的正常访问。

    3. 如果是糟糕的数据库设计可能会造成以下问题

    • 数据冗余、信息重复、存储空间浪费
    • 数据更新、插入、删除异常
    • 无法正确表示信息
    • 丢失有效信息
    • 程序性能差

    4. 良好的数据库设计则有以下优点:

    • 节省数据的存储空间
    • 能够保证数据的完整性
    • 方便进行数据库应用系统的开发

    总之,开始设置数据库的时候我们需要重视数据表的设计。为了建立冗余较小、结构合理的数据库,设计数据库时必须遵循一定的规则。

    范式

    范式简介

    在关系型数据库中,关于数据表设计的基本原则、规范就成为范式。可以理解为,一张数据表的设计结构需要满足的某种设计标准的级别。要想设计一个结构合理的关系型数据库,必须满足一定的范式。
    范式的英文名称是Normal Form,简称NF。它是英国人在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础,也是我们在设计数据库结构过程中所要遵循的规则和指导方法。

    范式包含哪些

    目前关系型数据库优六种常见范式,按照范式级别,从低到高分别是第一范式、第二范式、第三范式、巴斯-科德范式、第四范式和第五范式(又称完美范式)。
    数据库的范式设计越高阶,冗余度就越低,同时高阶的范式一定符合低阶范式的要求,满足最低要求的范式是第一范式。在第一范式的基础上进一步满足更多规范要求的称为第二范式,其余以此类推。
    一般来说,在关系型数据库设计中,最高也就遵循到巴斯范式,普遍是第三范式。但也不是绝对的,有时候为了提高某些查询性能,我们还需要破坏范式规则,也就是反范式化。

    键和属性的概念

    范式的定义会使用到主键和候选键,数据库中的键(key)由一个或多个属性组成。数据表中常用的几种键和属性的定义:

    • 超键:能唯一标识元组(记录)的属性集叫做超键。
    • 候选键:如果超键不包括多余的属性,那么这个超键就是候选键。
    • 主键:用户可以从候选键中选择一个作为主键。
    • 外键:如果数据表R1中的某属性集不是R1的主键,而是另一个表R2的主键,那么这个属性集就是数据表R1的外键。
    • 主属性:包含在任一候选键中的属性称为主属性。
    • 非主属性:与主属性相对,指的是不包含在任何一个候选键中的属性。
      通常,我们可将候选键称之为“码”,把主键称为“主码”。因为键可能是有多个属性组成,针对单个属性我们还可以用主属性和非主属性来进行区分。

    举例

    这里有两个表:
    球员表(player):球员编号 | 姓名 | 身份证号 |年龄 |球队编号
    球队表:(team):球队编号|主教练|球队所在地

    • 超键:对于球员表来说,超键就是包括球员编号或身份证号的任意组合,比如球员编号,球员编号和姓名,身份证号和年龄等。
    • 候选键:就是最小的超键,对于球员表来说,候选键就是球员编号或者身份证号
    • 主键:我们自己选定,也就是从候选键中选择一个,比如球员编号。
    • 外键:球员表中的球队编号。
    • 主属性、非主属性:在球员表中,主属性就是球员编号 身份证号,其他属性姓名 年龄 球队编号都是非主属性。

    第一范式(1NF)

    第一范式主要是确保数据表中每个字段的值必须具有原子性,也就是说数据表中每个字段的值为不可再拆分的最小数据单元。
    我们在设计某个字段的时候,对于字段x来说,不能把字段x拆分成字段x1和字段x2.事实上,任何dbms都会满足第一范式的要求,不会将字段进行拆分。

    举例1

    假设一家公司要存储员工的姓名和练习方式,它创建一个如下的表
    在这里插入图片描述

    改变就不符合1NF,因为规则说表的每个属性必须是原子值,lisi和zhaoliu员工的emp_mobile值违反了改规则。为了使表符合1NF,我们应该用如下表:
    在这里插入图片描述

    举例2

    有一个user表
    在这里插入图片描述
    其不符合第一范式。其中user_info字段为用户信息,可以进一步拆分成更小粒度字段。将user_info拆分后如下

    在这里插入图片描述

    举例3

    属性的原子性是主管的。* 例如employees*表中雇员姓名应当使用1个(fullname)、2个(firstname,lastname)还是3个(fistname,middlename,和lastname)属性表示呢?答案取决于应用程序。如果程序需要分别处理雇员的姓名部分(如:用于搜索目的),则有必要把它们分开。否则,不需要。在这里插入图片描述

    第二范式(2NF)

    第二范式要求在满足第一范式的基础上,还要满足数据表里的每一条记录都是可唯一标识的。而且所有非主键字段,都必须完全依赖于主键,不能之依赖主键部分。如果知道主键的所有属性的值,就可以检索到任何行的任何属性的任何值。(要求中的主键,可以拓展替换为候选键)。

    举例1

    成绩表(学号、课程号、成绩)关系中,(学号,课程号)可以决定成绩,但是学号不能决定成绩,课程号也不能决定成绩。所以(学号,课程号)–》成绩就是完全依赖关系。

    举例2

    比赛表player_game里包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性。这里候选键和主键都为(球员编号,比赛编号),我们可以通过主键来决定如下的关系:
    (球员编号,比赛编号)-----》(姓名,年龄,比赛时间,场地,得分)
    但是这个表不满足第二范式,因为表中字段还存在如下关系:
    (球员编号)—》(姓名,年龄)
    (比赛编号)—》(比赛时间,比赛场地)
    对于非主属性来说,并非完全依赖候主键。这样会产生怎么样的问题呢?

    1. 数据冗余,如果一个球员可以参加m场比赛,那么球员的姓名和年龄就要重复m-1次。一个比赛可能会有n个球员参加,比赛时间和场地就重复了n-1次。
    2. 插入异常,如果我们想要添加一场新的比赛,但是这时还没有确定参加的球员有谁,那么就无法插入。
    3. 删除异常,如果我要删除某个球员编号,如果没有单独保存比赛表的话,就会同时把比赛信息删除。
    4. 更新异常,如果我们调整了某个比赛时间,那么表中所有这个比赛时间都需要调整,否则就会出现一场比赛时间不同的情况。
      为了避免出现上述的情况,我们可以把球员比赛表设计为下面三张表
      在这里插入图片描述

    这样的话,每张数据表都符合第二范式,也就避免了异常情况的发生。

    1NF告诉我们字段属性需要是原子性,而2NF告诉我们一张表就是一个独立的对象,一张表只表达一个意思
    

    举例3

    定义了一个名为Orders的关系,表示订单和订单行的信息
    在这里插入图片描述
    违反了第二范式,因为有非主属性依赖于候选键(或主键)的一部分。例如,可以通过orderid找到订单的orderdate,以及customerid和companyname而没有必要再去使用productid
    修改:
    Orders表和OrderDetails表如下,此时符合第二范式。
    在这里插入图片描述

    小结:第二范式要求实体的属性完全依赖于主键字段。如果存在不完全依赖,那么这个属性和主键字段的一部分应该分离出来形成一个新的实体,新实体与原实体之间是一对多关系
    

    第三范式(3NF)

    第三范式是在第二范式的基础上,确保数据表中的每一个非主键字段都和主键字段直接相关,也就是说,要求数据表中的所有非主键字段不能依赖于其他非主键字段。即为不存在非主属性A依赖于非主属性B,非主属性B依赖于主键C的情况。通俗说,改规则的意思是所有非主属性之间不能有依赖关系,必须相互独立。
    这里的主键可以拓展为候选键。

    举例1

    部门信息表:每个部门有部门编号、部门名称、部门简介等信息。
    员工信息表:每个员工有员工编号、姓名、部门编号。列出部门编号就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
    如果不存在部门信息表,则根据3NF也应该构建它,否则就会又大量的数据冗余。

    举例2

    在这里插入图片描述
    商品类别名称依赖于商品类别id不符合3NF
    修改:
    表1 符合3NF的商品类别表的设计
    在这里插入图片描述
    表2 符合3NF的商品表的设计
    在这里插入图片描述
    商品表goods通过商品类别id字段与商品类别表进行关联。

    2NF和3NF通常以这句话概括“每个非键属性依赖于键,依赖于整个键,并且除了键别无他物”
    

    小结

    关于数据表的设计,有三个范式要遵循。

    1. 第一范式,确保每列保持原子性
      数据库每一列都是不可分割的原子数据项,不可再分的最小数据单元,而不能是集合、数组、记录等非原子数据项
    2. 第二范式,确保每列和主键完全依赖 。尤其是在复合主键的情况下,非主键部分不应该依赖于部分主键。
    3. 第三范式,确保每列都和主键列直接相关,而不是间接相关。
      **范式的优点:**数据的标准化有助于消除数据库中的数据冗余,3NF通常被认为在性能、扩展性和数据完整性方面达到了最好的平衡。
      **范式的缺点:**范式的使用,可能降低查询效率。因为范式等级越高,设计出来的数据表越多,越精细,数据的冗余度就越低,进行数据查询的时候就可能需要关联多张表,这不但代价昂贵,也可能使一些索引策略无效。
      范式知识提出了设计的标准,实际上设计数据表时未必一定要符合这些标准。开发中我们会出现为了性能和读取效率违反范式化的原则,通过增加少量的冗余或重复的数据来提高数据库的读性能,减少关联查询,join表的次,实现空间换取时间的目的。因此在实际的设计过程中要理论结合实际,灵活运用。
    范式本身没有优劣之分,只有适用场景不同。没有完美的设计,只有合适的设计,我们在数据表的设计中,还需要根据需求将范式和反范式混合使用。
    
    展开全文
  • 数据库设计三大范式

    千次阅读 2022-04-05 20:02:54
    范式:Normal Format,符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度。...一个数据库设计的是否合理,要从增删改查的角度去考虑,操作是否方便 范式:确保表
  • 文章目录1NF关系数据库设计中易犯的错误Armstrong公理系统正则覆盖2NFBCNF3NF(常用)多值依赖4NF(不常用) 1NF 如果某个域中元素被认为是不可分的,则这个域称为是原子的。 非原子域的例子如下: ​ ― 复合属性:.
  • 范式(1NF):每一列都是不可分割的原子数据项(什么意思,每一项都不可分割,像下面的表格就能分割,所以它连范式都算不上)  分割后的样子 (它就是范式了) 范式:在1NF基础上,非码...
  • 引言数据库设计范式数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造...
  • 数据库设计第范式---一二三范式介绍

    万次阅读 多人点赞 2017-05-05 11:43:41
    一、数据库设计范式及其意义和不足 数据库设计范式数据库设计所需要满足的规范,数据库的规范化是优化表的结构和优化把数据组织到表中的方式,这样使数据更明确,更简洁。实践中,通常把一个数据库分成两个或...
  • 数据库设计范式数据库设计所需要满足的规范,满足这些规范的数据库是简洁的、结构明晰的,同时,不会发生插入(insert)、删除(delete)和更新(update)操作异常。反之则是乱七八糟,不仅给数据库的编程人员制造麻烦...
  • 为了建立冗余较小,结构合理的数据库设计数据库时必须遵守一定的规则,在关系型数据库中这种规则就是范式范式是符合某一种级别的关系模式的集合。关系型数据库中的关系必须满足一定的要求,即满足不同的范式。 ...
  • 什么是数据库设计范式 数据库表的设计依据。教你怎么进行数据库表的设计数据库设计范式有几种 3种。 范式:要求任何一张表必须有主键,每一个字段原子性不可再分。 范式:建立在范式的基础之上,要求...
  • 数据库设计 第4范式(2)
  • 范式分为:三大范式,以及BC范式第四范式还有第五范式,一共六大范式;通常来说满足与三大范式就基本足够。 注意:项目的数据库设计并不一定要完全满足于三大范式,有些时候我们会适量的冗余让 Query 尽量减少 ...
  • 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小。但是有些时候一昧的追求范式减少冗余,反而会降低数据读写...
  • 6 第四范式:消除表中的多值依赖 7 详细举例 1 什么是数据库泛型? 数据库泛型就是数据库应该遵循的规则。数据库泛型也称作数据库范式数据库范式数据库设计需要满足的一些规范。满足这些规范可以使数据库变得...
  • 数据库设计三大范式(例子图解)

    千次阅读 多人点赞 2019-04-25 20:44:42
    为了减少数据冗余,设计数据表时必须遵循一定的规则,在关系型数据库中这种规则就称为范式。 引用:http://www.cnblogs.com/linjiqin/archive/2012/04/01/2428695.html 1.范式1NF(确保每列保持原子性) 每一...
  • 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。 而通常我们用的最多的就是第一范式(1NF)、第二范式...
  • 一、数据库设计三大范式 什么是范式:为了建立冗余较小、结构合理的数据库设计数据库时必须遵循一定的规则。在关系型数据库 中这种规则就称为范式范式是符合某一种设计要求的总结。要想设计一个结构合理的关系型...
  • 目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。 而通常我们用的最多的就是第一范式(1NF)、第二范式...
  • 范式要求关系数据库中一个实体的每一个属性都为不可再分解的基本数据单位。范式表达的核心思想的属性的原子性,是关系模式规范化的最低要求,否则,将有很多基本操作在这样的关系模式中实现不了。 1NF遵循...
  • 星光不问赶路人,时光不...目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范...
  • 数据库|第一范式、第二范式、第三范式、BC范式第四范式简单理解 在设计数据库的时候,虽说将我们要的数据正确完整导入数据库是很关键的,但是对于数据库设计者来说,如何将大量数据合理有效正确地导入数据库中也...
  • 范式(2nd NF)3.1 概念3.2 举例3.3 总结4. 范式(3rd NF)4.1 概念4.2 举例4.3 总结5. 范式的优缺点5.1 优点5.2 缺点6. 反范式化6.1 概念6.2 规范与性能平衡6.3 举例6.4 代码演示6.5 反范式的问题6.6 反范式...
  • 文章目录函数依赖部分函数依赖完全函数依赖传递函数依赖(非)平凡函数依赖多值依赖范式第一范式(1NF)第二范式(2NF)存在的问题第三范式(3NF)...存在的问题第四范式4NF)范式设计和反范式设计范式化反范式化参考...
  • 数据库设计常用三大范式

    万次阅读 多人点赞 2018-08-09 12:14:46
    目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)和第五范式(5NF,又称完美范式)。满足最低要求的范式是第一范式(1NF)。在第一范式的基础...
  • 目录一、数据库设计的重要性二、范式 - 简介:1、什么是范式?一范式 - 单一列二范式 - 中间表 - 一对多三范式 - 不产生中间表 - 一对...在数据库表设计上有个很重要的设计准则,称为范式设计。 二、范式 - 简介

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 59,451
精华内容 23,780
关键字:

数据库设计第四范式