Appearance
数据库系统
更新: 4/10/2025 字数: 0 字 时长: 0 分钟
数据库概述（⭐）
- 基本关系表【基表、基本表】：实际存在的表，实际存储数据的逻辑表示。
- 查询表：查询结果对应的表。
- 视图表：由基表或其它视图表导出的表，本身不存储数据，只存放它的定义（SQL语句），查询此表时通过执行SQL语句动态获取表数据，常称为虚表。
- 物化视图：将视图表的数据进行实际的物理存储，同时原始表中的数据更新时，物化视图也会更新。
数据库模式
- 逻辑独立性：数据的逻辑结构发生变化后，用户程序也可以不修改。但是为了保证应用程序能够正确执行，需要修改外模式和概念模式之间的映射。
- 物理独立性：当数据的物理结构发生改变时，应用程序不用修改。但是为了保证应用程序能够正确执行，需要修改概念模式和内模式之间的映射。
提示
外模式——视图级；概念模式——表级；内模式——文件级
分布式数据库
分布式数据库特点
- 数据独立性：除逻辑独立性、物理独立性外，还有数据的分布独立性【分布透明性】。
- 集中与自治共享结合的控制结构：各局部的DBMS可以独立地福安里局部数据库，具有自治功能。同时系统有设有集中控制机制，协调各局部DBMS的工作，执行全局应用。
- 适当增加数据冗余度：在不同的场地存储同一数据的多个副本，可以提高系统的可靠性和可用性，也可提高系统性能。
- 全局的一致性、可串行性和可恢复性。
分布式数据库模式
- 全局外模式：是对分布式数据库的最高层的抽象。
- 全局概念模式：是分布式数据库的整体抽象，包含了系统中全部数据的特性和逻辑结构，描述分布式数据库全局数据的逻辑结构，使得数据使用方便，如同没有分布一样。
- 分片模式：描述全局数据逻辑划分的视图，是全局数据的逻辑结构根据条件的划分；每个逻辑划分就是一个分片。
- 分布模式：描述局部逻辑的局部物理结构，是划分后的分片的物理分配视图。
分片透明性
- 分片透明：指用户不必管理数据是如何分片的，它们对数据的操作在全局关系上进行，即如何分片对用户是透明的。
- 复制透明：用户不用关系数据库在网络上各个节点的复制情况，被复制的数据的更新都由系统自动完成。
- 位置透明：指用户不必知道所操作的数据放在何处，即数据分配到哪个或哪些站点存储对用户是透明的。
- 局部映射透明性【逻辑透明】：是最低层次的透明性，该透明性提高数据到局部数据库的映射，即用户不必关系局部DBMS支持哪种数据模型、使用哪种数据操纵语言，数据模型和操纵语言的转换是由系统完成的。因此，局部映射透明性对异构型和同构异质的分布式数据库系统非常重要。
两阶段提交协议
2PC事务提交的两个阶段：
- 表决阶段：目的是形成一个共同的决定。
- 执行阶段：目的是实现这个协调者的决定。
两条全局提交规则：
- 只要有一个参与者撤销事务，协调者就必须做出全局撤销决定。
- 只要所有参与者都同意提交事务，协调者才能做出全局提交决定。
DDBMS
分布式数据库管理系统（Distributed Database Management System, DDBMS）
数据库设计（⭐⭐）
概念结构设计
在需求分析阶段产生的需求说明书的基础上，按照特定的方法将它们抽象为一个不依赖于任何DBMS的数据模型，即概念模型。概念模型的表现形式就是ER模型。 
集成的方法：
- 多个局部ER图一次集成。
- 逐步集成，用累加的方式一次集成两个局部ER图。
集成产生的冲突：
- 属性冲突：包括属性域冲突和属性取值冲突。
- 命名冲突：包括同名异义和异名同义。
- 结构冲突：包括同一对象在不同应用中具有不同的抽象，以及同一实体在不同局部E-R图中所包含的属性个数和属性排列次序不完全相同。
逻辑结构设计
关系模式
- 目或度：关系模式中属性的个数。
- 候选码【候选键】
- 主码【主键】
- 主属性和非主属性：组成候选码的属性就是主属性，其它就是非主属性。
- 外码【外键】
- 全码：关系模式的所有属性组是这个关系的候选码。
完整性约束
- 实体完整性约束：规定基本关系的主属性不能取空值。
- 参照完整性约束：关系与关系间的引用，其它关系的主键或空值。
- 用户自定义完整性约束：应用环境决定。
- 触发器
逻辑设计
主要任务是将概念设计阶段的ER图转换为选用具体机器上的DBMS所支持的数据模型相符合的逻辑结构。 
- ER图向关系模式的转换：
- 实体向关系模式的转换
- 联系向关系模式的转换
- 关系模式的规范化
- 确定完整性约束：保证数据的正确性
- 用户视图的确定：提高数据的安全性和独立性
- 根据数据流图确定处理过程使用的视图
- 根据用户类别确定不同用户使用的视图
- 应用程序设计
一个实体必须转化转换为一个关系模式。
联系转关系模式：
- 一对一联系的转换有2种方式：
- 独立的关系模式：并入两端主键及联系自身属性。（主键：任一端主键）
- 归并（任意一端）：并入另一端主键及联系自身属性。（主键：保持不变）
- 一对多联系的转换有2种方式：
- 独立的关系模式：并入两端主键及联系自身属性。（主键：多端主键）
- 归并（多端）：并入另一端主键及联系自身属性。（主键：保持不变）
- 多对多联系的转换只有1种方式：
- 独立的关系模式：并入两端主键及联系自身属性。（主键：两端主键的组合键）
物理结构设计
对一个给定的逻辑数据模型选取一个最适合应用环境的物理结构的过程，数据库的物理结构主要指数据库在物理设备上的存储结构和存取方法。
关系代数（⭐⭐⭐⭐）
- 并、差、交：集合中并集、差集和交集的概念，根据主键进行判断。
- 笛卡尔积：编号从1开始（下同）。
- 投影：选指定的数据库列。
- 选择：选指定的数据库行。
- 连接
规范化理论（⭐⭐⭐⭐）
函数依赖
部分函数依赖
当1个关系模式中主键由2个及以上的属性组成时，非主属性只依赖于其中1个主属性，就是部分函数依赖。
如：AB => D, A => C
传递函数依赖
当关系模式中，出现非主属性决定非主属性时，就是传递函数依赖。如：A => B => C
如何求候选键？
- 将关系模式的函数依赖用
有向图的方式表示 - 找入度为0的属性节点，并以该属性集合为起点，尝试遍历有向图，若能正常遍历图中所有节点，则该属性集为关系模式的候选键。
- 若入度为0的属性集不能遍历所有节点，则需要尝试将一些中间节点（既有入度也有出度的节点）并入入度为0的属性集中，直至该集合能遍历所有节点。
Armstrong公理
对关系模式 R<U, F>，U为属性集
自反律：若
，则 成立 这里的
表示Y是X的一部分，X是一个属性组，即一个属性组可以推出自身组内的任意属性。例如（软件学院，软件工程）可推出 软件工程 这个属性。 增广律：若
且 ，则 传递律：若
且 ，则
根据以上规则可推出：
- 合并规则：由
和 ，有 （规则2和3） - 伪传递规则：由
和 ，有 （规则2和3） - 分解规则：由
和 有 （规则1和3）
范式
1NF：属性都是不可分的原子值
消除非主属性对候选键的部分函数依赖，得到第二范式
2NF：满足第一范式，且每一个非主属性完全依赖候选键（没有部分函数依赖）
消除非主属性对候选键的传递函数依赖，得到第三范式
3NF：满足第二范式，且没有非主属性传递函数依赖候选键
消除主属性对候选键的部分函数依赖和传递函数依赖，得到BCNF范式
BCNF：设R表示关系模式，F是其依赖集，当且仅当F中的每个依赖的决定因素必定包含R的某个候选键。
模式分解
保持函数依赖分解
分解之后的函数依赖的集合与原函数依赖集合保持等价。需注意，分解后的函数依赖集合中，根据公式推理出来的函数依赖也包括在集合中。
案例1：F={A->B, B->C, A->C}，将其拆分为：R1{A, B}、R2{B, C}
点我查看答案
R1{A, B}，F1{A->B}；R2{B, C}，F2{B->C}；F1和F2的并集为{A→B, B→C}，由于可以推导出A→C；因此F1和F2的最终并集为{A→B，B→C，A→C}，与F是等价的，所以属于保持函数依赖分解。
案例2：F = {A->B, B->C}，将其分解为：R1{A, B}、R2{A, C}
点我查看答案
F1{A->B}，F2{}（空集）；F1和F2的并集为{A->B}，与F不等价，所以没有保持函数依赖分解。
无损联接分解
指将一个关系模式分解成若干个关系模式后，通过自然连接和投影等运算仍能还原到原来的关系模式。
定理：如果R的分解为
案例：设R=ABC，F={A->B}，则分解{
点我查看答案
如果函数依赖集合超过2个，可使用表格法来判断是否无损联接分解。
案例：
有关系模式：成绩（学号、姓名、课程号、课程名、分数）
函数依赖：学号->姓名，课程号->课程名，（学号、课程号）-> 分数
请问下面的分解是否为无损分解？
- 成绩（学号、课程号、分数）
- 学生（学号、姓名）
- 课程（课程号、课程名）
点我查看答案
由于有：学号->姓名，则：成绩（学号、课程号、分数、姓名）
由于有：课程号->课程名，则：成绩（学号、课程号、分数、姓名、课程名）
所以现在新的关系模式是：成绩（学号、课程号、分数、姓名、课程名）
根据分解得出初始表如下：
| 学号 | 姓名 | 课程号 | 课程名 | 分数 | |
|---|---|---|---|---|---|
| 成绩 | ✔ | ✔ | ✔ | ||
| 学生 | ✔ | ✔ | |||
| 课程 | ✔ | ✔ |
先根据依赖：学号->姓名，再根据依赖：课程号->课程名，得到如下表格：
| 学号 | 姓名 | 课程号 | 课程名 | 分数 | |
|---|---|---|---|---|---|
| 成绩 | ✔ | ✔（学号->姓名） | ✔ | ✔（课程号->课程名） | ✔ |
| 学生 | ✔ | ✔ | |||
| 课程 | ✔ | ✔ |
从上表可看出，成绩行已经全部是✔，符合新的关系模式，因此本次分解是无损分解。
并发控制（⭐）
ACID特性
- 原子性（Atomicity）：事务包含的所有操作要么全部成功，要么全部失败回滚。
- 一致性（Consistency）：事务必须使数据库从一个一致性状态变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
- 隔离性（Isolation）：一个事务的执行不能被其它事务干扰，即一个事务内部的操作及使用的数据对并发的其它事务是隔离的。
- 持久性（Durability）：一个事务一旦提交，它对数据库中数据的改变就是持久的，无论发生何种故障，都不应对其有任何影响。
并发问题
- 脏写：事务T1和事务T2同时在更新同一条数据，事务T1先修改为A，事务T2紧接着把它修改为B，这对事务T1来说就是脏写。
- 脏读：事务T1读取了事务T2更新的数据，然后事务T2回滚，那么T1读取的数据就是脏数据。
- 不可重复读：事务T1多次读取同一数据，事务T2在事务T1多次读取的过程中，对数据作了更新并提交，导致事务T1多次读取同一数据时，结果不一致。
- 幻读：事务T1多次查询同一范围的数据，期间事务T2新增了数据，导致事务T1再次读取数据时，结果不一致。
封锁协议
提示
- 写锁【独占锁、X锁】：读写互斥、写写互斥。
- 读锁【共享锁、S锁】：读写互斥，读读不互斥。
- 一级封锁协议：事务T1在修改数据之前必须先对其加X锁，直到事务T1结束才释放。
- 二级封锁协议：一级封锁协议的基础上，事务T2在读取数据之前必须先对其加S锁，读完即释放。
- 三级封锁协议：一级封锁协议的基础上，事务T2在读取数据之前必须先对其加S锁，直到事务T2结束才释放。
- 两段锁协议：写加X锁，读加S锁，当出现读写锁冲突时，后访问的事务必须等前一个事务执行完成，才能继续执行。（串行化，可能发生死锁）
| 封锁协议 | 防止脏写？ | 防止脏读？ | 防止不可重复读？ | 防止幻读？ |
|---|---|---|---|---|
| 一级 | ✔ | |||
| 二级 | ✔ | ✔ | ||
| 三级 | ✔ | ✔ | ✔ | |
| 两段锁 | ✔ | ✔ | ✔ | ✔ |
数据库安全（⭐）
安全性
- 用户标识和鉴定：最外层的安全保护措施，可以使用用户账户、口令及随机数校验等方式。
- 读写控制：对用户进行授权，包括操作类型（如查找、插入、删除、修改等动作）和数据对象（主要是数据范围）的权限。（Grant和Revoke）
- 密码存储和传输：对远程终端信息用密码传输
- 视图的保护：对视图进行授权
- 审计：使用一个专门文件或数据库，自动将用户对数据库的所有操作记录下来
数据备份
冷备份【静态备份】
将数据库正常关闭，在停止状态下对数据库的文件全部备份。
优点：
- 快速（只需复制文件）
- 容易归档
- 容易恢复到某个时间点
- 维护简单，安全读高
缺点：
- 单独使用时，只能提供到某一时间点上的恢复。
- 在实施备份的全过程中，数据库必须停止。
- 若磁盘空间有限，只能复制到磁带等其它外部存储设备上，速度会很慢。
- 不能按表或按用户恢复。
热备份【动态备份】
利用备份软件，在数据库正常运行时将数据库中的文件备份出来。
优点：
- 可在表空间或数据库文件级备份，备份时间短。
- 备份时数据库仍可工作。
- 可到达秒级恢复。
- 可对几乎所有数据库实体做恢复，恢复快速。
缺点：
- 不能出错，否则后果很严重。
- 若热备份不成功，所得结果不可用于时间点的恢复。
- 因难于维护，所以要特别小心，不允许以“失败”告终。
备份的数据量
- 完全备份：备份所有数据
- 差量备份：仅备份上一次完全备份之后变化的数据
- 增量备份：备份上一次备份之后变化的数据
示例：
| 周日 | 周一 | 周二 | 周三 | 周四 | 周五 | 周六 |
|---|---|---|---|---|---|---|
| 全备 | 增备 | 增备 | 差备 | 增备 | 差备 | 增备 |
提示
日志文件：事务日志是针对数据库改变所做的记录，它可以记录针对数据库的任何操作，并将记录结果保存在独立的文件中。
故障与恢复
| 故障关系 | 故障原因 | 解决方法 |
|---|---|---|
| 事务本身的可预期故障 | 本身逻辑 | 应用程序设置回滚 |
| 事务本身的不可预期故障 | 算术溢出、违反存储保护等 | 由DBMS的恢复子系统通过日志、撤销事务对数据库的修改，回退到事务初始状态 |
| 系统故障 | 系统停止运转 | 通常使用检查点法（系统重启时自动完成） |
| 介质故障 | 外存被破坏 | 一般使用日志重做业务 |
- 撤销事务【Undo】：故障发生时未完成的事务，放入Undo日志。
- 重做事务【Redo】：故障发生前已提交的事务
数据库性能优化（⭐⭐）
反规范化
| 技术手段 | 说明 |
|---|---|
| 增加派生性冗余列 | 已有单价和数量列，增加总价列 |
| 增加冗余列 | 已有学号列，增加姓名列 |
| 重新组表 | 把拆分的表重新组表 |
| 分割表 | 把用户表水平分割，长沙的用户存在长沙，上海的用户存在上海 |
反规范化的优点：连接操作少，检索快、统计快；查表少，检索容易。
| 反规范化的缺点 | 解决方案 |
|---|---|
| 数据冗余，需要更大的存储空间 | 无 |
| 插入、更新、删除操作开销更大，代码更复杂 | 无 |
| 数据不一致，可能产生添加、修改以及删除异常 | 1. 触发器同步 2. 应用程序同步 3. 批处理 |
数据库索引
索引：提升查询效率，但降低了增加、修改、删除的效率。采用B+树等。
数据库视图
视图的优点：
- 简化用户操作
- 使用户能以多角度看待同一数据
- 对重构数据库提供了一定程度的逻辑独立性
- 对机密数据提供安全保护
分区分表分库
| 分区 | 分表 | ||
|---|---|---|---|
| 共性 |
| ||
| 差异 | 逻辑上还是一张表 | 逻辑上已是多张表 | |
分区
| 分区策略 | 分区方式 | 举例 |
|---|---|---|
| 范围分区 | 按数据范围值来做分区 | ID<1000000的映射到A区； 1000000<=ID<2000000映射到B区；... |
| 散列分区 | 通过对key进行hash运算分区 | 根据ID取余均匀分到3个区，ID mod 3： 余数为0分到A区；余数为1到B区；余数为2的C区。 |
| 列表分区 | 根据某字段的某个具体值进行分区 | 用户表里有个城市字段，对应中国的各个城市，则： 上海用户分到A区；北京用户分到B区；... |
分区优点：
- 相对于单文件系统或硬盘，分区可以存储更多的数据。
- 数据管理比较方便，比如要清理或废弃某年的数据，就可以直接删除该日期的分区数据即可。
- 精准定位多个分区磁盘查询，不需要全表扫描，大大提高数据检索效率。
- 可跨多个分区磁盘查询，提高查询的吞吐量。
- 在涉及聚合函数查询时，可以很容易进行数据的合并。
NoSQL（⭐⭐⭐）
| 对比维度 | 关系型数据库 | 非关系型数据库NoSQL |
|---|---|---|
| 应用领域 | 面向通用领域 | 特定应用领域 |
| 数据容量 | 有限数据 | 海量数据 |
| 数据类型 | 结构化数据 | 非结构化数据 |
| 并发支持 | 支持并发，但性能低 | 高并发 |
| 事务支持 | 高事务性 | 弱事务性 |
| 扩展方式 | 向上扩展 | 向外扩展 |
键值对数据库
Key指向Value的键值对，通常使用Hash Table来实现。
典型应用场景：内容缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等。
优点：查询速度快。
缺点：数据无结构化，通常只被当作字符串或者二进制数据。
举例：Redis、Memcached
列式存储数据库
以列簇式存储数据，即将同一列数据存在一起。
典型应用场景：分布式文件系统.
优点：查找速度快，可扩展性强（更容易进行分布式扩展）
缺点：功能相对局限
举例：HBase、Riak
文档型数据库
Key-Value对应的键值对，Value为结构化数据。
典型应用场景：Web应用（与键值对数据库不同的是能够了解Value的内容）
优点：数据结构要求不严格，表结构可变，不需要像关系数据库预先定义表结构。
缺点：查询性能不高，而且缺乏统一的查询语法。
举例：MongoDB、CouchDB
图形数据库
图结构，利用图结构相关算法（如最短路径寻址，N度关系查找等），专注于构建关系图谱。
典型应用场景：社交网络、关系图谱
缺点：很多时候需要对整个图做计算才能得出需要的信息，而且这种结构不太好做分布式的集群方案。
举例：Neo4J、InfoGrid
联邦数据库系统（⭐）
联邦数据库系统【FDBS】是一个彼此协作却又相互独立的成员数据库（CDBS）的集合，它将成员数据库系统按不同程度进行集成。对该系统整体提供控制和协同操作的软件叫联邦数据库管理系统FDBMS。
