数据融合的核心存储模型及实现.docx
- 文档编号:8113842
- 上传时间:2023-05-12
- 格式:DOCX
- 页数:6
- 大小:22.04KB
数据融合的核心存储模型及实现.docx
《数据融合的核心存储模型及实现.docx》由会员分享,可在线阅读,更多相关《数据融合的核心存储模型及实现.docx(6页珍藏版)》请在冰点文库上搜索。
数据融合的核心存储模型及实现
数据融合的核心存储模型及实现
管理信息系统都具有信息采集、信息存储、信息展示三个环节[1],这些MIS系统通常使用关系数据库来存储数据。
不同的信息系统所处理的数据格式与类型往往差别很大,很难开发出一个通用的信息来适应所有的应用。
人们在设计MIS系统的时候,考虑到业务流程的需要以及用户的习惯,往往会参考手工作业的单据,这些单据的格式往往五花八门,依照这些单据形成的数据库表就自然具有了该应用独有的特色,这种特色导致了为一种业务设计的信息系统很难容纳另一种不同业务。
比如,一个财务系统的数据库结构就很难兼顾人事管理的业务。
应用系统的集成(EAI)需要解决操作系统平台、应用、数据三个层面的兼容问题[2]。
到数据集成这一层面,早期主要是采用编写数据转换的接口以解决在不同应用之间数据互通的问题。
今天,用户的要求已经不仅仅停留在简单的数据交换,而是希望能将所有应用的数据有机糅合起来,统一在新的应用中,这就是所谓的数据融合。
因此,为不同类的业务报表设计通用的数据存储关系模型,并开发一套统一的数据操作接口对数据融合类的应用是具有实用价值的。
1问题描述
MIS系统都围绕着处理业务报表这一核心功能来发展。
无非
是实现对各种业务报表的生成(采集)、存储、统计(运算变换)、
查询(操作)、展现这几个功能。
业务报表就是一张张的二维表,有的可能带有附件。
比如一张财务报表就是一组固定格式的二维表,由许多行与列组成众多的单元格,在格子中填写数据。
将业务报表抽象成“在一组按规则排列的格子中所填写的数据集”,而格子之间的排列规则由格子之间的关系决定,可以抽象成业务报表的格式,简称表格。
用英文表述的话,报表即report,代表一组数据集;表格即form,表示数据的格式信息。
人们最容易看到的是业务报表,因为它们是具体的业务数据,而报表的格式往往被忽略,格式是个抽象的东西,隐含在报表的呈现中。
关系数据库的基本存储单元是字段,一组相关字段形成一条记录,相同类型的记录保存在一张关系表中[3]。
如果用一条记录的某个字段来存储一张业务报表在某格子处的值,则一张业务报表就形成了一条记录,所有同类的业务报表都保存在一张关系表中。
用一张关系表保存所有同类业务报表的存储方式是许多MIS系统最常使用的方法,这种方法将业务报表作为记录存储在关系数据库中,而报表的格式信息则隐含在数据库的表结构定义中,这种存储模式简单直接,容易理解也易于编程实现,并且对数据的存取效率也非常之高,但是其弊端也很明显。
数据库表与业务报表类型一一对应的存储模式最大的弊端在于可扩展性与兼容性都很差,由此带来的系统维护代价很高。
对于关系数据库,一旦表结构确定了,就决定了数据操作的编程
界面固定下来了,后期对表结构的任何修改都会对应用程序带来影响,所有与SQL有关的代码几乎都需要重写。
因为没有统一的
报表格式,即使程序逻辑都一样,也必须为每个业务报表类型做单独的编程。
由此可见,为不同类型的业务报表设计通用的数据存储模型,并基于此模型建立统一的数据操作接口对开发MIS系
统是具有广泛的应用价值的,尤其适合于需要融合多个业务系统的场合。
本文基于一个已经交付的实际项目,分析了在传统数据集成中所面临的问题,提出了解决此问题所使用的一种新型数据存储模型,并基于此模型设计数据操作编程接口。
基于这种方法所实现的数据层能容纳任何业务类型的报表,即使其随时间而变化。
2解决问题的思路
MIS系统如果只存储业务报表,而将报表的格式隐含在关系数据库的表结构中,将使得表结构无法轻易变动,造成数据层无法适应业务的变化。
解决此问题的基本思路就是将业务报表的格式提取出来,形成一种有形的表示方法,也用数据库存储起来。
这种方法的核心思路是基于MetaData(元数据)的概念,就是在业务报表之上提炼出一层元数据专门用来描述业务报表的格式。
元数据的完整定义如下:
元数据是描述其它数据的数据
(dataaboutotherdata),或者说是用于提供某种资源有关
的信息的结构化数据(structureddata)。
元数据是描述信息资源或数据等对象的数据,其使用目的在于:
识别资源;评价资源;追踪资源在使用过程中的变化;实现简单高效地管理大量网络化数据;实现信息资源的有效发现、查找、一体化组织和对使用资源的有效管理。
由于元数据也是数据,因此可以用类似数据的方法在数据库中进行存储和获取[4]。
如果提供数据的组织同时提供描述数据的元数据,将会使数据的使用变得准确而高效。
用户在使用数据时可以首先查看其元数据以便能够获取自己所需的信息。
我们使用元数据的目的就是为了“描述报表(的格式)...追踪报表(格式)在使用过程中的变化;实现简单高效地管理大量报表数据”。
关系型数据管理系统(RDBM)S也是使用元数据来描述并管理自己内部的库表结构的。
Java语言的数据库编程接口JDBC中就使用了大量的MetaData类来描述数据库本身的结构。
一旦有了描述报表格式信息的元数据,报表的类型与格式就可以通过数据表达出来,我们就有途径编写不依赖于固定库表结构的程序,使之能动态地适应任何报表类型与格式。
3业务报表的维度模型数据融合将集中各类业务报表。
如果数据尚处于业务流程中,则数据会随着流程的流转而改变,这类报表不会进入融合阶段。
用来融合的数据应该是已经落地的归档数据,即不再改变的报表。
数据一般是多维度的,如果对业务数据做抽象,报表可以建立如图1所示的维度模型。
首先是时间维度,它代表产生业务数据的时间。
比如一张财务报表,反应了一个企业在特定时间段内的财务状况,可以是某年的某个月份或者季度。
因为要融合不同业务的报表,时间信息应该是多元的:
既支持时点数也支持区间数。
为了对时间维度做统一处理,引入时间码的概念,附加时间类型,可以有年度值、季度值、月度值、或者精确的时间点;并对时间维度设计统一的编程接口,提供了:
生成时间码、提取时间码,时间码比大小等操作。
再分析业务实体维度。
业务实体就是产生报表的主体,一张报表一定是某个业务实体在特定时间或时间段内的业务数据的集合。
业务实体具有唯一性,即在同一个业务系统中,一个业务实体应有一个明确的主键,就像企业有企业代码、个人有身份证号码一样。
对业务实体做抽象,它应该有自己的主键、名称、以及其他附加的属性。
设计业务实体的编程接口需要提供统一的主键管理、增删改查、属性管理等功能。
业务数据无法用一张报表来呈现。
比如企业的财务信息需要多种报表来表达:
资产负债表反映企业的资产与债务状况、现金流量表反映企业的现金情况、利润表反映企业的盈利情况,这就是业务类别维度。
即业务实体在同一时间上存在不同角度的业务数据,需要用不同类别的业务报表来表达,这种报表的多类别就形成了业务类别维度。
对业务类别做抽象,需要梳理业务系统,赋予报表类别以不同的层次,并加以编码,并提供统一的编程接口,包括类别编码的管理以及增删改查等功能。
有了时间、业务实体、业务类别这三个维度就足以描述业务报表了:
任何报表都可以看做一个业务实体在某个时间上一种业务的状态值。
然而,业务的多样性决定了仅这三个维度还不足以反映真实业务的变化。
以财务为例,随着时间的变化其报表格式会发生改变,某企业的利润表原来使用格式A,从某个时间开始
执行新的财务制度,换成格式B。
这隐含了报表模型的第四个维度:
报表格式维度。
如图1中虚线所示,即使同一业务类别,随时间的变化可能具有不同的数据格式。
对报表格式维度做抽象,需要梳理所有同业务类别的数据,整理出不同的格式,并赋予每种格式不同的编码,并提供统一的编程接口,包括格式编码的管理以及增删改查等功能。
四维报表模型足以容纳现实世界的所有业务报表。
其中时间维度与业务实体维度比较单一,处理起来很简单;业务类别与报表格式是数据融合的重点,它们随应用的不同差别很大。
MIS系
统实现对业务数据的采集、存储、查找、展现四个环节,对业务数据做归一化处理能给开发带来很多好处,本方法就是基于对业务数据做归一化处理的设想,设计统一的关系存储模型并提供数据操作的API,从而降低编程复杂性,增加程序的适应性与扩展能力。
4定义报表的格式元数据
用关系数据库存储业务报表时,如果不为每种业务类别定义单独的关系表,而是使用一套通用的关系模式来存储任意类型的报表,这对数据融合特别有价值。
设计这样的关系模型要解决四个问题:
1)处理报表格式随时间而变化。
2)能支持对海量数据的存储。
3)解决多维数据的访问效率。
4)向应用层提供简单一致的操作接口。
用一个例子来说明什么是通用的报表关系模型。
比如财务系统,对于资产负债表、利润表、现金流量表这三张报表,可以简单地使用三个不同的关系表存储数据;一旦报表格式改变,则关系表的结构就必须做调整,有可能增减表的字段,这样就势必要回过头来改程序。
通用的存储模型则能容纳各种类别的报表且容许格式随时间而变化,这样能让具有统一而且稳定的数据库持久层就显得尤其重要了。
简单地把表格都看成一堆单元格子,数据就是在格子中填写的值,如果每个值作为一条记录存在,则表格结构的变化意味着格子个数的变化,反映在数据库中就是记录数的变化,而不是表结构的变化,这样就能让数据持久层保持稳定。
为了方便,可以将表格的结构定义也用关系表存储起来,并且给每张表格加个编码,同时表格中的每个格子也加以编码。
这样就描述了报表格式的概念,形成了反应报表格式信息的元数据。
以下是报表格式元数据的几个核心概念。
Form(表格):
表示报表的格式,决定报表的结构,由几行
几列组成。
表格分不同的类型:
固定表格、行浮动表格、列浮动表格、行列浮动表格。
给表格赋予统一编码可以便于程序处理。
FormSection(表格分区):
表格可由多个部分组成,如标题、注脚、签名栏等等。
将表格定义成多个分区可以增加灵活性。
FormCell(单元格子):
一张表格具有多个分区,每个分区由多个格子组成,每个格子占据表格的一个明确位置(行、列)。
给单元格子做统一编码能方便程序的处理,还可定义格子中数据的类型。
SQL函数可以方便地做字符串与不同数据类型的转换,为简化处理,可以让所有单元格都是字符串类型。
FormStyle(样式):
将表格的样式信息提取出来,形成样式表。
Report(报表):
代表一组数据。
业务实体在某时间填写了一张表格就得到一个报表,由一系列格子中的数据组成。
CellValue(格子值):
一个格子中的数据。
如果一张固定表格有30个格子,则此表格生成的一张报表就由不超过30个格子值组成。
ReportAttach(报表附件):
有的报表除了填写的格子外,还带有附件,附件多以文件的形式单独存在。
这几个核心概念之间的关系如下:
表格具有多个分区;每个分区由多个格子按行列组成;表格可以有样式;表格分区、格子加上样式表就形成了报表的格式,简称表格。
表格具有编码、名称、大小、类型等属性;表格分区具有类型、大小等属性;格子具有编码、位置、数据类型等属性。
每张表格可以生成多个报表;每个报表具有多个格子值,这些格子值构成了报表的具体数据,即报表。
报表具有编码、所属实体、填报时间等属性,为方便查询,可以在报表记录中加上表格编码;格子值具有编码、位置、值的内容等属性。
图2是关系存储模型的E-R图,图中只标了实体的名称。
为了更清楚地描述报表的元数据,用一个具体的例子来说明这些实体之间的关系。
图3是一张利润表的表格,它包含3个固定区域:
只有一个格子的标题区;2行3列的表头区;21行3列的数据区。
这只是一张空白的表格,还没有任何的数据,所以我们称之为表格(报表的格式);只有当企业在利润表中填了数据之后,我们才将数据集称为报表。
在关系数据库中,只需四张表来存储报表的格式元数据,它们是:
表格、表格分区、单元格子、样式。
以图3中的利润表为例,要保存利润表的格式,会在Form表中生成1条记录,它保
存了利润表的总体属性,包括启用时间、制定日期等信息,并含有主键FORM」戸在FormSection表中生成3条记录,分别代表三个区域,都关联同一个FORM」耳在FormCell表中生成70条记录,代表70个格子,分别属于三个区域;在FormStyle(表格样式)表中生成一条记录,是一份XML格式的样式文件。
通过这四张关系表中存储的元数据,就能完全恢复出一张利润表来。
当利润表的格式发生变化时,只需在这四张表中增加一种新的格式,无需改变库表的结构也无需改动程序,这就是使用元数据带来的好处。
利用关系数据库对报表格式进行了存储,接下来看如何保存报表。
保存业务报表需要三个关系表:
Report(报表)、CellValue(格子值)、ReportAttach(报表附件)。
如果某业务实体生成了一张报表,则在Report中有一条记录,它关联了业务实体的主键、时间码、以及报表所使用的表格;报表的数据则保存在CellValue中,每个数据就是一条记录,假如利润表的70个格子都填了数据,则在CellValue中就有70条记录;如果报表有附件,则用ReportAttach表来保存。
这套关系模型不仅储存报表,还储存报表的格式信息,它把所有类型的报表统一起来,让任何业务报表都具有相同的存储模型,这给数据持久层的设计带来了一致性与稳定性,方便应用程序的开发与维护。
5业务信息的恢复与提取业务报表统一存储给编程带来了好处,但也付出了相应的代价,因为关系表不再具有业务含义。
传统的存储方式中,一张关系表就代表一种业务类别。
比如表A是利润表、表B是资产负债表,则净利润一定是A中的某个固定字段,净资产一定是B中的某个固定字段,业务意义隐含在关系表A与B的结构中。
当使用新模型时,所有数据都储存于格子值表中,关系表不再具有业务意义,因此需要对表格与单元格做编码,用编码来反应数据的业务意义。
比如:
编码为x的表格是利润表,其中编码为k的格子代表净利润,编码为y的表格是资产负债表,其中m格子代表净资产。
这样一来,任何业务指标都可以用表格编码与格子编码的函数P(f,c)来表达,其中f是表格的编码,c是格子的编码、P表示具有业务含义的指标项。
同理,任何指标值都可以用函数V(P(f,c),e,t)来表示,其中e是业务实体、t是时间码、V是指标项P的值。
采用编码的方式便于提供统一的数据操作接口。
数据库编程依赖表结构,如果业务层的变化会带来表结构的变化,这是很不利的设计。
新的存储模型表结构不随业务层的变化而改变,使得数据层操作接口保持稳定,可以非常方便的编写数据库内部程序(存储过程与自定义函数)产生特定的中间表来恢复业务报表或提取指标值。
这种存储方式就是对数据仓库概念的一种简化实现,而对业务数据查找与提取方式也是数据挖掘概念的一种简单体现[5]。
在此模型上设计通用的数据层操作API,为应用程序提供支
持。
数据层操作接口的结构如图4所示。
6使用表分区存储海量数据这一模型需解决效率问题。
因所有报表的格子值都存储在
CellValue表中,此表的记录会很多,这会严重影响数据查询的效率。
为解决这一问题,需要在另外的维度对数据做分表存储。
前面对数据的维度做过分析,可以基于时间维度或业务实个维度中对数据存储做分表处理。
以时间维度为例,可以将同一年的报表格子值放在单独的CellValue表中,每年新增加一个CellValue表,这样每个CellValue表最多只保存一年的数据。
以业务实体维度为例做分表,可以通过散列函数将数据均匀地分散在多个CellValue表中,每张表只保存一部分业务实体的数据。
在为上海市国资委开发的实际系统中,我们采用了二者相结合的方式:
首先在业务实体维度做分表处理,生成50个CellValue表;然后在每个表中按照时间维度做分区处理。
这一方案取得了很好的效果,实测下来查询效率很高,对任何指标值的提取耗时都在300毫秒内。
7总结
数据融合需要处理多个MIS系统中的报表,这些报表都是落地的数据,不再改变。
因为业务的差异,导致报表的类别与格式差别很大,融合起来很困难,能否设计一个统一的存储模型是最重要的一步。
在为上海市国资委设计监管信息系统的项目中,通过不断摸索,参照数据仓库与数据挖掘的原理,通过引入报表元数据,增加报表的格式信息,设计了一套关系模型,并基于此模型为应用编程提供了数据层的API。
该模型将不同业务的报表统一起来,能满足数据融合项目的存储要求,经过分表分区处理之后,数据查询效率也很高。
实际运行结果让用户非常满意,该模
型不失为一种数据融合的通用存储方案。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 数据 融合 核心 存储 模型 实现