一文学明白数据库系统--数据库系统期末复习--从入门到入考场--考前抄ppt系列

绪论

• 数据管理
  • 数据是能够被记录且有实际含义的已知事实
  • 基于文件系统的数据管理办法 vs 基于数据库管理系统的数据管理办法
    • file system：数据存储于文件中，数据由应用程序经过文件系统进行管理；需要查询数据时，编写应用程序进行查询；但是文件格式一变化就要修改应用程序，文件中存在冗余数据，文件修改可能造成数据不一致并且破坏数据的正确性，没有索引导致数据访问效率很低，对整个文件进行访问导致数据安全性差，并发控制不行导致读写经常出问题
  • 数据管理做什么
    • 数据定义：定义数据的结构、类型以及约束
    • 数据存储：存储和存取数据
    • 出局操纵：查询数据、更新数据（增删改）
    • 数据共享：事务管理、并发控制、故障恢复
    • 数据控制：保证数据完整性、数据安全性
    • 数据维护：数据录入、数据转换、数据备份、数据恢复、性能监控
• 数据库系统
  • 数据库：一个数据库是一个有组织的、可共享的、可持久化的关系数据的集合
  • 数据库管理系统：一个数据管理系统是一种通用软件，可以在不同用户和软件之间促进数据库的组织、存储、操纵、控制和维护
  • 数据库用户
    • 数据库管理员：授权数据库访问，协调和监控数据库使用，获取软硬件资源，控制资源的使用，监控数据库性能
    • 数据库设计者：负责定义数据库的内容、结构、约束、存储过程和事务
    • 终端用户：查询数据库，生成报表，部分终端用户还可以修改数据库内容
  • 数据库系统：是由数据库、数据库管理系统、应用程序和数据库用户在一起构成的系统
• 数据独立性
  • 数据抽象是将现实世界映射到计算机世界的过程
  • 数据模型是完成数据抽象的工具
    • 数据模型的三要素
      • 用于描述数据库的结构的一系列概念
      • 用于操纵数据结构的一系列操作
      • 数据库应当服从的约束条件
    • 数据模型的分类
      • 概念数据模型：该模型提供的概念最接近用户理解数据的方式，用于将现实世界映射到信息世界
      • 物理数据模型：该模型提供的概念用于描述数据库在计算机中的存储细节
      • 实现数据模型：该模型处在概念数据模型和物理数据模型之间，在实现DBMS时使用，例如关系数据模型
  • 数据库模式是对数据库的结构、类型、约束的描述，数据库实例是数据库在某一特定时间存储的数据
    • 数据库的三层模式结构：数据库不是只用一种模式来描述的，数据库模式分三个层次来定义
      • 内模式/存储模式：描述数据库的物理存储结构和存取方法，数据库只有一个内模式，定义内模式时通常使用物理数据模型提供的概念
      • 概念模式：为全体数据库用户描述整个数据库的结构和约束，数据库只有一个概念模式，定义概念模式时使用实现数据模型提供的概念
      • 外模式/视图：从不同类别用户的视角描述数据库的结构，数据库可以有多个外模式，定义外模式时也使用实现数据模型提供的概念
  • 模式映射
    • 在三层模式结构中，不同层次模式间的映射用于完成应用程序与数据库之间的数据转换和请求转换
      • 请求转换：应用程序是依据外模式开发的，应用程序在外模式上声明的数据请求通过模式映射转换为DBMS在内模式上的请求
      • 数据请求：是请求转换的逆过程，数据库的物理存储是按照内模式来组织的，DBMS检索到的数据通过模式映射转换为符合外模式的组织形式，返回给应用
    • 模式映射的分类
      • 外模式-概念模式映射
      • 概念模式-内模式映射
  • 数据独立性
    • 逻辑数据独立性
      • 当概念模式发生改变时，只需要修改外模式到概念模式的映射
      • 外模式无需改变，依据外模式开发的应用程序也无需改变
    • 物理数据独立性
      • 当内模式发生改变时，只需概念模式到内模式的映射
      • 概念模式和外模式无需改变，依据外模式开发的应用程序也无需改变
