考点：

数据库模式 ⭐️
分布式数据库 ⭐️⭐️⭐️
数据库设计阶段 ⭐️⭐️
概念结构设计——ER模型 ⭐️
逻辑结构设计——关系模式 ⭐️⭐️
关系代数 ⭐️⭐️⭐️⭐️
规范化理论 ⭐️⭐️⭐️⭐️⭐️
并发控制 ⭐️
数据库的安全性 ⭐️
数据库备份与恢复技术 ⭐️
数据库性能优化 ⭐️

选择、案例、论文均有涉及，高难

1 数据库的组成与分类
2 数据库设计 ⭐️⭐️☀️
3 关系代数 ⭐️⭐️⭐️⭐️
4 规范化理论 ⭐️⭐️⭐️⭐️⭐️☀️
5 并发控制 ⭐️
- 5.1 并发的问题
- 5.2 封锁协议
6 数据库的安全性 ⭐️
7 数据库备份与恢复技术 ⭐️
8 数据库性能优化 ☀️
9 综合案例分析练习

1 数据库的组成与分类

关系型数据库基础知识：MySQL基础

1.1 数据库模式 ⭐️

数据库模式

一般数据库的3种最基本的数据模式：

外模式：数据库的用户级表示，它定义了用户能够看到和操作的数据视图。——对应用户视图
- 外模式-概念模式映射：保证数据的【逻辑独立性】（当概念模式发生变化时，不需要改变外模式，从而保护应用程序和数据的一致性）
概念模式（模式/逻辑模式）：描述了整个数据库的逻辑结构，包括所有的数据元素、关系和约束条件。——对应DBA视图
- 概念模式-内模式映射：保证数据的【物理独立性】（当数据库的物理存储结构或访问方法发生改变时，可以通过调整映射来适应这些变化，而不影响上层应用和概念模式）
内模式（存储模式/物理模式）：定义了数据在物理介质上的存储方式，包括文件的组织形式、索引方法、存储分配等细节。是操作系统直接交互的部分，决定了数据存取效率和存储空间利用情况。——对应内部视图

关系表（简称关系）的3种类型：

基本关系（基本表/基表）：实际存在的表，实际存储数据的逻辑表示。(用CREATE创建的表)
查询表：查询结果对应的表。
视图表：由基表或其他视图表导出的表（虚表），本身不独立存储，数据库只存放它的定义。（详见后述数据库视图）

1.2 分布式数据库 ⭐️⭐️⭐️☀️

集中式数据库：将数据集中存储在同一数据库上。

分布式数据库（Distributed Database，DDB）：将数据存储在各存储结点上。

1.2.1 分布式的特点

分布式数据库有以下几个特点：

数据独立性：除了数据的逻辑独立性与物理独立性外，还有数据分布独立性（分布透明性）。
集中与自治共享结合的控制结构：各局部DBMS（数据库管理系统，Database Management System）可以独立地管理局部数据库，具有自治的功能。同时，系统又设有集中控制机制，协调各局部DBMS的工作，执行全局应用。
适当增加数据冗余度：在不同的场地存储同一数据的多个副本，可以提高系统的可靠性和可用性，同时也能提高系统性能。
- 提高系统的可用性：当系统中某个节点发生故障时，因为数据有其他副本在非故障场地上，对其他所有场地来说，数据仍然是可用的，从而保证数据的完备性。
全局上，具有一致性、可串行性和可恢复性。（集中式数据库的特点）

1.2.2 分布式数据库管理系统

分布式数据库管理系统（Distributed Database
Management System，DDBMS）的结构包括全局控制集中的DDBMS、全局控制分散的DDBMS、全局控制部分分散的DDBMS。

组成：

LDBMS（局部数据库管理系统，Local Database Management System）
GDBMS（全局数据库管理系统，Global Database Management System）
全局数据字典
通信管理（Communication Management，CM）

分布式数据库的模式结构：

全局DBMS：
1. 全局外模式
2. 全局概念模式：定义DBMS中数据的整体逻辑结构
3. 分片模式：决定如何执行数据分片（抽取部分行/列）
4. 分布模式：决定如何放置数据
局部DBMS（同集中式数据库）：
1. 局部概念模式
2. 局部内模式
3. 局部数据库

DDBS

1.2.3 分布透明性

分片：抽取部分行/列

分布式数据库有以下几点透明性：

分片透明性：用户感受不到是否分片。对数据的操作在全局关系上进行，有如下3种切片方式——
- 水平分片：将数据库中的表行（记录）按照某种规则划分到不同节点，每个节点存储部分数据行
- 垂直分片：将数据库中的表按列（属性）进行分割，不同节点存储不同的列
- 混合分片：结合水平分片和垂直分片
复制透明性：用户不必关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由系统自动完成。
位置透明性：用户不必知道数据放在何处。即数据分配到哪个或哪些站点存储对用户是透明的。
局部映像透明性（逻辑透明）：最低层次的透明性。该透明性提供局部数据模型透明，即用户不必关心局部DBMS支持哪种数据模型、使用哪种数据操纵语言，数据模型和操纵语言的转换由系统完成。

数据分片

1.2.4 两阶段提交协议（2PC）

两阶段提交协议（Two-phase Commit，2PC）：

2PC事务提交的两个阶段：
1. 表决阶段：形成一个共同的决定
2. 执行阶段：实现这个协调者的决定
两条全局提交规则
1. 只要有一个参与者撤销事务，协调者就必须做出全局撤销决定
2. 只有所有参与者都同意提交事务，协调者才能做出全局提交决定

1.3 NoSQL ☀️

NoSQL（Not-only SQL）：不仅仅只是SQL，泛指非关系型数据库。

关系型与非关系型数据库的对比：

对比维度	关系型数据库	NoSQL
数据一致性	实时一致性	最终一致性
应用领域	面向通用领域	特定应用领域
数据容量	有限数据	海量数据/大数据
数据类型	结构化数据【二维表】	非结构化数据
并发支持	支持并发，但性能低	高并发
事务支持	高事务性	弱事务性
扩展方式	向上扩展	向外扩展

