数据管理基础

基于王珊《数据库系统概论》第 6 版

在燃神 @hr 总结的期末重点上进行注解。由于是后面才想起来有重点所以前三章没有整，如果有机会的话后面再补（虽然前几章也没有什么内容）

不考的内容里面也有一些很有趣的东西，说不定也会补，咕咕咕

作业非常重要！！！需要会！！！

#第一章

基本概念：三个模型与映射，理解针对什么东西
概念模型E-R图
逻辑模型中关于关系的基本概念
结构：三级模式两个映射

#第二章

关系、码、关系基本性质
关系的完整性：三类约束条件，如何利用其进行检查处理
关系代数，包括集合、符号、与关系有关的操作等，操作的含义、结果如何做的很重要，详细定义可以不知道，但要知道怎么执行。用关系代数表达一些语义

#第三章

sql，特征仅看过理解即可，了解性质
知道数据定义、语法、代表含义，利用语法定义表等均需要
数据查询单表、连接需要，嵌套不做要求，用连接完成即可，尽量别嵌套（有风险）
集合、创建视图、更新删除等也需了解
了解空值等概念，不会特别考，但要知道
整个sql没什么不要的东西

#第四章

存取控制，如何做？缺点在哪里？REVOKE、GRANT等语句
强制控制和自主控制均要知道怎么做、有何缺点，不会很细

自主：

GRANT <权限类型> ON <对象类型> <对象名> TO <用户/角色> [WITH GRANT OPTION];
REVOKE <权限类型> ON <对象类型> <对象名> FROM <用户/角色> [CASCADE | RESTRICT];

“授权蔓延”、难以撤销、不适合高安全性环境

强制：密级

实现复杂、管理开销大、灵活性差、主要用于高安全性领域

#第五章

详细讨论完整性，断言和触发器不作要求
完整性检查需要知道怎么做

• 实体完整性：UNIQUE/NOT NULL

• 参照完整性：FOREIGN KEY

  • ON DELETE NO ACTION
  • ON DELETE CASCADE
  • ON DELETE SET NULL

• 用户定义完整性：

  • 属性上：
    • NOT NULL
    • UNIQUE
    • CHECK(expr)：CHECK(Grade >= 0 AND Grade <= 100)
  • 元组上：
    • CHECK(expr)：CHECK(Ssex = '女' OR Sname NOT LIKE 'Ms.%')
  • 也可以写成 CONSTRAINT <name> expr/UNIQUE/NOT NULL

#第六章

BCNF之前需要知道，之后的不需要知道
函数依赖等需要知道，给出例子需要能判断范式级别，也要知道如何提升等级
范式详细定义不会考，只考判定

• 1NF：所有属性均不可分

• 2NF：所有非主属性均完全函数依赖于主码（不能只依赖于一部分）

  • 反例：学生_课程_教师 (*StudentID, CourseID*, StudentName, TeacherName) 中，StudentName 只依赖于 StudentID，etc.
  • 如何做到 2NF？把所有部分函数依赖的键和它们各自依赖的主码的子集分拆出来

• 3NF：所有非主属性都直接函数依赖于主码

  • 反例：员工 (*EmpID*, EmpName, DeptID, DeptName) 中，DeptName 间接依赖于 EmpID（因为直接依赖于 DeptID 这个非主属性）
  • 如何做到 3NF？把所有传递依赖的属性和它们各自直接函数依赖的属性分拆出来

• BCNF：所有决定因素（无论是主属性还是非主属性）都必须是超码

  • 反例：学生_课程_助教 (StudentID, Course, Assistant) 中，如果 一个学生在特定课程中只能有一个助教 且 一个助教只负责一门课程，则不是 BCNF。因为课程依赖于助教，而助教不是超码。
  • 如何做到 BCNF？将不符合 BCNF 的关系进行分解，使得分解后的所有关系都满足 BCNF。

#第七章

数据分析不用太关注，要会绘制ER图
概念结构设计了解即可，如何将图拆开合并去除冗余，但是考试不是重点
逻辑结构设计转换要会做，ER图转换成表等
垂直和水平分解利弊需要知道，答题时要求举例一定要能够举例，什么时候用水平拆分，为什么用需要能说
物理模型设计：优化方式包括聚簇要求掌握，索引概念、创建索引等需要知道

