开发比较复杂的企业多用户管理信息系统(MIS)，不可能不涉及到系统内多个用户之间的数据文件的流转、审批等功用的开发。由于企业的需求总是随着时间推移不断发生变化，加之各个企业内部所设置的办公流程不尽相反，一套通用性比较好的管理信息系统应该能让系统管理员本人定义公文转发的流程。

　　虽然笔者没无机会在已参与开发了的MIS中实现出文件转发流程自定义的功用，但是，早在2002年初就曾深入思考过这方面的设计。当时由于某些缘由不能地下本人的设计思路，如今市面上曾经有不少MIS产品提供这样的功用，笔者又已离职，所以是时候把我的设计思路整理出来，和大家分享。

　　首先，让我们分析需求，制定目标。

　　1)普通情况下，企业内的公文转发、审批是按部门或职位来转送，即对岗不对人。例如：某个流程的某个环节需求财务总监审批，日后财务总监换人，该流程应该不受影响。而且，流程中某个环节可能出现某个部门中的任何一人都能审批，或者需求该部门的所有人员共同审批。
　　2)流程中转送，审批的公文普通分为文件和表单2种格式。文件格式的公文应该支持批处理，即一次可以转发多个文件，审批时可以只退回其中某一个不合格的文件，其他的文件可以转送到下一个环节继续处理。表单格式的公文应该能让用户本人定义表单格式，确定表单中的表项。同理，表单也应该支持批处理。
　　3)流程中处理公文的动作应该能让用户本人定义。这样一旦日后添加了新的处理动作，也不用修正MIS系统的底层数据建模。当然，要实现新的处理动作，还是需求在业务逻辑层编写相应的代码，不过和修正底层数据建模比起来，任务量要少得多。
　　4)每个流程的环节数不一定相反，应该能让用户设定环节数，指定公文流转中每个环节的发送部门和接受部门，处理模式，最长等待时间。
　　5)当待处理的公文发出后，系统应该在等待时间中定期向该流程中下个环节的用户(们)发出通知，提示该用户(们)及时处理，直至公文已被处理。如果超出最长等待时间，公文还未被用户(们)处理，此次流程处理失败。企业管理层可能会要求记录相关信息，以便在日后业务流程重组(BPR)时参考。
　　6)某些企业由于特殊缘由，在某个流程中要求实现跨环节处理。例如，该流程有6步，执行到第二个环节时要求处理后可以跳过两头三个环节，直接转到最后一个环节等候处理。其实，这种情况下，并不一定要在技术层面上实现其灵活性，这种特例毕竟是少数。用户只需定义一个新流程，把上面流程的第1，2，6步复制加入进来，2个流程之间用流程名来区分即可。一个优秀的系统架构设计师应该充分利用现有的工具，不要什么都自行架设开发。

　　上面的需求对灵活性要求较高，笼统化程度较深，所以在表现层和业务逻辑层的开发量较大，初期投资较多，不过开发完毕后估量不需对底层数据库修正，即可满足日后不断变化的公文流转需求。如果不需求这么高的灵活性，可以按实际项目简化某些假设条件。下面按照上面的需求进行用例(use case)分析和数据建模。

　　1)由于流程环节的发送方和接受方是对岗不对人，我们应该先描画出整个企业的机构设置，确定每个部门的权利职责。其中大的部门内可能有若干子部门，每个子部门内又有不同职位，担任处理相应的事务。所以，可先建立一个树形关系的数据表来保存企业结构，然后，采用权限表和用户组相结合的方式来保存每个部门每个职位的职能。这块的设计思路见我之前发布的“浅谈数据库设计技巧(上)、(下)”，我在下面直接给出大致的数据表结构：

部门表(Department_table)
名称　　　　类型　　　　约束条件　　　                    说明
Dp_id   　  int     　  无反复　　                   类别标识，主键
Dp_name　　 varchar(50) 不允许为空                   类型名称，不允许反复
Dp_father   int         不允许为空                   该类别的父类别标识，如果是顶节点的话设定为某个独一值
Dp_layer    varchar(6)  限定3层,初始值为000000       类别的先序遍历，次要为减少检索数据库的次数

功用表(Function_table)
名称　　　　类型　　　　约束条件　　　说明
f_id        int    　   无反复　　   功用标识，主键
f_name      varchar(20) 不允许为空   功用名称，不允许反复
f_desc      varchar(50) 允许为空     功用描述

用户组表(User_group)
名称　　　　类型　　　　 约束条件　　　说明
group_id    int          无反复        用户组标识，主键
group_name  varchar(20)  不允许为空    用户组名称
group_power varchar(100) 不允许为空    用户组权限表，内容为功用表f_id的集合

用户表(User_table)
名称　　　　类型　　　　约束条件　　　说明
user_id     int         无反复        用户标识，主键
user_name   varchar(20) 无反复        用户名
user_pwd    varchar(20) 不允许为空    用户密码
user_type   int         不允许为空    所属用户组标识，和User_group.group_id关联

　　说明：其中，按部门的不同职位设置不同权限的用户组，如某个用户组为“市场部业务员”，该用户组的用户可在流程“报销申请”中发送报销申请。

　　2)虽然流程中的公文分为文件和表单2种格式，但是每个文件/表单都应该有其独一标识，名称等属性。所以，我们把公文笼统化，把这2种格式的公文的共有属性提取出来建立一张公文表。

公文表(Document_table)
名称　　　　类型　　　　约束条件　　　说明
doc_id      int         无反复        公文标识，主键
doc_name    varchar(50) 不允许为空