企业官网建设流程全解析

简介：这是教务管理系统数据库课程设计报告，适合高校计算机专业学生完成数据库课程设计或毕业设计时参考。报告围绕高校教务管理场景，梳理教务员、教师、学生、系统管理员四类用户权限，覆盖数据录入、课程设置、成绩管理、多条件查询、权限控制、自动排课等功能模块，并给出需求分析、可行性分析、数据库模型设计、开发流程及测试部署思路，可引导读者把ER模型、C#后端开发、HTML/CSS/JavaScript前端和AJAX交互落地为完整项目。包体为单个doc文档，共1个文件，大小约287KB，内容约32页，包含系统功能模块图、界面截图、设计总结与体会，便于直接借鉴或改写。目前已有95人在CSDN学习下载，适合需要快速搭建教务管理系统框架并撰写规范课程设计报告的读者。整体结构完整，从需求梳理到部署维护均有说明，可作为课程设计说明书模板。

1. 教务管理系统数据库课程设计报告：拿到题目后，先别急着找模板

很多同学拿到一份名为“教务管理系统数据库课程设计报告.doc”的任务时，第一反应是找个模板改改名字就交，结果往往在答辩现场被一句“为什么成绩不放课程表里”问得哑口无言。这个标题真正考察的不是你的 Word 排版，而是你能不能把学生选课、教师授课、成绩录入这一串业务动作，翻译成一张能自圆其说的关系模型和一组能真实跑通的 SQL。教务管理系统是数据库课程设计里出现频率最高的选题，但高频不代表容易写好。这份报告适合正在做课设的学生，也适合带课老师用来判断题目难度；下面这个最小但完整的方案，会把从 ER 图设计、建库建表到存储过程与演示数据的整条路走通。

2. 从 ER 图到第三范式：先理顺教务系统的实体与关系

2.1 实体先于表：教务管理系统里到底有哪些“实体”

我见过最可惜的做法是一上来就打开 Navicat 建表，建到一半发现成绩没地方放。ER 图不是报告里凑页数的装饰，它是你后期不返工的唯一依据。教务管理系统的业务主线很清晰：学生选课，教师上课，期末产生成绩。沿着这条线去敲实体，最核心的是学生、教师、课程、教学班和选课记录这五个。

学生和课程之间是多对多关系，一个学生可以选多门课，一门课可以被多个学生选。关系模型里处理多对多的标准手段是拆关联表，于是就有了选课记录这个实体。这里藏着一个课程设计高频扣分点：很多人把成绩直接挂在课程表上，这在第三范式下是不成立的。成绩属于某一次选课行为，而不是属于课程本身；一门课可以被同一个学生修两次（重修），两次成绩都该被保留，所以成绩必须是选课记录上的属性，而不是课程上的属性。把这一点想清楚，后面建表才不会再犹豫。

教学班这个实体经常被忽略。同一门数据库原理可能同时开两个班，由不同老师授课，学生选了 A 班就不能再选 B 班。如果不引入教学班，选课表就必须同时写死课程号和教师号，一旦换老师就得改历史记录。课程设计报告里加上教学班，整套模型的业务表达力会立刻上一个台阶，而且答辩时这就是一个你能主动讲出来的设计亮点。

2.2 表结构选型：五张表还是七张表，以及我为什么删掉了“学院”表

我一般会给出一个最小五表方案：student、teacher、course、section、enroll。其中 section 是教学班，enroll 是选课成绩表。下面这张表就是你在报告第二章可以放的内容，既能解释结构，又能让老师一眼看到你的建模思路。

很多模板会让你拆出七张表，把学院、专业、班级全部独立成表。我不建议在课程设计里这么做。学院和班级在报表场景里只是展示字段，不参与核心业务计算；把它们做成字符串属性，插入数据时省掉一大串外键维护工作，报告的篇幅也更聚焦。但这里要提醒一句：如果题目明确要求“院系管理”或“专业管理”，那你必须独立建表，别为了省事丢掉得分点。选型原则只有一条——你的 ER 图里画了多少个实体，建表时就建多少张表，多画不建、建了不画，都是答辩翻车点。

字段类型也是报告里值得写两段的地方。学号用 CHAR(10) 而不是 INT，因为学号是等值查询的常用条件，定长字符比整数更适合做索引前缀，而且学号不是用来计算的；成绩用 DECIMAL(5,2) 而不是 FLOAT，因为浮点数的 0.1 加 0.2 会变成 0.30000000000000004，期末算绩点时这种误差会扩散；入学年份用 YEAR，它天然只保留年份，避免你在写“比较 2023 级和 2024 级人数”时还要先做截断。这些理由写在报告里，比堆一堆“VARCHAR(50)”有说服力得多。