E-R 图：

• 方框是实体

• 菱形是实体间的关系（1-1，1-n，m-n，或多元关系 etc.）

• 椭圆是实体或关系的（独有）属性

如何拆分 E-R 图：

• 属性不能再具有需要描述的性质

• 属性不能再与其它实体具有联系

如何合并 E-R 图：

• 属性冲突

  • 属性域冲突：例如你用 0 1 我用 ‘MALE’ ‘FEMALE’，需要统一定义
  • 属性取值单位冲突：例如你精确到年份我精确到日期，需要统一定义

• 命名冲突

  • 同名异义，需要改名字
  • 异名同义，需要改名字

• 结构冲突

  • 同一对象有不同抽象：你用属性我用实体，需要修改
  • 同一实体属性不同：你比我多属性，需要取并集
  • 同一关系定义不同：你是一对一我是一对多，看情况保留或合并

逻辑结构设计转换：

• 一对一：可以合并到一端，或者单独分拆

• 一对多：可以合并到“对多”一端，或者单独分拆

• 多对多：单独分拆

• 多元：分拆

垂直分解：

• 垂直分解是将一张表的列拆分到多个新的表中。每个新表都包含原始表的主键，以及原始表的某些非主键列。核心思想是根据列的访问模式将列分组，把经常同时使用的属性放在一起。

  • 利：
    • 减少行宽
    • 提高数据局部性：常用列放在一起，访问时数据更集中
  • 弊：
    • 增加 JOIN 操作

水平分解：

• 水平分解是将一张表（关系表）的行拆分到多个新的表中（或相同结构的多个数据库中），每个新表都包含原始表的完整结构。拆分通常基于某个列的值范围、哈希值或列表值。

  • 利：
    • 方便事务使用最经常使用的数据
    • 如果若干个事务使用的数据不相交，可以让这些事务存取数据
  • 弊：
    • 跨分区查询困难

聚簇：

• 一种物理数据组织方式，决定数据行在磁盘上的实际存储顺序。

• 如果一个表是聚簇的，那么具有相似聚簇键值的行将被物理地存储在一起。

• 使用 CLUSTERED INDEX 建立

索引：

CREATE [UNIQUE] [CLUSTERED | NONCLUSTERED] INDEX index_name
ON table_name (column1 [ASC|DESC], column2 [ASC|DESC], ...);

#第十章

事务的定义要知道
故障恢复过程中，日志、检查点等都需要知道，数据库镜像不是重点
恢复策略不作要求

事务：

• 事务是数据库管理系统（DBMS）执行的一个或一组操作，视为一个单一的、逻辑的工作单元。

• 事务是原子性的，要么全部成功执行并持久化到数据库，要么全部失败并回滚。

• 特性：ACID 原则

  • 原子性 (Atomicity)： 事务是“全有或全无”的。事务中的所有操作要么全部成功，要么全部失败并撤销。即使发生系统故障，已提交的事务也不会丢失。
  • 一致性 (Consistency)： 事务执行前后，数据库必须保持一致性状态。这意味着事务必须遵守所有预定义的规则、完整性约束（如主键、外键、检查约束）和业务逻辑。
  • 隔离性 (Isolation)： 多个并发执行的事务之间互不干扰。一个事务的中间状态对其他事务是不可见的，就好像它们是串行执行的一样。这防止了脏读、不可重复读和幻读等并发问题。
  • 持久性 (Durability)： 一旦事务成功提交，其对数据库所做的更改是永久性的，即使发生系统崩溃或电源故障，这些更改也不会丢失。数据库管理系统会确保这些更改被安全地记录下来。

故障：

• 事务故障：事务没有达到预期终点（COMMIT 或 ROLLBACK）

  • 需要撤销事务已经做出的任何修改（因为它确实未完成）

• 系统故障：系统停止运转

  • 需要撤销未完成事务、重做已提交（因为可能在缓存中，未写回磁盘）事务

