図面 (/)

技術 リレーショナルOLAPエンジンのための多次元計算を記述する方法、システム、およびプログラム

出願人 インターナショナル・ビジネス・マシーンズ・コーポレーション
発明者 コロッシ、ネイサン、ジェバードマロイ、ウィリアム、アールピラヘシュ、ミア、ハミドトムリン、クレイグ、レジナルド
出願日 2003年12月17日 (15年0ヶ月経過) 出願番号 2004-566154
公開日 2006年4月20日 (12年7ヶ月経過) 公開番号 2006-513474
状態 拒絶査定
技術分野 特定用途計算機 検索装置
主要キーワード 接触表示 スノーフレーク 月レベル 多次元構造 関数依存性 合計演算 統計関数 上層レベル
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2006年4月20日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (20)

課題

多次元計算を記述するシステム、方法、およびプログラムを開示する。

解決手段

ファクトメタデータオブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成されたキューブモデル・メタデータ・オブジェクトのサブセットの選択を受領する。前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照している。前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報検索するためのステートメントを生成する。前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している。

概要

背景

オンライン分析処理(OLAP:on-line analyticalprocessing)がますます一般的になってきている。緑行付出力用紙(green-bar paper)に印刷された統計報告の山を精査する代わりに、OLAP分析者対話的かつ動的にデータのビューを調整し、疑問点を質問し、そして、ほとんど瞬時に回答を得ながら、ビジネス成果調査することができる。固定したスケジュールに則り固定した質問に対する静的な回答に比べると、この自由さはビジネス分析者がより効率的に働き、事業活動における進歩をなし遂げることを可能にする。

ナイジェルペンドセ(Nigel Pendse)はOLAPシステム特徴付けるために、頭文字用語「FASMI」を導入した。FASMIの特徴は速い(Fast)、分析(Analysis)、共用(Shared)、多次元(Multidimensional)、および情報(Information)である。さらなる情報については、N・ペンドセ「OLAPとは何か?(WhatIs OLAP ?)」(OLAPレポート)(The OLAP Report, http://www.olapreport.com/fasmi.htm)を参照されたい。

速い(fast)については、OLAPの「O」の趣旨との調和を保つ点において、そのようなシステムはきわめて迅速に、通常は数秒以内に結果を提示する必要があり、20秒や30秒を超えることは滅多にない。分析者が注意散漫にならずに効率的に仕事をするのを可能にするという点において、このレベルの性能がきわめて重要である。

分析(analysis)については、OLAPの「A」を考慮して、OLAPシステムは一般に最小限のプログラミングで済む、所定の用途に最適な豊富分析機能を提供している。

共用(shared)については、OLAPシステムは通常、共用リソースである。これはOLAPシステムが適切なセキュリティ機能保全性機能を提供するための要件が存在するということを意味する。究極的には、これはデータベースの各セルごとに異なるアクセス制御を提供するということを意味する可能性がある。

多次元(multidimensional)については、多次元性はOLAPシステムにとって主要な要件である。OLAP製品は自身のデータを多次元のフレームワークにおいて提示する。次元とはシステムのデータ値の関連する識別子または属性(たとえば製品、市場、時間、チャネルシナリオ、または顧客)の集積のことである。特定の次元用の集積に属す識別子(たとえば「ロード・オブ・ザ・リング−DVD(TheLord of the Rings-DVD)」、「カリフォルニアサンノゼ(San Jose, California)」、「2002」、「小売りレンタル(RetailRental)」、および「ジョン・Q.パブリック(John Q. Public)」)は一般に階層のような何らかの種類の構造を有する。時として、これらの識別子に対して複数の自然の構造が存在する。

多次元の特徴はOLAPシステムが1つの次元の様々なサブセットと構造上の構成との間に加え、次元の様々な方向(orientation)の間で迅速に切り替わることができる、ということを意味する。OLAPシステムの多次元の性質のために、それらが実装するデータの集積はキューブ(cube:立方体)と呼ばれている。情報(information)については、OLAPシステムは情報を格納するとともに計算する。OLAPシステムのためのデータは多くの場合、少なくとも1つの動作中のシステムに由来するこれらのデータには分析モデルを適用し、その結果はシステムに格納するか、照会時に生成するかする。ある特定のOLAPシステムが管理しうる情報の量は当該システムの一特徴である。

企業は多年にわたりリレーショナル・データベースの中に多次元のデータを星型スキーマまたはスノーフレーク(snowflake:雪片)型スキーマを用いて蓄積し続けてきている。時が経つのにつれて、リレーショナル・データベースの提供業者はこれらのスキーマに照会性能を向上させる最適化を付加している。1990年代に、付加された計算上の複雑さを処理しうるとともに、一般にリレーショナル・エンジンよりも良好に実行しうる多くの専用のデータベースが開発された。

多次元OLAP(MOLAP:multidimensional OLAP)は専用のファイル・システムすなわち索引を用いてキューブ・データを格納するOLAPシステムのファミリーを指す。「Express Web Publisher」、「Essbase」、「TM1」、および「Pilot Suite」は専用の記憶と索引付けの技術に基づいた製品の数例である。マイクロソフト(R)(Microsoft(R))のOLAP商品もMOLAPエンジンを備えている。これらのシステムは多くの場合、基本データとともに周期的にロードされ、次いで抽出されたデータが計算され、格納され、そして索引付けが行われる読み取り専用のシステムである。MOLAPシステムの規模拡張性は多くの場合、その内部で、抽出された結果が計算され、格納されるバッチ・ウインドウのサイズによって限定される。規模拡張性を改善するために、そのようなシステムは多くの場合、抽出された結果の一部を照会時まで遅らせ手段を備えている。

リレーショナルOLAP(relational OLAP:ROLAP)の場合、リレーショナル・データベースの中の多次元データ表現する手段として、多年にわたり星型スキーマが用いられてきた。「MicroStrategy」、「Brio」、「Business Objects」、「Metacube」、「Hyperion」、および「Metaphor」のような多くの商用ソフトウェア開発会社がリレーショナル星型スキーマのためのバッチまたは対話型の多次元の報告探査インターフェースを開発してきた。これらのシステムはすべて、構造化照会言語(StructuredQuery language:SQL)に超集約演算子(super aggregate operator)が追加される前に設計され実装された。

特に、数年前まで、リレーショナル・データベースは照会ごとに単一のレベルのみにおける集約の計算を許可していた。たとえば、「GROUP BY」文節を伴う、ある「SELECT」ステートメントを用いて結果の組を四半期レベルで(すなわち1組の四半期に対して)検索しながら、「GROUP BY」文節を伴う別の「SELECT」ステートメントを用いて月レベルで(すなわち1組の月に対して)結果の組を検索するのが常であった。これは、変動するレベルにおいてセルを計算するために、OLAPシステムにデータベースに対して複数の照会を実行することを強いるものであった。

OLAP型の照会の作成を容易にするため、および、より進歩した最適化を実現するために、インターナシナル・ビジネス・マシーンズ・コーポレーション(International Business Machines Corporation)から入手可能なDB2(R)リレーショナル・データベース管理システム(relationaldatabase Management System:RDBMS)は単一の照会が複数の集約を生成するのを可能にする、SQL標準に追加された3つの新たな超集約演算子、すなわち「ROLLUP」、「CUBE」、および「GROUPINGSETS」を実装した。これらの超集約演算子は「GROUP BY」文節に対する拡張であり、複数のレベルにおいて集約を生成すべきことを指示する。たとえば、1つの「SELECT」ステートメントを用いて複数のレベル(たとえば四半期および月の双方)において集約の計算の結果の組を取得することができる。

これらの超集約演算子は複数のグループ化の組を生成するための単なる便法以上のものである。単一のステートメントにおいて複数のグループ化の組が要求されるから、DB2(R)RDBMSは計算に必要な各入力行を1度だけ参照するような方法で、すべてのグループ化の組を生成する実行計画構築することができる。これは特に入力行の組がバッファプール(すなわちキャッシュ)に適合していないときに、数桁の性能の改善をもたらす可能性がある。

従来技術のシステムは複数の照会を発行することにより、様々なレベルの粒度細分性)を備えた結果を提示する多次元の報告を生成するように設計されていた。複数の照会に対して複数の結果の組を取得し、それら結果の組をマージして単一の報告を作成する。そのようなシステムはデータを検索して多次元の報告を生成するのに、表のための役割のある種の記述メタデータ)と、必要なSQLステートメントを生成する星型スキーマにおける列とに依存している。正確なメタデータは製品ごとに異なる。

(たとえば「Hyperion」、「Cognos」、および「Microsoft(R)」のような会社に由来する)多次元オンライン分析処理(OLAP)システムは多次元のキューブの各端(edge)のためにメンバの組が与えられると、多次元の結果の組を自然に返すように設計されている。多次元OLAPシステムは任意の照会の結果の一部または全部を事前に計算するようにも設計されている。

概要

多次元計算を記述するシステム、方法、およびプログラムを開示する。ファクト・メタデータ・オブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領する。前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照している。前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成する。前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している。

目的

究極的には、これはデータベースの各セルごとに異なるアクセス制御を提供する

効果

実績

技術文献被引用数
1件
牽制数
2件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

多次元計算を記述する方法であって、ファクトメタデータオブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成されたキューブモデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照している、ステップと、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している、ステップとを含む方法。

請求項2

前記ステートメントは構造化照会言語ステートメントである、請求項1に記載の方法。

請求項3

前記測度メタデータ・オブジェクトの各々は少なくとも1つの構造化照会言語式を指定している、請求項1に記載の方法。

請求項4

前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる、請求項3に記載の方法。

請求項5

前記テンプレートは列、属性、および測度から成るリスト由来する特定の列、属性、または測度を参照する、トークン表記法を使用している、請求項4に記載の方法。

請求項6

前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる、請求項3に記載の方法。

請求項7

前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも1つの集約に基づいて生成する、請求項1に記載の方法。

請求項8

集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる、請求項7に記載の方法。

請求項9

多次元計算を記述するシステムであって、ファクト・メタデータ・オブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照している、ステップと、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している、ステップとを含む少なくとも1つのプログラムを動作させる少なくとも1つのプログラム可能な構成要素を有するコンピュータ・システムを含むシステム。

請求項10

コンピュータ・システムにロードされ、その上で実行されると、前記コンピュータ・システムに請求項1〜8のうちの1項に記載の方法のすべてのステップを実行させるコンピュータ・プログラム・コードを含むコンピュータ・プログラム。

技術分野

0001

本発明はリレーショナルオンライン分析処理(OLAP:on-lineanalytical processing)エンジン用に多次元計算を記述することに関する。

背景技術

0002

オンライン分析処理(OLAP:on-line analyticalprocessing)がますます一般的になってきている。緑行付出力用紙(green-bar paper)に印刷された統計報告の山を精査する代わりに、OLAP分析者対話的かつ動的にデータのビューを調整し、疑問点を質問し、そして、ほとんど瞬時に回答を得ながら、ビジネス成果調査することができる。固定したスケジュールに則り固定した質問に対する静的な回答に比べると、この自由さはビジネス分析者がより効率的に働き、事業活動における進歩をなし遂げることを可能にする。

0003

ナイジェルペンドセ(Nigel Pendse)はOLAPシステム特徴付けるために、頭文字用語「FASMI」を導入した。FASMIの特徴は速い(Fast)、分析(Analysis)、共用(Shared)、多次元(Multidimensional)、および情報(Information)である。さらなる情報については、N・ペンドセ「OLAPとは何か?(WhatIs OLAP ?)」(OLAPレポート)(The OLAP Report, http://www.olapreport.com/fasmi.htm)を参照されたい。

0004

速い(fast)については、OLAPの「O」の趣旨との調和を保つ点において、そのようなシステムはきわめて迅速に、通常は数秒以内に結果を提示する必要があり、20秒や30秒を超えることは滅多にない。分析者が注意散漫にならずに効率的に仕事をするのを可能にするという点において、このレベルの性能がきわめて重要である。

0005

分析(analysis)については、OLAPの「A」を考慮して、OLAPシステムは一般に最小限のプログラミングで済む、所定の用途に最適な豊富分析機能を提供している。

0006

共用(shared)については、OLAPシステムは通常、共用リソースである。これはOLAPシステムが適切なセキュリティ機能保全性機能を提供するための要件が存在するということを意味する。究極的には、これはデータベースの各セルごとに異なるアクセス制御を提供するということを意味する可能性がある。

0007

多次元(multidimensional)については、多次元性はOLAPシステムにとって主要な要件である。OLAP製品は自身のデータを多次元のフレームワークにおいて提示する。次元とはシステムのデータ値の関連する識別子または属性(たとえば製品、市場、時間、チャネルシナリオ、または顧客)の集積のことである。特定の次元用の集積に属す識別子(たとえば「ロード・オブ・ザ・リング−DVD(TheLord of the Rings-DVD)」、「カリフォルニアサンノゼ(San Jose, California)」、「2002」、「小売りレンタル(RetailRental)」、および「ジョン・Q.パブリック(John Q. Public)」)は一般に階層のような何らかの種類の構造を有する。時として、これらの識別子に対して複数の自然の構造が存在する。

0008

多次元の特徴はOLAPシステムが1つの次元の様々なサブセットと構造上の構成との間に加え、次元の様々な方向(orientation)の間で迅速に切り替わることができる、ということを意味する。OLAPシステムの多次元の性質のために、それらが実装するデータの集積はキューブ(cube:立方体)と呼ばれている。情報(information)については、OLAPシステムは情報を格納するとともに計算する。OLAPシステムのためのデータは多くの場合、少なくとも1つの動作中のシステムに由来するこれらのデータには分析モデルを適用し、その結果はシステムに格納するか、照会時に生成するかする。ある特定のOLAPシステムが管理しうる情報の量は当該システムの一特徴である。

0009

企業は多年にわたりリレーショナル・データベースの中に多次元のデータを星型スキーマまたはスノーフレーク(snowflake:雪片)型スキーマを用いて蓄積し続けてきている。時が経つのにつれて、リレーショナル・データベースの提供業者はこれらのスキーマに照会性能を向上させる最適化を付加している。1990年代に、付加された計算上の複雑さを処理しうるとともに、一般にリレーショナル・エンジンよりも良好に実行しうる多くの専用のデータベースが開発された。

0010

多次元OLAP(MOLAP:multidimensional OLAP)は専用のファイル・システムすなわち索引を用いてキューブ・データを格納するOLAPシステムのファミリーを指す。「Express Web Publisher」、「Essbase」、「TM1」、および「Pilot Suite」は専用の記憶と索引付けの技術に基づいた製品の数例である。マイクロソフト(R)(Microsoft(R))のOLAP商品もMOLAPエンジンを備えている。これらのシステムは多くの場合、基本データとともに周期的にロードされ、次いで抽出されたデータが計算され、格納され、そして索引付けが行われる読み取り専用のシステムである。MOLAPシステムの規模拡張性は多くの場合、その内部で、抽出された結果が計算され、格納されるバッチ・ウインドウのサイズによって限定される。規模拡張性を改善するために、そのようなシステムは多くの場合、抽出された結果の一部を照会時まで遅らせ手段を備えている。

0011

リレーショナルOLAP(relational OLAP:ROLAP)の場合、リレーショナル・データベースの中の多次元データ表現する手段として、多年にわたり星型スキーマが用いられてきた。「MicroStrategy」、「Brio」、「Business Objects」、「Metacube」、「Hyperion」、および「Metaphor」のような多くの商用ソフトウェア開発会社がリレーショナル星型スキーマのためのバッチまたは対話型の多次元の報告探査インターフェースを開発してきた。これらのシステムはすべて、構造化照会言語(StructuredQuery language:SQL)に超集約演算子(super aggregate operator)が追加される前に設計され実装された。

0012

特に、数年前まで、リレーショナル・データベースは照会ごとに単一のレベルのみにおける集約の計算を許可していた。たとえば、「GROUP BY」文節を伴う、ある「SELECT」ステートメントを用いて結果の組を四半期レベルで(すなわち1組の四半期に対して)検索しながら、「GROUP BY」文節を伴う別の「SELECT」ステートメントを用いて月レベルで(すなわち1組の月に対して)結果の組を検索するのが常であった。これは、変動するレベルにおいてセルを計算するために、OLAPシステムにデータベースに対して複数の照会を実行することを強いるものであった。

0013

OLAP型の照会の作成を容易にするため、および、より進歩した最適化を実現するために、インターナシナル・ビジネス・マシーンズ・コーポレーション(International Business Machines Corporation)から入手可能なDB2(R)リレーショナル・データベース管理システム(relationaldatabase Management System:RDBMS)は単一の照会が複数の集約を生成するのを可能にする、SQL標準に追加された3つの新たな超集約演算子、すなわち「ROLLUP」、「CUBE」、および「GROUPINGSETS」を実装した。これらの超集約演算子は「GROUP BY」文節に対する拡張であり、複数のレベルにおいて集約を生成すべきことを指示する。たとえば、1つの「SELECT」ステートメントを用いて複数のレベル(たとえば四半期および月の双方)において集約の計算の結果の組を取得することができる。

0014

これらの超集約演算子は複数のグループ化の組を生成するための単なる便法以上のものである。単一のステートメントにおいて複数のグループ化の組が要求されるから、DB2(R)RDBMSは計算に必要な各入力行を1度だけ参照するような方法で、すべてのグループ化の組を生成する実行計画構築することができる。これは特に入力行の組がバッファプール(すなわちキャッシュ)に適合していないときに、数桁の性能の改善をもたらす可能性がある。

0015

従来技術のシステムは複数の照会を発行することにより、様々なレベルの粒度細分性)を備えた結果を提示する多次元の報告を生成するように設計されていた。複数の照会に対して複数の結果の組を取得し、それら結果の組をマージして単一の報告を作成する。そのようなシステムはデータを検索して多次元の報告を生成するのに、表のための役割のある種の記述(メタデータ)と、必要なSQLステートメントを生成する星型スキーマにおける列とに依存している。正確なメタデータは製品ごとに異なる。