NoSQL数据库的分类：

键值（Key-Value）数据库
- 典型应用场景：内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等。
- 数据模型：(key, value)键值对，通常用哈希表来实现
- 优点：查找速度快
- 缺点：数据无结构化，通常只被当作字符串或者二进制数据
- 例：Redis（详见分布式缓存数据库）、Tokyo Cabinet、Tyrant、 Voldemort、Oracle BDB
列存储数据库（Column-oriented DBMS）
- 典型应用场景：分布式文件系统
- 数据模型：列簇式存储，将同一列数据存在一起
- 优点：查找速度快，可扩展性强，更容易进行分布式扩展
- 缺点：功能相对局限
- 例：HBase、Cassandra，Riak
文档数据库（Document Database）
- 典型应用场景：Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）
- 数据模型：(key, value)键值对，Value为结构化数据
- 优点：数据结构要求不严格，表结构可变，无需预先定义表结构（关系型数据库）
- 缺点：查询性能不高，且缺乏统一的查询语法
- 例：CouchDB、MongoDb
图数据库（Graph Database）
- 典型应用场景：社交网络，推荐系统等。专注于构建关系图谱
- 数据模型：图结构
- 优点：利用图结构相关算法。比如最短路径寻址，N度关系查找等
- 缺点：经常需要对整个图做计算才能得出需要的信息；不适合用作分布式集群
- 例：Neo4J、InfoGrid、Infinite Graph

1.4 联邦数据库 ☀️

联邦数据库系统（Federated Database System，FDBS）是一个彼此协作却又相互独立的成员数据库系统（Customer Database System，CDBS）的集合，它将成员数据库系统按不同程度进行集成，对该系统整体提供控制和协同操作的软件叫做联邦数据库管理系统（Federated Database Management System，FDBMS）。

FDBS

联邦数据库特征：

分布性
异构性
自治性
透明性

联邦数据库分类：

紧耦合
松耦合

2 数据库设计 ⭐️⭐️☀️

数据库设计关注的问题：性能、数据一致性、安全

数据库设计围绕数据展开，分为4个阶段：

需求分析
概念结构设计（注意ER模型在数据库设计时属于概念设计阶段，而软件开发设计时属于需求分析阶段）
逻辑结构设计
物理设计

数据库设计

2.1 数据库需求分析

在整个设计流程开始前，应先完成任务书和设计方案。

与通常软件设计不同，数据库设计以数据为中心。需求分析应结合当前和未来应用的数据要求及数据处理要求。

数据库需求分析的产物：数据流图、数据字典、需求说明书

2.2 概念结构设计 ⭐️

概念结构设计从需求中抽象出概念模型，生成ER模型。

2.2.1 ER模型

更多阅读：ER图的绘制与转换

实体关系图（ER图，Entity Relationship Diagram）的构成与表示如下：

实体（Entity）：用矩形表示，矩形框内写明实体名
属性（Attribute）：用椭圆形表示，并用无向边将其与相应的实体连接起来
联系（Relationship）：用菱形表示，菱形框内写明联系名，并用无向边分别与有关实体连接起来，同时在无向边旁标上联系的类型
- 两个不同实体集之间的联系：1 : 1、1 : n、n : 1、m : n

ER图

2.2.2 概念结构设计流程

概念结构设计的流程：抽象数据 → 设计局部ER模型 → 合并（集成）局部ER模型，消除冲突 → 重构优化，消除冗余

概念结构设计的过程

集成局部ER图的方法：

多个局部ER图一次集成。
逐步集成，用累加的方式一次集成两个局部ER图。

集成产生的冲突及解决办法：

属性冲突：包括属性域冲突（数据类型）和属性取值冲突（单位）。
- 解决方法：统一类型/单位
命名冲突：包括同名异义和异名同义。
- 解决方法：统一名称
结构冲突：包括同一对象在不同应用中具有不同的抽象（类的定义），以及同一实体在不同局部ER图中所包含的属性个数和属性排列次序不完全相同。
- 解决方法：合理调整类的定义，整合部分属性

产物：ER模型，即用户的数据模型，与DBMS无关。

2.3 逻辑结构设计 ⭐️⭐️

逻辑结构设计通过ER图转换成关系模式，进行关系规范化，生成关系模式（视图、完整性约束、应用处理说明书）。

2.3.1 关系模型

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

关系模型（Relational Model）用于记录某关系模式及其属性，形如R(U, F)，其中R为关系模式名，U = {a_1, a_2, ... , a_n}为属性集，F = {X_1 → Y_1, X_2 → Y_2, ... , X_m → Y_m}为函数依赖集（函数依赖的定义见后述）。多个属性的集合称为组合键。

【例1】学生(学号, 姓名, 性别, 所选课程, 成绩)、库存关系I(仓库号, 产品号, 产品数量)等均为合法的关系模型。
【例2】学生(学号, 姓名, 性别, (所选课程, 成绩))中的(所选课程, 成绩)为组合键。

2.3.2 数据库完整性约束

实体完整性约束：规定基本关系的主属性不可取空值（唯一且非空）。
- 实现：Primary Key【主键】
参照完整性约束：关系与关系间的引用，其他关系的主键或空值。
- 实现：Foreign Key【外键】
用户定义完整性约束：应用环境決定。
- 实现：Check、Assertion、【触发器】（详见MySQL高级-触发器）

2.3.3 逻辑结构设计流程

逻辑结构设计的流程：转换为数据模型 → 关系规范化 → 模式优化 → 设计用户子模式

逻辑结构设计的流程

ER图向关系模式的转换：

实体向关系模式的转换：1个实体必须转换为1个关系模式
联系向关系模式的转换：
1. 一对一联系的2种转换方式：
  - 成为独立的关系模式：关系模式中包含两端主键及联系自身属性，选择任意一端的主键为主键
  - 归并：关系模式中包含任意一端的主键及联系自身属性（主键保持不变）
