JP2008544382A - 関係データベースクエリと多次元データベースクエリとを変換するシステムおよび方法 - Google Patents

Abstract

未知の構成のデータソースを既知の構成のデータソースにマッピングする方法であって、メタデータ要求を未知の構成のデータソースにサブミットするステップと、未知の構成のデータソースから受け取ったメタデータに基づいて、既知の構成から関係スキーマを生成するステップと、生成された関係スキーマのメタデータを返すステップであって、返されるメタデータは未知の構成のデータソースを既知の構成にマッピングするステップと、を含む方法。好ましい実施形態では、未知の構成のデータソースは多次元データベースであり、既知の構成はスター関係スキーマまたはスノーフレーク関係スキーマである。

Description

関連出願の相互参照

本発明は、オンライン分析処理（ＯＬＡＰ）の分野に関し、特にＯＬＡＰおよび非ＯＬＡＰツールが多様な多次元データベースにアクセスできるようにするシステムおよび方法に関する。

オンライン分析処理（ＯＬＡＰ）および意思決定支援システム（ＤＳＳ）は、考えられる様々な情報のビューへの高速双方向アクセスを提供することにより、管理職者が洞察を得られるようにする。

こういったシステムは、通常はデータウェアハウスに収容される良質で一貫性のあるデータへのアクセスに依存する。データウェアハウスは、組織の広範囲のデータベースおよびデータソースからのデータを統合する。データウェアハウスはＯＬＡＰシステムの１つの構成要素にすぎない。ＯＬＡＰシステムは、基本的なナビゲーションおよび閲覧（多くの場合「スライスアンドダイス（ｓｌｉｃｅ ａｎｄ ｄｉｃｅ）」として知られている）および計算から時系列およびモデリング等のより本格的な分析に及ぶ機能を提供する。

ＯＬＡＰシステムは、データをＯＬＡＰ機能の提供のために最適化された専用データベース（データウェアハウス）に移すことにより実施されることがある。多くの場合、受け入れ側のデータストレージの設計は多次元である。

多次元データベース（ＭＤＢ）は、データウェアハウスおよびＯＬＡＰ用途に向けて最適化されたデータベースの一種である。

ＯＬＡＰシステムは、それぞれいくつかの次元を有する多次元キューブ、すなわちハイパーキューブを定義するために使用され、ハイパーキューブでの動作をサポートするはずである。動作としては、例えば、スライシング、値のグループ化、ドリルダウン、ロールアップ、キューブの異なるハイパープレーンまたは射影の表示、代数演算、および集成体型動作が挙げられる。

ＭＤＢは、ほぼ例外なく既存の関係データベースからの入力を使用して作成される。したがって、大半のＯＬＡＰシステムは、関係データベースからデータを読み取ってＯＬＡＰキューブに入れる内蔵ツールまたはインタフェースを有する。

この関連で、図１を参照してデータウェアハウスの概要を示す。情報がまず、別個のサーバによりオペレーションソースから抽出され、次にクリーニングおよび変換が行われて、データウェアハウスにロードされる（ＥＴＬ）。多くの場合、ＯＬＴＰ（オンライントランザクション処理）システムから導出される生産データは、異種のリモートリポジトリの集まりに常駐し、１つのクリーンストアに統合できるようになるまでには相当なマッサージを受けなければならない。

データは、リモートソースから抜き出されるとデータウェアハウスに配置され、この時点では大抵、関係データベースである。データウェアハウス自体は、一企業規模のエンティティおよび／または企業データの何等かのサブセットをそれぞれ含む一連のデータマートとして構築することができる。いずれの場合でも、ＤＳＳシステムに実際に分析機能を供給するのはＯＬＡＰサーバの仕事になる。

実際には、ＲＯＬＡＰ（関係ＯＬＡＰ）およびＭＯＬＡＰ（多次元ＯＬＡＰ）として知られている２つの形態のＯＬＡＰサーバがある。これらの違いは、システムの内部がどのように編成されるかに関係する。概念上、それぞれの目的は類似する。

最後に、フロントエンドツールが、ユーザフレンドリ（多くの場合、グラフィカル）インタフェースを、システムを利用する知識労働者に提供する。

ＲＯＬＡＰデータベースは、多くの場合、周知のスタースキームまたはスノーフレークスキームで並べられ、ファクトテーブルを示す中央のプライマリテーブルが次元テーブルを示すいくつかのセカンダリテーブルに関連付けられる。１つのファクトテーブルが多くの次元テーブルに関連付けられる。ファクトテーブルは、計算のベースとなるデータを含む。ファクトテーブル内のデータは最も詳細な情報を含む。次元テーブルは、計算をグループ化したいデータを含む。他のテーブルに基づく計算から生じるテーブル内のデータは、集計データと示される。

オープンデータベース接続（ＯＤＢＣ）を使用して、データを既存の関係データベースからインポートして、ＯＬＡＰ用の多次元データベースを作成することができる。

２つの主要なＯＬＡＰ製品は、ハイペリオンソリューション（Ｈｙｐｅｒｉｏｎ Ｓｏｌｕｔｉｏｎ）のエスベース（Ｅｓｓｂａｓｅ）およびオラクル（Ｏｒａｃｌｅ）のエクスプレスサーバ（Ｅｘｐｒｅｓｓ Ｓｅｒｖｅｒ）である。ハイペリオンエスベースは、エスベースインテグレーションサービス（ＥＩＳ：Ｅｓｓｂａｓｅ Ｉｎｔｅｇｒａｔｉｏｎ Ｓｅｒｖｉｃｅｓ）を介してメタデータ駆動環境を提供して、ハイペリオンエスベースに構築されたビジネス分析アプリケーションを関係データベースに記憶されている詳細データと統合する。ＥＩＳは、ビジネス分析アプリケーションの作成、開発、および管理の時間および費用を劇的に削減するグラフィカルツールスイート、データ統合サービス、およびメタデータカタログを提供する。ＥＩＳは、データおよびメタデータを、ＩＢＭ ＤＢ２、オラクル、テラデータ（Ｔｅｒａｄａｔａ）、マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）ＳＱＬサーバ、サイベース（Ｓｙｂａｓｅ）、およびインフォミックス（Ｉｎｆｏｒｍｉｘ）を含むすべての主要な関係データベースからデータをハイペリオンエスベースに移す方法を提供する。

ＯＬＡＰ市場に伴う問題の１つは、成長しているが、断片化した市場であることである。競合製品間の相互運用性は、非標準ＡＰＩ（アプリケーションプログラムインタフェース）、他のこのような基本技術、および競争の圧力により、あったとしても最小であった。多次元データベースの主要なクエリ言語はＭＤＸであり、これはＯＬＡＰデータベースを照会するために作成され、分析アプリケーションの分野内で広く利用されるようになった。ＭＤＸは、ＯＬＡＰ用ＯＬＥ ＤＢの言語構成要素をなし、多次元データソースのクエリ発行の標準としてマイクロソフト株式会社により設計された。

データの多次元概念ビュー、次元動作、集計、直観的データ操作、および報告を提供するために、広範囲のソフトウェアツールがＯＬＡＰユーザに提供されている。しかし、こういったツールは高価であり、多くの場合、ＯＬＡＰ市場範囲の独自のＭＤＢインプリメンテーションと相互運用性がない。

したがって、この相互運用性の制約に取り組む必要がある。

本発明の利点は、多次元データベースがデータを異なる種類の多次元データベースから調達できるようにし、それにより、異なるデータベースベンダーからのデータベース間に相互運用性を提供することである。

本発明の別の利点は、多次元データベースを特にサポートしない関係データベースツールを多次元データベースと併せて使用できるようにすることである。例えば、マイクロソフトエクセル（Ｍｉｃｒｏｓｏｆｔ Ｅｘｃｅｌ）のＳＱＬ機能を本発明の一実施形態と併せて使用して、多次元データソースを読み取ることができる。

本発明は、ＳＱＬクエリを発行して関係データベースからデータをインポートする現在のＯＬＡＰサーバの機能を利用し、この既存の機能を使用することで、ソースＯＬＡＰキューブ内にあるデータを宛先ＯＬＡＰキューブに移し、その結果、宛先ＯＬＡＰキューブで動作可能な分析ツールをソースＯＬＡＰキューブデータに対して使用することができるようになる。

広い態様では、本発明は、関係データベースクエリを多次元データベースクエリに変換するシステム、方法、およびインタフェースを提供する。通常、こういった関係クエリはＳＱＬクエリであるのに対して、多次元データベースクエリはＭＤＸクエリである。

