...

Oracle Database 11g Release 2のオンライン分析処理

by user

on
Category: Documents
6

views

Report

Comments

Transcript

Oracle Database 11g Release 2のオンライン分析処理
Oracle ホワイト・ペーパー
2009 年 9 月
Oracle Database 11g Release 2 の
オンライン分析処理
I
Oracle Database 11g Release 2 のオンライン分析処理
はじめに.............................................................................................................................. 1
キューブ - 3 つのユースケース .......................................................................................... 2
リレーショナル・ディメンション融合モデル .................................................................... 3
キューブの利点 ................................................................................................................... 3
問合せパフォーマンス ................................................................................................... 4
高速な増分アップデート ............................................................................................... 6
ビジネス・インテリジェンス・アプリケーションの分析コンテンツの強化 ............... 8
Oracle Business Intelligence でのキューブの使用 ........................................................... 13
Microsoft Excel でのキューブの使用 ................................................................................ 14
SQL によるキューブの問合せ .......................................................................................... 15
キューブ編成のマテリアライズド・ビューとクエリー・リライト ............................ 15
キューブ・ビュー ........................................................................................................ 18
キューブの設計と管理 ...................................................................................................... 26
Analytic Workspace Manager ...................................................................................... 27
キューブ・マテリアライズド・ビューのリフレッシュ .............................................. 28
組込み OLAP ソリューションのその他の利点 ................................................................. 29
結論 ................................................................................................................................... 30
II
Oracle Database 11g Release 2 のオンライン分析処理
はじめに
Oracle Database 11g の OLAP オプションは、Oracle Database Enterprise Edition に組み込まれたフ
ル機能のオンライン分析処理(OLAP)サーバーです。OLAP オプションには次の機能があります。

SQL ベースのビジネス・インテリジェンス・アプリケーション向けのサマリー管理ソリューショ
ン。この機能では、Oracle キューブがサマリー・データの管理に使用されます。また、Oracle
Database のクエリー・リライト機能により、Oracle キューブはキューブ編成のマテリアライズ
ド・ビューとして、SQL ベースのビジネス・インテリジェンス・アプリケーションから透過的に
アクセスされます。

SQL ベースのビジネス・インテリジェンス・アプリケーションに、豊富な分析コンテンツを提供
する計算エンジン。Oracle キューブは、加算的集計、非加算的集計、計算済メジャー、統計予測、
割当て、ディメンション計算モデルによって拡張できます。アプリケーションは、SQL を使用し
てキューブに問合せを実行します。

ディメンション指向のビジネス・インテリジェンス・アプリケーションにサービスを提供する、
フル機能の多次元サーバー。アプリケーションは、Oracle OLAP API や MDX といったディメン
ション問合せ言語を使用して、すべてのデータ(計算を含む)への問合せを実行します。
OLAP オプションは、組込みソリューションとして、Oracle Database インスタンス内で動作します。
OLAP オプションを使用するために、サーバー、ユーザー、データベース用の特別な管理ファイル
は必要ありません。OLAP オプションは、エンタープライズ用に準備された Oracle データベースの
セキュリティ機能と高可用性機能を継承しています。OLAP オプションが提供する OLAP キューブ
に対して SQL インタフェースを使用することで、スター・スキーマに問合せを実行できるすべての
アプリケーションは、OLAP キューブに対しても簡単に問合せを実行できます。これにより、問合
せのパフォーマンスは向上し、分析コンテンツが強化されます。
1
Oracle Database 11g Release 2 のオンライン分析処理
キューブ - 3 つのユースケース
Oracle データベースのアーキテクチャでは、1 つの OLAP キューブが、次の 3 つの役割を同時に果た
します。

アプリケーションにとって透過的なサマリー管理ソリューション

SQL ベースのビジネス・インテリジェンス・アプリケーションに対する、アプリケーションにとっ
て透過的で豊富な分析コンテンツの提供

フル機能の多次元 OLAP サーバー
Oracle OLAP キューブでキューブ編成のマテリアライズド・ビューを使用すると、SQL ベースのアプ
リケーションは、Oracle Database のクエリー・リライト機能によって、キューブ内で管理されている
サマリー・データに自動的にアクセスできます。キューブのこの使用方法では、キューブ内のサマ
リー・データが Oracle によって集計および管理されるため、アプリケーションは、これまでと同じ
ように、SQL を使用してディテール・リレーショナル表に対する問合せを実行できます。サマリー・
データが必要な問合せは、Oracle によって自動的にキューブに対する問合せにリライトされます。
SQL ベースのアプリケーションは、キューブによるパフォーマンスの向上という恩恵を受けていて
も、キューブの存在を意識する必要はありません。
SQL ベースのビジネス・インテリジェンス・アプリケーションは、OLAP キューブのビューを使用
して、キューブに対して直接問合せを実行することで、パフォーマンスの向上とキューブの分析コ
ンテンツへのアクセスを実現できます。キューブ・ビューは、データをリレーショナル・スター・
スキーマとして表現するキューブのリレーショナル・ビューです。OLAP キューブは、通常のスター・
スキーマとは異なり、ディテール・レベルおよび集計レベルのデータ、さらにはキューブ内で動的
に計算される興味深いメジャーも提供します。この使用法では、SQL ベースのアプリケーションは
キューブのリレーショナル・ビューに問合せを実行しますが、通常、キューブ自体を認識すること
はありません。
キューブには、MDX1あるいは Oracle OLAP API を使用して、ディメンション対応のアプリケーショ
ンからも問合せを実行できます。このタイプのアプリケーションでは通常、エンドユーザーが、ディ
メンション問合せや計算モデルを明示的に用いた問合せを実行できます。具体的には、ドリルとピ
ボット、ディメンション対応のクエリー・ビルダー、カスタム・メジャー(ファクト)の定義機能
などがユーザーに提供されます。こうしたアプリケーションは OLAP オプション用に設計され、
キューブに完全に対応しています。
これらの問合せ方式は 1 つのキューブで同時に提供されます。結果として、キューブに対する投資
を多くのアプリケーションとユーザーで活用できるため、最大の投資利益が得られます。
1
キューブに対する MDX 問合せには、サード・パーティの MDX プロバイダが必要です。
2
Oracle Database 11g Release 2 のオンライン分析処理
リレーショナル・ディメンション融合モデル
OLAP オプションは、Oracle Database の機能として組み込まれているため、リレーショナル・モデル
とディメンション・モデルの要素を 1 つのアプリケーション内に融合できます。
キューブの計算モデルはディメンションを使用しているため、開発者とデータベース管理者は、
Oracle Database 内にディメンション計算と階層計算を埋め込むことができます。これらの計算は簡単
に定義でき、実行時に効率的に実行されます。
Oracle ではキューブに対し、フル機能の SQL インタフェースを提供しているため、キューブは、高
いパフォーマンスと高度な分析コンテンツを提供するリレーショナル・オブジェクトであると考え
ることができます。また、ディメンションは、階層問合せの作成に有用な情報が格納された列を含
むリレーショナル・オブジェクトであると考えることができます。
アプリケーションは、SQL を使用して、リレーショナルの概念とディメンションの概念を自由に融
合させることができます。また、リレーショナル表をキューブとディメンションに結合することも
できます。アプリケーションは、ディメンション・コンテキストで、ドリル、ピボット、階層フィ
ルタおよび計算を使用してキューブに問合せを発行したり、SQL 集計関数を使用して属性に基づく
レポートを実行したり、リレーショナル表のディテールにドリルダウンしたりできます。
要するに、キューブとは、特別な性質を持つ、データベース内の新しいデータ型であり、リレーショ
ナル表と多次元キューブを含むモデル全体の一部を形成します。アプリケーション開発者は、要件
に応じてもっとも適切なタイプのオブジェクトを選択し、単一のモデルおよび問合せ内にシームレ
スに融合させることができます。
これは、キューブが、SQL による問合せ、およびリレーショナル・オブジェクトとの結合が可能な
フル機能のディメンション・オブジェクトだからです。
キューブの利点
Oracle OLAP キューブは、ビジネス・インテリジェンス・アプリケーションに大きな利益をもたらす、
Oracle Database 内のデータ型です。次のような利点があります。

問合せパフォーマンスの向上

高速な増分アップデート

豊富な分析コンテンツ

