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

【発明の詳細な説明】
【技術分野】
【０００１】
本発明はリレーショナル・オンライン分析処理（ＯＬＡＰ：on-lineanalytical processing)エンジン用に多次元計算を記述することに関する。
【背景技術】
【０００２】
オンライン分析処理（ＯＬＡＰ：on-line analyticalprocessing)がますます一般的になってきている。緑行付出力用紙（green-bar paper)に印刷された統計報告の山を精査する代わりに、ＯＬＡＰ分析者は対話的かつ動的にデータのビューを調整し、疑問点を質問し、そして、ほとんど瞬時に回答を得ながら、ビジネスの成果を調査することができる。固定したスケジュールに則り固定した質問に対する静的な回答に比べると、この自由さはビジネス分析者がより効率的に働き、事業活動における進歩をなし遂げることを可能にする。
【０００３】
ナイジェル・ペンドセ（Nigel Pendse）はＯＬＡＰシステムを特徴付けるために、頭文字用語「ＦＡＳＭＩ」を導入した。ＦＡＳＭＩの特徴は速い（Fast）、分析（Analysis）、共用（Shared）、多次元（Multidimensional）、および情報（Information)である。さらなる情報については、Ｎ・ペンドセ「ＯＬＡＰとは何か？（WhatIs OLAP ?）」（ＯＬＡＰレポート）（The OLAP Report, http://www.olapreport.com/fasmi.htm）を参照されたい。
【０００４】
速い（fast）については、ＯＬＡＰの「Ｏ」の趣旨との調和を保つ点において、そのようなシステムはきわめて迅速に、通常は数秒以内に結果を提示する必要があり、２０秒や３０秒を超えることは滅多にない。分析者が注意散漫にならずに効率的に仕事をするのを可能にするという点において、このレベルの性能がきわめて重要である。
【０００５】
分析（analysis）については、ＯＬＡＰの「Ａ」を考慮して、ＯＬＡＰシステムは一般に最小限のプログラミングで済む、所定の用途に最適な豊富な分析機能を提供している。
【０００６】
共用（shared）については、ＯＬＡＰシステムは通常、共用リソースである。これはＯＬＡＰシステムが適切なセキュリティ機能と保全性機能を提供するための要件が存在するということを意味する。究極的には、これはデータベースの各セルごとに異なるアクセス制御を提供するということを意味する可能性がある。
【０００７】
多次元（multidimensional）については、多次元性はＯＬＡＰシステムにとって主要な要件である。ＯＬＡＰ製品は自身のデータを多次元のフレームワークにおいて提示する。次元とはシステムのデータ値の関連する識別子または属性（たとえば製品、市場、時間、チャネル、シナリオ、または顧客）の集積のことである。特定の次元用の集積に属す識別子（たとえば「ロード・オブ・ザ・リング−ＤＶＤ（TheLord of the Rings-DVD)」、「カリフォルニア州サンノゼ（San Jose, California）」、「２００２」、「小売りレンタル（RetailRental)」、および「ジョン・Ｑ．パブリック（John Q. Public）」）は一般に階層のような何らかの種類の構造を有する。時として、これらの識別子に対して複数の自然の構造が存在する。
【０００８】
多次元の特徴はＯＬＡＰシステムが１つの次元の様々なサブセットと構造上の構成との間に加え、次元の様々な方向（orientation)の間で迅速に切り替わることができる、ということを意味する。ＯＬＡＰシステムの多次元の性質のために、それらが実装するデータの集積はキューブ（cube:立方体）と呼ばれている。情報（information)については、ＯＬＡＰシステムは情報を格納するとともに計算する。ＯＬＡＰシステムのためのデータは多くの場合、少なくとも１つの動作中のシステムに由来するこれらのデータには分析モデルを適用し、その結果はシステムに格納するか、照会時に生成するかする。ある特定のＯＬＡＰシステムが管理しうる情報の量は当該システムの一特徴である。
【０００９】
企業は多年にわたりリレーショナル・データベースの中に多次元のデータを星型スキーマまたはスノーフレーク（snowflake:雪片）型スキーマを用いて蓄積し続けてきている。時が経つのにつれて、リレーショナル・データベースの提供業者はこれらのスキーマに照会性能を向上させる最適化を付加している。１９９０年代に、付加された計算上の複雑さを処理しうるとともに、一般にリレーショナル・エンジンよりも良好に実行しうる多くの専用のデータベースが開発された。
【００１０】
多次元ＯＬＡＰ（ＭＯＬＡＰ:multidimensional OLAP）は専用のファイル・システムすなわち索引を用いてキューブ・データを格納するＯＬＡＰシステムのファミリーを指す。「Ｅｘｐｒｅｓｓ Ｗｅｂ Ｐｕｂｌｉｓｈｅｒ」、「Ｅｓｓｂａｓｅ」、「ＴＭ１」、および「Ｐｉｌｏｔ Ｓｕｉｔｅ」は専用の記憶と索引付けの技術に基づいた製品の数例である。マイクロソフト（Ｒ）（Ｍｉｃｒｏｓｏｆｔ（Ｒ））のＯＬＡＰ商品もＭＯＬＡＰエンジンを備えている。これらのシステムは多くの場合、基本データとともに周期的にロードされ、次いで抽出されたデータが計算され、格納され、そして索引付けが行われる読み取り専用のシステムである。ＭＯＬＡＰシステムの規模拡張性は多くの場合、その内部で、抽出された結果が計算され、格納されるバッチ・ウインドウのサイズによって限定される。規模拡張性を改善するために、そのようなシステムは多くの場合、抽出された結果の一部を照会時まで遅らせ手段を備えている。
【００１１】
リレーショナルＯＬＡＰ（relational OLAP:ＲＯＬＡＰ）の場合、リレーショナル・データベースの中の多次元データを表現する手段として、多年にわたり星型スキーマが用いられてきた。「ＭｉｃｒｏＳｔｒａｔｅｇｙ」、「Ｂｒｉｏ」、「Ｂｕｓｉｎｅｓｓ Ｏｂｊｅｃｔｓ」、「Ｍｅｔａｃｕｂｅ」、「Ｈｙｐｅｒｉｏｎ」、および「Ｍｅｔａｐｈｏｒ」のような多くの商用ソフトウェアの開発会社がリレーショナル星型スキーマのためのバッチまたは対話型の多次元の報告・探査インターフェースを開発してきた。これらのシステムはすべて、構造化照会言語（StructuredQuery language:ＳＱＬ）に超集約演算子（super aggregate operator）が追加される前に設計され実装された。
【００１２】
特に、数年前まで、リレーショナル・データベースは照会ごとに単一のレベルのみにおける集約の計算を許可していた。たとえば、「ＧＲＯＵＰ ＢＹ」文節を伴う、ある「ＳＥＬＥＣＴ」ステートメントを用いて結果の組を四半期レベルで（すなわち１組の四半期に対して）検索しながら、「ＧＲＯＵＰ ＢＹ」文節を伴う別の「ＳＥＬＥＣＴ」ステートメントを用いて月レベルで（すなわち１組の月に対して）結果の組を検索するのが常であった。これは、変動するレベルにおいてセルを計算するために、ＯＬＡＰシステムにデータベースに対して複数の照会を実行することを強いるものであった。
【００１３】
ＯＬＡＰ型の照会の作成を容易にするため、および、より進歩した最適化を実現するために、インターナショナル・ビジネス・マシーンズ・コーポレーション（International Business Machines Corporation)から入手可能なＤＢ２（Ｒ）リレーショナル・データベース管理システム（relationaldatabase Management System:ＲＤＢＭＳ）は単一の照会が複数の集約を生成するのを可能にする、ＳＱＬ標準に追加された３つの新たな超集約演算子、すなわち「ＲＯＬＬＵＰ」、「ＣＵＢＥ」、および「ＧＲＯＵＰＩＮＧ ＳＥＴＳ」を実装した。これらの超集約演算子は「ＧＲＯＵＰ ＢＹ」文節に対する拡張であり、複数のレベルにおいて集約を生成すべきことを指示する。たとえば、１つの「ＳＥＬＥＣＴ」ステートメントを用いて複数のレベル（たとえば四半期および月の双方）において集約の計算の結果の組を取得することができる。
【００１４】
これらの超集約演算子は複数のグループ化の組を生成するための単なる便法以上のものである。単一のステートメントにおいて複数のグループ化の組が要求されるから、ＤＢ２（Ｒ）ＲＤＢＭＳは計算に必要な各入力行を１度だけ参照するような方法で、すべてのグループ化の組を生成する実行計画を構築することができる。これは特に入力行の組がバッファ・プール（すなわちキャッシュ）に適合していないときに、数桁の性能の改善をもたらす可能性がある。
【００１５】
従来技術のシステムは複数の照会を発行することにより、様々なレベルの粒度（細分性）を備えた結果を提示する多次元の報告を生成するように設計されていた。複数の照会に対して複数の結果の組を取得し、それら結果の組をマージして単一の報告を作成する。そのようなシステムはデータを検索して多次元の報告を生成するのに、表のための役割のある種の記述（メタデータ）と、必要なＳＱＬステートメントを生成する星型スキーマにおける列とに依存している。正確なメタデータは製品ごとに異なる。
【００１６】
（たとえば「Ｈｙｐｅｒｉｏｎ」、「Ｃｏｇｎｏｓ」、および「Ｍｉｃｒｏｓｏｆｔ（Ｒ）」のような会社に由来する）多次元オンライン分析処理（ＯＬＡＰ）システムは多次元のキューブの各端（edge）のためにメンバの組が与えられると、多次元の結果の組を自然に返すように設計されている。多次元ＯＬＡＰシステムは任意の照会の結果の一部または全部を事前に計算するようにも設計されている。
【発明の開示】
【発明が解決しようとする課題】
【００１７】
リレーショナル・データベースの導入以来、ＳＱＬを用いて多次元分析を行ってきたが、リレーショナルＯＬＡＰシステムは多次元の結果の組を自然に返すことも、照会の結果の一部または全部を事前に計算することもできなかった。
【００１８】
したがって、改善されたリレーショナルＯＬＡＰシステムを求める需要が当技術分野には存在する。
【課題を解決するための手段】
【００１９】
したがって、本発明は、第１の側面において、多次元計算を記述する方法であって：ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照している、ステップと；前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している、ステップとを含む方法を提供する。
【００２０】
好ましくは、前記ステートメントは構造化照会言語ステートメントである。
【００２１】
好ましくは、前記測度メタデータ・オブジェクトの各々は少なくとも１つの構造化照会言語式を指定している。
【００２２】
好ましくは、前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる。
【００２３】
好ましくは、前記テンプレートは列、属性、および測度から成るリストに由来する特定の列、属性、または測度を参照する、トークンの表記法を使用している。
【００２４】
好ましくは、前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる。
【００２５】
好ましくは、前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも１つの集約に基づいて生成する。
【００２６】
好ましくは、集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる。
【００２７】
好ましくは、前記次元の組は集約の前記リストにおいて、別の集約関数の中で指定された次元以外のすべての利用可能な次元を含めるために、対応する集約関数のためにＮＵＬＬを指定する。
【００２８】
好ましくは、前記測度メタデータ・オブジェクトは少なくとも１つの構造化照会言語式を指定し、前記構造化照会言語式は集約から成る前記リストの中の集約に対する入力として使用する。
【００２９】
好ましくは、前記ステートメントはＲＯＬＬＵＰ文節を構築するために、階層メタデータ・オブジェクトの中のメタデータを用いて生成する。
【００３０】
好ましくは、測度メタデータ・オブジェクトが別の測度メタデータ・オブジェクトを参照する。
【００３１】
好ましくは、構造化照会言語の生成はさらに総計照会のためにＳＥＬＥＣＴステートメントを生成するステップを含んでいる。
【００３２】
好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのスライスのためのＳＥＬＥＣＴステートメントを生成るすステップを含んでいる。
【００３３】
好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのためのＳＥＬＥＣＴステートメントを生成るすステップを含んでいる。
【００３４】
好ましくは、前記方法はさらに、前記少なくとも１つの測度メタデータ・オブジェクトにおいて定義された対称的な測度と非対称の測度とを分離するステップと；前記対称的な測度のための構造化照会言語ステートメントを生成するステップと；前記非対称の測度のための構造化照会言語ステートメントを生成するステップと；前記対称的な測度のための構造化照会言語ステートメントと前記非対称の測度のための構造化照会言語ステートメントとを組み合わせて単一の構造化照会言語ステートメントにするステップとを含んでいる。
【００３５】
好ましくは、前記組み合わせるステップは結合を使用する。
【００３６】
好ましくは、前記方法はさらに、ある測度が少なくとも１つの測度と互換性を有するか否かを判断するステップと；前記測度が少なくとも１つの測度と互換性を有さない場合、前記測度のうちの任意のものが書き直されているか否かを判断するステップと；前記測度のうちの任意のものが書き直されている場合、前記測度を書き直すステップとを含んでいる。
【００３７】
好ましくは、前記方法はさらに、前記キューブ・モデル・メタデータ・オブジェクトの前記サブセットに基づいてキューブ・メタデータ・オブジェクトを生成するステップと、キューブ・ビューの作成のための構造化照会言語ステートメントを生成するステップであって、前記構造化照会言語ステートメントは前記少なくとも１つの測度メタデータ・オブジェクトから生成する、ステップとを含んでいる。
【００３８】
好ましくは、前記方法はさらに、アプリケーション・プログラムの制御下で、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトを用いて、多次元情報を検索するための構造化照会言語ステートメントを生成するステップを含んでいる。
【００３９】
第２の側面において、本発明は、多次元計算を記述するシステムであって、ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照している、ステップと；前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している、ステップとを含む少なくとも１つのプログラムを動作させる少なくとも１つのプログラム可能な構成要素を有するコンピュータ・システムを含むシステムを提供する。
【００４０】
好ましくは、前記ステートメントは構造化照会言語ステートメントである。
【００４１】
好ましくは、前記測度メタデータ・オブジェクトの各々は少なくとも１つの構造化照会言語式を指定している。
【００４２】
好ましくは、前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる。
【００４３】
好ましくは、前記テンプレートは列、属性、および測度から成るリストに由来する特定の列、属性、または測度を参照する、トークンの表記法を使用している。
【００４４】
好ましくは、前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる。
【００４５】
好ましくは、前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも１つの集約に基づいて生成する。
【００４６】
好ましくは、集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる。
【００４７】
好ましくは、前記次元の組は集約の前記リストにおいて、別の集約関数の中で指定された次元以外のすべての利用可能な次元を含めるために、対応する集約関数のためにＮＵＬＬを指定する。
【００４８】
好ましくは、前記測度メタデータ・オブジェクトは少なくとも１つの構造化照会言語式を指定し、前記構造化照会言語式は集約から成る前記リストの中の集約に対する入力として使用する。
【００４９】
好ましくは、前記ステートメントはＲＯＬＬＵＰ文節を構築するために、階層メタデータ・オブジェクトの中のメタデータを用いて生成する。
【００５０】
好ましくは、測度メタデータ・オブジェクトが別の測度メタデータ・オブジェクトを参照する。
【００５１】
好ましくは、構造化照会言語の生成はさらに総計照会のためにＳＥＬＥＣＴステートメントを生成するステップを含んでいる。
【００５２】
好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのスライスのためのＳＥＬＥＣＴステートメントを生成るすステップを含んでいる。
【００５３】
好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのためのＳＥＬＥＣＴステートメントを生成るすステップを含んでいる。
【００５４】
好ましくは、前記方法はさらに、前記少なくとも１つの測度メタデータ・オブジェクトにおいて定義された対称的な測度と非対称の測度とを分離するステップと；前記対称的な測度のための構造化照会言語ステートメントを生成するステップと；前記非対称の測度のための構造化照会言語ステートメントを生成するステップと；前記対称的な測度のための構造化照会言語ステートメントと前記非対称の測度のための構造化照会言語ステートメントとを組み合わせて単一の構造化照会言語ステートメントにするステップとを含んでいる。
【００５５】
好ましくは、前記組み合わせるステップは結合を使用する。
【００５６】
好ましくは、前記方法はさらに、ある測度が少なくとも１つの測度と互換性を有するか否かを判断するステップと；前記測度が少なくとも１つの測度と互換性を有さない場合、前記測度のうちの任意のものが書き直されているか否かを判断するステップと；前記測度のうちの任意のものが書き直されている場合、前記測度を書き直すステップとを含んでいる。
【００５７】
好ましくは、前記方法はさらに、前記キューブ・モデル・メタデータ・オブジェクトの前記サブセットに基づいてキューブ・メタデータ・オブジェクトを生成するステップと、キューブ・ビューの作成のための構造化照会言語ステートメントを生成するステップであって、前記構造化照会言語ステートメントは前記少なくとも１つの測度メタデータ・オブジェクトから生成する、ステップとを含んでいる。
【００５８】
好ましくは、前記方法はさらに、アプリケーション・プログラムの制御下で、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトを用いて、多次元情報を検索するための構造化照会言語ステートメントを生成するステップを含んでいる。
【００５９】
第３の側面において、本発明は、コンピュータ・システムにロードされ、その上で実行されると、前記コンピュータ・システムに第１の側面に従う方法のすべてのステップを実行させるコンピュータ・プログラム・コードを含むコンピュータ・プログラムを提供する。
【００６０】
多次元計算を記述するプログラムを含むコンピュータ・プログラムは製品の中に組み込むことができ、前記プログラムはオペレーションを実行させるものであり、前記オペレーションは、ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照している、ステップと；前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している、ステップとを含む。
【００６１】
好ましくは、前記ステートメントは構造化照会言語ステートメントである。
【００６２】
好ましくは、前記測度メタデータ・オブジェクトの各々は少なくとも１つの構造化照会言語式を指定している。
【００６３】
好ましくは、前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる。
【００６４】
好ましくは、前記テンプレートは列、属性、および測度から成るリストに由来する特定の列、属性、または測度を参照する、トークンの表記法を使用している。
【００６５】
好ましくは、前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる。
【００６６】
好ましくは、前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも１つの集約に基づいて生成する。
【００６７】
好ましくは、集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる。
【００６８】
好ましくは、前記次元の組は集約の前記リストにおいて、別の集約関数の中で指定された次元以外のすべての利用可能な次元を含めるために、対応する集約関数のためにＮＵＬＬを指定する。
【００６９】
好ましくは、前記測度メタデータ・オブジェクトは少なくとも１つの構造化照会言語式を指定し、前記構造化照会言語式は集約から成る前記リストの中の集約に対する入力として使用する。
【００７０】
好ましくは、前記ステートメントはＲＯＬＬＵＰ文節を構築するために、階層メタデータ・オブジェクトの中のメタデータを用いて生成する。
【００７１】
好ましくは、測度メタデータ・オブジェクトが別の測度メタデータ・オブジェクトを参照する。
【００７２】
好ましくは、構造化照会言語の生成はさらに総計照会のためにＳＥＬＥＣＴステートメントを生成するステップを含んでいる。
【００７３】
好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのスライスのためのＳＥＬＥＣＴステートメントを生成るすステップを含んでいる。
【００７４】
好ましくは、構造化照会言語の生成はさらにキューブ・モデル・メタデータ・オブジェクトのサブセットのためのＳＥＬＥＣＴステートメントを生成るすステップを含んでいる。
【００７５】
好ましくは、前記方法はさらに、前記少なくとも１つの測度メタデータ・オブジェクトにおいて定義された対称的な測度と非対称の測度とを分離するステップと；前記対称的な測度のための構造化照会言語ステートメントを生成するステップと；前記非対称の測度のための構造化照会言語ステートメントを生成するステップと；前記対称的な測度のための構造化照会言語ステートメントと前記非対称の測度のための構造化照会言語ステートメントとを組み合わせて単一の構造化照会言語ステートメントにするステップとを含んでいる。
【００７６】
好ましくは、前記組み合わせるステップは結合を使用する。
【００７７】
好ましくは、前記方法はさらに、ある測度が少なくとも１つの測度と互換性を有するか否かを判断するステップと；前記測度が少なくとも１つの測度と互換性を有さない場合、前記測度のうちの任意のものが書き直されているか否かを判断するステップと；前記測度のうちの任意のものが書き直されている場合、前記測度を書き直すステップとを含んでいる。
【００７８】
好ましくは、前記方法はさらに、前記キューブ・モデル・メタデータ・オブジェクトの前記サブセットに基づいてキューブ・メタデータ・オブジェクトを生成するステップと、キューブ・ビューの作成のための構造化照会言語ステートメントを生成するステップであって、前記構造化照会言語ステートメントは前記少なくとも１つの測度メタデータ・オブジェクトから生成する、ステップとを含んでいる。
【００７９】
好ましくは、前記方法はさらに、アプリケーション・プログラムの制御下で、前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトを用いて、多次元情報を検索するための構造化照会言語ステートメントを生成するステップを含んでいる。
【００８０】
したがって、好ましくは、多次元計算を記述する方法、システム、およびプログラムを提供する。ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成するキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領する。前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照する。前記キューブ・モデル・メタデータ・オブジェクトおよび前記測度メタデータ・オブジェクトの中のメタデータを用いて多次元情報を検索するためのステートメントを生成する。前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している。
【００８１】
本発明の記述された実施形態（implementation）はリレーショナルＯＬＡＰシステムにおいて多次元計算を記述する方法、システム、およびプログラムを提供する。
【発明を実施するための最良の形態】
【００８２】
以下の記述においては、その一部を形成するとともに、本発明のいくつかの実施形態を説明する添付図面に対する参照がなされている。本発明の範囲を逸脱することなく、他の実施形態を使用しうる点、および、構造上および動作上の変更をなしうる点が理解される。
【００８３】
〔Ａ．多次元メタデータの導入〕
いくつかの実施形態において、本発明は多次元メタデータ・オブジェクトと当該多次元メタデータ・オブジェクトを使用する手法とを実現する。参照を容易にするために、本発明の好適な実施形態を「ＯＡＬＰ多次元メタデータ・システム１００」として参照することとし、多次元メタデータ・オブジェクトを「メタデータ・オブジェクト」として参照することとする。
【００８４】
いくつかの実施形態において、インターナショナル・ビジネス・マシーンズ・コーポレーション（International Business Machines Corporation)から入手可能なＤＢ２（Ｒ）汎用データベース（UniversalDatabase: ＵＤＢ）ＲＤＢＭＳにＯＡＬＰ多次元メタデータ・システム１００を実装している。本明細書はＩＢＭ（Ｒ）のＤＢ２（Ｒ）ＵＤＢ ＲＤＢＭＳソフトウェアの使用を記述しているけれども、本発明は「Ｏｒａｃｌｅ（Ｒ）」、「ＩＢＭ（Ｒ）Ｉｎｆｏｒｍｉｘ（Ｒ）」、「Ｓｙｂａｓｅ（Ｒ）」から入手可能なＲＤＢＭＳソフトウェアのような他のＲＤＢＭＳソフトウェアを使用しうる、ということを当業者は認識しうる。また、本発明はＩＢＭ（Ｒ）ｚ／ＯＳ（Ｒ）、ＩＢＭ（Ｒ）ＡＩＸ（Ｒ）、Ｍｉｃｒｏｓｏｆｔ（Ｒ）Ｗｉｎｄｏｗｓ（Ｒ）２０００、Ｍｉｃｒｏｓｏｆｔ（Ｒ）Ｗｉｎｄｏｗｓ（Ｒ）ＸＰ、Ｌｉｎｕｘ（Ｒ）、Ｓｏｌａｒｉｓ（Ｒ）、ＨＰ−ＵＸのような様々なオペレーティング・システムを使用するコンピュータ上で実行することができる。
【００８５】
図１は、ブロック図において、本発明のいくつかの実施形態によるコンピューティング環境を示す。リレーショナル・データベース管理システム（ＲＤＢＭＳ:Relational Database Management System）１１０は多次元メタデータ・ソフトウェア１２０（たとえば格納プロシージャ型のアプリケーション・プログラミング・インターフェース（ＡＰＩ:applicationprogramming interface) とユーザ・インターフェース１５０とを備えている。ＲＤＢＭＳ１１０は多次元メタデータ・オブジェクト１３０とリレーショナル・データベース１４０にアクセスする。いくつかの実施形態では、多次元メタデータ・オブジェクト１３０の中のデータとリレーショナル・データベース１４０とを単一のデータベースに格納している。
【００８６】
ＯＬＡＰ多次元メタデータ・システム１００は多次元メタデータ・ソフトウェア１２０（たとえば格納プロシージャ型のアプリケーション・プログラミング・インターフェース（ＡＰＩ:application programming interface) ）、ユーザ・インターフェース１５０、および多次元メタデータ・オブジェクト１３０を含んでいる。多次元メタデータ・ソフトウェア１２０は多次元メタデータ・オブジェクト１３０を生成し、格納し、それにアクセスするために使用する。任意選択で、ユーザ・インターフェース１５０を備え、ユーザまたは管理者が多次元メタデータ・ソフトウェア１２０にコマンドを送付しうるようにしてもよい。ユーザはユーザ・インターフェース１５０を介してコマンドを送信することにより、多次元メタデータ・オブジェクト１３０を生成し、それにアクセスし、それを変更し、または削除する。それらのコマンドは多次元メタデータ・ソフトウェア１２０が受信して処理する。たとえば、多次元メタデータ・ソフトウェア１２０は多次元メタデータ・オブジェクト１３０を生成し、格納する。
【００８７】
いくつかの実施形態では、ＯＬＡＰ多次元メタデータ・システム１００はＲＤＢＭＳ１１０がＯＬＡＰ処理を実行する能力を向上させるＤＢ２（Ｒ）汎用データベース（Universal Database）（ここではＤＢ２（Ｒ）ＵＤＢと呼ぶ）のような、ＲＤＢＭＳ１１０のためのアドオン（拡張）機能を備えている。本発明の好適な実施形態はＯＬＡＰソリューション（解決策）の導入と管理を流線型にし（無駄を無くして合理化し）、ＯＬＡＰのツールとアプリケーションの性能を向上させている。
【００８８】
特に、ＯＬＡＰ多次元メタデータ・システム１００はメタデータ・オブジェクトを備えている。新たなメタデータ・オブジェクトはたとえば、既存のリレーショナル・データの次元モデルとＯＡＬＰ構成体を記述するデータベース・カタログ（たとえばＤＢ２（Ｒ）ＵＤＢカタログ）に格納する。このデータベース・カタログはそこからＯＬＡＰアプリケーションが多次元メタデータを取得しうる単一のリポジトリを備えている。いくつかの実施形態では、メタデータ・オブジェクトはデータベース・カタログではなくデータ・ストアに常駐している、あるいは、複数のデータ・ストアの全体にわたって常駐している。中央リポジトリの中の情報により、データベース最適化プログラムは照会の実行を最適化する、星型スキーマに特有の手法を用いることができる。
【００８９】
メタデータ・オブジェクトによって、本発明はサマリー表の中のデータを集約すること、および索引を作成することにより、ＯＬＡＰの照会の性能を最適化することができる。ＯＬＡＰ多次元メタデータ・システム１００はメタデータ・プログラミング・インターフェースも備えている。特に、ＯＬＡＰ多次元メタデータ・システム１００はＯＬＡＰのツールとアプリケーション開発者のために、ＳＱＬに基づくとともに、拡張可能なマーク付け言語（ＸＭＬ:extensible mark-up language) に基づいたアプリケーション・プログラミング・インターフェース（ＡＰＩ:applicationprogramming interface) を備えている。たとえばコマンド・ライン・インターフェース（ＣＬＩ:Command Line Interface)、オープン・データベース接続性（ＯＤＢＣ:OpenDatabase Connectivity)、またはＪａｖａ（Ｒ）データベース接続性（ＪＤＢＣ:Java Database Connectivity)の接続により、あるいは、たとえばＤＢ２（Ｒ）ＵＤＢに対する埋め込み型ＳＱＬを使用することにより、アプリケーションとツールは単一の格納プロシージャ（すなわち多次元メタデータ・ソフトウェア１２０の一例）を用いてメタデータ・オブジェクトを生成し、変更し、検索することができる。いくつかの実施形態では、複数の格納プロシージャがメタデータ・オブジェクトを生成し、変更し、検索する機能を備えている。
【００９０】
ＯＬＡＰ多次元メタデータ・システム１００のメタデータ・オブジェクトは関連する情報をインテリジェントなＯＬＡＰ構造体として記述しているが、本発明が提供する多次元メタデータ・オブジェクトは伝統的なＯＬＡＰのオブジェクトとは異なる。本発明のメタデータ・オブジェクトはメタデータを格納している、すなわち、このメタデータ・オブジェクトはデータに関する情報を基本表の中に格納している。メタデータ・オブジェクトは関係するデータがどこに配置されているのかを記述するとともに、基本データ内の関係も記述することができる。たとえば、ファクト（事実）メタデータ・オブジェクトは関連する測度（measure)、属性、および結合に関する情報を格納しているが、基本ファクト表に属すデータは個別には含まない特定のメタデータ・オブジェクトである。
【００９１】
メタデータはデータを理解する基盤をなす新たな観点を提供する。メタデータ・オブジェクトがないと、データベース・カタログは表の名前と列の名前について知っているのみであるから、表と列の意味、あるいは、表と列がどのように相互に関係しているのかということに関する情報を格納することができない。メタデータ・オブジェクトがあると、この情報を格納することができる。
【００９２】
各メタデータ・オブジェクトはリレーショナル・データが意味するものを示す全体像の一片を完成させる。一部のメタデータ・オブジェクトはデータを集約することにより、あるいは、リレーショナル表の中の特定の列に直接に対応することにより、リレーショナル・データに直接にアクセスするためのベース（base）として機能する。他のメタデータ・オブジェクトは基本メタデータ・オブジェクトの間の関係を記述するとともに、これらの基本メタデータ・オブジェクトを相互にリンクさせる。最終的には、すべてのメタデータ・オブジェクトを、互いに対するそれらの関係によってキューブ・モデルと呼ばれるメタデータ・オブジェクトにグループ化することができる。キューブ・モデルはリレーショナル表の特定のグループ化と構成を表している。キューブ・モデルの目的は所定のアプリケーションまたはツールに合わせてＯＬＡＰ構造体を記述することである。キューブ・モデルは様々なユーザが、分析中のデータを求めうるように、すべてのキューブを記述する傾向がある。キューブ・モデルは次元とファクトをグループ化し、次元のために複数の階層の柔軟性を提供する。キューブ・モデルは星型スキーマのデータベースの上に複雑な照会を生成する照会設計ツールとアプリケーションが必要とする構造上の情報を伝達する。
【００９３】
多次元メタデータ・オブジェクト・モデルは多次元データを表すための、リレーショナル・データベースの中のスキーマを記述するように設計されている。そのようなデータを編成する１つの方法は星型スキーマまたはスノーフレーク型スキーマを使用することによるものである（スノーフレーク型スキーマでは、次元表が規格化されている）。しかし、このモデルは十分に柔軟だから、任意の型のスキーマ（たとえばより規格化したスキーマ）を扱うことができる。
【００９４】
〔Ａ．１ 多次元メタデータの概観〕
多次元メタデータはデータウェアハウスに格納されているＯＬＡＰ構造体に関するメタデータの保守を可能にする。この情報は、以前はデータベース・カタログの中で利用できなかった、そして一般に、データウェアハウスのメタデータ・リポジトリによって文書化されていない。多次元メタデータはデータウェアハウスの設計者が表とそれらの列との間の構造上の関係を表現するのに役立つ。一旦、データベース・カタログの中にメタデータが存在すると、データベース最適化プログラム（たとえばＤＢ２（Ｒ）ＵＤＢ最適化プログラム）のような、ＲＤＢＭＳ１１０の他の構成要素はその構造上の情報を利用し、これら新たなＯＬＡＰメタデータ・オブジェクトによって記述されたデータに対する照会をより迅速に実行することができる。メタデータ・オブジェクトはデータウェアハウスに対して多次元照会を生成するのに必要な基本構造上の情報を提供することにより、ビジネス・インテリジェンス・ツールを支援することもできる。ＯＬＡＰの構造上の情報を取得するために、ＯＬＡＰ多次元メタデータ・システム１００は新たなメタデータ・オブジェクトをいくつか定義している。これらのメタデータ・オブジェクトはＯＬＡＰデータをモデル化するのに頻繁に使用する、星−結合型（star-join)スキーマおよびスノーフレーク型スキーマのようなスキーマの重要な側面を記述することができる。
【００９５】
データベース・カタログにメタデータ・オブジェクトを付加すると、データベースの他の構成要素と相まって、完全な機能性と統合が実現する。新たなメタデータ・オブジェクトは正規表（regular table)の場合と同様に、スキーマが所有する。メタデータ・オブジェクトの別の設計上の要点はそれらの大多数が独立して有用である、という点である。すなわち、メタデータ・オブジェクトは当該メタデータ・オブジェクトがより複雑な多次元構造に含まれているか否かに関わらず、基をなすリレーショナル・スキーマに関する情報を提供する。
【００９６】
キューブ・モデルは多くの方法で構成しうるが、多くの場合、リレーショナルの星型スキーマまたはスノーフレーク型スキーマを表すために構築する。単純な星型スキーマに基づいたキューブ・モデルはファクト表から集約したリレーショナル・データを記述している中央ファクト・メタデータ・オブジェクトの回りに構築する。測度メタデータ・オブジェクトはリレーショナル表の中の列に属すデータの計算を記述するとともに、相互に結合されてファクト・メタデータ・オブジェクトを生成する。図２は本発明のいくつかの実施形態に従い、ファクト・メタデータ・オブジェクト２１０と測度メタデータ・オブジェクト２２０、２３０とがリレーショナル・データ２５０に関係している様子を示す。
【００９７】
次元メタデータ・オブジェクトは、星型スキーマにおいて次元表がファクト表に接続されているのとまったく同様に、キューブ・モデルにおいてファクト・メタデータ・オブジェクトに接続されている。リレーショナル表に属すデータの列は、相互に結合されて次元メタデータ・オブジェクトを形成している属性メタデータ・オブジェクトによって表されている。
【００９８】
図３は本発明のいくつかの実施形態に従う星−結合型スキーマの実例を示す。この星−結合型スキーマは中央の「Sales(販売）」ファクト表３００に結合された「Time（時）」３１０、「Product(製品）」３２０、および「Region（地域）」３３０の次元表を有する。リレーショナル表の中の関連する次元表とファクト表３００、３１０、３２０、３３０の列のために属性を生成する。各次元表３１０、３２０、３３０は「TimeID(時ＩＤ) 」、「ProductID(製品ＩＤ）」、または「RegionID (地域ＩＤ) 」のような次元キー属性を有する。地域次元表３３０は「City（市）」属性と「City＿Population（市の人口）」属性も有し、そして「CityPopAR」と名付けられた属性関係も有する。この属性関係は「City（市）」属性の中のすべての値が「City＿Population（市の人口）」属性の中の対応する値を決定するという機能的な依存性を表現している。ファクト表の内には、「Sales(販売）」と「Costs(費用）」のための２つの測度と、３つの次元キー属性、「TimeID(時ＩＤ) 」、「ProductID(製品ＩＤ）」、および「RegionID (地域ＩＤ) 」とがある。
【００９９】
３つの結合が各次元表３１０、３２０、３３０を対応する次元キー属性の上の中央ファクト表３００に結合している。この例では、次元表３１０、３２０、３３０は「TimeID (時ＩＤ) 」属性、「ProductID(製品ＩＤ）」属性、および「RegionID (地域ＩＤ) 」属性のうちのいずれか１つに基づいてファクト表３００に結合している。図４は本発明のいくつかの実施形態に従いリレーショナル表４５０から次元メタデータ・オブジェクト４０６、４１０を構築する様子を示す。たとえば、メタデータ・オブジェクトの間で、次元メタデータ・オブジェクト４０６は属性メタデータ・オブジェクト４０８の上に構築されており、属性メタデータ・オブジェクト４０８はリレーショナル表の中の属性４５２に接続されている。次元メタデータ・オブジェクト４１０は属性メタデータ・オブジェクト４１２、４１４、および結合メタデータ・オブジェクト４１６の上に構築されている。これらの属性メタデータ・オブジェクトはリレーショナル表４５０の中の属性４５４、４５６に接続されている。
【０１００】
階層は次元の内の属性がどのように相互に関係付けられて構成されているのかに関する情報を格納している。メタデータ・オブジェクトとして、階層は次元を計算しナビゲートする方法を提供している。各次元は各メンバ属性のために定義されたレベルを備えた対応する階層を有する。たとえば、「Region（地域）」次元は「State(州）」属性と「City（市）」属性のために定義されたレベルを備えた「Region H」階層を有し、「CityPop AR」属性関係も参照する。キューブ・モデルでは、各次元は複数の階層を有することができるが、星型スキーマのこの例は各次元用に定義された階層を１つ有する。
【０１０１】
星型スキーマでは、すべての次元メタデータ・オブジェクトが中央のファクト・メタデータ・オブジェクトに星型の形状で接続され、キューブ・モデルを形成している。結合メタデータ・オブジェクトは表を結合してファクト・メタデータ・オブジェクトまたは次元メタデータ・オブジェクトを生成することができる。メタデータ結合はファクト・メタデータ・オブジェクトを次元メタデータ・オブジェクトに結合することにより、キューブ・モデルの内において接着剤としても機能しうる。次元メタデータ・オブジェクトはそれらの構成要素の階層、属性、属性関係、および関連する結合のすべてに関する情報を有している。ファクト・メタデータ・オブジェクトはそれらの構成要素の測度、属性、および関連する結合のすべてに関する情報を有している。
【０１０２】
図５は本発明のいくつかの実施形態に従いキューブ・モデルにおいてメタデータ・オブジェクト５００が相互に適合しあい、リレーショナル表５５０のリレーショナルの星型スキーマにマップされている様子を示す。キューブ・モデル・メタデータ・オブジェクト５１０は次元メタデータ・オブジェクト５１２、５１４、結合メタデータ・オブジェクト５１６、およびファクト・メタデータ・オブジェクト５２０の上に構築されている。
【０１０３】
キューブ・モデル・メタデータ・オブジェクトは特定の用途用により正確なキューブ・メタデータ・オブジェクトを生成するためにその構成要素を再利用しうる柔軟なメタデータ・オブジェクトである。たとえば、１つのキューブ・モデル・メタデータ・オブジェクトは３７個のファクトを有しうるが、キューブ・モデル・メタデータ・オブジェクトから生成した１つのキューブ・メタデータ・オブジェクトは少なくとも１つの次元メタデータ・オブジェクト、次元メタデータ・オブジェクトの少なくとも１つのレベル、もしくは、少なくとも１つの測度メタデータ・オブジェクト、または、これらのすべてを除去しうる。
【０１０４】
キューブ・モデル・メタデータ・オブジェクトに加え、キューブ・メタデータ・オブジェクトと呼ばれるより具体的なメタデータ・オブジェクトがある。キューブ・メタデータ・オブジェクトはＯＬＡＰの概念上のキューブに最も近いメタデータ・オブジェクトである。キューブ・メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトの特定のインスタンスすなわちサブセットである。キューブ・メタデータ・オブジェクトは親のキューブ・モデル・メタデータ・オブジェクトから抽出した類似しているがより限定的な、キューブ次元、キューブ階層、ＯＬＡＰキューブ・ファクトを含む、メタデータ・オブジェクトの特定の組を有している。たとえば、「RegionCubeDim 」は「Region（地域）」次元から抽出した属性のサブセットであるキューブ次元である。「RegionCubeDim」は「State(州）」属性と「City（市）」属性を参照するが、「City＿Population（市の人口）」属性または「CityPop AR」属性関係は参照しない。「RegionCubeDim」はそれが精査する「Region（地域）」次元と結合情報を含む構造上のすべての情報とを参照し、キューブ・モデルの「Region（地域）」次元に留まる。
【０１０５】
いくつかの実施形態では、キューブ・メタデータ・オブジェクトはキューブ次元ごとに１つのキューブ階層を有し、一方、次元メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトのために定義された多数の階層を有しうる。キューブ・メタデータ・オブジェクトとキューブ・モデル・メタデータ・オブジェクトとの間のこの構造上の相違は単一のＳＱＬステートメントを用いた、キューブ・メタデータ・オブジェクトの検索を可能にする。
【０１０６】
図６は本発明のいくつかの実施形態に従い概念上のメタデータ・オブジェクトを３つの層に分類する様子を示す。これらの層は「ベース／リレーショナル」層６００、「多次元」層６１０、および「ＯＬＡＰ」層６２０である。「ベース／リレーショナル」層６００は他のメタデータ・オブジェクトに基本インフラストラクチャを提供するとともに、リレーショナル・データベースの概念をカプセル化する。「多次元」層６１０は「ベース／リレーショナル」層６００の中のメタデータ・オブジェクトを参照してリレーショナル・データベースの上に多次元の抽象化を与えるメタデータ・オブジェクトを含んでいる。「ＯＬＡＰ」層６２０はＯＬＡＰ構造体を表す高レベルのメタデータ・オブジェクトを含んでいる。他の層に属すメタデータ・オブジェクトをグループ化することにより、「ＯＬＡＰ」層６２０は複雑性の程度が異なるＯＬＡＰキューブを実現する。
【０１０７】
この実施形態のより良き理解のために、一例を提示する。その例はデータマート、星−結合型スキーマにおいて使用する共通の構成に基づいている。星−結合型スキーマの場合、メタデータ・オブジェクトのインスタンスは「ベース／リレーショナル」層、「多次元」層、および「ＯＬＡＰ」層に基づいて作成する。図３は本発明のいくつかの実施形態に従いファクト表３００（Fact) 、ならびに、３つの次元表、「Time（時）」３１０、「Product(製品）」３２０、および「Region（地域）」３４０から成る単純な星−結合型スキーマを示す。
【０１０８】
既存のデータベース・カタログは通常、表名と列名を格納している。これらの表と列がどのような役割を演ずるのか、そして、これらの表と列は相互にどのように関係しているのかに関する情報は失われている。しかし、ＯＬＡＰ多次元メタデータ・システム１００を用いると、この情報はメタデータ・オブジェクトを作成することにより取得される。
【０１０９】
図７は本発明のいくつかの実施形態に従い「ベース／リレーショナル」層に対応するメタデータ・オブジェクト７００が作成される様子を示す。すべての次元表の列、および結合において使用するファクト表の列について属性が生成されている。ファクト表の中の各ファクト列ごとに１つの測度メタデータ・オブジェクトが生成されている。この星−結合型スキーマにおいて使用する結合は３つの結合メタデータ・オブジェクトによって取得される。これらの結合メタデータ・オブジェクトは対応するファクト表の属性と次元表とをいかにして結合するのかを指示している。「City（市）」と「City＿Population（市の人口）」との間の関係、および、「City（市）」属性の中のすべての値が「City＿Population（市の人口）」属性の中の値を決定するというファクト（事実）を表すために、「Region（地域）」次元表の中に１つの属性関係が生成されている。
【０１１０】
図８は本発明のいくつかの実施形態に従う、「ベース／リレーショナル」層に属す付加的なメタデータ・オブジェクトを示す。関連する属性の間の関係を表す３つの階層８００、８１０、８２０が作成されている。これらの階層８００、８１０、８２０は次元を計算してナビゲートする手段を作成するために、次元が多次元層の中で使用する。「Region H 」階層８２０において、「CityPop AR」属性関係が参照されている。所定の階層に適用される属性関係がすべて取得されている。キューブの文脈において使用するために、階層ごとに１つのキューブ階層８５０、８６０、８７０も作成されている。キューブ階層８５０、８６０、８７０は所定のキューブにとって関心のある階層のレベルを精査するのに使用される。キューブ階層８５０、８６０、８７０はそれに適用される属性関係も取得する。
【０１１１】
図９は本発明のいくつかの実施形態に従う、星−結合型スキーマに基づいて生成された、多次元層のメタデータ・オブジェクトを示す。ファクト表「Fact」のために１つの「Facts(ファクト）」メタデータ・オブジェクト９００が生成されている。「SalesFacts (販売ファクト）」メタデータ・オブジェクト９００は利用可能な測度と結合の大きさを調整するのに必要な、ファクトの中のを属性とを含む。星−結合型スキーマの一部である各次元表ごとに１つの次元メタデータ・オブジェクト９１０、９２０、９３０が生成されている。１つの次元メタデータ・オブジェクトはこの例では単一の次元表に由来し、高度に相互連関されている属性をグループ化している。次元メタデータ・オブジェクトは次元の属性に適用され階層も参照している。次元は定義済みの階層を複数個有しうるが、この例では、次元当たり唯１つの階層が定義されている。
【０１１２】
図１０は本発明のいくつかの実施形態に従う、キューブを定義するのに使用するメタデータ・オブジェクト１０００、１０１０、１０２０、１０３０のインスタンスを示す。キューブの一部である属性と測度を精査するために、キューブ・ファクト、キューブ次元、および、キューブ階層メタデータ・オブジェクトが使用されている。これらのメタデータ・オブジェクトの各々は精査中のメタデータ・オブジェクトを参照しており、結合のような構造上の情報はすべてメイン（すなわち親）のメタデータ・オブジェクトの中に保持されている。キューブに固有のオブジェクトはすべて、それからそれらが定義されたメイン・オブジェクトへの参照を保持している。たとえば、キューブ階層メタデータ・オブジェクトはそれから当該キューブ階層メタデータ・オブジェクトが定義された階層メタデータ・オブジェクトへの参照を有している。いくつかの実施形態では、キューブ次元のために、１つの階層を割り当てている。この例では、「SalesCubeFacts」１０００なるキューブ・ファクトが生成されており、キューブの中で使用される測度（「Sales(販売) 」）を列挙している。
【０１１３】
ＯＬＡＰ層はキューブ・モデルとキューブ・メタデータ・オブジェクトとによって構成されている。キューブ・モデル・メタデータ・オブジェクトは所定のアプリケーションにとって関心のあるファクトと次元を記述するものである。キューブ・モデル・メタデータ・オブジェクトの次元は定義済みの階層を複数個有しうる。このことはキューブ・モデル・メタデータ・オブジェクトをきわめて柔軟な構造体にしている。キューブ・メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトから抽出する。したがって、すべてのキューブ次元、キューブ階層、およびキューブ・ファクト・メタデータ・オブジェクトはキューブ・モデル・メタデータ・オブジェクトから抽出する。キューブ・モデル・メタデータ・オブジェクトとキューブ・メタデータ・オブジェクトとの間の相違は、キューブ・メタデータ・オブジェクトにおいては、次元当たり１つの階層を定義する、という点である。このことは単一のＳＱＬステートメントを用いてキューブ・メタデータ・オブジェクトを検索することを可能にする。
【０１１４】
図１１は本発明のいくつかの実施形態に従いあるＯＬＡＰ層の中の各メタデータ・オブジェクトのインスタンスを１つ作成する様子を示す。この例において作成されたキューブ・モデルは図３の星−結合型スキーマの例から生成される可能性のある１つのキューブ・モデル１１００を取得する。キューブ１１５０はキューブ次元「TomeCubeDim 」、「ProductCubeDim」、「RegionCubeDim 」、およびキューブ・ファクト「SalesCubeFacts」に基づいて作成されている。
【０１１５】
〔Ａ．２ メタデータ・オブジェクトのプロパティ〕
各メタデータ・オブジェクトはメタデータ・オブジェクトに固有のプロパティに加え、１組の一般のプロパティを有している。この一般のプロパティはメタデータ・オブジェクトのインスタンスを特定するため、メタデータ・オブジェクトのインスタンスの使用方法すなわち役割を記述するため、そして、メタデータ・オブジェクトのインスタンスの変化を追跡するために使用する。いくつかの実施形態では、他のデータベースのメタデータ・オブジェクトに名前を付けるのと同一の方法で、スキーマを用いてメタデータ・オブジェクトに名前を付けている。デフォルトのユーザ名のスキーマが望ましくない場合には、メタデータ・オブジェクトの完全な認定試験が必要になる。
【０１１６】
表１は本発明のいくつかの実施形態に従う、すべてのメタデータ・オブジェクトのために存在する一般のプロパティを記載している。
【０１１７】
【表１】

【０１１８】
すべてのメタデータ・オブジェクトが共用する一般のプロパティの共通の組に加え、各メタデータ・オブジェクトはメタデータ・オブジェクトに固有のプロパティの組を有している。これらメタデータ・オブジェクトに固有のプロパティは当該メタデータ・オブジェクトを定義する構成要素と品質を記述している。キューブ・モデルは論理的な星型スキーマの代表例である。キューブ・モデルは中央のファクト・メタデータ・オブジェクトの回りに関連する次元メタデータ・オブジェクトをグループ化するものである。各次元は複数の階層を有しうる。このことはキューブ・モデルの柔軟性を高める。ファクトと次元メタデータ・オブジェクトが使用する表を結合する方法に関する構造上の情報はキューブ・モデルに格納する。キューブ・モデルには、ＯＬＡＰデータを検索するための十分な情報も格納されている。キューブ・モデルを理解しうるとともに、特定の次元の複数の階層を取り扱いうる他の報告ツールとＯＬＡＰツールはキューブ・モデルの使用から恩恵を受けることができる。
【０１１９】
キューブ・モデルは関係の複雑な組を定義しており、関係するファクトと次元をアプリケーションに公開するのに使用することができる。次元を中央のファクト・メタデータ・オブジェクトに接続している各結合メタデータ・オブジェクトは対応する次元とともに組として格納する。キューブ・モデルの構成要素のサブセットは様々な分析目的のために多数のキューブが使用することができる。
【０１２０】
ファクト・メタデータ・オブジェクトも何らの次元も有さない空のキューブ・モデルを作成することができる。しかし、このキューブ・モデルは対応するキューブを作成する前に終了する。ＯＬＡＰ多次元メタデータ・システム１００は当該キューブ・モデルがファクト・メタデータ・オブジェクト、少なくとも１つの次元、および既存のファクトと次元との間の結合を含むこと、および、すべての属性が有効な表を参照していることを保証することにより、キューブ・モデルを有効にしている。あるキューブ・モデルが完全なものであると考えるために階層を必要としないが、キューブ・モデルからキューブを定義するために、次元ごとに少なくとも１つの階層を定義する。
【０１２１】
各メタデータ・オブジェクトは当該メタデータ・オブジェクトを定義する構成要素と品質を記述するメタデータ・オブジェクトに固有のプロパティの組を有している。キューブ・モデルのメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い表２に記載する。
【０１２２】
【表２】

【０１２３】
ファクト・メタデータ・オブジェクトは所定のアプリケーションにとって関心のある関連する測度をグループ化する。複数のリレーショナル・ファクト表を特定の属性について結合して付加的な関連測度にマップすることができる。ファクト・メタデータ・オブジェクトはファクト−次元結合において使用している属性に関する情報、ならびに、複数のデータベースの表の全体にわたって付加的な測度をマップするのに使用する属性および結合を格納している。したがって、１組の測度に加え、ファクト・メタデータ・オブジェクトは１組の属性と１組の結合を格納している。キューブ・モデルでは、ファクト・メタデータ・オブジェクトを星型スキーマの中心として使用する。
【０１２４】
ファクト・メタデータ・オブジェクトは星型スキーマにおけるファクト表の役割を演じる。ファクト表が行っているのとまったく同様に、ファクト・メタデータ・オブジェクトはデータベース・カタログの中で測度によって表されている測定実体（measurement entity）を収集する。これらは同一の表に由来している必要はないから、設計者は任意のＯＬＡＰアプリケーションのために必要に応じて測度をグループ化することができる。
【０１２５】
ファクト・メタデータ・オブジェクトの、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い表３に記載する。
【０１２６】
【表３】

【０１２７】
次元メタデータ・オブジェクトは星型スキーマにおける次元表の役割を演じる。次元は少なくとも１つの測度のある側面を共に記述している関連する属性をグループ化する。したがって、次元メタデータ・オブジェクトは測度のある側面を共に記述している関連する属性の組を分類する方法を提供する。キューブ・モデルでは、ファクト・メタデータ・オブジェクトの中のデータを「Region（地域）」、「Product(製品）」、または「Time（時）」のような論理カテゴリに従って分類するのに次元を使用する。関連する属性とこれらの属性をグループ化するのに必要な結合とは共に次元メタデータ・オブジェクトに固有のプロパティの中に定義する。
【０１２８】
次元は少なくとも１つの階層を参照する。階層は次元属性の関係と構成を記述しており、次元のナビゲーションと計算を推進するのに使用することができる。
【０１２９】
次元は当該次元が時指向であるか否かを記述する型も有している。たとえば、「Time（時）」と呼ばれる次元は「Year(年) 」、「Quarter(四半期) 」、および「Month(月) 」のようないくつかの属性を含むことができ、時（time）型になりうる。「Region (地域)」と呼ばれる別の次元は「Country(国) 」、「State(州) 」、「City (市) 」、および「Population (人口) 」のようないくつかの属性を含むことができ、通常（regular)型になりうる。型の情報はアプリケーションが時関連の関数をインテリジェントかつ適切に実行するのに使用することができる。
【０１３０】
次元メタデータ・オブジェクトのメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い表４に記載する。
【０１３１】
【表４】

【０１３２】
階層はキューブ・モデルの所定の次元の内の１組の少なくとも１つの属性の間における関係を定義している。これらの関係を定義することは、所定の次元を横断するナビゲーション上および計算上の手段を提供する。１つのキューブ・モデルの１つの次元のために複数の階層を定義することができる。階層メタデータ・オブジェクトは階層を他の関連する属性にリンクさせる１組の属性関係も参照する。属性関係によって直接に関係付けられている属性は階層の一部として照会することができる。たとえば、「Region (地域) 」次元のための階層は「City (市) 」属性を有することができ、１つの属性関係によって「City (市) 」を「City＿Population(市の人口) 」属性にリンクさせることができる。この階層は「City (市) 」を含む照会の中に「City＿Population (市の人口) 」の情報を含めることができる。
【０１３３】
階層は属性の間の親−子関係を記述している。この情報は次元が、どうすれば次元のメンバを閲覧しうるのか、および、当該次元の中のデータをどのように集約するのかを示すために参照する。
【０１３４】
階層型は階層内の属性の間の関係を記述している。次に示す４つの階層型がサポートされている。すなわち、均衡型（balanced）、不均衡型（unbalanced）、不揃型（ragged) 、およびネットワーク型（network)である。
【０１３５】
図１２は本発明のいくつかの実施形態に従う、均衡型階層１２００の一例を示す。均衡型階層は不変の深さを有する有意のレベルと分岐を備えたものである。各属性の論理上の親は当該属性の直上のレベルに存在している。均衡型階層１２００は「Year (年) 」、「Quarter(四半期) 」１２２０、および「Month(月) 」１２３０といった各レベルの意味と深さが不変である時を表している。
【０１３６】
図１３は本発明のいくつかの実施形態に従う、不均衡型階層１３００の一例を示す。不均衡型階層は不変の親−子関係を有するが、特定のレベルにおけるすべてのメンバについて意味構造上不定の意味を有するものである。また、この階層の分岐の深さは不定である。
【０１３７】
不均衡型階層は組織図（organization chart) を表すことができる。たとえば、不均衡型階層１３００は階層の最上層レベルにＣＥＯを、その下に分岐しうる、最高業務執行責任者（chiefoperating officer)と秘書室長（executive secretary)を含む少なくとも２人の人々を示している。最高業務執行責任者も多くの人々を分岐させているが、秘書室長はそうしていない。ＣＥＯと当該ＣＥＯの監督下にあるすべての人々との間には親−子関係が存在する。しかし、ＣＥＯの直下のレベルの意味構造上の意味は当該レベルに様々な型の従業員が存在するから、不定である。
【０１３８】
不揃型階層は、各レベルは不変の意味を有しているが、分岐が、１つの分岐に存在する少なくとも１つのメンバの属性が充足されていない不定の深さを有しているものである。不揃型階層は市または国といった各レベルの意味が一貫して使用されているが、階層の深さが変動する地理的階層を表すことができる。図１４は本発明のいくつかの実施形態に従う不揃型階層１４００を示す。不揃型階層１４００は定義済みの「Continent(大陸) 」レベル、「Country(国) 」レベル、「Province/State (地方／州) 」レベル、および「City(市) 」レベルを有する地理的階層を示している。１つの分岐は「Continent(大陸) 」として「北アメリカ」を、「Country(国) 」として「合衆国」、「Province/State(地方／州) 」として「カリフォルニア」、「City (市) 」として「サンフランシスコ」を有している。しかし、階層１４００は１つのメンバがすべてのレベルにおいてエントリを有していない場合、不揃型になる。たとえば、別の分岐は「Continent(大陸)」として「ヨーロッパ」、「Country(国) 」として「ギリシャ」、「City (市) 」として「アテネ」を有するが、「Province/State (地方／州)」レベルのためにはエントリを有していない（なぜなら、このレベルは「ギリシャ」には適用できないからである）。この例では、「ギリシャ」分岐と「合衆国」分岐は異なる深さまで下降して、不揃型階層１４００を形成している。
【０１３９】
ネットワーク型階層はレベルの順序は指定されていないが、レベルは意味構造上の意味を有しているものである。図１５は本発明のいくつかの実施形態に従い「Color(色) 」、「Size (サイズ) 」、「PackageType(容器の型) 」のような、製品の属性を記述するネットワーク型階層１５００を示している。属性のレベルが固有の親−子関係を有していないから、レベルの順序は変動する。ある小間物（widget）会社は「Color(色)」のための「白」、「Size (サイズ) 」のための「小」、および「PackageType(容器の型) 」のための「収縮包装（shrink wrap)」といったメンバ・エントリを有しているかもしれない。第２のメンバ・エントリは「Color(色)」のために「赤」、「Size (サイズ) 」のために「大」、および「PackageType(容器の型) 」のために「箱」を有しているかもしれない。
【０１４０】
階層（均衡型、不均衡型、不揃型、またはネットワーク型）は当該階層のための展開（deployment）機構も指定する。展開機構は階層の属性をどのように解釈するのかを定義する。次に示す２つの展開機構がサポートされている。すなわち、標準と再帰的である。
【０１４１】
標準展開機構は、階層の中の各属性が１つのレベルを定義している、階層のレベルの定義を使用する。たとえば、「Time (時) 」次元のための均衡型階層は「Year (年) 」、「Quarter(四半期) 」、および「Month(月) 」を含む定義済みの各レベルによって構成することができる。標準展開は４つの階層型のすべてのものとともに使用することができる。表５は本発明のいくつかの実施形態に従い「Time(時) 」次元のための均衡型階層の属性のうちのいくつかを標準展開を用いてどのように構成するのかを示している。
【０１４２】
【表５】

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

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

【０１４７】
測度メタデータ・オブジェクトは測定実体を定義しており、ファクト・メタデータ・オブジェクトの中で使用する。測度は次元の文脈の内において有意になる。たとえば、「３００」の売上は単独では有意ではない。売上なる測度を「Region（地域）」のような次元の文脈に置くと、当該測度は有意になる。たとえば、バーモント州の売上は「３００」である。測度メタデータ・オブジェクトの共通の例は「Revenue(売上)」、「Cost（費用）」、および「Profit (利益) 」である。
【０１４８】
測度オブジェクトは測定実体の存在を明示的にする。測度は少なくとも１つのＳＱＬ式によって定義されるが、それはテーブル列へのマッピングと同程度に単純でありうるし、あるいは、複数の列、および他の測度または属性を含みうる。各測度ごとに、集約のリストを定義してキューブ・モデルまたはキューブの文脈における計算の用に供する。このリストの中の各集約はＳＵＭ、ＣＯＵＮＴ、ＭＩＮ、ＭＡＸのような集約関数と、当該集約関数を適用する次元のリストとを指定している。集約の中の空の次元の組は測度の中で非明示的に参照されている残りの次元をすべて使用すべきことを表している。最初に使用する集約関数がＣＯＲＲＥＬＡＴＩＯＮのように複数の入力を必要とする場合、測度は複数のＳＱＬ式を有することになる。測度は、それが単一のＳＱＬ式のテンプレートを有し、かつ、それが他の測度を参照するのみである場合、集約の空のリストを有する可能性がある。この場合、参照されている測度の集約が実行される。測度と属性は同一の名前空間を共用する。すなわち、名前は、スキーマによって完全に資格が付与されると、測度と属性の間で一意になるはずである。測度の共通の例は「Sales(販売) 」、「Costs(費用) 」、「Profit (利益) 」などである。
【０１４９】
測度はＳＱＬ式の集約によって定義する。テーブル列、属性、および測度を、ＳＱＬ式を構築するためのテンプレート（すなわち「ＳＱＬ式テンプレート」）にマップする。次いで、結果として得られたＳＱＬ式を測度の第１の集約関数のための入力として使用する。測度が複数の集約を有する場合、集約関数はそれらが列挙されている順番に実行し、後続する各集約は先行する集約の結果を入力として取得することになる。測度メタデータ・オブジェクトのＳＱＬ式が他の測度を参照するのみである場合、参照されている測度は必要とされる何らかの集約を記述しているから、集約関数は省力する。
【０１５０】
測度のＳＱＬ式は２つのプロパティ、すなわちＳＱＬ式テンプレートと列、属性、および測度のリストとの組み合わせによって生成する。ＳＱＬ式テンプレートは、｛＄＄ｎ｝がトークンであり、ｎは当該リストに属す特定の列、属性、または測度を参照している、トークンの表記法を使用している。列、属性、および測度のリストは順序付けられており、列、属性、および測度のリストの中の位置はトークンの「ｎ」値に対応している。
【０１５１】
最初の集約への入力としてＳＱＬ式を使用する。各集約は対応する次元の組に適用する関数を指定している。集約関数はたとえばＳＵＭ、ＣＯＵＮＴ、ＭＩＮ、ＭＡＸ、およびＣＯＲＲＥＬＡＴＩＯＮを含む、基になるデータベースがサポートしている任意の集約関数でありうる。いくつかの実施形態では、測度メタデータ・オブジェクトによって各次元を１度だけ集約する。次元の組が空である場合、集約関数は、リストの中の別の集約が使用中であることが明確ではない、キューブまたはキューブ・モデルの中のすべての次元に適用する。いくつかの実施形態では、集約関数はＲＤＢＭＳ１１０がサポートしているユーザ定義の集約関数である。
【０１５２】
単純など測度の一例は「Revenue(売上) 」である。「Revenue(売上)」測度は３つの次元、すなわち「Product(製品) 」、「Market (市場) 」、および「Time
(時」) を備えたキューブ・モデルのために生成することができる。「Revenue(売上)」はＳＱＬ式テンプレート（テンプレート= " ｛$$1 ｝" ）を有し、これは列、属性、および測度の単一項目のリストの中に指定されている列への単一のマッピングである（ただし、リスト="ColumnFact.Rev"である）。集約リストは（ＳＵＭ，＜ＮＵＬＬ＞）である（ただしＳＵＭは集約関数、＜ＮＵＬＬ＞は空の次元の組である）。ＳＵＭなる集約関数のための入力としてＳＱＬ式を使用するから、結果はＳＱＬ、すなわち、ＳＵＭ(Fact.Rev)になる。
【０１５３】
より複雑な測度「Profit (利益) 」はＳＱＬ式テンプレート（テンプレート=" ｛$$1 ｝- ｛$$2 ｝" ）（ただし属性、列、および測度のリストは、リスト="Measure revenue,Column fact.Cost"である）を有している。トークンを正確な参照で置換すると、ＳＱＬ式は"Revenue -Fact.Cost" になる。売上測度の参照をその列の参照に拡張すると、ＳＱＬ式は"Fact.Rev - Fact.Cost"になる。「Profit(利益) 」測度の集約リストは（ＳＵＭ，＜ＮＵＬＬ＞）である。利益のＳＱＬ式をＳＵＭなる集約関数のための入力として使用すると、「Profit (利益) 」測度のためのＳＱＬはＳＵＭ(Fact.Rev- Fact.Cost)になる。
【０１５４】
測度が少なくとも２つのパラメータを必要とする、ＣＯＲＲＥＬＡＴＩＯＮのような集約関数を有する場合、当該測度は当該関数が入力として必要とする個数のＳＱＬ式を有することになる。すなわち、パラメータの個数はＳＱＬ式の個数と一致する。たとえば、ＣＯＲＲＥＬＡＴＩＯＮが２つのパラメータを必要とする場合、２つのＳＱＬ式が存在することになる。
【０１５５】
測度はＳＱＬデータ型に基づくデータ型も有する。ＯＬＡＰ多次元メタデータ・システム１００は測度のデータ型を自動的に判定する。また、測度と属性は同一の名前空間を共用している。したがって、各名前はスキーマによって完全に資格を付与されると、測度と属性の間で一意になる。測度メタデータ・オブジェクトのメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表８に記載する。
【０１５６】
【表８】

【０１５７】
属性はデータベースのテーブル列の基本的な抽象化を表している。属性はテーブル列への単純なマッピングでありうる、複数の列と他の属性を含みうる、そして、基になるデータベースの、ユーザ定義の関数のような機能をすべて含みうるＳＱＬ式によって定義する。いくつかの実施形態では、ＳＱＬ式を定義する際に他の属性を使用する場合、当該他の属性は属性参照ループを形成することができない。たとえば、属性Ａが属性Ｂを参照している場合、属性Ｂは属性Ａを参照することはできない。
【０１５８】
属性のＳＱＬ式は２つのプロパティ、すなわちＳＱＬ式テンプレートと列および属性のリストとの組み合わせによって作成する。ＳＱＬ式テンプレートは、｛＄＄ｎ｝がトークンであり、ｎは当該リストに属す特定の列または属性を参照している、トークンの表記法を使用している。列および属性のリストは順序付けられており、列または属性のリストの中の位置はトークンの「ｎ」値に対応している。
【０１５９】
たとえば、ＳＱＬ式テンプレート（テンプレート= " ｛$$1 ｝｜｜'' ｜｜｛$$2 ｝" ）はリスト="Column CUSTOMER.FIRSTNAME, AttributeLasdtName" のような対応するリストとともに使用し、顧客の名（first name）および姓（last name)とそれらの間の空間とを連結することができる。ＳＱＬ式テンプレートのトークンを正確なリストの参照で置換すると、ＳＱＬ式は"Customer.FirstName｜｜' ' ｜｜ LastName"になる。"Customer.FirstName ｜｜' ' ｜｜Costomer.LastName" なるＳＱＬ式を形成するには、属性の参照を列の参照にまでさらに拡張する。
【０１６０】
属性はデータウェアハウスまたはデータマートの設計において複数の役割を果たすことができる。属性が果たしうる役割はレベル、記述、次元属性、次元キー、またはキーである。
【０１６１】
レベル属性（level attributed）は階層において使用される。共通のレベル属性（levelattribute)の例は「Year (年) 」と「Quarter(四半期) 」、「State(州) 」と「City (市) 」である。記述属性は記述型の属性関係において使用され、付加的な記述情報を別の属性に関連付ける。たとえば、「Product(製品)」と呼ばれる表は製品コードと本文の（textual)記述を備えた記述属性とを備えた属性を有しうる。次元属性は次元型の属性関係において使用され、別の属性の特定の特徴と品質を定義している。共通の次元属性の例は「Population(人口) 」、「Size (サイズ) 」、および「Weight (重量) 」である。次元キー属性はファクトと次元メタデータ・オブジェクトとを結合するのに使用され、次元表の中の主キー、または、ファクト表において使用すべき次元表に属す外部キーを表す。キー属性はファクト・メタデータ・オブジェクトまたは次元メタデータ・オブジェクトの内の表を結合するのに使用される。キー属性は多くの場合、スノーフレーク型スキーマにおいて使用される。
【０１６２】
属性と測度は同一の名前空間を共用している。したがって、各名前はスキーマによって完全に資格が付与されると、属性と測度の間で一意になる。属性と測度はリレーショナル・データベースの列の抽象化である。しかし、それらは複数の列を含みうるＳＱＬ式によって定義されている。測度は属性よりも特殊化している−−それらは低レベルのデータから高レベルのサマリーを算出するのに使用する集約関数（列関数）を備えている。
【０１６３】
表９は本発明のいくつかの実施形態に従う、属性メタデータ・オブジェクトを定義するメタデータ・オブジェクトに固有のプロパティを記述している。
【０１６４】
【表９】

【０１６５】
属性関係は一般に属性の関係を記述している。これらの関係は左属性（leftattribute）および右属性（right attribute)、型、基数（cardinality:カルディナリティ）、ならびに、当該関係が関数依存性を決定しているか否か、によって記述する。型は左属性に対する右属性の役割は何かを記述する。たとえば、「ProductName(製品名)」なる右属性は「ProductCode(製品コード) 」なる左属性を記述している。「ProductName(製品名) 」と「ProductCode(製品コード)」との間の関係型が「ＤＥＳＣＲＩＰＴＩＯＮ」である。基数は左属性のインスタンスと右属性のインスタンスがどのように関係しているのかを記述している。「１：１」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは高々１つ存在し、左属性の各インスタンスに対して右属性のインスタンスは高々１つ存在する。「１：Ｎ」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは高々１つ存在し、左属性の各インスタンスに対して右属性のインスタンスは任意個数存在する。「Ｎ：１」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは任意個数存在し、左属性の各インスタンスに対して右属性のインスタンスは高々１つ存在する。「Ｎ：Ｎ」なる基数においては、右属性の各インスタンスに対して左属性のインスタンスは任意個数存在し、左属性の各インスタンスに対して右属性のインスタンスは任意個数存在する。
【０１６６】
関数依存性のプロパティは属性関係が関数依存性として使用しうるか否かを見分ける。関数依存性は２つの属性の間の関数関係を定義している。たとえば、「City (市) 」と「Mayor(市長) 」、または「Product(製品) 」と「Color(色) 」といった属性の間で関数依存性を定義することができる。関数依存性はすべての「City(市) 」値は１つの「Mayor(市長) 」値を決定している、あるいは、すべての「Product(製品) 」値は１つの「Color(色) 」値を決定している、ということを見分ける。これは、関係において記述される基数は設計者が設定する、ということを意味する。
【０１６７】
属性関係の１つの使用方法は次元における階層の文脈の内ある。階層属性に直接に関係している属性は当該階層の一部として照会することができる。これは当該階層の各レベルが所定のレベルの情報を補完する属性を定義することを可能にする。たとえば、ある階層は「City (市) 」属性を有しうる。この「City (市) 」属性は属性関係を用いて「City＿Population (市の人口) 」属性に関係付けることができる。属性関係の情報を用いると、「City＿Population(市の人口) 」なる情報は「City (市) 」を含む照会に含めることが可能になる。
【０１６８】
属性関係メタデータ・オブジェクトを定義するメタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表１０に記載する。
【０１６９】
【表１０】

【０１７０】
結合メタデータ・オブジェクトは２つのメタデータ・オブジェクトが参照しているリレーショナル表を結合する。２つのメタデータ・オブジェクトはリレーショナル表の列にマップされている属性メタデータ・オブジェクトの少なくとも１つの対について結合することができる。ファクト−次元結合では、結合メタデータ・オブジェクトはファクト・メタデータ・オブジェクトに由来する属性と次元メタデータ・オブジェクトに由来する属性とを結合する。複合結合では、属性対の組は表の同一の組に由来している。たとえば、「FirstName 」と「LastName」から成る複合キーを備えたリレーショナル表である「Table1」と、「FName 」と「LName」から成る複合キーを有するリレーショナル表である「Table2」とを結合するには、２つの結合述部、すなわち「Table1.FirstName」および「Table2.FName」のための１つの結合述部と「Table1.LastName」および「Table2.LName」のための第２の結合述部とを備えた１つのリレーショナル結合を使用する。この複合結合に関する情報は１つの結合メタデータ・オブジェクトに格納する。
【０１７１】
結合メタデータ・オブジェクトは左属性、右属性、および結合演算子から成るリストによって定義する。また、結合型と予期される基数を指定する。結合は２つのファクトの間、２つの次元の間、または、ファクトと次元の間で使用することができる。結合メタデータ・オブジェクトはキューブ・モデル・オブジェクト、ファクト・オブジェクト、および次元オブジェクトが参照する。
【０１７２】
結合メタデータ・オブジェクトを定義する、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表１１に記載する。
【０１７３】
【表１１】

【０１７４】
キューブは単一のＳＱＬステートメントを用いて伝達しうる、ＯＬＡＰキューブのきわめて正確な定義である。各キューブは単一のキューブ・モデルから抽出する。キューブ・ファクトとキューブ次元のリストとは参照元のキューブ・モデルにおけるもののサブセットである。データベースの中のキューブを表すキューブ・ビューの名前も定義する。キューブ次元はキューブ次元当たり１つのキューブ階層しか許可しないから、キューブは複数の階層を使用しないツールとアプリケーションに相応している。
【０１７５】
キューブの目的はＯＬＡＰ構成の標準のリレーショナル・ビューを定義することである。リレーショナル・ビューに加え、キューブはその列の役割を多次元の観点から記述する拡張記述（extended describe)（たとえばＸＭＬ文書）を提供する。キューブを定義するプロセスにおいて、設計者は利用可能な（possible）構成要素のサブセットを選定し、各次元ごとに単一の階層を選ぶ。これはキューブが単一のリレーショナルな結果の組を曖昧に定義することを保証する。キューブの単純性はキューブを、ワールド・ワイド・ウェブ（WorldWide Web: 「ウェブ(Web) 」）サービスによって強化された携帯用装置のようなあまり高機能ではないＯＬＡＰの用途にとって有用にする。
【０１７６】
キューブ・メタデータ・オブジェクトの、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表１２に記載する。
【０１７７】
【表１２】

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

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

