信息化软件 企业管理 营销管理 业界消息 标签索引
信息化软件目录
OA 办公自动化 CRM 客户关系管理 PM 项目管理 CC 协同商务 BPM 业务流程管理 KM/KBS 知识管理 CMS 内容管理 SCM 供应链管理 BI 商务智能 ERP 企业资源计划 HRM 人力资源管理 EAM 企业资产管理 电子商务系统 IT综合

一个通用的OLAP体系结构

2010-04-01

一个通用的OLAP体系结构: 0 引 言

随着市场竞争的日趋激烈,近年来企业更加强调决策的及时性和准确性,这使得以支持决策管理分析为主要目的的应用迅速崛起,这类应用被称为联机分析处理(On-Line Analytical Processing)。联机分析处理的主要特点,是直接仿照用户的多角度思考模式,预先为用户组建多维的数据模型,在这里,维指的是用户的分析角度。例如对销售数据的分析,时间周期是一个维度,产品类别、分销渠道、地理分布、客户群类也分别是一个维度。一旦多维数据模型建立完成,用户可以快速地从各个分析角度获取数据,也能动态地在各个角度之间切换或者进行多角度综合分析,具有极大的分析灵活性。

一个好的OLAP系统不仅在功能上能为用户提供快速一致的分析服务,而且在体系结构设计上也要达到足够的通用性和兼容性,后台能够与大多数大型数据仓库系统集成,前端可以方便地与不同的前端工具结合。目前很多OLAP服务系统在这一点上做得不够好,例如DB2的OLAP服务系统,只能对系统指定的DB2 UDB数据库中的数据进行分析,而且只能用于DB2本身自带的多维分析工具,存在一定的局限性,通用性不够好。本文提出的体系结构中,OLAP服务器可以方便地与多种大型数据仓库进行集成,并通过语义层屏蔽了各种数据源物理模式的差异,对前端用户透明,使得此体系结构更加方便通用。

  1 OLAP运行环境

一般的OLAP分析系统都是建立在OLAP立方体上,而本文提到OLAP系统不仅可以建立在OLAP立方体上,而且可以建立在数据仓库和OLTP数据库上,达到了一定的通用性和集成性。其中如何集成这几种运行环境,对用户屏蔽这几种环境的差异,实现本系统的灵活通用性,关键在于OLAP服务器的构建与实现。下面详细介绍OLAP服务器的具体结构。

整个OLAP框架如图1所示。

图1

一个通用的OLAP体系结构:2 OLAP应用服务器结构

OLAP应用服务器的设计是整个OLAP体系结构的关键,目前的OLAP产品,根据存储方式的不同,分为ROLAP和MOLAP及HOLAP等,但它们的分析数据都来自多维数据库,而本系统的分析数据源不仅有多维数据库还包括数据仓库和OLTP数据库,这几种数据源的存储方式各异,一般的数据仓库和OLTP数据库都采用关系数据库存储,而多维数据既可以采用多维数组也可以采用关系数据库存储。为此,本系统增加了一个新的层次:语义层,来对用户屏蔽这几种数据源的差异,而且增加了一个新的查询语言生成模块来处理客户端请求,并生成不同数据源的查询语句。这些结构的定义都增加了本系统的通用性。本服务器具体结构如图2所示。

图2

2.1 语义对象的定义

为了实现系统的通用性,在OLAP服务器中定义了一个语义层,并定义了一个新的对象:语义对象,在本系统中,OLAP分析的数据源分为普通关系数据库数据源(DB)、数据仓库数据源(DW)和OLAP立方体(CUBE)数据源。语义对象是在这三种数据源的物理模式上定义的一种统一的语义模型,它既包含有物理信息,又包含有逻辑信息。语义对象简单来讲,是对数据表字段的封装(在OLAP立方体中是对维下面的层次和度量的封装),将数据表中的一个或多个字段封装成用户能方便理解和操作的语义对象。