論理ビジネス・モデルとキューブのリレーショナル表現を記述するメタデータ
上記の利点を 1 つ以上活用することで、SQL ベースや MDX ベース、OLAP API ベースであるかに関
係なく、どのようなアプリケーションでも改善できる可能性があります。
3
Oracle Database 11g Release 2 のオンライン分析処理
問合せパフォーマンス
ビジネス・インテリジェンス・アプリケーションで卓越した問合せパフォーマンスを実現するには、
相互に関連する 2 つの大きな問題を解決する必要があります。1 つは、ビジネス・インテリジェンス・
アプリケーションのユーザーによって作成された大半の問合せが、サマリー・データを必要とする
という点です。もう 1 つは、ユーザーは固有の問合せとレポートを定義して、独自の方法でデータ
を探索しようとする傾向があるという点です。こうしたデータ探索を行うと、予測不能な非定型の
問合せパターンが作成されることになります。
非定型の問合せパターンと予測可能な問合せパターン
問合せパターンが予測可能な場合は、特定の問合せの要求を満たすデータをあらかじめ計算してお
くことで、アプリケーションの問合せパフォーマンスを比較的容易に最適化できます。たとえば、
BI ダッシュボードに 20 の異なる問合せが含まれている場合、それぞれの問合せに必要となるサマ
リー表やマテリアライズド・ビューを事前に作成して、問合せパフォーマンスを高めるようにする
のは理にかなっています。
しかし、問合せパターンが予測できなくなるにつれ、特定の問合せに合わせて事前に計算するのは
現実的ではなくなってきます。たとえば、5 つのディメンション(例:時間、顧客、製品、流通チャ
ネル、サプライヤと出荷方法)を持つデータ・モデルがあり、各ディメンションに 6 段階のサマリー・
レベル(時間ディメンションの場合は、日、週、月、四半期、半年、1 年)がある場合を考えてみま
す。この例では、ユーザーが問合せを実行する可能性のあるサマリー・レベル・データを表す一意
なレベルの組合せが 15,6242通りあります。
大半の DBA および BI アプリケーションの管理者は、エンドユーザーに事前定義の問合せだけを使
用するように強制することで、この問題を解決しようとします。つまり、サマリー表やマテリアラ
イズド・ビューを使用して一定量のサマリー・データを事前に計算しておくことで、これらの事前
定義の問合せをチューニングし、パフォーマンスを高める方法です。
ユーザーに事前定義のレポートや問合せだけを使用するように強制すると、問題の範囲が限定され
るため、DBA はそれらの問合せの要求を満たす個別のサマリー表やマテリアライズド・ビューを作
成でき、結果として問合せパフォーマンスが向上します。しかし、この解決方法では、ユーザーが
質問を作成するときの自由度が低下し、ビジネス・インテリジェンス・アプリケーションの効果と
価値が低下してしまいます。しかし、ユーザーが自由に非定型の問合せを使用してデータを探索で
きるようにすると、問合せパフォーマンスの低下という問題に直面することになります。
そこで代替策として、DBA は、汎用のサマリー管理ソリューションとして使用できるサマリー表と
マテリアライズド・ビューのコレクションを作成するという方法を選択できます。この方法では通
常、特定レベルの組合せデータを用いた表とマテリアライズド・ビューのコレクションを作成しま
す。この方法では、問合せがそれらのレベルの組合せから直接データを選択すること、あるいは、
実行時にサマリーを作成しても高いパフォーマンスを維持できるくらいに、サマリー表またはマテ
リアライズド・ビューのデータが問合せの要求に近いことを前提としています。この解決方法の効
果は、作成するサマリー表の数と問合せパターンによって異なりますが、多くの場合、達成される
2
5 つのディメンションにそれぞれ 6 つのレベルがあるため、そこからベース・レベルの 1 を引いて(56 –
1)となります。
4
Oracle Database 11g Release 2 のオンライン分析処理
パフォーマンスにばらつきがあります。すなわち、サマリー表から直接データを選択する問合せ、
またはサマリー表に非常に近いデータを使用する問合せでは、パフォーマンスが高くなりますが、
サマリー表のデータをほとんど利用できない問合せではパフォーマンスが低くなります。
データ・モデル全体で高い問合せパフォーマンスを実現するのは極めて困難です。というのは、膨
大な数のサマリー表またはマテリアライズド・ビューが必要になると考えられるからです。再度、
レベルの全組合せが 15,624 通りある先ほどの例で考えてみます。レベルの全組合せのわずか 5%(数
百のサマリー表またはマテリアライズド・ビュー)を作成した場合でも、データセットの管理に伴
うオーバーヘッドはかなり大きくなりますが、問合せパフォーマンスが向上するのはごく一部の
ケースだけに限られます。
サマリー・データの最適化
Oracle キューブはまさにこうした状況、すなわち、予測不可能な問合せパターンでエンドユーザーが
問合せを発行するビジネス・モデルに対処するために設計されたものです。こうしたビジネス・モ
デルでは、ビジネス・モデル全体がいつでも問合せの対象になります。
1 つの OLAP キューブは、Oracle Database 内の単一オブジェクト内で、全レベルのサマリー・データ
を表現したものです。キューブは、階層型集計とサマリー・データ管理用に高度に最適化されてい
ます。また、非定型の問合せパターンに典型的なランダム・セル(SQL から見た場合の行)アクセ
ス用にも高度に最適化されています。

OLAP オプションでは、特許で保護された独自の手法を用いて、サマリー・レベルのデータを集計
し、格納します。これらの手法は極めてスパースなデータセット向けに高度に最適化されており、
ビジネス・インテリジェンス・アプリケーションでは一般的です。この手法には、キューブの圧縮
とコストベースの集計テクノロジー(どちらもキューブ固有のテクノロジー)が含まれます。

ファクト(メジャー)のセルへの参照には、オフセット・アドレッシングと、ディメンションが
データへの索引として機能する専用の索引付け手法が使用されています。配列ベースの格納によ
り、キーが冗長的に格納されることがなくなります。

メジャー・データをディメンションと事前に結合することで、データにフィルタを適用したり、
(多くの時系列計算で必要になる)外部結合を解決したりする際、また 2 つ以上のキューブから
のデータが問合せに必要な場合に、キューブが極めて効率的に動作します。

キューブ編成のマテリアライズド・ビューは、単一のオブジェクトですべてのサマリーを表現し
たものです。これにより、SQL オプティマイザは、問合せ作成の最適な候補となるオブジェクト
を迅速に選択できます。
SQL ベースのビジネス・インテリジェンス・アプリケーションでキューブの問合せパフォーマンス
を活かすには、現在のサマリー管理方式の代わりにキューブベースのマテリアライズド・ビューを
使用するか、OLAP キューブ・ビューに対して直接問合せを実行します。
次のグラフを見れば、サマリー表または表のマテリアライズド・ビューとキューブとの問合せパフォー
マンスの相対差が分かります。一般に、事前定義のレポートや比較的小さな非定型問合せを特徴とす
るアプリケーションでは、(表とキューブの)どちらのデータ型でも差はありません。しかし、問合
せの非定型の度合いが大きくなると、問合せパフォーマンスはキューブの方が高くなります。
5
Oracle Database 11g Release 2 のオンライン分析処理
キューブとキューブ編成マテリアライズド・ビューの問合せパフォーマンスの優位性は、問合せパターンが非定型に近づくほど高まります。
高速な増分アップデート
問合せパフォーマンスは、パフォーマンスの要因の一部に過ぎません。すべてのサマリー管理ソ
リューションでは、データセットの定期的なアップデートにおけるパフォーマンスの優位性を容易
に管理および提供できなければなりません。
Oracle OLAP キューブは、高速な増分アップデートが実行できるよう高度に最適化されています。
キューブでは、すべてのサマリーを単一オブジェクト内で管理するため、多数のサマリー表または
マテリアライズド・ビューを使用するよりも管理が容易です。

キューブは、階層型集計の特徴である実データの散在性を利用した、特許で保護されたアルゴリ
ズムを用いて集計および格納されます。

キューブ内での集計の大半は増分集計です。キューブはベース・レベルのデータに対する変更を
認識し、ベース・レベルのデータが変更されたときにのみサマリー・レベルのデータを再集計し
ます。

キューブはデータベース内の単一オブジェクトです。キューブのソースであるディテール表は、
1 度スキャンされるだけで、すべての集計がソース表の 1 回のスキャンによって作成されます。

