- 一般情况下，企业内的公文转发、审批是按部门或职位来转送，即对岗不对人。例如：某个流程的某个环节需要财务总监审批，日后财务总监换人，该流程应该不受影响。而且，流程中某个环节可能出现某个部门中的任何一人都能审批，或者需要该部门的所有人员共同审批。
流程中转送，审批的公文一般分为文件和表单2种格式。文件格式的公文应该支持批处理，即一次可以转发多个文件，审批时可以只退回其中某一个不合格的文件，其他的文件可以转送到下一个环节继续处理。表单格式的公文应该能让用户自己定义表单格式，确定表单中的表项。同理，表单也应该支持批处理。
流程中处理公文的动作应该能让用户自己定义。这样一旦日后增加了新的处理动作，也不用修改MIS系统的底层数据建模。当然，要实现新的处理动作，还是需要在业务逻辑层编写相应的代码，不过和修改底层数据建模比起来，工作量要少得多。
每个流程的环节数不一定相同，应该能让用户设定环节数，指定公文流转中每个环节的发送部门和接受部门，处理模式，最长等待时间。
当待处理的公文发出后，系统应该在等待时间中定期向该流程中下个环节的用户(们)发出通知，提醒该用户(们)及时处理，直至公文已被处理。如果超出最长等待时间，公文还未被用户(们)处理，此次流程处理失败。企业管理层可能会要求记录相关信息，以便在日后业务流程重组(BPR)时参考。
某些企业由于特殊原因，在某个流程中要求实现跨环节处理。例如，该流程有6步，执行到第二个环节时要求处理后可以跳过中间三个环节，直接转到最后一个环节等候处理。其实，这种情况下，并不一定要在技术层面上实现其灵活性，这种特例毕竟是少数。用户只需定义一个新流程，把上面流程的第1，2，6步复制加入进来，2个流程之间用流程名来区分即可。一个优秀的系统架构设计师应该充分利用现有的工具，不要什么都自行架设开发。
分析：
1）由于流程每个节点环节的发送方和接受方是对岗不对人，应该考虑到整个企业的机构设置，确定每个部门的权利职责。每个大部门内可能有若干子部门，每个子部门内又有不同的职位，负责处理相应的事务。
* 部门的设置是根据每个部门相关人员的岗位来划分设置的。
* 用户组设置具体的岗位权限。
* 一个具体部门可能会拥有几个用户组所在岗位权限。
数据模型如下：
几点说明：
图中，也许有人会提出用户组部门表与用户组功能表应该合并成一张表。我的考虑是设置用户组部门表时不需要去考虑具体的明细功能，同样设置用户组功能表时也不需要去考虑属于哪个部门。因为一个用户组功能可以只属于一个部门也有可能属于几个部门，换句话说一个部门可以拥有一个用户组中的权限，也可以拥有多个用户组中的权限。
2）审批的公文一般分为文件和表单2种格式，应该把公文抽象化。把２种格式的公文的共有属性提取出来建立一张公文表。
a.文件格式的
公文表(Document_table)
名称 类型 约束条件 说明
doc_id int 无重复 公文标识，主键
doc_name varchar(50) 不允许为空 公文名称
doc_type char(1) 不允许为空 公文类型
doc_type字段用来辨别公文格式，目前只有2种格式，可设“1”表示文件格式，“2”表示表单格式。估计未来新增公文格式不会太多，所以该字段只需一位字符。文件格式的公文一般是在文件内固定好格式，我们可用一个二进制的字段直接保存整个文件的内容。文件格式的公文需要建一个表来保存相关信息，其大致数据表如下：
文件表(File_table)
名称 类型 约束条件 说明
file_id int 无重复 文件标识，主键
file_name varchar(50) 不允许为空 文件名称
file_value binary 不允许为空 文件内容
……
b.表单格式的公文要让用户自己定义表单格式，确定表单中的表项。有两种方法来实现：
①每当用户建立一个新格式的表单时，就新建立一个表，把用户输入的表单表项当作该表的字段。这种方式的优点是表单查询速度较快方便，业务逻辑层的开发量较小。缺点是不太灵活，如果企业所使用的不同格式的表单较多(>20种)，整个数据库的结构显得比较混乱，而且大部分表单中都有相同的字段，这样也增加了数据冗余。
这种方式的数据建模如下：
表单总表(Sheet_table)
名称 类型 约束条件 说明
sheet_id int 无重复 表单标识，主键
sheet_name varchar(50) 不允许为空 表单名称
table_name varchar(20) 不允许为空 表单子表名，如Sub_table1/Sub_table2
表单子表1(Sub_table1)
名称 类型 约束条件 说明
sub_id int 无重复 表单子表标识，主键
option1 varchar 不允许为空 表单表项1
option2 varchar 不允许为空 表单表项2
option3 varchar 不允许为空 表单表项3
……
表单子表2(Sub_table2)
名称 类型 约束条件 说明
sub_id int 无重复 表单子表标识，主键
option1 varchar 不允许为空 表单表项1
option2 varchar 不允许为空 表单表项2
option3 varchar 不允许为空 表单表项3
……
……
②对表单再进行一个抽象，把表单看成由若干个表单表项所组合成的一个集合。这种方式的优点是相当灵活，用户建立新格式的表单时只用从已有表单表项中勾选出需要的表项即可，而且整个数据库结构清晰，没有数据冗余。缺点是开发比较复杂，工作量和上面相比高出不少，而且表单查询速度较慢。下面是这种方式的数据建模：
表单总表(Sheet_table)
名称 类型 约束条件 说明
sheet_id int 无重复 表单标识，主键
sheet_name varchar(50) 不允许为空 表单名称
表单表项表(Option_table)
名称 类型 约束条件 说明
op_id int 无重复 表单表项标识，主键
op_name varchar(50) 不允许为空 表单表项名称
op_length int 不允许为空 表单表项长度
op_unit varchar(10) 允许为空 表单表项单位
表单信息表(Sheetinfo_table)
名称 类型 约束条件 说明
info_id int 无重复 表单信息标识，主键
sheet_id int 不允许为空 所属表单标识，和Sheet_table.sheet_id关联
op_id int 不允许为空 表单表项标识，和Option_table.op_id关联
info_value varchar() 不允许为空 表单信息值
对于以上的这两种情况，我个人认为应该采用第二种较为合适。
继续中....
