七、数据库管理
1. 安全性
问题的提出
- 数据库的一大特点是数据可以共享
- 但数据共享必然带来数据库的安全性问题
- 数据库系统中的数据共享不能是无条件的共享
- 数据库中数据的共享是在DBMS统一的严格的控制之下的共享,即 只允许有合法使用的权限的用户访问允许他存取的数据
- 数据库系统的 安全保护措施是否有效是数据库系统主要的性能指标之一
什么是数据库的安全性
- 指保护数据库,防止因用户非法使用数据库造成数据泄露、更改或破坏
什么是数据保密
- 数据保密是指用户合法地访问到机密数据后能否对这些数据保密
- 通过指定法律道德准则和政策法规来保证
用户非法使用数据库的情况
计算机系统中常用的安全模型
1.1 安全性控制的一般方法
-
用户标识和鉴定
- 系统提供的最外层安全保护措施
-
存取控制
-
存取控制机制的功能:保证用户只能访问其有权存取的数据
-
存取控制机制的组成
- 定义存取权限
- 检查存取权限
用户权限定义和合法权检查机制一起组成了DBMS的安全子系统
-
关系系统中的存取权限
-
-
视图
- 视图机制把要保密的数据对无权存取这些数据的用户隐藏起来,从而自动地对数据提供一定程度的安全保护。
- 视图机制更主要的功能在于提供数据独立性,其安全保护功能不太精细,往往远不能达到应用系统的要求。
- 在实际应用中通常是 视图 机制与 授权 机制配合使用,首先用视图机制屏蔽掉一部分保密数据,然后在视图上面再进一步定义存取权限。
-
审计
- 审计功能启用一个专用的 审计日志 (Audit Log ),系统自动将用户对数据库的所有操作记录在上面
- DBA 可以利用审计日志中的追踪信息,重现导致数据库现有状况的一系列事件,以找出非法存取数据的人
- C2 以上安全级别的 DBMS 必须具有审计功能
-
密码存储
- 数据加密
- 防止数据库中数据在存储和传输中失密的有效手段
- 加密的基本思想
- 根据一定的算法将原始数据(明文, Plain text )变换为不可直接识别的格式(密文, Cipher text)
- 不知道解密算法的人无法获知数据的内容
- 加密方法
- 替换方法:使用密钥( Encryption Key )将明文中的每一个字符转换为密文中的一个字符
- 置换方法:将明文的字符按不同的顺序重新排列
- DBMS中的数据加密
- 有些数据库产品提供了数据加密例行程序
- 有些数据库产品本身未提供加密程序,但提供了接口
- 数据加密功能通常也作为 可选特征 ,允许用户自由选择
- 数据加密与解密是比较费时的操作
- 数据加密与解密程序会占用大量系统资源
- 应该只对高度机密的数据加密
- 数据加密
1.2 SQL的 DCL 实现存取权限管理
不同的用户对不同的数据应具有何种操作权力 是由 DBA 和表的建立者 即表的属主 根据具体情况决定的
SQL 语言则为 DBA 和表的属主定义与回收这种权力提供了手段SQL 的 DCL
- 授权
- 回收权力
1.2.1 SQL的授权功能
- 操作权限
- 用户的权限
- 接受权限的用户
- WITH GRANT OPTION子句
1.2.2 SQL收回权限的功能
2. 完整性
什么是数据库的完整性
- 数据库的完整性是指数据的 正确性 和 相容性 防止不合语义的数据进入数据库
- 学生的年龄必须是整数 取值范围为 14 29
- 学生的性别只能是 男 或 女
- 学生的学号一定是唯一的
- 学生所在的系必须是学校开设的系
- 数据库是否具备完整性关系到数据库系统能否真实地反映现实世界 因此 维护数据库的完整性是非常重要 的
完整性控制机制
(1 )完整性约束条件定义机制
- 完整性约束条件是数据模型的一个重要组成部分 它约束了数据库中
数据的语义 - DBMS 应提供手段让用户根据现实世界的语义定义数据库的完整性约
束条件,并把它们作为模式的一部分存入数据库中
(2 )完整性检查机制
- 检查用户发出的操作请求是否违背了完整性约束条件
(3 )违约反应
- 如果发现用户的操作请求使数据违背了完整性约束条件,则采取一定
的动作来保证数据的完整性
2.1 完整性约束条件
- 整个完整性控制都是围绕 完整性约束条件 进行的
- 完整性约束条件 是完整性控制机制的 核心
完整性约束条件作用的对象
- 列
对属性的取值类型、范围、精度等的约束条件 - 元组
对元组中各个属性列间的联系的约束 - 关系
对若干元组间、关系集合上以及关系之间的联系的约束
对象的状态
- 静态
- 对静态对象的约束是反映数据库 状态合理性 的约束
- 这是最重要的一类完整性约束
- 动态
- 对动态对象的约束是反映数据库 状态变迁 的约束
完整性约束条件分类
完整性约束条件小结
2.2 完整性控制
-
DBMS 的完整性控制机制
-
(1 )定义 功能:一个完善的完整性控制机制应该允许用户定义各类完整性约束条件
-
(2 )检查功能
- 立即执行的约束 :检查是否违背完整性约束的时机通常是在一条语句执行完后立即检查
- 延迟执行的约束:有时,完整性检查需要延迟到整个事务执行结束后再进行,如银行转账
-
(3 )违约反应
- 拒绝该操作
- 其他处理方法
-
-
关系系统三类完整性的实现
- 违反 实体完整性 规则和 用户定义的完整性 规则 的操作
- 一般 都是采用 拒绝执行 的方式进行处理
- 而对于违反 参照完整性 的 操作,
- 并不 都是简单地 拒绝执行
- 有时 还需要采取另一种方法,即接受这个操作,同时执行一些附加的操作,以保证数据库的状态仍然是正确的
- 违反 实体完整性 规则和 用户定义的完整性 规则 的操作
-
参照完整性的实现
2.3 SQL Server完整性实现
- SQL Server 中的实体完整性
- SQL Server 中的参照完整性
- SQL Server 中用户定义的完整性
3. 并发控制
3.1 并发控制概述
事务是并发控制和恢复的基本单位
- 对多用户并发存取同一数据的操作不加控制可能会存取和存储不正确的数据
- DBMS 必须提供并发控制 机制
3.1.1 事务
- 事务 ( 是用户定义的一个 数据库操作序列 ,这些操作要么全做,要么全不做,是一个不可分割的 工作单位
- 事务 和 程序 是两个概念
- 在关系数据库中,一个事务可以是一条 SQL 语句,一组 SQL 语句或整个程序
- 一个应用 程序 通常包含多个 事务
- 事务 是恢复和并发控制的基本单位
定义事务的两种方式
- 显式方式
- 事务的 开始 由用户显式控制或 DBMS 自动隐含
- 事务 结束 由用户显式控制
- 隐式方式
- 当用户没有显式地定义事务时,由 DBMS 按缺省规定 自动划分事务
显示定义事务
事务结束语句
- COMMIT
- 事务 正常结束
- 提交 事务的所有操作(读 更新)
- 事务中所有对数据库的 更新永久生效
- ROLLBACK
- 事务 异常终止
- 事务运行的过程中发生了故障,不能继续执行, 回滚 事务的所
有更新操作 - 事务回滚到 开始时的状态
事务的ACID特性
- 原子性
- 一致性
- 隔离性
- 持续性
3.1.2 数据不一致问题
并发操作带来的数据不一致性
- 丢失修改
- 不可重复性
- 读 “脏” 数据
3.2 并发操作的调度
- 计算机系统对并行事务中并行操作的 调度是随机的而不同的调度可能会产生不同的结果
- 将所有事务 串行起来的调度策略 一定是 正确的调度策略
- 如果一个事务运行过程中没有其他事务在同时运行
- 也就是说它没有受到其他事务的干扰
- 那么就可以认为该事务的运行结果是正常的或者预想的
可串行化的调度
- 以不同的顺序 串行 执行事务也有可能会产生不同 的结果
- 但 由于不会将数据库置于不一致状态,所以都可以认为是 正确 的
- 几个事务的并行执行是 正确的
- 当且仅当 其结果与按某一次序串行地执行它们时的结果相同。这种并行调度策略称为 可串行化( Serializable )的调度
可串行化的调度策略
- 为了保证并行操作的正确性, DBMS 的并行控制机制必须提供一定的手段来保证调度是 可串行化 的
- 从理论上讲,在某一事务执行时禁止其他事务执行的调度策略一定是可串行化的调度,这也是 最简单的调度策略
- 但这种方法实际上是 不可行 的,因为它使用户不能充分共享数据库资源
不同调度策略
- 串行执行
- a. 串行调度策略
- b. 串行调度策略
- 交错执行
- c. 不可串行化的调度
- d. 可串行化的调度
3.3 封锁
3.3.1 封锁类型
基本封锁类型
-
排它锁
-
共享锁
3.3.2 封锁粒度
- X 锁 和 S 锁 都是加在某一个 数据对象 上的
- 封锁的数据对象可以是 逻辑单元
- 属性值、属性值集合、元组、关系、索引项、整个索引、整个数据库等
- 封锁的数据对象也可以是 物理单元
- 页(数据页或索引页)、块等
- 封锁对象可以很大也可以很小
- 对整个 数据库 加锁
- 对某个 属性 值加锁
- 封锁对象的大小称为 封锁的粒度
封锁粒度一般原则
- 需要处理大量元组的用户事务
- 以 关系 为封锁单元;
- 需要处理多个关系的大量元组的用户事务
- 以 数据库 为封锁单位;
- 只处理少量元组的用户事务
- 以 元组 为封锁单位
3.3.3 封锁协议
在运用X 锁和 S 锁对数据对象加锁时,需要约定一些规则,这些规则为 封锁协议
- 何时申请 X 锁或 S 锁
- 持锁时间
- 何时释放
两种封锁协议
- 三级封锁协议——保证数据一致性
- 两段锁协议——保证并行调度可串行性
3.4 死锁和活锁
- 封锁技术可以有效地解决并行操作的 一致性问题
- 但 也带来一些新的问题
- 死锁
- 活锁
3.4.1 活锁
如何避免活锁
采用先来先服务 的策略
- 当多个事务请求封锁同一数据对象时,封锁子系统按请求封锁的
先后次序对这些事务排队 - 该数据对象上的锁一旦释放,首先批准申请队列中第一个事务获
得锁
3.4.2 死锁
解决死锁的两类方法
- 死锁的预防
- 死锁的诊断与解除
4. 故障和恢复
4.1 数据库故障
- 故障 是不可避免的
- 计算机硬件故障
- 系统软件和应用软件的错误
- 操作员的失误
- 恶意的破坏
- 故障的影响
- 轻则造成运行事务非正常中断,影响数据库中数据的正确性
- 重则破坏数据库,使数据库中数据部分或全部丢失
数据库的可恢复性
数据库故障的类型
-
事务故障
-
系统故障
系统故障常见原因
- 操作系统 或 DBMS 代码错误
- 操作员操作失误
- 特定类型的硬件错误(如 CPU 故障)
- 突然停电
-
介质故障
4.2 恢复的实现技术
-
恢复技术的原理
- 利用存储在系统其它地方的 冗余 数据来修复或重建数据库中被破坏的或不正确的 数据。
-
恢复的实现技术:复杂
大型数据库产品,恢复子系统的代码要占全部代码的10% 以上 -
恢复机制涉及的关键问题
- 如何 建立冗余数据
- 数据转储
- 登记日志文件
- 如何 利用这些冗余数据实施数据库恢复
- 如何 建立冗余数据
4.2.1 数据恢复
什么是转储
- 转储是指 DBA 将整个数据库复制到磁带或另一个磁盘上保存起来的过程
- 这些备用的数据文本称为 后备副本 或后援副本
转储的用途
- 供 介质故障恢复 时使用
- 一旦系统发生介质故障,数据库遭到破坏,可以将后备副本重新装入,把数据库恢复起来
- 恢复 的程度
- 重装后备副本只能将 DB 恢复到转储时的状态
- 要想恢复到故障发生时的状态,必须重新运行自转储以后的所有更新事务
转储方法
-
静态转储 与动态转储
-
海量 转储与增量转储
-
转储方法分类
4.2.2 登记日志文件
- 日志文件的内容
- 日志文件的用途
- 进行事务故障恢复
- 进行系统故障恢复
- 协助后备副本进行介质故障恢复
- 登记日志文件的原则
- 为保证数据库是可 恢复的
- 登记的次序 严格按并行事务执行的时间次序
- 必须 先写日志文件 ,后写数据库
- 写日志文件操作:把表示这个修改的日志记录写到日志文件
- 写 数据库操作:把对数据的修改写到数据库中
- 为保证数据库是可 恢复的
4.2.3 恢复策略
-
事务 故障的恢复
-
系统故障的恢复
-
介质 故障的恢复
5. 复制
5.1 数据库复制
- 复制是数据库 更具容错性 的方法,主要用于 分布式结构 的数据库中
- 在多个场地保留多个数据库备份,可以是整个数据库的副本,也可以是部分数据库的副本
- 各个场地的用户可以并发存取不同的数据库副本,进一步提高系统并发度
- 但 DBMS 必须采取一定手段,保证用户对数据库的修改能够及时反映到其所有副本上
数据复制
数据库复制的方式
- 数据库复制三种方式:
- 对等复制(最理想的复制方式)
- 主 / 从复制
- 级联复制
- 对等复制(最理想的复制方式)
- 不同的复制方式提供了不同程度的数据一致性
5.2 数据库镜像
- 介质故障是对系统影响最为严重的一种故障,严重影响数据库的可用性
- 介质故障恢复比较费时
- 为预防介质故障, DBA 必须周期性地 转储数据库
- 提高数据库可用性的解决方案
- 日志文件
- 数据库镜像
什么是数据库镜像
- DBMS 自动把整个数据库或其中的关键数据复制到另一个磁盘上
- 每当主数据库更新时, DBMS 会自动把更新后的数据复制过去
- 即 DBMS 自动保证镜像数据与主数据的一致性
数据库镜像的用途
- 出现介质故障时
- DBMS 自动利用镜像磁盘数据进行数据库 的恢复
- 不 需要关闭系统和重装数据库副本
- 没有出现故障时
- 可用于并发操作
- 一个用户对数据加排他锁修改数据
- 其他用户可以读镜像数据库上的数据,而不必等待该用户释放锁
- 可用于并发操作
数据库镜像图
使用数据库镜像时注意
- 数据库镜像是通过复制数据实现的,频繁地复制数据会降低系统运行效率
- 在实际应用中用户往往只选择对关键数据镜像
- 如日志文件