考试系统（exam_system_ai）完整业务数据流向+表关联关系+业务交互逻辑 全梳理（含多版关系图+最佳实践）

结合考试系统行业最佳实践、这套表结构的字段约束+关联关系，完整的精细化梳理+补全细节+纠错补充+可视化关系图。

---

一、核心前置说明

✅ 业务角色定义（基于user表role字段：ADMIN/TEACHER/STUDENT）

1. 超级管理员(ADMIN)：最高权限，全量操作，包括：用户增删改查、年级/班级/科目基础数据维护、系统参数配置、所有考试/试卷/试题审核、阅卷任务仲裁、数据报表查看；
2. 教师(TEACHER)：核心操作权限，包括：知识点维护、试题创建/编辑、试卷组卷、创建考试、分配阅卷任务、阅卷评分、审核评分结果、查看所教班级学生成绩/知识点掌握情况；
3. 学生(STUDENT)：仅业务操作权限，包括：参加已发布的考试、作答提交试卷、查看个人考试成绩/答题记录/知识点薄弱项、查看试题解析。

✅ 核心优先级规则（你提到的关键规则，表结构已落地）

✅ 试题分值优先级：paper_question.score（试卷-题目关联表的题目分值） > question.score（试题表自身分值）
✅ 所有状态字段都是逻辑软控制，无物理删除，所有业务操作都是基于状态流转，而非删表数据。

---

二、完整业务数据流向（按【业务执行顺序】排序，10大阶段，贴合表关联，精准对应所有表）

✅ 阶段1：【基础字典数据初始化】- 业务根基，无依赖，最先落地

对应表：grade(年级) → classroom(班级) → subject(科目)
核心逻辑：先有年级→再有班级，科目是独立大维度字典，三者都是系统最底层的基础静态数据，无任何业务关联依赖，由【管理员】初始化维护，一次配置长期复用。

• 年级：比如 一年级、二年级、初一、高一 等，grade.grade_name唯一，避免重复；
• 班级：绑定对应年级（classroom.grade_id关联grade.id），比如 高一(1)班、初一(3)班，classroom.class_name唯一；
• 科目：比如 语文、数学、英语、物理，subject.name唯一，是知识点、试题、试卷的核心归类维度。

✅ 阶段2：【用户信息创建与关联】- 基于基础字典，绑定用户归属

对应表：user(用户主表)
核心逻辑：基础字典数据完成后，创建用户，所有用户都绑定归属关系，由【管理员】创建所有角色用户，是所有业务的核心主体表，系统中所有业务操作都围绕用户ID(user.id)展开。

• 学生用户：必须绑定 grade_id(年级ID) + class_id(班级ID)，明确学生的年级班级归属；
• 教师用户：可绑定年级/班级（也可空，比如科任老师），明确授课范围；
• 管理员用户：无年级/班级绑定，全权限；
• 关键字段：user.role 区分角色，user.status 控制账号启用/禁用，user.account 账号唯一不重复。

✅ 阶段3：【知识点体系维护】- 为试题打标签，做试题归类，支撑后续学情分析

对应表：knowledge(知识点表)
核心操作角色：【教师】为主，【管理员】审核；核心逻辑：科目是大分类，知识点是科目下的精细化分类，知识点支持无限级树形结构，你的理解「科目是大的范围，科目下面有多个知识点」完全正确。

• 关联关系：knowledge.subject 关联科目名称、knowledge.subject_id 关联subject.id，一个科目对应多个知识点；
• 树形结构：knowledge.parent_id 实现父子级，parent_id=0是一级知识点（比如：数学→函数），子级是二级知识点（函数→一次函数、二次函数）；
• 业务管控：知识点有审核流程 status(0-待审核/1-通过/2-驳回)，教师创建后需审核通过才能被试题引用；
• 核心价值：试题绑定知识点后，考试结束可精准统计「学生哪些知识点掌握薄弱、哪些知识点正确率高」，这是学情分析的核心数据来源。

