如何设计ERP系统 的数据权限？？

Posted 2023-05-15

参考技术A 按照岗位体系建立 数据权限 

应用：CRM

优点：1.设置简单，选择按照部门选择

缺点：1.需要维护一套岗位体系

2.不够灵活，不能看到跨部门数据（可以了解到其他部门的 价值 ） 也不能看到上级的数据（有个员工需要根据能力恒定自己的职业规划，那么他会以上级为参考点，去观察上级的销售数据如何）（人事 财务需要看到整个部门的数据，他们也不是领导，他们是专员，而且那些人也不是他们的下属 ，无论如何都看不到数据）

针对角色设置数据权限（实习公司也是这样处理：班主任， 助教， 管理员）

优点：不受岗位框架 影响，可以灵活设置，如果短期内 没有负责到这部分数据，我就取消对应角色权限即可，但不用删除掉这个角色以及权限；再比如 可以设置一个角色“宇宙总局xx指挥中心xx副局”，但实际上不存在这个岗位。

再比如，角色可以多层叠加，比如 华南地区xxx就可以看到华南地区的数据；华东地区xxx就可以看到华东地区的数据；总局可以看到xx所有数据，但是 我们不能让这个人看到所有数据， 只需要让他负责华南与华东即可，则给他两个角色 就好

怎么设置 角色权限呢？

采用 数据规则：规则编辑器

如：客户所在地区 等于 AS地区 且 客户状态 等于 带续签 ，输出结果： 交集

客户所在地区 等于 B地区 且 客户状态 等于 入住   或  客户所在地区 等于 K地区 且 客户状态 等于 签约，输出结果：并集

优点：1. 避免 与岗位直接绑定， 岗位变动 则 权限变动；

2.避免与岗位直接绑定， 僵化 管理，没有角色灵活

3. 可以适合 多种 特殊化场景 （临时需求居多），用完就释放 权限关系，避免数据泄露

缺点：1.需要维护角色 与权限关系

2.数据规则较为复杂，需要进一步管理

3.如果是多层计算，同样数据规则也很复杂

专化 岗位：  提供 岗位 方案  如：销售 （A,B,C都是销售，但A负责a课程的 物料，B负责b课程的人群转化以及转介绍，C负责d项目的引入 ）

不专化岗位：提供 角色 方案    如：销售  人事 （一个月前负责xx项目的招聘工作，一个月后负责xx项目的培训工作）

总结：

数据范围 划分清晰， 准确

尽量减少 维护成本（弄完一套规则体系后尽量不动 维持原态）

设置灵活（可塑，可拆，可整合）

名词解释：

直接下属：辖域 下面一层

所有下属：所有辖域，包括往下一层 往下二层 往下三层，，，

虚拟上级：一个节点

特殊情况处理：

人员变动：  判断人员是否 专化？ if 是，then 岗位；if 不是，then 角色 方案。

部门变动（几乎很少）：

并入新部门： 维持与新部门同个权限位置。

拆分： 经讨论分析，评判每个用户的角色等级。

移出：  撤销原有权限，载入并维持新权限。

用户和角色:通用权限管理系统数据库表结构如何设计？

  一，前言 权限管理系统的应用者应该有三种不同性质上的使用，
A,使用权限
B,分配权限
C,授权权限 
本文只从《使用权限》和《分配权限》这两种应用层面分析，暂时不考虑《授权权限》这种。
二，初步分析用户和角色 说到权限管理，首先应该想到，当然要设计一个用户表，一个权限表。这样就决定了一个人有什么样的权限。
做着做着就会发现这样设计太过繁琐，如果公司里面所有员工都有这样的权限呢，每一个人都要配置？那是一件很痛苦的事情。因此再添加一个角色表，把某些人归为一类，然后再把权限分配给角色。角色属下的用户也就拥有了权限。
用户、角色之间的关系是一个用户可以对应多个角色，一个角色可以对应多个用户。多对多关系。
所以需要一个中间表，相信大家都很熟悉，自然不会有疑问。
应用场景 有了用户和角色以后，就需要设计应用场景，比如一个应用程序有几大模块（系统模块、项目管理模块、销售模块），
类似这样的模块就是一种应用场景，常见的还有 菜单 、 操作 等等。
假设现在我们设计好了，应用场景包括 模块、菜单、和操作，那么应该有以下六种关系

• 一个用户可以对应多个模块，一个模块可以对应多个用户。多对多关系。
• 一个用户可以对应多个菜单，一个菜单可以对应多个用户。多对多关系。
• 一个用户可以对应多个操作，一个操作可以对应多个用户。多对多关系。
• 一个角色可以对应多个模块，一个模块可以对应多个角色。多对多关系。 
• 一个角色可以对应多个菜单，一个菜单可以对应多个角色。多对多关系。  
• 一个角色可以对应多个操作，一个操作可以对应多个角色。多对多关系。

于是建立六张表来维护这六种关系。
这样设计看起来没什么问题。是的，如果没有加入新的关系的话，这样是已经可以满足大部分的需求了。可是如果就是如果，新的关系（需求）往往会加入到系统进来。这个时候就需要再建立一个新的表。系统的复杂度也随着增加。
可以看出，这样的设计有几个问题：

• 数据表设计太复杂
• 应对系统方案过于固定

三，把问题简单化

不同的应用场合，你可能会想出不同的需求，提了一个新的需求以后，可能会发现原来的设计没方法实现了，于是还要添加一个新的表。这也是上面所提到的问题。 
其实不必想得那么复杂，权限可以简单描述为：
某某主体 在 某某领域 有 某某权限 

1，主体可以是用户，可以是角色，也可以是一个部门

2， 领域可以是一个模块，可以是一个页面，也可以是页面上的按钮

3， 权限可以是“可见”，可以是“只读”，也可以是“可用”(如按钮可以点击)

其实就是Who、What、How的问题

因此上面所提到的六张表其实可以设计一张表：




四，实例说明
下面用一个例子做设计说明。“用户、角色在页面上的是使用权限”
详细设计：
1，把菜单的配置放在数据库上，每一个菜单对于一个唯一的编码MenuNo，每一个“叶节点”的菜单项对于一个页面(url)。
2，把按钮的配置放在数据库上，并归属于一个菜单项上（其实就是挂在某一个页面上）。应该一个页面可能会有几个按钮组，比如说有两个列表，这两个列表都需要有“增加、修改、删除”。所以需要增加一个按钮分组的字段来区分。
3,把菜单权限分配给用户/角色，PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Menu",PrivilegeAccessValue为MenuNo,PrivilegeOperation为"enabled"
4,把按钮权限分配给用户/角色，PrivilegeMaster为"User"或"Role",PrivilegeMasterValue为UserID或RoleID,PrivilegeAccess为“Button",PrivilegeAccessValue为BtnID,PrivilegeOperation为"enabled"
5,如果需要禁止单个用户的权限，PrivilegeOperation 设置为"disabled"。
如果不清楚的可以看下图：
 
数据库设计：
 


四，结语
说了这么多，其实我推荐的只是Privilege的表设计。这个表是who、what、how问题原型的设计。不仅扩展性、灵活性都很好，而且将复杂的权限管理系统浓缩成一句话。

而PrivilegeOperation不仅仅只是使用和禁止两种，包括分配权限、授权权限，都可以用这个字段定义。只是这无疑加大了应用程序的设计难度，但是对于表设计可以不做出任何的修改就可以完成，可以看出其灵活性。

http://club.sm160.com/showtopic-934193.aspx