企业官网建设流程全解析

简介：《数据库实验四.docx》是一份面向数据库课程实验的完整作业文档，聚焦关系数据库的完整性约束与T-SQL语句操作，适合正在学习数据库原理、需要完成类似实验任务的高校学生参考。文档以实验四为载体，系统演示了主键与唯一约束的创建和删除、主表与从表间引用完整性的影响测试，以及级联引用设置，并通过将部门代号“00101”改为“00108”、工号“000002”改为“000020”等操作，记录了冲突提示和验证结果，帮助读者理解违反参照完整性时的失败原因。此外还包括多道思考题及课外任务的探究，对外键级联更新失败的处理思路进行了剖析。资源共包含1个docx文件，压缩包大小711KB，内容结构清晰，可直接作为实验报告模板或复习资料。目前已有343人学习下载，适合数据库初学者借以厘清主键、外键、唯一约束和级联操作的实际应用细节。

1. 数据库实验四：用 T-SQL 把完整性约束一次测透

做数据库课程实验，最怕的不是写不出 SQL，而是明明语句没错，却被一大堆约束冲突的报错弹回来。这次要拆的实验四，核心就是用 T-SQL 实操主键、唯一约束、引用完整性和级联引用，场景是经典的 dept、person、pay 三张表。很多人卡在同一个地方：外键约束一冲突，系统报一长串REFERENCE 约束 "FK__person__DeptNo__2B0A656D" 冲突，看着像乱码，根本不知道错在哪。其实这套报错是有明确规律的，实验做一遍，比背十页理论都管用。这份资源适合正在做数据库课设、或者想补约束实操的读者，内容不啰嗦，直接对着表结构和语句来。

2. 先动手把主键和唯一约束搞明白：pay 与 dept 两张表的 T-SQL 写法

2.1 联合主键的创建与删除：为什么从单列变成了三列

实验的第一个任务，是把表pay的No、Year、Month三列联合定义为主键。这个设计意图需要先理解：pay表存的是工资发放记录，同一个工号（No）会在不同年份、不同月份重复出现，单靠No根本没法唯一标识一条记录。只有No + Year + Month三者组合在一起，才能确定“某个人某年某月的工资记录”。

创建联合主键的常用做法是：

ALTER TABLE pay ADD CONSTRAINT PK_pay PRIMARY KEY (No, Year, Month);

这里的逻辑很直接：给表pay添加一个名为PK_pay的主键约束，括号里列出构成主键的三个列。约束名的命名规范我一般习惯用PK_表名的格式，方便后续删除或排查时一眼认出。

执行成功后，你可以用sp_helpconstraint 'pay'查看表的约束信息，能看到PK_pay的类型是PRIMARY KEY，约束列是No, Year, Month三列。

删除主键的对应语句是：

ALTER TABLE pay DROP CONSTRAINT PK_pay;

这里有个容易踩的细节：如果当初建表时没显式指定约束名，系统会自动生成一个类似PK__pay__xxxx的名字，删除时得先用系统视图查出来，不能凭感觉写。我一般会用这条语句查：

SELECT name FROM sys.key_constraints WHERE parent_object_id = OBJECT_ID('pay') AND type = 'PK';

查到系统生成的约束名后再执行DROP CONSTRAINT，否则会报“找不到对象”的错误。

2.2 唯一约束的创建与删除：和主键的边界在哪里

第二个任务是把dept表部门名称列上的唯一约束删除。这个任务的价值在于搞清楚唯一约束和主键的异同：两者都要求列值唯一，但唯一约束允许一个NULL值，而且一个表可以建多个唯一约束，主键则只允许一个。

创建唯一约束的 T-SQL 写法是：

ALTER TABLE dept ADD CONSTRAINT UK_DeptName UNIQUE (DepartmentName);

我习惯用UK_列名来命名唯一约束，和PK区分开。如果实验环境里dept表已经存在这个约束，直接删除即可：