本発明の第１の態様によれば、未知の構成のデータソースを既知の構成のデータソースにマッピングする方法であって、
ａ．メタデータ要求を未知の構成のデータソースにサブミットするステップと、
ｂ．未知の構成のデータソースから受け取ったメタデータに基づいて、既知の構成から関係スキーマを生成するステップと、
ｃ．生成された関係スキーマのメタデータを返すステップであって、返されるメタデータは未知の構成のデータソースを既知の構成にマッピングするステップと、
を含む方法が提供される。

第１の態様の一実施形態では、未知の構成のデータソースは多次元データベースである。

第１の態様のさらなる一実施形態では、既知の構成はスタースキーマまたはスノーフレークスキーマである。

本発明の利点は、新しいキューブをデータソースに動的に追加できることである。

第１の態様のさらなる一実施形態では、方法は、
ａ．データ消費者から、生成された関係スキーマに対するデータクエリを受け取るステップと、
ｂ．受け取ったクエリをデータソースによりサポートされる１つまたは複数のクエリに変換するステップであって、それにより、データソースからデータを検索するステップと、
ｃ．データソースから検索されたデータをデータ消費者に返すステップと、
を含む。

本発明の第２の態様は、データソースにサブミットされるクエリを変換する方法であって、クエリはデータソースによりサポートされない言語のものであり、方法は、
ａ．データ消費者からクエリを受け取るステップであって、クエリは既知の構成のスキーマに基づくステップと、
ｂ．受け取ったクエリを、データソースによりサポートされる１つまたは複数のクエリに変換するステップであって、それにより、上記既知の構成から生成されたスキーマおよび上記データソースからのメタデータを使用してデータソースからデータを検索するステップと、
ｃ．上記データソースから検索されたデータをデータ消費者に返すステップと、
を含む方法を提供する。

本発明の第３の態様は、データ消費者により発行される、データソースによりサポートされていない言語のクエリをデータソースがサポートする言語のクエリに変換するアダプタであって、
ａ．既知の構成の関係スキーマを生成する手段と、
ｂ．上記既知の構成に対するクエリを受け取るインタフェースと、
ｃ．データソースを表すモデルオブジェクトを含むメタデータモデルと、
ｄ．上記データソースを上記既知の構成でデータ消費者に提示する変換アルゴリズムと、
を備えるアダプタを提供する。

各種態様の一実施形態では、未知の構成のデータソースは多次元データベースであり、既知の構成はスター関係スキーマまたはスノーフレーク関係スキーマであり、データソースのサポートされる言語ＭＤＸであり、サポートされない言語はＳＱＬである。

本発明の一実施形態では、アダプタは、ＳＱＬを入力とし、ＭＤＸクエリを多次元データソースに対して実行するＯＤＢＣドライバである。

本発明のさらなる実施形態では、アダプタは、多次元キューブのスタースキーマまたはスノーフレークスキーマで、関係テーブルの概念セットに基づいてビューを提示して、ＯＬＡＰデータベースシステムにインポートする。さらなる実施形態では、多次元キューブはＳＡＰ ＢＷ（ビジネス情報ウェアハウス）キューブであり、ＯＬＡＰデータベースシステムは、ハイペリオン統合サービス（ＥＩＳ）を有するハイペリオンエスベースである。

特定の一実施形態では、アダプタは、ＯＤＢＣ、ＪＤＢＣ、またはＯＬＥ−ＤＢを介してアクセスされるＯＤＢＣドライバである。

一実施形態または緒実施形態をこれより単なる例として、図面を参照して説明する。

