简介本资源是《数据库系统概论》第3章核心实验内容的配套实现代码文档面向高校计算机专业本科生、数据库初学者及课程实践者聚焦SQL数据定义语言DDL与完整性约束的落地应用。文档以Word格式.doc完整呈现全部例题代码共1个文件大小1.49MB涵盖student、course、sc三张典型关系表的创建语句、主码/外码/检查/默认值等多类约束实现细节以及INSERT批量插入、ALTER TABLE结构修改、索引创建与删除等关键操作并附带常见报错分析与SQL Server适配说明如datetime类型修正、CASCADE语法兼容性处理等。内容严格对应教材例题编号例3–例15每段代码均含注释解析便于理解语法逻辑与工程实践差异。目前已有241人学习下载是课堂笔记补充、课后实操验证与期末复习的实用参考资料。1. 这不是一份“抄作业”的 DOC 文件而是一套能跑通的 SQL 实战沙盒覆盖建表、约束、插入、修改、索引、查询全链路专治《数据库系统概论》第3章“看懂了但写不出”的玄学卡点你是不是也经历过教材例题背得滚瓜烂熟一打开 SQL Server Management StudioSSMS就手抖CREATE TABLE 写到一半发现 CHECK 约束括号没闭合INSERT 多加了个逗号直接报错 102ALTER COLUMN 改个数据类型弹出“对象依赖于该列”却不知道该删哪个约束DROP INDEX 时死活找不到索引名翻遍 student 表 schema 也没见 stusname ——最后才发现自己建的是 stusno。这不是你菜是教材例题和真实数据库引擎之间隔着一层没明说的“执行上下文”。这份《数据库系统概论》第3章所有例题实现代码.doc本质是一份可复现、可调试、带排错注释的 SQL 沙盒脚本集它把王珊老师教材里分散在页眉页脚、批注框、勘误贴士里的隐性知识全部翻译成 SSMS 里能一行行执行、能看见错误码、能立刻 rollback 的真实语句。它不教你理论它替你踩坑——比如 SQL Server 不认cascadeOracle 和 SQL Server 对 NULL 排序逻辑相反_通配符在中文字段里必须用N_才生效……这些血泪经验全埋在注释里。适合刚学完关系模型、正对着第3章发懵的大二学生也适合需要快速搭建教学演示环境的助教——你复制粘贴进 SSMS按顺序执行就能看到三张表从无到有、数据逐条落库、索引成功创建、查询结果精准返回的完整闭环。它不是 PDF 笔记是能呼吸的数据库骨架。2. 数据定义与约束落地从 CREATE TABLE 到 FOREIGN KEY为什么你的建表语句总在第3行报错2.1 建表语句的“语法糖”陷阱列级 vs 表级约束的真实差异教材里常把 PRIMARY KEY、CHECK、DEFAULT 写在同一行看起来很清爽。但实际执行时列级约束和表级约束的解析优先级、错误定位粒度、以及后续 ALTER 的兼容性完全不同。我们以student表为例拆解每一条约束的底层含义CREATE TABLE student( sno CHAR(9) PRIMARY KEY, -- ✅ 列级主键SQL Server 自动创建唯一聚集索引默认 sname CHAR(20) NOT NULL, -- ✅ 列级非空强制插入时必须提供值 ssex CHAR(2) DEFAULT 男 CHECK(ssex IN (男,女)), -- ⚠️ 危险组合DEFAULT 和 CHECK 同属列级但 CHECK 会校验 DEFAULT 值是否合法 sage SMALLINT CHECK(sage15 AND sage45), -- ✅ 列级检查插入/更新时校验数值范围 sdept CHAR(20) -- ❌ 无约束允许 NULL且无索引 );关键参数说明CHAR(9)是定长字符串存储200215121会占满9字节比VARCHAR(9)更耗空间但查询略快SMALLINT取值范围是 -32768 到 32767完全覆盖 15~45比INT节省2字节存储CHECK(ssex IN (男,女))中的单引号必须是英文直角引号中文引号会导致语法错误 102DEFAULT 男的值必须符合CHAR(2)长度男正好2字节UTF-16若写男生会截断为男并静默警告。为什么强调这个因为后续ALTER COLUMN sage INT失败的根本原因就藏在这里CHECK约束被 SQL Server 视为一个独立对象如CK__student__sage__1CF15040它绑定在sage列上。当你试图ALTER COLUMN时引擎发现该列被 CHECK 约束“持有”必须先释放。这和教材里“直接改类型”的描述存在执行层偏差。2.2 外键约束的双向依赖为什么 SC 表建表失败时错误指向 course 表sc表的外键定义是理解参照完整性核心的关键CREATE TABLE sc( sno CHAR(9), cno CHAR(4), grade SMALLINT CHECK((grade IS NULL) OR (grade BETWEEN 0 AND 100)), PRIMARY KEY(sno, cno), -- ✅ 表级联合主键 FOREIGN KEY(sno) REFERENCES student(sno), -- ✅ 外键1sno 引用 student.sno FOREIGN KEY(cno) REFERENCES course(cno) -- ✅ 外键2cno 引用 course.cno );执行顺序决定生死必须先CREATE TABLE student和CREATE TABLE course否则REFERENCES student(sno)会报错 3701对象不存在student和course表的被引用列sno,cno必须已声明为 PRIMARY KEY 或 UNIQUE否则报错 1776被引用列未建立唯一约束sc表建表时SQL Server 会立即验证student和course表是否存在、被引用列是否唯一——这是 DDL 语句的原子性保障不是运行时检查。避坑提示很多初学者把sc表建在student和course之前或漏写PRIMARY KEY(cno)导致course.cno不是唯一键错误信息会指向FOREIGN KEY行但根因在上游表。建议建表顺序严格遵循student→course→sc。2.3 约束命名的隐形规则为什么 DROP CONSTRAINT 总找不到名字教材例题中大量使用匿名约束如CHECK(sage15)这在开发中极不友好。SQL Server 会自动生成约束名如CK__student__sage__1CF15040但名字含哈希值无法预测。生产环境必须显式命名约束-- ✅ 推荐写法显式命名便于后续管理 CREATE TABLE student( sno CHAR(9) CONSTRAINT PK_student_sno PRIMARY KEY, sname CHAR(20) CONSTRAINT NN_student_sname NOT NULL, ssex CHAR(2) CONSTRAINT DF_student_ssex DEFAULT 男, sage SMALLINT CONSTRAINT CK_student_sage CHECK(sage15 AND sage45), sdept CHAR(20) ); -- ✅ 删除约束时直接引用名字不再靠猜 ALTER TABLE student DROP CONSTRAINT CK_student_sage;参数价值CONSTRAINT name是标准 SQL 语法在 SQL Server、MySQL 8.0、PostgreSQL 中通用。命名规则建议CK_表名_列名_业务含义检查约束、PK_表名_列名主键、FK_表名_外键列_被引用表_被引用列外键。这样sp_helpconstraint student查看约束时名字即文档。3. 数据插入与类型对齐INSERT INTO VALUES 的 4 个致命细节90% 的人栽在第2条3.1 字符串长度与中文编码为什么插入 李勇 报错 “字符串截断”student表定义sname CHAR(20)看似足够存 20 个汉字。但在 SQL Server 中CHAR(n)的n指字符数不是字节数。李勇是2个 Unicode 字符CHAR(20)可存 20 个字符没问题。但问题出在客户端连接的默认排序规则和隐式转换-- ❌ 危险写法未指定 Unicode 前缀可能触发代码页转换 INSERT INTO student VALUES(200215121,李勇,男,20,CS); -- ✅ 安全写法显式 N 前缀声明 Unicode 字符串 INSERT INTO student VALUES(N200215121, N李勇, N男, 20, NCS);原理说明N李勇告诉 SQL Server 这是NVARCHAR字面量按 UTF-16 编码传输若省略N客户端可能用GBK或Latin1解析导致李被误读为乱码字节插入时因长度超限CHAR(20)按字节计报错 8152。尤其当数据库排序规则为Chinese_PRC_CI_AS时此问题高频出现。3.2 NULL 值的显式表达为什么 INSERT INTO sc VALUES(200215121,1,NULL) 报错看sc表定义grade SMALLINT CHECK((grade IS NULL) OR (grade BETWEEN 0 AND 100))。逻辑上允许NULL但直接写NULL会触发 CHECK 约束校验。问题在于SQL Server 在 CHECK 中对 NULL 的处理是三值逻辑True/False/Unknown而IS NULL是唯一能安全判断 NULL 的运算符。但插入时NULL字面量本身是合法的报错通常源于列顺序错位sc表列为(sno, cno, grade)若写VALUES(200215121, NULL, 1)则NULL被赋给cnoCHAR(4)违反非空约束cno无NOT NULL声明但CHAR(4)默认允许 NULL此处不报错更常见原因客户端工具自动补全或格式化。某些 SSMS 插件会将NULL替换为NULL字符串导致插入NULL到SMALLINT列报错 245类型转换失败。✅绝对安全的写法-- 显式指定列名杜绝顺序错位 INSERT INTO sc (sno, cno, grade) VALUES (N200215121, N1, NULL); -- 或使用 DEFAULT 关键字若 grade 有 DEFAULT 约束 INSERT INTO sc (sno, cno) VALUES (N200215121, N1); -- grade 自动为 NULL3.3 批量插入的事务边界为什么 10 条 INSERT 有一条失败其余全回滚教材例题把所有INSERT写在一起看似方便。但 SQL Server 默认每个语句是独立事务。若想保证“全成功或全失败”必须显式包裹在事务中BEGIN TRANSACTION; INSERT INTO student VALUES(N200215121, N李勇, N男, 20, NCS); INSERT INTO student VALUES(N200215122, N刘晨, N女, 19, NCS); -- ... 其他8条 IF ERROR 0 COMMIT TRANSACTION; ELSE ROLLBACK TRANSACTION;参数说明ERROR返回上一条语句的错误号0 表示成功。COMMIT持久化所有更改ROLLBACK撤销全部。这是教学演示必备技能——避免因某条INSERT主键冲突如重复sno导致部分数据脏写。3.4 数据验证INSERT 后如何确认数据真实落库别只信命令已成功完成。必须用SELECT验证-- ✅ 验证 student 表数据量和关键字段 SELECT COUNT(*) AS total_students FROM student; SELECT sno, sname, ssex, sage, sdept FROM student WHERE sno N200215121; -- ✅ 验证外键引用完整性sc 表的 sno 是否都在 student 中存在 SELECT sc.sno, sc.cno FROM sc LEFT JOIN student ON sc.sno student.sno WHERE student.sno IS NULL; -- 若返回记录说明存在孤儿外键技巧LEFT JOIN ... WHERE ... IS NULL是检测外键违规的标准方法比NOT IN更可靠NOT IN遇 NULL 会返回空集。4. 表结构修改实战ALTER TABLE 的 5 个雷区第4个让 80% 的人重装 SQL Server4.1 ADD COLUMNdatetime vs DATE为什么教材写 datetime 而不是 dateALTER TABLE student ADD s_entrance datetime;教材用datetime是因《数据库系统概论》第六版出版时2018年SQL Server 2016 已支持DATE类型但为兼容旧版本如 SQL Server 2005仍推荐datetime。实际选型应基于需求类型存储大小精度推荐场景DATE3 bytes日精度入学日期、生日等无需时间的场景DATETIME8 bytes3.33ms需要记录具体时刻且兼容老系统DATETIME2(n)6-8 bytes100ns新项目首选精度高存储优✅现代写法SQL Server 2008ALTER TABLE student ADD s_entrance DATE; -- 更精确更省空间 -- 或 ALTER TABLE student ADD s_entrance DATETIME2(0); -- 秒精度8字节4.2 ALTER COLUMN为什么 “ALTER COLUMN sage INT” 必须先删 CHECK 约束这是 SQL Server 的硬性限制。ALTER COLUMN修改数据类型时要求该列不能有任何依赖对象。CHECK约束正是这样的依赖对象。执行流程必须是-- 步骤1查出 sage 列的 CHECK 约束名 SELECT name FROM sys.check_constraints WHERE parent_object_id OBJECT_ID(student) AND OBJECT_NAME(parent_object_id) student; -- 步骤2删除约束假设名为 CK_student_sage ALTER TABLE student DROP CONSTRAINT CK_student_sage; -- 步骤3修改列类型 ALTER TABLE student ALTER COLUMN sage INT; -- 步骤4重建 CHECK 约束注意INT 范围更大原条件仍适用 ALTER TABLE student ADD CONSTRAINT CK_student_sage CHECK(sage15 AND sage45);血泪经验sys.check_constraints是系统视图OBJECT_ID(student)获取表ID。不要手动记约束名用查询动态获取——这是 DBA 的基本功。4.3 ADD UNIQUE为什么ALTER TABLE course ADD UNIQUE(cname)能成功而ADD PRIMARY KEY不行UNIQUE约束允许NULL值每列最多一个NULL且不改变表的物理结构而PRIMARY KEY要求非空且唯一并默认创建聚集索引。course表已有PRIMARY KEY(cno)再加PRIMARY KEY(cname)会违反“一个表只能有一个聚集索引”的规则除非显式指定NONCLUSTERED。✅安全添加唯一约束-- ✅ 添加唯一约束允许 NULL ALTER TABLE course ADD CONSTRAINT UQ_course_cname UNIQUE(cname); -- ✅ 添加非聚集主键不破坏现有聚集索引 ALTER TABLE course ADD CONSTRAINT PK_course_cname PRIMARY KEY NONCLUSTERED (cname);4.4 DROP TABLE为什么没有 CASCADE且必须先删外键DROP TABLE student报错消息 3726因为sc表的FOREIGN KEY(sno)依赖它。SQL Server绝不允许级联删除CASCADE是 PostgreSQL/MySQL 的语法这是数据安全的底线设计。✅正确删除流程-- 步骤1删除依赖它的外键约束不是删表 ALTER TABLE sc DROP CONSTRAINT FK_sc_sno_student; -- 假设外键名为此 -- 步骤2删除表 DROP TABLE student; -- 步骤3若需重建重新创建 student 和 sc避坑 / 常见问题 / 排查现象1执行DROP TABLE student报错 “因为一个或多个对象访问此列”原因sc表存在外键引用或student表上有索引、触发器、视图依赖解决运行sp_fkeys student查看所有外键引用sp_help student查看依赖对象现象2ALTER TABLE student ALTER COLUMN sage INT报错 “ALTER TABLE ALTER COLUMN sage 失败”原因除 CHECK 约束外该列还可能被计算列、索引、统计信息引用解决先运行SELECT * FROM sys.dm_db_index_usage_stats WHERE object_id OBJECT_ID(student)检查索引用DBCC SHOW_STATISTICS(student, _WA_Sys_...)查看统计信息现象3CREATE CLUSTERED INDEX stusname ON student(sname)报错 “不能在表 student 上创建多个聚集索引”原因PRIMARY KEY(sno)默认创建了聚集索引student表已存在一个解决要么DROP CONSTRAINT PK_student_sno先删主键不推荐要么创建NONCLUSTERED索引CREATE NONCLUSTERED INDEX IX_student_sname ON student(sname)现象4DROP INDEX student.stusname报错 “索引 student.stusname 不存在”原因索引名不是stusname而是stusno教材例14建的或索引在student表上但属于其他架构如dbo.student解决用SELECT name FROM sys.indexes WHERE object_id OBJECT_ID(student)精确查名删除时写全名DROP INDEX IX_student_sname ON student现象5INSERT INTO course插入cpno为NULL但查询时cpno显示为空字符串原因cpno CHAR(4)是定长类型NULL被隐式转换为 4个空格显示为空白解决改用VARCHAR(4)或CHAR(4) NULL并在应用层明确区分NULL和空字符串5. 索引与查询优化从 CREATE INDEX 到 LIKE 查询那些教材没写的性能真相5.1 聚集索引 vs 非聚集索引为什么CREATE CLUSTERED INDEX stusname ON student(sname)必须先删主键PRIMARY KEY默认创建聚集索引Clustered Index它决定了表数据的物理存储顺序。一个表只能有一个聚集索引因为数据行不能按两种顺序同时存储。student表的sno主键已占用这个位置。✅正确创建方式-- 方案1删除主键不推荐破坏实体完整性 ALTER TABLE student DROP CONSTRAINT PK_student_sno; CREATE CLUSTERED INDEX IX_student_sname ON student(sname); -- 方案2创建非聚集索引推荐保留主键聚集索引 CREATE NONCLUSTERED INDEX IX_student_sname ON student(sname);参数说明NONCLUSTERED是显式关键字可省略默认即非聚集。非聚集索引是独立的 B 树叶子节点存sname值 sno聚集键通过sno回表查整行。查询WHERE sname 李勇时先走索引找到sno再用sno查主键索引取数据。5.2 复合索引与最左前缀为什么CREATE INDEX index_sno_cno ON sc(sno,cno)能加速WHERE snoxxx AND cnoyyy但对WHERE cnoyyy无效复合索引(sno, cno)的 B 树按sno排序sno相同时再按cno排序。查询必须包含最左列sno才能使用该索引WHERE sno200215121 AND cno1→ ✅ 精准匹配索引高效WHERE sno200215121→ ✅ 范围扫描sno再过滤cnoWHERE cno1→ ❌ 无法跳过sno直接查cno索引失效全表扫描✅针对cno高频查询应另建索引CREATE NONCLUSTERED INDEX IX_sc_cno ON sc(cno); -- 或更优覆盖索引避免回表 CREATE NONCLUSTERED INDEX IX_sc_cno_covering ON sc(cno) INCLUDE (sno, grade);5.3 LIKE 查询的性能陷阱为什么WHERE sname LIKE _勇比WHERE sname LIKE %勇快 100 倍_是单字符通配符%是多字符通配符。索引只能用于前导匹配sname LIKE 李%→ ✅ 使用索引查找sname以李开头的所有行sname LIKE %勇→ ❌ 索引失效必须扫描全表找结尾为勇的行sname LIKE _勇→ ⚠️ 理论上可用索引但实际取决于统计信息和查询优化器选择_无法利用 B 树的有序性通常仍走全表扫描✅优化方案-- 方案1用全文索引适合大文本 CREATE FULLTEXT INDEX ON student(sname) KEY INDEX PK_student_sno; -- 方案2添加计算列并索引适合固定模式 ALTER TABLE student ADD sname_last_char AS RIGHT(sname, 1) PERSISTED; CREATE INDEX IX_student_sname_last ON student(sname_last_char); -- 查询WHERE sname_last_char N勇5.4 NULL 排序的跨平台差异SQL Server 认为 NULL 最小Oracle 认为最大如何写出兼容查询ORDER BY sage DESC在 SQL Server 中NULL排在最前最小在 Oracle 中NULL排在最后最大。标准 SQL 用NULLS FIRST/LAST显式控制SQL Server 2022 支持旧版不支持✅SQL Server 兼容写法-- 强制 NULL 排最后模拟 Oracle 行为 SELECT * FROM student ORDER BY CASE WHEN sage IS NULL THEN 1 ELSE 0 END, sage DESC; -- 强制 NULL 排最前SQL Server 默认 SELECT * FROM student ORDER BY CASE WHEN sage IS NULL THEN 0 ELSE 1 END, sage DESC;原理CASE生成排序辅助列NULL映射为 1 或 0再按sage排序。这是跨数据库的通用技巧。6. 查询实战与验证技巧用 3 个 SELECT 语句10 分钟内验证整个第3章知识链是否打通6.1 验证数据完整性一条 SQL 检查所有约束是否生效别手动一条条INSERT测试。用以下查询一次性暴露所有潜在违规-- ✅ 检查外键完整性sc 表中是否存在 student 表没有的 sno SELECT sc.sno 引用异常 AS issue, sc.sno, sc.cno FROM sc LEFT JOIN student ON sc.sno student.sno WHERE student.sno IS NULL UNION ALL -- ✅ 检查外键完整性sc 表中是否存在 course 表没有的 cno SELECT sc.cno 引用异常 AS issue, sc.sno, sc.cno FROM sc LEFT JOIN course ON sc.cno course.cno WHERE course.cno IS NULL UNION ALL -- ✅ 检查 CHECK 约束student 表中是否存在 age 超出 15-45 的记录 SELECT student.sage 范围违规 AS issue, sno, sname, sage FROM student WHERE sage 15 OR sage 45 UNION ALL -- ✅ 检查 DEFAULT 约束student 表中 ssex 是否有非 男/女 的值 SELECT student.ssex 值违规 AS issue, sno, sname, ssex FROM student WHERE ssex NOT IN (N男, N女) OR ssex IS NULL;执行后若返回空集说明所有约束已正确加载并生效。这是比SELECT * FROM student更有力的验证。6.2 验证索引有效性用 SET STATISTICS IO ON 看清执行计划真相CREATE INDEX IX_student_sname ON student(sname)是否真被用了别信猜测看真实 I/O-- 开启 I/O 统计 SET STATISTICS IO ON; GO -- 执行查询 SELECT * FROM student WHERE sname N李勇; -- 关闭统计 SET STATISTICS IO OFF; GO结果解读若Logical Reads为 2~3说明走了索引根页叶子页若Logical Reads等于student表总页数说明全表扫描索引未被使用原因可能是sname列重复率高如大量同名、统计信息过期、查询条件未匹配索引最左列。✅强制更新统计信息UPDATE STATISTICS student IX_student_sname; -- 或更新全表 UPDATE STATISTICS student;6.3 验证查询逻辑教材例题的“效果一样”背后藏着执行效率的天壤之别教材例16提到“法一、法二结果一样”但未提性能。以SELECT * FROM sc WHERE sno IN (200215121,200215122)为例法一IN 列表WHERE sno IN (200215121,200215122)→ ✅ 索引查找两次法二ORWHERE sno 200215121 OR sno 200215122→ ✅ 同样高效优化器会转为索引查找危险法LIKEWHERE sno LIKE 20021512%→ ❌ 索引失效因sno是CHAR(9)LIKE前导匹配仍可用但若写成%121则全表扫描✅终极验证技巧对比执行计划在 SSMS 中按CtrlM开启“包含实际执行计划”执行两条语句观察是否都显示Index Seek绿色图标Estimated Subtree Cost数值是否接近 10% 差异可接受Number of Rows是否与预期一致避免笛卡尔积。从那以后我每次教学生建完三张表第一件事不是写查询而是跑一遍SET STATISTICS IO ONSELECT * FROM student WHERE 10空查询看开销再跑上面那个四合一完整性检查。它像一道安检门把教材里没写的隐性漏洞全筛出来——不是为了炫技是让学生亲手摸到数据库的“心跳”。希望帮到你。本文还有配套的精品资源点击获取
