基于SOA架构的企业内容管理方案的数据建模

　　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 产品的差异，则就是一个强有力的中间层产品了，这就需要更多的设计与开发工作了。

查看本文来源