3. 用 MySQL 把库建出来：DDL 语句、字段类型与增删改查的落地写法

3.1 建库建表：字符集、外键与字段类型的取舍

ER 图落到 MySQL 8.0，第一件事不是写 CREATE TABLE，而是先定字符集。课程设计历史遗留问题里，中文乱码占了相当大的比例，根源几乎都是库、表、连接三级字符集不统一。下面的 DDL 是一份可以直接复制跑的版本，每一步的注释说明为什么这样写：

-- 创建数据库：统一 utf8mb4，避免中文乱码 CREATE DATABASE IF NOT EXISTS edu_admin DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci; USE edu_admin; -- 学生表 CREATE TABLE student ( student_id CHAR(10) PRIMARY KEY COMMENT '学号，定长字符更适合等值查询', name VARCHAR(20) NOT NULL COMMENT '姓名', gender ENUM('男','女') DEFAULT '男' COMMENT '性别', birth_date DATE COMMENT '出生日期', enroll_year YEAR COMMENT '入学年份', dept_name VARCHAR(30) COMMENT '院系，字符串即可，不必拆表', class_name VARCHAR(20) COMMENT '班级' ) ENGINE=InnoDB COMMENT='学生信息表';

字段类型的选择要和报告第二章的选型理由对上。student_id 用 CHAR(10) 而不是 VARCHAR，因为定长字段在 InnoDB 里检索时多一层稳定性；gender 用 ENUM 能约束数据，但要注意 ENUM 的排序规则是按定义顺序而不是字母序，如果你的查询里要按性别分组统计，这一点会有坑。birth_date 用 DATE 而不是 VARCHAR，因为后面要算年龄的时候可以直接用 YEAR(CURDATE()) - YEAR(birth_date)，字符串存日期总有一天要转换。

继续建剩下四张表。教师表要特别注意的是 dept_name 和 student 表的 dept_name 含义相同，但我不建外键，因为院系变化频率极低，用字符串查询足够。课程表里 credit 用 DECIMAL(3,1)，学分可能是 2.0、3.5 这样的半学分制，小数位保留一位就够了。

-- 教师表 CREATE TABLE teacher ( teacher_id CHAR(8) PRIMARY KEY COMMENT '教师工号', name VARCHAR(20) NOT NULL COMMENT '姓名', title VARCHAR(20) DEFAULT '讲师' COMMENT '职称', dept_name VARCHAR(30) COMMENT '院系', office VARCHAR(30) COMMENT '办公室' ) ENGINE=InnoDB COMMENT='教师信息表'; -- 课程表 CREATE TABLE course ( course_code VARCHAR(10) PRIMARY KEY COMMENT '课程号', course_name VARCHAR(50) NOT NULL COMMENT '课程名', credit DECIMAL(3,1) DEFAULT 2.0 COMMENT '学分', hours SMALLINT DEFAULT 32 COMMENT '总学时', course_type VARCHAR(10) DEFAULT '必修' COMMENT '必修/选修' ) ENGINE=InnoDB COMMENT='课程信息表'; -- 教学班表：把课程和教师关联到具体学期 CREATE TABLE section ( section_id INT AUTO_INCREMENT PRIMARY KEY COMMENT '教学班编号', course_code VARCHAR(10) NOT NULL COMMENT '课程号', teacher_id CHAR(8) NOT NULL COMMENT '教师工号', semester VARCHAR(20) NOT NULL COMMENT '开课学期', capacity INT DEFAULT 60 COMMENT '容量', CONSTRAINT fk_section_course FOREIGN KEY (course_code) REFERENCES course(course_code), CONSTRAINT fk_section_teacher FOREIGN KEY (teacher_id) REFERENCES teacher(teacher_id) ) ENGINE=InnoDB COMMENT='教学班表';

section 表是整套模型里最能体现设计感的地方。它把“这门课由谁教”从课程本身剥离开，同一个 course_code 可以开多个班，比如数据库原理同时由刘老师和赵老师各带一个班。外键这里我是建议建的，因为课程号和教师号都是稳定主键，外键能挡住传错值的低级错误。注意 capacity 用 INT DEFAULT 60，选课人数统计的时候就能拿它和 enroll 的 COUNT 做对比，判断是否满员。