2. 一对多联系的2种转换方式：
  - 成为独立的关系模式：关系模式中包含两端主键及联系自身属性，选择多端的主键为主键
  - 归并：关系模式中包含多端的主键及联系自身属性（主键保持不变）
3. 多对多联系只有1种转换方式：
  - 成为独立的关系模式：关系模式中包含两端主键及联系自身属性，主键为两端主键的组合键
    - 此时该关系模式中包含多个主键（且均为外键）

“多端”意为“x对多”中“多”的那端。
此处仅给出二元联系的转换方法，三元联系同理。

关系模式规范化：详见规范化理论

确定完整性约束：保证数据的正确性

用户视图的确定（提高数据的安全性和独立性）：

根据数据流图确定处理过程使用的视图
根据用户类别确定不同用户使用的视图

最后一步：应用程序设计

3 关系代数 ⭐️⭐️⭐️⭐️

关系代数（Relation Algebra）是一种抽象的查询语言，用对关系的运算来表达查询，作为研究关系数据语言的数学工具，即关系模式所做的代数运算。

在二维数据表中，通常可称行（记录）为元组、列为属性。

并（ $S_1 \cup S_2$ ）、交（ $S_1 \cap S_2$ ）、差（ $S_1 - S_2$ ）运算：

并、交、差

笛卡尔积（ $S_1 \times S_2$ ，记录数为len(S1) * len(S2)）、投影（ $\pi_{Sno,Sname}(S_1)$ ，筛选列）、选择（ $\sigma_{Sno=\text{No0003}}(S_1)$ ，筛选行）运算：

笛卡尔积、投影、选择

自然连接（ $S_1 \Join S_2$ ，JOIN）属于连接运算的一种，运算方式如下：

列：二者之并
行：对于重复的属性，保留相同值的所在行，剔除空值

如下图所示，与笛卡尔积的关系： $S_1 \Join S_2 = \pi_{1,2,3,5}(\sigma_{1=4}(S_1\times S_2))$ （可直接用列号 $1,2,\cdots$ 代替属性名，此时应将记录的值添加引号）

自然连接

应用：

根据关系代数表达式估计查询效率：观察所进行操作的表的“规模”大小；特殊值法。
根据关系代数表达式编写SQL语句：参考本站资源——MySQL基础：SQL基本操作

4 规范化理论 ⭐️⭐️⭐️⭐️⭐️☀️

通过规范化（Normalization）来解决非规范化的关系模式可能存在的问题：

数据冗余
插入异常
删除异常
修改异常

4.1 函数依赖

函数依赖（Functional Dependency）简单地说即某个属性集（决定因素）决定另一个属性集（被决定因素）时，称另一属性集依赖于该属性集。函数依赖关系可以是一对一、一对多、多对一、多对多。

【例】学号 → 系号、系号 → 系名。即确定左侧时可以确定右侧。

详细定义：设R(U, F)为属性集U上的一个关系模式，X和Y是U的子集，r为R的任一关系，若对于r中的任意两个元组u、v，只要有u[X] = v[X]，就有u[Y] = v[Y]，则称X函数决定Y，记为X → Y，或称Y函数依赖于X，记为Y ← X。

部分函数依赖（Partial Functional Dependency）：设关系模式R(A, B, C, D)，依赖集F = {AB → D, A → C}，则该关系模式的候选键（图示法求取，详见下一节）为AB。由于C只依赖于候选键的部分主属性A，故称C部分函数依赖于候选键AB。若C依赖于候选键的全部主属性，则称为完全函数依赖（Full functional dependency）/非部分函数依赖。

传递函数依赖（Transitive Functional Dependency）：设关系模式R(A, B, C)，依赖集F = {A → B, B → C}，则由A → B, B → C可推出A → C（详见Armstrong公理），故称C传递函数依赖于A。

4.2 候选键的求取

求取候选键最稳定的方法为图示法：

将关系模式的函数依赖关系用有向图（可能为复杂图）的方式表示。（注意无依赖关系的属性入度出度均为0）
找入度为0的属性（结点），并以该属性集合为起点，尝试遍历（任意方式；注意对多对一、多对多关系的遍历）有向图，若能正常遍历图中所有结点，则该属性集即为关系模式的候选键。
若入度为0的属性集不能遍历图中所有结点，则需要尝试性地将中间结点（既有入度，也有出度的结点）加入入度为0的属性集中，直至该集合能遍历所有结点，该集合即为1个候选键；反复尝试，得到多种集合，即为全部候选键。

【例1】给定关系R(A1, A2, A3, A4)上的函数依赖集F = {A1 → A2, A3 → A2, A2 → A3, A2 → A4}，求R的候选关键字。
【解】函数依赖关系有向图如下图(1)所示。入度为0的结点集合为{A1}，可遍历全图，故候选键即为A1。

【例2】关系模式P(A, B, C, D, E, F, G, H, I, J)满足下列函数依赖：FD = {ABD → E, AB → G, B → F, C → J, CJ → I, G → H}，求候选码。
【解】函数依赖关系有向图如下图(2)所示（注意多对一关系的表示形式）。入度为0的结点集合为ABCD（常将属性结点黏连着写来表示集合/组合键），可遍历全图，故候选码为ABCD。

【例3】关系R(A, B, C)满足下列函数依赖：F = {B → C, B → A, A → BC}，则关系R的候选关键字为（?）。（A. AB；B. A和B；C. A和BC；D. AC和AB）
【解】函数依赖关系有向图如下图(3)所示。入度为0的结点集合为空集，无法遍历全图。试着将A加入集合，可遍历全图，因此A为候选键；试着将B加入集合，也可遍历全图，因此B也为候选键。由于C出度为0，故必不能作为遍历起点（可提前排除C、D选项）。答案为B。
（选项A的写法表示组合键，缺一不可）