以下を参照により援用する。
[ＧｏＦ９５］Ｅ．ガンマ（Ｇａｍｍａ）、Ｒ．ヘルム（Ｈｅｌｍ）、Ｒ．ジョンソン（Ｊｏｈｎｓｏｎ）、Ｊ．ブリシデス（Ｖｌｉｓｓｉｄｅｓ）：Ｄｅｓｉｇｎ Ｐａｔｔｅｒｎｓ−Ｅｌｅｍｅｎｔｓ ｏｆ Ｒｅｕｓａｂｌｅ Ｏｂｊｅｃｔ−Ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ、アディソン−ウェスレイ（Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ）、１９９５年
［ＰＯＳＡ１］Ｆ．ブッシュマン（Ｂｕｓｃｈｍａｎｎ）、Ｒ．ムニエ（Ｍｅｕｎｉｅｒ）、Ｈ．ローネルト（Ｒｏｈｎｅｒｔ）、Ｐ．ゾンメルラード（Ｓｏｍｍｅｒｌａｄ）、Ｍ．スタル（Ｓｔａｌ）：Ｐａｔｔｅｒｎ−Ｏｒｉｅｎｔｅｄ Ｓｏｆｔｗａｒｅ Ａｒｃｈｉｔｅｃｔｕｒｅ−Ａ Ｓｙｓｔｅｍ ｏｆ Ｐａｔｔｅｒｎｓ−第１巻、ウィリー（Ｗｉｌｅｙ）、１９９６年
［ＤｅｖＧｕｉｄｅ］シンバテクノロジーズ（Ｓｉｍｂａ Ｔｅｃｈｎｏｌｏｇｉｅｓ）：Ｄｅｖｅｌｏｐｍｅｎｔ Ｇｕｉｄｅ Ｆｏｒ Ｗｉｎｄｏｗｓ

以下の説明では、同様の符号は図中の同様の構造を指す。以下の定義により、多次元ビューを反映した、ＯＬＡＰにとって基本的な概念を紹介する。

「次元」はデータを分類する構造である。一般に使用される次元としては、顧客、製品、および時間が挙げられる。通常、次元には１つまたは複数の階層が関連付けられる。メジャー（ｍｅａｓｕｒｅ）と組み合わせられたいくつかの別個の次元により、エンドユーザがビジネスでの質問に答えられるようにする。例えば、月でデータを分類する時間次元は、質問「１月または６月は製品の売り上げが多かったか」に答えるのに役立つ。

「メジャー」は、調べて分析できるデータ、通常は数値および加算を含む。通常、１つまたは複数の次元が所与のメジャーを分類し、これは「次元化」と記述される。

「階層」は、親子関係で次元要素を編成する手段として順序付きレベルを使用する論理構造である。通常、エンドユーザはレベルをドリルダウンまたはドリルアップすることで階層を拡張または折り畳むことができる。

「レベル」は階層中の位置である。例えば、時間次元は、日、月、四半期、および年のレベルでデータを表す階層を有し得る。

「属性」は、エンドユーザがデータ選択のために指定できる次元の要素の記述的特徴である。例えば、エンドユーザは、カラー属性を使用して製品を選択することができる。いくつかの属性は、他のテーブルへのキーまたは関係を表すことができる。

「クエリ」は、クエリの結果セットと呼ばれる特定のデータセットの仕様である。仕様は、データの選択、集計、計算、または他の操作を要求することができる。このような操作が要求される場合、それはクエリに固有の部分である。

「スキーマ」は関係データベースオブジェクトの集まりである。２種類のスキーマ、すなわちスタースキーマおよびスノーフレークスキーマがデータウェアハウスの特徴である。スタースキーマは、１つまたは複数の次元テーブルに関係する１つまたは複数のファクトテーブルを含む。関係は、外部キーおよびメタデータを通して定義される。スノーフレークスキーマは、スタースキーマを一部または完全に正規化して、次元テーブル内で値が重複する数を低減したものである。

例えば、スタースキーマは、４列、すなわち市、州、地域、および国を有する１つの地理次元テーブルを有し得る。市列のみが主に一意の値を有するのに対して、その他の列では重複する値の数が増える。スノーフレークスキーマは、３つの関係する地理次元テーブルを有することができ、１つのテーブルには、市と州との関係を定義する２つの列（市および州）があり、第２のテーブルには、州と国との関係を定義する２つの列（州および国）があり、第３のテーブルには、地域と国との関係を定義する２つの列（地域および国）がある。

「キューブ」は多次元データの論理編成である。通常、キューブの次元は次元値を含み、キューブの本体はメジャー値を含む。例えば、売り上げデータは、時間、製品、および顧客の各次元からの値を次元に含み、売り上げメジャーからの値を本体に含むキューブに編成することができる。

「メタデータ」−通常、ＯＬＡＰアプリケーションは、分析する情報を蓄える関係データベースと異なる概念モデルを利用する。そのため、ＯＬＡＰアプリケーションが実行されると、要求されたデータが関係データベースからフェッチされ、ＯＬＡＰアプリケーションが使用できる多次元形態に変換される。データを正しくフェッチして処理するためには、フェッチされる関係データベースの列とこれら列の役割とを識別しなければならない。この識別はメタデータにより行われる。

メタデータは、データを正しくフェッチして計算するために関係データベース内のデータおよびオブジェクトを記述するデータである。一般に、メタデータは、データソースが存在すること、ならびにそのデータソース内のデータの構造および特徴を意味するものと解釈することができる。例えば、販売個数（ｕｎｉｔｓＳｏｌｄ）メジャーが存在すること、販売個数メジャーが数値を含むこと、ならびに販売個数メジャーが地理および製品により次元化されることはメタデータとみなされる。これとは対照的に、１９９８年にフロリダ州タラハシー（Ｔａｌｌａｈａｓｓｅｅ，Ｆｌａ．）で製品が３０個売れたことはデータとみなされる。次元メンバに関して、地理次元が存在すること、およびこれがメンバとしてストリング値を含むことは、メタデータの別の例であるが、地理が特定のストリング「フロリダ州タラハシー」を含むことはデータである。同様に、地理に対して定義される標準と呼ばれる階層があること、およびこれが市、州、および地域と呼ばれる３つのレベルを含むことはすべてメタデータとみなされるが、「フロリダ州タラハシー」が「フロリダ（Ｆｌａ．）」の子であることはデータとみなされる。

したがって、メタデータは、ＯＬＡＰアプリケーションが分析のために多次元オブジェクトを定義できるように、関係データベース内で利用可能なデータについてＯＬＡＰアプリケーションに通知するために使用される。ＯＬＡＰアプリケーションは、実行されると、これら多次元オブジェクトをインスタンス化し、データベースからフェッチされたデータを投入する。

関係データベースの基本データモデルは、１列または複数列のデータを含むテーブルである。関係データベーステーブル内のデータはすべて、列で記憶される。これとは対照的に、基本多次元データモデルはキューブであり、メジャー、次元、および属性を含む。したがって、関係データベース内の特定の列からのデータが、多次元形態でメジャーとして機能するのか、次元として機能するか、それとも属性として機能するのかを識別することが重要である。さらに、どの列が関係データベースからのデータのインデックス付け及びフェッチのためのキーであるかをメタデータに識別させることが重要である。これら判断はメタデータおよび制約として記憶される。

特に、メタデータは、関係データベーステーブルに記憶されているファクトに対応するものとして多次元メジャーを定義する。用語「ファクト」は、通常、関係データベースで使用され、用語「メジャー」は、通常、多次元アプリケーションで使用される。したがって、メジャーはファクトテーブルに配置される。通常、ファクトテーブルは２種類の列、すなわちメジャー（またはファクト）および次元テーブルへの外部キーである。メジャーは、売り上げまたはコスト等の分析するデータを含む。本発明の一実施態様では、列がメジャーとして識別されるべき数値データ型または日データ型を有する必要がある。さらに頻繁に、メジャーは数値および加算である。次元テーブル内の１つまたは複数の列が、ファクトテーブルへの制約を形成する。これら制約は、ファクトテーブル内の外部キーおよびメタデータのうちの一方または両方により定義される。

次元は、ＯＬＡＰアプリケーションデータを識別して分類する。関係データベースシステムでは、次元メンバは次元テーブルに記憶される。各列は階層内の特定のレベルを表す。スタースキーマでは、列はすべて同じテーブル内にあり、スノーフレークスキーマでは、列は各レベル毎に別個のテーブル内にある。通常、メジャーは多次元であるため、メジャー内の１つの値が各次元のメンバにより有意であると見なされなければならない。例えば、販売メジャーは、製品、地理的エリア、および時間の次元を有し得る。販売メジャー内の値（３７８５４）は、製品（ＤＶＤプレーヤ）、地理的エリア（環太平洋）、および時間（２００１年３月）により適格であると見なされた場合のみ意味を持つ。データウェアハウスで次元を定義すると、メタデータが作成されることに加えてデータベース次元オブジェクトが作成される。次元オブジェクトは、次元テーブル内の列間の親子関係の詳細を含み、データを含まない。データベース次元オブジェクトは、データウェアハウスを最適化するためにサマリアドバイザおよびクエリリライトにより使用される。しかし、多次元側では、次元は、個々の製品の名称、地理的エリア、および時間期間等のデータを含まない。ＯＬＡＰ ＡＰＩは、メタデータ、次元オブジェクト、および次元テーブルを使用して、次元を構築する。

階層は、レベルに従ってデータを編成する一つの方法である。次元は、分析および表示のために異なる集計レベルのデータを一緒に効率的に操作できるように階層的に構造化される。各次元は少なくとも１つのレベルを有さなければならない。各レベルは階層内の位置を表す。レベルは、集計のためにデータをグループ化し、計算のために内部で使用される。ベース（または最低）レベルよりも上の各レベルは、それ未満のレベルの集計合計を表す。例えば、時間次元は時間次元階層のレベルに日、週、四半期、および年を有し得る。売り上げメジャーのデータが日で記憶される場合、より高いレベルの時間次元により、売り上げデータを週、四半期、および年に正しく集計することができる。異なるレベルにある階層のメンバは、１対多の親子関係を有する。例えば、「ＱＴＲ１」および「ＱＴＲ２」は「ＹＲ２００１」の子であり、したがって、「ＹＲ２００１」は「ＱＴＲ１」および「ＱＴＲ２」の親である。２つ以上の階層が次元に対して定義される場合、階層は同じベースレベルを有さなければならない。例えば、暦年に１つ、会計年に１つ、合計２つの階層を時間次元に定義することができる。両方の階層はベースレベルに日を使用する。次元の全レベルは次元テーブルに記憶される。次元は複数の階層を有することができるが、それらはすべて同じベースレベルを有さなければならない。そのレベルの値は、次元テーブルをファクトテーブルに結合するために使用されるキーに記憶される。

属性は、特定のレベルにある次元メンバについての補助情報を提供する。時間期間の「Ｔ２９６」の値のように次元メンバ自体は意味を持たないため、多くの場合、属性は表示に使用される。例えば、従業員数（ＥＮＵＭ）、姓（ＬＡＳＴ＿ＮＡＭＥ）、名（ＦＩＲＳＴ＿ＮＡＭＥ）、および内線番号（ＴＥＬＮＯ）に列があり得る。ＥＮＵＭは、キー列であり、その値は従業員を一意に識別するため、レベルに最適な選択である。ＥＮＵＭはまたＮＵＭＢＥＲデータ型も有し、インデックスの作成がテキスト列よりも効率的になる。ＬＡＳＴ＿ＮＡＭＥ、ＦＩＲＳＴ＿ＮＡＭＥ、およびＴＥＬＮＯは属性である。ＥＮＵＭにより次元化されても、これらはビジネス測度ではなく記述テキストであるため、適したメジャーにならない。属性には、次元階層の特定のレベルが関連付けられ、そのレベルと同じテーブルに記憶されなければならない。

図２を参照して、本発明の一実施形態による、データ消費者により発行されるクエリをデータソース２０２のクエリに変換するアダプタ１８０の構造を示す。アダプタは、ＡＰＩブリッジ１８２（ＪＤＢＣ等の特定の接続に向けて構成される）、ウィンドウズ（Ｗｉｎｄｏｗｓ）またはユニックス（Ｕｎｉｘ）アプリケーションがデータにアクセスするためのデータアクセスインタフェースを提供するＯＤＢＣシェル１８４、ＯＤＢＣ関数呼び出しを処理し、ＳＱＬ文をパーズし、データベースレコードマネージャ（ＤＲＭ）２００を通してデータにアクセスする最適なプランを生成するクエリプロセッサ１８６であって、データベースレコードマネージャ（ＤＲＭ）２００はデータソース２０２にマッピングするための低レベル関数セットを提供するクエリプロセッサ１８６、通常はＳＱＬエンジンを含む。ＤＲＭ２００は、クエリプロセッサ１８６を介して受け取ったＳＱＬ要求をＯＬＡＰアクセスクエリに変換して、多次元データソース２０２にアクセスする。ＤＲＭは各データソースに向けてカスタマイズされる。アダプタ１８０の新規の態様をより詳細に以下において説明する。ＡＰＩブリッジ１８２、ＯＤＢＣシェル１８４、およびクエリプロセッサ１８６は、通常、当分野において周知であるため、詳細に説明しないと理解されたい。クエリプロセッサ１８６の一実施態様の一例は、ＯＤＢＣ２．５標準およびＳＱＬ−９２シンタックスをサポートするシンバテクノロジーズ（Ｓｉｍｂａ Ｔｅｃｈｎｏｌｏｇｉｅｓ）によるシンバエンジン（ＳｉｍｂａＥｎｇｉｎｅ）として知られているＳＱＬエンジンである。

アダプタの中心には、変換層２０６およびＯＬＡＰアクセス層２０８を含むＤＲＭ２００がある。一実施形態では、変換層２０６は仮想スタースキームまたはスノーフレークスキームをクエリエンジン１８６に提示する。変換層２０６の下には、多次元データソース２０２と通信するＯＬＡＰアクセス層２０８がある。ＯＬＡＰアクセス層２０８は、特定の多次元データソース２０２との作業に関わる詳細をカプセル化する。本実施形態を、ＭＤＸ言語をサポートする多次元データソース２０２に関連して説明するが、本発明のアダプタはあらゆる多次元データソースと通信するように拡張可能である。

本発明の特定の一実施態様を、ハイペリオンエスベース統合サービス（ＥＩＳ）を使用してＳＡＰ ＢＷに接続するＯＤＢＣドライバの提供に関連して説明する。ＯＤＢＣドライバは、ＯＤＢＣドライバ開発用のＳＤＫである、先に参照したシンバエンジンを使用して開発された。

上述したように、ＭＤＸは、多次元データソースとの通信に使用される最も一般的な言語であり、現在、ＳＡＰ ＢＷ、マイクロソフト分析サービス（Ｍｉｃｒｏｓｏｆｔ Ａｎａｌｙｓｉｓ Ｓｅｒｖｉｃｅｓ）、ハイペリオンエスベース、アプリックス（Ａｐｐｌｉｘ）ｉＴＭ１、ＭＩＳアレア（ＭＩＳ Ａｌｅａ）、ＩＮＥＡ、アレリ（Ａｌｅｒｉ）、アームストロングレイングＥＰＯ（Ａｒｍｓｔｒｏｎｇ Ｌａｉｎｇ ＥＰＯ）、デシシス（Ｄｅｓｃｉｓｙｓ）のテラソルブ（ＴｅｒａＳｏｌｖｅ）等によりサポートされている。

ＭＤＸはクエリ言語であるが、ＭＤＸデータソースに接続するために使用されるアクセスプロトコルは、ＯＬＡＰ用ＯＬＥ ＤＢ（ＯＤＢＯ）またはアナリシス用ＸＭＬ（ＸＭＬＡ）である。したがって、本発明によるアダプタは、ＯＤＢＯまたはＸＭＬＡを介してあらゆるＭＤＸデータソースに接続することができる。

動作に関して、アダプタ１８０はスタービューまたはスノーフレークビューのキューブを提示する。データ消費者は、仮想スター／スノーフレークに対するＳＱＬクエリを生成する。アダプタ１８０は、ＳＱＬ文をパーズし、ＳＱＬ文の遂行に適当なＭＤＸ文を生成する。複数のＭＤＸ文が必要な場合、アダプタはその結果を再び一緒に組み立てる。

一実施形態では、アダプタ１８０は、要求されるデータ量を低減し、できるだけ多量の処理をデータソースのＭＤＸエンジンに委ね、アダプタ１８０が行う必要のある作業量を低減するように最適化することができる。

上述したように、変換エンジン２０６は、キューブのメタデータをスター／スノーフレークスキーマにマッピングする。アダプタ１８０は、ＳＱＬストリングに応答し、ＳＱＬストリングを１つまたは複数のＭＤＸ文にマッピングまたは変換することができ、ＭＤＸ文を生成する。アダプタは、ｊｏｉｎ文を処理し、結果として得られたデータが正にＳＱＬ文が要求したものであるようにＭＤＸ文により返されたデータをフィルタリングする。

図３を参照して、アダプタ１８０を使用してＳＡＰ ＢＷ等のソース多次元データベース２０２から、ＥＩＳを介するハイペリオンエスベース等のＯＬＡＰシステム３０２内の宛先キューブ３０１にインポートする構造の高レベル図を示す。以下に、ＯＬＡＰシステム３０２からアダプタ１８０へのシナリオおよびアクション、ＯＤＢＣインタフェースを介してＯＬＡＰシステムから使用可能な関係スキーマへの多次元データベース概念のマッピング、上記マッピングを遂行するためのアダプタ１８０内のデータフロー、ならびにアダプタサブシステムでの責任区分およびデータフローの理解について説明する。

好ましい実施形態では、アダプタは関係スキーマのＸＭＬモデル３０４を供給して、ＯＬＡＰシステム内の多次元キューブのモデリングプロセスを簡易化する。

以下、ＤＲＭ２００を概念およびサブシステムの視点から説明する。概念の視点では、データモデルおよびデータモデルのプロセス間での変換について説明する。サブシステムの視点はデータモデルの具体的な観点であり、個別のより具体的な概念への機能のカプセル化を提供する。

上述したように、アダプタは、多次元スキーマを関係スキーマにマッピングするＯＤＢＣドライバである。これにより、ＯＬＡＰシステムは、ＯＤＢＣインタフェースを使用してデータを多次元データからロードできるようになる。例えば、ＥＩＳと併せてアダプタを使用するプロセスは、ウェアハウスからキューブを選択し、最終的にＸＭＬモデルを生成するプロセスを通してユーザをガイドするウィザードを除き、他の任意のＯＤＢＣドライバを使用するプロセスと同様である。アダプタの動作は、以下の使用事例を最初に参照することで最もよく理解することができる。

使用事例
以下に、アダプタが果たす基本的な使用事例を概説する。アダプタの使用に関わる主なアクティビティは、ＤＳＮの作成、アダプタへのログイン、ＯＬＡＰモデルの構築、およびデータの抽出を含む。ＯＬＡＰシステムは、アダプタが生成するＸＭＬモデルを自動的にインポートすることができる。図４は基本的な使用事例４００を示す。データベースの接続に各種規格およびプロトコルが存在し、分析ツールについての同様であることに留意されたい。上述したように、本発明の使用事例をＳＡＰ ＢＷおよびハイペリオンエスベース製品の文脈で説明するが、本発明の教示は他のデータベースシステムおよび分析ツールに容易に適用することができる。

ＤＳＮ（データソース名）の作成
使用事例４００は、アダプタおよびデータベースフロントエンドがクライアントコンピュータにインストールされた後、ユーザ４０２がＯＤＢＣデータソース管理者制御パネル（図示せず）を使用して新規のＤＳＮを作成すると開始される。ＤＳＮがＯＤＢＣドライバを通してデータベースに接続を提供することは周知である。１つまたは複数のＧＵＩダイアログが、ウェアハウスに接続するために、システム名、ユーザ名、パスワード、クライアント、および使用言語の入力を促す。正しくない情報が入力された場合、ユーザがＤＳＮの作成をキャンセルするか、または正しい情報を入力するまで、情報の入力が促され続ける。

ウェアハウスが接続を確立すると、別のダイアログが、カタログのリストを表示し、ＤＳＮと併せて使用するカタログの入力を促す。ＯＬＡＰシステムが使用できるＤＳＮが作成される。

ＯＬＡＰシステムが実行されると、新規モデルが作成されるか、またはアダプタを使用して作成された既存のモデルまたはアウトラインが選択されて、開かれる。アダプタを使用して作成されたＤＳＮが選択され、ユーザ名およびパスワードが入力される。ＯＬＡＰシステムはアダプタに接続され、選択されたモデルまたはアウトラインが開かれる。

ＸＭＬモデルの生成
ＯＬＡＰシステムが実行され、アダプタにログインすると、イベントの流れは、ユーザが現在のＤＳＮのカタログ内のキューブリストからキューブを選択することである。ＯＬＡＰシステムは、選択されたキューブ名を供給する、アダプタ内のストアドプロシージャを実行する。アダプタは、キューブについてのメタデータ情報を検索し、多次元から関係へのマッピングというタイトルで後述するステップに概説するマッピングを実行する。アダプタは、マッピングに基づいてＸＭＬモデルを作成し、ストアドプロシージャからＯＬＡＰシステムにマッピングを返す。これが行われてしまえば、ＯＬＡＰシステムはＸＭＬモデルを受け取り、これを使用してＯＬＡＰモデルをキューブに作成することができる。

データの抽出
ＯＬＡＰシステムが実行され、メタアウトライン［ＮＴＤ：メタ−アウトラインが何か］がロードされる。ユーザは、メタ−アウトラインのメンバまたはデータのロードを選択する。ＯＬＡＰシステムは、検索するデータを指定する１つまたは複数のＳＱＬ文をアダプタに送る。アダプタは、各ＳＱＬ文で要求されたテーブルを判断し、１つまたは複数のＭＤＸ文を実行して、各ＳＱＬ文を満足させる。アダプタは、多次元キューブから返された結果をテーブルフォーマットに変換し、そのテーブルをＯＬＡＰシステムに返す。選択されたデータが、アダプタからＯＬＡＰシステムフォーマットに抽出される。

多次元から関係スキーマへのマッピング
このセクションでは、キューブ／ＯＤＢＯ概念の関係スキーマへのマッピングについて概説する。このマッピングは、アダプタがＸＭＬモデルを作成するステップおよびデータを抽出するステップを行えるようにするために行われる。

テーブルの説明
図５を参照して、関係テーブル５００を使用したデータソース２０２のキューブ表現を示す。キューブは、ファクトテーブルを中心にしたスノーフレークスキーマを使用して表される。ファクトテーブルの周囲はすべて次元テーブルおよび時間テーブルである。時間次元はすべて、ファクトテーブルに結合された１つの時間テーブルに折り畳まれる。次元テーブルは、次元のフラットなデフォルト階層を表す。ＳＡＰ ＢＷでは、すべての次元は１レベルを有するデフォルト階層を有する。次元が任意の代替階層を有する場合、代替階層は２つの形態で表される。第１に、代替階層内の各レベルがテーブルとして表される。代替階層内で最低レベルを表すテーブルが次元テーブルに結合される。第２の形態では、階層内のすべてのメンバは、階層関係がメンバ／子および親の列内に含まれる親子（または再帰）テーブルで表される。

ファクトテーブル
図５に示す実施形態では、ファクトテーブルの名称はＦａｃｔＴａｂｌｅである。このテーブルは以下のように定義することができる。
ｉ．各メジャーに１列。列の名称はそのメジャーの一意名である。列の内容はメジャーデータである。
ｉｉ．時間次元に１列。列の名称は最大時間次元の一意名である。列の内容は、最大時間次元からのメンバの一意名である。各非時間次元に１列。列の名称は次元の一意名である。列の内容は次元からのメンバの一意名である。

次元テーブル
ｉ．各次元テーブルの名称は、次元の一意名である。
ｉｉ．メンバの一意名、メンバ名、メンバキャプション、および説明を含む４列。各列の列名はＭｅｍｂｅｒＵｎｉｑｕｅＮａｍｅ、ＭｅｍｂｅｒＮａｍｅ、ＭｅｍｂｅｒＣａｐｔｉｏｎ、ＭｅｍｂｅｒＤｅｓｃｒｉｐｔｉｏｎである。
ｉｉｉ．各特徴属性に１列。特徴属性はＯＤＢＯ内の次元プロパティとして表される。列名は、次元プロパティ名に次元プロパティキャプションが付いたものである。列の内容は次元プロパティの値である。

すべての次元プロパティが表される。ＯＤＢＯでは、ＩｎｆｏＯｂｊｅｃｔのＫｅｙ、Ｓｈｏｒｔ ｔｅｘｔ、Ｍｅｄｉｕｍ ｔｅｘｔ、およびＬｏｎｇ ｔｅｘｔに次元プロパティがある。これらプロパティは、値が標準ＯＤＢＯプロパティを通して利用可能であるため、提示されない。

レベルテーブル
ｉ．各レベルテーブルの名称はレベルの一意名である。
ｉｉ．レベルテーブルの列は次元テーブルと同じであるが、親の一意名を含む追加の列を有することができる。この列の列名はＰａｒｅｎｔＵｎｉｑｕｅＮａｍｅである。この列は、階層の最上レベルを表すテーブル内で提示されない。

親子テーブル
ｉ．テーブルの名称は階層の一意名である。
ｉｉ．レベルテーブルの列は次元テーブルと同じであるが、親の一意名を含む追加の列を含む。この列の列名はＰａｒｅｎｔＵｎｉｑｕｅＮａｍｅである。

時間テーブル
ｉ．時間テーブルの名称はＴｉｍｅである。
ｉｉ．各時間次元は、メンバに一意名、メンバ名、およびメンバキャプションを含む３列を有する。各列の列名はＭｅｍｂｅｒＵｎｉｑｕｅＮａｍｅ、ＭｅｍｂｅｒＮａｍｅ、ＭｅｍｂｅｒＣａｐｔｉｏｎである。
ｉｉｉ．時間テーブルは、キューブ内のすべての時間次元からのメンバの空ではないクロス結合を含む。

時間表現
エスベースとは対照的に、ＳＡＰ ＢＷは複数の次元を使用して時間を表現する。時間次元は１つの時間テーブルに組み合わせされて、階層を構築できるようにする。ＢＷ表現の１つの悪影響は、エスベースの時間次元内の階層を手作業で構築する必要があることである。

階層表現
階層は、階層内の各レベルに１つのテーブルがあるスノーフレークスキーマを使用して表される。階層は、親子テーブルまたは再帰テーブルを使用して表すこともできる。表現の選択によりいくつかのトレードオフが発生する。スノーフレーク表現はハイブリッド分析をサポートするが、不揃いの（またはＯＤＢＯではアンバランスな）階層の最低レベルの葉のみがデータを含む。最低レベルにない葉はデータを含まない。親子表現は不揃いの階層をサポートするが、ハイブリッド分析に使用することができない。

ＭＤＸでは、各次元から１つだけの階層をクエリに使用することができる。その結果、ファクトテーブルは各特徴の１階層からのメンバしか含むことができない。ＳＡＰ ＢＷ内では、各特徴は、特徴内のすべてのメンバを含むデフォルトのフラットな階層を含む。その結果、デフォルト階層がファクトテーブルで使用する論理的な選択である。他のすべての代替階層は、デフォルト階層内のメンバのサブセットを含む。代替の階層内には、ポストできるノードおよびポストできないノードがある。階層が作成された特徴を参照するすべてのノードは、ポスト可能なノードである。すなわち、トランザクションデータは、ポスト可能なノードに対してのみ存在する。ポストできないノードは、作成された階層の特徴を参照しない。ポストできないノードは、階層内に含めて階層の構造を改良することができるテキストノードであるか、または外部特徴ノードである。ポスト可能なノードは、階層が作成された特徴を参照するため、デフォルトのフラットな階層内にもある。規則として、スノーフレークスキーマでは、代替階層の最低レベルは、ポストできないノードを含む。結果として、代替階層の場合、データは、代替階層の最低レベルを（１）デフォルト階層を表す次元テーブルおよび（２）ファクトテーブルに結合することによりロードされる。

階層の別の表現は、階層を１つのテーブルにフラット化し、ヌルプロモーション（ｎｕｌｌ ｐｒｏｍｏｔｉｏｎ）を使用して、すべての葉が次元テーブルに結合されることを保証する。この手法は、実施が比較的容易な他の２つの表現よりも技術的に難しいため、採用されない。

図６を参照して、結果として以下の表を生成する、国（レベル０）、州／県（レベル１）、市（レベル２）、および地区（レベル３）の単純な階層６００を示す。この階層は市特徴内にあり、他のすべてのノードは外部特徴からであると仮定する。

図７を参照して、３次元および１階層を有する単純なＢＷキューブに生成される関係スキーマ７００を示す。

ＢＷから関係／ＸＭＬモデルへのマッピング
以下に、ＳＡＰ ＢＷ／ＯＤＢＯを使用する本発明の一実施態様を説明する。したがって、以下の表は、ＢＷ／ＯＤＢＯアイテムの関係モデルおよびＸＭＬモデル両方へのマッピングを示す。

一意名に代えてキャプションを使用することができる。一意名は技術的な名称であるのに対して、キャプションは「フレンドリ」な名称である。すべての特徴が「フレンドリ」な名称を有するわけではないことに留意されたい。その結果、キャプションに代えて技術的な名称が使用される。

データフロー
図８を参照して、本発明の一実施形態によるＤＲＭ２００の概念流れ図８００を示す。この図では、「ドキュメント」形状は概念データアーティファクト（データ構造）を表し、矩形形状はアーティファクトに対する変換を表し、矢印付きの線はデータフローの方向を示す。矩形に入る矢印付き線は変換への入力を表し、矩形から出る矢印付き線は変換からの出力を表す。陰影付きのデータ形状および変換形状は、基礎データのセマンティクスから独立したデータ構造および変換をそれぞれ表す。換言すれば、ＳＡＰ ＢＷ等のＯＬＡＰデータソースまたは、例えばハイペリオンＥＩＳ等の関係ターゲットについて仮定がなされない。破線はアダプタドライバの層境界を表す。

アダプタ１８０は２つの広い機能、すなわちｉ）メタデータをマッピングして、ＯＬＡＰメタデータ２１０を、スター構成またはスノーフレーク構成のいずれかを有する関係スキーマおよびＯＬＡＰシステムのＸＭＬモデルに変換すること、およびｉｉ）利用可能なメタデータを使用してデータをマッピングして、関係データをフェッチする要求（すなわち、ＳＱＬクエリ）を変換してＯＬＡＰデータ要求にし、次に、フェッチされたＯＬＡＰデータを要求された関係形態に変換することを実行する。

アダプタ１８０が生成するデータアーティファクトは、ｉ）ＯＬＡＰキューブに対応するスノーフレークスキーマを提供する関係データ辞書２２４、ｉｉ）ＯＬＡＰキューブに対応するＸＭＬモデル２２２、およびｉｉｉ）ＯＬＡＰシステムにより発行されるＳＱＬクエリの関係結果セット（図示せず）を含む。

以下のサブセクションに、アダプタ１８０内のデータフローの各ステップの詳細を説明する。

メタデータ変換２１２
入力：ＯＬＡＰメタデータ２１０、出力：ＯＬＡＰ−関係スキーマ２１４
メタデータ変換ステップ２１２は、特定のキューブ（図示せず）についてのＯＬＡＰ−関係スキーマ２１４をＯＬＡＰメタデータ２１０から構築する。それは、ＯＬＡＰ−関係マッピングを確実に有意なものにするために必要な任意のビジネスロジックを提供する働きをする。換言すれば、確実に変換プロセスでのビジネスセマンティクス喪失がほとんど無いようにする。例えば、ＳＡＰ ＢＷインプリメンテーションの場合、アダプタのメタデータ変換により、ＳＡＰ ＢＷが時間を表す独自の方法に基づいて（すなわち、別個の次元として）時間次元テーブルに適当なスキーマが構築される。

ＯＬＡＰ−関係スキーマ２１４
このデータ構造は、関係およびＯＬＡＰの用語の両方でスタースキーマまたはスノーフレークスキーマを記述する。このような情報は、テーブル、列、結合、キューブ、レベル、階層、次元、メジャー、およびプロパティとして含まれる。ＯＬＡＰ−関係スキーマ２１４は、アダプタ１８０の残りの部分が要求されるＯＬＡＰ−関係マッピングを正しく実行するのに十分な情報を提供する。

ＸＭＬモデルジェネレータ２１６
入力：ＯＬＡＰ−関係スキーマ２１４、出力：ＸＭＬモデル２２２
このステップは、関係ターゲットが使うためのＸＭＬモデル２２２を構築する。モデルの構築に必要なすべての情報は、ＯＬＡＰ−関係スキーマ２１４から得られる。

ＸＭＬモデル２２２
このデータ構造は、接続されている特定の関係キューブにより定義されるモデルＤＴＤに準拠したＸＭＬドキュメントである。ＯＬＡＰキューブからアダプタ１８０により構築された関係スキーマを記述するメタデータを含む。

データ辞書投入２１８
入力：ＯＬＡＰ−関係スキーマ２１４、出力：関係データ辞書２２４
データ辞書投入２１８ステップは、関係データ辞書２２４に、ＯＬＡＰ−関係スキーマ２１４から得られた関係メタデータを投入する。これは、主テーブルおよび列メタデータを含む。

関係データ辞書２２４
これは、特定のスノーフレークスキーマの関係側面のみを記述するメタデータを含む仮想テーブルの集まりである。

ＳＱＬプッシュダウン／テーブルオープン要求２２６
アダプタ１８０の観点から、要求は、クエリエンジン１８６（シンバエンジン等）からのＳＱＬプッシュダウン（最適化されているケース）またはベーステーブルに対するテーブルオープン要求（最適化されていないケース）のいずれかである。根本的に、両方とも、データ消費者から発行されたＳＱＬ文に由来しており、これが次に、アダプタのクエリエンジン１８６の部分により処理される。簡易化のために、テーブルＴオープン要求は、ＳＱＬクエリｓｅｌｅｃｔ ＊ ｆｒｏｍ Ｔと概念的に等価であると考えることができる。

ＯＲＱジェネレータ２２０
入力：ＯＬＡＰ−関係スキーマ２１４、ＳＱＬプッシュダウン／テーブルオープン要求２２６、出力：ＯＬＡＰ−関係クエリ（ＯＲＱ）２３０、関係データ辞書２２４の更新
ＯＲＱジェネレータ２２０ステップは、フェッチするＯＬＡＰデータおよびこれを要求される関係形態にどのように変換するかを記述したＯＲＱ２３０を作成する。ベーステーブルに対する要求ならびに各種の最適化技法を実施して派生テーブルを生成するプッシュダウン要求を処理する。このステップは、ＯＬＡＰ−関係スキーマ２１４を入力としてとる。このステップは、これから、作成しなければならない、関係テーブルに対応するＯＬＡＰメタデータ、そのテーブルがベーステーブルであるか、それとも派生（すなわち、最適化された）テーブルであるかを識別する。このメタデータを使用して、フェッチするＯＬＡＰデータを記述するＯＲＱ２３０が生成される。最適化されるケースで新しい派生テーブルを作成することの悪影響として、このステップはまた、関係データ辞書２２４を新しいテーブルの記述子で更新する。

ＯＬＡＰ−関係クエリ（ＯＲＱ）２３０
これは、フェッチされるＯＬＡＰデータならびにフェッチされたデータをフォーマットしなければならない関係構造を記述するクエリ様の仕様である。それは、一般に、ＯＬＡＰアクセス層１５６により実行されるクエリとして働く。ＯＲＱ２３０は、キューブからＯＬＡＰデータ２４０をフェッチするＭＤＸクエリを生成するとともに、結果得られた軸行セット（ａｘｉｓ ｒｏｗｓｅｔ）およびセルデータに射影およびデータ型変換を適用するバインディングを生成するのに十分な情報を伝える。

ＯＲＱ２３０は、コマンド（Ｃｏｍｍａｎｄ）デザインパターン［ＧｏＦ９５］のコマンド（Ｃｏｍｍａｎｄ）の役割を果たす。コンポジット（Ｃｏｍｐｏｓｉｔｅ）パターン［ＧｏＦ９５］に従い、ｒａｗ ｔｅｘｔとしてではなくオブジェクト構造としてインプリメントすることができる。

ＭＤＸジェネレータ２３４
入力：ＯＲＱ２３０、出力：ＭＤＸクエリテンプレート２３８
ＭＤＸジェネレータ２３４は、ＯＲＱ２３０を入力とし、ＭＤＸクエリ２３８の「テンプレート」を生成する。テンプレート２３８は複数回「インスタンス化」して、ＯＲＱにより指定されるＯＬＡＰデータのパーティションをフェッチするＭＤＸ文を作成することができる。

ＭＤＸクエリテンプレート２３８
これは、ＯＲＱ２３０を使用してＭＤＸジェネレータ２３４により作成される不完全なＭＤＸ ＳＥＬＥＣＴ文である。それは、パーティションサイズおよびパーティション開始順によりパラメータ化される。これらパラメータが提供されると、テンプレートクエリは、ＯＲＱ２３０により示されたＯＬＡＰデータ２４０の１つのパーティションを検索する完全なＭＤＸクエリになる。

バインディングジェネレータ２３６
入力：ＯＲＱ２２０、出力：バインディング２４２
このステップはＯＲＱ２３０を入力とし、ＯＬＡＰデータソースからフェッチされたＲＯＷＳ軸行セットおよびセルデータに列射影およびデータ型変換を適用するバインディングを生成する。

バインディング２４２
バインディングデータ構造２４２は、ＲＯＷＳ軸行セットおよびセルデータから抽出する列ならびに所望のターゲットデータ型を記述する。この構造は、バッファレイアウトの詳細を記述し、ＯＬＡＰプロバイダにより返されるデータセットの構造の知識があると想定しているため、非常に低レベルな性質のものであることに留意されたい。この構造は、バインディングジェネレータ２３６により生成され、データセットテーブル化／射影２４４ステップにおいてＯＬＡＰデータ２４０に適用される。

データセットテーブル化／射影２４４
入力：ＯＬＡＰデータ２４０、出力：フラット化ＯＬＡＰデータ２４６
データセットテーブル化／射影２４４ステップは、データセットの形態のＯＬＡＰデータ２４０の１つのパーティションを入力としてとる。次元テーブルの場合、このデータセットはＲＯＷＳ軸および空のＣＯＬＵＭＮＳ軸を含む。ファクトテーブルの場合、ＣＯＬＵＭＮＳ軸はメジャーを含み、セルデータも同様に存在する。次元テーブルのパーティションを作成するには、このステップは単に適当なバインディングをＲＯＷＳ軸行セットに適用する。ファクトテーブルのパーティションを作成するには、このステップはまず、ＣＯＬＵＭＮＳ軸行セットをピボットさせてメジャー列を作成し、次にセルデータをＲＯＷＳ軸行セットからの行と結合しなければならない。この結果は、「フラット化」された２次元形態のＯＬＡＰデータのパーティションである。

フラット化ＯＬＡＰデータ２４６
フラット化ＯＬＡＰデータ２４６データ構造は、フラット化された形態のＯＬＡＰデータの１つのパーティションを含む。これは、元のＯＲＱ２３０により指定される形態に従って構造化される。このデータ構造は、追加のＯＬＡＰデータを含み得るという意味で必ずしも関係的である必要はない。さらに、このデータは、データ辞書内の対応する次元／ファクトテーブルにマッチする前にさらなる変換および変形が必要であり得る。このデータ構造は、データセットテーブル化／射影ステップ２４４により生成され、ＯＬＡＰアクセス層１５６のデータアクセス部分のプライマリ出力である。

データ検索２３２
入力：フラット化ＯＬＡＰデータ２４６、出力：要求された行／列２４８
このステップは、ブロック単位でＯＬＡＰデータ２４０にアクセスする。ＯＬＡＰアクセス層１５６から検索されたフラット化ＯＬＡＰデータのパーティションから各ブロックを作成する。各ブロックにつき、このステップはＤＲＭ層を介してＲＤＢＭエンジンに行および列を提供する。

要求された行／列２４８
これは、クエリエンジン１８６を介してデータ消費者が要求した行および列の集まりである。

以下に、上述したデータ構造のいくつかをさらに詳細に説明する。

ＯＬＡＰ−関係クエリ（ＯＲＱ）
簡潔に上述したように、ＯＬＡＰ−関係クエリ（ＯＲＱ）は、関係モデルから多次元モデルへのマッピングである。ＳＱＬクエリを、ＭＤＸクエリに容易に変換できる形態で表すために使用される。シンタックス的に有効なＭＤＸクエリを生成するために必要な情報のすべてを含む。その結果、データ辞書またはＯＬＡＰ−関係スキーマは、ＯＲＱをＭＤＸクエリに変換する際に使用されない。ＯＬＡＰ−関係スキーマ内の５つの可能な種類の関係テーブルを表す５つの種類のＯＲＱクエリがある。
ｉ．複数の次元で構成されるテーブル（例えば、ＳＡＰ ＢＷの場合での時間テーブル）を表すために使用されるコンポジットクエリ。
ｉｉ．１つの次元からの複数のレベルで構成されるテーブルを表すために使用されるマルチレベルクエリ。現在、ＳＡＰ ＢＷキューブのＯＬＡＰ−関係スキーマはマルチレベルテーブルをいずれも含まない。
ｉｉｉ．関係スノーフレークモデルでの次元テーブルおよびレベルテーブル等の次元からの１つのレベルで構成されるテーブルを表すために使用されるレベルクエリ。
ｉｖ．次元内で１つの階層で構成される親子テーブルを表すために使用される親子クエリ。
ｖ．ファクトテーブルを表すために使用されるファクトクエリ。

ＯＲＱ最適化により、集計関数、算術演算、結合条件、フィルタ、およびグループバイ（ｇｒｏｕｐ−ｂｙ）をＳＱＬからＭＤＸに変換することができる。以下は、上述した各種類のＯＲＱクエリの例である。

ＭＤＸ等価性
以下は、各種類のＯＲＱに生成される等価のＭＤＸクエリである。これらクエリ内で使用されるシンタックスおよび特徴はＳＡＰ ＢＷに固有であることに留意されたい。

ＯＬＡＰ−関係スキーマ２１４
ＯＬＡＰ−関係スキーマは、上述したように派生元のＯＬＡＰメタデータに関して合成関係スノーフレークスキーマを記述するデータ構造である。対応する物理ＯＬＡＰスキーマおよび関係スキーマへのリンクを有する「論理」ＯＬＡＰスキーマとして主に編成される。

以下の表はキューブの一表現である。

このキューブが「Ｓａｌｅｓ（売り上げ）」という名称であり、２つのメジャー「ＵｎｉｔＳａｌｅｓ（販売個数）」および「Ｃｏｓｔ（コスト）」を有するものと仮定する。あらゆるレベルが各メンバに属性「ＵｎｉｑｕｅＮａｍｅ（一意名）」および「Ｃａｐｔｉｏｎ（キャプション）」を定義し、「ＵｎｉｑｕｅＮａｍｅ（一意名）」が各メンバを一意に識別するものとも仮定する。これはＯＬＡＰメタデータの一般的な例であり、ＳＡＰ ＢＷメタデータの構造を反映していないことに留意されたい。図９は、スノーフレークスキーマのパーツに関連する共通する種類の情報のいくつかを示す、このキューブのＯＬＡＰ−関係スキーマ９００の一インプリメンテーションの一部を示す。上記図中で注目すべき３つのアイテムは、ＬｏｇｉｃａｌＤｉｍｅｎｓｉｏｎ、ＬｅｖｅｌＬｏｇｉｃａｌＨｉｅｒａｒｃｈｙ、およびＬｏｇｉｃａｌＬｅｖｅｌの各ＯＬＡＰ構造である。これらは、関係スキーマとしての提示のための物理ＯＬＡＰスキーマの特定の構造を表す論理ＯＬＡＰスキーマを表す。これら構成は、上で定義したＯＲＱの種類、すなわちコンポジット、マルチレベル、レベル、および親子に対応する。「ＬｅｖｅｌＬｏｇｉｃａｌＨｉｅｒａｒｃｈｙ」は、物理階層および他の種類の論理階層と区別するためにこのような名称を有する。この文脈での物理階層は、ＯＬＡＰメタデータから抽出される階層である。論理階層は、基礎のＯＬＡＰメタデータからのビジネスセマンティクスを保存するようにメタデータ変換ステップにより構築される階層である。論理階層は物理階層に対応する場合もあれば、対応しない場合もある。例えば、ＳＡＰ ＢＷキューブにコンポジット時間テーブルを構築するために使用される論理階層は、１つの物理階層に対応しない。

図１０は、ＳＡＰ時間テーブル１０００のＯＬＡＰ−関係スキーマの部分を示す。この例での「ＣｏｍｐｏｓｉｔｅＬｏｇｉｃａｌＨｉｅｒａｒｃｈｙ」の使用に留意されたい。実際に、この各レベルは異なる物理階層に属する。「ＣｏｍｐｏｓｉｔｅＬｏｇｉｃａｌＨｉｅｒａｒｃｈｙ」構造の作成は、部分的に、ドライバの側の当て推量作業である。このため、警告が、ＥＩＳに送られるＸＭＬモデル内にコメントとして埋め込まれる。

上記例は、最適化関連の注釈、すなわち行カウントも含む。可能な場合、厳密な、または適当な行カウントがメタデータ変換により求められ、ＯＲＱジェネレータのためにＯＬＡＰ−関係スキーマに含められる。

ＳＱＬからＭＤＸへのマッピング
以下に、ＯＤＢＳＣＥＮ０１キューブおよび４つの次元ＯＤＢ＿ＣＵＳＴ、ＯＤＢ＿ＣＯＮＴ、ＯＤＢ＿ＶＡＬＴＰ、０ＣＡＬＭＯＮＴＨに基づく単純なスタースキーマでのＳＱＬからＭＤＸのマッピングの例を提供する。ＳＱＬ例は、ＥＩＳがメンバまたはデータのロード中に生成し得るものに基づく。ＭＤＸが必要な演算を実行できない場合、ＳＥＮが必要なＳＱＬ演算を実行することを記したメモが作成される。

以下、１つまたは複数のＳＱＬクエリを列挙し、その後にＳＱＬクエリを満足させるために必要な結果を生成するＭＤＸクエリを列挙することによりマッピングを示す。

Ｄｉｓｔｉｎｃｔ
Ｄｉｓｔｉｎｃｔ句内で指定された列の１つが一意の場合、Ｄｉｓｔｉｎｃｔ句をクエリから除去することができる。ＭｅｍｂｅｒＵｎｉｑｕｅＮａｍｅ列は代替階層内で一意ではないことに留意されたい。

算術演算
ＳＥＮが％（剰余）により要求される計算を実行する必要がある。

スカラー関数
ＳＥＮがスカラー関数により要求される計算を実行する必要がある。

集計
以下の４つすべてのＳＱＬクエリが同じＭＤＸクエリになる。

句がＤｉｓｔｉｎｃｔ ＭｅｍｂｅｒＣａｐｔｉｏｎである場合、カウントすることができない。Ｃｏｕｎｔ ｄｉｓｔｉｎｃｔは、指定される列が一意である場合のみ行うことができる。

データの消費者は、以下の標準ＡＰＩ、すなわちＯＤＢＣ、ＪＤＢＣ、ＯＬＥ ＤＢ、ＡＤＯ、またはＡＤＯ．ＮＥＴのうちの任意の１つを介してアダプタに接続することができる。消費者は、メタデータクエリをアダプタに発行して、キューブのスター／スノーフレーク仮想ビューについての情報を得ることができる。消費者は、データプロバイダに対して実行されるＳＱＬクエリを生成する。多次元データソースが、ＯＤＢＯまたはＸＭＬＡのいずれかを介してデータをエクスポーズし、渡されたＭＤＸクエリを実行し、入力ＭＤＸクエリから生じたデータを返す。

ＳＱＬクエリのＭＤＸクエリへの変換は、キューブではなくスター／スノーフレークとして表されるデータソースをデータ消費者に提示することにより動作する。したがって、消費者は、ＳＱＬクエリをスター／スノーフレークに対して開始する。キューブをスター／スノーフレークとしてエクスポーズするために、アダプタがキューブのメタデータを読み取り、変換アルゴリズムを使用して、スター／スノーフレークを指定された形態で消費者に提示する。もちろん、スター／スノーフレークは実際には存在せず、仮想テーブルセットである。次に、消費者がＳＱＬ文を仮想スター／スノーフレークに対して実行すると、アダプタがＳＱＬを適当なＭＤＸ文にマッピングする。

まとめると、本発明によるアダプタは、アダプタにより返されるメンバおよびファクトデータが正確でなければならず、提示される関係スキーマにより、関係ターゲット（例えば、ＥＩＳ）がソースキューブ（例えば、ＳＡＰ ＢＷ）に厳密に適合した宛先データベース（例えば、エスベース）のキューブを作成できなければならないという点で高度の正確性を提供する。アダプタはデータを適時に効率的に転送するが、データを関係データベースからロードするほど高速ではないことがある。アダプタの他の緒特徴は、拡張性、移植性、柔軟性、および保全性である。

本発明を特定の好ましい１つまたは複数の態様に関連して説明したが、当業者が本明細書および添付図面を読んで理解すれば、等価の変形および変更に想到することが明らかである。特に、番号（構成要素、組立体、装置、構成物等）により参照される上記アイテムにより実行される各種機能に関連して、このようなアイテムを説明するために使用される用語（「手段」を指す用語を含む）は、本発明の本明細書に示した例示的な１つまたは複数の態様での機能を実行する、開示した構造と構造的に等価ではない場合であっても、別段に示されない限り、説明されたアイテムの指定された機能を実行する（例えば、機能的に等価の）あらゆるアイテムに対応することを意図する。さらに、本発明の特定の特徴を、いくつかの図示された態様の１つのみに関連して上述したが、このような特徴は、任意の所与または特定の用途に望ましく、有利である場合、その他の態様の１つまたは複数の特徴と組み合わせることも可能である。

図を参照した本明細書における説明は、当業者が本発明を各種の用途および装置で利用できるようにするのに十分詳細に本発明を説明するものと理解される。冒頭の特許請求の範囲において規定される本発明の趣旨および範囲から逸脱することなく、各種の変更および変形を行い得ることが容易に明らかであろう。

データウェアハウスの機能層を示す概略図である。 本発明によるアダプタの一実施形態の機能層のブロック図を示す。 アダプタの構造の高レベル図および典型的な使用シナリオを示す。 アダプタの使用事例の概略を示す。 関係テーブルを使用するキューブの図を示す。 テーブルが構築される単純な階層を示す。 ３次元および１階層の単純なキューブに生成される関係スキーマを示す。 本発明の一実施形態によるデータレコードマネージャの概念流れ図を示す。 キューブのＯＬＡＰ−関係スキーマの一実施態様の一部を示す。 ＳＡＰタイムテーブルのＯＬＡＰ−関係スキーマの一部を示す。

Claims (17)

1. 未知の構成のデータソースを既知の構成のデータソースにマッピングする方法であって、
   ａ．メタデータ要求を前記データソースにサブミットするステップと、
   ｂ．前記データソースから受け取った前記メタデータに基づいて、前記既知の構成の関係スキーマを生成するステップと、
   ｃ．前記生成された関係スキーマの前記メタデータを返すステップであって、該返されるメタデータは前記データソースを前記既知の構成にマッピングするステップと、
   を含む方法。
2. 前記未知の構成のデータソースは多次元データベースである、請求項１に記載の方法。
3. 前記既知の構成はスタースキーマまたはスノーフレークスキーマである、請求項１に記載の方法。
4. ａ．データ消費者から、前記生成された関係スキーマに対するデータクエリを受け取るステップと、
   ｂ．前記受け取ったクエリを前記データソースによりサポートされる１つまたは複数のクエリに変換するステップであって、それにより、前記データソースからデータを検索するステップと、
   ｃ．前記データソースから検索されたデータを前記データ消費者に返すステップと、
   を含む、請求項１に記載の方法。
5. データソースにサブミットされるクエリを変換する方法であって、前記クエリは前記データソースによりサポートされない言語のものであり、該方法は、
   ａ．データ消費者からクエリを受け取るステップであって、前記クエリは既知の構成の関係スキーマに基づき、前記スキーマは前記データソースを前記既知の構成にマッピングするステップと、
   ｂ．前記受け取ったクエリを、前記データソースによりサポートされる１つまたは複数のクエリに変換するステップであって、それにより、前記データソースからデータを検索するステップと、
   ｃ．前記データソースから検索された前記データを前記データ消費者に返すステップと、
   を含む方法。
6. 前記クエリは構造化照会言語（ＳＱＬ）クエリであり、前記データソースは多次元データベースである、請求項３に記載の方法。
7. 前記多次元データベースは多次元式言語（ＭＤＸ）をサポートする、請求項４に記載の方法。
8. 前記既知の構成はスタースキーマまたはスノーフレークスキーマである、請求項５に記載の方法。
9. 前記データソースはキューブの集まりである、請求項３に記載の方法。
10. 前記クエリは前記スター／スノーフレークスキーマに対するＳＱＬクエリである、請求項３に記載の方法。
11. データ消費者により発行される、データソースによりサポートされていない言語のクエリを前記データソースがサポートする言語のクエリに変換する方法であって、
    ａ．既知の構成の関係スキーマをデータ消費者に提示するステップと、
    ｂ．変換アルゴリズムを使用して、前記データソースを前記既知の構成で前記データ消費者に提示するステップと、
    ｃ．前記データソースを表すモデルオブジェクトを含むメタデータモデルを読み取るステップと、
    ｄ．前記既知の構成に対するクエリを受け取るステップと、
    ｅ．前記データソースから検索されたデータを前記データ消費者に返すステップと、
    を含む方法。
12. 前記クエリは構造化照会言語（ＳＱＬ）クエリであり、前記データソースは多次元データベースである、請求項９に記載の方法。
13. 前記データソースがサポートする言語は多次元式言語（ＭＤＸ）である、請求項１０に記載の方法。
14. 前記既知の構成はスター／スノーフレークスキーマである、請求項１１に記載の方法。
15. 前記クエリは、前記スター／スノーフレークスキーマに対するＳＱＬクエリである、請求項１２に記載の方法。
16. データ消費者により発行される、データソースによりサポートされていない言語のクエリを前記データソースがサポートする言語のクエリに変換するアダプタであって、
    ａ．既知の構成の関係スキーマを生成する手段と、
    ｂ．前記既知の構成に対するクエリを受け取るインタフェースと、
    ｃ．前記データソースを表すモデルオブジェクトを含むメタデータモデルと、
    ｄ．前記データソースを前記既知の構成で前記データ消費者に提示する変換アルゴリズムと、
    を備えるアダプタ。
17. ＯＤＢＣドライバ、ＪＤＢＣドライバ、またはＯＬＥ−ＤＢプロバイダのうちの１つを含むＳＱＬドライバである、請求項１４に記載のアダプタ。

Images