当前位置：首页 > 实用文档 > 其他范文> 关于用户角色权限的一点想法数据库教程

关于用户角色权限的一点想法数据库教程

时间：2023-10-10 08:18:54 其他范文收藏本文下载本文

关于用户角色权限的一点想法数据库教程（推荐3篇）由网友“天天懒虫”投稿提供，以下是小编精心整理的关于用户角色权限的一点想法数据库教程，供大家参考借鉴，希望可以帮助到有需要的朋友。

关于用户角色权限的一点想法数据库教程

篇1：关于用户角色权限的一点想法数据库教程

标题关于用户角色权限的一点想法(1) biggie（原作）关键字关于用户角色权限的一点想法

前言：

权限往往是一个极其复杂的问题，但也可简单表述为这样的逻辑表达式：判断“Who对What(Which)进行How的操作”的逻辑表达式是否为真，针对不同的应用，需要根据项目的实际情况和具体架构，在维护性、灵活性、完整性等N多个方案之间比较权衡，选择符合的方案。

目标：

直观，因为系统最终会由最终用户来维护，权限分配的直观和容易理解，显得比较重要，系统不辞劳苦的实现了组的继承，除了功能的必须，更主要的就是因为它足够直观。

简单，包括概念数量上的简单和意义上的简单还有功能上的简单。想用一个权限系统解决所有的权限问题是不现实的。设计中将常常变化的“定制”特点比较强的部分判断为业务逻辑，而将常常相同的“通用”特点比较强的部分判断为权限逻辑就是基于这样的思路。

扩展，采用可继承在扩展上的困难。的Group概念在支持权限以组方式定义的同时有效避免了重定义时

现状：

对于在企业环境中的访问控制方法，一般有三种：

1.自主型访问控制方法。目前在我国的大多数的信息系统中的访问控制模块中基本是借助于自主型访问控制方法中的访问控制列表(ACLs)。

2.强制型访问控制方法。用于多层次安全级别的军事应用。

3.基于角色的访问控制方法（RBAC）。是目前公认的解决大型企业的统一资源访问控制的有效方法。其显著的两大特征是：1.减小授权管理的复杂性，降低管理开销。2.灵活地支持企业的安全策略，并对企业的变化有很大的伸缩性。

名词：

粗粒度：表示类别级，即仅考虑对象的类别(the type of object)，不考虑对象的某个特

定实例。比如，用户管理中，创建、删除，对所有的用户都一视同仁，并不区分操作的具体对象实例。

细粒度：表示实例级，即需要考虑具体对象的实例(the instance of object)，当然，细

粒度是在考虑粗粒度的对象类别之后才再考虑特定实例。比如，合同管理中，列表、删除，需要区分该合同实例是否为当前用户所创建。

原则：

权限逻辑配合业务逻辑。即权限系统以为业务逻辑提供服务为目标。相当多细粒度的权限问题因其极其独特而不具通用意义，它们也能被理解为是“业务逻辑”的一部分。比如，要求：“合同资源只能被它的创建者删除，与创建者同组的用户可以修改，所有的用户能够浏览”。这既可以认为是一个细粒度的权限问题，也可以认为是一个业务逻辑问题。在这里它是业务逻辑问题，在整个权限系统的架构设计之中不予过多考虑。当然，权限系统的架构也必须要能支持这样的控制判断。或者说，系统提供足够多但不是完全的控制能力。即，设计原则归结为：“系统只提供粗粒度的权限，细粒度的权限被认为是业务逻辑的职责”。

需要再次强调的是，这里表述的权限系统仅是一个“不完全”的权限系统，即，它不提供所有关于权限的问题的解决方法。它提供一个基础，并解决那些具有“共性”的(或者说粗粒度的)部分。在这个基础之上，根据“业务逻辑”的独特权限需求，编码实现剩余部分(或者说细粒度的)部分，才算完整，

回到权限的问题公式，通用的设计仅解决了Who+What+How 的问题，其他的权限问题留给业务逻辑解决。

概念：

Who：权限的拥用者或主体（Principal、User、Group、Role、Actor等等）