ALTER TABLE dept DROP CONSTRAINT UK_DeptName;

但这里有一个很重要的实操问题：如果dept表里已经存在两条相同的部门名称，那么创建唯一约束这一步就会直接失败，报UNIQUE KEY冲突。这是实验中不会明说、但实际很容易遇见的坑。我一般会先查一下列里有没有重复值：

SELECT DepartmentName, COUNT(*) FROM dept GROUP BY DepartmentName HAVING COUNT(*) > 1;

如果查出有重复数据，要么清理数据，要么这个唯一约束本来就建不上。删除约束则不存在这个问题——只要约束存在就能删掉。实验里要求“删除”而不是“创建”，大概率是表里已经预置了这个约束，省去了处理脏数据的环节。

2.3 验证约束是否生效：两个查询习惯建议保留

每做完一个约束操作，不要直接进下一步，先用系统视图确认一下。我的固定操作是：

SELECT name, type_desc FROM sys.objects WHERE parent_object_id = OBJECT_ID('pay') AND type IN ('PK', 'UQ'); SELECT name, type_desc FROM sys.objects WHERE parent_object_id = OBJECT_ID('dept') AND type = 'UQ';

这样能清楚看到pay表上还有没有主键、dept表上还有没有唯一约束。很多同学做完删除操作后没验证，后面实验步骤全乱套，就是因为旧约束还残留在表结构里，新语句一直被拦。

验证这一步不算复杂，但能省下后面排查问题的不少时间。

3. 测试引用完整性：更新 dept 主表的那条经典报错

3.1 实验场景里主表与从表是怎么定义的

引用完整性的核心是外键关系。在这套实验里，dept（部门表）是主表，person（人员表）是从表，person表里有一个DeptNo字段引用dept表的部门代号。换句话说，person里的每个人必须属于一个真实存在的部门，不能凭空挂到一个不存在的部门代号上。

这个约束关系是通过建表语句或ALTER TABLE语句添加外键来实现的。实验中执行更新操作时，系统报错信息里的REFERENCE 约束 "FK__person__DeptNo__2B0A656D"，实际上就是 SQL Server 自动为person表生成的默认外键约束名。

它的命名规则不算复杂，但一眼看去确实容易懵。

3.2 把 '00101' 改成 '00108'：UPDATE 与 REFERENCE 约束冲突的完整解码

实验的第三个任务是这样的：执行下面这条更新语句，把部门代号从00101改成00108。

UPDATE dept SET DeptNo = '00108' WHERE DeptNo = '00101';

正常情况下，这条语句会执行失败，报错的核心内容如下：

UPDATE 语句与 REFERENCE 约束 "FK__person__DeptNo__2B0A656D" 冲突。

现在我解释一下这个报错是怎么来的。person表里有几行记录的DeptNo是00101，这些记录通过外键约束引用了dept表。现在你要把dept表里的这个部门代号改成00108，数据库需要检查：如果dept表改了，person表里那几行指向00101的记录是不是就断了？是的，它们失去了参照对象。数据库拒绝执行这个操作，并不是因为它不知道你要做什么，而是因为在默认的NO ACTION规则下，主表的更新会破坏从表数据的参照完整性。

这里有一个非常关键的概念区分：外键约束本身并不“反对”主表更新——它反对的是“会让从表失效”的更新。理解了这个底层逻辑，就不会对报错感到莫名其妙。

3.3 为什么 update 后查询 person 你会看到“双重结果”

我自己的血泪经验：主表dept更新失败后，很多人会不死心，再去查一遍person表，看DeptNo是不是已经被改了。

这种操作其实没意义。UPDATE语句是一个原子操作，执行失败代表整个事务被回滚了，dept表的数据根本没有变化。你看到的person表里的记录，自然也是没变的。正确的验证方式是：

SELECT * FROM dept WHERE DeptNo IN ('00101', '00108'); SELECT * FROM person WHERE DeptNo IN ('00101', '00108');