0016

(たとえば「Hyperion」、「Cognos」、および「Microsoft(R)」のような会社に由来する)多次元オンライン分析処理(OLAP)システムは多次元のキューブの各端(edge)のためにメンバの組が与えられると、多次元の結果の組を自然に返すように設計されている。多次元OLAPシステムは任意の照会の結果の一部または全部を事前に計算するようにも設計されている。

発明が解決しようとする課題

0017

リレーショナル・データベースの導入以来、SQLを用いて多次元分析を行ってきたが、リレーショナルOLAPシステムは多次元の結果の組を自然に返すことも、照会の結果の一部または全部を事前に計算することもできなかった。

0018

したがって、改善されたリレーショナルOLAPシステムを求める需要当技術分野には存在する。

課題を解決するための手段

0019

したがって、本発明は、第1の側面において、多次元計算を記述する方法であって:ファクト・メタデータ・オブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照している、ステップと;前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している、ステップとを含む方法を提供する。

0020

好ましくは、前記ステートメントは構造化照会言語ステートメントである。

0021

好ましくは、前記測度メタデータ・オブジェクトの各々は少なくとも1つの構造化照会言語式を指定している。

0022

好ましくは、前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる。

0023

好ましくは、前記テンプレートは列、属性、および測度から成るリストに由来する特定の列、属性、または測度を参照する、トークン表記法を使用している。

0024

好ましくは、前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる。

0025

好ましくは、前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも1つの集約に基づいて生成する。

0026

好ましくは、集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる。

0027

好ましくは、前記次元の組は集約の前記リストにおいて、別の集約関数の中で指定された次元以外のすべての利用可能な次元を含めるために、対応する集約関数のためにNULLを指定する。

0028

好ましくは、前記測度メタデータ・オブジェクトは少なくとも1つの構造化照会言語式を指定し、前記構造化照会言語式は集約から成る前記リストの中の集約に対する入力として使用する。

0029

好ましくは、前記ステートメントはROLLUP文節を構築するために、階層メタデータ・オブジェクトの中のメタデータを用いて生成する。

0030

好ましくは、測度メタデータ・オブジェクトが別の測度メタデータ・オブジェクトを参照する。

0031

好ましくは、構造化照会言語の生成はさらに総計照会のためにSELECTステートメントを生成するステップを含んでいる。

0032

好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのスライスのためのSELECTステートメントを生成るすステップを含んでいる。

0033

好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのためのSELECTステートメントを生成るすステップを含んでいる。

0034

好ましくは、前記方法はさらに、前記少なくとも1つの測度メタデータ・オブジェクトにおいて定義された対称的な測度と非対称の測度とを分離するステップと;前記対称的な測度のための構造化照会言語ステートメントを生成するステップと;前記非対称の測度のための構造化照会言語ステートメントを生成するステップと;前記対称的な測度のための構造化照会言語ステートメントと前記非対称の測度のための構造化照会言語ステートメントとを組み合わせて単一の構造化照会言語ステートメントにするステップとを含んでいる。

0035

好ましくは、前記組み合わせるステップは結合を使用する。

0036

好ましくは、前記方法はさらに、ある測度が少なくとも1つの測度と互換性を有するか否かを判断するステップと;前記測度が少なくとも1つの測度と互換性を有さない場合、前記測度のうちの任意のものが書き直されているか否かを判断するステップと;前記測度のうちの任意のものが書き直されている場合、前記測度を書き直すステップとを含んでいる。

0037

好ましくは、前記方法はさらに、前記キューブ・モデル・メタデータ・オブジェクトの前記サブセットに基づいてキューブ・メタデータ・オブジェクトを生成するステップと、キューブ・ビューの作成のための構造化照会言語ステートメントを生成するステップであって、前記構造化照会言語ステートメントは前記少なくとも1つの測度メタデータ・オブジェクトから生成する、ステップとを含んでいる。

0038

好ましくは、前記方法はさらに、アプリケーションプログラムの制御下で、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトを用いて、多次元情報を検索するための構造化照会言語ステートメントを生成するステップを含んでいる。

0039

第2の側面において、本発明は、多次元計算を記述するシステムであって、ファクト・メタデータ・オブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照している、ステップと;前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している、ステップとを含む少なくとも1つのプログラムを動作させる少なくとも1つのプログラム可能な構成要素を有するコンピュータ・システムを含むシステムを提供する。

0040

好ましくは、前記ステートメントは構造化照会言語ステートメントである。

0041

好ましくは、前記測度メタデータ・オブジェクトの各々は少なくとも1つの構造化照会言語式を指定している。

0042

好ましくは、前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる。

0043

好ましくは、前記テンプレートは列、属性、および測度から成るリストに由来する特定の列、属性、または測度を参照する、トークンの表記法を使用している。

0044

好ましくは、前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる。

0045

好ましくは、前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも1つの集約に基づいて生成する。

0046

好ましくは、集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる。

0047

好ましくは、前記次元の組は集約の前記リストにおいて、別の集約関数の中で指定された次元以外のすべての利用可能な次元を含めるために、対応する集約関数のためにNULLを指定する。

0048

好ましくは、前記測度メタデータ・オブジェクトは少なくとも1つの構造化照会言語式を指定し、前記構造化照会言語式は集約から成る前記リストの中の集約に対する入力として使用する。

0049

好ましくは、前記ステートメントはROLLUP文節を構築するために、階層メタデータ・オブジェクトの中のメタデータを用いて生成する。

0050

好ましくは、測度メタデータ・オブジェクトが別の測度メタデータ・オブジェクトを参照する。

0051

好ましくは、構造化照会言語の生成はさらに総計照会のためにSELECTステートメントを生成するステップを含んでいる。

0052

好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのスライスのためのSELECTステートメントを生成るすステップを含んでいる。

0053

好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのためのSELECTステートメントを生成るすステップを含んでいる。

0054

好ましくは、前記方法はさらに、前記少なくとも1つの測度メタデータ・オブジェクトにおいて定義された対称的な測度と非対称の測度とを分離するステップと;前記対称的な測度のための構造化照会言語ステートメントを生成するステップと;前記非対称の測度のための構造化照会言語ステートメントを生成するステップと;前記対称的な測度のための構造化照会言語ステートメントと前記非対称の測度のための構造化照会言語ステートメントとを組み合わせて単一の構造化照会言語ステートメントにするステップとを含んでいる。

0055

好ましくは、前記組み合わせるステップは結合を使用する。

0056

好ましくは、前記方法はさらに、ある測度が少なくとも1つの測度と互換性を有するか否かを判断するステップと;前記測度が少なくとも1つの測度と互換性を有さない場合、前記測度のうちの任意のものが書き直されているか否かを判断するステップと;前記測度のうちの任意のものが書き直されている場合、前記測度を書き直すステップとを含んでいる。

0057

好ましくは、前記方法はさらに、前記キューブ・モデル・メタデータ・オブジェクトの前記サブセットに基づいてキューブ・メタデータ・オブジェクトを生成するステップと、キューブ・ビューの作成のための構造化照会言語ステートメントを生成するステップであって、前記構造化照会言語ステートメントは前記少なくとも1つの測度メタデータ・オブジェクトから生成する、ステップとを含んでいる。

0058

好ましくは、前記方法はさらに、アプリケーション・プログラムの制御下で、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトを用いて、多次元情報を検索するための構造化照会言語ステートメントを生成するステップを含んでいる。

0059

第3の側面において、本発明は、コンピュータ・システムにロードされ、その上で実行されると、前記コンピュータ・システムに第1の側面に従う方法のすべてのステップを実行させるコンピュータ・プログラム・コードを含むコンピュータ・プログラムを提供する。

0060

多次元計算を記述するプログラムを含むコンピュータ・プログラムは製品の中に組み込むことができ、前記プログラムはオペレーションを実行させるものであり、前記オペレーションは、ファクト・メタデータ・オブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照している、ステップと;前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している、ステップとを含む。

0061

好ましくは、前記ステートメントは構造化照会言語ステートメントである。

0062

好ましくは、前記測度メタデータ・オブジェクトの各々は少なくとも1つの構造化照会言語式を指定している。

0063

好ましくは、前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる。

0064

好ましくは、前記テンプレートは列、属性、および測度から成るリストに由来する特定の列、属性、または測度を参照する、トークンの表記法を使用している。

0065

好ましくは、前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる。

0066

好ましくは、前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも1つの集約に基づいて生成する。

0067

好ましくは、集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる。

0068

好ましくは、前記次元の組は集約の前記リストにおいて、別の集約関数の中で指定された次元以外のすべての利用可能な次元を含めるために、対応する集約関数のためにNULLを指定する。

0069

好ましくは、前記測度メタデータ・オブジェクトは少なくとも1つの構造化照会言語式を指定し、前記構造化照会言語式は集約から成る前記リストの中の集約に対する入力として使用する。

0070

好ましくは、前記ステートメントはROLLUP文節を構築するために、階層メタデータ・オブジェクトの中のメタデータを用いて生成する。

0071

好ましくは、測度メタデータ・オブジェクトが別の測度メタデータ・オブジェクトを参照する。

0072

好ましくは、構造化照会言語の生成はさらに総計照会のためにSELECTステートメントを生成するステップを含んでいる。

0073

好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのスライスのためのSELECTステートメントを生成るすステップを含んでいる。

0074

好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのためのSELECTステートメントを生成るすステップを含んでいる。

0075

好ましくは、前記方法はさらに、前記少なくとも1つの測度メタデータ・オブジェクトにおいて定義された対称的な測度と非対称の測度とを分離するステップと;前記対称的な測度のための構造化照会言語ステートメントを生成するステップと;前記非対称の測度のための構造化照会言語ステートメントを生成するステップと;前記対称的な測度のための構造化照会言語ステートメントと前記非対称の測度のための構造化照会言語ステートメントとを組み合わせて単一の構造化照会言語ステートメントにするステップとを含んでいる。

0076

好ましくは、前記組み合わせるステップは結合を使用する。

0077

好ましくは、前記方法はさらに、ある測度が少なくとも1つの測度と互換性を有するか否かを判断するステップと;前記測度が少なくとも1つの測度と互換性を有さない場合、前記測度のうちの任意のものが書き直されているか否かを判断するステップと;前記測度のうちの任意のものが書き直されている場合、前記測度を書き直すステップとを含んでいる。

0078

好ましくは、前記方法はさらに、前記キューブ・モデル・メタデータ・オブジェクトの前記サブセットに基づいてキューブ・メタデータ・オブジェクトを生成するステップと、キューブ・ビューの作成のための構造化照会言語ステートメントを生成するステップであって、前記構造化照会言語ステートメントは前記少なくとも1つの測度メタデータ・オブジェクトから生成する、ステップとを含んでいる。

0079

好ましくは、前記方法はさらに、アプリケーション・プログラムの制御下で、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも1つの測度メタデータ・オブジェクトを用いて、多次元情報を検索するための構造化照会言語ステートメントを生成するステップを含んでいる。

0080

したがって、好ましくは、多次元計算を記述する方法、システム、およびプログラムを提供する。ファクト・メタデータ・オブジェクトおよび少なくとも1つの次元メタデータ・オブジェクトから生成するキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領する。前記ファクト・メタデータ・オブジェクトは少なくとも1つの測度メタデータ・オブジェクトを参照する。前記キューブ・モデル・メタデータ・オブジェクトおよび前記測度メタデータ・オブジェクトの中のメタデータを用いて多次元情報を検索するためのステートメントを生成する。前記測度メタデータ・オブジェクトの各々は少なくとも1つの集約を指定している。

0081

本発明の記述された実施形態(implementation)はリレーショナルOLAPシステムにおいて多次元計算を記述する方法、システム、およびプログラムを提供する。

発明を実施するための最良の形態

0082

以下の記述においては、その一部を形成するとともに、本発明のいくつかの実施形態を説明する添付図面に対する参照がなされている。本発明の範囲を逸脱することなく、他の実施形態を使用しうる点、および、構造上および動作上の変更をなしうる点が理解される。

0083

〔A.多次元メタデータの導入〕
いくつかの実施形態において、本発明は多次元メタデータ・オブジェクトと当該多次元メタデータ・オブジェクトを使用する手法とを実現する。参照を容易にするために、本発明の好適な実施形態を「OALP多次元メタデータ・システム100」として参照することとし、多次元メタデータ・オブジェクトを「メタデータ・オブジェクト」として参照することとする。

0084

