本文从数据建模角度，探讨在金融业，基于 SOA 架构如何设计一个平台级的数据模型，以满足其企业内容管理(Enterprise Content Management, ECM)方案的构建。

　　概述

　　ECM (Enterprise Content Management)是企业内容管理方案的英文简称，该类解决方案在各行业中正逐渐被广泛的采用。本文将探讨在金融业，基于 SOA 架构如何设计一个平台级的数据模型，以满足其 ECM 方案的构建。

　　ECM 在金融业中的采用方式普遍表现为，将各种原始单证扫描成图像后存入 ECM 系统，然后在其上建立业务流程，例如贷款审批业务，只需要审批人在原图像上加盖同意的数字章即可转入下一步流程，从而节省了纸张，提高了效率，流程更加透明，查询更加便利。另外，由于金融业分支机构众多，且现有应用众多，所以基于 SOA 的架构来实现 ECM，是一个好的选择。

　　在这种基于 SOA 的 ECM 架构中，要适应金融业的发展状况，平台级的数据模型设计就显得尤为关键，在本文中，详细论述了该类方案的数据建模要点和过程。

　　业务与架构

　　下图是 IBM 在信息管理方面的 SOA 参考架构。本文将要介绍的针对金融业 ECM 进行数据建模的内容对应于图中的 Content Management 区域。下面将首先从业务和架构展开详细描述。

　　图 1. IBM 信息管理的 SOA 参考架构

　　金融业在使用 ECM 方案处理各种单证文件信息时，主要表现为以下方面 :

　　信息的传输: 各网点将原始单证扫描后按业务分类，分批次传入后台的内容管理服务平台，平台可以部署在营业网点，当然这要视网点业务的规模而定，也可以部署在分中心，分中心还会再和总中心的内容管理平台打交道。这需要借助于 IBM 的企业服务总线 (ESB) 来实现。
　　流程的处理: 将内容管理平台纳入流程管理，后续业务操作将会基于已扫描的单证信息产生工作流，工作流的基本处理元素存储在 ECM 中。这些需要 IBM 流程服务器来构建。

　　针对上述业务特征，从 IT 角度来说，ECM 平台需要处理的主要元素包括 :

　　操作信息
　　业务信息
　　文档信息
　　文档页信息

　　以及上述各种信息之间的关系

　　另外，从操作性方面来考虑，还会涉及 :

　　事务控制
　　并发控制
　　权限控制
　　统计信息，包括运行状态，错误与异常。

　　由于上述所需处理的元素之间存在相当多的关系，而目前市场上多数的内容管理产品的强项在于内容本身的存储管理，对于内容间的复杂关系的管理，则显得是有点力不从心，例如多层引用关系就会导致内容管理性能的下降，所以使用单纯的内容管理产品往往无法满足金融业的 ECM 应用，需要借助成熟的数据库技术来实现，其架构如图 2 所示，其中元数据，即各种内容的描述信息及其业务关系信息交由数据库来处理，媒体(即内容)信息则交给内容管理产品来负责。

　　图 2. 内容管理平台架构

　　由此产生了数据建模的需要，数据模型需要满足以下要求：

　　模型通用化，与业务松耦合。
　　具有很好的扩展性，支持新业务的添加扩展。

　　下面进入我们富有创意的数据建模工作。

　　数据库模型设计概述

　　在开始我们的数据建模之前，首先让我们简单地回顾一下数据库模型设计的基本步骤，数据建模主要由逻辑模型设计和物理模型设计构成，其中逻辑模型设计主要完成以下三个任务：

　　标识逻辑实体
　　标识逻辑实体间关系
　　标识逻辑实体的属性

　　物理模型是由逻辑模型转化而来的，要根据具体的数据库产品，为已经设计好的逻辑模型实体选择合适的数据类型和长度(字符串，整形)或精度(浮点数，金额型)，将其转化为物理数据库模型，为物理数据库模型设计表空间，bufferpool，表，索引，外键，序列等等，最后得到数据库建库脚本。

　　有了逻辑模型后，物理模型就是水到渠成的事情了，所以本文重点在逻辑建模内容，物理模型不做赘述。

　　标识逻辑实体

　　逻辑模型设计的实体标识阶段，是要根据业务的分析结果，将业务对象抽象出来。

　　从前面描述的业务和 IT 要素中，我们可以分析得到逻辑实体有 :

　　参与人——业务人员
　　事件——扫描，传输，获取
　　事物——金融单证的图像，也可以叫做资源
　　时间——隐含在事件要素中
　　地点——各业务部门

　　图 3. 组成世界的逻辑对象

　　其实上述的五大要素构成了现实世界，所以从中我们可以抽象出所需要的逻辑实体：

　　Event
　　Business Info
　　Resource Item
　　Resource Item Component
　　Party

　　通过上述思路，可以有效的从具体业务中抽象出逻辑实体，这样即使将来增加其他的内容存储业务，也可以很好的对应进来，不过还需要类型配置来表明是何种业务何种数据，即再增加一个数据字典实体：

　　Classification

　　这样，我们就标识出了逻辑模型的基础实体。下面再标识实体的属性以及实体间的关系。

　　标识逻辑实体的属性和关系

　　EVENT

　　EVENT 代表了业务事件，其基本要素要求有时间，人员，事件类型，可以得出逻辑实体的属性如下图：