快速求取：观察函数依赖集，直接排除仅作为被决定因素的属性。

4.3 Armstrong公理

关系模式R(U, F)遵循如下的Armstrong公理系统：

A1. 自反律（Reflexivity）：若Y ⊆ X ⊆ U，则X → Y
A2. 增广律（Augmentation）：若Z ⊆ U且X → Y，则XZ → YZ
A3. 传递律（Transitivity）：若X → Y且Y → Z，则X → Z

根据自反律、增广律、传递律可得以下推理规则：

合并规则：由X → Y且X → Z，有X → YZ（A2, A3）
伪传递规则：由X → Y且WY → Z，有WX → Z（A2, A3
分解规则：由X → Y且Z ⊆ Y，有X → Z（A1, A3）（X → YZ ⇒ X → Y且X → Z）

4.4 范式判断

数据库理论存在诸多范式（Normal Form，NF），以解决诸多问题。常见范式如下所示，从上至下逐步优化，层层递进：

第一范式（1NF）：属性值都是不可分的原子值
- 原子值：简单属性（由1个独立成分构成，反之为复合属性）、单值属性（只含1个值，反之为多值属性）、NULL属性、派生属性
- 解决方法：拆分、重新设定属性。未达到第一范式就无法建表。
第二范式（2NF）：在1NF的基础上，不存在非主属性部分函数依赖依赖于候选键
- 常见问题情形：主键为组合键，非主属性函数依赖于其中一个主属性。（主键仅为1个属性时必满足2NF）
- 解决方法：拆分该非主属性及该主属性为新表（其主键即为该主属性），原表去除该非主属性（主键不变）。
第三范式（3NF）：在2NF的基础上，不存在非主属性传递函数依赖于候选键
- 常见问题情形：设X、Y为非主属性，Z为主键，存在Z → Y → X
- 解决方法：拆分X、Y成为独立的表（其主键为决定因素Y），原表去除这些非主属性（主键不变）
巴斯-科德范式（BCNF）：在3NF的基础上，每个依赖关系的决定因素包含候选键（整体）（即不存在部分与传递函数依赖）
- 常见问题情形：设关系模式STJ(S, T, J)，函数依赖集F = {SJ → T, T → J}，候选键为SJ、ST（图示法求取）。S、T、J均为主属性，无非属性（此时必达到3NF），则依赖关系T → J的决定因素仅包含SJ的部分主属性，即部分函数依赖。（SJ → T满足要求）
- 解决方法：无（实际上达到3NF已足够）

4.5 模式分解

模式分解（Schema Decomposition）是关系模式中根据属性进行拆分后的集合。判断分解是否保持函数依赖、是否无损的方法如下所示：

4.5.1 保持函数依赖分解

保持函数依赖分解：设数据库模式ρ = {R_1, R_2, ... , R_k}是关系模式R的一个分解，F是R上的函数依赖集，ρ中的每个模式R_i上的函数依赖集为F_i。若{F_1, F_2, ... , F_k}等价于F（即相互逻辑蕴含），则称分解ρ保持函数依赖。进一步地，若分解后某些依赖关系是通过Armstrong公理推导得出，则称该分解具有冗余函数依赖。

【例1】关系模式R(A, B, C)，函数依赖集F = {A → B, B → C}。将其拆分为R1(A, B)、R2(B, C)，是否保持函数依赖？
【解】R1、R2的函数依赖集分别为F1 = {A → B}、F2 = {B → C}，直接可得{F1, F2} = F，故该分解保持函数依赖。

【例2】关系模式R(A, B, C)，函数依赖集F = {A → B, B → C, A → C}。将其拆分为R1(A, B)、R2(B, C)，是否保持函数依赖？
【解】R1、R2的函数依赖集分别为F1 = {A → B}、F2 = {B → C}，根据A → B、B → C可以推出A → C，使得{F1, F2} = F，故该分解具有冗余函数依赖，其保持函数依赖。

【例3】关系模式R(A, B, C)，函数依赖集F = {A → B, B → C, A → C}。将其拆分为R1(A, B)、R2(A, C)，是否保持函数依赖？
【解】R1、R2的函数依赖集分别为F1 = {A → B}、F2 = {A → C}，此时{F1, F2} ≠ F（注意与例2的区别），故不保持函数依赖。

【例4】关系模式R(A, B, C, D, E)，函数依赖集F = {A → B, D → E}。将其拆分为R1(A, B, C)、R2(D, E)，是否保持函数依赖？
【解】R1、R2的函数依赖集分别为F1 = {A → B}、F2 = {D → E}，直接可得{F1, F2} = F，故该分解保持函数依赖。

4.5.2 无损分解

有损：不能还原。无损：可以还原。

无损连接分解：将一个关系模式分解成若干个关系模式后，通过自然连接和投影等运算仍能还原到原来的关系模式。

【例1】设关系模式成绩(学号, 姓名, 课程号, 课程名, 分数)，函数依赖集为{学号 → 姓名, 课程号 → 课程名, (学号, 课程号) → 分数}，将其分解为成绩(学号, 课程号, 分数)、学生(学号, 姓名)、课程(课程号, 课程名)。分析原关系模式及分解后的各关系模式的范式等级，并判断该分解是否为无损分解。
【解】解题步骤如下：

分析原关系模式：显然该模式满足1NF，候选键为(学号, 课程号), 存在非主属性对候选键的部分函数依赖（学号 → 姓名、课程号 → 课程名），故不满足2NF。
分析分解后的各模式：分解后的3个模式的函数依赖集分别为{(学号, 课程号) → 分数}、{学号 → 姓名}、{课程号 → 课程名}。其各自均不存在非主属性对候选键的部分函数依赖，故均满足2NF；且均不存在非主属性对候选键的传递函数依赖，故均满足3NF；且各自的依赖关系中决定因素均为候选码，故均满足BCNF。
判断分解是否保持函数依赖：由上一步分析可知，显然该分解保持函数依赖。
进行自然连接
- 连接条件与方法：
  1. 双方具有同名属性列
  2. 双方存在以同名属性列为决定因素的函数依赖
  3. 还原非决定因素所对应的模式
