数据融合的核心存储模型及实现.docx

数据融合的核心存储模型及实现 管理信息系统都具有信息采集、 信息存储、 信息展示三个环 节[1] ，这些 MIS 系统通常使用关系数据库来存储数据。不同的 信息系统所处理的数据格式与类型往往差别很大， 很难开发出一 个通用的信息来适应所有的应用。人们在设计 MIS 系统的时候， 考虑到业务流程的需要以及用户的习惯， 往往会参考手工作业的 单据，这些单据的格式往往五花八门， 依照这些单据形成的数据 库表就自然具有了该应用独有的特色， 这种特色导致了为一种业 务设计的信息系统很难容纳另一种不同业务。 比如，一个财务系 统的数据库结构就很难兼顾人事管理的业务。 应用系统的集成（EAI）需要解决操作系统平台、应用、数 据三个层面的兼容问题 [2] 。到数据集成这一层面，早期主要是 采用编写数据转换的接口以解决在不同应用之间数据互通的问 题。今天，用户的要求已经不仅仅停留在简单的数据交换，而是 希望能将所有应用的数据有机糅合起来， 统一在新的应用中， 这 就是所谓的数据融合。 因此，为不同类的业务报表设计通用的数 据存储关系模型， 并开发一套统一的数据操作接口对数据融合类 的应用是具有实用价值的。 问题描述 MIS系统都围绕着处理业务报表这一核心功能来发展。无非是实现对各种业务报表的生成 （采集）、存储、统计（运算变换） 、查询（操作）、展现这几个功能。 业务报表就是一张张的二维表， 有的可能带有附件。 比如一 张财务报表就是一组固定格式的二维表， 由许多行与列组成众多 的单元格， 在格子中填写数据。 将业务报表抽象成“在一组按规 则排列的格子中所填写的数据集”， 而格子之间的排列规则由格 子之间的关系决定，可以抽象成业务报表的格式，简称表格。用 英文表述的话，报表即 report ，代表一组数据集；表格即 form ， 表示数据的格式信息。 人们最容易看到的是业务报表， 因为它们 是具体的业务数据， 而报表的格式往往被忽略， 格式是个抽象的 东西，隐含在报表的呈现中。 关系数据库的基本存储单元是字段， 一组相关字段形成一条 记录，相同类型的记录保存在一张关系表中 [3] 。如果用一条记 录的某个字段来存储一张业务报表在某格子处的值， 则一张业务 报表就形成了一条记录， 所有同类的业务报表都保存在一张关系 表中。用一张关系表保存所有同类业务报表的存储方式是许多 MIS系统最常使用的方法，这种方法将业务报表作为记录存储在 关系数据库中， 而报表的格式信息则隐含在数据库的表结构定义 中，这种存储模式简单直接，容易理解也易于编程实现，并且对 数据的存取效率也非常之高，但是其弊端也很明显。 数据库表与业务报表类型一一对应的存储模式最大的弊端 在于可扩展性与兼容性都很差，由此带来的系统维护代价很高。 对于关系数据库， 一旦表结构确定了， 就决定了数据操作的编程 界面固定下来了， 后期对表结构的任何修改都会对应用程序带来 影响，所有与SQL有关的代码几乎都需要重写。 因为没有统一的 报表格式， 即使程序逻辑都一样， 也必须为每个业务报表类型做 单独的编程。 由此可见， 为不同类型的业务报表设计通用的数据 存储模型，并基于此模型建立统一的数据操作接口对开发 MIS系 统是具有广泛的应用价值的， 尤其适合于需要融合多个业务系统 的场合。 本文基于一个已经交付的实际项目， 分析了在传统数据集成 中所面临的问题， 提出了解决此问题所使用的一种新型数据存储 模型，并基于此模型设计数据操作编程接口。 基于这种方法所实 现的数据层能容纳任何业务类型的报表，即使其随时间而变化。 解决问题的思路 MIS系统如果只存储业务报表，而将报表的格式隐含在关系 数据库的表结构中， 将使得表结构无法轻易变动， 造成数据层无 法适应业务的变化。 解决此问题的基本思路就是将业务报表的格 式提取出来，形成一种有形的表示方法，也用数据库存储起来。 这种方法的核心思路是基于 Meta Data (元数据)的概念，就是 在业务报表之上提炼出一层元数据专门用来描述业务报表的格 式。 元数据的完整定义如下：元数据是描述其它数据的数据 ( data about other data )，或者说是用于提供某种资源有关 的信息的结构化数据( structured data )。元数据是描述信息 资源或数据等对象的数据，其使用目的在于：识别资源；评价资 源；追踪资源在使用过程中的变化； 实现简单高效地管理大量网 络化数据；实现信息资源的有效发现、查找、一体化组织和对使 用资源的有效管理。 由于元数据也是数据， 因此可以用类似数据 的方法在数据库中进行存储和获取 [4] 。如果提供数据的组织同 时提供描述数据的元数据，将会使数据的使用变得准确而高效。 用户在使用数据时可以首先查看其元数据以便能够获取