多次元モデルのメリット - oracle tech network...

多次元モデルのメリット

Oracleホワイト・ペーパー 2006年 5月


2

Oracle Corporation発行「Benefits of a Multi-Dimensional Model」の翻訳版です。


概要 ...................................................................................................................... 3 はじめに .............................................................................................................. 4 多次元構造 .......................................................................................................... 5 製品概要......................................................................................................... 5 ビジネスのモデル化..................................................................................... 5 ディメンション........................................................................................... 13 レベル ..................................................................................................... 13 階層 ......................................................................................................... 14 ディメンション・クエリー条件 ......................................................... 17 多次元クエリー ..................................................................................... 19

クエリーの妥当性検証............................................................................... 20 キューブ......................................................................................................... 8 メジャー......................................................................................................... 8 結合 ........................................................................................................... 9 キューブ・ベースの計算 ..................................................................... 11

まとめ ................................................................................................................ 22


3



概要

今日、あらゆる組織が、月単位、週単位、日単位、時間単位で膨大な量のデータ

を取得しているという問題に直面しています。技術の進歩とともに、いかに効果

的にデータを分析するかという問題は、増加する一方のデータを保管することよ

りも重要になっています。

そうしたデータを正しい方法とフォーマットで使用すれば、ユーザーは競争上

の優位性を得られるものであるというのが組織の認識です。顧客ベースから購

買パターンを抽出する能力は、企業の収益性に非常に大きな影響をもたらしま

す。ただし、多くのユーザーにとっては、競争上の優位性に結びつく状況を作

り出す能力には、その基本となるデータ・モデルが複雑なものであるという問

題が伴います。

ユーザーにはこうしたデータ・モデルの複雑さを理解することは困難です。ユー

ザーは多くのツールや製品で、表結合やシーケンシングといった最も難しいコ

ンセプトに接することを余儀なくされています。こうした複雑さのため、ユー

ザーは基本となるスキーマを調べたり、分析したりする意欲を失い、最悪の場

合、構文的には正しくても、事実としては正しくない結果をもたらすクエリー

を作り出すことになります。

この問題の解決策の 1つとして、リレーショナル・スキーマをビジネス定義の

中に含め、キューブ、メジャー、ディメンションなどの単純なビジネス関連オ

ブジェクトの周囲に問合せ言語と構文を含める方法があります。これらのオブ

ジェクトはすでに事前結合と事前集計が実行されており、ユーザーは整合性の

ある、構文的にも事実としても正しい結果を毎回得ることができます。こうし

たビジネス指向環境は、しばしばオンライン分析処理（OLAP）と呼ばれます。

OLAP環境では、ユーザーが任意のディメンションに関係するキューブ内でトレン

ド、パターンおよび異常状態を追うためのデータを得られるよう、強力な分析デー

タ・ソースが用意されています。Oracle OLAPの場合、統計、予想、計画および回

帰分析といった、ユーザーによる理論的な業務管理を可能にする分析計算オプショ

ンが設定されています。

本書では、多次元モデルをデータ・ウェアハウス環境でどのように使用すれば、

ユーザーが理論的なデータ分析を行えるビジネス主導型クエリーを作成すること

ができるかについて取り上げます。


4


はじめに

ユーザーが OLAPモデルを有力なものと考える理由は何でしょう。ユーザーは、

毎日ビジネス言語を使って会話をします。売上、原価、流通チャネル、顧客、時

間などの言葉で環境について語ります。こうしたビジネス定義をサポートする

データは、通常リレーショナル表に保存されています。このリレーショナル表を

使用してクエリーを作成する場合、データベース内でさまざまなテーブル同士が

どのように関係しあっているかを理解する必要があります。ユーザーにとって、

問合せ言語の性質と構造は強制されるものであり、また多くの場合、問合せ言語

はユーザーには外国語同様意味不明なものです。理想をいえば、ビジネス・ユー

ザーは通常の職場における対話と同じ定義および同じ用語を使って、データ・ク

エリーを実行することを希望しています。

多くの特別なクエリー・ツールでは、エンド・ユーザーの経験を豊富にするため、

独自の構造レイヤーあるいはメタデータ・レイヤーを備えています。こうしたメ

タデータ・レイヤーは、テーブルと列との関係に関して、より多くの情報を保存

することができます。場合によっては、追加構造が関係する列でのドリル能力な

ど、他のメリットをユーザーにもたらします。ただし、追加メタデータは、主と

して、レポート内でのフォーマットやレイアウトの管理に使用されます。

一般的レポート・ツールでは、こうした追加構造が持つポテンシャルのすべてが

活用されるわけではありません。データ・ウェアハウス・スキーマに構造を追加

