表单子表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() 不允许为空 表单信息值
3)我们可以把公文转发的流程抽象化，看作一个实体超类。建表如下：
流程表(Flow_table)
名称 类型 约束条件 说明
flow_id int 无重复 流程标识，主键
flow_name varchar(50) 不允许为空 流程名称
flow_stepnum int 不允许为空 流程步数
flow_desc varchar(200) 允许为空 流程描述
流程中的每一步都可以抽象化成从发送方至接受方的用例，其数据建模大致如下：
处理动作表(Action_table)
名称 类型 约束条件 说明
a_id int 无重复 动作标识，主键
a_name varchar(20) 不允许为空 动作名称
a_call varchar(50) 不允许为空 动作所调用的模块
a_desc varchar(200) 允许为空 动作描述
说明：如果采用面向过程的开发方式，如纯脚本语言，可以把每一个处理动作写成一个函数，调用a_call字段记录的函数，即可完成相应处理动作。如果采用面向对象的开发方式，可以用COM组件来封装处理动作，则a_call用来记录相应的COM组件的接口方法。如果是在.NET Framework环境下，可以采用Web服务的方式。当然，发送方、接受方以及公文标识是作为输入参数的。
流程环节表(Step_table)
名称 类型 约束条件 说明
step_id int 无重复 环节标识，主键
belong int 不允许为空 所属流程标识，和Flow_table.flow_id关联
setp_order int 不允许为空 所属流程的步骤次序
sender int 不允许为空 发送方标识，和User_group.group_id关联
receiver int 不允许为空 接受方标识，和User_group.group_id关联
a_id int 不允许为空 处理动作标识，和Action_table.a_id关联
a_type int 不允许为空 接受方所需的处理人数
max_wait int 不允许为空 最长等待时间
wait_unit varchar(5) 不允许为空 等待时间的单位
说明：a_type用来确定接受方所需的处理人数，“0”表示需同职位的所有人一起处理，“1”表示只需该职位的任意一名员工处理，“2”表示需该职位的任意两名员工一起处理，依次递推……一起处理的方式和处理动作有关，例如是投票方式，少数服从多数，还是某人有一票否决权等等。可能针对某些处理动作还得细化，进行相关的数据建模，这里我就不细分下去了。
4)下面分析公文转发的流程环节记录。此时相当于实例化一个流程环节的对象，发送方和接受方应具体联系到管理信息系统的某个(些)用户，而不是某个用户组。每经过一环节，我们除了要保存这方面的信息，还必须保存该环节所转发的公文，以及处理状况等信息。而且，该环节所转发公文数量大于等于一，所以可以参考我之前发布的“浅谈数据库设计技巧(下)”中的“简洁的批量m:n设计”，建表大致如下：
流程环节记录表(Step_log)
名称 类型 约束条件 说明
log_id int 无重复 环节记录标识，主键
step_id int 不允许为空 环节标识，和Step_table.step_id关联
sender varchar(100) 不允许为空 发送用户标识，相关用户组的User_table.user_id的集合
receiver varchar(100) 不允许为空 接受用户标识，相关用户组的User_table.user_id的集合
doc_id int 不允许为空 转发公文标识，和Document_table.doc_id关联
batch_no int 不允许为空 批量转发公文编号，同一流程环节转发的batch_no相同
state char(1) 不允许为空 处理状态
sub_date datetime 不允许为空 提交时间
res_date datetime 允许为空 处理回复时间
comment varchar(255) 允许为空 处理回复注释
说明：
①同一流程环节转发的batch_no和该批第一条入库的log_id相同。举例：假设当前最大log_id是64，接着某用户一次转发了3件公文，则批量插入的3条流程环节记录的batch_no都是65。之后另外一个用户通过某个流程环节转发了一件公文，再插入流程环节记录的batch_id是68。
②state字段用来描述其流程环节所处的状态，是正待处理，已被处理通过，已被处理驳回，还是超出最长等待时间被系统自动收回等等。通过这个字段我们对接受用户发出处理通知，还可以可以很容易的查询出所有超出最长等待时间被系统自动收回的流程，以便企业管理层在日后业务流程重组(BPR)时参考。
③如果某份公文在某个流程中的某个环节被处理驳回，可以看作该公文在此次流程中被驳回至起始点，最初发送用户可根据处理回复注释修改公文后重新发送。
总结：
企业公文流程自定义应该是把企业内已经固定了的公文转发、审批流程电子化，实现高效的无纸化办公，对于非正式的口头讨论、商议、集会等商务活动并不适合。当企业累积了一定数量的电子化公文转发的记录后，可以在商业咨询专家和技术开发人员的协助下对其进行数据挖掘，分析出其中的低效、无用环节，进行优化重组，最终提高整个企业的竞争力。作为技术开发人员，我们应该根据企业实际运作情况、资金投入规模，选择当前时期最适合的技术解决方案，切不可为了展示自己的技术实力，而把开发复杂化，企业开发并不是追求技术最先进，而且最适合。
名称 类型 约束条件 说明
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() 不允许为空 表单信息值
3)我们可以把公文转发的流程抽象化，看作一个实体超类。建表如下：
流程表(Flow_table)
名称 类型 约束条件 说明
flow_id int 无重复 流程标识，主键
flow_name varchar(50) 不允许为空 流程名称
flow_stepnum int 不允许为空 流程步数
flow_desc varchar(200) 允许为空 流程描述
流程中的每一步都可以抽象化成从发送方至接受方的用例，其数据建模大致如下：
处理动作表(Action_table)
名称 类型 约束条件 说明
a_id int 无重复 动作标识，主键
a_name varchar(20) 不允许为空 动作名称
a_call varchar(50) 不允许为空 动作所调用的模块
a_desc varchar(200) 允许为空 动作描述
说明：如果采用面向过程的开发方式，如纯脚本语言，可以把每一个处理动作写成一个函数，调用a_call字段记录的函数，即可完成相应处理动作。如果采用面向对象的开发方式，可以用COM组件来封装处理动作，则a_call用来记录相应的COM组件的接口方法。如果是在.NET Framework环境下，可以采用Web服务的方式。当然，发送方、接受方以及公文标识是作为输入参数的。
流程环节表(Step_table)
名称 类型 约束条件 说明
step_id int 无重复 环节标识，主键
belong int 不允许为空 所属流程标识，和Flow_table.flow_id关联
setp_order int 不允许为空 所属流程的步骤次序
sender int 不允许为空 发送方标识，和User_group.group_id关联
receiver int 不允许为空 接受方标识，和User_group.group_id关联
a_id int 不允许为空 处理动作标识，和Action_table.a_id关联
a_type int 不允许为空 接受方所需的处理人数
max_wait int 不允许为空 最长等待时间
wait_unit varchar(5) 不允许为空 等待时间的单位
说明：a_type用来确定接受方所需的处理人数，“0”表示需同职位的所有人一起处理，“1”表示只需该职位的任意一名员工处理，“2”表示需该职位的任意两名员工一起处理，依次递推……一起处理的方式和处理动作有关，例如是投票方式，少数服从多数，还是某人有一票否决权等等。可能针对某些处理动作还得细化，进行相关的数据建模，这里我就不细分下去了。
4)下面分析公文转发的流程环节记录。此时相当于实例化一个流程环节的对象，发送方和接受方应具体联系到管理信息系统的某个(些)用户，而不是某个用户组。每经过一环节，我们除了要保存这方面的信息，还必须保存该环节所转发的公文，以及处理状况等信息。而且，该环节所转发公文数量大于等于一，所以可以参考我之前发布的“浅谈数据库设计技巧(下)”中的“简洁的批量m:n设计”，建表大致如下：
流程环节记录表(Step_log)
名称 类型 约束条件 说明
log_id int 无重复 环节记录标识，主键
step_id int 不允许为空 环节标识，和Step_table.step_id关联
sender varchar(100) 不允许为空 发送用户标识，相关用户组的User_table.user_id的集合
receiver varchar(100) 不允许为空 接受用户标识，相关用户组的User_table.user_id的集合
doc_id int 不允许为空 转发公文标识，和Document_table.doc_id关联
batch_no int 不允许为空 批量转发公文编号，同一流程环节转发的batch_no相同
state char(1) 不允许为空 处理状态
sub_date datetime 不允许为空 提交时间
res_date datetime 允许为空 处理回复时间
comment varchar(255) 允许为空 处理回复注释
说明：
①同一流程环节转发的batch_no和该批第一条入库的log_id相同。举例：假设当前最大log_id是64，接着某用户一次转发了3件公文，则批量插入的3条流程环节记录的batch_no都是65。之后另外一个用户通过某个流程环节转发了一件公文，再插入流程环节记录的batch_id是68。
②state字段用来描述其流程环节所处的状态，是正待处理，已被处理通过，已被处理驳回，还是超出最长等待时间被系统自动收回等等。通过这个字段我们对接受用户发出处理通知，还可以可以很容易的查询出所有超出最长等待时间被系统自动收回的流程，以便企业管理层在日后业务流程重组(BPR)时参考。
③如果某份公文在某个流程中的某个环节被处理驳回，可以看作该公文在此次流程中被驳回至起始点，最初发送用户可根据处理回复注释修改公文后重新发送。
总结：
企业公文流程自定义应该是把企业内已经固定了的公文转发、审批流程电子化，实现高效的无纸化办公，对于非正式的口头讨论、商议、集会等商务活动并不适合。当企业累积了一定数量的电子化公文转发的记录后，可以在商业咨询专家和技术开发人员的协助下对其进行数据挖掘，分析出其中的低效、无用环节，进行优化重组，最终提高整个企业的竞争力。作为技术开发人员，我们应该根据企业实际运作情况、资金投入规模，选择当前时期最适合的技术解决方案，切不可为了展示自己的技术实力，而把开发复杂化，企业开发并不是追求技术最先进，而且最适合。
