Django教师教学质量评价系统：ORM建模、权重计算与MySQL迁移

简介：基于Python+Django的教师教学质量评价系统毕业设计项目，面向需要完成毕业设计、期末大作业或课程设计的Python学习者和开发者，也适合想通过实战快速上手Django的初学者。项目围绕教学质量评价的核心流程，将前端展示、后端业务与数据存储整合，可直接运行并二次开发。资源包共134个文件，压缩后约3.78MB，主要包含HTML页面、Python源码、CSS/JS静态资源、SQL/SQLite数据库及项目配置文件；其中HTML页面覆盖基础模板与评价页面，Python源码承担业务逻辑与数据处理，数据库文件方便本地调试，整体结构精简。目前已有264人学习下载，该项目经老师指导并通过，属于高分毕业设计范例。对于学习者而言，既可借此掌握Django模型-视图-模板的开发思路，也可参考其目录划分和前后端交互方式，作为大作业或课程设计的代码蓝本与排错参考。

1. 教师教学质量评价系统到底在做什么：从毕业设计题目到可落地的评价闭环

如果你打开这个标题的压缩包，看到的不是一份“点几下就能跑”的网页，而是一个包含Django项目源码、SQLite或MySQL数据库以及项目说明文档的完整工程。教师教学质量评价系统，本质上要解决一个很具体的业务问题：学期末几百个学生要打分、几十位督导和同行要提交评价表、教务处要在一个月内按教师汇总排名并生成报表。手工用Excel汇总的痛点是，数据对不上、权重算错、教师来质疑结果时拿不出明细。用Python和Django做这套系统，就是把“评价方案的业务逻辑”翻译成“ORM模型、视图函数和查询语句”，让评价、汇总、导出这条链路可以重复跑，且每一份原始评分都留底。

这套系统适合两类人：一类是计算机相关专业的毕业生，需要把业务场景做成可演示、可答辩的课题；另一类是想用最小成本给院系做内部评价工具的工程人员。标题里“源码+数据库”的意思是，项目包已经替你完成了数据建模和基础功能开发，你拿到后有两条路：直接部署使用，或者在自己可控的费用和时间内，把它改成你的评价方案。先说结论：这类系统的核心不在页面好看，而在“评价方案能不能被数据模型稳定表达”，这是一切后续代码的前提。

2. 先建模再写代码：评价方案的数据模型与权重设计

2.1 评价主体与评价表怎么分：学生、督导、同行到底谁评谁

任何一个教学评价系统，开工前必须先回答“谁评谁、多久评一次、评完怎么汇总”。最常见的评价方案是三类主体：学生评教、督导评教、同行（教师互评）评教。三者的评价指标不同、权重不同、频次也不同——学生通常每学期对每门课评一次，督导随机听课打分，同行在一个系内部互评。如果你的毕业设计直接用现成源码，却不知道这三类主体背后的逻辑，后面改需求就会处处受限。

在Django里，评价主体不要做成“一个用户的角色字段”，而要把“评价方案”做成一等公民。我一般会先设计一张评价方案表，再设计一张方案明细表：

class EvaluationScheme(models.Model): name = models.CharField(max_length=128) # 方案名称，比如"2024-2025-1学生评教" evaluator_type = models.CharField(max_length=20) # 评价主体：student/supervisor/peer target_type = models.CharField(max_length=20) # 被评对象：teacher/course weight = models.DecimalField(max_digits=5, decimal_places=2) # 本方案占总评权重 start_time = models.DateTimeField() end_time = models.DateTimeField() status = models.CharField(max_length=10, default="draft") # draft/ongoing/finished created_at = models.DateTimeField(auto_now_add=True) class EvaluationItem(models.Model): scheme = models.ForeignKey(EvaluationScheme, on_delete=models.CASCADE, related_name="items") content = models.TextField() # 指标内容，如"教学态度认真，备课充分" full_score = models.IntegerField(default=5) # 该指标满分 score_type = models.CharField(max_length=10) # score_1_to_5 / score_100 / text sort_order = models.IntegerField(default=0) # 指标排序

逻辑说明：EvaluationScheme定义了“一次评价活动”，EvaluationItem定义这次活动里有哪些指标。这样做的好处是，下学期换一套指标体系时，不需要改代码，只要库里新增一条方案记录。weight字段放在方案表上，而不是指标表上，因为权重是“学生评教占总评多少、督导占多少”，不是每个指标自己带权重——后面汇总时，先算每个方案的平均分，再乘各自的权重，最后相加。

参数说明：score_type我建议至少支持1_to_5和100两种，因为很多学校督导评教用百分制，学生评教用五级制。如果你只做了单选或者文本框，答辩时容易被问“为什么不能扩展”。full_score和score_type配合，前端渲染时就能自动判定是横向单选、下拉还是输入框。

