《Orace数据库11g新特性.docVIP

  1. 1、本文档共20页,可阅读全部内容。
  2. 2、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
《Orace数据库11g新特性

Oracle数据库11g新特性:数据仓库和OLAP Oracle数据库11g面向DBA和开发人员的重要新特性:数据仓库和OLAP ??? 数据库驻留的按多维数据集组织的物化视图(无需任何特殊工具将 OLAP 多维数据集的强大功能同 SQL 的简单性集成在一起)、通过分区变化跟踪功能轻松识别刷新、新增的分析工作区管理器、扩展到子查询和远程表的查询重写以及许多其他新特性使 Oracle 数据库成为更强有力的数据仓库平台。 ??? 按多维数据集组织的物化视图 ??? 联机分析处理 (OLAP) 概念自 20 世纪 70 年代以来一直很活跃,并在 20 世纪 90 年代中期开始成为主流,Ted Codd 在 1992 年创造了术语“OLAP”。由于有点深奥,大多数企业当时都不知道如何正确利用 OLAP. ??? 多年以后,该技术已十分完善,使得 OLAP 依靠大型数据仓库变得切实可行,从而真正将“智能”引入业务智能中。与传统关系设计截然不同,OLAP 允许以最有效的方式存储和访问数据,即最终用户可以遍历具有许多维度的假定“多维数据集”的边缘。(请参见下面的多维数据集数据示例)。 ? 多维数据集的维度与事实(也称为“量度”)相关联。用关系术语来讲,事实与维度之间具有多对一关系。例如,Acme Computer Supplies 可能有一个销售数据库。维度通常包括客户、产品和时间元素(月份、季度等)。在特定的时间段(2008 年 8 月)内,特定产品(Cat5e 电缆)与特定客户 (Oracle Corp.) 之间对应的销售额是一个量度。维度和事实(例如销售额)都存储在单个表上。因此,用关系术语来讲,事实表是维度表的子表。 ??? 但是,这仅仅是一个比喻而已。在关系设计中,将通过在事实表的 customer、product 或 time 列上创建的索引来访问量度。而在 OLAP 方法中,特定单元格(量度)是通过遍历多维数据集进行访问的:本示例中的访问方法如下:先转至包含时间 Aug 08 的部分,再转至产品 Cat5e,最后转至客户 Oracle. ??? Oracle 像在数组(而不是表)中一样计算目的地,然后即可知道如何到达这些部分。例如,假定维度是按以下方式组织的: Dimension Time := {May,Jun,Jul,Aug} Dimension Customer := {Microsoft,IBM,Oracle,HP} Dimension Product := {Fiber,Cat6e,Cat5e,Serial} ??? 为了找到 Oracle + Aug + Cat5e 量度,OLAP 引擎将按如下方式执行导航: ??? 1、Aug 08 是 Time 数组的第四个元素,因此沿着多维数据集的时间维度转至第四个单元格。 ??? 2、Cat5e 是 Product 数组的第三个元素,因此转至第三个元素。 ??? 3、Oracle 是 Customer 数组的第三个元素,因此转至第三个元素。 ??? 就是这样!现在您已经找到了所需的量度。由于维度值充当数组指针,因此在执行此操作时不必使用索引。同样,如果您要计算 2008 年 8 月份所有客户的销售总额,可以执行同样的操作,只是在第 3 步中将数组各元素的量度加起来,而不是转至特定单元格。 ??? 以传统星型模式存储的纯关系形式数据的关系访问与上述方法不同,如下所示。 在关系数据库方法中,您必须将此“事实”表与所有维度联接。每次需要数据时,都需要从事实表中选择合适的数据(可能要通过索引),然后将其与所有维度逐个联接起来(再次通过索引)。虽然此方法在技术上是可行的,但在大型数据库中完全行不通。 ??? 作为替代方法,能否为所有这些选项创建物化视图 (MV) 呢?用户可以使用维度元素的任意组合: ??? ■? 8 月份针对所有客户的 Cat5e 销售额 ??? ■? 8 月份针对 Oracle 的串行电缆销售额与 IBM 销售额(针对同一产品和月份)的百分比 ??? ■? 针对 HP 的光缆销售额与针对 Microsoft 的串行电缆销售额的百分比 ??? 等等。但是,需要创建多少个 MV 呢?理论上讲,应该为每个组合创建一个 MV (4 x 4 x 4 = 64 MV)。除了空间,您还需要足够的时间和数据库资源,以便在数据发生变化时刷新 MV,可能会涉及数千个元素。这样,要创建和管理的 MV 的数量 ??? 将变得相当庞大。 ??? 相反,多维数据集是单个段,却可以同样轻松地处理任意类型的查询。虽然二者都可用于旨在加快汇总数据(与 OLTP 数据不同)处理速度的数据仓库设计中,却存在着巨大的根本区别:MV 存储预先计算的结果以避免联接和聚合,而多维数据集存储原始数据

文档评论(0)

yingrong + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档