逻辑模型转物理模型本质是将业务规则翻译为数据库方言，需人工处理字段类型、主外键落地及目标库语法差异，Navicat转换强制面对三大现实问题并依赖四项关键配置检查。
逻辑模型转物理模型，本质是“翻译业务规则为数据库方言”
这一步不是点一下就完事的自动映射，而是把抽象的实体关系（比如“用户-订单是1对多”）翻译成具体数据库能执行的结构定义（比如 user_id int primary key、orders.user_id int not null references users(id)）。navicat 的转换过程会强制你面对三个现实问题：字段类型怎么选、主外键怎么落地、目标数据库到底支持什么语法。
转换前必须检查的 4 个关键配置项
很多人跳过这步直接点“转换”，结果生成的 SQL 在 MySQL 里跑不通，或在达梦里报错。真正起作用的是这四个地方：
- 在“变换为物理数据模型”向导的“数据类型映射”页，确认
String映射到了VARCHAR(255)而不是TEXT（后者可能不支持索引） - 在“选项”页填的
模式名（如HR_schema）会变成 SQL 里的CREATE SCHEMA或USE语句，达梦和 PostgreSQL 对 schema 处理差异很大 - 逻辑模型中未标注“主键”的实体，在物理模型里不会自动生成
PRIMARY KEY约束——Navicat 不会替你做这个判断 - 多对多关系在逻辑层只画连线，但转换后是否生成关联表（如
post_tag），取决于你在关系属性里是否勾选了创建关联表
生成 SQL 前，务必打开“属性”视图调出字段细节
转换后的物理模型默认只显示表名和字段名，但字段长度、是否允许 NULL、默认值这些关键信息全藏在“属性”视图里。不手动展开看一遍，很容易导出带 INT 却没 AUTO_INCREMENT 的主键，或者把时间字段生成成 DATETIME 却漏掉 DEFAULT CURRENT_TIMESTAMP。
实操建议：
– 右键点击任意表 → 选择 编辑表 → 切换到 属性 视图
– 检查每个字段的 数据类型、长度/精度、允许为空、默认值
– 特别注意外键字段：它的类型必须和被引用字段**完全一致**（比如都是 BIGINT UNSIGNED），否则同步到 MySQL 8.0+ 会失败
正向工程到数据库时，“同步”比“执行 SQL”更安全
直接导出 SQL 再手工执行，容易忽略已有数据、索引冲突、权限限制等问题。“同步到数据库”功能会先做差异对比，只变更需要的部分，比如只新增字段、只加索引，不删表重来。
但要注意两个坑：
– 同步前必须确保目标数据库已连接且有 CREATE 和 ALTER 权限
– 如果物理模型里改了字段名（比如从 user_name 改成 username），同步默认是 RENAME COLUMN，但达梦 8 和 MySQL 5.7 不支持该语法，会报错
utf8mb4、时间字段要不要加 ON UPDATE CURRENT_TIMESTAMP、外键要不要开 CASCADE。这些决定没法靠转换按钮自动完成。 