- 由于有学号 → 姓名，故可自然连接成绩(学号, 课程号, 分数)与学生(学号, 姓名)，结果为成绩(学号, 课程号, 分数, 姓名)。（模式名任起）
- 由于有课程号 → 课程名，故可自然连接成绩(学号, 课程号, 分数, 姓名)与课程(课程号, 课程名)，结果为成绩(学号, 姓名, 课程号, 课程名, 分数)，可以还原。（还原方法不唯一）
上述自然连接的操作过程可以归纳为表格法，如下所示（最左列为分解后的各模式，最上行为所有属性），每次还原操作即为在空格处打上√：

自然连接

无损连接定理：设R的分解为ρ = {R1, R2}，F为R所满足的函数依赖集，则分解ρ具有无损连接性的必要条件为：

    R1 ∩ R2 → (R1 - R2)
or  R1 ∩ R2 → (R2 - R1)

其中模式的交集R1 ∩ R2的属性由双方公共元素组成，模式的差集R1 - R2、R2 - R1的属性为被减集的属性去除其与减集的公共属性。该定理表明若R1与R2的公共属性能决定R1中或R2中的特有属性，则该分解具有无损连接性。

【例2】设关系模式R=ABC，函数依赖集F={A → B}，则分解ρ1 = {R1(AB), R2(AC)}与分解ρ2 = {R1(AB), R3(BC)}是否都为无损分解？
【解】使用公式法：对于ρ1，由R1 ∩ R2 = A，R1 - R2 = B，因为A → B，故R1 ∩ R2 → R1 - R2，ρ1具有无损连接性。
对于ρ2，由R1 ∩ R3 = B，R1 - R3 = A，R3 - R1 = C（只需B → A或B → C即满足要求），不存在对应的函数依赖关系，故ρ2不具有无损连接性。
使用表格法亦容易得出结果。

5 并发控制 ⭐️

事务（Transaction）的ACID特性：

原子性（Atomicity）：事务包含的所有操作要么全部成功（commit），要么全部失败回滚（rollback）。这些操作是一个整体，不能部分地完成。
一致性（Consistency）：事务必须使数据库从一个一致性状态变换到另一个一致性状态，即一个事务执行之前和执之后都必须处于一致性状态。（转账操作）
隔离性（Isolation）：一个事务的执行不能被其他事务干扰，即一个事务内部的操作及使用的数据对并发的其他事务是隔离的。（可串行化）
持续性（Durability，永久性）：一个事务一旦被提交了，其对数据库中的数据的改变就是永久性的，无论发送何种故障，都不应对其有任何影响。

5.1 并发的问题

以下伪代码中的①②③仅表示“行号”或“时间步”

多个事务并发执行时容易产生的问题：

丟失更新/丢失修改：T1的修改操作被T2的修改操作覆盖了。

T1 {
    ① 读 A = 10;
    ②
    ③ A = A - 5 写回;
    ④
}

T2 {
    ①
    ② 读 A = 10;
    ③
    ④ A = A - 8 写回;
}

读“脏”数据：T1对A进行了修改，T2读取后T1进行回滚（ROLLBACK），造成T2读取到的是回滚前的值（“中间数据”，即“脏”数据）

T1 {
    ① 读 A = 20;
    ② A = A + 50 写回;
    ③
    ④ ROLLBACK;     // A恢复为20
}

T2 {
    ①
    ②
    ③ 读 A = 70;
    ④
}

不可重复读：在T1第一次读取A后，T2修改了A的值，导致T1重复修改A时读不到原来的数据。

T1 {
    ① {
        读 A = 20;
        读 B = 30;
        求和 sum = 50;
    }
    ②
    ③ {
        读 A = 70;
        读 B = 30;
        求和 sum = 100;   // 验算，发现出错
    }
}

T2 {
    ①
    ② {
        读 A = 20;
        A = A + 50 写回;
    }
    ③
}

解决方法：添加封锁协议

5.2 封锁协议

S锁和X锁：

S锁（读锁/共享锁）：允许事务读取数据但不允许写，多个事务可同时读取该数据。
X锁（写锁/排他锁）：允许事务读取和写入数据，但其他事务不能读取或写入该数据（具有排他性）。（若某事务比其他事务早添加X锁，则其他事务只有等该事务读写结束释放X锁后才能读写；事务执行完成时自动释放全部锁）

封锁协议（Locking Protocol）：

一级封锁协议：事务在修改数据之前必须先对其加X锁，直到事务结束才释放。
- 作用：防止丢失修改
- 丢失更新加锁：

T1 {
    ① 对A加X锁;
    ②
    ③ 读 A = 10;
    ④ A = A - 5 写回;
    ⑤ 释放对A的X锁;
    ⑥
    ⑦
    ⑧
}

T2 {
    ①
    ② 对A加X锁;
    ③ // 等待
    ④ // 等待
    ⑤ // 等待
    ⑥ 读 A = 5;      // 此时T1已完成对A的更新操作
    ⑦ A = A - 8 写回;
    ⑧ 释放对A的X锁;
}

二级封锁协议：在一级封锁协议的基础上，事务在读取数据之前先对其加S锁，读完后即可释放S锁。
- 作用：防止丢失修改，还可防止读“脏”数据
- 读脏数据加锁：

T1 {
    ① 对A加X锁;
    ② 读 A = 20;
    ③ A = A + 50 写回;
    ④
    ⑤ ROLLBACK;     // 事务执行完成时自动释放全部锁
    ⑥
    ⑦
    ⑧
}

T2 {
    ①
    ②
    ③
    ④ 对A加S锁;
    ⑤ // 等待
    ⑥ 读 A = 20;     // 等到A释放X锁之后才能进行读取
    ⑦
}