することのメリットを全面的に活かすには、単純なリレーショナル・データ・モ

デルから多次元モデルへの移行が必要です。

ユーザーは、データがビジネス・エンティティ（ディメンション）やデータ項目

（キューブ、メジャー）を中心として構造化されるものと考えます。本書の以下の

セクションでは、3つのキー・コンセプトに基づいた多次元モデルを使用するこ

とのメリットについて説明します。

ビジネス・ルールのモデル化

キューブとメジャー

ディメンション

レポート・ツールでは、これらのコンセプトによって、ユーザーが、強力で、ビ

ジネスに焦点を絞ったクエリーを迅速かつ簡単に作成することができ、その結果、

追加のドリルダウンやピボット操作の間にクエリーを拡張することで、一貫性の

ある有効な分析を実行することができます。


5


多次元構造

概要

クエリー・テクノロジへの深い理解は、1つの組織内のすべてのユーザーにとっ

ての理想的な解決策というわけではありません。リレーショナル分析には、1つ

の基本的ストレージ構造が存在します。それがフラット・テーブルです。このオ

ブジェクトは、他のテーブルとの関係や結合に応じて、さまざまな役割を担いま

す。スター・スキーマでは、ファクト表とディメンション表により、そのスキー

マにある各種テーブル間の関係が記述されます。ファクト表が、クエリー内での

通常のメイン・ドライバとなります。

多次元分析にも、同じ基本構造が存在します。ファクト表はキューブ、テーブル

内の列はメジャーとそれぞれ呼ばれます。各キューブには、シンプルなテーブル

の上に追加構造が設定されます。キューブにはディメンションと呼ばれるエッジ

があります。各ディメンションは、1つ以上のテーブルの共通する列、または関

係する列を単一のエンティティにグループ化したものです。たとえば、製品ディ

メンションは、カテゴリ、サブカテゴリおよび製品を参照する列を含む単一、も

しくは複数のテーブルをベースにすることができます。

これらの構造（キューブ、メジャー、ディメンション）は、すべて相互に関わっ

ていて、非常に強力なレポーティング環境を構築します。各オブジェクトは、十

分に活用することで新しいレベルのインタラクティビティをもたらします。

多次元モデルを使用することは、問合せ言語に SQLを使用しないということでは

ありません。単に、多次元環境で提供される追加構造メタデータを理解し、活用

するために、サポートとなるクエリー製品が必要となるだけです。実際に、 Oracle

OLAP BIレポート製品はすべて SQLを使用しており、多次元クエリーを実行しま

す。ただし、このことは、あらゆるデータベース・セマンティクスから分離され

ることを希望するエンド・ユーザーにとっては興味のないことです。ユーザーは

ビジネス用語やオブジェクトを使用して、基本となっているストレージ・モデル

を理解する必要なく、対話形式によってデータを利用することを望んでいます。

物理的ストレージ・モデルを論理的プレゼンテーション・モデルから分離するこ

とが、多次元モデルの成功のカギとなります。

ビジネスのモデル化

リレーショナル・データ・モデルを使用し、表結合のコンセプトをマスターする

のは難しいことではありません。ほとんどの特殊クエリー・ツールでは、ユーザー

は基本的なリレーショナル・コンセプトを理解する必要がありません。テーブル

やビューは、通常、フォルダなどのコンセプトにマッピングされます。管理者が

必要な結合の作成、メタデータの追加、および列名やフォルダ名の変更をするこ

とで、リレーショナル・オブジェクトが拡張されます。

図 1 - 製品ディメンション


6


図 2 - リレーショナル・スキーマの図

ただし、新たなメタデータを追加した場合であっても、ユーザーは問合せ言語が持

つ構造的性質に左右され、また、ある程度は物理的ストレージ・オブジェクトの構

造的性質の影響も受けます。多次元モデルは、スキーマの視覚化を、よりビジネス

に特化した環境へと変換します。多次元モデルは 3つの基本的オブジェクトで構成

されています。その 3つとは、キューブ、メジャー、ディメンションです。

図 3 ‒ 多次元スキーマ


7


キューブはファクト表から外挿されます。キューブには、共通のディメンションを

有するメジャーが含まれており、メジャーはファクト表に属する単一の列にリンク

されています。また、それぞれに、ビジネス・ルールが定義と共に直接組み込まれ

ています。

レポートに組み入れるファクトを選択する場合、ユーザーは、通常、適用する集計

のタイプを決定する必要があります。これは、収益や原価といった単純なファクト

に関しては簡単に行えます。しかし、人員数や在庫といった複雑なファクトに関し

ては、正しく対応することが容易ではありません。ビジネス・ユーザーの間では広

く知られたことですが、多くのファクトには、その集計方法を規定する複雑なビジ

