简述各种约束对表中数据的作用（数据库应用与开发）

数据库完整性（Database Integrity）是指数据库中数据的正确性和相容性。数据库完整性由各种各样的完整性约束来保证，因此可以说数据库完整性设计就是数据库完整性约束的设计。数据库完整性约束可以通过DBMS或应用程序来实现，基于DBMS的完整性约束作为模式的一部分存入数据库中。通过DBMS实现的数据库完整性按照数据库设计步骤进行设计，而由应用软件实现的数据库完整性则纳入应用软件设计（本文主要讨论前者）。数据库完整性对于数据库应用系统非常关键，其作用主要体现在以下几个方面：

1．数据库完整性约束能够防止合法用户使用数据库时向数据库中添加不合语义的数据。

2．利用基于DBMS的完整性控制机制来实现业务规则，易于定义，容易理解，而且可以降低应用程序的复杂性，提高应用程序的运行效率。同时，基于DBMS的完整性控制机制是集中管理的，因此比应用程序更容易实现数据库的完整性。

3．合理的数据库完整性设计，能够同时兼顾数据库的完整性和系统的效能。比如装载大量数据时，只要在装载之前临时使基于DBMS的数据库完整性约束失效，此后再使其生效，就能保证既不影响数据装载的效率又能保证数据库的完整性。

4．在应用软件的功能测试中，完善的数据库完整性有助于尽早发现应用软件的错误。

数据库完整性约束可分为6类：列级静态约束、元组级静态约束、关系级静态约束、列级动态约束、元组级动态约束、关系级动态约束。动态约束通常由应用软件来实现。不同DBMS支持的数据库完整性基本相同，Oracle支持的基于DBMS的完整性约束如下表所示：

数据库完整性设计示例

一个好的数据库完整性设计首先需要在需求分析阶段确定要通过数据库完整性约束实现的业务规则，然后在充分了解特定DBMS提供的完整性控制机制的基础上，依据整个系统的体系结构和性能要求，遵照数据库设计方法和应用软件设计方法，合理选择每个业务规则的实现方式；最后，认真测试，排除隐含的约束冲突和性能问题。基于DBMS的数据库完整性设计大体分为以下几个阶段：

1．需求分析阶段

经过系统分析员、数据库分析员、用户的共同努力，确定系统模型中应该包含的对象，如人事及工资管理系统中的部门、员工、经理等，以及各种业务规则。

在完成寻找业务规则的工作之后，确定要作为数据库完整性的业务规则，并对业务规则进行分类。其中作为数据库模式一部分的完整性设计按下面的过程进行。而由应用软件来实现的数据库完整性设计将按照软件工程的方法进行。

2．概念结构设计阶段

概念结构设计阶段是将依据需求分析的结果转换成一个独立于具体DBMS的概念模型，即实体关系图（ERD）。在概念结构设计阶段就要开始数据库完整性设计的实质阶段，因为此阶段的实体关系将在逻辑结构设计阶段转化为实体完整性约束和参照完整性约束，到逻辑结构设计阶段将完成设计的主要工作。

3．逻辑结构设计阶段

此阶段就是将概念结构转换为某个DBMS所支持的数据模型，并对其进行优化，包括对关系模型的规范化。此时，依据DBMS提供的完整性约束机制，对尚未加入逻辑结构中的完整性约束列表，逐条选择合适的方式加以实现。

在逻辑结构设计阶段结束时，作为数据库模式一部分的完整性设计也就基本完成了。每种业务规则都可能有好几种实现方式，应该选择对数据库性能影响最小的一种，有时需通过实际测试来决定。

数据库完整性设计原则

在实施数据库完整性设计的时候，有一些基本的原则需要把握：

1．根据数据库完整性约束的类型确定其实现的系统层次和方式，并提前考虑对系统性能的影响。一般情况下，静态约束应尽量包含在数据库模式中，而动态约束由应用程序实现。

2．实体完整性约束、参照完整性约束是关系数据库最重要的完整性约束，在不影响系统关键性能的前提下需尽量应用。用一定的时间和空间来换取系统的易用性是值得的。

3．要慎用目前主流DBMS都支持的触发器功能，一方面由于触发器的性能开销较大，另一方面，触发器的多级触发不好控制，容易发生错误，非用不可时，最好使用Before型语句级触发器。

