用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月，肖永威