5.1 数据库的安全性
5.1.1 数据库安全性含义
- 数据库的安全性：指保护数据库防止非法使用所造成的数据泄露、更改或破坏。
5.1.2 安全性控制的一般方法
- 安全性控制：指要尽可能地杜绝所有可能的数据库非法访问。
- 安全性措施：
- 用户标识和鉴定：系统提供的最外层的安全保护措施。
- 用户存取权限控制
- 授权：定义用户存取权限
- 存取权限两要素：数据对象和操作类型
- 存取权限：系统权限和对象权限
- 定义视图
- 数据加密
- 将明文加密成不可直接识别的密文，数据以密文形式存储和传输
- 审计
5.1.3 SQL Server 2012的数据安全性机制
- SQL Server 2012安全模型：
- 服务器安全管理
- 数据库安全管理
- 数据库对象访问权限管理
5.1.4 SQL Server 2012身份验证模式
- Windows身份验证模式
- 特点：“登陆一次”，授信连接
- 优点：
- 数据库管理员的工作可以集中在管理数据库方面，而不是管理用户账户。
- Windows有着更强的用户账户管理工具
- Windows的组策略支持多个用户同时被授权访问SQL Server
- 混合身份验证模式
- 允许使用SQL Server身份验证模式或Windows身份验证模式
- 优点：
- 比Windows验证模式更安全
- 能够支持更大范围的用户
- 允许用户从未知或不可信的域进行连接
- 允许SQL Server支持基于Web的应用程序
- 设置身份验证模式
5.1.5 SQL Server 2012登陆账号和服务器角色
- SQL Server的服务器角色
- 角色：对权限集中管理的一种机制，角色可以方便管理员对用户权限的集中管理
- 服务器角色：是执行服务器级管理操作的用户权限的集合。是SQL Server系统内置的，数据库管理员（DBA）不能创建服务器角色
5.1.6 SQL Server 2012的数据库用户账号和数据库角色
- 数据库的用户账号
- 登录名：访问SQL Server的通行证，存在master数据库的表syslogins中
- 用户名：主要用于数据库权限管理，必须和某个登录名相关联，存放在其相关数据库的sysusers表中
- 一个登陆账户可以创建多个用户，但一个登陆账户对于每一个数据库只能创建一个用户与之对应
- 数据库角色：与服务器角色不同的是，数据库角色权限的作用域仅限在特定的数据库内
- 用户权限管理
- 系统权限：表示用户对数据库的操作权限
- 对象权限：授予数据库用户对特定数据库中的表、视图和存储过程等对象的操作权限，相当于数据库操纵语言的语句权限
5.2 完整性控制
5.2.1 数据库完整性含义
- 数据库完整性：保护数据库中数据的正确性、有效性和相容性，防止错误的数据进入数据库造成无效操作
- 完整性和安全性的区别
- 安全性措施的防范对象时非法用户和非法操作
- 完整性的防范对象时不合语义的数据
5.2.2 完整性规则的组成
- 构成
- 触发条件
- 约束条件
- 违约响应
- 从执行时间上分两类
- 立即执行约束
- 延迟执行约束
- 一条完整性规则五元组——D,O,A,C,P
- D(Data)——代表约束作用的数据对象，可以是关系、元组和列
- O(Operation)——代表出发完整性检查的数据库操作
- A(Assertion)——代表数据对象必须满足的语义约束，这是规则主体
- C(Condition)——代表选择A作用的数据对象值的谓词
- P(Oricedure)——代表违反完整性规则时触发执行的操作过程
5.2.3 完整性约束条件的分类
- 值约束和结构约束
- 值约束：对数据类型、数据格式、取值范围和空值进行规定
- 结构约束：函数依赖约束，实体完整性约束，参照完整性约束，统计约束
- 静态约束和动态约束
- 静态约束，值的约束和结构的约束均属于静态约束
- 动态约束，反映的是数据库状态变迁的约束
5.2.4 数据完整性的实施
- 声明式数据完整性
- 程序化数据完整性
- 实施数据完整性的方法
- 约束（优先选择，执行速度比默认值和规则快）
- 默认值
- 规则
- 存储过程
- 触发器
5.2.5 规则
- 创建规则
CREATE RULE rule_name AS condition_expression
- 规则的绑定与松绑
使用存储过程sp_bindrule绑定规则
sp_bindrule [@rulename =] 'rule', [@objname =] 'object_name'[, 'futureonly']
futureonly:仅在绑定规则到用户自定义数据类型上时才可以使用
使用存储过程sp_unbindrule解绑规则
sp_unbindrule [@objname =] 'object_name'[, 'futureonly']
5.2.6 默认
- 创建默认
CREATE DEFAULT default_name AS constant_expression
- 默认的绑定和松绑
使用存储过程sp_binddefault绑定默认
sp_binddefault [@defaultname =] 'default', [@objname =] 'object_name'[, 'futureonly']
使用存储过程sp_unbinddefault绑定默认
sp_binddefault [@objname =] 'object_name'[, 'futureonly']
如果同时绑定了一个规则和默认，默认应该符合规则的规定
- 删除默认（删除前应先解绑）
DROP DEFAULT {default_name} [,...n]
5.3 并发控制与封锁
5.3.1 数据库并发性的含义
并发控制：防止多个用户并发存取同一数据时产生不正确的数据或破坏数据的完整性
并发控制就是解决这类问题保持数据库中数据的一致性
5.3.2 事务（Transaction）
- 事务：是数据库系统中执行的一个工作单位，它是由用户定义的一组操作序列，
- 事务的特征
- 原子性
- 一致性
- 隔离性
- 持久性
5.3.3 并发操作导致的数据不一致性
- 丢失更新
- 污读
- 不可重读
5.3.4 封锁，实现并发控制的方法（重点）
- 封锁类型
- 排他型锁（写封锁，简称X封锁）：原理，禁止并发操作
- 共享封锁（读封锁，简称S封锁）：原理，允许其他用户对同一数据对象进行查询，但不能进行修改
- 封锁协议
- 一级封锁协议：事务T在修改数据对象之前必须对其加X锁，直到事务结束。此级别只有修改数据时才进行加锁，读取并不加锁，所以不能防止“污读”和“不可重读”数据
- 二级封锁协议：在一级封锁协议的基础上，加上事务T在读取数据R之前必须对其加S锁，读完后释放S锁。可防止“污读”，但在读取数据之后立即释放S锁，仍然不能防止“不可重读”数据
- 三级封锁协议：在一级封锁协议的基础上，嘉盛事务T在读取数据R之前必须先对其加S锁，读完后不释放S锁，直到事务T结束后才释放。此类彻底解决了并发操作带来的三个不一致性问题
- 封锁粒度
- 封锁数据对象的大小称为封锁粒度
- 封锁粒度越小，系统能够被封锁的对象就越多，并发度越高，但封锁机构越复杂，系统开心越大。封锁粒度越大则相反
- 在实际应用中选择封锁粒度时应同时考虑封锁机构和并发度两个因素
- 死锁和活锁
- 活锁：当某个事物请求对某一数据进行排他性封锁时，由于其他事务对该数据的操作而使这个事务处于永久等待状态，这种状态称为活锁。避免活锁的简单方法采用先来先服务的策略
- 死锁：在同时处于等待状态的两个或多个事务中，其中的每一个在它能够进行之前，都等待着某个数据，而这个数据已被他们中的某个事务所封锁，这种状态称为死锁
- 死锁产生的必要条件
- 互斥条件：对数据的封锁采用排他式
- 不可抢占条件：不能别别的事务强行抢占
- 部分分配条件：一个事务已经封锁分给它的数据对象，但仍然要求封锁其他数据
- 循环等待条件：允许等待其他事物释放数据对象，系统处于加锁请求相互等待的状态
- 死锁的预防
- 一次加锁法：每个事务将所要使用的数据对象全部一次枷锁，只要有一个加锁不成功，则本次加锁失败，立即释放所有加锁成功的数据对象，然后重新开始加锁
- 扩大了封锁范围，降低了系统的并发度
- 由于数据是动态变化的，很难事先精确的确定每个事务要封锁数据对象，进一步降低了并发度，影响了系统的运行效率
- 顺序加锁法：预先对所有可加锁的数据对象规定一个加锁顺序，对每个事务都需要按此顺序加锁，在释放时，按逆序进行
- 一次加锁法：每个事务将所要使用的数据对象全部一次枷锁，只要有一个加锁不成功，则本次加锁失败，立即释放所有加锁成功的数据对象，然后重新开始加锁
- 死锁的诊断与解除：选择一个处理死锁代价最小的事务，将其撤销，并在之后加以恢复
5.4 数据库的恢复
5.4.1 数据库恢复的含义
数据库的恢复：系统必须具有检测故障并把数据从错误状态中恢复到某一正确状态的功能
5.4.2 数据库恢复的原理及其实现技术
- 数据库恢复的原理：利用数据冗余，恢复系统应提供两种类型的功能：生成冗余数据和冗余重建
- 生成冗余数据
- 登记日志文件
- 数据转储
5.4.3 数据库的故障和恢复策略
- 事务故障：采用事务撤销
- 系统故障
- 介质故障