• 数据库语言
  • 数据库语言是用户/应用程序与DBMS交互时所使用的语言
    • 数据定义语言：数据库设计者用来声明数据库模式的语言
    • 数据操纵语言：查询和更新数据库时所使用的语言
  • 数据库查询：DML通常是描述式的，用它编写的数据库查询只描述查询意图，而不指明查询执行过程，DBMS自动生成最优的查询计划，然后在数据库上执行查询计划
• 事务处理
  • 事务：事务是由数据库上的一系列操作完成的复杂任务，这些造作要么全执行，要么全不执行。例如：银行转账、在线购物、会议室预定
  • 事务具有acid四个性质：原子性，一致性，隔离性，持久性
  • 并发控制：为了充分利用数据库系统，允许多个事务在数据库上并发执行，多个事务并发执行可能会破坏数据库的一致性，并发控制确保多个事务并发执行不会破坏数据库的一致性
  • 故障恢复：故障可能在事务执行过程中发生，从而破坏数据库的一致性，故障恢复确保系统重启后数据库可以恢复到最近的一致性状态

关系数据库

• 关系数据模型：这是一种被广泛使用的实现数据模型，是众多关系数据库管理系统的模型基础
  • 关系数据结构：关系数据模型使用唯一的数据结构就是关系
    • 关系的定义：设$D_1,\cdots,D_n$D1​,⋯,Dn​是$n$n个值域，$D_1\times \cdots\times D_n$D1​×⋯×Dn​的子集$R$R称作这$n$n个域上的关系，记作$R(D_1,\cdots,D_n)$R(D1​,⋯,Dn​)，其中$R$R是关系名，$n$n是关系的度
    • 正确性：$D_1\times \cdots\times D_n$D1​×⋯×Dn​的任意子集都是关系，但未必都是正确的关系，只有复合客观事实的关系才是正确的关系
    • 关系的属性：由于域可能相同，为了加以区分，可为关系的每个域起一个名字，称作属性
    • 关系的键：关系的某些属性集合具有区分不同元组的作用，称作键
      • 超键：如果关系的某一组属性的值能唯一标识每个元组，则称该组属性为超键
      • 候选键：如果一个超键的任意真子集都不是超键，则称该超键为候选键，也就是极小超键
      • 主键：每个关系中都有至少一个候选键，人为指定其中一个作为主键
      • 外键：不同关系中的元组可以存在联系，这种联系通过外键建立起来。设$F$F是关系$R$R的属性子集，若$F$F与关系$S$S的主键$K$K相对应，则称$F$F是$R$R的外键
  • 关系操作：增删查改
  • 关系完整性约束：关系数据库中所有数据必须满足的约束条件
    • 实体完整性：关系中任意元组的主键值必须唯一且非空
    • 参照完整性：针对的是外键，设$F$F是关系$R$R的外键，$F$F参照关系$S$S的主键，则$R$R中任意元组的$F$F属性值必须满足以下两个条件之一：1. $F$F的值为空，2. 若$F$F的值不为空，则$F$F的值必须在$S$S中存在
    • 用户定义完整性：自定义约束条件
• 关系代数：关系代数是一种使用关系代数操作表达式来表示查询的语言，明确给出了查询的执行过程
  • 基本关系代数操作：选择、投影、并、差、笛卡尔积、重命名
  • 派生关系代数操作：交、$\theta$θ连接、自然连接，外连接（左外连接、右外连接、全外连接）、除
  • 扩展关系代数操作：分组、赋值
• 关系演算
  • 元组关系演算：用形如$\{t|P(t)\}${t∣P(t)}的表达式标识查询
  • 域关系演算：表达式与元组关系演算表达式的定义类似，不同之处是表达式中使用域变量

结构化查询语言

