数据库课程设计实战：学生选课管理系统SQL Server落地

简介：这份面向高校数据库课程设计的报告范文，围绕“学生选课管理信息系统”给出从需求分析到应用实现的完整写作框架，适合正在完成课程设计、需要参考规范结构、建模过程和SQL Server实验步骤的学生。正文覆盖需求概述、组织结构与功能模块划分、业务流与数据流分析、数据字典，以及实体属性联系、CDM概念模型和PDM逻辑模型设计；物理实验部分包含表结构、完整性约束、视图、索引、存储过程和触发器的创建代码，并延伸到学生信息、课程信息、登录与成绩管理等模块的功能调试和应用程序设计，能够帮助读者对照检查各阶段文档是否完整。资源包为1个docx文档，约3.96MB，目录层级清晰，便于按章节查阅、摘录和改写。已有852人学习，可作为课程设计排版、数据库建模及视图、触发器、存储过程实现的参考素材。

1. 从目录反推落地路径：这份选课系统课设素材能省下多少重复劳动

每到期末周，总有人拿着一份《数据库系统概论》课程设计任务书来问，能不能把学生选课管理信息系统的报告拆开看看。他们缺的其实不是想法，而是一份能对着改的骨架。网上流传的数据库课程设计范文大多只有目录和几张截图，模板里没有一行能跑的 SQL，素材里也没有数据字典和约束定义，抄过去答辩时被问一句「你这个外键为什么放这张表」就卡住了。这份选课管理系统的课设报告不一样，它从需求分析、数据字典、E-R 图一路写到 SQL Server 的建表、视图、触发器、存储过程，把三类角色六个功能模块压缩成了六张表。下面按能复现的顺序拆一遍，重点放在哪些地方能直接改、哪些地方必须自己补。

2. 需求分析与数据字典：把范文目录落成能建表的字段清单

2.1 三类角色六个功能模块，最后只能落成六张表

选课系统的角色划分在报告里写得很直白：教务管理员、开课教师、选课学生。三者的权限差异不是靠一句「管理员权限最高」带过的，而是直接决定了数据怎么存。管理员要做的是设置选课时段、维护选课规则、增删用户、改密码、备份还原、注销账号；教师要做的是申请开课、维护自己的基本信息、录入成绩；学生要做的是浏览课程、选课退课、查成绩、改个人资料。

把这三类人的动作翻译成数据动作，会发现真正需要持久化的实体只有四个：学生、课程、教师、管理员。剩下的都是联系——学生和课程之间的「选」，教师和课程之间的「授」。四个实体加两条多对多联系，正好六张表：student、course、teacher、manage、SC、teachingplan。

这里有个新手常犯的错：把管理员和教师合并成一张user表，加一个role字段区分身份。报告里没这么干是对的。教师表上有职称、所属院系、参考书名这些字段，管理员根本没有这些属性；塞进同一张表就会造出一排 NULL，后面每个查询都得带一句WHERE Duty IS NOT NULL来过滤身份，越写越别扭。真正需要合并的是「登录」这个动作，不是「人」这个实体。

提示：管理员表和教师表分开建，但登录时可以用一个存储过程按角色分别查三张表，前端只传账号、密码、角色三个参数，后端用 IF 分流。这样既保留了表结构的清晰，又不用在前端暴露三套登录接口。

功能模块划分也要和表对上。报告里列了课程管理、学生管理、教师管理、查询管理、数据库管理、选课管理六个模块，听着多，但落到 SQL 上就是几张表的增删改查加三个连接查询。写报告时可以在模块图下面直接标一句「本模块对应 student / course 表」，答辩时一眼就能看出你是真想过还是照抄的架构图。

2.2 数据字典要写成能直接翻译成 DDL 的字段表

数据字典这一节是整份报告里最容易被糊弄过去、也最影响后面建表的部分。很多范文的数据字典长这样：数据项名、含义、类型，三列完事。这种表建出来的库一定会有问题，因为缺了三个关键信息——长度上限、是否允许为空、默认值或取值约束。

我一般会把它扩成六列，用学生表举个例子：