语义对象的物理信息由普通数据库数据源(DB)的物理模式、数据仓库数据源Datahouse (DW)的物理模式或者OLAP分析立方体(CUBE)的物理模式得到,并在物理信息上增加了一层逻辑概念。引入语义层的目的就是为了对用户屏蔽物理模式的信息而向最终用户展现统一的逻辑上的概念,它对OLAP前端用户屏蔽了DB、DW和OLAP立方体三种数据源的差异,使系统能够面向一般的非专业用户,使他们以熟悉的行业术语进行数据分析及交流,同时也屏蔽了保密数据,加强了对于数据库的安全维护

2.2 语义对象设计与存储

(1)语义对象的逻辑概念

语义对象的逻辑概念也就是展现给OLAP前端工具用户的概念,用户通过对语义对象进行拖动、排列等操作,来设计OLAP分析的结果在前端工具的展现模式,获得自己想要的分析结果。

·分析数据源:分析数据源是建立在物理数据源之上的一个逻辑概念。一个语义对象存储文件记录一个分析数据源的信息,因此一个物理数据源对应一个或者多个分析数据源。

·分析主题(SUBJECT):一个语义对象存储文件记录关于一个分析数据源的多个分析主题的信息。用户的每个分析都针对一个分析主题进行,一个分析主题包含有一个或者多个语义对象。

·语义对象:针对OLAP立方体数据源定义的语义对象,可以理解为对维下面的层次或者度量的简单封装。针对普通DB数据源定义的可以理解为对数据库表字段的封装(需要手动干预)。DW数据源很特殊,因为DW在逻辑概念层有立方体度量和维的概念,但是在物理层具有和一般DB一样的物理模式。所以针对DW数据源定义的语义对象也是对数据表字段的封装,但是在生成过程中可以参考其逻辑模式自动生成。

·语义对象之间有层次关联的概念:即语义对象可以作为另一个语义对象的父对象或者子对象,而且这种父子关系具有传递性。如在多维数据库中维的不同层次的对象具有父子关系。前端工具中对子语义对象的操作必须同样施加于其所有的父对象,这样做是为了使生成的报表更加有实际应用意义。语义对象之间的关联性可以在使用语义对象设计器设计时指定,也可以不指定,保证了灵活性。

(2)语义对象设计

语义对象的设计人员首先使用语义对象生成器,根据普通数据库数据源(DB)的物理模式、数据仓库数据源(DW)的物理模式,或者OLAP立方体(CUBE)的物理模式中任一种自动或者手动定义语义对象(这个过程中就自动或者手动地添加了一层逻辑概念),并将定义好的语义对象的物理信息和逻辑信息存储在OLAP应用服务器中,也就是相应的语义对象文件。

语义对象的物理信息主要供OLAP应用服务器将OLAP原语转化为对具体数据源的查询语句时使用。OLAP前端工具获取存储的语义对象文件中语义对象的逻辑信息部分,将语义对象展现给OLAP前端工具用户并接受用户的操作而生成OLAP原语。其中,OLAP原语是前端工具跟OLAP服务器的数据借口,传递前端用户的数据请求信息。

(3)语义对象存储

语义对象存储文件不仅存储了分析主题和语义对象等逻辑概念信息,还要存储语义对象与后台DB,DW或者OLAP分析立方体的物理模式的对应关系等物理信息,因为这些信息在OLAP原语到具体查询语言的转化过程中将被使用。

语义对象存储文件可以从普通关系数据库(DB)、数据仓库(DW)或者多维立方体(CUBE)的物理模式生成,分以下三种情况:

①如果语义对象存储文件从DB物理模式得来,则只要连接DB数据源。

②如果语义对象存储文件从DW物理模式得来,则只要连接DW数据源。

③如果语义对象存储文件从OLAP立方体的物理模式得来,即存在实际CUBE立方体存储数据,则不但要能连接CUBE数据源,还要能连接CUBE数据源所对应的DW数据源。因为CUBE中保存数据的粒度比DW 中的大,对CUBE进行下钻操作时,所需粒度层次的数据的可能在CUBE中没有保存,而要下钻到DW中。

