软考：高级软件架构师学习笔记——数据库|dbms|key|sql|应用程序|视图|转储|软件架构师|软考

核心知识

数据库体系结构数据库模式三层模式$两层映射关系

这里的模式是集中数据库的模式

对于用户或者程序员来说，是外模式，它对应用户视图

概念模式简称为模式，数据的逻辑结构，存储的基本表结构

内模式是存储文件

外模式-概念模式映射实现了逻辑独立性，外模式是根据概念模式来的
概念模式-内模式映射实现了物理独立性，概念模式是根据内模式来的

概念模式下有概念级数据库

内模式下有物理级数据库

关系表的3种类型

在概念模式中存储的是基本表，对于关系数据库而言，就是关系表，关系表有3种类型：

基本表就是正常的表，查询表就是执行查询语句的时候，输出的表

视图表是虚拟机的

数据库视图

由于只存粗SQL查询语句，所以每次使用都会查询一次，这里问题就是效率不高

物理视图适合读多写少的场景，不然每次都得更新数据，比较麻烦

分布式数据库分布式数据库的特点

分布式数据库和前面的集中式数据库相比，还会有一个数据分布独立性（分布透明性）

分布数据库模式

分布数据库在局部DBMS中，就是集中式数据库的模式

在全局DBMS来看，对外是全局外模式，然后是全局概念模式

分片模式：数据如何切割
分布模式：数据如何放置

分布透明性和分片方式

分布透明性主要有四种：

分片方式有三种

分布式数据库的组成和结构

分布式数据库的事务

数据库设计过程整体

数据流图是以图的形式来展示数据的转换过程

数据字典：数据的具体含义

物理设计考虑索引

概念结构设计

1️⃣属（属性冲突）
→ 看属性取值范围或类型是否打架
例：年龄字段同时出现"18"和"成年"——数值型与字符型冲突

2️⃣名（命名冲突）
→ 查同名不同义/异名同义陷阱

同名异义：两个"用户ID"分别指客户编号和员工编号
异名同义："手机号"与"联系电话"指向同一信息

3️⃣结（结构冲突）
→ 比对同一实体的不同描述维度
例：同一客户在A系统有5个属性字段，在B系统却有7个字段——属性数量/结构差异
或同一实体在E-R图中被抽象为实体，在另一图中却作为属性存在

ER模型

E-R模型-联系类型判断

逻辑结构设计

E-R图向关系模式的转换

分为实体向关系模式的转换和联系向关系模式的转换，首先实体是肯定要转换为一个关系模式的

复杂的联系向关系模式的转换，分为三种情况：

第一种：一对一，比如一个班级有一个班长，此时由两种方式，一种是独立关系模式，独立关系模式的意思是在搞出一个新的表格，这个新的表格中，这个表格中由可以由班长作为主键，或者班级作为主键都可以，然后把相关的属性加入进来。或者是直接合并为一个表格，叫做归并

第二种：一对多，一个班级有多个学生，此时可以独立关系模式，合并成一个表格，但是需要用学生作为主键，如果用班级作为主键，那么就只能存一条数据了，此时肯定会重复。还可以直接将归并到多端。记住一句，多是老大

第三种：多对多，一个学生可以选择多个课程，一个课程可以被多个学生选择，此时只能选择独立模式，两端主键合起来作为合并表的主健

首先每个实体A，B，C肯定是一个关系模式，此时就有三个关系模式了，然后三个实体之间的关系合并起来可以构成一个独立的关系模式，所以此时有4个

供应关系是供应商、项目、零件组成的，是三个实体的多对多的关系

每个员工可以参加多个项目，同时项目可以被多个员工参加，所以是多对多的关系，多对多只能选择独立的方式

关系模型的概念

候选码由一个或者多个属性组成

候选码有多个，可以从候选码中选择一个作为主键，主键只有一个，比如工号和身份证在公司都可以标识一个人，那么工号和身份证号都可以作为候选码，此时我们选择工号作为主键即可

完整性约束

了解触发器是约束

派生属性就是冗余属性，就是一个属性可以由另外一个属性计算得到，比如年龄就可以根据出生日期得到，所以年龄就是派生属性。

关系代数

关系代数是针对关系模式做的代数运算，关系代数主要考虑两个表之间的并、交、差、笛卡尔积、投影、选择、连接

s1-s2 就是s1中去除s1和s2相交的

笛卡尔积是两个表的合并，假设s1有三列，s2有三列，那么合起来就是6列，行是二者的成绩，s1有n行，s2有m行，那么笛卡尔积就有m*n行

投影是垂直，也就是select 列名1，列名2

选择是水平，也就是where 列名1=条件

连接就是列去重，行要根据去重的列求相等的

先把表切割小了，再做自然连接，此时性能就会好

规范化理论

未规范化所带来的问题。如上所示就是没有规范化的基本表，可以看到很多问题，我们规范化的核心就是为了解决这些问题。

规范化理论-函数依赖

规范化理论-键

规范化理论-求候选键

这个的核心意思就是将关系模式的函数依赖用有向图表示，然后将所有入度为0的选出来，这些一定是候选键的一部分，之所以说是一部分，是因为有可能这些是无法遍历所有的，此时就需要将中间节点加进来了。注意对于只有入度，没有出度的节点来说，一定不会是候选健的一部分。

第三题中，C肯定不是，因为C只有入度没有出度

规范化理论-Armstrong公理

核心就是大推小

R，U是属性集合，F是函数依赖集合

规范化理论-范式判断

解决问题通过拆分表格就好了，不断拆分表格，逐步由1NF到BCNF，第三范式必须在第二范式基础上才会被考虑，如果你都没有满足第二范式，那么就不需要考虑第三范式了

拆：将复合属性拆分为最小单元
看：检查是否存在多值属性（如一个字段存多个电话号码）
查：排查NULL值滥用（除标识列外，关键属性应避免空值）

如上所示高级职称可以分为副教授和教授，所以是可以拆分的，所以此时不满足INF

不满足第一范式，那么它连二维表都不满足的

数据冗余：每条选课记录重复存储课程学分（如计算机课程学分在多行重复出现）
更新异常：修改某课程学分需遍历所有相关行，易出错且效率低
插入异常：新增课程时若暂无学生选修，无法插入学分信息
删除异常：删除某学生选课记录时，会连带删除该课程的学分数据

解决这类问题，第一步先找候选键（可能有多个），然后看非候选键（成绩和学分）是否有对候选键的部分依赖，如上所示学分只依赖课程号

学生选课表（学号，课程号，成绩）主键：（学号，课程号）完全依赖：成绩同时依赖学号和课程号
课程信息表（课程号，学分）主键：课程号完全依赖：学分仅依赖课程号

首先候选键只有学号，所以这里没有部分依赖，所以是满足2NF的，你不要管系位置和学号有没有关系，就是候选键就只有一个，那么就没有部分依赖

现在的问题是非主属性通过其他属性（非主属性）间接依赖候选键

当前模式分析候选键：学号（唯一标识学生）传递依赖链：学号→系号→系名/系位置违反2NF的根源：系名/系位置作为非主属性，通过系号间接依赖于学号，构成传递依赖

拆分前模式
R（学号，姓名，系号，系名，系位置）

拆分后满足2NF的模式

学生表（学号，姓名，系号）主键：学号消除传递依赖：系号作为外键引用系表
系表（系号，系名，系位置）主键：系号完全消除传递依赖：系名/系位置直接依赖于系号

对于这个例题来说，每一个老师只教一门课程，所以（T->J）,每门课程有若干老师，某一学生选定某门课，就对应一个固定老师，所以(S,J->T)，这就是它的函数依赖集合

候选键为S，T和S，J都可以

主属性是S T J ，没有非主属性，所以自动满足第2范式和第三范式

在函数依赖X→Y中，X称为决定因素，X必须是候选键才可以，这是决定BC范式的核心

这里的函数依赖有两个（T->J）(S,J->T)，可以看到（T->J）中的T没有包含候选码S，T或者S，J，所以不符合，而(S,J->T)满足，只要有一个不满足，那么就不满足BC范式

例题：

在这里面，可以找到候选码就是A1 A5

可以看到肯定不满足第二范式，因为存在部分依赖A2只依赖A1，A3只依赖A1，所以只满足第一范式

所以我们可以把属性集拆分为（A1，A2，A3）（A3，A4）（A1,A5,A6）

此时（A1，A2，A3）的候选键为A1，A1决定A2 A3，此时就满足BC范式

此时（A3，A4）的候选键为A3，A3决定A4，此时就满足BC范式
此时（A1,A5,A6）的候选键为A1和A5，A1和A5决定A6，此时就满足BC范式

规范化理论

规划化的过程就是通过拆分表格来实现了。这个过程可以叫做关系分解，就是将老关系拆分为新的关系，也不能随便拆分，首先必须保证拆分后依然和原有的函数依赖集合保持一致，拆分之后的关系模式能够无损。下面介绍是否保持函数依赖和是否无损分解的方式。

是否保持函数依赖

依赖函数很好看，我们只需要看拆分后的能不能通过Amstrong公里来推出原来的关系就好了

例题一：R1（A,B），包含了A->B R2(B,C)，包含了B->C,保持函数依赖
例题二：R1（A,B），包含了A->B R2(B,C)，包含了B->C，同时隐含了A->B->C,保持函数依赖

