数据管理基础-期末复习

第一章绪论

数据（Data）是数据库中存储的基本对象
什么是数据库，有什么基本特点
- 数据库（Database，简称DB）是长期储存在计算机内、有组织的、可共享的大量数据的集合
- 数据库的基本特征
  - 数据按一定的数据模型组织、描述和储存
  - 可为各种用户共享
  - 冗余度较小
  - 数据独立性较高
  - 易扩展
数据库系统（Database System，简称DBS），在计算机系统中引入数据库后的系统构成
- 数据库
- 数据库管理系统（及其应用开发工具）
- 应用程序
- 数据库管理员（DBA）
数据模型
- 概念模型：按用户的观点来对数据和信息建模，主要用于数据库设计
- 逻辑模型：按计算机系统的观点对数据建模，主要用于数据库管理系统的实现
- 物理模型：对数据最底层的抽象，是面向计算机系统的
常见逻辑数据模型
- 格式化模型
  - 层次模型（Hierarchical Model）
  - 网状模型（Network Model）
- 关系模型（Relational Model)）
- 对象模型
  - 面向对象数据模型（Object Oriented Data Model）
  - 对象关系数据模型（Object Relational Data Model）
关系模型的优缺点
- 优点
  - 建立在严格的数学概念的基础上
  - 概念单一
  - 关系模型的存取路径对用户透明
    - 具有更高的数据独立性，更好的安全保密性
    - 简化了程序员的工作和数据库开发建立的工作
- 缺点
  - 存取路径对用户透明，查询效率往往不如格式化数据模型
  - 为提高性能，必须对用户的查询请求进行优化，增加了开发DBMS的难度
三级模式
- 数据库系统的三级模式结构由外模式、模式和内模式组成
- 外模式，是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图。
- 模式，是数据库中全体数据的逻辑结构和特性的描述，是所有用户的公共数据视图。模式描述的是数据的全局逻辑结构。外模式通常是模式的子集。一个数据库只有一个模式。
- 内模式，是数据在数据库系统内部的表示，即对数据的物理结构和存储方式的描述。一个数据库只有一个内模式。
两级映像
- 二级映象在数据库管理系统内部实现这三个抽象层次的联系和转换
- 外模式／模式映像：保证数据的逻辑独立性
  - 当模式改变时，数据库管理员对外模式／模式映象作相应改变，使外模式保持不变
- 模式／内模式映：保证数据的物理独立性
  - 当数据库的存储结构改变了，数据库管理员修改模式／内模式映象，使模式保持不变。

第二章关系型数据库

关系模型的完整性约束
- 实体完整性规则（Entity Integrity）
  - 若属性A是基本关系R的主属性，则属性A不能取空值
- 参照完整性规则
  - 若属性（或属性组）F是基本关系R的外码,它与基本关系S的主码K_s相对应（基本关系R和S不一定是不同的关系），则对于R中每个元组在F上的值必须为：
    - 或者取空值（F的每个属性值均为空值）
    - 或者等于S中某个元组的主码值
- 用户定义的完整性
  - 针对某一具体关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求
5种基本操作
- 选择、投影、并、差、笛卡尔积

第三章关系数据库标准语言SQL

基本表和视图
- 基本表
  - 本身独立存在的表
  - 一个关系对应一个基本表
- 视图
  - 从一个或几个基本表导出的表
  - 数据库中只存放视图的定义而不存放视图对应的数据
  - 视图是一个虚表
连接操作
- 嵌套循环法
- 排序合并法
- 索引连接法

EXISTS 子查询

查询选修了全部课程的学生姓名。

SELECT Sname
FROM Student
WHERE NOT EXISTS
(SELECT *

FROM Course
WHERE NOT EXISTS
  (SELECT * FROM SC
   WHERE Sno= Student.Sno
    AND Cno= Course.Cno
   )

);

查询至少选修了学生201215122选修的全部课程的学生号码。
SELECT DISTINCT Sno
FROM SC SCX
WHERE NOT EXISTS
(SELECT *

FROM SC SCY
WHERE SCY.Sno = ' 201215122 '  AND 
      NOT EXISTS
        (SELECT *
         FROM SC SCZ
         WHERE SCZ.Sno=SCX.Sno AND
               SCZ.Cno=SCY.Cno
        )

);