原报告里姓名写的是Char(10)，我在复现时改成了NVARCHAR(20)。定长CHAR会用空格把值补齐到声明长度，'张三'存进去实际占 10 个字符位，后面拼字符串或者算长度时很容易出岔子。判断规则其实很简单：学号、课程号、教师工号这种编码类字段，长度由编码规则本身决定，用CHAR；姓名、院系、邮箱、书名这种长度不定的，一律用VARCHAR或NVARCHAR，中文多的用后者。

再看选课表SC。报告里给了四个字段：课程号、学号、成绩、先修课号。这里有个设计上的取舍值得说清楚——Grade必须允许为空。选课的时候成绩还没出来，如果设成NOT NULL DEFAULT 0，那「未出成绩」和「考了 0 分」在数据上就没法区分了，后面统计挂科率会把没考的也算进去。正确做法是允许 NULL，查平均分时用AVG(Grade)自动跳过 NULL，查挂科时用WHERE Grade < 60也自动排除 NULL。

先修课号Cpno放在SC表里其实不太合理。先修关系是课程对课程的关系，跟哪个学生选了什么没关系。报告里这么写是把「课程的先修课」和「学生的选课记录」混在一张表了。复现时我把它挪到course表里做自引用外键，SC表只留学号、课程号、成绩三个字段，主键设成(Sno, Cno)复合主键，一个人同一门课只能选一次。

2.3 数据流图不用画得多漂亮，但层次要和表对齐

数据流分析这一节，报告里画了 0 层、1 层、2 层三张图，思路是对的，很多人卡在不知道每层该画什么。

0 层图只画系统边界：左边三个外部实体——学生、教师、管理员，中间一个圆圈叫「选课管理系统」，右边一个数据存储叫「选课数据库」。就这五个元素，多一个都是错的。这一层的目的是告诉读者系统的边界在哪。

1 层图把中间那个圆圈拆成三个加工：学生子系统、教师子系统、管理员子系统，各自和数据库有一条双向数据流。这一步对应的是权限划分，谁也别越界。

2 层图再往下拆，比如学生子系统拆成「选课」「退课」「查询成绩」「修改资料」四个加工，每个加工对应一条具体的 SQL 语句。画到这一层就够了，再拆下去就变成程序流程图了。

对齐的关键在于数据存储的命名。第 1 层里那个叫「选课数据库」的存储，到第 2 层就应该展开成student、course、SC三张具体的表名。如果 2 层图里还写着「数据库」这种笼统的名字，说明画图和设计是两张皮，答辩时老师一问「你这个数据流最终写进哪张表」就答不上来。

3. 概念模型转逻辑模型：E-R 图到六张表的主外键落位规则

3.1 实体抽取：选课和授课为什么必须单独成表

概念结构设计这一节，报告里列了三个实体加两个联系，这个数量是对的，但实体的属性归属经常被搞混。

学生实体的属性是学号、密码、姓名、系名、性别、年龄、邮箱、电话。课程实体的属性是课程号、课程名、开课学期、授课教师号、学分。教师实体的属性是工号、密码、姓名、院系、电话、职称、参考书名。这三个实体的属性都是「描述自己」的，不依赖别人而存在。

真正的难点在于「选课」和「授课」这两个联系。新手最容易犯的错，是在学生表里加一个SelectedCourses字段存「已选课程列表」，用逗号分隔。这种写法在课程设计里直接判不及格，因为违反了第一范式——字段不可再分。而且一旦要查「某门课有多少人选」，就得用LIKE '%C001%'去匹配字符串，C001和C0011还会误伤。

正确做法是把联系升格成独立的表。选课是学生和课程之间的多对多联系，一个学生选多门课，一门课被多个学生选，中间表SC的主键就是两边的组合(Sno, Cno)。授课是教师和课程之间的多对多联系，一个老师教多门课，一门课也可以有多个老师（比如实验课和理论课分开排），中间表teachingplan的主键是(Cno, Tno)。

这里还有个小细节：course表里已经有一个Tno字段了，那是「课程负责人」，和teachingplan里的授课教师不是一回事。负责人只有一个，授课教师可以有多个。报告里两个都保留了，这个设计是对的，答辩时可以主动提一句区别，能加分。

3.2 1:N 与 M:N 的转换：外键到底落在哪一侧

从 E-R 图往关系模式转换，规则其实就三条，但每年都有人把外键放反。