✅ 阶段4：【试题库建设】- 基于知识点+科目，构建系统核心题库资源

对应表：question(题目表)
核心操作角色：【教师】创建维护，【管理员】审核；核心逻辑：所有试题都归属「科目」+绑定「知识点」，试题自身带完整属性，形成独立题库，试题库是组卷的核心素材，试题与试卷解耦，一道试题可被多张试卷复用。

• 核心关联：question.subject_id关联科目、question.knowledge_id关联知识点，精准归类；
• 试题属性：自带 type(题型：单选/多选/判断/填空/简答)、difficulty(难度)、answer(标准答案)、analysis(解析)、score(默认分值)；
• 结构化存储：选择题的选项用options(json)格式存储，完美适配多选项场景；
• 审核管控：audit_status 审核状态，审核通过的试题才能被用于组卷；
• ✅ 关键补充：你提到的「试题自身属性」完全覆盖，这是题库的核心价值，无试题则无后续所有业务。

✅ 阶段5：【试卷创建与组卷】- 基于题库，组合形成完整试卷，支持复用

对应表：paper(试卷表) + paper_question(试卷-题目关联表) 【核心关联中间表】
核心操作角色：【教师】创建组卷，【管理员】审核发布；核心逻辑：试卷是试题的组合体，通过中间表实现「多对多」关联，这是考试系统的经典设计，你的理解「基于题型组卷、自动/手动组卷」完全贴合表结构。

• 核心关联逻辑（重中之重）：
  1. paper表：存储试卷的基础信息，包括paper_name(试卷名)、subject(科目)、compose_method(组卷方式：自动/手动)、total_score(总分)、duration(考试时长)；
  2. paper_question：试卷和试题的桥接表，核心字段paper_id关联试卷、question_id关联试题、score是「该试题在本试卷中的分值」；
• 核心规则：paper_question有唯一约束(uk_paper_question) → 同一张试卷中，一道试题只能出现一次，杜绝重复出题；
• 分值优先级落地：试卷中每个题的最终分值，以paper_question.score为准，试题自身的question.score只是默认值，完美解决「同一道题在不同试卷中分值不同」的业务场景；
• 试卷管控：publish_status 发布状态，未发布的试卷不能创建考试，发布后可复用创建多次考试。

✅ 阶段6：【考试创建与发布】- 基于已发布试卷，配置考试规则，发起考试

对应表：mock_exam(考试表) 【考试核心主表】
核心操作角色：【教师】创建，【管理员】审核发布；核心逻辑：试卷是静态资源，考试是试卷的「一次动态使用实例」，一张试卷可创建多次考试（比如：月考、期中、期末都用同一张数学试卷），考试是学生参与答题的核心入口，考试配置了所有答题规则，你的理解「考试有自己的状态、发布、参数设置」完全精准且完整。

• 核心关联：mock_exam.paper_id 关联paper.id，绑定本次考试用哪张试卷；mock_exam.create_by 关联创建人（教师ID）；
• 考试核心配置项（全部在mock_exam表中，你提到的都包含，补充完整）：
  ✔️ 基础参数：total_score(总分)、total_time(考试时长)、start_time/end_time(考试起止时间)；
  ✔️ 答题规则：allow_pause(是否允许暂停)、allow_retake(是否允许重考)、max_attempts(最大考试次数)、auto_save_interval(自动保存间隔)；
  ✔️ 结果展示：real_time_judge(实时判分)、show_analysis(是否显示解析)、show_suggestions(是否显示建议)；
• 考试状态流转（核心业务链路，基于status+publish_status双状态管控）：
  未发布(0) → 发布后未开始(1) → 到时间进行中(2) → 结束后已结束(3)；
• 关键补充：mock_exam.question_ids/json 存储本次考试的试题ID集合，student_ids/json 存储本次考试的考生范围，精准控制「哪些学生能参加本次考试」。

✅ 阶段7：【学生参与考试+答题过程】- 核心业务交互，生成答题原始数据