行列子集视图
- 若一个视图是从单个基本表导出的，并且只是去掉了基本表的某些行和某些列，但保留了主码，我们称这类视图为行列子集视图
视图有什么作用
- 视图能简化用户的操作
- 视图使用户能以多种视角看待同一数据
- 视图对重构数据库提供了一定程度的逻辑独立性
- 视图能够对机密数据提供安全保护
- 适当的利用视图可以更清晰地表达查询

第四章数据库安全性

自主存取控制和强制存取控制
- 自主存取控制
  - 用户对不同的数据对象有不同的存取权限
  - 不同的用户对同一对象也有不同的权限
  - 用户还可将其拥有的存取权限转授给其他用户
- 强制存取控制
  - 每一个数据对象被标以一定的密级
  - 每一个用户也被授予某一个级别的许可证
  - 对于任意一个对象，只有具有合法许可证的用户才可以存取
  - 用户不能直接感知或进行控制
GRANT和REVOKE
- GRANT INSERT ON TABLE SC TO U5 WITH GRANT OPTION;
- REVOKE INSERT ON TABLE SC FROM U5 CASCADE ;
审计
- 启用一个专用的审计日志（Audit Log）将用户对数据库的所有操作记录在上面

第五章数据库完整性

完整性和安全性
- 数据的完整性
  - 防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据
  - 防范对象：不合语义的、不正确的数据
- 数据的安全性
  - 保护数据库，防止恶意的破坏和非法的存取
  - 防范对象：非法用户和非法操作
参照完整性检查

