流程管理公文转发流程自定义的数据建模.docx
- 文档编号:5727701
- 上传时间:2022-12-31
- 格式:DOCX
- 页数:10
- 大小:20.91KB
流程管理公文转发流程自定义的数据建模.docx
《流程管理公文转发流程自定义的数据建模.docx》由会员分享,可在线阅读,更多相关《流程管理公文转发流程自定义的数据建模.docx(10页珍藏版)》请在冰豆网上搜索。
流程管理公文转发流程自定义的数据建模
(流程管理)公文转发流程自定义的数据建模
公文转发流程自定义的数据建模
开发比较复杂的企业多用户管理信息系统(MIS),不可能不涉及到系统内多个用户之间的数据文件的流转、审批等功能的开发。
由于企业的需求总是随着时间推移不断发生变化,加之各个企业内部所设置的办公流程不尽相同,壹套通用性比较好的管理信息系统应该能让系统管理员自己定义公文转发的流程。
尽管笔者没有机会于已参和开发了的MIS中实现出文件转发流程自定义的功能,可是,早于2002年初就曾深入思考过这方面的设计。
当时由于某些原因不能公开自己的设计思路,当下市面上已经有不少MIS产品提供这样的功能,笔者又已离职,所以是时候把我的设计思路整理出来,和大家分享。
首先,让我们分析需求,制定目标。
1)壹般情况下,企业内的公文转发、审批是按部门或职位来转送,即对岗不对人。
例如:
某个流程的某个环节需要财务总监审批,日后财务总监换人,该流程应该不受影响。
而且,流程中某个环节可能出现某个部门中的任何壹人均能审批,或者需要该部门的所有人员共同审批。
2)流程中转送,审批的公文壹般分为文件和表单2种格式。
文件格式的公文应该支持批处理,即壹次能够转发多个文件,审批时能够只退回其中某壹个不合格的文件,其他的文件能够转送到下壹个环节继续处理。
表单格式的公文应该能让用户自己定义表单格式,确定表单中的表项。
同理,表单也应该支持批处理。
3)流程中处理公文的动作应该能让用户自己定义。
这样壹旦日后增加了新的处理动作,也不用修改MIS系统的底层数据建模。
当然,要实现新的处理动作,仍是需要于业务逻辑层编写相应的代码,不过和修改底层数据建模比起来,工作量要少得多。
4)每个流程的环节数不壹定相同,应该能让用户设定环节数,指定公文流转中每个环节的发送部门和接受部门,处理模式,最长等待时间。
5)当待处理的公文发出后,系统应该于等待时间中定期向该流程中下个环节的用户(们)发出通知,提醒该用户(们)及时处理,直至公文已被处理。
如果超出最长等待时间,公文仍未被用户(们)处理,此次流程处理失败。
企业管理层可能会要求记录关联信息,以便于日后业务流程重组(BPR)时参考。
6)某些企业由于特殊原因,于某个流程中要求实现跨环节处理。
例如,该流程有6步,执行到第二个环节时要求处理后能够跳过中间三个环节,直接转到最后壹个环节等候处理。
其实,这种情况下,且不壹定要于技术层面上实现其灵活性,这种特例毕竟是少数。
用户只需定义壹个新流程,把上面流程的第1,2,6步复制加入进来,2个流程之间用流程名来区分即可。
壹个优秀的系统架构设计师应该充分利用现有的工具,不要什么均自行架设开发。
上面的需求对灵活性要求较高,抽象化程度较深,所以于表现层和业务逻辑层的开发量较大,初期投资较多,不过开发完毕后估计不需对底层数据库修改,即可满足日后不断变化的公文流转需求。
如果不需要这么高的灵活性,能够按实际项目简化某些假设条件。
下面按照上面的需求进行用例(usecase)分析和数据建模。
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)
不允许为空
公文名称
doc_type
char
(1)
不允许为空
公文类型
doc_type字段用来辨别公文格式,目前只有2种格式,可设“1”表示文件格式,“2”表示表单格式。
估计未来新增公文格式不会太多,所以该字段只需壹位字符。
文件格式的公文壹般是于文件内固定好格式,我们可用壹个二进制的字段直接保存整个文件的内容。
文件格式的公文需要建壹个表来保存关联信息,其大致数据表如下:
文件表(File_table)
名称
类型
约束条件
说明
file_id
int
无重复
文件标识,主键
file_name
varchar(50)
不允许为空
文件名称
file_value
binary
不允许为空
文件内容
表单格式的公文要让用户自己定义表单格式,确定表单中的表项。
有俩种方法来实现:
①每当用户建立壹个新格式的表单时,就新建立壹个表,把用户输入的表单表项当作该表的字段。
这种方式的优点是表单查询速度较快方便,业务逻辑层的开发量较小。
缺点是不太灵活,如果企业所使用的不同格式的表单较多(>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()
不允许为空
表单信息值
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组件的接口方法。
如果是于.NETFramework环境下,能够采用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)时参考。
③如果某份公文于某个流程中的某个环节被处理驳回,能够见作该公文于此次流程中被驳回至起始点,最初发送用户可根据处理回复注释修改公文后重新发送。
总结:
企业公文流程自定义应该是把企业内已经固定了的公文转发、审批流程电子化,实现高效的无纸化办公,对于非正式的口头讨论、商议、集会等商务活动且不适合。
当企业累积了壹定数量的电子化公文转发的记录后,能够于商业咨询专家和技术开发人员的协助下对其进行数据挖掘,分析出其中的低效、无用环节,进行优化重组,最终提高整个企业的竞争力。
作为技术开发人员,我们应该根据企业实际运作情况、资金投入规模,选择当前时期最适合的技术解决方案,切不可为了展示自己的技术实力,而把开发复杂化,企业开发且不是追求技术最先进,而且最适合。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 流程 管理 公文 转发 自定义 数据 建模
![提示](https://static.bdocx.com/images/bang_tan.gif)