3.3 数据库系统

目录 ✌ #

本章内容在上午的选择题和下午的案例分析题中都会涉及到，在下午的案例分析题里面考到过视图、规范化理论、反规范化理论等；相对比较重要，正常约占4~9分，占比5.3%~12%

1 数据库模式 ✅✅✅ #

数据库模式一句话概括为三级模式两级映像；其中三级模式分别是：外模式(用户模式、子模式)、模式(概念模式)、内模式；两级映像分别是：外模式与模式之间的映像、模式与内模式之间的映像。如下图所示。

外模式

外模式是面向用户或者应用程序的数据库局部视图。它是从模式导出的一个子集(在golang中同切片和数组的关系类似)，外模式包含模式中允许特定用户使用的那部分数据。外模式反映了数据库的用户观。

模式

又称概念模式或逻辑模式，它是对数据库中全部数据的逻辑结构和特征的总体描述，是所有用户的公共数据视图(全局视图)。模式反映了数据库系统(DBS)的整体观。

内模式：

又称存储模式，对应于物理级。它是数据库中全体数据的内部表示或底层描述，是数据库最低一级描述，它描述了数据在存储介质上的存储方式和物理结构，对应着实际存储在外存储介质上的数据库。它是数据库的存储观。创建索引改变的是数据库的内模式。

外模式-模式（保证了数据的逻辑独立性）

用户应用程序根据外模式进行数据操作，通过外模式—模式映射，定义和建立某个外模式与模式间的对应关系(加一层)，将外模式与模式联系起来，当模式发生改变时，只要改变其映射，就可以使外模式保持不变，对应的应用程序也可保持不变。

模式-内模式（保证了数据的物理独立性）

通过模式—内模式映射，定义建立数据的逻辑结构（模式）与存储结构（内模式）间的对应关系(加一层)，当数据存储结构发生变化时，只需改变模式—内模式映射，就能保持模式不变，因此应用程序也可以保持不变。

关系的3种类型

基本关系 (通常又称为基本表或基表) : 实际存在的表，实际存储数据的逻辑表示。

查询表:查询结果对应的表。

视图表:由基表或其他视图表导出的表，本身不独立存储，数据库只存放它的定义，常称为虚表。

2 数据库设计 ✅✅✅ #

数据库设计依次包含阶段，分别是：需求分析、概念结构设计、逻辑结构设计、物理设计阶段。

需求分析产物有：数据流图、数据字典、需求说明书，概念结构设计的产物有：ER图，逻辑结构设计的产物有：关系模式，还需要考虑ER图转关系模式的转换规则和规范化相关的一些东西，物理设计考虑的是具体的物理存储、物理分布等。

例题
学霸肯定对了 ↕
C
学霸肯定对了 ↕
C

2.1 需求分析 ✅✅ #

根据当前和未来应用的数据要求、数据处理要求来进行需求分析，此阶段的产物有：数据流图、数据字典、需求说明书。注意：数据流图本身是很重要的，在结构化需求分析SA中会详细讲到。

2.2 概念结构设计 ✅✅ #

概念结构设计也就是通过需求分析的结果来获得ER图的过程。下图是示例的ER图：

ER图就是实体联系图，两个不同的实体集之间有三种联系，分别是1:1,1:m,m:n。上图是m:n的多对多关系(联系的类型需要会判断)。

E-R图具体的建立过程

合并的方法：一次集成：多个局部E-R图一次集成；逐步集成：用累加的方式一次集成两个局部E-R。

合并时冲突的分类：属性冲突：属性域冲突或属性取值冲突；命名冲突：同名异义和异名同义；结构冲突：同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数不完全相同。

2.3 逻辑结构设计 ✅✅✅✅ #

逻辑结构设计的产物是关系模式，关系模式(关系模型) = ER图 + 转换规则和规范化理论。

数据模型三要素：数据结构、数据操作、数据的约束条件。数据模型包括层次模型、网状模型、面向对象模型、关系模型。

关系模型的相关概念

以下的几种表达形式都表示了同一个关系模型。

以学生、选课关系为例，说明关系模型中的相关概念。其中：学生(学号，姓名，年龄，班级编号)和选课(学号，课程号，课程名)。

1、学生关系是一个4目关系；选课关系是一个3目关系。

