数据库笔记

习题

  • 如何构造出一个合适的数据逻辑结构是_____C_______主要解决的问题。

    A.关系数据库优化 B.数据字典

    C.关系数据库规范化理论 D.关系数据库查询

关系数据库规范化理论,一个关系数据库模式由一组关系模式组成,一个关系模式由一组属性名组成。关系数据库设计,就是如何把已给定的相互关联的一组属性名分组,并把每一组属性名组成关系的问题。然而,属性的分组不是唯一的,不同的分组对应着不同的数据库应用系统,它们的效率往往相差很远。为了使数据库设计合理可靠,简单实用,长期以来,形成了关系数据库设计的理论——规范化理论。
关系数据库的优化是一个和实际数据库结构密切相关的问题,在实际应用中应该结合具体的数据库服务器,深入的理解服务器的运作模式、资源配置,优化服务器的运行环境,选择合适的操作系统,最大限度的发挥服务器的性能。
数据字典是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述,其目的是对数据流程图中的各个元素做出详细的说明。 其关注点是在数据项、数据元素上。
关系数据库查询,是通过查询语言(SQL),从关系数据库中查找符合查询条件信息的过程。

1概论

三级模式结构,外模式、模式和内模式

  • 模式也称为逻辑模式,对应于逻辑层数据抽象,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。
  • 外模式也称子模式或用户模式,对应于视图层数据抽象,是数据库用户(包括应用程序员和最终用户)能够看见和使用的局部数据的逻辑和特征的描述。
  • 内模式称为存储模式,对应于物理层数据抽象,是数据的物理结构和存储方式的描述,是数据在数据库内部的表示方式。

4数据库建模

矩形表示实体集、椭圆表示属性、双椭圆表示多值属性、菱形框表示联系集、双矩形表示弱实体集、双菱形表示表示实体集、虚下划线表示弱实体集部分码,ISA为“is a”表示父类-子类联系,内部包含菱形框的带填充背景的矩形表示联系实体集,

→表示指向参与联系集中的“一”方实体集,—表示参与联系集中的“多”方实体集

约束

映射约束

一对一

一对多

多对多

码约束

多值属性

1可以转化为多个单值属性

2将多值属性单独建模为一个弱实体集

主码

选取原则:

  • 属性长度最短的候选码
  • 包含单个属性的码,而不是复合候选码
  • 在数据库系统生命周期内属性值最少变化的候选码
  • 在数据库系统生命周期内更可能包含唯一值的候选码
联系集的主码和属性安置

二元联系集主码依赖于联系集的映射基数

  • 一对一联系集:主码使用任何一方实体集的主码
  • 一对多(多对一)联系集:主码由“多”的一方实体集的主码组成
  • 多对多联系集:主码由参与实体集中所有实体集的主码组成
二元联系集 主码 属性安置
一对一联系集 任何一方 任一边的实体集上
一对多(多对一)联系集 “多”方 联系集或“多”方上
多对多联系集 所有实体集的主码 只能在联系集上

例如

将聘用日期直接定义为多方实体集教师的属性。

依赖约束

两种:

  • 依赖实体集:实体集依赖于联系集
  • 弱实体集:实体集依赖于另一个实体集

参与约束

如果实体集A中只有部分实体参与到联系集R的联系中,则称实体集部分参与到联系集R的联系中。每个实体都参与则为全部参与。

全部参与双实线表示

弱实体集

弱实体集:其属性不足以形成主码,必须依赖于其他实体集的存在而存在

强实体集:可以形成主码的实体集称为强实体集

标识实体集:弱实体集所依赖的实体集称为标识实体集

联系实体集:聚合功能将一个联系集及其相关联的实体集抽象为联系实体集(高层实体集)对待,然后建立该联系实体集与其他实体集之间的联系集

ER建模问题

ER建模的基本原则

  • 忠实性

    • 实体集、联系集、属性都应当反映现实世界,根据事实建模
  • 简单性

    • 非必须不增加更多成分
    • 只需对数据库使用者感兴趣的属性建模,例如教师联系集中没必要将身高作为属性
  • 避免冗余

    • 原则:一个对象指存放在一个地方
  • 选择实体集还是属性

    • 作为属性:①属性不可分②属性不能和其他实体相联系
    • 对于复合属性,可将该复合属性的每一个子部分直接建模为一个属性,而不必建模为实体集。例如“家庭住址”可分成“省份”、“城市”、“街道”三个部分
  • 选择实体集还是联系集

    • 实体对应现实世界中实际存在的事物,是名词
    • 联系对应一般为一种动作,即描述实体间的一种行为
  • 多元联系转化为二元联系

    • 大部分情况下是建立一个依赖实体集或弱实体集,再与原实体集之间建立二元联系。

