本文从数据建模角度，探讨在金融业，基于 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 产品的差异，则就是一个强有力的中间层产品了，这就需要更多的设计与开发工作了。