必须经逻辑模型过渡，因概念模型仅描述业务实体与关系，不含数据库语法细节；逻辑模型承担标准化字段名、主键策略、关系基数及外键归属的“翻译”职责，是概念到物理落地的必要中间层。
概念模型 → 物理模型 不是一键操作，中间必须经过逻辑模型过渡。Navicat 17 不支持跳过逻辑层直接生成物理模型——这是硬性限制，不是配置问题。
为什么必须先转成逻辑模型？
概念模型只描述业务实体和关系（比如“用户”“订单”“下单”），不含任何数据库语法细节；而物理模型要落地到具体 DBMS（如 MySQL 8.0、PostgreSQL、达梦 8）。中间的逻辑模型承担了关键“翻译”职责：它把模糊的业务术语标准化为可映射的字段名、主键策略、关系基数（1:1 / 1:N / M:N），并明确外键归属。跳过这步，Navicat 根本不知道 user_id 是该建为 BIGINT UNSIGNED 还是 VARCHAR(32)，也不知道多对多关系要不要生成 post_tag 关联表。
转换流程中三处必手动干预点
从概念模型右键选择「转换为逻辑模型」后，立刻要做以下检查：
- 打开每个实体的「Attributes」页，确认每个属性的
Physical Name已填写且与你期望的字段名完全一致（例如不能留空或写成PkUserID，而应填id） - 检查所有关系连线：右键 →「Edit Relationship」→ 确保
Referenced Table下拉框里显示的表名，和目标物理模型最终要生成的表名大小写、下划线都严格一致（MySQL 默认不区分大小写，但 Navicat 解析时区分） - 多对多关系必须手动勾选「创建关联表」，否则逻辑模型里不会生成第三张表，后续物理模型也就没有
order_item这类中间表
生成物理模型前的关键配置项
在逻辑模型上右键 →「转换为物理数据模型」，进入向导后重点盯住这四页：
-
数据类型映射页：确认String映射为VARCHAR(255)而非TEXT（后者在多数库不支持索引） -
选项页：填入正确的模式名（如ecommerce_db），注意达梦不支持CREATE SCHEMA，PostgreSQL 则依赖它 -
主键页：逻辑模型中未标注主键的实体，物理模型里不会自动生成PRIMARY KEY——Navicat 不推断 -
外键页：若目标库是 MySQL 8.0+ 且用 InnoDB，建议关闭Generate constraint names（避免CONSTRAINT `fk_xxx`语法报错）
生成 SQL 前最容易漏掉的三项检查
物理模型画布默认只显示表名和字段名，真正决定 DDL 行为的设置全藏在细节里：
- 双击每张表 →「字段」页 → 点开每个字段的「属性」视图：逐个核对
长度/精度、允许为空、默认值（比如DATETIME是否设了DEFAULT CURRENT_TIMESTAMP） - 外键字段类型必须与被引用字段**字节级一致**：比如引用的是
BIGINT UNSIGNED，外键也得是BIGINT UNSIGNED，差一个UNSIGNED在 MySQL 8.0+ 就同步失败 -
Description字段（逻辑层写的注释）不会自动同步到物理模型的Comment属性，导出 SQL 前必须手动复制粘贴，否则建表语句里没有COMMENT
Physical Name 或一个大小写不一致的 Referenced Table 名——它们不会报错，但会导致生成的外键指向不存在的列或表。 