【０１８２】
キューブ階層メタデータ・オブジェクトは階層の精査済み版（scopedversion）であり、キューブの中で使用する。キューブ階層はそれが抽出される元をなす階層を参照するとともに、親の階層に由来する属性のサブセットを有しうる。また、キューブ階層メタデータ・オブジェクトはキューブに適用されている属性関係を参照する。いくつかの実施形態では、１つのキューブの１つのキューブ次元ごとに１つのキューブ階層を定義することができる。キューブ階層メタデータ・オブジェクトは当該キューブ階層メタデータ・オブジェクトが抽出される元をなす階層と同一の階層型および展開機構を有している。
【０１８３】
キューブ階層は階層にきわめて似ている。しかし、キューブ次元は１つのキューブ階層のみを参照する。これは単一の「ＳＥＬＥＣＴ」ステートメントがキューブのセルを計算するのを可能する。
【０１８４】
キューブ階層メタデータ・オブジェクトを定義する、メタデータ・オブジェクトに固有のプロパティを、本発明のいくつかの実施形態に従い、次に示す表１５に記載する。
【０１８５】
【表１５】

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

【０１８８】
いくつかの実施形態によれば、メタデータ・オブジェクトの命名規約と命名のための規則とが存在する。本発明の範囲を逸脱することなく、ここで記述したもの以外の命名の規約と規則を使用することができる。オブジェクトを命名する命名規約には２つの異なるもの、すなわち，通常型と区切り型（delimited)がある。メタデータ・オブジェクトの場合、その柔軟性ゆえに、オブジェクトを命名するとき、および、データベースの表と列を参照するときには区切り型の規約を使用する。区切り型の規約は大文字と小文字が混合した名前、空間、および、各国語の文字のような特別の文字を認めている。文字の完全な組はオブジェクトが常駐しているデータベースのコード・ページによって決まる。
【０１８９】
いくつかの実施形態では、命名規約の外に、オブジェクトの中の様々な識別子にいくつかの規則を適用する。たとえば、スキーマの長さは１〜３０バイトであり、スキーマの名前は「ＳＹＳ」で始まらない；名前の長さは１〜１２８バイトである；ビジネスの名前の長さは１〜１２８バイトである；コメントの長さは０〜２５４バイトである；（列を参照する際に使用する）表スキーマの長さは１〜１２８バイトである；（列を参照する際に使用する）表の名前の長さは１〜１２８バイトである；そして、（列を参照する際に使用する）列の名前の長さは１〜１２８バイトである。
【０１９０】
強制されている関係に加え、各メタデータ・オブジェクトごとに付加的な規則が記述されている。すなわち、あらゆるメタデータ・オブジェクトはそれ自体の規則の組を有し、メタデータ・オブジェクトのインスタンスは、当該メタデータ・オブジェクトが当該メタデータ・オブジェクトのためのすべてのメタデータ・オブジェクト規則に従う場合に、有効になる。これらの規則は３つのカテゴリ、すなわち「基本規則（Base Rules) 」、「キューブ・モデル完全性規則（Cube Model Completeness Rules)」、および「最適化規則（OptimizationRules）」に分かれる。次に示す特定の規則の検討は本発明のいくつかの実施形態のための１組の規則を提供する。他の実施形態では、少なくとも１つのメタデータ・オブジェクトのための規則の組を、本発明の範囲を逸脱することなく、変更している。
【０１９１】
キューブ・モデル・メタデータ・オブジェクトのための基本規則は、（１）キューブ・モデル・メタデータ・オブジェクトは０個または１個以上のファクト・メタデータ・オブジェクトを参照する；（２）キューブ・モデル・メタデータ・オブジェクトは０個または１個以上の次元を参照する；（３）次元−結合対は次元および結合の双方を有する；（４）結合の一側のすべての属性がファクト・メタデータ・オブジェクトの属性リストの中に存在し、かつ、すべての他側の属性が次元メタデータ・オブジェクトの属性リストの中に存在する場合、次元に付随する結合は有効になる；および、（５）キューブ・モデルのファクトの中で参照されている各測度ごとに、当該測度の集約におけるすべての明示的な次元の参照は当該キューブによって参照される、である。キューブ・モデルが少なくとも１つの次元を参照している場合、空の次元の組を用いた集約はそれまで参照されなかった、当該キューブ・モデルに由来する少なくとも１つの次元と一致する。
【０１９２】
キューブ・メタデータ・オブジェクトのための基本規則は、（１）キューブ・メタデータ・オブジェクトは１つのキューブ・ファクトを参照する；（２）キューブ・メタデータ・オブジェクトは少なくとも１つのキューブ次元を参照する；（３）キューブ・ファクトはキューブ・モデルの中で使用しているファクトから抽出する；および、（４）キューブ次元はキューブ・モデルの中で使用している次元から抽出する、である。
【０１９３】
ファクト・メタデータ・オブジェクトのための基本規則は、（１）ファクト・メタデータ・オブジェクトは少なくとも１つの測度を参照する；（２）ファクトが参照する属性と測度はすべて結合可能である；（３）ファクト・メタデータ・オブジェクトの文脈では、所定の２つの表の間に単一の結合を定義することができる；（４）ファクト・メタデータ・オブジェクトの中に、結合のループはない；および、（５）ファクト・メタデータ・オブジェクトが参照するすべての結合はファクト・メタデータ・オブジェクトの属性を参照する、である。
【０１９４】
次元メタデータ・オブジェクトのための基本規則は、（１）次元メタデータ・オブジェクトは少なくとも１つの属性を参照する；（２）次元が参照する属性は結合可能てある；（３）結合ループはない；（４）次元の文脈では、任意の２つの所定の表の間で単一の結合が定義されている；（５）ある次元が参照する階層は当該次元の属性を参照する；（６）ある次元の階層が参照する属性関係は当該次元の属性を参照する；および、（７）ある次元が参照する結合は当該次元の属性を参照する、である。
【０１９５】
キューブ・ファクト・メタデータ・オブジェクトのための基本規則は、（１）キューブ・ファクト・メタデータ・オブジェクトは少なくとも１つのファクトを参照する；（２）キューブ・ファクト・メタデータ・オブジェクトは少なくとも１つの測度を参照する；（３）キューブ・ファクト・メタデータ・オブジェクトが参照るす測度はファクト・メタデータ・オブジェクトの一部である、である。
【０１９６】
キューブ次元メタデータ・オブジェクトのための基本規則は次のとおりである。（１）キューブ次元メタデータ・オブジェクトは１つの次元を参照する；（２）キューブ次元メタデータ・オブジェクトはキューブ階層を参照する；および、（３）キューブ次元メタデータ・オブジェクトが参照するキューブ階層はキューブ次元メタデータ・オブジェクトの次元が参照している階層から抽出する。
【０１９７】
階層メタデータ・オブジェクトのための基本規則は、（１）階層メタデータ・オブジェクトは少なくとも１つの属性を参照する；（２）再帰的な展開のために２つの属性を必要とする；（３）ある階層の内部のすべての属性関係は当該階層の一部として左属性を有する；（４）階層の内のすべての属性関係は「１：１」または「Ｎ：１」の基数を有する；および、（５）階層の型と階層の展開とのいくつかの組み合わせは本発明のいくつかの実施形態に従い表１７のように表すことが可能である、である。
【０１９８】
【表１７】

