Oracle数据库11g新特性.docx

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存储预先计算的结果以避开联接和聚合，而多维数据集存储原始数据并即时计算大多数汇总数据。〔需要强调的是“