2、学生关系的候选码只有一个，是学号；选课关系的候选码也只有一个，是(学号，课程号)。

3、学生关系的主键是学号；选课关系的主键是(学号，课程号)。

4、学生关系的主属性有学号，非主属性有姓名，年龄，班级编号；选课关系的主属性有学号和课程号，非主属性有课程名。

5、学生关系没有外键；选课关系的外键是学号，学号是学生关系的主键。

6、学生关系没有全码，选课关系也没有全码。全码(全部属性都是候选码，即选课关系去掉课程名之后，剩下的就是全码)

官方描述如图：

完整性约束
- 实体完整性：规定基本关系的主属性不能取空值。跟主键相关
- 参照完整性：关系与关系之间的引用。跟外键相关
- 用户自定义完整性：应用环境决定。如年龄取值范围等。
- 触发器：复杂的完整性约束，可做逻辑判断等功能。

例题
学霸肯定对了 ↕
B

关系模式的具体的建立过程

建立过程：1. ER图向关系模式转换：需要将ER图中的实体和联系转换为关系模式。

例题
学霸肯定对了 ↕
C
学霸肯定对了 ↕
D C A

2、关系模式的规范化传送门。

3、确定完整性约束(保证数据的正确性；实体完整性、参照完整性、用户自定义完整性)。

2.4 物理设计 ✅ #

物理设计考虑具体的物理存储、物理分布情况。

3 关系代数 ✅✅✅✅ #

关系代数是针对关系模式进行的代数运算。

并交差是同构的二元运算。

笛卡尔积、投影选择可是同构，也可异构；笛卡尔积是二元运算，投影、选择都是一元运算；它们都可用1，2，3…来代替列名，有同名的情况需要加上“表名.”。经常会出现这样的sql考察形式：select 投影 from 笛卡尔积 where 选择。

连接有多种，考试基本上只考自然连接。有同名的情况需要加上“表名.”。笛卡尔积的结果非常庞大，将笛卡尔积进行适当的选择、投影(注意顺序，下面两个式子中，第一个是对的)就可以得到自然连接的结果，所以也会考察它们相等的情况。如果考虑性能情况，一般需要先投影选择之后再做笛卡尔积或自然连接的性能最高。

例题
学霸肯定对了 ↕
D C
学霸肯定对了 ↕
B C

4 规范化理论 ✅✅✅✅✅ #

规范的必要性

非规范化的关系模式可能存在的问题包括：数据冗余、更新异常(修改操作一致性问题)、插入异常、删除异常。

经常考察的点：

1、给你一个关系模式，让你看看有啥问题(异常)，做法：先看该关系模式达到第几范式，再说出对应范式的问题就行；

2、让你修改关系模式来消除这些问题。一般来说没达到第三范式都有问题。

4.1 函数依赖 ✅✅✅✅✅ #

函数依赖是一个语义概念，是一个自然而然的概念。如果x能唯一决定y，则称x函数决定y，或者是y函数依赖于x，记作x->y。

特殊的函数依赖关系
- 部分函数依赖：C依赖于A，所以C部分依赖于AB
- 传递函数依赖

4.2 求候选键 ✅✅✅✅✅ #

候选键可以有多个，每个候选键可以由多个属性构成。知道候选键了以后，其余的情况都能一目了然，现在介绍如何求取候选键。

1、在关系模式中，一般用R(U,F)表示，U是属性，表示节点；F是函数依赖，表示边；所以将关系模式转换为一个有向图（可选）。

2、(入度出度都为0的属性一定是在候选码中)，找入度为0的属性(只在箭头左边出现过的属性就是入度为0的属性；箭头指入为入度，箭头指出为出度)，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有结点，则该属性集即为关系模式的候选键。

3、若入度为0的属性集不能遍历图中所有结点，则需要尝试性的将一些中间结点(既有入度，也有出度的结点)并入入度为0的属性集中，直至该集合能遍历所有结点，集合为候选键。

例题
学霸肯定对了 ↕
A ABCD B

4.3 Armstrong公理 ✅✅ #

函数依赖在题目中一般都给的不全，但是我们可以通过题目给的函数依赖推导出所有的属性，期间推导的依据就是Armstrong公理。

增广率有两种形式：1、若x->y,则x->xy 2、若x->y,则xz->yz

例题
学霸肯定对了 ↕
C
解析：A选项是传递律，B选项是自反律，D选项是分解规则

