[转帖]基于ODS构建商业系统的即时OLAP应用_MQ, Tuxedo及OLTP讨论区_Weblogic技术|Tuxedo技术|中间件技术|Oracle论坛|JAVA论坛|Linux/Unix技术|hadoop论坛_联动北方技术论坛  
网站首页 | 关于我们 | 服务中心 | 经验交流 | 公司荣誉 | 成功案例 | 合作伙伴 | 联系我们 |
联动北方-国内领先的云技术服务提供商
»  游客             当前位置:  论坛首页 »  自由讨论区 »  MQ, Tuxedo及OLTP讨论区 »
总帖数
1
每页帖数
101/1页1
返回列表
0
发起投票  发起投票 发新帖子
查看: 3886 | 回复: 0   主题: [转帖]基于ODS构建商业系统的即时OLAP应用        下一篇 
赖文婷
注册用户
等级:少校
经验:1094
发帖:81
精华:0
注册:2012-11-5
状态:离线
发送短消息息给赖文婷 加好友    发送短消息息给赖文婷 发消息
发表于: IP:您无权察看 2012-11-15 9:35:11 | [全部帖] [楼主帖] 楼主

摘要:基于DB和DW的中间层ODS的数据存储技术,从应用的角度分析设计了一个商业系统的即时OLAP系统。通过使用ODS克服了利用DW进行决策过于臃肿且不适合企业即时的中层决策的问题。

    关键词:数据仓库(DW),操作数据存储(ODS),即时联机分析处理(OLAP)

    1.问题提出

    面向主题的数据仓库(DW)概念的提出,不但为有效地支持企业经营管理决策提供了一个全局一致的数据环境,也为历史数据,综合数据的处理提出了一种行之有效的解决方法。数据仓库概念的提出也清楚的把数据处理划分为了操作型处理和分析型处理两种不同类型,从而建立起了 DB-DW的两层体系结构。但是有很多情况,DB-DW的两层体系结构并不能涵盖企业所有的数据处理要求,因为企业的数据处理虽然可以较为粗略的划分成操作型和分析型两部分,但这两种类型也不是泾渭分明的,它们之间也有交叉的情况,譬如,有些是操作型的,但不适合在操作型DB中进行,而又有一些是分析型处理,但不适合在DW中进行。

    比如我们开发的一个医药销售公司的决策系统,按要求公司经理要解决什么商品该进货了,各种商品近来的赢利情况,客户的信任情况等等。要回答这些问题,他必须首先要弄清楚药品的存货是否充裕,还要了解该药品近期的销售情况,另外还要和别的药品的库存和销售情况进行比较等。如果我们把这个决策分析过程放在原有的面向应用的分散DB系统中去完成的话,不一定得到每个部门的准确一致的信息,而要进行各部门间的协调配合,工作量势必会很大,但如果把其放在DW中去进行分析的话,不但费时,而且会有很多的不必要的数据检索存在。

    对于上述问题可以借助于DB-DW的中间层ODS(操作数据存储)来解决。它象DW一样是一种面向主题,集成的数据环境,又象操作型DB一样包含着全局一致的,细节的当前的数据。建立基于ODS的即时OLAP应用是应中层决策分析之需要的一种解决方案,它能很好的适应企业日常频繁的中低层次的决策分析应用。

    2.ODS技术和即时OLAP

    2.1 操作数据存储(ODS)

    是用于支持企业日常的全局应用的数据集合,ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。ODS是介于DB和DW之间的一种数据存储技术,和原来面向应用的分散的DB相比,ODS中的数据组织方式和数据仓库(DW)一样也是面向主题的和集成的,所以对进入ODS的数据也象进入数据仓库的数据一样进行转化和集成处理。另外ODS只是存放当前或接近当前的数据,如果需要的话还可以对 ODS中的数据进行增、删和更新等操作,虽然DW中的数据也是面向主题和集成的,但这些数据一般不进行修改,所以ODS和DW的区别主要体现数据的可变性和当前性上。

    2.2 即时OLAP

    ODS主要是适应企业级的全局应用的需要而产生的,对它的应用主要是在即时"OLAP"的数据处理上。

    我们在DW上实现OLAP主要是为了进行长期趋势分析,DW中是数据量很大,所以OLAP应用的运行时间都比较长。在企业日常经营中,常常要进行一些非战略的中层决策以实现企业的日常管理和控制,譬如,医药销售公司经理要每周查看药品的销售情况,各地区的药品销售情况,业务员的业绩情况等等,并且这种决策过程并不需要参考太多的历史数据,主要是参考当前的或比较当前的数据,还需要比较快的执行速度,可以把这种分析决策称为"即时OLAP"。显然利用DW不但运行的效率是无法让人忍受而且也很难准确的反映近期的真实情况,ODS的建立克服了DW系统过于臃肿,处理时间过长和不适应即时OLAP的情况,提供给中层决策者以快捷准确的分析信息。

    2.3 从DB向ODS转化的实现机制

    在DB-ODS的体系结构中,ODS的实现机制表现在其记录系统定义的数据传送关系上,如图1所示。操作型环境中各分散的DB记录经过过滤后形成了ODS系统的记录系统,向ODS系统中提供数据。记录系统定义了原有分散DB中那些数据送往ODS,并指明与ODS数据相应的数据表。通过ODS的定义可以把分散于应用的DB中的数据复制到ODS中去,这样原来的分散DB中的记录就形成了ODS中的面向主题的记录。ODS维护着一个分析型的环境,数据处理简单得多,实际需要的支持技术也很少。

    没有给出从ODS向DB转化的实现机制,这种情况主要用在有关企业全局操作应用的情况,可以通过在 ODS系统中存放一些参数表,它所反应的关系是ODS全局更新时必须要反应到所有DB中的相关记录。此时,ODS是一个操作型环境,实现ODS所要求的技术跟原来的面向应用的分散的数据库系统一样,包括事务管理、封锁管理、数据恢复等等技术。

    3 基于ODS的药品销售即时OLAP应用的设计

    我们知道ODS是介于DB和DW之间的一种新的数据存储技术,它兼有DW和DB的特点,在开发即时OLAP系统时,其开发方式更接近DW的开发模式。

    3.1 建立ODS

    该药品销售公司原本的一个销售数据库管理系统数据库结构,是分布在

