不需要数据库服务器也能设计关系模式：添加表，为它们定义带类型、键和默认值的列，然后用关系把表连接起来。实体关系图随你的输入实时重绘，同一个模型可以导出为 MySQL、PostgreSQL、SQL Server、SQLite 或 Oracle 的 CREATE TABLE DDL、Mermaid erDiagram 源码，或可在此重新导入、也可用迁移生成器打开的可移植 模式 JSON。全部本地运行。
什么是 ERD？ ERD 是 实体关系图（entity relationship diagram）的缩写，它是数据库的设计图纸，而不是对建成数据库的记录。一个有用的类比是建筑蓝图：运行中的数据库是大楼，ERD 是蓝图，没有人会先浇混凝土再测量。本页就是这张蓝图绘图桌——你在这里塑造模型，DDL、Mermaid 源码和模式 JSON 都从这一个模型打印出来，因此图不会偏离它生成的 SQL。
同一张图的三个层次。 概念 ERD 只命名重要的事物及其关系，用非程序员也能核对的语言。逻辑 ERD 增加标识每个事物的键并化解多对多连接，同时不涉及任何引擎的方言。物理 ERD 补齐特定产品要求的一切——类型宽度、默认值、可空性、唯一约束、删除规则——当你在本页选择 MySQL、PostgreSQL、SQL Server、SQLite 或 Oracle 时导出的就是这一层。
方框从哪里来。 读一段系统描述并圈出名词：客户、发票、产品、发货。这些就是表。挂在名词上的事实和属性——发票日期、单价、电子邮件地址——就是它的列。把两个名词绑在一起的动词，比如“订单由客户下达”，就是一个关系，它通过把父行中起标识作用的键复制到子行作为外键来存储。
什么时候是多对多。 一个菜谱用多种食材，一种食材出现在多个菜谱里，两张表都无法保存对方的键而不自我重复。答案是第三张实体表，它唯一的职责就是配对——即连接（或关联）表，为每一方保存一个外键，通常把这对键作为自己的主键。一个模型里大多是这种配对表完全正常：白板上的多对多连线在真实模式里总要变成一个方框。
为什么要在 DDL 出现之前费这个劲。 图纸上画错一条线，擦掉只要一分钟；同样的错误在发布之后才发现，代价是对生产数据做一次迁移。图也是非开发人员唯一能评审的产物，关系错误——弄反的基数、缺失的唯一键、可以没有父行的子行——在这里会以明显错误的线的形式暴露，而在 400 行的 DDL 文件里它们藏在约束中间。
正向还是逆向？ 本设计器是正向的：先建模，再输出 DDL。姊妹页
SQL 转 ERD走另一条路——粘贴现有
CREATE TABLE 语句，它会重建图，这在数据库已经存在时是更快的路线。
4 — 导出
Mermaid erDiagram 源码
JSON 模型是数据库工具家族的交换格式：把它作为修改前/后的模式粘贴到
迁移生成器，或在这里重新导入以便日后继续编辑。
