前言
随着IT新技术不断完善成熟，企业数字化建设得到全面的发展，数据将成为一个创造财富的重要来源，并且越来越多地被视为一项值得重视的企业资产。未来，很多企业之间的竞争，其实也是资源和数据竞争。那么针对数据资产，如何保障它的安全性呢？数据的权限管理无疑是必不可少的。数据权限从数据源来控制不同的用户能够查看、使用和授权不同的数据表数据（其实就是数据表行列的管控），就如同筑起了一道道护城墙,为数据安全提供了保障。
应用场景
在我们的日常生活中，经常也会接触到许许多多关于数据权限的场景案例，下面我就枚举一些业务场景供大家加深对数据权限的理解。
在公司招聘期间，HR会搭建新员工的档案记录，为了防止员工数据泄露，仅对行政主管和总监设置查看所有员工的档案记录，实现对权限范围内的数据进行管控，让数据和公司行政管理更好地结合，大幅度提高员工管理效率。
在公司的行政管理工作中，我们只能够查询到个人自己的工资或档案信息；还有我们进行入职转正申请或离职申请时，我们的申请信息通常只能够被直属领导、分管领导或单位的一把手看到，而同事或其他部门领导是无法看到。
对于有一定规模且销售直营的公司，一般情况下员工是分布在全国各地，为了便于销售数据的管理和使用，想要不同地区的销售助理也能看到客户经理负责地区的数据，可以通过权限管理设置，实现数据源头的安全控制。同一张销售数据表，不同销售助理只能看到自己负责的用户数据。
在一个超市门店进行日常管理中，店长需要了解门店总销售数据和所有库存数据，以便对门店的经营情况做一个全面了解；营业员只需要了解自己负责的商品区域的销售额和对应商品库存信息，用于明确自己的销售业绩和未来销售计划；收银出纳需要了解总销售数据，进行账务核查矫正；而采购库管，只需要了解所有商品库存信息，进行商品库存核算。这个过程中大家在数据上各取所需，又进行了数据的隔离管控。
业务需求
根据上述描述的数据权限的应用场景，我们进行分析，可以提取出以下核心业务需求。
需求一：根据组织结构，用户能够看见所属部门以及下属部门的所有行数据。实现效果为总公司可以看到所有的数据，分公司只能够看到所在的分公司数据和分公司所管辖部门的所有数据，部门只看自己的数据。
需求二：登录用户只能看到自己有权限的数据。员工用自己的账号登录公司的OA系统时，只能看到自己的工资信息。
需求三：各种权限交叉时的生效逻辑。一个用户同时属于多个部门和角色时，享受权限并集。
需求四：数据分级授权。多部门共用系统、各个部门有其自己的管理员，并给其部门员工分配权限，即实现多级管理员层层分配。分级管理员只能管理自己职责范围内的模板权限分配。
需求五：数据字段（列）支持授权展示。普通HR在查询员工档案信息表时，只会显示员工姓名、年龄、手机号、岗位、级别、入司时间、工龄和学历这些字段信息，高级HR或总监在查询员工档案信息表时，除上述字段外，还会显示年度绩效、月度绩效、薪资、公司关系等等字段信息。
设计方案
我们在进行数据权限的设计过程中，应当遵循两个要点：安全和灵活，即安全是设计的初衷，灵活是系统功能落地的要求。
业务解决方案梳理
方案一:标记数据归属
首先在规划设计时，事先在每一个数据表中设置组织、区域、人等字段信息，标记每一行记录的对应的组织、区域和人信息，同时维护配置系统人员的属性信息（例如：ID、区域、部门、角色等）。再通过角色定义每个功能单据的数据权限，实现不同角色授予同一份表单不同数据权限。最后获取用户信息和角色信息（数据权限）（通俗的讲，就是角色提供限制字段信息，用户提供限制字段对应的值信息），与功能单据的数据内容进行匹配过滤，实现数据权限区分。实体关系图如下所示。
注意事项：一个角色中同一个功能表单的限制选项是单选（即全部可见、组织（部门）限制、区域限制、人员限制进行四选一）；多个角色中对一个功能表单的限制是取并集限制。若一个功能表单的其中一个限制选项是由多个字段组成，则字段间的限制是且的关系（例如区域，有归类区域（华东、华南等）和地理区域（杭州、武汉等），在选择区域限制时，需要同时满足归类区域和地理区域的条件）。
此方案的优点是用户维护简单，开发实现上较对于方案二简单；缺点是需要系统有完善的组织结构和区域结构信息，适用性比较单一。
方案二：建立数据过滤规则
建立数据权限规则体系，规则体系中可配置数据表、字段、字段关系（且、或）、判断符（=、!=、>、< 等）、字段值（相当于配置SQL语句中where后面的信息）。再建立用户或组织与权限规则的关联关系（数据权限）。用户访问系统功能页面时，获取该功能页面对应数据表名信息，结合用户+数据表名信息与数据权限进行匹配，判断该表是否需要限制，若不需要，则直接使用现有查询条件进行查询；若需要，则将规则体系中的限制条件与现有查询条件做拼接，传给后台进行查询，实现数据权限区分。实体关系如下图所示。
此方案的优点是配置灵活，适用性广，大多应用于BI平台；缺点是配置维护复杂，系统实现难度高，容易影响系统查询效率。
Demo设计
Demo设计可以参考
帆软BI的设计。
————————————————
版权声明：本文为CSDN博主「冷暖从容」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/qq_40664711/article/details/123469245
标签：限制,用户,信息,数据表,设计,权限,数据 来源： https://www.cnblogs.com/wl-blog/p/16500886.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。