这个模板适合做什么
给要为学校/教务系统画数据库 ER 图的开发者、数据库设计师、计算机专业学生和学校 IT 老师——不用打开付费建模工具。这份学校管理系统数据库设计模板给你一份可直接编辑的表结构，覆盖教务系统必备的实体：院系、归属院系的教师、由教师讲授的课程、学生、把学生关联到某学期某课程的选课，以及针对每条选课记录的成绩。学生和课程是多对多关系，通过选课表干净地解决——这是本领域最重要的一个设计决定，也是初学者最容易搞错的一个。打开模板，把实体名改成你学校的叫法（班级 vs 教学班、选课 vs 报名），加上你系统需要的字段，再把图分享给团队或作为数据库课程的作业起点。因为它是可编辑的白板，而不是数据库迁移文件，你能在几分钟里迭代 schema，再写一句 SQL——这正是你确定表结构之前最需要的。无需注册、无需下载。
适用场景
- 为新的 K-12、大学或在线教务系统设计数据库。
- 通过选课表建模学生与课程之间的多对多关系。
- 规划成绩如何挂到具体的选课记录，而不是直接挂在学生上。
- 决定教师和课程如何连接到院系，以及先修课怎么建模。
- 为新加入的开发者整理现有学校数据库的文档。
- 作为数据库课程或软件工程课的 ER 图作业起点。
使用步骤
- 1从院系开始，把教师记录关联到它（每位教师属于一个院系）。
- 2添加课程表，同时引用院系和讲授该课程的教师。
- 3添加学生表，记录选课的人。
- 4添加选课表，把学生关联到某学期的课程——不要让学生直接连课程。
- 5添加成绩表，成绩挂在选课记录上，而不是挂在学生上。
- 6标注基数：一个学生有多条选课；一门课程有多条选课；每条选课对应一条成绩。
简单示例
学校选课 schema
相关资源
和相似工具的对比
K-12 班级制 vs 大学教学班制
K-12 学校把学生整学年分到固定班级，选课基本是静态的，schema 保持简单（Student → Class → Teacher）。大学把 Course（目录条目）和 Section（某学期具体开课，有独立教师、时间和容量）分开，选课指向 Section，而不是 Course。学校按整学年固定分班运行时用 K-12 式；同一门课一学期可能开多个教学班时用大学式。前期选错，后面就要付出昂贵的表结构迁移代价。
选课表 vs 学生-课程直接关联
初学者最常见的错误是让学生和课程直接多对多关联。ER 图上看着更简单，但撑不住真实教务系统需要的字段——学期、状态（在读/退课）、选课时间，以及成绩挂在哪。选课作为中间表多花一个实体，让 schema 能随着需求自然生长。**永远用选课表。**
成绩挂在选课 vs 挂在学生
很容易想给 Student 加一个 gpa 字段，或者把成绩直接挂在学生上。别这么做。同一学生可能在不同学期修同一门课（重修、gap year、转学分），成绩属于某次具体的选课记录（Enrollment）。综合 GPA 由选课记录派生出来算；不要把非稳定身份属性预算好存在学生表上。
单学期 vs 多学期 / 学年模型
小系统有时把「当前学期」直接烘焙进选课表，不建独立的 Term 实体。这在需要跨学年成绩单、按学期出报表之前都还能用。一旦系统要回答「Fall 2026 有多少人选了这门课」「按学期算 GPA」这类问题，就应该加 Term（或 AcademicYear + Semester）实体——事后再补进来很痛。
常见误区
学生和课程直接多对多
跳过选课中间表，第一稿看着更干净，但只要开始需要把学期、状态或成绩挂在具体选课上就撑不住。破解：始终用选课表解决学生到课程的关系，哪怕当前需求勉强能用直接 M:N——需求一定会长大。
成绩挂在学生上，而不是选课上
把成绩挂在 Student 行（或更糟，挂在 Course 行）上，撑不了重修或不同学期修同一门课。破解：成绩挂在 Enrollment 上，每条选课一条成绩。综合 GPA 由派生算，不预存。
选课表忘了 term 字段
没有 term 列的选课表只能表达「现在正在选」。它回答不了「这个学生 2025 春季修了什么？」破解：从第一天起就在选课表放 term（可选还带 status）列——事后再补要给所有历史行做回填。
Course（目录）和 Section（开课）不分
如果同一门课在不同学期可以换教师、教室或时间，一行 Course 记录扛不下「目录」+「本学期具体教师」两件事。破解：拆成 Course (id, catalog_code, credits) 和 Section (id, course_id, teacher_id, term, room, capacity)，让 Enrollment 指向 Section。学校永远只有一门课一学期只开一个教学班时，才可以省掉这一步。
常见问题
学校管理系统的数据库应该有哪些表？+
至少要有：Department（院系）、Teacher（教师）、Course（课程）、Student（学生）、Enrollment（选课）和 Grade（成绩）。选课是中间表，把学生和某学期的课程关联起来；成绩挂在选课上。可选但常见的还有：Section（同一门课某学期的具体开课）、Term / AcademicYear（学期/学年）、Assignment 和 Submission（成绩册颗粒度）、Prerequisite（先修课，Course 到 Course 的自关联）。
学生和课程为什么要中间一张选课表？+
因为它们本来就是多对多关系（一个学生选多门课；一门课有多个学生），而且这个关系本身还要带字段——学期、状态、选课时间、成绩挂哪。直接 M:N 关联撑不住这些字段。选课表还让重修变得自然：同一学生在不同学期选同一门课，是选课表里两条不同的行。
成绩应该怎么存？+
成绩挂在选课记录上，而不是挂在学生或课程上。一条选课对应一条成绩（成绩册颗粒的话可以对应一小组作业成绩）。存原始分数和折算的等级；GPA 由学生所有选课的成绩派生算，不预存在 Student 上。这样重修、申诉、按学期算 GPA 才自然。
K-12 学校和大学的数据库设计有什么不同？+
K-12 把学生整学年分到固定班级，选课基本是静态的：Student → Enrollment → Class。大学把 Course（目录）和 Section（本学期具体开课，有教师、时间、容量）分开，选课指向 Section。K-12 的 schema 更简单；大学 schema 需要 Section 和 Term 实体，因为同一门课能开好几遍。
这份 ER 图能导出成 SQL 或直接用于真实数据库吗？+
模板是设计工具——它把实体、字段和关系摆清楚，方便你和团队在写 SQL 之前先对齐模型。图定稿后，翻译成目标数据库（Postgres、MySQL、SQLite）的 CREATE TABLE 语句即可。关系直接对应：一对多变成「多」侧的外键；多对多用选课式的中间表。
在线开始编辑
在 CodePic 中打开模板后，替换示例节点，就能很快整理成自己的学习导图。
