数据库期末复习后四章

第8章 数据库的安全与完整性约束

 

8.1  数据库的安全

8.1.1  何谓数据库的安全
8.1.2  DBMS的安全机制

视图机制

为不同的用户定义不同的视图，可以限制各个用户的访问范围
用户标识与鉴别（User Identification &  Verification）

存取控制（Access Control）

授权(Authorization): 对用户存取权限的定义
    集中式授权：由DBA统一定义和管理。
    分散式授权：由DBA及授权的用户分散定义和管理
证实(Authentication)：在查询处理时由DBMS统一实施权限检查。只有检查“通过”才能执行相应的操作。
特权(Privilege): 执行一种特殊类型的SQL语句或存取(另一用户的)模式对象的权力。
    系统特权(System Privilege)

ALTER ANY TABLE －允许被授权者修改任何模式中的任何表/视图的定义。

CREATE TABLE －允许被授权者在自己模式中创建表。

GRANT ANT PRIVILEGE－允许被授权者将任何系统特权授给其他用户。

    对象特权(Object Privilege)

SELECT ON emp －允许被授权者在emp表上查询数据。

DELETE ON emp －允许被授权者在emp表上删除数据。

UPDATE (ename, sal ) ON emp －允许被授权者在emp表的ename列、sal列上更新数据。

角色(Role)
一组特权集合的一个命名，可授予其他角色/用户。
可通过对角色的授权和回收操作来达到对具有该角色的用户的授权功能。
系统总是预定义了一些例行的角色；DBA或授权用户也可以创建其他角色。
系统提供的与角色有关的操作

• 创建、删除、修改功能
• 将某个权限授给一个角色
• 从一个角色那里回收某个权限
• 将某个角色授给一个用户
• 从一个用户那里回收某个角色

授权的SQL DDL / DCL语句

创建角色:  CREATE  ROLE  角色名…;

删除角色:  DROP  ROLE  角色名;

授予系统特权

GRANT  系统特权名/角色名… TO  用户名/角色名…;

收回系统特权:

REVOKE  系统特权名/角色名…  FROM  用户名/角色名… ;

授予对象特权

GRANT  对象特权名… ON  对象标识  TO  用户名/角色名…;

收回对象特权:

REVOKE 对象特权名…ON  对象标识  FROM 用户名/角色名… ;

审计（Audit）

对选定的用户动作进行监控和记录。
数据加密（Data Encryption）

数据加密存储/传输。DBMS必须支持数据加密/解密

8.2  完整性约束

8.2.1  完整性约束及其类型

完整性约束的实现措施

• 完整性约束条件的定义及检查
• 触发器
• 并发控制技术

完整性约束条件的类型
静态约束(Static Constraints)：对DB状态的约束。
固有约束(Inherent Constraints)：指数据模型固有的约束。e.g. 关系数据模型中的1NF条件，etc.
隐含约束(Implicit Constraints)：指隐含在数据模式中的约束，通常需用DDL来申明，约束的定义存于DD中。对关系模型来说，包括：

•   域完整性约束(Domain Integrity Constraints)：属性值应在域中取值、属性值是否可为NULL
•   实体完整性约束(Entity Integrity Constraints)：每个关系必须有一个键，每个元组的键值应唯一，且不能为NULL。在SQL实现时，可为每个关系选定一个主键（PK）。
•   引用完整性约束(Referential Integrity Constraints)：一个关系中的FK值必须引用（另一个关系或本关系中）实际存在的PK值，否则只能取NULL。

显式约束(Explicit Constraints) 

动态约束

8.2.2  完整性约束的SQL实现

RDBMS实现完整性约束的各种机制 

机  制			实现的完整性约束		说  明
在 基 表 定 义 中	数据类型(+规则)		域完整性约束		SQL2 / SQL:1999标准；除ASSERTION外，大型商用RDBMS大多已实现。
	NOT NULL
	UNIQUE		实体完整性约束
	PRIMARY KEY
	FOREIGN KEY		引用完整性约束
	CHECK	基于属性	属性层	显式完整性约束
		基于元组	元组层
用断言	ASSERTION		关系层
用触发器	TRIGGER		动态完整性约束		SQL:1999标准；大多已实现。

用断言说明的约束