拿「一门课程可以有一门或多门先修课」这个自引用关系举例。转换后course表里多一个Cpno字段，它是指向course.Cno的外键。插入数据时必须先插没有先修课的基础课，再插依赖它的后续课，否则外键约束会拒绝。这个顺序在批量导入课程数据时特别容易翻车，后面第 5 章会细说。

外键落位还有一个隐性成本：它会影响删除顺序。删课程之前得先删SC和teachingplan里引用它的行，否则报「与 REFERENCE 约束冲突」。报告里没写级联删除，我建议也别加ON DELETE CASCADE——课设系统里误删一门课连带删掉几百条选课记录，这个锅不好背。稳妥做法是在存储过程里按顺序手动删，删之前先SELECT COUNT(*)确认影响范围。

3.3 CDM 到 PDM：自动生成之后必须手改的四处

报告里用了.cdm和.pdm两种文件，对应概念模型和物理模型，工具大概率是 PowerDesigner。用工具画图再自动生成 SQL 确实省事，但生成出来的脚本基本不能直接用，有四处必须手改。

第一处是数据类型。工具默认会给所有字符字段生成VARCHAR(254)，学号变成 254 位、密码变成 254 位，看着就离谱。得按数据字典逐个改回CHAR(10)、CHAR(6)这种精确长度。

第二处是主键顺序。复合主键(Sno, Cno)和(Cno, Sno)在逻辑上等价，在物理上不等价——SQL Server 默认把主键建成聚集索引，索引的排序按主键列的顺序来。如果系统里最高频的查询是「某门课有哪些学生」，那主键顺序应该是(Cno, Sno)；如果最高频的是「某个学生选了什么课」，才是(Sno, Cno)。这个选择直接决定了后面要不要额外建索引。

第三处是约束。工具能生成主键和外键，但生成不了CHECK约束和默认值。性别限定男女、成绩限定 0 到 100、课程容量默认 60，这些都得手写。

第四处是注释。工具生成的中文注释经常在导出时丢失，变成一堆Column1、Column2。我一般会在建表脚本里用--手动补上中文说明，后面维护的人（包括三个月后的自己）能少查好几次数据字典。

4. SQL Server 物理落地：六个对象从建表到存储过程的完整脚本

4.1 六张表的建表顺序与完整性约束

建表脚本最容易出的问题不是语法，是顺序。course表里有外键指向teacher，SC表有外键指向student和course，如果按报告目录的顺序从上往下执行，跑到course就会报「引用了无效的表 teacher」。

正确的顺序是：先建没有任何外键依赖的student和teacher和manage，再建依赖teacher且有自引用的course，最后建两张中间表SC和teachingplan。

-- 1. 学生表：无外键依赖，可最先建 CREATE TABLE student ( Sno CHAR(10) NOT NULL, Spassword CHAR(6) NOT NULL, Sname NVARCHAR(20) NOT NULL, Sdept VARCHAR(30) NULL, Ssex CHAR(2) NULL, Sage INT NULL, Telephone VARCHAR(12) NULL, Email VARCHAR(50) NULL, CONSTRAINT PK_student PRIMARY KEY (Sno), CONSTRAINT CK_student_sex CHECK (Ssex IN ('男', '女')), CONSTRAINT CK_student_age CHECK (Sage BETWEEN 15 AND 60) ); GO -- 2. 教师表：同样无外键依赖 CREATE TABLE teacher ( Tno CHAR(5) NOT NULL, Tpassword CHAR(6) NOT NULL, Tname NVARCHAR(20) NOT NULL, Sdept VARCHAR(30) NULL, Duty VARCHAR(10) NULL, Telephone VARCHAR(12) NULL, Book NVARCHAR(50) NULL, CONSTRAINT PK_teacher PRIMARY KEY (Tno) ); GO -- 3. 课程表：依赖 teacher，且 Cpno 自引用，必须放在 teacher 之后 CREATE TABLE course ( Cno CHAR(7) NOT NULL, Cname NVARCHAR(30) NOT NULL, Term INT NOT NULL, Tno CHAR(5) NULL, -- 课程负责人 Ccredit INT NOT NULL, Cpno CHAR(7) NULL, -- 先修课号，指向本表 Cno Capacity INT NOT NULL DEFAULT 60, CONSTRAINT PK_course PRIMARY KEY (Cno), CONSTRAINT FK_course_teacher FOREIGN KEY (Tno) REFERENCES teacher(Tno), CONSTRAINT FK_course_cpno FOREIGN KEY (Cpno) REFERENCES course(Cno), CONSTRAINT CK_course_credit CHECK (Ccredit BETWEEN 1 AND 10), CONSTRAINT CK_course_term CHECK (Term BETWEEN 1 AND 8) ); GO -- 4. 选课表：依赖 student 和 course，主键为复合键 CREATE TABLE SC ( Sno CHAR(10) NOT NULL, Cno CHAR(7) NOT NULL, Grade INT NULL, -- 允许空表示尚未录入成绩 CONSTRAINT PK_SC PRIMARY KEY (Sno, Cno), CONSTRAINT FK_SC_student FOREIGN KEY (Sno) REFERENCES student(Sno), CONSTRAINT FK_SC_course FOREIGN KEY (Cno) REFERENCES course(Cno), CONSTRAINT CK_SC_grade CHECK (Grade BETWEEN 0 AND 100) ); GO -- 5. 授课表：教师与课程的多对多落地 CREATE TABLE teachingplan ( Cno CHAR(7) NOT NULL, Tno CHAR(5) NOT NULL, CONSTRAINT PK_teachingplan PRIMARY KEY (Cno, Tno), CONSTRAINT FK_tp_course FOREIGN KEY (Cno) REFERENCES course(Cno), CONSTRAINT FK_tp_teacher FOREIGN KEY (Tno) REFERENCES teacher(Tno) ); GO