ネス・ルールがあります。たとえば、在庫の場合、その数値は一定の時点における

ポジションを表しているため、時間経過に伴う集計は必要ありません。在庫は SUM()

演算子を使用し、製品に基づいた集計が可能ですが、時間経過に伴う集計では最終

値が必要になります。クエリーを作成するときに、ユーザーがこうしたビジネス・

ルールを理解していると期待することは妥当ではありません。こうしたルールはビ

ジネス・モデルの中に含めておき、ユーザーが意識しないようにします。多次元モ

デルであれば、このレベルの分離が可能であり、ユーザーはファクトに適用した集

計タイプを設定するよう求められることはありません。

売上

製品

時間

製造者

ブランド

品目

継続

総和

月四半期年

郵便番号市

州

顧客

加重平均

図 4 - 組み込まれたビジネス・ルール

ディメンションは 1つ以上のテーブルの複数の列を、1つ以上の階層を中心とした

単一のエンティティにまとめ、レベル順に並べ替えます。これらのオブジェクトは、

次のような非常にシンプルなクエリー・インタフェースとして表示されます。


8


図 5 - 多次元モデル

キューブ

キューブとは、多次元データの論理的組織です。キューブはファクト表から派生

します。キューブのデータは、ディメンションによって分類され、同じディメン

ションを持つメジャーが含まれます。エンド・ユーザーにとっては、キューブよ

りもその中に含まれているメジャーの方が重要なため、通常キューブを意識する

ことはありません。

メジャー

メジャーは配列と同様に、物理的ファクト表の列や関係するディメンション表へ

自動的に関連付けられます。ファクト表列からメジャーへの変換により、ユーザー

は基本となっているスキーマを理解する煩雑さや、スキーマの各部分がどのよう

に結合されているかを理解する必要性を回避できます。

メジャーの間ではディメンションを共有することができます。たとえば、価格と

原価で、製品、チャネル、時間という同じディメンションを共有できます。ただ

し、販売数量のようなメジャーは、製品、地理区分、チャネル、時間というディ

メンションで表されます。OLAP環境では、売上収益や売上原価といった新しい

メジャーを作成する場合、数量×価格と数量×単価という計算を別々に行うだけ

であり、極めて簡単です。結果として得られる変数はディメンションであり、数

量と同じ構造を持ちます。そのため、新しいメジャーのディメンションは、製品、

地理区分、チャネル、時間となります。

多次元の Oracle OLAP Query Builderを使用する場合、ユーザーは最初に分析する

メジャーを選択します。メジャーの選択、もしくはメジャーのグループ化は、関

連付けられたディメンションをすべて自動的に選択するよう設定できるため、結

合の管理はユーザーに代わって自動で実行されます。


9


結合

リレーショナル・データ・モデルは、複数のテーブルを結合するために必要とな

ります。そうした結合の複雑さや数は、スキーマによって決まります。Oracle 10g

Common Schemaの場合、スター・スキーマをベースにしているため、結合は比較

的シンプルです。

図 6 - Oracle 10g Common Schemaスター・スキーマ図

スター・スキーマは、リレーショナル・クエリー・ツール用にデータ・モデルを

簡素化します。ただし、ユーザーはクエリーに加えるテーブルや必要な列、およ

び無視するテーブルや列の決定を行う必要があります。クエリーから列やテーブ

ルを除外することは、結果に大きな影響を与えます。ユーザーは列を除外するこ

との意味を理解していなければなりません。

クエリーのドリルダウンや、分析計算の追加により、データ・モデルを対話形式

で処理する場合、エンド・ユーザーはこの単純化されたレイヤーから、より複雑

な詳細へと進むことができます。一方、多次元環境では、結合プロセスはユーザー

ではなくクエリー・ツールが管理するため、ユーザーは基本となっているスキー

マから分離されます。したがって、ユーザーはサポートしているスキーマ構造に

惑わされることなく、データ分析に集中できます。

ユーザーは、テーブルを結合して結果セットを生成したり、結合の実行、不実行

による特定のテーブルへの影響を把握する必要がなくなります。これが、多次元

モデルが持つ大きな利点の 1つです。下図に示されているように、リレーショナ

ル・スター・スキーマの多次元モデルは極めてシンプルです。


10


収益

原価

利益

製品

時間販売促進

地理区分

チャネル

全製品

部門

カテゴリ

製品

全地域

地域

下位地域

国

年

四半期

月

全販売促進

カテゴリ

サブカテゴリ

販売促進

全チャネル

チャネル・クラス

チャネル

図 7 - Oracle 10g Common Schema多次元モデル

このモデルにおけるメジャーの重要性は、すべてのユーザーに対して均一な情報

を提供できる点にあります。メジャーはディメンションによって制限されるため、