三级封锁协议：在一级封锁协议的基础上，事务在读取数据之前先对其加S锁，直到事务结束才释放。
- 作用：防止丢失修改、防止读“脏”数据与防止数据（不可）重复读
- 不可重复读加锁（读“脏”数据加锁方式基本同二级封锁协议）：

T1 {
    ① {
        对A与B加S锁;
        读 A = 20;
        读 B = 30;
        求和 sum = 50;
    }
    ②
    ③ {
        读 A = 20;
        读 B = 30;
        求和 sum = 50;
        释放对A与B的S锁;
    }
    ④
}

T2 {
    ①
    ② 对A加X锁;    // 由于A已加了S锁，故等待
    ③ // 等待
    ④ {
        读 A = 20;
        A = A + 50 写回;
        释放对A的X锁;
    }
}

两段锁协议：串行化。可能发生死锁，可以预防或人工解除。

6 数据库的安全性 ⭐️

保障数据库安全性的措施：

用户标识和鉴定：最外层的安全保护措施，可以使用用户帐户、口令及随机数检验等
存取控制：对用户进行授权，包括操作类型（如查找、插入、删除、修改等动作）和数据对象（主要是数据范围）的权限。（Grant、Revoke）
密码存储和传输：对远程终端信息用密码传输
视图的保护：对视图进行授权（注：无法通过视图进行数据更新！）
审计：使用一个专用文件或数据库，自动将用户对数据库的所有操作记录下来（常与追踪一起使用）

7 数据库备份与恢复技术 ⭐️

根据备份时数据库是否运作来划分备份技术：

冷备份（静态备份）：将数据库正常关闭，在停止状态下，将数据库的文件全部备份（复制）。
- 优点：非常快速（只需复制文件）；容易归档（简单复制即可）；容易恢复到某个时间点上（只需将文件再复制回去）；能与归档方法相结合，做数据库“最佳状态”的恢复；低度维护，高度安全
- 缺点：单独使用时，只能提供到某一时间点上的恢复；在实施备份的全过程中，数据库不能做其他工作；若磁盘空间有限，只能复制到磁带等其他外部存储设备上，速度很慢；不能按表或按用户恢复
热备份（动态备份）：利用备份软件，在数据库正常运行的状态下，将数据库中的数据文件进行备份。
- 优点：可在表空间或数据库文件级备份，时间短；备份时数据库仍可使用；可达到秒级恢复（恢复到某一时间点上）；可对几乎所有数据库实体做恢复；很快
- 缺点：不能出错，否则后果严重；若热备份不成功，所得结果不可用于时间点的恢复；因难于维护，要特别小心，不允许“以失败告终”

根据备份量来划分备份技术：

完全备份（全备）：备份所有数据。即使两个备份时间点之间数据没有任何变动，所有数据还是会被备份下来。
增量备份（增备）：仅记录上次备份之后的变动情况。在做数据备份前先判断数据的最后修改时间是否比上次备份的时间晚，若不是，则表示该数据未被修改，无需备份。
差量备份（差备）：同增量备份，但仅针对上一次完全备份之后。

日志文件：事务日志是针对数据库改变所做的记录，可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。

常见的数据库故障关系及其原因与解决方法：

事务本身的可预期故障
- 故障原因：本身逻辑
- 解决方法：在程序中预先设置Rollback语句
事务本身的不可预期故障
- 故障原因：算术溢出、违反存储保护
- 解决方法：由DBMS的恢复子系统通过日志，撤销事务对数据库的修改，回退到事务初始状态。（用户看不见）
系统故障
- 故障原因：系统停止运转
- 解决方法：通常使用检查点法（将事务放入对应的事务队列中）。（系统重启时自动完成）
- 两个事务队列：
  - 撒销（UNDO）事务队列：存放故障发生时未完成的事务
  - 重做（REDO）事务队列：存放故障发生前已提交的事务
介质故障
- 故障原因：外存被破坏
- 解决方法：更换介质（需要人为介入），再使用日志重做业务（自动）

8 数据库性能优化 ☀️

【总结】数据库性能优化方法：

集中式数据库优化（单节点）
1. 硬件系统：CPU、内存、I/O（硬盘，阵列）、网络
2. 系统软件：参数，如进程优先级、CPU使用权、内存使用
3. 数据库设计
  - 表与视图：表的规划；建立物化视图
  - 索引：常查询——建索引；常修改——避免索引
  - SQL优化：
    1. 以不相干子查询替代相干子查询
    2. 只检索需要的列
    3. 用带IN的条件子句等价替换OR子句
    4. 经常提交COMMIT，以尽早释放锁
    5. 尽可能减少多表查询
4. 应用软件：数据库连接池
分布式数据库优化（结点之间）：
- 通信代价：
  1. 全局查询树的变换
  2. 多副本策略
  3. 查询树的分解
  4. 半连接与直接连接

8.1 规范化与反规范化 ☀️

如前所述的规范化存在副作用：数据库规范化实际是对数据表的不断拆分，以达到更高的规范程度。这样使得多表关联查询（表连接操作）频繁，导致效率低下。表拆分得越多，查询性能也就越差。

反规范化（Denormalization）：规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术。通过有选择地在数据中加入特定的冗余数据，使得查询时减少表连接操作，从而提高数据检索速度和查询性能。

反规范化

反规范化的技术手段：

增加派生性冗余列：冗余列由现有列派生（计算得出）。例如已有“单价”和“数量”列，增加“总价”列。
增加冗余列：冗余列无法由现有列派生。例如已有“学号”列，增加“姓名”列。
重新组表：把拆分的表重新组表。
分割表：将表做水平分割（按属性分类，例如将各省的数据存放于各省分公司）。

特点：

优点：
1. 连接操作少，检索快、统计快
2. 需要查的表减少，检索容易（但导致更容易出错）
缺点（除数据不一致外均无解）：
1. 数据冗余，需要更大存储空间
2. 插入、修改、删除等操作开销更大
3. 数据不一致；可能产生添加、修改、删除异常
  - 解决方法：
    1. 触发器数据同步
    2. 应用程序数据同步