Oracle Database 11g より、Oracle マテリアライズド・ビューのリフレッシュ・システムを使用し
てキューブを更新できるようになりました。これにより、キューブは、マテリアライズド・ビュー
のログ表からソース表に対する変更を処理できるので、ソース表をスキャンする必要がなくなり
ました。挿入、更新、削除は、マテリアライズド・ビューのログ表を基に増分的に処理されます。
6
Oracle Database 11g Release 2 のオンライン分析処理
一般にキューブは、ほとんどのサマリー・レベルのデータを、問合せに対する応答として実行時に
計算するという点を知っておく必要があります。すべてのサマリー・データを事前に計算してキュー
ブの全データを集計しておくことはほとんどありません。ほとんどの場合は、キューブのアップデー
ト時に比較的尐量のデータが事前集計されるだけです。
この実行時のデータ集計という点については、明白な利点がいくつか挙げられます。その中でももっ
とも重要な 2 つの利点は、細かな単位でのサマリー・データの事前集計とキューブに対するディメ
ンションの事前結合です。
Oracle Database 11g で導入されたコストベースの集計では、データの事前集計に非常に細かな単位に
よるアプローチを採用しています。コストベースの集計では、レベルの組合せを選択するといった
極めて粗い方法でデータを事前集計するのではなく、計算の処理負荷が大きいセル(SQL 用語でい
う行)を動的に決定し、それらのセルだけを格納します。この決定の一部は、データを調べて、親
セルの集計を作成するために必要な子セルの数を把握することによって下されます。コストのしき
い値は DBA が変更できます。コストベースの集計方法によって、非常に'網の目の細かい'事前集計
セルが作成され、キューブ全体で一貫性のあるパフォーマンスが実現されます。
キューブの配列ベースの実装では、ディメンションとキューブが事前結合されます。これにより、
キューブ内での集計データの生成プロセスで結合処理を行う必要がなくなりました。
キューブの保守プロセスでは、前もって余分な作業(たとえば、ディメンションの編集、参照整合
性の強制、データの自動索引付け)が必要になるため、キューブのデータ準備に必要な最小時間は、
単純にリレーショナル表にデータを挿入する場合に比べて長くなると予想されます。しかし、表の
索引付けとサマリー表またはマテリアライズド・ビューの作成に必要な時間も含めると、全体的な
データ準備時間はキューブの方が短くなります。
問合せで使用可能になるまでのデータ準備時間が、キューブとサマリー表ではどちらが短くて済む
かは、問合せの負荷と必要とされる問合せパフォーマンスによって決まります。再度、予測可能な
問合せパターンと非定型の問合せパターンの違いについて考えてみます。問合せパターンの予測可
能性が極めて高い場合は、数個のサマリー表またはマテリアライズド・ビューがあれば十分です。
キューブを作成するよりもこれらの表を作成した方が速い場合がほとんどです。
しかし、問合せパターンの予測可能性が低くなってくると、キューブの方が有利になります。キュー
ブは、高度に効率化された集計アルゴリズム(キューブの圧縮とコストベースの集計)によって、
比較的迅速に問合せに対して完全な最適化が行われる傾向があるためです。コストベースの集計を
用いて比較的尐量のデータを事前集計するため、キューブはより短時間で問合せに対して最適化さ
れるようになります。サマリー表またはマテリアライズド・ビューの場合は、問合せ負荷の非定型
度が増すにつれて、問合せパフォーマンスを高めるためにより多くの表を作成する必要があります。
以下のグラフは、この関係を示しています。
7
Oracle Database 11g Release 2 のオンライン分析処理
キューブは、非定型の問合せ環境に対して迅速に最適化されます。
キューブは、予測可能な問合せと予測不可能な問合せのどちらの負荷に対しても短い時間で対応し
ています。この結果からみて、企業は、ディメンション・データセットのサマリー方法として、キュー
ブおよびキューブ編成のマテリアライズド・ビューを検討する必要があるでしょう。
ビジネス・インテリジェンス・アプリケーションの分析コンテンツの強化
キューブのパフォーマンス特性だけでもデータウェアハウスまたはデータ・マートにキューブの追
加を検討する十分な理由になります。しかし、パフォーマンスは、キューブがもたらす利点の 1 つ
に過ぎません。キューブのもう 1 つの利点として、ビジネス・インテリジェンス・アプリケーショ
ンの分析コンテンツを大幅に強化できる点が挙げられます。
キューブ内には、多様な分析計算を定義できます。これには、階層型集計、計算済メジャー、割当
て、統計予測、メンバー計算モデルなどが含まれます。
キューブはデータベース内で自動的にスター・スキーマとして表現されます。キューブの各ディメ
ンションにはリレーショナル・ビューが対応しており、キューブのメジャーが 1 つのビューで表現
されます。キューブの分析計算結果は、キューブ・ビューのリレーショナル列として公開されます。
たとえば、売上げ収益、年度累計売上げ、在庫残高、在庫費用の列があるとします。列には複雑な
計算値(例:年度累計売上げ)が返されることもあれば、高度な集計方法を必要とするもの(例:
在庫残高)もありますが、問合せツールで計算ルールを理解する必要はありません。ツールは簡単
な SQL を発行するだけです。必要な計算はキューブが自動的に実行します。
8
Oracle Database 11g Release 2 のオンライン分析処理
ビジネス・インテリジェンスやキューブに関する知識を必要としない、Oracle Application Express を使用して作成されたアプリケーションの例
キューブで管理される分析コンテンツ(年度累計計算など)に対する問合せを実行できます。
ディメンション・モデルを活用した計算の定義
キューブでは、ディメンション・モデルを使用して計算の定義を簡素化しています。たとえば、メ
ジャーの計算は、親、子、祖先、子孫といった階層関係を認識する構文を使用して定義できます。
メジャー計算を定義する構文はディメンションに対応していますが、OLAP 関数は SQL の文法に基
づいているため、LAG や RANK といった SQL 分析関数の使用経験がある開発者や DBA にも違和感
がありません。
階層構造を認識する計算関数の大きな利点は、1 つの式をキューブ内のどこでも使用できることです。
従来の SQL ベースのアプリケーションでは、問合せの対象となる列によって式が変わる可能性があ
ります。
LAG 関数を例に考えてみます。製品ディメンションに、合計、メーカー、ブランド、品目、SKU の
各レベルがあり、親階層の製品を順位付けする必要がある場合、アプリケーションは、レベルごと
に 1 つの式を定義する必要があります。次に例を示します。
--ブランドを合計でランク付け
rank() over(PARTITION BY p.TOTAL ORDER BY f.sales DESC NULLS LAST) RANK
--ブランドの品目でランク付け
rank() over(PARTITION BY p.BRAND ORDER BY f.sales DESC NULLS LAST) RANK
--品目の SKU でランク付け
rank() over(PARTITION BY p.ITEM ORDER BY f.sales DESC NULLS LAST) RANK
9
Oracle Database 11g Release 2 のオンライン分析処理
一部の高度な問合せアプリケーションは、中間層に階層と計算式を定義することによってこの問題
を解決していますが、多くのアプリケーションではこの問題を解決できません。このため、エンド
ユーザーは、サマリー・レベルごとに式を定義する必要があります。これは、とりわけデータ内を
ドリルダウンまたはドリルアップする必要のあるアプリケーションでは、大変面倒な作業になる可
能性があります。
キューブを使用すれば、1 つの式を使用して、モデル内のどこでも動作する階層計算式を定義できま
す。次のランク式は、階層内の任意の場所で親階層に属する製品をランク付けするものです。上記
の 3 つの SQL ランク関数は、この式で置き換えることができます。
--親階層でランク付け
RANK() OVER HIERARCHY (PRODUCT.PRIMARY ORDER BY UNITS_CUBE.SALES DESC NULLS
LAST WITHIN PARENT)
この OLAP 式は先の SQL 式とほぼ同じですが、問合せのパーティション句が階層と PARENT キー
ワードで置き換えられている点に注意してください。OLAP 式はハードコードされた列ではなく、相
対的な関係を記述しているため、どのサマリー・レベルでも使用できます。同じパターンを別の例
で見てみます。この例は、終了日付指定期間の時系列の計算に基づいたものです。
--SQL 式
SUM(f.sales)
OVER(PARTITION BY t.calendar_year
ORDER BY t.end_date
RANGE BETWEEN unbounded preceding AND current row)
--OLAP 式
SUM(units_cube.sales)
OVER HIERARCHY (time.calendar
BETWEEN unbounded preceding AND current member
WITHIN ancestor at level time.calendar.calendar_year)
前の例と同様、OVER が OVER HIERARCHY で置き換えられ、列名が階層の各要素で置き換えられ
ています。
同じような関数が、分配、過去/未来期間、終了日付指定期間、開始日付指定期間、移動集計、累積
集計といった一般的な計算にも使用できます。各タイプの計算について、特定レベルおよび複数レ
ベルの親や子孫に対して計算するためのさまざまなバリエーションが用意されています。
10
Oracle Database 11g Release 2 のオンライン分析処理
キューブはデータの密度を高めるために自動的にパーティション外部結合を実行するため、時系列
計算はさらに簡素化されます。これにより、過去および未来の期間計算結果は、たとえ過去または
未来の期間が NULL であっても、常に正しい値を返すようになります。ディメンションとキューブ
は自動的に結合されるため、キューブでは、この操作を非常に効率的に実行できます。
複数の OLAP 関数を組み合わせたりネストしたりして、新しい関数を作ることもできます。また、
大半の SQL 単一行関数(DECODE や ROUND など)は、キューブに埋め込まれる OLAP 計算式内で
使用できます。これにより、キューブ内に、非常に強力なユーザー定義の計算式を作成できます。
前述のとおり、すべてのメジャー計算式は SQL キューブ・ビュー内の列として明示されます。アプ
リケーションは SQL キューブ・ビュー内の列を選択するだけで、計算結果にアクセスできます。
キューブ内で使用可能な各種計算
キューブ内で使用できるさまざまなタイプの計算は、階層集計、メジャー計算、割当て、統計予測、
モデルのいずれかのカテゴリに分類できます。以下の各項で、これらの各カテゴリについて説明し
ます。
階層集計
階層集計とは、階層の低レベル・メンバーから高レベル・メンバーに向かってデータを集計する計
算のことです。OLAP オプションでは、合計、階層加重平均、スケール合計など、多様な集計方法を
サポートしています。集計方法はディメンションごとに変わる可能性があります。たとえば、人員
数メジャーの集計は、組織ディメンションに対しては合計をとり、日、月、四半期、年といった期
間ディメンションに対しては平均をとるといった具合です。
計算済メジャー
計算済メジャーとは、キューブ内には計算式として存在し、問合せ中に動的に計算されるメジャー
のことです。たとえば、時系列計算、市場シェア、索引、分散、ランキングなどがあります。キュー
ブでは、行間計算、外部結合、異なるキューブ間の結合などが必要になる場合でも、メジャーの計
算を極めて効率的に処理できます。
計算済メジャーは、追加のファクト列として、SQL キューブ・ビューに追加されます。
割当て
割当てでは、階層の高レベル・メンバーから低レベル・メンバーにデータを分配します。たとえば、
企業の予算管理システムでは、割当てシステムを使用して、来年度の予算を、部門から製品グルー
プ、最終的には個々の製品にまで分配できます。
11
Oracle Database 11g Release 2 のオンライン分析処理
OLAP オプションでは、コピー方式(階層コピー、最小、最大、先頭、末尾)、均等分配方式(均等、
階層均等)、比例方式(加重分配など)といった多様な割当て方式をサポートしています。
割当ての結果はキューブに格納され、SQL キューブ・ビューのファクト列として問合せの対象にな
ります。
統計予測
OLAP オプションは、完全な統計予測システムを提供します。予測方法には、非線形回帰、単純指数
平滑法、2 次指数平滑法、Holt/Winters 法などがあります。予測システムは、データの季節変動の予
測機能も備えています。
予測結果はキューブに格納され、SQL キューブ・ビューのファクト列として問合せの対象になりま
す。
メンバーの計算モデル
OLAP モデルでは、個々のディメンション・メンバーを、それぞれに固有の計算ルールに従って計算
します。OLAP オプションは自動的に計算を命令します。連立方程式もサポートしています。モデル
は財務アプリケーションで使用され、特に勘定科目一覧表などの非階層ディメンション内に計算を
定義する場合に多く使用されます。
Oracle データ・ディクショナリ内の BI メタデータ
キューブは、エンタープライズ・ビジネス・インテリジェンス・プラットフォームのいくつかのイ
ンポート資産を表します。すなわち、データ、論理ビジネス・モデル、計算ルール、ビジネス・モ
デルの物理表現です。これらの各要素は、Oracle データ・ディクショナリ内に記述されます。ビジネ
ス・インテリジェンス・アプリケーションは、データ・ディクショナリに問い合わせてキューブの
あらゆる側面を調査し、自身のメタデータ・リポジトリに、SQL キューブ・ビューに問い合わせる
ために必要な情報を自動的に格納します。
一般に、OLAP メタデータは次のどちらかのカテゴリに分類できます。

