ER 图与数据建模
从已有数据库逆向理解实体关系,或先建立模型草案、生成 DDL,再经过人工审阅进入实施阶段。
适用场景
ER 图适合在接手陌生数据库、评审结构变更、梳理核心业务域或准备数据字典时快速建立全局认识。它把表呈现为实体节点,把数据库元数据中已声明的外键呈现为关系线,便于从订单、客户、商品等核心表向外围表逐层阅读。
ER 建模适合在建表前整理草案,或将现有库逆向导入后继续调整。建议先选一个边界明确的业务域,不要一开始把全库所有表放进同一画布;表越多,交叉连线越密,越难发现命名、基数和依赖方向问题。
- 现状梳理:从已有库生成 ER 图,识别核心实体、桥接表与孤立表。
- 方案评审:在落库前整理字段、主键、外键与关系,讨论后再生成 DDL。
- 变更核对:将模型生成的 DDL 与现网结构、变更单和回滚方案逐项比对。
- 文档沉淀:整理画布后导出 PNG,作为评审材料;图片只反映生成时读取到的元数据。
customer_id 不会仅凭名称自动等同于一条可信外键关系。入口路径
从顶部菜单进入「工具中心」,切换到「结构工具」分类。根据目的选择对应入口:
- 查看现有库:打开「ER 图」,在数据源选择器中指定连接与数据库,再选择需要放入画布的表。
- 设计或调整模型:打开「ER 建模」,新建模型草案,或从现有数据库逆向导入结构后继续编辑。
- 回到对象上下文核对:在 SQL 工作台左侧对象树展开连接、数据库和表,核对表名、对象范围及所属数据库。
前置条件
- 已创建并成功连接目标数据源,当前账号至少能够读取数据库、表、列、主键和外键等元数据。
- 已确认要分析的数据库与业务边界;同名数据库或多环境连接并存时,先核对连接名称、主机和库名,避免看错环境。
- 若要逆向已有库,先了解目标账号是否能读取系统目录;权限不足可能导致表、字段或外键信息缺失。
- 若要把模型转为真实结构变更,先备份重要数据或准备可恢复快照,并在开发或测试环境验证生成的 DDL。
- 准备一份人工关系清单,记录由应用逻辑维持但数据库未声明外键的关联,避免把「没有连线」误判为「没有关系」。
编号步骤
- 确认数据源和数据库。在工作台对象树核对连接及库名,再进入「工具中心 → 结构工具」。生产、测试连接命名相近时,先停下来确认主机与数据库,避免基于错误环境制作模型。
- 选择 ER 图或 ER 建模。只是理解现状时使用只读的「ER 图」;需要设计草案或调整逆向模型时使用「ER 建模」。不要把浏览任务直接变成结构变更任务。
- 选择表并控制范围。优先勾选一个业务域内的核心表、桥接表和必要字典表。先用少量表确认关系,再逐批补充外围表;若全选后画布拥挤,缩小范围重新生成通常比强行阅读更有效。
- 生成并检查关系线。从现有库生成 ER 图后,先检查主键字段,再沿外键关系线从引用表追到被引用表。将画布与数据库约束或已有设计文档比对;缺线时检查外键是否真实存在以及账号是否有元数据读取权限。
- 整理布局并分层阅读。把核心实体放在中间,主数据与上游实体放在一侧,明细表、桥接表和下游记录放在另一侧;使用缩放与适应视图观察整体,再放大检查字段。线条交叉不代表新增关系,只是当前布局的视觉重叠。
- 形成建模草案。在 ER 建模器中定义或调整实体、字段与关系;逐项确认字段类型、长度、可空性、默认值、主键、唯一性和外键方向。逆向导入后也应先保存为待评审草案,不要默认现有结构就是理想设计。
- 预览并人工审阅 DDL。生成建表或改表 SQL 后,先发送到 SQL 工作台或复制出来审阅,不要直接执行。重点核对目标方言、标识符引用、可能丢失数据的变更、默认值、索引、约束命名、外键创建顺序及回滚方式。
- 在受控环境验证。先备份或建立可恢复点,在开发或测试库执行;检查执行结果、表结构、约束与索引,并用代表性查询验证。确认脚本可重复执行策略和回滚方案后,再按团队变更流程进入下一环境。
参数说明
| 参数或选择 | 作用 | 检查重点 |
|---|---|---|
| 数据源 / 数据库 | 确定读取元数据或承载模型的上下文 | 核对环境、主机、库名与账号权限,尤其避免误选生产库 |
| 表选择 | 控制进入 ER 图或逆向模型的实体范围 | 按业务域分批选择;包含核心表、桥接表和必要字典表 |
| 主键 | 标识实体记录,并帮助理解关系目标 | 联合主键要完整;没有稳定主键的表应单独标记并评估 |
| 外键关系 | 从数据库约束元数据生成表间连线 | 确认引用列、目标列和方向;无外键时关系可能不完整 |
| 字段定义 | 描述列名、类型、长度、可空性与默认值 | 检查跨数据库方言差异、隐式转换、默认值表达式和字符长度 |
| 布局 / 适应视图 | 调整节点位置、缩放比例并让画布内容进入可视区域 | 布局仅改变阅读方式,不会补充或修改数据库关系 |
| 导出 PNG | 将当前 ER 图保存为评审或文档图片 | 导出前整理布局,并注明数据库、表范围和生成时间 |
| 生成 DDL | 把模型草案转换为建表或结构调整 SQL | 执行前人工审阅方言、数据影响、索引、约束顺序与回滚脚本 |
预期结果
从现有库生成 ER 图后,应看到所选表的节点、字段和可读取的主外键信息。布局应能让核心实体与主要依赖关系被快速识别;导出的 PNG 应与当前画布一致,并能说明本次选择的表范围。
完成模型草案后,应得到一份可评审的实体、字段与关系定义,以及对应的 DDL 预览。此时的成功标准不是「SQL 已生成」,而是以下检查已经完成:
- 所选表与业务边界一致,没有因误选连接而混入其他环境对象。
- 数据库已声明的外键能在图中找到;业务关系但未建外键的部分已在评审记录中补充说明。
- 字段类型、长度、主键、唯一约束、可空性、默认值和索引均经过人工核对。
- DDL 已在备份或可恢复前提下于非生产环境验证,执行结果与预期结构一致。
常见问题
为什么两张业务上有关联的表之间没有关系线?
先检查数据库是否真正声明了外键,而不是仅有相似字段名或由应用代码维护关联;再确认当前账号能读取外键元数据。若数据库刻意不建外键,应在评审文档中人工记录关系,不要把缺少连线当成无关联。
全库生成后节点和线挤在一起,应该怎样阅读?
回到表选择,按业务域缩小范围,从核心表、直接明细表和桥接表开始;使用适应视图观察整体,再缩放查看字段。可按上游主数据、核心交易、下游记录分区摆放。布局只改善可读性,不改变实际约束。
生成的 DDL 可以直接在生产库执行吗?
不建议。先人工检查目标数据库方言、字段变更的数据影响、默认值、索引、外键创建顺序和约束命名;准备备份与回滚方案,在开发或测试环境执行并核对结果,之后再按团队审批流程进入生产。
逆向导入的模型为什么与预期设计不完全一致?
逆向结果以当前账号可读取的数据库元数据为准。检查是否选错数据库、系统目录读取权限是否不足,以及业务关系是否未落实为外键。还要注意,逆向模型描述的是「当前结构」,并不自动代表目标设计或最佳实践。
模型生成 SQL 后,怎样降低误改或丢数风险?
把 SQL 先放入工作台逐句审阅,重点识别 DROP、列类型收窄、非空约束、新增唯一约束等高风险操作;用数据副本验证,并对执行前后的表结构、行数和关键查询做对照。任何导入、恢复或迁移相关操作也应先验证备份可用。
MagicDB Studio