这是我参与「第五届青训营 」伴学笔记创作活动的第 17 天
今天深入学习了数据库相关知识。
第一讲:绪论
- 数据模型的组成要素:数据结构(静态特性),数据操作(动态特性),完整性约束条件
- 任何关系必须满足实体完整性和参照完整性两个条件(还有用户自定义完整性)
- 层次,网状,关系
第二讲:关系型数据库
-
域(domin):是一组具有相同数据类型的值的集合(类似于数学的取值范围)
-
笛卡尔积:行行相乘
-
元组:一行数据,有n列就n元(向量)
-
分量:一个元组的一个列单元(分量)
-
属性:一列
-
候选码:所有唯一表示的键放一块(可以是好多个,也可以由多个组成一个)
-
全码:所有属性一起才能唯一表示称之为主码
-
主属性:候选码的属性
-
关系模式可以形式化地表示为: R(U,D,DOM,F)
R:关系名
U :组成该关系的属性名集合
D :属性组U中属性所来自的域
DOM:属性向域的映象集合
F:属性间的数据依赖关系集合
-
关系代数运算符
- 选择:选择特定行
- 投影:输出特定列
- 连接相关定义
第三讲:SQL
-
视图
- 从一个或几个基本表导出的表
- 数据库中只存放视图的定义而不存放视图对应的数据,视图是一个虚表
- 用户可以在视图上再定义视图
-
模式(todo)
-
删除的相关限制
- CASCADE 和 RESTRICT
-
删除附带的情况
- MySQL数据类型
# CLUSTER 表示创建聚蔟索引
CREATE [UNIQUE] [CLUSTER] INDEX <索引名> ON <表名> (<列名>[<次序>]…);
# ESCAPE表示指定该符号为转移字符
SELECT *
FROM Course
WHERE Cname LIKE‘DB_%i_ _’ ESCAPE ‘\ ’
#这里先用GROUP BY字句按Sno进行分组,然后再用COUNT对每一组计数,HAVING给出了选择组的条件,只有满足条件的组才会被选出
SELECT Sno
FROM SC
GROUP BY Sno
HAVING COUNT(*) >3;
HAVING短语与WHERE子句的区别:
作用对象不同;
WHERE子句作用于基表或视图,从中选择满
足条件的元组;
HAVING短语作用于组,从中选择满足条件的组
-
一般情况下主键会默认创建聚簇索引,且一张表只允许存在一个聚簇索引
-
DISTINCT表示会去除重复的行
-
% 表示任意长度的字符串。 _ 则表示任意的单个字符
-
Where 子句中是不能用聚集函数作为条件表达式的
-
like和=的区别
- like模糊查询,=准确查找
- like严格匹配空格,=会自动去除多余前缀后缀空格
-
IS NULL 或 IS NOT NULL其中的is不能用=替代
-
排序相关
-
升序:ASC;降序:DESC,缺省值为升序
-
当排序列含空值时:
- ASC:排序列为空值的元组最后显示
- DESC:排序列为空值的元组最先显示
-
-
当聚集函数遇到空值时,除了count( * )外,都跳过空值只处理非空值
-
HAVING短语与WHERE子句的区别:作用对象不同
- WHERE子句作用于基表或视图,从中选择满足条件的元组;
- HAVING短语作用于组,从中选择满足条件的组
-
子查询的限制
- 不能使用 ORDER BY 子句
- 层层嵌套方式反映了 SQL 语言的结构,有些嵌套查询可以用连接运算替代;
-
子查询分类
- 不相关子查询:先内层查询,再外层查询
- 相关查询:取得外层中获取一条元组,代入到内层查询中,再查询得到内查询结果,再运行外层查询,然后再取一个元组运算
-
视图相关
-
视图定义以后,可以当成基本表一样使用,视图定义后,并不执行任何操作,只有在使用视图时,才执行,视图只是虚表,对视图的操作都转化成为对相应基本表的操作
-
只能修改行列子视图,其他视图都不能修改
-
视图的更新是受限更新
- 1.视图由两个基本表导出,则不可更新:
- 2.视图的字段来白聚集函数,不可更新;
- 3.视图定义中有GROUP BY或者DISTINCT短语,不允许更新4.定义在视图之上的视图,不允许更新
-
视图的作用
- 视图能够简化用户的操作
- 视图使用户能以多种角度看待同一数据
- 视图对重构数据库提供了一定程度的逻辑独立性
- 视图能够对机密数据提供安全保护
- 适当的利用视图可以更清晰的表达查询
-
第四章:数据库安全性
GRANT <权限> [,<权限>]...
ON <对象类型> <对象名>]
TO <用户> [,<用户>]...
[WITH GRANT OPTION];#设置能否传递数据
#授予的权限可以由DBA或其他授权者用REVOKE语句收回
REVOKE <权限>[,<权限>]...
ON <对象类型> <对象名>]
FROM <用户>[,<用户>]...;
#对创建数据库模式一类的数据库对象的授权由DBA在创建用户时实现
CREATE USER <username>
[WITH][DBA | RESOURCE | CONNECT]
#角色的创建
CREATE ROLE <角色名>
#对角色授权
GRANT <权限>[,<权限>]…
ON <对象类型> 对象名
TO <角色>[,<角色>]…
#对修改SC表结构或修改SC表数据的操作进行审计
AUDIT ALTER,UPDATE
ON SC;
# 取消对SC表的一切审计
NOAUDIT ALTER,UPDATE
ON SC;
-
常用存取控制方式
- 自主存取控制(Discretionary Access Control,DAC)
- 强制存取控制(Mandatory Access Control, MAC)
-
对创建数据库模式一类的数据库对象的授权由DBA在创建用户时实现
-
创建数据库模式的权限
- 具有CONNECT特权的用户:不能创建新用户,不能创建模式和基本表,可以与数据库连接,能根据授权进行数据库中数据的查询、更新。
- 具有RESOURCE特权的用户除具有CONNECT特权外,还能创建表、索引,修改表结构,将自己创建的数据对象的访问权授予其他用户或从其他用户那儿收回,对自己创建的数据对象能进行跟踪审查。
- 具有DBA特权的用户能进行所有的数据库操作
-
数据库角色:被命名的一组与数据库操作相关的权限
- 角色是权限的集合
- 可以为一组具有相同权限的用户创建一个角色
- 使用角色来管理数据库权限可以简化授权的过程
-
强制存取控制(Mandatory Access Control,MAC)
- 每一个数据对象被标以一定的密级,每一个用户也被授予某一个级别的权限,对于任意一个数据对象,只有具有合法许可证的用户才可以存取
- 保证更高程度的安全性
- 用户不能直接感知或进行控制
- 适用于对数据有严格而固定密级分类的部门
- 仅当主体的许可证级别大于或等于客体的密级时,该主体才能读取相应的客体
- 仅当主体的许可证级别等于客体的密级时,该主体才能写相应的客体
- 禁止了拥有高许可证级别的主体更新低密级的数据对象。
- 强制存取控制是对数据本身进行密级标记,无论数据如何复制,标记与数据是一个不可分的整体,只有符合密级要求的用户才可以操作数据,从而提供了更高级别的安全性
-
还可以通过使用户观察视图而非控制原表格来实现
-
审计功能
- 审计功能是数据库管理系统达到C2以上安全级别必不可少的一项指标 审计功能是把用户对数据库的所有操作自动记录下来放入审计日志(audit log)中,审计员可以利用审计日志监控数据库的各种行为,找出非法数据的人、时间和内容,对潜在的威胁提前采取措施加以防范。 审计通常很费时间和空间,所以数据库管理系统往往都将审计设置为可选特征,允许数据库管理员根据具体应用对安全性的要求灵活地打开或者关闭审计功能。
- 数据库安全审计系统提供了一种事后检查的安全机制,将特定用户或者特定对象相关的操作记录到审计日志中,作为后续对操作的查询分析和追踪的依据
第五章:数据库完整性
#创建对应断言来简化条件筛选
CREATE ASSERTION ASSE_SC_DB_NUM
CHECK ( 60>= ( SELECT count(*)
FROM Course, SC
WHERE SC.Cno=Course.Cno AND Course.Cname=‘数据库’ ) );
#触发器的创建相关
CREATE TRIGGER <触发器名>
{ BEFORE | AFTER } <触发事件> ON <表名>
FOR EACH { ROW | STATEMENT }
[ WHEN <触发条件>] < 触发动作体 >
-
实体完整性
- 主码的值必须不为空且唯一
第六章:关系数据理论
第八章:数据库恢复技术
-
为什么要先写入日志
- 写数据库和写日志文件是两个不同的操作在这两个操作之间可能发生故障
- 如果先写了数据库修改,而在日志文件中没有登记下这个修改,则以后就无法恢复这个修改了
- 如果先写日志,但没有修改数据库,按日志文件恢复时只不过是多执行一次不必要的UNDO操作,并不会影响数据库的正确性
-
数据库恢复的流程
- 撤销(Undo)故障发生时未完成的事务;
- 重做(Redo)已完成的事务。
-
redo日志和undo日志的本质区别(数据丢失时回复的流程)
- 重做(REDO)队列在故障发生前已经提交的事务,这些事务既有BEGIN TRANSACTION记录,也有COMMIT记录
- 撤销 (Undo)队列故障发生时尚未完成的事务,这些事务只有BEGIN TRANSACTION记录,无相应的COMMIT记录
-
数据库恢复步骤
-
1、正向扫描日志文件(即从头扫描日志文件)
- 重做(REDO)队列在故障发生前已经提交的事务,这些事务既有BEGIN TRANSACTION记录,也有COMMIT记录
- 撤销 (Undo)队列故障发生时尚未完成的事务,这些事务只有BEGIN TRANSACTION记录,无相应的COMMIT记录
-
2、对撤销(Undo)队列事务进行撤销(UNDO)处理
- 反向扫描日志文件,对每个UNDO事务的更新操作执行逆操作,即将日志记录中“更新前的值”写入数据库
-
3、对重做(Redo)队列事务进行重做(REDO)处理
- 正向扫描日志文件,对每个REDO事务重新执行登记的操作, 即将日志记录中“更新后的值”写入数据库
-
-
使用检查点方法可以改善恢复效率
- 当事务 T 在一个检查点之前提交,T 对数据库所做的修改已写入数据库,写入时间是在这个检查点建立之前或在这个检查点建立之时,在进行恢复处理时,没有必要对事务T执行REDO操作。
-
动态维护日志文件的方法:周期性地执行如下操作:建立检查点,保存数据库状态
- 将当前日志缓冲区中的所有日志记录写入磁盘的日志文件上;
- 在日志文件中写入一个检查点记录;
- 将当前数据缓冲区的所有数据记录写入磁盘的数据库中;
- 把检查点记录在日志文件中的地址写入一个重新开始文件。
-
冗余磁盘阵列(Redundent Array of Independent Disks,RAID)
-
RAID将一组磁盘驱动器用某种逻辑方式联系起来,作为逻辑上的一个磁盘驱动器来使用。
-
一般情况下,组成的逻辑磁盘驱动器的容量要小于各个磁盘驱动器容量的总和。
-
RAID通过冗余技术,提供一个高级别的数据保护。
-
RAID的具体实现可以靠硬件也可以靠软件,Windows NT操作系统就提供软件RAID功能。
-
优点
- 成本低,功耗小,传输速率高
- 可以提供容错功能
- 具备数据校验(Parity)功能
- RAID比起传统的大直径磁盘驱动器来,在同样的容量下,价格要低许多
-
第九讲:并发控制
-
依赖的事务构成了环则为死锁,可以撤销代价小的事务解决
-
两段锁协议
- 第一阶段是获得封锁,也称为扩展阶段
- 事务可以申请获得任何数据项上的任何类型的锁,但是不能释放任何锁
- 第二阶段是释放封锁,也称为收缩阶段
- 事务可以释放任何数据项上的任何类型的锁,但是不能再申请任何锁
-
意向锁
-
如果对一个结点加意向锁,则说明该结点的下层结点正在被加锁
-
对任一结点加基本锁,必须先对它的上层结点加意向锁
- 例:对任一元组加锁时,必须先对它所在的数据库和关系加意向锁
-
SIX锁
- 如果对一个数据对象加SIX锁,表示对它加S锁,再加IX锁, 即SIX = S + IX。(只和IS锁相容)
- 对某个表加SIX锁,则表示该事务要读整个表(所以要对该表加S锁),同时会更新个别元组(所以要对该表加IX锁)
- 之所以其只和is锁相容是因为IX锁只和IS和IX锁相容
- IX锁和IX锁相容是因为两者都只是意向锁
-
第十章:数据库设计
-
数据库设计分6个阶段 ① 需求分析 ② 语义数据库建模(概念结构设计) ③ 逻辑结构设计 ④ 物理结构设计 ⑤ 数据库实现 ⑥ 数据库运行管理与维护
-
需求分析和概念设计独立于任何数据库管理系统
-
逻辑设计和物理设计与选用的DBMS密切相关
-
数据字典的用途
- 进行详细的数据收集和数据分析所获得的主要结果
-
数据字典的内容
- 数据项
- 数据结构
- 数据流
- 数据存储
- 处理过程
总结
-
数据库系统的特点
- 数据结构化;数据的共享性高,冗余度低,易扩充;数据独立性高;数据由DBMS统一管理和控制
-
数据模型分为两类(分属两个不同的层次)
-
概念模型 也称信息模型,它是按用户的观点来对数据和信息建模,用于数据库设计。
-
逻辑模型和物理模型
- 逻辑模型主要包括网状模型、层次模型、关系模型、面向对象模型等,按计算机系统的观点对数据建模,用于DBMS实现。 物理模型是对数据最底层的抽象,描述数据在系统内部的表示方式和存取方法,在磁盘或磁带上的存储方式和存取方法。
-
-
数据模型的组成要素:数据结构 ;数据操作;完整性约束条件
-
关系数据模型的优缺点
-
优点
- 建立在严格的数学概念的基础上
- 概念单一
- 实体和各类联系都用关系(即表)来表示,对数据的检索结果也是关系
- 关系模型的存取路径对用户透明
- 具有更高的数据独立性,更好的安全保密性简化了程序员的工作和数据库开发建立的工作
-
缺点
- 存取路径对用户透明导致查询效率往往不如非关系数据模型
- 为提高性能,必须对用户的查询请求进行优化增加了开发DBMS的难度
-
-
先进行DAC检查,通过DAC检查的数据对象再由系统进行MAC检查,只有通过MAC检查的数据对象方可存取。
-
两段锁协议
- 指所有事务必须分两个阶段对数据项加锁和解锁
- 在对任何数据进行读、写操作之前,事务首先要获得对该数据的封锁
- 在释放一个封锁之后,事务不再申请和获得任何其他封锁
-
封锁对象的大小称为封锁粒度(Granularity) 封锁的对象:逻辑单元,物理单元 封锁粒度与系统的并发度和并发控制的开销密切相关。 封锁的粒度越大,数据库所能够封锁的数据单元就越少,并发度就越小,系统开销也越小; 封锁的粒度越小,并发度较高,但系统开销也就越大