对应表：exam_screen_record(考试屏幕切换记录) → mock_exam_answer(答题记录表) → mock_exam_record(考试记录表)
核心操作角色：【学生】；核心逻辑：学生进入考试后，系统自动生成考试记录，每答一道题生成一条答题记录，全程监控屏幕切换行为，这三张表是考试过程中实时生成的核心业务数据，是后续评分、统计的唯一数据来源，三者强关联。
✅ 三者关联关系：exam_id(考试ID) + user_id(学生ID) 作为核心关联主键，贯穿始终。

1. mock_exam_record(考试记录表)：【学生进入考试的瞬间，生成1条记录】，1个学生+1次考试，仅生成1条记录，存储考试整体维度数据：开始时间、结束时间、用时、总分、实际得分、考试状态、班级/年级排名等，是学生本次考试的「总台账」；
2. exam_screen_record(屏幕切换记录)：【考试过程中实时生成】，记录学生考试时的页面切换行为（切屏、切窗口），before_position/after_position 存储切换前后的页面位置，是防作弊核心表，无作弊则无数据，有作弊则留痕；
3. mock_exam_answer(答题记录表)：【学生每答一道题，生成1条记录】，1个学生+1次考试+1道题，生成1条记录，存储单题维度的答题详情：用户答案、标准答案、是否正确、得分、答题时间，是客观题自动评分、主观题人工阅卷的核心数据源；
   • 关键字段：is_correct 客观题自动判分后赋值（0错误/1正确），score 客观题自动赋值，主观题初始为0，等待阅卷后更新；
   • 唯一约束：uk_exam_question_user → 杜绝同一题重复答题记录；

• 考试提交：学生提交试卷后，mock_exam_record.status 变为已完成(2)，mock_exam_answer 所有记录状态锁定，不再允许修改答案，答题阶段结束。

✅ 阶段8：【阅卷评分全流程】- 系统最复杂的业务模块，多表协同，人工+质控结合

对应表：marking_task(阅卷任务主表) → marking_task_assignment(阅卷任务分配表) → marking_score(阅卷评分表) → marking_quality_control(阅卷评分质量控制表)
核心操作角色：【教师(阅卷老师/审核老师)】+【管理员(仲裁老师)】；核心逻辑：考试结束后，系统自动创建阅卷任务，管理员/教师分配阅卷任务给指定老师，老师完成评分后，系统自动做评分质控，差异过大则发起仲裁，这四张表是阅卷评分的完整闭环，是主观题（简答/论述）得分的核心来源，也是客观题得分的二次校验，你的理解「阅卷任务分配、多老师评分误差监控」完全精准，且表结构设计了完整的质控体系。
✅ 核心关联主键：exam_id(考试ID) + task_id(任务ID) + question_id(试题ID) + student_id(学生ID) + teacher_id(教师ID)
✅ 阅卷核心前提：客观题（单选/多选/判断/填空）在学生提交试卷后，由系统自动评分，直接写入mock_exam_answer.score和mock_exam_record.actual_score；只有主观题（简答题）需要人工阅卷，这是考试系统的行业最佳实践，极大提升阅卷效率。

阅卷业务完整流转（核心链路，按顺序执行）

1. 创建阅卷任务：考试结束后，创建marking_task，绑定考试ID、任务名称、总试题数、总考生数、分配规则（按试题/考生/混合）；
2. 分配阅卷任务：通过marking_task_assignment将任务分配给指定教师，绑定「教师+试题/考生」，明确该老师需要批阅哪些学生的哪些题，记录应评数量、已评数量、准确率；
3. 教师阅卷评分：老师批阅后，生成marking_score评分记录，存储「试题分值、实际得分、评分意见、评分痕迹」，主观题得分写入该表，同时同步更新mock_exam_answer.score和mock_exam_record.actual_score；
4. 评分质量质控（核心亮点）：系统自动触发质控规则，对「同一道题由两位老师分别评分」的情况，计算score_diff(评分差异)和diff_rate(差异率)，如果is_over_threshold(超出阈值)，则标记为异常，进入仲裁流程；
5. 仲裁处理：管理员指定仲裁老师，填写arbitration_score(仲裁得分)和arbitration_opinion(仲裁意见)，仲裁得分作为最终得分，更新到所有关联表，质控状态改为已解决。