5关系数据理论与模式

属性集闭包,由A函数确定的所有属性的集合

问题

数据冗余导致的问题

拿表举例:字段 studentNo studentName courseNo courseNo score

  • 冗余存储
    • 浪费大量存储空间
    • 学生姓名和课程名被重复存储多次
  • 更新异常
    • 重复的副本被修改后,所有副本都必须进行同样的修改
    • 修改的时候只修改了部分副本的学生姓名或课程名
  • 插入异常
    • 只有当一些信息事先已经存放在数据库中时,另外一些信息才能存入数据库中
    • 如果学生没有选修课程,那不能将他的信息插入,因为会违背实体完整性原则
  • 删除异常
    • 删除某些信息时可能丢失其他信息
    • 当一个学生的所有选修课程信息都被删除时,该课程的信息也会被丢失

模式分解导致的问题

分解后的模式是否具有无损连接保持依赖等特性

无损连接:能够通过连接分解后所得到的较小关系完全还原被分解关系的所有实例,称为无损连接。

有损连接:无法完全还原回的

保持依赖:分解之后,主码和其他的属性要在同个关系模式中,可以理解为原本属性都依赖主码,分解后,属性依旧依赖于主码。所有依赖关系都应该在分解得到的关系模式中保留。

  • 关系就是一个二维表

  • 关系模式:用来定义关系

    • Student(Sno,Sname) 就是对关系表的描述,这是R(U)形式
    • 五元组,R(U,D,DOM,F),R关系名,U组成该关系的属性名集合,D属性组U中属性所来自的域,DOM属性向域的映像集合,F属性间数据的依赖关系集合。一般用R(U),R(U,F)表示
  • 关系数据库:基于关系模型的数据库,用关系描述现实世界

  • 关系数据库的模式:定义这组关系的全体

  • 数据依赖

    • 完整性约束,实体完整性,参照完整性,用户自定义完整性

    • 表现形式:

      • 限定属性取值范围
      • 定义属性值间的相互关联(值相等与否),这就是数据依赖,是数据库模式设计的关键
    • 主要类型

      • 函数依赖FD
      • 多值依赖
      • 连接依赖
  • 关系模式的简化表示

    • 关系模式简化为三元组R(U,F) R关系模式,二维表是关系
    • 当且仅当U上的一个关系r满足F(数据依赖)时,r称为关系模式R(U,F)的一个关系
  • 规范化理论

    • 用来改造关系模式
    • 判断数据依赖是否存在是否存在不合适的地方,通过分解消除其中不合适的数据依赖
    • 解决插入异常、删除异常、更新异常和数据冗余问题

函数依赖

在关系模式R的任意一个可能的r,每一个X对应一个Y则X决定Y,称X确定Y,或Y函数依赖于X,X→Y

如学号决定性别,学号决定年龄,姓名决定性别,姓名决定年龄(不同名);不存在学号相等的情况下性别不等,反过来不一定成立

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

X→Y,当Y不包含于X,则称为非平凡依赖,若Y包含于X则为平凡依赖

  • 例如关系模式SC(Sno,Cno,Grade)
    • 非平凡依赖:(Sno,Cno)→Grade,一个学号和的一门课程对应一个唯一的成绩,Grade不包含于(Sno,Cno)中
    • 平凡依赖:(Sno,Cno)→Sno和(Sno,Cno)→Cno,学号可课程号可以确定唯一学号/课程号,后者包含于前者

完全函数依赖与部分函数依赖

  • 例如关系模式SC(Sno,Cno,Grade)
    • 完全函数依赖:(Sno,Cno)→Grade,只有学号加课程号才能决定成绩,单独的学号或课程号无法决定成绩Grade
    • 部分函数依赖,:(Sno,Cno)→Sno和(Sno,Cno)→Cno,其中一个真子集可以决定

传递函数依赖