这段脚本里有三处值得单独说。第一处是CK_SC_grade CHECK (Grade BETWEEN 0 AND 100)，它同时挡住了负分和超过 100 的分数，但不会挡住 NULL——SQL 的 CHECK 约束对 NULL 一律判定为 UNKNOWN，不视为违规，这正好符合「未出成绩」的语义。第二处是course表里的自引用外键，建表时course表还不存在，SQL Server 允许自引用外键在同一个 CREATE TABLE 语句里定义，不用额外的 ALTER。第三处是GO批处理分隔符，它不是 SQL 语句，是 SSMS 的批处理标记；用 ADO.NET 或 JDBC 执行这段脚本时必须先按GO分割，否则会报语法错误。

注意：如果你的服务器上已经建过同名的旧表，脚本第一步会失败。稳妥做法是在文件开头加一段条件删除，按teachingplan→SC→course→teacher→student的倒序清理，顺序反了同样会撞外键。

4.2 视图：把三表连接封装起来

报告里建了学生基本信息视图、学生参考书视图、教师基本信息视图三个。思路没错，但前两个的实用价值不高——单表查询封装成视图，除了少写几个字段名，没什么收益。真正该建视图的是跨表连接查询。

选课系统里最高频的查询是「某个学生这学期选了什么课、谁教的、多少学分、考了多少分」。这个查询要连student、SC、course、teacher四张表，每次前端调用都写一遍 JOIN 又长又容易写错。

-- 学生选课全景视图：四表连接，前端只查这一个视图 CREATE VIEW v_student_course AS SELECT s.Sno, s.Sname, s.Sdept, c.Cno, c.Cname, c.Ccredit, c.Term, t.Tname AS TeacherName, sc.Grade, -- 学分是否已获得：及格才计入 CASE WHEN sc.Grade >= 60 THEN c.Ccredit ELSE 0 END AS EarnedCredit FROM student s INNER JOIN SC sc ON s.Sno = sc.Sno INNER JOIN course c ON c.Cno = sc.Cno LEFT JOIN teacher t ON t.Tno = c.Tno; GO

这段视图有两个设计决策。一是teacher用了LEFT JOIN而不是INNER JOIN，因为课程可能还没分配负责人（course.Tno允许为空），用内连接会把这些课直接漏掉，学生就看到自己选的课凭空消失了。二是EarnedCredit这个派生列，把「及格才计学分」的业务规则固化进视图，前端不用再写一遍判断，也避免了不同页面算法不一致的问题。

视图命名建议统一加v_前缀，跟物理表区分开。有些团队习惯用view_或者vw_，都行，关键是全项目一致。视图里不要写ORDER BY，SQL Server 会直接报错「视图或函数中的 ORDER BY 子句无效」，除非同时加TOP。排序的事情交给查询语句去做。

4.3 触发器：选课容量和成绩录入两道闸

