需求陈述
不同职责的人员，对于系统 *** 作的权限应该是不同的。优秀的业务系统，这是最基本的功能。
可以对“组”进行权限分配。对于一个大企业的业务系统来说，如果要求管理员为其下员工逐一分配系统 *** 作权限的话，是件耗时且不够方便的事情。所以，系统中就提出了对“组”进行 *** 作的概念，将权限一致的人员编入同一组，然后对该组进行权限分配。
权限管理系统应该是可扩展的。它应该可以加入到任何带有权限管理功能的系统中。就像是组件一样的可以被不断的重用，而不是每开发一套管理系统，就要针对权限管理部分进行重新开发。
满足业务系统中的功能权限。传统业务系统中，存在着两种权限管理，其一是功能权限的管理，而另外一种则是资源权限的管理，在不同系统之间，功能权限是可以重用的，而资源权限则不能。
关于设计
借助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表记录着所有管理员的信息，每添加一个管理员，该表就会增加一条记录。
可以新建一张表 用户权限表
这张表用来存用户权限。
他里面放 用户权限编号做主键，用户编号和权限编号是外键。
查询用户有那些权限的时候，只需要，
select 权限编号 From 用户权限表 where 用户编号='用户编号'
存的时候，就要把用户所有的权限信息，存进去。
Insert INTO 用户权限表(用户编号,权限编号) values('用户编号','权限编号')
设计如图所示的。
系统的主要特点有：1）统一建库、统一管理
整个系统将单位信息、人员信息统一建库，统一进行管理。即采用中心数据库（如图1）管理信息。只有一级主管单位的相关业务负责人员才有权修改中心库中相关业务的数据。其他人员只能根据各自的 *** 作权限，查询和下载相关数据。
图1 中心数据库结构图
2）按照业务职能分层管理
人力资源信息系统是按照业务职能分层管理，这其中包含两层意思。一是按照业务职能管理，二是分层管理。按照业务职能管理指的是：由主管职能部门负责本单位所有人力资源的计划与编制工作，由各级职能处室负责相关业务。与此相对应，软件也要按照业务职能划分子系统。分层管理指的是基层单位的数据上报其主管单位，由主管单位汇总上报到上一级主管单位，依次类推，最后由顶级的主管单位修改和更新中心库，基层单位的有关人力资源计划、编制方面的数据由其主管单位收发、审批，并一级级上报，而不是将数据直接送达到顶级主管单位。
此解决方案适合于要求对单位及人员信息高度统一管理的系统。由于一切信息以中心数据库中的信息为基准，因此不会出现使用数据和上报数据不一致的情况。数据结构由主管单位各职能处制定，一级级下发到基层单位，以保持统一的数据格式。用户在保持数据结构与上级单位要求相一致的同时，也可以根据自己的需要自设数据项。
3）采用三层结构
本系统采用C／S三层结构，后台数据库采用SQL Server 7．0，开发工具采用VB6．0及VC6．0，并利用ADO实现系统数据调用。系统以模块组合为基础，既强化了对系统整体的管理，又兼顾了单项应用的功能。
4）权限管理模块
权限管理模块中包含电子印模管理和用户权限管理。
电子印模管理主要是在文件等的审批时，加上审批人的电子印模，实现责任管理。电子印模专门建库，每一条记录的读写都有口令设置，读写口令不一样，一般只有本人才有读写自己电子印模的权利。
用户权限管理按照优先顺序分成以下级别：
A． *** 作权限。设置子系统权限，即是否有进入编制管理、职称管理、工资管理、离退休管理、培训管理、领导查询、办公自动化、指标体系和用户管理子系统的权限。
B．数据权限。为用户指定访问单位、部门的权限。通过数据权限的设置，各单位只能在中心数据库中浏览本单位的数据，而不能浏览其他单位的数据。
C．表／字段权限。为用户设定读、写、增、删数据表／字段的权限。
人事信息管理系统应用经验
济南市人事局采用金益康人事信息网，实现了济南市人事管理工作的信息化，通过Intranet／Internet进行网上办公，彻底摆脱了原有的手工录入、手工查询、手工制表、手工统计等繁重的劳动。本系统通过建立中心数据库，录入了济南市26万余个职工的基础信息，并预先设置了人事工作中用到的所有表格，还规范了待业人员管理标准，明确了基础数据的来源，并对工作程序进行了优化。
信息采集是济南市人事管理工作中一项重要内容。过去没有解决信息共享问题，在对重要人事信息进行整理、编辑和录入时，既出现重复劳动，又不能保证录入信息的准确，这往往会白白耗费单位大量的人力、物力和财力。本系统采用模块组合方式，各模块间的信息高度共享，实现录入、修改与审批等功能的统一，在各相关数据间做到了数据的连动。这种模块结构为人事部门查询、检索、读取信息提供了极大的便利。而且本系统在输入模块中还提供了默认的模板结构，提高了信息录入的效率。
人事信息网建设使济南市人事局从事务管理转变为职能管理，在职能管理过程中全面应用了信息技术。上级人事局将数据下发给主管局，主管局接收上级数据，并根据自身的实际情况在指标体系中，添加自己的指标集和指标次参数，设定数据结构，将数据结构下发给基层单位。基层单位得到主管局的数据结构，只需按自身需求添加部分指标即可。这种数据发收的形式，保证了结构的唯一性，减少了工作环节，缩短了整个工作流程，更易于方案的落实。
办公自动化系统的应用
济南市人事信息综合管理网络另一特色是将政府的办公系统与日常人事管理工作进行紧密结合。应用网络提高了人事工作的透明度，降低了办公费用，提高了办事效率，有利于勤政和廉政建设，同时大幅度提高人事管理工作的信息化水平。
此办公自动化系统共由六大功能子系统组成：公文管理、文秘档案管理、综合办公、公共信息、个人事务和系统管理。在公文管理方面，本系统以工作流的方式基本实现公文的收文、发文及其他管理工作，并根据人事工作的特性，规范公文类型和表单样式，提供了自定义表单功能，提高了系统的灵活性。
为方便用户，系统对处于流转过程中的公文进行全面的跟踪监控。系统采用严密的安全机制，仿照公文实际处理情况，可接触公文的人员范围随着公文不断流转而动态变化。
办公自动系统与人事信息管理系统间形成无缝结合，是人事管理信息化的一大突破。人事信息管理系统可与办公自动化系统进行自由切换，优化了工作流程。
图2 程序网络图
------------------------------------------------------------------------
精彩点评
金益康人事信息综合管理网络整体解决方案应用信息技术进行人事工作管理与规划。方案由两大系统组成：一是人事信息管理系统，以目前中国人事管理的现状为基础，强调人事管理工作的通用性，兼顾专用性，预留二次开发空间；二是金益康办公自动化系统，协助人事部门内部实现办公工作自动化，通过此系统衔接人事部门与其它部门的业务，利用互联网模块，获得与人事管理机关相关的全方位综合信息。两大系统无缝结束，在信息技术方面，两大系统信息共享，数据自由转换，系统间自由切换；最重要的是在人事管理业务方面，将人事管理工作融入到日常管理中，减少人事工作独立办公现象，并通过办公自动化系统及时发布人事管理的信息政策等，增进人事管理工作的时效性、透明性。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）