キューブの構造、データ、計算方法に関する情報

SQL キューブ・ビューを使用した問合せに対するキューブの見せ方に関する情報
キューブの構造を記述するデータ・ディクショナリ・ビューを参照することで、アプリケーション
は、キューブのディメンション、階層、レベル、属性、メジャーを確認できます。キューブとメジャー
の場合、データ・ディクショナリ・ビューには、キューブの計算方法とメジャーの計算式が記述さ
れています。アプリケーションは、この情報を使用してキューブの論理モデルを把握できます。
SQL を介してキューブを公開する方法を記述したデータ・ディクショナリ・ビューには、キューブ、
ディメンション、階層のビューが、ビュー名や列名とその役割などの情報によって記述されていま
す。アプリケーションは、この情報を使用して、アプリケーションを SQL キューブ・ビューにマッ
ピングできます。
12
Oracle Database 11g Release 2 のオンライン分析処理
OLAP データ・ディクショナリ・ビューには XXX_CUBE という接頭辞が付いている(例:USER_CUBE、
ALL_CUBE、DBA_CUBE)ので、簡単に見つけることができます。
Oracle Business Intelligence でのキューブの使用
Oracle Business Intelligence Enterprise Edition は、さまざまなデータソースにアクセスできるダッ
シュボードやアラートを備えた、フル機能のビジネス・インテリジェンス・レポート作成システ
ムです。Oracle Business Intelligence は、SQL ベースのシステムとして、Oracle キューブをサマリー
管理ソリューション(キューブ編成マテリアライズド・ビューを透過的に使用)あるいは豊富な
分析コンテンツを持つデータソース(キューブ・ビューに直接問合せを実行)として使用できま
す。
Oracle Business Intelligence でキューブ編成のマテリアライズド・ビューを使用する場合、リレー
ショナル表に問合せを実行すると、データベースにより自動的にキューブへの問合せがリライト
されます。Oracle Business Intelligence のリポジトリには何の変更もありません。
キューブへの直接の問合せをサポートするため、Oracle Business Intelligence はキューブ内の計算に
アクセスでき、Oracle OLAP オプションが、1 つ以上のキューブを表すリポジトリを Oracle Business
Intelligence に自動的に作成する機能を提供します。Oracle Business Intelligence が生成されたリポジ
トリに基づいて発行する SQL は、完全にキューブに対応しており、最適なパフォーマンスを保証
します。
13
Oracle Database 11g Release 2 のオンライン分析処理
Oracle Business Intelligence Enterprise Edition の年度累計ダッシュボード・ページ
すべてのデータは、SQL を使用して Oracle キューブから問合せが実行されます。
Microsoft Excel でのキューブの使用
Microsoft Excel のピボット・テーブルを使用して、ディメンション・コンテキストで Oracle キューブ
に問合せを実行できます。Microsoft Excel では、MDX プロバイダを使用して、直接 Oracle キューブ
に問合せを実行できるため、ユーザーは、キューブ内のあらゆるデータ(ディテール・データ、サ
マリー・データ、計算)にインタラクティブにアクセスできます。ユーザーは独自の問合せを定義
でき、サマリー・レベルからディテール・レベルまで階層内を移動でき、ディメンションにピボッ
トを付けてレポートの方向を変えることができます。
Microsoft Excel の形式機能とグラフ機能は、Oracle キューブのデータで使用できます。キューブ・デー
タをワークシートの他のセルや別のワークシートから参照できます。Microsoft Excel のピボット・
テーブルやグラフは、PowerPoint や Word といった他の Microsoft Office アプリケーションに埋め込
むことができるため、これらのアプリケーションで Oracle OLAP キューブのデータをそのまま表示
できます。
14
Oracle Database 11g Release 2 のオンライン分析処理
Microsoft Excel のピボット・テーブルを使用した、Oracle キューブへの問合せ
SQL によるキューブの問合せ
SQL は、ビジネス・インテリジェンス・アプリケーション、問合せアプリケーション、レポート作
成アプリケーションでもっとも広く使用されている問合せ言語です。大部分のデータがリレーショ
ナル・データベースで管理されていることを考えれば当然です。OLAP オプションは、SQL ベース
のアプリケーションからも利用できます。したがって、SQL ベースのアプリケーションから標準の
SQL を用いてキューブに問合せを実行できます。アプリケーションは、キューブ内のあらゆるデー
タ(ディテール・データ、サマリー・データ、ストアド・データ、計算済データなど)に簡単な SQL
文でアクセスできます。キューブ内でのデータの計算方法について理解する必要はありません。
アプリケーションは通常、次のどちらかのカテゴリに分類されます。