4.4 范式判断 ✅✅✅✅✅ #

关系数据库在设计过程中必然会考虑到规范化程度，范式就是判断规范化程度的度量。欲达到更高的规范化程度，则需要将表格拆分得更细。拆分得越细，查询性能会越低，所以并不是越细越好，所以也会出现非规范化理论。一般在开发过程中达到第三范式就刚好。

第一范式

最普通的二维表就达到了第一范式，一般题目给到的表，都是达到了第一范式。所以下表不满足第一范式，不是普通二维表，因为高级职称人数可继续拆分。

第二范式

该例子是一个普通的二维表，所以该关系模式至少达到了第一范式，但该关系模式存在非主属性对候选码的部分函数依赖(学分部分依赖候选码学号和课程号)，所以该关系模型未能达到第二范式，目前只是第一范式。存在部分函数依赖的前提是候选码至少由两个及以上的属性构成。若消除了非主属性对候选码的部分函数依赖，则该关系模式可以达到第二范式；如何消除？将该关系模式(学号，课程号，成绩，学分)拆成两个关系模式(课程号，学分)和(学号，课程号，成绩)。

第三范式

该例子是普通二维表且候选码只有一个属性构成，所以该关系模式至少达到了第二范式。主属性学号->系号，系号->系名和系位置(其中系号一定是非主属性才行)；所以该关系模式存在非主属性对主属性的传递依赖(系名和系位置传递依赖于学号)，所以该关系模式未达到第三范式。若消除了非主属性对主属性的传递依赖，则该模式可以达到第三范式，如何消除？将关系模式(学号，姓名，系号，系名，系位置)拆分成两个关系模式(学号，姓名，系号)和(系号，系名，系位置)。

BCNF范式

该例子是是普通二维表且没有非主属性(F{T->J,SJ->T}，所以候选码为：SJ，ST)，所以该关系模型至少达到了第三范式。当且仅当F中的每个依赖的左边都必定包含R的某个候选码时，就达到BCNF范式。显然T不包含SJ或ST，所以未达到BCNF范式。

例题
学霸肯定对了 ↕
C A

4.5 模式分解 ✅✅✅✅✅ #

将关系模式拆分成更小的关系模式以达到更高的规范化程度的过程就是模式分解的过程。模式分解的过程中，需要考虑两个问题：1、是否保持函数依赖；2、是否无损分解。比较好的模式分解应该是即保持了函数依赖，又是无损分解。

保持函数依赖分解

关系模式分解前必然存在一个函数依赖集合F，关系模式分解后假设得到了两个关系模式，那么这两个关系模式也必定有自己的函数依赖集合F1，F2；若F1并F2等价于F，则称这种模式分解保持了函数依赖。在F中可能存在冗余函数依赖，它其实是可以通过公理推导出来的，所以在判断是否保持函数依赖时不用考虑冗余函数依赖(当它没有)。

例题
学霸肯定对了 ↕
是是
第一问解析：R1的函数依赖F1={A->B}，R2的函数依赖F2={B->C}，函数依赖F1并F2是等价于分解前的函数依赖F的，所以该分解保持了函数依赖。第二问解析：同第一问一样，只不过F中存在了冗余函数依赖A->C(通过传递律可知)，在判断的时候不需要考虑，所以该分解保持了函数依赖。
学霸肯定对了 ↕
不是是
第一问解析：R1的函数依赖F1={A->B}，R2的函数依赖F2={A->C}，函数依赖F1并F2是不等价于分解前的函数依赖F的(缺少B->C)，所以该分解没有保持函数依赖。第二问解析：R1的函数依赖F1={A->B}，R2的函数依赖F2={D->E}，函数依赖F1并F2是等价于分解前的函数依赖F的，所以该分解保持了函数依赖。

有损无损分解
- 有损：拆分后不能还原出原来的函数依赖。
- 无损：拆分后可以还原出原来的函数依赖。指将一个关系模式分解成若干关系模式后，通过自然连接和投影运算仍能还原成原来的关系模式。

判断是否无损分解一般可用表格法(通用方法)和公式法判断(本文不做介绍)。