报告里建了触发器，但只提了「创建触发器」四个字，没写具体管什么。课设系统里触发器最适合守两道闸。

第一道是选课容量。course表有Capacity字段，学生选课时如果人数已经满了，应该直接拒绝，而不是先插进去再靠人工清理。

-- 选课容量闸：插入 SC 后检查该课程是否超员 CREATE TRIGGER trg_sc_capacity ON SC AFTER INSERT AS BEGIN SET NOCOUNT ON; -- 用集合方式判断，不要用变量接 inserted 的列 IF EXISTS ( SELECT 1 FROM inserted i INNER JOIN course c ON c.Cno = i.Cno WHERE (SELECT COUNT(*) FROM SC x WHERE x.Cno = i.Cno) > c.Capacity ) BEGIN RAISERROR('该课程选课人数已满，请选择其他教学班', 16, 1); ROLLBACK TRANSACTION; END END; GO

SET NOCOUNT ON放在第一行，是为了阻止「(1 行受影响)」这类消息混进结果集，前端用 DataReader 读的时候会莫名其妙多出一条记录。判断逻辑用EXISTS子查询而不是SELECT @Count = COUNT(*)，是因为触发器可能一次处理多行——学生批量选课时，inserted里可能有 10 条记录，用变量接只能拿到最后一条，前面 9 条就漏检了。

RAISERROR的第二个参数 16 表示错误级别，10 以上才会被客户端当作异常抛出；第三个参数 1 是状态值，随便填，主要用于内部排查。ROLLBACK TRANSACTION必须显式写，AFTER触发器本身不会自动回滚，只抛错不回滚的话数据照样插进去了。

第二道闸是成绩录入权限。教师只能给自己教的课录成绩，不能改别人课的。这个逻辑放在存储过程里更合适，用触发器的话每次更新都要连表判断，开销大。但如果一定要用触发器，可以写成INSTEAD OF UPDATE，在触发器里判断EXISTS (SELECT 1 FROM teachingplan WHERE Cno = ... AND Tno = CURRENT_USER)，不满足就直接RETURN，不执行实际更新。

4.4 存储过程与索引：分页查询和覆盖索引

存储过程这块，报告里列了「创建存储过程」，但没给具体业务。选课系统里最少要两个：查学生成绩单、按条件分页查课程。

-- 学生成绩单：支持按学期过滤，学期为空则查全部 CREATE PROCEDURE usp_GetStudentScore @Sno CHAR(10), @Term INT = NULL AS BEGIN SET NOCOUNT ON; SELECT c.Cno, c.Cname, c.Ccredit, c.Term, sc.Grade, CASE WHEN sc.Grade >= 60 THEN N'及格' ELSE N'不及格' END AS Status FROM SC sc INNER JOIN course c ON c.Cno = sc.Cno WHERE sc.Sno = @Sno AND (@Term IS NULL OR c.Term = @Term) ORDER BY c.Term, c.Cno; END; GO

@Term INT = NULL这种写法叫默认参数，调用时可以只传学号，也可以传学号加学期。(@Term IS NULL OR c.Term = @Term)是处理可选参数的标准套路，但要注意它可能导致执行计划不走索引——优化器没法预知@Term到底是不是 NULL。数据量小的时候无所谓，数据量大了要拆成两个分支或者用动态 SQL。

索引方面，SC表的主键(Sno, Cno)会自动建成聚集索引，按学号查很快，但按课程号查就扫全表了。教学管理里「某门课有哪些学生选」是高频查询，必须补一个非聚集索引。

-- 覆盖索引：查询只需要 Cno 和 Grade，索引里直接带上 Grade 就不用回表 CREATE NONCLUSTERED INDEX IX_SC_Cno ON SC (Cno) INCLUDE (Grade); -- 课程表按负责人查：教师端「我教的课」列表要用 CREATE NONCLUSTERED INDEX IX_course_Tno ON course (Tno) INCLUDE (Cname, Term, Ccredit);

INCLUDE子句是 SQL Server 特有的覆盖索引写法，把 SELECT 里用到但不在索引键里的列附在叶子节点上，查询时只读索引不读表，少一次回表操作。代价是索引占的空间变大，更新时维护成本变高。课设这种数据量下随便加，真实系统里要拿执行计划验证过再决定。

5. 常见问题排查：五个让课设跑不起来的坑

5.1 从现象倒推原因，五个高频翻车点