执行完UPDATE后，这两条查询的结果应该跟执行前完全一致，dept表里依然是00101，没有00108。这才是“未完成主表更新操作”的正确验证思路。

提示：碰到外键冲突报错时，先区分清楚是哪个表的哪个约束在拦你。报错信息里带REFERENCE 约束的是外键，带PRIMARY KEY的是主键，带UNIQUE KEY的是唯一约束。

3.4 这个报错在提醒你：NO ACTION 和 CASCADE 的处世哲学完全不同

实验里这个失败结果，本质是NO ACTION默认规则的体现。它不主动改任何东西，只是拒绝可能破坏完整性的操作。很多教材会说“默认外键不允许更新”，更准确的说法是“默认外键在NO ACTION规则下，拒绝可能让从表失去参照的操作”。

这种规则的哲学是“宁可操作失败，也不留脏数据”。当你把00101改成00108时，数据库在提交前检查了一遍person表，发现有记录还引着旧值，于是整个 UPDATE 被拦下来。

而级联更新（CASCADE）的哲学正好相反，它会在主表更新时，自动同步更新从表的所有记录。实验的第五个任务就是针对这种差别，先别急，留着后面详细说。

4. 从表操作的对称性：pay 表更新失败背后的两条约束

4.1 person 与 pay：两个方向的外键约束对照

实验的第四个任务，是把pay表中的工号000002改为000020，预期是更新失败。这里涉及的外键关系是：person表是主表，pay表是从表，pay.No引用person.No。

这和前一个任务刚好形成对称：前面是更新主表，约束去查从表有没有关联记录；这次是更新从表，约束去查主表有没有对应记录。两个方向都测一遍，才算是把引用完整性理解透了。只看一个方向很容易产生错觉，碰上反向的约束之前，根本不会意识到这个问题的严重性。

4.2 从表更新失败的根因：修改的不是参照来源

执行的语句如下：

UPDATE pay SET No = '000020' WHERE No = '000002';

执行后系统报错：

UPDATE 语句与 FOREIGN KEY 约束 "fk_no" 冲突。

这个报错的含义是：pay表有一条记录的No是000002，你要把它改成000020，但person主表里根本不存在工号000020。如果这条更新成功，pay表里就会出现一个不属于任何人的工资记录，参照完整性被破坏。数据库因此拒绝操作。

进一步用查询验证：

SELECT * FROM person WHERE No = '000020'; SELECT * FROM pay WHERE No = '000002';

person表里查不到000020，说明pay表里那条000002的记录失去参照对象，这就是更新失败的根本原因。

注意：约束名fk_no是创建外键时手动指定的，实验环境里如果约束是系统自动生成的，名字也可能是FK__pay__No__xxxx。不管名字长什么样，报错机制是一样的。

这里有一个思考题的映射：在什么样的主表和从表增删改操作里，数据的完整性约束会被破坏？这个实验已经把两类核心场景测出来了——修改主表的主键值，会让从表失去参照；修改从表的外键值，会让记录指向不存在的主表数据。其实删除操作也一样危险，比如删掉course表里的某门课，但sc表里还有选了这门课的成绩记录，外键约束同样是拦截的。

4.3 从表插入的隐性问题：为什么插入也可能被拦

实验里只测了更新，但实际场景中，插入操作同样会触发外键约束。考虑这个场景：

INSERT INTO pay (No, Year, Month, Salary) VALUES ('000030', 2026, 1, 8000);

如果person表里不存在工号000030，这条插入语句一样会被fk_no拦截。很多人以为只有更新才触发外键检查，其实插入、删除、更新三兄弟全都在检查范围内，只是暴露的频率和时机不同。做课外练习时如果卡在插入的报错上，优先去主表查一下关联字段是否存在，多半是这个问题。

5. 级联引用与课外任务：设置 CASCADE 后主表更新为何能成功

5.1 修改外键定义支持级联更新的完整 T-SQL 操作