キューブによるパフォーマンスの向上だけを目指したアプリケーション
これらのアプリケーションは、キューブ編成のマテリアライズド・ビューを使用してキューブ内
のサマリー・データにアクセスできます。

キューブの高いパフォーマンスと豊富な分析コンテンツを利用するアプリケーション
これらのアプリケーションは、キューブ・ビューに問い合わせることで、パフォーマンスを高め、
キューブ内のあらゆるコンテンツにアクセスできます。
キューブ編成のマテリアライズド・ビューとクエリー・リライト
キューブ編成のマテリアライズド・ビューを使用すると、キューブで管理されているサマリー・デー
タに、あらゆるアプリケーションから透過的にアクセスでき、結果として、問合せパフォーマンス
が即座に向上します。Oracle Database 11g より導入されたキューブ編成のマテリアライズド・ビュー
は、表ベースのマテリアライズド・ビューと同じ役割を果たします。つまり、問合せ発行元のアプ
リケーションにとって透過的なサマリー管理ソリューションという役割です。表ベースのマテリア
15
Oracle Database 11g Release 2 のオンライン分析処理
ライズド・ビューと同様、アプリケーションがディテール表に対して問合せを発行すると、その問
合せは、データベースによって、マテリアライズド・ビュー内のサマリー・データにアクセスする
ように自動的にリライトされます。
キューブ編成のマテリアライズド・ビューの場合、データは、表内ではなくキューブ内で管理され
ます。このため、キューブ編成のマテリアライズド・ビューは、キューブが備えている、問合せと
リフレッシュに関する以下のパフォーマンス上の利点を継承しています。

圧縮キューブ集計テクノロジー

コストベースの集計

単一のデータベース・オブジェクトによるすべてのサマリーの管理

配列ベースのストレージと高速なセル(行)アクセス

高速な増分リフレッシュと集計
キューブ編成のマテリアライズド・ビューは、メタデータだけが格納されたオブジェクトという点
では、事前に構築された表のマテリアライズド・ビューと同じです。データはキューブ内で管理お
よび格納されます。マテリアライズド・ビューには、データベースが、クエリー・リライト、およ
びマテリアライズド・ビュー・リフレッシュ・システムを介したキューブのリフレッシュを行うた
めに必要メタデータだけが格納されます。キューブからキューブ編成のマテリアライズド・ビュー
にデータが複製されることはありません。
キューブ内のすべてのサマリー・データを表す単一のマテリアライズド・ビューが存在します。サ
マリー管理ソリューションとして、数十、数百、あるいは数千の表ベースのマテリアライズド・ビュー
を使用する代わりに、単一のキューブベース・オブジェクトだけを参照すれば済むため、問合せの
実行の際にオプティマイザが考慮する必要のあるマテリアライズド・ビューの数が大幅に削減され、
さらにキューブの他の利点も加わって、クエリー・リライト機能の効率が向上します。
キューブ編成のマテリアライズド・ビューは、すべてのサマリーを表しているため、データベース
がマテリアライズド・ビューに合わせて問合せをリライトする速度は、通常極めて高速です。この
ことは、主要なビジネス・インテリジェンス・アプリケーションを用いたテストで実証済みです。
キューブ編成のマテリアライズド・ビューは、名前の先頭に CB$という接頭辞がついているのです
ぐに識別できます。たとえば、UNITS_CUBE という名前のキューブを表すマテリアライズド・ビュー
の名前は、CB$UNITS_CUBE となります。キューブ編成のマテリアライズド・ビューをキューブに
追加するには、Analytic Workspace Manager(OLAP 管理ツール)または OLAP API を使用します。追
加されたマテリアライズド・ビューの定義は、データベースによって自動的に保守されます。
問合せ発行元のアプリケーション、およびソース表の管理およびリフレッシュ・プロセスが、キュー
ブ編成のマテリアライズド・ビューを認識することはまったくありません。アプリケーションは、
これまでと変わらず、リレーショナル表に対する問合せを発行します。表の管理プロセスが、キュー
ブの存在によって変更されることはありません。
問合せの例
キューブ編成のマテリアライズド・ビューを使用して、アプリケーションがキューブ内のサマリー・
16
Oracle Database 11g Release 2 のオンライン分析処理
データに対し、透過的にアクセスする方法を示した例を以下に示します。
この例では、TIME_DIM、PRODUCT_DIM、CUSTOMER_DIM、CHANNEL_DIM、UNITS_FACT の
5 つの表があるものとします。_DIM で終わる名前を持つ表はディメンション表です。UNITS_FACT
表はファクト表です。これらの表のコレクションにより、スター・スキーマが形成されます。
これらの表のディメンション、階層、およびファクト・データを反映するようにキューブが作成さ
れ、DBA がキューブ編成のマテリアライズド・ビューを有効にします。キューブ編成のマテリアラ
イズド・ビューの名前は、CB$UNITS_CUBE です。
アプリケーションが、キューブやマテリアライズド・ビューを認識することはありません。キュー
ブが作成される前と同じように、次のような問合せを使用して表に問い合わせるだけです。
SELECT t.calendar_year_id time,
p.class_id product,
c.region_id region,
SUM(f.sales) sales
FROM time_dim t,
product_dim p,
customer_dim c,
units_fact f
WHERE t.month_id = f.month_id
AND p.item_id = f.item_id
AND c.ship_to_id = f.ship_to_id
GROUP BY t.calendar_year_id,
p.class_id,
c.region_id;
Oracle オプティマイザは、この問合せで要求されているサマリー・データがキューブに格納されてい
ることを認識し、キューブ編成のマテリアライズド・ビューに合わせてクエリー・リライトを実行
します。生成される SQL 実行計画は次のとおりです。
OPERATION
-------------------SELECT STATEMENT
HASH
CUBE SCAN CB$UNITS_CUBE
CUBE SCAN 処 理 は 、 キ ュ ー ブ 行 ソ ー ス に よ っ て デ ー タ が 返 さ れ る こ と を 示 し ま す 。
CB$UNITS_CUBE は、キューブ編成のマテリアライズド・ビューです。
17
Oracle Database 11g Release 2 のオンライン分析処理
古いデータの管理
表ベースのマテリアライズド・ビューと同じように、データベースは、ソース表が変更された場合、
キューブがソース表の最新状態を反映しなくなることを把握しています。キューブが最新のソー
ス・データを表している場合、そのキューブはフレッシュであると表現します。キューブがフレッ
シュでない場合は、マテリアライズド・ビューが古いと表現します。マテリアライズド・ビュー・
システムを使用すると、データベース管理者は、古いマテリアライズド・ビューに対するリライト
を許可または禁止できます。この点では、表もキューブ編成のマテリアライズド・ビューも変わり
ません。
キューブ・ビュー
Oracle OLAP キューブ・ビューを使用することで、企業は、SQL ベースのビジネス・インテリジェン
ス・アプリケーションを、パフォーマンスと分析コンテンツの両面で改善できます。OLAP キューブ・
ビューは OLAP キューブ、ディメンション、階層のリレーショナル・ビューであり、キューブとディ
メンションの全内容を表示するものです。
概要
キューブ・ビューを使用すると、アプリケーションは、格納されているファクト、およびキューブ
に埋め込まれた計算済メジャーなどの分析コンテンツに対して問合せを実行できます。ディメン
ションと階層ビューを使用すると、アプリケーションは、ディメンションのメンバーおよびメンバー
の属性に対して問合せを実行できます。OLAP ディメンションの属性には、レベル、親子関係、祖先、
子孫などの階層属性を含めることができます。これらの階層属性を使用すると、SQL ベースのアプ
リケーションにディメンション問合せモデルの要素を追加できます。
ディメンション内のキューブ、ディメンション、階層は、常に、リレーショナル・ビューとして、
SQL ベースのアプリケーションに提示されます。次の 3 種類のビューがあります。

キューブ・ビュー

ディメンション・ビュー

