通用数据权限设计思维概述

1、数据权限概述

  1.1 什么是数据权限?
  数据权限是指对系统用户进行数据资源可见性的控制,通俗的解释就是:只有符合条件的用户才能看到该条件下对应的数据资源.举个简单的例子:
  本组织的销售人员只能看见本组织的客户信息。
  某专职会计只能看见A部门及其下级部门的单据。
  上述这些需求,使用硬编码也是可以实现的,但是在业务快速发展的过程中,类似这种数据权限需求会越来越多,如果全部采用硬编码的方式,无疑会给我们带来巨大的开发和维护压力。
  1.2 要素分析
  从数据权限的解释来看,只有符合条件的用户才能看到该条件下对应的数据资源.由此可以分析出数据权限控制中几个关键要素:
  1.主体。狭义上来讲,主体单指用户,但是实际应用上来讲,权限可能分配给某一群或某一类人更方便,所以广义上的主体,我们可以扩展到身份,角色,职务等跟用户相关的概念。
  2.资源。即需要控制访问范围的数据,例如客户信息,部门信息。
  3.规则描述。即主体对于特定的数据资源适用的条件。
  以上是数据权限的基础三要素。

2、数据权限设计

  理论上来说,数据权限描述的是用户在访问受控的系统数据时,获取用户对数据资源适用的条件规则,而用户对资源的条件规则一般并不是唯一的,例如:
  某用户在填制单据时,使用的数据资源要符合如下规则:
  物料 的 物料分类 的 编码是以‘01‘开头的
  并且 部门的主管是‘张三‘
  并且 客户信息的所属组织是用户的所属组织。
  像这样的规则逻辑如何用程序来描述呢?
  2.1规则和原子规则
  2.1.1规则
  根据上个章节的描述,其实数据权限可以表达为对不同主体所分配的数据资源的适用性条件的组合,剥离主体这个不确定的受众之后,其实数据权限可以描述成针对不同数据资源的适用性条件,这个我们可以归纳成一个数据规则,而这个规则具有通用性,可以被多个受众/主体使用,所以我们将相对完整并独立的数据资源的适用性条件声明为规则。规则直接可以组合成新的规则。例如
  物料 的 物料分类 的 编码是以‘01‘开头的
  这个可以认为是针对物料这个资源的一个规则。
  物料 的 物料分类 的 编码是以‘01‘开头的
  并且 部门的主管是‘张三‘
  并且 客户信息的所属组织是用户的所属组织。
  这个可以认为是对某个用户/角色的规则
  2.1.2 原子规则
  从上面列举的例子我们可以看到,规则可以是多个资源的适用性条件组合,也可以是多级资源的适用性条件拼接,这样我们描述一个规则时可能会有多种方式,这样反而不利于我们建立规则描述的标准,我们需要建立一个标准来规范它,在此,我们定义:对于资源和资源自身直接属性的非组合性条件限定属于基础规则,例如
  物料=A
  物料的物料分类=A(因为物料分类是物料的直接属性)
  都是基础规则
  而
  物料的物料分类的编码=A牵扯到了物料和物料分类2个资源的属性,不属于基础规则。
  同样的
  物料=A并且物料的物料分类=A也不属于基础规则
  如此,我们可以声明对于单个资源的基础规则描述可以称为原子规则。
  声明了原子规则有什么好处?
  1、原子规则是针对一个资源的简单条件限定,逻辑简单,且不会产生跨领域或跨服务的问题。
  2、所有的复杂逻辑都可以分解为原子规则再进行拼装。
  3、分解后的规则职责明确,追溯方便。
  如下图,将所有的数据规则都最终分解为原子规则后,每个应用只解析自己负责的资源条件即可,不需要产生跨领域的连接和依赖,而且每个规则解析完的结果都非常明确,出问题后非常容易溯源。

  2.2 资源和条件描述
  前面说明的规则的组成部分,那如何将规则程序化呢?
  资源:这个就比较简单,资源实际就是需要控制的数据,一般可以描述成业务对象,考虑多系统多应用的支持,提供统一注册和访问机制即可。
  条件描述:为了将条件描述转换成机器可理解的逻辑,我们需要设计一套逻辑表达式和表达式解析器,比如正则表达式,公式等等,因为目前大部分业务应用是基于关系型数据库开发的,从实现难度考虑,建议采用一些比较方便SQL语法化的逻辑表现形式。
  2.3规则分类
  实际应用中,我们的规则其实主要可以分为两类
  1)静态数据型
  此类规则的限定条件一般是跟环境无关,例如:
  地区分类=北京
  商品分类=办公用品
  明确的资源和明确的值范围。可以预先计算出结果并存储起来以备使用。
  2)动态逻辑型
  此类规则的限定条件一般是和环境信息相关,根据环境信息动态变化的,例如:
  客户的所属组织=用户的所属组织
  条件的判断与登录的用户身份息息相关,不能预先计算得到结果,需要动态解析计算的。
  静态数据型可以通过预先计算提高效率,但是一般会存在数据时效性的问题。
  静态数据型可以转换成动态逻辑型,但是动态逻辑型一般不能转成静态数据型。
  2.4多应用规则注册与解析设计

  企业系统中,为了统一数据管理,有的建立了公共数仓,有的不一定有,为了适多应用多场景的情况,我们设计了权限的解析模型,每个应用都针对自己的资源发布原子服务,然后公共数仓针对公用的数据发布代理服务,原子服务和原子服务直接因为是跨服务调用,所以只能顺序调用,而同一个数仓发布的代理服务,因为数据存储在同一位置,可以进行规则合并。

原文地址:https://blog.51cto.com/14084875/2422499

时间: 2024-08-25 17:36:20

通用数据权限设计思维概述的相关文章