What：权限针对的对象或资源（Resource、Class）。

How：具体的权限（Privilege, 正向授权与负向授权）。

Role：是角色，拥有一定数量的权限。

Operator：操作。表明对What的How 操作。

说明：

User：与 Role 相关，用户仅仅是纯粹的用户，权限是被分离出去了的。User是不能与 Privilege 直接相关的，User 要拥有对某种资源的权限，必须通过Role去关联。解决 Who 的问题。

Resource：就是系统的资源，比如部门新闻，文档等各种可以被提供给用户访问的对象。资源可以反向包含自身，即树状结构，每一个资源节点可以与若干指定权限类别相关可定义是否将其权限应用于子节点。

Privilege：是Resource Related的权限。就是指，这个权限是绑定在特定的资源实例上的。比如说部门新闻的发布权限，叫做“部门新闻发布权限”。这就表明，该Privilege是一个发布权限，而且是针对部门新闻这种资源的一种发布权限。Privilege是由Creator在做开发时就确定的。权限，包括系统定义权限和用户自定义权限用户自定义权限之间可以指定排斥和包含关系(如：读取，修改，管理三个权限，管理权限包含前两种权限)。Privilege 如“删除” 是一个抽象的名词，当它不与任何具体的 Object 或 Resource 绑定在一起时是没有任何意义的。拿新闻发布来说，发布是一种权限，但是只说发布它是毫无意义的。因为不知道发布可以操作的对象是什么。只有当发布与新闻结合在一起时，才会产生真正的 Privilege。这就是 Privilege Instance。权限系统根据需求的不同可以延伸生很多不同的版本。

Role：是粗粒度和细粒度(业务逻辑)的接口，一个基于粗粒度控制的权限框架软件，对外的接口应该是Role，具体业务实现可以直接继承或拓展丰富Role的内容，Role不是如同User或Group的具体实体，它是接口概念，抽象的通称。

Group：用户组，权限分配的单位与载体。权限不考虑分配给特定的用户。组可以包括组(以实现权限的继承)。组可以包含用户，组内用户继承组的权限。Group要实现继承。即在创建时必须要指定该Group的Parent是什么Group。在粗粒度控制上，可以认为，只要某用户直接或者间接的属于某个Group那么它就具备这个Group的所有操作许可。细粒度控制上，在业务逻辑的判断中，User仅应关注其直接属于的Group，用来判断是否“同组” 。Group是可继承的，对于一个分级的权限实现，某个Group通过“继承”就已经直接获得了其父Group所拥有的所有“权限集合”，对这个Group而言，需要与权限建立直接关联的，仅是它比起其父Group需要“扩展”的那部分权限。子组继承父组的所有权限，规则来得更简单，同时意味着管理更容易。为了更进一步实现权限的继承，最直接的就是在Group上引入“父子关系”。

User与Group是多对多的关系。即一个User可以属于多个Group之中，一个Group可以包括多个User。子Group与父Group是多对一的关系。Operator某种意义上类似于Resource + Privilege概念，但这里的Resource仅包括Resource Type不表示Resource Instance。Group 可以直接映射组织结构，Role 可以直接映射组织结构中的业务角色，比

篇2：一种简单方便的用户权限管理方法使用菜单来管理用户权限数据库教程

菜单|用户权限

今天刚写完一个权限管理的程序，本来有很多解决方案可以实现，只是当时灵机一现，突然想到用菜单来进行权限分配，因为大部分项目的权限要通过菜单来控制，对于在窗口中要控制的非菜单的控件，控制他们其实也可以用一个隐藏的菜单来对应，这样有不少好处，至少可以在一登陆的时候就把所有权限用菜单的ENABLED为TRUE和FALSE来处理，以后，在需要判断权限时，取权限对应菜单的ENABLED一看便知，不用去数据库里取了！用菜单来进行权限分配的一大好处就是直观，所见即所得，通过点选菜单，使菜单项的CHECDED为TRUE即表示拥有该权限了，为FALSE即为不拥有该权限。这样的方式，我认为编程比较简单，比用TREEVIEW来的简单，尤其PB6。5的TREEVIEW还不带复选框，用TREEVIEW来分配权限也是不方便，用数据窗口形式，或则列表框都可以实现，不过我还是自以为用菜单来分配方便简单，于是决定要这样做了！不敢独享，放在这里，也算是对所以帮助过我的网友致谢！