階層ビュー
これらのビューは、データベースによって自動的に作成および管理されます。アプリケーション開
発者および DBA は、システムが保持しているキューブ・ビューから自由に新しいビューを作成でき
ます。
キューブ、ディメンション、および階層を表すビューのコレクションから、スター・スキーマが構
築されます。
キューブ・ビュー
キューブ・ビューは、キューブのファクト・データを表します。キューブ・ビューには、各キー(ディ
メンションを表す)と各ファクトの列が格納されています。キューブ・ビューの革新的な特徴は、
キューブ内のすべてのデータ(ストアド・メジャー、計算済メジャー、ディテール・データ、サマ
18
Oracle Database 11g Release 2 のオンライン分析処理
リー・レベル・データ)を表現している点です。つまり、アプリケーションは、ファクトがどのよ
うに集計または計算されるのかをまったく意識することなく、SQL による問合せを実行できます。
これにより、キューブ・ビューを、サマリー管理ソリューションとしても、豊富な計算方法を持つ
データソースとしても利用できます。
典型的なキューブ・ビューは、次のような列で構成されます。
名前
型
------------------------
--------------
TIME
VARCHAR2(100)
PRODUCT
VARCHAR2(100)
CUSTOMER
VARCHAR2(100)
CHANNEL
VARCHAR2(100)
SALES
NUMBER
UNITS
NUMBER
COST
NUMBER
PROFIT
NUMBER
SALES_YR_AGO
NUMBER
SALES_DIFF_YR_AGO
NUMBER
SALES_PCTDIFF_YR_AGO
NUMBER
SALES_YTD
NUMBER
SALES_YTD_YR_AGO
NUMBER
SALES_DIFF_YTD_YR_AGO
NUMBER
注 - キューブ・ビューの各列の役割と説明は、xxx_CUBE_VIEW_COLUMNS データ・ディクショナ
リ・ビューで確認できます。
ディメンション・ビュー
ディメンション・ビューと階層ビューは、どちらもディメンションでデータを表現します。この 2
つのビューはそれぞれ、尐しずつ異なる方法でディメンションを提示します。アプリケーションは、
必要に応じて、どちらか一方または両方のビューを使用できます。
ディメンション・ビューは、すべてのディメンション・メンバー(すべての階層のディテールおよ
びサマリー)を単一のビューで表します。行には、ディテール・メンバーとサマリー・メンバーの
両方が格納されます。列はキー列だけです。追加の列には、キー列のディメンション・メンバーの
属性が格納されます。
典型的なディメンション・ビューは、次のような列で構成されます。
名前
型
------------------------
-------------
DIM_KEY
VARCHAR2(100)
LEVEL_NAME
VARCHAR2(30)
LONG_DESCRIPTION
VARCHAR2(100)
SHORT_DESCRIPTION
VARCHAR2(100)
CUSTOMER_TOTAL_ID
VARCHAR2(100)
CUSTOMER_REGION_ID
VARCHAR2(100)
19
Oracle Database 11g Release 2 のオンライン分析処理
CUSTOMER_WAREHOUSE_ID
VARCHAR2(100)
CUSTOMER_SHIP_TO_ID
VARCHAR2(100)
CUSTOMER_MARKET_SEGMENT_ID VARCHAR2(100)
CUSTOMER_ACCOUNT_ID
VARCHAR2(100)
DIM_KEY 列はビューの主キーであり、ディメンションの各メンバー(ディテール・レベルとサマ
リー・レベルの両方)が格納されます。
LEVEL_NAME 列には、メンバーのレベルが格納されます。この例では、SHIP_TO、WAREHOUSE、
REGION、ACCOUNT、MARKET_SEGMENT、および TOTAL の各レベルがあります。LEVEL_NAME
列を参照することで、アプリケーションは、問合せが必要としているサマリー・レベルを簡単に特
定できます。
SHORT_DESCRIPTION および LONG_DESCRIPTION 列には、ディメンション・メンバーの分かりや
すい名前が格納されます。
_ID 列には、DIM_KEY 列のサマリー・レベル・メンバーが格納されます。これらは、特定のディメ
ンション・メンバーの祖先や子孫を見つけるのに便利です。
注 - ディメンション・ビューの各列の役割と説明は、xxx_DIMENSION_VIEW_COLUMNS データ・
ディクショナリ・ビューで確認できます。
階層ビュー
ディメンションの各階層には、1 つの階層ビューが対応します。階層ビューは、ディメンション・
ビューとほぼ同じですが、次の 3 つの点が異なります。

階層ビューには、その階層に属するメンバーに対応する行だけが格納されます。

階層ビューには、PARENT 列が含まれます。この列には、DIM_KEY 列のディメンション・メン
バーの親が格納されます。

階層ビューには、各レベルを表す 2 つの列があります。1 つはオリジナルのキーを表す列、もう
1 つは代理キーを表す列です。代理キーは、ディメンション表から OLAP ディメンションにデー
タをロードするプロセスの一部として、ディメンション内に生成されることがあります。3
階層ビューは、階層内をドリルアップまたはドリルダウンする問合せ、およびソース表にキューブ
を結合する問合せに特に有用です。
3
代理キーは、ディメンション・メンバーがソース表内のレベル全体で一意ではない(同名のメンバーが存在する)場合に、OLAP
ディメンション内に生成されます。
20
Oracle Database 11g Release 2 のオンライン分析処理
典型的な階層ビューは、次のような列で構成されます。
名前
型
DIM_KEY
VARCHAR2(100)
LEVEL_NAME
VARCHAR2(30)
LONG_DESCRIPTION
VARCHAR2(100)
SHORT_DESCRIPTION
VARCHAR2(100)
PARENT
VARCHAR2(100)
TOTAL
VARCHAR2(100)
CUSTOMER_TOTAL_ID
VARCHAR2(100)
REGION
VARCHAR2(100)
CUSTOMER_REGION_ID
VARCHAR2(100)
WAREHOUSE
VARCHAR2(100)
CUSTOMER_WAREHOUSE_ID
VARCHAR2(100)
SHIP_TO
VARCHAR2(100)
CUSTOMER_SHIP_TO_ID
VARCHAR2(100)
注 - 階層ビューの各列の役割と説明は、xxx_HIERARCHY_VIEW_COLUMNS データ・ディクショナ
リ・ビューで確認できます。
問合せの例
4 つのディメンション(Time、Product、Customer、Channel)と 1 つのキューブ(Units Cube)がある
前出の例を引き続き用いて、以下に問合せの例を示します。Time ディメンションには 2 つの階層、
すなわち Calendar と Fiscal があります。Customer ディメンションには 2 つの階層、
すなわち Shipments
と Segment があります。Product ディメンションと Channel ディメンションには 1 つの階層があり、
どちらも Primary という名前になっています。このモデルから次の 11 のビューが生成されます。

TIME_VIEW

TIME_CALENDAR_VIEW

TIME_FISCAL_VIEW

PRODUCT_VIEW

PRODUCT_PRIMARY_VIEW

CUSTOMER_VIEW

CUSTOMER_SHIPMENTS_VIEW

CUSTOMER_SEGMENTS_VIEW

CHANNEL_VIEW

CHANNEL_PRIMARY_VIEW

UNITS_CUBE_VIEW
21
Oracle Database 11g Release 2 のオンライン分析処理
次の問合せは、マテリアライズド・ビューの例で紹介した問合せに相当するものです。
SELECT t.time_calendar_quarter_id time,
p.product_class_id product,
cu.customer_region_id customer,
f.sales sales
FROM time_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
AND p.dim_key = f.product
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND t.level_name = 'CALENDAR_QUARTER'
AND p.level_name = 'CLASS'
AND cu.level_name = 'REGION'
AND ch.level_name = 'TOTAL';
この問合せはスター・クエリーのスタイルに従っていますが、マテリアライズド・ビューに対する
問合せとは次の点が異なっています。

ファクト列 SALES に集計演算子を必要としない。

集計演算子を使用しないため、GROUP BY 句を必要としない。

LEVEL_NAME 列に対するフィルタが含まれている。

CHANNEL_VIEW ビューと UNITS_CUBE_VIEW ビューの結合操作が含まれている。
これらの各変更点は、ディテール・レベルとサマリー・レベルの両データを含む革新的なキューブ・
ビューによって可能となったものです。ビューにはサマリー・レベルのデータが含まれているため、
アプリケーションはそのデータを直接問い合わせることができます。結果として、集計演算子と
GROUP BY 句を指定せずに済みます。
22
Oracle Database 11g Release 2 のオンライン分析処理
レベル・フィルタは、目的のサマリー・レベルを指定するために使用しています。4
また、CHANNEL_VIEW と UNITS_FACT_VIEW を結合しているのは、問合せがチャネル・ディメン
ションの TOTAL 値を利用できるようにするためです。この結合操作は、チャネルのすべてのディ
テール行を集計するのと同等です。
この例から分かる基本原則は、問合せはキューブによって提供される集計結果をそのまま利用でき
るということです。そのため問合せ内でデータを再集計する必要はありません。複雑な集計結果や
その他の計算結果は、キューブ内にすでに格納されているものをそのまま使用すれば良いため、非
常に簡単な SQL を使用してキューブに問い合わせることができます。この SQL の簡素化によって、
開発者の生産性を飛躍的に高めることができます。
ディテール・レベルとサマリー・レベルの両方のデータをキューブ・ビュー内に保持していると、
キューブ内で計算される特定タイプのデータを問い合わせるときにその価値が明らかになります。
もっともよくあるのは、次のようなケースです。