例三：R1（A,B）可以推出A->B。R2（A,C）可以推出A->C,但是无法推出B-C，所以没有保持函数依赖

例四：R1（A,B）可以推出A->B。R2（D,E）可以推出D->E,保持了函数依赖，我们不用关心C

是否无损分解

是否无损可以通过两种方式来确定：

一种方式是表格法（用函数推导的方式看看能不能推出全部，表格法会比较直观）

一种方式是数学法（前提是只能分解为两个关系模式）

表格法是这样的，列是每一个字段，行是表名

分析过程如下：

首先找到同名属性列，此时可以找到学号是一样的。学号只能决定姓名，同时在学生表中姓名是存在的，所以成绩中也可以把姓名给补齐

接下俩看课程号同名的，可以决定课程名，课程中课程名是存在的，所以可以把成绩中的课程名给补齐，所以

这种方法是数学法，此时将关系分成了两个，就可以用这种方法，核心就是计算3个东西，一个是R1∩R2，一个是R1-R2，一个是R2-R1，算出来之后，只需要看能不能通过R1∩R2的结果根据关系推出R1-R2或者R2-R1，只要能推出一个就可以了。

如上例子中，p1中，可以由A->B，所以无损，p2，不可以推出B->A,B->C所以有损

并发控制事物的ACID特性

转账操作就是一致性，A给B转账500，那么B就加500，A就减500

并发控制存在的问题

丢失更新：两个事务同时读取并修改同一数据，后提交的事务覆盖了先提交的事务的修改，导致其中一个事务的更新完全丢失。

不可重复读：同一个事务内，两次读取同一数据，中间被其他事务修改并提交，导致两次读取的结果不一致。

读脏数据：一个事务读取了另一个事务未提交的修改数据，随后该事务回滚，导致读取到的数据是无效的 “脏数据”。脏数据就是中间过程的数据，并不是最终的数据。

解决方式----封锁协议

S是共享锁，读锁，如果一个事务加了读锁之后，另外一个事务依然可以加读锁，但是另外一个事务不可以加写锁，因为写锁是独享锁。

X是写锁，独享锁，如果一个事务加了写锁之后，另外一个事务不可以加任何锁。

协议是手段，隔离级别是目标

数据库通过设置不同的事务隔离级别来解决这些问题：

读未提交（Read Uncommitted）：三个问题都无法解决
读已提交（Read Committed）：解决脏读，仍存在不可重复读、丢失更新
可重复读（Repeatable Read）：解决脏读、不可重复读，仍存在丢失更新（MySQL InnoDB 默认级别）
可串行化（Serializable）：解决所有三个问题，但性能最低

事务隔离级别

对应封锁协议

解决丢失更新

解决脏读

解决不可重复读

解决幻读

读未提交

读已提交

二级封锁协议

可重复读

三级封锁协议

❌（InnoDB 通过 MVCC 解决）

可串行化

严格三级协议 + 范围锁

举例：丢失更新加锁

举例：读脏数据加锁

举例：不可重复读加锁

数据库的安全性

视图是不能修改的

触发器是完整性约束的，是被动触发的

数据备份

核心一点：冷备份的时候，需要将数据库停止

日志文件：先写日志，在写数据库，所以恢复的时候，可以用日志来恢复

恢复的时候

先找最近的全备，然后找最近的差备，然后加上差备后面的所有增备

如果最近没有差备，那么就只能找所有的增备了

数据故障与恢复

反规范化

有时候规范化会把表拆的很散，导致操作数据的时候需要操作多个数据表，比如成绩表中，有学号课程号成绩。但是我们在查询的时候需要显示学生姓名，这个时候就想把学生姓名加入进来，这样就可以一次查询就好了，所以虽然冗余了，不满足范式了，但是做业务更方便了。

派生性冗余列：这个列是通过其他列计算得到的

数据库索引

数据库视图

分区分表分库

NoSQL

联邦数据库

数据库性能优化

思维导图

