精华内容
下载资源
问答
  • 数据库设计范式

    2019-03-16 10:19:14
    对于数据库分析方法,常见的就是数据库范式设计 所有的设计范式,都是作为一种参考,在初期可以根据范式进行设计,但之后几乎所有的范式都被打破 我们在数据库设计的时候,根据业务的需要尽可能的减少多表复杂...

    对于一个软件开发而言,一定经历这几个步骤:
    获取需求;
    需求分析与业务设计;
    数据库设计;
    程序开发与业务实现;
    程序测试;
    程序运维;

    对于数据库的分析方法,常见的就是数据库的范式设计
    所有的设计范式,都是作为一种参考,在初期可以根据范式进行设计,但之后几乎所有的范式都被打破
    我们在数据库设计的时候,根据业务的需要尽可能的减少多表复杂查询;
    第一范式:数据表中的每个字段都不可在分;
    某一个字段:例,联系方式(其中包括手机,QQ,微信,email)这不符合。
    第二范式:数据表之中不存在非关键字段对任意一候选关键字段的部分函数依赖
    函数与函数依赖;

    展开全文
  • 关系数据库中的关系必须满足一定的要求,即满足不同的范式。 满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三...

    范式

    什么是范式

    范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的范式。

    满足最低要求的范式是第一范式(1NF)。在第一范式的基础上进一步满足更多要求的称为第二范式(2NF),其余范式以次类推。一般说来,数据库只需满足第三范式(3NF)就行了。

    函数依赖

    在学习范式前,我们还需要了解函数依赖

    1. 函数依赖的定义

    函数依赖(functional dependency,FD)是一种完整性约束,是现实世界事物属性之间的一种制约关系,它广泛地存在于现实世界中。

    在这里插入图片描述

    图1可称α函数确定β,或β函数依赖于α,记作α→β

    2. 平凡函数依赖与非平凡函数依赖

    在这里插入图片描述
    在这里插入图片描述

    3. 完全函数依赖和部分函数依赖

    注:可以看出,当α是单属性是,α→β完全函数依赖总是成立的。

    在这里插入图片描述

    4. 传递函数依赖

    若α→β,β→γ和α→γ都是非平凡函数依赖,且β→α不成立,则称α→γ是传递函数依赖

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ogJiLHR4-1576659913273)(D:\张文东\md笔记\数据库\pictures\图5 传递函数α→γ依赖图.png)]

    第一范式(1NF)——码

    定义

    如果一关系模式r(R)的每个属性对应的域值都是不可分的,则称r(R)属于第一范式(1NF),记为r(R)∈1NF。

    目标

    将基本数据划分成称为实体集或表的逻辑单元,当设计好每个实体后,需要为其指定主码

    第二范式2NF——全部是码

    定义

    如果一个关系模式r(R)∈1NF,且所有非主属性都完全依赖于r(R)的候选码,则称r(R)属于第二范式(2NF),记作r(R)∈2NF。

    设有一关系模式r(R),α ⊆ R。

    若α包含在r(R)某一个候选码中,则称α主属性,否则α为非主属性

    如:r(R)=r(A,B,C,D),候选码为AB和AD,那么A、B、D就是主属性,C是非主属性。

    也就是说,对于满足1NF的关系模式,如果有复合候选码(即多个属性共同构成的候选码),那么非主属性不允许依赖于部分的候选码属性,必须完全依赖于全部的候选码属性——全部是码

    目标

    将只部分依赖于候选码(即依赖于候选码的部分属性)的非主属性通过关系模式分解到其他表当中。

    第三范式3NF——仅仅是码

    定义

    如果一个关系模式r(R)∈2NF,且所有非主属性都直接依赖于r(R)的候选码(即不存在非主属性传递依赖于候选码),则称r(R)属于第三范式(3NF),记为r(R)∈3NF。

    也就是说,对于满足2NF的关系模式,非主属性不能依赖于另一个(组)非主属性(这样就形成了对于候选码的传递依赖),即非主属性只能直接依赖于候选码——仅仅是码

    目标

    将不直接依赖于候选码(即传递依赖于候选码)的非主属性通过关系模式分解到其它表中去。

    总之,所有的非主属性应该直接依赖于(即不能存在传递依赖,这是3NF的要求)全部候选码(即必须完全依赖,不能存在部分依赖,这是2NF的要求)。

    Boyce-Codd范式BCNF

    定义

    给定关系模式r(R)∈1NF,函数依赖集F,若F+(F的闭包)中的所有函数依赖α→β至少满足下列条件之一:

    • α→β是平凡函数依赖(即β⊆α)
    • α是r(R)的一个超码(即α中包含r®的候选码)

    则称r(R)属于Boyce-Codd范式,记为r(R)∈BCNF。

    从函数依赖角度可得出,一个满足BCNF的关系模式必然满足下列结论:

    1. 所有非主属性都完全依赖于每个候选码
    2. 所有主属性都完全依赖于每个不包含它的候选码。
    3. 没有任何属性完全函数依赖于非候选码的任一组属性。

    因此,BCNF不仅排除了任何属性(包括主属性和非主属性)对候选码的部分依赖和传递依赖,而且派出了主属性之间的传递依赖。BCNF确保了通过函数依赖不能再查出任何冗余,即只考虑函数依赖关系时,BCNF已是最好的范式。

    做题方法

    求候选码

    将关系模式r(R)里的所有属性分为4类

    • L:只存在依赖集左边的属性(一定是候选码的属性)
    • R:只存在依赖集右边的属性
    • LR:存在于依赖集左右两边的属性(可能是候选码的属性)
    • N:不存在于依赖集的属性

    求候选码顺序

    1. 将关系模式r(R)里的L类和LR类属性写出来
    2. 求L类里的所有属性组成的属性集的闭包
    • 如果闭包等于r(R)里的所有属性,那么该属性集就是候选码,到此结束
    • 不等于则进入第3步
    1. 将LR类里的属性逐个加进L类的属性集,然后求新属性集的闭包
    • 如果闭包等于r(R)里的所有属性,那么该新属性集就是候选码;
    • 如果不是则该新属性集不是候选码;
    • 继续第3步,直至遍历完LR类所有属性

    判断最高满足哪种范式

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-08Jnezo9-1576659913277)(C:\Users\SAMSUNG\AppData\Roaming\Typora\typora-user-images\1576659444190.png)]

    例题

    【例1】对于关系模式r(R)=r(A,B,C,D),判断下列关系模式r(R)的候选码和最高满足哪种范式?

    1. F1={C→D,C→A,B→C};
    2. F2={ABC→D,D→A};
    3. F3={A→B,BC→D};

    解:

    1. 候选码为:B;因为存在传递依赖,所以最高满足2NF;
    2. 候选码为:ABC和BCD;因为存在依赖D→A,D不是r®的超码,所以最高满足3NF;
    3. 候选码为:AC;因为B部分依赖于候选码AC,所以最高满足1NF。
    展开全文
  • 数据库范式属于数据库设计过程中。设计一个新的数据库系统需要关注广泛的问题,对于一般的数据库设计来说,大体上是下面的步骤数据库设计最初阶段需要完整刻画未来数据库用户的数据需求,为了完成这个任务...

    概述

    数据库三范式属于数据库设计过程中。设计一个新的数据库系统需要关注广泛的问题,对于一般的数据库设计来说,大体上是下面的步骤:

    1. 数据库设计最初阶段需要完整刻画未来数据库用户的数据需求,为了完成这个任务需要设计人员与专家和用户进行交流,产生需求规格说明。

    2. 经过上面的需求分析,获得了基本的需求规格说明,基于需求利用实体-联系图也就是E-R图,建立概念模型。建立的模型需要不断 进行审查,力求设计出的概念模型对说有数据需求都满足。这个阶段,只关注描述数据及其联系,而不关注物理存储具体实现。

    3. 完善的概念模式还应该指明企业的功能需求,在功能需求规格说明中,用户描述将在数据上进行的各类操作(或事务)。

    4. 最后将抽象数据模型进行数据库实现,具体还分为两个阶段:

    • 逻辑设计阶段。将高层概念模式映射到将使用的数据库系统的实现数据模型上。实现数据模型通常是关系数据模型,该阶段通常包括将以 实体-联系模型定义的概念模式映射到关系模式。

    • 设计者将所得到的系统特定的数据库模式使用到后续的物理设计阶段中。在该阶段指明数据库的物理特征。

    通过上述四个步骤,实际上就可以得到一个基本的数据库模式,但是往往这样的数据库模式不一定是良好的数据库模式,设计数据库模式的目标是 生成一组关系模式,使我们存储信息时避免不必要的冗余,也没有增删改查产生的异常,数据也可以保持良好的一致性。基于这个要求,就需要设计 满足适当范式(normal form)的模式来实现。

    初学这个概念的时候,可能很难理解为什么要引入这些概念,为什么数据库不能随意设计呢,即使不基于这样的概念,难道不能设计出好的数据库模式吗? 实际上,良好的数据库模式基本上都满足于三范式的要求。殊途同归,因为三范式的设计要求能极大的避免数据冗余,保证数据的一致性和良好的操作性。 因此,理解并在实际设计数据库过程中遵循三范式的要求是一种必然的要求。

    随着近些年数据库技术的蓬勃发展,实际上部分数据库已经不遵循这种设计理念了,比如Redshift数据库甚至都不对主键的唯一性做出约束,这样的数据库 设计并不普适与所有的业务场景,传统的PostgreSQL与MySQL还都是遵循这些准则。因此,实际使用数据库管理系统时,需要区分不同数据库的特性,才能 更好的使用他们。

    函数依赖

    函数依赖是三范式的基础,三范式都是在函数依赖的概念上进一步讨论的。

    首先先明确函数依赖的定义,给定一个关系r,如果对实例中所有元组对,t1和t2,都满足t1[a]=t2[a],则t1[b]=t2[b],那么我们说该函数依赖在模式r上成立。我们可以通过下面一组关系来进一步理解函数依赖的概念。

    r(A,B,C,D)

    A B C D
    a1 b1 c1 d1
    a1 b1 c1 d2
    a2 b2 c2 d2
    a2 b3 c2 d3
    a3 b3 c2 d4

    我们可以注意到每个A的值会对应一个C的值,a1对应c1,a2对应c2,只要是A属性相同取值,C属性取值必然相同,是多对一的关系,这种情况符合函数依赖的定义,记为A-->C,但是反过来,C-->A并不成立。

    第一范式

    有了函数依赖的定义之后就可以讨论范式的概念了。

    第一范式是关系型数据库的基本要求,甚至有的说法称,如果连第一范式都不满足的数据库就肯定不是关系型数据库,虽然一定意义上是这样的,但是现在的数据库系统已经允许一定程度上不满足第一范式的要求。

    所谓的第一范式,就是要求所有属性都是原子的属性,不可再分。比如现在有一个个人信息的关系。

    r(name,age,gender,address)

    name age gender address
    wang 18 male 中国北京市海淀区

    此时的地址属性就是组合属性,将国家省市和区组合在一起,显然是不符合第一范式的定义,假设某个人搬家,从海淀区搬到朝阳区,则对数据库的修改将变得麻烦,数据库不同表中的相应数据也难以保持一致。

    第一范式是关系型数据库的基本要求。

    第二范式

    第二范式是在第一范式的基础上进行定义的,首先要求每个属性都是不可再分的原子属性,其次要求每个非主属性都要完全函数依赖于码。换句话说将一范式的数据库模式消除部份依赖就可以产生第二范式。

    假设有这样一组关系,r(学号,系,宿舍,课程号,分数),根据生活中经验积累,我们可以明确这个关系的主键是(学号,课程号),其中依赖关系是(学号,课程号)-->(系,宿舍,分数)。

    但是我们还可以发现其他的依赖关系,学号-->系,学号-->宿舍,这种模式可以通过如下的图形象的表示出来。 这样系和宿舍这两个属性对主键就存在部分依赖,他们都部分依赖于学号这个属性,而不是完全依赖于(学号,课程号)这两个属性,这种部分依赖是第二范式中着重要消除的依赖关系。

    这种依赖关系的存在会导致四种问题:

    1. 数据冗余

    2. 插入异常

    3. 删除异常

    4. 修改复杂,数据不一致

    学号 宿舍 课程号 分数
    20200301 计算机 01 200001 90
    20200302 计算机 01 200002 100
    20200401 电气自动化 01 20001 85

    从上面的示例表可以看到如下问题:

    • 系和宿舍显然出现了多次重复,数据冗余,占用数据库的存储空间。

    • 假如学校新开设一个人工智能系,还未对外招生,没有学生信息和课程信息,此时这条数据则因为缺少主键不能插入,产生插入异常。

    • 假如因为教育部的知识和学校的动态调整,将电气自动化系取消,学生分流向其他系,此时需要删除电气自动化系的记录,却将学号为20200401的学生从数据库中误删,导致学号信息丢失。

    面对这些第一范式存在的问题,根据第二范式的原则,我们将这个关系,分解成两个关系。

    可以在一定程度上解决第一范式的四个问题,但是那四个问题并没有完全解决,由此就产生了第三范式。

    第三范式

    为了进一步解决第二范式面对的数据冗余,插入删除异常等问题,提出了第三范式。 第三范式是在第二范式的基础上,消除第二范式中存在的传递依赖所得到的。也就是说,第三范式要求,该数据库的模式每个属性都是原子属性,非主属性对码都是完全函数依赖,非主属性不传递依赖于码。

    我们接着讨论上面分析的(学号,系,宿舍,课程号,分数)这个关系。经过第二范式已经分解成两个关系后,实际上,(学号,系,宿舍)中仍然存在一种函数依赖系-->宿舍,学号是这个关系的主属性,系和宿舍是非主属性,但是存在传递依赖关系,通过下图进行理解。

    针对这个问题,按照第三范式的原则,我们进一步对这个关系进行分解,进而消除传递依赖。

    通过这样分解,我们就能得到一个相对良好的数据库设计模式,可以解决大部分的数据冗余,插入删除异常,数据不一致的情况。但是实际上,第三范式仍然存在一些问题,还不是最严格的设计方案,更加严格的要求进而有BC范式,第四范式等等,感兴趣的同学可以深入研究,日后可以考虑出一起BC范式和第四范式的介绍。

    笔者水平有限,在理解前人的成熟知识的基础上写出这篇文章,谬误之处必定多多,还希望批评指针。进步的路上你我相伴才不会孤单。

    展开全文
  • 一、关系型数据库设计范式 范式:Normal Format,符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度 范式是离散数学里的概念 范式目标是在满足组织和存储的前提下使数据...

     

    一、关系型数据库设计范式

    范式:Normal Format,符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度

    • 范式是离散数学里的概念

    • 范式目标是在满足组织和存储的前提下使数据结构冗余最小化

    • 范式级别越高,表的级别就越标准

    • 目前数据库应用到的范式有以下几层

      • 第一范式:1NF

      • 第二范式:2NF

      • 第三范式:3NF

      • 逆规范化

    示例

    1、一张员工表

    工号

    姓名

    部门

    入职时间

    0001

    杨戬

    武装部

    0001-01-01

    0002

    李白

    书院部

    1500-12-12

    2、每个员工都是与部门挂钩的,但是部门不可能很多,所以上述表中会有很多数据重复,此时应该将部门单独维护出来,减少数据冗余

    部门编号

    部门名称

    1

    武装部

    2

    书院部

     

    工号

    姓名

    部门编号

    入职时间

    0001

    杨戬

    1

    0001-01-01

    0002

    李白

    2

    1500-12-12

    N个1和N个武装部占用的磁盘空间肯定是不一样的

    小结

    1、范式是一种数学理论,在关系型数据库上用来减少数据冗余

    2、满足的范式越多,越符合高标准表设计

    3、范式一共有6层,但是数据库的设计通常只要求满足3层即可

    1、第一范式1NF

    目标:了解第一范式的原理,掌握第一范式的实际应用

    概念

    第一范式:1NF,数据字段设计时必须满足原子性

    • 1NF要求字段数据是不需要拆分就可以直接应用

    • 如果数据使用的时候需要进行拆分那么就违背1NF

    步骤

    1、设计的字段是否在使用的时候还需要再拆分?

    2、将数据拆分到最小单位(使用),然后设计成字段

    3、满足1NF

    示例

    1、设计一张学生选修课成绩表

    学生

    性别

    课程

    教室

    成绩

    学习时间

    张三

    PHP

    101

    100

    2月1日,2月28日

    李四

    Java

    102

    90

    3月1日,3月31日

    张三

    Java

    102

    95

    3月1日,3月31日

    当前表的学习时间在使用的时候肯定是基于开始时间和结束时间的,而这种设计就会存在使用时的数据拆分,不满足原子性也就是1NF

    2、满足1NF的设计:字段颗粒度应用层最小(不需要拆分)

    学生

    性别

    课程

    教室

    成绩

    开始时间

    结束时间

    张三

    PHP

    101

    100

    2月1日

    2月28日

    李四

    Java

    102

    90

    3月1日

    3月31日

    张三

    Java

    102

    95

    3月1日

    3月31日

    小结

    1、1NF就是要字段数据颗粒度最小,保证数据取出来使用的时候不用再拆分

    2、1NF是满足数据表设计的最基础规范

    2、第二范式2NF

    目标:了解第二范式的原理,掌握第二范式的实际应用

    概念:

    第二范式:2NF,字段设计不能存在部分依赖

    • 部分依赖:首先表存在复合主键,其次有的字段不是依赖整个主键,而只是依赖主键中的一部分

    • 部分依赖解决:让所有非主属性都依赖一个候选关键字

      • 最简单方式:取消复合主键(一般选用逻辑主键替代,但是本质依然是复合主键做主),所有非主属性都依赖主属性(逻辑主键)

      • 正确方式:将部分依赖关系独立成表

    步骤

    1、表中是否存在复合主键?

    2、其他字段是否存在依赖主键中的一部分?

    3、如果存在部分依赖,将部分依赖的关系独立拆分成表

    4、满足2NF

    示例

    1、学生成绩表中学生和课程应该是决定性关系,因此属于主属性(主键)

    学生(P)

    性别

    课程(P)

    教室

    成绩

    开始时间

    结束时间

    张三

    PHP

    101

    100

    2月1日

    2月28日

    李四

    Java

    102

    90

    3月1日

    3月31日

    张三

    Java

    102

    95

    3月1日

    3月31日

    • 成绩是由学生和课程决定的,是完全依赖主属性

    • 性别只依赖学生(部分依赖)

    • 教室、开始时间和结束时间依赖课程(部分依赖)

    2、解决方案:将学生信息维护到一张表,课程信息维护到一张表,成绩表取两个表的主属性即可

    学生表

    Stu_id(P)

    姓名

    性别

    1

    张三

    2

    李四

     

     

     

    • Stu_id是姓名的代指属性(逻辑主键,本质主键是姓名)

    • 性别只依赖主属性

    课程表

    Class_id(P)

    课程

    教室

    开始时间

    结束时间

    1

    PHP

    101

    2月1日

    2月28日

    2

    Java

    102

    3月1日

    3月31日

     

     

     

     

     

    • Class_id是课程的代指属性(逻辑主键)

    • 教室、开始时间和结束时间都依赖课程(主属性)

    成绩表

    Stu_id(P)

    Class_id(P)

    成绩

    1

    1

    100

    2

    2

    90

    1

    2

    95

    • Stu_id和Class_id共同组成主属性(复合主键)

    • 成绩依赖Stu_id和Class_id本身,不存在部分依赖

    小结

    1、2NF是在满足1NF的前提之上的

    2、2NF的目标是取消表中存在的部分依赖

    • 主属性(主键)为复合主键才有可能存在

    • 解决方案就是让部分依赖存在的关系独立成表(学生表和课程表),不存在部分依赖关系的独立成表(学生成绩表)

    3、2NF可以实现很大程度的数据冗余减少

    3、第三范式3NF

    目标:了解第三范式的原理,掌握第三范式的实际应用

    概念

    第三范式:3NF,字段设计不能存在传递依赖

    • 传递依赖:字段某个非主属性不直接依赖主属性,而是通过依赖某个其他非主属性而传递到主属性之上

    • 传递依赖解决:让依赖非主属性的字段与依赖字段独立成表

    步骤

    1、确定表中的所有字段都是依赖主属性的

    2、如果存在不直接依赖主属性,而是通过依赖其他属性产生依赖的,形成独立的表

    3、满足3NF

    示例

    1、学生表:包括所在系信息

    学号(P)

    姓名

    专业编号

    专业名字

    1

    张三

    0001001

    软件工程

    2

    李四

    0001002

    土木工程

    • 姓名和专业编号都依赖于学号(为学号提供信息支持)

    • 专业名字依赖专业编号(为编号提供信息支持)

    • 专业名字间接依赖学号:传递依赖

    • 随着学生增加,专业名字会出现大量数据冗余

    2、解决方案:将存储传递依赖部分的字段(非主属性)独立成表,然后在需要使用相关信息的时候,引入即可

    专业表

    专业编号(P)

    专业名字

    0001001

    软件工程

    0001002

    土木工程

    • 即使有更多的信息为专业提供支持也不存在传递关系

    学生表

    学号(P)

    姓名

    专业编号

    1

    张三

    0001001

    2

    李四

    0001002

    • 姓名和专业编号都依赖学号(为学号提供信息支持)

    • 没有其他字段是通过非主属性(专业编号)来依赖主属性的:没有传递依赖

    • 学生再多,专业名字信息只需要维护一次,减少数据冗余

    小结

    1、3NF目的是为了解决非主属性对主属性的传递依赖

    2、让有关联关系的表独立成表就可以消除传递依赖,满足3NF

    4、逆规范化

    目标:了解逆规范化的概念,掌握逆规范化的应用

    概念

    逆规范化:为了提升数据查询的效率而刻意违背范式的规则

    • 逆规范化的目标是为了提升数据访问效率

    • 所谓逆规范化就是减少表之间的关联查询(效率降低),刻意增加数据冗余

    步骤

    1、表中部分数据来源于其他表(通常只需要其他表的某个简单数据)

    2、当前表会被高频次查询

    3、数据表数据量很大

    4、考虑使用逆规范化

    示例

    1、学生成绩表需要经常查询,而且数据量很大,但是:

    • 成绩表中只有学号,显示的时候需要学生姓名(去学生表中连表查询)

    • 成表表中只有课程号,显示的时候需要显示课程名(去课程表中连表查询)

    • 逆规范化:将学生姓名和课程名在表中冗余维护(不满足2NF)

    学号(P)

    学生姓名

    课程号(P)

    课程名字

    成绩

    1

    张三

    1

    PHP

    100

    1

    张三

    2

    Java

    90

    • 学生姓名部分依赖学号(主属性):不满足2NF

    • 学生姓名和课程名字会有大量数据冗余存在(不满足2NF导致)

    小结

    1、逆规范化只有在数据量大,查询效率低下的时候为了提升查询效率而牺牲磁盘空间的一种做法

    2、逆规范化后数据表的设计必然是不完全符合范式要求的(2NF/3NF)

    5、总结

    1、范式是关系型数据库设计借鉴用来减少数据冗余的

    • 1NF:数据字段的原子性,增强数据的可用性

    • 2NF:取消字段的部分依赖,建立数据的关联性,减少数据冗余

    • 3NF:取消字段的传递依赖,将相关实体独立划分,减少数据冗余

    • 逆规范化:为了提升数据访问效率,刻意增加数据冗余(磁盘空间利用率与访问效率的矛盾)

    2、在进行数据表设计的时候,需要严格遵循范式规范

    • 基于规范设计数据表

    • 在设计表中深入认知范式规范

    • 熟练的基于业务设计数据表

    二、表关系

    学习目标:了解MySQL中表设计关系,理解关系设计给数据库带来的方便,掌握表关系的应用实现复杂数据库设计

    • 一对一关系

    • 一对多关系(多对一)

    • 多对多关系

    概念

    表关系:一个表代表一个实体,实体之间都有关联关系的

    • 根据范式的要求来设计表关系,减少数据冗余

    • 根据实际需求来设计表关系,提升访问效率

    示例

    设计一个简单新闻管理系统的数据库

    • 新闻信息表:id、标题、内容、发布时间、作者id(作者表主属性)、分类id(分类表主属性)、阅读量、推荐数

    • 作者表:id、作者名字、作者来源id(来源表)

    • 来源表:id、来源名字、来源描述

    • 分类表:id、分类名字、分类级别(父分类id)

    • 评论表:id、评论人id(评论表)、评论时间、评论内容(不回复)

    小结

    1、表关系是体现数据实际联系的方式

    2、表关系的设计好坏直接关联数据维护的准确性、有效性

    3、良好的数据库设计有助于后期程序开发

    1、一对一关系

    目标:了解一对一关系的处理方式,掌握一对一关系的实体设计

    概念

    一对一关系:一张表中的一条记录与另外一张表中有且仅有一条记录有关系

    • 一对一关系通常是用来将一张原本就是一体的表拆分成两张表

      • 频繁使用部分:常用字段

      • 不常使用部分:生僻字段

      • 使用相同的主键对应

    • 一对一关系设计较多使用在优化方面

    步骤

    1、一张表的数据字段较多且数据量较大

    2、表中有部分字段使用频次较高,而另一部分较少使用

    3、将常用字段和不常用字段拆分成两张表,使用同样的主键对应

    示例

    1、学生信息表

    学号(P)

    姓名

    性别

    年龄

    身高

    体重

    籍贯

    政治面貌

    1

    张飞

    20

    178

    160

    农民

    2

    武则天

    21

    168

    110

    党员

    • 以上数据表信息字段较多

    • 姓名、性别、年龄属于常用字段,频繁查询

    2、一对一关系设计

    • 将常用字段取出,与学号组合成一张常用表

    • 将不常用字段取出,与学号组合成一张不常用表

    • 表与表数据对应关系:基于学号(唯一)是一对一关系

    常用表

    学号(P)

    姓名

    性别

    年龄

    1

    张飞

    20

    2

    武则天

    21

    不常用表

    学号(P)

    身高

    体重

    籍贯

    政治面貌

    1

    178

    160

    农民

    2

    168

    110

    党员

    小结

    1、一对一关系的核心是两张表中记录匹配有且仅有一条匹配

    2、一对一关系常用来进行分表,实现优化操作

    3、因为一对一关系表通常有相同信息作为匹配条件,所以查询方式也比较方便

    • 连表操作:利用共有信息进行匹配,一并查出一条完整信息

    • 多次查询:利用共有信息进行多表查询,利用程序组合成一条完整信息

    2、一对多关系

    目标:了解一对多关系的原理,掌握一对多关系的实体设计

    概念

    一对多关系:也叫多对一关系,一张表中的一条记录与另外一张表的多条记录对应,反过来另外一张表的多条记录只能对应当前表的一条记录

    • 一对多关系是实体中非常常见的一种关系,实体设计时也应用非常多

    • 一对多关系的核心解决方案是如何让记录能够正确匹配到另外表中的数据

      • 一表设计:一表记录在另外一张表中有多条记录,所以无法记录多个字段(违背1NF)

      • 多表设计:多表记录在另外一张表中只有一条记录,可以设置字段记录对应的主属性(通常主键)

    步骤

    1、确定实体间的关系为一对多(多对一)关系

    2、在多表中增加一个字段记录一表中对应的主属性

    示例

    1、老师与学科间的关系:一个老师只能教一个学科,但是一个学科有多个老师教授,学科与老师形成的关系就是一对多(反过来老师与学科的关系就是多对一关系)

    老师表(多表)

    老师ID(P)

    姓名

    年龄

    性别

    1

    张老师

    35

    2

    李老师

    34

    3

    王老师

    30

    学科表(一表)

    学科ID(P)

    名字

    课时长度

    1

    PHP

    600

    2

    Java

    800

     

     

     

    • 以上两个实体没有体现彼此之间的关联关系

    • 实际上讲师与学科肯定是有关联的

    2、在多表(讲师)中增加字段维护一表(学科)的关系型,形成多对一关系

    老师ID(P)

    姓名

    年龄

    性别

    学科ID

    1

    张三

    35

    1

    2

    李四

    34

    1

    3

    王五

    30

    2

    • 基于新的讲师表与学科表产生了关联关系(多对一)

    • 基于讲师表可以知道讲师所属学科

    • 基于学科ID可以统计出不同学科的讲师数量

    小结

    1、一对多关系设计是将实体的关系在表结构层进行强制关联(没有关系程序层也可以控制,但是会非常麻烦)

    • 便于连表操作

    • 便于数据分析统计(数据库层)

    2、一对多关系的核心在于分析出表与表之间的关系

    3、多对多关系

    目标:了解多对多关系的处理方式,掌握多对多关系的实体设计

    概念

    多对多关系:一张表中的一条记录对应另外一个表中多条记录,反过来一样

    • 多对多关系在实体中是最常见的关系

    • 多对多关系是无法在自身表中维护对应表关系的(违背1NF),需要通过第三方表来实现将多对多关系变成多个多对一关系

      • 设计一个中间表:记录两张表之间的对应关系(主属性)

      • 中间表与其他表都是多对一的关系

    步骤

    1、确定实体间的关系为多对多关系

    2、设计中间表,记录两张表的对应关系

    示例

    1、老师与学生之间的关系:一个老师会教授多个学生,一个学生也会听多个老师的课,所以实体关系是多对多关系

    老师表

    老师ID(P)

    姓名

    年龄

    性别

    1

    张老师

    35

    2

    李老师

    34

    3

    王老师

    30

    学生表

    学生ID(P)

    姓名

    年龄

    性别

    1

    小明

    15

    2

    小红

    14

    3

    小萌

    14

    • 以上实体没有从结构上体现表之间的关系

    2、设计一个中间表:老师与学生关系表,将老师与学生的对应关系对应上(多对一)

    中间表

    ID(P)

    学生ID

    老师ID

    1

    1

    1

    2

    1

    2

    3

    1

    3

    4

    2

    1

    5

    2

    2

    6

    2

    3

    7

    3

    1

    8

    3

    3

    • 中间表与老师表的对应关系是多对一:通过老师ID可以找到每一个上过课的老师

    • 中间表与学生表的对应关系是多对一:通过学生ID可以找到每一个听过课的学生

    • 老师找学生:老师表--》中间表(找出老师对应的学生ID)--》学生表(找出学生ID对应的学生信息)

    • 学生找老师:学生表--》中间表(找出学生对应的老师ID)--》老师表(找出老师ID对应的老师信息)

    小结

    1、多对多关系在表上不能直接维护(字段设计违背1NF)

    2、多对多关系是将关系抽离形成中间关系表,形成多个多对一的关系

    3、多对多关系是否建立主要看业务上是否存在数据要求,如果不存在数据需求,那么就没必要刻意设计

    4、总结

    1、表关系的设计是要遵循范式规范作为前提

    2、表关系的设计是根据实体关系以及业务需求进行设计

    • 一对一关系:主要在于优化访问效率、传输效率

    • 一对多关系:在于如何让实体间的联系在结构中体现(后期可以使用外键进行相关约束保证数据的有效性)

    • 多对多关系:与一对多关系一样,清晰明了的体现实体间的结构联系

    3、在设计数据库的时候,要严格使用表关系来进行实体关联设计

    • 基于表关系来实现实体间的关联控制

    • 在设计和应用表的时候提炼对表关系的认知

    • 能够熟练的基于业务控制数据库的关系

     

    展开全文
  • 数据库范式

    2018-10-24 19:16:41
    设计数据库步骤、 一、建模(构建模型):收集信息、绘制E-R图 二、用数据模型建表 三、规范化(运用三范式) 三范式: 1、确保列的原子性,避免冗余,维护数据的完整性 2、使每列都和主键关联 3、使每列都和主键有...
  • 范式是关系型数据库的设计标准,范式分别有第一范式,第二范式,第三范式,BCNF范式(是在第三范式的补充和修订),第四范式和第五范式, 第一范式 数据库表中的字段都是单一属性的,不可再分。这个单一属性...
  • 数据库——范式判断类 题型、解题的套路、步骤

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

    千次阅读 2015-11-26 16:33:30
    第一范式( 1NF ):属性不可分; 第二范式(2NF):符合1NF,并且,非主属性完全依赖于主键,而不是依赖于部分主键属性; 第三范式(3NF):符合2NF,并且,消除传递依赖; BC范式(BCNF):符合3NF,并且,主属性...
  • 在了解范式之前我们先了解下数据库中关于码的概念 1.码 1.超码 能够唯一标识元组的某一属性或属性组,任何包含超码的超集也是超码,这里唯一标识元组可以简单的理解为根据某一个字段或几个字段的值,查询出某一行...
  • 数据库范式的理解

    2018-09-05 16:58:46
    规范化是一些步骤的序列,通过这些步骤创建和改进关系数据库模型,规范化过程中的步骤序列称为范式。 为什么要规范化 ? 规范化可简化复杂的数据建模过程 第一范式概念: 如果一个关系模式R的所有属性都是不可分...
  • 摘:数据库范式

    2019-03-06 16:02:08
    同一个项目,很多人参与了需求的分析数据库的设计,不同的人具有不同的想法,不同的部门具有不同的业务需求,我们以此设计的数据库将不可避免的包含大量相同的数据,在结构上也有可能产生冲突,在开发中造成不便。...
  • 数据库结构优化目的: 减少数据冗余 尽量避免数据维护中出现更新,插入和删除异常 插入异常:如果表中的某个...数据库结构优化设计步骤: 需求分析:全面了解产品设计的存储需求、存储需求、数据处理需求、数...
  • 数据库设计 范式 规范化实例

    千次阅读 2008-07-29 10:07:00
    设计范式范式,数据库设计范式,数据库的设计范式)是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则。在关系数据库中,这种规则就是范式。关系数据库中的关系必须满足一定的要求,即满足不同的范式...
  • 数据库——范式判断实例

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

    千次阅读 2020-08-24 20:04:52
    在关系型数据库中这种规则就称为范式范式是符合某一种设计要求的总结。,以提升数据库的存储效率、数据完整性和可扩展性。 第一范式:确保每列保持原子性 要求: 要求每一列都是不可分割的原子属性。 要求不...
  • 1.需求分析:全面了解产品设计的存储需求 存储需求:数据库需要存储什么样的数据,数据具有什么样特点 数据处理需求:我们需要如何对数据库进行读取或修改以完成产品设计的功能,已经对数据处理的响应时间有什么...
  • 一、基础概念 实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看...在关系数据库中,属性又是个物理概念,属性可以看作是“表的
  • 关于Oracle数据库的学习记录:五十、数据库设计范式对于任何一个软件项目开发而言,都一定会经历以下几个步骤:**获取需求阶段**需求分析与业务设计**数据库设计**程序开发与业务实现**程序的测试**程序的运维对于...
  • 数据库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...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 17,964
精华内容 7,185
关键字:

数据库分析范式类型步骤