キューブが、キューブ固有の集計演算子を使用してサマリー・データを計算する場合。
たとえば、階層加重平均が挙げられます。

集計演算子がディメンションによって異なる場合。
たとえば、Time ディメンションには LAST 集計演算子を使用して、Account のような他のディメ
ンションには SUM を使用して、Ending Balance を計算するケースが挙げられます。

キューブが、集計できない特定タイプのメジャーを計算する場合。
たとえば、ランキングや変化率といったメジャーを、あるレベルから別のレベルに集計すること
はできません。その場合データを集計した後に、目的のレベルで計算を実行する必要があります。
このようなタイプの計算に共通するのは、SUM(または別の集計関数)や GROUP BY を用いて集計
することができないという点です。こうした集計はキューブ内で簡単に定義および実行できますが、
その場合、SQL 内で集計を実行してはなりません。
売上げ、年度累計売上げ、年度累計売上げ変化率を選択する例で考えてみます。
SELECT t.time_calendar_quarter_id time,
f.sales sales,
f.sales_ytd sales_ytd,
ROUND(f.sales_pctdiff_ytd_yr_ago,1) pct_chg_ytd
FROM time_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
AND p.dim_key = f.product
4
SUM 関数と GROUP BY 句を含めたとしても、この問合せの結果は変わらない点に注意してください。これは、この問合せは
このままでサマリー・データを返すためです。各行は一意であるため、この例では、GROUP BY 句を追加しても実際には何も変
わりません。
23
Oracle Database 11g Release 2 のオンライン分析処理
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND t.level_name = 'CALENDAR_QUARTER'
AND p.level_name = 'TOTAL'
AND cu.level_name = 'TOTAL'
AND ch.level_name = 'TOTAL' and t.time_calendar_year_id in
('CY2005','CY2006')
ORDER BY time;
TIME
SALES
SALES_YTD
PCT_CHG_YTD
---------
-----------
------------
-----------
CY2005.Q1
31381338.07
31381338.07
-4.8
CY2005.Q2
37642741.22
69024079.29
0.4
CY2005.Q3
32617248.57
101641327.86
-0.6
CY2005.Q4
35345244.10
136986571.96
-5.1
CY2006.Q1
36154818.61
36154818.61
15.2
CY2006.Q2
36815657.09
72970475.70
5.7
CY2006.Q3
32318934.94
105289410.64
3.6
CY2006.Q4
34848910.74
140138321.38
2.3
この例では、Month(月)レベルのデータから PCT_CHG_YTD を集計して、Quarter(四半期)レベ
ルの PCT_CHG_YTD を計算することはできません。このメジャーは、四半期ごとのデータを集計し
てから計算する必要があります。パーティション化された外部結合を含む非常に複雑な SQL を、
PCT_CHG_YTD を計算するキューブ内の 1 つの関数で置き換えることができるため、
アプリケーショ
ンは目的のサマリー・レベルでメジャーを選択するだけで済みます。
最後の例として、ドリルダウンとドリルアップ(折りたたむ操作)を行う問合せを考えてみます。
親子関係のデータが階層ビューに明示されるため、ドリルダウンとドリルアップを行う問合せは、
簡単かつ効率的に実行できます
次の問合せは、年内の各四半期にドリルダウンする様子を示しています。この例の問合せは、ドリ
ルダウンされた年とその子レベル(四半期)の両方のメジャー・データを返す点に注意してくださ
い。これにより、キューブ・ビューに対する問合せが非常に簡単になります。
SELECT t.dim_key time,
f.sales sales, f.sales_ytd sales_ytd,
ROUND(f.sales_pctdiff_ytd_yr_ago, 1) pct_chg_ytd
FROM time_calendar_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
24
Oracle Database 11g Release 2 のオンライン分析処理
AND p.dim_key = f.product
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND p.level_name = 'TOTAL'
AND cu.level_name = 'TOTAL'
AND ch.level_name = 'TOTAL'
AND(t.dim_key = 'CY2006' OR t.parent = 'CY2006')
ORDER BY time;
TIME
--------CY2006
SALES
SALES_YTD
PCT_CHG_YTD
-----------
------------
-----------
140138478.38
140138478.38
2.3
CY2006.Q1
36154975.61
36154975.61
15.2
CY2006.Q2
36815657.09
72970632.70
5.7
CY2006.Q3
32318934.94
105289567.64
3.6
CY2006.Q4
34848910.74
140138478.38
2.3
この問合せは、特定の親を持つメンバーを選択します。階層ビューはすべてのレベルのメンバーを
行として保持しているため、この問合せは、任意のメンバーの子に対して使用できます(この問合
せにはレベル・フィルタは必要ない点に注意してください)。
25
Oracle Database 11g Release 2 のオンライン分析処理
同様の問合せを使用して、特定のメンバーの親を見つけることができます。
SELECT t.dim_key time,
f.sales sales,
f.sales_ytd sales_ytd,
ROUND(f.sales_pctdiff_ytd_yr_ago,1) pct_chg_ytd
FROM time_calendar_view t,
product_view p,
customer_view cu,
channel_view ch,
units_cube_view f
WHERE t.dim_key = f.time
AND p.dim_key = f.product
AND cu.dim_key = f.customer
AND ch.dim_key = f.channel
AND p.level_name = 'TOTAL'
AND cu.level_name = 'TOTAL'
AND ch.level_name = 'TOTAL'
AND t.dim_key = (SELECT DISTINCT parent
FROM time_calendar_view
WHERE dim_key ='CY2006.Q2')
ORDER BY time;
これらの例から、SQL ベースのアプリケーションで列と階層属性を使用して、インタラクティブな
OLAP アプリケーション形式で簡単にキューブ・ビューに対して問合せを実行できることが分かりま
す。
キューブの設計と管理
ここまでで、キューブが、パフォーマンスと分析コンテンツの両面で、SQL ベースのディメンショ
ン対応ビジネス・インテリジェンス・アプリケーションに大きな利点をもたらすことが明らかにな
りました。キューブは、リレーショナル・データ型とデータウェアハウスに慣れているユーザーに
とって最初は特殊に感じることがありますが、作成と保守は難しくありません。
キューブベースのソリューションの作成には、2 つのフェーズがあります。第 1 フェーズは、キュー
ブの設計プロセスです。設計プロセスは、レポート要件と分析要件を定義することによって進めら
れます。また、通常は、OLAP 管理ツールである Analytic Workspace Manager を使用して実装されま
す。第 2 フェーズでは、キューブを新しいデータで定期的にリフレッシュします。このフェーズで
は、Analytic Workspace Manager、および Oracle Database 11g で新しく導入されたマテリアライズド・
ビュー・リフレッシュ・システムを使用します。
26
Oracle Database 11g Release 2 のオンライン分析処理
Analytic Workspace Manager
Analytic Workspace Manager は、Oracle アプリケーションの開発者、データベース管理者、IT 技術に
詳しい事業部門ユーザーが、キューブを作成および管理できるように設計されたツールです。
Analytic Workspace Manager を使用すれば、ユーザーは、ディメンション・モデルおよびキューブを
対話方式で直接操作できます。プロトタイプの作成とアプリケーション開発は、通常このような直
接対話方式で行います。Analytic Workspace Manager の設計で重視したのは、使いやすさ、モデリン
グ、集計やその他の計算の定義です。
Analytic Workspace Manager のおもな機能は、次のとおりです。

論理ディメンション・モデル(ディメンション、階層、キューブ)の定義

モデルのリレーショナル・データソースへのマッピング(スター、スノーフレーク、その他のス
キーマ)

集計とメジャー計算の定義

データのロードや再集計などの定期的メンテナンスの実行

モデルまたはモデルの一部を、テンプレートを介して他のユーザーやアプリケーションと共有で
きる協調型管理プロセスのサポート
一般的なキューブ作成プロセスは、次のとおりです。

ユーザー・コミュニティが求めるレポート要件に基づいた、論理ディメンション・モデル(ディ
メンション、階層、キューブ、ベース・メジャー)を設計する。モデルは必要に応じて、後で更
新可能です。