# 数据库系统 - 核心知识思维导图（完整版）│├── 0️⃣ 数据库基础概念 (★★★)│   ├── 数据库模式（三级模式）│   │   ├── 外模式（用户级）：对应数据库用户视图，是用户需要使用的部分数据的描述，描述特定用户或应用程序所见的局部数据逻辑结构，如用户看到的部分表或字段。例如：用户A只能查看“员工表”的姓名和部门字段，这种权限控制通过外模式实现│   │   ├── 概念模式（逻辑级）：也称为模式，描述全体数据的全局逻辑结构，包括记录的类型和记录间的联系、操作、数据的完整性和安全性，对应数据表│   │   └── 内模式（物理级）：描述数据的物理存储结构，对应物理文件、存储结构。例如：如果对一个表创建聚簇索引，那么改变的是数据库的内模式│   ├── 两层映像│   │   ├── 外模式-模式映像│   │   └── 模式-内模式映像：描述数据的逻辑结构与物理存储的映射，当物理存储（如文件组织方式）改变时，只需调整映像，应用程序无需修改│   ├── 数据独立性│   │   ├── 物理独立性：内模式改变，应用程序不变│   │   └── 逻辑独立性：逻辑结构改变，用户程序不变│   │       └── ⚠️ 逻辑独立性比物理独立性更难实现│   └── 关系数据库模式五元组│       └── 表示为 R(U, D, DOM, F)，其中：│           ├── R：关系名│           ├── U：属性名集合│           ├── D：属性所来自的域│           ├── DOM：属性向域的映象集合│           └── F：属性间的数据依赖关系集合│├──  数据完整性 (补充)│   └── 定义：在数据库系统中，数据的完整性是指数据的有效性、正确性和可维护│├──  设计模式补充 (外观模式)│   ├── 适用场景：若系统中的某子模块需要为其他模块提供访问不同数据库系统的功能，这些数据库系统提供的访问接口有一定的差异，但访问过程却都是相同的（例如，先连接数据库，再打开数据库，最后对数据进行查询），此时应该使用外观模式│   └── 定义：外观（Facade）模式是对象的结构模式，要求外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用│├──  UML关系补充│   ├── 依赖（dependency）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义│   ├── 关联（association）：描述一组对象之间连接的结构关系│   ├── 泛化（generalization）：一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象│   └── 实现（realization）：类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约│├──  数据库特征 (补充)│   ├── 1. 数据库中的数据确实按照一定的数据模型进行组织、描述和储存│   ├── 2. 数据间联系密切、冗余度较小│   ├── 3. 数据独立性较高│   └── 4. 数据库可以为各种用户共享│├──  关系数据库操作特点 (补充)│   ├── 1. 操作的对象：关系数据库以关系（表）的形式存储数据，表中的数据本质上是一个数学意义上的集合。数据库的操作（如查询、插入、更新、删除）作用于这些集合上的行（元组）或列（属性）│   ├── 2. 操作的结果：查询操作（如 SELECT）的结果也是一个关系，仍然是一个集合。关系数据库遵循关系代数的运算规则，操作的输入和输出都符合集合的性质（无序、无重复）│   └──  核心：操作的对象和结果都是集合│├── 1️⃣ 分布式数据库 (★★★)│   ├── 体系结构│   │   ├── 全局DBMS（GDBMS）│   │   │   ├── 全局外模式│   │   │   ├── 全局概念模式│   │   │   │   └── 定义分布式数据库中数据的整体逻辑结构，使数据使用方便，如同没有分布一样│   │   │   ├── 分片模式│   │   │   │   └── 描述全局数据逻辑划分的视图，是全局数据的逻辑结构根据条件的划分，每一个逻辑划分成为一个分片│   │   │   └── 分布模式（分配模式）│   │   │       └── 描述局部逻辑的局部物理结构，是划分后的片段的物理分配视图，是全局概念层的内容│   │   └── 局部DBMS（LDBMS）│   │       └── 与原有的集中式数据库相同│   ├── 特性│   │   ├── 逻辑独立性与物理独立性│   │   ├── 数据分布独立性（分布透明性）│   │   ├── 集中与自治结合的控制结构│   │   ├── 适当增加数据冗余度（提高可靠性、可用性、性能）│   │   └── 全局一致性、可串行性、可恢复性│   ├── DDBMS组成│   │   ├── 局部DBMS（LDBMS）│   │   ├── 全局DBMS（GDBMS）│   │   ├── 通信管理（CM）│   │   └── 全局数据字典│   ├── 分布透明性│   │   ├── 分片透明（同义词：片段透明）：用户或应用程序不需要知道逻辑上访问的表具体是如何分块存储的。**（最高层次）**│   │   │   ├── 水平分片│   │   │   ├── 垂直分片│   │   │   └── 混合分片│   │   ├── 位置透明（同义词：场地透明、场地透明性）：用户无须知道数据存放的物理位置。**（次高层次）**│   │   ├── 复制透明（同义词：副本透明）：采用复制技术的分布方法，用户不需要知道数据是复制到哪些节点及如何复制的│   │   └── 逻辑透明（同义词：局部数据模型透明）：用户或应用程序无须知道局部场地使用的是哪种数据模型。**（最低层次）**│   ├── 分配策略│   │   ├── 集中式：将所有的数据分段都安排在同一个场地上│   │   ├── 分割式：将所有数据只有一份，分割成若干逻辑分段，每个逻辑分段指派到一个特定的场地上│   │   ├── 全复制式：在每个场地重复存储数据，每个场地上都有一个完整的数据副本│   │   └── 混合式：介于分割式和全复制之间的分配方式│   └── 两阶段提交协议（2PC）│       ├── 表决阶段（准备阶段）：协调者发布“准备提交”指令，形成共同决定。所有参与者有一票否决权│       ├── 执行阶段（提交阶段）：实现协调者的决定，各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中│       │   ├── Redo Log（重做日志）：记录“事务做了什么操作”，用于重做│       │   └── Undo Log（撤销日志）：记录“事务操作前的旧值”，用于回滚│       └── 全局提交规则│           ├── 任一参与者撤销 → 全局撤销│           └── 全部参与者提交 → 全局提交│├── 2️⃣ 分库分区分表 (★★★)│   ├── 基本概念│   │   ├── 分库：将数据分散到多个数据库实例│   │   ├── 分区：将一张表的数据分散到不同物理区域│   │   │   └── 逻辑上还是一张表│   │   └── 分表：将数据分散到多张表│   │       └── 逻辑上已经不是一张表│   ├── 分区策略│   │   ├── 范围分区（RANGE）：按数据范围划分│   │   ├── 散列分区（HASH）：按哈希值划分│   │   └── 列表分区（LIST）：按具体值划分│   │       └── 示例：长沙一个分区，北京一个分区│   ├── 分库分表方式│   │   ├── 垂直分库：按业务模块拆分│   │   ├── 垂直分表：按字段拆分│   │   ├── 水平分库：按数据行拆分到多个库│   │   └── 水平分表：按数据行拆分到多张表│   ├── 分库分表优点│   │   ├── 解决单库存储瓶颈│   │   ├── 提升并发访问能力│   │   ├── 提高查询效率│   │   └── 降低数据库I/O压力│   └── 分库分表挑战│       ├── 分布式事务问题│       ├── 跨节点查询问题│       ├── 主键全局唯一性问题│       └── 数据扩容与迁移问题│├── 3️⃣ 索引和视图 (★★★)│   ├── 关系表类型│   │   ├── 基本关系（基表）：实际存储数据│   │   ├── 查询表：通常指查询结果对应的临时表，虽然不永久存储数据，但在查询执行期间可能会暂时存储数据│   │   └── 视图表（虚表）：由基表或其他视图表导出，不独立存储│   ├── 视图│   │   ├── 定义：虚拟表，不实际存储数据│   │   ├── 视图优点│   │   │   ├── 简化用户操作│   │   │   ├── 多角度查询同一数据│   │   │   ├── 提供逻辑独立性│   │   │   └── 保护机密数据安全│   │   └── 物化视图：虽然名为视图，但实际上是一种特殊的实体表，会存储查询结果，并在原始数据更新时同步更新│   └── 索引│       ├── 作用：加快数据检索速度│       ├── 代价：占用存储空间、降低DML操作效率│       └── 典型实现│           ├── B+树│           ├── B*树：B树的变种，特别适合于磁盘存储系统，能够保持数据有序，同时支持高效的范围查询操作│           └── 哈希索引│├── 4️⃣ 数据库设计过程 (★★)│   ├── 需求分析（确定系统边界）│   │   ├── 输入：数据处理要求│   │   └── 产出│   │       ├── 数据流图│   │       ├── 数据字典│   │       └── 需求说明书│   ├── 概念设计│   │   ├── 主要任务：按照用户的观点对数据和信息建模，通常使用实体-联系模型（E-R模型）来表示│   │   └── E-R图集成│   │       ├── 集成方法│   │       │   ├── 一次集成│   │       │   └── 逐步集成（累加方式）│   │       └── 冲突及解决办法（针对同一对象）│   │           ├── 属性冲突：域冲突、取值冲突（不同人设计导致属性的类型、取值范围、数据单位等不一致）│   │           ├── 命名冲突：同名异义、异名同义│   │           └── 结构冲突：同一对象在不同应用中具有不同抽象，同一实体在不同局部E-R图中包含的属性个数和属性排列次序不完全相同│   ├── 逻辑设计（含关系规范化和反规范化）│   │   ├── 相关概念│   │   │   ├── 目或度：关系模式中属性的个数│   │   │   ├── 候选码（候选键）：关系中的某一属性或属性组，能唯一标识一个元组，且无冗余（最小性），候选码可能有多个│   │   │   ├── 主码（主键）：候选键任选一个│   │   │   ├── 主属性与非主属性：组成候选码的属性就是主属性，其他的就是非主属性│   │   │   ├── 外码（外键）：其他关系的主键│   │   │   ├── 全码：关系模式的所有属性组是这个关系的候选码│   │   │   └── 属性类型│   │   │       ├── 简单属性│   │   │       ├── 复合属性│   │   │       ├── 派生属性：一个属性可以由另外一个属性计算得到│   │   │       └── 多值属性│   │   ├── E-R图转关系模式│   │   │   ├── 实体 → 关系模式│   │   │   └── 联系 → 关系模式│   │   │       ├── 1:1 → 独立或归并（任一端）│   │   │       ├── 1:N → 独立或归并入多端│   │   │       └── M:N → 需转换为独立的关系表│   │   ├── 关系规范化│   │   ├── 完整性约束│   │   │   ├── 实体完整性：数据模型中约束主键的规则，要求主属性（主键的组成部分）不能为空也不能重复│   │   │   ├── 参照完整性：外键引用主键（通常情况）。详细说明：外键不一定引用另一张表的主键，也可以引用另一张表中具有 UNIQUE 约束的列（即唯一键），并且外键可以为空│   │   │   ├── 用户定义完整性：自定义约束条件，由应用环境决定。例如：软考成绩不能小于0且不能大于75│   │   │   └── 触发器：针对复杂的约束，系统通过用户编程实现。当对表执行插入、更新、删除等操作时自动触发执行│   │   │       └── 示例：设有职务工资关系P（职务，最低工资，最高工资），员工关系EMP（员工号，职务，工资），要求任何一名员工的工资值必须在其职务对应的工资范围之内。实现该需求的方法是建立EMP上的触发器程序，在对工资进行修改或插入新记录时触发，将新工资值与工资范围表中职工职务对应的工资范围对比，只有在范围内才提交，否则回滚│   │   ├── 用户视图确定（提高数据的安全性和独立性）│   │   │   ├── 根据数据流图确定处理过程使用的视图│   │   │   └── 根据用户类别确定不同用户使用的视图│   │   ├── “建立实际的数据库结构”阶段│   │   │   ├── 定义数据库模式与子模式 → 即逻辑结构设计（如表、视图、关系等）│   │   │   ├── 描述数据库完整性约束 → 如主键、外键、检查约束等│   │   │   ├── 描述数据库安全性要求 → 用户权限、访问控制等│   │   │   └── 设置数据库物理存储参数 → 如文件组、表空间、索引存储策略等│   │   └── 数据模型的三要素│   │       ├── 数据模型的作用：提供数据库系统信息表示与操作的抽象框架│   │       ├── 数据结构：对象类型的集合，用于描述系统的静态特性│   │       ├── 数据操作：数据库中各种对象实例允许执行的操作集合│   │       └── 数据的约束条件：一组完整性规则的集合│   ├── 物理设计│   │   ├── 主要工作步骤：确定数据分布、存储结构和访问方式│   │   ├── 根据不同应用分布数据：因为不同应用对数据的访问模式和需求不同，需要据此规划分布│   │   ├── 根据处理要求确定数据的分布：处理需求（如性能、吞吐量要求）会影响如何分布数据│   │   └── 根据数据的逻辑结构确定分布：数据间的逻辑关系和结构会影响分布策略│   └── 数据库实施与试运行│       ├── 主要任务：创建数据库结构、装载数据、试运行与评价│       └── 试运行与评价的主要目的│           ├── 测试应用程序的功能（验证应用程序是否能按设计要求正确访问和操作数据库）│           └── 测试数据库的运行效率（评估响应时间、吞吐量、并发处理能力、索引效果等）│           └──  用户原话：在数据库实施过程中，关于数据库试运行和评价的主要目的测试应用程序的功能和数据库的运行效率│├── 5️⃣ 关系代数 (★★)│   ├── 基本运算│   │   ├── 并（∪）：结果为两者元组之和去除重复行│   │   ├── 交（∩）：结果为二者重复行│   │   ├── 差（−）：前者去除二者重复行│   │   ├── 笛卡尔积（×）：所有列保留，所有行全映射，两表所有组合。新关系的属性个数 = R的属性个数 + S的属性个数，元组个数（行数）为 m × n（其中 m、n 分别为 R、S 的元组数）│   │   ├── 投影（π）：选取指定的列│   │   ├── 选择（σ）：选取满足条件的行│   │   ├── 自然连接（⋈）：列数为二者列数之和去除重复列，行为二者同名属性列其值相同的结果元组│   │   └──  重要等价变换│   │       └── R ∩ S ≡ R - (R - S)   （交运算可以用差运算表示）│   ├── 外连接│   │   ├── 左外连接（⟕）：取出左侧关系中所有与右侧关系中任一元组都不匹配的元组，用空值NULL充填所有来自右侧关系的属性，构成新的元组，将其加入自然连接的结果中│   │   ├── 右外连接（⟖）：取出右侧关系中所有与左侧关系中任一元组都不匹配的元组，用空值NULL充填所有来自左侧关系的属性，构成新的元组，将其加入自然连接的结果中│   │   └── 全外连接（⟗）：完成左外连接和右外连接。即填充左侧关系中与右侧关系中任一元组都不匹配的元组，并填充右侧关系中所有与左侧关系中任一元组都不匹配的元组，将产生的新元组加入自然连接的结果中│   ├── 查询优化原则│   │   ├── 先做选择投影，再做连接│   │   ├── 在连接之前先做筛选，大量减少连接的数据量，再做连接时性能非常高，这是评价SQL性能的标志│   │   └── ⚠️ 笛卡尔积、选择、投影的组合表示可以与自然连接等价│   └── 关系演算示例│       └── R* = { t | (∃ u)(R(t) ∧ S(u) ∧ t[3] < u[2]) } 表示：t 是关系 R 中的一个元组，存在一个元组 u 属于关系 S，并且 t 的第 3 个分量 < u 的第 2 个分量（不是一行一行对应的）│├── 6️⃣ 规范化理论 (★★★)│   ├── 非规范化存在的问题│   │   ├── 数据冗余│   │   ├── 更新异常│   │   ├── 插入异常│   │   └── 删除异常│   ├── 2NF 示例│   │   └── 关系模式 EMP(员工号，姓名，性别，部门，部门电话，部门负责人，家庭住址，家庭成员，成员关系)，主键为 (员工号, 家庭成员)。部门名、部门电话等非主属性对主键存在部分依赖（仅依赖于员工号），不符合 2NF│   ├── 函数依赖│   │   ├── 定义：X→Y 表示X函数决定Y│   │   ├── 函数依赖表示说明：a→b 表示 a 决定 b；ab→c 表示 ab 同时决定 c│   │   ├── 平凡函数依赖：X → Y，其中 Y ⊆ X（即右边是左边的子集）。判断方法：只需看右边是否是左边的子集│   │   ├── 非平凡函数依赖：X → Y，其中 Y ⊈ X（即右边不是左边的子集）│   │   ├── 完全函数依赖：如果 X → Y，并且 Y 不依赖于 X 的任何真子集，则称 Y 对 X 是完全函数依赖│   │   ├── 部分函数依赖│   │   ├── 传递函数依赖│   │   └── Armstrong公理（大范围决定小范围）│   │       ├── 自反律：Y⊆X ⇒ X→Y （记忆：子集决定父集，平凡函数依赖）│   │       ├── 增广律：X→Y ⇒ XZ→YZ （记忆：两边加相同属性，依赖依然成立）│   │       ├── 传递律：X→Y, Y→Z ⇒ X→Z （记忆：链式推导，与数学传递性一致）│   │       ├── 合并规则：X→Y, X→Z ⇒ X→YZ （记忆：相同左部合并右部）│   │       ├── 伪传递规则：X→Y, WY→Z ⇒ XW→Z （记忆：中间替换，左部加前）│   │       └── 分解规则：X→Y, Z⊆Y ⇒ X→Z （记忆：右部取子集）│   ├── 候选键求解│   │   └── 有向图法│   │       ├── 入度为0的属性集为候选键起点│   │       ├── 若入度为0的属性集不能遍历图中所有节点，则尝试加入一些中间节点（既有入度又有出度）│   │       └── ⚠️ 只有入度的肯定不是候选节点│   ├── 范式│   │   ├── 1NF：属性不可再分。存在数据冗余、更新异常、删除异常和插入异常│   │   ├── 2NF：消除非主属性对主键的部分依赖│   │   ├── 3NF：消除非主属性对主键的传递依赖（基于非主属性）│   │   ├── BCNF：每个函数依赖的决定因素都包含候选码│   │   └── ⚠️ 范式升级的过程就是不断拆表的过程│   ├── 模式分解│   │   ├── 保持函数依赖：分解后依赖集等价于原依赖集│   │   └── 无损分解：分解后的模式集合能够通过自然连接还原原模式│   │       ├── 公式法（判定定理）：R1∩R2 → R1-R2 或 R2-R1│   │       └── 表格法│   └── 反规范化│       ├── 目的：减少连接操作，提高检索效率│       ├── 技术手段│       │   ├── 增加派生冗余列│       │   ├── 增加冗余列│       │   ├── 重新组表│       │   └── 分割表（水平分割）│       └── 代价│           ├── 数据冗余│           ├── 操作开销大│           ├── 可能数据不一致│           ├── 需要更大的空间│           └── 更新和插入的代码更难写│├── 7️⃣ 并发控制 (★★)│   ├── 事务ACID特性│   │   ├── 原子性（Atomicity）：操作序列要么都做要么不做。使用影子拷贝（浅拷贝）实现│   │   ├── 一致性（Consistency）：转账前后，系统里的总钱数不变。使用完整性约束检查实现│   │   ├── 隔离性（Isolation）：确保在转账事务未完成前，其他事务看不到中间状态│   │   └── 持久性（Durability）：保证提交后的数据永不丢失│   ├── 事务管理的基本原理│   │   └── 事务通常以 BEGIN TRANSACTION（事务开始）语句开始，以 COMMIT 或 ROLLBACK 语句结束│   ├── 事务故障恢复│   │   ├── UNDO：撤销未提交事务的操作，保证完整性│   │   └── REDO：重做已提交事务的操作，保证持久性│   ├── 并发问题│   │   ├── 丢失更新│   │   ├── 读“脏”数据│   │   ├── 不可重复读│   │   └── ⚠️ 这三个问题主要是事务的并发操作破坏了事务的隔离性│   └── 封锁协议│       ├── 读锁（S锁）：共享锁，其他事务也可以加S锁，但是不能加X锁│       ├── 写锁（X锁）：不能在加任何锁│       └── 各级封锁协议│           ├── 一级封锁协议：防止丢失更新。事务T在修改之前必须先加X锁│           ├── 二级封锁协议：防止读脏数据。在一级封锁协议基础上，另外一个事务读取之前先加S锁，读完释放│           ├── 三级封锁协议：防止不可重复读。在一级封锁协议基础上，另外一个事务读取之前先加S锁，事务完成释放│           └── 两段锁协议：可串行化，可能发生死锁。两段锁协议允许事务在两个不同的阶段分别进行加锁和解锁操作。两段锁协议分为获得封锁（扩展）阶段和释放封锁（收缩）阶段│├── 8️⃣ 数据库故障与恢复 (★★)│   ├── 故障关系：事务本身的可预期故障│   │   ├── 故障原因：本身逻辑│   │   └── 解决办法：预先RollBack│   ├── 故障关系：事务本身的不可预期的故障│   │   ├── 故障原因：算数溢出、违反存储保护│   │   └── 解决办法：通过日志，撤销事务对数据库的修改│   ├── 故障关系：系统故障│   │   ├── 故障原因：系统停止运转│   │   └── 解决办法：检查点法│   └── 故障关系：介质故障│       ├── 故障原因：外存被破坏│       └── 解决办法：日志重做业务│├── 9️⃣ 数据备份与恢复 (★★)│   ├── 冷备份（静态备份）│   │   └── 数据库关闭状态下复制文件│   ├── 热备份（动态备份）│   │   └── 数据库运行时备份│   ├── 备份类型│   │   ├── 完全备份：备份所有数据│   │   ├── 差量备份：备份上次完全备份后变化的数据│   │   └── 增量备份：备份上次任何备份后变化的数据│   ├── 日志文件│   │   ├── 定义：事务日志是针对数据库改变所做的记录│   │   ├── 功能：记录针对数据库的任何操作，并将记录结果保存到独立的文件中│   │   └── ⚠️ 先写日志，再落盘数据│   ├── 数据的转储│   │   ├── 静态转储│   │   │   ├── 定义：转储期间不允许对数据库进行任何存取、修改操作│   │   │   ├── 特点：需要锁定数据库，阻止所有事务 → 对于大型繁忙系统会导致服务中断│   │   │   └── 适用：小型或可停机的系统│   │   ├── 动态转储│   │   │   ├── 定义：转储期间允许对数据库进行存取、修改操作，转储和用户事务可并发执行│   │   │   └── 特点：不需要锁定整个数据库，不影响正常事务处理│   │   ├── 全局转储│   │   │   ├── 定义：转储整个数据库的状态（包括所有数据和事务日志）│   │   │   └── 用途：创建数据库的完整备份│   │   ├── 增量转储│   │   │   ├── 定义：只转储自上次转储以来发生变化的数据│   │   │   ├── 优点：节省存储空间│   │   │   └── 缺点：恢复时需要多次转储的日志，过程较复杂│   │   └── 组合方式（重要场景）│   │       ├── 动态全局转储│   │       │   ├── 含义：在系统运行时，完整复制整个数据库（数据+日志）│   │       │   ├── 优势：不影响在线事务，又能得到完整一致的备份点│   │       │   └──  典型场景：**正在运行的证券公司股票交易系统**│   │       │       └── 需要在不影响正在进行的交易的同时转储全部数据 → 动态全局转储是最合适的选择│   │       └── 动态增量转储特点│   │           ├── 宜在事务不繁忙时进行│   │           ├── 备份过程允许外部事务访问│   │           ├── 装载后，数据库需进一步处理才可达一致性│   │           └──  假设系统中有运行的事务，若要转储全部数据库，应采用动态全局转储方式（已在证券公司场景中验证）│   └── 数据的转储（原有简洁条目已融入上述结构）│├── 1️⃣0️⃣ 数据库高级技术 (★★)│   ├── NoSQL整体框架│   │   ├── 1️⃣ 接口层：为上层应用提供了数据调用接口│   │   ├── 2️⃣ 数据逻辑层：表述了数据的逻辑表现形式│   │   ├── 3️⃣ 数据分布层：定义了数据如何分布│   │   └── 4️⃣ 数据持久层：定义了数据的存储形式，包括基于内存、硬盘、内存和硬盘接口、订制可插拔4种形式│   ├── NoSQL与关系数据库对比│   │   ├── 应用领域：关系数据库面向通用领域，NoSQL面向特定应用领域│   │   ├── 数据容量：关系数据库有限数据，NoSQL海量数据│   │   ├── 数据类型：关系数据库结构化数据（二维表），NoSQL非结构化数据│   │   ├── 并发支持：关系数据库支持并发但性能低，NoSQL高并发│   │   ├── 事务支持：关系数据库高事务性，NoSQL弱事务性│   │   ├── 扩展方式：关系数据库向上扩展，NoSQL向外扩展│   │   └── 一致性模型：NoSQL（如Cassandra）常采用最终一致性，允许短期数据不一致，换取高可用和分区容忍性（符合CAP定理）；关系型数据库通过锁和事务保证强一致性│   ├── NoSQL与关系数据库混用的数据一致性解决方案│   │   ├── 实时同步方式│   │   │   ├── 数据查询：首先从缓存中查找，如果查询不到再从MySQL数据库中查询，并将查询结果保存到缓存│   │   │   └── 数据更新：首先更新数据库，再将缓存中相应数据设置为过期或失效，或者更新缓存中的相应数据│   │   ├── 异步队列方式│   │   │   └── 采用消息中间件│   │   ├── 自定义函数方式│   │   │   ├── 实现方式：在主数据库中进行编程，利用触发器的方式进行数据同步│   │   │   └── ⚠️ 缺点：实现简单，但对主数据库的性能影响大│   │   └── 专门数据同步工具│   │       └── 使用MySQL日志同步工具，如canal等│   ├── NoSQL数据库分类│   │   ├── 键值存储（Key-Value）│   │   │   ├── 适用场景：主要用于内容缓存，如会话、配置文件、参数等│   │   │   ├── 数据模型：Key指向Value的键值对，通常用hash table来实现│   │   │   ├── 优点：查找速度快│   │   │   ├── 缺点：数据无结构化，通常只被当作字符串或者二进制数据│   │   │   └── 举例：Redis, Tokyo Cabinet/Tyrant, Voldemort, Oracle BDB│   │   ├── 列存储数据库│   │   │   ├── 适用场景：主要用于分布式数据存储和管理│   │   │   ├── 数据模型：以列簇式存储，将同一列数据存在一起│   │   │   ├── 优点：查找速度快，可扩展性强，更容易进行分布式扩展│   │   │   ├── 缺点：功能相对局限│   │   │   └── 举例：HBase, Cassandra, Riak│   │   ├── 文档型数据库│   │   │   ├── 适用场景：适用于Web应用，存储面向文档和半结构化数据│   │   │   ├── 数据模型：Key-Value对应的键值对，Value为结构化数据│   │   │   ├── 优点：数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义数据结构│   │   │   ├── 缺点：查询性能不高，而且缺乏统一的查询语法│   │   │   └── 举例：CouchDB, MongoDB│   │   └── 图形数据库（Graph）│   │       ├── 适用场景：如 Neo4j、OrientDB 最适合处理社交网络中的复杂关系数据，也用于推荐系统等需要构建系统图谱的场景，支持复杂的图形算法│   │       ├── 数据模型：图结构│   │       ├── 优点：利用图结构相关算法，比如最短路径寻址，N度关系查找等│   │       ├── 缺点：很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案│   │       └── 举例：Neo4J, InfoGrid, Infinite Graph│   ├── 数据库访问中间件│   │   ├── 定义：通过一个抽象层访问数据库，从而允许使用相同或相似的代码访问不同的数据库资源│   │   └── 典型技术│   │       ├── ODBC（Windows平台）│   │       └── JDBC（Java平台）│   ├── 共享数据库集成│   │   ├── 定义：一种重要的企业应用集成方式，将应用程序的数据存储在一个共享数据库中，通过统一的数据库模式处理不同应用的集成需求│   │   ├── 优点：为不同应用提供统一的数据存储与格式定义，缓解数据语义不一致问题（但无法完全解决）│   │   ├── 缺点与限制│   │   │   ├── 性能瓶颈：多应用频繁读写相同数据，使数据库成为瓶颈│   │   │   └── 对外部封装应用的集成余地小：封装好的应用只能使用自己定义的数据库模式，调整困难│   │   └── 典型场景：企业应用集成（EAI）│   ├── iBatis框架补充│   │   └── iBatis框架以小巧、上手快速著称，适合不需要太多复杂功能的场景│   └── ORM框架与数据库访问方式│       ├── MyBatis：半自动的ORM框架│       ├── Hibernate：全自动的ORM框架│       ├── JPA（Java Persistence API）：Java自带的ORM框架│       ├── 用户不能直接访问后台数据库，需要通过高级程序语言来完成与用户之间的交互│       └── 嵌入式：将SQL语句直接写入某种高级程序语言│├── 1️⃣1️⃣ 数据库管理系统DBMS (★★)│   ├── 1. DBMS具有较高的数据独立性│   ├── 2. 数据结构化且统一管理│   ├── 3. 数据控制功能包含安全性、完整性、并发控制和故障恢复│   │   ├── 并发控制：主要负责协调并发事务的执行，以保证数据库的完整性不受破坏│   │   ├── 安全性：主要用于保护数据库防止不合法使用造成的数据泄露、更改或破坏│   │   ├── 完整性：用于确保数据的正确性和相容性，防止加入不符合语义的数据│   │   └── 故障恢复：主要处理各种故障导致的数据库不一致状态，将数据库恢复到正确状态│   ├── 对数据库的操作语言│   │   ├── 数据定义语言（DDL）：用于定义数据库的结构，如创建表、修改表结构等，不是用于数据操作│   │   ├── 数据操纵语言（DML）：正是用于实现对数据库中数据的基本操作，包括检索、插入、修改和删除│   │   ├── 数据控制语言（DCL）：主要用于控制数据库的访问权限和安全性，不直接操作数据│   │   └── 结构化查询语言（SQL）：是一种综合性语言，包含了DDL、DML和DCL的功能│   ├── DBMS提供数据定义语言(DDL)，用于描述数据库结构，包括外模式、模式和内模式的定义│   └── DBMS的主要功能包括数据定义、数据库操作、数据库运行管理、数据组织存储和管理、数据库建立和维护等│└── 1️⃣2️⃣ 数据库维护 (★★)    └── 数据库维护的主要内容包括        ├── 对数据库性能的监测和改善        ├── 故障恢复        └── 数据库的重组和重构