4．在需求分析阶段就必须制定完整性约束的命名规范，尽量使用有意义的英文单词、缩写词、表名、列名及下划线等组合，使其易于识别和记忆，如：CKC_EMP_REAL_INCOME_EMPLOYEE、PK_EMPLOYEE、CKT_EMPLOYEE。如果使用CASE工具，一般有缺省的规则，可在此基础上修改使用。

5．要根据业务规则对数据库完整性进行细致的测试，以尽早排除隐含的完整性约束间的冲突和对性能的影响。

6．要有专职的数据库设计小组，自始至终负责数据库的分析、设计、测试、实施及早期维护。数据库设计人员不仅负责基于DBMS的数据库完整性约束的设计实现，还要负责对应用软件实现的数据库完整性约束进行审核。

7．应采用合适的CASE工具来降低数据库设计各阶段的工作量。好的CASE工具能够支持整个数据库的生命周期，这将使数据库设计人员的工作效率得到很大提高，同时也容易与用户沟通。

数据完整性（Data Integrity）是指数据的精确性（Accuracy） 和可靠性（Reliability）。它是应防止数据库中存在不符合语义规定的数据和防止因错误信息的输入输出造成无效 *** 作或错误信息而提出的。数据完整性分为四类：实体完整性（Entity Integrity）、域完整

性（Domain Integrity）、参照完整性（Referential Integrity）、用户定义的完整性（User-definedIntegrity）。

数据库采用多种方法来保证数据完整性，包括外键、束约、规则和触发器。系统很好地处理了这四者的关系，并针对不同的具体情况用不同的方法进行，相互交叉使用，相补缺点。

31 SQL 中的完整性约束

SQL把各种完整性约束作为数据库模式定义的一部分。既有效防止了对数据库的意外破坏，提高了完整性检测的效率，又可以减轻编程人员的负担。

SQL对三种不同完整性约束的设置及检测，采取了不同的方式加以实现。下面分别介绍。

311 实体完整性和主码

实体完整性规定，主码的任何属性都不能为空，因为，概念模型中实体和联系都是可区分的，而且它们以码为唯一性标识。如果，主码的属性值可以为空，则意味着在概念模型中存在着不以码为唯一性标识的实体。这显然是前后矛盾的。

那么怎样保证实体完整性呢？SQL中实体完整性是通过主码来实现的。一旦某个属性或属性组被定义为主码，该主码的每个属性就不能为空值，并且在关系中不能出现主码值完全相同的两个元组。

主码的定义是在Create Table 语句中使用 Primary Key关键字来实现的。方法有两种：

a) 在属性定义后加上关键字 Primary Key；

b) 在属性表定义后加上额外的定义主码的子句：Primary Key（<主码属性名表>）

说明：

² 如果主码仅由一个属性组成，上述两种方法都可定义，若由两个或以上的属性组成，则只能用上述第二种方法定义了。

² 对于候选码的说明方法，可以用Unique说明该属性的值不能重复出现。Unique的使用与Primary Key相似。

² 一个表中只能有一个主码定义，但可以有多个Unique说明。

² SQL中，并没有强制为每个关系指定主码，但为每个关系指定主码通常会更好一些。（因为主码的指定可以确保关系的实体完整性）

312 参照完整性约束与外部码

参照完整性是对关系间引用数据的一种限制。即：若属性组A是基本关系R1的外码，它与基本关系R2的主码K相对应，则R1中每个元组在A上的值必须：要么取空值，要么等于R2中某元组的主码值。

一、外部码约束的说明：

SQL中就是利用外部码的说明来实现参照完整性约束，限制表中某些属性的取值的。外部码的说明也有两种方法：

1、在该属性的说明后直接加上关键字”REFERENCES <表名>（<属性名>）”，其中表名称为参照关系名，属性名称为参照关系的主码。

2、在Create Table 语句的属性清单后，加上外部码说明子句，格式为：

FOREIGN KEY <属性名表1> REFERENCES <表名>(<属性名表2>)

上式中的属性名表1和属性名表2中属性可以多于一个，但必须前后对应。

二、参照完整性约束的实现策略

前面讲了，外部码的取值只有两种情况：要么取空，要么取参照关系中的主码值。可是当用户 *** 作违反了这个规则时，如何保持此约束呢？

SQL提供了三种可选方案：

1、RESTRICT(限制策略)：

当用户对表进行违反了上述完整性约束、条件的插入、删除或修改 *** 作时，将会被系统拒绝。

2、CASCADE（级联策略）：

