公文转发流程自定义的数据建模

核心提示： 5)当待处理的公文发出后，系统应该在等待时间中定期向该流程中下个环节的用户(们)发出通知，公文转发流程自定义的数据建模(2)，提醒该用户(们)及时处理，直至公文已被处理，然后，采用权限表和用户组相结合的方式来保存每个部门每个职位的职能，如果超出最长等待时间，公文还未被用户(们)处理

5)当待处理的公文发出后，系统应该在等待时间中定期向该流程中下个环节的用户(们)发出通知，提醒该用户(们)及时处理，直至公文已被处理。如果超出最长等待时间，公文还未被用户(们)处理，此次流程处理失败。企业管理层可能会要求记录相关信息，以便在日后业务流程重组(BPR)时参考。

6)某些企业由于特殊原因，在某个流程中要求实现跨环节处理。例如，该流程有6步，执行到第二个环节时要求处理后可以跳过中间三个环节，直接转到最后一个环节等候处理。其实，这种情况下，并不一定要在技术层面上实现其灵活性，这种特例毕竟是少数。用户只需定义一个新流程，把上面流程的第1，2，6步复制加入进来，2个流程之间用流程名来区分即可。一个优秀的系统架构设计师应该充分利用现有的工具，不要什么都自行架设开发。

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

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

部门表(Department_table)

名称　　　　类型　　　　约束条件　　　　　　　　　　　　　说明