定义断言
 CREATE  ASSERTION  <name>  CHECK( <condition> );
撤消断言
 DROP  ASSERTION  <assertion-name-list>;

断言实际上定义了一种通用的约束(General Constraints)，从这种意义上说，前述的域完整性约束、引用完整性约束和CHECK约束是特殊类型的断言

用触发器说明的约束

第9章 触发器与主动数据库系统 

9.1  主动数据库系统

实现主动数据库系统的基本方法

规则(Rule)机制有时也称规则系统(Rules System)
当前，主动数据库系统的主要规则
条件－动作规则 (Condition-Action rule, CA rule) 
事件－条件－动作规则 (Event-Condition-Action rule, ECA rule)
ECA规则也称触发器(Trigger)

9.2  ECA规则

触发器类型
		Each ROW	Each STATEMENT
当“条件”满足时，“动作”的执行时刻/方式	BEFORE	行(层、事件)前触发器	语句前触发器
	AFTER	行后触发器	语句后触发器
	INSTEAD OF	行替代触发器	语句替代触发器

“事件”：SQL操纵语句(INSERT, DELETE, UPDATE)
“动作”执行频度
Each ROW：对“事件”导致的每个“行”操纵，“动作”执行一次。
Each STATEMENT：对整个“事件”，“动作”执行一次。
“动作”执行时刻/方式
BEFORE：“动作”在“事件”前执行。
AFTER：“动作”在“事件”后执行。
INSTEAD OF：“动作”替代“事件”而执行(“事件”语句不执行)。（SQL:1999中没有INSTEAD OF触发器，ORACLE系统中支持此种触发器） 

 <触发器定义> ::= CREATE TRIGGER <触发器名>                               

                              {BEFORE∣AFTER} <事件> ON <表名>

                               [REFERENCING

                              OLD {ROW∣TABLE} AS <过渡行/表标识符>, 

                              NEW {ROW∣TABLE} AS <过渡行/表标识符>] 

                              FOR EACH {ROW∣STATEMENT}

                                [WHEN <条件>]     <动作>;

<事件>::= INSERT∣DELETE∣UPDATE [OF <属性表>]

<条件>::= <SQL谓词>

<动作>::= <SQL DML语句>∣

                  BEGIN <SQL DML语句>[; <SQL DML语句>]… END

触发器/ECA规则定义作为模式对象存放数据字典中。

注触发器/ECA规则可暂停(用DEACTIVE TRIGGER语句)、复活(用ACTIVE TRIGGER语句)、撤消(用DROP TRIGGER语句)。 
 

对于UPDATE操作，既有旧值，又有新值。对于INSERT操作，只有新值，没有旧值。对于DELETE操作，只有旧值，没有新值。

9.3  触发器的应用

完整性约束的维护
是触发器的主要应用！
导出数据(Derived Data)实时更新
如：实视图(Materialized View)刷新
数据库多副本一致性的维护 

第10章 数据依赖与关系模式规范化

“不好的” 关系模式

• 数据冗余度
• 元组插入操作
• 元组删除操作
• 元组更新操作

好的设计方案应该是：既具有合理的数据冗余度，又没有插入和删除等异常现象的出现。

数据依赖
是通过一个关系中属性间值的相等与否体现出来的数据间的相互关系，是现实世界属性间相互联系的抽象，是语义的体现。

由于在关系模式R中存在某些数据依赖，引起数据冗余和数据更新异常。解决方法：通过分解关系模式来消除其中不合适的数据依赖，即关系规范化。

如何设计“好的”关系模式 

规范化(Normalization)
模式分解的条件 / 准则
起码：分解是无损的(Lossless)
理想：分解是保持依赖的(Preserving Dependencies)

范式(Normal Form)
规范化(即模式分解)程度的一种测度

• 第一范式(1NF)
• 第二范式(2NF)                   函数依赖(FD)范畴  √
• 第三范式(3NF)
• Boyce-Codd 范式(BCNF)
• 第四范式(4NF)                   多值函数依赖(MVD)范畴
• 第五范式(5NF)                   连接依赖(JD)范畴

函数依赖（FD – Functional Dependency）

多值依赖（MVD – Multi-Valued Dependency）

权衡：规范化 & 性能 

规范化程度并非越高越好