ユーザーは自由にキューブを切り分け、独自のメジャー・ビューを作成すること

ができます。たとえば、ブランド・マネージャは、複数の期間やマーケットにお

ける製品グループに着目し、金融アナリストは、すべてのマーケットと製品を対

象に現行期間とその直前の期間に注目します。地域担当セールス要員は、特定の

マーケットにおける全期間および全製品を調べ、経営戦略を担当する役員は、特

定の地域だけで販売した革新的製品について、現行四半期と次四半期といった企

業データのサブセットを調べます。

ユーザーは、キューブ構造の特定や理解をすることなく、同じデータをそれぞれ

の目的に合った形で表示し、操作することができます。これとは逆に、多くのリ

レーショナル・ベースのレポーティング環境では、このような種類のマルチ・

ビューを作成するために、複雑な自己結合文が必要になります。

多次元データは暗黙のうちに結合されるため、以下のようなクエリーはリレー

ショナル・モデルよりも多次元モデルで迅速に実行できます。

階層を含むレポート：多次元モデルでは、階層関係はデータベースの明示

的オブジェクトです。こうした関係によって、各レベル内の階層レベルや

メンバーが決定されます。したがって、クエリーやレポートは、結合によっ

て新しい関係を作成するかわりに、このような関係を参照します。ユー

ザーは使用する階層を選択し、表示する階層レベルを選択します。

時間

製品

マーケット

財務マネージャ

の視点

製品マネージャ

の視点

地域マネージャ

の視点

特殊な視点


11


期間相互比較：多次元モデルでは、マトリックス算法を使用して期間相互

比較を実行します。マトリックス演算では、データの列と行の両方につい

ての計算が可能です。

キューブ・ベースの計算

多次元モデルは拡張することができます。ユーザーは、迅速かつ簡単に計算式を

追加できる必要があります。計算式を作成するには、関連するキューブの構造か

らユーザーを分離することが必要です。

販売量価格売上額

図 8 - 計算済みメジャーの作成

オラクルの多次元 Calculation Builderは、新たな計算式やキューブを作成するため

のシンプルで使いやすいインタフェースを提供します。エンド・ユーザーはテン

プレートを使用して新しいメトリクスを定義するため、基本となっている技術的

な詳細を理解する必要がありません。

多くのデータ・ウェアハウスでは収益のトラッキングが行われています。レポー

トという観点からは、収益それ自体がモニターに対して重要なメジャーとなりま

す。しかし、ほとんどのユーザーは、収益増加のトラッキングに関心があります。

多次元モデルの場合、時間という特殊なタイプのディメンションがあります。時

間ディメンションには、多次元エンジンによる時間ベースの分析を可能にする重

要なメタデータが含まれています。時間ディメンションを定義する構造やレベル

を理解することで、前期比による成長率など、単一の計算式を作成できます。こ

のモデルでは、各階層レベルに関して直前の期間を正しく設定することができ、

そのため、Q1が Q2の直前の期間であること、1月が 2月の直前の期間であるこ

とを認識しています。

このような計算は、すべてテンプレートを介して管理されます。テンプレートは

タイプ別にまとめられています。先ほどの例でいえば、エンド・ユーザーは適切

な時系列テンプレートを選択して、新しいメジャーを定義します。

その結果、新しいメジャーを含めるためのウェアハウスの拡張に関しては、ユー

ザー自らが対応できます。特に重要なことは、計算済みメジャーが通常のメジャー

とまったく同じように扱われる点です。つまり、ソース・メジャーとしてまった

く同じディメンションを共有することになります。計算済みメジャーはネストす

ることも可能です。

図 9 ‒ Calculation Builder


12


オラクルの多次元ツールには、次の計算テンプレートが設定されています。

グループ名計算名

基本算法加算減算乗算除算比

高度算法累計指数比例マークアップ比例差異ランクシェア差異

過去、将来比較過去の値過去の値との相違過去の値との相違率将来の値

タイムフレーム移動平均移動最大値移動最小値移動合計年度累計

これら計算済みメジャーの使用に関する制限はありません。ユーザーは条件付き

フォーマットやトラフィック・ライト・レポートを計算済みメジャーに基づいて

作成することができます。ディメンションは、計算済みメジャーから得られた条

件に基づいてフィルタリングすることができます。


13


ディメンション

ディメンションによって、ビジネス・エンティティに関係する情報が特定され、

分類されます。ディメンション・メンバーはディメンション表に保存されます。

各列は階層内のレベルを表します。スター・スキーマでは、列はすべて同じテー

ブルにあります。スノーフレーク・スキーマでは、列は各レベルの異なるテー