• 评分状态流转：待评分(1) → 已评分(2) → 已审核(3) / 需重评(4)；

✅ 阶段9：【操作日志审计】- 全链路日志，无死角记录所有操作

对应表：operation_log(操作日志表)
核心逻辑：系统中所有用户的所有操作，都会自动生成一条日志记录，无任何业务前置/后置依赖，是独立的审计表，贯穿所有业务阶段。

• 记录内容：操作用户ID/姓名、操作类型、操作内容、目标ID/类型、IP地址、操作状态（成功/失败）、操作时间；
• 核心价值：溯源追责（比如：谁创建了考试、谁批阅的试卷、谁修改了评分）、故障排查，是企业级系统的必备表。

✅ 阶段10：【学情分析+数据统计】- 业务最终价值输出，基于全量业务数据做聚合分析

核心数据来源：全量表的关联聚合，无单独的统计表，而是通过SQL查询+业务层计算生成统计数据；
核心操作角色：【学生】查看个人、【教师】查看班级/年级、【管理员】查看全量；核心逻辑：所有统计分析都是基于前面9个阶段生成的原始数据，通过「知识点、科目、题型、难度、分数段」等维度做聚合计算，这是这套系统的最终业务价值，你的理解完全精准，补充完整统计维度：

✔️ 学生端（个人视角）

• 个人考试总分、排名、用时；
• 错题本：mock_exam_answer.is_correct=0的试题，关联question.knowledge_id查看错题对应的知识点；
• 知识点掌握情况：按知识点维度统计「正确率、错误率」，生成薄弱知识点清单；
• 成绩趋势：按考试时间维度，统计历次考试的总分变化，生成分数趋势图。

✔️ 教师端（班级/年级视角）

• 班级平均分、最高分、最低分、分数段分布（比如：90+、80-90、70-80）；
• 知识点掌握情况：按班级维度统计每个知识点的正确率，精准定位「全班共性薄弱点」；
• 阅卷质量统计：marking_quality_control的差异率、阈值超标率，评估阅卷老师的评分准确性；
• 试题质量分析：按试题维度统计正确率，评估试题难度是否合理。

✔️ 管理员端（全局视角）

• 全系统考试数据汇总、各科目考试参与率、平均分排名；
• 各教师的阅卷效率、评分质量排名；
• 全系统知识点掌握情况，为题库更新、试卷优化提供数据支撑。

---

三、【完整表结构关联关系图】（2个版本，满足你的不同使用场景，全部贴合你的表结构）

✅ 版本一：【业务逻辑关联图（文字层级版）】- 最清晰，适配阅读，精准对应业务流向，推荐优先看

所有表按业务阶段排序，箭头表示【数据流向+关联关系】，括号内是核心关联字段，无任何冗余，100%贴合你的建表语句

基础字典层：grade(年级) → classroom(班级) [grade_id] → subject(科目)
       ↓
用户层：user(用户) [grade_id/class_id]
       ↓
知识点层：knowledge(知识点) [subject_id/creator_id→user.id]
       ↓
试题层：question(试题) [subject_id/knowledge_id/creator_id→user.id]
       ↓
试卷层：paper(试卷) [creator_id→user.id] → paper_question(试卷题目关联) [paper_id/question_id]
       ↓
考试层：mock_exam(考试) [paper_id/create_by→user.id]
       ↓
考试过程层：mock_exam_record(考试记录) [exam_id/user_id] + exam_screen_record(切屏记录) [exam_id/user_id] + mock_exam_answer(答题记录) [exam_id/user_id/question_id]
       ↓
