按照上面的框架我们已经讲了关系数据结构还有关系操作，今天来补充这一章的关系完整性约束
关系完整性约束
完整性约束
完整性约束可以保证数据的一致性和元组的唯一性
实体完整性约束
比如在学生表中，每一个元组都应该是唯一并且元组之间是可以区分的，通常通过对主键进行约束。比如主键下的值不能是空值，并且不能有重复的情况。即非空性和唯一性。
违反非空性：
| 用户ID (UserID) | 用户名 (Username) | 邮箱 (Email) |
| 101 | Alice | alice@example.com |
| 102 | Bob | bob@example.com |
| NULL | Eve | eve@example.com |
| 103 | Charlie | charlie@example.com |
下面这个则违反了唯一性：
| 用户ID (UserID) | 用户名 (Username) | 邮箱 (Email) |
| 101 | Alice | alice@example.com |
| 102 | Bob | bob@example.com |
| 101 | Charlie | charlie@example.com |
上面两个关系的主键都是用户ID（UserID）
若主键不单单是一个属性列，而是多个属性列组成的，即复合键，它也同时要满足非空性和唯一性。
例如下面这个就违反了非空性
| 学生ID (StudentID) | 课程ID (CourseID) | 成绩 (Grade) |
| 1 | CS101 | A |
| 2 | MATH202 | B+ |
| NULL | CS101 | B- |
| 3 | NULL | C+ |
| 4 | CS101 | A- |
违反唯一性：
| 学生ID (StudentID) | 课程ID (CourseID) | 成绩 (Grade) |
| 1 | CS101 | A |
| 1 | MATH202 | B+ |
| 2 | CS101 | B |
| 3 | CS101 | A- |
| 1 | CS101 | C+ |
上面两个关系的复合键都是学生ID和课程ID。
在修改数据（包含插入、修改、删除）时若是违反了上述规则，数据库是不会运行该数据操作的，它会选择拒绝，因为在设计数据库时会设置好实体完整性约束，事实上都是为了每一个元组都唯一且彼此之间可区分。
参照完整性约束
这个约束是指主键和外键的对应关系不能出错，比如在在选课表中的外键是学生ID，而学生ID在学生表中是主键，主键和外键要“相等”，“一模一样”。
| 学生ID (StudentID) | 姓名 (Name) |
| 1 | 张三 |
| 2 | 李四 |
| 3 | 王五 |
| 学生ID (StudentID) | 课程ID (CourseID) |
| 1 | CS101 |
| 2 | MATH202 |
| 4 | CS101 |
| 3 | PHYS303 |
比如这个就明显违反了该约束，因为在选课表中出现了学生表没有的学生ID。而且在进行删除操作时，禁止删除主键（被引用），进行插入操作时，主键（被引用）先更新，即不能直接对外键值进行操作，要确保外键值是有效的，就必须是被引用的主键（也叫参照）先进行关系操作。
用户定义完整性约束
之前在说域这个概念时就有提到关系中的每个属性都存在一个取值集合即域，比如学生的年龄是大于等于0的。其实这个就是用户定义完整性约束。主要是体现在数据库的应用场景下，再比如学生表中每一个学生都必须要有性别和年龄信息，Sname 和Sage都不能取空值。
其他约束
非空约束
指某一属性下的值不能是空值，比如特定对Sage属性进行非空约束，那么就不能插入一个年龄为空的学生信息。
唯一约束
也是指对某一属性进行唯一约束，即不能取重复值，但是可以取空值，并且可以对多个属性进行约束，比完整性约束作用范围更大。
自增长约束
某一属性列的值必须满足自增，比如用户ID，学生号（2021210223->2021210224）
默认值约束
比如某一属性列的值默认是空值（NULL）或者0，也可以是其他默认值。
检查约束
某一属性必须满足某一取值范围，比如Sage必须大于等于零。
关系模型就暂告一段落了，接下来学习第三章——数据库设计