通用基础表逻辑设计（三）——功能权限

概述

        在一个应用系统中有多个用户，用户通常分为多种角色，每种角色的用户能够访问的页面、能够查看的数据或者能够执行的操作等各有不同，因此需要设计与实现应用系统的权限体系。通过对应用系统进行需求分析，由用例图可知功能需求，由E-R图可知数据需求，应用系统的权限就包括功能权限和数据权限。功能权限描述了一个用户或者一种角色能够访问哪些页面、能够执行哪些操作（按钮、链接等），数据权限描述了一个用户或者一种角色能够查看什么范围内的数据（水平范围内的记录）、能够查看数据的哪些属性（垂直范围内的字段）。本文仅讨论功能权限的设计与实现，从数据库层面尽量实现一种通用的功能权限体系。

部门、用户与角色

        在面向对象分析和设计中，通过用例图可以明确一个应该系统中有哪些用户、用户分哪些角色、用户属于哪个组织架构、各种用户或角色有哪些行为，通过E-R图来分析一个应用系统中的用户有哪些属性、用户与组织架构之间的关系、用户与角色之间的关系。1个用户属于1个部门，1个用户拥有1个或多个角色。用户属于哪个部门，则表示该用户只能查看与该部门关联的数据，这可以通过数据权限实现，也可以通过用户与部门之间的关联以及部门与其数据之间的关联推导出用户可查看哪些数据；用户拥有哪些角色，则表示该用户拥有这些角色赋予的权限。

图1：部门-用户-角色的E-R图

        部门、用户和角色各自包含哪些基本属性，则用以下表说明：

表1：base_user用户表

表2：base_department部门表

表3：base_role角色表

表4：map_user_role用户与角色关联表

模块、操作与权限

        通过模块化设计一个应用系统，可以将系统划分为若干模块（Module：一个模块可以是一个页面、可以是一个控制器等等），每个模块包含各自的操作（Operation：一个操作可以是访问一个页面、可以是点击一个链接、可以是点击一个按钮、可以是点击一个菜单等等），一个模块的一个操作可以定义为最小粒度的权限（Power）。无论是通过点击链接或是按钮，都可以最终指向一个模块的一个操作。所有模块的通用操作我觉得基本上如下表所示：

表5：操作列表

图2：模块-操作-权限E-R图

表6：base_module模块表

表7：base_operation操作表

表8：base_power权限表

用户、角色与权限

        为各角色分配权限，则属于该角色的所有用户都将拥有这些权限。若一个用户还拥有所属角色之外的特殊权限，也可以单独为该用户分配权限，但为了统一规范权限体系，建议为这些特殊权限新建一个角色。一个用户的权限是其所属的所有角色的权限并集。

图3：角色-权限E-R图

表9：map_role_power角色与权限关联表

综述

        配置部门->配置角色->分配权限->添加用户并设置所在部门和所属角色。在前后端分离项目中，一个业务接口为一个操作，一类接口为一个模块，比如ASP.NET MVC WebApi中，使用控制器名作为模块编码，使用方法名为操作编码。

图4：综合E-R图

图5：程序流程图

最后

以上就是长情泥猴桃为你收集整理的通用基础表逻辑设计（三）——功能权限的全部内容，希望文章能够帮你解决通用基础表逻辑设计（三）——功能权限所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。