最后是选课成绩表。它同时关联学生和教学班，score 字段是决定整套系统业务成败的地方。这里我加了一个 CHECK 约束，把成绩限制在 0~100，虽然 MySQL 8.0 之前 CHECK 约束是空架子，但 8.0 之后是真的会拦截非法值，写进报告反而是加分项。

-- 选课成绩表：第三范式落地的核心 CREATE TABLE enroll ( enroll_id INT AUTO_INCREMENT PRIMARY KEY COMMENT '自增主键，无业务含义', student_id CHAR(10) NOT NULL COMMENT '学号', section_id INT NOT NULL COMMENT '教学班编号', score DECIMAL(5,2) COMMENT '成绩，保留两位小数', status ENUM('在读','通过','不通过') DEFAULT '在读' COMMENT '修读状态', CONSTRAINT fk_enroll_student FOREIGN KEY (student_id) REFERENCES student(student_id) ON DELETE CASCADE, CONSTRAINT fk_enroll_section FOREIGN KEY (section_id) REFERENCES section(section_id), CONSTRAINT chk_score CHECK (score BETWEEN 0 AND 100) ) ENGINE=InnoDB COMMENT='选课成绩表';

这里唯一要解释的是 ON DELETE CASCADE。学生退学删除学生记录时，他的选课记录应该一并清掉，所以用级联删除；但成绩历史有时候要留存，如果你的任课老师要求保留退学学生的成绩副本，就把 CASCADE 改成 RESTRICT。这个取舍没有标准答案，但报告里一定要写清楚你选 CASCADE 的理由，这让老师知道你理解外键行为，而不是随手复制的建表语句。

3.2 mysql 数据库修改结构的高频操作：ALTER、唯一索引与字段语义调整

写课程设计报告的时候，你能明显感觉到“一次建表成功”和“改了三轮才把表调对”是两种完全不同的评分体验。修改结构本身不是丢人事，但你要让老师看到你是带着目的去改的，不是建错了在补洞。最常见的修改是给 enroll 表加唯一索引，防止同一个学生在同一个教学班里重复选课：

-- 防止同一学生在同一教学班重复选课 ALTER TABLE enroll ADD UNIQUE KEY uniq_student_section (student_id, section_id);

这条语句加上去之后，你再执行两次完全相同的 INSERT 选课记录，第二次会被拒绝，报错信息是 Duplicate entry。这比在应用程序里先 SELECT 再 INSERT 要靠谱得多，因为 SELECT 到 INSERT 之间永远存在时间差，而唯一索引是数据库层面的硬约束。报告里写这一段时，搭配一个“重复选课报错”的截图，说服力很强。

另一种高频修改是字段语义调整。比如教师职称从“讲师/副教授/教授”调整为带“未定”的初始值，或者把某个 VARCHAR(20) 的字段扩宽到 VARCHAR(30)，这些都属于 mysql 数据库修改结构里的常规操作：

-- 调整字段类型与默认值：注意修改会触发表的重建 ALTER TABLE teacher MODIFY COLUMN title VARCHAR(30) DEFAULT '未定' COMMENT '职称';

ALTER TABLE 的代价是修改过程中 MySQL 可能对表加锁，对于课程设计这种数据量几百条的小库来说无感，但如果写在报告的性能分析里，就要老老实实承认它在大数据量下会阻塞读写。很多模板动不动就在结论里写“本系统具有良好扩展性”，这是最容易被答辩老师怼的一句话。哪怕你只做了最基础的 ALTER，也要把它的锁表机制写明白，这才叫有边界。

3.3 数据库增删改查：报告里必写的四条业务语句

增删改查是数据库课程设计评分表里的基础项，老师一定会找四段业务场景来验证你的系统是不是真的能用。很多同学把 SELECT 写得极其华丽，INSERT 和 DELETE 却只写了“INSERT INTO student VALUES(...)”，这种提交方式会让老师怀疑你根本没跑过代码。下面这四段是教务系统最常见的场景，也直接对应报告里的业务描述。

-- 新增一名学生 INSERT INTO student (student_id, name, gender, birth_date, enroll_year, dept_name, class_name) VALUES ('2023001001', '张伟', '男', '2005-03-12', 2023, '计算机学院', '计科2301'); -- 期末成绩复核：修正录错的分数 UPDATE enroll SET score = 88.5 WHERE student_id = '2023001001' AND section_id = 1; -- 学生退课 DELETE FROM enroll WHERE student_id = '2023001001' AND section_id = 1; -- 查询某学期所有学生的选课成绩 SELECT s.student_id, s.name, c.course_name, e.score FROM enroll e JOIN section sec ON e.section_id = sec.section_id JOIN course c ON sec.course_code = c.course_code JOIN student s ON e.student_id = s.student_id WHERE sec.semester = '2024-2025-1' ORDER BY s.student_id;