实验的第五个任务，是把dept表里的部门代号00101改成00108，这次要让它成功执行。关键在于把外键约束设置成ON UPDATE CASCADE，让主表更新时自动同步修改从表的关联记录。

在 SQL Server 里，级联更新不是直接修改现有约束，而是要先把旧约束删掉，再按CASCADE规则重建。操作流程是：

ALTER TABLE person DROP CONSTRAINT FK__person__DeptNo__2B0A656D; ALTER TABLE person ADD CONSTRAINT FK_person_dept_cascade FOREIGN KEY (DeptNo) REFERENCES dept(DeptNo) ON UPDATE CASCADE;

这里有个非常关键的点要强调：SQL Server 不允许直接用ALTER TABLE ... ALTER CONSTRAINT给现有外键添加级联选项。网上很多教程直接写一条语句就完事，实际执行会报语法错误。必须先删后建，这是唯一可行的路子。

5.2 执行更新并验证级联效果：两张表同步变化

外键重建完成后，再执行之前失败的更新语句：

UPDATE dept SET DeptNo = '00108' WHERE DeptNo = '00101';

这一次，语句执行成功。验证方式如下：

SELECT * FROM dept WHERE DeptNo = '00108'; SELECT * FROM person WHERE DeptNo = '00108';

你会看到，dept表里部门代号变成了00108，同时person表里原来部门代号为00101的所有员工的记录，也自动同步成了00108。这就是CASCADE级联更新的行为特征：主表动，从表跟着动。

5.3 课外任务 3 和 4 的翻车现场：为什么 course 级联更新会失败

课外任务更狠：要求先给sc表加ON UPDATE CASCADE外键，再给course表的cpno（先修课号）定义自引用级联更新。很多人在这里做一半就放弃，因为实验结果跟预期完全对不上——级联更新失败，报错信息看不懂。

先说第一个：sc表外键设为级联更新后，执行如下更新：

UPDATE course SET cno = '0809023601' WHERE cno = '0809023501';

如果失败，报错大概率还是外键冲突。这里有个很容易被忽略的细节：虽然你改了sc表的外键定义，但前提是sc.cno引用course.cno时，只有一个外键约束。而course表里cpno还引用着course.cno，即自引用外键。course表的主键cno一改，cpno指向旧值的那些行没有级联更新，于是约束冲突，整体失败。

第二个任务给course.cpno加级联更新，需要做的是：

ALTER TABLE course DROP CONSTRAINT FK__course__cpno__xxxx; ALTER TABLE course ADD CONSTRAINT FK_course_cpno_cascade FOREIGN KEY (cpno) REFERENCES course(cno) ON UPDATE CASCADE;

加完之后更新cno，你会发现cpno字段并没有级联更新。这是 SQL Server 的经典限制：自引用外键的级联更新行为在很多场景下并不可靠，系统会返回错误信息，明确说 self-referencing 表上存在多个级联路径。这类限制和实现机制有关，手动改数据反而更可控。课外任务里那个“请记录提示信息”，实际就是把这条报错如实记录下来。

5.4 保证数据正确性的补救方案：手动写 UPDATE 同步

既然CASCADE在自引用场景下靠不住，那怎么保证数据一致？我的做法是：用事务包住多次更新。

BEGIN TRANSACTION; UPDATE course SET cno = '0809023601' WHERE cno = '0809023501'; UPDATE sc SET cno = '0809023601' WHERE cno = '0809023501'; UPDATE course SET cpno = '0809023601' WHERE cpno = '0809023501'; COMMIT TRANSACTION;

这段脚本的思路是：先改主表，再手动同步所有从表和自引用字段，最后一次性提交。如果中途某一步失败，整个事务回滚，不会留下半改的脏数据。实际项目里我会先模拟数据确认影响行数，再执行真实更新。这个“先查后改”的习惯帮我避免了不止一次误更新全表。

6. 避坑与常见问题：约束操作中的五个经典翻车现场

6.1 约束名是系统自动生成的，别靠猜