坑一：拼出来的字符串中间一堆空格，LEN算出来的长度也不对。

现象是视图里写Sname + '-' + Sdept，结果输出成「张三 -计算机系」，中间空了一大截；用LEN(Sname)查长度得到 2，但数据字典里明明定义的是 10。

原因是CHAR是定长类型，存'张三'会补 8 个空格到 10 位。LEN()函数会忽略尾部空格所以返回 2，DATALENGTH()才返回真实的 10。拼接时空格原样带出来，前端不做TRIM就会显示异常。

解决办法是分两步：姓名、院系、邮箱这类长度不定的字段统一改成NVARCHAR或VARCHAR；已经建成CHAR的历史表不想改的话，所有拼接处套RTRIM()，比较处也老老实实写WHERE RTRIM(Sname) = '张三'。编码类字段（学号、课程号）保留CHAR不动，因为它们本来就该定长。

坑二：一次性执行整个建表脚本，报「引用了无效的对象名 teacher」。

现象是新建一个空库，把报告里的建表代码从头到尾粘贴执行，跑到CREATE TABLE course就停下。

原因是course表里有FOREIGN KEY (Tno) REFERENCES teacher(Tno)，而teacher表在后面才建。外键要求被引用的表和列必须已经存在。

解决办法有两个。一是调整顺序，按student→teacher→manage→course→SC→teachingplan排列，删表时反序。二是先建所有表不带外键，最后用一串ALTER TABLE ... ADD CONSTRAINT统一补，这种方式对已有数据的库更友好。我一般用第一种，脚本从上往下读着顺。

坑三：按课程号查选课记录特别慢，执行计划显示聚集索引扫描。

现象是SELECT * FROM SC WHERE Cno = 'C0001'在大数据量下要跑好几秒，而按学号查同样的表瞬间返回。

原因是SC表的主键(Sno, Cno)默认建成了聚集索引，索引的排序是先按Sno再按Cno。按Cno查的时候，Cno不是前导列，优化器用不上这个索引，只能全表扫。

解决办法是补一个IX_SC_Cno非聚集索引，如果查询只取课程号和成绩，用INCLUDE (Grade)做成覆盖索引。如果系统里按课程查的需求远多于按学生查，可以考虑把聚集索引改成(Cno, Sno)，但主键约束本身不能随便改，得先删了重建。

坑四：批量插入选课记录，触发器没拦住超员的课。

现象是单个学生选课时超员能正确报错，用INSERT ... SELECT一次插 20 条记录时，超员了也没报错。

原因是触发器里写了SELECT @Cno = Cno FROM inserted这种赋值语句。inserted是表不是变量，一次插入多行时它里面有多行数据，赋值语句只会取其中任意一行（实际是最后一行），其余行就漏检了。

解决办法是触发器里禁止用变量接inserted的列，全部改成集合操作。判断超员用IF EXISTS (SELECT 1 FROM inserted i JOIN course c ON ... WHERE (SELECT COUNT(*) ...) > c.Capacity)，inserted当表来用，一行都不用漏。

坑五：视图定义里写了ORDER BY，创建时报语法错误。

现象是照着查询语句改视图，CREATE VIEW v_course AS SELECT * FROM course ORDER BY Cno，SQL Server 直接报「视图或函数 'v_course' 中的 ORDER BY 子句无效，除非还指定了 TOP、OFFSET 或 FOR XML」。

原因是关系模型的视图本身是无序集合，标准 SQL 不允许视图里有ORDER BY。SQL Server 严格执行这一条。

解决办法是去掉视图里的ORDER BY，排序写在查询视图的语句上：SELECT * FROM v_course ORDER BY Cno。如果确实需要在视图里做分页，可以写成SELECT TOP 20 * FROM course ORDER BY Cno，加了TOP之后ORDER BY才有了明确语义，是允许的。

5.2 交付前跑一遍自检脚本，别等答辩现场才发现

上面五个坑单看都是小问题，凑在一起就是「本地能跑、换台机器就崩」。每次改完脚本，我会固定跑一遍下面这组检查，三十秒能筛掉大部分低级错误。