通用数据权限的思考与设计

1 数据权限概述 1.1 什么是数据权限? 数据权限是指对系统用户进行数据资源可见性的控制,通俗的解释就是:`符合某条件的用户只能看到该条件下对应的数据资源`.那么最简单的数据权限大概就是:用户只能看到自己的数据.而在正式的系统环境中,会有很多更为复杂的数据权限需求场景,如: 领导需要看到所有下属员工的客户数据,员工只能看自己的客户数据: 经理A能看到所有企业客户,经理B只能看到年销售额小于1000万的企业客户: 角色A能看到全国的产品数据,角色B只能看到上海的产品数据: 上述这些需求,使用硬编

通用数据权限管理系统设计

一: 应用场景: 在实际应用中,数据权限的控制点一般相对固定,如针对公司.部门.个人.客户.供应商等,也就是说数据权限一般针对指定数据类型下的一些数据对象. 例如:某公司有北京生产部.上海生产部和保定生产部,现在需要定义几种角色: 总部总监         -- 能察看所有生产部的产品: 北京生产部经理 -- 只能察看北京生产部的所有产品: 上海生产部经理 -- 只能察看上海生产部的所有产品: 保定生产部经理 -- 只能察看保定生产部的所有产品: 二:角色定义: 上述角色的定义如下: -----

关于数据权限设计的一些想法

序言 在各种系统中,要保证数据对象的安全性以及易操作性,使企业的各业务部门.职能部门能够方便而且高效的协同工作,那么一个好的数据权限管理设计就成为一个关键的问题.虽然企业中各个单元的工作流程有所不同,处理的数据对象也有所不同,但是在组织结构.信息的处理方式上具有很多相同的地方,这就为设计数据对象的权限控制提供了一个抽象基础.数据权限的控制不同于一般的功能权限的控制,一般的功能权限指的是某个用户.角色或者是某个用户组能不能操作某种功能.而数据权限指的是某个用户.角色或者是某个用户组对某个数据对象的

JAVA 数据权限设计

数据权限设计 序言 在各种系统中,要保证数据对象的安全性以及易操作性,使企业的各业务部门.职能部门能够方便而且高效的协同工作,那么一个好的数据权限管理设计就成为一个关键的问题.虽然企业中各个单元的工作流程有所不同,处理的数据对象也有所不同,但是在组织结构.信息的处理方式上具有很多相同的地方,这就为设计数据对象的权限控制提供了一个抽象基础.数据权限的控制不同于一般的功能权限的控制,一般的功能权限指的是某个用户.角色或者是某个用户组能不能操作某种功能.而数据权限指的是某个用户.角色或者是某个用户组对

通用用户权限设计

设计User表,Role表,UserRole表,Right表,RightRole表,Module表,Function表. 其中User表主要存放用户信息,Role表主要存放用户的角色,UserRole表主要是User和Role的关联关系,Right表主要存放一些权限,比如说新增某个按钮的权限,删除,查询某个东西的权限,RightRole表主要是角色拥有哪些权限的关联表.如果还有分层模块的话,就必须在Right表中关联Module表,module表主要是存放按钮或者某个权限在哪个模块,再建一张增删

大话设计,没有模式—通用权限设计与实现

当代码写多了,总有些是经验,但经验是什么呢?if-else用的次数比别人多?显然不是.有些超棒的设计可以谓之经验! 功能权限网络上流行的经典的权限设计是[主体]- [领域] - [权限]( who.what.how问题原型 ) 的设计思想,其中: [主体]可以是用户,可以是角色,也可以是一个部门 [领域]可以是一个模块,可以是一个页面,也可以是页面上的按钮 [权限]可以是"可见",可以是"只读",也可以是"可用"(如按钮可以点击) 为了简化程序开

论权限设计

都是老生常谈的东西,我只是做一个总结.我接触过的权限设计一般都是做成功能类型的,不会颗粒度很细.权限关系有很多种设计与实现,有颗粒度细的,对数据做权限管理的(比 较喜欢,一般这样的系统都是需要定制的,很难做到通用化.),颗粒度大的,也就是常用的,大都是根据功能上的划分模块来做. 如果是颗粒度比较粗的比如,我列出我们需要的建的表.管理用户表:存各种管理员基础信息角色表:存储各种角色信息,这也是权限细化的第一部分,多角色系统.功能表:存储功能模块的信息,列出功能的的结构然后就是他们的关联了,然后为了

数据产品设计专题(2)- 数据产品设计方法论之框架体系

一.前言 数据产品设计与业务产品设计差异还是比较大的,根据过往的经验,引入5w+1h分析方法,形成数据产品设计思维框架,解决数据产品经理,面相数据产品设计,无从下手的问题. 二.正文 三.解读       3.1 who - 目标用户 数据产品的目标用户是谁,此处需要注意的问题是,用户的多样性,即同一个数据产品可能有不同的用户,需要针对不同的用户分析其需求:       3.2 why - 用户痛点 数据产品要解决的用户的核心需求问题即为用户痛点,此处需要注意的问题是不同的用户,需求不同,痛点不

通用权限管理设计 之 数据权限

阅读目录 前言 初步分析 通用查询机制 数据权限规则 实际应用 结语 前言 前一篇文章<通用权限管理设计 之 数据库设计方案>介绍了[主体]- [领域] - [权限]( who.what.how问题原型 ) 的设计思想 本文将对这种设计思想作进一步的扩展,介绍数据权限的设计方案. 权限控制可以理解,分为这几种 : [功能权限]:能做什么的问题,如增加产品.[数据权限]:能看到哪些数据的问题,如查看本人的所有订单.[字段权限]:能看到哪些信息的问题,如供应商账户,看不到角色. 部门等信息. 上面