Navicat Premium 不检查、不提示、不强制3NF，合规性完全取决于人工识别函数依赖；需主动发现A→B→C型传递依赖（如学院编号→学院名称→学院电话），将B、C提取为独立实体，学生表仅保留学院编号外键，并通过SQL验证（如DISTINCT查询比对）确认消除冗余。
Navicat Premium 本身不检查、不提示、不强制第三范式（3NF），你画出来的模型是否合规，完全取决于你对函数依赖的识别能力——它只负责把你的设计原样转成 CREATE TABLE 语句。
怎么识别传递依赖并拆表
3NF 的核心是消除“非主属性对主键的传递依赖”，典型模式是：A → B → C，其中 A 是主键，B 和 C 都是非主属性，C 不直接依赖 A，而是通过 B 间接依赖。这种结构必须拆。
- 常见错误场景：学生表里同时有
学院编号、学院名称、学院电话—— 这里学院名称 → 学院电话，而学院编号 → 学院名称，构成传递链 - 正确做法：把
学院名称和学院电话提到单独的学院实体中，学生表只保留学院编号（外键） - 在 Navicat 模型工作区中，右键学生实体 → 「编辑实体」→ 删除
学院名称和学院电话字段，不能只是隐藏或注释 - 拆完后要问自己一句：这个字段能否通过
JOIN获取？是否属于另一实体的直接特征？如果是，就该删
外键设置 ≠ 满足 3NF
很多人以为只要在 Navicat 里拖线加了 FOREIGN KEY 约束，就自动满足 3NF。这是最危险的误解。
-
FOREIGN KEY只保证引用存在，不消除冗余字段或函数依赖 - 例如学生表仍含
学院名称和学院电话，即使加了学院编号外键，也明显违反 3NF - Navicat 不提供依赖分析功能，也不会标红提示“此处存在传递依赖”
- 验证方式只能靠 SQL：执行
SELECT DISTINCT 学院名称, 学院电话 FROM 学生，若结果行数 ≠SELECT COUNT(DISTINCT 学院名称) FROM 学生，说明同一学院名对应多个电话，直接证伪 3NF
生成 SQL 前必须手动检查字段列表
Navicat 的「正向工程」不会帮你过滤冗余字段，它忠实反映模型里的每一个字段——哪怕你忘了删。
- 生成 SQL 前，在模型中逐个打开每张实体的字段列表，确认无一字段能被其他表通过外键推导出来
- 特别注意命名一致性：所有外键字段统一用
xxx_id（如college_id），避免混用college_name或college_code等歧义命名 - 生成后务必点开「SQL 预览」，逐行读
CREATE TABLE语句，而不是直接执行 - 如果发现某张表字段过多、ID 列密集（如同时出现
csr_id、customer_id、vehicle_id），大概率说明业务语义没理清，需要回退到逻辑模型重审实体边界
真正难的不是拖拽连线或生成 SQL，而是你在画每个字段时，脑子里得持续判断：“它由谁决定？能不能被另一个实体唯一确定？”——这个判断无法被工具替代，Navicat 再新版本也做不到。