例题
学霸肯定对了 ↕
无损分解
解析：分解前为1NF，分解后满足BCNF。模式分解后保持了函数依赖。现在判断是否无损分解。
用表格法比较清晰：
1、构造初始表，列名是源属性集，行是分解后的关系模式，有值的打钩；
2、找出表中的同名属性列，看它在原本函数依赖F中能决定出什么，如果有的话说明该函数依赖在分解后被保留下来了，就可以在各表的同名属性列决定的属性处打钩，如果没有就跳过；
3、新决定出来的列可重新按上述规则重新判断下一个，以此类推，知道出现任意一行全部为钩则无损分解，若表格的所有属性都遍历完了也没有一行全为钩的，就是有损分解。
具体为：初始表如下；同名属性列学号在原有函数依赖中决定了姓名，所以在学号为钩的行给姓名打钩；同名属性列姓名在源有函数依赖中没有决定任何属性，所以跳过；同名属性列课程号在原有函数依赖中决定了课程名，所以在课程号为钩的行给课程名打钩；此时满足任意一行(成绩表)全为钩；所以它是无损分解。
学霸肯定对了 ↕
D A
解析参考上面例题的解析，思路完全一模一样。
学霸肯定对了 ↕
A D
解析参考上面例题的解析，思路完全一模一样。

4.6 闭包 ✅✅✅ #

x(1) = x(0) U CD

4.7 反规范化理论 ✅✅✅✅ #

案例分析例题
学霸肯定对了 ↕

5 并发控制 ✅✅ #

5.1 事务 ✅✅ #

并发控制指的是事务的并发控制，事务保证了数据的完整性。事务有4个特点：简称ACID

原子性(Atomicity)

是指事务包含的所有操作要么全部成功，要么全部失败回滚。这些操作是一个整体，不能部分地完成，跟操作系统的原语一样(PV操作)。影子拷贝是保证事务原子性的一种方法；影子拷贝：假设在某一个时刻只有一个活动的事务，为了保证事务的原子性，对于要执行写操作的数据项，数据库系统在磁盘上维护数据库的一个副本，所有的写操作都在数据库副本上执行，而保持原始数据库不变，如果在任一时刻操作不得不中止，系统仅需要删除副本，原数据库没有受到任何影响。这种设计策略称为影子拷贝。

一致性(Consistency)

是指事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。比如说转账。数据库系统通常采用完整性约束检查机制保证单个事务的一致性。

隔离性(Isolation)

是指一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的。也就是执行的效果应该和串行一样互不影响。事务的隔离性保证操作并发执行后的系统状态与这些操作以某种次序串行化执行后的状态是等价的。两阶段锁协议是实现隔离性的常见方案，该协议能够保证事务的可串行化执行，但它可能发生死锁。

持久性(Durability)

是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，无论发送何种故障，都不应对其有任何影响。假设在日志中记录所有对数据库的修改操作，将一个事务的所有写操作延迟到事务提交后才执行，则在日志中无需记录数据项被事务修改前的原始值，当系统发生故障时，如果某个事务已经开始，但没有提交，则该事务应该什么也不用做。

5.2 并发可能产生的问题 ✅ #

并发可能会产生以下问题：1、丢失更新；2、读脏数据；3、不可重复读问题。

5.3 封锁协议 ✅ #

封锁协议是用来解决并发可能会产生的那三个问题。

S封锁是读锁/共享锁：一个事务对操作对象上了读锁，另一个事务也可对该操作对象上读锁，这两个事务共享该操作对象。
X锁是写锁/排它锁：一个事务对操作对象上了写锁，那么其他任何事务都没法对该操作对象上任何锁，X锁具有排它性：
一级封锁协议解决丢失更新
二级封锁协议解决丢失更新、读脏数据
三级封锁协议解决丢失更新、读脏数据、不可重复读。
两段锁协议，分为加锁和解锁两个阶段，任何读之间都加S锁，任何写之前都加X锁，加锁就像操作系统的P操作一样，解锁就是V操作，可能会导致死锁。

6 数据库的安全性 ✅✅ #

例题
学霸肯定对了 ↕
C
索引和视图是无法更新的、存储过程是可以被第三方开发人员调用的，而触发器不行。

7 数据库的备份与恢复技术 ✅ #

7.1 数据备份 ✅ #

例题
学霸肯定对了 ↕
B

7.2 数据库故障与恢复 ✅ #

数据库容灾属于网络安全和应用安全考虑范畴。