-- 1. 检查是否有被禁用的外键约束（导入数据后常被临时关掉忘了开） SELECT name AS FK_Name, is_disabled, is_not_trusted FROM sys.foreign_keys WHERE is_disabled = 1 OR is_not_trusted = 1; -- 2. 检查触发器状态，确认没有被禁用 SELECT t.name AS Trigger_Name, t.is_disabled, OBJECT_NAME(t.parent_id) AS Table_Name FROM sys.triggers t WHERE t.parent_id IN (OBJECT_ID('SC'), OBJECT_ID('course')); -- 3. 数据体检：找出实际选课人数超过容量的课程 SELECT c.Cno, c.Cname, c.Capacity, COUNT(sc.Sno) AS Picked FROM course c LEFT JOIN SC sc ON sc.Cno = c.Cno GROUP BY c.Cno, c.Cname, c.Capacity HAVING COUNT(sc.Sno) > c.Capacity; -- 4. 数据体检：找出成绩不在 0-100 区间的记录（绕过 CHECK 的历史数据） SELECT Sno, Cno, Grade FROM SC WHERE Grade IS NOT NULL AND (Grade < 0 OR Grade > 100); -- 5. 检查索引是否都已创建 SELECT i.name AS Index_Name, OBJECT_NAME(i.object_id) AS Table_Name, i.type_desc FROM sys.indexes i WHERE OBJECT_NAME(i.object_id) IN ('SC', 'course') AND i.name IS NOT NULL;

第 1 条最值得说。做数据迁移或者批量导入时，常见做法是先ALTER TABLE ... NOCHECK CONSTRAINT ALL关掉外键，导完再打开。但如果导入中途报错退出，外键就一直处在禁用状态，后面所有插入都不校验，脏数据会越积越多。is_not_trusted = 1表示约束虽然启用了但没做过数据校验，也要单独处理。

第 3 条和第 4 条是数据层面的自检，专门抓「约束没生效期间插进去的脏数据」。答辩演示前跑一次，有问题提前修，总比现场翻车强。

6. 答辩前的验证闭环：登录分流与成绩模块的四组测试数据

报告最后一章写的是应用程序设计，只提了登录模块和成绩管理模块，没给实现。这两个模块恰好是答辩时必问的，我一般会用一条存储过程把登录分流做掉，用一组固定测试数据把成绩模块跑通。

登录分流的思路是：前端只传账号、密码、角色三个参数，存储过程内部按角色分别查三张表，任何一张命中就返回对应的身份标识。

-- 登录分流：按角色查不同的表，避免前端拼 SQL CREATE PROCEDURE usp_Login @Account VARCHAR(20), @Password VARCHAR(20), @Role VARCHAR(10) -- 'student' / 'teacher' / 'admin' AS BEGIN SET NOCOUNT ON; IF @Role = 'student' SELECT Sno AS UserId, Sname AS UserName, 'student' AS Role FROM student WHERE Sno = @Account AND Spassword = @Password; ELSE IF @Role = 'teacher' SELECT Tno, Tname, 'teacher' FROM teacher WHERE Tno = @Account AND Tpassword = @Password; ELSE IF @Role = 'admin' SELECT Gno, Gname, 'admin' FROM manage WHERE Gno = @Account AND Gpassword = @Password; END; GO

参数化调用是底线，前端绝对不能用字符串拼接把账号密码塞进 SQL，' OR '1'='1这种老掉牙的攻击到现在还有系统中招。存储过程返回空结果集就代表登录失败，不用额外返回错误码，前端判断DataReader.HasRows即可。

成绩模块的验证，我习惯准备四组数据，覆盖正常和异常两条路径。

T04 特别值得跑一遍，因为UPDATE匹配不到行时 SQL Server 不会报错，只会返回「0 行受影响」。如果应用层不检查这个返回值，用户会以为成绩录进去了，实际什么都没发生。

提示：答辩演示用的数据库，提前用一组真实感的数据灌满——至少 30 个学生、10 门课、200 条选课记录，其中要有几门课接近满员、几个学生有不及格成绩。空库演示「查询所有课程」看不出任何东西，数据一多才能体现索引和视图的价值。

从那以后我每次交课设之前，都会强制走一遍这三步：先在全新数据库上从头执行建表脚本，确认没有顺序问题；再灌一批测试数据跑自检脚本，确认没有脏数据；最后用四组用例把登录和成绩模块点一遍。这三步加起来不到二十分钟，能挡掉答辩现场九成的尴尬。希望帮到你。

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