2.2 权重、指标体系与计算逻辑：分数从哪里来

权重是毕业设计答辩时最容易被追问的部分。你需要提前问清楚：你们学校是“学生评教占60%、督导占30%、同行占10%”，还是“学生评教作为参考，督导有一票权”？同一个源码，两种方案的汇总逻辑完全不同。常见做法是，把权重放在方案表上，汇总时按方案分组算平均，再按权重合成总分。

拿学生评教举例，一次学生评教往往有5到8个指标，最终这个教师的“学生评教得分”是这些指标的平均分。督导评教类似，但可能每个督导只听了某一节课，需要对同一教师的多次督导打分取平均。这里有一个很容易算错的地方：平均分应该按“教师-课程”维度还是直接按“教师”维度算？我建议按教师维度算。

# 按方案分组，计算每位教师在某个方案下的平均分 from django.db.models import Avg def calc_scheme_average_score(scheme_id): rows = EvaluationRecord.objects.filter(item__scheme_id=scheme_id).values( "teacher_id" ).annotate(avg_score=Avg("score")) return {row["teacher_id"]: row["avg_score"] for row in rows}

逻辑说明：EvaluationRecord是评价记录表，里面存的是每条打分明细——谁在哪个方案、对哪位老师、哪个指标、打了多少分。按teacher_id分组后Avg("score")，拿到的就是这位老师在该方案下的平均分。注意这里用的是Avg而不是Sum，因为指标总分是5分制，且每个方案下学生对同一老师的指标数是一样的，平均和加权的结果一致；但如果两个方案指标数量不同，就必须先标准化再汇总。

参数说明：上面代码只返回平均值，实际系统里建议同时把评价人数Count("id")查出来，用来做“参评率”统计。答辩时老师大概率会问：“如果某老师只有一个学生参与评价，和另一个老师有50个学生参与评价，结果能直接比吗？” 这就引出修正公式——经典做法是final_score = avg_score * (actual_count / expected_count)，把人数不足的情况拉低分数。你的系统里只要有参评率字段，就能给出这个解释，不然就是纯展示一个平均分，业务上站不住脚。

2.3 建表落地：核心模型设计与关键字段说明

上面涉及的模型如果在源码里都有，你只需要确认表结构是否匹配；如果源码里没有，你需要把下面这几张表补全。除了方案表、指标表、记录表，一个完整的评价系统还需要教师表、学生表/督导表（一般用Django自带的User表加一个user_type字段）、课程表、评价任务表（记录某教师在某个方案下被哪些人评过，防止重复提交）。

评价记录表是所有表里最关键的一张，需要仔细设计。

class EvaluationRecord(models.Model): scheme = models.ForeignKey(EvaluationScheme, on_delete=models.CASCADE) item = models.ForeignKey(EvaluationItem, on_delete=models.CASCADE) teacher = models.ForeignKey(Teacher, on_delete=models.CASCADE) course = models.ForeignKey(Course, on_delete=models.CASCADE, null=True, blank=True) evaluator = models.ForeignKey(User, on_delete=models.CASCADE) score = models.DecimalField(max_digits=5, decimal_places=2) comment = models.TextField(blank=True) submit_time = models.DateTimeField(auto_now_add=True) class Meta: unique_together = ("item", "evaluator", "teacher", "course")

参数与逻辑说明：unique_together防止同一个学生对同一门课的同一个指标重复打分——这是去重的最低要求。course允许为空，因为督导评教可能只针对教师不针对课程。comment字段存文字评语，很多设计方案把它和省掉，答辩时如果被问到“如何存储学生的主观意见”，就露馅了。score用DecimalField而不是FloatField，因为浮点累加会出现 0.1+0.2 不等于 0.3 的问题，汇总成绩时一个小小的精度误差到公示环节就会被放大成教学事故。

数据库选型方面，源码里如果是SQLite，开发期完全够用，但你要在文档里写明“生产部署建议迁移到MySQL”。Django基本不需要改模型代码，只需要改settings.py里的数据库连接配置和执行一次migrate。如果答辩环境要求MySQL，但你现在只有SQLite，后面第5章会讲到迁移验证的方法。

3. 用 Django 把系统跑起来：项目骨架、评价流程与关键代码

3.1 项目起步：Django 项目与 app 的最小分层

拿到源码后，第一件事不是马上python manage.py runserver，而是先确认Django版本和Python版本的配对关系。多数毕业设计源码基于 Django 2.x 或 3.x，如果你本机装的是 Django 5.x，urls.py里的url()写法会报错。建议直接用项目自带的requirements.txt安装依赖。

python -m venv venv source venv/bin/activate # Windows 下是 venv\Scripts\activate pip install -r requirements.txt python manage.py migrate python manage.py runserver