这四条语句里，INSERT 要考虑主键冲突，比如学号已经存在时报错，实际系统里经常用 INSERT IGNORE 或者 ON DUPLICATE KEY UPDATE 来吸收这种冲突；UPDATE 和 DELETE 的 WHERE 条件如果不带全，会把整张表的数据改掉，所以报告里要强调“带条件操作”；SELECT 是四表联合查询，每一步 JOIN 的关联字段分别是 enroll 的外键和对应主键，这也是老师考察你外键用得对不对的地方。

建议把这几段 SQL 的执行结果截图放进报告的“系统实现”部分，并在截图旁边说明每一段对应哪个业务功能。别担心截图太朴素，老师更愿意看到一个真实控制台输出，而不是一套用 PowerPoint 画的理想页面。

4. 视图、存储过程与触发器：让报告从“会建表”升级到“会设计”

4.1 视图：把“学生选课成绩查询”做成一等公民

只写裸 SQL 的课程设计报告，勉强算及格但拿不到优秀。教务管理系统里，成绩查询是学生、老师、教务员三个角色都要用到的功能，如果每次查询都写一遍四表 JOIN，你的报告会在可读性上吃大亏。视图的用处是把这个查询固化下来，之后所有角色都只需要 SELECT * FROM v_student_score，业务层不用关心表结构细节。

-- 创建学生成绩汇总视图，供成绩查询与打印成绩单使用 CREATE VIEW v_student_score AS SELECT s.student_id, s.name, c.course_name, c.credit, e.score, CASE WHEN e.score >= 60 THEN '通过' ELSE '不通过' END AS pass_flag FROM enroll e JOIN section sec ON e.section_id = sec.section_id JOIN course c ON sec.course_code = c.course_code JOIN student s ON e.student_id = s.student_id;

视图创建后，查询就变成 SELECT * FROM v_student_score WHERE student_id = '2023001001'。这个 CASE WHEN 表达式把成绩转成了“通过/不通过”，正好对应 enroll 表里 status 字段的语义，报告里可以解释为“视图负责计算派生字段，减少应用层判断”。要注意的是，视图不要滥用，如果视图与视图之间层层嵌套超过三层，性能会明显下降，而且排错变成了黑匣子；课程设计这个规模，两层视图已经顶天了。

4.2 存储过程：用参数化流程生成不及格名单

存储过程是课程设计报告里的加分大头，因为它能体现你对“可复用业务逻辑”的理解。教务系统里最典型的场景是期末考试后统计每门课的不及格名单，教务员需要按课程号调出所有挂科学生。这个需求如果用两个 SQL 分两次执行，中间状态就得靠人脑维持；用一个存储过程包住，参数传进去，结果直接出来，正好写进报告。

DELIMITER $$ CREATE PROCEDURE proc_fail_students(IN p_course_code VARCHAR(10)) BEGIN SELECT s.student_id, s.name, e.score FROM enroll e JOIN section sec ON e.section_id = sec.section_id JOIN student s ON e.student_id = s.student_id WHERE sec.course_code = p_course_code AND e.score < 60 ORDER BY e.score ASC; END$$ DELIMITER ;

调用时只需要 CALL proc_fail_students('CS101')，就能拿到数据库原理这门课的全部不及格名单。注意 DELIMITER $$ 这个语法不是给存储过程本身用的，而是告诉 MySQL 客户端“我的语句结束符临时改成 $$，这样 BEGIN...END 内部的分号不会被提前截断”，跑完之后记得恢复成 DELIMITER ; 。存储过程里除了 SELECT，还可以把 COMMIT 或 ROLLBACK 包进来；写入类型的存储过程加上事务后，才是完整的“存储过程支持事务”的演示素材。再往下走，你也可以把录入成绩做成一个存储过程，在循环里逐条 INSERT 并在出错时回滚，这对报告里的“数据完整性”章节很有帮助。

4.3 触发器：什么时候该用，什么时候写了反而扣分

触发器是课程设计里最容易被忽略也最容易写砸的数据库对象。一个能自圆其说的用法是防止非法成绩录入。虽然 enroll 表里已经加了 CHECK 约束，但保存历史数据时触发器的存在价值在于，它能拦截通过存储过程或者批量导入绕开默认检查的脏数据。

