数据库期末复习

第四章

数据库安全性定义

数据库安全性是指保护数据库以防止不合法使用所造成的数据泄露、更改或破坏

权限管理

自主存取控制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数据定义语言完成
• 完整性约束的检查
  • 检查数据是否满足完整性约束条件的机制
  • 检查实体完整性：
    • 检查主码是否唯一
    • 检查每个属性是否都为非空
  • 检查参照完整性：
    • 如下
• 违法处理
  • 拒绝、级联

可能破坏参照完整性的情况以及违约处理

 

1. 没有这个学生，但插入了该学生的成绩
2. 修改了学号，但参照表并没有这个新的学号
3. 原有某个学生的成绩，但被参照的学生没了，成绩作废
4. 修改了学生信息，成绩得跟着改，或者删掉

触发器

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锁，事务结束后才释放，解决了不可重复读问题

死锁的诊断方法

超时法、事务等待图法

等待图：周期性生成，如果出现环就说明产生死锁

可串行

多个事务并发执行是正确的，当且仅当其结果于依次顺序传销执行这些事务时的结果相同

可串行性时并发事务正确调度的准则

两端锁协议

在对任何数据进行读写之前，要先申请对该数据的封锁

在释放一个封锁后，事务不能申请合伙的任何其他封锁。

事务在开始的“扩张阶段”获得封锁，然后再“收缩阶段”释放封锁

遵循两段锁，是可串行调度的充分条件