必要に応じ、
論理モデルを Oracle Database のソースにマップする。
これらのソースには、
表、
ビュー、
外部表であるフラット・ファイル、その他のリレーショナル・オブジェクトなどがあります。

最初のアナリティック・ワークスペースを作成する。これには、データのロードのほか、必要に
応じて、パフォーマンスを最適化するための一部データの集計も含まれます。

必要に応じて、新しいメジャー計算を定義する。

BI ツールまたはデータの問合せを行うアプリケーションのコンテキストで、設計を再確認する。

必要に応じて見直す。
Analytic Workspace Manager は、これらのプロセスを最初から最後まで、ディメンション対応の単一
の設計環境でサポートします。
27
Oracle Database 11g Release 2 のオンライン分析処理
Analytic Workspace Manager を使用して、キューブ編成のマテリアライズド・ビューを有効にします。
キューブ・マテリアライズド・ビューのリフレッシュ
いったんキューブを設計した後は、データを定期的に更新することがおもなキューブの管理作業に
なります。データの定期的な更新には、Analytic Workspace Manager またはマテリアライズド・
ビュー・リフレッシュ・システムを使用します。多くの企業は、スクリプトの作成が容易で、増分
リフレッシュによるパフォーマンスの向上を実現できるという理由で、本番環境ではマテリアライ
ズド・ビュー・リフレッシュ・システムを採用します。
マテリアライズド・ビュー・リフレッシュ・システムを使用すると、DBA は、DBMS_MVIEW.REFRESH
プログラムを呼び出すことで、表ベースのマテリアライズド・ビューと同じ要領でキューブ編成の
マテリアライズド・ビューをリフレッシュできます。DBMS_MVIEW.REFRESH では、第一引数にマ
テリアライズド・ビューの名前を指定します。データベース管理者は、マテリアライズド・ビュー
がキューブ編成されていることや、そもそもキューブが存在することも認識する必要はありません。
オブジェクトをマテリアライズド・ビューとして認識するだけです。これにより、キューブは日常
の管理業務から完全に透過的な存在になります。
高速リフレッシュは、ソース表に記録されているマテリアライズド・ビューのログを読み取り、挿
入、更新、削除が行われたかどうかを確認します。これらの変更は、キューブに増分的に適用され
ます。その後、キューブは増分的に事前集計されます。すなわち、新規のメンバーまたは変更され
たメンバーの祖先だけが再計算されます。
28
Oracle Database 11g Release 2 のオンライン分析処理
完全リフレッシュは、キューブ内のファクト・データの切捨て、ソース表からのすべてのデータの
ロード、キューブの集計5を実行します。この動作は、表ベースのマテリアライズド・ビューとまっ
たく同じです。
強制リフレッシュは、表ベースのマテリアライズド・ビューの場合と同様、可能な場合は高速リフ
レッシュを、高速リフレッシュが実行できない場合は完全リフレッシュを実行します。 Oracle
Database で高速リフレッシュが実行できない場合、ソース表の全データをキューブにロードします。
ソース表からの完全リフレッシュ後、キューブは増分的に事前集計を実行できます。
組込み OLAP ソリューションのその他の利点
ここまでで、Oracle データベースにキューブを導入するおもな利点の 1 つとして、1 つのキューブが
3 つの役割を果たすことが明らかになりました。3 つの役割とは、SQL ベースのアプリケーションに
対するサマリー管理ソリューション、SQL ベースのアプリケーションに対する豊富なコンテンツ・
データソース、ディメンション指向アプリケーションに対する多次元サーバーです。これらの複数
の使用法と、データ・ディクショナリに格納されるビジネス・インテリジェンス・メタデータを併
せて利用することで、企業は、キューブに対する投資を多くのアプリケーションで活用できます。
キューブのマテリアライズド・ビュー・リフレッシュの説明から、データベース管理者の視点から
見たときの、Oracle Database に統合された OLAP の利点は明白です。キューブのマテリアライズド・
ビュー・リフレッシュ機能は、キューブに対する更新を(マテリアライズド・ビュー・ログからの
自動増分ロードによって)より効率的に行い、キューブの管理を透過的にするという 2 つの目的を
実現するために設計されたものです。
データベース内でのキューブの透過性は、よく取り上げられるテーマです。このテーマは、SQL 問
合せやマテリアライズド・ビュー・リフレッシュをはじめ、データベース管理の他のさまざまな側
面にも登場します。キューブの透過性に関して重要な点は、次のとおりです。

OLAP は Oracle インスタンス内に組み込まれています。
別途ソフトウェアをインストールしたり、
インスタンスを管理したりする必要はありません。また、サーバー・コンピュータを追加する必
要もありません。

OLAP キューブは、Oracle データファイル内に格納されます。キューブは、データベース内の他
のデータとともにバックアップおよびリストアされます。独自のプロセスや特別な手順は必要あ
りません。

OLAP ユーザーは、普通のデータベース・ユーザーと同等です。キューブを作成および管理する
ための専用ユーザーやエンティティは存在しません。

Oracle キューブは、
標準の Oracle データベース機能によってセキュリティ保護されています。SQL
GRANT と REVOKE を使用することで、OLAP キューブ、ディメンション、キューブ・ビュー、
ディメンション・ビュー、階層ビューに対するアクセスを許可または拒否できます。また、仮想
プライベート・データベースを使用することで、キューブ、ディメンション、階層の各ビューに
対するアクセスも制御できます。Oracle Extensible Data Security フレームワーク内で、キューブ・
5
キューブは通常、パフォーマンスを最適化するため、部分的に事前集計されます。ほとんどの場合、ごく尐量のデータが事前
集計され、キューブに格納されます。
29
Oracle Database 11g Release 2 のオンライン分析処理
セキュリティをきめ細かく定義できます。

OLAP は、Oracle Real Application Clusters および Oracle Grid Computing に完全対応しているため、
高い信頼性とスケーラビリティが実現されます。
要するに、OLAP キューブは、データベース内の新しいデータ型であり、データ型として管理される
ということです。キューブは、膨大なサマリー・データを管理し、高度な計算を実行する高度なデー
タ型です。したがって、設計プロセスではこの点を考慮する必要があります。ただし、キューブや
OLAP について専門知識のないデータベース管理者でも、キューブの日常管理業務を容易にこなすこ
とができます。
結論
Oracle Database 11g の OLAP キューブを使用すると、企業ではすでに使用しているビジネス・インテ
リジェンス・アプリケーションの問合せパフォーマンスが高まり、分析コンテンツを強化できます。
キューブ編成のマテリアライズド・ビューを使用することで、アプリケーションはキューブ内で管
理されているサマリー・データに透過的にアクセスできるため、問合せパフォーマンスが即座に向
上します。また、SQL アプリケーションは、キューブに埋め込まれている豊富な分析コンテンツを
利用できるため、多様な分析要件に対応できます。さらに、簡単な SQL を用いたキューブの分析コ
ンテンツへのアクセスにより、開発者の生産性が大幅に向上し、アプリケーションの開発が簡素化
されます。
OLAP オプションは、すでに導入済みの Oracle Database 11g の組込みオプションです。OLAP キュー
ブは、組込み型のソリューションであるため、エンタープライズクラスのリレーショナル・データ
ベースである Oracle のアーキテクチャと機能による恩恵をそのまま受けることができます。Oracle
キューブは、高いセキュリティ、スケーラビリティ、管理性を備えています。そのため、企業は、
手持ちのデータベースやサーバー・コンピュータ、および蓄積したスキルを活かして、使いやすく
コスト効率の高い OLAP ソリューションを手にすることができます。
30
Oracle Database 11g Release 2 の
オンライン分析処理
2009 年 9 月
著者:William Endress
Copyright © 2009, Oracle and/or its affiliates. All rights reserved.
本文書は情報提供のみを目的として提供されており、ここに記載される内容は予告なく変更されることがあります。本文書は一
切間違いがないことを保証するものではなく、さらに、口述による明示または法律による黙示を問わず、特定の目的に対する商
品性もしくは適合性についての黙示的な保証を含み、いかなるほかの保証や条件も提供するものではありません。オラクル社は
本文書に関するいかなる法的責任も明確に否認し、本文書によって直接的または間接的に確立される契約義務はないものとしま
す。本文書はオラクル社の書面による許可を前もって得ることなく、いかなる目的のためにも、電子または印刷を含むいかなる
形式や手段によっても再作成または送信することはできません。
Oracle は米国 Oracle Corporation およびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。
0109
Fly UP