【０１９９】
キューブ階層メタデータ・オブジェクトのための基本規則は、（１）キューブ階層メタデータ・オブジェクトは１つの階層を参照する；（２）キューブ階層メタデータ・オブジェクトは少なくとも１つの属性を参照する；（３）キューブ階層メタデータ・オブジェクトが参照する属性は当該階層の一部である；（４）キューブ階層メタデータ・オブジェクトにおける属性の順序は（ネットワークとして定義された階層を例外として）階層におけるものと同一である；（５）階層の内のすべての属性関係は当該階層の一部として左属性を有する；および、（６）キューブ階層メタデータ・オブジェクトにおいて参照される属性関係はキューブ階層を定義する階層においても参照される、である。
【０２００】
測度メタデータ・オブジェクトのための基本規則は、（１）測度メタデータ・オブジェクトは各ＳＱＬ式テンプレートのためのパラメータとして、属性、列、測度を有しうるが、あるいは、これらをまったく有さなくともよい；（２）ＳＱＬテンプレートとして使用する属性と測度は属性の間、もしくは、測度の間、または、属性および測度の間に依存ループを生成することができない；（３）測度メタデータ・オブジェクトにおいて定義されるすべてのＳＱＬテンプレートは空のストリングではない；（４）ＳＱＬテンプレートは集約関数を使用しない；（５）少なくとも１つの測度、そして測度のみを参照する場合、集約は必要ではない；（６）ＳＱＬテンプレートの個数は第１の集約関数のパラメータの個数と一致する；（７）複数のＳＱＬテンプレートを備えた測度メタデータ・オブジェクトは集約スクリプトの中に少なくとも１つの集約ステップを定義する；（８）測度メタデータ・オブジェクトＡが、複数のＳＱＬテンプレートを定義する測度メタデータ・オブジェクトＢを参照する場合、測度メタデータ・オブジェクトＡは集約スクリプトを有さない；この規則は測度参照ツリーにおけるすべてのレベルに対して適用される；（９）第１の集約として、複数パラメータ型の集約関数を使用する；（１０）測度メタデータ・オブジェクトが少なくとも１つの集約を定義している場合、１つの集約は空の次元の組を有している；（１１）測度メタデータ・オブジェクトの内では、１つの集約の内において、または、複数の集約の全体にわたって、次元を２回以上参照する；（１２）ＳＱＬ式テンプレートの内では、トークンの標識（すなわち｛＄＄＃｝）は「１」から計数を開始するが、計数が途切れることなく連続している；および、（１３）ＳＱＬ式の内では、すべての列、属性、および測度は少なくとも１回は参照される、である。
【０２０１】
属性メタデータ・オブジェクトのための基本規則は、（１）属性メタデータ・オブジェクトはＳＱＬテンプレートのためのパラメータとして、属性、列を有しうるが、あるいは、これらをまったく有さなくともよい；（２）ＳＱＬテンプレートのためのパラメータとして使用する属性は属性の間にループを生成することができない；（３）ＳＱＬテンプレートは空のストリングまたはブランク・ストリングではありえない；（４）ＳＱＬテンプレートの一部になることを許可されている集約関数はない；（５）ＳＱＬ式テンプレートの内では、トークンの標識（すなわち｛＄＄＃｝）は「１」から計数を開始するが、計数が途切れることなく連続している；（６）ＳＱＬ式の内では、すべての列、属性、および測度を少なくとも１回は参照する、である。
【０２０２】
属性関係メタデータ・オブジェクトのための基本規則は、（１）属性関係メタデータ・オブジェクトは２つの属性を参照する；および、（２）属性関係メタデータ・オブジェクトは「基数＝Ｎ：Ｎ」および「関数依存性＝ＹＥＳ」を有するように定義することはできない、である。
【０２０３】
結合メタデータ・オブジェクトのための基本規則は、（１）結合メタデータ・オブジェクトは左属性、右属性、および演算子から成る少なくとも１つのトリプレットを参照する；（２）結合メタデータ・オブジェクトの中のすべての左属性は単一の表の少なくとも１つの列に帰着する；（３）結合メタデータ・オブジェクトの中のすべての右属性は単一の表の少なくとも１つの列に帰着する；および、（４）結合メタデータ・オブジェクトの各トリプレットは有効な演算を定義する；左属性および右属性のデータ・タイプ、ならびにそれらのために定義された演算は互換性がある、である。
【０２０４】
キューブ・モデルが他のメタデータ・オブジェクトへの必要なリンクを有することを保証するために、キューブ・モデル完全性規則は基本規則を拡張して有効なウェアハウスＳＱＬ照会を実行しうるようにする。キューブ・モデル・メタデータ・オブジェクトのためのキューブ・モデル完全性規則は、（１）キューブ・モデル・メタデータ・オブジェクトは１つのファクトを参照する；（２）キューブ・モデル・メタデータ・オブジェクトは少なくとも１つの次元を参照する、である。
【０２０５】
最適化規則はウェアハウスＳＱＬ照会の最適化を実行しうることを保証するために、キューブ・モデル完全性規則を拡張する。
【０２０６】
キューブ・モデル・メタデータ・オブジェクトのための最適化規則は、（１）ファクト−次元において使用する結合は「１：１」または「Ｎ：１」なる基数を有し、ファクト表を次元の主表に結合する、である。
【０２０７】
次元メタデータ・オブジェクトのための最適化規則は、（１）次元の結合によって形成される結合ネットワークを考慮すると、少なくとも１つの表（主表）が存在し、その中では、この表から発散しているすべての結合が「Ｎ：１」または「１：１」なる基数を有する、である。
【０２０８】
結合メタデータ・オブジェクトのための最適化規則は、（１）結合に参加する列について定義した制約が存在する；結合が自己結合である（すなわち、等式の両側で列の同一の組を使用する）場合、当該列の組と一致する主キーを定義する；他のすべての場合において、一方の側の列の組が結合の他方の側と異なる場合、主キーは結合の一方の側の列と一致し、外部キーは主キーを参照するのに加え、列の他の組と一致する；（２）結合の基数は「１：１」、「Ｎ：１」、または「１：Ｎ」である；結合が自己結合である場合、基数は「１：１」である；他のすべての結合の場合において、基数は主キーが定義されている側では「１」であり、外部キーが定義されている側では「Ｎ」である；外部キー側がそれについて定義された主キーも有する場合、基数として「１」を使用する；（３）結合において使用するすべての属性はヌル可能でないＳＱＬ式に帰着する；（４）結合のタイプは「ＩＮＮＥＲ ＪＯＩＮ」である、である。
【０２０９】
〔Ａ．４ メタデータ・オブジェクトの例〕
図１７は本発明のいくつかの実施形態に従う、２つの次元表１７１０、１７２０とファクト表１７００から成る星型スキーマを示す。２本の線１７３０、１７４０がファクト表１７００と次元表１７１０、１７２０の間を結合している。いくつかの実施形態では、データベースの設計者はモデル化ツールまたはユーザ・インターフェース１３０を用いて、メタデータ・オブジェクト１３０のメタデータ・オブジェクト・インスタンスを生成する。多次元メタデータの生成の間に定義される大多数のメタデータ・オブジェクト１３０は当該メタデータ・オブジェクトが新たなモデルと重なり合っている場合には、当該新たなモデルのために再使用することができる。
【０２１０】
図１８〜２２は本発明のいくつかの実施形態に従う、メタデータ・オブジェクト・インスタンスのありうる組と、簡単化のために、図１７の星型スキーマのために生成されるメタデータ・オブジェクトのいくつかのプロパティとを示す。特に、図１８〜２２では省略したプロパティのうちのいくつかは共通のプロパティである。たとえば、図１８〜２２はキューブ・モデル・メタデータ・オブジェクト・インスタンス１８００、キューブ・メタデータ・オブジェクト・インスタンス１８０２、ファクト・メタデータ・オブジェクト・インスタンス１８０４、キューブ・ファクト・メタデータ・オブジェクト・インスタンス１８０６、測度メタデータ・オブジェクト・インスタンス１８０８、１８１０、次元メタデータ・オブジェクト・インスタンス１８１２、１８１４、キューブ次元メタデータ・オブジェクト・インスタンス１８１６、１８１８、階層メタデータ・オブジェクト・インスタンス１８２０、１８２２、１８２４、キューブ階層メタデータ・オブジェクト・インスタンス１８２６、１８２８、結合メタデータ・オブジェクト・インスタンス１８３０、１８３２、および、属性メタデータ・オブジェクト・インスタンス１８３４〜１８４８を示す。
【０２１１】
ユーザはユーザ・インターフェース１５０を用いてメタデータ・オブジェクトを作成する。空のキューブ・モデル・メタデータ・オブジェクトを作成したのち、ファクト・メタデータ・オブジェクトと次元メタデータ・オブジェクトを作成し、適切な結合メタデータ・オブジェクトを作成することにより、キューブ・モデル・メタデータ・オブジェクトに結合させる。
【０２１２】
ここで検討したメタデータ・オブジェクトのプロパティは本発明の範囲を逸脱することなく、変更することができる。
【０２１３】
〔Ｂ．リレーショナル・オンライン分析処理（ＯＬＡＰ）エンジンのために多次元計算を記述する〕
ＯＬＡＰ多次元メタデータ・システム１００は多次元計算を支援する、測度メタデータ・オブジェクトの作成を可能にする。いくつかの実施形態では、測度メタデータ・オブジェクトは表８の中で定義されている特定のプロパティを含む。
【０２１４】
測度メタデータ・オブジェクトの中の測度はＳＱＬ式の集約によって定義する。特に、テーブル列、属性、および測度をＳＱＬ式テンプレートにマップしてＳＱＬ式を構築する。次いで、結果として得られたＳＱＬ式を、測度メタデータ・オブジェクトの第１の集約関数のための入力として使用する。測度メタデータ・オブジェクトが複数の集約を有する場合、集約関数はそれらが列挙されている順序で実行し、後続する各集約は先行する集約の結果を入力として取得する。測度メタデータ・オブジェクトのＳＱＬ式が他の測度を参照しているのみの場合、参照される測度が、必要な集約をすべて記述しているから、集約関数を省略する。
【０２１５】
測度の計算において使用するＳＱＬ式は２つのプロパティ、すなわちＳＱＬ式テンプレートのリストと、列、属性、および測度から成るリストとによって作成する。このＳＱＬ式テンプレートは、｛＄＄ｎ｝がトークンであり、ｎはリストに属す特定の列、属性、または測度を参照している、トークンの表記法を使用する。列、属性、および測度のリストは順序付けられており、列、属性、または測度のリストの中における位置はトークンの「ｎ」値に対応している。大多数の集約関数の場合、大多数の集約関数は入力として単一の式を受領するから、リストの中のＳＱＬ式テンプレートの個数は「１」である。しかし、ＣＯＲＲＥＬＡＴＩＯＮのような集約関数を使用する場合、ＳＱＬ式テンプレートの個数は当該集約関数が受領する入力パラメータの個数と一致する。
【０２１６】
ここでも、第１の集約への入力としてＳＱＬ式を使用する。各集約は対応する次元の組に適用される関数を指定する。集約関数はたとえばＳＵＭ、ＣＯＵＮＴ、ＭＩＮ、ＭＡＸ、およびＣＯＲＲＥＬＡＴＩＯＮを含む、基になるＲＤＢＭＳ１１０にサポートされた任意の集約関数でありうる。いくつかの実施形態では、測度メタデータ・オブジェクトが各測度を一旦集約する。次元の組が空である場合には、リストの中の任意の他の集約が明らかに使用中でないキューブまたはキューブ・モデルの中のすべての次元に集約関数を適用する。
【０２１７】
多次元メタデータ・ソフトウェア１２０は測度メタデータ・オブジェクトの中のメタデータを用いて、キューブ・ビューの生成のためのＳＱＬステートメントを生成する。
【０２１８】
〔Ｂ．１ 測度の要件〕
この節は本発明のいくつかの実施形態に従う、測度のいくつかの要件を記述している。
【０２１９】
測度の一要件は測度の内において特定の計算順序をサポートすることである。キューブ・モデル・メタデータ・オブジェクトまたはキューブ・メタデータ・オブジェクトが参照する測度メタデータ・オブジェクトの組のための計算順序は同一である必要はない−−各測度メタデータ・オブジェクトは任意の他の測度メタデータ・オブジェクトの計算順序とは異なる計算順序を指定することができる。たとえば、「Quantity Sold = SUM(Revenue / UnitPrice) (販売数量＝合計（売上／単価) 」、および「ProfitMargin = SUM(Profit) / SUM(Revenue) (利幅＝合計（利益）／合計（売上) 」。図２３は本発明のいくつかの実施形態に従う、基本データを示す表Ａ１９００を示す。「Clothes(衣料品)」と名付けられたメンバは「Trousers (スボン) 」１９０２、「Shirt(シャツ) 」１９０４、および「Tie(ネクタイ) 」１９０６の親であり、「UnitPrice (単価) 」１９１０と「Revenue(売上) 」１９１２を用いて「Quality Sold for Clothes (衣料品の販売数量) 」を算出する。すなわち、（６８０／４０）＋（７８０／６０）＋（１７５／２５）＝１７＋１３＋７＝３７である。「Clothes(衣料品)」の「Profit Margin(利幅）」は「Revenue(売上) 」１９１２と「Profit (利益) 」１９１４を用いて算出する。すなわち、（６８＋１１７＋５２．５）／（６８０＋７８０＋１７５）＝２３７．５／１６３５＝０．１４５である。
【０２２０】
測度の別の要件は相関演算（たとえば、CORRELATION(Revenue,Profit) (相関 (売上、利益) ) のような複数の入力パラメータを有する集約関数をサポートすることである。測度オブジェクトは集約関数の各入力ごとに独立した式を定義することを必要とする。
【０２２１】
測度のさらに別の要件はスナップショット測度（たとえば、Inventory(在庫))のような半付加的（semi-additive)な測度をサポートすることである。たとえば、「Market(市場) 」次元と「Product(製品) 」次元のために、合計演算（たとえば、SUM(Inventory) (合計 (在庫))）を実行する。「Time (時)」次元のために、ＭＩＮ（最小）演算（たとえば、MIN(Inventory) (最小 (在庫))）を実行する。
【０２２２】
図２４は本発明のいくつかの実施形態に従う、（SUM, Market) (合計，市場)と（MIN, Time) (最小，時) なる集約を有する測度を示す表Ｂ２０００を示す。表Ｂ２０００において、アスタリスク（たとえば「＊」）またはプラス符号「たとえば「＋」）を有さない数は基本データを表す。アスタリスクを有する数は（SUM,Market) (合計，市場) に対する集約を示す。プラス符号を有す数は（MIN, Time) (最小，時) に対する集約を示す。たとえば、「１月」２００４に対するとともに「カリフォルニア」２００２に対する（SUM,Market) (合計，市場) は「２８」であり、「四半期１」に対するとともカリフォルニア２００２に対する（MIN, Time) (最小，時) は「２５」である。
【０２２３】
測度の付加的な要件は次元当たり１つの集約をサポートすること、次元の全体にわたって異なる計算順序をサポートすること、および、高度の応用（たとえば、「(SUM, Product) (合計，製品) 」、「(AVG, Market)(平均，時) 」、「(MAX, Market)(最大，市場)」を用いて、最大平均在庫を有する市場の所在を探索すること）を目標にすることである。高度の応用を目標にするとは半付加的な測度をより一般的に表現することであるが、それは図３０を参照して後述する。また、高度の応用を目標にすることの要件は非対称測度によって表されるが、それは後述する。非対称測度は集約リストの中で複数の集約を定義する。
【０２２４】
図２５〜２８は本発明のいくつかの実施形態に従う、集約、すなわち「(SUM,Product) (すなわち製品の合計) 」、「(AVG, Time) （すなわち時にわたる平均）」、および「(MAX, Market)(すなわち市場の最大値)」を有する測度を示す表Ｃ２１００を示す。表Ｃ２１００において、アスタリスク（たとえば「＊」）またはプラス符号（「たとえば「＋」）またはダッシュ（たとえば「−」）を有さない数は基本データを表す。すなわち、図２５にベース・データが示されている。図２６では、表Ｃ２１００において、「(SUM,Product) (合計，製品) 」のための集約のための数が付加されており、アスタリスクによって識別されている。たとえば、「January(１月）」２１０５について「LosAngels (ロサンゼルス) 」２１０４における「Clothes(衣料品) 」の場合、「(SUM, Product) (合計，製品) 」は「６６」である。図２７では、表Ｃ２１００において、「(AVG,Time)(平均，時) 」のための集約のための数が付加されており、プラス符号によって識別されている。たとえば、「第１四半期（ＱＴＲ１）」２１０９における「SanJose（サンノゼ）」２１０８における「ズボン（Trousers）」２１０６の場合、「(AVG, Market)(平均，時) 」は「１１」である。図２８では、「(MAX,Market)(最大，市場) 」用の数が付加されており、ダッシュによって識別されている。たとえば、「January(１月）」２１０５における「California(カリフォルニア）」２１１２における「Shirt(シャツ) 」２１１０の場合、「(MAX, Market)(最大，市場) 」は「３６」である。
【０２２５】
〔Ｂ．２ 測度を記述する〕
本発明のいくつかの実施形態では、式のリストと集約のリストとを含む測度メタデータ・オブジェクトを作成する。測度メタデータ・オブジェクトは節Ａにおいて詳細に検討した。理解を容易にするために、この節においても測度メタデータ・オブジェクトを検討することにする。測度メタデータ・オブジェクトの中の式のリストは各式のためのＳＱＬ式テンプレートと、各ＳＱＬ式のための列のリスト、属性、および測度とを含む。集約のリストの中の各エントリは集約関数と対応する次元の組とを含む。空の次元は残りの次元をすべて集約関数のために使用すべきことを意味する。いくつかの実施形態では、測度メタデータ・オブジェクトの場合、１つの集約のみが空の次元の組を有しうる。
【０２２６】
図２９は本発明のいくつかの実施形態に従う、２つの完全に付加的な測度メタデータ・オブジェクト（「費用（Cost）」２２１０と「売上(revenue）」２２２０）の作成を示す。図２９の例では、３つの次元、すなわち製品（Product)２２０２、市場（Market)２２０４、および時（Time）２２０６が存在する。各測度メタデータ・オブジェクト２２１０、２２２０は＜ＮＵＬＬ＞なる次元の組を指定しているが、これはＳＵＭなる集約関数のためにすべての次元を使用することを意味する。
【０２２７】
「費用」測度メタデータ・オブジェクト２２１０は３つの次元、すなわち製品２２０２、市場２２０４、および時２２０６を備えたキューブ・モデルのために作成されている。「費用」測度メタデータ・オブジェクト２２１０はＳＱＬ式テンプレート２２１２（テンプレート＝“｛＄＄１｝”）有するが、これは列、属性、および測度から成る単項目のリスト（リスト＝“Column Fact.Cost”）への単純なマッピングを表している。すなわち、「費用」測度メタデータ・オブジェクト２２１０の場合、式のリストは“｛＄＄１｝”を参照するが、それはＳＱＬ式を生成するときに「ColumnFact.Cost」で置換されるトークンである。集約リスト２２１４は（ＳＵＭ，＜ＮＵＬＬ＞）（ただし、ＳＵＭは集約関数であり、＜ＮＵＬＬ＞は空の次元の組である）である。ＳＱＬ式テンプレート２２１２に由来するＳＱＬ式はＳＵＭなる集約関数のための入力として使用し、結果として「ＳＵＭ（Fact.Cost)」というＳＱＬになる。
【０２２８】
「売上」測度メタデータ・オブジェクト２２２０は３つの次元、すなわち製品２２０２、市場２２０４、および時２２０６を備えたキューブ・モデルのために作成する。「売上」測度メタデータ・オブジェクト２２２０はＳＱＬ式テンプレート２２２２（テンプレート＝“｛＄＄１｝”）を有するが、これは列、属性、および測度から成る単項目のリスト（リスト＝“Column Fact.Rev"）への単純なマッピングを表している。すなわち、「売上」測度メタデータ・オブジェクト２２２０の場合、式のリストは“｛＄＄１｝”を参照するが、それはＳＱＬ式を生成するときに「ColumnFact.Rev 」で置換されるトークンである。集約リスト２２２４は（ＳＵＭ，＜ＮＵＬＬ＞）（ただし、ＳＵＭは集約関数であり、＜ＮＵＬＬ＞は空の次元の組である）である。ＳＱＬ式テンプレート２２２２に由来するＳＱＬ式はＳＵＭなる集約関数のための入力として使用し、結果として「ＳＵＭ（Fact.Rev)」というＳＱＬになる。
【０２２９】
図３０は本発明のいくつかの実施形態に従う半付加的な測度の作成を示す。「在庫(Inventory）」測度メタデータ・オブジェクト２３１０はＳＱＬ式テンプレート２３１２（テンプレート＝“＄＄１”）を有するが、これは列、属性、および測度から成る単項目のリスト（この場合、リスト＝"ColuumnFact.Inv"）への単純なマッピングを表している。「在庫」測度メタデータ・オブジェクト２３１０において、集約リスト２３１４は２つの集約、ＳＵＭとＡＶＧ（すなわち平均）を含む。「在庫」測度メタデータ・オブジェクト２３１０は「時」なる次元のリストを集約するから、集約リストはＳＵＭのために＜ＮＵＬＬ＞を指示し（これは、すべての次元がリストにおいて参照されているわけではない〔すなわち、時以外のすべての次元であり、この例の場合には製品や市場でありうる〕、ということを意味する）、「時」のためにＡＶＧを指示している。ＳＵＭ演算を最初に実行し、その合計演算の結果を用いてＡＶＧ演算を実行する。結果として得られるＳＱＬ式は複数の集約ステップを含む。理解を容易にするために、結果として得られるＳＱＬ式の単純な例を提示する。たとえば、結果として得られるＳＱＬ式はＡＶＧ（Ｓ１）である（ただし、Ｓ１はＳＵＭ（Fact.Inv）の結果である）。
【０２３０】
図３１は本発明のいくつかの実施形態に従う、集約を備えた複合測度の作成を示す。この場合、「利益（Profit）」測度メタデータ・オブジェクト２４１０は事前に定義した測度を使用し、実行すべき集約を決定する。「利益」のようなより複雑な測度はＳＱＬ式テンプレート２４１２（テンプレート＝“｛＄＄１｝−｛＄＄２｝”）（ただし、列、属性、、および測度から成るリストは「リスト＝“MeasureRevenue, Column Fact.Cost"」である）を有する。すなわち、式のリストは“｛＄＄１｝−｛＄＄２｝”を含むが、これは第１のトークン｛＄＄１｝は「売上」測度メタデータ・オブジェクト２２２０からの集約の結果で置換され、第２のトークン｛＄＄２｝は「費用」測度メタデータ・オブジェクト２２１０からの集約の結果で置換される、ということを表している。トークンを正確な参照で置換すると、ＳＱＬ式は“Revenue- Fact.Cost"になる。「売上」測度の参照をその列の参照に拡張すると、ＳＱＬ式は"Fact.Rev -Fact.Cost"になる。
【０２３１】
「利益」測度メタデータ・オブジェクト２４１０の集約リスト２４１４は（ＳＵＭ，＜ＮＵＬＬ＞）である。集約リスト２４１０において、＜ＮＵＬＬ＞なる次元の組はＳＵＭ演算のためのすべての次元を表すために使用されている。「利益」ＳＱＬ式をＳＵＭなる集約関数のための入力として使用すると、「利益」測度のＳＱＬ式はＳＵＭ（Fact.Rev - Fact.Cost）になる。すなわち、利益は、売上から費用をすべて減算したものを合計することにより得られる。
【０２３２】
図３２は本発明のいくつかの実施形態に従う、集約のない複合測度の作成を示す。この場合、「利幅（Profit Margin)」測度メタデータ・オブジェクト２５１０は事前に定義された測度メタデータ・オブジェクト（すなわち「売上」測度メタデータ・オブジェクト２２２０と「利益」測度メタデータ・オブジェクト２４１０）を使用し、実行すべき集約を何ら必要としない（これは集約リスト２４１４の中のある集約の代わりに＜ＮＵＬＬ＞によって表示されている）。この場合、当該集約は基本測度に由来する。
【０２３３】
「利幅」測度メタデータ・オブジェクトはＳＱＬ式テンプレート２５１２（テンプレート＝“｛＄＄１｝／｛＄＄２｝”）を有する。第１のトークン｛＄＄１｝は「利益」測度メタデータ・オブジェクト２４１０からの集約の結果によって置換し、一方、第２のトークン｛＄＄２｝は「売上」測度メタデータ・オブジェクト２２２０からの集約の結果によって置換する。したがって、「利幅」測度メタデータ・オブジェクトのための、結果として得られるＳＱＬ式は「ＳＵＭ(Fact.Rev - Fact.Cost)／ＳＵＭ(Fact.Rev)」である。すなわち、利益の合計を計算し、売上の合計を計算し、そして利益を売上で除算して利幅を得る。
【０２３４】
図３３は本発明のいくつかの実施形態に従う、ＯＬＡＰ関数を用いた、測度の作成を示す。「利益順位（Profit Rank)」測度メタデータ・オブジェクト２６１０は（たとえばＤＢ２（Ｒ）ＵＤＢ ＲＤＢＭＳから利用できる）ＲＡＮＫ関数を用いて「利益」測度を順位付ける。新たな「利益順位」測度メタデータ・オブジェクト２６１０は集約を何ら必要としない。特に、「利益順位」測度メタデータ・オブジェクト２６１０はＳＱＬ式テンプレート（テンプレート＝“ＲＡＮＫ（）ＯＶＥＲ （ＯＲＤＥＲ ＢＹ｛＄＄１｝）”）を有するが、これは第１のトークンは｛＄＄１｝は「利益」測度メタデータ・オブジェクト２４１０からの集約の結果で置換する、ということを表す。集約リスト２６１４は集約関数の代わりに＜ＮＵＬＬ＞を備えることにより、集約は存在しない、ということを表している。ＲＡＮＫ測度の結果として得られるＳＱＬ式は「ＲＡＮＫ（）ＯＶＥＲ（ＯＤＥＲ ＢＹ ＳＵＭ（Fact.Rev- Fact.Cost))」である。
【０２３５】
図３４は本発明のいくつかの実施形態に従う、集約と複数の入力とを備えた測度を示す。「売上−利益相関（RevProfit Correlation)」測度メタデータ・オブジェクト２７１０は「売上」測度メタデータ・オブジェクト２２２０と「利益」測度メタデータ・オブジェクト２４１０とを利用する。「売上−利益相関」測度メタデータ・オブジェクトは各々が｛＄＄１｝によって表される第１のトークンを備えた２つのＳＱＬ式テンプレート２７１２、１７１３を有する。ＳＱＬ式テンプレート２７１２（テンプレート＝“｛＄＄１｝”）の場合、第１のトークン｛＄＄１｝は「売上」測度メタデータ・オブジェクト２２２０からの集約の結果で置換する。ＳＱＬ式テンプレート２７１３（テンプレート＝“｛＄＄１｝”）の場合、第１のトークン｛＄＄１｝は「利益」測度メタデータ・オブジェクト２４１０からの集約の結果で置換する。次いで、相関を実行する。相関とは２つの一連の数がどの程度良好に相互に関連するかの測定結果を与える統計関数のことである。「相関」測度のための、結果として得られるＳＱＬ式はＣＯＲＲＥＬＡＴＩＯＮ（Fact.Rev,(Fact.Rev-Fact.Cost)) である。集約リスト２７１４はＣＯＲＲＥＬＡＴＩＯＮ演算とすべての次元を表す＜ＮＵＬＬ＞なる次元の組とを指定している。
【０２３６】
図３５は本発明のいくつかの実施形態に従う、図２９〜３４に由来するすべての定義済みの測度メタデータ・オブジェクトを示す。一部の測度メタデータ・オブジェクトは他のものの上に構築する。たとえば、「売上−利益相関」測度メタデータ・オブジェクト２７１０は「売上」測度メタデータ・オブジェクト２２２０と「利益」測度メタデータ・オブジェクト２４１０の上に構築し、一方、「利益」測度メタデータ・オブジェクト２４１０は「費用」測度メタデータ・オブジェクト２２１０と「売上」測度メタデータ・オブジェクト２２２０の上に構築する。
【０２３７】
〔Ｂ．３ 少なくとも１つの測度メタデータ・オブジェクトによって表される測度のためのＳＱＬステートメントを生成する〕
多次元メタデータ・ソフトウェア１２０は測度メタデータ・オブジェクトによって表される単一のＳＱＬステートメントを生成する。図３６は本発明のいくつかの実施形態に従い少なくとも１つの測度メタデータ・オブジェクトからＳＱＬステートメントを生成する論理を示す。制御はブロック２９００において、少なくとも１つの測度メタデータ・オブジェクトの各々のもののための測度記述の受領と、測度記述に基づいた、図２９〜３５において説明した測度メタデータ・オブジェクトのうちの少なくとも１つのもののような、少なくとも１つの測度メタデータ・オブジェクトの生成とによって開始する。ブロック２９０２において、すべての測度メタデータ・オブジェクトを参照しているファクト・メタデータ・オブジェクトのファクト記述を受領し、ファクト記述からファクト・メタデータ・オブジェクトを生成する。また、ファクト記述は属性メタデータ・オブジェクトと結合メタデータ・オブジェクトを参照する。ブロック２９０３において、少なくとも１つの次元メタデータ・オブジェクトの各々のための次元記述を受領し、この次元記述から少なくとも１つの次元メタデータ・オブジェクトを生成する。次元記述は少なくとも１つの属性メタデータ・オブジェクト、０個または１個以上の結合メタデータ・オブジェクト、および少なくとも１つの階層メタデータ・オブジェクトを参照している。各階層メタデータ・オブジェクトはＲＯＬＬＵＰ文節を構築するのに使用する情報を含む。特に、本発明のいくつかの実施形態では、キューブ・モデル・メタデータ・オブジェクトはいくつかの利用可能な階層を参照するが、ＳＱＬの生成にはただ１つの階層の選択を必要とするのみである。ブロック２９０４において、ファクトと少なくとも１つの次元メタデータ・オブジェクトとを参照するキューブ・モデル・メタデータ・オブジェクトのキューブ・モデル記述を受領し、このキューブ・モデル記述からキューブ・モデル・メタデータ・オブジェクトを生成する。ブロック２９０６において、キューブ・モデル記述のサブセットの選択を受領する。ブロック２９０８において、この選択に基づいて、キューブ・メタデータ・オブジェクトを生成する。また、少なくとも１つの測度メタデータ・オブジェクトの中のメタデータからキューブ・ビューを作成するＳＱＬステートメントを生成する。ＳＱＬステートメントの生成は他のメタデータ・オブジェクト（たとえば階層メタデータ・オブジェクト）の中の他のメタデータも使用する。
【０２３８】
特に、ＳＱＬステートメントの生成は階層メタデータ・オブジェクトの中のメタデータから少なくとも１つのＲＯＬＬＵＰ演算子を生成する。ＲＯＬＬＵＰ演算子（「ＧＲＯＵＰ ＢＹ」文節の拡張）は列のリストに基づいて複数の小計（subtotal）のグループ化文節を生成する。グループ化文節は階層メタデータ・オブジェクトに由来する情報を用いて生成する。これはＯＬＡＰの観点からは、所定の次元における階層の計算と同じ効果を有する。国、州、および市から成る階層を有する場所のような次元を考える。ＲＯＬＬＵＰ（国，州，市）なる文節は当該階層の計算を表すグループ化文節を生成する。ｎ個の構成要素(c₁, c₂, . . . , c_n-1,c_n)から成るＲＯＬＬＵＰは次に示すグループ化文節と等価である。
(c₁,c₂, . . . , c_n-1, c_n)
(c₁,c₂, . . . , c_n-1)
· ··
(c₁,c₂)
(c₁)
【０２３９】
ＲＯＬＬＵＰ文節の中のｎ個の構成要素が（ｎ＋１）個のグループ化文節に変換される点に留意されたい。ＯＬＡＰアプリケーションは（たとえば次元メタデータ・オブジェクトの中で定義される）複数の次元を有する。各次元のためのＲＯＬＬＵＰはＯＬＡＰキューブを表す結果をリレーショナルな方法で返す。単一のステートメントにおいて複数のＲＯＬＬＵＰ演算子を組み合わせると、グループ化文節の直積演算（Cartesian product)が各ＲＯＬＬＵＰごとに生成されることになる。たとえば、ＲＯＬＬＵＰ（国，州）なる単一のステートメントに次に示すＲＯＬＬＵＰ演算子の対を組み合わせると、次に示す文節が生成されるが、それらはキューブを構成する１組のグループ化文節である。
（国，州，年，月）
（国，州，年）
（国，州）
（国，年，月
（国）
（年，月）
（年）
（ ）
【０２４０】
ＲＯＬＬＵＰ演算子を使用する照会は単一の結果の組の中にすべての生成済みのグループ化文節を含んでいる。したがって、この結果の組はすべてのグループ化文節の列に加え集約済みの列を含んでいる。次の例において示すように、様々なグループ化の組の結果を組み合わせるために、所定の行がメンバではないすべてのグループ化列においてヌル（null）を返す。単一の次元におけるＲＯＬＬＵＰ照会の結果については表１８を参照されたい。ＲＯＬＬＵＰ演算子を含むＳＥＬＥＣＴステートメントを生成する。メタデータ・オブジェクト１３０に基づいて、ＳＥＬＥＣＴステートメントを生成する。たとえば、下のＳＥＬＥＣＴステートメントでは、測度メタデータ・オブジェクトから「合計」演算子を生成し、結合メタデータ・オブジェクトから結合を生成している。
【０２４１】
ＳＥＬＥＣＴ country，state、ｓｕｍ（ａｍｔ） ＡＳ revenue
ＦＲＯＭ ファクト ｆ，location １
ＷＨＥＲＥ ｆ．ｌｉｄ ＝ １．ｌｉｄ
ＧＲＯＵＰ ＢＹ ＲＯＬＬＵＰ（country，state）
【０２４２】
【表１８】