4. 更新和插入代码更难编写

【例】某集团公司在各省均设有分公司，现欲建立全国统一的销售管理信息系统，以便总公司及时掌握各分公司的销售情况。公司成立专门的项目组进行该系统的研发工作，其中张工负责其中的数据库设计工作。
张工和需求分析小组紧密合作，在设计出数据流图和数据字典的基础上，给出了数据库关系模式和相应的索引设计。同时考虑到未规范化关系模式可能引起的各类数据错误，对关系模式进行了全面的规范化处理，使所有关系模式均达到了3NF或BCNF。
在项目实施过程中，应用开发小组认为该设计方案未考虑应用功能的实际需求。如果严格按照设计方案实施，会对应用系统中整体性能产生较大影响。主要的原因在于进行数据查询时，会产生大量的多表连接操作，影响性能。而设计方案中的索引设计，并不能完全满足数据查询的性能要求。
应用开发小组还认为，该设计方案未考虑到信息系统中核心销售数据处理的特点：各分公司在使用该信息系统时只能操作自己分公司的销售数据，无权操作其它分公司的销售数据；只有总公司有权利操作所有销售数据，以便进行统计分析。
应用开发小组要求，在数据库设计方案中，必须针对实际应用功能的实现来考虑关系模式的规范化，必要时需要采用逆规范化或解除规范化的方法来保证性能要求。
问题1（8分）：
系统需要管理供应商和货物等信息，具体包括供应商姓名、地址以及货物名称、价格等，供应商可以提供0~n种货物，其公司地址也可能发生变化。请以供应商关系模式supplier(name, address, product, price)为例，解释不规范的关系模式存在哪些问题。
问题2（6分）：
应用开发小组认为张工的规范化设计虽然解决了未规范化关系模式带来的问题，但实际实现功能时会造成系统性能的下降，请解释其原因。
问题3（5分）：
请解释逆规范化方法，说明其优缺点。
问题4（6分）：
针对该信息系统中核心销售数据处理的特点，如采用关系表水平分割的逆规范化方法，请给出具体的解决方案，并说明该方案存在的问题。
【解】
问题1：
由题可得函数依赖关系图（如下所示），则可得候选键为(name, product)
规范化例题
该不规范的关系模式中存在的问题
（1）数据冗余：关系模式中多次重复记录了同一供应商的地址。
（2）插入异常：如果还未确定一个供应商有哪些货物，只是想添加一个供应商的地址信息，则会产生产品与
价格均为空的记录。
（3）修改异常：当修改一个供应商的地址时，需要将多条记录同时更新，若未同时更新，则数据产生不一致。
（4）删除异常：当删除一个供应商的货物时，其地址信息被一并删除。
问题2：
数据库规范化的过程，实际是对数据表的不断拆分，以达到更高的规范程度。这样处理带来的问题是，系统中大量查询不能通过单表完成，而需要将多表进行连接查询，所以表拆分得越多，查询性能也就越差。
问题3：
规范化设计后，数据库设计者希望牺牲部分规范化来提高性能，这种从规范化设计的回退方法称为反规范化技术。
逆规范化方法优点：提高统计、查询效率。
逆规范化方法缺点：增加了数据冗余，浪费存储空间，增、删、改操作的效率降低，可能导致数据不一致，可能产生添加、修改、删除异常。
问题4：
解决方案：将各省的数据存放于各省分公司。
该方案主要问题：
（1）在于总公司进行全国数据统计时，需要从各省服务器调取数据，效率较低。
（2）执行应用功能时需要动态选择分公司的数据库表，增加了应用程序的复杂度。

8.2 数据库索引 ☀️

数据库索引：提升查询效率，降低添加、修改、删除效率。采用B树，B+树等。

MySQL中采用B+树建立索引：

B+树

8.3 数据库视图 ☀️

数据库视图（View）是虚表，从一个或几个基本表（或视图）中导出，在系统的数据字典中仅存放视图的定义（即SQL查询语句），不存放视图。

优点：

简化用户操作（多表联合查询）
使用户能以多种角度看待同一数据
对重构数据库提供了一定程度的逻辑独立性
可以对机密数据提供安全保护（只读）

有时建立视图时需进行极为耗时的统计分析操作，为了解决该问题通常会建立针对性的关系表，但同一数据存储多份常造成数据不一致问题，解决方法如下：

应用程序实现：从应用程序层面中控制多个表的操作
触发器实现：发生变化时同步更新其他表
物化视图实现：将视图的内容物理存储起来，其数据随原始表变化，同步更新。（因此适用于多查询、少更新的情况）。