• 介质故障：硬盘炸了

  • 备份，否则没救了

日志：

• 一个连续的记录序列，详细记录了数据库中发生的所有事务操作（包括数据的修改、插入、删除，以及事务的开始、提交、回滚等）。

• 内容包含：

  • 事务 ID
  • 操作类型（如 INSERT, UPDATE, DELETE）
  • 被修改的数据项标识（如表名、行 ID）
  • 旧值 (Before Image)： 数据项被修改前的值（用于回滚事务）
  • 新值 (After Image)： 数据项被修改后的新值（用于重做已提交事务）
  • 事务的开始、提交、回滚记录

为什么重做已提交任务是可行的？

因为赋值操作是幂等的，多做一次并不会改变结果。同理，这就是为什么日志是赋值而非修改

检查点：

• 将内存中所有已提交但尚未写入磁盘的数据（即脏页）强制写入磁盘，并记录下日志文件的当前位置。简单来说，它为恢复过程创建了一个一致的起点。

• 操作过程：

  • 暂停或限制新的数据库活动。
  • 将所有内存中的脏页（已修改但未写入磁盘的数据页）写入磁盘。
  • 将所有活跃事务的日志记录强制写入磁盘。
  • 在日志文件中写入一个特殊的检查点记录，其中包含活跃事务列表和日志起始位置等信息。
  • 恢复正常数据库活动。

#第十一章

并发控制为什么会出问题？如何解决不一致性？——主要是封锁，两种锁，写读锁之间如何影响，几个协议相互关系等
事务调度：基本概念，串行、冲突可串行化包括后面的几个锁等都需要知道
重点在讨论理解性和技术的部分，概念性的东西不是重点。

隔离级别：

• 读未提交：可以读未提交的内容，解决丢失修改

• 读已提交：只能读已提交的内容，解决脏读

• 可重复读：读过的内容别人不能写（S 锁），解决不可重复读

• 串行化：两阶段封锁，解决幻读

为什么读未提交解决了丢失修改？因为这四个隔离级别都会给写加 X 锁

两种基本锁类型：

• 排他锁 (Exclusive Lock, X-Lock / 写锁)

  • 用于写操作（INSERT, UPDATE, DELETE）

• 共享锁 (Shared Lock, S-Lock / 读锁)

  • 用途： 用于读操作（SELECT）

协议：

• 一级封锁协议

  • 事务在修改数据之前必须加 X-Lock，事务结束后释放 X-Lock。

• 二级封锁协议

  • 在一级封锁协议的基础上，事务在读取数据之前必须加 S-Lock，读完即可释放 S-Lock。修改数据前加 X-Lock，事务结束后释放 X-Lock。

• 三级封锁协议

  • 在二级封锁协议的基础上，要求 S-Lock 也必须在事务结束时才释放（而非读完释放）。

冲突可串行化 (Conflict Serializability)

• 冲突操作： 指在不同事务中，针对同一数据项，且至少有一个操作是写操作的两个操作。

  • R(X) 与 W(X) 冲突 (读写冲突)
  • W(X) 与 R(X) 冲突 (写读冲突)
  • W(X) 与 W(X) 冲突 (写写冲突)

• 冲突等价： 如果一个并发调度通过交换非冲突操作的顺序，可以转换为一个串行调度，那么这个并发调度就是冲突可串行化的。

• 可串行化：执行结果与这些事务的某个串行调度的执行结果相同（是“冲突可串行化”的超集）。

• 意义： 冲突可串行化是判断并发调度是否正确（即是否能避免所有并发异常）的重要标准之一。如果一个调度是冲突可串行化的，那么它保证是正确的。

• 与 2PL 的关系： 所有遵守两阶段封锁协议（2PL）的调度都是冲突可串行化的。 这也是 2PL 如此重要的原因。它提供了一个实际可行的机制来生成正确的并发调度。

两段锁协议保证可串行化调度，但是有可能死锁。

意向锁是用来减少“加锁时查询子节点是否有锁”的开销的。

SIX 是 S + IX，所以共存性是两个锁相交