数据库的完整性_什么是数据库的完整性-CSDN博客

本文链接：https://blog.csdn.net/suoyue_py/article/details/102587691

数据库的完整性： 是指数据的正确性、有效性和相容性。
说明：完整性是为了防止数据库中存在不符合语义的数据，防止错误信息的输入和输出
数据的完整性和安全性是两个不同概念

数据的完整性：

防止数据库中存在不符合语义的数据，也就是防止数据库中存在不正确的数据
防范对象：不合语义的、不正确的数据
数据库完整性约束条件：加在数据库数据之上的语义约束条件。
完整性检查：在DBMS中检查数据是否满足完整性条件的机制。
违约处理：DBMS若发现用户的操作违背了完整性约束条件，采取一定的动作，如拒绝该操作或级联执行其他操作来保证数据的完整性。

DBMS的完整性控制机制应具有三个方面的功能：

（1）定义功能：提供定义完整性约束条件的机制。
（2）检查功能：检查用户发出的操作请求是否违背了完整性约束条件。
（3）防范功能：如果发现用户的操作请求使数据违背了完整性约束条件，采取一定的动作来保证数据的完整性。

完整性的语义约束和检查时机：

（1）立即执行约束：检查是否违背完整性约束的时机通常是在一条语句执行完后立即检查。
（2）延迟执行约束：完整性检查延迟到整个事务执行结束后再进行，检查正确方可提交。
（3）在事务的某些特定检查点检查。
（4）在一个维护操作请求之后且执行之前检查。
（5）在DBA或审计员发出检查请求时。

数据的安全性：

保护数据库防止恶意的破坏和非法的存取
防范对象：非法用户和非法操作

违约处理
如果发现用户的操作请求使数据违背了完整性约束条件，则采取一定的动作来保证数据的完整性。
1）违反实体完整性规则和用户定义的完整性规则的操作：

一般是拒绝执行

2）违反参照完整性的操作：

拒绝执行
接受这个操作，同时执行一些附加的操作，以保证数据库的状态正确

（一）实体完整性

1.实体完整性定义

关系模型的实体完整性：

CREATE  TABLE中用PRIMARY KEY定义

单属性构成的码有两种说明方法：

定义为列级约束条件
定义为表级约束条件

对多个属性构成的码只有一种说明方法：

定义为表级约束条件

2.实体完整性检查和违约处理
插入或对主码列进行更新操作时，DBMS按照实体完整性规则自动进行检查。包括：

检查主码值是否唯一，如果不唯一则拒绝插入或修改。
检查记录中主码值是否唯一的一种方法是进行全表扫描。
检查主码的各个属性是否为空，只要有一个为空就拒绝插入或修改。

（二）参照完整性

若属性组A是基本关系R的外码，它与基本关系S的主码Ks相对应，则R中每个元组在A上的值必须：

要么取空值；
要么等于S中某元组的主码值。

1.参照完整性定义

参照完整性是指在两个表的主键和外键之间数据的完整性，其含义包括：

参照完整性保证被参照表和参照表之间数据的一致性；
可以防止数据丢失或者无意义的数据；
可以禁止从表中插入被参照表中不存在的关键字的记录。

参照完整性的常见实现机制包括：

外键（Foreign Key）
检查（Check）
触发器（Trigger）
存储过程（Stored Procedure）

在输入或删除记录时，可以用来保持所有表之间定义的关系，以确保键值在所有表中一致。
关系模型的参照完整性定义：

在CREATE TABLE中用FOREIGN KEY短语定义哪些列为外码
用REFERENCES短语指明这些外码参照哪些表的主码

2.参照完整性检查和违约处理
在这里插入图片描述
参照完整性违约处理：

拒绝(NO ACTION)执行
默认策略
级联(CASCADE)操作
设置为空值（SET-NULL）
对于参照完整性，除了应该定义外码，还应定义外码列是否允许空值

（三）用户定义的完整性

用户定义的完整性就是针对某一具体应用的数据必须满足的语义要求。
对于用户自定义完整性约束，SQL提供了：

非空约束(NOT NULL)
列值唯一约束(UNIQUE)
对属性的CHECK约束:检查列值是否满足一个表达式
触发器等来实现用户的各种完整性要求

DBMS提供，而不必由应用程序承担

1.属性上的约束条件的定义
CREATE TABLE时定义：

列值非空（NOT NULL）
列值唯一（UNIQUE）
检查列值是否满足一个条件表达式（CHECK）

非空约束：
在CRETE TABLE 中的属性定义后面加上NOT NULL关键字即可。
若在表级定义实体完整性，隐含不允许取空值，则列级不允许取空值的定义就不必写

2.属性上的约束条件检查和违约处理
插入元组或修改属性的值时，DBMS检查属性上的约束条件是否被满足
如果不满足则操作被拒绝执行

3.元组上的约束条件的定义
在CREATE TABLE时可以用CHECK短语定义元组上的约束条件，即元组级的限制。
同属性值限制相比，元组级的限制可以设置不同属性之间的取值的相互约束条件。

4.元组上的约束条件检查和违约处理
插入元组或修改属性的值时，DBMS检查元组上的约束条件是否被满足。
如果不满足则操作被拒绝执行。

（四）完整性约束命名子句

CONSTRAINT 约束：

CONSTRAINT <完整性约束条件名>
［PRIMARY KEY短语
   |FOREIGN KEY短语
   |CHECK短语］

修改表中的完整性限制：
使用ALTER TABLE语句修改表中的完整性限制

（五）触发器

触发器（Trigger）是用户定义在关系表上的一类由事件驱动的特殊过程，又称:事件-条件-动作规则。当特定的系统事件（增删改操作）发生时，对规则的条件进行检查，如果条件成立则执行规则中动作，否则不执行该动作。规则中动作体通常是一段SQL存储过程。

由服务器自动激活
可以进行更为复杂的检查和操作，具有更精细和更强大的数据控制能力

定义触发器
CREATE TRIGGER语法格式：

CREATE TRIGGER <触发器名>  
{BEFORE | AFTER} <触发事件> ON <表名>
FOR EACH  {ROW | STATEMENT}
［WHEN <触发条件>］
<触发动作体>

定义触发器的语法说明:

创建者：表的拥有者
触发器名
表名：触发器的目标表
触发事件：INSERT、DELETE、UPDATE
触发器类型
行级触发器（FOR EACH ROW）
语句级触发器（FOR EACH STATEMENT）
触发条件
触发条件为真
省略WHEN触发条件
触发动作体
触发动作体可以是一个匿名PL/SQL过程块
也可以是对已创建存储过程的调用

激活触发器
触发器的执行，是由触发事件激活的，并由数据库服务器自动执行
一个数据表上可能定义了多个触发器
同一个表上的多个触发器激活时遵循如下的执行顺序：

（1）执行该表上的BEFORE触发器；
（2）执行表上激活触发器的SQL语句（触发事件）；
（3）执行该表上的AFTER触发器。

删除触发器

删除触发器的SQL语法：

DROP TRIGGER <触发器名> ON <表名>;

触发器必须是一个已经创建的触发器，并且只能由具有相应权限的用户删除。