いくつかの実施形態において、インターナショナル・ビジネス・マシーンズ・コーポレーション(International Business Machines Corporation)から入手可能なDB2(R)汎用データベース(UniversalDatabase: UDB)RDBMSにOALP多次元メタデータ・システム100を実装している。本明細書はIBM(R)のDB2(R)UDB RDBMSソフトウェアの使用を記述しているけれども、本発明は「Oracle(R)」、「IBM(R)Informix(R)」、「Sybase(R)」から入手可能なRDBMSソフトウェアのような他のRDBMSソフトウェアを使用しうる、ということを当業者は認識しうる。また、本発明はIBM(R)z/OS(R)、IBM(R)AIX(R)、Microsoft(R)Windows(R)2000、Microsoft(R)Windows(R)XP、Linux(R)、Solaris(R)、HP−UXのような様々なオペレーティング・システムを使用するコンピュータ上で実行することができる。

0085

図1は、ブロック図において、本発明のいくつかの実施形態によるコンピューティング環境を示す。リレーショナル・データベース管理システム(RDBMS:Relational Database Management System)110は多次元メタデータ・ソフトウェア120(たとえば格納プロシージャ型のアプリケーション・プログラミング・インターフェース(API:applicationprogramming interface) とユーザ・インターフェース150とを備えている。RDBMS110は多次元メタデータ・オブジェクト130とリレーショナル・データベース140にアクセスする。いくつかの実施形態では、多次元メタデータ・オブジェクト130の中のデータとリレーショナル・データベース140とを単一のデータベースに格納している。

0086

OLAP多次元メタデータ・システム100は多次元メタデータ・ソフトウェア120(たとえば格納プロシージャ型のアプリケーション・プログラミング・インターフェース(API:application programming interface) )、ユーザ・インターフェース150、および多次元メタデータ・オブジェクト130を含んでいる。多次元メタデータ・ソフトウェア120は多次元メタデータ・オブジェクト130を生成し、格納し、それにアクセスするために使用する。任意選択で、ユーザ・インターフェース150を備え、ユーザまたは管理者が多次元メタデータ・ソフトウェア120にコマンドを送付しうるようにしてもよい。ユーザはユーザ・インターフェース150を介してコマンドを送信することにより、多次元メタデータ・オブジェクト130を生成し、それにアクセスし、それを変更し、または削除する。それらのコマンドは多次元メタデータ・ソフトウェア120が受信して処理する。たとえば、多次元メタデータ・ソフトウェア120は多次元メタデータ・オブジェクト130を生成し、格納する。

0087

いくつかの実施形態では、OLAP多次元メタデータ・システム100はRDBMS110がOLAP処理を実行する能力を向上させるDB2(R)汎用データベース(Universal Database)(ここではDB2(R)UDBと呼ぶ)のような、RDBMS110のためのアドオン(拡張)機能を備えている。本発明の好適な実施形態はOLAPソリューション(解決策)の導入と管理を流線型にし(無駄を無くして合理化し)、OLAPのツールとアプリケーションの性能を向上させている。

0088

特に、OLAP多次元メタデータ・システム100はメタデータ・オブジェクトを備えている。新たなメタデータ・オブジェクトはたとえば、既存のリレーショナル・データの次元モデルとOALP構成体を記述するデータベース・カタログ(たとえばDB2(R)UDBカタログ)に格納する。このデータベース・カタログはそこからOLAPアプリケーションが多次元メタデータを取得しうる単一のリポジトリを備えている。いくつかの実施形態では、メタデータ・オブジェクトはデータベース・カタログではなくデータ・ストア常駐している、あるいは、複数のデータ・ストアの全体にわたって常駐している。中央リポジトリの中の情報により、データベース最適化プログラムは照会の実行を最適化する、星型スキーマに特有の手法を用いることができる。

0089

メタデータ・オブジェクトによって、本発明はサマリー表の中のデータを集約すること、および索引を作成することにより、OLAPの照会の性能を最適化することができる。OLAP多次元メタデータ・システム100はメタデータ・プログラミング・インターフェースも備えている。特に、OLAP多次元メタデータ・システム100はOLAPのツールとアプリケーション開発者のために、SQLに基づくとともに、拡張可能マーク付け言語(XML:extensible mark-up language) に基づいたアプリケーション・プログラミング・インターフェース(API:applicationprogramming interface) を備えている。たとえばコマンド・ライン・インターフェース(CLI:Command Line Interface)、オープンデータベース接続性(ODBC:OpenDatabase Connectivity)、またはJava(R)データベース接続性(JDBC:Java Database Connectivity)の接続により、あるいは、たとえばDB2(R)UDBに対する埋め込み型SQLを使用することにより、アプリケーションとツールは単一の格納プロシージャ(すなわち多次元メタデータ・ソフトウェア120の一例)を用いてメタデータ・オブジェクトを生成し、変更し、検索することができる。いくつかの実施形態では、複数の格納プロシージャがメタデータ・オブジェクトを生成し、変更し、検索する機能を備えている。

0090

OLAP多次元メタデータ・システム100のメタデータ・オブジェクトは関連する情報をインテリジェントなOLAP構造体として記述しているが、本発明が提供する多次元メタデータ・オブジェクトは伝統的なOLAPのオブジェクトとは異なる。本発明のメタデータ・オブジェクトはメタデータを格納している、すなわち、このメタデータ・オブジェクトはデータに関する情報を基本表の中に格納している。メタデータ・オブジェクトは関係するデータがどこに配置されているのかを記述するとともに、基本データ内の関係も記述することができる。たとえば、ファクト(事実)メタデータ・オブジェクトは関連する測度(measure)、属性、および結合に関する情報を格納しているが、基本ファクト表に属すデータは個別には含まない特定のメタデータ・オブジェクトである。

0091

メタデータはデータを理解する基盤をなす新たな観点を提供する。メタデータ・オブジェクトがないと、データベース・カタログは表の名前と列の名前について知っているのみであるから、表と列の意味、あるいは、表と列がどのように相互に関係しているのかということに関する情報を格納することができない。メタデータ・オブジェクトがあると、この情報を格納することができる。

0092

各メタデータ・オブジェクトはリレーショナル・データが意味するものを示す全体像の一片を完成させる。一部のメタデータ・オブジェクトはデータを集約することにより、あるいは、リレーショナル表の中の特定の列に直接に対応することにより、リレーショナル・データに直接にアクセスするためのベース(base)として機能する。他のメタデータ・オブジェクトは基本メタデータ・オブジェクトの間の関係を記述するとともに、これらの基本メタデータ・オブジェクトを相互にリンクさせる。最終的には、すべてのメタデータ・オブジェクトを、互いに対するそれらの関係によってキューブ・モデルと呼ばれるメタデータ・オブジェクトにグループ化することができる。キューブ・モデルはリレーショナル表の特定のグループ化と構成を表している。キューブ・モデルの目的は所定のアプリケーションまたはツールに合わせてOLAP構造体を記述することである。キューブ・モデルは様々なユーザが、分析中のデータを求めうるように、すべてのキューブを記述する傾向がある。キューブ・モデルは次元とファクトをグループ化し、次元のために複数の階層の柔軟性を提供する。キューブ・モデルは星型スキーマのデータベースの上に複雑な照会を生成する照会設計ツールとアプリケーションが必要とする構造上の情報を伝達する。

0093

多次元メタデータ・オブジェクト・モデルは多次元データを表すための、リレーショナル・データベースの中のスキーマを記述するように設計されている。そのようなデータを編成する1つの方法は星型スキーマまたはスノーフレーク型スキーマを使用することによるものである(スノーフレーク型スキーマでは、次元表規格化されている)。しかし、このモデルは十分に柔軟だから、任意の型のスキーマ(たとえばより規格化したスキーマ)を扱うことができる。

0094

〔A.1多次元メタデータの概観
多次元メタデータはデータウェアハウスに格納されているOLAP構造体に関するメタデータの保守を可能にする。この情報は、以前はデータベース・カタログの中で利用できなかった、そして一般に、データウェアハウスのメタデータ・リポジトリによって文書化されていない。多次元メタデータはデータウェアハウスの設計者が表とそれらの列との間の構造上の関係を表現するのに役立つ。一旦、データベース・カタログの中にメタデータが存在すると、データベース最適化プログラム(たとえばDB2(R)UDB最適化プログラム)のような、RDBMS110の他の構成要素はその構造上の情報を利用し、これら新たなOLAPメタデータ・オブジェクトによって記述されたデータに対する照会をより迅速に実行することができる。メタデータ・オブジェクトはデータウェアハウスに対して多次元照会を生成するのに必要な基本構造上の情報を提供することにより、ビジネス・インテリジェンス・ツールを支援することもできる。OLAPの構造上の情報を取得するために、OLAP多次元メタデータ・システム100は新たなメタデータ・オブジェクトをいくつか定義している。これらのメタデータ・オブジェクトはOLAPデータをモデル化するのに頻繁に使用する、星−結合型(star-join)スキーマおよびスノーフレーク型スキーマのようなスキーマの重要な側面を記述することができる。

0095

データベース・カタログにメタデータ・オブジェクトを付加すると、データベースの他の構成要素と相まって、完全な機能性と統合が実現する。新たなメタデータ・オブジェクトは正規表(regular table)の場合と同様に、スキーマが所有する。メタデータ・オブジェクトの別の設計上の要点はそれらの大多数が独立して有用である、という点である。すなわち、メタデータ・オブジェクトは当該メタデータ・オブジェクトがより複雑な多次元構造に含まれているか否かに関わらず、基をなすリレーショナル・スキーマに関する情報を提供する。

0096

キューブ・モデルは多くの方法で構成しうるが、多くの場合、リレーショナルの星型スキーマまたはスノーフレーク型スキーマを表すために構築する。単純な星型スキーマに基づいたキューブ・モデルはファクト表から集約したリレーショナル・データを記述している中央ファクト・メタデータ・オブジェクトの回りに構築する。測度メタデータ・オブジェクトはリレーショナル表の中の列に属すデータの計算を記述するとともに、相互に結合されてファクト・メタデータ・オブジェクトを生成する。図2は本発明のいくつかの実施形態に従い、ファクト・メタデータ・オブジェクト210と測度メタデータ・オブジェクト220、230とがリレーショナル・データ250に関係している様子を示す。

0097

次元メタデータ・オブジェクトは、星型スキーマにおいて次元表がファクト表に接続されているのとまったく同様に、キューブ・モデルにおいてファクト・メタデータ・オブジェクトに接続されている。リレーショナル表に属すデータの列は、相互に結合されて次元メタデータ・オブジェクトを形成している属性メタデータ・オブジェクトによって表されている。

0098

図3は本発明のいくつかの実施形態に従う星−結合型スキーマの実例を示す。この星−結合型スキーマは中央の「Sales(販売)」ファクト表300に結合された「Time(時)」310、「Product(製品)」320、および「Region(地域)」330の次元表を有する。リレーショナル表の中の関連する次元表とファクト表300、310、320、330の列のために属性を生成する。各次元表310、320、330は「TimeID(時ID) 」、「ProductID(製品ID)」、または「RegionID (地域ID) 」のような次元キー属性を有する。地域次元表330は「City(市)」属性と「City_Population(市の人口)」属性も有し、そして「CityPopAR」と名付けられた属性関係も有する。この属性関係は「City(市)」属性の中のすべての値が「City_Population(市の人口)」属性の中の対応する値を決定するという機能的な依存性を表現している。ファクト表の内には、「Sales(販売)」と「Costs(費用)」のための2つの測度と、3つの次元キー属性、「TimeID(時ID) 」、「ProductID(製品ID)」、および「RegionID (地域ID) 」とがある。

0099

3つの結合が各次元表310、320、330を対応する次元キー属性の上の中央ファクト表300に結合している。この例では、次元表310、320、330は「TimeID (時ID) 」属性、「ProductID(製品ID)」属性、および「RegionID (地域ID) 」属性のうちのいずれか1つに基づいてファクト表300に結合している。図4は本発明のいくつかの実施形態に従いリレーショナル表450から次元メタデータ・オブジェクト406、410を構築する様子を示す。たとえば、メタデータ・オブジェクトの間で、次元メタデータ・オブジェクト406は属性メタデータ・オブジェクト408の上に構築されており、属性メタデータ・オブジェクト408はリレーショナル表の中の属性452に接続されている。次元メタデータ・オブジェクト410は属性メタデータ・オブジェクト412、414、および結合メタデータ・オブジェクト416の上に構築されている。これらの属性メタデータ・オブジェクトはリレーショナル表450の中の属性454、456に接続されている。

0100

階層は次元の内の属性がどのように相互に関係付けられて構成されているのかに関する情報を格納している。メタデータ・オブジェクトとして、階層は次元を計算しナビゲートする方法を提供している。各次元は各メンバ属性のために定義されたレベルを備えた対応する階層を有する。たとえば、「Region(地域)」次元は「State(州)」属性と「City(市)」属性のために定義されたレベルを備えた「Region H」階層を有し、「CityPop AR」属性関係も参照する。キューブ・モデルでは、各次元は複数の階層を有することができるが、星型スキーマのこの例は各次元用に定義された階層を1つ有する。

0101

星型スキーマでは、すべての次元メタデータ・オブジェクトが中央のファクト・メタデータ・オブジェクトに星型の形状で接続され、キューブ・モデルを形成している。結合メタデータ・オブジェクトは表を結合してファクト・メタデータ・オブジェクトまたは次元メタデータ・オブジェクトを生成することができる。メタデータ結合はファクト・メタデータ・オブジェクトを次元メタデータ・オブジェクトに結合することにより、キューブ・モデルの内において接着剤としても機能しうる。次元メタデータ・オブジェクトはそれらの構成要素の階層、属性、属性関係、および関連する結合のすべてに関する情報を有している。ファクト・メタデータ・オブジェクトはそれらの構成要素の測度、属性、および関連する結合のすべてに関する情報を有している。

0102

図5は本発明のいくつかの実施形態に従いキューブ・モデルにおいてメタデータ・オブジェクト500が相互に適合しあい、リレーショナル表550のリレーショナルの星型スキーマにマップされている様子を示す。キューブ・モデル・メタデータ・オブジェクト510は次元メタデータ・オブジェクト512、514、結合メタデータ・オブジェクト516、およびファクト・メタデータ・オブジェクト520の上に構築されている。

0103

キューブ・モデル・メタデータ・オブジェクトは特定の用途用により正確なキューブ・メタデータ・オブジェクトを生成するためにその構成要素を再利用しうる柔軟なメタデータ・オブジェクトである。たとえば、1つのキューブ・モデル・メタデータ・オブジェクトは37個のファクトを有しうるが、キューブ・モデル・メタデータ・オブジェクトから生成した1つのキューブ・メタデータ・オブジェクトは少なくとも1つの次元メタデータ・オブジェクト、次元メタデータ・オブジェクトの少なくとも1つのレベル、もしくは、少なくとも1つの測度メタデータ・オブジェクト、または、これらのすべてを除去しうる

0104

キューブ・モデル・メタデータ・オブジェクトに加え、キューブ・メタデータ・オブジェクトと呼ばれるより具体的なメタデータ・オブジェクトがある。キューブ・メタデータ・オブジェクトはOLAPの概念上のキューブに最も近いメタデータ・オブジェクトである。キューブ・メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトの特定のインスタンスすなわちサブセットである。キューブ・メタデータ・オブジェクトは親のキューブ・モデル・メタデータ・オブジェクトから抽出した類似しているがより限定的な、キューブ次元、キューブ階層、OLAPキューブ・ファクトを含む、メタデータ・オブジェクトの特定の組を有している。たとえば、「RegionCubeDim 」は「Region(地域)」次元から抽出した属性のサブセットであるキューブ次元である。「RegionCubeDim」は「State(州)」属性と「City(市)」属性を参照するが、「City_Population(市の人口)」属性または「CityPop AR」属性関係は参照しない。「RegionCubeDim」はそれが精査する「Region(地域)」次元と結合情報を含む構造上のすべての情報とを参照し、キューブ・モデルの「Region(地域)」次元に留まる。

0105

いくつかの実施形態では、キューブ・メタデータ・オブジェクトはキューブ次元ごとに1つのキューブ階層を有し、一方、次元メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトのために定義された多数の階層を有しうる。キューブ・メタデータ・オブジェクトとキューブ・モデル・メタデータ・オブジェクトとの間のこの構造上の相違は単一のSQLステートメントを用いた、キューブ・メタデータ・オブジェクトの検索を可能にする。

0106

図6は本発明のいくつかの実施形態に従い概念上のメタデータ・オブジェクトを3つの層に分類する様子を示す。これらの層は「ベース/リレーショナル」層600、「多次元」層610、および「OLAP」層620である。「ベース/リレーショナル」層600は他のメタデータ・オブジェクトに基本インフラストラクチャを提供するとともに、リレーショナル・データベースの概念をカプセル化する。「多次元」層610は「ベース/リレーショナル」層600の中のメタデータ・オブジェクトを参照してリレーショナル・データベースの上に多次元の抽象化を与えるメタデータ・オブジェクトを含んでいる。「OLAP」層620はOLAP構造体を表す高レベルのメタデータ・オブジェクトを含んでいる。他の層に属すメタデータ・オブジェクトをグループ化することにより、「OLAP」層620は複雑性の程度が異なるOLAPキューブを実現する。

0107

この実施形態のより良き理解のために、一例を提示する。その例はデータマート、星−結合型スキーマにおいて使用する共通の構成に基づいている。星−結合型スキーマの場合、メタデータ・オブジェクトのインスタンスは「ベース/リレーショナル」層、「多次元」層、および「OLAP」層に基づいて作成する。図3は本発明のいくつかの実施形態に従いファクト表300(Fact) 、ならびに、3つの次元表、「Time(時)」310、「Product(製品)」320、および「Region(地域)」340から成る単純な星−結合型スキーマを示す。

0108

既存のデータベース・カタログは通常、表名と列名を格納している。これらの表と列がどのような役割を演ずるのか、そして、これらの表と列は相互にどのように関係しているのかに関する情報は失われている。しかし、OLAP多次元メタデータ・システム100を用いると、この情報はメタデータ・オブジェクトを作成することにより取得される。

0109

図7は本発明のいくつかの実施形態に従い「ベース/リレーショナル」層に対応するメタデータ・オブジェクト700が作成される様子を示す。すべての次元表の列、および結合において使用するファクト表の列について属性が生成されている。ファクト表の中の各ファクト列ごとに1つの測度メタデータ・オブジェクトが生成されている。この星−結合型スキーマにおいて使用する結合は3つの結合メタデータ・オブジェクトによって取得される。これらの結合メタデータ・オブジェクトは対応するファクト表の属性と次元表とをいかにして結合するのかを指示している。「City(市)」と「City_Population(市の人口)」との間の関係、および、「City(市)」属性の中のすべての値が「City_Population(市の人口)」属性の中の値を決定するというファクト(事実)を表すために、「Region(地域)」次元表の中に1つの属性関係が生成されている。

0110

図8は本発明のいくつかの実施形態に従う、「ベース/リレーショナル」層に属す付加的なメタデータ・オブジェクトを示す。関連する属性の間の関係を表す3つの階層800、810、820が作成されている。これらの階層800、810、820は次元を計算してナビゲートする手段を作成するために、次元が多次元層の中で使用する。「Region H 」階層820において、「CityPop AR」属性関係が参照されている。所定の階層に適用される属性関係がすべて取得されている。キューブの文脈において使用するために、階層ごとに1つのキューブ階層850、860、870も作成されている。キューブ階層850、860、870は所定のキューブにとって関心のある階層のレベルを精査するのに使用される。キューブ階層850、860、870はそれに適用される属性関係も取得する。

0111

図9は本発明のいくつかの実施形態に従う、星−結合型スキーマに基づいて生成された、多次元層のメタデータ・オブジェクトを示す。ファクト表「Fact」のために1つの「Facts(ファクト)」メタデータ・オブジェクト900が生成されている。「SalesFacts (販売ファクト)」メタデータ・オブジェクト900は利用可能な測度と結合の大きさを調整するのに必要な、ファクトの中のを属性とを含む。星−結合型スキーマの一部である各次元表ごとに1つの次元メタデータ・オブジェクト910、920、930が生成されている。1つの次元メタデータ・オブジェクトはこの例では単一の次元表に由来し、高度に相互連関されている属性をグループ化している。次元メタデータ・オブジェクトは次元の属性に適用され階層も参照している。次元は定義済みの階層を複数個有しうるが、この例では、次元当たり唯1つの階層が定義されている。

0112

図10は本発明のいくつかの実施形態に従う、キューブを定義するのに使用するメタデータ・オブジェクト1000、1010、1020、1030のインスタンスを示す。キューブの一部である属性と測度を精査するために、キューブ・ファクト、キューブ次元、および、キューブ階層メタデータ・オブジェクトが使用されている。これらのメタデータ・オブジェクトの各々は精査中のメタデータ・オブジェクトを参照しており、結合のような構造上の情報はすべてメイン(すなわち親)のメタデータ・オブジェクトの中に保持されている。キューブに固有のオブジェクトはすべて、それからそれらが定義されたメイン・オブジェクトへの参照を保持している。たとえば、キューブ階層メタデータ・オブジェクトはそれから当該キューブ階層メタデータ・オブジェクトが定義された階層メタデータ・オブジェクトへの参照を有している。いくつかの実施形態では、キューブ次元のために、1つの階層を割り当てている。この例では、「SalesCubeFacts」1000なるキューブ・ファクトが生成されており、キューブの中で使用される測度(「Sales(販売) 」)を列挙している。

0113

OLAP層はキューブ・モデルとキューブ・メタデータ・オブジェクトとによって構成されている。キューブ・モデル・メタデータ・オブジェクトは所定のアプリケーションにとって関心のあるファクトと次元を記述するものである。キューブ・モデル・メタデータ・オブジェクトの次元は定義済みの階層を複数個有しうる。このことはキューブ・モデル・メタデータ・オブジェクトをきわめて柔軟な構造体にしている。キューブ・メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトから抽出する。したがって、すべてのキューブ次元、キューブ階層、およびキューブ・ファクト・メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトから抽出する。キューブ・モデル・メタデータ・オブジェクトとキューブ・メタデータ・オブジェクトとの間の相違は、キューブ・メタデータ・オブジェクトにおいては、次元当たり1つの階層を定義する、という点である。このことは単一のSQLステートメントを用いてキューブ・メタデータ・オブジェクトを検索することを可能にする。

0114

図11は本発明のいくつかの実施形態に従いあるOLAP層の中の各メタデータ・オブジェクトのインスタンスを1つ作成する様子を示す。この例において作成されたキューブ・モデルは図3の星−結合型スキーマの例から生成される可能性のある1つのキューブ・モデル1100を取得する。キューブ1150はキューブ次元「TomeCubeDim 」、「ProductCubeDim」、「RegionCubeDim 」、およびキューブ・ファクト「SalesCubeFacts」に基づいて作成されている。

0115

〔A.2メタデータ・オブジェクトのプロパティ
各メタデータ・オブジェクトはメタデータ・オブジェクトに固有のプロパティに加え、1組の一般のプロパティを有している。この一般のプロパティはメタデータ・オブジェクトのインスタンスを特定するため、メタデータ・オブジェクトのインスタンスの使用方法すなわち役割を記述するため、そして、メタデータ・オブジェクトのインスタンスの変化を追跡するために使用する。いくつかの実施形態では、他のデータベースのメタデータ・オブジェクトに名前を付けるのと同一の方法で、スキーマを用いてメタデータ・オブジェクトに名前を付けている。デフォルトのユーザ名のスキーマが望ましくない場合には、メタデータ・オブジェクトの完全な認定試験が必要になる。

0116

表1は本発明のいくつかの実施形態に従う、すべてのメタデータ・オブジェクトのために存在する一般のプロパティを記載している。

0117

0118

すべてのメタデータ・オブジェクトが共用する一般のプロパティの共通の組に加え、各メタデータ・オブジェクトはメタデータ・オブジェクトに固有のプロパティの組を有している。これらメタデータ・オブジェクトに固有のプロパティは当該メタデータ・オブジェクトを定義する構成要素と品質を記述している。キューブ・モデルは論理的な星型スキーマの代表例である。キューブ・モデルは中央のファクト・メタデータ・オブジェクトの回りに関連する次元メタデータ・オブジェクトをグループ化するものである。各次元は複数の階層を有しうる。このことはキューブ・モデルの柔軟性を高める。ファクトと次元メタデータ・オブジェクトが使用する表を結合する方法に関する構造上の情報はキューブ・モデルに格納する。キューブ・モデルには、OLAPデータを検索するための十分な情報も格納されている。キューブ・モデルを理解しうるとともに、特定の次元の複数の階層を取り扱いうる他の報告ツールとOLAPツールはキューブ・モデルの使用から恩恵を受けることができる。

0119

キューブ・モデルは関係の複雑な組を定義しており、関係するファクトと次元をアプリケーションに公開するのに使用することができる。次元を中央のファクト・メタデータ・オブジェクトに接続している各結合メタデータ・オブジェクトは対応する次元とともに組として格納する。キューブ・モデルの構成要素のサブセットは様々な分析目的のために多数のキューブが使用することができる。

0120

ファクト・メタデータ・オブジェクトも何らの次元も有さない空のキューブ・モデルを作成することができる。しかし、このキューブ・モデルは対応するキューブを作成する前に終了する。OLAP多次元メタデータ・システム100は当該キューブ・モデルがファクト・メタデータ・オブジェクト、少なくとも1つの次元、および既存のファクトと次元との間の結合を含むこと、および、すべての属性が有効な表を参照していることを保証することにより、キューブ・モデルを有効にしている。あるキューブ・モデルが完全なものであると考えるために階層を必要としないが、キューブ・モデルからキューブを定義するために、次元ごとに少なくとも1つの階層を定義する。

0121

各メタデータ・オブジェクトは当該メタデータ・オブジェクトを定義する構成要素と品質を記述するメタデータ・オブジェクトに固有のプロパティの組を有している。キューブ・モデルのメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い表2に記載する。

0122

0123

ファクト・メタデータ・オブジェクトは所定のアプリケーションにとって関心のある関連する測度をグループ化する。複数のリレーショナル・ファクト表を特定の属性について結合して付加的な関連測度にマップすることができる。ファクト・メタデータ・オブジェクトはファクト−次元結合において使用している属性に関する情報、ならびに、複数のデータベースの表の全体にわたって付加的な測度をマップするのに使用する属性および結合を格納している。したがって、1組の測度に加え、ファクト・メタデータ・オブジェクトは1組の属性と1組の結合を格納している。キューブ・モデルでは、ファクト・メタデータ・オブジェクトを星型スキーマの中心として使用する。

0124

ファクト・メタデータ・オブジェクトは星型スキーマにおけるファクト表の役割を演じる。ファクト表が行っているのとまったく同様に、ファクト・メタデータ・オブジェクトはデータベース・カタログの中で測度によって表されている測定実体(measurement entity)を収集する。これらは同一の表に由来している必要はないから、設計者は任意のOLAPアプリケーションのために必要に応じて測度をグループ化することができる。

0125

ファクト・メタデータ・オブジェクトの、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い表3に記載する。

0126

0127

次元メタデータ・オブジェクトは星型スキーマにおける次元表の役割を演じる。次元は少なくとも1つの測度のある側面を共に記述している関連する属性をグループ化する。したがって、次元メタデータ・オブジェクトは測度のある側面を共に記述している関連する属性の組を分類する方法を提供する。キューブ・モデルでは、ファクト・メタデータ・オブジェクトの中のデータを「Region(地域)」、「Product(製品)」、または「Time(時)」のような論理カテゴリに従って分類するのに次元を使用する。関連する属性とこれらの属性をグループ化するのに必要な結合とは共に次元メタデータ・オブジェクトに固有のプロパティの中に定義する。

0128

次元は少なくとも1つの階層を参照する。階層は次元属性の関係と構成を記述しており、次元のナビゲーションと計算を推進するのに使用することができる。

0129

次元は当該次元が時指向であるか否かを記述する型も有している。たとえば、「Time(時)」と呼ばれる次元は「Year(年) 」、「Quarter(四半期) 」、および「Month(月) 」のようないくつかの属性を含むことができ、時(time)型になりうる。「Region (地域)」と呼ばれる別の次元は「Country(国) 」、「State(州) 」、「City (市) 」、および「Population (人口) 」のようないくつかの属性を含むことができ、通常(regular)型になりうる。型の情報はアプリケーションが時関連の関数をインテリジェントかつ適切に実行するのに使用することができる。

0130

次元メタデータ・オブジェクトのメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い表4に記載する。

0131

0132

階層はキューブ・モデルの所定の次元の内の1組の少なくとも1つの属性の間における関係を定義している。これらの関係を定義することは、所定の次元を横断するナビゲーション上および計算上の手段を提供する。1つのキューブ・モデルの1つの次元のために複数の階層を定義することができる。階層メタデータ・オブジェクトは階層を他の関連する属性にリンクさせる1組の属性関係も参照する。属性関係によって直接に関係付けられている属性は階層の一部として照会することができる。たとえば、「Region (地域) 」次元のための階層は「City (市) 」属性を有することができ、1つの属性関係によって「City (市) 」を「City_Population(市の人口) 」属性にリンクさせることができる。この階層は「City (市) 」を含む照会の中に「City_Population (市の人口) 」の情報を含めることができる。

0133

階層は属性の間の親−子関係を記述している。この情報は次元が、どうすれば次元のメンバを閲覧しうるのか、および、当該次元の中のデータをどのように集約するのかを示すために参照する。

0134

層型階層内の属性の間の関係を記述している。次に示す4つの階層型がサポートされている。すなわち、均衡型(balanced)、不均衡型(unbalanced)、不揃型(ragged) 、およびネットワーク型(network)である。

0135

図12は本発明のいくつかの実施形態に従う、均衡型階層1200の一例を示す。均衡型階層は不変の深さを有する有意のレベルと分岐を備えたものである。各属性の論理上の親は当該属性の直上のレベルに存在している。均衡型階層1200は「Year (年) 」、「Quarter(四半期) 」1220、および「Month(月) 」1230といった各レベルの意味と深さが不変である時を表している。

0136

図13は本発明のいくつかの実施形態に従う、不均衡型階層1300の一例を示す。不均衡型階層は不変の親−子関係を有するが、特定のレベルにおけるすべてのメンバについて意味構造不定の意味を有するものである。また、この階層の分岐の深さは不定である。

0137

不均衡型階層は組織図(organization chart) を表すことができる。たとえば、不均衡型階層1300は階層の最上層レベルにCEOを、その下に分岐しうる、最高業務執行責任者(chiefoperating officer)と秘書室長(executive secretary)を含む少なくとも2人の人々を示している。最高業務執行責任者も多くの人々を分岐させているが、秘書室長はそうしていない。CEOと当該CEOの監督下にあるすべての人々との間には親−子関係が存在する。しかし、CEOの直下のレベルの意味構造上の意味は当該レベルに様々な型の従業員が存在するから、不定である。

0138

不揃型階層は、各レベルは不変の意味を有しているが、分岐が、1つの分岐に存在する少なくとも1つのメンバの属性が充足されていない不定の深さを有しているものである。不揃型階層は市または国といった各レベルの意味が一貫して使用されているが、階層の深さが変動する地理的階層を表すことができる。図14は本発明のいくつかの実施形態に従う不揃型階層1400を示す。不揃型階層1400は定義済みの「Continent(大陸) 」レベル、「Country(国) 」レベル、「Province/State (地方/州) 」レベル、および「City(市) 」レベルを有する地理的階層を示している。1つの分岐は「Continent(大陸) 」として「アメリカ」を、「Country(国) 」として「合衆国」、「Province/State(地方/州) 」として「カリフォルニア」、「City (市) 」として「サンフランシスコ」を有している。しかし、階層1400は1つのメンバがすべてのレベルにおいてエントリを有していない場合、不揃型になる。たとえば、別の分岐は「Continent(大陸)」として「ヨーロッパ」、「Country(国) 」として「ギリシャ」、「City (市) 」として「アテネ」を有するが、「Province/State (地方/州)」レベルのためにはエントリを有していない(なぜなら、このレベルは「ギリシャ」には適用できないからである)。この例では、「ギリシャ」分岐と「合衆国」分岐は異なる深さまで下降して、不揃型階層1400を形成している。

0139

ネットワーク型階層はレベルの順序は指定されていないが、レベルは意味構造上の意味を有しているものである。図15は本発明のいくつかの実施形態に従い「Color(色) 」、「Size (サイズ) 」、「PackageType(容器の型) 」のような、製品の属性を記述するネットワーク型階層1500を示している。属性のレベルが固有の親−子関係を有していないから、レベルの順序は変動する。ある小間物(widget)会社は「Color(色)」のための「白」、「Size (サイズ) 」のための「小」、および「PackageType(容器の型) 」のための「収縮包装(shrink wrap)」といったメンバ・エントリを有しているかもしれない。第2のメンバ・エントリは「Color(色)」のために「赤」、「Size (サイズ) 」のために「大」、および「PackageType(容器の型) 」のために「箱」を有しているかもしれない。

0140

階層(均衡型、不均衡型、不揃型、またはネットワーク型)は当該階層のための展開(deployment)機構も指定する。展開機構は階層の属性をどのように解釈するのかを定義する。次に示す2つの展開機構がサポートされている。すなわち、標準と再帰的である。

0141

標準展開機構は、階層の中の各属性が1つのレベルを定義している、階層のレベルの定義を使用する。たとえば、「Time (時) 」次元のための均衡型階層は「Year (年) 」、「Quarter(四半期) 」、および「Month(月) 」を含む定義済みの各レベルによって構成することができる。標準展開は4つの階層型のすべてのものとともに使用することができる。表5は本発明のいくつかの実施形態に従い「Time(時) 」次元のための均衡型階層の属性のうちのいくつかを標準展開を用いてどのように構成するのかを示している。

0142

0143

再帰的展開機構は階層の属性の間における固有の親−子関係を使用する。再帰的展開を使用する不均衡型階層は親−子型属性対として表す。たとえば、表6は本発明のいくつかの実施形態に従い図13の組織図を記述する不均衡型階層のための属性対を示している。この親−子型属性対は最高経営責任者と秘書室長、最高経営責任者と最高業務執行責任者、最高業務執行責任者と通信部長、通信部長と通信担当者を含んでいる。再帰的展開は不均衡型階層とともに使用する。

0144

0145

階層メタデータ・オブジェクトのメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表7に記載する。

0146

0147

測度メタデータ・オブジェクトは測定実体を定義しており、ファクト・メタデータ・オブジェクトの中で使用する。測度は次元の文脈の内において有意になる。たとえば、「300」の売上は単独では有意ではない。売上なる測度を「Region(地域)」のような次元の文脈に置くと、当該測度は有意になる。たとえば、バーモント州の売上は「300」である。測度メタデータ・オブジェクトの共通の例は「Revenue(売上)」、「Cost(費用)」、および「Profit (利益) 」である。

0148

測度オブジェクトは測定実体の存在を明示的にする。測度は少なくとも1つのSQL式によって定義されるが、それはテーブル列へのマッピングと同程度に単純でありうるし、あるいは、複数の列、および他の測度または属性を含みうる。各測度ごとに、集約のリストを定義してキューブ・モデルまたはキューブの文脈における計算の用に供する。このリストの中の各集約はSUM、COUNTMIN、MAXのような集約関数と、当該集約関数を適用する次元のリストとを指定している。集約の中の空の次元の組は測度の中で非明示的に参照されている残りの次元をすべて使用すべきことを表している。最初に使用する集約関数がCORRELATIONのように複数の入力を必要とする場合、測度は複数のSQL式を有することになる。測度は、それが単一のSQL式のテンプレートを有し、かつ、それが他の測度を参照するのみである場合、集約の空のリストを有する可能性がある。この場合、参照されている測度の集約が実行される。測度と属性は同一の名前空間を共用する。すなわち、名前は、スキーマによって完全に資格が付与されると、測度と属性の間で一意になるはずである。測度の共通の例は「Sales(販売) 」、「Costs(費用) 」、「Profit (利益) 」などである。

0149

測度はSQL式の集約によって定義する。テーブル列、属性、および測度を、SQL式を構築するためのテンプレート(すなわち「SQL式テンプレート」)にマップする。次いで、結果として得られたSQL式を測度の第1の集約関数のための入力として使用する。測度が複数の集約を有する場合、集約関数はそれらが列挙されている順番に実行し、後続する各集約は先行する集約の結果を入力として取得することになる。測度メタデータ・オブジェクトのSQL式が他の測度を参照するのみである場合、参照されている測度は必要とされる何らかの集約を記述しているから、集約関数は省力する。

0150

測度のSQL式は2つのプロパティ、すなわちSQL式テンプレートと列、属性、および測度のリストとの組み合わせによって生成する。SQL式テンプレートは、{$$n}がトークンであり、nは当該リストに属す特定の列、属性、または測度を参照している、トークンの表記法を使用している。列、属性、および測度のリストは順序付けられており、列、属性、および測度のリストの中の位置はトークンの「n」値に対応している。

0151

最初の集約への入力としてSQL式を使用する。各集約は対応する次元の組に適用する関数を指定している。集約関数はたとえばSUM、COUNT、MIN、MAX、およびCORRELATIONを含む、基になるデータベースがサポートしている任意の集約関数でありうる。いくつかの実施形態では、測度メタデータ・オブジェクトによって各次元を1度だけ集約する。次元の組が空である場合、集約関数は、リストの中の別の集約が使用中であることが明確ではない、キューブまたはキューブ・モデルの中のすべての次元に適用する。いくつかの実施形態では、集約関数はRDBMS110がサポートしているユーザ定義の集約関数である。

0152

単純など測度の一例は「Revenue(売上) 」である。「Revenue(売上)」測度は3つの次元、すなわち「Product(製品) 」、「Market (市場) 」、および「Time
(時」) を備えたキューブ・モデルのために生成することができる。「Revenue(売上)」はSQL式テンプレート(テンプレート= " {$$1 }" )を有し、これは列、属性、および測度の単一項目のリストの中に指定されている列への単一のマッピングである(ただし、リスト="ColumnFact.Rev"である)。集約リストは(SUM,<NULL>)である(ただしSUMは集約関数、<NULL>は空の次元の組である)。SUMなる集約関数のための入力としてSQL式を使用するから、結果はSQL、すなわち、SUM(Fact.Rev)になる。

0153

より複雑な測度「Profit (利益) 」はSQL式テンプレート(テンプレート=" {$$1 }- {$$2 }" )(ただし属性、列、および測度のリストは、リスト="Measure revenue,Column fact.Cost"である)を有している。トークンを正確な参照で置換すると、SQL式は"Revenue -Fact.Cost" になる。売上測度の参照をその列の参照に拡張すると、SQL式は"Fact.Rev - Fact.Cost"になる。「Profit(利益) 」測度の集約リストは(SUM,<NULL>)である。利益のSQL式をSUMなる集約関数のための入力として使用すると、「Profit (利益) 」測度のためのSQLはSUM(Fact.Rev- Fact.Cost)になる。

0154

測度が少なくとも2つのパラメータを必要とする、CORRELATIONのような集約関数を有する場合、当該測度は当該関数が入力として必要とする個数のSQL式を有することになる。すなわち、パラメータの個数はSQL式の個数と一致する。たとえば、CORRELATIONが2つのパラメータを必要とする場合、2つのSQL式が存在することになる。

0155

測度はSQLデータ型に基づくデータ型も有する。OLAP多次元メタデータ・システム100は測度のデータ型を自動的に判定する。また、測度と属性は同一の名前空間を共用している。したがって、各名前はスキーマによって完全に資格を付与されると、測度と属性の間で一意になる。測度メタデータ・オブジェクトのメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表8に記載する。

0156

0157

属性はデータベースのテーブル列の基本的な抽象化を表している。属性はテーブル列への単純なマッピングでありうる、複数の列と他の属性を含みうる、そして、基になるデータベースの、ユーザ定義の関数のような機能をすべて含みうるSQL式によって定義する。いくつかの実施形態では、SQL式を定義する際に他の属性を使用する場合、当該他の属性は属性参照ループを形成することができない。たとえば、属性Aが属性Bを参照している場合、属性Bは属性Aを参照することはできない。

0158

属性のSQL式は2つのプロパティ、すなわちSQL式テンプレートと列および属性のリストとの組み合わせによって作成する。SQL式テンプレートは、{$$n}がトークンであり、nは当該リストに属す特定の列または属性を参照している、トークンの表記法を使用している。列および属性のリストは順序付けられており、列または属性のリストの中の位置はトークンの「n」値に対応している。

0159

たとえば、SQL式テンプレート(テンプレート= " {$$1 }||'' ||{$$2 }" )はリスト="Column CUSTOMER.FIRSTNAME, AttributeLasdtName" のような対応するリストとともに使用し、顧客の名(first name)および姓(last name)とそれらの間の空間とを連結することができる。SQL式テンプレートのトークンを正確なリストの参照で置換すると、SQL式は"Customer.FirstName||' ' || LastName"になる。"Customer.FirstName ||' ' ||Costomer.LastName" なるSQL式を形成するには、属性の参照を列の参照にまでさらに拡張する。

0160

属性はデータウェアハウスまたはデータマートの設計において複数の役割を果たすことができる。属性が果たしうる役割はレベル、記述、次元属性、次元キー、またはキーである。

0161

レベル属性(level attributed)は階層において使用される。共通のレベル属性(levelattribute)の例は「Year (年) 」と「Quarter(四半期) 」、「State(州) 」と「City (市) 」である。記述属性は記述型の属性関係において使用され、付加的な記述情報を別の属性に関連付ける。たとえば、「Product(製品)」と呼ばれる表は製品コードと本文の(textual)記述を備えた記述属性とを備えた属性を有しうる。次元属性は次元型の属性関係において使用され、別の属性の特定の特徴と品質を定義している。共通の次元属性の例は「Population(人口) 」、「Size (サイズ) 」、および「Weight (重量) 」である。次元キー属性はファクトと次元メタデータ・オブジェクトとを結合するのに使用され、次元表の中の主キー、または、ファクト表において使用すべき次元表に属す外部キーを表す。キー属性はファクト・メタデータ・オブジェクトまたは次元メタデータ・オブジェクトの内の表を結合するのに使用される。キー属性は多くの場合、スノーフレーク型スキーマにおいて使用される。

0162

属性と測度は同一の名前空間を共用している。したがって、各名前はスキーマによって完全に資格が付与されると、属性と測度の間で一意になる。属性と測度はリレーショナル・データベースの列の抽象化である。しかし、それらは複数の列を含みうるSQL式によって定義されている。測度は属性よりも特殊化している−−それらは低レベルのデータから高レベルのサマリーを算出するのに使用する集約関数(列関数)を備えている。

0163

表9は本発明のいくつかの実施形態に従う、属性メタデータ・オブジェクトを定義するメタデータ・オブジェクトに固有のプロパティを記述している。

0164

0165

属性関係は一般に属性の関係を記述している。これらの関係は左属性(leftattribute)および右属性(right attribute)、型、基数(cardinality:カルディナリティ)、ならびに、当該関係が関数依存性を決定しているか否か、によって記述する。型は左属性に対する右属性の役割は何かを記述する。たとえば、「ProductName(製品名)」なる右属性は「ProductCode(製品コード) 」なる左属性を記述している。「ProductName(製品名) 」と「ProductCode(製品コード)」との間の関係型が「DESCRIPTION」である。基数は左属性のインスタンスと右属性のインスタンスがどのように関係しているのかを記述している。「1:1」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは高々1つ存在し、左属性の各インスタンスに対して右属性のインスタンスは高々1つ存在する。「1:N」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは高々1つ存在し、左属性の各インスタンスに対して右属性のインスタンスは任意個数存在する。「N:1」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは任意個数存在し、左属性の各インスタンスに対して右属性のインスタンスは高々1つ存在する。「N:N」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは任意個数存在し、左属性の各インスタンスに対して右属性のインスタンスは任意個数存在する。

0166

関数依存性のプロパティは属性関係が関数依存性として使用しうるか否かを見分ける。関数依存性は2つの属性の間の関数関係を定義している。たとえば、「City (市) 」と「Mayor(市長) 」、または「Product(製品) 」と「Color(色) 」といった属性の間で関数依存性を定義することができる。関数依存性はすべての「City(市) 」値は1つの「Mayor(市長) 」値を決定している、あるいは、すべての「Product(製品) 」値は1つの「Color(色) 」値を決定している、ということを見分ける。これは、関係において記述される基数は設計者が設定する、ということを意味する。

0167

属性関係の1つの使用方法は次元における階層の文脈の内ある。階層属性に直接に関係している属性は当該階層の一部として照会することができる。これは当該階層の各レベルが所定のレベルの情報を補完する属性を定義することを可能にする。たとえば、ある階層は「City (市) 」属性を有しうる。この「City (市) 」属性は属性関係を用いて「City_Population (市の人口) 」属性に関係付けることができる。属性関係の情報を用いると、「City_Population(市の人口) 」なる情報は「City (市) 」を含む照会に含めることが可能になる。

0168

属性関係メタデータ・オブジェクトを定義するメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表10に記載する。

0169

0170

結合メタデータ・オブジェクトは2つのメタデータ・オブジェクトが参照しているリレーショナル表を結合する。2つのメタデータ・オブジェクトはリレーショナル表の列にマップされている属性メタデータ・オブジェクトの少なくとも1つの対について結合することができる。ファクト−次元結合では、結合メタデータ・オブジェクトはファクト・メタデータ・オブジェクトに由来する属性と次元メタデータ・オブジェクトに由来する属性とを結合する。複合結合では、属性対の組は表の同一の組に由来している。たとえば、「FirstName 」と「LastName」から成る複合キーを備えたリレーショナル表である「Table1」と、「FName 」と「LName」から成る複合キーを有するリレーショナル表である「Table2」とを結合するには、2つの結合述部、すなわち「Table1.FirstName」および「Table2.FName」のための1つの結合述部と「Table1.LastName」および「Table2.LName」のための第2の結合述部とを備えた1つのリレーショナル結合を使用する。この複合結合に関する情報は1つの結合メタデータ・オブジェクトに格納する。

0171

結合メタデータ・オブジェクトは左属性、右属性、および結合演算子から成るリストによって定義する。また、結合型と予期される基数を指定する。結合は2つのファクトの間、2つの次元の間、または、ファクトと次元の間で使用することができる。結合メタデータ・オブジェクトはキューブ・モデル・オブジェクト、ファクト・オブジェクト、および次元オブジェクトが参照する。

0172

結合メタデータ・オブジェクトを定義する、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表11に記載する。

0173

0174

キューブは単一のSQLステートメントを用いて伝達しうる、OLAPキューブのきわめて正確な定義である。各キューブは単一のキューブ・モデルから抽出する。キューブ・ファクトとキューブ次元のリストとは参照元のキューブ・モデルにおけるもののサブセットである。データベースの中のキューブを表すキューブ・ビューの名前も定義する。キューブ次元はキューブ次元当たり1つのキューブ階層しか許可しないから、キューブは複数の階層を使用しないツールとアプリケーションに相応している。

0175

キューブの目的はOLAP構成の標準のリレーショナル・ビューを定義することである。リレーショナル・ビューに加え、キューブはその列の役割を多次元の観点から記述する拡張記述(extended describe)(たとえばXML文書)を提供する。キューブを定義するプロセスにおいて、設計者は利用可能な(possible)構成要素のサブセットを選定し、各次元ごとに単一の階層を選ぶ。これはキューブが単一のリレーショナルな結果の組を曖昧に定義することを保証する。キューブの単純性はキューブを、ワールドワイドウェブ(WorldWide Web: 「ウェブ(Web) 」)サービスによって強化された携帯用装置のようなあまり高機能ではないOLAPの用途にとって有用にする。

0176

キューブ・メタデータ・オブジェクトの、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表12に記載する。

0177

0178

キューブ・ファクト・メタデータ・オブジェクトは特定のファクト・メタデータ・オブジェクトに由来する順序付けられたリストの中の測度のサブセットを有する。キューブ・ファクト・メタデータ・オブジェクトはキューブに、キューブ・モデルのためのファクトを精査する柔軟性を付与する。結合と属性のような構造上の情報は親のファクト・メタデータ・オブジェクトから参照される。キューブ・ファクト・メタデータ・オブジェクトの、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表13に記載する。

0179

0180

キューブ次元メタデータ・オブジェクトはキューブの中で使用する次元を精査するのに使用する。キューブ次元メタデータ・オブジェクトはそれが抽出される元をなす次元と、所定のキューブのための関連するキューブ階層とを参照する。いくつかの実施形態では、1つのキューブ次元に1つのキューブ階層を適用することができる。キューブ次元に適用されている結合と属性は次元定義から参照される。キューブ次元メタデータ・オブジェクトを定義する、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表14に記載する。

0181

0182

キューブ階層メタデータ・オブジェクトは階層の精査済み版(scopedversion)であり、キューブの中で使用する。キューブ階層はそれが抽出される元をなす階層を参照するとともに、親の階層に由来する属性のサブセットを有しうる。また、キューブ階層メタデータ・オブジェクトはキューブに適用されている属性関係を参照する。いくつかの実施形態では、1つのキューブの1つのキューブ次元ごとに1つのキューブ階層を定義することができる。キューブ階層メタデータ・オブジェクトは当該キューブ階層メタデータ・オブジェクトが抽出される元をなす階層と同一の階層型および展開機構を有している。

0183

キューブ階層は階層にきわめて似ている。しかし、キューブ次元は1つのキューブ階層のみを参照する。これは単一の「SELECT」ステートメントがキューブのセルを計算するのを可能する。

0184

キューブ階層メタデータ・オブジェクトを定義する、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表15に記載する。

0185

0186

図16は本発明のいくつかの実施形態に従う、いくつかのメタデータ・オブジェクトの間のいくつかの関係を示す。矢印はあるメタデータ・オブジェクトが別のメタデータ・オブジェクトを参照することを表している。たとえば、キューブ・メタデータ・オブジェクト1610はキューブ・モデル・メタデータ・オブジェクト1600を参照する。メタデータ・オブジェクトの関係のより詳細な記述を、本発明のいくつかの実施形態に従い表16に記載する。

0187

0188

いくつかの実施形態によれば、メタデータ・オブジェクトの命名規約と命名のための規則とが存在する。本発明の範囲を逸脱することなく、ここで記述したもの以外の命名の規約と規則を使用することができる。オブジェクトを命名する命名規約には2つの異なるもの、すなわち,通常型と区切り型(delimited)がある。メタデータ・オブジェクトの場合、その柔軟性ゆえに、オブジェクトを命名するとき、および、データベースの表と列を参照するときには区切り型の規約を使用する。区切り型の規約は大文字小文字が混合した名前、空間、および、各国語文字のような特別の文字を認めている。文字の完全な組はオブジェクトが常駐しているデータベースのコード・ページによって決まる。

0189

いくつかの実施形態では、命名規約の外に、オブジェクトの中の様々な識別子にいくつかの規則を適用する。たとえば、スキーマの長さは1〜30バイトであり、スキーマの名前は「SYS」で始まらない;名前の長さは1〜128バイトである;ビジネスの名前の長さは1〜128バイトである;コメントの長さは0〜254バイトである;(列を参照する際に使用する)表スキーマの長さは1〜128バイトである;(列を参照する際に使用する)表の名前の長さは1〜128バイトである;そして、(列を参照する際に使用する)列の名前の長さは1〜128バイトである。

0190

強制されている関係に加え、各メタデータ・オブジェクトごとに付加的な規則が記述されている。すなわち、あらゆるメタデータ・オブジェクトはそれ自体の規則の組を有し、メタデータ・オブジェクトのインスタンスは、当該メタデータ・オブジェクトが当該メタデータ・オブジェクトのためのすべてのメタデータ・オブジェクト規則に従う場合に、有効になる。これらの規則は3つのカテゴリ、すなわち「基本規則(Base Rules) 」、「キューブ・モデル完全性規則(Cube Model Completeness Rules)」、および「最適化規則(OptimizationRules)」に分かれる。次に示す特定の規則の検討は本発明のいくつかの実施形態のための1組の規則を提供する。他の実施形態では、少なくとも1つのメタデータ・オブジェクトのための規則の組を、本発明の範囲を逸脱することなく、変更している。

0191

キューブ・モデル・メタデータ・オブジェクトのための基本規則は、(1)キューブ・モデル・メタデータ・オブジェクトは0個または1個以上のファクト・メタデータ・オブジェクトを参照する;(2)キューブ・モデル・メタデータ・オブジェクトは0個または1個以上の次元を参照する;(3)次元−結合対は次元および結合の双方を有する;(4)結合の一側のすべての属性がファクト・メタデータ・オブジェクトの属性リストの中に存在し、かつ、すべての他側の属性が次元メタデータ・オブジェクトの属性リストの中に存在する場合、次元に付随する結合は有効になる;および、(5)キューブ・モデルのファクトの中で参照されている各測度ごとに、当該測度の集約におけるすべての明示的な次元の参照は当該キューブによって参照される、である。キューブ・モデルが少なくとも1つの次元を参照している場合、空の次元の組を用いた集約はそれまで参照されなかった、当該キューブ・モデルに由来する少なくとも1つの次元と一致する。

0192

キューブ・メタデータ・オブジェクトのための基本規則は、(1)キューブ・メタデータ・オブジェクトは1つのキューブ・ファクトを参照する;(2)キューブ・メタデータ・オブジェクトは少なくとも1つのキューブ次元を参照する;(3)キューブ・ファクトはキューブ・モデルの中で使用しているファクトから抽出する;および、(4)キューブ次元はキューブ・モデルの中で使用している次元から抽出する、である。

0193

ファクト・メタデータ・オブジェクトのための基本規則は、(1)ファクト・メタデータ・オブジェクトは少なくとも1つの測度を参照する;(2)ファクトが参照する属性と測度はすべて結合可能である;(3)ファクト・メタデータ・オブジェクトの文脈では、所定の2つの表の間に単一の結合を定義することができる;(4)ファクト・メタデータ・オブジェクトの中に、結合のループはない;および、(5)ファクト・メタデータ・オブジェクトが参照するすべての結合はファクト・メタデータ・オブジェクトの属性を参照する、である。

0194

次元メタデータ・オブジェクトのための基本規則は、(1)次元メタデータ・オブジェクトは少なくとも1つの属性を参照する;(2)次元が参照する属性は結合可能てある;(3)結合ループはない;(4)次元の文脈では、任意の2つの所定の表の間で単一の結合が定義されている;(5)ある次元が参照する階層は当該次元の属性を参照する;(6)ある次元の階層が参照する属性関係は当該次元の属性を参照する;および、(7)ある次元が参照する結合は当該次元の属性を参照する、である。

0195

キューブ・ファクト・メタデータ・オブジェクトのための基本規則は、(1)キューブ・ファクト・メタデータ・オブジェクトは少なくとも1つのファクトを参照する;(2)キューブ・ファクト・メタデータ・オブジェクトは少なくとも1つの測度を参照する;(3)キューブ・ファクト・メタデータ・オブジェクトが参照るす測度はファクト・メタデータ・オブジェクトの一部である、である。

0196

キューブ次元メタデータ・オブジェクトのための基本規則は次のとおりである。(1)キューブ次元メタデータ・オブジェクトは1つの次元を参照する;(2)キューブ次元メタデータ・オブジェクトはキューブ階層を参照する;および、(3)キューブ次元メタデータ・オブジェクトが参照するキューブ階層はキューブ次元メタデータ・オブジェクトの次元が参照している階層から抽出する。

0197

階層メタデータ・オブジェクトのための基本規則は、(1)階層メタデータ・オブジェクトは少なくとも1つの属性を参照する;(2)再帰的な展開のために2つの属性を必要とする;(3)ある階層の内部のすべての属性関係は当該階層の一部として左属性を有する;(4)階層の内のすべての属性関係は「1:1」または「N:1」の基数を有する;および、(5)階層の型と階層の展開とのいくつかの組み合わせは本発明のいくつかの実施形態に従い表17のように表すことが可能である、である。

0198

0199

キューブ階層メタデータ・オブジェクトのための基本規則は、(1)キューブ階層メタデータ・オブジェクトは1つの階層を参照する;(2)キューブ階層メタデータ・オブジェクトは少なくとも1つの属性を参照する;(3)キューブ階層メタデータ・オブジェクトが参照する属性は当該階層の一部である;(4)キューブ階層メタデータ・オブジェクトにおける属性の順序は(ネットワークとして定義された階層を例外として)階層におけるものと同一である;(5)階層の内のすべての属性関係は当該階層の一部として左属性を有する;および、(6)キューブ階層メタデータ・オブジェクトにおいて参照される属性関係はキューブ階層を定義する階層においても参照される、である。

0200

測度メタデータ・オブジェクトのための基本規則は、(1)測度メタデータ・オブジェクトは各SQL式テンプレートのためのパラメータとして、属性、列、測度を有しうるが、あるいは、これらをまったく有さなくともよい;(2)SQLテンプレートとして使用する属性と測度は属性の間、もしくは、測度の間、または、属性および測度の間に依存ループを生成することができない;(3)測度メタデータ・オブジェクトにおいて定義されるすべてのSQLテンプレートは空のストリングではない;(4)SQLテンプレートは集約関数を使用しない;(5)少なくとも1つの測度、そして測度のみを参照する場合、集約は必要ではない;(6)SQLテンプレートの個数は第1の集約関数のパラメータの個数と一致する;(7)複数のSQLテンプレートを備えた測度メタデータ・オブジェクトは集約スクリプトの中に少なくとも1つの集約ステップを定義する;(8)測度メタデータ・オブジェクトAが、複数のSQLテンプレートを定義する測度メタデータ・オブジェクトBを参照する場合、測度メタデータ・オブジェクトAは集約スクリプトを有さない;この規則は測度参照ツリーにおけるすべてのレベルに対して適用される;(9)第1の集約として、複数パラメータ型の集約関数を使用する;(10)測度メタデータ・オブジェクトが少なくとも1つの集約を定義している場合、1つの集約は空の次元の組を有している;(11)測度メタデータ・オブジェクトの内では、1つの集約の内において、または、複数の集約の全体にわたって、次元を2回以上参照する;(12)SQL式テンプレートの内では、トークンの標識(すなわち{$$#})は「1」から計数を開始するが、計数が途切れることなく連続している;および、(13)SQL式の内では、すべての列、属性、および測度は少なくとも1回は参照される、である。

0201

属性メタデータ・オブジェクトのための基本規則は、(1)属性メタデータ・オブジェクトはSQLテンプレートのためのパラメータとして、属性、列を有しうるが、あるいは、これらをまったく有さなくともよい;(2)SQLテンプレートのためのパラメータとして使用する属性は属性の間にループを生成することができない;(3)SQLテンプレートは空のストリングまたはブランク・ストリングではありえない;(4)SQLテンプレートの一部になることを許可されている集約関数はない;(5)SQL式テンプレートの内では、トークンの標識(すなわち{$$#})は「1」から計数を開始するが、計数が途切れることなく連続している;(6)SQL式の内では、すべての列、属性、および測度を少なくとも1回は参照する、である。

0202

属性関係メタデータ・オブジェクトのための基本規則は、(1)属性関係メタデータ・オブジェクトは2つの属性を参照する;および、(2)属性関係メタデータ・オブジェクトは「基数=N:N」および「関数依存性=YES」を有するように定義することはできない、である。

0203

結合メタデータ・オブジェクトのための基本規則は、(1)結合メタデータ・オブジェクトは左属性、右属性、および演算子から成る少なくとも1つのトリプレットを参照する;(2)結合メタデータ・オブジェクトの中のすべての左属性は単一の表の少なくとも1つの列に帰着する;(3)結合メタデータ・オブジェクトの中のすべての右属性は単一の表の少なくとも1つの列に帰着する;および、(4)結合メタデータ・オブジェクトの各トリプレットは有効な演算を定義する;左属性および右属性のデータ・タイプ、ならびにそれらのために定義された演算は互換性がある、である。

0204

キューブ・モデルが他のメタデータ・オブジェクトへの必要なリンクを有することを保証するために、キューブ・モデル完全性規則は基本規則を拡張して有効なウェアハウスSQL照会を実行しうるようにする。キューブ・モデル・メタデータ・オブジェクトのためのキューブ・モデル完全性規則は、(1)キューブ・モデル・メタデータ・オブジェクトは1つのファクトを参照する;(2)キューブ・モデル・メタデータ・オブジェクトは少なくとも1つの次元を参照する、である。

0205

最適化規則はウェアハウスSQL照会の最適化を実行しうることを保証するために、キューブ・モデル完全性規則を拡張する。

0206

キューブ・モデル・メタデータ・オブジェクトのための最適化規則は、(1)ファクト−次元において使用する結合は「1:1」または「N:1」なる基数を有し、ファクト表を次元の主表に結合する、である。

0207

次元メタデータ・オブジェクトのための最適化規則は、(1)次元の結合によって形成される結合ネットワークを考慮すると、少なくとも1つの表(主表)が存在し、その中では、この表から発散しているすべての結合が「N:1」または「1:1」なる基数を有する、である。

0208

結合メタデータ・オブジェクトのための最適化規則は、(1)結合に参加する列について定義した制約が存在する;結合が自己結合である(すなわち、等式の両側で列の同一の組を使用する)場合、当該列の組と一致する主キーを定義する;他のすべての場合において、一方の側の列の組が結合の他方の側と異なる場合、主キーは結合の一方の側の列と一致し、外部キーは主キーを参照するのに加え、列の他の組と一致する;(2)結合の基数は「1:1」、「N:1」、または「1:N」である;結合が自己結合である場合、基数は「1:1」である;他のすべての結合の場合において、基数は主キーが定義されている側では「1」であり、外部キーが定義されている側では「N」である;外部キー側がそれについて定義された主キーも有する場合、基数として「1」を使用する;(3)結合において使用するすべての属性はヌル可能でないSQL式に帰着する;(4)結合のタイプは「INNERJOIN」である、である。

0209

〔A.4メタデータ・オブジェクトの例〕
図17は本発明のいくつかの実施形態に従う、2つの次元表1710、1720とファクト表1700から成る星型スキーマを示す。2本の線1730、1740がファクト表1700と次元表1710、1720の間を結合している。いくつかの実施形態では、データベースの設計者はモデル化ツールまたはユーザ・インターフェース130を用いて、メタデータ・オブジェクト130のメタデータ・オブジェクト・インスタンスを生成する。多次元メタデータの生成の間に定義される大多数のメタデータ・オブジェクト130は当該メタデータ・オブジェクトが新たなモデルと重なり合っている場合には、当該新たなモデルのために再使用することができる。

0210

図18〜22は本発明のいくつかの実施形態に従う、メタデータ・オブジェクト・インスタンスのありうる組と、簡単化のために、図17の星型スキーマのために生成されるメタデータ・オブジェクトのいくつかのプロパティとを示す。特に、図18〜22では省略したプロパティのうちのいくつかは共通のプロパティである。たとえば、図18〜22はキューブ・モデル・メタデータ・オブジェクト・インスタンス1800、キューブ・メタデータ・オブジェクト・インスタンス1802、ファクト・メタデータ・オブジェクト・インスタンス1804、キューブ・ファクト・メタデータ・オブジェクト・インスタンス1806、測度メタデータ・オブジェクト・インスタンス1808、1810、次元メタデータ・オブジェクト・インスタンス1812、1814、キューブ次元メタデータ・オブジェクト・インスタンス1816、1818、階層メタデータ・オブジェクト・インスタンス1820、1822、1824、キューブ階層メタデータ・オブジェクト・インスタンス1826、1828、結合メタデータ・オブジェクト・インスタンス1830、1832、および、属性メタデータ・オブジェクト・インスタンス1834〜1848を示す。

0211

ユーザはユーザ・インターフェース150を用いてメタデータ・オブジェクトを作成する。空のキューブ・モデル・メタデータ・オブジェクトを作成したのち、ファクト・メタデータ・オブジェクトと次元メタデータ・オブジェクトを作成し、適切な結合メタデータ・オブジェクトを作成することにより、キューブ・モデル・メタデータ・オブジェクトに結合させる。

0212

ここで検討したメタデータ・オブジェクトのプロパティは本発明の範囲を逸脱することなく、変更することができる。

0213

〔B.リレーショナル・オンライン分析処理(OLAP)エンジンのために多次元計算を記述する〕
OLAP多次元メタデータ・システム100は多次元計算を支援する、測度メタデータ・オブジェクトの作成を可能にする。いくつかの実施形態では、測度メタデータ・オブジェクトは表8の中で定義されている特定のプロパティを含む。

0214

測度メタデータ・オブジェクトの中の測度はSQL式の集約によって定義する。特に、テーブル列、属性、および測度をSQL式テンプレートにマップしてSQL式を構築する。次いで、結果として得られたSQL式を、測度メタデータ・オブジェクトの第1の集約関数のための入力として使用する。測度メタデータ・オブジェクトが複数の集約を有する場合、集約関数はそれらが列挙されている順序で実行し、後続する各集約は先行する集約の結果を入力として取得する。測度メタデータ・オブジェクトのSQL式が他の測度を参照しているのみの場合、参照される測度が、必要な集約をすべて記述しているから、集約関数を省略する。

0215

測度の計算において使用するSQL式は2つのプロパティ、すなわちSQL式テンプレートのリストと、列、属性、および測度から成るリストとによって作成する。このSQL式テンプレートは、{$$n}がトークンであり、nはリストに属す特定の列、属性、または測度を参照している、トークンの表記法を使用する。列、属性、および測度のリストは順序付けられており、列、属性、または測度のリストの中における位置はトークンの「n」値に対応している。大多数の集約関数の場合、大多数の集約関数は入力として単一の式を受領するから、リストの中のSQL式テンプレートの個数は「1」である。しかし、CORRELATIONのような集約関数を使用する場合、SQL式テンプレートの個数は当該集約関数が受領する入力パラメータの個数と一致する。

0216

ここでも、第1の集約への入力としてSQL式を使用する。各集約は対応する次元の組に適用される関数を指定する。集約関数はたとえばSUM、COUNT、MIN、MAX、およびCORRELATIONを含む、基になるRDBMS110にサポートされた任意の集約関数でありうる。いくつかの実施形態では、測度メタデータ・オブジェクトが各測度を一旦集約する。次元の組が空である場合には、リストの中の任意の他の集約が明らかに使用中でないキューブまたはキューブ・モデルの中のすべての次元に集約関数を適用する。

0217

多次元メタデータ・ソフトウェア120は測度メタデータ・オブジェクトの中のメタデータを用いて、キューブ・ビューの生成のためのSQLステートメントを生成する。

0218

〔B.1測度の要件〕
この節は本発明のいくつかの実施形態に従う、測度のいくつかの要件を記述している。

0219

測度の一要件は測度の内において特定の計算順序をサポートすることである。キューブ・モデル・メタデータ・オブジェクトまたはキューブ・メタデータ・オブジェクトが参照する測度メタデータ・オブジェクトの組のための計算順序は同一である必要はない−−各測度メタデータ・オブジェクトは任意の他の測度メタデータ・オブジェクトの計算順序とは異なる計算順序を指定することができる。たとえば、「Quantity Sold = SUM(Revenue / UnitPrice) (販売数量=合計(売上/単価) 」、および「ProfitMargin = SUM(Profit) / SUM(Revenue) (利幅=合計(利益)/合計(売上) 」。図23は本発明のいくつかの実施形態に従う、基本データを示す表A1900を示す。「Clothes(衣料品)」と名付けられたメンバは「Trousers (スボン) 」1902、「Shirt(シャツ) 」1904、および「Tie(ネクタイ) 」1906の親であり、「UnitPrice (単価) 」1910と「Revenue(売上) 」1912を用いて「Quality Sold for Clothes (衣料品の販売数量) 」を算出する。すなわち、(680/40)+(780/60)+(175/25)=17+13+7=37である。「Clothes(衣料品)」の「Profit Margin(利幅)」は「Revenue(売上) 」1912と「Profit (利益) 」1914を用いて算出する。すなわち、(68+117+52.5)/(680+780+175)=237.5/1635=0.145である。

0220

測度の別の要件は相関演算(たとえば、CORRELATION(Revenue,Profit) (相関(売上、利益) ) のような複数の入力パラメータを有する集約関数をサポートすることである。測度オブジェクトは集約関数の各入力ごとに独立した式を定義することを必要とする。

0221

測度のさらに別の要件はスナップショット測度(たとえば、Inventory(在庫))のような半付加的(semi-additive)な測度をサポートすることである。たとえば、「Market(市場) 」次元と「Product(製品) 」次元のために、合計演算(たとえば、SUM(Inventory) (合計 (在庫)))を実行する。「Time (時)」次元のために、MIN(最小)演算(たとえば、MIN(Inventory) (最小 (在庫)))を実行する。

0222

図24は本発明のいくつかの実施形態に従う、(SUM, Market) (合計,市場)と(MIN, Time) (最小,時) なる集約を有する測度を示す表B2000を示す。表B2000において、アスタリスク(たとえば「*」)またはプラス符号「たとえば「+」)を有さない数は基本データを表す。アスタリスクを有する数は(SUM,Market) (合計,市場) に対する集約を示す。プラス符号を有す数は(MIN, Time) (最小,時) に対する集約を示す。たとえば、「1月」2004に対するとともに「カリフォルニア」2002に対する(SUM,Market) (合計,市場) は「28」であり、「四半期1」に対するとともカリフォルニア2002に対する(MIN, Time) (最小,時) は「25」である。

0223

測度の付加的な要件は次元当たり1つの集約をサポートすること、次元の全体にわたって異なる計算順序をサポートすること、および、高度の応用(たとえば、「(SUM, Product) (合計,製品) 」、「(AVG, Market)(平均,時) 」、「(MAX, Market)(最大,市場)」を用いて、最大平均在庫を有する市場の所在を探索すること)を目標にすることである。高度の応用を目標にするとは半付加的な測度をより一般的に表現することであるが、それは図30を参照して後述する。また、高度の応用を目標にすることの要件は非対称測度によって表されるが、それは後述する。非対称測度は集約リストの中で複数の集約を定義する。

0224

図25〜28は本発明のいくつかの実施形態に従う、集約、すなわち「(SUM,Product) (すなわち製品の合計) 」、「(AVG, Time) (すなわち時にわたる平均)」、および「(MAX, Market)(すなわち市場の最大値)」を有する測度を示す表C2100を示す。表C2100において、アスタリスク(たとえば「*」)またはプラス符号(「たとえば「+」)またはダッシュ(たとえば「−」)を有さない数は基本データを表す。すなわち、図25にベース・データが示されている。図26では、表C2100において、「(SUM,Product) (合計,製品) 」のための集約のための数が付加されており、アスタリスクによって識別されている。たとえば、「January(1月)」2105について「LosAngels (ロサゼルス) 」2104における「Clothes(衣料品) 」の場合、「(SUM, Product) (合計,製品) 」は「66」である。図27では、表C2100において、「(AVG,Time)(平均,時) 」のための集約のための数が付加されており、プラス符号によって識別されている。たとえば、「第1四半期(QTR1)」2109における「SanJose(サンノゼ)」2108における「ズボン(Trousers)」2106の場合、「(AVG, Market)(平均,時) 」は「11」である。図28では、「(MAX,Market)(最大,市場) 」用の数が付加されており、ダッシュによって識別されている。たとえば、「January(1月)」2105における「California(カリフォルニア)」2112における「Shirt(シャツ) 」2110の場合、「(MAX, Market)(最大,市場) 」は「36」である。

0225

〔B.2測度を記述する〕
本発明のいくつかの実施形態では、式のリストと集約のリストとを含む測度メタデータ・オブジェクトを作成する。測度メタデータ・オブジェクトは節Aにおいて詳細に検討した。理解を容易にするために、この節においても測度メタデータ・オブジェクトを検討することにする。測度メタデータ・オブジェクトの中の式のリストは各式のためのSQL式テンプレートと、各SQL式のための列のリスト、属性、および測度とを含む。集約のリストの中の各エントリは集約関数と対応する次元の組とを含む。空の次元は残りの次元をすべて集約関数のために使用すべきことを意味する。いくつかの実施形態では、測度メタデータ・オブジェクトの場合、1つの集約のみが空の次元の組を有しうる。

0226

図29は本発明のいくつかの実施形態に従う、2つの完全に付加的な測度メタデータ・オブジェクト(「費用(Cost)」2210と「売上(revenue)」2220)の作成を示す。図29の例では、3つの次元、すなわち製品(Product)2202、市場(Market)2204、および時(Time)2206が存在する。各測度メタデータ・オブジェクト2210、2220は<NULL>なる次元の組を指定しているが、これはSUMなる集約関数のためにすべての次元を使用することを意味する。

0227

「費用」測度メタデータ・オブジェクト2210は3つの次元、すなわち製品2202、市場2204、および時2206を備えたキューブ・モデルのために作成されている。「費用」測度メタデータ・オブジェクト2210はSQL式テンプレート2212(テンプレート=“{$$1}”)有するが、これは列、属性、および測度から成る単項目のリスト(リスト=“Column Fact.Cost”)への単純なマッピングを表している。すなわち、「費用」測度メタデータ・オブジェクト2210の場合、式のリストは“{$$1}”を参照するが、それはSQL式を生成するときに「ColumnFact.Cost」で置換されるトークンである。集約リスト2214は(SUM,<NULL>)(ただし、SUMは集約関数であり、<NULL>は空の次元の組である)である。SQL式テンプレート2212に由来するSQL式はSUMなる集約関数のための入力として使用し、結果として「SUM(Fact.Cost)」というSQLになる。

0228

「売上」測度メタデータ・オブジェクト2220は3つの次元、すなわち製品2202、市場2204、および時2206を備えたキューブ・モデルのために作成する。「売上」測度メタデータ・オブジェクト2220はSQL式テンプレート2222(テンプレート=“{$$1}”)を有するが、これは列、属性、および測度から成る単項目のリスト(リスト=“Column Fact.Rev")への単純なマッピングを表している。すなわち、「売上」測度メタデータ・オブジェクト2220の場合、式のリストは“{$$1}”を参照するが、それはSQL式を生成するときに「ColumnFact.Rev 」で置換されるトークンである。集約リスト2224は(SUM,<NULL>)(ただし、SUMは集約関数であり、<NULL>は空の次元の組である)である。SQL式テンプレート2222に由来するSQL式はSUMなる集約関数のための入力として使用し、結果として「SUM(Fact.Rev)」というSQLになる。

0229

図30は本発明のいくつかの実施形態に従う半付加的な測度の作成を示す。「在庫(Inventory)」測度メタデータ・オブジェクト2310はSQL式テンプレート2312(テンプレート=“$$1”)を有するが、これは列、属性、および測度から成る単項目のリスト(この場合、リスト="ColuumnFact.Inv")への単純なマッピングを表している。「在庫」測度メタデータ・オブジェクト2310において、集約リスト2314は2つの集約、SUMとAVG(すなわち平均)を含む。「在庫」測度メタデータ・オブジェクト2310は「時」なる次元のリストを集約するから、集約リストはSUMのために<NULL>を指示し(これは、すべての次元がリストにおいて参照されているわけではない〔すなわち、時以外のすべての次元であり、この例の場合には製品や市場でありうる〕、ということを意味する)、「時」のためにAVGを指示している。SUM演算を最初に実行し、その合計演算の結果を用いてAVG演算を実行する。結果として得られるSQL式は複数の集約ステップを含む。理解を容易にするために、結果として得られるSQL式の単純な例を提示する。たとえば、結果として得られるSQL式はAVG(S1)である(ただし、S1はSUM(Fact.Inv)の結果である)。

0230

図31は本発明のいくつかの実施形態に従う、集約を備えた複合測度の作成を示す。この場合、「利益(Profit)」測度メタデータ・オブジェクト2410は事前に定義した測度を使用し、実行すべき集約を決定する。「利益」のようなより複雑な測度はSQL式テンプレート2412(テンプレート=“{$$1}−{$$2}”)(ただし、列、属性、、および測度から成るリストは「リスト=“MeasureRevenue, Column Fact.Cost"」である)を有する。すなわち、式のリストは“{$$1}−{$$2}”を含むが、これは第1のトークン{$$1}は「売上」測度メタデータ・オブジェクト2220からの集約の結果で置換され、第2のトークン{$$2}は「費用」測度メタデータ・オブジェクト2210からの集約の結果で置換される、ということを表している。トークンを正確な参照で置換すると、SQL式は“Revenue- Fact.Cost"になる。「売上」測度の参照をその列の参照に拡張すると、SQL式は"Fact.Rev -Fact.Cost"になる。

0231

「利益」測度メタデータ・オブジェクト2410の集約リスト2414は(SUM,<NULL>)である。集約リスト2410において、<NULL>なる次元の組はSUM演算のためのすべての次元を表すために使用されている。「利益」SQL式をSUMなる集約関数のための入力として使用すると、「利益」測度のSQL式はSUM(Fact.Rev - Fact.Cost)になる。すなわち、利益は、売上から費用をすべて減算したものを合計することにより得られる。

0232

図32は本発明のいくつかの実施形態に従う、集約のない複合測度の作成を示す。この場合、「利幅(Profit Margin)」測度メタデータ・オブジェクト2510は事前に定義された測度メタデータ・オブジェクト(すなわち「売上」測度メタデータ・オブジェクト2220と「利益」測度メタデータ・オブジェクト2410)を使用し、実行すべき集約を何ら必要としない(これは集約リスト2414の中のある集約の代わりに<NULL>によって表示されている)。この場合、当該集約は基本測度に由来する。

0233

「利幅」測度メタデータ・オブジェクトはSQL式テンプレート2512(テンプレート=“{$$1}/{$$2}”)を有する。第1のトークン{$$1}は「利益」測度メタデータ・オブジェクト2410からの集約の結果によって置換し、一方、第2のトークン{$$2}は「売上」測度メタデータ・オブジェクト2220からの集約の結果によって置換する。したがって、「利幅」測度メタデータ・オブジェクトのための、結果として得られるSQL式は「SUM(Fact.Rev - Fact.Cost)/SUM(Fact.Rev)」である。すなわち、利益の合計を計算し、売上の合計を計算し、そして利益を売上で除算して利幅を得る。

0234

図33は本発明のいくつかの実施形態に従う、OLAP関数を用いた、測度の作成を示す。「利益順位(Profit Rank)」測度メタデータ・オブジェクト2610は(たとえばDB2(R)UDBRDBMSから利用できる)RANK関数を用いて「利益」測度を順位付ける。新たな「利益順位」測度メタデータ・オブジェクト2610は集約を何ら必要としない。特に、「利益順位」測度メタデータ・オブジェクト2610はSQL式テンプレート(テンプレート=“RANK()OVER (ORDER BY{$$1})”)を有するが、これは第1のトークンは{$$1}は「利益」測度メタデータ・オブジェクト2410からの集約の結果で置換する、ということを表す。集約リスト2614は集約関数の代わりに<NULL>を備えることにより、集約は存在しない、ということを表している。RANK測度の結果として得られるSQL式は「RANK()OVER(ODERBY SUM(Fact.Rev- Fact.Cost))」である。

0235

図34は本発明のいくつかの実施形態に従う、集約と複数の入力とを備えた測度を示す。「売上−利益相関(RevProfit Correlation)」測度メタデータ・オブジェクト2710は「売上」測度メタデータ・オブジェクト2220と「利益」測度メタデータ・オブジェクト2410とを利用する。「売上−利益相関」測度メタデータ・オブジェクトは各々が{$$1}によって表される第1のトークンを備えた2つのSQL式テンプレート2712、1713を有する。SQL式テンプレート2712(テンプレート=“{$$1}”)の場合、第1のトークン{$$1}は「売上」測度メタデータ・オブジェクト2220からの集約の結果で置換する。SQL式テンプレート2713(テンプレート=“{$$1}”)の場合、第1のトークン{$$1}は「利益」測度メタデータ・オブジェクト2410からの集約の結果で置換する。次いで、相関を実行する。相関とは2つの一連の数がどの程度良好に相互に関連するかの測定結果を与える統計関数のことである。「相関」測度のための、結果として得られるSQL式はCORRELATION(Fact.Rev,(Fact.Rev-Fact.Cost)) である。集約リスト2714はCORRELATION演算とすべての次元を表す<NULL>なる次元の組とを指定している。

0236

図35は本発明のいくつかの実施形態に従う、図29〜34に由来するすべての定義済みの測度メタデータ・オブジェクトを示す。一部の測度メタデータ・オブジェクトは他のものの上に構築する。たとえば、「売上−利益相関」測度メタデータ・オブジェクト2710は「売上」測度メタデータ・オブジェクト2220と「利益」測度メタデータ・オブジェクト2410の上に構築し、一方、「利益」測度メタデータ・オブジェクト2410は「費用」測度メタデータ・オブジェクト2210と「売上」測度メタデータ・オブジェクト2220の上に構築する。

0237

〔B.3 少なくとも1つの測度メタデータ・オブジェクトによって表される測度のためのSQLステートメントを生成する〕
多次元メタデータ・ソフトウェア120は測度メタデータ・オブジェクトによって表される単一のSQLステートメントを生成する。図36は本発明のいくつかの実施形態に従い少なくとも1つの測度メタデータ・オブジェクトからSQLステートメントを生成する論理を示す。制御はブロック2900において、少なくとも1つの測度メタデータ・オブジェクトの各々のもののための測度記述の受領と、測度記述に基づいた、図29〜35において説明した測度メタデータ・オブジェクトのうちの少なくとも1つのもののような、少なくとも1つの測度メタデータ・オブジェクトの生成とによって開始する。ブロック2902において、すべての測度メタデータ・オブジェクトを参照しているファクト・メタデータ・オブジェクトのファクト記述を受領し、ファクト記述からファクト・メタデータ・オブジェクトを生成する。また、ファクト記述は属性メタデータ・オブジェクトと結合メタデータ・オブジェクトを参照する。ブロック2903において、少なくとも1つの次元メタデータ・オブジェクトの各々のための次元記述を受領し、この次元記述から少なくとも1つの次元メタデータ・オブジェクトを生成する。次元記述は少なくとも1つの属性メタデータ・オブジェクト、0個または1個以上の結合メタデータ・オブジェクト、および少なくとも1つの階層メタデータ・オブジェクトを参照している。各階層メタデータ・オブジェクトはROLLUP文節を構築するのに使用する情報を含む。特に、本発明のいくつかの実施形態では、キューブ・モデル・メタデータ・オブジェクトはいくつかの利用可能な階層を参照するが、SQLの生成にはただ1つの階層の選択を必要とするのみである。ブロック2904において、ファクトと少なくとも1つの次元メタデータ・オブジェクトとを参照するキューブ・モデル・メタデータ・オブジェクトのキューブ・モデル記述を受領し、このキューブ・モデル記述からキューブ・モデル・メタデータ・オブジェクトを生成する。ブロック2906において、キューブ・モデル記述のサブセットの選択を受領する。ブロック2908において、この選択に基づいて、キューブ・メタデータ・オブジェクトを生成する。また、少なくとも1つの測度メタデータ・オブジェクトの中のメタデータからキューブ・ビューを作成するSQLステートメントを生成する。SQLステートメントの生成は他のメタデータ・オブジェクト(たとえば階層メタデータ・オブジェクト)の中の他のメタデータも使用する。

0238

特に、SQLステートメントの生成は階層メタデータ・オブジェクトの中のメタデータから少なくとも1つのROLLUP演算子を生成する。ROLLUP演算子(「GROUP BY」文節の拡張)は列のリストに基づいて複数の小計(subtotal)のグループ化文節を生成する。グループ化文節は階層メタデータ・オブジェクトに由来する情報を用いて生成する。これはOLAPの観点からは、所定の次元における階層の計算と同じ効果を有する。国、州、および市から成る階層を有する場所のような次元を考える。ROLLUP(国,州,市)なる文節は当該階層の計算を表すグループ化文節を生成する。n個の構成要素(c1, c2, . . . , cn-1,cn)から成るROLLUPは次に示すグループ化文節と等価である。
(c1,c2, . . . , cn-1, cn)
(c1,c2, . . . , cn-1)
· ··
(c1,c2)
(c1)

0239

ROLLUP文節の中のn個の構成要素が(n+1)個のグループ化文節に変換される点に留意されたい。OLAPアプリケーションは(たとえば次元メタデータ・オブジェクトの中で定義される)複数の次元を有する。各次元のためのROLLUPはOLAPキューブを表す結果をリレーショナルな方法で返す。単一のステートメントにおいて複数のROLLUP演算子を組み合わせると、グループ化文節の直積演算(Cartesian product)が各ROLLUPごとに生成されることになる。たとえば、ROLLUP(国,州)なる単一のステートメントに次に示すROLLUP演算子の対を組み合わせると、次に示す文節が生成されるが、それらはキューブを構成する1組のグループ化文節である。
(国,州,年,月)
(国,州,年)
(国,州)
(国,年,月
(国)
(年,月)
(年)
( )

0240

ROLLUP演算子を使用する照会は単一の結果の組の中にすべての生成済みのグループ化文節を含んでいる。したがって、この結果の組はすべてのグループ化文節の列に加え集約済みの列を含んでいる。次の例において示すように、様々なグループ化の組の結果を組み合わせるために、所定の行がメンバではないすべてのグループ化列においてヌル(null)を返す。単一の次元におけるROLLUP照会の結果については表18を参照されたい。ROLLUP演算子を含むSELECTステートメントを生成する。メタデータ・オブジェクト130に基づいて、SELECTステートメントを生成する。たとえば、下のSELECTステートメントでは、測度メタデータ・オブジェクトから「合計」演算子を生成し、結合メタデータ・オブジェクトから結合を生成している。

0241

SELECT country,state、sum(amt) AS revenue
FROMファクトf,location 1
HERE f.lid = 1.lid
GROUP BY ROLLUP(country,state)

0242

0243

表18における例では、州の列における(ダッシュで示されている)ヌルによって、アメリカ合衆国(USA)の総売上を有する行を指定している。国の列および州の列の双方におけるヌルによって、すべての国と州の総売上を備えた行を指定している。

0244

図36はキューブ・ビューを生成するために測度メタデータ・オブジェクトを使用することを記述しているけれども、付加的な実施形態では、キューブ・ビューを生成することなく、測度メタデータ・オブジェクトを使用する。すなわち、キューブ・ビューは計算を指定するために測度メタデータ・オブジェクトの定義を使用する1つの方法である。測度メタデータ・オブジェクトの定義を使用する別の方法は、アプリケーションが測度の定義とキューブ・モデルのメタデータとを読み取り、測度の定義とキューブ・モデルのメタデータとからSQLステートメントを直接に生成することである。

0245

図37は本発明のいくつかの実施形態に従い少なくとも1つの測度メタデータ・オブジェクトとキューブ・モデル・メタデータ・オブジェクトとからSQLステートメントを生成する論理を示す。制御はブロック2910において、少なくとも1つの測度メタデータ・オブジェクトの各々のための測度記述の受領と、測度記述に基づいた、図29〜35において説明した測度メタデータ・オブジェクトのうちの少なくとも1つのもののような、少なくとも1つの測度メタデータ・オブジェクトの生成とによって開始する。ブロック2912において、すべての測度メタデータ・オブジェクトを参照するファクト・メタデータ・オブジェクトのファクト記述を受領し、このファクト記述からファクト・メタデータ・オブジェクトを生成する。また、ファクト記述は属性メタデータ・オブジェクトと結合メタデータ・オブジェクトを参照する。ブロック2913において、少なくとも1つの次元メタデータ・オブジェクトの各々のための次元記述を受領し、この次元記述から当該少なくとも1つの次元メタデータ・オブジェクトを生成する。次元記述は少なくとも1つの属性メタデータ・オブジェクト、0個または1個以上の結合メタデータ・オブジェクト、および少なくとも1つの階層メタデータ・オブジェクトを参照する。各階層メタデータ・オブジェクトはROLLUP文節を構築するのに使用する情報を含んでいる。特に、本発明のいくつかの実施形態では、キューブ・モデル・メタデータ・オブジェクトはいくつかの利用可能な階層を参照するが、SQLの生成にはただ1つの階層の選択を必要とするのみである。ブロック2914において、ファクトと少なくとも1つの次元メタデータ・オブジェクトとを参照するキューブ・モデル・メタデータ・オブジェクトのキューブ・モデル記述を受領し、このキューブ・モデル記述からキューブ・モデル・メタデータ・オブジェクトを生成する。ブロック2916において、キューブ・モデル・メタデータ・オブジェクトのサブセットの選択をアプリケーション・プログラムによって行う。ブロック2918において、アプリケーション・プログラムの制御下で、キューブ・モデル・メタデータ・オブジェクトと上記測度メタデータ・オブジェクトのうちの少なくとも1つのものとを用いて、多次元の情報を検索するSQLステートメントを生成する。このSQLステートメントの生成は他のメタデータ・オブジェクト(たとえば階層メタデータ・オブジェクト)の中の他のメタデータも使用する。

0246

多次元メタデータ・ソフトウェア120は単一のSQLステートメントを備えた複数の測度を計算する際における主要な問題点(すなわち、測度の対称性、含まれている集約関数の分配、および順序(order)次元が集約スクリプトの中に現れる)を取り扱う。また、多次元メタデータ・ソフトウェア120は様々な型(たとえば、総計(GrandTotal)照会、スライス基準(Slice based)照会、および完全キューブ照会)を取り扱う。総計スライスにおいては、すべての次元の総計のみを返す。スライスは副キューブ(sub-cube)であり、一方、完全キューブは全キューブ(entirecube)である。

0247

測度は測度メタデータ・オブジェクトとして表す。単一のSQLステートメントにおいて複数の測度を計算すべき場合、本発明の実施形態はそれらの測度に互換性があるか否かを判断する。互換性のある測度はそれらが参照する次元のための同一の集約順序仕様を有する。1組の測度に互換性がない場合、本発明は互換性のない測度を単一のSQLステートメントにおいて組み合わせるための方法を少なくとも1つ決定する。いくつかの実施形態では、JOIN演算(「結合(joining)とも呼ばれる」)を用いて組み合わせるが、このプロセスは図38において詳述する。いくつかの実施形態では、集約ステップを再構成することにより互換性のない測度を組み合わせて、それらが互換性を有するようにしている(これは「ネスティング(nesting)」とも呼ばれている)が、このプロセスは図39において詳述する。いくつかの実施形態では、数組の測度を結合させるとともに数組の測度をネストさせる、結合とネスティングとの混合形態を実現している。

0248

図38は本発明のいくつかの実施形態に従い測度を組み合わせるための論理のさらなる詳細を示す。図38のプロセスはすべての測度を計算するための単一のSQLステートメントを生成するのに使用する最高レベルの論理を示す。本発明の実施形態は最小個数の、互換性のある測度の組を生成することを試みる。また、測度の非互換性に起因して複数の組が不可避である場合には、組の好適な組み合わせは、その中にすべての対称的な測度を備えた測度の対称的な組を有するものである。

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

技術視点だけで見ていませんか?

この技術の活用可能性がある分野

分野別動向を把握したい方- 事業化視点で見る -

ページトップへ

新着 最近 公開された関連が強い 技術

この 技術と関連性が強い 技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する挑戦したい社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