【例】某软件企业开发一套类似于淘宝网上商城业务的电子商务网站。该系统涉及多种用户角色，包括购物用户、商铺管理员，系统管理员等。在数据库设计中，该系统数据库的核心关系包括：
产品(产品编码, 产品名称, 产品价格, 库存数量, 商铺编码)
商铺(商铺编码, 商铺名称, 商铺地址, 商铺邮箱, 服务电话)
用户(用户编码, 用户名称, 用户地址, 联系电话)
订单(订单编码, 订单日期, 用户编码, 商铺编码, 产品编码, 产品数量, 订单总价)
不同用户角色有不同的数据需求，为此该软件企业在基本数据库关系模式的基础上，定制了许多视图。其中，有很多视图涉及到多表关联和聚集函数运算。
问题1（8分）：
商铺用户需要实时统计本商铺的货物数量和销售情况，以便及时补货，或者为商铺调整销售策略。为此专门设计了可实时查看当天商铺中货物销售情况和存货情况的视图：商铺产品销售情况日报表(商铺编码, 产品编码, 日销售产品数量, 库存数量, 日期)。数据库运行测试过程中，发现针对该视图查询性能比较差，不满足用户需求。
请说明数据库视图的基本概念及其优点，并说明本视图设计导致查询性能较差的原因。
问题2（8分）：
为解决该视图查询性能比较差的问题，张工建议为该数据建立单独的商品当天货物销售、存货情况的关系表。但李工认为张工的方案造成了数据不一致的问题，必须采用一定的手段来解决。
1）说明张工方案是否能够对该视图查询性能有所提升，并解释原因。
2）解释说明李工指出的数据不一致问题产生的原因。
问题3（9分）：
针对李工提出的问题，常见的解决手段有应用程序实现，触发器实现和物化视图实现等，请用300字以内的文字解释说明这三种方案。
【解】
问题1：
视图是虚表，从一个或几个基本表（或视图）中导出，在系统的数据字典中仅存放了视图的定义，不存放视图对应的数据。
视图的优点：
1、视图能简化用户的操作
2、视图机制可以使用户以不同的方式查询同一数据
3、视图对数据库重构提供了一定程度的逻辑独立性
4、视图可以对机密的数据提供安全保护
查询性能较差的原因是视图中“日销售产品数量”需要针对订单表做统计分析，订单表中有数量庞大的历史销售记录，所以这种操作极为耗时。
问题2：
1）张工方案能够对该视图查询性能有所提升，因为这样做能极大的减少统计分析的数据量，对小数据量进行统计，性能是能得以保障的。
2）由于当日订单数据既存储在订单表中，又存储在单独的当天货物销售、存货情况表中。同一数据存储了两份，一旦出现修改，未同步修改，则会造成数据不一致。
问题3：
应用程序实现：在进行订单的添加、修改、删除操作时，从应用程序中，控制对两个数据表都进行相关操作，以保障数据的一致性。
触发器实现：在应用程序中，只对订单表进行操作。但写触发器，当订单表发生变化时，把当日订单内容同步更新到当天货物销售、存货情况表中。
物化视图实现：建立“当天货物销售、存货情况”的物化视图，物化视图会把相应的数据物理存储起来，而且在订单表发生变化时，会自动更新。

8.4 数据库分区分表分库 ☀️

辨析分区与分表：

共性：
1. 都针对数据表
2. 都使用了分布式存储
3. 都提升了查询效率
4. 都低数据库的频繁I/O压力值
差异：
- 分区逻辑上还是1张表
- 分表逻辑上已是多张表（分库与之同理）

数据库分区分表分库

分区的常见方式：

范围分区
哈希分区
列表分区

3种分区方法

分区的优点：

相对于单个文件系统或硬盘，分区可以存储更多的数据。
数据管理比较方便。例如要清理或废弃某年的数据，直接删除该日期的分区数据即可。
精准定位分区查询数据，不需要全表扫描查询，大大提高数据检索效率。
可跨多个分区磁盘查询，来提高查询的吞吐量。
在涉及聚合函数查询时，可以很容易进行数据的合并。

9 综合案例分析练习

【例】某软件企业开发了一套新闻社交类软件，提供常见的新闻发布、用户关注、用户推荐、新闻点评、新闻推荐、热点新闻等功能，项目采用MySQL数据库来存储业务数据。系统上线后，随着用户数量的增加，数据库服务器的压力不断加大。为此，该企业设立了专门的工作组来解决此问题。
张工提出对MySQL数据库进行扩展，采用读写分离，主从复制的策略，好处是程序改动比较小，可以较快完成，后续也可以扩展到MySQL集群，其方案如下图所示。李工认为该系统的诸多功能，并不需要采用关系数据库，甚至关系数据库限制了功能的实现，应该采用NoSQL数据库来替代MySQL，重新构造系统的数据层。而刘工认为张工的方案过于保守，对该系统的某些功能，如关注列表、推荐列表、热搜榜单等实现困难，且性能提升不大；而李工的方案又太激进，工作量太大，短期无法完成，应尽量综合二者的优点，采用Key-Value数据库+MySQL数据库的混合方案。
经过组内多次讨论，该企业最终决定采用刘工提出的方案。
张工的读写分离方案
问题1（8分）：
张工方案中采用了读写分离、主从复制策略。其中，读写分离设置物理上不同的主/从服务器，让主服务器负责数据的（a）操作，从服务器负责数据的（b）操作，从而有效减少数据并发操作的（c），但却带来了（d）。因此，需要采用主从复制策略保持数据的（e）。
MySQL数据库中，主从复制是通过binarylog来实现主从服务器的数据同步，MySQL数据库支持的三种复制类型分别是（f）、（g）、（h）。
请将答案填入（a）~（h）处空白，完成上述描述。
问题2（8分）：
李工方案中给出了关系数据库与NoSQL数据的比较，如下表所示，以此来说明该新闻社交类软件更适合采用NoSQL数据库。请完成下表中的（a）~（d）处空白。
关系型非关系型对比填空
问题3（9分）：
刘工提出的方案采用了Key-Value数据库+MySQL数据库的混合方案，根据数据的读写特点将数据分别部署到不同的数据库中。但是由于部分数据可能同时存在于两个数据库中，因此存在数据同步问题。请用200字以内的文字简要说明解决该数据同步问题的三种方法。
【解】
问题1：
（a）写；（b）读；（c）锁争用；（d）数据冗余；（e）一致性；（f）、（g）、（h）基于SQL语句的复制（statement-basedreplication, SBR）、基于行的复制（row-based replication, RBR）、混合模式复制（mixed-based replication, MBR）
问题2：
（a）最终一致性；（b）非结构化数据；（c）柔性事务性/弱事务性；（d）海量数据
问题3：
1、实时同步方案，先查缓存，查不到再从DB查询，并保存到缓存；更新缓存时先更新数据库，再将
缓存设置过程期更新缓存。
2、异步队列方式同步，可采用消息中间件处理。
3、通过数据库插件完成数据同步。
4、利用触发器进行缓存同步。

一	二	三	四	五	六	日
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

KINA-0

Start having fun with KINA right now!