ブルにあります。OLAPツールがこの情報をエンド・ユーザーに表示するとき、メンバーは値をまとめた 1つの長いリストとして表示されます。OLAPエンジンは、リレーショナル表の列をディメンション・メンバーの 1つの列に変換します。この変換プロセスを以下に示します。

図 10 - リレーショナル表のディメンション・モデル

最も基本的なレベルで、ユーザーはディメンションによって、メンバー・リスト

の展開や折りたたむことができます。図の左に示されているように、メンバー

「Channel Total」が展開され、その下にあるメンバーが全表示されています。さまざまな特殊クエリー・レポート・ツールにも、シンプルなドリル操作が用意され

ています。ただし、そうしたドリル操作はアプローチが統一されておらず、ユー

ザーは十分なクエリー機能を利用することができません。

レベル

レベルによって、ディメンション内での個々のメンバー値の順番が決まります。

レベルは、ディメンション内で重要なグループを特定する際に使用されます。ユー

ザーはレベルによって、迅速かつ簡単にディメンション・メンバーのグループや

クラスタを選択することができます。このコンセプトは、リレーショナル・デー

タ・モデル内では通常隠されています。しかし、多次元クエリー・モデルにとっ

ては非常に強力な機能となります。また、ユーザーによる自己保持式の動的構造

主導の選択を可能にします。

多くのリレーショナル・クエリー・モデルにおいて、ユーザーはファクトに基づ

き、あるいはクエリー作成用のメンバーやキーを手動で選択し、データをフィル

タリングするのが普通です。たとえば、2004年第 24週における、アメリカ、ヨーロッパ、その他の地域におけるカメラの総売上高はどのくらいだったかというク

エリーについて考えてみます。

図 11 - レベルの活用


14


この例では、ユーザーはディメンション・メンバーであるカメラを選択し、次に必

要な地域と期間を選択します。ただし、このタイプのクエリー生成は構造的に静的

であり、エラーが起こりがちです。データ・ウェアハウス環境は静的ではありませ

ん。企業は定期的にスキーマを再編します。そのため、その他の地域を中東とオセ

アニアに変更した場合、上記のクエリーは機能しなくなります。構造的に認識され

なくなります。そのため、構造的に誤ったレポートが表示されることになります。

この新しい地域を含めるには、クエリーを書き直さなければなりません。

それには、クエリー自身に自動で書き直しを実行させることです。多次元モデル

はこの有効な機能をサポートしています。ユーザーは構造的条件に基づいてクエ

リーを作成することができ、そのクエリーはディメンションの構造的コンポーネ

ント（レベル）と直接連動します。

そこで、上記のクエリーは次のように書き直すことができます。

地理区分ディメンション内のレベルである地域において、時間ディメンション

の最終週でのカメラの総売上高はどれくらいであったか。

データ・ウェアハウスの構造は進化するものであることから、クエリーは自動的に

アップデートされ、2つの新しい地域である中東とオセアニアが取り込まれること

になります。そのため、多次元モデルの別の重要な機能が注目されることになりま

す。それは各ディメンションの独立クエリーの作成です。この後、このコンセプト

について詳しく説明します。

階層

階層によって、ディメンション内でのレベルの順番が決まります。また、ディメン

ション・キーの親子関係も明確になります。ほとんどの階層は、レベルをベースと

して定義されます。つまり、階層内のあるレベルと次のレベルの関係という点で、

構造はシンプルになります。たとえば、レベルベースの地理区分階層は次のように

なります。

全地域

州

郡

市

アカウント

ただし、ほとんどのディメンションが複数の階層を持っており、Oracle OLAP内

では、1つのディメンションに割り当てる階層の数に制限はありません。


15


代表的多階層シナリオは、地理区分ディメンションで次のように作成することが

できます。

全地域

州

郡

市

アカウント

全地域

セールス・マネージャ

セールス要員

アカウント

この例では、2つの階層が最高レベルの全地域であり、また同じリーフ・ノード

であるアカウントを持っています。したがって、すべてのセールス・マネージャ

の合計は、すべての州の合計と正確に一致します。

ただし、すべての階層が上述した階層のように常にシンプルとは限りません。多

くの組織で広く見られる階層には、この他に 3つのタイプがありますが、単純な

リレーショナル・レポート・モデルでは一般的に利用できるものではありません。

価値ベース

スキップ・レベル

不調和

価値ベース

価値ベースの階層は、レベルによるディメンションの組織化が不可能な、大半の

組織階層を代表するものです。たとえば、典型的な組織では、同じ役職が複数の

レベルに現れます。

King 社長

Blake アナリスト

Allen アナリスト

James 事務員

Clark 販売員

Ward 販売員

Turner アナリスト

この場合、"販売員"というレベルは 2つあります。Wardが Clarkの部下で、この