借助中间的Y

  • 候选码:K为关系模式R(U,F)中的属性或属性组合,U完全依赖与K(K完全决定U),则K称为R的一个候选码。(K可以决定所有的其他属性,且它本身不含多余值)
  • 若关系模式R有多个候选码,则选定其中一个作为主码
  • 候选码能够唯一地标识一个关系的元组
  • 主码又和外码一起提供了一个表示关系间联系的手段
  • 组成候选码的属性叫做主属性,其他的就是非主属性

范式

关系数据库的关系满足一定要求称为一种范式

第一范式1NF

是最基本的要求,R的所有属性都是不可分的基本数据项

部分函数依赖使得不是一个好的模式——要分解

image-20230429215614925

(Sno,Cno)能决定其他全部属性,但是是一个部分函数依赖,分解成下图:

但是这样还是不够好,SC是好的,SL中每一个学生都对应一个宿舍楼Sloc,2000个学生就有2000个宿舍,冗余了,因此要求要再严格些

第二范式2NF

SL仍有异常,因为存在传递依赖,分解掉

第三范式3NF

上面的例子中,SL属于第二范式2NF,但是有传递函数依赖,去掉之后得到SD、DL,消除了函数依赖

注意定理中,第三范式还是建立1NF基础上而不是2NF,其实3NF是一种特殊的2NF,是3NF则一定是2NF

若R∈3NF,则R的每一个**非主属性不部分函数依赖于**候选码不传递函数依赖于候选码。解决的是非主属性,但仍存在问题

BC范式(BCNF) 候选码一定包含在左端!

修正的第三范式

如果一个关系模式R(属于第一范式)写出来的所有函数依赖X→Y,左边X都含有候选码,R是BC范式。

  • BCNF的关系模式所具有的性质
    • 所有非主属性都完全函数依赖于每个候选码
    • 所有主属性都完全函数依赖于每个不包含它的候选码
    • 没有任何属性完全依赖于非码的任何一组属性
  • BC范式与第三范式的关系
    • BC一定是第三,第三不一定是BC(因为第三只规定了非主属性)
    • 如果R是第三范式,且R只有一个候选码,则R必属于BCNF。(一般情况下关系模式有一个候选码,第三范式就满足了BC范式)
  • BC是最高等级了,消除了异常
  • BCNF范式排除了:
    • 任何属性(包括主属性和非主属性)对候选码的部分依赖和传递依赖
    • 主属性之间的传递依赖。

例子:

这题中关系模式只有三个属性,(S,C)→T,(S,T)→C,则这两个都是候选码,S、T、C都是主属性,所以也满足第三范式即STC∈3NF

但是不是BCNF,因为(S,T)→C同时T→C,主属性部分依赖于码(S,T)因此还需要分解才能变成BC范式。

对比3NF和BCNF

  • BCNF比3NF严格。
    • BCNF要求所有的非平凡函数依赖中的是超码,而3NF则放松了该约束,允许不是超码。
    • 若关系模式属于BCNF范式就一定属于3NF范式。反之则不一定成立。
  • 3NF存在数据冗余和异常问题,而BCNF是基于函数依赖理论能够达到的最好关系模式。
  • BCNF范式分解是无损分解,但不一定是保持依赖分解; 而3NF分解既是无损分解,又是保持依赖分解

规范化

范式 特征
1NF 所有的数据项不能再分
2NF 消除非主属性对码的部分函数依赖
3NF 消除非主属性对码的传递函数依赖
BCNF 函数依赖左端属性集一定包含候选码

函数依赖理论

函数依赖集闭包(重要概念)

  • 定义5.11 若给定函数依赖集F,可以证明其他函数依赖也成立,则称这些函数依赖被F逻辑蕴涵。
  • 定义5.12 令F为一函数依赖集,F逻辑蕴涵的所有函数依赖组成的集合称为F的闭包,记为F+。
  • 函数依赖集F的闭包计算方法
    • Armstrong公理的推理规则

属性集闭包(重要概念)

无损连接分解

表格判断法

image-20230623110907566

保持依赖分解

候选码的计算

把左边写出来,右边写出来,重复的删去,只在左边出现一定是候选码,右边出现的一定不是候选码

如果能推出来全体,则为唯一候选码

当去重的左边不能推出全部的时候,从不确定的中任取一个加入到左边的

8数据库存储结构与查询

启发式优化策略

  • 尽早执行选择操作
  • 尽早执行投影运算