逻辑说明：前三步把Python环境隔离到当前目录，避免污染全局环境；migrate按模型生成数据库表；runserver是Django自带的开发服务器，调试阶段不用配Nginx和uWSGI。如果migrate报错，先看是不是requirements.txt装到的版本和源码不匹配。

参数说明：Django 4.x 及以上要求 Python 3.8+，Django 3.x 支持 Python 3.6—3.10。不要强行用最新版Django跑老源码，那等于给自己找翻车的理由。如果requirements.txt缺失，先看settings.py里django.__version__或源码里urls.py的写法来判断版本号。

3.2 评价任务发布到评分提交：一条链路的关键视图

系统的主干功能是：管理员创建评价任务 → 学生登录看到待评课程列表 → 逐项打分并提交 → 系统校验是否重复提交 → 教师登录查看自己的得分。下面这段代码聚焦在“学生提交评分”的核心视图上，这是业务逻辑最集中的地方。

from django.views.decorators.http import require_POST from django.shortcuts import get_object_or_404 from django.core.exceptions import ValidationError @require_POST def submit_evaluation(request, record_id): if not request.user.is_authenticated: return JsonResponse({"code": 401, "msg": "请先登录"}, status=401) task = get_object_or_404(EvaluationTask, id=record_id) if task.scheme.status != "ongoing": return JsonResponse({"code": 400, "msg": "当前不在评价时间范围内"}) existing = EvaluationRecord.objects.filter( evaluator=request.user, teacher=task.teacher, course=task.course, scheme=task.scheme, ).first() if existing: return JsonResponse({"code": 400, "msg": "你已经提交过该教师的评价"}) scores = request.POST.getlist("scores", []) for item in task.scheme.items.all().order_by("sort_order"): if item.is_required and str(item.id) not in [s.split("_")[1] for s in scores]: return JsonResponse({"code": 400, "msg": "存在未完成的评价项"}) EvaluationRecord.objects.create( scheme=task.scheme, item=item, teacher=task.teacher, course=task.course, evaluator=request.user, score=float(scores[i]), ) task.submitted = True task.save() return JsonResponse({"code": 200, "msg": "提交成功"})

逻辑说明：这个视图做了三件必要的事——状态检查、去重检查、逐项落库。EvaluationTask是评价任务表，它把“某教师在某课程下要被哪些人评”这件事实例化；没有它，你很难判断“这个学生到底该不该评这位老师”。scores用request.POST.getlist而不是get，因为指标是多项的。提交前先查EvaluationRecord是否有当前用户在相同scheme、teacher、course下的记录，一旦有就拒绝，保证同一学生不会对同一门课评两次。

参数说明：@require_POST直接挡掉GET请求，避免有人通过URL带参数伪造提交。getlist("scores")拿到的表单数据格式是index_指标ID，后续创建记录时才不会指标准位错序。注意这里的scores列表和task.scheme.items.all()的顺序必须一致——如果前端模板里指标已经按sort_order渲染，那么后端这里最好也按sort_order取指标列表，否则会张冠李戴。

3.3 数据统计与导出：把评价结果变成可用的表格

评分提交进入库之后，接着是汇总。汇总输出一般分两级：教师个人明细（每个指标的分项均分+评语列表）和全院汇总排名（总分、排名、参评率、各分项明细）。很多毕业设计做到提交就停了，而答辩时老师一定会问：“这个数据怎么导出来给教务处？” 下面是一个用Django输出Excel的经典做法。

import openpyxl from django.http import HttpResponse def export_teacher_score(request, teacher_id): teacher_avg = EvaluationRecord.objects.filter( teacher_id=teacher_id, ).values("item__content").annotate(avg=Avg("score")) wb = openpyxl.Workbook() ws = wb.active ws.title = "评教明细" ws.append(["指标内容", "平均分"]) for row in teacher_avg: ws.append([row["item__content"], round(row["avg"], 2)]) resp = HttpResponse( content_type="application/vnd.openxmlformats-officedocument.spreadsheetml.sheet" ) resp["Content-Disposition"] = f'attachment; filename="teacher_{teacher_id}_score.xlsx"' wb.save(resp) return resp

逻辑说明：values("item__content")按指标分组，annotate(avg=Avg("score"))计算每个指标的均分。这是Python里最常见的分组聚合写法，翻译成SQL就是SELECT content, AVG(score) FROM record GROUP BY content。openpyxl负责把结果写入Excel，HttpResponse指定Content-Disposition让浏览器触发下载。

参数说明：如果你想导出全院的汇总排名，把filter(teacher_id=...)换成values("teacher_id").annotate(avg=Avg("score"), cnt=Count("id")).order_by("-avg")，再逐个教师生成Sheet或者在同一个Sheet里逐行追加。round(..., 2)在导出前保留两位小数，避免Excel显示超长浮点数。这里有一个坑：Avg("score")返回的是Decimal对象，openpyxl写入Excel时偶尔会因为单元格格式报错，如果遇到，用float(round(row["avg"], 2))显式转换一下。