# 数据库系统 - 核心知识思维导图 │ ├── 0️⃣ 数据库基础概念 (★★★) │ ├── 数据库模式（三级模式） │ │ ├── 外模式（用户级）：对应数据库用户视图，是用户需要使用的部分数据的描述，描述特定用户或应用程序所见的局部数据逻辑结构，如用户看到的部分表或字段。例如：用户A只能查看“员工表”的姓名和部门字段，这种权限控制通过外模式实现 │ │ ├── 概念模式（逻辑级）：也称为模式，描述全体数据的全局逻辑结构，包括记录的类型和记录间的联系、操作、数据的完整性和安全性，对应数据表 │ │ └── 内模式（物理级）：描述数据的物理存储结构，对应物理文件、存储结构。例如：如果对一个表创建聚簇索引，那么改变的是数据库的内模式 │ ├── 两层映像 │ │ ├── 外模式-模式映像 │ │ └── 模式-内模式映像：描述数据的逻辑结构与物理存储的映射，当物理存储（如文件组织方式）改变时，只需调整映像，应用程序无需修改 │ ├── 数据独立性 │ │ ├── 物理独立性：内模式改变，应用程序不变 │ │ └── 逻辑独立性：逻辑结构改变，用户程序不变 │ │ └── ⚠️ 逻辑独立性比物理独立性更难实现 │ └── 关系数据库模式五元组 │ └── 表示为 R(U, D, DOM, F)，其中： │ ├── R：关系名 │ ├── U：属性名集合 │ ├── D：属性所来自的域 │ ├── DOM：属性向域的映象集合 │ └── F：属性间的数据依赖关系集合 │ ├── 数据完整性 (补充) │ └── 定义：在数据库系统中，数据的完整性是指数据的有效性、正确性和可维护 │ ├── 设计模式补充 (外观模式) │ ├── 适用场景：若系统中的某子模块需要为其他模块提供访问不同数据库系统的功能，这些数据库系统提供的访问接口有一定的差异，但访问过程却都是相同的（例如，先连接数据库，再打开数据库，最后对数据进行查询），此时应该使用外观模式 │ └── 定义：外观（Facade）模式是对象的结构模式，要求外部与一个子系统的通信必须通过一个统一的外观对象进行，为子系统中的一组接口提供一个一致的界面，外观模式定义了一个高层接口，这个接口使得这一子系统更加容易使用 │ ├── UML关系补充 │ ├── 依赖（dependency）：两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义 │ ├── 关联（association）：描述一组对象之间连接的结构关系 │ ├── 泛化（generalization）：一般化和特殊化的关系，描述特殊元素的对象可替换一般元素的对象 │ └── 实现（realization）：类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约 │ ├── 数据库特征 (补充) │ ├── 1. 数据库中的数据确实按照一定的数据模型进行组织、描述和储存 │ ├── 2. 数据间联系密切、冗余度较小 │ ├── 3. 数据独立性较高 │ └── 4. 数据库可以为各种用户共享 │ ├── 关系数据库操作特点 (补充) │ ├── 1. 操作的对象：关系数据库以关系（表）的形式存储数据，表中的数据本质上是一个数学意义上的集合。数据库的操作（如查询、插入、更新、删除）作用于这些集合上的行（元组）或列（属性） │ ├── 2. 操作的结果：查询操作（如 SELECT）的结果也是一个关系，仍然是一个集合。关系数据库遵循关系代数的运算规则，操作的输入和输出都符合集合的性质（无序、无重复） │ └── 核心：操作的对象和结果都是集合 │ ├── 1️⃣ 分布式数据库 (★★★) │ ├── 体系结构 │ │ ├── 全局DBMS（GDBMS） │ │ │ ├── 全局外模式 │ │ │ ├── 全局概念模式 │ │ │ │ └── 定义分布式数据库中数据的整体逻辑结构，使数据使用方便，如同没有分布一样 │ │ │ ├── 分片模式 │ │ │ │ └── 描述全局数据逻辑划分的视图，是全局数据的逻辑结构根据条件的划分，每一个逻辑划分成为一个分片 │ │ │ └── 分布模式（分配模式） │ │ │ └── 描述局部逻辑的局部物理结构，是划分后的片段的物理分配视图，是全局概念层的内容 │ │ └── 局部DBMS（LDBMS） │ │ └── 与原有的集中式数据库相同 │ ├── 特性 │ │ ├── 逻辑独立性与物理独立性 │ │ ├── 数据分布独立性（分布透明性） │ │ ├── 集中与自治结合的控制结构 │ │ ├── 适当增加数据冗余度（提高可靠性、可用性、性能） │ │ └── 全局一致性、可串行性、可恢复性 │ ├── DDBMS组成 │ │ ├── 局部DBMS（LDBMS） │ │ ├── 全局DBMS（GDBMS） │ │ ├── 通信管理（CM） │ │ └── 全局数据字典 │ ├── 分布透明性 │ │ ├── 分片透明（同义词：片段透明）：用户或应用程序不需要知道逻辑上访问的表具体是如何分块存储的。**（最高层次）** │ │ │ ├── 水平分片 │ │ │ ├── 垂直分片 │ │ │ └── 混合分片 │ │ ├── 位置透明（同义词：场地透明、场地透明性）：用户无须知道数据存放的物理位置。**（次高层次）** │ │ ├── 复制透明（同义词：副本透明）：采用复制技术的分布方法，用户不需要知道数据是复制到哪些节点及如何复制的 │ │ └── 逻辑透明（同义词：局部数据模型透明）：用户或应用程序无须知道局部场地使用的是哪种数据模型。**（最低层次）** │ ├── 分配策略 │ │ ├── 集中式：将所有的数据分段都安排在同一个场地上 │ │ ├── 分割式：将所有数据只有一份，分割成若干逻辑分段，每个逻辑分段指派到一个特定的场地上 │ │ ├── 全复制式：在每个场地重复存储数据，每个场地上都有一个完整的数据副本 │ │ └── 混合式：介于分割式和全复制之间的分配方式 │ └── 两阶段提交协议（2PC） │ ├── 表决阶段（准备阶段）：协调者发布“准备提交”指令，形成共同决定。所有参与者有一票否决权 │ ├── 执行阶段（提交阶段）：实现协调者的决定，各参与者节点执行事务操作，并将 Undo 和 Redo 信息记入事务日志中 │ │ ├── Redo Log（重做日志）：记录“事务做了什么操作”，用于重做 │ │ └── Undo Log（撤销日志）：记录“事务操作前的旧值”，用于回滚 │ └── 全局提交规则 │ ├── 任一参与者撤销 → 全局撤销 │ └── 全部参与者提交 → 全局提交 │ ├── 2️⃣ 分库分区分表 (★★★) │ ├── 基本概念 │ │ ├── 分库：将数据分散到多个数据库实例 │ │ ├── 分区：将一张表的数据分散到不同物理区域 │ │ │ └── 逻辑上还是一张表 │ │ └── 分表：将数据分散到多张表 │ │ └── 逻辑上已经不是一张表 │ ├── 分区策略 │ │ ├── 范围分区（RANGE）：按数据范围划分 │ │ ├── 散列分区（HASH）：按哈希值划分 │ │ └── 列表分区（LIST）：按具体值划分 │ │ └── 示例：长沙一个分区，北京一个分区 │ ├── 分库分表方式 │ │ ├── 垂直分库：按业务模块拆分 │ │ ├── 垂直分表：按字段拆分 │ │ ├── 水平分库：按数据行拆分到多个库 │ │ └── 水平分表：按数据行拆分到多张表 │ ├── 分库分表优点 │ │ ├── 解决单库存储瓶颈 │ │ ├── 提升并发访问能力 │ │ ├── 提高查询效率 │ │ └── 降低数据库I/O压力 │ └── 分库分表挑战 │ ├── 分布式事务问题 │ ├── 跨节点查询问题 │ ├── 主键全局唯一性问题 │ └── 数据扩容与迁移问题 │ ├── 3️⃣ 索引和视图 (★★★) │ ├── 关系表类型 │ │ ├── 基本关系（基表）：实际存储数据 │ │ ├── 查询表：通常指查询结果对应的临时表，虽然不永久存储数据，但在查询执行期间可能会暂时存储数据 │ │ └── 视图表（虚表）：由基表或其他视图表导出，不独立存储 │ ├── 视图 │ │ ├── 定义：虚拟表，不实际存储数据 │ │ ├── 视图优点 │ │ │ ├── 简化用户操作 │ │ │ ├── 多角度查询同一数据 │ │ │ ├── 提供逻辑独立性 │ │ │ └── 保护机密数据安全 │ │ └── 物化视图：虽然名为视图，但实际上是一种特殊的实体表，会存储查询结果，并在原始数据更新时同步更新 │ └── 索引 │ ├── 作用：加快数据检索速度 │ ├── 代价：占用存储空间、降低DML操作效率 │ └── 典型实现 │ ├── B+树 │ ├── B*树：B树的变种，特别适合于磁盘存储系统，能够保持数据有序，同时支持高效的范围查询操作 │ └── 哈希索引 │ ├── 4️⃣ 数据库设计过程 (★★) │ ├── 需求分析（确定系统边界） │ │ ├── 输入：数据处理要求 │ │ └── 产出 │ │ ├── 数据流图 │ │ ├── 数据字典 │ │ └── 需求说明书 │ ├── 概念设计 │ │ ├── 主要任务：按照用户的观点对数据和信息建模，通常使用实体-联系模型（E-R模型）来表示 │ │ └── E-R图集成 │ │ ├── 集成方法 │ │ │ ├── 一次集成 │ │ │ └── 逐步集成（累加方式） │ │ └── 冲突及解决办法（针对同一对象） │ │ ├── 属性冲突：域冲突、取值冲突（不同人设计导致属性的类型、取值范围、数据单位等不一致） │ │ ├── 命名冲突：同名异义、异名同义 │ │ └── 结构冲突：同一对象在不同应用中具有不同抽象，同一实体在不同局部E-R图中包含的属性个数和属性排列次序不完全相同 │ ├── 逻辑设计（含关系规范化和反规范化） │ │ ├── 相关概念 │ │ │ ├── 目或度：关系模式中属性的个数 │ │ │ ├── 候选码（候选键）：关系中的某一属性或属性组，能唯一标识一个元组，且无冗余（最小性），候选码可能有多个 │ │ │ ├── 主码（主键）：候选键任选一个 │ │ │ ├── 主属性与非主属性：组成候选码的属性就是主属性，其他的就是非主属性 │ │ │ ├── 外码（外键）：其他关系的主键 │ │ │ ├── 全码：关系模式的所有属性组是这个关系的候选码 │ │ │ └── 属性类型 │ │ │ ├── 简单属性 │ │ │ ├── 复合属性 │ │ │ ├── 派生属性：一个属性可以由另外一个属性计算得到 │ │ │ └── 多值属性 │ │ ├── E-R图转关系模式 │ │ │ ├── 实体 → 关系模式 │ │ │ └── 联系 → 关系模式 │ │ │ ├── 1:1 → 独立或归并（任一端） │ │ │ ├── 1:N → 独立或归并入多端 │ │ │ └── M:N → 需转换为独立的关系表 │ │ ├── 关系规范化 │ │ ├── 完整性约束 │ │ │ ├── 实体完整性：数据模型中约束主键的规则，要求主属性（主键的组成部分）不能为空也不能重复 │ │ │ ├── 参照完整性：外键引用主键（通常情况）。详细说明：外键不一定引用另一张表的主键，也可以引用另一张表中具有 UNIQUE 约束的列（即唯一键），并且外键可以为空 │ │ │ ├── 用户定义完整性：自定义约束条件，由应用环境决定。例如：软考成绩不能小于0且不能大于75 │ │ │ └── 触发器：针对复杂的约束，系统通过用户编程实现。当对表执行插入、更新、删除等操作时自动触发执行 │ │ │ └── 示例：设有职务工资关系P（职务，最低工资，最高工资），员工关系EMP（员工号，职务，工资），要求任何一名员工的工资值必须在其职务对应的工资范围之内。实现该需求的方法是建立EMP上的触发器程序，在对工资进行修改或插入新记录时触发，将新工资值与工资范围表中职工职务对应的工资范围对比，只有在范围内才提交，否则回滚 │ │ ├── 用户视图确定（提高数据的安全性和独立性） │ │ │ ├── 根据数据流图确定处理过程使用的视图 │ │ │ └── 根据用户类别确定不同用户使用的视图 │ │ ├── “建立实际的数据库结构”阶段 │ │ │ ├── 定义数据库模式与子模式 → 即逻辑结构设计（如表、视图、关系等） │ │ │ ├── 描述数据库完整性约束 → 如主键、外键、检查约束等 │ │ │ ├── 描述数据库安全性要求 → 用户权限、访问控制等 │ │ │ └── 设置数据库物理存储参数 → 如文件组、表空间、索引存储策略等 │ │ └── 数据模型的三要素 │ │ ├── 数据模型的作用：提供数据库系统信息表示与操作的抽象框架 │ │ ├── 数据结构：对象类型的集合，用于描述系统的静态特性 │ │ ├── 数据操作：数据库中各种对象实例允许执行的操作集合 │ │ └── 数据的约束条件：一组完整性规则的集合 │ └── 物理设计 │ ├── 主要工作步骤：确定数据分布、存储结构和访问方式 │ ├── 根据不同应用分布数据：因为不同应用对数据的访问模式和需求不同，需要据此规划分布 │ ├── 根据处理要求确定数据的分布：处理需求（如性能、吞吐量要求）会影响如何分布数据 │ └── 根据数据的逻辑结构确定分布：数据间的逻辑关系和结构会影响分布策略 │ ├── 5️⃣ 关系代数 (★★) │ ├── 基本运算 │ │ ├── 并（∪）：结果为两者元组之和去除重复行 │ │ ├── 交（∩）：结果为二者重复行 │ │ ├── 差（−）：前者去除二者重复行 │ │ ├── 笛卡尔积（×）：所有列保留，所有行全映射，两表所有组合。新关系的属性个数 = R的属性个数 + S的属性个数，元组个数（行数）为 m × n（其中 m、n 分别为 R、S 的元组数） │ │ ├── 投影（π）：选取指定的列 │ │ ├── 选择（σ）：选取满足条件的行 │ │ └── 自然连接（⋈）：列数为二者列数之和去除重复列，行为二者同名属性列其值相同的结果元组 │ ├── 外连接 │ │ ├── 左外连接（⟕）：取出左侧关系中所有与右侧关系中任一元组都不匹配的元组，用空值NULL充填所有来自右侧关系的属性，构成新的元组，将其加入自然连接的结果中 │ │ ├── 右外连接（⟖）：取出右侧关系中所有与左侧关系中任一元组都不匹配的元组，用空值NULL充填所有来自左侧关系的属性，构成新的元组，将其加入自然连接的结果中 │ │ └── 全外连接（⟗）：完成左外连接和右外连接。即填充左侧关系中与右侧关系中任一元组都不匹配的元组，并填充右侧关系中所有与左侧关系中任一元组都不匹配的元组，将产生的新元组加入自然连接的结果中 │ ├── 查询优化原则 │ │ ├── 先做选择投影，再做连接 │ │ ├── 在连接之前先做筛选，大量减少连接的数据量，再做连接时性能非常高，这是评价SQL性能的标志 │ │ └── ⚠️ 笛卡尔积、选择、投影的组合表示可以与自然连接等价 │ └── 关系演算示例 │ └── R* = { t | (∃ u)(R(t) ∧ S(u) ∧ t[3] < u[2]) } 表示：t 是关系 R 中的一个元组，存在一个元组 u 属于关系 S，并且 t 的第 3 个分量 < u 的第 2 个分量（不是一行一行对应的） │ ├── 6️⃣ 规范化理论 (★★★) │ ├── 非规范化存在的问题 │ │ ├── 数据冗余 │ │ ├── 更新异常 │ │ ├── 插入异常 │ │ └── 删除异常 │ ├── 2NF 示例 │ │ └── 关系模式 EMP(员工号，姓名，性别，部门，部门电话，部门负责人，家庭住址，家庭成员，成员关系)，主键为 (员工号, 家庭成员)。部门名、部门电话等非主属性对主键存在部分依赖（仅依赖于员工号），不符合 2NF │ ├── 函数依赖 │ │ ├── 定义：X→Y 表示X函数决定Y │ │ ├── 函数依赖表示说明：a→b 表示 a 决定 b；ab→c 表示 ab 同时决定 c │ │ ├── 平凡函数依赖：X → Y，其中 Y ⊆ X（即右边是左边的子集）。判断方法：只需看右边是否是左边的子集 │ │ ├── 非平凡函数依赖：X → Y，其中 Y ⊈ X（即右边不是左边的子集） │ │ ├── 完全函数依赖：如果 X → Y，并且 Y 不依赖于 X 的任何真子集，则称 Y 对 X 是完全函数依赖 │ │ ├── 部分函数依赖 │ │ ├── 传递函数依赖 │ │ └── Armstrong公理（大范围决定小范围） │ │ ├── 自反律：Y⊆X ⇒ X→Y （记忆：子集决定父集，平凡函数依赖） │ │ ├── 增广律：X→Y ⇒ XZ→YZ （记忆：两边加相同属性，依赖依然成立） │ │ ├── 传递律：X→Y, Y→Z ⇒ X→Z （记忆：链式推导，与数学传递性一致） │ │ ├── 合并规则：X→Y, X→Z ⇒ X→YZ （记忆：相同左部合并右部） │ │ ├── 伪传递规则：X→Y, WY→Z ⇒ XW→Z （记忆：中间替换，左部加前） │ │ └── 分解规则：X→Y, Z⊆Y ⇒ X→Z （记忆：右部取子集） │ ├── 候选键求解 │ │ └── 有向图法 │ │ ├── 入度为0的属性集为候选键起点 │ │ ├── 若入度为0的属性集不能遍历图中所有节点，则尝试加入一些中间节点（既有入度又有出度） │ │ └── ⚠️ 只有入度的肯定不是候选节点 │ ├── 范式 │ │ ├── 1NF：属性不可再分。存在数据冗余、更新异常、删除异常和插入异常 │ │ ├── 2NF：消除非主属性对主键的部分依赖 │ │ ├── 3NF：消除非主属性对主键的传递依赖（基于非主属性） │ │ ├── BCNF：每个函数依赖的决定因素都包含候选码 │ │ └── ⚠️ 范式升级的过程就是不断拆表的过程 │ ├── 模式分解 │ │ ├── 保持函数依赖：分解后依赖集等价于原依赖集 │ │ └── 无损分解：分解后的模式集合能够通过自然连接还原原模式 │ │ ├── 公式法（判定定理）：R1∩R2 → R1-R2 或 R2-R1 │ │ └── 表格法 │ └── 反规范化 │ ├── 目的：减少连接操作，提高检索效率 │ ├── 技术手段 │ │ ├── 增加派生冗余列 │ │ ├── 增加冗余列 │ │ ├── 重新组表 │ │ └── 分割表（水平分割） │ └── 代价 │ ├── 数据冗余 │ ├── 操作开销大 │ ├── 可能数据不一致 │ ├── 需要更大的空间 │ └── 更新和插入的代码更难写 │ ├── 7️⃣ 并发控制 (★★) │ ├── 事务ACID特性 │ │ ├── 原子性（Atomicity）：操作序列要么都做要么不做。使用影子拷贝（浅拷贝）实现 │ │ ├── 一致性（Consistency）：转账前后，系统里的总钱数不变。使用完整性约束检查实现 │ │ ├── 隔离性（Isolation）：确保在转账事务未完成前，其他事务看不到中间状态 │ │ └── 持久性（Durability）：保证提交后的数据永不丢失 │ ├── 事务管理的基本原理 │ │ └── 事务通常以 BEGIN TRANSACTION（事务开始）语句开始，以 COMMIT 或 ROLLBACK 语句结束 │ ├── 事务故障恢复 │ │ ├── UNDO：撤销未提交事务的操作，保证完整性 │ │ └── REDO：重做已提交事务的操作，保证持久性 │ ├── 并发问题 │ │ ├── 丢失更新 │ │ ├── 读“脏”数据 │ │ ├── 不可重复读 │ │ └── ⚠️ 这三个问题主要是事务的并发操作破坏了事务的隔离性 │ └── 封锁协议 │ ├── 读锁（S锁）：共享锁，其他事务也可以加S锁，但是不能加X锁 │ ├── 写锁（X锁）：不能在加任何锁 │ └── 各级封锁协议 │ ├── 一级封锁协议：防止丢失更新。事务T在修改之前必须先加X锁 │ ├── 二级封锁协议：防止读脏数据。在一级封锁协议基础上，另外一个事务读取之前先加S锁，读完释放 │ ├── 三级封锁协议：防止不可重复读。在一级封锁协议基础上，另外一个事务读取之前先加S锁，事务完成释放 │ └── 两段锁协议：可串行化，可能发生死锁。两段锁协议允许事务在两个不同的阶段分别进行加锁和解锁操作。两段锁协议分为获得封锁（扩展）阶段和释放封锁（收缩）阶段 │ ├── 8️⃣ 数据库故障与恢复 (★★) │ ├── 故障关系：事务本身的可预期故障 │ │ ├── 故障原因：本身逻辑 │ │ └── 解决办法：预先RollBack │ ├── 故障关系：事务本身的不可预期的故障 │ │ ├── 故障原因：算数溢出、违反存储保护 │ │ └── 解决办法：通过日志，撤销事务对数据库的修改 │ ├── 故障关系：系统故障 │ │ ├── 故障原因：系统停止运转 │ │ └── 解决办法：检查点法 │ └── 故障关系：介质故障 │ ├── 故障原因：外存被破坏 │ └── 解决办法：日志重做业务 │ ├── 9️⃣ 数据备份与恢复 (★★) │ ├── 冷备份（静态备份） │ │ └── 数据库关闭状态下复制文件 │ ├── 热备份（动态备份） │ │ └── 数据库运行时备份 │ ├── 备份类型 │ │ ├── 完全备份：备份所有数据 │ │ ├── 差量备份：备份上次完全备份后变化的数据 │ │ └── 增量备份：备份上次任何备份后变化的数据 │ ├── 日志文件 │ │ ├── 定义：事务日志是针对数据库改变所做的记录 │ │ ├── 功能：记录针对数据库的任何操作，并将记录结果保存到独立的文件中 │ │ └── ⚠️ 先写日志，再落盘数据 │ └── 数据的转储 │ ├── 静态转储：转储期间不允许对数据库进行任何存取、修改操作 │ ├── 动态转储：转储期间允许对数据库进行存取、修改操作，转储和用户事务可并发执行 │ ├── 海量转储：每次转储全部数据 │ ├── 增量转储：每次只转储上次转储后更新过的数据 │ ├── 动态增量备份特点 │ │ ├── 宜在事务不繁忙时进行 │ │ ├── 备份过程允许外部事务程序访问数据库 │ │ └── 装载后，数据库并不立即处于一致性状态，需进一步处理才可达一致性 │ └── 假设系统中有运行的事务，若要转储全部数据库，应采用动态全局转储方式 │ ├── 1️⃣0️⃣ 数据库高级技术 (★★) │ ├── NoSQL整体框架 │ │ ├── 1️⃣ 接口层：为上层应用提供了数据调用接口 │ │ ├── 2️⃣ 数据逻辑层：表述了数据的逻辑表现形式 │ │ ├── 3️⃣ 数据分布层：定义了数据如何分布 │ │ └── 4️⃣ 数据持久层：定义了数据的存储形式，包括基于内存、硬盘、内存和硬盘接口、订制可插拔4种形式 │ ├── NoSQL与关系数据库对比 │ │ ├── 应用领域：关系数据库面向通用领域，NoSQL面向特定应用领域 │ │ ├── 数据容量：关系数据库有限数据，NoSQL海量数据 │ │ ├── 数据类型：关系数据库结构化数据（二维表），NoSQL非结构化数据 │ │ ├── 并发支持：关系数据库支持并发但性能低，NoSQL高并发 │ │ ├── 事务支持：关系数据库高事务性，NoSQL弱事务性 │ │ ├── 扩展方式：关系数据库向上扩展，NoSQL向外扩展 │ │ └── 一致性模型：NoSQL（如Cassandra）常采用最终一致性，允许短期数据不一致，换取高可用和分区容忍性（符合CAP定理）；关系型数据库通过锁和事务保证强一致性 │ ├── NoSQL与关系数据库混用的数据一致性解决方案 │ │ ├── 实时同步方式 │ │ │ ├── 数据查询：首先从缓存中查找，如果查询不到再从MySQL数据库中查询，并将查询结果保存到缓存 │ │ │ └── 数据更新：首先更新数据库，再将缓存中相应数据设置为过期或失效，或者更新缓存中的相应数据 │ │ ├── 异步队列方式 │ │ │ └── 采用消息中间件 │ │ ├── 自定义函数方式 │ │ │ ├── 实现方式：在主数据库中进行编程，利用触发器的方式进行数据同步 │ │ │ └── ⚠️ 缺点：实现简单，但对主数据库的性能影响大 │ │ └── 专门数据同步工具 │ │ └── 使用MySQL日志同步工具，如canal等 │ ├── NoSQL数据库分类 │ │ ├── 键值存储（Key-Value） │ │ │ ├── 适用场景：主要用于内容缓存，如会话、配置文件、参数等 │ │ │ ├── 数据模型：Key指向Value的键值对，通常用hash table来实现 │ │ │ ├── 优点：查找速度快 │ │ │ ├── 缺点：数据无结构化，通常只被当作字符串或者二进制数据 │ │ │ └── 举例：Redis, Tokyo Cabinet/Tyrant, Voldemort, Oracle BDB │ │ ├── 列存储数据库 │ │ │ ├── 适用场景：主要用于分布式数据存储和管理 │ │ │ ├── 数据模型：以列簇式存储，将同一列数据存在一起 │ │ │ ├── 优点：查找速度快，可扩展性强，更容易进行分布式扩展 │ │ │ ├── 缺点：功能相对局限 │ │ │ └── 举例：HBase, Cassandra, Riak │ │ ├── 文档型数据库 │ │ │ ├── 适用场景：适用于Web应用，存储面向文档和半结构化数据 │ │ │ ├── 数据模型：Key-Value对应的键值对，Value为结构化数据 │ │ │ ├── 优点：数据结构要求不严格，表结构可变，不需要像关系型数据库一样需要预先定义数据结构 │ │ │ ├── 缺点：查询性能不高，而且缺乏统一的查询语法 │ │ │ └── 举例：CouchDB, MongoDB │ │ └── 图形数据库（Graph） │ │ ├── 适用场景：如 Neo4j、OrientDB 最适合处理社交网络中的复杂关系数据，也用于推荐系统等需要构建系统图谱的场景，支持复杂的图形算法 │ │ ├── 数据模型：图结构 │ │ ├── 优点：利用图结构相关算法，比如最短路径寻址，N度关系查找等 │ │ ├── 缺点：很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案 │ │ └── 举例：Neo4J, InfoGrid, Infinite Graph │ ├── iBatis框架补充 │ │ └── iBatis框架以小巧、上手快速著称，适合不需要太多复杂功能的场景 │ └── ORM框架与数据库访问方式 │ ├── MyBatis：半自动的ORM框架 │ ├── Hibernate：全自动的ORM框架 │ ├── JPA（Java Persistence API）：Java自带的ORM框架 │ ├── 用户不能直接访问后台数据库，需要通过高级程序语言来完成与用户之间的交互 │ └── 嵌入式：将SQL语句直接写入某种高级程序语言 │ ├── 1️⃣1️⃣ 数据库管理系统DBMS (★★) │ ├── 1. DBMS具有较高的数据独立性 │ ├── 2. 数据结构化且统一管理 │ ├── 3. 数据控制功能包含安全性、完整性、并发控制和故障恢复 │ │ ├── 并发控制：主要负责协调并发事务的执行，以保证数据库的完整性不受破坏 │ │ ├── 安全性：主要用于保护数据库防止不合法使用造成的数据泄露、更改或破坏 │ │ ├── 完整性：用于确保数据的正确性和相容性，防止加入不符合语义的数据 │ │ └── 故障恢复：主要处理各种故障导致的数据库不一致状态，将数据库恢复到正确状态 │ ├── 对数据库的操作语言 │ │ ├── 数据定义语言（DDL）：用于定义数据库的结构，如创建表、修改表结构等，不是用于数据操作 │ │ ├── 数据操纵语言（DML）：正是用于实现对数据库中数据的基本操作，包括检索、插入、修改和删除 │ │ ├── 数据控制语言（DCL）：主要用于控制数据库的访问权限和安全性，不直接操作数据 │ │ └── 结构化查询语言（SQL）：是一种综合性语言，包含了DDL、DML和DCL的功能 │ ├── DBMS提供数据定义语言(DDL)，用于描述数据库结构，包括外模式、模式和内模式的定义 │ └── DBMS的主要功能包括数据定义、数据库操作、数据库运行管理、数据组织存储和管理、数据库建立和维护等 │ └── 1️⃣2️⃣ 数据库维护 (★★) └── 数据库维护的主要内容包括 ├── 对数据库性能的监测和改善 ├── 故障恢复 └── 数据库的重组和重构