先解释下上一篇部门+权限文章“数据库设计系列[04]组织结构加入权限系统”最终的结果:
1> Employee:独立管理用户信息;
2> Dept:独立管理部门信息;
3> Post(Role)独立管理岗位信息;
4> Resource:独立管理资源(页面和按钮)信息;
5> Organization:管理部门+岗位实例的树形实体;
6> PostPermission:管理岗位的权限,即某个岗位类型对应的页面即按钮信息;
7> EmployeePermission:管理员工的权限,将Organization中的岗位实例分配给员工;
总得来说,还是基于角色操作的访问控制权限,只不过加上了部门以及部门与岗位的树形关系。
公司有总部+分公司,分公司的结构与总公司类似,但也有不同。结构如下:
这个组织机构,并不是正常的公司、部门和岗位之间的一级一级多对多个关系。而是可以岗位下可以有公司,公司下可以直接有岗位,因为并不是所有的部门都需要对应的系统中去的。
加入公司后的权限模型CDM:
1>橙色+黄色的部分是用于权限控制,红色+黄色的部分是用于做组织结构;
2>Post实体的Type表示某个岗位是总公司的还是子公司的,还是公共的。
3>Organization实体中可以有三种数据:Company、Dept和Post,用type做区分。对应的RefID可以存CompanyID、DeptID和PostID.
在业务系统中,偶尔会有某个部门比其它相同的部分多一些权限。总公司的账务比分公司的账务权限大,销售计算机的总经理比销售手机的总经理多一些权限。当遇到这种情况时,我们应该怎么办。
方法一:依然某于角色操作的权限模型,将销售计算机的总经理和销售手机的总经理看作两个不同的岗位类型。两个岗位类型分别做权限,CDM图不变。
方法二:基于角色操作+基于角色实例的权限模型。即销售计算机的总经理和销售手机的总经理的公共权限做成一个总理的岗位类型,然后,销售计算机的总经理这一岗位实例直接与Resource关联,CDM图如下:
权限模型就先写到这,写这个权限模型一是做个记录,防止时间长忘了;二是因为每个系统都要有权限控制,而一些人对权限可能还不是很清楚,所以写出来,标识出一些主要的权限实体,以及常见的关系,以供大家参考。文章中有片面或错误的地方,还问各位指出,先谢谢各位了。