OLAP开发指南.docx
- 文档编号:6687001
- 上传时间:2023-01-09
- 格式:DOCX
- 页数:16
- 大小:213.63KB
OLAP开发指南.docx
《OLAP开发指南.docx》由会员分享,可在线阅读,更多相关《OLAP开发指南.docx(16页珍藏版)》请在冰豆网上搜索。
OLAP开发指南
OLAP开发指南
介绍
OLAP(Onlineanalyticalprocessing:
联机分析处理)是一个日益普及的技术,它可以显著地改善商业分析,但历史上它却具有价格昂贵、难于实现,且不能进行灵活部署的特征。
微软公司解决了OLAP问题,并创建了一个解决方案。
该解决方案可以使得更加广泛的观众都可以获得多维分析,并且是在成本明显更低的水平上获得的。
Microsoft®SQLServer™OLAP服务(OLAPServices)完全具有OLAP功能的特征,是MicrosoftSQLServer7.0的一个组件。
OLAP服务包括一个中间层(middle-tier)服务器,利用其杰出的性能,允许用户对大量的数据进行复杂的分析。
OLAP服务的另外一个特性是客户端高速缓存和计算引擎,称为MicrosoftPivotTable®Service(微软数据透视表服务),它帮助提高性能和降低网络流量。
数据透视表服务允许用户在企业网络断开时进行分析。
OLAP是数据仓储过程中的一个关键组件,并且OLAP服务为广泛范围内的应用提供了重要的功能,这些应用范围从企业报表到高级决策支持。
在SQLServer中包含OLAP功能将有助于客户更能承受多维分析,并且可以将OLAP的好处带给更广泛的用户,这些用户不仅包括更小的组织机构,还包括在大型公司中的团体和个人,由于当今产品的费用和复杂性,他们已经被排除在OLAP行业以外了。
OLAP服务通过MicrosoftOLEDBforOLAP接口与种类广泛的工具和支持OLAP的应用软件结合在了一起,它将增加对复杂分析工具的访问,并可以降低数据仓储的费用。
OLAP系统的基本原理
在历史上,企业计算中的大量投资都是投在生成或捕获数据的系统中,如记帐、定单处理、制造和客户信息等。
组织正在越来越多地在应用和技术方面投资,这些应用和技术可以从这些搜集的数据中体现出额外的价值。
数据仓储是这样的过程:
从各种操作系统中搜集、净化(cleaning)和筛选数据,并使广泛的最终用户可以访问这些合成的信息以进行分析和生成报表。
数据仓库(datawarehouse)和数据市场(datamart)都可以用来描述这些经过净化和汇总的非易失性数据仓库,用户都可以进行浏览。
微软数据仓储策略
几年前,对于商界中的扩展数据仓储和决策支持可用性的总体目标,微软公司采取了两个主动行动。
这两个主动行动是:
MicrosoftDataWarehousingFramework(微软数据仓储框架),它是微软产品开发的路标;MicrosoftAllianceforDataWarehousing(微软数据仓储联盟),它是约定将微软平台和数据仓储框架用于开发和市场目的的一个工商业界的联合。
这些主动行动是基于微软的中心策略的,它在以下方面对数据仓储做出了贡献:
∙降低了获取、实现和维护的费用
∙重新定义了可伸缩性,不仅是为大型系统提供服务,还要为个人用户提供服务。
∙有越来越多的第三方销售商提供的集成工具。
微软数据仓储框架(MicrosoftDataWarehousingFramework)
数据仓储框架是一个开放的体系结构,它描述了在数据仓库和数据市场的构建和管理中,共享数据和元数据的机制。
在数据仓储框架中的基本技术是OLEDB数据接口和运行SQLServer的MicrosoftRepository实例。
MicrosoftRepository是一个保存有关于软件组件和它们之间关系(元数据)的描述性的信息的数据库。
在用于数据库模式、数据转换和OLAP数据库模式的MicrosoftRepository中已经定义了元数据模型。
数据仓储框架组件代表了在数据仓储过程中的完整的步骤,其中某些是由微软公司发表的,但是微软客户和使用选择性技术的第三方商业界可以很容易地对其进行扩展。
SQLServer7.0将提供创建和维护一个数据仓库所需的许多基本组件:
利用图形化模式设计器进行数据库设计;通过数据转换服务(DataTransformationServices:
DTS)实现数据转换功能;通过OLAP服务实现OLAP功能等等。
datawrhs.bmp
要了解关于微软数据仓储框架的更多信息,请参看“MicrosoftSQLServer7.0DataWarehousingFramework(MicrosoftSQLServer7.0Data数据仓储框架)”(产品编号098-80704).
数据复杂性
尽管数据仓储过程为最终用户的使用准备数据,但是在关系数据仓库中,大部分信息是不容易进行浏览的。
对于最终用户来说,数据结构经常是很难理解的,或问题(如,“在去年中,按月来说在每个地区谁的销售额最高?
”)在SQL中表达时是很复杂的。
有些挑战性问题可以利用高级查询工具解决,它们向最终用户隐藏了数据库的复杂性。
然而,对于最终用户浏览多维数据的大量应用来说,微软相信最佳解决方案是OLAP技术。
所有的组织都拥有多维数据,复杂性并不一定是公司大小的函数。
甚至最小的组织也希望按产品、销售人员、地理分布、客户和时间来跟踪销售情况。
组织一直在寻找一种工具,以便可以以一种轻松自然的方式获取、操纵和分析多维数据。
OLAP不是一个新的概念,但仅是最近才将OLAP这一名称赋给这种技术的。
在1993年,E.F.Codd博士,数据库研究员和关系型数据库模型的发明者在他的白皮书“ProvidingOLAPtoUserAnalysis:
AnITMandate,”中提出了这个术语,在这个白皮书中,他设计了12条规则,定义了OLAP应用的特征。
后来,NigelPendse和RichardCreeth的OLAP报告()利用所谓的FASMI测试精炼了他的定义。
该报告指出,OLAP应当提交对共享的多维信息的快速分析,含义是:
快速
以相当固定的速度向用户提交信息。
大多数查询应当在5秒或更短时间内提交给用户。
分析
执行对数据的基本数字和统计分析,这是由应用程序开发人员预定义或由用户特别定义的。
共享的
在大量用户间,实现潜在地共享秘密数据所必需的安全性需求。
多维
是OLAP的基本特征
信息
访问应用程序必需的、相关的所有数据和信息,而不管它驻留在何处,并不受卷的限制。
对组织的价值
OLAP提供给组织一种高灵活性、高性能地存取、浏览和分析数据的手段。
首先,OLAP通过一种自然的、直觉的数据模型将数据展示给最终用户。
利用这种可操纵方式,最终用户可以更有效地浏览和理解他们的数据仓库中的信息,这样就使得组织可以更好地认识他们的数据的价值。
第二,通过在数据中准备一些事先计算的,而不是在执行时加入的数值,OLAP加快了向浏览这些多维结构的最终用户提交信息的速度。
与可能只采用关系型数据库技术相比,轻松导航和快速执行的结合使得最终用户可以更快、更高效地浏览和分析数据。
最终结果是,可以花费更多的时间分析数据,而分析数据库上花费的时间更少。
OLAP术语和概念
定义和阐明在OLAP的讨论中常用的术语和概念是很重要的。
OLAP数据模型
在一个OLAP数据模型中,信息可以在概念上被视为一个立方体,它由描述的种类(维)和定值(量度)组成。
对于用户来说,多维数据模型使得设计复杂的查询、在报表上安排数据、从汇总转向细节性数据、将数据过滤或分割为有意义的子集变得简单了。
例如,在包含销售信息的立方体中,典型的维将包括时间、地理分布、产品、渠道、组织和说明(预算和实际数目)。
典型的量度包括美元销售额、单位销售额、存货、职员总数、收入和开支等。
.
在OLAP实际模型的每一维内,数据可以被组织到一个层次中,该层次描述了数据上的细节的层次。
例如,在时间维内,你可能有年、月和日层次;同样地,在地理维内,你可能有国家、州/省和城市层次。
一个OLAP时间模型的特殊实例在层次中的每个层都有确定的值。
一个浏览OLA数据的用户可以在层次间上升或下降来浏览更详细或更粗略的信息。
总和及存储模型
立方体、维、层次和量度是OLAP多维导航的实质。
通过以这种方式描述和介绍数据,用户可以直观地操纵一个复杂的数据集。
然而,仅仅以一种更直觉的表示方法来描述数据模型,对于要将信息更快地提交给用户的帮助是很小的。
OLAP的一个关键原则是,对于用户所需的每个数据视图或切片(slice),应当有一致的响应时间。
由于数据通常只是在细节层次上收集的,所以信息汇总通常是事先计算出来的。
这些预先计算出的值或总和(aggregations)是OLAP性能增强的基础。
在OLAP技术的早期,多数销售商假定OLAP应用的唯一可能的解决方案是一种专用的、非关系存储模型。
后来,其他销售商发现,通过数据库结构、索引和总和存储的使用,关系型数据库管理系统(RDBMS)可以用于OLAP。
这些销售商称这项技术为关系型OLAP(RelationalOLAP:
ROLAP)。
那些早期的OLAP销售商当时采用了多维OLAP(DimensionalOLAP:
MOLAP)这一术语。
通常,MOLAP实现的性能超过了ROLAP技术,但是存在可伸缩性方面的问题。
另一方面,ROLAP实现的可伸缩性更强,对于客户常常更具吸引力,因为他们可以充分利用在现有的关系型数据库技术方面的投资。
近来的开发采用的是一个混合的OLAP解决方案(hybridOLAP:
HOLAP),它将ROLAP和MOLAP体系结构结合在一起,形成了一个同时具有高性能和广泛可伸缩性这两个最好特性的解决方案。
一种采用HOLAP的方法是:
在一个单独的MOLAP仓库中保持总和的同时,在关系型数据库中保持细节记录(最大卷)。
OLAP服务体系结构
MicrosoftSQLServerOLAP服务(OLAPServices)是在帮助最小化最重要的、创建和维护OLAP应用的拥有成本的基础上设计的。
OLAP服务由服务器和客户端(中间层:
MiddleTier)软件组件组成。
dssarch.bmp
在服务器端,OLAP服务分析(OLAPServicesAnalysis)服务器作为MicrosoftWindowsNT®服务来进行运作,并提供核心的计算功能。
在分析(Analysis)服务器中,对管理功能的编程访问是通过称为决策支持模型(DecisionSupportObjects:
DSO)的对象模型来实现的,该对象模型是由微软OLAP管理器(Microsoft.OLAPManager)证明了的。
微软OLAP管理器是一个用于OLAP服务的内置的管理用户界面,它也是在DSO的基础上开发的,且提供了丰富的用户经验而无需编程。
OLAP管理器(OLAPManager)可以在一台独立于分析服务器的计算机上执行,它允许数据库管理员设计OLAP数据模型、存取RDBMS仓库中的信息、设计总和,以及给OLAP数据仓库装入数据等等。
OLAP元数据定义被存储在专用库(privaterepository)中,但是使用一个简单的实用工具,OLAP元数据可以导入到采用OLAP开放信息模型(OpenInformationModel:
OIM)的MicrosoftRepository中。
OLAP服务可以存取任何被支持的OLEDB数据提供者中的源数据,不仅包括SQLServer,而且还包括大量桌面和服务器数据库(包括MicrosoftAccess,MicrosoftFoxPro®,Oracle,Sybase和Informix)。
通过OLEDB中的工具软件,可以访问任何提供开放式数据库连接(OpenDatabaseConnectivity:
ODBC)接口的数据库源。
该工具将ODBC驱动程序打包,使它们就象是本地的OLEDB接口一样。
这些数据源可以驻留在除WindowsNT操作系统以外的平台上,如UNIX或大型机系统,和诸如IBMDB2或Teradata的数据库等。
通过OLEDB的多平台性能,可以从多种系统中存取数据,就好象是在提供OLAP服务的服务器本地进行存取一样。
在客户端,OLAP服务包含一个称为微软数据透视表服务(MicrosoftPivotTableService)的组件。
数据透视表服务是将OLAP客户端应用连接到提供OLAP服务的服务器上的一个工具。
所有对OLAP服务管理的数据,定制程序或客户端工具管理的数据的存取,是通过数据透视表服务提供的OLEDbforOLAP接口实现的。
OLAP服务的客户端和服务器组件在功能性方面都是可扩展的。
利用DSO中记录完全的特性,客户站点、独立软件销售商和顾问都可以扩展计算、数据管理,或应用功能。
利用这种内置的可扩展性,客户可以确信:
OLAP服务将具有解决他们的应用需求所必需的功能。
实现OLAP的挑战
OLAP的实现提出了几个必须要克服的挑战性问题。
创建OLAP数据模型
OLAP实现的一个重要的挑战是将最初的数据库模式映射为多维模型。
这需要利用当今市场上许多产品的重要程序设计成果。
在OLAP产品的演进过程当中,OLAP数据库的设计已经成为了一项专门的、神秘的过程,被杂乱地联接到了所配置的特殊的OLAP技术上。
因此,OLAP数据库开发人员是非常专业的,这就导致了开发应用中费用很高,且使得费用集中在数据设计阶段。
在大多数的OLAP实现中,假定通过利用数据仓储,用于分析的数据已经准备好了,由此在信息合并到OLAP应用中之前,已经从操作系统中析取出来,经过了净化、验证和汇总。
在过程中,这是一个至关重要的步骤,它确保了OLAP用户正在浏览的数据是正确的、一致的,与组织对数据的定义相匹配。
数据仓库中的信息越来越多地以一种星型或雪片模式被组织起来,这就简化了用户对数据的理解,最大化了用于决策支持应用的数据库查询性能,并且对于大型数据库需要较少的仓储空间。
下面的插图是星型模式的一个例子。
在这种数据库模式中,一个中心的项目表被链接到了相关的元表中。
星型和雪片模式是OLAP数据模型的关系近似,可以作为创建OLAP立方体定义的良好出发点。
然而,很少有OLAP产品利用这种趋势。
它们通常不提供简易的工具来将星型模式映射为OLAP模型,这样的结果是使得创建OLAP模型的费用非常高,且开发时间过长。
直观的用户界面
OLAP服务中一个重要的不同是OLAP管理器(OLAPManager)的用户界面,它是特意为那些人数很少的OLAP数据库管理员创建的。
OLAP管理器是作为到微软管理控制台(MicrosoftManagementConsole:
MMC)的一个咬接部件交付的,与MicrosoftBackOffice®家族一样,它共享同一个管理用户界面。
这样做的明显好处是:
OLAP数据库管理员可以更好地将SQLServer技术转化为其他微软产品的技术。
在用户理解了MMC的强大功能和灵活性时,更多的价值变得显而易见。
OLAP服务包括完整的任务填充(taskpad),它指导新手或不经常使用的用户完成普通任务。
包含在OLAP服务中的有关于OLAP概念的完整的自学材料和创建一个OLAP立方体的按部就班的指导。
详尽的向导可以用于自动处理那些最普通的活动,如创建一个维度定义等。
此外,OLAP服务进行了优化,用于已经设计了星型或雪片模式的设计仓库的开发场合。
立方体创建向导(CubeCreationWizard)尤其适合这些预创建模式,并且到多维模型的转换是非常迅速的。
OLAP服务可以很容易地适合其他可能遇到源模式。
为了确保成功地解释OLAP服务用户界面概念,微软实验室进行了很多可用性测试。
最后,大型beta测试已经向OLAP服务提供了广泛的曝光和客户输入。
作为对数据库管理员的需求进行投入的结果,大多数用户可以在30分钟内创建他们的第一个立方体。
利用总和来管理数据爆炸(DataExplosion)
正如以前指出的那样,预先计算总和(precomputingaggregations)是大多数OLAP产品的一个关键的性能策略。
然而,预先总和(preaggregation)的费用巨大:
总和的数目非常容易超过初始细节点的数目,并且存储的数据量也显著膨胀。
在OLAP模型中的总和的数目是维数、分层中的层数和母子比率(parent-childratio)的函数。
要理解更多信息,请参阅站点的OLAP报告(OLAPReport)分析。
现实世界中,这种数据爆炸的影响大量存在。
一个最近公布的对另一OLAP产品的基准测试的数据爆炸因子为240,需要2.4GB的存储空间来管理10M的输入数据。
提供适当的磁盘存储空间来处理数据的巨大膨胀,是大型OLAP实现的有效的代价,并且它形成了对组织想得到的对所有源层次上的数据进行分析的能力的限制。
由于数据爆炸,当源或细节性数据极少地分布在多维立方体中时,OLAP应用的品质可能会降低更多。
丢失的或无效的数据值在OLAP数据模型中会引起稀疏性(sparsity)。
在最坏情况下,一个OLAP产品仍然保存空值。
例如,一个公司可能并未在所有地区销售所有产品,这样在没有销售产品的某一特定地区的交叉点处,将没有数值出现。
对于那些已经在不同程度上取得成功的OLAP销售商来说,数据稀疏性是一个挑战。
最坏的实现情况将导致数据库存储空值,这样就使得密度较低,浪费空间和资源。
OLAP服务并不存储空值,这样的结果是:
甚至是数据稀少的立方体在大小上也不会象气球一样变大。
虽然这个问题常常被某些OLAP销售商强调为OLAP体系结构中的决定因子,但是与预先计算太多的总和所引起的更大的数据爆炸相比,销售商稀疏性管理的实现间的区别是很小的。
灵活的存储选择
微软公司相信,OLAP服务在提供灵活的解决方案方面领导着市场,这种解决方案允许OLAP数据库管理员决定哪一种存储模型是最适当的。
OLAP服务支持完全MOLAP实现、完全的ROLAP实现或HOLAP解决方案。
例如,一个数据库管理员可能选择将经常存取的数据放置在MOLAP中,将有更多可伸缩性问题的历史数据放置在ROLAP中。
然而,下面的数据模型对于客户应用来说是完全不可见的,且用户只能感觉到立方体的存在。
无论一个人选择实现MOLAP,ROLAP,还是HOLAP数据模型,微软认为,使用关系型数据库的OLAP服务的集成是出众的。
通过将图形化用户界面设计工具和向导直接捆绑到OLEDB,OLAP服务保留了在源数据-OLAP多维元数据和总和间的强大的链接。
在实现ROLAP数据模型时,OLAP服务定义、安置和保留了所有的关系型数据库结构。
这就将开发人员从执行这些任务中,或更坏的情况——必须管理多个表和服务器间的复杂查询——中间解脱出来。
智能型预先求和功能
OLAP服务同时将OLAP技术的基本问题(过多的预先求和导致数据爆炸)减到了最小。
正如前面描述的那样,OLAP数据爆炸是多维预先求和的结果。
在传统的OLAP系统中,如果不是在运行时计算,经过预先求和的数据不能用于生成报表和分析的目的。
通过预先计算及存储所有可能的总和组合(例如,所有时间段、所有组织、所有的分配渠道间的所有产品和层次的总和等等),传统的OLAP产品将导致巨大的数据爆炸。
与计算所有可能的总和方法相比,OLAP服务确定哪些总和提供最大的性能改进,并且通过数据存储和总和向导(DataStorageandAggregationWizard),使得OLAP数据库管理员可以在系统速度和管理总和所需的磁盘空间之间作出平衡。
如果开发人员要预先计算出所有的总和,磁盘空间需求将最大化(从而导致数据爆炸综合症)。
另一方面,如果开发人员不做任何预先计算,磁盘需求将为0,但性能将不会有所改进。
在大多数情况下,如果没有过多的总和预先计算,OLAP服务在查询性能方面大约可以获得80%的改进(数据的指数增长总是发生在最后的20%总和期间)。
OLAP服务对OLAP元数据模型进行分析,试探性地确定最佳的总和集合,所有的其他总和都可以从这个集合中得出。
结果是:
OLAP服务从几个现有的集合数值中得出未总和的数据,而不用扫描整个数据仓库。
然而,这种部分预先求和策略仅是出发点而已。
尽管OLAP服务的探索是很出色的,但它们是建立在数学模型基础上的,这个数学模型能够或不能够适合实际的使用模式。
为了按照实际的使用模式来优化性能,OLAP服务可有选择地将发送到服务器的查询记入日志。
然后这些日志可以用来调整OLAP服务保留的总和集合。
例如,基于使用的优化向导(Usage-BasedOptimizationWizard)使得数据库管理员可以告诉OLAP服务,为那些需要多于n秒时间响应的查询创建一个新的总和集(n可能是10秒或更多)。
在许多组织中,与磁盘空间相比,人们更关心处理时间。
一个人可以总是购买过多的磁盘空间,但是如果需要一天来处理相当于一天的新数据,那实在是没有更多的时间可购买了。
然而,数据爆炸的OLAP服务解决方案减少了处理初始负载和增加的更新的时间,同时将所需的磁盘空间减到了最小。
如果一个应用开始有10GB的数据仓库,并产生了10GB的总和,那么所需的处理时间只是处理完全分解的总和集合所需时间的一部分。
OLAP服务也采取了一种创新的方法来解决数据稀疏性问题。
虽然内部实现的细节是专有的,但是最终结果是MOLAP和ROLAP的实现可以很好地管理存储空间的需求,通常的结果是:
与最早的细节性数据相比,数据库需要的OLAP存储空间较少。
无论在何时,用户希望从两个相异的、共享关联几个公共维的立方体中都可以使用可视化立方体(Virtualcubes)浏览信息。
在概念上与关系型视图相似,可视化立方体是在运行时按照一个或更多公共的元链接起来的两个或更多个立方体。
可视化立方体的一个好处是,可以在数据稀疏性十分重要的情况中应用。
例如,一个包含按单位和销售价格计算销售额的立方体也可以使用价格表方法来计算折扣,但是价格表数值可以多次重复。
在可视化立方体中,通过创建一个价格表立方体与销售立方体通过单位和销售价格信息连接起来,数据库管理员可以去除大量的数据冗余。
创建可视化立方体的能力意味着:
许多不是必需的数值完全可以从OLAP数据存储中去除。
性能和可伸缩性
OLAP应用的专门性能规律(metric)是几个因素的函数,这些因素包括数据库大小、硬件计算能力和可分配给预先求和数据的磁盘空间。
然而,在实际的实现中,基于OLAP服务的应用在少于5秒的时间内对大多数查询作出响应,并且几乎可以在10秒内对所有的查询作出响应。
OLAP服务的分区立方体(partitionedcubes)的实现使得该技术的可伸缩性很强。
一个分区的立方体使得一个数据的逻辑立方体可以在多个物理立方体之间,甚至是分离的物理服务器间传播。
在对用户查询的响应中,OLAP服务在分区的服务器间分配查询,使得平行地检索数据成为可能。
例如,考虑跟踪地理上的10个地区电话的应用情况,在这种情况下,每个区每天可以有几百万个电话。
出于分析的目的,每个应用可以在10个服务器间分割数据,每个服务器包含某个特定地区的数据。
然而,从用户的角度观察,只有一个逻辑的数据立方体。
在对这些信息的用户需求的响应中,OLAP服务将查询无缝地转换为适合10个服务器中每个服务器的查询,并将单一的结果集返回给用户。
对于查找个别地区信息的分析员来说,同样可以单独访问10个数据库中的每个数据库。
微软公司相信,OLAP服务在多个服务器间高效地管理分区数据的能力将使得该项技术的可伸缩性比许多竞争产品的可伸缩性都要更好。
向用户提交OLAP信息
历史上,OLAP服务器技术已经紧紧地与专有客户端技术相联系,这意味着客户在他们
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- OLAP 开发 指南
![提示](https://static.bdocx.com/images/bang_tan.gif)