• sql数据定义
  • 基本数据类型
    • 数值型
      • 整型：integer或int（4字节），smallint（2字节），tinyint（1字节），mediumint（3字节），bigint（8字节）
      • 定点型：decimal（p,s）,numeric(p,s)
      • 浮点型：float是单精度4字节，double是双精度8字节
      • 二进制数型：bit（b）表示b位二进制数(1<=b <= 64)
    • 日期时间型：year（YYYY），date（YYYY-MM-DD），time（HH：MM：SS），datetime（YYYY-MM-DD HH：MM：SS），timestamp（YYYY-MM-DD HH：MM：SS）
    • 字符串型：char（n）是定长字符串，varchar(n)是变长字符串，text类型：有tinytext（L<=512B）,text（L<=$2^{16}$216）,tinytext（L<=$2^{24}$224B）,tinytext（L<=$2^{32}$232B）
    • 二进制串：binary(n)是定长二进制串，varbinary（n）是变长的，blob是二进制对象型，也分为tiny、blob、medium和long
    • 枚举类型：值列表中最多包含65535个不同的值，如果值列表中包含至多255个值，则占1字节，否则占2字节
    • 集合型：存储为二进制数，对于集合SET(‘Mercury’, ‘Venus’, ‘Earth’, ‘Mars’），'Mercury,Earth’存储为0101
  • 创建关系模式：使用create table创建关系模式，使用primary key声明主键，使用foreign key声明外键，使用not null、unique、auto_increment、default、check(expression)声明用户定义完整性约束
  • 修改关系模式使用alter table
  • 删除关系模式使用drop table 关系名1，关系名2
  • 定义视图使用create view、alter view、drop view，查询的话就把创建的视图当作一张表来用就行
• sql数据更新
  • 插入
  • 修改
  • 删除
  • 数据完整性检查
• sql数据查询（自己找几个题目看一下就行了）
  • 单关系查询
  • 连接查询
  • 嵌套查询

概念数据库设计

• 数据库设计的过程
  • 数据密集型应用的设计有两个主要任务：数据库设计和应用程序设计
  • 具体过程
    • 概念设计：设计数据库的抽象概念模式
    • 逻辑设计：根据所使用的DBMS，设计数据库的逻辑模式
    • 物理设计：根据性能需求和应用访问数据库的特点，设计数据库的物理模式
• 实体-联系模型（ER模型）
  • 简称ER模型，是概念数据库设计阶段使用的一种重要的概念模型，用于将现实世界抽象为实体以及实体间的联系
  • 与实体相关的概念
    • 实体：数据库中表示的现实世界中的具体对象或事物
    • 属性：用于刻画实体的特性
      • 简单属性：具有原子属性值的属性，其属性值不可再分
      • 复合属性：由多个成分构成的属性
      • 多值属性：一个实体可具有多个值的属性
      • 派生属性：由其它属性派生出来的属性
      • 键属性：可以用于区分同一实体型的任意实体，可以是复合属性，一个实体型可以有多个键属性
    • 实体型与实体集
      • 实体型：具有相同属性的实体共同具有的类型
      • 实体集：当前存储在数据库中的某实体型的实例的集合
      • 实体 vs 实体型 vs 实体集：对象，类，对象集
    • 弱实体型与弱实体集
      • 弱实体型：没有键属性的实体型，必须全部参与到标识联系型中
      • 标识实体型/属主实体型：由于弱实体型没有键属性，需要依赖于其它实体型进行区分，比如实验室是依靠实验室主任区分的
      • 标识联系型：弱实体型与其标识实体型通过标识联系型关联
      • 部分键：用于区分和同一标识实体相关联的弱实体的属性集合
      • 使用“弱实体型的部分键和标识实体型的主键”来区分不同弱实体
  • 与联系相关的概念
    • 联系：一个联系标识多个实体之间有意义的关联关系
    • 联系型：同一类联系共同具有的类型
    • 联系型的度：参与到一个联系型重点额实体型的个数
    • 联系集：数据库中当前存储的联系型的实例的集合
    • 联系型的约束
      • 基数比：1对1，多对1，多对多
      • 存在依赖约束/参与度约束：刻画实体型参与到联系型中的最小基数
    • 联系型的属性
      • 联系型的属性主要出现在M：N联系型中，N：1联系型的属性可以被移到N一方的实体型中
    • 多元联系
      • 三个以上实体参与的联系
      • 一个n元联系和n个二元联系所表示的意义通常是不同的
• 增强实体-联系图（EER图）
  • 子类/超类
    • 实体型E的一部分实体构成了一个有特殊含义的子集，这部分实体的实体型E‘称为E的子类，同时E称为E’的超类
    • 子类继承了父类的全部属性以及父类所参与的全部联系型
  • 不相交子类
    • 如果超类的每个实体属于最多一个子类，则子类是不相交的
  • 重叠子类
    • 如果超类的每个实体可以属于多个子类，则子类是重叠的
  • 全部特化
    • 超类的每个实体必须属于至少一个子类
  • 部分特化
    • 超类的某i额实体可以不属于任何子类

逻辑数据库设计

• ER模型转换为关系模式数据库模式
  • 实体型
    • 实体型的名称$\rightarrow$→关系名
    • 实体型的属性集$\rightarrow$→关系的属性集（多值属性除外）
    • 实体型的主键$\rightarrow$→关系的主键
    • 实体$\rightarrow$→元组
  • 复合属性：复合属性的最低级组成成分$\rightarrow$→关系的属性
  • 多值属性
    • 实体型关系的属性集中不包含多值属性
    • 多值属性$\rightarrow$→关系
    • 将实体型的主键并入多值属性关系中
    • 建立多值属性关系到实体型关系的外键约束
  • 弱实体型
    • 弱实体型的名称$\rightarrow$→关系名
    • 弱实体型的属性集$\cup$∪属主实体型的主键$\rightarrow$→关系的属性集
    • 属主实体型的主键$\cup$∪弱实体型的部分键$\rightarrow$→关系的主键
    • 建立弱实体型关系到主实体型关系的外键约束
  • M:N二元联系型的转换
    • 联系型的名称$\rightarrow$→关系名
    • 实体型1的主键$\cup$∪实体型2的主键$\cup$∪联系型的属性集$\rightarrow$→关系的属性集
    • 实体型1的主键$\cup$∪实体型2的主键$\rightarrow$→关系的主键
    • 建立联系型关系到实体型1关系的外键约束
    • 建立联系型关系到实体型2关系的外键约束
  • N:1二元联系型的转化
    • 将实体型2的主键和联系型的属性并入实体型1的属性集中
    • 建立实体型1关系到实体型2关系的外键约束
  • 二元自联系型的转换
    • 与不同实体型间二元联系型的转换方法相同
    • 对重名属性重命名
• 函数依赖
  • 数据依赖
    • 关系的属性在语义上的依赖关系
    • 关系模式中的不合理数据依赖会导致一系列问题
      • 数据插入异常：该插入的数据无法插入
      • 数据删除异常：不该删除的数据不得不删除
      • 数据修改繁琐：数据修改的非常繁琐，容易出错
      • 数据冗余
  • 函数依赖
    • 定义：设$R(U)$R(U)是属性集$U$U上的关系模式，$X,Y\subseteq U$X,Y⊆U。对于$R(U)$R(U)的任意关系实例中的任意两个元组$t_1,t_2$t1​,t2​，如果$t_1[X]=t_2[X]$t1​[X]=t2​[X]可以推出$t_1[Y]=t_2[Y]$t1​[Y]=t2​[Y]，则称$X$X函数决定$Y$Y，或$Y$Y函数依赖于$X$X，记作$X\rightarrow Y$X→Y。如果$Y$Y不依赖于$X$X，则记作$X \nrightarrow Y$X↛Y，如果$X\rightarrow Y$X→Y且$Y\rightarrow X$Y→X，则记作$X \leftrightarrow Y$X↔Y
    • 泛化规定
      • 函数依赖是关系模式的所有关系实例上都成立的依赖关系，不能只根据某些关系实例来确定依赖函数
      • 函数依赖是语义范畴的概念，只能根据数据的语义来确定函数依赖
      • 数据库设计者可以对现实世界做出强制规定
    • 类型
      • 平凡依赖函数：若$Y \subseteq X$Y⊆X，则$X\rightarrow Y$X→Y是
      • 非平凡依赖函数：若$Y \nsubseteq X$Y⊈X，则$X\rightarrow Y$X→Y是
      • 完全依赖函数：在关系模式$R(U)$R(U)中，如果$X\rightarrow Y$X→Y，且$\forall X'\subset X,X'\nrightarrow Y$∀X′⊂X,X′↛Y，则称$Y$Y完全函数依赖于$X$X，记作$X \overset{f}{\rightarrow}Y$X→fY
      • 部分函数依赖：在关系模式$R(U)$R(U)中，如果$X\rightarrow Y$X→Y，且$\exists X'\subset X,X'\rightarrow Y$∃X′⊂X,X′→Y，则称$Y$Y部分函数依赖于$X$X，记作$X \overset{p}{\rightarrow}Y$X→pY
      • 传递函数依赖：在关系模式$R(U)$R(U)中，如果$X\rightarrow Y$X→Y，$Y\rightarrow Z$Y→Z，且$Y\nsubseteq,Y\nrightarrow X$Y⊈,Y↛X，则称$Z$Z传递函数依赖于$X$X，记作$X \overset{t}{\rightarrow} Z$X→tZ
    • 公理系统
      • 逻辑蕴含：设$R(U,F)$R(U,F)是一个关系模式，其属性集为$U$U，函数依赖集为$F$F，若在$R$R的任意关系实例$r$r中，函数依赖$X\rightarrow Y$X→Y都成立，则称$F$F逻辑蕴含$X\rightarrow Y$X→Y，记作$F\models X\rightarrow Y$F⊨X→Y
      • 推理规则
        • 自反律：若$Y\subseteq X \subseteq U$Y⊆X⊆U，则$F\models X\rightarrow Y$F⊨X→Y
        • 增广律：若$F\models X\rightarrow Y$F⊨X→Y，则对任意$Z\subseteq U$Z⊆U，有$F\models XZ\rightarrow YZ$F⊨XZ→YZ
        • 传递律：若$F\models X\rightarrow Y,F\models Y\rightarrow Z$F⊨X→Y,F⊨Y→Z，则$F\models X\rightarrow Z$F⊨X→Z
      • 公理系统是正确的且完备的
        • 正确性：使用公理系统推出的任何函数依赖一定被$F$F逻辑蕴含
        • 完备性：任何被$F$F逻辑蕴含的函数依赖一定能够用公理系统推出
      • 导出规则
        • 合并规则：若$F\models X\rightarrow Y,F\models X\rightarrow Z$F⊨X→Y,F⊨X→Z，则$F\models X\rightarrow YZ$F⊨X→YZ
        • 伪传递规则：若$F\models X\rightarrow Y,F\models WY\rightarrow Z$F⊨X→Y,F⊨WY→Z，则$F\models XW\rightarrow Z$F⊨XW→Z
        • 分解规则：若$F\models X\rightarrow Y$F⊨X→Y，则$\forall Z\subseteq Y,F\models X\rightarrow Z$∀Z⊆Y,F⊨X→Z
    • 属性集的闭包
      • 定义：设$R(U,F)$R(U,F)是一个关系模式，集合$\{A|A\in U,F\models X\rightarrow A\}${A∣A∈U,F⊨X→A}称为$X$X关于$F$F的闭包，记作$X_F^+$XF+​
      • 定理：设$R(U,F)$R(U,F)是一个关系模式，$X,Y\subseteq U,F\models X\rightarrow Y$X,Y⊆U,F⊨X→Y的充要条件是$Y\subseteq X_F^+$Y⊆XF+​
      • 计算：初始化一个只包含自身的集合，迭代扩充该集合，每次迭代的增量为$B \gets \{A|V\rightarrow W\in F,V\subseteq X^{(i)},A\in W\}$B←{A∣V→W∈F,V⊆X(i),A∈W}
    • 等价函数依赖集
      • 函数依赖集的闭包：设$R(U,F)$R(U,F)是一个关系模式，由$F$F逻辑蕴含的全部函数依赖的集合叫做$F$F的闭包，记作$F^+$F+
      • 等价函数依赖集：设$F$F和$G$G是关系模式$R(U)$R(U)上的两个函数依赖集，如果$F^+=G^+$F+=G+，则$F$F于$G$G等价
      • 函数依赖集的覆盖：设$F$F和$G$G是关系模式$R(U)$R(U)上的两个函数依赖集，如果$G^+\subseteq F^+$G+⊆F+，则称$F$F覆盖$G$G
      • 定理：函数依赖集$F$F与$G$G等价，当且仅当$F$F覆盖$G$G且$G$G覆盖$F$F
      • 判定
        • 方法1：使用$F^+=G^+$F+=G+
        • 2：如果$F$F覆盖$G$G，且$G$G覆盖$F$F
    • 最小覆盖
      • 定义：关系模式$R(U)$R(U)的函数依赖集$F$F的最小覆盖是满足下列3个条件的$F$F的等价函数依赖集$F_c$Fc​
        • 不存在冗余函数依赖：$F_c$Fc​中不存在函数依赖$X\rightarrow Y$X→Y，使得$F_c$Fc​与$F_c - \{X\rightarrow Y\}$Fc​−{X→Y}等价
        • 函数依赖左部不存在冗余属性：$F_c$Fc​中不存在函数依赖$X\rightarrow Y$X→Y，有$Z\subset X$Z⊂X，使得$F_c$Fc​与$F_c - \{X\rightarrow Y\}\cup\{Z\rightarrow Y\}$Fc​−{X→Y}∪{Z→Y}等价
        • 函数依赖左部唯一：$F_c$Fc​中任意两个函数依赖的左部不相同
      • 计算
• 关系模式的范式
  • 第一范式：如果关系模式$R$R的每个属性都是不可分的
  • 1NF存在的问题
  • 1NF问题的解决办法
    • 问题产生的原因：非主属性$Sdept$Sdept和$Sdean$Sdean部分函数依赖于候选键$(Sno,Cno)$(Sno,Cno)
    • 解决办法：把$SDC$SDC分解为$SD(Sno,Sname,Sdept,Sdean)$SD(Sno,Sname,Sdept,Sdean)和$SC(Sno,Cno,Grade)$SC(Sno,Cno,Grade)，这样可以解决数据的更新时的异常和冗余数据的问题
  • 第二范式：如果关系模式$R\in 1NF$R∈1NF，且$R$R的每个非主属性都完全函数依赖于$R$R的候选键
  • 2NF存在的问题
  • 2NF问题的解决办法
    • 产生的原因：非主属性$Sdean$Sdean传递函数依赖于候选键$Sno$Sno
    • 解决办法：将$SD$SD分解为$(Sno,Sname,Sdept),(Sdept,Sdean)$(Sno,Sname,Sdept),(Sdept,Sdean)
  • 第三范式：如果关系模式$R\in 2NF$R∈2NF，且$R$R的每个非主属性都不传递函数依赖于$R$R的候选键。但是如果是不存在非主属性的情况下的传递函数依赖，则依然会存在第二范式的问题
  • 3NF存在的问
  • 3NF问题的解决办法
    • 产生原因：主属性$Cno$Cno部分函数依赖于$(Sno,Tno)$(Sno,Tno)
    • 解决办法：把$STC$STC分解为$TC(Tno,Cno)$TC(Tno,Cno)和$ST(Sno,Tno)$ST(Sno,Tno)
  • $Boyce-Codd$Boyce−Codd范式
    • 定义：满足以下两种情况中的任意一个都是BCNF
      • 若$R(U,F)\in 1NF$R(U,F)∈1NF，且$F$F的最小覆盖中每个函数依赖$X\rightarrow Y$X→Y的左部$X$X都是$R$R的候选键
      • 若$R(U,F)\in 3NF$R(U,F)∈3NF，且$R$R的任意主属性都完全函数依赖于$R$R的候选键
  • 范式之间的关系
  • 设计规范的关系模式
    • 核心思想：一个关系模式只对应一个实体型或一个联系型
    • 规范化程度越高，查询时需要进行的连接操作越多，查询效率越低
• 关系模式分解
  • 定义
  • 关系模式分解准则
    • 无损连接性
      • 定义
      • 可能存在的问题，某些函数依赖丢失了
      • 判定
        • 一个关系模式被分解为两个关系模式时
        • 一个关系模式被分解为3个以上关系模式时
          • TODO
    • 函数依赖保持性
      • 函数依赖集的投影：设$R(U,F)$R(U,F)是关系模式，$U$U是属性集，$F$F是函数依赖集，对于$V\subseteq U$V⊆U，$F$F在$V$V上的投影是$F^+$F+中满足$X\cup Y\subseteq V$X∪Y⊆V的函数依赖的$X\rightarrow Y$X→Y的集合
      • 保持函数依赖的分解的定义
      • 判定
        • 方法1：根据定义进行判定
        • 2：对于函数依赖集中的每个函数依赖，判断是否蕴含在$F_1\cup \cdots\cup F_n$F1​∪⋯∪Fn​中TODO
  • 关系模式分解算法TODO
    • 3NF关系模式分解
    • BCNF关系模式分解

物理数据库设计

• 概述
  • 任务：在逻辑数据库设计的基础上，为每个关系模式选择合适的存储结构和存取方法，使得数据库的上的事务能够高效率地运行
  • 设计步骤
    • 分析数据库负载
      • 对于查询，需要掌握以下信息：查询涉及的关系，投影属性，选择条件和连接条件涉及的属性，选择条件和连接条件的选择度
      • 对于更新，需要掌握以下信息：被更新的关系，更新的类型，被更新的属性，更新条件涉及的关系，选择条件和连接条件涉及的属性以及选择度
    • 选择关系数据库的存取方法
      • 存取方法：DBMS访问元组的方法有顺序访问和索引访问
    • 设计关系数据库的物理存储结构
      • 确定如何在存储器上存储关系及索引，使得存储空间利用率最大化，数据操作产生的系统开销最小化
      • RDBMS使用的物理存储结构取决于存储引擎，用户可以选择合适的存储引擎，但基本不能改变存储引擎使用的物理存储结构
• 索引的设计
  • 索引
    • 索引能够帮助DBMS快速找到关系中满足搜索条件的元组
    • 索引的构成
      • 索引键：索引根据一组属性来定位元组，索引记录了元组的索引键值与元组地址的对应关系
      • 索引项：索引中的（键值，地址）对，索引中的索引项按索引键值排序
    • 索引的分类
      • 主索引：索引键是关系的主键
      • 二级索引：索引键不是关系的主键
      • 唯一索引：索引键值不重复
      • 非唯一索引：索引键值可重复
      • 聚簇索引/索引组织表：索引中存储的是元组本身
      • 非聚簇索引：索引中存储的是元组地址
    • MySQL中的索引
      • 主索引采用聚簇索引
      • 二级索引采用非聚簇索引，二级索引中存储的不是元组地址，而是元组的主键值
  • 创建索引：可以使用alter table添加索引，除了主索引外，也可以使用create index语句添加索引create [unique] index 索引名 on 关系名 (索引键)
    • 主索引：在create table或alter table语句中使用primary key声明主键时，自动建立主索引，用asc或desc声明主索引中属性按照升序还是降序排列，索引的名字默认就是primary
    • 二级索引：在create table或alter table语句中声明二级索引key|index （索引键）[索引名]，用asc或desc声明主索引中属性按照升序还是降序排列
    • 唯一索引：在create table或alter table语句中声明唯一索引unique [key|index] (索引键) [索引名]
    • 外键索引：使用foreign key声明外键时，会为外键创建索引，建外键索引是为了加快参照完整性检查
  • 删除索引
    • 删除二级索引：drop index 索引名 on 关系名，删除二级索引不需要重新组织关系中的元组
    • 删除主索引：drop index ‘primary’ on 关系名，删除主索引需要重新组织关系中的元组，删除主索引的代价比二级索引高
  • 索引数据结构：不同的索引结构具有不同的功能和特性
    • B+树，对于B+树索引支持的查询，其查询结果中元组的索引键值在B+树的叶节点中连续存储：
      • 可以是全值匹配，也可以是匹配最左前缀
      • 只匹配某属性的开头部分
      • 范围匹配，在给定范围内对某属性进行匹配
      • 精确匹配某一属性并范围匹配另一属性
      • 支持按照索引属性进行排序
    • B+树索引的限制
      • 必须从索引的最左属性开始查找
      • 条件中不能包含表达式
      • 不能跳过索引中的属性进行查找
      • 如果查询中有关于某个属性的范围查询，则其右边所有属性都无法使用索引查找
    • 哈希索引，哈希表中的索引项是（索引键值的哈希值，元组地址），床架索引时使用using hash即可
    • 哈希索引的限制：
      • 哈希索引不支持部分索引属性匹配
      • 只支持等值比较，不支持范围查询
      • 不能用于元组的排序，并且存在冲突问题
  • 索引设计技巧
    • 伪哈希索引，有些存储引擎不支持哈希索引，但我们可以模拟哈希索引
    • 前缀索引
      • 索引的选择性：不重复的索引键值和元组数量N的比值$\frac{count(distinct\ A)}{count(*)}$count(∗)count(distinct A)​，选择性越高，索引的过滤能力越强
      • 当索引很长的字符串时，索引会变得很大，而且很慢，当字符串的前缀具有较好的选择性时，可以只索引字符串的前缀
      • 缺点：前缀索引不支持排序和分组查询
    • 单个多属性索引 vs 多个单属性索引
      • 多个单属性索引的缺点
        • 效率没有在单个多属性索引上做查询高
        • 索引合并涉及排序，消耗计算资源
        • 在查询优化时，索引合并的代价并不被计入，故“低估”了查询代价
    • 索引属性的顺序：当不考虑排序和分组时，将选择性最高的属性放在最前面通常是好的，可以更快地过滤掉不满足条件的记录
    • 聚簇索引，元组按照索引聚集性存储
      • 优点
        • 相关数据保存在一起，可以减少磁盘I/O
        • 无需“回表”，数据访问更快
      • 缺点
        • 如果数据全部在内存中则无用
        • 插入删除代价很高
      • 如果是在主键上建立聚簇索引
      • 如果是在代理键上建立聚簇索引
    • 覆盖索引：如果一个索引包含（覆盖）一个查询需要用到所有属性，则称该索引为覆盖索引
      • 索引数量通常远小于元组数量，如果只需访问覆盖索引，则可以极大减少数据访问量
      • 索引中属性值是顺序存储的，能更快找到满足条件的属性值
      • 不需要回表
      • 即使一个索引不能覆盖某个查询，我们也可以将该索引用作覆盖索引，并采用延迟连接方式改写查询
  • 避免不合理地使用索引
  • 查询改写
  • 索引涉及过程
    • 分析负载
    • 依次检查每个重要的查询
    • 权衡索引更新代价
• 物理存储结构的设计
  • 数据类型的选择
    • 尽量使用可以正确存储数据的最小数据类型
    • 尽量选择简单的数据类型
    • 若无需存储空值，则最好将属性声明为not null，因为含空值的属性使得索引、统计、比较都更复杂
  • 标识符类型的选择：整型是最好的选择，enum、set和字符串类型都是糟糕的选择
  • 数据库的划分
    • 关系模式的设计：一个关系不要包含太多属性，也不要为实体的每个属性建立一个关系
    • 纵向划分
    • 横向划分

存储管理（知道一些基本概念就可以）

• 存储媒介
  • 操作系统将每个track分成若干相等的块，也叫页面
  • 逻辑块地址是从0到n-1的
• 数据库在磁盘上的表示
  • 值表示
  • 元组
    • 头部包含一个指向元组的模式的指针，元组的长度，可见性信息，一个bitmap指示空或非空
    • 数据字段包含了顺序定义的属性值，并且每个属性值的存储位置使用一个四字节或八字节的倍数偏移表示
  • 页：每一个页面被分配一个独一无二的页号，DBMS使用一个间接层将页号映射到物理地址
    • 头部：指明了页大小，校验码，DBMS版本，是否能见，压缩信息
    • 存储元组的页
      • 
      • 记录号：为了追踪元组，DBMS给每个元组分配了一个独一无二的记录号，最常见的记录号是$(pageID,Slot\#)$(pageID,Slot#)
    • 存储日志的页
      • 
      • 对于增删查改
  • 文件：操作系统将问价组织成页，文件的内容对OS不可见，文件中存储的是页
    • 堆文件组织：应该支持创建、获取、写入、删除页操作，支持遍历页
      • 链表法，文件头部存储两个指针，一个指向空闲页的列表，另一个指向数据页的列表
      • 页目录法
    • 顺序文件组织，文件中的页按照某个key的值顺序存储
    • 哈希文件组织
• 系统目录
• 缓冲区管理
  • 缓冲池：以数组的形式建立在缓存中，每个元素是一个页大小的块，叫做frame
  • 缓冲区管理器：负责将页替换到缓冲区中
  • 页表：跟踪在缓冲池中的页
  • frame的元数据
    • $pin\_count$pin_count：frame中的尚未被释放的page被请求的次数
    • $dirty$dirty：frame中的页是否被修改自从被安排在缓冲池
  • 请求页的过程
    • 检查frames中是否包含被请求的页P
    • 如果包含，则相应frame的pin_count增加1
    • 如果不包含，使用选择策略选择一个pin_count为0的页进行替换，如果页dirty就把页写回，然后读取被请求的页
  • 页替换策略
    • 替换最长时间没有使用的
    • 每一个frame添加一个reference变量，轮询，找到第一个这个变量是0的

查询执行

查询优化

并发控制

故障恢复

待续~~~