设计思想：

前提：

权限是按菜单来分配的，一个菜单项对应是一个权限，窗口中要控制的非菜单控件通过隐性菜单项来体现到菜单上，保证一个菜单项对应一个权限。

1，从数据库表里取到用户组（角色或者用户，都一样处理）所具有的权限

2根据这些权限设置菜单，将相应菜单项的CHECKED=TRUE（有权限）

3，

用户在菜单上进行权限设置，要设有权限即设置相应菜单的CHECKED属性为真

反之，则假

4确定用户的选择，遍历菜单将每个菜单项与用户组权限表比较，如果用户权限表里有的权限而在对应菜单里CHECKED=FALSE，则删去此权限，为TRUE则不处理，如果用户权限表中没有的权限而在对应菜单里CHECKED=TRUE，则增加此权限，为FALSE则不处理。

效果图如下

：

在每个菜单项的CLICKED事件里写

this.checked=not this.checked

在做这个程序的时候，碰见一个最大的问题就是，在点选菜单时，一点击左键菜单就不展开了，要为下一个权限点选的时候，又要重新点开菜单，这样是很麻烦的。所以我想要是在点开菜单的同时，可以点选很多子项菜单，这样就可以只需要展开一次菜单，然后可以给多个子菜单项进行权限设置了。

这可是个大问题啊，问了很多高人。子定义可视类不能以菜单为基类。又不能给菜单定义用户事件来映射到WINDOW消息上。而且菜单只有CLICKED和SELECTED两个事件，菜单调用CLICKED事件后会自动变成不展开状态，SELECTED事件里又不能用KEYDOWN函数来判断是否点击了鼠标右键或着键盘按下了某个键，在这个事件里去触发窗口里自定义事件（这个事件里放了KEYDOWN来判断是否有鼠标右键或其他键盘键按下），也不能遂愿。郁闷了我一天啊！

今天手写累了，先到这，要是大家觉得放在这不会玷污大家的眼睛的话，我会尽快努力把下文写完的，

待续！

篇3：一种简单方便的用户权限管理方法使用菜单来管理用户权限（下）数据库教程

菜单|用户权限

问题有点棘手，于是想到去MSDN上查看有哪些可以用的关于的菜单消息，我找到了两

WM_MENUCHAR,WM_MENUSELECT,WM_MENUCHAR是用来判断当有菜单项被选中时，接收到了来自键盘的按键的时候触发，WM_MENUSELECT是在菜单项选中时触发，于是我试了两个消息，发现在映射到WM_MENUSELECT的用户自定义事件中用KEYDOWN判断用户是否按下键根本没用，现在大家明白了，WM_MENUCHAR就是解决问题的关键所在。

WM_MENUCHAR消息是在当用户选中了某个菜单项时（任一个），只是只要按下键盘上的任一个有效键，通过消息上的CHAR可以看出来，就可以触发该事件了，这样。我可以在选中某个菜单项的时候，在出来这个消息的事件里让这个菜单项的CHECKED属性变化，这样就可以让菜单保持展开状态，实现复选了。

在菜单所在窗口中定义一个用户事件，映射到系统消息PBM_MENUCHAR 叫US_MENUCHAR

在这个事件里写

int li_upper

li_upper=upperbound(myCurMenu.item)

if keydown(keyD!) and li_upper= 0 then //判断D键是否按下和是否还有下一级菜单，但是在这里keydown判断不了是否鼠标右键被按下，是因为这个消息只取键盘按键按下与否的信息，

myCurMenu.checked=not myCurMenu.checked

myCurMenu.enabled=not myCurMenu.enabled

end if

myCurMenu是个全局变量，用来存放当前用户选中的菜单项，当然这需要在每个菜单项的SELECTED事件里加上一句

MyCurMenu =this

来获得当前高亮显示的菜单。