Navicat不支持角色建模的ER图或权限可视化设计，需手动创建users、roles、role_permissions三张表实现RBAC模型，注意主键、外键及复合主键设置，并通过查询验证权限链路。
navicat 本身不提供角色建模的er图或权限关系可视化设计能力——它是个管理工具，不是权限建模平台。真正要设计“用户-角色-权限”模型，得先在数据库里建好三张表（users、roles、permissions），再用 navicat 辅助建表、填数据、测试查询逻辑。
先建三张核心表：users / roles / role_permissions
这是 RBAC（基于角色的访问控制）最简可行结构。Navicat 的“新建表”功能能快速完成，但字段设计容易错：
-
users表必须有唯一标识字段（如user_id），别只依赖username做主键——登录名可能变更 -
roles表建议加role_code字段（如'admin'、'viewer'），比纯中文名更利于程序判断和迁移 -
role_permissions是关联表，**必须设复合主键**：(role_id, permission_id)，否则重复授权会失败 - 外键约束别漏：Navicat 建表时勾选“Foreign Key”，指向
roles.role_id和permissions.permission_id
示例建表语句（MySQL）：
CREATE TABLE `users` ( `user_id` INT PRIMARY KEY AUTO_INCREMENT, `username` VARCHAR(50) UNIQUE NOT NULL, `email` VARCHAR(100) ); <p>CREATE TABLE <code>roles</code> ( <code>role_id</code> INT PRIMARY KEY AUTO_INCREMENT, <code>role_code</code> VARCHAR(20) UNIQUE NOT NULL, <code>description</code> VARCHAR(100) );</p><p>CREATE TABLE <code>permissions</code> ( <code>permission_id</code> INT PRIMARY KEY AUTO_INCREMENT, <code>code</code> VARCHAR(30) UNIQUE NOT NULL, -- 如 'user:read', 'order:write' <code>name</code> VARCHAR(50) );</p><p>CREATE TABLE <code>role_permissions</code> ( <code>role_id</code> INT NOT NULL, <code>permission_id</code> INT NOT NULL, PRIMARY KEY (<code>role_id</code>, <code>permission_id</code>), FOREIGN KEY (<code>role_id</code>) REFERENCES <code>roles</code>(<code>role_id</code>), FOREIGN KEY (<code>permission_id</code>) REFERENCES <code>permissions</code>(<code>permission_id</code>) );
用Navicat导入/填充初始角色与权限数据
建完表后，直接双击打开 roles 和 permissions 表，在网格里手动插入几条基础数据即可。注意两个易错点：
- Navicat 默认开启“自动提交”，但批量插入时建议先关掉（菜单栏 → 工具 → 选项 → SQL 编辑器 → 取消勾选“自动提交”），避免某条失败导致整批回滚失败
-
role_permissions关联数据不能靠手输——用 Navicat 的“查询”功能写 JOIN 插入更稳，例如：INSERT INTO role_permissions (role_id, permission_id) SELECT r.role_id, p.permission_id FROM roles r, permissions p WHERE r.role_code = 'viewer' AND p.code = 'user:read'; - 别把权限字符串硬编码进应用层；Navicat 里维护好
permissions.code，程序只认这个字段值
权限验证：用Navicat模拟不同角色的SQL执行边界
建模不是为了画图，而是确保权限逻辑跑得通。Navicat 的查询窗口就是最直接的验证场：
- 新建连接时，用刚创建的用户账号登录（比如
viewer_user），然后执行SELECT * FROM users;—— 应该成功；但DELETE FROM users WHERE user_id = 1;必须报错 - 如果删操作没报错，说明不是数据库级权限控制失效，就是你的应用没走
role_permissions查表逻辑 - Navicat 不会自动帮你校验“用户→角色→权限”链路是否生效；你得自己写查询验证：
SELECT p.code FROM users u JOIN user_roles ur ON u.user_id = ur.user_id JOIN role_permissions rp ON ur.role_id = rp.role_id JOIN permissions p ON rp.permission_id = p.permission_id WHERE u.username = 'alice';
Navicat导出权限模型为SQL脚本供团队复用
设计定稿后，右键点击数据库 → “转储SQL文件” → “仅结构”即可导出建表语句。但要注意：
- 默认导出不含外键约束语句（尤其 MySQL 5.7+），需在导出设置里勾选“添加外键约束”
- 如果用了 PostgreSQL 或 SQL Server，
role_permissions的复合主键语法略有差异，Navicat 导出时会自动适配，但建议人工核对PRIMARY KEY (role_id, permission_id)是否保留 - 不要导出测试数据——权限模型是结构契约，数据属于环境配置，应由部署脚本或初始化服务注入
真正的难点不在 Navicat 点几下，而在于想清楚：哪些操作该收口到角色，哪些该拆成细粒度权限码，以及用户能否同时属于多个角色。这些决策一旦落地，改起来就牵一发而动全身。