　　图 4. EVENT

　　Resource Item

　　Resource Item 代表了资源项，主要内容包括资源项类型，对应的事件，序号等信息，其实体属性如下图：

　　图 5. Resource Item

　　Resource Item Component

　　Resource Item Component 代表了资源项的组件，主要内容包括资源项组件的类型，对应的事件，组件在资源项中的序号，对之进行改动的人员及时间，其实体属性如下图：

　　图 6. Resource Item Component

　　Business Info

　　Business Info 代表了业务信息，由于金融业务信息千差万别，这里无法做到用模型概括，所以这里的 Business Info 只是定义了非常通用的业务属性，即业务类型属性。具体的业务可以继承 Business Info 的属性，在其基础之上进行扩展和自定义。详细扩展方式参见模型的可扩展 -BusinessInfo 的继承。

　　将以上各个实体的属性丰满起来之后，再标识实体间关系，如一对多，一对一，多对多等关系。从而得出实体关系如图 7:

　　图 7. 实体关系图

　　上图 7 中黄色部分是基础实体，代表了我们的业务对象，绿色部分是主要实体间关系衍生而来的关系型实体，灰色部分是分类的定义，其中灰色部分的实体全部继承自 Classification 实体，其继承关系如下图 8 所示：

　　图 8. 分类继承关系图

　　上图 8 中的灰色实体全部为逻辑化实体，在逻辑模型转为物理模型时将其内容合并上升到 Classification 实体中。

　　模型的可扩展性 – Business Info 的继承

　　模型为新业务提供了扩展点，Business Info 实体是所有业务的父亲，新增添的业务可以在它基础上加以继承，如图 9：

　　图 9. Business Info 扩展

　　上图中 XXX Business Info 为新增的某业务示例，它的 ID 继承自 Business Info 实体，其它部分为 XXX 业务特定的业务信息，是扩展时根据具体业务需要自行定义的。

　　这样就提供了一个扩展框架，可以在此框架之上任意添加新的业务实体。在添加新的业务时，应用程序主程序几乎不需要变动，只需要添加一个新的业务处理类，主程序从 Business Info 中可以得到新业务的 ID 和业务类型 Business Type，然后将 ID 和 Business Type 交给业务处理单元处理，业务处理单元根据业务类型 Business Type 调用相应的业务处理类就可以了，如此扩展带来的成本很低，效率却很高。

　　模型的松耦合性 – Classification 的使用

　　模型不仅提供了良好的扩展性，还具备了与业务无关的松耦合性，这个特性是通过 Classification 实体来实现的。在 Classification 实体中，可以定义任意的业务含义，这些业务含义和那些抽象实体(如 Event，Resource Item，Resource Item Component)相结合，就可以处理各种业务情况。

　　可以把 Classification 理解为字典数据，只不过这个字典数据是需要系统自定义的，而且可以定义成任何含义，从而达到脱离具体的业务用语，实现模型与业务的松散耦合。

　　事务控制

　　在基于 SOA 架构的 ECM 应用中，数据交换的内容包括两部分：

　　XML 格式的元数据
　　媒体文件

　　两者可以作为一个包传输，也可以分开传输，由于两者在内容，用途和大小上差异很大，分开并行传输是一个好的选择，这就引出了同步和事务控制的问题，这在数据模型中也是需要考虑的，但因为它已经和业务无关了，是纯粹的 IT 技术问题，所以在这里不做深入探讨，下面只是简单介绍思路和要点，有兴趣的读者可以自己尝试完成。

　　在模型中建立 APP 的主题域，在该域中下定义两个实体：sync list 和 transaction control。

　　sync list 用于同步元数据和媒体数据，当两者成对收到后即可进行下一步处理。

　　transaction control 用于控制 DBM 与 CM 存储时多阶段提交的事务完整性，逻辑表示如下图：

　　图 10. 事务控制时序图

　　从图 10 中可以看到，事务的每一步执行都预先登记在 Transaction Control 中，即时任何一刻失败了，例如遇到宕机，应用崩溃等，将系统重启后，应用重新扫描 Transaction Control，即可从上次失败处继续处理，从而实现了事务的逻辑完整性。

　　另外，当客户端提交数据后，由于传输中包括了媒体信息，所以后台的异步传输是需要一些时间的，用户可能在这个时间段内要求查询处理状况，从上面的设计可以看到，可以从以下地方查询到处理情况：

　　数据在 Sync List 中，说明还在传输途中。
　　数据在 Transaction control 中，说明还在保存中。
　　数据不在上述两项中，但在数据库中可以查到对应的记录，说明处理已完成。

　　结束语

　　本文针对金融业的 ECM 方案，从数据建模的角度论述了如何设计数据模型，可以实现与业务的松耦合，保持良好的扩展，从而做到平台级别的设计。文中包含了典型的数据模型设计方法，和已经验证多年的成熟的设计技巧，希望能给数据建模人员带来帮助。

　　从数据建模的角度，文章到这里就可以结束了，但从 ECM 数据平台的角度，则还有很多工作要做，比如如果能在数据库之上设计一层数据存取层，提供标准的 API，从而屏蔽掉数据库和 CM 产品的差异，则就是一个强有力的中间层产品了，这就需要更多的设计与开发工作了。