第四章
数据库安全性定义
数据库安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或破坏
权限管理
自主存取控制DAC
- 同一用户对于不同的数据对象有不同的存取权限
- 不同用户对统一对象也有不同的权限
- 用户可以将拥有的存取权限转授给其他用户
通过GRANT/REMOVE 实现:
GRANT INSERT/SELECT/UPDATE(sno)/ALL PRIVILEGES
ON TABLE table1,table2
TO U1,U2/PUBLIC
WITH GRANT OPTION //允许传播权限
REMOVE UPDATE(sno)/INSERT/SELECT
ON TABLE tabel1
FROM PUBLIC/U1
//FROM U1 CASCADE 联级回收因其分配出去的权限
可能存在无意泄露
强制存取控制MAC
系统为保证更高程度的安全性,按TDI/TCSEC标准中安全策略要求,所采取的强制存取检查手段
主体和客体:
主体:进程,DBMS的用户
客体:被动实体,受主体操纵,有自己相应的密级(T>S>C>P)
通过比较主体的许可证级别和客体的密级,最终确定主体是否能够存取客体
- 仅当主体的许可证级别大于或等于客体密级时,主体才能读取相应客体(权限高的可以修改权限低的)
- 仅当主体的许可证级别小于或等于客体密级时,主体才能写相应客体(权限低的虽然可以向权限高的写东西,但无法读取其中内容,也就无从更改,密级从高流向低,造成数据泄露)
强制存取控制是对数据本身进行密级标记,无论数据如何赋值,标记与数据是一个不可分的整体,只有符合密级标记要求的用户才可以操纵数据,从而提供了更高级别的安全性。
视图机制
把要保密的数据对无权存取这些数据的用户隐藏起来,提供数据独立性,与授权机制配合使用
- 使用视图机制屏蔽掉一部分保密数据
- 视图上面再进一步定义存取权限
- 间接实现了支持存取谓词的用户权限定义
CREATE VIEW view_name colume_list
AS select_statement
[WITH CHECK OPTION]
GRANT SELECT ON 职工 TO 王明;
GRANT SELECT ON 部门 TO 王明;
CREATE VIEW 职工_工资 AS
SELECT 职工号,工资 FROM 职工;
GRANT SELECT ON 职工 TO 刘星;
GRANT UPDATE(工资) ON 职工_工资 TO 刘星
第五章
数据库完整性的定义
指数据的正确性和相容性
- 数据的正确性:数据符合现实
- 数据的相容性:同一对象在不同关系表中的数据是符合逻辑的(学生所选课程必须是学院已经有的课程)
为了维护数据库完整性DBMS需要做什么
- 完整性约束条件机制的定义
- 数据库中数据必须满足的语义约束条件
- 完整性包含实体完整性、参照完整性、用户定义完整性
- 由SQL数据定义语言完成
- 完整性约束的检查
- 检查数据是否满足完整性约束条件的机制
- 检查实体完整性:
- 检查主码是否唯一
- 检查每个属性是否都为非空
- 检查参照完整性:
- 如下
- 违法处理
- 拒绝、级联
可能破坏参照完整性的情况以及违约处理
- 没有这个学生,但插入了该学生的成绩
- 修改了学号,但参照表并没有这个新的学号
- 原有某个学生的成绩,但被参照的学生没了,成绩作废
- 修改了学生信息,成绩得跟着改,或者删掉
触发器
CREATE TRIGGER [if not EXISTS] trigger_name
trigger_time trigger_ecent
ON tbl_name FOR EACH ROW
trigger_body;
trigger_time:{BEFORE|AFTER}
trigger_event:{INSERT|UPDATE|DELETE}
CREATE TRIGGER before_employee_update
BEFORE UPDATE
ON employee
FOR EACH ROW
INSERT INTO employees_audit(info,chagetime) VALUES("update",now());
- 表的拥有者才可以在表上创建触发器
- 触发器名必须唯一
- 触发器名和表名必须在同一模式下
- 只能定义在表上,不能定义在视图上
DROP TRIGGER if exists <name>
CREATE TABLE 职工 (
职工号 INT PRIMARY KEY,
姓名 VARCHAR(100),
年龄 INT CHECK (年龄 <= 60),
职务 VARCHAR(100),
工资 DECIMAL(10, 2),
部门号 INT,
FOREIGN KEY (部门号) REFERENCES 部门(部门号)
);
第六章
关系数据理论解决什么问题?
- 数据冗余:在不同表里同样的数据重复出现
- 更新异常:由于数据冗余,要对很多表里的数据进行更新
- 插入异常:系刚成立但没有学生,就会导致插入异常
- 删除异常:删除别的信息,但删掉了其他的数据
函数依赖
- 函数依赖:学生ID是逐渐,可以推知学生年龄,B->A
- 平凡函数依赖:{学生ID,姓名,年龄}A->{学生ID,姓名}B B是A的子集
- 非平凡函数依赖:{学生ID}A->{学生ID,姓名,年龄}B B不是A的子集
- 部分函数依赖:复合主键,主键中的一部分就能让另一个产生依赖
- 传递函数依赖:主键依赖主键
- 完全函数依赖:复合主键,全部共同决定一个属性Z
候选码
当集合K(P)→U,K是超码【K里面的元素组成的集合K能锁定某个元组】
即:超码对应部分函数依赖
当集合K(F)→U,K是候选码【完全函数依赖】
即:候选码对应完全函数依赖
候选码可以有很多,选一个作为主码
全码:整个属性组都是码
范式
第一范式1NF
所有属性都不可再分,拥有唯一标识这一行的码
第二范式2NF
满足1NF的基础上,每一个非主属性完全函数依赖于任何一个候选码
消除非主属性对复合主键(候选码)的部分依赖
第三范式3NF
消除传递依赖,非主键之间不能有依赖关系
如学生id,学生姓名,学生专业,专业负责人,虽然学生id可以唯一标示专业负责人,但也存在专业负责人可以被学生专业标识,学生专业又依赖于学生id,形成传递依赖
BC范式
x→Y,x必须是一个超码
候选码之间的传递依赖关系不会破坏第三范式,但会破坏BC范式
消除了主属性之间的函数依赖
阿姆斯特丹公理系统
最小覆盖
第七章
数据库设计的6个阶段
- 需求分析阶段
- 概念结构设计阶段
- 逻辑结构设计阶段
- 物理结构设计阶段
- 数据库实施阶段
- 数据库运行和维护阶段
ER图画法#
ER图的集成
合并ER图,生成初步ER图
消除不必要的冗余,设计基本的ER图
ER图转换为关系模式
确定数据库的物理结构,在关系数据库里指的是什么
为关系模式选择存取方式,以及设计关系,索引等数据库文件的物理存储结构
评价物理结构
对时间效率、空间效率、维护代价、各种用户要求进行平衡,依赖于对方案的细致评价
评价物理数据库的方法完全依赖于所选用的关系库管理系统,主要是从定量估算各种方案的存储空间、存取时间和维护代价入手,对估算结果进行权衡,比较,选择较优的、合理的物理结构。
不符合用户需求则需重新修改设计
第十章
事务的定义
时用户定义的一个数据库操作序列,这些操作要么全做,要么全不做,是一个不可分割的工作单位
提交方式
COMMIT 提交,提交事务的所有操作
ROLLBACK 回滚将所有已完成的操作全部撤销,回滚到事务开始的状态、
四个ACID特性
- 原子性
- 一致性
- 持久性
- 隔离性
前三类故障指什么(不用背)
- 事务内部故障:非预期的,来自程序内部的故障,可以被事务程序本身发现的或非预期的。意味着事务没有到达预期的重点因此数据库处于不正确的状态
- 系统故障:造成系统停止运转的任何时间,使得系统要重新启动
- 介质故障:硬故障,硬件损坏影响
恢复的原理是冗余,建立冗余的技术
数据转储
重装后副本只能将数据库恢复到转储时的状态
静态转储
动态转储
2x2
动态海量转储、动态增量转储、静态海量转储、静态增量转储
登记日志文件
是用来记录事务对数据库的更新操作的文件
登记的次序严格按并发事件执行的事件次序
必须先写日志文件再写数据库
检查点
检查点内容:
建立检查点时刻所有正在执行的事务清单
事务最近一个日志记录的地址
周期性地执行建立检查点,保存数据库状态地操作
可以改善恢复效率
数据库镜像
第十一章
并发控制带来的三个问题
- 失去修改:两个事务同时修改一个数据,第一个修改的结果被第二个给提交了,第一个的修改失效
- 不可重复读:拿到一个数据后,该数据被读取了,但当它再次访问时,该数据可能被别的事物更改
- 读脏数据:某个事务对数据进行更改,另一个进行了读取,但那个事务进行了回滚,拿到的数据和数据库里面的不一致
并发控制的主要解决方法 相容矩阵
封锁
排他锁(写锁):事务T对对象上X锁,期间其他事务不能再对该对象加任何锁,知道T释放A上的锁。
以及共享锁(读锁):读取时,上S锁,其他事务只能加S锁,所有S锁释放前不能对数据进行修改,只能进行读取
三级封锁协议
一级封锁:事务T再修改数据R之前必须加X锁,事务结束再释放(commit,rollback),解决了失去修改的问题
二级封锁:在一级封锁基础上增加在读取前,必须加S锁,读完后释放,解决了读脏数据的问题
三级封锁协议:在以及封锁协议的基础上增加在读取数据R之前加S锁,事务结束后才释放,解决了不可重复读问题
死锁的诊断方法
超时法、事务等待图法
等待图:周期性生成,如果出现环就说明产生死锁
可串行
多个事务并发执行是正确的,当且仅当其结果于依次顺序传销执行这些事务时的结果相同
可串行性时并发事务正确调度的准则
两端锁协议
在对任何数据进行读写之前,要先申请对该数据的封锁
在释放一个封锁后,事务不能申请合伙的任何其他封锁。
事务在开始的“扩张阶段”获得封锁,然后再“收缩阶段”释放封锁
遵循两段锁,是可串行调度的充分条件