# 片段：用于教师端展示个人得分（含参评率） def teacher_dashboard(request, teacher_id): total_schemes = EvaluationScheme.objects.exclude(status="draft") for s in total_schemes: records = EvaluationRecord.objects.filter(teacher_id=teacher_id, scheme=s) avg = records.aggregate(avg=Avg("score"))["avg"] # 参评率：实际参评人数 / 该教师应被评人数 actual = records.values("evaluator").distinct().count() print(s.name, avg, actual)

逻辑说明：这里演示的是“按方案名遍历并分别计算平均值和参评人数”。实际系统里建议一次性用Prefetch或annotate查完，不要在视图里循环查询数据库，否则学期末数据多时会卡掉页面。这个片段的价值只有一点——让学生认识到“平均分高不代表排名高，人数少的老师分数往往虚高，需要修正”，这是答辩时展示你对业务理解的加分点。

4. 评价系统避坑：数据库设计与 Django 实战的 5 个高频问题

这套系统最典型的翻车点集中在重复提交、分数制混用和迁移文件缺失上面。前两个属于业务逻辑的坑，新增字段能补；最后一个属于工程化管理的坑，需要从一开始就检查压缩包的结构。拿到源码后，第一步先看manage.py是否存在，第二步看settings.py里的INSTALLED_APPS和数据库配置，第三步再谈功能。

有一个血泪经验：很多源码包喜欢把migrations文件夹清空后再压缩，以为能“减少体积”。结果导致新手一migrate就报错，然后开始在models.py上疯狂改动、越改越乱。拿到包后如果migrations目录为空或缺失，不要去翻models.py找问题，直接makemigrations重新生成。

数据库的另一个坑是中文编码。SQLite天生支持UTF-8，但MySQL如果库表字符集是latin1，Django写入中文评语时会报Incorrect string value。解决办法是在settings.py的数据库配置里加OPTIONS指定charset = utf8mb4，同时确认数据库本身的character-set-server是utf8mb4。作为毕业设计，建议文档里写清楚这一点，答辩时提到就能证明你真的部署过，而不是只看了PDF教程。

5. 从源码到自己的毕设：验证、改造与提交前的实用技巧

如果你用的是现成的“源码+数据库”压缩包，那么离合格交付还有几步路。先把源码跑起来，导入数据库，用测试账号创建一次完整的评价流程——从方案发布到学生打分、再从教师登录查看结果、最后导出Excel。把这四条链路走通，项目的可信度才落得住。如果其中任何一步报错，优先检查settings.py的数据库配置和INSTALLED_APPS，八成是这两处的版本或注册问题。

源码改造的价值点在答辩的口头汇报。光复现项目原流程是不够的，你需要给它加一个让答辩组能记住的功能。最常见的低成本改造方向是“导出带图表的总评PDF”或“多维度对比雷达图”。下面给出一个用Django自带模板配合matplotlib生成成绩趋势图的实例，适合放在“系统扩展”章节。

import matplotlib matplotlib.use("Agg") import matplotlib.pyplot as plt import io, base64 def teacher_trend_chart(request, teacher_id): records = EvaluationRecord.objects.filter(teacher_id=teacher_id).values( "scheme__name" ).annotate(avg=Avg("score")) names = [r["scheme__name"] for r in records] values = [float(r["avg"]) for r in records] fig, ax = plt.subplots() ax.bar(names, values, color="#4C72B0") ax.set_ylabel("平均分") ax.set_ylim(0, max(values) * 1.2) buf = io.BytesIO() plt.savefig(buf, format="png") buf.seek(0) uri = base64.b64encode(buf.read()).decode("ascii") plt.close(fig) return JsonResponse({"chart_uri": f"data:image/png;base64,{uri}"})

技巧说明：matplotlib.use("Agg")是指定后端为无界面模式，服务器上没有显示屏幕也不报错。io.BytesIO把图片写入内存，base64编码后内嵌到前端img标签里，省去配置静态文件服务的麻烦。这里用values(...).annotate(Avg(...))一次取回数据，不需要循环数据库。

我个人的习惯是，在答辩前三天，把项目的README.md重写一遍。写清三件事：项目跑起来的命令、数据库的所有表和核心字段说明、以及如何定制自己的评价指标和权重。不要写“本系统功能完善、操作简单”，只写可复现的操作和一路踩过的坑。很多平时做得很好的项目，就败在答辩时对方看不到你的判断和取舍——写出你从SQLite迁到MySQL的过程，写出你发现5分制与100分制混用的bug并修好的过程，这比任何功能列表都加分。希望这篇笔记能帮你在复现和改造这套系统时少走弯路。

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