首页 > 编程知识 正文

mysql删除用户权限,oracle创建角色并赋予权限

时间:2023-05-04 18:50:59 阅读:59027 作者:1268

文章来自http://www.cn blogs.com/a 7345678/archive/2008/09/25/1298838.html

在业务系统中实现用户权限管理

B/S系统的权限比C/S的权限更重要。 由于C/S系统具有特殊的客户端,因此访问用户的权限检测可以在客户端或客户端/服务器端进行。 另一方面,在B/S中,所有计算机都已经具备浏览器,如果不建立完全的权限检测,一个“非法用户”很可能能够通过浏览器轻松访问B/S系统的所有功能。 因此,B/S业务系统需要一个或多个权限系统来实现访问权限检测,以确保授权用户可以正常使用功能。 被非法的“非法用户”完全“拒绝”。 本节介绍如何设计满足大多数B/S系统用户功能权限控制的权限系统。

需求说明

根据职责的不同,对系统操作的权限应该不同。 优秀的业务系统,这是最基本的功能。

允许将权限分配给组。 在一个大企业的业务系统中,要求管理者向其下的员工逐一分配系统操作权限既费时又不便。 因此,系统中提出了操作“组”的概念,将权限一致的人编入同一组,并向该组分配权限。

权限管理系统必须是可扩展的。 应该可以添加到任何具有权限管理功能的系统中。 可以像组件一样不断重用,而不是每次开发管理系统时都重新开发权限管理部分。

满足业务系统内的功能权限。 传统的业务系统存在功能权限管理和资源权限管理两种权限管理,不同系统之间可以复用功能权限,但不能复用资源权限。

关于设计

根据NoahWeb运行编程的理念,在设计阶段,系统设计人员不需要考虑程序结构的设计,而是从程序流程和数据库结构入手。 为了实现需求,数据库的设计可以说是其重要性。 “组”操作的概念和整个权限管理系统的复用性都在于数据库的设计。

首先分析一下数据库结构:

首先,action表(以下称为“权限表”)、gorupmanager表(以下称为“管理组表”)和master表(以下称为“人员表”)分别表示“权限”信息、“管理组”信息和“人员表”

这三个表之间的关系是多对多的,一个权限可以同时属于多个管理组,也可以一个管理组包含多个权限。 同样,一个人同时属于多个管理组,一个管理组可能同时包含多个人。 下图:

因为这三个表之间有多对多的关系,所以它们之间的相互作用最好使用其他两个表来进行。 这两个表起着映射的作用,分别是“actiongroup”表“以下简称“权限映射表””和“mastergroup”表“以下简称“人员映射表””,前者后者映射个人表和管理组表之间的交互。 下图:

此外,还需要一个表来控制系统运行时左侧菜单中的权限列,即“权限列表”,如下图所示。

根据上面的分析,设计数据库结构,如下图所示。

为了进行良好的分析,我们分割了数据库结构图,清楚了三个实体表的作用,现在让我们来看看两个映射表的作用。

权限图如下图所示。

首先,让我们看看权限映射表与管理组表和权限表之间的字段关联。

请查看图中的红圈,首先查看gorupid字段的关联。 此关联在实际数据库中表现为:

如果管理组表中超级管理员的groupid为1,则权限映射表中groupid为1的权限是超级管理员拥有的权限,如所示。

使用groupid字段关联是为了检查管理组可以执行的权限。 但是,这些权限的详细信息将通过action字段关联进行查询。

action字段与数据库相关联的情况如下图所示。

此关联查询权限映射表中的权限详细信息。 总的来说,您可以看到一个管理组可以执行的权限以及这些权限的详细信息。

你可能会想,为什么不使用actionid字段进行关联? 因为:

权限表中的id字段可能在多次数据库操作后发生更改。

权限映射表中只记录了一个管理组可以执行的权限。

当权限表的id发生变化时,权限映射表中的记录也发生变化。

管理组可以执行的权限错误是非常不可取的。

考虑到上述内容,必须使用action字段进行关联。 理由如下。

在权限表中,id可能会发生更改,但不能在任何情况下更改action字段。

权限映射表中记录的action字段也不会改变。

