优先用“转换”或“逆向工程”生成逻辑模型骨架再补全细节；新建时须手动选择“逻辑”模型类型，否则不支持主键/外键等语义设置；已有数据库应通过“从数据库导入”快速还原结构并转为逻辑模型；关系基数需两端分别准确配置；转物理模型前须定义字段类型与约束并验证模型。
直接创建逻辑模型，别从头画起——优先用“转换”或“逆向工程”生成骨架，再手工补全细节。
新建逻辑模型时选错模型类型，文件 → 新建模型 里必须手动选“逻辑”
Navicat 不会默认给你逻辑模型。点 文件 → 新建模型 后，弹窗里“模型类型”下拉框默认可能是“物理”，你得主动切换成 逻辑，否则后续添加的实体不支持设置主键/外键语义，字段也无法定义是否为空或唯一性约束。
常见错误现象：
– 实体加了属性，但右键找不到“设为主键”选项
– 关系连线后，双击无法编辑基数（1:1 / 1:N / N:M）
– 导出 SQL 时字段类型全变成 VARCHAR(255)，没按实际数据库适配
- 确认当前模型类型：看窗口标题栏是否含“逻辑模型”字样，或右下角状态栏是否有
Logical标识 - 如果已误建为物理模型，不能直接改类型，需另存为新模型并重新导入
- 逻辑模型不绑定具体数据库版本，所以“数据库类型”和“版本”字段可留空或选通用项（如 MySQL 通用）
从已有数据库逆向生成逻辑模型，从数据库导入 比手动画快十倍
如果你已经有运行中的数据库，别一个个拖表、连关系——用 文件 → 从数据库导入 直接拉取结构。它会自动识别主键、外键、索引，并生成带基数标注的关系线。
使用场景：
– 快速还原遗留系统结构，用于交接或重构评审
– 验证线上库与文档是否一致
– 把生产环境结构同步到设计稿，避免“设计归设计，上线归上线”
- 导入前先确保数据库连接可用，且账号有
SELECT权限访问INFORMATION_SCHEMA - 勾选“导入外键关系”和“导入注释”，否则关系线和字段说明会丢失
- 导入后，Navicat 默认生成的是物理模型；需右键模型标签 →
转换模型为 → 逻辑模型才能进入逻辑层编辑
在逻辑模型里设置关系基数，基数在 实体名1 和 基数在 实体名2 必须配对理解
画完关系线后双击它，弹出的对话框里有两个独立下拉项：基数在 实体名1 和 基数在 实体名2。这不是“左边是1、右边是N”的固定套路，而是分别对应关系两端的参与度。
容易踩的坑：
– 把“客户-订单”关系设成两端都是 多个，结果导出 SQL 时生成了无外键的孤立表
– 忘记把“订单明细”对“订单”的基数设为 多个，导致生成的 DDL 缺少 ON DELETE CASCADE 等行为定义
- 典型配置举例：
– “客户”对“订单”：基数设为零或多个（一个客户可下0单或多单）
– “订单”对“客户”：基数设为一（每张订单必须属于一个客户） - 关系名（如
has_order）建议用动词短语，方便后期生成文档或代码映射 - 如果关系涉及三张以上实体（如多对多中间表），逻辑模型里需显式添加关联实体，不能只靠连线
逻辑模型转物理模型前，务必检查属性是否已定义数据类型和约束
逻辑模型本身不强制填字段类型，但一旦执行 转换模型为 → 物理模型，Navicat 会按默认规则填充（比如全填 VARCHAR(255)、INT），且后续修改成本高。这步漏检，会导致生成的 SQL 脚本无法直接执行。
性能与兼容性影响：
– 字段过宽（如 TEXT 替代 VARCHAR(50)）影响索引效率
– 缺少 NOT NULL 或 DEFAULT 定义，使 ORM 映射失败或插入报错
– 主键未设为 自增，导致迁移脚本在 PostgreSQL 等引擎上失败
- 批量检查方式：打开“实体设计器”，在“属性”选项卡中按
CTRL+F搜索NULL，快速定位未设是否为空的字段 - 关键字段（如 ID、时间戳、状态码）建议提前填好类型，例如
created_at设为DATETIME而非VARCHAR - 转换前右键模型 →
验证模型，它会标出缺失主键、重复字段名等硬性问题
逻辑模型不是草图，它是字段语义和业务规则的正式载体。很多人卡在“画得像不像ER图”，其实重点是“字段含义有没有被准确表达”——比如一个 status 字段，逻辑层就得明确它是枚举值、是否允许为空、哪些状态可互相流转。这些信息一旦漏掉，后面物理模型和代码生成就全是债。