对更新频繁/查询较少的表：规范化高  ------减少“异常”
对查询频繁/更新较少的表：规范化低  ------提高“性能” 

函数依赖与范式

函数依赖

在一个关系模式R(U)中，如果一部分属性Y的取值依赖于另一部分属性X的取值，则在属性集X和属性集Y之间存在着一种数据依赖关系，我们称之为函数依赖。
定义：函数依赖 / 决定子(Determinant)

设有关系模式R，其中U是属性集，A、B是U的子集。若对于关系模式R(U)的任一关系实例 r 中的任两个元组 t 和s，

t [A] = s [A]   ——>   t [B] = s [B] 成立，

则称B函数依赖于A或A函数决定B，记为：A -> B。A称为决定子。

函数依赖是语义范畴上的概念，只有根据属性间固有的语义联系才能归纳出与客观事实相符合的函数依赖关系，而不是仅从现有的一个或若干个关系实例中得出的结论。
特定的关系实例虽然不能用于函数依赖的发现，但可以用于否定某些函数依赖。

定义：平凡依赖 / 非平凡依赖 / 完全非平凡依赖
设A, B是某模式的两个属性集，对函数依赖A->B，
若B  A，则称此函数依赖为平凡依赖(Trivial Dependency);
若B – A≠Ф，则称此函数依赖为非平凡依赖(Nontrivial Dependency);
若B∩A = Ф，则称此函数依赖为完全非平凡依赖(Completely Nontrivial Dependency)。 
 

对于任一关系模式，平凡函数依赖都是必然成立的，它不反映新的语义，因此若不特别声明， 我们总是讨论非平凡函数依赖。

传递依赖

A->B,B->C  =>    A->C

范式

定义: 1NF
设有一个关系模式R, 若R的任一关系实例r中的属性值均是原子数据(属性都是不可分的基本数据项), 则称R属于1NF，记为R∈1NF。
定义: 2NF
设有一个关系模式R∈1NF, 若R的每个非主属性均完全函数依赖于键, 则称R属于2NF，记为R∈2NF。
定义: 3NF
设有一个关系模式R∈1NF，若R的任一非平凡函数依赖X->A满足下列两个条件之一: (1) X是超键, (2)A是主属性，则称R属于3NF，记为R∈3NF。

3NF是从1NF消除非主属性对键对部分函数依赖和传递函数依赖而得到的关系模式。

定义: BCNF
设有一个关系模式R∈1NF，若R的任一非平凡函数依赖X->A满足下列条件：决定子X必是超键，则称R属于BCNF，记为R∈BCNF。

• BCNF消除了(非主/主)属性对键的部分依赖和传递依赖。
• 关系模式达到BCNF后，在函数依赖范畴内已彻底规范化了，并消除了冗余和异常。 
• 任何全键关系模式必属于BCNF 
• 任何两属性关系模式必属于BCNF
• 关系模式无损分解成BCNF的策略  

   1NF
    ↓  消除非主属性对键的部分函数依赖
   2NF
    ↓  消除非主属性对键的传递函数依赖
   3NF
    ↓  消除主属性对键部分和传递函数依赖
   BCNF 

模式分解理论 

逻辑蕴涵

设一关系模式R(U,F)，其中U为R的属性集，F为R的函数依赖集，若对任意的r∈R，函数依赖 X  ->  Y在r上实际是成立的，则此时称F逻辑蕴涵X  ->  Y。记为F |= X     Y。

第十一章 数据库设计

数据库设计的基本过程

• 需求分析
• 概念设计
• 逻辑设计
• 物理设计

需求分析：提交成果
需求规格说明
元数据库

概念设计
任务：对数据实体及其联系进行概念建模
技术：实体联系（ER）建模或UML类图建模
方法：
集中式模式设计法
视图集成法

逻辑设计
任务：设计数据库的逻辑（概念）模式和外模式
技术：ER模式向关系模式的转换
          关系模式规范化
          模式的调整
          外模式设计

ER向关系转换
实体/属性——>关系模式/含属性
联系/属性——>联系根据一定的规则、通过键引用（FK->PK）置于参与联系的某个实体所对应的关系模式中/含属性或单独的关系模式/含属性

模式的调整
为改善DB性能的调整：
减少连接运算
减少表的大小
尽量使用快照