当对参照关系进行删除和修改时，SQL所提供的一种方案。在这种策略下，当删除或修改参照关系中某元组的主码值时，被参照关系中，那些外部码具有该值的元组也将被删除或修改，以保证参照完整性。

3、SET NULL（置空策略）：

置空策略也是针对参照关系的删除或修改 *** 作的。在这种策略下，当删除参照关系中的某一元组或修改某一元组的主码值时，被参照关系中外码值等于该主码值的元组在该外码上的值将被置空

说明：

当用户不指定参照完整性的实现策略时，一般被默认为RESTRICT(限制策略)。实现策略的说明通常被加在外部码的说明后面，格式为：ON DELETE SET NULL ON UPDATE CASCADE。

313 用户自定义完整性约束

对于用户自定义完整性约束，SQL提供了非空约束、对属性的CHECK约束、对元组的CHECK约束、触发器等来实现用户的各种完整性要求。

1、非空约束：

在CRETE TABLE 中的属性定义后面加上NOT NULL关键字即定义了该属性不能取空值。

2、基于属性的CHECK约束

使用CHECK（检查）子句可保证属性值满足某些前提条件。其一般格式为：

CHECK（<条件>）

它既可跟在属性定义的后面，也可在定义语句中另增一子句加以说明。

如：CHECK（age>=18 AND age<=65）;

CHECK（sex IN (“男”,”女”)）;

CHECK（dno IN(select dno from department)）;

从上例中可以看出，CHECK子句的条件中还可以带子查询。

3、基于元组的CHECK约束

基于元组的CHECK约束往往要涉及到表中的多个域。所以它是元组约束。在对整个元组完成插入或对某一元组的修改完成之后，系统将自动检查是否符合CHECK条件表达式。若不符合条件，系统将拒绝该插入或修改 *** 作。

基于元组CHECK约束的说明方法是在CREATE TABLE语句中的属性表、主码、外部码的说明之后加上CHECK子句。

314 约束的更新

约束与数据库中的表和视图一样，可以进行增、删、改的更新 *** 作。为了改和删约束，需要在定义约束时对其进行命名，在各种约束的说明前加上关键字CONSTRAINT 和该约束的名称即可。

例如：在employee表的create table语句中：

eno char(4) CONSTRAINT PK_employee PRIMARY KEY,

dno char(4)CONSTRAINT FK_employee FOREIGN KEY REFERENCES department(dno);

当对各种约束进行命名后，就可以用ALTER TABLE语句来更新与属性或表有关的各种约束。如：

ALTER TABLE employee DROP CONSTRAINT FK_employee;

ALER TABLE Salary ADD CONSTRAINT RightSalary CHECK(Insure+Fund<Rest);

上述的增加约束，实际上也是通过ALTER TABLE语句定义约束的一种形式。

SQL不能直接修改约束，修改某一个约束实际上是用ALTER TABLE 语句先删除该约束，然后再增加一个与该约束同名的新约束。

解答如下：完整性有三类：实体完整性，参照完整性，用户定义完整性。(1)实体完整性：规定基本关系R的主属性A不能取空值，如：Create Table 学生( 学号CHAR(10) PRIMARY KEY, 姓名 CHAR(20), );(2)参照完整性：规定若F是基本关系的外码，它与基本关系S的住吗相对应，则对于R中每一个远足在F上的值必须取空值（F的每一个属性值均为空值），或等于S中某一个远足的主码值。如：Create Table 学生( 学号 CHAR(10) PRIMARY KEY, 姓名 CHAR(20), 课程号 CHAR(10), FOREIGN KEY(课程号)REFERENCES 课程(课程号) );Create 课程( 课程号 CHAR(10) PRIMATY KEY, );(3)用户定义完整性：就是针对某一具体的关系数据库的约束条件，反映某一具体应用所涉及的数据必须满足的语义要求，由应用环境决定，即属性值限定，包括：列值非空(NOT NULL), 列值唯一(UNIQUE),检查列值是否满足一个布尔表达式。如：Create Table 学生_课程( 学号 CHAR(10) NOT NULL, 课程号 CHAR(10) NOTNULL, 成绩 SMALLINT NOT NULL, PRIMARY KEY(学号，课程号)， );

以上就是关于简述各种约束对表中数据的作用（数据库应用与开发）全部的内容，包括:简述各种约束对表中数据的作用（数据库应用与开发）、SQL数据完整性有哪几种，各自作用是什么、关系数据库有哪几种完整性等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！