语义对象存储文件需要存储的信息列表如下:

·分析数据源的名称。

·语义对象存储文件从哪种情况生成。用来判断是情况①、②、③中的哪一种。

·物理数据源的名称和连接信息。

情况①、情况②时,需要记录DB或者DW的数据源名称和连接信息;情况③时,除了记录立方体数据源的名称和连接信息,还要记录DW数据源名称和连接信息。

·一个或者多个分析主题的信息,包括:

1)分析主题的名称。

2)情况①、情况②时,需要记录分析主题对应的DB或者DW的数据源名称;情况③时,除了分析主题对应的立方体数据源的名称,还要记录立方体对应的DW数据源名称。

3)情况③时,要记录分析主题对应的具体立方体的名称。

4)一个或者多个语义对象的信息:

·语义对象的名称。

·语义对象的简短说明。

·语义对象的类型:(both、banner、content)表示是作为报表工具中的标题显示还是内容显示或者两者都可以。OLAP立方体中的维层次封装的语义对象属性必须为banner,度量封装的属性必须为content,这样做是为了保证对多维数据库查询语句生成的正确性。

·是否是可计算语义对象。即转化为SQL语句时是否有计算函数。

·是否是带函数的语义对象。即转化为SQL语句时是否有其他函数。

·是否有直接父语义对象,有的话记录直接父语义对象的名称。

·是否有直接子语义对象,有的话记录其名称。

·语义对象所对应的SQL语句。情况①,情况②时,该SQL语句是语义对象对DB,DW中表字段的封装;情况③时,该SQL语句是语义对象所封装的维层次或者度量对其所对应的DW 中表字段的封装。

·情况③时,还要记录语义对象所封装的维层次和维层次对应的维的名称(对banner语义对象来讲)或者所封装的度量的名称(对content语义对象来讲)。

5)数据库表之间的连接信息。每两个表之间的连要关系定义为一个连接,这是为了OLAP应用服务器把OLAP原语转化为SQL查询语言时调用。

2.3 查询语言生成模块

当客户端向OLAP服务器发出请求,查询语言生成模块根据语义对象存储文件的相关信息,判断要连接哪种数据源,并生成相应数据源的查询语句,向相应数据源发出请求,获取相应数据后再把查询结果集返回给前端用户。

通过语义对象及查询语言生成模块的定义,成功地对用户屏蔽了后台各种数据源物理模式上的差异,充分体现了本系统的通用性及可扩展性。用户看到的只是自己熟悉的各种语义对象名称,并且在这些对象上可以进行方便的可视化操作,得到最终分析结果,而不必关心后台服务器的结构以及分析数据的获取。

  3 结 语

随着OLAP技术的发展,人们越来越追求OLAP系统的通用性和开放性,这也是OLAP技术发展的必然目标。本文提出的通用OLAP体系结构,可以集成多种类型的分析数据源,并支持多种OLAP前端工具,具有较好的灵活性和可扩展性,其在集成现有的商业智能系统的应用环境中前景更为广阔。

相关链接
QlikView助安吉天地汽车物流高效运营2010-04-08 BI让信息转化为能量2010-03-24
构建基于Web数据挖掘的信息服务系统2010-03-23 MySQL被并购 开源数据库将倒退十年2010-03-17
基于DW、OLAP和DM的商业智能2010-04-16 动态数据仓库设计与应用浅谈2010-03-16
面向商业OLAP的并行数据抽取接口设计2010-03-15 BI走下神坛 中小企业如何迎娶其过门?2010-04-27
Informatica第二季度营收1.173亿美元2010-03-06 借助商务智能提升经营分析能力2010-04-28
返回首页 信息化软件 企业管理 营销管理 业界消息 文档查询
Copyright © 2005-2010   http://www.ourdoc.cn, 知识文档中心