【０２４３】
表１８における例では、州の列における（ダッシュで示されている）ヌルによって、アメリカ合衆国（ＵＳＡ）の総売上を有する行を指定している。国の列および州の列の双方におけるヌルによって、すべての国と州の総売上を備えた行を指定している。
【０２４４】
図３６はキューブ・ビューを生成するために測度メタデータ・オブジェクトを使用することを記述しているけれども、付加的な実施形態では、キューブ・ビューを生成することなく、測度メタデータ・オブジェクトを使用する。すなわち、キューブ・ビューは計算を指定するために測度メタデータ・オブジェクトの定義を使用する１つの方法である。測度メタデータ・オブジェクトの定義を使用する別の方法は、アプリケーションが測度の定義とキューブ・モデルのメタデータとを読み取り、測度の定義とキューブ・モデルのメタデータとからＳＱＬステートメントを直接に生成することである。
【０２４５】
図３７は本発明のいくつかの実施形態に従い少なくとも１つの測度メタデータ・オブジェクトとキューブ・モデル・メタデータ・オブジェクトとからＳＱＬステートメントを生成する論理を示す。制御はブロック２９１０において、少なくとも１つの測度メタデータ・オブジェクトの各々のための測度記述の受領と、測度記述に基づいた、図２９〜３５において説明した測度メタデータ・オブジェクトのうちの少なくとも１つのもののような、少なくとも１つの測度メタデータ・オブジェクトの生成とによって開始する。ブロック２９１２において、すべての測度メタデータ・オブジェクトを参照するファクト・メタデータ・オブジェクトのファクト記述を受領し、このファクト記述からファクト・メタデータ・オブジェクトを生成する。また、ファクト記述は属性メタデータ・オブジェクトと結合メタデータ・オブジェクトを参照する。ブロック２９１３において、少なくとも１つの次元メタデータ・オブジェクトの各々のための次元記述を受領し、この次元記述から当該少なくとも１つの次元メタデータ・オブジェクトを生成する。次元記述は少なくとも１つの属性メタデータ・オブジェクト、０個または１個以上の結合メタデータ・オブジェクト、および少なくとも１つの階層メタデータ・オブジェクトを参照する。各階層メタデータ・オブジェクトはＲＯＬＬＵＰ文節を構築するのに使用する情報を含んでいる。特に、本発明のいくつかの実施形態では、キューブ・モデル・メタデータ・オブジェクトはいくつかの利用可能な階層を参照するが、ＳＱＬの生成にはただ１つの階層の選択を必要とするのみである。ブロック２９１４において、ファクトと少なくとも１つの次元メタデータ・オブジェクトとを参照するキューブ・モデル・メタデータ・オブジェクトのキューブ・モデル記述を受領し、このキューブ・モデル記述からキューブ・モデル・メタデータ・オブジェクトを生成する。ブロック２９１６において、キューブ・モデル・メタデータ・オブジェクトのサブセットの選択をアプリケーション・プログラムによって行う。ブロック２９１８において、アプリケーション・プログラムの制御下で、キューブ・モデル・メタデータ・オブジェクトと上記測度メタデータ・オブジェクトのうちの少なくとも１つのものとを用いて、多次元の情報を検索するＳＱＬステートメントを生成する。このＳＱＬステートメントの生成は他のメタデータ・オブジェクト（たとえば階層メタデータ・オブジェクト）の中の他のメタデータも使用する。
【０２４６】
多次元メタデータ・ソフトウェア１２０は単一のＳＱＬステートメントを備えた複数の測度を計算する際における主要な問題点（すなわち、測度の対称性、含まれている集約関数の分配、および順序（order)次元が集約スクリプトの中に現れる）を取り扱う。また、多次元メタデータ・ソフトウェア１２０は様々な型（たとえば、総計（GrandTotal)照会、スライス基準（Slice based)照会、および完全キューブ照会）を取り扱う。総計スライスにおいては、すべての次元の総計のみを返す。スライスは副キューブ（sub-cube）であり、一方、完全キューブは全キューブ（entirecube)である。
【０２４７】
測度は測度メタデータ・オブジェクトとして表す。単一のＳＱＬステートメントにおいて複数の測度を計算すべき場合、本発明の実施形態はそれらの測度に互換性があるか否かを判断する。互換性のある測度はそれらが参照する次元のための同一の集約順序の仕様を有する。１組の測度に互換性がない場合、本発明は互換性のない測度を単一のＳＱＬステートメントにおいて組み合わせるための方法を少なくとも１つ決定する。いくつかの実施形態では、ＪＯＩＮ演算（「結合（joining)とも呼ばれる」）を用いて組み合わせるが、このプロセスは図３８において詳述する。いくつかの実施形態では、集約ステップを再構成することにより互換性のない測度を組み合わせて、それらが互換性を有するようにしている（これは「ネスティング（nesting)」とも呼ばれている）が、このプロセスは図３９において詳述する。いくつかの実施形態では、数組の測度を結合させるとともに数組の測度をネストさせる、結合とネスティングとの混合形態を実現している。
【０２４８】
図３８は本発明のいくつかの実施形態に従い測度を組み合わせるための論理のさらなる詳細を示す。図３８のプロセスはすべての測度を計算するための単一のＳＱＬステートメントを生成するのに使用する最高レベルの論理を示す。本発明の実施形態は最小個数の、互換性のある測度の組を生成することを試みる。また、測度の非互換性に起因して複数の組が不可避である場合には、組の好適な組み合わせは、その中にすべての対称的な測度を備えた測度の対称的な組を有するものである。
【０２４９】
図３８において、制御はブロック２９４０において１組の測度にアクセスすることにより開始する。１組の測度は少なくとも１つの測度を含む。ブロック２９４２において、少なくとも１つの測度メタデータ・オブジェクトの中の測度の組を対称的な測度の組と非対称の組とに分離する。対称的な測度は単一の集約演算子を有し、特定の集約の順序を何ら指定しない。多くの用途において、このような測度は一般的である。すべての対称的な測度は互換性がある。次元ごとにＲＯＬＬＵＰ演算子を用いることにより、すべての対称的な測度を計算する単一のＳＱＬステートメントを生成することができる。たとえば、先行する例で使用した「売上」測度、「費用」測度、および「製品」測度は対称的である。一部の測度メタデータ・オブジェクトは少なくとも１つの他の測度を参照する。たとえば、「利幅」測度は「利益」測度と「売上」測度を参照し、これらは「収入（Income）」測度と「出費（Expense)」測度を参照する。「収入」測度および「出費」測度の両者は対称的であるから、「利幅」測度は対称的な測度の組の中に存在する。ブロック２９４４において、対称的な測度の組のためのＳＱＬステートメントを生成する。対称的な測度の組と非対称の測度の組は独立かつ同時並行的に、あるいは任意の順序で処理する。ブロック２９４６において、対称的な測度の組のためのＳＱＬステートメントを非対称の測度の組のためのＳＱＬステートメントと組み合わせて、多次元の情報を検索するための単一のＳＱＬステートメントを形成する。これら２つのステートメントを組み合わせるのに使用する手法は非対称の測度の組の性質によって決まる。非対称の組の中の一部の測度を一般的かつ対称的なサブキューブから計算しうる場合、対称的な計算を、一般的かつ対称的なサブキューブの計算の上に構築するネストされた計算として書き直すことにより、ネスティングを用いてそれらの測度の計算と対称的な測度とを組み合わせることができる。非対称の組のすべての測度が、特定の順序で集約されるべき次元を必要としている（すなわち対称性をほとんど、またはまったく有さない）、あるいは、キューブの次元について矛盾する計算を指定している場合、それら非対称の測度を同一の計算の順序を共用しているサブセットに分割し、それらを内部結合と組み合わせるＳＱＬステートメントを生成する。ネスティングによって分離できない非互換性を有するこれら非対称の測度は内部結合によって、対称的な測度と、さらに、ネスティングによって対称的な測度と組み合わせることのできた任意の非対称の測度とを組み合わせる。
【０２５０】
図３９は本発明のいくつかの実施形態に従いネスティングを用いて互換性のない測度を組み合わせるための論理のさらなる詳細を示す。制御はブロック２９５０において、１組の測度にアクセスすることにより開始する。ブロック２９５２において、測度の上記組の中の次の測度を選択し、１つのもの（たとえば第１のもの）について開始する。ブロック２９５４において、当該測度が先行する測度と互換性がある否かを判断する。第１の測度を処理する場合、（第１の測度には先行する測度が存在しないから）上記判断は当該測度には互換性がある、というものである。当該測度に互換性がある場合、プロセスはブロック２９６０に進み、そうでない場合、プロセスはブロック２９５６に進む。ブロック２９５６において、選択した測度が先行する測度と互換性を有しうるように少なくとも１つの測度が書き直されているか否かを判断する。少なくとも１つの測度が書き直されている場合、プロセスはブロック２９５８に進み、そうでない場合、プロセスはブロック２９６４に進む。ブロック２９５８において、少なくとも１つの測度を書き直す。次いで、処理すべき測度が他にあるか否かを判断する。そうである場合、プロセスはブロック１９５２にループバックし、そうでない場合、プロセスはブロック２９６２に進む。ブロック２９６２において、書き直した測度を処理し、多次元の情報を検索するためのＳＱＬステートメントを生成する。選択した測度が先行する測度と互換性がなく、書き直しができない場合、ブロック２９６４において、当該測度を、図３８を参照して説明した手法を用いて結合する。
【０２５１】
図４０は本発明のいくつかの実施形態に従う、対称的な測度の組と非対称の測度の組（ブロック２９４４、２９４５）の両者のためのＳＱＬステートメントを生成する論理のさらなる詳細を示す。制御はブロック２９７０において、測度メタデータ・オブジェクトの中の少なくとも１つのＳＱＬ式テンプレートの中の式を測度メタデータ・オブジェクトにおいて定義されている集約のリストの中の第１の集約に入力することにより開始する。ブロック２９７２において、次の集約を処理し、１つのもの（たとえば第１のもの）について開始する。集約を処理することの結果はＳＱＬステートメントである。測度が複数の集約を含む場合、第１の集約から生じる結果を次の集約のための入力として使用する。これはネストされたＳＱＬステートメントと呼ばれいている。ブロック２９７４において、集約リストの中に処理すべきさらなる集約があるか否かを判断する。そうである場合、プロセスはブロック２９７２に進み、先行する集約の処理の出力を次の集約に入力する。そうでない場合、プロセスはブロック２９７６に進む。ブロック２９７６において、多次元の情報を検索する構造化照会言語（Structured Query Language)ステートメントを出力する。いくつかの実施形態では、ＳＱＬステートメントをキューブ・ビューとしてカタログ化し、キューブ・メタデータ・オブジェクトがそれを参照する。
【０２５２】
複数の測度を計算するという観点から、測度の対称性、含まれている集約関数の分配、および集約スクリプトの中の順序の次元の出現は多次元メタデータ・ソフトウェア１２０が取り扱う。
【０２５３】
対称性については、対称的な測度は集約リストの中に単一の出力を定義し、非対称の測度は集約リストの中に複数の集約を定義する。測度が集約を定義しない場合、対称性は基本測度が定義する。この状況では、測度はその基本測度がすべて対称的である場合には対称であり、測度はその基本測度のうちの何らかのものが非対称である場合には非対称である。図４１は本発明のいくつかの実施形態に従う、いくつかの測度を列挙するとともにどの測度が対称的または非対称であるのかを表示する表Ｄ３０００を示す。たとえば、「費用」測度３００２は対称的であり、一方、「在庫」測度３００４は非対称である。表Ｄ３０００は測度の網羅的なリストを提示しておらず、他の測度も対称的または非対称として定義しうる。
【０２５４】
分配については、集約関数が分配的なのは、それを、当該集約関数の結果を変更することなく、複数の集約ステップに分解しうる場合である。たとえば、ＳＵＭの場合、これは分配的である。すなわち、単一の集約ステップ＝ＳＵＭ（２，８，１１）＝２１、この単一の集約ステップを２つの集約ステップに分解する。たとえば、集約ステップ１はステップ１ａ＝ＳＵＭ（２，８）とステップ１ｂ＝ＳＵＭ（１１）とを有するようにしうるから、集約ステップ２＝（ステップ１ａ，ステップ１ｂ）＝ＳＵＭ（１０，１１）＝２１となる。これは、単一のステップを分解しても結果は変わらないから、ＳＵＭは分配的である、ということを示している。集約関数は、当該集約関数の結果を変化させることなく、当該集約関数を複数の集約ステップに分解できない場合、非分配的である。たとえば、平均（ＡＶＧ）、標準偏差（ＳＴＤＤＥＶ）、および相関（ＣＯＲＲＥＬＡＴＩＯＮ）は非分配的である。たとえば、ＡＶＧの場合、単一の集約ステップ＝ＡＶＧ（２，８，１１）＝７、この単一の集約ステップを２つの集約ステップに分解する。たとえば、集約ステップ１はステップ１ａ＝ＡＶＧ（２，８）とステップ１ｂ＝ＡＶＧ（１１）とを有するようにしうるから、集約ステップ２＝（ステップ１ａ，ステップ１ｂ）＝ＡＶＧ（５，１１）＝８となる。これは、単一のステップを分解すると結果が変化するから、ＡＶＧは非分配的である、ということを示している。
【０２５５】
図４２は本発明のいくつかの実施形態に従う、いくつかの集約を列挙し、どの集約が分配的であり、どの集約が非分配的であるのかを表示する表Ｅ３１００を示す。たとえば、ＳＵＭ集約関数３１０２は分配的であり、一方、ＡＶＧ集約関数３１０４とＣＯＲＲＥＬＡＴＩＯＮ集約関数３１０６は非分配的である。表Ｅは集約関数の網羅的なリストを提示しておらず、他の集約関数を分配的、または非分配的として分類することができる。
【０２５６】
集約スクリプトの中に次元が現れる順序については、ファクト表のすべてのメンバに同一の個数の集約ステップを使用させ、かつ、各集約ステップに同一の組の次元を計算させるのが望ましい。２つの集約ステップが同一の集約関数を使用している場合、当該２つの集約ステップを組み合わせる。また、両集約関数が分配的である場合、集約ステップを少なくとも２つの集約ステップに分離することができる。図４３は本発明のいくつかの実施形態に従う、測度を列挙し、集約ステップを当該測度のための複数の集約ステップにどのようにして分解するのかを表示する表Ｆ３２００を示す。表Ｄ３２００では、アスタリスクを有する数は測度を計算する別の方法を表している。たとえば、「費用」測度３２０２の場合、第１の選択肢は製品次元、市場次元、および時次元のＳＵＭであり、一方、第２の選択肢は製品次元と市場次元の合計を始めに行い、次いで、時次元を加算することである。
【０２５７】
〔Ｂ．４ 対称的な測度の組のためのＳＱＬステートメントを生成する〕
多次元メタデータ・ソフトウェア１２０は対称的な測度ためのＳＱＬステートメントを生成する。理解を容易にするために、この節では、いくつかの対称的な測度ために生成したＳＱＬステートメントを提示する。「総計」照会または「任意スライス」照会のために生成したＳＱＬステートメントを実行した結果を、たとえば報告（report）に格納する。しかし、完全なキューブ照会のために生成したＳＱＬステートメントを実行した結果はキューブ・ビューであり、それ自体が照会される。
【０２５８】
すべての型の照会について、各測度のためのＳＱＬ式の生成は図４０に記載されているフローに従う。
【０２５９】
たとえば、対称的な測度を有する「総計」照会の場合、多次元メタデータ・ソフトウェア１２０は次の「選択（Select）」ステートメントを生成する。
select SUM(f.Cost) as Cost, SUM(f.Rev) as Revenue, SUM(f.Rev - f.Cost)as Profit,
SUM(f.Revenue - f.Cost) / SUM(f.Rev) as "Profit Margin",
RANK () OVER (ORDER BY SUM(f.Rev - f.Cost)) as "Profit Rank",
CORRELATION(f.Revenue, f.Revenue - f.Cost) as "RevProfitCorrelation" from Fact f
【０２６０】
対称的な測度を有する「任意スライス（Arbitray Slice）」照会の場合、多次元メタデータ・ソフトウェア１２０は次の「選択」ステートメントを生成する。
select SUM(f.Cost) as Cost, SUM(f.Rev) as Revenue, SUM(f.Rev - f.Cost)as Profit,
SUM(f.Revenue - f.Cost) / SUM(f.Rev) as "Profit Margin",
RANK () OVER (ORDER BY SUM(f.Rev -f.Cost)) as "ProfitRank",
CORRELATION(f.Revenue, f.Revenue - f.Cost) as "RevProfitCorrelation",m.Country, m.State, t.Year
from Fact f, Market m, Time t
where f.marketid = m.marketid AND f.timeid = t.timeid
group by m.Country, m.State, t.Year
【０２６１】
対称的な測度を有する完全なキューブ照会の場合、多次元メタデータ・ソフトウェア１２０は次の選択ステートメントを生成する。
select SUM(f.Cost) as Cost, SUM(f.Rev) as Revenue, SUM(f.Rev - f.Cost)as Profit,
SUM(f.Revenue - f.Cost) / SUM(f.Rev) as "Profit Margin",
RANK () OVER (ORDER BY SUM(f.Rev - f.Cost)) as "Profit Rank",
CORRELATION(f.Revenue, f.Revenue - f.Cost) as "RevProfitCorrelation",m.Country, m.State, m.City,
t.Year, t.Quarter, t.Month,
p.Line, p.Group, p.Product,
from Fact f, Market m, Time t, Product p
where f.marketid = m.marketid AND f.timeid = t.timeid AND f.prodid =p.prodid
group byROLLUP(m.Country, m.State, m.City),
ROLLUP(t.Year,t.Quarter, t.Month),
ROLLUP(p.Line, p.Group, p.Product)
【０２６２】
〔Ｂ．５ 非対称の測度の組のためのＳＱＬステートメントを生成する〕
多次元メタデータ・ソフトウェア１２０は非対称の測度ためのＳＱＬステートメントを生成する。理解を容易にするために、この節では、いくつかの非対称の測度ために生成したＳＱＬステートメントを提示する。「総計」照会または「任意スライス」照会のために生成したＳＱＬステートメントを実行した結果を、たとえば報告に格納する。しかし、完全なキューブ照会のために生成したＳＱＬステートメントを実行した結果はキューブ・ビューであり、それ自体が照会される。
【０２６３】
ネストされたＳＥＬＥＣＴステートメントを用いて、１組の非対称の測度を計算する。集約ステップの各々はＳＥＬＥＣＴの中のあるレベルにマップされている。ＳＥＬＥＣＴの中の最内のネスティング・レベルにある第１の集約を計算するが、これは図４０のブロック２９７０に記載されている。図４０のブロック２９７２に記載されているように、各レベルの結果を、直外のネストされたＳＥＬＥＣＴへの入力として使用する。これらのレベルの各々において、所定のレベルにおいていまだに計算されておらず、計算されそうもない次元のために、最も細分性の大きな（詳細な）次元の属性を「ＧＲＯＵＰ ＢＹ」文節に含める。このように、そのような次元のためには集約は発生しない。集約関数については、各レベルは測定の結果を入力としてとる集約関数を直内のレベルに有している。最低のレベルの場合、図４０のブロック２８７０に記載されているように、集約関数のための入力は測度の中で定義されているＳＱＬステートメントである。
【０２６４】
たとえば、非対称の測度を有する「総計」照会の場合、多次元メタデータ・ソフトウェア１２０は次の「選択」ステートメントを生成する。
select AVG(s.Inventory) as Inventory
from (select SUM(f.Inv) as Inventory, f.timeid
from Fact f
group byf.timeid) s
【０２６５】
非対称の測度を有する「任意スライス」照会の場合、多次元メタデータ・ソフトウェア１２０は次の「選択」ステートメントを生成する。
select AVG(s.Inventory) as Inventory,
s.Country, s.State, s.Year
from (select SUM(f.Inv) as Inventory,
F.timeid,
m.Country,m.State, t.Year
from Fact f, Market m, Time t
where f.marketid = m.marketid AND f.timeid = t.timeid
group by f.timeid, m.Country, m.State, t.Year) s
group by s.Country, s.State, s.Year
【０２６６】
非対称の測度を有する完全キューブ照会の場合、多次元メタデータ・ソフトウェア１２０は次の「選択」ステートメントを生成する。
select AVG(s.Inventory) as Inventory,
s.Year, s.Quarter, s.Month,
s.Country, s.State, s.City,
s.Line, s.Group, s.Product
from (select SUM(f.Inv) as Inventory, f.timeid, m.Country, m.State,m.City,
t.Year, t.Quarter, t.Month, p.Line, p.Group, p.Product
from Fact f, Market m, Time t, Product p
where f.marketid = m.marketid AND f.timeid = t.timeid AND f.prodid =p.prodid
group by f.timeid, t.Year, t.Quarter,t.Month,
ROLLUP(m.Country, m.State, m.City),
ROLLUP(p.Line, p.Group, p.Product) ) s
group by ROLLUP(s.Year, s.Quarter, s.Month),
s.Country, s.State, s.City, s.Line, s.Group, s.Product
【０２６７】
〔Ｂ．６ 互換性のない測度の組のためのＳＱＬステートメントを生成する〕
この節は複数の測度の組（たとえば対称的な測度の組と非対称の測度の組）のために生成した複数のＳＱＬステートメントをどのように組み合わせて単一のＳＱＬステートメントにするのかを記述する。
【０２６８】
表Ｆの例では、次元の組の共通の組を見いだすのは不可能である。すべての（すなわち対称的な、および非対称の）測度を計算する選択肢には２つのものがある。各選択肢は個別のＳＱＬ照会を作成し、それらを互いにマージする。たとえば、第１の選択肢は、「費用」、「売上」、「利益」、「利幅」、「利益順位」、および、すべての次元（「AllDim」）と実質的な時（AllbutTime）（「時」）の「在庫」との「売上−利益相関」をとることである。たとえば、第２の選択肢は、すべての次元（「AllDim」）と「在庫」との「売上−利益相関」、「費用」、「売上」、「利益」、「利幅」、実質的な時（AllbutTime）（「時」）の「利益順位」をとることである。
【０２６９】
対称的な測度および非対称の測度のために生成した複数のＳＱＬステートメントは、これらのＳＱＬステートメントが同一のスライスまたはキューブのために生成された場合、同一の組の属性を共用する。したがって、これらの属性のインスタンスはすべてのＳＱＬステートメントにおいて同一になる。異なる測度の組のＳＱＬステートメントを組み合わせる手法は両ＳＱＬステートメントの結果を結合することから成る。すなわち、各測度の組のために生成したＳＱＬステートメントは「ＩＮＮＥＲ ＪＯＩＮ」を用いてそれらを接続させることにより、単一のＳＱＬステートメントの中に結合する。いくつかの実施形態では、使用する結合の型はＳＱＬステートメントの「ＧＲＯＵＰ ＢＹ」文節の中で使用した属性についての「ＩＮＮＥＲ ＪＯＩＮ」である。
【０２７０】
複数のＳＱＬステートメントの間における内部結合で使用する文節は組み合わせるＳＱＬステートメントの型（すなわち、スライス基準対完全キューブ）に依存する。スライス基準のＳＱＬステートメントの場合、内部結合で使用する文節はスライスの中のすべての属性の単純なＡＮＤされた等式を使用することになる。次に示すものは多次元メタデータ・ソフトウェア１２０が第１の選択肢のために生成したスライス基準のＳＱＬステートメントである。
select r1.Inventory,r2.Cost, r2.Revenue, r2.Profit, r2.Margin, r2."Profit
Rank", r2."RevProfit Correlation",
r1.Country, r1.State, r1.Year
(select AVG(s.Inventory) as Inventory,
s.Country, s.State, s.Year
from (selectSUM(f.Inv) as Inventory,
f.timeid, m.Country, m.State, t.Year
from Fact f, Market m,Time
where f.marketid =m.marketid AND f.timeid = t.timeid
group by f.timeid, m.Country, m.State, t.Year) s
group by s.Country, s.State, s.Year) r1
INNER JOIN
(select SUM(f.Cost) as Cost,SUM(f.Rev) as Revenue, SUM(f.Rev
-f.Cost) as Profit
SUM(f.Revenue - f.Cost) / SUM(f.Rev) as Margin,
RANK () OVER (ORDER BY SUM(f.Rev - f.Cost)) as "Profit Rank",
CORRELATION(f.Revenue, f.Revenue - f.Cost) as "RevProfitCorrelation",m.Country, m.State, t.Year from Fact f, Market m, Time t
where f.marketid = m.marketidAND f.timeid = t.timeid
group by m.Country, m.State, t.Year) r2
ON r1.Country = r2.Country AND r1.State = r2.State AND r1.Year = r2.Year
【０２７１】
「総計」スライスでは、すべての次元の総計のみを返す。照会されているスライスが「総計」スライスである場合、グループ化中である属性は存在せず、したがって、結合文節の中では一時的な一定の属性を使用する。この一時的な一定の属性は「総計」列に関連付けられており、所定の属性のための集約が保持されているか否かを記述している。次に示すものは多次元メタデータ・ソフトウェア１２０が第１の選択肢のために生成した「総計」スライスのＳＱＬステートメントである。
select r1.Inventory,
r2.Cost, r2.Revenue, r2.Profit, r2.Margin, r2. "Profit Rank",r2. "RevProfit Correlation"
(select AVG(s.Inventory) as Inventory, 1 as GrandTotal
from (selectSUM(f.Inv) as Inventory, f.timeid
from Fact f
group by f.timeid) s
) r1
INNER JOIN
(select SUM(f.Cost) as Cost, SUM(f.Rev) as Revenue, SUM(f.Rev -
f.Cost) as Profit,
SUM(f.Revenue - f.Cost) / SUM(f.Rev) as "Profit Margin",
RANK () OVER (ORDER BY SUM(f.Rev - f.Cost)) as "Profit Rank",
CORRELATION(f.Revenue, f.Revenue - f.Cost) as "RevProfitCorrelation",1 as GrandTotal
from Fact f) r2
ON r1.GrandTotal = r2.GrandTotal
【０２７２】
完全キューブ型のＳＱＬステートメントの場合、結合の文節は属性のインスタンスは集約の表現も含むことになる、という事実をも考慮する。このため、組み合わせを行っている最中の基本ＳＱＬステートメントに一時的な属性を付加する。これら新たな一時的な一定の属性は所定の属性のために集約が保持されているか否かを記述している。次いで、結合の文節は属性のインスタンスを、それらが特定のメンバを含んでいる場合、あるいは集約を含んでいる場合、結合する。次に示すものはＡＧＧ（すなわち集約（aggregation)）によって接尾辞を付した一時的な一定の属性の使用方法を示す、多次元メタデータ・ソフトウェア１２０が第１の選択肢のために生成したキューブ基準のＳＱＬステートメントである。
select r1.Inventory,r2.Cost, r2.Revenue, r2.Profit, r2.Margin, r2. "Profit Rank", r2."RevProfit Correlation",
r1.Year, r1.Quarter, r1.Month, r1.Country, r1.State, r1.City,r1.Line,r1.Group, r1.Product
(select AVG(s.Inventory) as Inventory, s.Year, s.Quarter, s.Month,
s.Country, s.State, s.City, s.Line, s.Group, s.Product,
GROUPING(s.Year) as YearAgg, GROUPING(s.Quarter) as
QuarterAgg, GROUPING(s.Month) as MonthAgg,
s.CountryAgg, s.StateAgg, s.CityAgg, s.LineAgg, s.GroupAgg,
s.ProductAgg
from (selectSUM(f.Inv) as Inventory, f.timeid, t.Year, t.Quarter,
t.Month, m.Country, m.State, m.City, p.Line, p.Group, p.Product,
GROUPING(m.Country) as CountryAgg, GROUPING(m.State) as StateAgg,
GROUPING(m.City) as CityAgg,
GROUPING(p.Line) as LineAgg, GROUPING(p.Group) as GroupAgg,
GROUPING(p.Product) as ProductAgg
from Fact f, Market m,Time t, Product p
where f.marketid =m.marketid AND f.timeid = t.timeid AND
f.prodid = p.prodid
group by f.timeid, t.Year, t.Quarter, t.Month,
ROLLUP(m.Country, m.State, m.City), ROLLUP(p.Line, p.Group,
p.Product) ) s
group by ROLLUP(s.Year, s.Quarter, s.Month), s.Country, s.State,
s.City, s.Line, s.Group, s.Product,
s.CountryAgg, s.StateAgg, s.CityAgg, s.LineAgg, s.GroupAgg,
s.ProductAgg) r1
INNER JOIN
(select SUM(f.Cost) as Cost,SUM(f.Rev) as Revenue, SUM(f.Rev
-.Cost) as Profit,
SUM(f.Revenue - f.Cost) / SUM(f.Rev) as "Profit Margin",
RANK () OVER (ORDER BY SUM(f.Rev - f.Cost)) as "Profit Rank",
CORRELATION(f.Revenue, f.Revenue - f.Cost) as "RevProfitCorrelation",
m.Country,m.State, m.City, t.Year, t.Quarter, t.Month, p.Line,
p.Group, p.Product,
GROUPING(m.Country) as CountryAgg, GROUPING(m.State)
as StateAgg, GROUPING(m.City) as CityAgg,
GROUPING(t.Year) as YearAgg, GROUPING(t.Quarter) as
QuarterAgg, GROUPING(t.Month) as MonthAgg,
GROUPING(p.Line) as LineAgg, GROUPING(p.Group) as
GroupAgg, GROUPING(p.Product) as ProductAgg
from Fact f,Market m, Time t, Product p
where f.marketid =m.marketid AND f.timeid = t.timeid AND f.prodid =
p.prodid
group by ROLLUP(m.Country, m.State, m.City), ROLLUP(t.Year,
t.Quarter, t.Month), ROLLUP(p.Line, p.Group, p.Product)) r2
ON (r1.Country = r2.Country OR (r1.CountryAgg=1 AND
r2.CountryAgg=1)) AND
(r1.State = r2.State OR (r1.StateAgg=1 AND r2.StateAgg=1)) AND
(r1.City = r2.City OR (r1.CityAgg=1 AND r2.CityAgg=1)) AND
(r1.Year = r2.Year OR (r1.YearAgg=1 AND r2.YearAgg=1)) AND
(r1.Quarter = r2.Quarter OR (r1.QuarterAgg=1 AND
r2.QuarterAgg=1)) AND
(r1.Month = r2.Month OR (r1.MonthAgg=1 AND r2.MonthAgg=1)) AND
(r1.Line = r2.Line OR (r1.LineAgg=1 AND r2.LineAgg=1)) AND
(r1.Group = r2.Group OR (r1.GroupAgg=1 AND r2.GroupAgg=1)) AND
(r1.Product = r2.Product OR (r1.ProductAgg=1 AND
r2.ProductAgg=1))
【０２７３】
上の例は２つの測度の組を示しているけれども、本発明の実施形態は３個以上の測度の組を組み合わせている。さらに、ここでの例はＳＱＬステートメントに関するものであったけれども、データベースにアクセスするのに使用する単一のステートメントも本発明の範囲のの内である。
【０２７４】
いくつかの実施形態では、複数の測度の組のために生成したＳＱＬステートメントを組み合わせるのではなく、集約の組を、それらが互換性を有しうるように、再構成している。たとえば、「販売」測度と「在庫」測度の計算を組み合わせてもよい。「販売」測度はすべての次元に対するＳＵＭを使用し、「在庫」測度は実質的な時のＳＵＭを使用しているから、「販売」測度の計算は２つのステップに分解することができる。最初のステップは時以外のすべての次元のＳＵＭであり、最後のステップは時のＳＵＭである（これはＳＵＭが分配性を有するからうまくいく）。「販売」のこの計算順序は今や「在庫」のために必要とされるステップと互換性がある。
【０２７５】
ＩＢＭ（Ｒ）、ＤＢ２（Ｒ）、Ｚ／ＯＳ（Ｒ）、およびＡＩＸ（Ｒ）はインターナショナル・ビジネス・マシーンズ・コーポレーション（International Business Machines Corporation)の、合衆国もしくは他の国または双方における商標である。Ｗｉｎｄｏｗｓ（Ｒ）はマイクロソフト・コーポレーション（MicrosoftCorporation)の、合衆国もしくは他の国または双方における商標である。Ｓｏｌａｒｉｓ（Ｒ）およびＪＤＢＣ（Ｒ）はサン・マイクロシステムズ（SunMicrosystems）の、合衆国もしくは他の国または双方における商標である。Ｌｉｎｕｘ（Ｒ）はリーナス・トーヴァルズ（Linus Torvalds）の、合衆国もしくは他の国または双方における商標である。ＨＰ−ＵＸはオープン・グループ・ＵＮＩＸ ９５（OpenGroup UNIX 95）の商標の付された、合衆国もしくは他の国または双方における製品である。Ｐｉｌｏｔ Ｓｕｉｔｅ（Ｒ）はパイロット・ソフトウェア（PilotSoftware）の、合衆国もしくは他の国または双方における商標である。Ｅｘｐｒｅｓｓ（Ｒ）はオラクル・コーポレーション（Oracle Corporation）の、合衆国もしくは他の国または双方における商標である。Ｅｓｓｂａｓｅ（Ｒ）はハイパーリン・ソリューションズ・コーポレーション（HyperinSolutions Corporation)の、合衆国もしくは他の国または双方における商標である。ＴＭ１（Ｒ）はアプリックス・インク（Applix, Inc.）の、合衆国もしくは他の国または双方における商標である。
【０２７６】
〔付加的な実施形態の詳細〕
ネットワークの構成要素の上に情報を保持するための既記述の手法は、ソフトウェア、ファームウェア、または、それらの任意の組み合わせを製造するための標準のプログラミング手法もしくはエンジニアリング手法または双方を用いる方法、装置、または製品として実現することができる。ここで使用する用語「製品（article of manufacture）」はハードウェア論理（たとえば、集積回路チップ、プログラム可能なゲート・アレイ（ＰＧＡ：ProgrammableGate Array)、特定用途向け集積回路（ＡＳＩＣ：Application Specific Integrated Circuit)など）、または、磁気記憶媒体（たとえば、ハード・ディスク駆動装置、フロッピー（Ｒ）ディスク、テープなど）、光記憶装置（たとえば、ＣＤ−ＲＯＭ、光ディスクなど）、揮発性記憶装置および不揮発性記憶装置（たとえば、ＥＥＰＲＯＭ、ＲＯＭ、ＰＲＯＭ、ＲＡＭ、ＤＲＡＭ、ＳＲＡＭ、ファームウェア、プログラマブル・ロジックなど）のようなコンピュータ読み取り可能な媒体の中に実装されたコードまたは論理を指す。コンピュータ読み取り可能な媒体の中のコードはプロセッサがアクセスして実行する。その中に好適な実施形態を実装したコードは伝送媒体を通じて、または、ネットワークを介したファイル・サーバからさらにアクセスすることができる。そのような場合、その中に上記コードが実装されている製品はネットワーク伝送線、無線伝送媒体、空間の中を伝搬する信号、無線波、赤外線信号などのような伝送媒体を含む。したがって、「製品」はその中に上記コードが埋め込まれている媒体を含む。また、「製品」はその中に上記コードが埋め込まれ、処理され、そして実行されるハードウェア構成要素とソフトウェア構成要素との組み合わせを含む。無論、当業者は、本発明の範囲を逸脱することなく、この構成に多くの変更をなしうること、および、上記製品は当技術分野で知られた情報担持媒体をすべて含むことを理解しうる。
【０２７７】
図３６、図３７、図３８、図３９、および図４０の論理は特定の順序で生じる特定のオペレーションを記述している。別の実施形態では、論理オペレーションの一部を異なる順序で実行したり、変更したり、あるいは、除去したりしている。また、上述した論理にステップを付加することができ、そうしても、既述した実施形態に適合している。さらに、ここに記述したオペレーションは順次に生じる、あるいは、いくつかのオペレーションは並行して処理することができる、あるいは、単一のプロセッサによって実行されるように記述したオペレーションは分散プロセスによって実行することができる。
【０２７８】
図３６、図３７、図３８、図３９、および図４０の論理はソフトウェアで実装されているように記述した。この論理はホスト・システムのオペレーティング・システムまたはアプリケーション・プログラムの一部でありうる。さらなる実施形態では、この論理は記憶領域の中に、または、読み取り専用メモリまたは他のハードワイヤード（hardwired)型の装置の中に保持されている。好適な論理はハードウェアの中に、または、プログラム可能なゲート・アレイ・ロジックおよびプログラム可能でないゲート・アレイ・ロジックの中に実装することができる。
【０２７９】
図４４はコンピュータ・システム１００のアーキテクチャの一実現例を示す。コンピュータ・システム１００はプロセッサ３３０２（たとえばマイクロプロセッサ）、メモリ３３０４（たとえば揮発性記憶装置）、および記憶装置３３０６（たとえば、磁気ディスク駆動装置、光ディスク駆動装置、テープ駆動装置などのような不揮発性の記憶領域）を有するコンピュータ・アーキテクチャ３３００を実装している。記憶装置３３０６は内部記憶装置、または、付加された、もしくはネットワーク・アクセス可能な記憶装置を含む。記憶装置３３０６の中のプログラムはメモリ３３０４の中にロードし、当技術分野で知られた方法でプロセッサ３３０２が実行する。アーキテクチャはさらにネットワークとの通信を可能にするネットワーク・カード３３０８を備えている。入力装置３３１０はプロセッサ３３０２にユーザ入力を供給するのに使用され、キーボード、マウス、ペン・スタイラス、マイクロフォン、接触表示画面、または、当技術分野で知られた任意の他の起動（activation）機構もしくは入力機構を含む。出力装置３３１２はプロセッサ３３０２、または、ディスプレイ・モニタ、プリンタ、記憶装置などのような他の構成要素から情報を送信させることができる。
【０２８０】
本発明の好適な実施形態の上述した記述は説明と記述を目的として提示されている。網羅的であること、あるいは、本発明を開示したとおりの形態に限定することは意図されていない。上の教示に鑑みて、多くの変更と変形が可能である。
【図面の簡単な説明】
【０２８１】
【図１】ブロック図において、本発明のいくつかの実施形態によるコンピューティング環境を示す図である。
【図２】本発明のいくつかの実施形態に従い、ファクト・メタデータ・オブジェクトと測度メタデータ・オブジェクとがリレーショナル・データに関係している様子を示す図である。
【図３】本発明のいくつかの実施形態に従う星−結合型スキーマの実例を示す図である。
【図４】本発明のいくつかの実施形態に従いリレーショナル表から次元メタデータ・オブジェクトを構築する様子を示す図である。
【図５】本発明のいくつかの実施形態に従いキューブ・モデルにおいてメタデータ・オブジェクトが相互に適合しあい、リレーショナル表のリレーショナルの星型スキーマにマップされている様子を示す図である。
【図６】本発明のいくつかの実施形態に従い概念上のメタデータ・オブジェクトを３つの層に分類する様子を示す図である。
【図７】本発明のいくつかの実施形態に従い「ベース／リレーショナル」層に対応するメタデータ・オブジェクトが作成される様子を示す図である。
【図８】本発明のいくつかの実施形態に従う、「ベース／リレーショナル」層に属す付加的なメタデータ・オブジェクトを示す図である。
【図９】本発明のいくつかの実施形態に従う、星−結合型スキーマに基づいて生成された、多次元層のメタデータ・オブジェクトを示す図である。
【図１０】本発明のいくつかの実施形態に従う、キューブを定義するのに使用するメタデータ・オブジェクトのインスタンスを示す図である。
【図１１】本発明のいくつかの実施形態に従って作成された、オンライン分析処理（ＯＬＡＰ）層の中の各メタデータ・オブジェクトの１つのインスタンスを示す図である。
【図１２】本発明のいくつかの実施形態に従う、均衡型階層の一例を示す図である。
【図１３】本発明のいくつかの実施形態に従う、不均衡型階層の一例を示す図である。
【図１４】本発明のいくつかの実施形態に従う不揃型階層を示す図である。
【図１５】本発明のいくつかの実施形態に従うネットワーク型階層を示す図である。
【図１６】本発明のいくつかの実施形態に従う、いくつかのメタデータ・オブジェクトの間のいくつかの関係を示す図である。
【図１７】本発明のいくつかの実施形態に従う、２つの次元表とファクト表から成る星型スキーマを示す図である。
【図１８】本発明のいくつかの実施形態に従う、メタデータ・オブジェクト・インスタンスのありうる組と、星型スキーマのために生成されるメタデータ・オブジェクトのいくつかのプロパティとを示す図である。
【図１９】本発明のいくつかの実施形態に従う、メタデータ・オブジェクト・インスタンスのありうる組と、星型スキーマのために生成されるメタデータ・オブジェクトのいくつかのプロパティとを示す図である。
【図２０】本発明のいくつかの実施形態に従う、メタデータ・オブジェクト・インスタンスのありうる組と、星型スキーマのために生成されるメタデータ・オブジェクトのいくつかのプロパティとを示す図である。
【図２１】本発明のいくつかの実施形態に従う、メタデータ・オブジェクト・インスタンスのありうる組と、星型スキーマのために生成されるメタデータ・オブジェクトのいくつかのプロパティとを示す図である。
【図２２】本発明のいくつかの実施形態に従う、メタデータ・オブジェクト・インスタンスのありうる組と、星型スキーマのために生成されるメタデータ・オブジェクトのいくつかのプロパティとを示す図である。
【図２３】本発明のいくつかの実施形態に従う、基本データを示す表Ａを示す図である。
【図２４】本発明のいくつかの実施形態に従う、ＳＵＭ（市場）とＭＩＮ（時）なる集約を有する測度を示す表Ｂを示す図である。
【図２５】本発明のいくつかの実施形態に従う、集約、すなわちＳＵＭ（製品）(すなわち製品の合計) 」、ＡＶＧ（時）（すなわち時にわたる平均）」、およびＭＡＸ（市場）（すなわち市場の最大値) 」を有する測度を示す表Ｃを示す図である。
【図２６】本発明のいくつかの実施形態に従う、集約、すなわちＳＵＭ（製品）(すなわち製品の合計) 」、ＡＶＧ（時）（すなわち時にわたる平均）」、およびＭＡＸ（市場）（すなわち市場の最大値) 」を有する測度を示す表Ｃを示す図である。
【図２７】本発明のいくつかの実施形態に従う、集約、すなわちＳＵＭ（製品）(すなわち製品の合計) 」、ＡＶＧ（時）（すなわち時にわたる平均）」、およびＭＡＸ（市場）（すなわち市場の最大値) 」を有する測度を示す表Ｃを示す図である。
【図２８】本発明のいくつかの実施形態に従う、集約、すなわちＳＵＭ（製品）(すなわち製品の合計) 」、ＡＶＧ（時）（すなわち時にわたる平均）」、およびＭＡＸ（市場）（すなわち市場の最大値) 」を有する測度を示す表Ｃを示す図である。
【図２９】本発明のいくつかの実施形態に従う、２つの完全に付加的な測度メタデータ・オブジェクの作成を示す図である。
【図３０】本発明のいくつかの実施形態に従う半付加的な測度の作成を示す図である。
【図３１】本発明のいくつかの実施形態に従う、集約を備えた複合測度の作成を示す図である。
【図３２】本発明のいくつかの実施形態に従う、集約のない複合測度の作成を示す図である。
【図３３】本発明のいくつかの実施形態に従う、ＯＬＡＰ関数を用いた、測度の作成を示す図である。
【図３４】本発明のいくつかの実施形態に従う、集約と複数の入力とを備えた測度を示す図である。
【図３５】本発明のいくつかの実施形態に従う、図２９〜３４に由来するすべての定義済みの測度メタデータ・オブジェクトを示す図である。
【図３６】本発明のいくつかの実施形態に従い少なくとも１つの測度メタデータ・オブジェクトのためのＳＱＬステートメントを生成する論理を示す図である。
【図３７】本発明のいくつかの実施形態に従い少なくとも１つの測度メタデータ・オブジェクトのためのＳＱＬステートメントを生成する論理を示す図である。
【図３８】本発明のいくつかの実施形態に従い少なくとも１つの測度メタデータ・オブジェクトのためのＳＱＬステートメントを生成する論理を示す図である。
【図３９】本発明のいくつかの実施形態に従い少なくとも１つの測度メタデータ・オブジェクトのためのＳＱＬステートメントを生成する論理を示す図である。
【図４０】本発明のいくつかの実施形態に従い少なくとも１つの測度メタデータ・オブジェクトのためのＳＱＬステートメントを生成する論理を示す図である。
【図４１】本発明のいくつかの実施形態に従う、いくつかの測度を列挙するとともにどの測度が対称的または非対称であるのかを表示する表Ｄを示す図である。
【図４２】本発明のいくつかの実施形態に従う、いくつかの集約を列挙し、どの集約が分配的であり、どの集約が非分配的であるのかを表示する表Ｅを示す図である。
【図４３】本発明のいくつかの実施形態に従う、測度を列挙し、集約ステップを当該測度のための複数の集約ステップにどのようにして分解するのかを表示する表Ｆを示す図である。
【図４４】コンピュータ・システムのアーキテクチャの一実現例を示す図である。
【符号の説明】
【０２８２】
１００ ＯＬＡＰ多次元メタデータ・システム
１１０ リレーショナル・データベース管理システム
１２０ 多次元メタデータ・ソフトウェア
１３０ 多次元メタデータ・オブジェクト
１４０ リレーショナル・データベース
１５０ ユーザ・インターフェース
２１０ ファクト
２２０ 測度
２３０ 測度
２５０ リレーショナル表
３００ ファクト表
３１０ 次元表
３２０ 次元表
３３０ 次元表
４００ ＯＬＡＰモデル・オブジェクト
４０６ 次元
４０８ 属性
４１０ 次元
４１２ 属性
４１４ 属性
４１６ 結合
４５０ リレーショナル表
５００ ＯＬＡＰモデル・オブジェクト
５１０ キューブ・モデル
５１２ 次元
５１４ 次元
５１６ 結合
５２０ ファクト
５５０ リレーショナル表
６００ ベース／リレーショナル層
６１０ 多次元層
６２０ ＯＬＡＰ層
７００ メタデータ・オブジェクト
８００ 階層
８１０ 階層
８２０ 階層
８５０ キューブ階層
８６０ キューブ階層
８７０ キューブ階層
９００ ファクト・メタデータ・オブジェクト
９１０ 次元メタデータ・オブジェクト
９２０ 次元メタデータ・オブジェクト
９３０ 次元メタデータ・オブジェクト
１０００ メタデータ・オブジェクト
１０１０ メタデータ・オブジェクト
１０２０ メタデータ・オブジェクト
１０３０ メタデータ・オブジェクト
１１００ キューブ・モデル
１１５０ キューブ
１２００ 均衡型階層
１３００ 不均衡型階層
１４００ 不揃型階層
１５００ ネットワーク型階層
１６００ キューブ・モデル
１６１０ キューブ
１７００ ファクト表
１７１０ 次元表
１７２０ 次元表
１７３０ 線
１７４０ 線
１８００ キューブ・モデル・メタデータ・オブジェクト・インスタンス
１８０２ キューブ・メタデータ・オブジェクト・インスタンス
１８０４ ファクト・メタデータ・オブジェクト・インスタンス
１８０６ キューブ・ファクト・メタデータ・オブジェクト・インスタンス
１８０８、１８１０ 測度メタデータ・オブジェクト・インスタンス
１８１２、１８１４ 次元メタデータ・オブジェクト・インスタンス
１８１６、１８１８ キューブ次元メタデータ・オブジェクト・インスタンス
１８２０、１８２２、１８２４ 階層メタデータ・オブジェクト・インスタンス

