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

http://hi.baidu.com/chenrui9814/blog/item/e6fc864674d1210a6a63e56e.html

http://www.builder.com.cn/2007/1215/683339.shtml

数据库模型设计概述

 

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

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

　　物理模型是由逻辑模型转化而来的，要根据具体的数据库产品，为已经设计好的逻辑模型实体选择合适的数据类型和长度(字符串，整形)或精度(浮点数，金额型)，将其转化为物理数据库模型，为物理数据库模型设计表空间，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 产品的差异，则就是一个强有力的中间层产品了，这就需要更多的设计与开发工作了。

查看本文来源