ACCESS97数据库中,分属于财务,销售和库存等几个数据库中。

    根据前面的分析,优先选择销售区域,客户和药品三个在销售领域最关切的的主题,把事务数据库中涉及到此领域的数据转入到ODS中。ODS(主要对照DW)逻辑模型的类别主要有星形模型,雪花模型和混合模型等三种,我们在开发ODS逻辑模型时用了星形模型。一个简单的星形模型由一个事实表和若干个维表组成,而复杂的的星形模型可能包括数百个维表。星形模型从支持商务决策的角度定义了数据实体,它能客观在实体中反映商务运行的规则和属性,与后两种模型相比,设计相对简单,更容易被用户所理解和接受。

    定义记录系统时,主要考虑如何将主题域的各个属性分配到应用系统中去,这里主要考虑把各主题中的属性分配到药品销售的操作环境中的销售和库存等子系统中。

    3.2 数据采集

     数据采集过程跨越分散DB操作环境和ODS分析环境。本系统中数据采集过程较为简单,只需要按照ODS记录系统和ODS记录系统定义两者之间的映射关系,将DB中的数据传送到ODS,这里我们采用了SQL SERVER 7.0的DTS数据转换服务,SQL SERVER 7.0的DTS(Data Transformation Services)提供了数据的提取,转换和装载的功能。利用SQL SERVER 7。0的输入输出向导创建DTS包,在复制时使用SNAPSHOT(快照类型)对ODS中的数据进行清除和重建,由于数据量不是很大,故可以取得很好的执行效率。

    3.3 系统用户界面的实现

    最终用户界面利用DELPHI 5.X来实现,这里有几个有利的地方,DELPHI提供了一组决策支持元件,用于对数据进行全方位多层次的分析。这些决策支持元件包括:

    .TDecisionCube 这是以个多维数据仓库。

    .TDecisionQuery 类似于TQuery,用于与数据库的连接。

    .TDecisionSource 类似于TDatasource,可以为数据透视表,栅格,图表等元件提供数据源连接。

    .TDecisionPivot 用于对栅格的形式显示多维的数据。

    .TDecisionGraph 以图表的形式显示数据,可以按照不同的字段重新组织图表。

    通过把所建的ODS数据表通过连接导入到数据仓库元件(TDecisionCube)中,即可利用其他的决策元件来实现多维栅格和图表的显示,给用户提供一个直观,明了的分析界面。

    4.结束语

    ODS技术的引入和应用,为企业在日常经营中进行即时OLAP提供了一种解决方案使得企业无须建立一个"臃肿"的DW,就可以进行一些非战略性的的中层决策,来实现对企业的日常管理和控制,同时也能获得较快的响应速度。

    同时,企业在构建DW时,可以考虑DB-ODS-DW的三层模式来开发DW,进而更进一步的开发具有全局应用的高层OLAP决策系统,以实现企业的总体决策和即时决策相互补充。




赞(0)    操作        顶端 
总帖数
1
每页帖数
101/1页1
返回列表
发新帖子
请输入验证码: 点击刷新验证码
您需要登录后才可以回帖 登录 | 注册
技术讨论