数据库课设里最尴尬的一幕表你已经建好了CREATE TABLE也跑通了可老师要的是E-R 图。很多同学这时候开始手动摆方框——11 张表、一百多个字段摆一下午还经常把外键连错levelRef到底指向单位级别还是级别变更记录这篇不讲理论直接摊开一套真实跑出来的数据库资料大学生就业咨询系统建库脚本11 张表 / 15 个外键 / 227 行配套 E-R 图 10 张1 张总体 9 张子图与数据字典。所有内容都来自一次真实导出不是示意。一、建表 SQL 能推出什么、推不出什么先把边界说清楚这决定了你导入 SQL 之后还要补多少东西能自动推出来推不出来必须你来定表名、字段名、数据类型、长度字段的中文业务含义主键、唯一键、索引一对一 / 一对多 / 多对多的语义外键与引用方向业务流程谁先谁后、能不能撤销自增 / 默认值 / 是否可空角色与权限谁能改哪些数据表与字段注释如果写了COMMENT业务规则例如一个毕业生只能投递同一单位一次一句话SQL 给你结构语义得你自己补。本项目 11 张表里有 103 处字段注释正是这些注释让后续的 E-R 图和数据字典能说人话——所以建表时写COMMENT不是可选项是省时间的投资。二、这 11 张表是怎么组织的按照实际脚本整理出来的清单字段数与外键数都是脚本里真实统计的表名中文名字段数外键数tb_systemAdministrator系统管理员表80tb_major专业表90tb_unitLevel单位级别表70tb_region地区表80tb_dataBackupRecord数据备份记录表101tb_employer用人单位表152tb_graduate毕业生表152tb_dataRestoreRecord数据恢复记录表102tb_demandInfo需求信息表142tb_levelChangeRecord级别变更记录表113tb_demandDetail需求明细表102合计11 张表117 个字段15 个外键看一眼分布就懂了这个系统的骨架4 张基础表管理员/专业/单位级别/地区没有任何外键它们是字典表被别的表引用7 张业务表围绕它们展开外键最多的tb_levelChangeRecord有 3 个。画 E-R 图时这个分布很关键没有外键的表通常是独立实体矩形外键多的表通常是关系或明细菱形/弱实体。照这个规律摆结构不会错。三、外键决定连线15 条关系一次列全E-R 图的连线不是画出来的是从外键推出来的。下面是这 15 条引用列指向含义operatorReftb_systemAdministrator操作人regionReftb_region所属地区levelReftb_unitLevel单位级别majorReftb_major所属专业regionReftb_region所在地区backupReftb_dataBackupRecord关联备份记录operatorReftb_systemAdministrator操作人employerReftb_employer所属用人单位regionReftb_region工作地区employerReftb_employer发布单位beforeLevelRef/afterLevelReftb_unitLevel变更前 / 变更后级别demandReftb_demandInfo所属需求majorReftb_major专业要求parentReftb_region上级地区自引用三个值得单独讲的点一封多引用tb_levelChangeRecord同时引用变更前级别和变更后级别这类表在 E-R 图里表现为两条指向同一实体的连线线上必须标1:N与角色名before/after否则读图的人会以为是重复连线。自引用tb_region.parentRef指向自己地区有上下级。这在 E-R 图里是从实体回到自身的环答辩常被问为什么不做成两张表——答案是层级深度不固定。同名列不同义regionRef在tb_graduate里是生源地在tb_employer里是工作地区。数据字典必须区分否则两张子图会看起来一模一样。四、E-R 图长什么样总体图 子图先看总体 E-R 图。它回答数据怎么组织实体、属性、联系、基数一次交代。总体图的问题是信息密度太高——11 个实体、117 个字段挤在一张图上打印成 A4 基本看不清。所以这份交付里额外导出了9 张 E-R 子图按实体拆开子图怎么用设计文档里放 2–3 张关键实体的子图数据库章节答辩 PPT 上放总体图讲全局老师追问某张表时直接把对应子图翻出来。比反复缩放一张大图体面得多。五、E-R 图与数据字典怎么互相对照E-R 图画的是关系数据字典写的是字段。两者必须能互相印证我一般按这个顺序核对看 E-R 图上的每个实体能不能在字典里找到同名表看每条连线能不能在字典的外键引用列里找到对应行看字典里每个NOT NULL字段图上有没有标必填看有没有字典里有、图上没有的字段——通常是漏画的属性。本项目导出的数据字典与 E-R 图是同一份结构派生的字段名、类型、唯一键、外键引用逐列对齐改一处两边同时变。这也是为什么建议先定字段再画图反过来的话图要重画一遍。顺带说一句数据流图E-R 图管数据怎么组织数据流图管数据怎么流动。本项目里顶层数据流图长这样回答的是外部实体进来、经过哪些加工、落到哪个存储——它和 E-R 图配合看业务与数据才对得上。六、三线表、建库脚本、设计文档要对齐数据库这一章通常要在三个地方出现同一套结构材料放什么常见扣分点设计文档「数据库设计」章三线表字段/类型/约束/说明 E-R 图图和表不是同一版建库脚本CREATE DATABASE/CREATE TABLE/ 外键图上有的字段脚本里没有开题报告数据来源与表规模几句话写的表数量与实际不符本项目这套资料里的数据库脚本是MySQL 方言、utf8mb4字符集、11 张表 15 个外键 227 行和设计文档里的三线表、E-R 图同源。答辩时被问你这个表为什么这么设计最稳的回答是当场翻出三线表和外键清单而不是凭记忆讲。七、你可能踩的三个坑中文注释乱码用 Navicat 之类的工具逆向导入时中文表名/注释经常变乱码。建库脚本里显式写DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci能避免一半问题。外键顺序建表有先后依赖先tb_region才能建引用它的表。脚本里用CREATE DATABASE→CREATE TABLE的固定顺序不要照着 E-R 图的视觉顺序抄。自引用表的插入顺序tb_region.parentRef指向自己插数据时必须先插父级再插子级否则外键报错。课设演示数据里如果地区表建了层级别忘了这条。八、说实话的部分本文的表结构、字段数、外键清单都来自一份真实导出的建库脚本11 张表 / 15 个外键 / 227 行你可以对着自己的 SQL 一条条核。E-R 图是初稿实体名、关系基数按这份脚本推出来了但这个外键的业务含义是什么仍要你自己确认——比如regionRef到底是生源地还是意向工作地机器推不出来。字段注释不全会直接拉低后续所有材料的质量。花十分钟把 117 个字段的注释补齐比后面改三份文档划算得多。一句话总结外键决定连线、注释决定可读性、子图决定答辩时能不能翻得出来——先把这 11 张表的结构定死E-R 图、数据字典、设计文档数据库章、建库脚本自然就是同一套事实。