2006年08月18日 11:15:52
通用数据权限管理系统设计
|
通用数据权限管理系统设计（一） 作者：老丁 (笔名：逸云) 转载请注明出处：http://laoding.ccidnet.com 前言： 本文提供一种集成功能权限和数据权限的解决方法，以满足多层次组织中权限管理方面的集中控制。本方法是RBAC（基于角色的访问控制方法）的进一步扩展和延伸，即在功能权限的基础上增加数据权限的管理，实现数据权限和功能权限的集中处理。 解释： 功能权限：能做什么的问题，如增加销售订单； 数据权限：能在哪里干什么的问题，如察看北京分公司海淀销售部张三的销售订单； 术语： 资源：系统中的资源，主要是各种业务对象，如销售单、付款单等； 操作类型：对资源可能的访问方法，如增加、删除、修改等； 功能：对资源的操作，是资源与操作类型的二元组，如增加销售单、修改销售单等； 数据类型：业务系统中常用的数据权限类型，如公司、部门、项目、个人等； 数据对象：具体的业务对象，如甲公司、乙部门等等，包括所有涉及到数据权限的对象值； 权限：角色可使用的功能，分角色的功能权限和角色的数据权限； 角色：特定权限的集合； 用户：参与系统活动的主体，如人，系统等。 通用数据权限管理系统设计（二） 方法说明： 在实际应用中，数据权限的控制点一般相对固定，如针对公司、部门、个人、客户、供应商等，也就是说数据权限一般针对指定数据类型下的一些数据对象。 本方法中，数据权限的依赖于功能权限，是对功能权限的进一步描述，说明角色在指定的功能点上的数据控制权限。 本方法中采用“没有明确规定即视为有效”的原则，如果没有定义功能的数据权限，则说明该角色具有该功能的全部的权限。如果定义了功能的某种类型的数据权限，则该用户只具有该类型下指定数据的数据权限。 这段话比较绕口，下面举个例子实际例子。 某公司有北京销售部、上海销售部和广州销售部三个销售部，现在需要定义几种角色： 销售总监 -- 能察看所有销售部的销售订单； 北京销售经理 -- 只能察看北京销售部的所有销售订单； 上海销售经理 -- 只能察看上海销售部的所有销售订单； 广州销售经理 -- 只能察看广州销售部的所有销售订单； 上述角色的定义如下： ------------------------------------------------------------------- 角色名称 功能 数据类型 数据对象 ------------------------------------------------------------------- 销售总监 察看销售订单 北京销售经理 察看销售订单 部门 北京 上海销售经理 察看销售订单 部门 上海 广州销售经理 察看销售订单 部门 广州 ------------------------------------------------------------------- 上述定义中，销售总监只定义了功能权限，而没有定义数据权限，所以销售总监能够察看所有的销售订单；而其他几位销售经理分别定义了这一功能的数据权限，所以只能察看指定部门的销售订单。 在实际应用中，往往会出现部门分组，组长能够察看本组所有人员处理的销售订单的情况，以及某些情况下，某些人只能察看本人的销售订单的情况，这些特殊情况在上述的说明中无法解决，需要在设计和实现中进行处理。 北京销售代表 -- 只能察看北京销售部的本人的所有销售订单； 北京销售代表 察看销售订单 部门 北京 个人 通用数据权限管理系统设计（三）--数据库设计 我们先来看看传统的基于角色的权限管理系统，如下图所示，最简单的基于角色的权限管理由系统功能、系统角色、系统用户、角色功能和用户角色五部分组成。 图一：基于角色的数据库结构  为实现数据权限控制，在设计上对基于角色的权限管理进行扩充，如下图所示：图二：通用数据权限管理系统数据库设计 对比两张图，我们可以看到，他们之间的主要变化为： 1、 增加系统资源信息和操作类型信息，系统资源为树形结构、如销售模块、销售订单等；操作类型记录可能的操作，如增加、删除、修改、查看、查询等，系统功能是资源与操作类型的组合，对资源的操作就是系统功能。 2、 增加数据对象类型和数据对象两张表，数据对象类型记录系统中需要控制的对象类型，如部门、库房、员工、客户、供应商等；数据对象记录各对象类型的对象实例，如北京销售部、上海销售部、张三、李四等等。（独立保存的好处后面会说到） 3、 增加系统资源与数据对象类型的关联表（多对多），本表为配置表，说明某种资源可能需要的控制点，如销售订单与部门类型的关联可能涉及到分部门分配权限；销售订单与客户的关联可能涉及到按客户分配权限等等。 4、 增加数据对象与角色权限的关联，这张表是真正最终实现数据权限管理的所在地。 通过这种设计，能够最小化地减少对原有权限系统的更改，并且可以很灵活地增加数据的控制点。在产品化软件的设计中使用，能够灵活满足客户的需要。 下一篇文章将讨论这种结构如何满足第二部分功能需求的问题，如果时间允许，将对程序的设计做进一步阐述。 本设计方法已应用于自行开发的通用供应链管理系统中，欢迎指正。 察看相关文章请返回开源供应链[进销存]系统说明目录 Tags：
权限设计 数据权限
|
一共有 9 条评论
非常感谢你的建议。关于你的几点意见的答复如下：
〉Q1、权限管理我认为应该建立在组织结构设计基础上的
这套权限系统设计是独立的，可以看作与组织机构无关；
〉Q2、权限管理中的用户和组织结构上的人员应该分开存储
没错，本文中的系统用户与组织机构中的人员是独立的，他们通过帐号映射关联（只是虚关联）。组织机构中的一个人可以有多个帐号。
〉Q3、数据权限的控制应该默认为本组织或本部门的数据，这样才能在灵活和效率上找到平衡，否则太多的数据权限设置就是个问题，特别是多极权限管理中；您的例子没能说明你的设计的好处；虽然我已经明白；
多谢理解，这种方法支持指定部门或者默认本部门，因为涉及到实现层面的问题，因此没有太多说明。
〉Q4、没有在多极权限管理方面进行说明，逐级授权，每一级系统管理员可授权范围可以设置；还有各级系统管理员的产生和管理问题
这个建议很好，我的理解你指的是与组织结构相关的逐级授权，不知是否正确？
1、权限管理我认为应该建立在组织结构设计基础上的
2、权限管理中的用户和组织结构上的人员应该分开存储
3、数据权限的控制应该默认为本组织或本部门的数据，这样才能在灵活和效率上找到平衡，否则太多的数据权限设置就是个问题，特别是多极权限管理中；您的例子没能说明你的设计的好处；虽然我已经明白；
4、没有在多极权限管理方面进行说明，逐级授权，每一级系统管理员可授权范围可以设置；还有各级系统管理员的产生和管理问题
我们系统的做法是：
系统部署时设置两个内部管理员，一个系统管理员，一个人事管理员；初化后系统管理员将下级机构加入可访问系统的列表中，并产生该机构的两个管理员