关系数据库理论建立在关系模型之上，而关系模型除了数据结构的定义（二维表）、关系操作（关系代数与关系演算）之外，还有一组至关重要的约束机制，被称为关系的完整性规则。完整性（Integrity）在数据库领域指的是数据库中数据必须满足的语义约束条件，它保证存放在数据库中的数据是正确、有效、相容的。教材中对此的经典表述是：关系模型的完整性规则是对关系的某种约束条件，任何关系在任何时刻都必须满足这些约束，否则关系就不是合法的。
在关系模型中，完整性约束被划分为三大类：实体完整性（Entity Integrity）、参照完整性（Referential Integrity）和用户定义的完整性（User-defined Integrity）。这三类完整性约束构成了关系数据库保证数据质量的第一道防线，也是数据库系统工程师、软件设计师、系统分析师等多个软考科目反复考查的核心知识点。
实体完整性规则规定：若属性（或属性组）是关系的主键，则该属性（或属性组）的取值不能为空，且必须唯一。这里的"空"即NULL，代表未知或不存在；"唯一"意味着主键值不能重复。实体完整性约束的对象是主键，其理论依据在于：主键是关系中元组（记录）的唯一标识，如果主键允许取空值，就无法唯一确定一条记录，也就失去了作为标识符的意义。
参照完整性规则规定：若属性（或属性组）F是关系R的外键，且F与关系S的主键K相对应，则对于R中每个元组，F上的取值要么等于S中某个元组的主键值，要么取空值。参照完整性约束的对象是外键，其本质是维系关系与关系之间的引用（参照）关系，保证一个关系对外部关系的引用是有效的，不会出现"悬空引用"。
用户定义的完整性规则规定：针对某一具体应用场景，用户根据业务语义自行定义的约束条件，它反映的是具体应用所涉及的数据必须满足的语义要求。例如年龄不能为负数、账户余额不能低于某个阈值、性别只能是"男"或"女"等。这类约束由具体应用决定，数据库系统通常通过CHECK约束、NOT NULL约束、UNIQUE约束、DEFAULT默认值、触发器、规则等手段实现。
需要特别强调的是，这三类完整性约束并不是孤立存在的，它们共同构成了关系数据库的数据质量保障体系。实体完整性解决"每条记录是否可被唯一识别"的问题，参照完整性解决"记录之间的引用是否有效"的问题，用户定义完整性解决"记录是否满足业务语义"的问题。
从理论渊源上看，完整性约束的概念是关系模型区别于早期网状模型和层次模型的重要标志之一。在关系数据库诞生之前，数据的约束往往分散在应用程序代码中，由程序员在每次数据操作时自行判断维护，这种方式容易遗漏，在多个应用共享同一数据库时也难以保证约束的一致性。关系模型之父科德（E. F. Codd）在提出关系模型时，就把完整性规则作为模型本身的组成部分，主张把约束从应用程序中剥离出来，由数据库管理系统统一负责实施。这一思想奠定了现代数据库"数据约束集中管理"的基本原则，也是软考命题中经常隐含考查的理论背景。
还应当辨析"完整性约束"与"安全性"这两个容易被混为一谈的概念。完整性约束关注的是数据的正确性、有效性和相容性，防止不合法、不合语义的数据进入数据库；而安全性关注的是防止非法用户对数据的非法访问和破坏。二者的防护对象不同：完整性防护的是"错误的数据"，安全性防护的是"非法的访问"。虽然两者都涉及数据库的保护机制，但在软考选择题中，命题人常把"防止非法访问"之类的选项混入完整性相关题目中，考生需准确把握二者的边界。
实体完整性约束背后对应的是关系模型中的"键"（Key）理论。在关系数据库中，能够唯一标识关系中元组的属性或属性组被称为候选键（Candidate Key），从候选键中选定的一个作为主键（Primary Key），主键之外的候选键称为备用键或候选键的其余部分。主键所包含的属性被称为主属性，不包含在任何候选键中的属性被称为非主属性。
实体完整性要求主键不能取空值且唯一，其根本原因可以从两个层面理解。第一层面是元组标识的唯一性：关系是一个元组的集合，集合中的元素应当是可区分的，而主键就是区分元组的标识符，如果标识符本身不确定（为空）或重复，元组之间就无法相互区分。第二层面是现实世界的实体可区分性：关系模型中的每个元组对应现实世界中的一个实体，现实世界中的实体都是可区分的，这种可区分性在关系模型中就体现为主键的唯一性。
参照完整性约束处理的是关系与关系之间的引用关系。在关系模型中，关系与关系之间的关联通过外键（Foreign Key）来建立。外键是指关系R中的一个属性或属性组，它不是R的主键，但它与另一个关系S的主键相对应，用来表示R中的元组对S中元组的引用。
参照完整性的核心语义是"引用有效"。当关系R中的某个元组通过外键引用了关系S中的某个元组时，被引用的元组必须真实存在，否则这个引用就是无效的、悬空的。具体到取值层面，参照完整性允许外键取两种值：一种是与被参照关系中某个元组的主键值相等，表示确实引用了某条真实存在的记录；另一种是空值NULL，表示该元组没有引用任何外部记录，即"不参与引用"。这两种取值之外的任何值都是非法的。
在数据库的实现层面，参照完整性通常通过外键约束（FOREIGN KEY ... REFERENCES ...）来强制实施。当用户试图插入或更新一条外键值不合法的记录时，数据库系统会拒绝该操作并报错。同时，当用户试图删除或更新被参照关系中的主键值时，数据库系统会根据设定的引用动作（如级联删除CASCADE、置空SET NULL、限制RESTRICT/NO ACTION）来决定如何处理引用该主键的外键记录，以维持参照完整性的成立。
用户定义的完整性约束是三类完整性约束中最灵活的一类，它没有统一的、固定的规则形式，而是由具体的应用语义来决定。它的实现机制在数据库系统中对应着一组丰富的约束设施，包括列级约束和表级约束。
列级约束包括NOT NULL（非空约束）、UNIQUE（唯一约束）、CHECK（检查约束）、DEFAULT（默认值约束）等。NOT NULL要求某列不允许取空值；UNIQUE要求某列取值唯一；CHECK要求某列的取值必须满足给定的逻辑条件表达式，例如"余额 >= 100"；DEFAULT为某列指定默认值，插入时未显式提供该列的值则自动采用默认值。
表级约束主要体现为CHECK约束在表级别的运用（可以引用同一表中的多个列）、触发器（Trigger）以及更复杂的业务规则。触发器是一种特殊的存储过程，当对表执行INSERT、UPDATE、DELETE等操作时自动触发执行，可用来实现跨表、跨行的复杂完整性检查，例如"当一个会员的消费总额达到阈值时自动升级会员等级"这类规则。
用户定义完整性之所以重要，是因为实体完整性和参照完整性只能保证数据在"结构"层面是合法的，而无法保证数据在"语义"层面是正确的。例如，实体完整性保证每条会员记录都有唯一的主键，参照完整性保证会员的消费记录引用的会员确实存在，但它们都无法保证会员的"账户余额"这个字段的取值是合理的（比如不小于100），这个业务语义就需要用户定义的完整性约束来承担。
从约束的检查时机来看，三类完整性约束都遵循"即时检查"的原则。数据库系统在每次执行INSERT、UPDATE、DELETE等数据操作之后，都会立即触发相应约束的检查，若发现违反约束，则回滚该操作并报错。这种即时性保证了数据库在任何时刻都处于满足完整性约束的合法状态。
另外需要理解约束的实施代价。完整性约束虽然保证了数据质量，但也带来了额外的系统开销，每一条约束在被检查时都要消耗计算资源。因此，在实际数据库设计中，需要在数据质量与系统性能之间取得平衡，约束并非越多越好，冗余的约束会拖慢数据操作的速度。理解这一代价，有助于考生在"约束越多越好"这类判断题中保持清醒。
三类完整性约束在具体的数据库设计和应用中各有其适用场景和边界条件，理解这些场景和边界，是软考解题的关键。
实体完整性的应用场景是所有关系都必须满足的基础约束。任何一个关系都必须确定其主键，并保证主键非空且唯一。这里的边界条件值得注意：实体完整性针对的是主键（或候选键），而不是任意属性；对于非主属性，实体完整性并不要求其非空或唯一。此外，当主键是复合主键（由多个属性组成）时，实体完整性要求的是整个属性组非空且唯一，即属性组中的任何一个属性都不能取空值，且属性组的整体取值不能重复，而非要求每个属性单独唯一。
参照完整性的应用场景是所有存在关联的关系。边界条件包括：外键可以取空值（表示不参与引用），也可以取被参照关系主键的现有值；外键所参照的必须是另一个关系的主键（或候选键），而不能是任意属性；一个关系可以有多个外键，分别参照不同的关系；外键也可以参照本关系自身的主键，构成自引用关系（如员工表中"上级编号"参照本表的"员工编号"）。在复合外键的情况下，外键的属性个数和顺序必须与被参照主键保持一致。
用户定义完整性的应用场景最为广泛，凡是业务语义能够明确描述的约束都可以归入此类。其边界条件在于：用户定义完整性是与具体应用紧密绑定的，同样的数据结构在不同应用中的约束可能完全不同。例如同样是"年龄"字段，在学籍管理系统中可能要求"6到18岁"，在职工管理系统中可能要求"16到65岁"，这就是用户定义完整性随应用而异的典型体现。
此外，还需要厘清三类完整性约束与SQL语言中具体约束子句之间的对应关系。在SQL中，PRIMARY KEY子句实现实体完整性，FOREIG
本篇完！