2人が共に"販売員"であるためです。


16


スキップ・レベル

スキップ・レベル階層は、主にあるレベルの親レベルが複数存在するコンシュー

マ小売環境に見られます。たとえば、ある製品ディメンションで、ブランドレベ

ルにあるいくつかのディメンション・キーに、カテゴリレベルの親が複数あり、

サブカテゴリレベルにも親があるといった場合です。多くのリレーショナル・レ

ポーティング製品において、エンド・ユーザーはこのデータ・モデルを理解し、

どのブランドがどの親レベルに対してレポートされるかを把握しておく必要があ

ります。ドリルは非常に複雑で理解しにくいものになります。

これとは逆に、多次元環境の場合、ユーザーは単純に階層をドリルすることがで

き、基本ロジックはスキップ・レベルの問題をシームレスに管理することができ

ます。これが、ディメンション、レベル、階層の関係を、ディメンション・キー

と親キーの組合せを持つシンプルなテーブルとして管理する理由です。そのため、

アプリケーション・ロジックにとって（結果的にユーザーにとっても）、スキッ

プ・レベルを極めて簡単に横断できるようになります。

不調和

不調和階層は、データが同じ階層の異なるレベルにロードされる不調和レベルを

ベースとします。この場合も、エンド・ユーザーは、スキーマの観点からの理解

を必要とします。このタイプのスキーマは、さまざまな組織やコスト・センター

構造内の異なるレベルで、予算の計画化が実行される金融タイプ・アプリケーショ

ンで広く使用されます。

階層の活用 - 親と子

階層はさまざまな方法で導入が可能であり、データはさまざまなレベルで表示す

ることができるため、こうした階層構造を利用するにはユーザーは新たなインテ

リジェント・セマンティクスを必要とします。

多次元階層から生まれた追加構造コンセプトは親と子に関係します。1つのディ

メンション内に階層を構築することで、新たなメタデータが作成され、ユーザー

は関係に基づいた条件を使って値を選択することができます。ディメンション選

択を作成するためには、次の条件を使用します。

選択説明

親階層で 1つ上のレベルのディメンション・メンバーを返します。前述の例では、ユーザーが市の親を要求した場

合、郡が返されます。

子階層で 1つ下のレベルのディメンション・メンバーを返します。前述の例では、ユーザーが郡の子を要求した場

合、市が返されます。

兄弟階層で同じレベルのすべてのディメンション・メンバー

を返します。前述の例では、ユーザーが郡の兄弟を要求

した場合、すべての郡が返されます。

図 12 - 親子情報の活用


17


上位階層内で選択したメンバーより上の全レベルのディメン

ション・メンバーを返します。前述の例では、ユーザー

が市の上位を要求した場合、選択された市に関係する郡

と州が返され、また、階層の最上位レベルとして全地域

が返されます。

下位階層内で選択したメンバーより下の全レベルのディメン

ション・メンバーを返します。前述の例では、ユーザー

が州の下位を要求した場合、すべての郡と市が返されま

す。

最上位選択したメンバーより上の階層内で最上位レベルのディ

メンション・メンバーを返します。前述の例では、ユー

ザーが市の最上位を要求した場合、階層の最上位レベル

である全地域が返されます。

最下位選択したメンバーより下の階層内で最下位レベルのディ

メンション・メンバーを返します。前述の例では、ユー

ザーが州の最下位を要求した場合、市がその階層の最下

位レベルであるため、その州内の市が返されます。

この新しいクエリー・メソッドは、データ・ウェアハウスの構造から直接生じる、

動的で自己保持的クエリーの作成を可能にする強力な手段です。また、このクエ

リー・メソッドは、ユーザーがデータを構造化し、対応する構造をナビゲートす

る方法を反映します。

ディメンション・クエリー条件

これまでの例は極めてシンプルなものであり、各ディメンションに対し、それぞれ

のスペースで個別にクエリーを実行できるものでした。これらの例では、ファクト

表内の特定の列に対する直接リンクは示されていませんでした。これは、多次元分

析では、どのディメンション値をターゲット・プレゼンテーションに表示するかと

いうこととは無関係に、対話形式によって各ディメンションが使用できるためです。

また、ディメンション・クエリーは、単一のステップをベースにするということ

はほとんどなく、多くのステップで構成されます。リレーショナル・モデルの場

合、ユーザーはリターンする値を決定する際、SQLのセマンティクスと AND/OR

ルールの重要性を理解しなければなりません。リレーショナル・モデルの大きな

問題は用語にあるというよりも、ユーザーがフィルタリング対象の列ではなく、

クエリー全体への影響を理解しなければならない点にあります。通常、クエリー