一个管理

组可以执行的权限就不会出错了。

二 人员映射表 如下图:

我们来了解一下人员映射表与管理组表以及人员表之间的字段关联,如下图:

看图中的红圈部分,先看groupid字段关联,这种关联方式在数据库中的表现如下图:

如图,“超级管理员”组的groupid为1,我们再看人员映射表,admin属于超级管理员组,而administrator属于超级管理员组,同时也属于管理员组。

使用这种关联方式,是为了查到一个管理组中的人员有谁。和上面一样,人员的详细信息是靠id字段(人员映射表中是masterid字段)关联查询到的。

id字段(人员映射表中是masterid字段)关联表现在数据库中的形式如下图:

一个人员可能同时属于多个“管理组”,如图中,administrator就同时属于两个“管理组”。所以,在人员映射表中关于administrator的记录就会是两条。

这种关联方式才查询到管理组中人员的详细信息有哪些。综合起来,才可以知道一个管理组中的人员有谁,以及这个人员的详细信息。

再结合上面谈到的权限表和权限映射表,就实现了需求中的“组”操作,如下图:

其实,管理组表中仅仅记录着组的基本信息,如名称,组id等等。至于一个组中人员的详细信息,以及该组能够执行的权限的详细信息,都记录在人员表和权限表中。两张映射表才真正记录着一个组有哪些人员,能够执行哪些权限。通过两张映射表的衔接,三张实体表之间的交互才得以实现,从而完成了需求中提到的“组”操作。

我们再来看一下权限分栏表与权限表之间的交互。这两张表之间的字段关联如下图:

两张表使用了actioncolumnid字段相关联,这种关联方式在数据库中的表现如下图:

如图所示,通过这种关联方式,我们可以非常清晰的看到权限表中的权限属于哪个分栏。

现在,数据库结构已经很清晰了,分配权限的功能以及“组”操作都已经实现。下面我们再来分析一下需求中提到的关于权限管理系统的重用性问题。

为什么使用这种数据库设计方式搭建起来的系统可以重用呢?

三张实体表中记录着系统中的三个决定性元素。“权限”,“组”和“人”。而这三种元素可以任意添加,彼此之间不受影响。无论是那种类型的业务系统,这三个决定性元素是不会变的,也就意味着结构上不会变,而变的仅仅是数据。

两张映射表中记录着三个元素之间的关系。但这些关系完全是人为创建的,需要变化的时候,只是对数据库中的记录进行操作,无需改动结构。

权限分栏表中记录着系统使用时显示的分栏。无论是要添加分栏,修改分栏还是减少分栏,也只不过是操作记录而已。

综上所述,这样设计数据库,系统是完全可以重用的,并且经受得住“变更”考验的。

总结:

此套系统的重点在于,三张实体表牢牢地抓住了系统的核心成分,而两张映射表完美地映射出三张实体表之间的交互。其难点在于,理解映射表的工作,它记录着关系,并且实现了“组”操作的概念。而系统总体的设计是本着可以在不同的MIS系统中“重用”来满足不同系统的功能权限设置。

附录:

权限管理系统数据表的字段设计

下面我们来看看权限管理系统的数据库表设计,共分为六张表,如下图:

action表:

action表中记录着系统中所有的动作,以及动作相关描述。

actioncolumn表:

actioncolumn表中记录着动作的分栏,系统运行时,左侧菜单栏提供了几块不同的功能,每一块就是一个分栏,每添加一个分栏,该表中的记录就会增加一条,相对应的,左侧菜单栏中也会新增机一个栏。

actiongroup表:

actiongroup表记录着动作所在的组。

groupmanager表:

groupmanager表记录着管理组的相关信息,每添加一个管理组,这里的记录就会增加一条。

mastergroup表:

mastergroup表记录着管理员所在的管理组,由于一名管理员可能同同时属于多个组,所以该表中关于某一名管理员的记录可能有多条。

master表:

master表记录着所有管理员的信息,每添加一个管理员,该表就会增加一条记录。

版权声明:该文观点仅代表作者本人。处理文章:请发送邮件至 三1五14八八95#扣扣.com 举报,一经查实,本站将立刻删除。