首页 > 代码库 > 用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续)
用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续)
1、办公系统中文档的定义
办公系统中的文档就是指对数据不敏感的业务,例如流程中的审批单、信息专栏、数据上报、信息记录等。而对于这些信息的管理,特别是时效性较强的管理记录,仍采用关系型数据库进行管理。
(1)流程中审批单
流程中审批单由功能按钮区、特殊功能区、业务表单区、附件区、审批意见区等区域构成,其中,业务表单区理论上包含附件和意见,但是由于附件和意见的业务特殊性,需要单独进行管理,剩下的业务表单就可以看作文档了。
在一些流程审批业务中,业务信息有的是以Excel或word文件等方式专递,这样非常简洁,缺点就是不直观。
图1
典型业务表单样例
业务表单内容,主要用于审批主体对象,如下图所示的直观展示,能方便审批工作(与附件相对应),提高审批效率。
图2
(2)综合信息
综合信息是指新闻、资料、学习园地、法律法规、部门职能介绍等信息展现类业务,这类业务是以文字、图片为主,信息存储结构简单,不固定。而对信息的答复、评论,都是依附信息存在的,删除信息,则其所对应的评论、答复也就不存在了。
其中,信息专栏是信息按预定分类进行展现的入口,专栏结构不固定,变化较为频繁。
(3)数据上报
数据上报是指填报数据给主管部门,需要填报数据随意性比较大,变是常态。
以上审批单、综合信息、数据上报等业务主体,都具有数据结构不固定、变化频繁、数据敏感度低等特性;上述业务高端应用使用Lotus Notes/Domino(文档型数据库)系统来实现。因此,本文提出使用NoSQL数据库来实现上述业务。
2、审批单/表单“保存”与业务完整性
流程业务通常情况是这样的,工作人员填写业务申请单(填写表单),并准备好相关资料(添加附件),把业务申请单和资料打包(保存)后,送出传递给流程下一环节审批人。
完成上述业务,如下图3所示,至少需要填写表单、添加附件、保存、送出四个操作动作,而且其操作对象分别是文档资料和走流程,也就是说流程是运输线,文档资料是需要运载的货物。
基于上述定义,流程和文档资料可以进行分别管理,每个流程实例把流程和文档关联起来。
图3
(1)业务操作顺序
在处理流程中审批单业务时,用户操作顺序如下:
第一步:填写表单内容(含上传附件)或审批意见;
第二步:选择下一步及下一步接受人;
第三步:保存表单(等待反馈成功);
第四步:送出表单(审批单按工作流规则送往下一环节);
第五步:关闭当前页面,完成业务处理。
(2)业务完整性处理
在处理流程审批单业务过程中,要求先保存成功表单(保存到MongoDB中),并返回表单文档ID,然后,再进行送出操作,此时是工作流和业务关键数据在关系型数据库中进行保存更新操作,其中,记录了前面返回的表单文档ID。
3、数据库设计
(1)文档数据库设计
依据MongoDB数据库设计模型,一对多的关系(Model One-to-Many Relationships with Embedded Documents)模型。
在审批单中,如图2所示审批单主表与资产明细是一对多的关系,审批意见也是一对多的关系,把关系型数据库转换成NoSQL文档型数据库,也就是从Table转换为Collection,如下图4所示为内嵌式文档,资产明细在文档中存储为多条。
图4
由于审批意见是与流程相关的,流转经流程环节与审批意见对应,所以,审批意见应从Collection中拿出来,放到关系型数据库中进行使用。
(2)文档型数据库与关系型数据库结合使用思路
图5
从管理整体来看,也从技术架构整体来分析,数据库设计仍以关系型为主,引入NoSQL数据库仅仅解决了文档型数据信息的存储灵活性和数据结构不定、多变的需求。仅此一项将节省一部分的设计、开发工作量。
另外,围绕文档的定义,例如表单的配置数据项与MongoDB中Collection Schema对应。由于MongoDB数据库的列的水平扩展能力,在一个Collection(关系型数据库的表)中不同Document(关系型数据中的row),可以任意扩展以支持表单灵活、动态配置。
参考:
(1)通用流程化应用审批单设计思路(一) 2014年12月,肖永威
(2)在BPM动态可配置表单中使用NoSQL技术可行性分析——通用流程化应用审批单设计思路(二)2014年12月,肖永威
(3)云计算统一办公运营平台服务能力设计方案 2014年11月,肖永威
用MongoDB数据库来管理办公系统中文档型的表单和信息——通用流程化应用审批单设计思路(二,续)