MySQL学生成绩管理系统：数据库设计与Flask实现

简介这份资源是面向高校数据库课程设计场景的MySQL学生成绩管理系统课程设计报告适合正在完成数据库课设、需要参考完整项目文档与实现思路的计算机相关专业学生。报告以Python Flask搭配MySQL、前端采用HTMLCSSJS的前后端分离方案为基础围绕管理员、教师、学生三类角色展开涵盖系统总体设计、需求分析、概要设计、系统实现与测试总结等章节具体涉及功能结构设计、数据库概念与逻辑结构设计、物理设计、界面设计及主要功能程序代码并附有测试与总结内容可帮助读者理解成绩录入、修改、删除、查询及学生选课、成绩查看等模块的落地方式。资源包共1个doc文件大小约3.95MB以课程设计报告文档形式呈现目录层次清晰便于按章节检索。目前已有5074人学习下载适合需要参照完整课设文档结构、梳理数据库设计与Flask实现思路的读者使用。1. 从一份“能跑就行”的课设说起MySQL 学生成绩管理系统要解决什么每到期末教务口最头疼的不是考试本身而是考完那一周的成绩统计三个年级、十几个专业、几十门课成绩散在任课老师的 Excel 里汇总靠人工复制粘贴改一个分数要连带改三张表错一个学号就得翻半天。这份 MySQL 学生成绩管理系统就是冲着这个场景来的——用 Python Flask MySQL 把成绩的录入、修改、删除、查询、统计收进一个单机可跑的系统里分管理员、教师、学生三类角色各管各的一摊事。它适合正在做数据库课设、课程设计的学生直接照着搭结构也适合需要一份能交付的成绩管理原型的从业者参考。下面按需求、设计、实现、避坑、验收的顺序把这份方案拆开讲透。2. 需求与角色边界三类用户各自能碰什么数据2.1 业务需求先落到角色权限上做课设最容易翻车的地方是一上来就画页面、写登录结果做到一半发现“教师能不能删学生”这种问题没想清楚代码里到处打补丁。这份方案的做法是先把三类角色的权限边界钉死再谈实现。管理员是唯一拥有全量增删改查的角色管学生、教师、课程、专业、专业选课五类数据教师只能看自己的信息、自己教的课程、选课学生名单并对成绩做录入和修改外加查看分数段统计学生只能看自己的信息、自己选的课和成绩以及改密码。注意这里有个容易被忽略的设计点学生没有“选课”的写权限选课关系是由管理员维护的“专业选课”表通过触发器批量生成的学生端只读。这个决定直接影响了后面数据库的设计也是这份方案里比较聪明的一处。把权限表先写出来后面每个接口的鉴权就有依据角色可读数据可写数据登录账号管理员全部学生/教师/课程/专业/专业选课admin教师本人信息、所教课程、选课学生及成绩所教课程的成绩教师编号学生本人信息、所选课程及成绩仅本人密码学号这张表看着简单但它决定了后端每个路由要不要加角色判断。我一般会在 Flask 里用一个装饰器统一处理而不是在每个视图函数里手写 if否则后期加角色就是灾难。2.2 数据需求与实体关系业务需求理清后数据需求自然浮出来。系统涉及的核心实体是学生、教师、课程、专业、管理员加上两张联系表学生选课学号 课程编号 成绩和专业选课专业编号 课程编号。实体之间的联系是一个专业有多名学生一名学生属于一个专业一名教师教多门课程一名学生选多门课一门课被多名学生选成绩挂在“学生—课程”这个联系上。这里要强调一个概念结构设计上的取舍成绩不放在学生表也不放在课程表而是作为学生选课表的属性。原因是成绩的本质是“某个学生某门课的结果”是联系属性而非实体属性。很多同学图省事把成绩塞进学生表结果一个学生只能存一门课的成绩做到统计功能时直接卡死。E-R 图里把成绩画在“学生—课程”的菱形联系上转成关系模式就是 student_course(student_id, course_id, grade)这个判断是整份数据库设计的地基。3. 数据库设计七张表与一个触发器的落地细节3.1 逻辑结构到物理表结构概念模型转关系模式后物理设计要落到字段类型、主外键和约束上。这份方案共七张表student、teacher、course、major、admin、student_course、major_course。字段设计上有几个值得说的点学号用 char(10)、教师编号 char(5)、专业编号 char(3)都是定长数字串用 char 比 varchar 更贴合“编号”语义密码字段统一 varchar(128)为后面存哈希留足空间成绩用 tinyint unsigned天然限制在 0~100省掉一层应用层校验。建表顺序有讲究必须先建被引用的主表再建带外键的从表。下面是核心建表语句注意外键上的 on delete cascade它保证了删专业时该专业学生和选课记录跟着清理避免脏数据create database grade_manage_system; use grade_manage_system; -- 专业表先建学生表要引用它 create table major( major_id char(3) primary key, major_name varchar(20) not null unique ); create table student( student_id char(10) primary key, student_name varchar(20) not null, sex char(2), birth_year char(4), province varchar(20), enter_year char(4) not null, major_id char(3) not null, password varchar(128) not null ); alter table student add foreign key (major_id) references major(major_id) on delete cascade; create table teacher( teacher_id char(5) primary key, teacher_name varchar(20) not null, sex char(2), birth_year char(4), password varchar(128) not null ); create table course( course_id char(5) primary key, course_name varchar(20) not null, year char(4) not null, semester char(2) not null, teacher_id char(5) not null, credit tinyint unsigned not null ); alter table course add foreign key (teacher_id) references teacher(teacher_id) on delete cascade;参数说明char 定长适合编号类字段查询时不用处理变长开销tinyint unsigned 的取值范围 0~255用来存学分和成绩都够用且自带下界约束on delete cascade 是双刃剑删专业会连带删学生做演示时很爽但真实教务场景里通常要改成 restrict 防止误删课设阶段用 cascade 可以少写很多清理逻辑这一点要在报告里说明取舍。3.2 联系表与触发器自动选课两张联系表是这套设计的重点。student_course 用 (student_id, course_id) 做联合主键天然防止同一学生重复选同一门课major_course 同样用联合主键。真正让这套方案“有点东西”的是原文里那个 after insert 触发器管理员往专业选课表里加一条“某专业选某课”触发器自动把这个专业下所有学生批量插入学生选课表成绩先置空。create table major_course( major_id char(3), course_id char(5) ); alter table major_course add primary key (major_id, course_id); alter table major_course add foreign key (major_id) references major(major_id) on delete cascade; alter table major_course add foreign key (course_id) references course(course_id) on delete cascade; create table student_course( student_id char(10), course_id char(5), grade tinyint unsigned ); alter table student_course add primary key (student_id, course_id); -- 专业选课后自动为该专业全体学生生成选课记录 delimiter // create trigger trigger_insert_1 after insert on major_course for each row begin insert into student_course(student_id, course_id, grade) select student_id, new.course_id, null from student where major_id new.major_id; end// delimiter ;这段触发器的逻辑是new.major_id 拿到刚插入的专业编号子查询捞出该专业所有学号拼上 new.course_id 批量写入。它把“专业选课”和“学生选课”两个动作合并成一次操作管理员不用手动给几百个学生逐个选课。注意 delimiter 的用法触发器体里有分号不换分隔符 MySQL 会在第一个分号处截断这是新手最常踩的语法坑。另外触发器只处理 insert如果管理员删掉一条专业选课对应的学生选课记录不会自动删这个不对称要在文档里写清楚或者补一个 after delete 触发器。4. 后端实现Flask 路由、鉴权与成绩统计4.1 登录鉴权与角色分流后端用 Flask 组织前后端分离接口用 Postman 测。登录接口接收角色、账号、密码三个参数按角色去不同表校验成功后把用户标识和角色写进 session。这里的关键设计是三类用户存在三张表里账号体系不统一所以登录必须先知道角色不能只凭账号去猜。初始密码规则也要在文档里写明——学生和教师初始密码等于自己的编号管理员固定账号密码且不可改。from flask import Flask, request, session, jsonify import pymysql app Flask(__name__) app.secret_key grade_system_key def get_conn(): # 单机课设直接连本地库生产环境应改为连接池 return pymysql.connect(hostlocalhost, userroot, passwordyour_pwd, databasegrade_manage_system, charsetutf8mb4) app.route(/login, methods[POST]) def login(): role request.json.get(role) uid request.json.get(uid) pwd request.json.get(pwd) table {student: (student, student_id), teacher: (teacher, teacher_id), admin: (admin, admin_name)}[role] conn get_conn() cur conn.cursor() # 参数化查询杜绝拼接 SQL 带来的注入风险 cur.execute(fselect password from {table[0]} where {table[1]}%s, (uid,)) row cur.fetchone() conn.close() if row and row[0] pwd: session[uid] uid session[role] role return jsonify({code: 0, msg: ok}) return jsonify({code: 1, msg: 账号或密码错误})这段代码里表名是白名单映射出来的不是用户输入直接拼的所以 f-string 拼表名是安全的真正来自用户的 uid 走 %s 参数化。密码这里为了课设演示用了明文比对实际交付时应该用 werkzeug 的 generate_password_hash 存哈希登录时 check_password_hash 比对字段留了 varchar(128) 就是为这个准备的。session 里存角色后续每个接口开头判断 session.get(role) 是否匹配不匹配直接返回 403。4.2 教师端成绩录入与分数段统计教师端最核心的两个功能是改成绩和看统计。改成绩是一条 update统计则用一条带 case when 的聚合 SQL 一次算出各分数段人数比在 Python 里循环计数高效得多也更能体现数据库课设该有的 SQL 功底。app.route(/teacher/grade, methods[POST]) def update_grade(): if session.get(role) ! teacher: return jsonify({code: 403}), 403 sid request.json.get(sid) cid request.json.get(cid) grade request.json.get(grade) conn get_conn() cur conn.cursor() cur.execute(update student_course set grade%s where student_id%s and course_id%s, (grade, sid, cid)) conn.commit() conn.close() return jsonify({code: 0}) app.route(/teacher/stat/cid) def grade_stat(cid): conn get_conn() cur conn.cursor() cur.execute( select sum(grade 90) as excellent, sum(grade between 80 and 89) as good, sum(grade between 70 and 79) as medium, sum(grade between 60 and 69) as pass, sum(grade 60) as fail from student_course where course_id%s , (cid,)) row cur.fetchone() conn.close() keys [excellent, good, medium, pass, fail] return jsonify(dict(zip(keys, row)))统计 SQL 里 sum(条件) 的写法利用了 MySQL 中布尔表达式返回 1/0 的特性五个分数段一次扫描出结果比五次 count 查询少扫四遍表。参数 cid 从 URL 取走参数化。这里有个细节grade 为 null 的记录还没录成绩在 sum 里按 0 计不会污染统计但如果要统计“已录入人数”得额外加 count(grade)。教师端页面上的“查看详情”和“查看统计”两个按钮背后就是这两个接口。5. 避坑与排查课设里最容易翻车的五个点5.1 触发器不生效或只执行一半现象是管理员加了专业选课学生选课表却没数据。原因通常是 delimiter 没改触发器体在第一个分号被截断或者触发器建在了错误的库上。解决方法是建触发器前先 use 目标库用 delimiter // 包裹整个 begin...end建完再改回 delimiter ;然后用 show triggers 确认它挂在 major_course 表上。5.2 外键约束导致建表失败现象是执行建表语句报 1215 或 1452。原因是建表顺序反了先建了引用方、后建被引用方或者外键字段类型和主表不一致比如主表 char(3)、从表 varchar(3)。解决方法是严格按 major → student、teacher → course、再联系表的顺序建字段类型逐字对齐必要时先建表再 alter add foreign key。5.3 中文乱码现象是学生姓名、专业名存进去变成问号。原因是连接字符集和表字符集不一致。解决方法是在建库时指定 character set utf8mb4PyMySQL 连接参数里带 charsetutf8mb4前端页面 meta 声明 UTF-8三处统一缺一处就乱。5.4 密码明文与初始密码规则混乱现象是学生改完密码登不上或者教师初始密码对不上。原因是初始密码规则没统一学生用学号、教师用编号、管理员固定值改密码时又没校验旧密码。解决方法是在文档里把三类初始密码写死改密码接口强制校验旧密码并做两次新密码一致性检查存储层预留哈希字段。5.5 统计结果对不上人工核算现象是教师看分数段人数和实际名单不符。原因多半是 grade 为 null 的记录被算进了某个区间或者同一学生同一课程存在重复行。解决方法是先查 select count(*) 和 count(grade) 是否相等确认空值数量再用联合主键约束保证不重复统计口径在报告里写清楚“未录入不计入任何分数段”。6. 验收与答辩怎么证明这套系统真的能交付验收这一步很多同学栽在“功能都能点但说不清为什么这么设计”。我的建议是把验收拆成三层逐层过。第一层是数据层验收直接在 MySQL 命令行跑几条 SQL 自证show tables 确认七张表齐全select 查一遍外键约束是否生效试着删一个有学生的专业看是否级联往 major_course 插一条记录再查 student_course 看触发器是否批量生成。这一层能挡住大部分“数据库设计不过关”的质疑。第二层是接口层验收用 Postman 按角色跑通主流程管理员登录 → 加专业 → 加学生 → 加课程 → 加专业选课教师登录 → 查课程 → 改成绩 → 看统计学生登录 → 看成绩 → 改密码 → 用新密码重登。每个接口记录请求参数和返回码整理成一张验收表验收项操作预期结果判定角色隔离学生 session 调教师改成绩接口返回 403通过/不通过触发器插入专业选课学生选课表新增对应行通过/不通过级联删除删除有学生的专业学生及选课记录同步删除通过/不通过统计准确构造 5 个分数段样本各段人数与手工核算一致通过/不通过第三层是答辩话术。老师最爱问的三个问题基本固定为什么成绩放在联系表而不是学生表、触发器解决了什么手工操作、外键 cascade 在真实场景是否合适。前两个照第 3 章的设计取舍答第三个要主动承认 cascade 在课设里图方便、生产环境应改 restrict 并加软删除这种“知道边界在哪”的回答比硬撑更加分。演示时按角色顺序走一遍别跳着点让评委看到权限是真的隔离的。血泪经验是答辩前一定用一份全新的空库从建表脚本重跑一遍我见过太多人本地库改乱了、脚本却跑不通现场重建直接卡住。从那以后我每次交课设前都强制走一遍“删库—跑脚本—灌测试数据—全流程点一遍”的流程宁可多花二十分钟也不在台上赌运气。希望这套结构和验收方法能帮到你照着改改就能变成你自己的方案。本文还有配套的精品资源点击获取