１８２６、１８２８ キューブ階層メタデータ・オブジェクト・インスタンス
１８３０、１８３２ 結合メタデータ・オブジェクト・インスタンス
１８３４〜１８４８ 属性メタデータ・オブジェクト・インスタンス
１９００ 表Ａ
２０００ 表Ｂ
２１００ 表Ｃ
２２０２、２２０４、３３０６ 次元
２２１０、２２２０ 測度メタデータ・オブジェクト
２３１０ 測度メタデータ・オブジェクト
２４１０ 測度メタデータ・オブジェクト
２５１０ 測度メタデータ・オブジェクト
２６１０ 測度メタデータ・オブジェクト
２７１０ 測度メタデータ・オブジェクト
３０００ 表Ｄ
３１００ 表Ｅ
３２００ 表Ｆ
３３００ コンピュータ・アーキテクチャ
３３０２ プロセッサ
３３０４ メモリ
３３０６ 記憶装置
３３０８ ネットワーク・カード
３３１０ 入力装置
３３１２ 出力装置

【特許請求の範囲】
【請求項１】
多次元計算を記述する方法であって、
ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照している、ステップと、
前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している、ステップと
を含む
方法。
【請求項２】
前記ステートメントは構造化照会言語ステートメントである、
請求項１に記載の方法。
【請求項３】
前記測度メタデータ・オブジェクトの各々は少なくとも１つの構造化照会言語式を指定している、
請求項１に記載の方法。
【請求項４】
前記構造化照会言語式の各々は照会言語式を構築するためのテンプレートを含んでいる、
請求項３に記載の方法。
【請求項５】
前記テンプレートは列、属性、および測度から成るリストに由来する特定の列、属性、または測度を参照する、トークンの表記法を使用している、
請求項４に記載の方法。
【請求項６】
前記構造化照会言語式の各々は列、属性、および測度から成るリストを含んでいる、
請求項３に記載の方法。
【請求項７】
前記構造化照会言語ステートメントは前記測度メタデータ・オブジェクトの各々の中の指定済みの少なくとも１つの集約に基づいて生成する、
請求項１に記載の方法。
【請求項８】
集約の前記リストは集約関数および対応する次元の組から成るリストを含んでいる、
請求項７に記載の方法。
【請求項９】
多次元計算を記述するシステムであって、
ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照している、ステップと、
前記キューブ・モデル・メタデータ・オブジェクトおよび前記少なくとも１つの測度メタデータ・オブジェクトの中のメタデータを用いて、多次元情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している、ステップとを含む少なくとも１つのプログラムを動作させる少なくとも１つのプログラム可能な構成要素を有するコンピュータ・システムを含む
システム。
【請求項１０】
コンピュータ・システムにロードされ、その上で実行されると、前記コンピュータ・システムに請求項１〜８のうちの１項に記載の方法のすべてのステップを実行させるコンピュータ・プログラム・コードを含む
コンピュータ・プログラム。
【特許請求の範囲】
【請求項１】
対称的な測度の組または非対称の測度の組を含む多次元計算を記述する単一の構造化照会言語ステートメントを自動的に生成する、コンピュータで実現する方法であり、
対称的な測度は単一の集約演算子を有し、かつ、特定の集約順序を有さず、
非対称の測度は複数の集約演算子を有する、方法であって、
ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領するステップであって、前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照している、ステップと、
前記キューブ・モデル・メタデータ・オブジェクトの中のメタデータを用いて多次元の情報を検索するためのステートメントを生成するステップであって、前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している、ステップと、
前記少なくとも１つの測度メタデータ・オブジェクトの中で定義されている対称的な測度と非対称の測度とを分離するステップと、
前記対称的な測度のための構造化照会言語ステートメントを生成するステップと、
前記非対称の測度のための構造化照会言語ステートメントを生成するステップと、
前記対称的な測度のための前記構造化照会言語ステートメントと前記非対称の測度のための前記構造化照会言語ステートメントを組み合わせて単一の構造化照会言語ステートメントにするステップと
を含む
方法。
【請求項２】
組み合わせる前記ステップは結合の使用を含む、
請求項２に記載の方法。
【請求項３】
対称的な測度の組または非対称の測度の組を含む多次元計算を記述する単一の構造化照会言語ステートメントを自動的に生成する装置であり、対称的な測度は単一の集約演算子を有し、かつ、特定の集約順序を有さず、非対称の測度は複数の集約演算子を有する、装置であって、
ファクト・メタデータ・オブジェクトおよび少なくとも１つの次元メタデータ・オブジェクトから生成されたキューブ・モデル・メタデータ・オブジェクトのサブセットの選択を受領する手段であって、前記ファクト・メタデータ・オブジェクトは少なくとも１つの測度メタデータ・オブジェクトを参照している、手段と、
前記キューブ・モデル・メタデータ・オブジェクトの中のメタデータを用いて多次元の情報を検索するためのステートメントを生成する手段であって、前記測度メタデータ・オブジェクトの各々は少なくとも１つの集約を指定している、手段と、
前記少なくとも１つの測度メタデータ・オブジェクトの中で定義されている対称的な測度と非対称の測度とを分離する手段と、
前記対称的な測度のための構造化照会言語ステートメントを生成する手段と、
前記非対称の測度のための構造化照会言語ステートメントを生成する手段と、
前記対称的な測度のための前記構造化照会言語ステートメントと前記非対称の測度のための前記構造化照会言語ステートメントを組み合わせて単一の構造化照会言語ステートメントにする手段と
を含む
装置。
【請求項４】
コンピュータ・システムにロードされ、その上で実行されると、前記コンピュータ・システムに請求項１または２に記載の方法のすべてのステップを実行させるコンピュータ・プログラム・コードを含む
コンピュータ・プログラム。

