做数据库课程设计的时候最折磨人的往往不是 SQL 语句怎么写而是那张 ER 图怎么画。学校老师要求提交逻辑模型图答辩时要能讲清楚实体和关系公司里做新项目也要先在库里把表结构理顺画出一张能沟通的底图。我自己经历过几个阶段最早用桌面端绘图软件装完还要找激活后来试过在线商业工具免费版限制多涉及公司内部表结构又不敢乱传最后把目光放在开源的 Web 工具上才发现这个方向其实已经被解决得很好了。这篇文章就围绕数据库设计里最常用的 ER 图画图场景介绍 3 款真正能在浏览器里跑起来的开源工具draw.io、WWW SQL Designer 和 CloudBeaver。它们覆盖三条完全不同的路线——正向设计、SQL 生成、逆向可视化。适合做课程设计的学生、需要快速梳理老项目表结构的后端开发以及想在团队里统一建模流程的技术负责人。1. 为什么画 ER 图这件事值得从桌面软件搬到浏览器里先想清楚一个问题ER 图本质上是 数据库结构设计的中间产物它不像代码那样需要 IDE 的深度集成也不像压测脚本那样对本地环境有要求。它需要的是随时改、随时看、随时给别人留评论。这个特性天然和浏览器匹配。1.1 需求场景比想象中广泛得多搜索数据库工具相关话题的时候能发现一个很有意思的现象问 er图用什么软件画 的人里至少有一半不是专业 DBA而是正在做数据库课程设计的学生。他们通常会查 er图转化为关系模型、mysql的表导出er关系图核心诉求是快速出图、符合教材规范、能在论文里放得清楚。而另一类需求来自已经上线的老项目。很多小公司连数据库设计文档都没有库表几十张外键关系错综复杂接手的开发只能一边查 information_schema 一边手动画图。这时能自动生成关系图的价值就远大于手动画得漂亮。第三类是协作场景。课程设计的团队里有人画图有人写代码如果画图的工具只能保存在本地其他成员就永远看不到最新版。Web 工具天然解决了这个问题——发个链接或者用共享存储大家看到的就是同一份。1.2 桌面软件的三个痛点桌面端绘图软件在 ER 图场景下有三个绕不开的问题。第一是安装成本。Visio 这种商业软件要授权破解版有安全风险DataGrip 虽然自带 ER 图功能但那是 IDE 的付费功能之一。为了画一张图装一堆软件怎么想都不划算。第二是跨平台协作。团队里有人用 Windows有人用 macOS还有人用 Linux桌面软件的分发、版本管理都是额外工作量。哪怕只是换个电脑原来存的绘图文件也不一定打得开。第三是导出和嵌入不方便。论文、PPT、在线文档才是 ER 图的最终去处。桌面软件导出的图片格式经常要反复调整缩放比例稍不注意导出分辨率就糊了。Web 工具导出的 SVG 可以无损缩放这对于文档排版是非常友好的体验。1.3 开源自托管的独特价值开源和Web这两个属性叠加在一起解决了一个在线 SaaS 工具很难解决的问题数据可控。如果你只是画一张不敏感的教学图哪个在线工具都无所谓。但如果要画的是公司核心业务库表名、字段名本身就暴露了业务逻辑这时候把结构传到第三方平台心里多少有点不踏实。开源工具可以部署在内网服务器上数据完全自控该有的 Web 功能一个不少还能复用现有的 Nginx、LDAP 等基础设施。对个人开发者来说自托管其实也是一件一劳永逸的事。一台最低配的小主机就够跑这些工具一次部署之后任何设备浏览器打开就能画图。相比反复安装桌面客户端的体验完全是两种工作流。2. draw.io通用绘图工具里最接近专业 ER 设计的那一个先说第一款也是大家听过得最多的draw.io项目现在叫 diagrams.net。它的定位是通用绘图工具但很多人并不知道它对数据库设计做了专门支持甚至可以直接从 SQL 建表语句生成 ER 图。2.1 部署方式在线版与 Docker 自托管draw.io 的 Web 版可以直接打开官方站点使用不需要注册画完保存到本地或云端网盘。如果不希望图数据经过第三方服务官方提供了 Docker 镜像一条命令就能自托管docker run -it --rm --name drawio -p 8080:8080 -v /path/to/draw:/root/.drawio jgraph/drawio这条命令把容器的 8080 端口映射到宿主机同时挂载了一个本地目录存图。启动之后浏览器访问服务器的 8080 端口就能看到完整编辑器体验和在线版基本一致。自托管版同样支持保存到本地磁盘、浏览器、网盘也可以接 GitHub、GitLab 等外部存储。这里有个细节值得注意draw.io 的数据库建模能力并不依赖于外部插件它就内置在编辑器里。官方为它准备了一套 Database 图形库里面包含表、字段、主键、索引等基础形状画出来的 ER 图风格非常标准。2.2 用 DDL 文本快速生成 ER 图draw.io 最让我觉得惊艳的功能是能从一段建表 SQL 直接生成 ER 图。它的菜单位置是Arrange Insert Advanced SQL。点击之后会弹出一个对话框把 MySQL 或 PostgreSQL 风格的建表语句粘进去点击插入编辑器会自动解析表名、字段、主键、外键并绘制成带关系的实体框。举个例子粘入下面这段简单的 DDLCREATE TABLE student ( id INT PRIMARY KEY, name VARCHAR(50), class_id INT, FOREIGN KEY (class_id) REFERENCES class(id) ); CREATE TABLE class ( id INT PRIMARY KEY, name VARCHAR(50) );draw.io 会自动生成两个表框并在class_id和class.id之间拉出一条关系线。表与表之间的连线通过外键识别方向也比较直观。这个功能在处理几十张表的结构时尤其高效。手动画一张表要拖拽十几次用导入的方式只需要准备一份建表语句几秒钟就能得到一张完整的关系图底稿。之后你可以微调布局、补充分组色块、加注释最终导出的图既清晰又规范。需要提醒的是draw.io 对 DDL 的解析依赖相对标准的语法格式。如果你的建表语句里充满了数据库特有的方言、特殊注释或者外键定义方式非常规解析出来的关系线可能会出现偏差。所以正确做法是先用规范的 SQL 生成底稿再对它做人工微调而不是指望工具一次到位。2.3 画完图之后导出、协作与版本管理对于课程设计和团队文档来说ER 图画完只是第一步怎么把图放进论文或分享给同事才是真正的刚需。draw.io 的导出选项很全。File Export As里支持 PNG、JPEG、SVG、PDF 等常见格式。做课程设计时推荐导出 SVG在 Word 或 LaTeX 里放大缩小都保持清晰。如果只是为了快速发到群里看效果PNG 就够了画布大小可以手动调整。协作方面draw.io 虽然没有实时多人光标这种功能但因为它支持将图保存到 GitHub、GitLab、OneDrive、Google Drive 等平台本质上可以借助这些平台的协作机制实现多人编辑。内网部署时把 mirror 目录放到共享存储上也能达到多人共同维护图表的效果。这也引出一个实用经验用 draw.io 画 ER 图的时候最好把 DDL 文本和图片放在同一个文档目录里方便追溯。我见过太多同学图导出得很漂亮但问他要建表语句时却找不到了实际上完整的表结构定义才是 ER 图的灵魂。3. WWW SQL Designer二十年历史的老牌开源 Web 表结构设计器如果你想要一款更专精的数据库设计工具——专门用来从零设计表、生成 SQL而不是像 draw.io 那样什么图都能画那么 WWW SQL Designer 值得了解一下。这个项目从 2003 年启动至今仍在维护仓库地址在 GitHub 的ondras/wwwsqldesigner是 PHP 社区里知名度很高的开源 Web 表结构设计器。3.1 部署一个 PHP 环境就能跑起来WWW SQL Designer 的技术栈非常轻就是传统的 PHP 加 JavaScript。部署方式很简单准备好一个 PHP 环境把项目代码 clone 到 Web 根目录然后通过浏览器访问入口文件。git clone https://github.com/ondras/wwwsqldesigner.git cd wwwsqldesigner php -S 0.0.0.0:8080如果本机安装了 PHP 5.6 以上版本这条命令就能在当前目录起一个临时服务。浏览器打开http://localhost:8080工具界面就出来了。它的界面风格是典型的 2000 年代 Web 应用上方一排工具按钮中间是无限画布左下角有存储和加载选项。它的核心价值不在界面美观而在轻量。因为不需要 Node.js、不需要编译、不需要数据库随便一台能跑 PHP 的机器就能部署非常适合教学环境。如果你所在的实验室没有多余的服务器甚至可以用局域网里的一台老电脑跑起来。3.2 从零设计表并导出 DDLWWW SQL Designer 的工作流围绕表结构本身展开。双击画布空白处可以创建一个新表双击表标题可以修改表名表体内部默认有字段列表点击添加按钮可以加入新的字段然后依次编辑字段名、类型、长度、是否允许 NULL、是否为自增主键。建立外键关系的方式也很直观工具栏上有一个画关系的按钮从一个表的字段拖到另一个表的字段松开鼠标后就会形成外键关联。画布上会用连线把两张表连起来并且能够识别一对多关系。完成表结构后最关键的一步是导出 SQL。左下方工具区可以选择方言支持 MySQL、PostgreSQL、Oracle、SQLite、MSSQL 等多种形式选择后点击生成按钮就会按当前选中的数据库方言把 ER 图转换成建表语句。这意味着你可以先在画布上规划好实体关系再一键得到 DDL 文件用数据库客户端执行即可建库。这个反向流程图生成 SQL正好补上了 draw.io 的短板。前面提到 draw.io 能从 SQL 生成图但反过来从图导出 SQL 并不是它的强项而 WWW SQL Designer 恰恰是面向设计完后端写代码这个正向流程来设计的。我在实际使用中比较多的一个场景是给新项目设计人员权限模块。先在这个工具里把 user、role、permission、user_role、role_permission 五张表画出来确认关系没有遗漏再导出 MySQL 方言的 SQL直接放在项目初始化脚本里执行效率很高。3.3 老工具的现实局限说实话WWW SQL Designer 也明显有它的年代感。界面完全不响应式在手机上打开基本没法用画布缩放、对齐辅助、批量改字段等现代建模工具的标配是缺失的如果表数量超过五十张画布操作会开始有点卡。另外保存和加载设计文件虽然支持导出为本地 XML但格式是它自己的私有格式无法直接与其他建模工具互通。它还有一个从数据库导入已有表结构的后端能力但需要额外配置后端存储环境实际用起来不如 CloudBeaver 那样开箱即用。所以我给它的定位是快速原型设计、教学演示、轻量化正向设计。它适合在项目早期把核心实体和关系理清楚一旦表结构达到几十张以上就应该换用更专业的工具来做管理。4. CloudBeaver把已有数据库反向生成 ER 图的开源 Web 工具第三款工具和前面两款思路完全不同。CloudBeaver 本质上是开源数据库客户端 DBeaver 的 Web 版本但是它的 ER 图可视化能力非常强特别适合已经有数据库需要快速生成表关系图的场景。4.1 用 Docker 一键起服务CloudBeaver 的官方仓库在 GitHub 的dbeaver/cloudbeaver提供 Docker 镜像部署比想简单得多docker run --name cloudbeaver --rm -ti -p 8978:8978 dbeaver/cloudbeaver启动后浏览器访问服务器的 8978 端口首次进入会要求创建一个管理员账号然后就能在管理界面里配置数据库连接。支持 MySQL、PostgreSQL、SQLite、Oracle、SQL Server、ClickHouse 等常见数据库连接信息的填写方式和 DBeaver 桌面版基本一致。CloudBeaver 的定位是 Web 端数据库管理客户端所以除了看 ER 图它还能执行 SQL、查看表数据、管理权限等。这意味着它就相当于给团队提供了一个统一的数据库管理入口部署在内网后各成员都不用再各自装桌面客户端了浏览器打开就能操作。4.2 连接数据库并生成关系图连上数据库之后生成 ER 图非常直接在左侧数据库树里找到你要可视化的库或模式右键单击在菜单里选中 View ER Diagram。CloudBeaver 会自动读取当前库的表、字段、主键、外键和索引信息以 ER 图的形式展示出来。表与表之间会根据外键关系自动连线表内字段也会标注主键、可空性等属性。画布支持拖拽调整布局、缩放、选择层级整体交互比想象中的流畅。这套机制解决了一个很实际的问题老项目的表结构文档几乎为零新接手的人只能靠一条条看建表语句来建立全局认识。用 CloudBeaver 连接一次测试库把 ER 图导出来再结合几张核心表的数据样例对整个数据库结构的理解效率会高上好几倍。4.3 关系图的保存与分享CloudBeaver 查看 ER 图之后可以保存为 PNG、SVG 格式的图片。右键点击画布空白区域选择导出图片就能把当前视图存到本地。有一点需要提醒CloudBeaver 生成的 ER 图更偏向数据库结构的真实映射它不会像设计工具那样自动做布局美化也不会把多对多关系自动拆分成中间表。你看到的就是数据库里的实际结构有些表间如果没有外键关系即使逻辑上是关联的也不会画出连线。这是它作为逆向工具的特点不是缺陷。实际使用中我一般把 CloudBeaver 生成的图当作基础底图然后导入到 draw.io 里重新整理布局和分组加上注释后作为正式文档。这个组合方式既保证了结构准确又兼顾了可读性。5. 三款工具的横向对比与选型建议三款工具的定位差异很大但很多人第一次看到时容易混淆。下面这张表把它们的核心区别整理出来可以直接用来做选型参考。5.1 三款工具核心参数对比对比维度draw.ioWWW SQL DesignerCloudBeaver项目定位通用绘图工具表结构正向设计器Web 数据库管理客户端部署方式在线版 / Docker 自托管PHP 环境Docker 自托管是否支持从零画 ER 图支持且友好支持核心场景不支持只读已有库结构是否支持 SQL 生成 ER 图支持DDL 文本导入支持从已有库导入但不常用原生支持自动读取外键关系是否支持 ER 图导出 SQL不支持支持多种数据库方言不支持导出格式PNG / SVG / PDF / HTMLXML设计文件PNG / SVG协作能力支持网盘、Git 存储较弱支持多用户连接管理界面现代化程度高低高学习成本低低中5.2 不同场景下的选择思路如果你是在做数据库课程设计需要画一张规范的 ER 图放进论文里同时还要把实体关系说清楚首选 draw.io。从 DDL 生成底稿再手动整理出图速度快导出 SVG 放进论文很清晰。如果老师要求提交建表语句可以用 WWW SQL Designer 把图画完后导出 SQL或者直接手写 create table 语句维护同目录的一份 DDL。如果你是后端开发接手一个没有人维护文档的老项目重点是搞清楚库里有哪些表、表和表之间怎么关联CloudBeaver 是最优选。一条 docker 命令起来连上库右键看 ER 图几分钟就能建立全貌还能顺手执行 SQL 验证数据这个体验是其他工具替代不了的。如果你是小型团队的技术负责人希望统一团队的建模方式我更推荐双工具组合用 CloudBeaver 连接开发库定期生成结构底图用 draw.io 维护正式的架构文档作为评审和交付物。至于新功能涉及的新表设计可以在 draw.io 里用 DDL 导入快速验证或者回落到 WWW SQL Designer 做正向建模。5.3 我自己的固定工作流这里分享一套我现在经常使用的固定流程拿到需求后先在 WWW SQL Designer 里快速画出核心实体和关系导出初始 DDL在真实数据库里把表建好、填入样例数据然后用 CloudBeaver 连接数据库右键查看 ER 图核对结构是否和设计一致最后把 CloudBeaver 导出的图导入 draw.io整理布局、补充业务说明形成正式的设计文档。这套流程已经把设计-实现-核对-文档化串成了一条完整的链路每张图都是真实结构的映射基本不会出现文档和代码不一致的尴尬情况。6. 画 ER 图时的常见坑与课程设计实战细节工具用顺手之后真正决定 ER 图质量的其实是基础理论。很多人在绘图工具里把表拉出来、线连上图看起来也像模像样但交给老师或同事一看就露馅。这里说说最常出问题的几个点。6.1 ER 图转关系模型的通用步骤搜索热点里经常出现er图转化为关系模型这个需求对应的其实是数据库设计里的标准流程。教材上的做法可以概括为三步第一步把每个实体转换成一张表。实体的属性就是表的字段实体的主键就是表的主键。这一步看起来简单但经常有人把多值属性当成一个字段存在表里比如一个学生有多个联系电话正确做法是单独建一张联系表而不是在 student 表里加 phone1、phone2、phone3。第二步处理关系。一对一关系可以把任意一方的主键放进另一方做外键一对多关系在多的一方加外键引用一的一方的主键多对多关系必须拆成一张中间表中间表的主键通常是两个外键的组合同时这些外键也分别指向两边的主键。第三步优化和规范化。检查所有字段是否满足至少第三范式即非主键字段不能依赖于其他非主键字段。比如把班级名称直接存在 student 表里就不太规范应该通过 class_id 关联班级表。课程设计里如果这一步做得好老师会很认可。6.2 我踩过的几个具体坑工具使用过程中有几个非常具体的坑遇到了可以先按下面的思路排查。第一个坑draw.io 导入 DDL 后外键连线丢失。这通常是因为 DDL 里的外键名重复或者外键定义被写在了表级约束之外导致解析没识别到。解决办法是给每个外键起全局唯一的约束名导入前先把超长的注释删掉尽量使用标准的FOREIGN KEY (col) REFERENCES table(col)语法。第二个坑CloudBeaver 里查看一张几十个字段的大表时ER 图非常乱。这是它照实绘制所有字段的结果并不是工具故障。解决办法是在画布上手动隐藏不关心的字段或者调整表的折叠状态只看主键和外键字段然后再截图导出。第三个坑WWW SQL Designer 导出的 SQL 在中文环境下出现乱码。这个工具诞生年代较早对 UTF-8 的支持有时会出现问题。解决方法是导出 SQL 后用编辑器转成 UTF-8或者在生成 DDL 后手动在表定义上加DEFAULT CHARSETutf8mb4后缀。6.3 给课程设计和新手的最短可行路线最后给正在做数据库课程设计的同学一条最短可行路线先不要急着画图把需求里的核心实体列出来控制在 6 到 10 个实体以内确定每个实体的主键和主要属性然后用 draw.io 的 SQL 导入功能生成底图手动调整布局加上关系线标注再根据 6.1 提到的规则检查有没有多对多关系没有拆中间表最后导出 PNG/SVG 放进文档把对应的 DDL 附在附录里。只要沿着这条路线走ER 图部分基本不会成为拉分项。反过来如果把大量时间浪费在折腾破解软件和反复重画布局上那才是真的消耗精力。工具只是辅助你对数据库结构的理解才是图纸真正的质量。选择开源 Web 工具的初衷说到底就是把重复劳动交给代码把思考时间留给自己。这套流程用顺手之后你会发现在浏览器里设计数据库这件事远比想象中靠谱。