按照角色权限的最简单的设计
名称 | 描述 |
用户 | 不具备管理功能 |
管理员 | 具备管理普通用户的权限 |
超级管理员 | 具备管理管理员的权限 |
|
|
上面的设计直接将参与系统的用户分为三类角色:用户,管理员,超级管理员。
按照角色权限,粒度划分再小些设计
名称 | 权限 | 描述 |
普通用户 | 普通服务 | 享有系统有限服务 |
VIP用户 | 高级服务 | 享有VIP服务 |
|
|
|
上面是用户的简单划分示例,通过将用户进行权限划分,来提供不同的服务。
名称 | 权限 | 描述 |
产品管理员 | 管理产品模块 | 具备产品模块的管理操作权限 |
客户管理员 | 管理客户模块 | 具备客户模块的管理操作权限 |
|
|
|
上面是管理员的简单划分示例,通过将后台管理员进行权限划分,使的每一个管理员角色具备不同的操作权限,并且不同角色的管理员在管理角色上不存在交叉管理,这样系统的管理部分才有可能保存清晰,完整,有效。
名称 | 权限 | 描述 |
超级管理员 | 管理各类管理员 | 具备最高的管理权限 |
系统管理员 | 管理整个系统,包括管理超级管理员 | 系统管理员具备操作整个系统的最高权限 |
|
|
|
上面是系统级别的管理简单划分示例,一个系统建设完成后应该具备自管理的功能,即:系统环境配置,模块管理,使用系统的干系人管理等都可以通过自身的管理模块完成,而不是人为的修改数据或者系统程序。
按照模块对角色具备的操作权限进行划分,粒度将更细。对于模块层的权限划分使得系统权限管理严格,个角色的智能更加精确,当然系统的设计,实现也相对复杂。
2.用户-角色-权限的一个物理模型
设计示例图如下所示:
用户
三个用户(标识列[主键],用户编码,用户名称)
角色
四种角色(标识列[主键],角色编码,角色名称)
用户角色
用户角色标识列,用户编码,角色编码即构成用户角色中间表。注:实际中一个用户足矣具备多种角色。
模块
[模块标识列,模块编码,模块名称,父模块编码,模块URL]
说明:
父模块编码:用于模块划分粒度层次标识
模块URL:用于模块在WBE应用中的访问标识,当然也可以作为他用。
权限
权限标识,权限编码,权限名称。
模块权限
模块权限标识列,模块编码,权限编码。模块权限表在模块粒度和权限粒度上对模块进行的相应的权限设置,可以简单表述为:具备在某一模块上的某种权限操作。因此将角色和模块权限进行关联将成为角色具备这一粒度层次上的操作权限。
角色权限
角色权限标识列,角色编码,模块权限编码
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
SELECT
t_account.ACCCODE, t_account.ACCNAME,
t_role.ROLECODE, t_role.ROLENAME,
t_module_privilege.MODUELCODE,
t_module.MODUELCODE, t_module.MODUELNAME,
t_privilege.PRICODE, t_privilege.PRINAME
FROM
t_account, t_account_role, t_role, t_role_privilege, t_module_privilege, t_module, t_privilege
WHERE
t_account_role.ACCCODE=t_account.ACCCODE
AND
t_account_role.ROLECODE=t_role.ROLECODE
AND
t_account.ACCCODE=
"400900500"
AND
t_role_privilege.ROLECODE=t_role.ROLECODE
AND
t_role_privilege.MPID=t_module_privilege.MPID
AND
t_module_privilege.MODUELCODE=t_module.MODUELCODE
AND
t_module_privilege.PRICODE=t_privilege.PRICODE
|