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

公文转发流程自定义的数据建模开发比较复杂的企业多用户管理信息系统（MIS），不可能不涉及到系统内多个用户之间的数据文件的流转、审批等功能的开发。由于企业的需求总是随着时间推移不断发生变化，加之各个企业内部所设置的办公流程不尽相同，一套通用性比较好的管理信息系统应该能让系统管理员自己定义公文转发的流程。尽管笔者没有机会在已参与开发了的MIS中实现出文件转发流程自定义的功能，但是,早在2002年初就曾深入思考过这方面的设计。当时由于某些原因不能公开自己的设计思路，现在市面上已经有不少MIS产品提供这样的功能，笔者又已离职，所以是时候把我的设计思路整理出来，和大家分享。首先，让我们 分析 定性数据统计分析pdf销售业绩分析模板建筑结构震害分析销售进度分析表京东商城竞争战略分析 需求，制定目标。1）一般情况下，企业内的公文转发、审批是按部门或职位来转送，即对岗不对人。例如：某个流程的某个环节需要财务总监审批，日后财务总监换人，该流程应该不受影响。而且，流程中某个环节可能出现某个部门中的任何一人都能审批，或者需要该部门的所有人员共同审批。2）流程中转送，审批的公文一般分为文件和 表 关于同志近三年现实表现材料材料类招标技术评分表图表与交易pdf视力表打印pdf用图表说话 pdf 单2种格式。文件格式的公文应该支持批处理，即一次可以转发多个文件，审批时可以只退回其中某一个不合格的文件，其他的文件可以转送到下一个环节继续处理。表单格式的公文应该能让用户自己定义表单格式，确定表单中的表项。同理，表单也应该支持批处理。3）流程中处理公文的动作应该能让用户自己定义。这样一旦日后增加了新的处理动作，也不用修改MIS系统的底层数据建模。当然，要实现新的处理动作，还是需要在业务逻辑层编写相应的代码，不过和修改底层数据建模比起来，工作量要少得多。4）每个流程的环节数不一定相同，应该能让用户设定环节数，指定公文流转中每个环节的发送部门和接受部门，处理模式，最长等待时间。5）当待处理的公文发出后，系统应该在等待时间中定期向该流程中下个环节的用户（们）发出通知，提醒该用户（们）及时处理，直至公文已被处理。如果超出最长等待时间，公文还未被用户（们）处理，此次流程处理失败。企业管理层可能会 要求 对教师党员的评价套管和固井爆破片与爆破装置仓库管理基本要求三甲医院都需要复审吗 记录相关信息，以便在日后业务流程重组（BPR）时参考。6）某些企业由于特殊原因，在某个流程中要求实现跨环节处理。例如，该流程有6步，执行到第二个环节时要求处理后可以跳过中间三个环节，直接转到最后一个环节等候处理。其实，这种情况下，并不一定要在技术层面上实现其灵活性，这种特例毕竟是少数。用户只需定义一个新流程，把上面流程的第1,2,6步复制加入进来，2个流程之间用流程名来区分即可。一个优秀的系统架构设计师应该充分利用现有的工具，不要什么都自行架设开发。上面的需求对灵活性要求较高，抽象化程度较深，所以在表现层和业务逻辑层的开发量较大，初期投资较多，不过开发完毕后估计不需对底层数据库修改，即可满足日后不断变化的公文流转需求。如果不需要这么高的灵活性，可以按实际项目简化某些假设条件。下面按照上面的需求进行用例（usecase分析和数据建模。1）由于流程环节的发送方和接受方是对岗不对人，我们应该先描画出整个企业的机构设置，确定每个部门的权利职责。其中大的部门内可能有若干子部门，每个子部门内又有不同职位，负责处理相应的事务。所以，可先建立一个树形关系的数据表来保存企业结构，然后，采用权限表和用户组相结合的方式来保存每个部门每个职位的职能。这块的设计思路见我之前发布的浅谈数据库设计技巧（上）、（下）”，我在下面直接给出大致的数据表结构：部门表(Department_table)［名称类型约束条件说明Dpidint无重复类别标识，主键Dpnamevarchar(50)不允许为空类型名称，不允许重复Dpfatherint不允许为空该类别的父类别标识，如果是顶节点的话设定为某个唯一值Dplayervarchar(6)限定3层，初始值为000000类别的先序遍历，主要为减少检索数据库的次数功能表(Function_table)名称类型|约束条件说明fidint无重复功能标识，主键fnamevarchar(20)不允许为空功能名称，不允许重复f_descvarchar(50)允许为空［功能描述用户组表(User_group)名称类型约束条件说明groupidint无重复用户组标识，主键groupnamevarchar(20)?不允许为空用户组名称grouppowervarchar(100)不允许为空用户组权限表，内容为功能表fid的集合用户表(User_table)名称类型约束条件说明useridint无重复用户标识，主键usernamevarchar(20)无重复用户名userpwdvarchar(20)不允许为空用户密码所属用户组标识，和user_typeint不允许为空User_group.group_id关联说明：其中，按部门的不同职位设置不同权限的用户组，如某个用户组为市场部业务员”该用户组的用户可在流程报销申请”中发送报销申请。尽管流程中的公文分为文件和表单2种格式，但是每个文件/表单都应该有其唯一标识，名称等属性。所以，我们把公文抽象化，把这2种格式的公文的共有属性提取出来建立一张公文表。公文表(Document_table)名称类型约束条件说明docidint无重复公文标识，主键docnamevarchar(50)不允许为空公文名称doc_typechar(1)?不允许为空公文类型doc_type字段用来辨别公文格式，目前只有2种格式，可设“1表示文件格式，“2表示表单格式。估计未来新增公文格式不会太多，所以该字段只需一位字符。文件格式的公文一般是在文件内固定好格式，我们可用一个二进制的字段直接保存整个文件的内容。文件格式的公文需要建一个表来保存相关信息，其大致数据表如下：文件表(File_table)名称类型约束条件说明fileidint无重复文件标识，主键filenamevarchar(50)不允许为空文件名称filevaluebinary?不允许为空文件内容表单格式的公文要让用户自己定义表单格式，确定表单中的表项。有两种方法来实现:每当用户建立一个新格式的表单时，就新建立一个表，把用户输入的表单表项当作该表的字段。这种方式的优点是表单查询速度较快方便，业务逻辑层的开发量较小。缺点是不太灵活，如果企业所使用的不同格式的表单较多(>20种)，整个数据库的结构显得比较混乱，而且大部分表单中都有相同的字段，这样也增加了数据冗余。这种方式的数据建模如下：表单总表(Sheet_table)名称类型约束条件说明sheetidint无重复表单标识，主键sheetnamevarchar(50)不允许为空表单名称tablenamevarchar(20)不允许为空表单子表名，如Subtable1/Subtable2表单子表1(Sub_table1)名称类型约束条件说明subidint无重复表单子表标识，主键option1varchar不允许为空表单表项1option2varchar不允许为空表单表项2option3varchar不允许为空表单表项3表单子表2(Sub_table2)名称类型约束条件说明subidint无重复表单子表标识，主键option1varchar不允许为空表单表项1option2varchar不允许为空表单表项2option3varchar不允许为空表单表项3②对表单再进行一个抽象，把表单看成由若干个表单表项所组合成的一个集合。这种方式的优点是相当灵活，用户建立新格式的表单时只用从已有表单表项中勾选出需要的表项即可，而且整个数据库结构清晰，没有数据冗余。缺点是开发比较复杂，工作量和上面相比高出不少，而且表单查询速度较慢。下面是这种方式的数据建模：表单总表(Sheet_table)名称类型约束条件说明sheetidint无重复表单标识，主键sheetnamevarchar(50)不允许为空表单名称表单表项表(Option_table)［名称类型约束条件说明opidint无重复表单表项标识，主键opnamevarchar(50)不允许为空表单表项名称oplengthint不允许为空表单表项长度op_unitvarchar(10)允许为空表单表项单位表单信息表(Sheetinfo_table)名称类型约束条件说明infoidint无重复表单信息标识，主键sheetidint不允许为空？？所属表单标识，和Sheettable.sheeti(关联opidint不允许为空？？表单表项标识，和Optiontable.opid关联info_valuevarchar()?不允许为空表单信息值我们可以把公文转发的流程抽象化，看作一个实体超类。建表如下:流程表(Flowtable)名称类型约束条件说明flowidint无重复流程标识，主键flownamevarchar(50)不允许为空流程名称flowstepnumint不允许为空流程步数Iflowdesc|varchar(200)|允许为空|流程描述流程中的每一步都可以抽象化成从发送方至接受方的用例，其数据建模大致如下：处理动作表(Action_table)名称类型约束条件说明aidint无重复动作标识，主键a_namevarchar(20)不允许为空动作名称acallvarchar(50)不允许为空动作所调用的模块adescvarchar(200)允许为空动作描述说明：如果米用面向过程的开发方式，如纯脚本语言，可以把每一个处理动作写成一个 函 关于工期滞后的函关于工程严重滞后的函关于工程进度滞后的回复函关于征求同志党风廉政意见的函关于征求廉洁自律情况的复函 数，调用a_call字段记录的函数，即可完成相应处理动作。如果采用面向对象的开发方式，可以用COM组件来封装处理动作，则a_call用来记录相应的COM组件的接口方法。如果是在.NETFramework环境下，可以米用Web服务的方式。当然，发送方、接受方以及公文标识是作为输入参数的。流程环节表(Step_table)名称类型约束条件说明stepidint无重复环节标识，主键belongint不允许为空所属流程标识，和Flowtable.flowid关联setporderint不允许为空所属流程的步骤次序senderint不允许为空发送方标识，和Usergroup.groupid关联receiverint?不允许为空接受方标识，和Usergroup.groupid关联aidint不允许为空？?？处理动作标识，和Action_table.a_id关联atypeint不允许为空接受方所需的处理人数maxwaitint不允许为空最长等待时间waitunitvarchar(5)不允许为空等待时间的单位说明：a_type用来确定接受方所需的处理人数，“0表示需同职位的所有人一起处理，1表示只需该职位的任意一名员工处理，“2表示需该职位的任意两名员工一起处理，依次递推……一起处理的方式和处理动作有关，例如是投票方式，少数服从多数，还是某人有一票否决权等等。可能针对某些处理动作还得细化，进行相关的数据建模，这里我就不细分下去了。下面分析公文转发的流程环节记录。此时相当于实例化一个流程环节的对象，发送方和接受方应具体联系到管理信息系统的某个(些)用户，而不是某个用户组。每经过一环节,我们除了要保存这方面的信息，还必须保存该环节所转发的公文，以及处理状况等信息。而且，该环节所转发公文数量大于等于一，所以可以参考我之前发布的浅谈数据库设计技巧（下）”中的简洁的批量m:n设计”建表大致如下：流程环节记录表（Step_log）名称类型约束条件说明log」dint无重复环节记录标识，主键stepidint不允许为空环节标识，和Steptable.stepid关联sendervarchar(1OO)不允许为空发送用户标识，相关用户组的Usertable.userid的集合receivervarchar(1OO)不允许为空接受用户标识，相关用户组的Usertable.userid的集合docidint不允许为空转发公文标识，和Documenttable.docid关联batchnoint不允许为空批量转发公文编号，同一流程环节转发的batchno相同statechar(1)?不允许为空处理状态subdatedatetime不允许为空提交时间resdatedatetime允许为空处理回复时间commentvarchar(255)允许为空处理回复注释说明:同一流程环节转发的batch_no和该批第一条入库的log」d相同。举例：假设当前最大log_id是64,接着某用户一次转发了3件公文，则批量插入的3条流程环节记录的batch_no都是65。之后另外一个用户通过某个流程环节转发了一件公文，再插入流程环节记录的batch」d是68。state字段用来描述其流程环节所处的状态，是正待处理，已被处理通过，已被处理驳回，还是超出最长等待时间被系统自动收回等等。通过这个字段我们对接受用户发出处理通知，还可以可以很容易的查询出所有超出最长等待时间被系统自动收回的流程，以便企业管理层在日后业务流程重组（BPR）时参考。如果某份公文在某个流程中的某个环节被处理驳回，可以看作该公文在此次流程中被驳回至起始点，最初发送用户可根据处理回复注释修改公文后重新发送。总结：企业公文流程自定义应该是把企业内已经固定了的公文转发、审批流程电子化，实现高效的无纸化办公，对于非正式的口头讨论、商议、集会等商务活动并不适合。当企业累积了一定数量的电子化公文转发的记录后，可以在商业咨询专家和技术开发人员的协助下对其进行数据挖掘，分析出其中的低效、无用环节，进行优化重组，最终提高整个企业的竞争力。作为技术开发人员，我们应该根据企业实际运作情况、资金投入规模，选择当前时期最适合的技术解决方案，切不可为了展示自己的技术实力，而把开发复杂化，企业开发并不是追求技术最先进，而且最适合。