关于权限设计的探讨（转）
但凡涉及多用户不同权限的网络或者单机程序，都会有权限管理的问题，比较突出的是MIS系统。 下面我要说的是MIS系统权限管理的数据库设计及实现，当然，这些思路也可以推广开来应用，比如说在BBS中用来管理不同级别的用户权限。 权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。 这三个部分相互依存，密不可分，要实现完善的权限管理体系，必须考虑到每一个环节可行性与复杂程度甚至执行效率。 我们将权限分类，首先是针对数据存取的权限，通常有录入、浏览、修改、删除四种，其次是功能，它可以包括例如统计等所有非直接数据存取操作，另外，我们还可能对一些关键数据表某些字段的存取进行限制。除此，我想不出还有另外种类的权限类别。 完善的权限设计应该具有充分的可扩展性，也就是说，系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化，要达到这个目的，首先是数据库设计合理，其次是应用程序接口规范。 我们先讨论数据库设计。通常我们使用关系数据库，这里不讨论基于Lotus产品的权限管理。 权限表及相关内容大体可以用六个表来描述，如下：
1 角色（即用户组）表：包括三个字段，ID，角色名，对该角色的描述；
2 用户表：包括三个或以上字段，ID，用户名，对该用户的描述，其它（如地址、电话等信息）；
3 角色-用户对应表：该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色组也可拥有多个用户。包括三个字段，ID，角色ID，用户ID；
4 限制内容列表：该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述，包括三个字段，ID，名称，描述；
5 权限列表：该表记录所有要加以控制的权限，如录入、修改、删除、执行等，也包括三个字段，ID，名称，描述；
6 权限-角色-用户对应表：一般情况下，我们对角色/用户所拥有的权限做如下规定，角色拥有明令允许的权限，其它一律禁止，用户继承所属角色的全部权限，在此范围内的权限除明令禁止外全部允许，范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点，设计的思路也很多，可以说各有千秋，不能生搬硬套说某种方法好。对此，我的看法是就个人情况，找自己觉得合适能解决问题的用。 先说第一种也是最容易理解的方法，设计五个字段：ID，限制内容ID，权限ID，角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限），角色/用户ID，权限类型（布尔型字段，用来描述一条记录表示允许还是禁止） 好了，有这六个表，根据表六，我们就可以知道某个角色/用户到底拥有/禁止某种权限。 或者说，这么设计已经足够了，我们完全实现了所需要的功能：可以对角色和用户分别进行权限定制，也具有相当的可扩展性，比如说增加了新功能，我们只需要添加一条或者几条记录就可以，同时应用程序接口也无须改动，具有相当的可行性。但是，在程序实现的过程中，我们发现，使用这种方法并不是十分科学，例如浏览某个用户所拥有的权限时，需要对数据库进行多次（甚至是递归）查询，极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道，Unix文件系统将对文件的操作权限分为三种：读、写和执行，分别用1、2、4三个代码标识，对用户同时具有读写权限的文件被记录为3，即1+2。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表，加入一个字段：标识码，例如，我们可以将录入权限标识为1，浏览权限标识为2，修改权限标识为4，删除权限标识为8，执行权限标识为16，这样，我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了，例如，假定某用户ID为1，库存表对应的限制内容ID为2，同时规定角色类型为0、用户类型为1，我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为：2,15,1,1。 确实很简单，不是吗？甚至还有更过激的办法，将限制内容列表也加上一列，定义好标识码，这样，我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然，这样做的前提是限制内容数量比较小，不然，呵呵，2的n次方递增起来可是数量惊人，不容易解析的。 从表面上看，上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的，但这样做有个弊端，我们所涉及的权限列表不是相互独立而是互相依赖的，比如说修改权限，其实是包含浏览权限的，例如，我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除（1+4+8=13),但事实上，该用户具有(1+2+4+8=15）的权限，也就是说，在这种方案中，13=15。于是当我们调用API询问某用户是否具有浏览权限时，就必须判断该用户是否具有对该数据表的修改权限，因此，如果不能在程序中固化权限之间的包含关系，就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。 这个问题如何解决？我想到了另外一种设置标识码的方法，那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为2,3,5,7,11，当遇到权限互相包含的时候，我们将它的标识码设定为两个（或多个）基本标志码的乘积，例如，可以将“修改”功能的标志码定为3*5=15，然后将所有的权限相乘，就得到了我们需要的最终权限标识值。这样，我们在询问用户是否具有某项权限的时候，只需要将最终的值分解成质因子，例如，我们可以定义一个用户具有录入+修改+删除库存表的权限为 2*15*7=2*3*5*7，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。 当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：） 我希望以上的分析是正确且有效的（事实上，我也用这些的方法在不止一套系统中实现），但无论如何，我觉得如此实现权限管理，只是考虑了数据库设计和应用程序接口两部分内容，对于实现，还是显得很费劲。因此，我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。 另外，关于数据库设计的思路还有使用二维表的，这将在以后的时间里讨论，关于应用程序接口的设计和实现我也将在利用另外篇幅和大家共同探讨，代码将用类C语法实现（我不喜欢pascal，抱歉） 欢迎朋友们和我联系，mailto:berg@91search.com，也欢迎访问我和另外一位朋友共同建设的网站：http://www.91search.com，那里将有一个音乐搜索的工具软件提供下载。
======================================== 关于权限包容关系通过角色和权限掩码来实现。 /// <summary>
/// 权限保护类型枚举类型。
/// </summary>
public enum ProtectEnum
{
/// <summary>撤回权限保护类型</summary>
RevokeProtect = 0,
/// <summary>授予权限保护类型</summary>
GrantProtect = 1,
/// <summary>拒绝权限保护类型</summary>
DenyProtect = 2
} /// <summary>
/// 系统固定用户或角色枚举类型。
/// </summary>
/// <remarks>
/// 管理员角色：16399 = 100000000001111
/// 所有者角色：16385 = 100000000000001
/// 只读者角色：16386 = 100000000000010
/// 安全员角色：16388 = 100000000000100
/// 配置员角色：16392 = 100000000001000
/// </remarks>
public enum FixedRoleEnum
{
///<summary>系统管理员固定用户</summary>
Administrator = 1,
///<summary>系统管理员固定角色</summary>
Administrators = 16399,
///<summary>所有者固定角色（具有读写操作之权限）</summary>
Authors = 16385,
///<summary>只读者固定角色（具有只读操作之权限）</summary>
Readers = 16386,
///<summary>系统安全管理员固定角色</summary>
Security = 16388,
///<summary>系统设置管理员固定角色</summary>
Setting = 16392
} /// <summary>
/// 系统权限枚举类型。
/// </summary>
public enum PermissionEnum
{
/// <summary>“读取”权限</summary>
FetchPermission = 1,
/// <summary>“新增”权限</summary>
AddNewPermission = 2,
/// <summary>“更新”权限</summary>
UpdatePermission = 4,
/// <summary>“删除”权限</summary>
DeletePermission = 8,
/// <summary>“打印”权限</summary>
PrintPermission = 16,
/// <summary>系统保留，应用于流程处理</summary>
FlowPermission = 1024,
/// <summary>系统保留，应用于流程处理</summary>
VoidPermission = 2048
} 如果用户“Popeye”对“销售出仓单[2009]”系统对象具有读写（读取＋修改＋删除＋新增）权限：（权限表定义如下TPermission）
FormID UID Permission
======= ==== ==========
2009 Popeye 1+2+4+8=15 ***** 上面系统定义的默认权限肯定是不够系统使用的，那么还有一些权限（例如：报关系统中的“计算差异表”“制造申报单”等权限，就由系统再定义），其实不用太担心会不够用的，因为在一个Form中不可能会出现所有权限情况，所以，系统自定义的权限掩码可重复使用在不同的表单中。***** 建议不要把角色和用户分开两张表来存储（可参考MS-SQL Server中的sys_users表），因为在后面的权限定义表需要引用这个表的UID（其可为用户或角色，SQL中是使用UID的数值范围来区别用户与角色的，建议也如此。），版主说的角色与用户分开对待权限设置，这点我不赞成。因为角色只不过是一种用户组，其应该享用用户的权限定义范围，在其下属的角色成员（注意角色成员不同于用户或角色哦，其可以为角色也可以为用户）均默认继承其定义的权限，除非角色成员重新指派其上级角色定义的权限字。下面给出我的相关表定义： TUser(用户或角色表)
===================
(PK)UID int NOT NULL（主键）
Name nvarchar(50) NOT NULL（唯一性约束）
FullName nvarchar(100) NULL
Description nvarchar(255) NULL
MasterNo varchar(25) NULL（注：该字段对应为员工表中的员工编号，通过该字段就可以关联知道该用户或角色所属的员工了，在企业管理系统中很有用啊！） TMember(用户与角色关系表)
=========================
(*PK)RoleID int NOT NULL
(*PK)UserID int NOT NULL TPermission(用户权限表)
=======================
(*PK)FormID int NOT NULL（表示系统中各个模块或表单的唯一编号）
(*PK)UserID int NOT NULL（用户或角色编号）
Protect bit NOT NULL（1：表示显示授予权限；0：表示显示拒绝权限）
Permission int NOT NULL（权限掩码和） ***** 如果哪位兄弟有意研究权限与流程定制方面的东东，相信找偶是没错的了！！！呵呵～～～ 老板，给分啊～～～～～×××××
========================================== 以上的方法与我做的项目的方法基本一致，现摘一部分的表结构，以供大家参考
create table t_workelement /*工作元素表*/
(
code varchar(20) not null, /*元素的代码，唯一*/
name varchar(50) not null UNIQUE,/*元素的名称，唯一*/
type int not null, /*类型 0-单据操作 1-报表操作 2-功能操作*/
bcode varchar(20) null, /*对应操作的单据\报表\功能的代码*/
style int null, /*单据：类型 0-查看 1-新增 2-修改 3-删除*/
/*报表：无*/
/*功能：无*/
term ntext null, /*单据：查看\修改\删除时要符合的条件,如"{$承揽合同.编号}=12\n{$承揽合同.名称}<>'afd'"*/
primary key(code)
)
go
drop table t_role
go
create table t_role /*角色表*/
(
name varchar(30) not null,
category varchar(50) null,
remark varchar(100) null,
primary key(name)
)
go
drop table t_roleelement
go
create table t_roleelement /*角色元素操作表*/
(
rname varchar(30) not null, /*角色名称*/
ecode varchar(20) not null, /*元素的代码*/
primary key(rname,ecode)
)
go
drop table t_users
go
create table t_users /*用户表*/
(
name varchar(20) not null, /*用户的名称*/
dcode varchar(20) not null, /*所属的部门*/
category varchar(50) null, /*用户的类别*/
pswd varchar(15) null, /*密码*/
primary key(name)
)
go
/*插入系统管理员*/
INSERT INTO t_users
(
name,
dcode,
category,
pswd
)
VALUES
(
'Admini',
'system',
'超级用户',
''
)
go
drop table t_userrole
go
create table t_userrole /*用户角色表*/
(
uname varchar(20) not null, /*用户名称*/
rname varchar(30) not null, /*角色的名称*/
primary key(uname,rname)
)
go
INSERT INTO t_userrole
(
uname,
rname
)
VALUES
(
'Admini',
'系统管理员'
)
go
drop table t_dept
go
create table t_dept /*部门表*/
(
code varchar(20) not null, /*部门的代码*/
name varchar(50) not null UNIQUE,/*部门的名称*/
type varchar(10) null, /*部门的类别 行政 仓库 车间*/
subtype varchar(16) null, /*子类别 成品仓库 原料仓库自定义*/
primary key(code)
)
go
/*插入系统管理部*/
INSERT INTO t_dept
(
code,
name,
type
)
VALUES
(
'system',
'系统管理部',
'行政'
)
go
关于权限设计的探讨 原文：http://expert.csdn.net/Expert/topic/1653/1653829.xml?temp=.2015345
作者： zealberg (冰山)
但凡涉及多用户不同权限的网络或者单机程序，都会有权限管理的问题，比较突出的是MIS系统。 下面我要说的是MIS系统权限管理的数据库设计及实现，当然，这些思路也可以推广开来应用，比如说在BBS中用来管理不同级别的用户权限。 权限设计通常包括数据库设计、应用程序接口(API)设计、程序实现三个部分。 这三个部分相互依存，密不可分，要实现完善的权限管理体系，必须考虑到每一个环节可行性与复杂程度甚至执行效率。 我们将权限分类，首先是针对数据存取的权限，通常有录入、浏览、修改、删除四种，其次是功能，它可以包括例如统计等所有非直接数据存取操作，另外，我们还可能对一些关键数据表某些字段的存取进行限制。除此，我想不出还有另外种类的权限类别。 完善的权限设计应该具有充分的可扩展性，也就是说，系统增加了新的其它功能不应该对整个权限管理体系带来较大的变化，要达到这个目的，首先是数据库设计合理，其次是应用程序接口规范。 我们先讨论数据库设计。通常我们使用关系数据库，这里不讨论基于Lotus产品的权限管理。 权限表及相关内容大体可以用六个表来描述，如下：
1 角色（即用户组）表：包括三个字段，ID，角色名，对该角色的描述；
2 用户表：包括三个或以上字段，ID，用户名，对该用户的描述，其它（如地址、电话等信息）；
3 角色-用户对应表：该表记录用户与角色之间的对应关系，一个用户可以隶属于多个角色，一个角色组也可拥有多个用户。包括三个字段，ID，角色ID，用户ID；
4 限制内容列表：该表记录所有需要加以权限区分限制的数据表、功能和字段等内容及其描述，包括三个字段，ID，名称，描述；
5 权限列表：该表记录所有要加以控制的权限，如录入、修改、删除、执行等，也包括三个字段，ID，名称，描述；
6 权限-角色-用户对应表：一般情况下，我们对角色/用户所拥有的权限做如下规定，角色拥有明令允许的权限，其它一律禁止，用户继承所属角色的全部权限，在此范围内的权限除明令禁止外全部允许，范围外权限除明令允许外全部禁止。该表的设计是权限管理的重点，设计的思路也很多，可以说各有千秋，不能生搬硬套说某种方法好。对此，我的看法是就个人情况，找自己觉得合适能解决问题的用。 先说第一种也是最容易理解的方法，设计五个字段：ID，限制内容ID，权限ID，角色/用户类型（布尔型字段，用来描述一条记录记录的是角色权限还是用户权限），角色/用户ID，权限类型（布尔型字段，用来描述一条记录表示允许还是禁止） 好了，有这六个表，根据表六，我们就可以知道某个角色/用户到底拥有/禁止某种权限。 或者说，这么设计已经足够了，我们完全实现了所需要的功能：可以对角色和用户分别进行权限定制，也具有相当的可扩展性，比如说增加了新功能，我们只需要添加一条或者几条记录就可以，同时应用程序接口也无须改动，具有相当的可行性。但是，在程序实现的过程中，我们发现，使用这种方法并不是十分科学，例如浏览某个用户所拥有的权限时，需要对数据库进行多次（甚至是递归）查询，极不方便。于是我们需要想其它的办法。使用过Unix系统的人们都知道，Unix文件系统将对文件的操作权限分为三种：读、写和执行，分别用1、2、4三个代码标识，对用户同时具有读写权限的文件被记录为3，即1+2。我们也可以用类似的办法来解决这个问题。初步的想法是修改权限列表，加入一个字段：标识码，例如，我们可以将录入权限标识为1，浏览权限标识为2，修改权限标识为4，删除权限标识为8，执行权限标识为16，这样，我们通过权限累加的办法就可以轻易的将原本要分为几条记录描述的权限放在一起了，例如，假定某用户ID为1，库存表对应的限制内容ID为2，同时规定角色类型为0、用户类型为1，我们就可以将该用户具有录入、浏览、修改、删除库存表的权限描述为：2,15,1,1。 确实很简单，不是吗？甚至还有更过激的办法，将限制内容列表也加上一列，定义好标识码，这样，我们甚至可以用简单的一条记录描述某个用户具有的对全部内容所具有的全部权限了。当然，这样做的前提是限制内容数量比较小，不然，呵呵，2的n次方递增起来可是数量惊人，不容易解析的。 从表面上看，上述方法足以达到实现功能、简化数据库设计及实现的复杂度这个目的，但这样做有个弊端，我们所涉及的权限列表不是相互独立而是互相依赖的，比如说修改权限，其实是包含浏览权限的，例如，我们可能只是简单的设置用户对库存表存取的权限值为录入+修改+删除（1+4+8=13),但事实上，该用户具有(1+2+4+8=15）的权限，也就是说，在这种方案中，13=15。于是当我们调用API询问某用户是否具有浏览权限时，就必须判断该用户是否具有对该数据表的修改权限，因此，如果不能在程序中固化权限之间的包含关系，就不能利用应用程序接口简单的做出判断。但这与我们的目的“充分的可扩展性”矛盾。 这个问题如何解决？我想到了另外一种设置标识码的方法，那就是利用素数。我们不妨将录入、浏览、修改、删除、执行的基本标志码定为2,3,5,7,11，当遇到权限互相包含的时候，我们将它的标识码设定为两个（或多个）基本标志码的乘积，例如，可以将“修改”功能的标志码定为3*5=15，然后将所有的权限相乘，就得到了我们需要的最终权限标识值。这样，我们在询问用户是否具有某项权限的时候，只需要将最终的值分解成质因子，例如，我们可以定义一个用户具有录入+修改+删除库存表的权限为 2*15*7=2*3*5*7，即表示，该用户具有了对库存表录入+浏览+修改+删除权限。 当然，对权限列表我们使用上述方法的前提是权限列表记录条数不会太多并且关系不是十分复杂，否则，光是解析权限代码就要机器忽悠半宿：） 我希望以上的分析是正确且有效的（事实上，我也用这些的方法在不止一套系统中实现），但无论如何，我觉得如此实现权限管理，只是考虑了数据库设计和应用程序接口两部分内容，对于实现，还是显得很费劲。因此，我恳请有过类似设计、实现经验的同志们提出建设性的意见和修改建议。 另外，关于数据库设计的思路还有使用二维表的，这将在以后的时间里讨论，关于应用程序接口的设计和实现我也将在利用另外篇幅和大家共同探讨，代码将用类C语法实现（我不喜欢pascal，抱歉） 欢迎朋友们和我联系，mailto:berg@91search.com，也欢迎访问我和另外一位朋友共同建设的网站：http://www.91search.com，那里将有一个音乐搜索的工具软件提供下载。
======================================== 关于权限包容关系通过角色和权限掩码来实现。 /// <summary>
/// 权限保护类型枚举类型。
/// </summary>
public enum ProtectEnum
{
/// <summary>撤回权限保护类型</summary>
RevokeProtect = 0,
/// <summary>授予权限保护类型</summary>
GrantProtect = 1,
/// <summary>拒绝权限保护类型</summary>
DenyProtect = 2
} /// <summary>
/// 系统固定用户或角色枚举类型。
/// </summary>
/// <remarks>
/// 管理员角色：16399 = 100000000001111
/// 所有者角色：16385 = 100000000000001
/// 只读者角色：16386 = 100000000000010
/// 安全员角色：16388 = 100000000000100
/// 配置员角色：16392 = 100000000001000
/// </remarks>
public enum FixedRoleEnum
{
///<summary>系统管理员固定用户</summary>
Administrator = 1,
///<summary>系统管理员固定角色</summary>
Administrators = 16399,
///<summary>所有者固定角色（具有读写操作之权限）</summary>
Authors = 16385,
///<summary>只读者固定角色（具有只读操作之权限）</summary>
Readers = 16386,
///<summary>系统安全管理员固定角色</summary>
Security = 16388,
///<summary>系统设置管理员固定角色</summary>
Setting = 16392
} /// <summary>
/// 系统权限枚举类型。
/// </summary>
public enum PermissionEnum
{
/// <summary>“读取”权限</summary>
FetchPermission = 1,
/// <summary>“新增”权限</summary>
AddNewPermission = 2,
/// <summary>“更新”权限</summary>
UpdatePermission = 4,
/// <summary>“删除”权限</summary>
DeletePermission = 8,
/// <summary>“打印”权限</summary>
PrintPermission = 16,
/// <summary>系统保留，应用于流程处理</summary>
FlowPermission = 1024,
/// <summary>系统保留，应用于流程处理</summary>
VoidPermission = 2048
} 如果用户“Popeye”对“销售出仓单[2009]”系统对象具有读写（读取＋修改＋删除＋新增）权限：（权限表定义如下TPermission）
FormID UID Permission
======= ==== ==========
2009 Popeye 1+2+4+8=15 ***** 上面系统定义的默认权限肯定是不够系统使用的，那么还有一些权限（例如：报关系统中的“计算差异表”“制造申报单”等权限，就由系统再定义），其实不用太担心会不够用的，因为在一个Form中不可能会出现所有权限情况，所以，系统自定义的权限掩码可重复使用在不同的表单中。***** 建议不要把角色和用户分开两张表来存储（可参考MS-SQL Server中的sys_users表），因为在后面的权限定义表需要引用这个表的UID（其可为用户或角色，SQL中是使用UID的数值范围来区别用户与角色的，建议也如此。），版主说的角色与用户分开对待权限设置，这点我不赞成。因为角色只不过是一种用户组，其应该享用用户的权限定义范围，在其下属的角色成员（注意角色成员不同于用户或角色哦，其可以为角色也可以为用户）均默认继承其定义的权限，除非角色成员重新指派其上级角色定义的权限字。下面给出我的相关表定义： TUser(用户或角色表)
===================
(PK)UID int NOT NULL（主键）
Name nvarchar(50) NOT NULL（唯一性约束）
FullName nvarchar(100) NULL
Description nvarchar(255) NULL
MasterNo varchar(25) NULL（注：该字段对应为员工表中的员工编号，通过该字段就可以关联知道该用户或角色所属的员工了，在企业管理系统中很有用啊！） TMember(用户与角色关系表)
=========================
(*PK)RoleID int NOT NULL
(*PK)UserID int NOT NULL TPermission(用户权限表)
=======================
(*PK)FormID int NOT NULL（表示系统中各个模块或表单的唯一编号）
(*PK)UserID int NOT NULL（用户或角色编号）
Protect bit NOT NULL（1：表示显示授予权限；0：表示显示拒绝权限）
Permission int NOT NULL（权限掩码和） ***** 如果哪位兄弟有意研究权限与流程定制方面的东东，相信找偶是没错的了！！！呵呵～～～ 老板，给分啊～～～～～×××××
========================================== 以上的方法与我做的项目的方法基本一致，现摘一部分的表结构，以供大家参考
create table t_workelement /*工作元素表*/
(
code varchar(20) not null, /*元素的代码，唯一*/
name varchar(50) not null UNIQUE,/*元素的名称，唯一*/
type int not null, /*类型 0-单据操作 1-报表操作 2-功能操作*/
bcode varchar(20) null, /*对应操作的单据\报表\功能的代码*/
style int null, /*单据：类型 0-查看 1-新增 2-修改 3-删除*/
/*报表：无*/
/*功能：无*/
term ntext null, /*单据：查看\修改\删除时要符合的条件,如"{$承揽合同.编号}=12\n{$承揽合同.名称}<>'afd'"*/
primary key(code)
)
go
drop table t_role
go
create table t_role /*角色表*/
(
name varchar(30) not null,
category varchar(50) null,
remark varchar(100) null,
primary key(name)
)
go
drop table t_roleelement
go
create table t_roleelement /*角色元素操作表*/
(
rname varchar(30) not null, /*角色名称*/
ecode varchar(20) not null, /*元素的代码*/
primary key(rname,ecode)
)
go
drop table t_users
go
create table t_users /*用户表*/
(
name varchar(20) not null, /*用户的名称*/
dcode varchar(20) not null, /*所属的部门*/
category varchar(50) null, /*用户的类别*/
pswd varchar(15) null, /*密码*/
primary key(name)
)
go
/*插入系统管理员*/
INSERT INTO t_users
(
name,
dcode,
category,
pswd
)
VALUES
(
'Admini',
'system',
'超级用户',
''
)
go
drop table t_userrole
go
create table t_userrole /*用户角色表*/
(
uname varchar(20) not null, /*用户名称*/
rname varchar(30) not null, /*角色的名称*/
primary key(uname,rname)
)
go
INSERT INTO t_userrole
(
uname,
rname
)
VALUES
(
'Admini',
'系统管理员'
)
go
drop table t_dept
go
create table t_dept /*部门表*/
(
code varchar(20) not null, /*部门的代码*/
name varchar(50) not null UNIQUE,/*部门的名称*/
type varchar(10) null, /*部门的类别 行政 仓库 车间*/
subtype varchar(16) null, /*子类别 成品仓库 原料仓库自定义*/
primary key(code)
)
go
/*插入系统管理部*/
INSERT INTO t_dept
(
code,
name,
type
)
VALUES
(
'system',
'系统管理部',
'行政'
)
go
----------- 在设计一个灵活的权限管理系统时,不仅要考虑权限分配,还要考虑到权限与界面,功能的挂接,在开发现在一个系统时,基于WEB应用,大家其实可以研究一下Windows的权限管理,我就是这么实现的.
1.用户基本信息表.Users
2.组信息表:Groups
3.组明细表:GroupsDetail
4.用户资源表:UserSource
5.组资源表:GroupSource
6.功能组件列表:Components
用法:
1.组名细表包含组里的用户,如果设计成树型结构则可以形成金字塔型权限管理,目前只实现了二层结构,即组下挂用户(GroupDetail),设计类来实现从组中开用户集合和从用户中列组集合.
2.用户资源表和组资源表,分别记录单个用户能存取的资源明细及组能存取的资源明细,要简化设计,可以只用组资源表,即权限授给组,用户从组中继承权限.在资源表中设属性,可控制资源的存取能力,如(完全控制,改写,只读,不可见等)
3.组件功能列表(Components),设计成树型结构,列出软件里的所有功能,具体用户能存取哪些功能,通过授权放到了资源表里.
4.用户登陆后的权限:用户登录系统,从用户资源表(UserSource)得到用户自已的功能,从(GroupDetail)得到用户所属的组,从(GroupSource)得到这些组的资源,最后形成用户能存取的所有资源.
5.通过这些资源来动态构建用户界面.
------------------------
权限设计分析
设计要求：
通过一次代码设计，无论在整个应用的任何地方或通过何种形式调用此功能，都能被功能权限所限制，要求限制级别到达模块下文档权限。
权限划分主要从权限对象来看，大的方向上的是
系统模块权限：模块的所有管理权
文档权限：浏览、增加，修改、删除
权限管理数据结构设计:
方案一
功能（模块）表：
数据元素——功能编号 (funid)；功能名称(funname)；功能说明（funintro）
角色(分组)表：
数据元素——角色编号（roleid）；角色名称（rolename）；角色说明(roleintro)
角色功能表：
数据元素——角色编号（roleid）；功能编号（funid）
用户信息表：
数据元素——用户编号（userid）；用户名称（username）
用户角色表：
数据元素——用户编号（userid）；角色编号（roleid）
功能（模块）表：主要存储系统用户的操作功能。
角色(分组)表：存储系统使用人员扮演的角色和职位。
角色功能表：某个角色在系统中所具有的系统操作功能。
用户信息表：存储系统使用用户的信息
用户角色表：用户在使用系统时，所扮演的角色。
每个角色对应具体的功能，至少具有基本权限；每个用户至少拥有一个角色；这样很方便管理用户的权限功能。设置一个系统管理员用户，具有所有的权限，授权用户只有系统管理员，可以对用户的进行管理和用户权限的管理，对用户的权限判断，读取用户角色表取得用户的角色数据，通过角色功能表获得用户所扮演的角色所具有的系统功能。
系统由系统管理员进入进行功能的维护（添加、修改、删除），角色的维护（添加、修改、删除），用户的维护（添加、修改、删除），角色权限的维护（添加、修改、删除）、用户角色的维护（添加、修改、删除）。
以上的方案通过对角色的权限设定，确定用户在所扮演角色下所具有的系统功能，在判断用户功能的时候需要对数据库多次进行操作，查询出用户所有对应的权限。
