数据库期末复习

第四章

数据库安全性定义

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

权限管理

自主存取控制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锁,事务结束后才释放,解决了不可重复读问题

死锁的诊断方法

超时法、事务等待图法

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

可串行

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

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

两端锁协议

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

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

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

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

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值