现象：执行DROP CONSTRAINT FK__person__DeptNo__2B0A656D时，把名字抄错了，系统报找不到对象。 原因：SQL Server 自动生成的外键名带一串十六进制后缀，实验指导书里打印的约束名和实际库里的不一定完全一致，不同环境、不同建表顺序生成的名称都不同。 解决：先查再删，固定操作如下：

SELECT name FROM sys.foreign_keys WHERE parent_object_id = OBJECT_ID('person');

不管环境怎么变，以查出来的实际名字为准。

6.2 创建主键时提示“与某列冲突”

现象：执行ALTER TABLE pay ADD CONSTRAINT PK_pay PRIMARY KEY (No, Year, Month)，报错说有行与主键冲突。 原因：表中已有重复的(No, Year, Month)组合值，不满足主键唯一性。 解决：先分组查重复值：

SELECT No, Year, Month, COUNT(*) FROM pay GROUP BY No, Year, Month HAVING COUNT(*) > 1;

把重复数据清理掉再建主键，或者换一组能唯一标识数据的列。

6.3 加了外键约束后，主表删除操作被拦

现象：删除dept表里的某个部门，提示外键冲突。 原因：默认NO ACTION规则下，person表还有记录引用了该部门代号。 解决：两步走——先处理从表数据，再删主表记录：

DELETE FROM person WHERE DeptNo = '00101'; DELETE FROM dept WHERE DeptNo = '00101';

如果业务允许，也可以把外键改成ON DELETE CASCADE，让从表记录随主表删除自动清掉。

6.4 在course表加外键约束时失败

现象：执行：

ALTER TABLE course ADD CONSTRAINT FK_course_cpno FOREIGN KEY (cpno) REFERENCES course(cno);

报错说cpno列的值在cno列中不存在。 原因：course表已有数据里，某些行的cpno指向了表中不存在的cno。 解决：用NOT EXISTS查一下非法数据：

SELECT * FROM course AS a WHERE a.cpno IS NOT NULL AND NOT EXISTS (SELECT 1 FROM course AS b WHERE b.cno = a.cpno);

把查出来的问题行修正或删除，再重新添加外键约束。思考题里专门问这个问题，其实就是引导你先看数据再动结构。

6.5 课外任务里cpno不加约束，更新照样失败

现象：只给sc表加了级联，更新course.cno依然报外键冲突。 原因：course表的cpno自引用外键挡在前面，没有级联处理。 解决：手动事务同步更新，把sc表和cpno都改到位。具体脚本参考前面 5.4 节的做法。这种组合拳比单纯依赖CASCADE可靠得多。

7. 最后的技巧：用三段式检查脚本判断约束状态是否正常

每次实验做完，我习惯跑一套三段式检查脚本，确认约束状态没有残留问题。第一步查主键和外键：

SELECT OBJECT_NAME(parent_object_id) AS table_name, name AS constraint_name, type_desc AS constraint_type FROM sys.objects WHERE type IN ('PK', 'FQ', 'UQ') ORDER BY table_name, constraint_type;

第二步查外键的级联动作：

SELECT OBJECT_NAME(parent_object_id) AS table_name, name AS constraint_name, delete_referential_action_desc, update_referential_action_desc FROM sys.foreign_keys;

第三步查数据冲突，比如department改名后person表是否同步：

SELECT (SELECT COUNT(*) FROM person) AS person_count, (SELECT COUNT(DISTINCT DeptNo) FROM person) AS distinct_deptno, (SELECT COUNT(*) FROM dept) AS dept_count;

这套检查脚本的价值在于，实验报告里要写的“验证结果”全部来自实际查询结果，不是靠回忆记下来的。比如你看到update_referential_action_desc显示CASCADE，就能明确确认级联已生效。从那以后我每次做约束实验都会强制走一遍这三段式脚本，不再凭感觉判断约束状态，报错信息也就自然对上了。希望帮到你。

本文还有配套的精品资源，点击获取