navicat premium 不检测范式冲突，因其 .nmodel 文件仅为元数据容器，无内置规则引擎校验传递依赖或部分函数依赖；范式合规需人工识别、外键建模及导出前sql审查。
navicat premium 本身不检测、不阻止范式冲突，模型设计阶段的范式问题必须靠人工识别+规则约束，工具只负责忠实呈现你的设计。
为什么 Navicat 的 ER 模型不会报“违反第三范式”
Navicat 的 .nmodel 文件只是结构元数据的可视化容器，它不执行范式校验逻辑——没有内置的“检查传递依赖”“识别部分函数依赖”等规则引擎。你画出一张表里同时存用户姓名、城市、城市邮编、城市所属省份，Navicat 不会警告“邮编 → 城市 → 省份，存在传递依赖”，它只会照常导出 CREATE TABLE 语句。
常见错误现象包括：
- 在“用户”表里直接加
city_name和province_name字段，未拆出cities表 - 订单明细行里重复存储商品名称、单价、分类，而非只存
product_id - 模型中设置了主键，但未标记外键关系，导致逆向生成 SQL 时缺失
FOREIGN KEY约束
用好“外键建模”功能才能逼近范式要求
Navicat 能辅助你靠近第二、三范式，前提是主动使用其外键建模能力，而不是仅靠拖拽字段：
- 建表时务必在
Table Designer中为关联字段点击「Set as Foreign Key」，而非手动写字段名 - 创建关系线后，右键连线 →「Edit Relationship」→ 勾选
Enforce Referential Integrity，否则导出 SQL 不含ON DELETE CASCADE等行为 - 逆向工程（从库生成模型）时，确保源数据库已启用
information_schema.KEY_COLUMN_USAGE，否则 Navicat 可能漏掉外键连线 - 若模型中两个表有逻辑关联但无外键线，Navicat 同步到库时不会自动加约束，等于默许冗余字段存在
真正起作用的只有“模型评审 + 导出前检查”
范式合规性最终取决于人，Navicat 只提供检查支点：
- 导出 SQL 前，用
Model → Generate SQL File，打开生成的脚本，肉眼扫一遍：有没有非主键字段依赖于主键的一部分？有没有字段值能被另一张表的主键推导出来？ - 对关键模型，导出后运行
SELECT * FROM information_schema.KEY_COLUMN_USAGE WHERE TABLE_SCHEMA = 'your_db'对比外键定义是否与模型一致 - 把
.nmodel文件纳入 Git，每次提交附带简短说明，例如：refactor: split address into cities & provinces to eliminate transitive dependency—— 这比任何工具提示都管用 - 禁用 Navicat 的「Auto-generate foreign keys from naming convention」选项（位于
Tools → Options → Modeling），该功能仅按字段名猜测外键（如user_id→users.id），极易误判，反而掩盖真实范式缺陷
最容易被忽略的一点：Navicat 的「验证模型」（Model → Validate Model）只检查语法合法性（比如字段名重复、主键缺失），不涉及范式逻辑。它通过 ≠ 合规，别把它当范式审查开关。