【図１】

【図２】

【図３】

【図４】

【図５】

【図６】

【図７】

【図８】

【図９】

【図１０】

【図１１】

【図１２】

【図１３】

【図１４】

【図１５】

【図１６】

【図１７】

【図１８】

【図１９】

【図２０】

【図２１】

【図２２】

【図２３】

【図２４】

【図２５】

【図２６】

【図２７】

【図２８】

【図２９】

【図３０】

【図３１】

【図３２】

【図３３】

【図３４】

【図３５】

【図３６】

【図３７】

【図３８】

【図３９】

【図４０】

【図４１】

【図４２】

【図４３】

【図４４】

【公表番号】特表２００６−５１３４７４（Ｐ２００６−５１３４７４Ａ）
【公表日】平成１８年４月２０日（２００６．４．２０）
【国際特許分類】
【出願番号】特願２００４−５６６１５４（Ｐ２００４−５６６１５４）
【出願日】平成１５年１２月１７日（２００３．１２．１７）
【国際出願番号】ＰＣＴ／ＧＢ２００３／００５４９０
【国際公開番号】ＷＯ２００４／０６３９４２
【国際公開日】平成１６年７月２９日（２００４．７．２９）
【出願人】（３９０００９５３１）インターナショナル・ビジネス・マシーンズ・コーポレーション (4,084)
【氏名又は名称原語表記】ＩＮＴＥＲＮＡＴＩＯＮＡＬ　ＢＵＳＩＮＥＳＳ　ＭＡＳＣＨＩＮＥＳ　ＣＯＲＰＯＲＡＴＩＯＮ
【Ｆターム（参考）】