DELIMITER $$ CREATE TRIGGER trg_enroll_before_insert BEFORE INSERT ON enroll FOR EACH ROW BEGIN IF NEW.score IS NOT NULL AND (NEW.score < 0 OR NEW.score > 100) THEN SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '成绩必须在 0~100 之间'; END IF; END$$ DELIMITER ;

这段触发器在每次 INSERT 进 enroll 表之前自动检查成绩范围，不合格就直接抛错，业务层甚至不用再做二次校验。写进报告时的核心卖点是“数据库层完成完整性约束”，这一句就能让老师知道你是理解了触发器的应用场景，而不是为了凑篇幅。

也要讲清楚什么时候不该用触发器：不要在触发器里调用存储过程，不要做跨表的大规模 UPDATE，更不要在一个表上堆五六个触发器。触发器是隐式执行的，排错的时候它像一个黑匣子——你看到一条 INSERT 触发了连锁反应，但很难立刻定位问题在哪。课程设计报告里写一个触发器正好，写多了反而暴露你滥用数据库对象的问题。

5. 教务管理系统课程设计报告避坑：5 条血泪级踩坑记录

5.1 字段与表名全用英文，报告里却全是中文图：答辩时对不上

现象：报告正文的 ER 图里标着“学号”“姓名”“成绩”，代码清单里却是 student_id、name、score，老师追问“你的学号字段到底叫什么”时，你在两套命名之间来回切换。

原因：画图时用中文是为了版面好看，建表时用英文是数据库习惯，但没有做中英文对照表。

解决：在报告附录加一张“数据字典对照表”，左边是字段中文名，右边是英文列名，再标上类型和长度。这一步没有任何技术难度，却能让你的报告在规范性上超过一半的人。下次答辩前再自查一次：图里出现的每一个属性，都要能在 DDL 里找到对应字段。

5.2 插入数据时 “Cannot add or update a child row”：外键约束失败

现象：按报告里的 SQL 插入选课记录，MySQL 报错 Cannot add or update a child row: a foreign key constraint fails，程序当场崩溃。

原因：插入 enroll 时，section_id 指向的教学班在 section 表里还不存在；或者顺序写反了，先往子表插数据，主表却没数据。

解决：所有 INSERT 必须严格按照主表到子表的顺序执行——先插 student、course，再插 section，最后插 enroll。这个报错不是引擎坏了，就是告诉你数据依赖顺序乱了。报告里写 INSERT 样例时，尽量把四张表的插入顺序排成一列，并在注释里标明“先建主表数据，再建子表数据”，这能帮你避掉答辩现场最尴尬的演示事故。

5.3 乱码是玄学吗：MySQL 8 下 utf8 与 utf8mb4 的显示问题

现象：Navicat 查询结果里中文全是“???”，或者“�”，但表结构里的 COMMENT 中文却正常。

原因：数据库是 utf8mb4，但建立数据库连接时没有指定字符集，客户端和服务器之间用了默认的 latin1 或 utf8 传输。MySQL 8.0 默认字符集虽然已经是 utf8mb4，但旧的连接配置仍会把你拉回乱码状态。

解决：连接串里加上 characterEncoding=utf8，并在建库后执行 SET NAMES utf8mb4;。另外要注意 utf8 在 MySQL 里其实不是真正的 UTF-8，它最多存三个字节，像 emoji 这样的四字节字符会直接失败，所以建库语句里用 utf8mb4 而不是 utf8。这不是玄学，是字符集计算问题，排查顺序永远是：库字符集、表字符集、连接字符集、客户端显示设置。

5.4 两个学生同时选同一门课：唯一索引与并发锁

现象：答辩时老师问“两个同学同时选同一门只剩一个名额的课，系统怎么保证不会超选？”你答“用 if 判断剩余名额”，但说不清两个并发请求同时通过 if 判断会发生什么。

原因：应用程序的检查与数据库的写入是两步操作，两个请求可能同时读到“还剩一个名额”，然后同时 UPDATE，把最后一个名额卖出两次。这就是数据库并发锁要解决的问题。

解决：最简单的答案是给 enroll 表加唯一索引，让数据库在写入层直接拒绝重复选课；更完整的思路是在事务里执行 SELECT ... FOR UPDATE 锁定教学班容量行，然后再插入选课记录。课程设计报告里不需要你实现真正的高并发方案，但你要能说清楚“为什么两个请求同时来一定会有一个失败”，以及 InnoDB 的行锁是什么。顺着这个话题往下会被问到死锁：两个事务各自锁了不同教学班，又互相申请对方锁住的数据，就会死锁；InnoDB 检测到死锁会自动回滚一个事务，不需要手动处理。

