这里写目录标题
5. 数据库完整性
数据库的正确性
- 是指数据是符合现实世界语义,反映了当前实际状况的。
例如:
- 学生的学号必须唯一
- 性别只能是男或女
- 成绩的取值范围为0~100
数据库的相容性
- 是指数据库同一对象在不通关系表中的数据是符合逻辑的
例如:
- 学生所选的课程必须是学校开设的课程
- 学生所在的院系必须是学校已成立的院系
完整性和安全性是两个不同概念
完整性是阻止合法用户通过合法操作向数据库中加入不正确的数据。
安全性防范的是非法用户和非法操作存取数据库中的正确数据。
- 提供定义完整性约束条件的机制
- 完整性约束条件也成为完整性规则,是数据库中的数据必须满足的语义约束条件。
- SQL标准使用了一系列概念来描述完整性,包括关系模型的实体完整性、参照完整性和用户定义完整性
- 这些完整性一般由SQL的数据定义语言语句来实现。
- 提供完整性检查机制
- 数据库管理系统中检查数据是否满足完整性约束条件的机制称为完整性检查。
- 一般在INSERT\UPDATE\DELETE语句执行后开始检查,也可以在事务提交时检查
- 违约处理
- 数据库管理系统若发现用户的操作违背了完整性约束条件就采取一定的动作
- 拒绝(NO ACTION)执行该操作。
- 级练(CASCADE)执行其他操作。
5.1 实体完整性
实体完整性定义
- CREATE TABLE 中用PRIMARY KEY定义
单属性构成的码有两种说明方法 - 定义为列级约束条件
- 定义为表级约束条件
(1)在列级定义主码
CREATE TABLE Student
( Sno CHAR(9) PRIMARY KEY,
//定义列时定义主码
Sname CHAR(20) NOT NULL,
Ssex CHAR(2),
Sage SMALLINT,
Sdept CHAR(20)
);
(2)
CREATE TABLE Student
( Sno CHAR(9),
Sname CHAR(20) NOT NULL,
Ssex CHAR(2),
Sage SMALLINT,
Sdept CHAR(20)
PRIMARY KEY (Sno)
);
CREATE TABLE SC
( Sno CHAR(9) NOT NULL,
Cno CHAR(4) NOT NULL,
Grade SMALLINT,
PRIMARY KEY(Sno, Cno)
//只能在表级定义主码
实体完整性检查和违约处理
插入或对主码列进行更新操作时,关系数据库管理系统按照实体完整性规则自动进行检查。
- 检查主码值是否唯一,如果不唯一则拒绝插入或修改
- 检查主码的各个属性是否为空,只要有一个为空就拒绝插入或修改。
检查主码是否唯一
——进行全表扫描。
- 表扫描缺点
- 十分耗时
- 为避免对基本表进行全表扫描,RDBMS核心一般都在主码上自动建立一个索引。
5.2 参照完整性
参照完整性规则
例:学生关系的“专业号”是外码,它参照专业关系的主码“专业号”
学生关系中每个元组的“专业号”属性只取两类值:
(1)空值,表示该学生尚未确定专业
(2)非空值,这是该值必须是专业关系中某个元组的“专业号”值,表示该学生不可能属于一个不存在的专业。
参照完整性检查和违约处理
DBMS什么时候进行参照完整性的检查?
- 一个参照完整性将两个表中的相应元素联系起来
- 对被参照表和参照表进行增删改操作时有可能破坏参照完整性,必须进行检查
违约例子
违约处理
违约处理类型
- 拒绝(NO ACTION)执行
不允许该操作执行。该策略一般设置为默认策略。 - 级联(CASCADE)操作
当删除或修改被参照表(Student)的一个元组造成了与参照表(SC)的不一致,则删除或修改参照表中的所有造成不一致的元组。 - 设置为空值(SET-NULL)
当删除或修改被参照表的一个元组时造成了不一致,则将参照表中的所有造成不一致的元组的对应属性设置为空值。
5.3 用户定义的完整性
5.4 完整性约束命名字句
CONSTRAINT <完整性约束条件名><完整性约束条件>
完整性约束条件:NOT NULL
, UNIQUE
, PRIMARY KEY
, FOREIGN KEY
, CHECK
短语等。
例子:
ALTER TABLE语句修改表中的完整性限制
去掉例5.10Student表中对性别的限制。
ALTER TABLE Student
DROP CONSTRAINT C4;
修改表Student中的约束条件,要求学号改为在900000~999999之间,年龄由小于30改为小于40
ALTER TABLE Student
DROP CONSTRAINT C1;
//先删除原来的约束条件,再增加新的约束条件
ALTER TABLE Student
ADD CONSTRAINT C1 CHECK (Sno BETWEEN 900000 AND 999999);
ALTER TABLE Student
DROP CONSTRAINT C3;
ALTER TABLE Student
ADD CONSTRAINT C3 CHECK( Sage<40 );
5.5 断言
CREATE ASSERTION
可以定义涉及多个表的或聚集操作的比较复杂的完整性约束。
断言创建以后,任何对断言中所涉及的关系的操作都会触发关系数据库管理系统对断言的检查,任何使断言不为真值的操作都会被拒绝执行。
- 创建断言的语句格式
CREATE ASSERTION <断言名><CHECK子句>
- 每个断言都被赋予一个名字
- <CHECK子句>中的约束条件与WHERE子句的条件表达式类似。
5.6 触发器
定义触发器
GREATE TRIGGER<触发器名>
{BEFORE|AFTER}<触发事件>ON<表名>
REFERENCING NEW|OLD ROW AS<变量>
FOR EACH {
ROW|STATEMENT}
[WHEN<触发条件>]<触发动作体>
-
触发器只能定义在基本表上,不能定义在视图上
-
当基本表的数据发生变化时,将激活定义在该表上相应触发事件的触发器。
-
触发器名和表名必须在同一模式下
-
AFTER/BEFORE是触发的时机
- AFTER表示在触发事件的操作执行之后激活触发器
- BEFORE表示在触发事件的操作执行之前激活触发器
触发器类型
- 行级触发器
- 语句级触发器
在TEACHER表上创建一个AFTER UPDATE触发器,触发事件是UPDATE语句:
UPDATE TEACHER SET Deptno = 5;
假设表TEACHER有1000行
-
如果是语句级触发器,那么执行完该语句后,触发动作只发生一次
-
如果是行级触发器,触发动作将执行1000次
-
触发器被激活时,只有当触发条件为真时出发动作体才执行;否则触发动作体不执行。
-
如果省略WHEN触发条件,则触发动作体在触发器激活后立刻执行。
当特定的系统事件发生时,对规则的条件进行检查,如果条件成立则执行规则中的动作,否则不执行该动作。规则中的动作体可以很复杂,通常是一段SQL存储过程。
触发器又叫做事件-条件-动作(event-condition-action)规则。
- 触发器的执行,是由触发事件激活的,并由数据库服务器自动执行
- 一个数据表上可能定义了多个触发器,遵循如下的执行顺序:
(1)执行该表上的BEFORE触发器;
(2)激活触发器的SQL语句;
(3)执行该表上的AFTER触发器。
删除触发器
DROP TRIGGER <触发器名> ON <表名>
触发器必须是一个已经创建的触发器,并且只能由具有相应权限的用户删除。