B/S系统权限设计:实现用户权限管理

需积分: 14 10 下载量 112 浏览量 更新于2024-09-23 2 收藏 182KB DOC 举报
"比较通用的权限数据库设计" 在B/S(浏览器/服务器)系统中,权限数据库设计扮演着至关重要的角色,因为它确保了系统安全性和数据保护。与C/S(客户机/服务器)系统相比,B/S架构由于依赖标准的浏览器作为客户端,权限管理必须在服务器端严谨执行,以防止未经授权的用户访问敏感信息或执行不应有的操作。 一个通用的权限数据库设计应具备以下几个关键特性: 1. 用户差异化权限:不同的用户角色对应不同的操作权限。系统需要能够区分并设定不同职责的人员所能执行的操作,确保每个用户只能访问和操作与其职责相符的功能。 2. 组权限分配:为了便于管理,权限系统应支持对用户进行分组,并允许管理员对组进行权限分配。这样,管理员无需为每个单独用户设置权限,只需设置好各个组的权限,节省时间和资源。 3. 可扩展性:权限管理系统应该是模块化的,可以轻松地融入到各种业务系统中,而不是每个系统都需要独立开发权限管理模块。这提高了代码复用性和开发效率。 4. 功能权限与资源权限:在传统业务系统中,权限管理通常包括功能权限(用户可以执行哪些操作)和资源权限(用户可以访问哪些具体资源,如文件、记录等)。功能权限在不同系统间可重用,而资源权限因系统特定而不可复用。 在设计权限数据库时,主要涉及以下核心表格: - Action表(权限表):记录所有可用的操作或功能权限。 - GroupManager表(管理组表):存储管理组信息,每个组对应一组权限。 - Master表(人员表):包含所有用户信息,用户可归属多个管理组。 这三个表之间的关系是多对多关联。一个权限可以被分配给多个管理组,一个管理组可以包含多个权限。同样,一个用户可以属于多个管理组,而一个管理组可以包含多个用户。这种设计允许灵活的权限分配和用户组织。 在实际设计中,可能还需要额外的关联表来处理这些多对多关系,如`group_action`表用于连接管理组和权限,`user_group`表用于连接用户和管理组。这些关联表使得权限分配更加精细化和可调整。 此外,为了实现动态的权限控制,还可以引入角色概念,让用户可以扮演多个角色,每个角色对应一组预定义的权限。通过角色的管理和切换,可以轻松地调整用户权限。在数据库中,这可能意味着需要添加`Role`表和相关的关联表。 一个有效的权限数据库设计应该兼顾灵活性、可扩展性和易管理性,以满足不同规模和类型的B/S业务系统的权限控制需求。
2009-11-03 上传
1、 抽象——总体思路。 先看这个ER图。 很简单,就是说明一下人员和资源的关系,一个人可以使用多个资源,一个资源可以被多个人使用,就是多对多的关系了。 不知道这个是不是可以叫做“抽象”。这个就是在金字塔的顶端来看权限了,站在顶端来看,就这么一点,估计没有那种情况可以逃出这个描述吧。 资源:这里指的资源是广义上的资源,包括很多的东东,模块、数据,菜单、节点、按钮、控件,表、字段、存储过程,页面、窗口、表单、图表、报表,什么都可以算作是一种资源。您也可以把您遇到的一些情况都来算作是一种资源。关于资源先说这些,下面还有详细的说明。 2、 加入权限 第一个图也太简单了,我们把他详细一下,把人员分成两个表——人员基本信息和登录信息,在加入“权限”。就是下面这个表了。 人员分成两个表可以应对很多的情况,比如一个人可以有多个登录帐号,人员基本信息还可以和其他的表相关联,登录方面的需求有什么变化的话,只需要修改登录信息表就可以了,不会影响人员基本信息表,不会让其越来越臃肿。 以前对于“权限”是很模糊的,似有似无的感觉,现在看来他其实就是一个多对多的关联表,呵呵。当然您可以说我的这个看法不对,呵呵,我只是说一下我的感觉。 3、 加入角色 第二个图,是把帐号的资源直接联系起来,这个有一个不方便的地方,比如有五个业务员他们的功能都是一样的,但是我们却需要做五遍一样的操作才能给这五个业务员设置好权限,而当业务员可以做的事情有变化的时候,我就又需要做五次相同的操作,这个就很麻烦了,所以引用了“角色”。 我们可以建立一个业务员角色,设置业务员角色可以做的事情,然后把五个业务员和业务员角色关联起来。这样就方便了,业务员可以做得事情有变化的时候,我只需要修改业务员角色可以做得事情就可以了。 您可能会问,客户的人少,每个人做得事情都不一样,这个怎么办呀? 这也好办呀,一个人一个角色就可以了。虽然对于这种情况多用了一个角色,有点绕远的感觉,但是总体来说是可以接受的。角色初期设置一下就可以了,角色和人员“绑定”之后,修改角色可以做什么事情,和修改人员可以做什么事情,操作步骤都是一样的。 您可能又问了,客户是一个很大的公司,设置了n个角色之后,客户提出了一个需求:张三这个人比较特殊,他可以做XX事情,但是有没有对应的角色,也不想再多设置一个角色了,需要直接给张三设置可以做这件事情就可以了。 这个又要怎么处理呢?是不是要修改表结构了呢?我是不想改的,还是用角色绑定的方法来处理,增加一个“张三专用角色”,这个角色是“隐藏”的,不和其他的角色一样的管理,需要通过对“张三”来管理。这个好像说不太清楚,先这样吧,呵呵。 4、 表关联图 我觉得ER图就是ER图,不能代替表关系图,所以我就又做了一个表关系图。 【图四】 左面从上往下看,人员、登录帐号、角色、资源,右面是两个多对多的关联表。这个看起来就比较清晰了吧。 这个设计还可以吧,资源保罗万象什么都可以往里放,您可以展开您的联想,帮想到的东东都放进去就可以了。 这个图从设计的角度来说应该是挺简洁的,五六个表就搞定了。而且也可以适合很大的范围,因为那个资源的定义实在是太广泛了,到了无所不包的程度了。但是这个设计真的好吗?或者是实用吗? .......