の重要コンポーネントを分離し、分離した状態で条件を設定することでクエリー

を構築します。リレーショナル・モデルでは、ユーザーはすべての要素を 1つの

ものとして取り扱わねばならず、混乱と予想外の結果がもたらされることがあり

ます。


18


これと対照的に、多次元モデルでは、ユーザーは各ディメンションを分離してフィ

ルタリングし、追加、保持、除外といったなじみのある用語を使用することがで

きます。ユーザーは次のように、迅速かつ簡単に多段階のクエリーを作成するこ

とができます。

利幅の前年比においてカリフォルニアで最も成績がよい 5つの市を選別

せよ。

この質問は 2段階のシンプルなクエリーになります。

カリフォルニアから開始する

前年比の利幅が最もよい上位 5つの市を保持せよ。

このクエリーの構文は、ユーザーがクエリーを記述した場合の構文と極めて似て

いる点に注目してください。クエリーの作成をできるだけシンプルなものにする

ため、Oracle OLAP BI Dimensional Query Builderでは、分析条件の作成プロセスを

案内するテンプレートを用意しています。

データ主導クエリーと構造的メタデータに基づいたクエリーの作成を支援するた

めに、次のようなタイプのテンプレートがあります。

グループ例外タイプ

例外売上収益>1000 売上収益>原価売上収益>原価＋10 売上収益>原価－10％売上収益が原価の 10以内売上収益が原価の 10％以内ではない売上収益が 5000から 10000の間

上/下売上収益のトップ 10位売上収益のトップ 10％売上収益のトップ 10％を構成

階層全地域の子カリフォルニアの全レベル全地域

時間/序数最後/最初の州

一致名前に含まれる

Oracle OLAP Query Builderウィザードで上記のリストが表示されます。クエリー・

テンプレートを使うことで、ユーザーは、自分の要件に正確に合うようクエリー

をカスタマイズすることができます。クエリーの各パートはハイパーリンクに

なっていて、ユーザーはデフォルト・ステートメントを変更することができます。

上位/下位グループの場合、グループの最初のテンプレートを使い、数字を 10か

ら 5に変更するだけで、クエリーに基づいたトップ 5を簡単に作成することがで

きます。

図 13 - 条件の作成

図 14 - ‘最上位’条件の作成


19


多次元クエリー

多次元クエリー・モデルには、リレーショナル・クエリー・モデルに比べて、1

つ大きな利点があります。各ディメンションに対し個別にクエリーを実行できる

点です。そのため、非常に複雑になりかねないクエリーを、シンプルで管理の容

易なステップに置き換えることができます。例として、以下のクエリーについて

検討してみます。

米国地域での売上収益ベースでトップ 5のブランドが、3つの主要流通チャネル

を通じてヨーロッパ内のトップ 5地域ではどの程度売れているかを知りたい。

クエリーとしては複雑で、単純なリレーショナル分析ツールを使用した場合には

構築するのが困難です。ユーザーは各列の異なる条件間の相互作用を理解し、全

体的な結果セットへの影響を理解しなければなりません。しかし、OLAPモデル

におけるディメンション上の独立性から、このクエリーはシンプルなステップに

簡単に分解することができます。

1. 売上収益に基づいて、レベルであるブランド用の製品ディメンションで

トップ 5クエリーを構築します。

2. 地理区分ディメンションで 2段階クエリーを構築します。ディメンショ

ン値であるヨーロッパを選択し、売上収益に基づいたトップ 5である地

域を保持します。

3. チャネルディメンションで流通チャネルを選択します。

4. 最後に、関連するディメンション・メンバーを選択して手動、またはク

エリー条件を使用して、直近の 3ヶ月または直近の 3四半期など、期間

を選択します。

上述したように、多次元モデルは非常に強力なフィルタリング能力を備えていま

す。さらに、最終レポートに含まれないメジャーに基づいて条件を作成すること

もできます。ディメンション・クエリーはフィルターからは独立しているため、

条件の構造を決定する際に極めて高度なフレキシビリティを発揮します。たとえ

ば、レポートには以下のような事項を表示させることができます。

売上収益

売上収益の対前年比

売上収益の 6ヶ月間移動平均

ただし、米国地域での売上収益ベースでトップ 5のブランドが、3つの主要流通

チャネルを通じてヨーロッパ内のトップ 5地域ではどの程度売れているかを分析

することは可能です。

こうした機能によって、ユーザーは非常に大きなフレキシビリティを得ることが

できます。ただし、複雑なクエリーを作成する場合、行が返されない可能性は常

に存在します。では、マルチディメンション・モデルであれば、この問題も解決

できるでしょうか。

図 15 - 時間ベースのインテリジェント・

クエリーの作成


20


クエリーの妥当性検証