8 数据库性能优化 ✅✅ #

9 数据库索引 ✅✅ #

索引表是实际存在的表。假设要查询学号为417的这条记录，顺序查找的思想是一个一个对比，查询6次才能查到，效率非常低；可能会很自然想到二分查找，但二分查找需要排序的前提。建立索引表本身采用的是B树或者B+树；为了方便解释，这里以二分查找建立索引为例，只需要查2次。

10 数据库视图 ✅✅✅ #

数据库视图：它一个虚拟表 (逻辑上的表)，其内容由查询定义(仅保存SOL查询语句，所以效率可能有点低，可以使用物化视图提高效率)同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并没有真正存储这些数据，而是通过查询原始表动态生成所需要的数据，可以理解为视图是一个指针，可以指向单个表、多个表的联合查询结果，底层的表的数据变了，视图的结果自然也会变(跟golang里面的切片和数组挺像的)。

视图的优点:

1、视图能简化用户操作

2、视图使用户能以多种角度看待同一数据

3、视图对重构数据库提供了一定程度的逻辑独立性

4、视图可以对机密数据提供安全保护，如不想授权整个表给外部查询，那么就可授权这个表的某个查询视图给外部就行。

物化视图:它不是传统意义上虚拟视图，是实体化视图，其本身会存储数据。同时当原始表中的数据更新时，物化视图也会自动更新。适合于多查询少更新的场景。

案例分析例题
学霸肯定对了 ↕

11 数据库的分区分表分库 ✅✅ #

分区是数据库自带的，比如说属于列表分区的有：按天分区，按操作系统类型分区，按日志名字分区等等，逻辑上还是一张表。分区一般针对hive，分区可以增加数据查询的速度。

11.1 常见的分区方式 ✅✅ #

哈希分区相对分的比较均匀。

11.2 分表分库 ✅✅ #

分表分库通常是针对mysql(这其实已经涉及到分布式数据库了)；当数据库的QPS过高、数据库的连接数不足的时候就需要分库；当单表数据量过大，严重影响读写性能时就需要分表。分表有水平分表和垂直分表；水平分表(是分布式数据库里面的水平切片，也是反规范化理论里面的水平分表)：将数据记录存放在不同的表中；垂直分表(是分布式数据库里面的垂直切片)：将不同的字段放在不同的表中。

分表分库同分区一样，也可采用、范围、列表和哈希，通常采用哈希算法。

12 分布式数据库 ✅✅✅ #

分布式数据库是对应于集中式数据库而言的，平时所用到的简单的mysql等都是集中式数据库(在企业中的mysql肯定是做的分布式数据库，不然性能跟不上)，分布式会考虑物理上把数据放在不同的物理节点上，其逻辑上依然是一个整体。

12.1 分布式数据库的层次 ✅✅✅ #

分布式数据库的层次和集中式数据库的三级模式两级映像大致相似，只不过在原有的外模式、概念模式、内模式上增加了一些具体的特性，如分片模式，分布模式；全局外模式和外模式一样，都直接用于用户程序，局部概念模式和概念模式一样，都是库表，局部内模式同内模式一样。其中，全局概念模式定义分布式数据库中数据的整体逻辑结构，使得数据使用方便，如同没有分布或分片一样。其具体情况如下图：

12.2 分片模式 ✅✅✅ #

分片模式使得数据具有分片透明性，分片透明性：是指用户不必关心数据是如何分片的，它们对数据的操作在全局关系上进行，即如何分片对用户是透明的。分片模式具体分为水平分片、垂直分片。

水平分片：是将表中不同行的数据存储到不同的服务器上(反规范化理论，将北京的用户放在北京的表，将贵州的用户放在贵州的表)。
垂直分片：是将表中不同字段的数据存储到不同的服务器上。

12.3 分布模式 ✅✅✅ #

分布模式使得数据具有分布透明性；具体分为：复制透明性、位置透明性、逻辑透明性。

复制透明：用户不用关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由RDBMS系统自动完成，数据复制是为了提升数据访问效率而采用的一种增加数据冗余的方法(也就是主从)。
位置透明：是指用户不必知道所操作的数据放在何处，即数据分配到哪个或哪些站点存储对用户是透明的。
逻辑透明：是指局部数据模型透明，即用户或应用程序无需知道局部场景使用的是哪种数据模型。