计算机毕设不用愁！建表 SQL 一键生成 ER 图，外键关系自动识别数据库课设里很常见的一种情况：表已经建好了，CREA

计算机毕设不用愁！建表 SQL 一键生成 ER 图，外键关系自动识别

数据库课设里很常见的一种情况：表已经建好了，CREATE TABLE 写了几十行，主键、外键、中文注释都有，但导师要的 ER 图还没画。

对着 SQL 一个个摆实体、连关系，是能画出来，但十几张表容易连错。连错之后，后面的数据库设计章节、三线表、建库脚本会跟着一起错。

这篇按实际操作顺序讲一遍：怎么把建表语句变成图，出图之后要核对哪些地方，以及改完之后怎么确认图和 SQL 还对得上。

SQL 能推出什么，推不出什么

动手之前先分清这一点，后面的判断会容易很多。

建表语句里明确写着的东西，工具能可靠读出来：

有哪些表（对应候选实体）
每张表有哪些字段、类型、长度
主键、非空、唯一约束
显式声明的外键，以及它引用的是哪张表的哪个字段
COMMENT 里写的中文名

建表语句里没有的东西，任何工具都推不出来：

一个业务操作要经过哪些步骤、失败了怎么返回
谁有权做这件事（权限控制通常写在程序里，不在表结构里）
关系基数——一对多还是多对多，取决于业务规则，不取决于字段名
那些"约定俗成"的关联：字段叫 major_id 但没写 FOREIGN KEY 的情况

所以从 SQL 生成的 ER 图，性质上是一版待确认的初稿，不是可以直接交的定稿。下面所有核对动作，都是围绕这句话展开的。

导入：粘贴语句，或者直接传 .sql 文件

进入捷码AI工作台，首页给的是四种起点。

捷码AI 工作台首页，中央是 AI 生成、SQL 导入、模板开始、手动设计四个入口

看这张图只需要确认一件事：已经有建表语句时选「SQL 导入」，不要选 AI 生成。AI 生成适合只有课题描述、还没动手建表的情况；如果结构已经定了，让 AI 重新生成一套反而要多做一轮比对。

页面下方还有社区模板可以直接套用相近的业务结构。但既然 SQL 已经写好了，模板的意义不大——你要的是一张和现有表结构一致的图，不是另起一套。

手机端也能走同样的入口：

捷码AI 移动端首页，智能生成区同样提供 SQL 导入

这张图里有两处容易看错的地方。上方"智能生成"的四个入口和 PC 端一致；下方"毕业工具箱 / 精选模板 / 我的项目"是三个并列的功能分类，切到"交付产物"后列出的"文档生成""开题报告""答辩 PPT"是可以进入的功能入口，不是已经生成好的文件。

字段多、关系复杂的时候还是建议回电脑上做。小屏拖动节点比较费劲，核对字段也要来回滚动。

在 SQL 导入页有两种提交方式：把 CREATE TABLE 语句粘贴进去，或者上传 .sql 文件。点「开始解析」之后先别急着进项目，看一眼解析预览里的表、字段和识别到的联系，确认没有明显的解析错误再继续。

解析出来的是候选实体，不是最终模型

用一小段 SQL 说明这件事。

CREATE TABLE major (
  id   BIGINT PRIMARY KEY,
  name VARCHAR(100) NOT NULL COMMENT '专业名称'
);

CREATE TABLE student (
  id       BIGINT PRIMARY KEY,
  name     VARCHAR(100) NOT NULL COMMENT '学生姓名',
  major_id BIGINT NOT NULL COMMENT '所属专业',
  CONSTRAINT fk_student_major
    FOREIGN KEY (major_id) REFERENCES major(id)
);

解析会得到两个候选实体和一条联系。但这条联系对不对，还得回到业务上问：

一个专业是不是可以有多个学生？通常是，所以是 1:N
一个学生是不是只能属于一个专业？如果学校允许双学位或跨专业培养，这条外键就表达不全
学生的其他信息（班级、入学年份）放哪？SQL 里没写的，图上也不会有

工具给出的是"SQL 字面意思"，不是"业务真实意思"。 这一步的判断只能自己做，这也是为什么下面要花不少篇幅讲核对。

出图之后，对着右侧数据字典核对四处

解析完成后进入 E-R 图工作区。这个界面最值得先熟悉的是左图右表的布局：

捷码AI E-R 图工作区，左侧关系图与右侧数据字典同屏，底部显示实体、字段与关系数量统计

