- 1、本文档共20页,可阅读全部内容。
- 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
- 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载。
- 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
Oracle数据库11g特性:数据仓库和OLAP
Oracle数据库11g面对DBA和开发人员的重要特性:数据仓库和OLAP
数据库驻留的按多维数据集组织的物化视图〔无需任何特别工具将OLAP多维数据集的强大功能同SQL的简洁性集成在一起〕、通过分区变化跟踪功能轻松识别刷、增的分析工作区治理器、扩展到子查询和远程表的查询重写以及很多其他特性使Oracle数据库成为更强有力的数据仓库平台。
按多维数据集组织的物化视图
联机分析处理〔OLAP〕概念自20世纪70年月以来始终很活泼,并在20世纪90年月中期开头成为主流,TedCodd在1992年制造了术语“OLAP”。由于有点浅显,大多数企业当时都不知道如何正确利用OLAP.
多年以后,该技术已格外完善,使得OLAP依靠大型数据仓库变得切实可行,从而真正将“智能”引入业务智能中。与传统关系设计截然不同,OLAP允许以最有效的方式存储和访问数据,即最终用户可以遍历具有很多维度的假定“多维数据集”的边缘。〔请参见下面的多维数据集数据例如〕。
多维数据集的维度与事实〔也称为“量度”〕相关联。用关系术语来讲,事实与维度之间具有多对一关系。例如,AcmeComputerSupplies可能有一个销售数据库。维度通常包括客户、产品和时间元素〔月份、季度等〕。在特定的时间段〔2023年8月〕内,特定产品〔Cat5e电缆〕与特定客户〔OracleCorp.〕之间对应的销售额是一个量度。维度和事实〔例如销售额〕都存储在单个表上。因此,用关系术语来讲,事实表是维度表的子表。
但是,这仅仅是一个比方而已。在关系设计中,将通过在事实表的customer、product或time列上创立的索引来访问量度。而在OLAP方法中,特定单元格
〔量度〕是通过遍历多维数据集进展访问的:本例如中的访问方法如下:先转至包含时间Aug08的局部,再转至产品Cat5e,最终转至客户Oracle.
Oracle像在数组〔而不是表〕中一样计算目的地,然后即可知道如何到达这些局部。例如,假定维度是按以下方式组织的:
DimensionTime:={”May”,”Jun”,”Jul”,”Aug”}
DimensionTime:={”May”,”Jun”,”Jul”,”Aug”}
DimensionCustomer:={”Microsoft”,”IBM”,”Oracle”,”HP”}DimensionProduct:={”Fiber”,”Cat6e”,”Cat5e”,”Serial”}
为了找到Oracle+Aug+Cat5e量度,OLAP引擎将按如下方式执行导航:
1、Aug08是Time数组的第四个元素,因此沿着多维数据集的时间维度转至第四个单元格。
2、Cat5e是Product数组的第三个元素,因此转至第三个元素。
3、Oracle是Customer数组的第三个元素,因此转至第三个元素。
就是这样!现在您已经找到了所需的量度。由于维度值充当数组指针,因此在执行此操作时不必使用索引。同样,假设您要计算2023年8月份全部客户
的销售总额,可以执行同样的操作,只是在第3步中将数组各元素的量度加起来,而不是转至特定单元格。
以传统星型模式存储的纯关系形式数据的关系访问与上述方法不同,如下所示。
在关系数据库方法中,您必需将此“事实”表与全部维度联接。每次需要数据时,都需要从事实表中选择适宜的数据〔可能要通过索引〕,然后将其与全部维度逐个联接起来〔再次通过索引〕。虽然此方法在技术上是可行的,但在大型数据库中完全行不通。
作为替代方法,能否为全部这些选项创立物化视图〔MV〕呢?用户可以使用维度元素的任意组合:
8月份针对全部客户的Cat5e销售额
8月份针对Oracle的串行电缆销售额与IBM销售额〔针对同一产品和月份〕的百分
比
针对HP的光缆销售额与针对Microsoft的串行电缆销售额的百分比
等等。但是,需要创立多少个MV呢?理论上讲,应当为每个组合创立一个MV〔4x4x4=64MV〕。除了空间,您还需要足够的时间和数据库资源,以便在数据发生变化时刷MV,可能会涉及数千个元素。这样,要创立和治理的MV的数量
将变得相当浩大。
相反,多维数据集是单个段,却可以同样轻松地处理任意类型的查询。虽然二者都可用于旨在加快汇总数据〔与OLTP数据不同〕处理速度的数据仓库设计中,却存在着巨大的根本区分:MV存储预先计算的结果以避开联接和聚合,而多维数据集存储原始数据并即时计算大多数汇总数据。〔需要强调的是“
文档评论(0)