| 被参照表 | 参照表 | 违约处理 |
| ——————————— | ——————————— | —————————————— |
| 可能破坏参照完整性 | 插入元组 | 拒绝 |
| 可能破坏参照完整性 | 修改外码值 | 拒绝 |
| 删除元组 | 可能破坏参照完整性 | 拒绝/级连删除/设置为空值 |
| 修改主码值 | 可能破坏参照完整性 | 拒绝/级连修改/设置为空值 |
断言
- 使用 CREATE ASSERTION语句，通过声明性断言来指定更具一般性的约束。
- 可以定义涉及多个表的或聚集操作的比较复杂的完整性约束。
- CREATE ASSERTION ASSE_SC_CNUM1
  CHECK(60 >= ALL (SELECT count(*) FROM SC GROUP by cno);
触发器
- 触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程
- CREATE TRIGGER SC_T
  AFTER UPDATE OF Grade ON SC
  REFERENCING
  OLD row AS OldTuple,
  NEW row AS NewTuple
  FOR EACH ROW
  WHEN (NewTuple.Grade >= 1.1 * OldTuple.Grade)
  INSERT INTO SC_U (Sno,Cno,OldGrade,NewGrade)
  VALUES(OldTuple.Sno,OldTuple.Cno,OldTuple.Grade,NewTuple.Grade)

第六章关系数据库理论

范式
- 1NF：每个分量必须是不可分开的数据项。
- 2NF：若关系模式R∈1NF，并且每一个非主属性都完全函数依赖于任何一个候选码，则R∈2NF
- 3NF：设关系模式R∈1NF,若R中不存在这样的码X、属性组Y及非主属性Z（Z ⊉Y）, 使得X→Y，Y→Z成立，Y ↛ X，则称R ∈ 3NF。
- BCNF：设关系模式R∈1NF，若X →Y且Y ⊈ X时X必含有码，则R∈BCNF。
简述规范化理论对数据库设计的指导意义
- 在数据分析阶段，用数据依赖的概念分析和表示各项数据项之间的关系
- 在设计概念结构阶段，用规范化理论消除初步 E-R 图冗余的联系
- 在 E-R 图向数据模型转化阶段，用模式分解的概念和方法指导设计

第七章数据库设计

数据库设计的基本步骤
- 需求分析
- 概念结构设计
  - 概念模式
- 逻辑结构设计
  - 逻辑模式和外模式
- 物理结构设计
  - 内模式
- 数据库实施
- 数据库运行和维护
逻辑模型设计中的水平分解和垂直分解
- 水平分解：把（基本）关系的元组分为若干子集合，定义每个子集合为一个子关系
  - 对符合”80/20“原则的，把经常被使用的数据分解出来，形成一个子关系
  - 水平分解为若干子关系，使每个事务存取的数据对应于一个子关系
- 垂直分解：经常在一起使用的属性从 R 中分解出来形成一个子关系模式
  - 优点：提高某些事务的效率
  - 缺点：可能使另一些事务不得不执行连接操作，降低了效率

第十章数据库恢复技术

事务(Transaction)是用户定义的一个数据库操作序列，这些操作要么全做，要么全不做，是一个不可分割的工作单位。事务是恢复和并发控制的基本单位
事务的特性（ACID）
- 原子性
- 一致性
- 隔离性
- 持久性
故障种类
- 事务内部的故障
  - 事务没有达到预期的终点(COMMIT或者显式的ROLLBACK)
- 系统故障
- 介质故障
- 计算机病毒
恢复的基本原理：冗余
- 利用存储在系统别处的冗余数据来重建数据库中已被破坏或不正确的那部分数据
静态转储和动态转储
- 静态转储
  - 在系统中无运行事务时进行的转储操作
  - 转储开始时数据库处于一致性状态
  - 转储期间不允许对数据库的任何存取、修改活动
  - 得到的一定是一个数据一致性的副本
  - 优点：实现简单
  - 缺点：降低了数据库的可用性
- 动态转储
  - 转储操作与用户事务并发进行
  - 转储期间允许对数据库进行存取或修改
  - 优点
    - 不用等待正在运行的用户事务结束
    - 不会影响新事务的运行
  - 缺点：不能保证副本中的数据正确有效
海量转储和增量转储
- 海量转储: 每次转储全部数据库
- 增量转储: 只转储上次转储后更新过的数据
日志文件
- 日志文件是用来记录事务对数据库的更新操作的文件
- 作用
  - 事务故障恢复和系统故障恢复必须用日志文件。
  - 在动态转储方式中必须建立日志文件，后备副本和日志文件结合起来才能有效地恢复数据库。
  - 在静态转储方式中，也可以建立日志文件。
    - 当数据库毁坏后可重新装入后援副本把数据库恢复到转储结束时刻的正确状态
    - 利用日志文件，把已完成的事务进行重做处理
    - 对故障发生时尚未完成的事务进行撤销处理
    - 不必重新运行那些已完成的事务程序就可把数据库恢复到故障前某一时刻的正确状态
为什么要先写日志文件
- 写数据库和写日志文件是两个不同的操作
- 在这两个操作之间可能发生故障
- 如果先写了数据库修改，而在日志文件中没有登记下这个修改，则以后就无法恢复这个修改了
- 如果先写日志，但没有修改数据库，按日志文件恢复时只不过是多执行一次不必要的UNDO操作，并不会影响数据库的正确性
恢复策略
- 事务故障
  - 反向扫描文件日志（即从最后向前扫描日志文件），查找该事务的更新操作。
  - 对该事务的更新操作执行逆操作。即将日志记录中“更新前的值” 写入数据库。
  - 继续反向扫描日志文件，查找该事务的其他更新操作，并做同样处理。
  - 如此处理下去，直至读到此事务的开始标记，事务故障恢复就完成了。
- 系统故障
  - 正向扫描日志文件，找出在故障发生前已经提交的事务队列(REDO队列)和未完成的事务队列(UNDO队列)。
  - 对未完成的事务队列中的各个事务进行UNDO处理。反向扫描日志文件，对每个撤销事务的更新操作执行逆操作
  - 对已经提交的事务队列中的各个事务进行REDO处理。正向扫描日志文件，对每个重做事务重新执行登记的操作
- 介质故障
  - 装入最新的数据库后备副本(离故障发生时刻最近的转储副本),使数据库恢复到最近一次转储时的一致性状态。
  - 装入转储结束时刻的日志文件副本，重做已完成的事务。
检查点记录
- 建立检查点时刻所有正在执行的事务清单
- 这些事务最近一个日志记录的地址
重新开始文件的内容
- 记录各个检查点记录在日志文件中的地址
动态维护日志文件的方法
- 周期性地执行如下操作：建立检查点，保存数据库状态。
- 具体步骤是：
  - 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上
  - 在日志文件中写入一个检查点记录
  - 将当前数据缓冲区的所有数据记录写入磁盘的数据库中
  - 把检查点记录在日志文件中的地址写入一个重新开始文件
利用检查点恢复步骤
- 从重新开始文件中找到最后一个检查点记录在日志文件中的地址，由该地址在日志文件中找到最后一个检查点记录
- 由该检查点记录得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST
  - 建立两个事务队列
    - UNDO-LIST
    - REDO-LIST
  - 把ACTIVE-LIST暂时放入UNDO-LIST队列，REDO队列暂为空。
- 从检查点开始正向扫描日志文件，直到日志文件结束
  - 如有新开始的事务Ti ，把Ti暂时放入UNDO-LIST队列
  - 如有提交的事务Tj，把Tj从UNDO-LIST队列移到REDO-LIST队列；直到日志文件结束
- 对UNDO-LIST中的每个事务执行UNDO操作
- 对REDO-LIST中的每个事务执行REDO操作

第十一章并发控制

并发操作带来的数据不一致
- 丢失修改
- 不可重复读
- 读脏数据
并发控制的主要技术
- 封锁
- 时间戳
- 乐观控制法
- 多版本并发控制
封锁：事务T在对某个数据对象（例如表、记录等）操作之前，先向系统发出请求，对其加锁。在事务T释放它的锁之前，其它的事务不能更新此数据对象。

基本类型：排它锁、共享锁
封锁协议
- 一级封锁协议
  - 事务T在修改数据R之前必须先对其加X锁，直到事务结束才释放。
  - 防止丢失修改
- 二级封锁协议
  - 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，读完后即可释放S锁。
  - 防止丢失修改和读“脏”数据
- 三级封锁协议
  - 一级封锁协议加上事务T在读取数据R之前必须先对其加S锁，直到事务结束才释放。
  - 防止丢失修改、读脏数据和不可重复读
什么是活锁，如何避免？
- 事务T1封锁了数据R，事务T2又请求封锁R，于是T2等待。
- T3也请求封锁R，当T1释放了R上的封锁之后系统首先批准了T3的请求，T2仍然等待。
- T4又请求封锁R，当T3释放了R上的封锁之后系统又批准了T4的请求……
- T2有可能永远等待，这就是活锁的情形
- 避免活锁：采用先来先服务的策略
什么是死锁，如何解决？
- 事务T1封锁了数据R1，T2封锁了数据R2
- T1又请求封锁R2 ，因T2已封锁了R2 ，于是T1等待T2释放R2上的锁
- 接着T2又申请封锁R1 ，因T1已封锁了R1 ， T2也只能等待T1释放R1上的锁
- 这样T1在等待T2 ，而T2又在等待T1 ， T1和T2两个事务永远不能结束，形成死锁
- 预防死锁的方法：
  - 一次封锁法，要求每个事务必须一次将所有要使用的数据全部加锁，否则就不能继续执行
  - 顺序封锁法，预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实行封锁
- 检测死锁的方法：
  - 超时法，如果一个事务的等待时间超过了规定的时限，就认为发生了死锁
  - 等待图法，并发控制子系统周期性地（比如每隔数秒）生成事务等待图，检测事务。如果发现图中存在回路，则表示系统中出现了死锁
- 解除死锁的方法：
  - 选择一个处理死锁代价最小的事务，将其撤消
  - 释放此事务持有的所有的锁，使其它事务能继续运行下去
可串行化调度
- 多个事务的并发执行是正确的，当且仅当其结果与按某一次序串行地执行这些事务时的结果相同
冲突可串行化
- 一个调度Sc在保证冲突操作的次序不变的情况下，通过交换两个事务不冲突操作的次序得到另一个调度Sc’，如果Sc’是串行的，称调度Sc是冲突可串行化的调度
两段锁协议，指所有事务必须分两个阶段对数据项加锁和解锁。可保证并发调度的可串行性
- 在对任何数据进行读、写操作之前，事务首先要获得对该数据的封锁
- 在释放一个封锁之后，事务不再申请和获得任何其他封锁
封锁粒度
- 封锁对象的大小称为封锁粒度
意向锁
- 提高对某个数据对象加锁时系统的检查效率
- 如果对一个结点加意向锁，则说明该结点的下层结点正在被加锁
- 对任一结点加基本锁，必须先对它的上层结点加意向锁

第十二章 NoSQL

关系型数据库的优缺点
- 优点
  - 建立在严格的数学概念的基础上
  - 概念单一
  - 关系模型的存取路径对用户透明
  - 获取持久化数据
  - 并发
  - 近乎标准的模型
- 缺点
  - 存取路径对用户透明，查询效率往往不如格式化数据模型（NoSQL）
  - 为提高性能，必须对用户的查询请求进行优化，增加了开发 DBMS 的难度
阻抗失谐：关系模型和内存中的数据结构之间存在差异
- 如果在内存中使用了较为丰富的数据结构，那么要把它保存到磁盘之前，必须先将其转换成“关系形式。于是就发生了“阻抗失谐”：需要在两种不同的表示形式之间转译
NoSQL共同特征
- 不使用关系模型
- 在集群中运行良好
- 开源
- 适用于21世纪的互联网公司
- 无模式
聚合
- 把一组相互关联的对象视为一个整体单元来操作，而这个单元就叫聚合（aggregate）。
- “键值数据库”、“文档数据库”、“列族数据库”
CAP定理：给定“一致性”(Consistency)、“可用性”(Availability)、“分区耐受性”( Partition tolerance) 这三个属性，我们只能同时满足其中两个属性。
仲裁
- 写入仲裁
  - 对等式分布模型：如果发生两个相互冲突的写入操作，那么只有其中一个操作能为超过半数的节点所认可，W>N/2 。即，参与写入操作的节点数(W)，必须超过副本节点数(N)的一半。副本个数又称为“复制因子”
  - 主从式分布模型：只需要向主节点中写入数据
- 读取仲裁
  - 对等式分布模型：只有当R+W>N时，才能保证读取操作的“强一致性”。其中，执行读取操作时所需联系的节点数(R)，确认写入操作时所需征询的节点数(W)，以及复制因子(N)
  - 主从式分布模型：只需从主节点中读取数据
键值数据库
- 键值数据库(key-value store)是一张简单的哈希表(hash table)，主要用在所有数据库访问均通过主键(primary key)来操作的情况下。
- 客户端可以根据键查询值，设置键所对应的值，或从数据库中删除键。
- 适用场景
  - 保存会话
  - 购物车数据
  - 用户配置信息
- 不适用场景
  - 数据间关系
  - 含有多项操作的事务
  - 查询数据（无法根据值来查询）
  - 操作关键字集合（一次只能操作一个键）
文档数据库
- 文档彼此相似，但不必完全相同。文档数据库所存放的文档，就相当于键值数据库所存放的“值”。
- 文档数据库可视为其值可查的键值数据库。
- “文档”( document)是文档数据库中的主要概念。
- 其格式可以是XML、JSON、BSON等。
- 文档具备自述性(self-describing)，呈现分层的树状数据结构(hierarchical tree data structure)，可以包含映射表、集合和标量值。
- 适用场景
  - 事件记录
  - 内容管理系统及博客平台
  - 网站分析与实时分析
  - 电子商务应用程序
- 不适用场景
  - 包含多项操作的复杂事务
  - 查询持续变化的聚合结构
列族数据库
- 列族数据库，可以存储关键字及其映射值，并且可以把值分成多个列族，让每个列族代表一张数据映射表(map of data)。
- 列族数据库将数据存储在列族中，而列族里的行则把许多列数据与本行的“行键”(row key)关联起来。
- 适用场景
  - 事件记录
  - 内容管理系统和博客平台
  - 计数器
  - 限期
- 不适用场景
  - 需要以“ACID事务”执行写入及读取操作的系统。
  - 根据查询结果来聚合数据(例如SUM(求和)或AVG (求平均值))
  - 在开发早期原型或刚开始试探某个技术方案时
图数据库
- 图数据库可存放实体及实体间关系。
- 实体也叫“节点”(node)，它们具有属性(property)。可将节点视为应用程序中某对象的实例。
- 关系又叫“边”(edge)，它们也有属性。边具备方向性( directional significance)，而节点则按关系组织起来，以便在其中查找所需模式。
- 适用场景
  - 互联数据
  - 安排运输路线
  - 分派货物和基于位置的服务
  - 推荐引擎
- 不适用场景
  - 更新全部或某子集内的实体
  - 无法处理那么大的数据量，尤其在执行“全局图操作”，涉及整张图的操作)时更是如此
NoSQL汇总

数据管理基础-期末复习

第一章 绪论

第二章 关系型数据库

第三章 关系数据库标准语言SQL

第四章 数据库安全性

第五章 数据库完整性

第六章 关系数据库理论

第七章 数据库设计

第十章 数据库恢复技术

第十一章 并发控制

第十二章 NoSQL

第一章绪论

第二章关系型数据库

第三章关系数据库标准语言SQL

第四章数据库安全性

第五章数据库完整性

第六章关系数据库理论

第七章数据库设计

第十章数据库恢复技术

第十一章并发控制