数据库安全性
1.数据库的不安全因素
- 非授权用户对数据库的恶意存取和破坏
- 数据库中重要的数据被泄露
- 安全环境的脆弱性
2.授权：授予与收回
2.1.GRANT
grant <权限>，···
on <对象类型><对象名>，···
to <用户>···
[with check option] //表示 被授权的用户可以在授予其他用户这些权限(继续传递)
/* 把查询student表的权限授予U1 */
grant select //还可以是 ALL PRIVILEGES 全部权限，UPDATE（Sno） 更新某列
on Table student
to U1
2.2.REVOKE
revoke <权限>，···
on <对象类型><对象名>，···
from <用户>···[cascade|restrict] //默认：cascade 收回衍生权限
数据库完整性
1.实体完整性
- 列级约束条件
- 表级约束条件
- 单属性构成时，都可
- 多属性构成时，只能表级约束
create table stu
(
sno CHAR(9) PRIMARY KEY //列级约束定义
sname CHAR(20)
)
create table stu
(
sno CHAR(9)
sname CHAR(20)
PRIMARY KEY(sno) //表级约束条件
)
create table stu
(
sno CHAR(9)
sname CHAR(20)
PRIMARY KEY(sno,sname) //多值时表级约束，，！！表明 主码是（sno，sname），不是两个分开
)
1.1.实体完整性检查和违约处理
- 检查主码值是否唯一，不唯一则拒绝
- 检查主码的各个属性是否为空，有空就拒绝
2.参照完整性
2.1.定义参照完整性
//主码(sno,cno),sno为stu主码，cno为course主码
create table sc
(
sno int not null,
cno int not null,
grade int,
PRIMARY KEY(sno,cno),
FOREIGN KEY(sno) references stu(sno),
FOREIGN KEY(cno) references coruse(cno),
)
3.用户定义的完整性
3.1.属性列上的约束条件
- 列值非空 not null
- 列值唯一 unique
- 列值是否满足一个条件表达式 check
create table stu
( sno int not null，unique //not null.unique
ssex char(2) check(ssex in ('男','女')) //check
grade int check(grade > 0) //check
)
4.触发器
create trigger <触发器名> //触发事件发生时，触发器激活
{before|after} <触发事件> on <表名> //指明触发器激活的时间，是在触发事件前 或 后
REFERENCING NEW | OLD ROW AS<变量> //REFERENCING指出引用的变量
FOR EACH{ROW|STATEMENT} //定义触发器类型，知名动作体制性的频率
[when<触发条件>]<触发动作> //仅当触发条件为真时，触发动作体
关系数据理论
1.问题的提出
- 1NF：每一个分量是不可分的数据项
- 数据依赖：关系内部属性与属性之间的一种约束关系。最重要的是 函数依赖FD 多值依赖MVD
- 关系模型常常会有四种问题
- 一个好的模式应当不会发生插入异常、删除异常、更新异常。数据冗余尽可能小
2.规范化
2.1.函数依赖
- 平凡函数依赖：X->Y,Y属于X（不讨论）
- 非平凡函数依赖：X->Y,Y不属于X（以下均均为非平凡函数依赖）
- 决定因素：自变量，X
- 完全函数依赖：在某一关系模式下，X->Y，对于X的任一真子集，都无法推导出Y
- 部分函数依赖：在某一关系模式下，X->Y，存在至少一个X的真子集，可以推导出Y
- 传递函数依赖：在某一关系模式下，X->Y，Y推不出X，Y->Z，则X->Z
2.2.码
- 候选码：某一关系模式下，某个属性或属性组合，被完全函数依赖。即可称为该关系的候选码
- 超码：某一关系模式下，某个属性或属性组合，被部分函数依赖。即可称为该关系的超码
- 候选码是一类特殊的超码
- 主属性：包含在任何一个候选码中的属性
- 非主属性：不包含在任何一个候选码中的属性
- 全码：整个属性组是码
- 外码：某个属性不是本关系的码，是其他关系模型的码。
2.3.范式
- 规范化：一个低一级的范式关系模式通过模式分解转换成高级范式关系模型的集合的过程
2.4.2NF
- R属于1NF，且每个非主属性完全依赖于任何一个候选码，则R属于2NF
- 2NF消除的是非主属性对码的部分函数依赖
2.4.3NF
- R属于2NF，若R中不存在这样的 码X，属性组Y，非主属性Z（Z不属于Y）。使得X->Y，Y->Z成立。则符合3NF
- 3NF消除非主属性对码的传递依赖
2.4.BCNF
2.5.多值依赖
- 多值依赖：BCNF解决的问题都是函数范畴内，但仍然存在数据冗余以及增删改的不方便问题。
- 特性：
- 对称性
- 传递性
- 函数依赖可以看作多值依赖的特殊情况
- 多值依赖的解决要靠4NF
3.数据依赖的公理系统(Armstrong)
- Armstrong公理系统的推理规则：
- 根据以上规则，可以继续推出：
- 合并规则：由X->Y，X->Y，有X->YZ
- 伪传递规则：由X->Y，WY->Z，有XW->Z
- 分解规则：由X->Y，Z属于Y，有X->Z
- Armstrong公理系统是有效的，完备的
- 有效：由F触发根据公里推导出来的每一个函数依赖一定在F+中
- 完备：F+中的每一个函数依赖，必定可以由F出发根据Armstrong公理推导出来
- 闭包问题
零碎：
1.存储过程
- 优点：
- 存储过程不像sql语句那样再提出请求时才语法分析和优化，所以高效率
- 存储过程降低了客户机和服务器的通信量
- 方便实施企业规则
create or replace procedure <过程名>（参数）
AS
<过程化sql块>
2.事务
- 事务：用户定义的一个数据库操作序列，这些操作要么全做，要么全部做
- commit：提交事务
- rollback：回滚，撤销到事务开始阶段
- 事务的特性：ACID
- 事务故障类型：
- 事务内部故障：大多是非预期的，不可由应用程序处理
- 系统故障：指造成系统停止运转的任何事件，需要重新启动
- 介质故障
- 计算机病毒
- 各类故障对数据库的影响有两种可能性
- 恢复的原理也很简单：冗余
3.日志
- 记录事务对数据库的更新操作文件，包括：
- 登记日志文件，原则：
- 登记的次序严格按照并发事务执行的时间次序
- 必须先写日志文件，后写数据库
4.并发控制
- 交叉并发方式：在单处理机系统中，事物的并发执行实际上是这些并行事务的并行操作轮流交叉运行（实际还是串行）
- 同时并发方式：在多处理机系统中，可以实现多个事务真正的并行运行
- 事务是并发控制的基本单位
- 并发操作带来的数据不一致保活：
- 丢师修改
- 不可重复读
- 读脏数据（读到不正确的数据）
- 以上错误的原因：并发操作破坏了事务的隔离性
- 控制并发的主要技术：
- 可串行性 是并发事务正确性的准则
封锁
- 基本的封锁类型：
- 只存在多事务 同时用S锁对数据上锁，是可以同时进行，其他的组合方式都会被拒绝。
- 封锁协议：在对数据对象加锁时，还需要规则，例如：
- 封锁协议的类型
- 一级封锁协议
- 事务T在修改数据R之前必须对其加X锁，直至事务结束才能释放
- 一级封锁协议可防止丢失修改，保证事务T是可恢复的
- 在一级封锁协议中，读数据是不需要加锁的，所以她不能保证可重复读，不读脏数据
- 二级封锁协议
- 在一级封锁的基础上增加事务T在读取数据R之前必须加S锁，读完后释放S锁
- 防止读脏
- 三级封锁协议
- 在一级封锁协议的基础上增加事务T在读取数据之前R必须先对其加S，事务结束再释放
- 做到了防止重复读
- 该三级协议的主要区别在于 什么时候申请封锁，什么时候释放锁
活锁
- 封锁是可能导致产生操作系统中的异常状态的
- 活锁：某个事务的请求永远得不到处理，资源被抢占
- 解决方法：采用FIFO
死锁
- 死锁：互相等待的状况
- 死锁预防：
- 一次封锁法：要求每个事务必须一次将所有要用的数据全部加锁
- 顺序封锁法：预先对数据对象规定一个封锁顺序，所有事务都按这个顺序实施封锁
- 死锁的诊断与解除
- 超时法：设定时长，解锁
- 等待图法：不可产生回路，即可解决
