数据库总结
计算机组成原理总结
数据库急救包（Double S）
数据库基本概念
数据库（Database，简称DB）是长期存储在计算机内的、有组织的、可共享的大量数据的集合。
数据库的特征
（1）数据按一定的数据模型组织、描述和存储—数据模型!
（2）可为各种用户共享
（3）冗余度较小
（4）数据独立性较高（数据独立于应用程序）
（5）易扩展
数据库系统组成部分
硬件系统
数据库集合
数据库管理系统及相关软件
数据库管理员
用户
元数据：元数据即描述数据的数据，相当于数据字典。主要是描述数据属性（property）的信息，如数据的类型，格式，存储大小等。
数据模型
对现实世界数据特征的抽象和对现实世界的模拟。
组成要素：数据结构、数据操作、数据完整性
概念数据模型：E-R图，与具体的DBMS无关
逻辑数据模型：是具体的DBMS所支持的数据模型。有层次模型，网状模型，关系模型，面向对象模型。
物理数据模型：面向具体的DBMS，描述数据在存储介质上的组织结构
数据管理技术
数据库管理系统
功能：
特点：
- 数据结构化
- 数据的共享性高、冗余度低，易扩充
- 数据独立性高
- 数据由DBMS统一管理和控制
数据库系统结构（三层模式）
- 外模式
- 外模式也称子模式或用户模式，它是数据库用户看见和使用的局部数据的逻辑结构和特征的描述，是数据库用户的数据视图，是与某一应用程序有关的数据的逻辑表示。
- 外模式通常是模式的子集，一个数据库可以有多个外模式。
- 模式
- 模式也称逻辑模式，是数据库中全体数据的逻辑结构和特征的描述，是所有用户的公共数据视图。
- 它是数据库系统模式结构的中间层，既不涉及数据的物理存储细节和硬件环境，也与具体的应用程序、所使用的应用开发工具及高级程序设计语言无关。
- 一个数据库只有一个模式。
- 内模式
- 内模式也称存储模式，一个数据库只有一个内模式。
- 它使用一个物理数据模型，全面描述了数据库中数据存储的全部细节和存取路径，是数据在数据库内部的表示方式。
- 外模式/模式映射
- 模式表达了数据的全局逻辑结构，外模式表达了数据的局部逻辑结构。对于每一个外模式，数据库系统都有一个外模式/模式映像。对应于同一个模式可以有任意多个外模式。当模式改变时，由DBA对各个外模式/模式映像作相应改变，可以使外模式/模式保持不变，从而应用程序不必改变，保证了数据的逻辑独立性。
- 模式/内模式映射
- 数据库只有一个模式和一个内模式，所以模式/内模式映像是唯一的。
- 它定义了数据全局逻辑结构和存储结构之间的对应关系。
- 当数据库的存储结构改变了，由DBA对模式/内模式作相应改变，可以使模式保持不变，从而保证了数据的物理独立性。
- 目的：保证数据独立性
- 逻辑独立性：指外部模式不受模式变化影响。
- 物理独立性：指模式不受内部模式变化的影响。
关系代数
除 关系代数 $\pi_XR-\pi_X((\pi_XR\times \pi_YS)-R)$
设关系模式为$R(A_1， A_2 ，…， A_n)$。它的一个关系设为$R$，$t[A_i]$则表示元组t中相应于属性A_i的一个分量。
给定一个关系R(X，Z)，X和Z为属性组。当$t[X] = x$时，x在R中的象集（Images Set）为：
$$Z_x={t[Z]|t\in R,t[X]=x}$$
给定关系R(X，Y)和S(Y，Z)，其中X，Y，Z为属性组。R中的Y与S中的Y可以有不同的属性名，但必须出自相同的域集，Z可以为空。R与S的除运算得到一个新的关系P(X)，P是R中满足下列条件的元组在X属性列上的投影：元组在X上分量值x的象集Y_X包含S在Y上投影的集合。记为：
$$R\div S={t_r[X]|t_r\in R\and\pi_Y(S)\subseteq Y_x}$$
广义投影 $\pi_{F_1,F_2,\ldots,F_n}(R)$ F为关系R属性上的函数，并可能含有常量
聚集函数 $\mathcal{G}_{count-distinct(职称)}(医生)$
分组形式 $(职称)\mathcal{G}_{count(医生编号)}(医生)$
数据库设计
数据库开发生命周期(DDLC)
（1）可行性研究和需求分析：了解企业或组织的运营状况，分析信息系统如何帮助解决经营过程中存在的问题，然后确定系统需求，完成功能规格说明书(FSD)。
（2）数据库设计：确定符合组织需求的数据库模型（数据库的概念模型）。
（3）数据库实现：根据选定的DBMS，将详细的概念模型转化为DBMS的实现模型。
（4）数据和应用程序转化：加载应用数据，将旧系统切换到新系统。
（5）测试和验证：测试新的数据库，验证预期结果。
（6）监控和维护：监控数据内容和应用程序的发展和扩充，并可能实施数据库模式的修改或重组。
数据库设计
需求分析阶段
概念设计阶段
逻辑设计阶段
物理设计阶段
实现阶段
运行与维护阶段
逻辑设计
实体转换规则
一个实体集转换为关系模型中的一个关系，实体的属性就是关系的属性，实体的码就是关系的码，关系的结构是关系模式。
联系转换规则
1：1联系：可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
当转换为独立的关系模式时，与之相连的每个实体的键均成为此关系模式的候选键，联系具有的属性成为关系的属性。如果采用与其中一端实体对应的关系模式合并方式，则合并后的关系模式属性应该加入另一端未合并的实体键和联系本身所具有的属性。
1：n联系：可以转换为一个独立的关系模式，也可以与n端所对应的关系模式合并。
如果采用转换为一个独立的关系模式，则与此联系相连接的各个实体的键，以及联系本身的属性均被转换为关系的属性，关系的键为n端实体的键。如果与n段对应关系合并，新属性包含1端实体集的码与联系自身属性，新增属性后原关系码不变。
m：n联系：转换为一个关系模式。
与此联系相连的各个实体的键及联系本身的属性均转换为关系的属性，各个相连实体的键的组合成为关系的键。
E-R图
实体集
- 强实体集指不依赖于其他实体集存在的实体集。强实体集的特点是：每个实例都能被实体集的主键唯一标识。
- 弱实体集指依赖于其他实体集存在的实体集。弱实体集的特点是：每个实例不能用实体集的属性唯一标识。
三个概念
- 实体用方框表示，方框内注明实体的名称；
- 属性用椭圆形框表示，并用无向边将属性与对应的实体连接起来；
- 联系用菱形框表示，并用无向边将其与相关的实体连接起来。
属性还是实体集
（1）作为属性，不能再具有需要描述的性质。属性必须是不可分的数据项，不能包含其他属性。
（2）属性不能与其他实体具有联系，即E-R图中所表示的联系是实体之间的联系。
无损分解与保持依赖
无损分解：一个关系表被分解成两个或两个以上的小表，通过连接被分解后的小表可以获得原始表的内容，则称为无损连接分解。
- 充分必要条件：$(U_1\cap U_2)\rightarrow(U_1-U_2)$或$(U_1\cap U_2)\rightarrow(U_2-U_1)$
保持依赖：设$\rho={R_1,\ldots,R_k}$是$R$的一个分解，$F$是$R$上的FD集，如果有$\mathop{\cup}\limits_{i=1}^k\prod R_i(F)\models F$
最小依赖集
范式
1NF：在关系模式R的每个关系r中，每个属性值都是不可再分的原子值。
2NF：关系模式R∈1NF，且每个非主属性（不是组成候选码的属性）完全函数依赖于候选码。
设有关系模式R(U)，主键是W，R上还存在函数依赖X→Z，其中Z是非主属性和$X\subset W$，则$W→Z$就是一个局部依赖。此时应该把R分解成两个模式：
① R1（XZ），主键是X；
② R2（U-Z），主键仍为W，外键是X（参考R1）。
利用外键和主键的连接可以从R1和R2重新得到R。
如果R1和R2还不是2NF，则重复上述过程，一直到数据库模式中每一个关系模式都是2NF为止。
3NF:关系模式R∈1NF，且每个非主属性都不传递依赖于R的候选码。
（1）R中的非主属性相互独立；
（2）R中的非主属性函数依赖于主键。
设关系模式R（U），主键是W，R上还存在FD X→Z，其中Z是非主属性，$Z\not\subseteq X$ 且X不是候选键，这样W→Z就是一个传递依赖。此时应把R分解成两个模式：
① R1（XZ），主键是X；
② R2（U-Z），主键仍是W，外键是X（参考R1）。
利用外键和主键相匹配机制，R1和R2通过连接可以重新得到R。
如果R1和R2还不是3NF，则重复上述过程，一直到数据库模式中每一个关系模式都是3NF为止。
BCNF:关系模式R∈1NF，且 (包含主属性和非主属性)都不传递依赖于R的候选码。
所有非主属性对每一个码都是完全函数依赖。
所有的主属性对每一个不包含它的码，也是完全函数依赖。
没有任何属性完全函数依赖于非码的任何一组属性。
SQL一些内容，语法见PPT
概述
数据定义功能，DDL（Data Definition Language）
提供命令定义关系模式、索引、视图，包括创建CREATE，修改ALTER以及删除DROP等命令。
数据操纵功能，DML（Data Manipulation Language）
提供命令对存储在数据库中的数据进行查询和修改操作，包括查询数据SELECT、插入数据INSERT、更新数据UPDATE、删除数据DELETE等命令。
数据控制命令，DCL（Data Control Language）
提供对关系和视图的授权命令、事务的控制命令以及并发控制中的加锁操作等。
视图：虚表，只存储视图定义，不存储视图数据
优点
视图能简化用户的操作
提高数据的安全性
保证数据的完整性
定义视图语法
CREATE VIEW <视图名> [(视图列表)]
AS <子查询>
[ WITH CHECK OPTION ]
查询视图语法
SELECT * FROM DiagView
更新视图原则
所定义的视图必须有一个单一表源
创建视图语法中不能用DISTINCT，不能含有GROUP BY、HAVING子句
每一个选择条目必须是一个简单的字段引用，选择列表中不能包含表达式、计算字段或者字段函数等
必须包含表源的所有NOT NULL列
删除视图语法
DROP VIEW 要删除的视图名
完整性约束（实体完整性、参照完整性、用户自定义完整性）
主键约束
- 在一个属性的类型定义完毕后，直接在后面加上PRIMARY KEY。
- 在所有属性定义完毕后，增加一个PRIMARY KEY的声明，指出主键包含哪些属性。
UNIQUE约束：指明某一列或多个列的组合上的取值必须唯一
- 在一个关系中，PRIMARY KEY只有一个，而UNIQUE可以声明多个
- PRIMARY KEY要求属性取值不能为NULL，而UNIQUE允许属性取空值，允许多个空值同时存在
- UNIQUE约束定义和PRIMARY KEY约束定义不能在同一属性上
- PRIMARY KEY子句中的每个属性的取值都必须是NOT NULL
- UNIQUE 约束唯一标识数据库表中的每条记录
- 可使用 UNIQUE 约束确保在非主键列中不输入重复值。
NOT NULL约束
CHECK约束：保证属性值满足指定的条件
约束命名： CONSTRAINT 约束名称
约束创建
Create table RecipeDeteail(
Rno varchar(10) Constraint pk_rd primary key,
Pno varchar(20),
Dno varchar(20),
Constraint un_pname_pm unique(Pno,Dno))
约束添加
ALTER TABLE RecipeDetail
ADD CONSTRAINT rno_mnokey PRIMARY KEY(Rno,Mno);
约束删除
ALTER TABLE RecipeDetail DROP CONSTRAINT rno_mnokey;
Foreign Key约束
lR中每个元组在F上的值必须为：①或者取空值；②或者等于S中某个元组的主码值。
- REFERENCES <被参照表表名>（<属性名>）
- FOREIGN KEY（<属性名>）REFERENCES <被参照表表名>（<属性名>）
破坏参照完整性对策
受限策略（RESTRICTED）（默认）
当出现违背参照完整性规则的更新操作请求时，系统拒绝执行该操作。
置空策略（SET-NULL）
依照参照完整性规则，外码是可以取空值的。
Ddeptno VARCHAR(10) REFERENCES Dept(DeptNo) ON DELETE SET NULL
级联策略（CASCADE）不用拒绝用户操作请求的处理方式，连带处理参照数据。
Ddeptno VARCHAR(10) REFERENCES Dept(DeptNo) ON DELETE CASCADE
断言：SQL中的断言可以解决多张关系表关联的约束定义。
CREATE ASSERTION <断言名> CHECK<谓词>
Create assertion salarycheck check(
Not exists(
Select from Doctor x
Where Dsalary >= some ( select Dsalary from Doctor y
Where x.Deptno=y.Deptno and y.Dno =(
Select Manager from Dept
Where x.Deptno =Dept.Deptno)
索引：避免全表扫描，耗时，提高查询性能的主要手段，属于内模式
常采用B树、B+树结构
聚簇索引
建立聚簇索引后，基表中数据也需要按指定的聚簇属性值的升序或降序存放。也即聚簇索引的索引项顺序与表中记录的物理顺序一致
一个基本表上最多只能建立一个聚簇索引
对于某些类型(范围查找)的查询，可以提高查询效率
适用于：很少对基表进行增删操作
很少对其中的变长列进行修改操作
CREATE CLUSTER INDEX Stusname ON Student(Sname)；
非聚簇索引
- 数据存储在一个地方，索引存储在另一个地方，索引带有指针指向数据的存储位置。
- 在搜索数据值时，先对非聚集索引进行搜索，找到数据值在表中的位置，然后从该位置直接检索数据。
- 由于索引包含描述查询所搜索的数据值在表中的精确位置的条目，这使非聚集索引成为精确匹配查询的最佳方法。
唯一值索引
- 唯一索引确保索引列不包含重复的值。
- 创建PRIMARY KEY或UNIQUE约束会在表中指定的列上自动创建唯一索引。
索引建立方法
- 选择数据量较大的表建立索引
- 建立索引的数量要适量（需要付出代价）
- 最好不超过3个
- 占用磁盘空间
- 建立索引会减慢插入、修改、删除的执行速度
- 在加快查询速度和降低更新速度之间作出权衡
- 选择合适的时机建立索引
- 建立索引应选择在表中装入数据之后（如果要保证装入数据的唯一性，则只能以牺牲系统性能为代价，而在装入数据前建立唯一性索引）
- 优先考虑主键列建立索引
索引相关语法
创建索引
CREATE [ UNIQUE ] [ CLUSTERED | NONCLUSTERED ] INDEX <索引名>
ON < 基表名 | 视图名> ( 列名[ ASC | DESC ] [ ,…n ] )
删除索引
DROP INDEX 索引名
是否冲突
若调度S中属于不同事务的两条操作指令是不冲突的，则可以交换两条指令的执行顺序，得到一个新的调度S′。称调度S与调度S′冲突等价的（conflict equivalent）。
若一个调度冲突等价于一个串行调度，则该调度是冲突可串行化的。
冲突可串行化$\Rightarrow$可串行性
对同一事务集，如果两个调度S1和S2在任何时候都保证每个事务读取相同的值，写入数据库的最终状态也是一样的，则称调度S1和S2视图等价。
如果某个调度视图等价于一个串行调度，则称这个调度是视图可串行化的
如果调度是冲突可串行化的，则该调度一定是视图可串行化的。但反过来未必成立。
可串行化判定：前驱图
若前驱图中存在环，则表示调度S是不可串行化的；否则，表示调度S是冲突可串行化的，可用拓扑排序得到调度S 的一个等价的串行调度
数据库系统要求所有调度可恢复，可恢复条件：调度S中，事务Ti如果读取了事务Tj修改过的数据，则事务Ti必须等事务Tj提交后才能提交
无级联回滚条件:调度S中的每对事务Ti和Tj，事务Ti如果读取了事务Tj修改过的数据，则事务Tj必须在Ti读取前提交
封锁
后像后写
后像在事务提交后才写入数据库
事务T的日志写入步骤
在T开始执行前，向日志中写入记录
; T的一次write（X）操作导致向日志中写入一条新记录;
最后，当T全部操作结束，向日志中写入记录
事务恢复
忽略未完成的事务；
重复(Redo(Ti))已提交事务的影响：将事务Ｔi更新的所有数据项的值设为新值
简化日志内容结构
由于忽略未完成的事务，只需要数据项的新值，前面介绍的更新日志记录结构可以简化，省去旧值字段。
日志记录<T，X，V1>：事务Ｔ对数据项Ｘ执行写操作，写入新值V1
恢复处理步骤
从后向前扫描日志，将提交的事务放入队列redo-list（找提交操作命令）
从前往后扫描日志。对遇到的每一<T,X,V1>记录:
如果T不是redo-list中的事务，则什么也不做。
如果T是redo-list中的事务，则为数据项X写入值V1
对每个未完成的事务，在日志中写入一个<T,ABORT>记录并刷新日志
后像前写
后像在事务提交前完全写入数据库
事务T的日志写入执行步骤
在T开始执行前，向日志中写入记录
; T的一次write（X）操作导致向日志中写入一条新记录;
最后，被改变的所有数据项已写入磁盘后向日志中写入记录<T, COMMIT>
事务恢复
撤销(Undo($\rm{T}_i$))未完成的事务:将事务$\rm{T_i}$更新的所有数据项的值设为旧值。
简化日志内容结构
日志记录<T，X，V1 >表示：事务Ｔ对数据项Ｘ执行写操作，写前的旧值为V1。
前面介绍的更新日志记录结构可以简化，省去新值字段。
恢复处理步骤
首先对日志文件从后向前进行扫描，将有<T，COMMIT>记录的事务放入redo-list队列;
然后对日志文件从后向前进行扫描;
对遇到的每一个<T，X，V1>记录，若事务T在redo-list队列中，则恢复管理器什么都不做；
对遇到的每一个<T，X，V1>记录，若事务T不在redo-list队列中，则恢复管理器将数据项X在数据库中的值改为旧值V1。
对每个未完成的事务，在日志中写入一个<T,ABORT>记录并刷新日志。
后像前后写
后像在事务提交前后写入数据库
事务T的日志写入执行步骤
在T开始执行前，向日志中写入记录
； T的一次write（X）操作导致向日志中写入一条新记录；
最后，被改变的所有数据项已写入磁盘后向日志中写入记录<T, COMMIT>。
事务恢复
Undo (Ti)：将未提交事务Ti更新的所有数据项的值设为旧值。
Redo (Ti)：将已提交事务Ti更新的所有数据项的值设为新值。
日志内容结构
日志记录<T，X，V1，V2>表示：事务Ｔ对数据项Ｘ执行写操作，写前的旧值为V1，写后的新值为V2
恢复处理步骤
首先对日志文件从后向前进行扫描，将有<T，COMMIT>记录和没有<T，COMMIT>记录的事务分别放入两个队列：redo-list队列，undo-list队列；
从前向后再次扫描日志记录，重新执行redo-list队列中的事务；
从后向前再次扫描日志记录，撤销undo-list队列中的事务。
缓冲区管理
最近最少使用LRU：最久无访问
先进先出FIFO：最早进入缓冲区
最近最少使⽤算法LFU ：最小访问频率
先写日志规则：
在日志记录【Ti commit】写入磁盘之后，才允许事务Ti进入提交状态(写入磁盘);
在日志记录【Ti commit】写入磁盘之前，要保证commit之前的日志记录已经写入磁盘；
主存中的数据块写入磁盘之前，所有与该数据块相关的日志记录必须已写入磁盘；
检查点
提交一致性检查点：所有检查点前执行的事务将已经完成，并且其更新也已经写入磁盘。因此，恢复时这些事务都不需要撤销。在恢复时，系统从日志尾部（上面图的最下面）开始向前扫描，确定未完成的事务，当发现
记录时，表明已找完所有未完成的事务。由于只有检查点结束后事务才能开始，因此没有必要扫描 记录以前的部分。这样，可以大大减少进行恢复操作所需要的时间。 - 提交一致性检查点需要等到所有活动事务提交后才能建立，等待时间可能会很长
高速缓存一致性检查点：所做的任何数据库修改都必然在检查点前或作为检查点的一部分写入数据库
数据转储
- 静态转储
- 在系统无运行事务时进行转储
- 转储开始时数据库处于一致性状态
- 转储期间不允许对数据库的任何存取、修改活动
- 优点：实现简单
- 缺点：降低了数据库的可用性
- 转储必须等用户事务结束
- 新的事物必须等转储结束
- 动态转储
- 转储操作与用户事务并发进行
- 转储期间允许对数据库进行存取或修改
- 优点
- 不用等待正在运行的用户事务结束
- 不会影响新事务的运行
- 缺点
- 不能保证副本中的数据正确有效
- 利用动态转储得到的副本进行故障恢复
- 需要把动态转储期间各事务对数据库的修改活动登记下来，建立日志文件
- 后备副本加上日志文件才能把数据库恢复到某一时刻的正确状态
- 完全转储: 每次转储全部数据库
- 增量转储: 只转储上次转储后更新过的数据
- 完全转储与增量转储比较
- 从恢复角度看，使用完全转储得到的后备副本进行恢复往往更方便
- 但如果数据库很大，事务处理又十分频繁，则增量转储方式更实用更有效
恢复处理
事务故障（含逻辑错误与系统错误）
- 恢复策略：利用日志文件撤销此事务对数据库已经进行做过的修改
- 恢复处理
- 后像后写：恢复管理器忽略这些未完成的事务
- 后像前写与后像前后写：使用日志文件撤销此事务对数据库的修改
系统故障
- 恢复策略：利用日志文件撤销未完成事务，重做已提交事务
- 恢复处理
- 当系统崩溃重新启动时，它构造两个队列：undo-list存放需要撤销的事务标识符，redo-list存放需要重做得事务标识符。
- 这两个队列刚开始时都是空的。
- 队列构造步骤如下
- 系统反向扫描日志，直到发现第一个
记录。 - 对每一个<Ti，COMMIT>记录，将Ti加入redo-list。
- 对每一个<Ti，START>记录，如果Ti不属于redo-list，则将Ti加入undo-list。
- 系统反向扫描日志，直到发现第一个
- 后像后写
- 对undo-list中的事务，在日志中写入一个<Ti，ABORT>记录并刷新日志。
- 对redo-list中的事务执行REDO操作：从前面发现的
记录开始，正向扫描日志文件，对遇到的每一个<Ti，X，V1>记录，将数据库中的X数据项更新为新值V1。
- 后像前写
- 反向扫描undo-list日志文件，对遇到的每一个<Ti，X，V1>记录，将数据库中的X数据项更新为旧值V1，扫描到<Ti，START>记录时，扫描停止。
- 在日志中写入一个<Ti，ABORT>记录并刷新日志。
- 重复上两个步骤，直到处理完撤销队列中的每一个事务。
- 后像前后写
- 系统重新反向扫描日志文件，对undo-list中的每一事务执行UNDO操作，即对遇到的每一个<Ti，X，V1，V2>记录，将数据库中的X数据项更新为旧值V1。
- 在日志中写入一个<Ti，ABORT>记录并刷新日志。当undo-list中所有事务Ti所对应的<Ti，START>记录都找到时，扫描结束。
- 系统找出日志中最后一条
记录。 - 系统由最后一条
记录开始，正向扫描日志文件，对redo-list中的事务Ti的每一个日志记录执行redo操作。即对遇到的每一个<Ti，X，V1，V2>记录，将数据库中的X数据项更新为新值V2。
介质故障
恢复处理
如果有后续的增量转储，按照从前往后的顺序，根据增量转储来修改数据库。
装入最近的完全转储后备副本，若数据库副本是动态转储的，还需要同时装入转储开始时刻的日志文件副本，利用恢复系统故障的方法将数据库恢复到某个一致性状态。
装入转储结束后的日志文件副本，重做已完成的事务。首先反向扫描日志文件，找出故障发生时已经提交的事务，将事务标识符写入redo-list。然后正向扫描日志文件，对redo-list中的所有事务进行redo操作。
数据库安全概述
- 支持自主存取控制（DAC）的DBMS属于C1级；
- 支持审计功能的DBMS属于C2级；
- 支持强制存取控制（MAC）的DBMS则可以达到B1级。
- B2以上的系统标准更多地还处于理论研究阶段，
产品化以至商品化的程度都不高，
其应用也多限于一些特殊的部门如军队等。
DAC（自主访问控制）C1
访问数据的权限
SELECT（读取权限）：允许读数据，但不能修改数据。
例：SELECT（Pname，Paddr）表示只授予用户查询关系表中Pname，Paddr 两个属性中数据的权限，关系表中其他属性的数据对用户是屏蔽的。
lNSERT（插入权限）：允许插入一条新的数据，但不能修改已有数据。
UPDATE（修改权限）：允许修改数据，但不能删除数据。
DELETE（删除权限）：允许删除数据。
修改数据库模式的权限
lndex（索引权限）：允许建立或删除索引。
Create（创建权限）：允许建立新的关系表。
Alter（修改权限）：允许对关系表中的属性进行增加、删除。
Drop（删除权限）：允许删除关系表。
其它权限
REFERENCE权限：允许用户在建立关系的完整性约束中引用一个参照关系
USAGE权限：授权用户使用一个指定的域
TRIGGER权限：授权用户定义关系表中触发器的权利
EXECUTE权限：授予用户执行一个函数或过程的权利
UNDER权限：授权用户建立一给定类的子类
授权
GRANT {all privileges|privilege{. privilege….}}
ON [TABLE] tablename|viewname
TO [PUBLIC|user_name{,user_name…}]
[WITH GRANT OPTION]
ALL PRIVILEGES是所有权限的总称
数据对象可以是基本表，也可以是视图
用户名可以代表单一用户也可以代表一组用户，当代表一组用户时我们称为角色。PUBLIC是所有数据库用户的总称；
WITH GRANT OPTION，受权者可以将此权限转授给其他用户；
一个用户如果是表的创建者，他就自动拥有了对所创建表的所有权利以及将该表权利授予其他用户的权利，而且不能取消。
收回权限格式
REVOKE [GRANT OPTION FOR]{ALL PRIVILEGES|privilege{. Privilege….}}
ON [TABLE] tablename|viewname
FROM [PUBLIC|user_name{,user_name…}]
[RESTRICT|CASCADE]
基于角色的访问控制（RBAC）
创建角色
CRETAE ROLE Admin;
角色授权
GRANT SELECT ON RecipeMaster TO Admin;
角色授予用户或其他角色
GRANT Admin TO LiXia;
CREATE ROLE Manager;
GRANT Admin to Manager;
GRANT Manager TO WangHao;
角色Manager除具有直接赋予它的权限外，还继承了角色Admin具有的权限。
MAC（强制访问控制）B1
保密性规则
仅当主体的许可证级别高于或者等于客体的密级时（只进不出）（Read,Lsubject≥Lobject），该主体才能读取相应的客体。（下读，RD）
仅当主体的许可证级别低于或者等于客体的密级时（Write,Lsubject≤Lobject），该主体才能写相应的客体。（上写，WU）
完整性规则
仅当主体的许可证级别低于或者等于客体的密级时（Read,Lsubject≤Lobject），该主体才能读取相应的客体。（上读，RU）
仅当主体的许可证级别高于或者等于客体的密级时（Write,Lsubject≥Lobject），该主体才能写相应的客体。（下写，WD）
MAC与DAC结合
- DAC与MAC共同构成DBMS的安全机制
- 先进行DAC检查，通过DAC检查的数据对象再由系统进行MAC检查
- 只有通过MAC检查的数据对象方可存取。
审计C2
跟踪审计是一种监视措施，记录了用户对数据库的所有操作。一旦发现问题，系统可自动报警，或根据数据进行事后的分析和调查。
审计操作（ORACLE）
提供AUDIT语句设置审计功能，NOAUDIT语句取消审计功能。
通过DBA_AUDIT_TRAIL视图可以查询审计结果。
审计示例：跟踪用户scott的表RecipeMaster上的所有更新操作
SQL> AUDIT UPDATE on scott.RecipeMaster BY ACCESS;
SQL> NOAUDIT ALL ON RecipeMaster；
完结！SQL详细语法看PPT吧
祝君考试顺利
Double S 2022.5.24