複数のステップで構成されるクエリーを作成することは、行が返されない可能性

をもたらします。リレーショナル・データ・モデルのユーザーにとっては、通常、

どの結合あるいは条件が原因なのかが不明なので、これは極めて大きなストレス

をもたらす問題となります。こうなると、SQLセマンティクスの中心部および基

本となるスキーマの構造の解明に着手することになります。

ディメンション・クエリーは、個々のディメンション・オブジェクトを中心に

構成されています。各クエリーは他とは分離された状態で作成されるため、ディ

メンション・クエリー・ツールを使用すれば、個々のディメンション・クエリー

を実行した際の結果を迅速かつ簡単にチェックできます。一連のクエリー・ス

テップを構築した後、クエリーに対してデータ行が返されるかどうかは、クエ

リー・ウィザードのメンバー・パネルを使ってクエリー・ステップの結果を表

示すれば確認できます。したがって、ユーザーはレポートやグラフを作成する

ことなく、クエリーの結果をチェックすることで、返された結果が予測と一致

するかどうかを知ることができます。

時間ディメンション

各メンバーのタイム・スパンや最終日付などに関する追加情報を必要とする、特

殊な‘時間’ディメンションが存在します。これらの追加属性により、オラクル

の多次元モデルは、‘通常’のディメンションと比較した場合、新たな機能を提

供することができるのです。

時間ディメンションが定義されると、追加の計算テンプレートが用意されます。

これらのテンプレートでは、時間ベースの属性を使用して、次のような時間ベー

スの計算を理論的に管理します。

• 過去の値

• 過去の値との相違

• 過去の値との相違率

• 将来の値

• 移動平均

• 移動最大値

• 移動最小値

• 移動合計

• 年度累計

これらの機能は、階層内のすべての期間を通じて、自動的にその方向性を決定

します。年単位値や四半期単位値を計算する式を定義する必要はありません。

多次元モデルでは、定義することも可能ですが、そうした複雑な操作をすべて

自動的に管理することができます。そのため、1つの計算で、年、四半期、月、

週、日に関する計算を正確に行うことができます。

図 16 - メンバー機能を使用してのクエリー・

ステータスのチェック


21


このクエリー・モデルでは、クエリー・テンプレートを使用して、時間インテリ

ジェント・ステップを設定することが可能です。たとえば、次のようなステップ

が可能になります。

• ‘05年 1月’から始まる 6ヶ月

• 直近の 3ヶ月


22


まとめ

あらゆる組織で、取り扱うデータ量が急速に増加しています。そうしたデータに

含まれる知識を、競争上の優位性に変換することが求められています。多くの人

が情報には力があることを知っています。顧客ベースの購買パターンを把握でき

れば、企業の収益に極めて大きな貢献をもたらします。しかし、そうした変換は、

ユーザーがデータに正しい方法とフォーマットでアクセスした場合に限り可能に

なるものです。

ユーザーが理論的な方法で情報を調べ、分析できるよう、企業は膨大な時間と資

源を費やして、リレーショナル・データベース・スキーマを構造化し整理しよう

としています。それは、エンド・ユーザーが実行する分析プロセスの簡素化となっ

て現れようとしています。そのデータベースの構造化および整理の手段として最

高峰に位置するのが多次元モデルです。このモデルにより、ユーザーはデータ・

ウェアハウス・スキーマにアクセスし、迅速かつ簡単にデータを高品質の情報に

変換することができます。また、データベースとの対話を、職場での日常業務に

使用しているビジネス指向の言語や用語を使用できるため、ユーザーによるセル

フサポートが実現します。

オラクルのOLAP多次元モデルは、市場に類を見ない独創的なソリューションです。

多次元モデルのメリット 2006年 5月著者： Keith Laker Principal Product Manager Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. お問合せ：電話: +1.650.506.7000 Fax: +1.650.506.7200 www.oracle.com Copyright © 2003 – 2006, Oracle. All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載され

る内容は予告なく変更されることがあります。本文書は一切間違いが

ないことを保証するものではなく、さらに、口述による明示または法

律による黙示を問わず、特定の目的に対する商品性もしくは適合性に

ついての黙示的な保証を含み、いかなる他の保証や条件も提供するも

のではありません。オラクルは本文書に関するいかなる法的責任も明

確に否定し、本文書によって直接的または間接的に確立される契約義

務はないものとします。本文書はオラクルの書面による許可を前もっ

て得ることなく、いかなる目的のためにも、電子または印刷を含むい

かなる形式や手段によっても再作成または送信することはできません。

Oracleはオラクルおよびその子会社、関連会社の登録商標です。その他の名称はそれぞれの会社の商標です。

多次元モデルのメリット - oracle tech network...

Documents