个人总结，仅供参考，欢迎加好友一起讨论
架构 - 数据库系统
考点摘要
- 数据库模式（★）
- 分布式数据库（★★★）
- 数据库设计阶段（★★）
- 概念结构设计 - ER模型（★）
- 逻辑结构设计 - 关系模式（★★）
- 关系代数（★★★★）
- 规范化理论（★★★★★）
- 并发控制（★）
- 数据库的安全性（★）
- 数据库备份与恢复技术（★）
第二版新教材上对应2.3.3及6，主要考点在6，这里一起合并总结了。新教材主要改动在数据设计，但是个人认为改动不是很大，仅供参考。
数据库系统模式
| 三层模式（三个级别） | |
|---|---|
| 外模式 用户模式，子模式 |
外模式（子模式、用户模式）用以描述用户看到或使用的那部分数据的逻辑结构，用户根据外模式用数据操作语句或应用程序去操作数据库中的数据 对应视图，外部视图，多个外部视图，用户级别 |
| 概念模式 模式 |
概念模式是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图 一个数据库只有一个概念模式 数据库概念视图，数据库中的关系表，概念级别 |
| 内模式 存储模式 |
内模式定义的是存储记录的类型、存储域的表示以及存储记录的物理顺序，指引元、索引和存储路径等数据的存储组织 一个数据库只有一个内模式 数据库内部视图，涉及存储结构，有索引和文件，物理级别 |
| 两层映像 | |
| 外模式 - 概念模式 | 关系表变化，不用修改应用程序 |
| 概念模式 - 内模式 | 存储结构变化，不用修改应用程序 |
| 两个独立性 | |
| 逻辑独立性 | 当模式改变时（例如增加新的关系，新的属性，改变属性的数据类型等），有数据库管理员对各个外模式/模式的映像做相应的改变，可以使外模式保持不变。应用程序是依据数据的外模式编写的，从而应用程序不必修改，保证了数据与程序的逻辑独立性，简称数据的逻辑独立性。 数据库的视图和基本表之间 |
| 物理独立性 | 当数据库的存储结构改变了，有数据库管理员对模式/内模式映射做相应的改变，可以使模式保持不变，从而应用程序也不必改变，保证了数据与程序的物理独立性，简称数据的物理独立性。 基本表与存储文件之间 |
| 三种关系 | |
| 基本关系 | 又称基本表或者基表，实际存在的表，实际存储数据的逻辑表示 |
| 查询表 | 查询结构对应的表 |
| 视图表 | 由基表或其他视图表导出的表，本身不独立存储，数据库只存放它的定义，常称为虚表 |
数据库视图
数据库视图：它一个虚拟表（逻辑上的表)，其内容由查询定义（仅保存SQL查询语句）。同真实的表一样，视图包含一系列带有名称的列和行数据。但是，视图并没有真正存储这些数据,而是通过查询原始表动态生成所需要的数据。
视图的优点：
- 视图能简化用户操作
- 视图使用户能以多种角度看待同一数据
- 视图对重构数据库提供了一定程度的逻辑独立性
- 视图可以对机密数据提供安全保护
物化视图：它不是传统意义上虚拟视图，是实体化视图，其本身会存储数据。同时当原始表中的数据更新时，物化视图也会更新。
数据模型（基本数据模型）
基本数据模型是按照计算机系统的观点来对数据和信息建模，主要用于DBMS的实现。基本数据模型是数据库系统的核心和基础。常用的基本数据模型有层次模型、网状模型、关系模型和面向对象模型。
数据模型三要素：
- 数据结构（静态）
- 数据操作（动态）
- 数据的约束条件
数据库完整性约束
完整性约束一共分为三种：实体完整性约束，参照完整性约束，用户自定义完整性约束。
| 实体完整性 | 约束主键 | 关系中的每一个元组对应一个实体，在关系中用主关键字来唯一标识一个实体，实体具有独立性，实体的主属性不能取空值 |
| 参照完整性 | 约束外键 | 用于约定两个关系之间的联系 |
| 用户定义完整性 | 限定取值区间 | 约束是用户定义某个具体数据库所涉及的数据必须满足的约束条件，是由具体应用环境来决定的 |
| 触发器 | 脚本编程 | 用于加强数据的完整性约束和业务规则等。它也是保证数据完整性的一种方法 |
典型例题：某数据库中有员工关系E(员工号，姓名，部门，职称，月薪)，产品关系P(产品号，产品名称，型号，尺寸，颜色)，仓库关系W(仓库号，仓库名称，地址，负责人)，库存关系Q(仓库号，产品号，产品数量)。
若数据库设计中要求：
①仓库关系W中的“负责人”引用员工关系E的员工号
②库存关系Q中的“仓库号，产品号”唯一标识Q中的每一个记录
③员工关系E中的职称为“工程师”的月薪不能低于3500元则
①②③依次要满足的完整性约束是：参照完整性，实体完整性，用户定义完整性
关系模型
| 关系 | 可以理解为一张二维表，每个关系都具有一个关系名，就是通常说的表名 |
| 元祖 | 可以理解为二维表中的一行，在数据库中经常被称为记录 |
| 属性 | 可以理解为二维表中的一列，在数据库中经常被称为字段 |
| 域 | 属性的取值范围，也就是数据库中某一列的取值限制 |
| 关键字 | 一组可以唯一标识元组的属性，数据库中常称为主键,由一个或多个列组成 |
| 关系模式 | 旨对关系的描述。其格式为：关系名(属性1，属性属性N)，在数据库中成为表结构 |
| 目或者度 | 关系模式中属性的个数 |
| 候选码（候选键） | 唯一标识元组，且无冗余 |
| 主码（主键） | 候选码任选一个 |
| 主属性和非主属性 | 组成候选码的属性就是主属性,其它的就是非主属性 |
| 外码（外键） | 其它关系的主键 |
| 全码（All-Key） | 关系模式的所有属性组是这个关系的候选码 |
关系代数
| 并 | S1∪S2 | 合并两个关系模式去重复列 |
| 交 | S1∩S2 | 取S1和S2两个关系都有的部分 |
| 差 | S1-S2 | 在S1中有但不在S2中的，以S1为准去掉S1和S2公共部分 |
| 笛卡尔积 | S1×S2 | 记录的条数是S1记录条数 * S2记录条数 |
| 投影 | δ1=4(R) | 是针对行，筛选符合条件的记录（行/元祖）,比如选择1=4意思是选出第一列和第四列数据相同的内容来 |
| 选择 | π3,1(S1) | 做列的投影，选取关系模式中某些需要的列，它是一种垂直操作 |
| 连接 | R⋈S |
等值连接，关系R、S取两者笛卡尔积中属性值相等的行/元组 等值连接要求R、S中有相同的属性，需要列出全部关系中的列 自然连接，一种特殊的等值连接，它要求比较的属性列必须是相同的属性组，并且把结果中重复属性去掉。注意与笛卡尔积的区别 |
| 外连接，外连接是建立在自连接基础上 | ||
| 左外连接 | R左外S，以R为基准，S中没有的用null代替 | |
| 右外连接 | R右外S，以S为基准，R中没有的用null代替 | |
| 全外连接 | R全外S，分别以R和S为基准，分别在S和R中没有的用null代替 | |
| 另外一些符号：∧逻辑与(and) ∨逻辑或(or) | ||
规范化理论
非规范化的关系模式，可能存在的问题包括：数据冗余、更新异常(修改操作一致性问题)、插入异常、删除异常。
候选键、主键、外键、主属性，非主属性
候选键：
唯一标识元祖，且无冗余。和主键区别候选键都可以做主键，人为选择其中一个做了主键，这些键都叫候选键
例：关系式S(Sid，Sno，Sdept，Sage)
比如Sid和Sno都可以做为主键，人为可选择Sid或Sno都可以，Sid和Sno称为候选键
主键：
Sno→Sdept，Sno→Sage，Sno是主键（也叫主码）
若有关系式SC(Sno，Cno，Grade)中，(Sno，Cno)是主键（复合主键/联合主键）
外键：
关系模式R中某属性集不是R的主键，是关系模式S的主键，这个属性集模式R外键
例：关系式SC(Sno，Cno，Grade)
Sno不是主键，但它是S(Sno，Sdept，Sage)的主键，则Sno是关系模式SC的外键。
主属性，非主属性：
包含在任何一个主键中（主键中的属性），称为主属性，否则为非主属性。
例如：S(Sno，Sdept，Sage)，Sno是主键，也是主属性，Sdept，Sage是非主属性。
求候选键
- 将关系模式的函数依赖关系用“有向图”的方式表示
- 找入度为0的属性，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有结点，则该属性集即为关系模式的候选键
- 若入度为0的属性集不能遍历图中所有结点，则需要尝试性的将一些中间结点（既有入度，也有出度的结点）并入入度为0的属性集中，直至该集合能遍历所有结点，集合为候选键
典型例题1：给定关系R(A1，A2，A3，A4)上的函数依赖集F={A1—A2，A3—A2，A2—A3，A2—A4}，R的候选关键字为？
解：参考下面”有向图“，找入度为0的属性起点集合，所以候选关键字是：(A1)
典型例题2：关系模式P(A，B，C，D，E，F，G，H，l，J)满足下列函数依赖:FD={ABD→E，AB→G，B→F，C→J，CJ→l，G→H}，求候选码？
解：参考下面”有向图“，找入度为0的属性起点集合，所以候选关键字是：(ABCD)
典型例题3：关系R(A，B，C)满足下列函数依赖:F{B→C，B→A，A→BC},关系R的候选关键字为？
解：参考下面”有向图“，找入度为0的属性起点集合，如果没有找寻中间结点，所以候选关键字是：(A)或者(B)
函数依赖
Armstrong公理
| 设关系式R(U，F)，U是关系模式R的属性集，F是U上一组函数依赖，如下推理规则： | |
| 自反律 | 若Y⊆X⊆U，则X→Y为F所蕴含[⊆属于，包含于] |
| 增广律 | 若X→Y为F所蕴含，且Z⊆U，则XZ→YZ为F所蕴含 |
| 传递律 | 若X→Y，Y→Z为F所蕴含，则X→Z为F所蕴含 |
| 根据以上，再推出以下规则： | |
| 合并规则 | 若X→Y，X→Z，则X→YZ为F所蕴含 |
| 伪传递规则 | 若X→Y，WY→Z，则XW→Z为F所蕴含 |
| 分解规则 | 若X→Y，Z⊆Y，则X→Z为F所蕴含 |
数据库范式
范式：符合某一种级别的关系模式的集合
第一范式，第二范式，第三范式，BC范式，第四范式，第五范式
第一范式（1NF）
在关系模式R中，当且仅当所有域只包含原子值，即每一个属性都是不可再分的数据项，则称关系模式R是第一范式。
第二范式（2NF）
在1NF的基础上，每一个非主属性完全依赖于主键，不存在部分依赖
例如：R(学号，姓名，班级，课程，成绩)
函数依赖：{学号→姓名，学号→班级，（学号，课程号）→成绩}
主键：（学号，课程号），姓名，班级部分依赖于主键，不属于2NF
需将其分解为：R1（学号，姓名，班级），R2（学号，课程，成绩）
第三范式（3NF）
在2NF的基础上，消除非主属性对主键/主码的传递函数依赖，也就是主键直接推出非主属性。
例如: Store(商店，商品,经营部，经理)
函数依赖:（商店，商品)→经营部，(商店，经营部)→经理
由于有传递依赖不满足3NF，将其分解为：R1(商店，商品，经营部)、R2(商店，经营部，经理)
BC范式（BCNF）
R属于BCNF当且仅当其F中每个依赖的决定因素必定包含R的某个候选键。
（如果要考这个范式，我认了，不要这1分了）
保持函数依赖与是否无损分解
保持函数依赖
设数据库模式ρ={R1，R2，…，Rk}是关系模式R的一个分解，F是R上的函数依赖集，p中每个模式Ri上的FD集是Fi。如果{F1，F2，…，Fk}与F是等价的（即相互逻辑蕴涵），那么称分解ρ保持FD。
典型例题1：有关系模式R(A，B，C)，F={A→B，B→C}，将其拆分为：R1(A，B) ，R2(B，C)，是否保持函数依赖？（T）
解：判断是否保持函数依赖，分解了2个关系，依赖关系分别代入R1和R2，有缺失的就是不保持关系，否则保持
典型例题2：有关系模式R(A，B，C)，F= {A→B，B→C，A→C}，将其拆分为:R1(A，B)，R2(B，C)，是否保持函数依赖？（T）
解：虽然分解的关系满足A→B和B→C，通过“传递律”A→C
典型例题3：有关系模式R(A，B，C) ，F={A→B，B→C，A→C}，将其拆分为:R1(A，B)，R2 (A，C)，是否保持函数依赖？（F）
解：缺少B→C
典型例题4：有关系模式R(A，B，C，D，E) ，F= {A→B，D→E}，将其拆分为:R1 (A，B，C)，R2 (D，E)，是否保持函数依赖？（T）
解：保持
无损连接分解
指将一个关系模式分解成若干个关系模式后，通过自然联接和投影等运算仍能还原到原来的关系模式。
如何判断保持函数依赖
注：判断是否保持函数依赖，除了基本的直接推导，还需要注意利用”Armstrong公理“的间接推导也成立
如何判断否无损分解
个人总结：
分解为2个关系的情况下:
- 选获取R1∩R2交集R，再获取R1-R2差集C1，以及R2-R1差集C2
- 判断“R→C1”或者”R→C2”，也就是交集分别推导差集
- 有一个成立就是无损分解
- 换一种说法，把R扔进任意一个R1或者R2中，看看能推出来吧
分解为3个关系：
- 使用二维表形式
- 二维表中有一行全部推导出就是无损分解
- 具体操作详见例题
数据库设计
| 基于DBS生存期的数据库设计分成五个阶段： | |
| 规划阶段 | （非必须阶段）建立数据库的必要性、可行性 |
| 需求分析 | 收集需求，理解需求，数据字典，数据流图，需求说明书/需求规格说明书 |
| 概念（结构）设计 | 建立概念模型，E-R模型 建立与DBMS无关的概念模型 |
| 逻辑（结构）设计 | 建立逻辑模型，依据转换规则和规范化理论，它的产出物是关系模式 将概念模型转化为某个特定的DBMS上的逻辑模型 |
| 物理（结构）设计 | 建立物理模式，结合数据库管理系统DBMS，硬件和OS特征 |
E-R模型
概念数据模型（实体-联系模型，E-R模型），是按照用户的观点来对数据和信息建模，主要用户数据库设计。概念模型主要用实体 - 联系方法表示，也就是E-R模型。
E-R图中包括三个要素：
- 实体（用矩形框表示，框内标注实体名称）
- 属性（用椭圆形表示，并用连线与实体连接起来）
- 实体之间的联系（用菱形框表示，框内标注联系名称，并用连线将菱形框分别与有关实体相连，并在连线上注明联系类型）。
需求分析
需求分析的目标是通过调查研究，了解用户的数据和处理要求，并按照一定格式整理成需求规格说明书。
需求分析的结果是否准确地反映了用户的实际要求，将直接影响到后面各个阶段的设计，并影响到设计结果是否合理和实用。
调查的重点是“数据”和“处理”，数据字典的内容：数据项、数据流、数据存储、数据加工（处理过程）。
数据库的元数据交由数据字典来进行管理，常用的加工描述方法有结构化语言、判定表和判定树。
概念结构设计
在需求分析阶段产生的需求说明书的基础上，按照特定的方法将它们抽象为一个不依赖于任何DBMS的数据模型，即概念模型（E-R图/局部E-R >>> 全局E-R图）。
集成的方法：
- 多个局部E-R图一次集成
- 逐步集成，用累加的方式一次集成两个局部E-R
集成产生的冲突及解决办法：
-
属性冲突，包括属性域冲突和属性取值冲突
属性域冲突（例：不同学校编码方式不同）
属性值冲突（例：重量有的采用千克，有的是克）
-
命名冲突，包括同名异义和异名同义
-
结构冲突，包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。（例：职工在某一应用中是实体，在另一个应用中变成了属性）
逻辑结构设计
逻辑设计也称为逻辑结构设计，其任务是将概念模型转化为某个特定的DBMS上的逻辑模型（层次模型、网状模型、关系模型）。
-
E-R图向关系模式的转换：
E-R图的实体转换为关系
E-R的属性转换为关系的属性
E-R图的关键字转换为关系的关键字
-
关系模式的规范化
-
确定完整性约束（保证数据的正确性）
实体完整性约束
参照完整性约束
用户自定义完整性约束
触发器
-
用户视图的确定（提高数据的安全性和独立性）
根据数据流图确定处理过程使用的视图
根据用户类别确定不同用户使用的视图
-
应用程序设计
物理设计
- 确定数据库存储结构与存取方法
- 设计存储记录结构，包括记录的组成、数据项的类型和长度，以及逻辑记录到 存储记录的映射
- 确定数据存储安排
- 设计访问方法，为存储在物理设备上的数据提供存储和检索的能力
- 进行完整性和安全性的分析与设计
- 数据库程序设计
反规范化
由于规范化会使表不断的拆分，从而导致数据表过多，这样虽然减少了数据冗余，提高了增，删，改的速度，但会增加查询的工作量。系统需要进行多次连接，才能进行查询操作，使得系统效率大大下降。反规范化说白了就是以空间换时间。
| 增加冗余列 | 增加冗余列是指在多个表中具有相同的列，它常用来在查询时避免连接操作。例如：以规范化设计的理念，学生成绩表中不需要字段“姓名”，因为“姓名”字段可以通过学号查询到，但在反规范化设计中，会将“姓名”字段加入表中。这样查询一个学生的成绩时，不需要与学生表进行连接操作，便可得到对应的“姓名”。 | |
| 增加派生列 增加派生性的冗余列 |
增加派生列指增加的列可以通过表中其他数据计算生成。它的作用是在查询时减少计算量，从而加快查询速度。例如：订单表中，有商品号、商品单价、采购数量，我们需要订单总价时，可以通过计算得到总价，所以规范化设计的理念是无须在订单表中设计“订单总价”字段。但反规范化则不这样考虑，由于订单总价在每次查询都需要计算，这样会占用系统大量资源，所以在此表中增加派生列“订单总价”以提高查询效率。 | |
| 重新组表 | 重新组表指如果许多用户需要查看两个表连接出来的结果数据，则把这两个表重新组成一个表来减少连接而提高性能。 | |
| 分割表 | 水平分割 | 根据一列或多列数据的值把数据行放到两个独立的表中。水平分割通常在下面的情况下使用。情况1：表很大，分割后可以降低在查询时需要读的数据和索引的页数，同时也降低了索引的层数，提高查询效率。情况2：表中的数据本来就有独立性，例如表中分别记录各个地区的数据或不同时期的数据，特别是有些数据常用，而另外一些数据不常用。情况3：需要把数据存放到多个介质上。 |
| 垂直分割 | 把主码和一些列放到一个表，然后把主码和另外的列放到另一个表中。如果一个表中某些列常用，而另外一些列不常用，则可以采用垂直分割，另外垂直分割可以使得数据行变小，一个数据页就能存放更多的数据，在查询时就会减少I/O次数。其缺点是需要管理冗余列，查询所有数据需要连接操作。 | |
事务管理（4个特征）
数据库系统DBMS运行的基本工作单位是事务，事务相当于操作系统中的进程，是用户定义的一个数据库操作序列，这些操作序列要么全做要么全不做，是一个不可分割的工作单位。
事务通常以BEGIN TRANSACTION语句开始，以ROLLBACK（事务回滚）或者COMMIT（事务提交）语句结束。
| 事务的4个属性（4个特性）： | |
| 原子性 | 操作，操作序列（事务）要么全做，要么全不做 |
| 一致性 | 数据，数据库从一个一致性状态，变到另一个一致性状态 |
| 隔离性 | 执行，一个事务的执行不能被其他事务干扰 |
| 持续性 | 变化，一个事务一旦提交，它对数据库的改变是永久的，即便系统出现了故障 |
数据库安全
| 措施 | 说明 |
|---|---|
| 用户标识和鉴定 | 最外层的安全保护措施，可以使用用户帐户、口令及随机数检验等方式 |
| 存取控制 | 对用户进行授权，包括操作类型（如查找、插入、删除、修改等动作）和数据对象（主要是数据范围）的权限。（Grant和Revoke） |
| 密码存储和传输 | 对远程终端信息用密码传输 |
| 视图的保护 | 对视图进行授权 |
| 审计 | 使用一个专用文件或数据库，自动将用户对数据库的所有操作记录下来 |
并发控制
产生的问题
| 并发产生的问题： |
|---|
| 丢失更新 |
| 不可重复读问题 |
| 读出“脏”数据 |
排他X锁与共享S锁
处理并发控制的主要方法是采用封锁技术。
| 处理并发控制的主要方法是采用封锁技术排他型封锁（X锁）和共享型封锁（S锁） | |
| 排他型封锁 简称X锁 |
如果事务T对数据A（可以是数据项、记录、数据集，乃至整个数据库）实现了X封锁，那么只允许事务T读取和修改数据A，其他事务要等事务T解除X封锁以后，才能对数据A实现任何类型的封锁。可见X封锁只允许一个事务独锁某个数据，具有排他性 |
| 共享型封锁 简称S锁 |
X封锁只允许一个事务独锁和使用数据，要求太严。需要适当放宽，例如可以允许并发读，但不允许修改，这就产生了S封锁概念。S封锁的含义是：如果事务T对数据A实现了S封锁，那么允许事务T读取数据A，但不能修改数据A，在所有S封锁解除之前绝不允许任何事务对数据A实现X封锁 |
| X锁 | 写锁 | 排他锁 | 事务T对数据A加上X锁时，只允许事务T读取和修改数据A，其他事务不能再对A加任何锁，直到T释放A上的锁 |
| S锁 | 读锁 | 共享锁 | 事务T对数据A加上S锁时，其他事务只能再对数据A加S锁，而不能加X锁，直到T释放A上的S锁 |
封锁协议
| 丢失更新 | 两个事务T1和T2同时读入同一数据并修改，T2提交的结果将破坏T1的结果，T1的修改被丢失 |
| 对T1加X锁（写锁），那么T2只能在T1解锁后读 | |
| 读赃数据 | T1修改了某一个数据，T2读取了同一个数据，T1由于某种原因被撤销，则T2读到的数据就是赃数据 |
| 修改时加排他锁，直到事务提交后才释放，读取时加共享锁，读取完释放T1读取数据时加上共享锁后，不允许任何事物操作该数据，只能读取 | |
| 不可重复读 | T1读取某一数据，T2读取某一数据，并进行修改，T1为了对读取值进行校对再读取时，得到不同结果 |
| T1加X锁（写锁）后，T2对同一数据加X锁（写锁），这样T1的锁解开后，才可以调用T2 |
| 一级封锁协议 | 事务T1在修改A之前必须先对其加X锁，直到事务结束才释放 可防止丢失修改 |
| 二级封锁协议 | 在一级封锁协议加上事务T1在读取数据A之前先对其加S锁，读完后即可释放S锁 可防止丢失修改，可防止读脏数据 |
| 三级封锁协议 | 在一级封锁协议加上事务T1在读取数据R之前先对其加S锁，直到事务结束时才释放 可防止丢失修改，可防止读脏数据，防止数据重复读 |
| 两段锁协议 | 分为封锁阶段（扩展）和释放阶段（收缩）。封锁阶段只能加锁、扩展阶段只能解锁 可串行化的，可能发生死锁 |
数据库备份
数据库备份按照不同方式可分为多种，这里按照备份内容分为物理备份和逻辑备份两类。
冷备份（静态备份）：
- 将数据库正常关闭，在停止状态下将数据库文件全部备份（复制）下来
- 优点：非常快速的备份方法（只需备份文件）；容易归档（简单复制即可），容易恢复到某个时间点上（只需将文件再复制回去），能与归档方法相结合，做数据库“最佳状态”的恢复，低度维护，高度安全
- 缺点：单独使用时，只能提供到某一时间点上的恢复；在实施备份的全过程中，数据库必须要作备份而不能做其他工作，若磁盘空间有限只能复制到磁盘等其他外部存储设备上，速度会很慢；不能按表或按用户恢复
热备份（动态备份）：
- 利用备份软件，在数据库正常运行的状态下，将数据库中的数据文件备份出来
- 优点：可在表空间或数据库文件级备份，备份的时间短，备份时数据库仍可使用；可达到秒级恢复，可对几乎所有数据库实体做恢复，恢复是快速的
- 缺点：不能出错，否则后果严重，若热备份不成功所得结果不可用于时间点的恢复；因难于维护，所有要特别小心，不允许以失败告终
按照备份容量分为物理备份和逻辑备份两类。
完全备份：
- 将数据库的内容全部备份
- 不足之处在于，各个全备份磁带中的备份数据存在大量的重复信息；另外，由于每次需要备份的数据量相当大，因此备份所需时间较长
增量备份：
- 只备份上次完全、增量或差异备份以来修改的数据
- 因此备份的数据量不大，备份所需的时间很短。但增量备份的数据恢复是比较麻烦的。必须具有上一次全备份和所有增量备份磁带（一旦丢失或损坏其中的一盘磁带，就会造成恢复的失败），并且它们必须沿着从全量备份到依次增量备份的时间顺序逐个反推恢复，因此这就极大地延长了恢复时间
差异备份：
- 备份自上次完全备份后发生变化的所有数据
- 差异备份在避免了另外两种备份策略缺陷的同时，又具备了它们各自的优点。首先，它具有了增量备份需要时间短、节省磁盘空间的优势；其次，它又具有了全量备份恢复所需磁带少、恢复时间短的特点。系统管理员只需要两盘磁带，即全备份磁带与灾难发生前一天的差异备份磁带，就可以将系统恢复
数据库故障与恢复
| 故障关系 | 故障原因 | 解决办法 | |
|---|---|---|---|
| 事务故障 | 可预期故障 | 本身逻辑 | 在程序中预先设置Rollback语句 |
| 不可预期故障 | 算术溢出，违反存储保护 | 由DBMS的恢复子系统通过日志，撤销事务对数据库的修改，回退到事务初始状态 | |
| 系统故障 | 系统停止运转 | 通常使用检查点法（系统重启时自动完成） | |
| 介质故障 | 外存被破坏 | 一般使用日志重做业务 | |
| 撤销事务（UNDO）：故障发生时未完成的事务，放入Undo撤销。 重做事务（REDO）：故障发生前已提交的事务，放入Redo重做。 | |||
分布式数据库
概念
大量的数据在网络上传输是不合适的，在此背景下才需要有分布式数据库。由一组数据组成的，这组数据分布在计算机网络的不同计算机上，网络中的每个节点具有独立处理的能力（成为场地自治），它可以执行局部应用，同时每个节点也能通过网络通信子系统执行全局应用，这就是分布式数据库的概念。
分布式数据库物理上面是隔离的，逻辑层面上是一个完整的整体的数据库。数据都存在局部的数据库中，通过分布模式，整合在一起。
特点
- 数据的分布性，分布式数据库中的数据分布于网络中的各个结点，它既不同于传统的集中式数据库，也不同于通过计算机网络共享的集中式数据库系统。
- 集中与自治共享结合的控制结构，各局部的DBMS可以独立地管理局部数据库，具有自治的功能。同时，系统又设有集中控制机制，协调各局部DBMS的工作，执行全局应用。
- 适当增加数据冗余度，在不同的场地存储同一数据的多个副本，可以提高系统的可靠性和可用性,同时也能提高系统性能。
- 提高系统的可用性，即当系统中某个节点发生故障时,因为数据有其他副本在非故障场地上，对其他所有场地来说，数据仍然是可用的,从而保证数据的完备性。
- 全局的一致性（可串行性和可恢复性），主要表现在数据在逻辑上的统一性和数据在管理上的统一性两个方面。分布式数据库系统通过网络技术把局部的、分散的数据库构成一个在逻辑上单一的数据库，从而呈现在用户面前的就如同是一个统一的、集中式的数据库。这就是数据在逻辑上的统一性，因此，它不同于由网络互联的多个独立数据库。分布式数据库是由分布式数据库管理系统统一管理和维护的，这种管理上的统一性又使它不同于一般的分布式文件系统。
- 透明性，用户在使用分布式数据库时，与使用集中式数据库一样，无须知道其所关心的数据存放在哪里，存储了几次。用户需要关心的仅仅是整个数据库的逻辑结构。
| 分布式数据库（与集中式数据库对比优缺点） | |
| 坚固性好 | 由于分布式数据库系统是由多个位置上的多台计算机构成的，在个别结点或个别通信链路发生故障的情况下，它仍然可以降低级别继续工作，如果采用冗余技术，还可以获得一定的容错能力。因此，系统的坚固性好，即系统的可靠性和可用性好。 |
| 可扩充性好 | 可根据发展的需要增减结点，或对系统重新配置，这比用一个更大的系统代替一个已有的集中式数据库要容易得多。 |
| 可改善性能 | 在分布式数据库中可按就近分布，合理地冗余的原则来分布各结点上的数据，构造分布式数据库，使大部分数据可以就近访问，避免了集中式数据库中的瓶颈问题，减少了系统的响应时间，提高了系统的效率，而且也降低了通信费用。 |
| 自治性好 | 数据可以分散管理，统一协调，即系统中各结点的数据操纵和相互作用是高度自治的，不存在主从控制，因此，分布式数据库较好地满足了一个单位中各部门希望拥有自己的数据，管理自己的数据，同时又想共享其他部门有关数据的要求。 |
| 虽然分布式数据库系统与集中式数据库相比有不少优点，但同时也需要解决一些集中式数据库所没有的问题。首先，异构数据库的集成问题是一项比较复杂的技术问题，目前还很难用一个通用的分布式数据库管理系统来解决这一问题。其次，如果数据库设计得不好，数据分布不合理，以致远距离访问过多，尤其是分布连接操作过多，不但不能改善性能，反而会使性能降低。 | |
分布透明性
| 分片透明 | 指用户不必关心数据是如何分片的，它们对数据的操作在全局关系上进行，即如何分片对用户是透明的。 分布透明性的最高层次 |
| 复制透明 | 用户不用关心数据库在网络中各个节点的复制情况，被复制的数据的更新都由系统自动完成。 |
| 位置透明 | 是指用户不必知道所操作的数据放在何处，不必了解片段的存储场地，即数据分配到哪个或哪些站点存储对用户是透明的。 |
| 逻辑透明 局部数据模型透明性 |
最低层次的透明性，该透明性提供数据到局部数据库的映像，即用户不必关心局部DBMS支持哪种数据模型、使用哪种数据操纵语言，数据模型和操纵语言的转换是由系统完成的。因此，局部映像透明性对异构型和同构异质的分布式数据库系统是非常重要的。 |
2PC事务
2PC事务提交的两个阶段：文章来源：https://www.toymoban.com/news/detail-490455.html
- 表决阶段，目的是形成一个共同的决定
- 执行阶段，目的是实现这个协调者的决定
两条全局提交规则：文章来源地址https://www.toymoban.com/news/detail-490455.html
- 只要有一个参与者撤销事务，协调者就必须做出全局撤销决定
- 只有所有参与者都同意提交事务，协调者才能做出全局提交决定
到了这里，关于【新版】系统架构设计师 - 数据库系统的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
