二、功能设计
有了需求分析之后，我们就可以进行功能设计了，我们可以看看一般的权限管理和EOM权限管理的相同之处和不同之处。在大的功能方面两者没有什么不同，但是在功能适用范围和细节上那就有不同之处了。
1、 一般的权限管理
一般的权限管理大同小异，主要有权限设置、权限比对、参数设置三大功能。权限设置相变化比较多一些，例如，有角色的或无角色的，用户名直接输入的或通过单位部门进行选择的等等。单一系统的权限管理和多系统的权限管理之间的差别在于后者增加了系统代码。由于增加了系统代码，所以在权限设置中就有了系统代码的选项，权限比对中就有了系统代码的入口参数，参数设置中就有了系统代码的创建和维护。
而且这些功能因程序员而异，可以说十个系统的权限管理就有十个不同的功能，其功能细节上各不相同，但是大的功能方面还是一样的。
2、 EOM的权限管理
主要是由于其定位于通用程序，无论是十个系统还是1000个系统，均是采用相同的权限管理系统或模块，具有相同的功能。EOM当然具有一般权限管理的功能，但是EOM站在企业经营管理大局之上，更注重权限管理的参数化管理、企业内部系统关系管理，以及企业与企业之间或企业内部和外部之间的用户权限的管理，以适应各种权限管理的要求。
1） 权限设置
1.用户功能权限设置
建立用户与系统功能代码之间的关系，注意，此间增加了系统代码，体现了可实现多系统权限管理的功能。
2.用户操作权限设置
建立用户与系操作代码之间的关系，注意，此间增加了系统代码、功能代码，体现了多系统的功能。
3.用户角色设置
建立用户与角色之间的关系。
4．角色的创建
建立角色和功能之间、角色和操作之间的对应关系。
2） 权限比对
1．权限比对相比一般权限比对，增加了、操作代码、系统代码、企业代码等入口参数，使得权限比对的范围最大化，并更具有灵活性。
例如，当比对类型参数为1时，必对只比用户名和功能代码，当参数为2时，则比对系统代码、用户名和功能代码。当参数为3时，就要比对企业代码、系统代码、用户名、功能代码了。
2．另外，当出现特殊权限需求的时候，权限比对则可以通过特殊权限类型，来确定以何种方式调用权限管理的接口程序。
例如，有一种特殊的权限要求，如果用户年龄大于50岁，则不可以进行某项查询操作。象用户年龄大于50的权限条件是非常特殊权限要求。EOM不可能满足，但是它可以提供各种接口程序来满足这些要求。
假定检查用户年龄大于50岁的函数是以Webservice方式。则权限比对首先会去查找接口表，看本操作是否存在特殊权限，如果有则查看其处理方式，当发现是WebService方式后，就会去WebSercie名字去调用这个函数。
3） 参数设置
1． 功能代码的创建和维护
2． 操作代码的创建和维护
3． 系统代码的创建和维护
4． 特殊权限定义的创建和维护
5． 权限参数维护
4） 外部用户权限管理
当企业有外部用户访问的时候，必须建立外部用户权限管理。
1． 外部用户的角色管理
2． 外部企业代码创建和维护
5)日志管理
所有重要的用户访问，包括允许或不允许的访问和操作都要进行日志记录，以便对用户进行操作监管。
EOM不但能满足各种权限管理的需求，而且其通过EOM权限管理来规范各种应用系统的与权限相关的功能，解决了现有权限管理功能的无序的设计，实现了标准权限管理功能的共享。
三、 数据库设计
在有了权限管理的定位和功能设计之后，最重要的建立满足功能的数据库设计，这个设计不但要反映了权限管理定位、功能的要求，更重要的是反映了权限管理的各种要素的抽象，以及要素之间的关系。在数据库设计方面一般的权限管理和EOM权限管理的存在较大的差异。
1、 一般的权限管理
其数据库设计其相对比较简单，根据现实中的系统功能权限状况来设计功能表、用户功能表、角色表、角色功能表等，它与权限管理和实际系统相关比较直接，比如，功能代码，如果这个系统只有3个功能，其代码可能就会用一个字符，也就是说，这个数据库设计是为了这个系统的权限管理而设计的。
2、 EOM权限管理
EOM的数据库设计则是站在整个企业信息化高度角度上来建立企业信息化体系的，所有的信息设计都要考虑到企业信息化所有系统的共享和标准化，并且根据EOM的七大要素采用的是抽象的方式，对所有信息进行合理的分类，使得所有信息在整个企业信息化的大框架下形成有机的一体。因此，EOM权限管理并不从具体的系统，具体的功能上进行数据库设计，而是在抽象权限管理的要素基础上，标准化权限管理的各种信息，并且尽可能地利用其他的公共信息。
权限管理的主要信息有：
1)用户信息
2)功能信息
3)操作信息
4)角色信息
5)用户和功能关系信息
6)角色和功能关系信息
7)用户和操作关系信息
8） 角色和操作关系信息
9） 应用系统信息
10） 外部用户信息
11） 外部角色信息
12） 外部用户角色关系信息
13） 外部企业信息
14） 特殊权限定义信息
15） 权限管理标准函数信息
与权限管理相关联的信息：
1） 部门信息
2） 员工职位信息
这些信息对员工的权限影响很大，例如，员工只能看本部门的数据，一般员工看不见企业的利润和奖金发放情况等，管理者可以看到普通员工看不到的报表等。
我想指出的这里的各种信息都是建立在抽象要素基础上的，与实际内容没有关系，但是能满足各种实际的各种要求，而且每个信息的设计都要有来自EOM理论的支持。
3、两者设计比较
以功能信息设计为例进行比较。
1） 一般权限管理
在功能设计上会根据这个系统有多少个功能来设计，例如，这个系统最多有30项功能（主菜单和子菜单），那他会这样设计功能信息表。
1． 功能代码 char（2） ；代码方式表示功能，最多可以定义100个功能（假定代码是数字方式,同下）
2． 功能名称 char(50) ；说明功能名称
3． 功能界面程序名 char（100） ；用于调用这个功能程序
4． 功能标志 char（1） ；此功能是否有效
这个功能表的确能满足这个系统的权限管理的要求。
但是这个功能表
1． 并不能满足任意的、所有的应用系统的要求。例如，如果一个应用系统有150个功能，则功能代码定义的长度就不够了。
2． 不能反映多系统的要求，只能是单一系统。
3． 只考虑的功能的个数，没有考虑到功能的层级关系，一般来说一个系统的功能是分层级的（有主菜单和子菜单），用户往往不会是一个或零散的功能，而是具有一类或多类的功能，因此，功能表设计的时候，要考虑功能的分类，以及分类后的各种功能的具体实现。
4． 有的程序员在设计功能代码时会采用数据位方式来体现功能的层级关系。
例如：系统共有五个主菜单，第一个主菜单下有3个子菜单。假定功能层级为2。他可能会定义 10 为第一个主菜单，20为第二个主菜单，30，40，50为第3，4，5主菜单。11，12，13为第一个主菜单下面的3个子菜单。
这种靠数据位来区分功能分类的方式比较原始（来自于汇编中的位操作），并不能适应功能分类的灵活变化。例如，原来12，功能将要放在第2个主菜单下面，这种情况处理起来就比较麻烦了。
2） EOM权限管理
在设计功能表时将会考虑
1． 任意应用系统中最大的功能个数
2． 反应系统与功能之间的关系，就是说功能表中要有系统代码的字段
3． 功能之间的分类以及关系
4． 功能的调整
5． 仅考虑与功能有关的信息，不考虑功能相关的信息，相关信息可以放在另外一张表中
6． 功能信息和其他信息的一致性。例如，操作信息、角色信息、部门信息等。
7． 其他因素
附1：系统功能表设计说明
|
系统功能表 |
|||||
|
Sysfunction |
|||||
|
序号 |
名称 |
字段名 |
说明 |
类型 |
备注 |
|
1 |
应用系统 |
appsys |
应用系统 |
Char(3) |
|
|
2 |
系统功能编码 |
Id |
系统功能编码 |
Char(9) |
|
|
3 |
系统功能编码1 |
Code1 |
系统功能编码1 |
Char(3) |
系统功能大类或第一层次 |
|
4 |
系统功能编码1名称 |
Name1 |
系统功能编码1名称 |
Char(50) |
|
|
5 |
系统功能编码2 |
Code2 |
系统功能编码2 |
Char(3) |
系统功能中类或第二层次 |
|
6 |
系统功能编码2名称 |
Name2 |
系统功能编码2名称 |
Char(50) |
|
|
7 |
系统功能编码3 |
Code3 |
系统功能编码3 |
Char(3) |
系统功能小类或第三层次 |
|
8 |
系统功能编码3名称 |
Name3 |
系统功能编码3名称 |
Char(50) |
|
|
9 |
系统功能名称 |
Name |
系统功能名称 |
Char(80) |
系统功能名称,总称或简称 |
|
10 |
上级系统功能编码 |
Up_code1 |
上级系统功能编码 |
Char(9) |
当为大类时 |
|
11 |
上上级系统功能编码 |
Up_code2 |
上上级系统功能编码 |
Char(9) |
当为中类时 |
|
12 |
编码等级 |
Codelevel |
编码等级 |
Char(1) |
用于说明编码等级0 最高层 1 1层 2 2层 3 3层 |
|
13 |
标志 |
Flag |
有效标志 |
Char(1) |
有效标志 EX:N 无效 缺省空值 有效 |
|
14 |
备注 |
Remark |
备注 |
Char(50) |
|
附2：NRP系统功能的实例，901表示NRP