5.5 ER 图画了七个实体，建表只有五张：连自己都圆不回来

现象：报告第三章的 ER 图里有“学院”“专业”，但下面的建表脚本里没有这两张表，评委问“专业表在哪”，你只能说“暂时用字符串代替”。

原因：画 ER 图时习惯把业务概念画全，建表时又嫌表多麻烦，只挑了核心表落地。

解决：ER 图和表清单必须逐一对应。课程设计规模下，要么把学院、专业从 ER 图里删掉，要么老老实实建出这三张表并用外键关联。我的建议是五张表方案就不要画七张图，图表的自洽比“看起来全面”重要得多。写报告前最后一遍检查方法很土但有效：把每张 ER 图里的矩形框抄到一张纸上，然后和 CREATE TABLE 数量比一遍，多一个少一个都要当场改齐。

6. 验证与演示：用一套最小数据集把报告里的每一条结论钉死

6.1 最小数据集与验证脚本

报告里的 SQL 是不是真的能跑通，取决于你有没有一套完整的测试数据。我每次都会准备一套刚好覆盖核心场景的最小数据集：三个学生、两门课、两个教学班、四条选课记录，其中故意放一个不及格分数，用来验证视图和存储过程的“筛选”能力。

-- 初始化最小测试数据集 INSERT INTO student (student_id, name, gender, birth_date, enroll_year, dept_name, class_name) VALUES ('2023001001', '张伟', '男', '2005-03-12', 2023, '计算机学院', '计科2301'), ('2023001002', '李娜', '女', '2005-07-21', 2023, '计算机学院', '计科2301'), ('2023002001', '王强', '男', '2004-11-02', 2023, '机械学院', '机械2301'); INSERT INTO teacher (teacher_id, name, title, dept_name, office) VALUES ('T001', '刘涛', '副教授', '计算机学院', 'B302'), ('T002', '赵敏', '讲师', '计算机学院', 'B305'); INSERT INTO course (course_code, course_name, credit, hours, course_type) VALUES ('CS101', '数据库原理', 4.0, 64, '必修'), ('CS201', '数据结构', 3.5, 56, '必修'); INSERT INTO section (course_code, teacher_id, semester, capacity) VALUES ('CS101', 'T001', '2024-2025-1', 60), ('CS101', 'T002', '2024-2025-1', 60), ('CS201', 'T001', '2024-2025-1', 60); INSERT INTO enroll (student_id, section_id, score) VALUES ('2023001001', 1, 82.5), ('2023001002', 1, 58.0), ('2023001001', 3, 91.0), ('2023002001', 2, 76.0);

这套数据的妙处在第四条选课记录：王强选了赵老师的 CS101 教学班（section_id=2），而张伟和李娜都在刘老师的班（section_id=1），这样同一个课程号下出现两个教学班的场景就有了真实数据支撑。插入之后，跑一遍 SELECT * FROM v_student_score，应该看到三行成绩；再 CALL proc_fail_students('CS101')，应该只返回李娜一个人，这就能证明视图和存储过程确实是按业务规则在工作的。

6.2 两分钟答辩演示顺序与每步要截的图

演示不需要多，两分钟四步最稳。第一步，SELECT 视图，展示所有学生的成绩汇总，说明视图把四表 JOIN 封装成了一个报表；第二步，调用存储过程，传入门课程号，展示不及格名单，强调参数化查询让教务员不用改 SQL；第三步，重复插入同一条选课记录，让唯一索引报错，证明数据完整性约束不是摆设；第四步，执行 UPDATE 修改一个成绩，再查视图，展示数据联动更新。每一步都要在演示前把截图存好，因为现场可能没有稳定网络环境，本地 MySQL 也偶尔会因为服务没起来而打不开，截图是后悔药。

最后说一个我长期保留的习惯：提交报告之前，把从建库到查询的所有 SQL 按顺序重跑一遍，不要跳步。视图依赖表、存储过程依赖视图，顺序错一步就会报“找不到对象”。有一次我把存储过程写在建表之前，脚本里单独跑没问题，连起来跑就报错，从此我交付前一定会做一次“清库重跑”。这份教务管理系统课程设计的完整链路，说到底是让每个结论都有一次真实执行来兜底。希望帮到你。

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