1. 绪论
看笔记5
2. 关系数据库
域,笛卡尔积,基数
关系模式(schema)是对关系的描述,关系是关系描述在某一时刻的状态或内容。
关系代数:集合运算符(并 交 差 笛卡尔积)和关系运算符(选择 投影 连接 除)
P110
4. 安全性
数据库安全性(定义),不安全因素(3),安全模型,存取控制流程,安全性控制方法(5)
数据库安全性控制(6),自主存取控制方法(GRANT,REVOKE),
GRANT <权限>
ON <对象类型><对象名>
TO <用户>
[WITH GRANT OPTION]
如
GRANT SELECT
ON TABLE Student
TO U1
REVOKE <权限>
ON <对象类型><对象名>
FROM <用户>
CREATE USER(3权限:CONNECT, RESOURCE, DBA)
- 数据库角色(权限的集合)
为一组具有相同权限的用户创建一个角色,简化授权过程
- 角色创建
CREATE ROLE <角色名>
- 角色授权
GRANT <权限>
ON <对象类型>对象名
TO <角色>
- 将一个角色授予其他的角色或用户
GRANT <角色1>
TO <角色2>
[WITH ADMIN OPTION]
- 角色权限收回
REVOKE <权限>
ON <对象类型>对象名
FROM <角色>
自主存取控制的缺点,主体客体,敏感度标记(TS, S, C, P),许可证级别,密级,强制存取控制规则
DAC + MAC安全检查
视图机制(要保密的数据隐藏,)
审计(审计日志,审计事件),AUDIT和NOAUDIT,
数据加密(基本思想,方法(2)),
5. 完整性
数据库完整性(正确性,相容性),
5.1 实体完整性
定义PK,列级定义和表级定义
- 实体完整性检查和违约处理
PK唯一?PK为空?B+树索引
5.2 参照完整性
定义:FK定义外码, 用REFERENCES短语指明这些外码参照哪些表的主码
参照完整性检查和违约处理
一个参照完整性将两个表中的相应元组联系起来,对被参照表和参照表进行增删改操作时可能破坏参照完整性(四种情况): 导致 参照表中某些元组的外码值在被参照表里找不到一个元组,其对应主码值与之相等。
参照违约处理(3)
还应定义外码列是否允许空值
5.3 用户定义完整性
属性上的约束条件
NOT NULL,UNIQUE,CHECK
不满足则拒绝执行
- 元组上的约束条件
用CHECK定义,不同于属性值限制,元组级限制可以设置不同属性之间的取值的相互约束
5.4 完整性约束命名子句CONSTRAINT
对完整性约束条件命名。
CONSTRAINT <完整性约束条件名><完整性约束条件>
- 修改表中的完整性限制
使用ALTER TABLE语句修改完整性限制
5.5 断言
CREATE ASSERTION,指定更具有一般性的约束。可以定义涉及多个表或聚集操作的比较复杂的完整性约束。
-
创建断言
CREATE ASSERTION <断言名>
,CHECK子句与WHERE子句相似
-
删除断言
DROP ASSERTION <断言名>
5.6 触发器TRIGGER
用户定义在关系表上的一类由事件驱动的特殊过程。
CREATE TRIGGER <触发器名>
{BEFORE | AFTER} <触发事件> ON <表名>
REFERENCING NEW | OLD {ROW | TABLE} AS <变量>
FOR EACH {ROW | STATEMENT}
[WHEN <触发条件>] <触发动作体>
6. 关系数据理论
概念集合:数据冗余、更新异常、插入异常、删除异常、完全函数依赖(P,F),超码,候选码、主码、主属性、非主属性。
1NF(数据项不可分),2NF(非主属性完全依赖任何候选码),3NF(消除传递依赖),BCNF(定义、性质,消除主属性对码的部分依赖和传递依赖),ArmStrong(自反、增广、传递、证明)
推理规则(
合并(X->Y, X->Z, 则X->YZ)、
伪传递(X->Y, WY->Z, 则WX->Z)、
分解(X->Y且Z⊆Y,则X->Z)
)
F的闭包(属性集X关于函数依赖集F的闭包)
引理6.2
7. 数据库设计
- 数据库设计:根据给定的应用环境,构造优化的逻辑模式和物理结构,据此建立数据库及其应用系统,满足信息管理要求(存储和管理哪些)和数据操作要求(查询,增,删改查,统计)。
- 目标:为用户和各种应用系统提供一个信息基础设施和高效率的运行环境。
- 特点(2):
- 数据库建设的基本规律
- 结构设计和行为设计相结合
- 设计基本步骤(需求分析,概念结构设计(概念模型E-R图),逻辑结构设计(关系模型),物理结构设计(物理结构),数据库实施,数据库运行和维护)
7.1 需求分析
- 任务:调查的重点是数据和处理,获得用户对数据库的要求(信息要求,处理要求,安全性和完整性要求)
- 数据字典:在需求分析阶段建立,是进行数据收集和分析的主要结果。数据项,数据结构,数据流,数据存储,处理过程
7.2 概念结构设计(概念模式)
- 定义:将需求分析得到的用户需求抽象为概念模型,就是概念结构设计。
- 特点:真实充分反映现实世界,易于理解,易于更改,易于向关系、网状、层次等各种数据模型转换
E-R模型
1. 实体与属性的划分原则
能作为属性的尽量作为属性,属性不能与其他实体有联系。
2. E-R图的集成
- 合并。消除子系统E-R图的冲突(属性冲突,命名冲突,结构冲突)
- 修改和重构。消除不必要的冗余.
3. 规范化理论消除冗余
- 确定 子 E-R图实体之间的数据依赖。得到函数依赖集FL。
- 求FL的最小覆盖GL,差集为D=FL-GL。逐一考察D中函数依赖,判断是否为冗余,若是则去掉。(D中联系不一定冗余)
7.3 逻辑结构设计(逻辑模式。外模式)
把基本E-R图转换为逻辑结构(即关系模式)。
转换原则
1. 一个实体型转换为一个关系模型。
关系属性:实体属性
关系的码:实体的码
2. 实体型1:1联系
可以转换为一个独立的关系模式,也可以与任意一端对应的关系模式合并。
- 独立的关系模式
- 关系的属性:与该联系相连的各实体的码和联系本身的属性
- 关系的候选码:每个实体的码均是
- 与某一端实体对应的关系模式合并
- 关系的属性:加入对应关系的码和联系本身的属性
- 关系的码:不变
3. 实体型1:n联系
- 独立的关系模式
- 属性:与该联系相连的各实体的码和联系本身的属性
- 码:n端实体的码
- 与n端对应的关系模式合并(better)
- 属性:在n端关系中加入1端关系的码和联系本身的属性
- 码:不变
4. 实体型m:n
- 属性:与联系相连的各实体的码 和 本身的属性
- 码: 各实体码的组合
5. 两个以上实体间的多元联系
- 属性:与多元联系相连的各实体的码即联系本身的属性
- 码:各实体码的组合
6. 具有相同码的关系模式可合并
- 将其中一个关系模式的全部属性加入到另一个关系模式种
- 去掉同义属性
- 调整属性次序
7.4 数据模型的优化
转换的主要依据是所选用的数据库管理系统的功能及限制,通常以规范化理论为指导。
方法
- 确定数据依赖
- 把依赖进行极小化处理,消除冗余的联系
- 确定属于第几范式
- 合并和分解。如果只是查询,不执行更新,非BCNF范式无影响。
- 对关系模式进行必要的分解。
- 水平分解:把关系的元组分为若干个子集合,定义每个子集合为一个子关系(8/2规则)
- 垂直分解:把关系R的属性分解为若干个子集合。经常使用的属性放在一起
7.5 物理设计(内模式)
为给定逻辑数据模型选取一个最适合应用要求的物理结构(存取结构和存取方法)的过程。
-
B+树索引存取方法
(经常出现的属性,经常作为最大值和最小值等聚集函数的参数的索引,常出现在连接操作条件中)作为索引。
-
Hash索引
-
聚簇存取
聚簇:为了提高属性组的查询速度,把这些属性上具有相同值的元组集中存放在连续物理块中。该属性组,称作聚簇码cluster key。
一个基本表最多只能建立一个聚簇索引。
优点:提高查询效率,节省存储空间。ORDER BY, GROUP BY, UNION, DISTINCT等子句特别有利。
缺点:只使用特定应用,建立和维护开销大。
确定数据库的存储结构
确定数据的存放位置和存储结构,包括:关系,索引,聚簇,日志,备份等的存储安排和存储结构,确定系统配置。
考虑存取时间,存储空间利用率和维护代价。(评估方向)
7.6 数据库实施和维护
应用程序调试 + 数据库试运行 + 数据库的运行和维护
- 维护工作:数据库的转储和恢复;数据库的安全性、完整性控制;数据库性能的监督、分析和改进;数据库重组织(物理存储变坏)和重构造(实体和实体间的联系发生变化)。
8. 关系查询处理和查询优化
9. 数据库恢复
9.1 事务
- 定义:用户定义的一个数据库操作序列,是一个不可分割的工作单位。事务是恢复和并发控制的基本单位。
BEGIN TRANSACTION
SQL 语句1
SQL ....
.....
COMMIT [or ROLLBACK]
COMMIT:正常结束,提交所有操作
ROLLBACK:异常终止,撤销完成的操作,回滚至开始状态
9.1.1 ACID特性
保证ACID特性是事务处理的重要任务。
- 原子性:事务不可分割,都做
- 一致性:从一个一致性变到另一个一致性状态。(不一致:发生故障,有些被迫中断,导致数据库处于不确定状态)
- 隔离性:一个事务的执行不能被其他事务干扰
- 持续性:一个事务一旦提交,他对数据库的数据改变是永久性的。
破坏ACID因素:不同事务交叉执行;事务运行过程中被强行停止
9.2 数据库恢复概述
- 定义:DBMS把DB从错误状态恢复到某一已知的正确状态。
9.3 故障种类
- 事务内部故障:指非预期的故障。意味没有到达预期的终点,可能处于不正确状态。事务撤销UNDO强行回滚事务,并撤销任何修改。
- 系统故障:软故障,内存中的数据库缓冲区信息全部丢失。系统重启时,所有非正常终止事务回滚,强行撤销UNDO未完成事务。对于缓冲区丢失信息,需要重做REDO所有的已提交事务
- 介质故障:硬故障。
- 计算机病毒
9.4 恢复的实现
- 恢复的基本原理:冗余。用存储在系统别处的冗余数据重建数据库中已被破坏或不正确的那部分数据。
- 如何建立冗余数据
- 如何利用冗余数据实施数据库恢复
9.4.1 数据转储
转储:DBA定期的将全部数据库备份的过程。(backup)
想要恢复到故障发生时的状态,需要重新运行自转储以后的所有更新事务。
- 转储方法:静态转出(无运行事务时执行),动态转储(和用户事务并发,必须建立日志文件),海量转储(每次转出全部数据库),增量转储(只转储更新过的数据)
9.4.2 登记日志文件
- 事务故障恢复和系统故障恢复必须用日志文件
- 登记的次序 严格按并发事务执行的时间次序
- 先写日志,后写数据库
- log定义:记录事务对数据库的更新操作的文件。格式:以记录为单位和以数据块为单位
- 以记录为单位,日志记录:(开始标记BEGIN TRANSACTION,结束标记COMMIT或ROLLBACK,所有更新操作)。记录的内容:事务标识,操作类型,操作对象,更新前后值
- 以数据块为单位:事务标识,被更新的数据块
作用(3):事务故障恢复;系统故障恢复,协助后被副本进行介质故障恢复。
9.5 恢复策略
9.5.1 事务故障恢复
有恢复子系统利用日志文件撤销(UNDO)此事务已对数据库进行的修改。由系统自动完成,对用户透明,无需用户干涉。
步骤
- 反向扫描文件日志,查找更新操作
- 对该事务的更新操作执行逆操作
- 继续反向扫描,重复
- 直至读到开始标记
9…5.2 系统故障恢复
- 未完成事务已写入DB:UNDO
- 已完成事务未写入DB:REDO
系统故障恢复在系统重新启动时自动完成
步骤
- 正向扫描日志文件
- REDO队列:既有BEGIN也有COMMIT
- UNDO队列:只有BEGIN,无COMMIT
- UNDO队列UNDO处理
- REDO队列REDO处理
9.5.3 介质故障恢复
- 重装数据库
- 重做已完成的事务
步骤
- 装入最新后备数据库副本,恢复至最新一致性状态。静态装入即可,动态还需装入日志文件副本,利用恢复系统故障的方法(REDO + UNDO)
- 装入转储结束时刻的日志文件,重做已完成的事务。
介质恢复需要DBA接入,但具体操作仍有DBMS完成
9.6 具有检查点的恢复技术
- 作用:减少崩溃恢复时间。
通过检查点,确定恢复时那些重做日志应该被扫描并应用于恢复。
- 日志文件中增加检查点记录
- 增加重新开始文件
- 动态维护日志
检查点记录的内容、重新开始文件的内容
动态维护日志文件的方法
周期性的执行:建立检查点、保存数据库状态
利用检查点的恢复步骤
- 从重新开始文件中找到最后一个检查点记录在日志文件中的地址,由该地址在日志文件中找到最后一个检查点记录。
- 得到检查点建立时刻所有正在执行的事务清单ACTIVE-LIST。ACTIVE暂时放入UNDO队列,REDO队列置空。
- 从检查点开始正向扫描,直到结束。
- 新开始的放入UNDO
- 提交的从UNDO移到REDO
- UNDO,REDO
9.7 数据库镜像
10. 并发控制
允许多个用户同时使用数据库系统。
- 存在问题:多事务同时存取同一数据;破坏隔离性和一致性
10.1 并发控制概述
事务是并发控制的基本单位。
- 并发控制机制的任务:对并发操作进行正确调度;保证事务隔离性;保证数据库的一致性
带来的数据不一致性
- 丢失修改
T1和T2读入统一数据并修改,写回的晚的事务破坏之前的提交结果,导致修改被丢失。
- 不可重复读
T1读取后,T2更新(修改–值不同,删除–值丢失,插入–值变多),则T1无法再现前一次的读取结果
- 读“脏”数据
T1修改,T2读取,而T1撤销操作,导致T2读取不正确数据
原因:并发操作破坏了事务的隔离性
10.2 封锁
排它锁
T对数据对象A加上X锁,则只允许T读取和修改,其他任何事务都不能再对A加任何类型的锁。保证释放前,不能读取和修改
共享锁
T可以读A但不能修改,其他事务只能再对A加S锁,不能加X锁,直到T释放A。保证其他事务可以读A,但不能修改。
10.3 封锁协议
- 定义:对封锁方式规定不同的规则(何时申请,持锁时间,何时释放),为并发操作的正确调度提供保证。分123级
一级封锁协议
T在修改R之前必须加X锁,直到事务结束才释放。(COMMIT或ROLLBACK)。
防止丢失修改。
如果仅读是不加锁的,因此不能保证可重复读和不读“脏”数据
二级封锁协议
一级封锁协议 + T读取R之前必须加S锁,读完即可释放S锁。
可以防止丢失修改 和 读脏数据。但由于读完立即释放S锁,所以不能保证可重复读
三级封锁协议
一级封锁协议 + ** 读取R之前加S锁,直到事务结束才释放。**三级协议都能避免。
10.4 活锁和死锁
活锁
先申请的封锁可能一直得不到满足。解决:采用FCFS
死锁
T1封锁R1,T2封锁R2,T1等待R2并保持R1,T2同理,导致死锁。
死锁原因:都封锁,都请求,都等待,都保持
-
死锁预防
- 一次封锁法:一次将所有使用的数据加锁,否则不执行
- 顺序封锁法:规定封锁顺序
-
死锁诊断
- 超时法:事务的等待时间超过时限,认为发生死锁
- 等待图法:T1等待T2:T1 -> T2.有环路表示有死锁
-
死锁解除:
选择处理死锁代价最小的T,并撤销
10.5 并发调度的可串行性
- 定义:已知串行调度是正确的,执行结果等价于串行调度的调度也是正确的,称为可串行化调度。
10.5.1 可串行化调度
pass
10.5.2 冲突可串行化调度
冲突可串行化
10.6 两段锁协议
- 定义:所有事务必须分两个阶段对数据项加锁和解锁,实现并发调度的可串行性。在对任何数据进行读写操作前,事务首先要获得对该数据的封锁;在释放一个封锁之后,事务不再申请和获得任何其他封锁。
- 第一阶段获得封锁,也成为扩展阶段。事务可以申请任何数据项上的任何类型的锁,但不能释放任何锁。
- 第二阶段释放封锁,也称为**收缩阶段。**可以释放任意,不能再申请。
两段锁一定可串行;可串行不一定是两段锁。遵循两段锁可能发生死锁。
10.7 封锁的粒度
- 定义:封锁对象的大小称为封锁粒度,封锁的对象包括逻辑单元和物理单元。
封锁的粒度越大,能封锁的单元越少,并发度越小,系统开销就越小。
多粒度封锁
支持多种封锁粒度供不同事务选择。同时考虑封锁开销和并发程度选择封锁粒度。
- 多粒度树:允许每个结点独立的加锁;一个节点加锁,则其子树都加相同类型锁;可能显示封锁(直接加锁)和隐式封锁(父节点导致)
加锁时检查
- 该数据对象
- 所有上级结点:本事物的显示 和 上级的隐式冲突
- 所有下级节点:与2相反
意向锁
对任意结点加基本锁,需要先对他的上层结点加意向锁。
-
意向共享锁 IS
一个节点加IS锁,表示后裔节点有意向加S锁
-
意向排它锁 IX
一个节点加IX锁,表示后裔节点有意向加X锁
-
共享意向排它锁 SIX
SIX表示 加S锁,再加IX锁 SIX = S + IX