阅卷层：marking_task(阅卷任务) [exam_id] → marking_task_assignment(任务分配) [task_id/teacher_id→user.id] → marking_score(评分记录) [task_id/assignment_id/student_id/question_id] → marking_quality_control(评分质控) [exam_id/task_id/question_id/student_id/teacher1_id/teacher2_id→user.id]
       ↓
审计层：operation_log(操作日志) [user_id]
       ↓
最终输出：学情分析/数据统计（全表聚合查询）

✅ 版本二：【实体关系ER图（结构化完整版）】- 适配画架构图/文档，标准数据库ER图格式，所有表+核心关联+业务说明

核心实体分组+关联规则（标准ER图规范，一对多/多对多标注）

1. 基础模块：grade(1) --n--> classroom(n) 、subject(独立)
2. 用户模块：user(n) --1--> grade(1) 、user(n) --1--> classroom(1)
3. 知识点模块：subject(1) --n--> knowledge(n) 、knowledge(1) --n--> knowledge(n)（父子级）、user(1) --n--> knowledge(n)
4. 试题模块：subject(1) --n--> question(n) 、knowledge(1) --n--> question(n) 、user(1) --n--> question(n)
5. 试卷模块：user(1) --n--> paper(n) 、paper(1) --n--> paper_question(n) 、question(1) --n--> paper_question(n) 【试卷-试题 多对多，通过中间表关联】
6. 考试模块：paper(1) --n--> mock_exam(n) 、user(1) --n--> mock_exam(n)
7. 答题模块：mock_exam(1) --n--> mock_exam_record(n) 、user(1) --n--> mock_exam_record(n)
mock_exam(1) --n--> mock_exam_answer(n) 、user(1) --n--> mock_exam_answer(n) 、question(1) --n--> mock_exam_answer(n)
mock_exam(1) --n--> exam_screen_record(n) 、user(1) --n--> exam_screen_record(n)
8. 阅卷模块：mock_exam(1) --n--> marking_task(n) 、marking_task(1) --n--> marking_task_assignment(n) 、user(1) --n--> marking_task_assignment(n)
marking_task_assignment(1) --n--> marking_score(n) 、marking_score(n) --1--> marking_quality_control(n)
9. 日志模块：user(1) --n--> operation_log(n)

---

四、【核心业务补充+最佳实践】（贴合你的表结构，无额外设计，纯优化建议）

✅ 你理解的内容100%正确，补充2个你没提到但表结构已落地的核心亮点

1. 阅卷双盲评分+质控仲裁：marking_quality_control表是这套系统的核心亮点，采用「两位老师独立评分，系统自动计算差异率，超标则仲裁」的模式，这是正规考试的行业标准阅卷流程，避免单老师评分的主观偏差，保证评分公平性；
2. 考试防作弊体系：exam_screen_record表记录切屏行为，结合mock_exam的auto_save_interval自动保存，避免学生切屏作弊后丢失答案，同时留痕可追溯，是在线考试的必备能力。

✅ 最佳实践建议（基于你的表结构，无需改表，仅业务层优化）

1. 客观题自动评分优先级：学生提交试卷后，先执行mock_exam_answer的自动判分，将is_correct和score赋值，再生成阅卷任务，只对主观题分配人工阅卷，提升效率；
2. 知识点统计维度：所有统计都基于knowledge.id，而非subject，因为知识点是精细化分类，能精准定位学生的薄弱项，这是学情分析的核心价值；
3. 数据归档策略：考试结束后，将mock_exam_answer、exam_screen_record的历史数据归档，保留mock_exam_record的核心数据，提升查询性能。

---

总结

这套表结构的设计逻辑就是按照如下思路落地的，从基础字典→用户→知识点→试题→试卷→考试→答题→阅卷→统计，形成了完整的闭环业务链路，所有表之间的关联都是通过「主键ID」做精准关联，无任何数据孤岛，所有业务操作都有迹可循、有数据可查，是一套设计规范、贴合业务、具备企业级使用能力的考试系统表结构。