看这张图的重点是布局本身：左边是画布，右边是数据字典面板，逐行列出字段的列名、中文名、类型、长度、主键、外键、非空、唯一、默认值和注释。

改动的时候两边要一起看。 只看图会把字段类型看漏，只看表会看不出关系画错了——这两个错误在答辩时都很显眼。

对照时按四项走，顺序不要乱：

一、表和实体是不是一对一。 字典表、日志表、中间表算不算业务实体？上面的例子里 major 和 student 是实体，但如果 SQL 里还有一张 sys_dict，把它当业务实体画进主干就不合适。

二、字段和属性对不对。 主键选对了没有？类型和长度是否符合需求？中文名是不是课题里用的说法——图上写"专业"、文档里写"系别"，答辩时会被追问。

三、外键指向对不对。 字段名相似很容易连错。class_id 到底指向班级表还是课程表，要看 SQL 里的 REFERENCES 写了什么，不能靠名字猜。

四、关系基数对不对。 图上的 1、N、M 要和业务规则一致。多对多的场景通常需要中间实体承载额外属性（比如选课记录要存成绩和选课时间），这时候要新增实体，而不是把连线标签从 1 改成 N。

最容易漏的是没写外键的那类。 字段命名暗示了关联，但 SQL 里没有 FOREIGN KEY，工具就不会连线。图上看不出问题，核对时也很容易跳过去。

看一张画得比较完整的图，找找读图顺序

上面讲的是核对方法，下面这张是另一个示例项目导出的 E-R 图，可以拿来练读图：

学生信息管理系统 E-R 图示例，包含课程、班级、学生、教师和学生选课五个实体及其属性

这张图来自"学生信息管理系统"示例，和上面的工作台界面不是同一个项目，用途也不同——它是导出后的成品图，没有编辑界面。

读图建议按这个顺序，不要一上来盯所有连线：

先找矩形里的实体：课程、班级、学生、教师，以及中间那个"学生选课"
再沿连线找关系：学生和班级之间是"属于"，学生和课程之间通过"学生选课"连接
注意"学生选课"上挂着的属性：分数、备注、选课时间——这三样是选课这个动作产生的，不属于学生也不属于课程
最后核对基数：一个班级有多个学生（1:N），一个学生选多门课、一门课被多个学生选（M:N）

第 3 步是判断 E-R 图画得好不好的关键。如果"选课时间"被挂到了"学生"或"课程"上，说明中间实体没建对——即使连线的形状看起来差不多，模型也已经错了。

图不对就改结构，不要改截图

发现关系错了，有两种改法：截个图用画图软件擦掉重画，或者回工作区改结构。

用第一种，图和 SQL、三线表、设计文档马上就对不上了。 而且后面每改一次字段，都要重新截一次图。

在工作区能改的东西包括：

新增或删除实体
增删字段，改中英文名、类型、长度
改主键、唯一键、外键引用
拖动节点，或用智能布局整理交叉的连线

改完结构和布局，先点「保存布局」，再去导出。E-R 图的导出按钮在布局未保存时会提示"请先保存布局后再导出"——这不是权限限制，是在避免你拿到一版旧图。

导出格式有 PNG、SVG、Drawio、Visio 四种，分别适合什么场景，另一篇单独讲，这里不展开。

交之前，把图和 SQL 再对一遍

如果同时生成了数据库脚本，把外键约束和图上关系逐条对一遍：

捷码AI 数据库脚本视图，按数据库创建、表结构、视图、索引、存储过程等小节组织

这张图来自另一个演示项目的脚本界面，项目名和前面两张都不同。它的用途很直接：找到"表结构创建"那一节，看看 FOREIGN KEY 是不是和图上画的联系一致。

脚本拿到之后还得在目标数据库里实际执行一遍。主外键能不能建起来、字段长度够不够、初始数据有没有冲突，跑一遍才知道。能生成脚本，不等于脚本已经跑通。

最后三个验收问题

ER 图做完，用这三个问题自检一遍就够了：

图里每个核心实体，能不能在 SQL 里找到对应的表？
图上每条重要联系，能不能用字段或者业务规则解释清楚？
把图放大之后，实体名和基数还看得清吗？

三个都答"能"，再往论文或课设报告里放。有一个答不上来，就回工作区改结构，别只在文档里补救——文档改了图没改，问题只是被藏起来，答辩时还会被翻出来。