JP2007517314A - ディスティンクトカウントメトリック（ｄｉｓｔｉｎｃｔｃｏｕｎｔｍｅｔｒｉｃｓ）のための集約ナビゲーションの最適化 - Google Patents

Abstract

集約ナビゲーションの利用によりディスティンクトカウントメトリックを行なうためのファシリティが与えられる（２００）。クエリが０以上の限定を特定する場合、詳細テーブルの識別子のディスティンクトカウントクエリについて、ファシリティは詳細テーブル（２０６）に関連付けられた集約テーブルを特定する。その後、ファシリティは、ディスティンクトカウントされている識別子を集約テーブルが含むか否かを判断し、含んでいる場合、識別子が集約テーブル（２１４）のすべての行の中で異なるか否かを判断する。異なる場合、ファシリティは、ディスティンクトカウントクエリについて結果を得るために、指定された限定を満たす集約テーブルの行でカウント動作を行なう。識別子が集約テーブルのすべての行の中で異なるのではない場合、ファシリティは、ディスティンクトカウントクエリについて結果を得るために、指定された限定を満たす集約テーブルの行でディスティンクトカウント動作を行なう。

Description

関連出願
本出願は、米国特許法第１１９条（ｅ）に従い、２００３年１２月２３日に出願された米国仮特許出願番号第６０／５３１，８４０号、および２００４年１１月１１日に出願された米国特許出願番号第１０／９９４，９０５号の優先権の利益を主張し、各々の全体が引用によって本願明細書に援用される。

技術分野
記載された技術は一般にデータベースクエリに向けられ、より特定的にはディスティンクトカウントメトリックの効率的な実行に向けられる。

背景
データベースはデータの集合体である。典型的にはユーザはデータベース管理システム（ＤＢＭＳ）などのコンピュータプログラムを用いて、データベースにデータを格納し、検索し、修正する。

ＤＢＭＳの１つの種類には、テーブルに情報を格納するリレーショナルデータベース管理システムがある。テーブルとは一連の交差する行および列である。テーブルの行は典型的には特定の項目に関する情報の集合体であるレコードを表わし、列は典型的にはレコードの特定の属性を特定するフィールド、例えばレコードの各フィールドに含まれる特定の種類のデータを表わす。各フィールドは交差する行と列に対する特定の属性を有するデータを含む。

リレーショナルデータベースのテーブルに格納されたデータは、一般にクエリおよび解析ツールを用いてアクセスされ検索される。例えば、ユーザは、テーブル、行、および個々のデータ要素上で、ツールを用いて特定の動作を行なうことができる。１つの種類の動作として集約動作があり、そのような集約関数の１つはディスティンクトカウント（distinct count）と呼ばれる。

ディスティンクトカウントは非常に重要で一般的な分析的要件である。列に分割される行から構成される詳細テーブルについて、ディスティンクトカウントは、他の列において０以上の条件を満たす行の第１の列に現われる一意の値の個数を表示する。例えば、ある顧客が注文した各品目ごとに１行を含み、その行がｃｕｓｔｏｍｅｒ ＩＤ（顧客ＩＤ）列、ｉｔｅｍ ＩＤ（品目ＩＤ）列、ｏｒｄｅｒ ｄａｔｅ ＩＤ（注文日ＩＤ）列およびｃｕｓｔｏｍｅｒ ｚｉｐ ＩＤ（顧客郵便番号ＩＤ）列に分割されているＯｒｄｅｒｅｄ Ｉｔｅｍｓ（注文品目）詳細テーブルについて、ユーザは、郵便番号９８２１０を含む行に含まれる、異なるユーザＩＤの個数をカウントすることを望むかもしれない。

ディスティンクトカウントメトリックを行なう従来の公知の方法では、ディスティンクトカウントを行なうために集約ナビゲーションを用いることができない。逆にこれらの従来の方法では常に最も詳細なソースからディスティンクトカウントメトリックを得るので、結果として重大な性能上の障害を生じる。性能上の大きな問題が生じるのは、通常、分析的な環境でディスティンクトカウントメトリックを行なうために従来の方法を用いる場
合である。なぜなら、ディスティンクトカウントのこれらの従来の方法は、まさにその性質のために、他の集約関数よりも桁違いに遅いからである。この問題は、レポートに１つ以上のディスティンクトカウントメジャーがある場合に増大する。

したがって、ディスティンクトカウントメトリックを実行するための集約ナビゲーションを利用する手法は著しく有用であろう。

詳細な説明
ディスティンクトカウントメトリックを実行するための集約ナビゲーションを利用するソフトウェアファシリティ（「ファシリティ」）が説明される。いくつかの実施例では、ファシリティは、集約テーブル（aggregate table）上でカウント動作を行なうことによりディスティンクトカウントメトリックを計算する。いくつかの実施例では、ファシリティは、従来のディスティンクトカウント動作を行うために典型的に利用される詳細テーブルよりも小さいテーブル上でディスティンクトカウント動作を行なうことにより、ディスティンクトカウントメトリックを計算する。この態様でほとんどのクエリについてディスティンクトカウントをすべてなくすことによって、または他のいくつかの場合には、より小さいテーブル上でディスティンクトカウントを行うことによって同じ回答−すなわちディスティンクトカウントメトリック−を出すことで、ファシリティは、詳細なテーブル上で行なわれる従来のディスティンクトカウントと比較した場合、クエリ時間の著しいスピードアップ−例えば増進−をもたらす。

明細書全体にわたって以下の用語は一般に以下の意味を有する。
用語「集約テーブル」は、他のデータベーステーブルからの詳細レベルレコードを要約するかまたは統合するテーブルを指す。

用語「ベーステーブル」「詳細テーブル」または「ファクトテーブル」は、詳細データを含むデータベーステーブルを指す。

用語「カウント」は、選択された列における行数のカウントを指す。
用語「キューブ」は、ディメンションおよびメジャーを含むマルチディメンション構造を指す。ディメンションはキューブ構造を規定する。メジャーは関心の数値を与える。

用語「ディメンション」はキューブの構造属性を指し、ファクトテーブルのデータを記述する、体系づけられたカテゴリの階層（レベル）である。これらのカテゴリは、典型的には、分析が行なわれる類似のメンバ集合を記述する。ディメンションは集約することができるフィールド（列）である。例えば時間ディメンションは、年、月および日のレベルを含み得る。

用語「ディメンション階層」は、あるディメンションにおけるメンバ集合およびメンバ同士の相対的位置を指す。

用語「ディスティンクトカウント（distinct count）」または「カウントディスティンクト（count distinct）」は、選択された列における一意の行個数のカウントを指す。これは、選択された列における、重複分をカウントしない行数カウントを指す。

用語「細分性（granularity）」または「粒度（grain）」は、データ要素に含まれる情報の特定性の程度を指す。

用語「階層」は、各メンバが１つの親および０以上の子供メンバを有するようにディメ
ンションのメンバを体系づける、論理的ツリー構造を指す。

用語「レベル」または「カテゴリ」は、ディメンション階層におけるある集合の名称を指し、その全メンバは階層の根から同じ距離にある。例えば時間ディメンションは、年、月および日のレベルを含み得る。

用語「メジャー」は、あるキューブにおいて、そのキューブのファクトテーブルのある列に基づく値の集合を指す。メジャーは、集約され分析される主要値である。

用語「メンバ」はディメンションの項目を指し、１つ以上のデータ発生を表わす。メンバは一意でも、一意でなくてもよい。例えば、２００３および２００４は、時間ディメンションの年レベルにおいて一意のメンバを示す。対照的に１０月は、時間ディメンションの月レベルで一意でないメンバを示す。なぜなら、時間ディメンションに１年分以上のデータを含む場合、時間ディメンションに１つ以上の１０月があり得るからである。

用語「クエリ」は、ユーザが有用なフォーマットで情報を得るためにデータベースに「尋ねる」質問を指す。

用語「限定」は、列に課された条件または基準を指す。例えばある限定は、一般に、特定の基準に一致する列に対する値を備えた行のみにクエリを限定するためのやり方を指す。

用語「テーブル」は、リレーショナルデータベースにデータを格納するために用いられる、行および列を含む、二次元のオブジェクトを指す。テーブルは行と列とに体系づけられた情報の表示である。

いくつかの実施例では、ファシリティは、（１）集約−すなわちディスティンクトカウントされているある識別子−すなわちメジャー−を含む集約テーブルが存在する場合、または、（２）集約テーブルの行が識別子自体の代わりにディスティンクトカウントされている識別子のカウントを含む場合に、詳細テーブルの代わりに集約テーブルを利用してディスティンクトカウントメトリックに答える。

集約されている識別子を含む集約テーブルが存在する場合（ケース１）。
ａ：ディスティンクトカウントされている識別子が集約テーブルにおいて一意の場合−すなわちディスティンクトカウントされている識別子が集約テーブルのすべての行において異なることが確実である場合は、ファシリティは、はるかに遅いディスティンクトカウント演算子の代わりにカウント演算子を集約テーブルに適用する。この例では、詳細についてＣＯＵＮＴ ＤＩＳＴＩＮＣＴが要求されるマスタ／詳細の関係に対するマスタ集約テーブルであってマスタではない。一例としてＯｒｄｅｒ／ＯｒｄｅｒＤｅｔａｉｌｓ（注文／注文詳細）があり、製品ごとの一意の注文数は、ＯｒｄｅｒＤｅｔａｉｌｓ（注文詳細）を介してＰｒｏｄｕｃｔ（製品）に合わさるので、ディスティンクトカウント（すなわちＯｒｄｅｒＤｅｔａｉｌｓ（注文詳細）テーブルのＣＯＵＮＴ ＤＩＳＴＩＮＣＴ）でなければならない。対照的に、１ディメンションおきに集約すると、はるかに速いカウント動作（すなわちＯｒｄｅｒ（注文）ヘッダテーブルのＣＯＵＮＴ）のみを要する。

ｂ：ディスティンクトカウントされている識別子が集約テーブルにおいて一意でない場合、ファシリティは、ディスティンクトカウント演算子を集約テーブルに適用する。この例では、集約テーブルの一部としてディスティンクトカウントキーが格納される。例えば、ユーザが、過去数か月間にある特定の製品を買った一意の顧客数について関心を持っていると仮定する。ＣｕｓｔｏｍｅｒＩＤ（顧客ＩＤ）、ＰｒｏｄｕｃｔＩＤ（製品ＩＤ）
、およびＭｏｎｔｈＩＤ（月ＩＤ）ディメンションを有する集約テーブルを用いて、［Ｐｒｏｄｕｃｔ（製品），Ｍｏｎｔｈ（月）］の粒度またはそれ以上の粒度での集約をサポートするようにＣｕｓｔｏｍｅｒＩＤにわたってＣＯＵＮＴ ＤＩＳＴＩＮＣＴを実行することにより、過去数か月間にある特定の製品を買った一意の顧客数を決定することができる。当業者であれば、これがＯｒｄｅｒ／ＯｒｄｅｒＩｔｅｍ（注文／注文品目）ベースまたはファクトテーブルを用いたディスティンクトカウントの実行と対比して桁違いにはるかに速い実行をもたらすようなシナリオを想定できることが認識される。

集約テーブルが存在するが、集約テーブルの行が識別子自体の代わりにディスカウントされている（discounted）識別子のカウントを含む場合（ケース２）。

ａ：集約テーブルが、カウントされた識別子に従属するディメンションのみを伴うディメンション数を有する場合、ファシリティは集約テーブルの適切な行からのカウントを合計して、正確なディスティンクトカウントを得る。この例では、ＣＯＵＮＴ ＤＩＳＴＩＮＣＴは集約テーブルに格納され、集約テーブルの粒度またはそれ以上の粒度のいかなるクエリも、あらかじめ計算されたＣＯＵＮＴ ＤＩＳＴＩＮＣＴ数において合計することによって、集約体を利用することができる。これが有用である１つの例は、一意の注文数をカウントする場合である。Ｔｉｍｅ（時間）、Ｃｕｓｔｏｍｅｒ（顧客）、Ｐｒｏｄｕｃｔ（製品）、Ｃｈａｎｎｅｌ（チャネル）のディメンションを備えたサブジェクトエリアを仮定する。図表の意味するところにより、製品以外のすべてのディメンションにおいて＃ ｏｆ Ｏｒｄｅｒｓ（注文数）メジャーを合計することができる。（すなわち、所与の注文に複数の製品が関連付けられ得る一方で、その注文はある１日に、一人の顧客について、単一のチャネルを通してなされている）。このシナリオの下では、ＡｌｌＰｒｏｄｕｃｔ（すべての製品）の粒度において、かつ例えばＭｏｎｔｈ、ＣｕｓｔｏｍｅｒＺｉｐ、Ｃｈａｎｎｅｌなど他のディメンションの任意の粒度にわたって、集約テーブルを作成することができる。集約テーブルの粒度またはそれ以上の粒度のいかなるクエリもここではこの集約テーブルをヒットし、あらかじめ計算されたディスティンクトカウントにおいて合計する。例えば、直近の四半期についてウェブチャネルによってなされた個別注文数を示すクエリは、この集約テーブルをヒットする。

ｂ：集約テーブルが、ディスティンクトカウントされている識別子に従属するいくつかのディメンションと、ディスティンクトカウントされている識別子から独立したいくつかのディメンションとを有する場合、独立レベルについての集約体のレベルとクエリとがレベルで一致する限り、ファシリティは、正確なディスティンクトカウントを得るためにカウントを合計する。その１つの例は、クエリが顧客のディスティンクトカウントに対するクエリであり、集約テーブルが製品および（顧客の主たる住所の）郵便番号ごとの顧客カウントを有する場合である。この場合、ある州の郵便番号について顧客を加算することによって、その州の顧客数のディスティンクトカウントを得ることができる（なぜなら顧客が２つの州で同時に主たる住所を有することはあり得ないからである）。しかしながら、ブランドの顧客数のディスティンクトカウントは、製品について加算することによっては得ることができない（なぜなら顧客はあるブランドで２つ以上の製品を買うかもしれないからである）。

ｃ：集約テーブルのすべてのディメンションがディスティンクトカウントされている識別子から独立である場合、ファシリティは、クエリのレベルがテーブルのレベルと正確に一致する場合にのみ集約体を用いる。この例では、ＣＯＵＮＴ ＤＩＳＴＩＮＣＴは集約テーブルの一部として格納されるが、レベル／粒度の正確な一致しかサポートしない。例えば、ＰｒｏｄｕｃｔＩＤ、ＭｏｎｔｈＩＤ、およびＮＵＭ＿ＣＵＳＴＯＭＥＲＳ（顧客数）のディメンションを有する集約テーブルは、［Ｐｒｏｄｕｃｔ，Ｍｏｎｔｈ］の粒度のクエリにのみ用いることができるが、［Ｐｒｏｄｕｃｔ，Ｑｕａｒｔｅｒ（四半期）］
の粒度のクエリには用いることができない。換言すると、後者のクエリは集約テーブルを欠く。

１つの実施例では、前述の機能は、メジャー（ＡＭｅａｓｕｒｅＤｅｆｎ）と論理テーブルソース（ＡＬｏｇｉｃａｌＴａｂｌｅＳｏｕｒｃｅ）との間のリレーションシップオブジェクトである新しいメタデータオブジェクト（ＡＯｖｅｒｒｉｄｅＡｇｇｒＲｕｌｅ）にサポートされる。換言すると、ファシリティは、所与の論理テーブルソース（ＬＴＳ）についてオーバーライド（ｏｖｅｒｒｉｄｅ）集約表現を指定することができる。ファシリティがオーバーライドを指定しない場合、現在（すなわち従来のディスティンクトカウント）の行動が優先する。ファシリティがＬＴＳについてオーバーライドを指定する場合は、その集約ルールが適用される。

例えば、上記のケース１．ｂについてのＬＴＳオーバーライド表現は、ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ”＃ ｏｆ Ｃｕｓｔｏｍｅｒｓ（顧客数）”）である。上記のケース１．ａについてのＬＴＳオーバーライドは、ＣＯＵＮＴ（”＃ ｏｆ Ｏｒｄｅｒｓ（注文数）”）である。上記のケース２．ａのためのＬＴＳオーバーライドは、ＳＵＭ（” ＃ ｏｆ
Ｏｒｄｅｒｓ（注文数）”）である。

ファシリティの様々な実施例とその利点とは、図面の図１−図１１を参照して最もよく理解される。図面の要素は必ずしも縮尺どおりではなく、その代り発明の原理を明らかに図示するために強調されている。図面の全体にわたって、様々な図面の同じまたは対応する部分には同じ番号が用いられている。

図１は、ファシリティがその上で実行するコンピュータシステムのうちの少なくともいくつかに典型的に組み込まれる、選択されたコンポーネントを示すブロック図である。これらのコンピュータシステム１００は、コンピュータプログラムの実行のための１つ以上の中央処理装置（「ＣＰＵ」）１０２、プログラムおよびデータ−データ構造を含む−が使用されている間それらを格納するためのコンピュータメモリ１０４、プログラムおよびデータを恒久的に格納するためのデータハードドライブなどの恒久的な記憶装置１０６、コンピュータ可読媒体に格納されたプログラムおよびデータを読み取るためのＣＤ−ＲＯＭドライブなどのコンピュータ可読媒体ドライブ１０８、ならびに、プログラムおよび／またはデータ構造を含むデータを交換するためにインターネットなどを通してコンピュータシステムを他のコンピュータシステムに接続するためのネットワーク接続１１０を含み得る。

ファシリティは、プログラムモジュールなど、コンピュータシステム１００または他の装置によって実行されるコンピュータ可読命令の一般的コンテキストにおいて記述され得る。一般にプログラムモジュールは、特定のタスクを実行し、または特定の抽象的データタイプを実現する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。メモリ１０４および恒久的な記憶装置１０６は、ファシリティを実現する命令を含み得るコンピュータ可読媒体である。メモリ１０４および恒久的な記憶装置１０６は、ファシリティを実現する命令に加えて様々な他のコンテンツを有してもよいことが認識される。

コンピュータシステム１００が、プログラム出力を表示するためのビデオモニタまたはＬＣＤパネルなどの１つ以上の表示装置、および、キーボード、マイクロホン、またはマウスなどのポインティングデバイスといった、ユーザ入力を受取るための１つ以上の入力装置を含んでもよいことが認識される。ファシリティの動作をサポートするために、典型的には上述のように構成されたコンピュータシステム１００が用いられるが、ファシリティは様々な種類および構成の装置を用いて実現され、様々なコンポーネントを有し得るこ
とが認識される。

下記の説明では、ファシリティの実施例が様々な明示的例と共に記載される。ファシリティの実施例は、多くの点においてこれらの例から著しく発展した状況で用いられ得ることが認識される。

図２Ａから図２Ｃは、いくつかの実施例による、ファシリティがディスティンクトカウントメトリックを実行する方法２００のフローチャートを示す。ステップ２０２で、ファシリティは、ある詳細テーブルの識別子のディスティンクトカウントを要求するクエリを受取る。クエリは１つ以上の限定を含んでもよい。ステップ２０４で、ファシリティは、詳細テーブルに対応する集約テーブルを特定する。ステップ２０６で、ファシリティは、ディスティンクトカウントされている識別子を含む集約テーブルがあるか否かを判断するために、特定した集約テーブルをチェックする。

ディスティンクトカウントされている識別子を含む集約テーブルがある場合、次に、ステップ２０８で、ファシリティは、ディスティンクトカウントされている識別子が集約テーブルのすべての行において異なるか否かを判断するために、集約テーブルの各行をチェックする。ディスティンクトカウントされている識別子が集約テーブルのすべての行において異なる場合、次にファシリティは、ステップ２１０で、集約テーブルの指定されたクエリ限定を満たす行についてカウント動作を行ない、要求されたディスティンクトカウントメトリックを導き出す。ここで、ファシリティは、ディスティンクトカウントメトリックを導き出すために集約ナビゲーションを利用することによって、性能増進をもたらす。換言すると、ファシリティは、より小さな集約テーブルでより速いカウント動作を行なうことによって性能増進をもたらす。

そうではなく、ディスティンクトカウントされている識別子が集約テーブルのすべての行において異なるわけではない場合、次にファシリティは、ステップ２１２で、集約テーブルの指定されたクエリ限定を満たす行についてディスティンクトカウント動作を行ない、要求されたディスティンクトカウントメトリックを導き出す。ここで、ファシリティは、ディスティンクトカウントメトリックを導き出すために集約ナビゲーションを利用することによって、なおも性能増進をもたらす。換言すると、ファシリティは、より小さな集約テーブルでディスティンクトカウント動作を行なうことにより、性能増進をもたらす。

ステップ２０６で、ファシリティが、ディスティンクトカウントされている識別子のカウントを含む集約テーブルがないと判断した場合、次にファシリティは、ステップ２１４で、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むような集約テーブルがあるか否かを判断するためにチェックする。各カウントは、ディスティンクトカウントされている識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示する。各ディメンション値はそのディメンションの特定のレベルにある。ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むような集約テーブルがある場合、ファシリティは次に、ステップ２１６で、処理すべき指定されたクエリ限定があるか否かを判断する。処理すべき指定された限定がある場合、ファシリティは次に、ステップ２１８で、現在処理されている指定された限定が、集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定であるか否かを判断するためにチェックする。

現在処理されている指定された限定が、集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定である場合、ファシリティはステップ２１６に戻り、処理すべき別のクエリ限定を処理する。そうではなく、現在処理されている指定された限定が、集約テーブルのディメンション値と同じまたはより高いレベルの従属ディ
メンションについての限定ではない場合、ファシリティは次に、ステップ２２０で、現在処理されている指定された限定が、集約テーブルのディメンション値と同じレベルの独立ディメンションの限定であるか否かを判断するために、チェックする。

現在処理されている指定された限定が、集約テーブルのディメンション値と同じレベルの独立ディメンションの限定である場合、ファシリティはステップ２１６に戻り、処理すべき別のクエリ限定を処理する。そうではなく、現在処理されている指定された限定が、集約テーブルのディメンション値と同じレベルではない独立ディメンションの限定である場合、ファシリティは次に、ステップ２２２で、詳細テーブルの指定されたクエリ限定を満たす行についてディスティンクトカウント動作を行ない、要求されたディスティンクトカウントメトリックを導き出す。この例では、ファシリティがディスティンクトカウントメトリックを導き出すために集約ナビゲーションを利用することができないので、性能増進はない。

ステップ２１６で、ファシリティが、もはや処理すべき指定されたクエリ限定はないと判断した場合、ファシリティは次に、ステップ２２４で、集約テーブルのディメンション値が指定されたクエリ限定をすべて満たすような集約テーブルの行に含まれるカウントを合計し、要求されたディスティンクトカウントメトリックを導き出す。換言すると、集約テーブルの独立ディメンションのレベルとクエリ限定とがレベルで一致する限り、カウントは合計されて正確なディスティンクトカウント回答を与える。ここで、ファシリティは、クエリに含まれる各限定をチェックし、限定の各々が、集約テーブルのディメンション値と同じレベまたはより高いレベルの従属ディメンションの限定か、または集約テーブルのディメンション値と同じレベルの独立ディメンションの限定のいずれかであると判断した。ファシリティは次に、集約テーブルのディメンション値と同じ（すなわち正確な）レベルまたはより高いレベルの従属ディメンション、および集約テーブルのディメンション値と同じレベルの独立ディメンションにわたって加算することができる。

ここでファシリティは以下のいずれかを決定した。（１）ディスティンクトカウントされている識別子に従属するディメンションのみを集約テーブルが含んでおり（ステップ２１８）、集約テーブルの適切な行−すなわち集約テーブルのディメンション値が指定されたクエリ限定をすべて満たすような集約テーブルの行−からのカウントが合計されて（ステップ２２４）正確なディスティンクトカウントを得ることができる。（２）集約テーブルが、ディスティンクトカウントされている識別子に従属するいくつかのディメンションとディスティンクトカウントされている識別子から独立したいくつかのディメンションとを含んでおり（ステップ２１８およびステップ２２０）、集約テーブルの適切な行−すなわち集約テーブルのディメンション値が指定されたクエリ限定をすべて満たすような集約テーブルの行−からのカウントが合計されて（ステップ２２４）正確なディスティンクトカウントを得ることができる。または、集約テーブルのすべてのディメンションがディスティンクトカウントされている識別子から独立しており（ステップ２２０）、そのため集約体は、クエリのレベルがテーブルのレベルと正確に一致する場合のみにしか用いられ得ない。したがってファシリティは、ディスティンクトカウントメトリックを導き出すために集約ナビゲーションを利用することによって性能増進をもたらす。換言すると、ファシリティは、より小さな集約テーブルの適切な行についてより速い合計動作を行なうことによって性能増進をもたらす。

ステップ２１４で、ファシリティが、ディスティンクトカウントされている識別子のカウントを含む行を有する集約テーブルがないと判断した場合、ファシリティは、ステップ２２６で、指定されたクエリ限定を満たす詳細テーブルの行についてディスティンクトカウント動作を行ない、要求されたディスティンクトカウントメトリックを導き出す。この例では、ファシリティは、ディスティンクトカウントメトリックを導き出すために集約ナ
ビゲーションを利用することができないので、性能増進はない。

当業者は、本願明細書に開示されたこの、および他のプロセスならびに方法について、そのプロセスおよび方法で行なわれた関数が異なる順序で実現され得ることを認識する。さらに、概説されたステップは単に例示的であり、ステップのうちいくつかは任意であってもよく、より少ない数のステップと組み合わせてもよく、または本発明の本質を低下させることなく追加的ステップへと拡張されてもよい。

方法２００のさまざまな局面が、以下の例と共にさらに図示される。以下の例が図示する目的で与えられ、いかなる態様においても徹底的または完全であると考えられてはならないことが認識される。この例は、図３に示される詳細テーブル３０を含むデータベース、および図４Ａから図４Ｃで示される詳細テーブル３０に対応するディメンションテーブルを仮定する。ディメンションテーブルの各々は、テーブル３０のレコードを記述する属性を含む。

図示されるように、Ｄｅｔａｉｌ Ｔａｂｌｅ（詳細テーブル）３０は、顧客が出した１０個の注文レコードを含む。各レコードは、「Ｏｒｄｅｒ Ｎｕｍｂｅｒ（注文番号）」、「Ｐｒｏｄｕｃｔ（製品）」、「Ｃｕｓｔｏｍｅｒ（顧客）」、「Ｏｒｄｅｒ Ｄａｔｅ（注文日）」、および「Ｄｅｌｉｖｅｒ ｔｏ Ｚｉｐ（配達先郵便番号）」とラベル付けされた、５つの列またはディメンションを有するように示される。第２のディメンションの値が第１のディメンションにおいて１つの値のみを有するかまたは１つの値とのみ関連付けられる場合、第１のディメンションは第２のディメンションに「従属」する。そうではなく、第２のディメンションの値が第１のディメンションにおいて複数の値を有するかまたは複数の値と関連付けられる場合、第２のディメンションから「独立」である。テーブル３０において、各注文は一人の顧客とのみ関連付けられるかまたは一人の顧客によって出されるので、「Ｃｕｓｔｏｍｅｒ」は「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」に従属する。同様に、各注文はある一日とのみ関連付けられるかまたはある一日に出されるので、「Ｏｒｄｅｒ Ｄａｔｅ」は「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」に従属する。対照的に、各注文は複数の製品について出され得るので、「Ｐｒｏｄｕｃｔ」は「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」から独立である。同様に、例えばいくつかの製品は第１の郵便番号に配達され、残りの製品は第２の異なる郵便番号に配達される場合など、複数の製品について１つの注文があり得、ある注文における製品が複数の郵便番号に配達され得るので、「Ｄｅｌｉｖｅｒ ｔｏ Ｚｉｐ」は「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」から独立である。

ディメンションテーブル（Ｄｉｍｅｎｓｉｏｎ Ｔａｂｌｅ）１（図４Ａ）はテーブル３０の「Ｐｒｏｄｕｃｔ」ディメンションに関する情報を含んでおり、製品をブランドにさらに分ける階層を図示する。ディメンションテーブル（Ｄｉｍｅｎｓｉｏｎ Ｔａｂｌｅ）２（図４Ｂ）はテーブル３０の「Ｄｅｌｉｖｅｒ ｔｏ Ｚｉｐ」ディメンションに関する情報を含んでおり、郵便番号を対応する州にさらに分ける階層を図示する。Ｄｉｍｅｎｓｉｏｎ Ｔａｂｌｅ３（図４Ｃ）はテーブル３０の「Ｏｒｄｅｒ Ｄａｔｅ」ディメンションに関する情報を含んでおり、注文日の月を対応する年にさらに分ける階層を図示する。

例１：ディスティンクトカウントされている識別子が集約テーブルに存在し、一意である場合−カウント動作が用いられる。

例として、ユーザは、詳細テーブル３０に記録されたような、各顧客が出した一意の注文数のディスティンクトカウントを得ることに関心を持っているかもしれない。ここでファシリティは、ユーザから「Ｒｅｑｕｅｓｔ：ｃｕｓｔｏｍｅｒ，＃ of ｏｒｄｅｒｓ（顧客，注文数），」というストリングを受取ってもよく（ステップ２０２）、ファシリ
ティは、各顧客が行った一意の注文数に対するディスティンクトカウントクエリとしてストリングを理解する。ファシリティは「ｃｕｓｔｏｍｅｒ」がディスティンクトカウントクエリの限定であると判断する。ファシリティはさらに、詳細テーブル３０の識別子「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」のディスティンクトカウントを行なうことにより、一意の注文数に対するディスティンクトカウントクエリを得ることができると判断する。

図５に示されるように、ファシリティが、Ａｇｇ＿Ｔａｂｌｅ＿１（集約テーブル１）を、テーブル３０に関連付けられる集約テーブルとして特定し（ステップ２０４）、かつ例えばクエリに答えるために必要な識別子「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」を含むディスティンクトカウントされている識別子の集約体と仮定すると（ステップ２０６）、ファシリティはＡｇｇ＿Ｔａｂｌｅ＿１をチェックして、Ａｇｇ＿Ｔａｂｌｅ＿１のすべての行において識別子「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」が異なるか否かを確認する（ステップ２０８）。示されるように、Ａｇｇ＿Ｔａｂｌｅ＿１は、注文番号を特定する第１の列、顧客を特定する第２の列、および日付を表示する第３の列の３つの列を含む。識別子「Ｏｒｄｅｒ Ｎｕｍｂｅｒ」がＡｇｇ＿Ｔａｂｌｅ＿１のすべての行で異なることを確認すると、ファシリティは、限定−すなわち顧客−を満たすＡｇｇ＿Ｔａｂｌｅ＿１の行をカウントすることによりディスティンクトカウントクエリに回答できると結論付ける（ステップ２１０）。

ファシリティが構造化照会言語（ＳＱＬ）プロセッサの機能および特徴を組み込んでいるか、またはＳＱＬプロセッサに結合されていると仮定すると、ファシリティは、受取ったストリングを下記のＳＱＬ表現に変換することができ、各顧客が出した一意の注文数について要求されたディスティンクトカウントを決定する：
ＳＥＬＥＣＴ ｃｕｓｔｏｍｅｒ
ＣＯＵＮＴ（ｏｒｄｅｒ ｎｕｍｂｅｒ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿１
ＧＲＯＵＰ ＢＹ ｃｕｓｔｏｍｅｒ
１つの実施例において、ファシリティのＳＱＬプロセッサコンポーネントは上記のＳＱＬ表現を処理し、図６に示されるように、各顧客が出した一意の注文数のディスティンクトカウントを含むＤｉｓｔｉｎｃｔ＿Ｃｏｕｎｔ＿Ｔａｂｌｅ＿１（ディスティンクトカウントテーブル１）を生成する。示されるように、Ｄｉｓｔｉｎｃｔ＿Ｃｏｕｎｔ＿Ｔａｂｌｅ＿１は２つの列を含み、一方の列は各顧客を特定し、他方の列は出された注文数のディスティンクトカウントを含む。Ｄｉｓｔｉｎｃｔ＿Ｃｏｕｎｔ＿Ｔａｂｌｅ＿１に見られるように、顧客１は２つの注文を出し、顧客２も２つの注文を出している。

ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿１のカウント演算子を適用することによって他のディスティンクトカウントクエリに回答することができる。例えばユーザは、詳細テーブル３０に記録されるような各年に出された一意の注文数のディスティンクトカウントを要求し、ファシリティに「Ｒｅｑｕｅｓｔ：ｙｅａｒ，＃ ｏｆ ｏｒｄｅｒｓ（年，注文数）」というストリングを提出していてもよい。ファシリティは、受取ったストリングが各年に出された一意の注文数に対するディスティンクトカウントクエリであると解釈し、ディスティンクトカウントされている識別子が「ｏｒｄｅｒ ｎｕｍｂｅｒ」であって、ディスティンクトカウントクエリの限定が「ｙｅａｒ」であると判断する。

識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」がＡｇｇ＿Ｔａｂｌｅ＿１のすべての行で異なることを確認すると、ファシリティは、限定−すなわち年−を満たすＡｇｇ＿Ｔａｂｌｅ＿１の行をカウントすることによってディスティンクトカウントクエリに回答できると結論付ける。したがってファシリティは、受取ったストリングを下記のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｙｅａｒ
ＣＯＵＮＴ（ｏｒｄｅｒ ｎｕｍｂｅｒ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿１
ＧＲＯＵＰ ＢＹ ｙｅａｒ
上記のＳＱＬ表現が処理されると、２００３年に３つの注文が出され、２００４年に１つの注文が出されたことが確認される。

同様の態様で、詳細テーブル３０に記録されるような２００３年１月に各顧客が出した一意の注文数のディスティンクトカウントは、Ａｇｇ＿Ｔａｂｌｅ＿１でカウント動作を行なうことにより得ることができる。このディスティンクトカウントリクエストは、「Ｒｅｑｕｅｓｔ：ｃｕｓｔｏｍｅｒ，＃ ｏｆ ｏｒｄｅｒｓ，ｄａｔｅ＝Ｊａｎ ２００３」というストリングによって表わすことができる。ファシリティは、ディスティンクトカウントされている識別子が「ｏｒｄｅｒ ｎｕｍｂｅｒ」であって、ディスティンクトカウントクエリの限定が「ｃｕｓｔｏｍｅｒ」および「ｄａｔｅ＝Ｊａｎ ２００３」であると判断する。

識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」がＡｇｇ＿Ｔａｂｌｅ＿１のすべての行で異なることを確認すると、ファシリティは、限定−すなわち顧客および日付＝２００３年１月−を満たすＡｇｇ＿Ｔａｂｌｅ＿１の行をカウントすることによってディスティンクトカウントクエリに回答できると結論付ける。したがってファシリティは、受取ったストリングを以下のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｃｕｓｔｏｍｅｒ
ＣＯＵＮＴ（ｏｒｄｅｒ ｎｕｍｂｅｒ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿１
ＷＨＥＲＥ ｄａｔｅ＝「Ｊａｎ ２００３」
ＧＲＯＵＰ ＢＹ ｙｅａｒ
上記のＳＱＬ表現が処理されると、Ｃｕｓｔｏｍｅｒ１が２００３年１月に１つの注文を出し、Ｃｕｓｔｏｍｅｒ２は２００３年１月に注文を出さなかった（ゼロ）ことが確認される。

例２：ディスティンクトカウントされている識別子が集約テーブルに存在するが一意ではない場合−ディスティンクトカウント動作が用いられる。

例として、ユーザは、詳細テーブル３０に記録されるようなブランドごとの一意の注文数のディスティンクトカウントを得ることに関心を持っているかもしれない。ここで、ファシリティはユーザから「Ｒｅｑｕｅｓｔ：ｂｒａｎｄ，＃ ｏｆ ｏｒｄｅｒｓ（ブランド，注文数），」というストリングを受取ってもよく、ファシリティは各顧客が行った一意の注文数に対するディスティンクトカウントとしてストリングを理解する（ステップ２０２）。ファシリティは、「ｂｒａｎｄ」がディスティンクトカウントクエリの限定であると判断する。ファシリティはさらに、詳細テーブル３０の識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」のディスティンクトカウントを行なうことにより、一意の注文数のためのディスティンクトカウントクエリを得ることができると判断する。

図７に示されるように、ファシリティが、Ａｇｇ＿Ｔａｂｌｅ＿２（集約テーブル２）を、テーブル３０に関連付けられる集約テーブルとして特定し（ステップ２０４）、かつ例えばクエリに回答するために必要な識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」を含むディスティンクトカウントされている識別子の集約体と仮定すると（ステップ２０６）、ファシリティがＡｇｇ＿Ｔａｂｌｅ＿２をチェックして、Ａｇｇ＿Ｔａｂｌｅ＿２のすべての行において識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」が異なるか否かを確認する（ステップ２０８）。示されるように、Ａｇｇ＿Ｔａｂｌｅ＿２は、注文数を識別する第１の列、ブランドを識別する第２の列、および日付を表示する第３の列の３つの列を含む。識別子「ｏｒ
ｄｅｒ ｎｕｍｂｅｒ」がＡｇｇ＿Ｔａｂｌｅ＿２のすべての行で異なるわけではないことを確認すると、ファシリティは、限定−すなわちブランド−を満たすＡｇｇ＿Ｔａｂｌｅ＿２の行をディスティンクトカウントすることによりディスティンクトカウントクエリに回答できると結論付ける（ステップ２１２）。したがってファシリティは、受取ったストリングを以下のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｂｒａｎｄ
ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ ｏｒｄｅｒ ｎｕｍｂｅｒ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿２
ＧＲＯＵＰ ＢＹ ｂｒａｎｄ
上記のＳＱＬ表現が処理されると、ブランド１に４つの注文が出され、ブランド２に３つの注文が出されたことが確認される。

ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿２のカウント演算子を適用することによって、他のディスティンクトカウントクエリに回答することができる。例えばユーザは、詳細テーブル３０に記録されるような各年に出された一意の注文数のディスティンクトカウントを要求し、ファシリティに「Ｒｅｑｕｅｓｔ：ｙｅａｒ，＃ ｏｆ ｏｒｄｅｒｓ（年，注文数）」というストリングを提出したかもしれない。ファシリティは、受取ったストリングが各年に出された一意の注文数に対するディスティンクトカウントクエリであると解釈し、ディスティンクトカウントされている識別子が「ｏｒｄｅｒ ｎｕｍｂｅｒ」であり、ディスティンクトカウントクエリに対する限定が「ｙｅａｒ」であると判断する。

識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」がＡｇｇ＿Ｔａｂｌｅ＿２のすべての行で異なるわけではないことを確認すると、ファシリティは、限定−すなわち年−を満たすＡｇｇ＿Ｔａｂｌｅ＿２の行をディスティンクトカウントすることによってディスティンクトカウントクエリに回答できると結論付ける。したがってファシリティは、受取ったストリングを以下のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｙｅａｒ
ＣＯＵＮＴ（ＤＩＳＴＩＮＣＴ ｏｒｄｅｒ ｎｕｍｂｅｒ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿２
ＧＲＯＵＰ ＢＹ ｙｅａｒ
上記のＳＱＬ表現が処理されると、２００３年に３つの注文が出され、２００４年に１つの注文が出されたことが確認される。

例３：ディスティンクトカウントされている識別子を集約テーブルが含まない場合−従属ディメンションだけを含む。

例として、ユーザは、詳細テーブル３０に記録されるような各年ごとの一意の注文数のディスティンクトカウントを得ることに関心を持っているかもしれない。ここで、ファシリティはユーザから「Ｒｅｑｕｅｓｔ：ｙｅａｒ，＃ ｏｆ ｏｒｄｅｒｓ（年，注文数）」というストリングを受取ってもよく、ファシリティは各顧客が各年に出した一意の注文数についてのディスティンクトカウントとしてストリングを理解する（ステップ２０２）。ファシリティは、「ｙｅａｒ」がディスティンクトカウントクエリに対する限定であると判断する。ファシリティはさらに、詳細テーブル３０の識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」のディスティンクトカウントを行なうことにより、一意の注文数に対するディスティンクトカウントクエリを得ることができると判断する。

図８に示されるように、ファシリティが、Ａｇｇ＿Ｔａｂｌｅ＿３をテーブル３０に関連付けられる集約テーブルとして特定し（ステップ２０４）、かつ例えばディスティンクトカウントされている識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」のカウントを行が含むディスティンクトカウントされている識別子の集約体と仮定すると（ステップ２０８）、ファシ
リティはＡｇｇ＿Ｔａｂｌｅ＿３をチェックして、Ａｇｇ＿Ｔａｂｌｅ＿３に含まれるディメンションのタイプを判断する。示されるように、Ａｇｇ＿Ｔａｂｌｅ＿３は、日付を表示する第１の列と注文数のカウントを含む第２の列との２つの列を含む。詳細テーブル３０では、ある注文は１人の顧客および１つの日付のみを有することができる。集約テーブルが従属ディメンションのみを含む場合、ファシリティは従属ディメンションにわたって合計してディスティンクトカウントを導き出すことができる。集約テーブル３に関しては、ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿３が従属ディメンションのみを含み、限定「ｙｅａｒ」がＡｇｇ＿Ｔａｂｌｅ＿３の値−例えば年月−と同じまたはより高いレベルにおける従属ディメンション−すなわち日付−の限定であると判断する（ステップ２１８）。年ディメンションは、Ｄｉｍｅｎｓｉｏｎ Ｔａｂｌｅ（ディメンションテーブル）３（図４Ｃ）に示されるように、日付−例えば月および年−より高いレベルにある。したがって、ファシリティは、そのディメンション値−すなわち日付値−が、すべてのクエリ限定−すなわち年−を満たすようなＡｇｇ＿Ｔａｂｌｅ＿３の行に含まれるカウント−すなわち注文数のカウント−を合計することにより、ディスティンクトカウントクエリに回答できると結論付ける（ステップ２２４）。したがって、ファシリティは、受取ったストリングを下記のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｙｅａｒ
ＳＵＭ（＃ ｏｆ ｏｒｄｅｒｓ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿３
ＧＲＯＵＰ ＢＹ ｙｅａｒ
上記のＳＱＬ表現が処理されると、２００３年に３つの注文が、２００４年に１つの注文が出されたことが確認される。

例４：ディスティンクトカウントされている識別子を集約テーブルが含まない場合−いくつかの従属ディメンションおよびいくつかの独立ディメンションを含む。

例として、ユーザは、詳細テーブル３０に記録されるような日付とブランドとの組合わせごとの一意の注文数のディスティンクトカウントを得ることに関心を持っているかもしれない。ここで、ファシリティは、ユーザから「Ｒｅｑｕｅｓｔ：ｄａｔｅ，ｂｒａｎｄ，＃ ｏｆ ｏｒｄｅｒｓ（日付，ブランド，注文数），」というストリングを受取ってもよく、ファシリティは日付とブランドとの各組合わせについて出された一意の注文数についてのディスティンクトカウントクエリとしてストリングを理解する（ステップ２０２）。ファシリティは、「ｄａｔｅ」および「ｂｒａｎｄ」がディスティンクトカウントクエリに対する限定であると判断する。ファシリティはさらに、詳細テーブル３０の識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」のディスティンクトカウントを行なうことによって、一意の注文数のためのディスティンクトカウントクエリを得ることができると判断する。

図９に示されるように、ファシリティが、Ａｇｇ＿Ｔａｂｌｅ＿４（集約テーブル４）を、テーブル３０に関連付けられる集約テーブルとして特定し（ステップ２０４）、かつ例えばディスティンクトカウントされている識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」のカウントを行が含むディスティンクトカウントされている識別子の集約体と仮定すると（ステップ２０８）、ファシリティはＡｇｇ＿Ｔａｂｌｅ＿４をチェックして、Ａｇｇ＿Ｔａｂｌｅ＿４に含まれるディメンションのタイプを判断する。示されるように、Ａｇｇ＿Ｔａｂｌｅ＿４は、日付を表示する第１の列と、ブランドを表示する第２の列と、注文数のカウントを含む第３の列との３つの列を含む。詳細テーブル３０においては、ある注文は１つの日付のみを有し得るが、複数の製品に対する注文でもあり得、それはＤｉｍｅｎｓｉｏｎ Ｔａｂｌｅ（ディメンションテーブル）１（図４Ａ）に示されるように、複数のブランドに対する注文でもあり得る。集約テーブルが、識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」に従属するディメンションと識別子から独立したディメンションとを含む場合、独立ディメンションについて集約テーブルのレベルとクエリとがレベルで一致する限り、ファシ
リティはカウントを合計してディスティンクトカウントを導き出すことができる。Ａｇｇ＿Ｔａｂｌｅ＿４に関しては、ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿４が従属ディメンションおよび独立ディメンションの両方を含むと判断する。ファシリティはさらに、限定「ｄａｔｅ」がＡｇｇ＿Ｔａｂｌｅ＿４の値−例えば年月−と同じまたはより高いレベルにおける従属ディメンション−すなわち日付−の限定であると判断し（ステップ２１８）、限定「ｂｒａｎｄ」がＡｇｇ＿Ｔａｂｌｅ＿４の値−例えばＢｒａｎｄ１またはＢｒａｎｄ２−と同じレベルにおける独立ディメンション−すなわちブランド−の限定であると判断する（ステップ２２０）。したがってファシリティは、そのディメンション値−すなわち日付およびブランド値−が、クエリのすべての限定−すなわち日付とブランドとの組合わせ−を満たすようなＡｇｇ＿Ｔａｂｌｅ＿４の行に含まれるカウント−すなわち注文数のカウント−を合計することにより、ディスティンクトカウントクエリに回答できると結論付ける（ステップ２２４）。したがって、ファシリティは、受取ったストリングを以下のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｄａｔｅ，ｂｒａｎｄ
ＳＵＭ（＃ ｏｆ ｏｒｄｅｒｓ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿４
上記のＳＱＬ表現が処理されると、Ｊａｎ ２００３およびＢｒａｎｄ １の組合せについて１つの注文が出され、Ｊａｎ ２００３およびＢｒａｎｄ ２の組合せについて１つの注文が出され、Ｆｅｂ ２００３およびＢｒａｎｄ １の組合せについて２つの注文が出され、Ｆｅｂ ２００３およびＢｒａｎｄ ２の組合せについて１つの注文が出され、Ｊａｎ ２００４およびＢｒａｎｄ １の組合せについて１つの注文が出され、かつ、Ｊａｎ ２００４およびＢｒａｎｄ ２の組合せについて１つの注文が出されたことが確認される。

ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿４のカウント演算子を適用することによって他のディスティンクトカウントクエリに回答することができる。例えばユーザは、詳細テーブル３０に記録されるようなブランドと年との各組合わせについて出された一意の注文数のディスティンクトカウントを要求し、ファシリティに「Ｒｅｑｕｅｓｔ：ｂｒａｎｄ，ｙｅａｒ，＃ ｏｆ ｏｒｄｅｒｓ（ブランド，年，注文数）」というストリングを提出したかもしれない。ファシリティは、受取ったストリングがブランドと年との各組合わせについて出された一意の注文数についてのディスティンクトカウントクエリであると解釈し、ディスティンクトカウントされている識別子が「ｏｒｄｅｒ ｎｕｍｂｅｒ」であり、ディスティンクトカウントクエリに対する限定が「ｂｒａｎｄ」および「ｙｅａｒ」であると判断する。

ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿４が従属ディメンションおよび独立したディメンションの両方を含むと判断する。ファシリティはさらに、限定「ｙｅａｒ」がＡｇｇ＿Ｔａｂｌｅ＿４の値−例えば年月−と同じまたはより高いレベルにおける従属ディメンション−すなわち日付−の限定であると判断し（ステップ２１８）、限定「ｂｒａｎｄ」がＡｇｇ＿Ｔａｂｌｅ＿４の値−例えばＢｒａｎｄ１またはＢｒａｎｄ２−と同じレベルにおける独立ディメンションの限定であると判断する（ステップ２２０）。ファシリティは従属ディメンションである日付にわたって合計するのみなので、ファシリティは、そのディメンション値−すなわち日付およびブランド値−が、すべてのクエリ限定−すなわち年とブランドとの組合わせ−を満たすようなＡｇｇ＿Ｔａｂｌｅ＿４の行に含まれるカウント−すなわち注文数のカウント−を合計することにより、ファシリティがディスティンクトカウントクエリに回答できると結論付ける（ステップ２２４）。したがってファシリティは、受取ったストリングを以下のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｂｒａｎｄ，ｙｅａｒ
ＳＵＭ（＃ ｏｆ ｏｒｄｅｒｓ）
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿４
ＧＲＯＵＰ ＢＹ ｂｒａｎｄ，ｙｅａｒ
上記のＳＱＬ表現が処理されると、Ｂｒａｎｄ１および２００３の組合せについて３つの注文が出され、Ｂｒａｎｄ２および２００３の組合せについて２つの注文が出され、Ｂｒａｎｄ１および２００４の組合せについて１つの注文が出され、かつ、Ｂｒａｎｄ２および２００４の組合せについて１つの注文が出されたことが確認される。

対照的に、ファシリティは、各年に出された一意の注文数に対するＡｇｇ＿Ｔａｂｌｅ＿４からのディスティンクトカウントクエリ−例えばＲｅｑｕｅｓｔ：ｙｅａｒ，＃ ｏｆ ｏｒｄｅｒｓ（年，注文数）−に回答することができない。なぜならそれは、独立ディメンションであるブランドにわたっての集約が要求されるからである。換言すると、そのディメンション値−すなわち日付およびブランド値−が特定のクエリ限定−すなわち年−のすべてを満たすようなＡｇｇ＿Ｔａｂｌｅ＿４の行がない。クエリはブランドおよび独立ディメンションについての限定を欠いている。この例では、ファシリティは詳細テーブル３０でディスティンクトカウント動作を行なう。

例５：ディスティンクトカウントされている識別子を集約テーブルが含まない場合−独立ディメンションのみを含む。

例として、ユーザは、詳細テーブル３０に記録されるようなブランドと州との組合わせごとの一意の注文数のディスティンクトカウントを得ることに関心を持っているかもしれない。ここで、ファシリティは「Ｒｅｑｕｅｓｔ：ｂｒａｎｄ，ｓｔａｔｅ，＃ ｏｆ ｏｒｄｅｒｓ（ブランド，州，注文数），」というストリングをユーザから受取ってもよく、ファシリティはブランドと州との各組合わせについて出された一意の注文数についてのディスティンクトカウントクエリとしてストリングを理解する（ステップ２０２）。ファシリティは、「ｂｒａｎｄ」および「ｓｔａｔｅ」がディスティンクトカウントクエリに対する限定であると判断する。ファシリティはさらに、詳細テーブル３０の識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」のディスティンクトカウントを行なうことにより、一意の注文数のためのディスティンクトカウントクエリを得ることができると判断する。
（００８７） 図１０に示されるように、ファシリティがＡｇｇ＿Ｔａｂｌｅ＿５（集約テーブル５）を詳細テーブル３０に関連付けられる集約テーブルとして特定し（ステップ２０４）、かつ例えばディスティンクトカウントされている識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」のカウント行が含むディスティンクトカウントされている識別子の集約体と仮定すると（ステップ２０８）、ファシリティはＡｇｇ＿Ｔａｂｌｅ＿５をチェックして、Ａｇｇ＿Ｔａｂｌｅ＿５に含まれるディメンションのタイプを判断する。示されるように、Ａｇｇ＿Ｔａｂｌｅ＿５は、ブランドを表示する第１の列と、州を表示する第２の列と、注文数のディスティンクトカウントを含む第３の列との３つの列を含む。詳細テーブル３０においては、ある注文は複数の製品に対する注文であり得、Ｄｉｍｅｎｓｉｏｎ Ｔａｂｌｅ１（ディメンションテーブル１）（図４Ａ）に示されるように、それは複数のブランドに対する注文でもあり得、またディメンションテーブル２（図４Ｂ）に示されるように、複数の州に対応する複数の郵便番号当てに出荷され得る。ディスティンクトカウントされている識別子「ｏｒｄｅｒ ｎｕｍｂｅｒ」から独立したディメンションのみを集約テーブルが含む場合、集約テーブルの集約体−すなわちディスティンクトカウントは、クエリ限定のレベルが集約テーブルのディメンションのレベルと正確に一致する場合にのみ用いられ得る。Ａｇｇ＿Ｔａｂｌｅ＿５に関しては、ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿５が独立ディメンションのみを含むと判断する。ファシリティはさらに、限定「ｂｒａｎｄ」が同じレベルで独立ディメンション−すなわちブランド−の限定であり、限定「ｓｔａｔｅ」が同じレベルの独立ディメンション−すなわち州−の限定であると判断する。したがってファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿５に含まれる注文数のディスティンクトカウントを用いてディスティンクトカウントクエリに回答できると結論付ける。したがってファシリティは、受取ったストリングを下記のＳＱＬ表現に変換する：
ＳＥＬＥＣＴ ｂｒａｎｄ，ｓｔａｔｅ，＃ ｏｆ ｄｉｓｔｉｎｃｔ Ｏｒｄｅｒｓ ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿５
上記のＳＱＬ表現が処理されると、Ｂｒａｎｄ１およびＳｔａｔｅ１の組合せについて４つの注文が出され、Ｂｒａｎｄ２およびＳｔａｔｅ１の組合せについて１つの注文が出され、Ｂｒａｎｄ１およびＳｔａｔｅ２の組合せについて出された注文はなく、Ｂｒａｎｄ２およびＳｔａｔｅ２の組合せについて３つの注文が出されたことが確認される。

同様にファシリティは、以下のＳＱＬ表現を用いることによって、ブランドおよび州１の各組み合わせについての一意の注文数のディスティンクトカウントに対するＡｇｇ＿Ｔａｂｌｅ＿５からのクエリ−例えばＲｅｑｕｅｓｔ：ｂｒａｎｄ，ｓｔａｔｅ，＃ ｏｆ
ｏｒｄｅｒｓ ｗｈｅｒｅ ｓｔａｔｅ＝”Ｓｔａｔｅ １”（ブランド、州、注文数、州＝「州１」）−に回答することができる。
ＳＥＬＥＣＴ ｂｒａｎｄ，ｓｔａｔｅ，＃ ｏｆ ｄｉｓｔｉｎｃｔ Ｏｒｄｅｒｓ
ＦＲＯＭ Ａｇｇ＿Ｔａｂｌｅ＿５
ＷＨＥＲＥ ｓｔａｔｅ＝”Ｓｔａｔｅ１”
上記のＳＱＬ表現が処理されると、Ｂｒａｎｄ１およびＳｔａｔｅ１の組合せのために４つの注文が出され、Ｂｒａｎｄ２およびＳｔａｔｅ１の組合せのために１つの注文が出されたことが確認される。

対照的に、ファシリティは、Ａｇｇ＿Ｔａｂｌｅ＿５からの、例えばＲｅｑｕｅｓｔ：ｂｒａｎｄ，＃ ｏｆ ｏｒｄｅｒｓ（ブランド、注文数）といった、各ブランドに出された一意の注文数のディスティンクトカウントクエリに回答することができない。なぜならそれは独立したディメンションである州にわたっての集約が要求されるからである。換言すると、Ａｇｇ＿Ｔａｂｌｅ＿５のディメンションのレベルとクエリの限定レベルとが正確には一致しない。この例では、ファシリティは詳細テーブル３０でディスティンクトカウント動作を行なう。

図１１は、いくつかの実施例による、ファシリティがディスティンクトカウントクエリに答える際に用いる集約テーブルを特定する方法１１００のフローチャートを示す。例として、ファシリティは、詳細テーブル中の識別子のディスティンクトカウントを要求するクエリを受け取ってもよい。ステップ１１０２で、ファシリティは、クエリが適用される詳細テーブルに関連した集約テーブルを特定する。ファシリティは、クエリされた識別子の集約体である集約テーブルを特に特定する。１つの実施例では、ファシリティは、それらの名称からこれらの集約テーブルを特定してもよい。例えば、データベース管理責任者は、集約テーブルとそれに関連する詳細テーブルとの関係を表示する命名規約を実現していてもよい。この例では、集約テーブルの名称は関連する詳細テーブルを特定し、関係の基礎についての表示を与える。

別の実施例において、集約テーブルの生成を監視するためにプロセスが構成されてもよく、また個々の集約テーブルについて、関連する詳細テーブルおよびデータベースの詳細テーブルとの関係の基礎の表示を与える。その後、ファシリティはこのデータベースに含まれるデータを検査することができ、詳細テーブルに関連付けられた、クエリされた識別子の集約体である集約テーブルを特定する。さらに別の実施例において、ファシリティは、集約テーブルに関連付けられた定義および／またはメタデータから詳細テーブルに関連付けられる集約テーブルを特定することができる。例えば、ツールが各集約テーブルについてメタデータを作成してもよく、メタデータは、関連する詳細テーブル、および詳細テーブルとの関係の基礎に関するデータを含む。

ステップ１１０４で、ファシリティは、現在のディスティンクトカウントクエリに答える際の使用に適さない集約テーブルを廃棄する。例えば、ファシリティは、クエリされた
識別子の集約体でない集約テーブルを廃棄する。ステップ１１０６では、ファシリティは、ディスティンクトカウントされている識別子を含む少なくとも１つの集約テーブルがあるか否かを判断するために、廃棄されていない集約テーブルをチェックする。ディスティンクトカウントされている識別子を含む少なくとも１つの集約テーブルがある場合、次に、ステップ１１０８で、ファシリティは最も粒度の高い集約テーブルを選択する。集約テーブルが１つしかない場合（ステップ１１０６）、その集約テーブルが最も粒度の高い集約テーブルである。換言すれば、ファシリティは最小の集約テーブルを選択し、選択された集約テーブルを用いてディスティンクトカウントクエリの処理を続ける。

ディスティンクトカウントされている識別子を含む集約テーブルがない場合、次に、ステップ１１１０で、ファシリティは、ディスティンクトカウントされている識別子のカウントを含む少なくとも１つの集約テーブルがあるか否かを判断するために、廃棄されていない集約テーブルをチェックする。ディスティンクトカウントされている識別子のカウントを含む少なくとも１つの集約テーブルがある場合、次に、ステップ１１１２で、ファシリティは最も粒度の高い集約テーブルを選択し、選択された集約テーブルを用いて、ディスティンクトカウントクエリを処理し続ける。集約テーブルが１つしかない場合（ステップ１１１０）、その集約テーブルが最も粒度の高い集約テーブルである。

ディスティンクトカウントされている識別子のカウントを含む集約テーブルがない場合、次に、ステップ１１１４で、ファシリティはディスティンクトカウントされている識別子のディスティンクトカウントを含む少なくとも１つの集約テーブルがあるか否かを判断するために、廃棄されていない集約テーブルをチェックする。ディスティンクトカウントされている識別子のディスティンクトカウントを含む少なくとも１つの集約テーブルがある場合、次に、ステップ１１１６で、ファシリティは最も粒度の高い集約テーブルを選択し、選択された集約テーブルを用いて、ディスティンクトカウントクエリを処理し続ける。集約テーブルが１つしかない場合（ステップ１１１４）、その集約テーブルが最も粒度の高い集約テーブルである。

そうではなく、ファシリティが、クエリに答える際に用いる集約テーブルの特定に失敗した場合、ファシリティは詳細テーブルを用いてディスティンクトカウントクエリを処理し続ける。

本発明の実施例は図示する目的のために本願明細書に記載されているが、本発明の精神および範囲から逸れることなく様々な修正がなされ得ることは前記から認識されるだろう。従って、本発明は、添付の請求項で明示的に詳細に示された要素と一致するもの以外には限定的ではない。

少なくともファシリティが実行するコンピュータシステムのうちのいくつかに典型的に組み込まれた、選択されたコンポーネントを図示するブロック図である。 いくつかの実施例による、ファシリティがディスティンクトカウントメトリックを行なう方法のフローチャートを示す図である。 いくつかの実施例による、ファシリティがディスティンクトカウントメトリックを行なう方法のフローチャートを示す図である。 いくつかの実施例による、ファシリティがディスティンクトカウントメトリックを行なう方法のフローチャートを示す図である。 詳細テーブルの例を示す図である。 図３に示された詳細テーブルに対応するディメンションテーブルの例を示す図である。 図３に示された詳細テーブルに対応するディメンションテーブルの例を示す図である。 図３に示された詳細テーブルに対応するディメンションテーブルの例を示す図である。 図３に示された詳細テーブルに対応する集約テーブルの例を示す図である。 図３に示された詳細テーブルに対応する集約テーブルの例を示す図である。 図３に示された詳細テーブルに対応する集約テーブルの例を示す図である。 図３に示された詳細テーブルに対応する集約テーブルの例を示す図である。 図３に示された詳細テーブルに対応する集約テーブルの例を示す図である。 図３に示された詳細テーブルに対応する集約テーブルの例を示す図である。 いくつかの実施例による、ファシリティがディスティンクトカウントクエリに答える際に用いる集約テーブルを特定する方法のフローチャートを示す図である。

Claims (25)

1. ディスティンクトカウントクエリを処理するための計算システムの方法であって、
   詳細テーブルのディスティンクトカウントを要求するクエリを受取るステップを含み、クエリは一意にカウントされる詳細テーブルの識別子タイプを指定し、クエリはさらに、詳細テーブルのディメンションに対する０以上の限定を指定し、指定された各限定は独立ディメンションまたは従属ディメンションのいずれかの限定であって、指定された各限定はそのディメンションの特定のレベルにあり、さらに、
   詳細テーブルに対応する集約テーブルを特定するステップと、
   特定された集約テーブルの行が、
   （１）指定されたタイプの識別子を含むか、または（２）ディメンション値の異なる組合せについて詳細テーブルに生じる、指定されたタイプの複数の一意の識別子を各々表示するカウントを含むかを判断するステップとを含み、各ディメンション値はそのディメンションの特定のレベルにあり、
   特定された集約テーブルの行が指定されたタイプの識別子を含む場合：
   指定されたタイプの識別子が各々特定された集約テーブルに一意に生じる場合、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行で平易なカウント動作を行なうステップと、
   指定されたタイプの識別子が各々特定された集約テーブルに一意に生じない場合、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行でディスティンクトカウント動作を行なうステップとを含み、さらに、
   特定された集約テーブルの行が、ディメンション値の異なる組合せについて詳細テーブルに生じる、指定されたタイプの複数の一意の識別子を各々表示するカウントを含み、各ディメンションがそのディメンションの特定のレベルにある場合：
   各指定された限定について、指定された限定が、（１）集約テーブルのディメンション値と同じレベルの独立ディメンションにあるか、または（２）集約テーブルのディメンション値と同じレベルまたはより高いレベルの従属ディメンションにあるかを判断するステップを含み、さらに、
   各指定された限定が、（１）集約テーブルのディメンション値と同じレベルの独立したディメンションにあるか、または（２）集約テーブルのディメンション値と同じレベルまたはより高いレベルの従属ディメンションにあるかのいずれかである場合：
   ディスティンクトカウントクエリに対する結果を得るために、そのディメンション値が指定された限定をすべて満たすような集約テーブルの行に含まれるカウントを合計するステップを含み、さらに、
   指定された限定すべてが、（１）集約テーブルのディメンション値と同じレベルの独立したディメンションにあるか、または（２）集約テーブルのディメンション値と同じレベルまたはより高いレベルの従属ディメンションにあるかのいずれかであるわけではない場合：
   ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす詳細テーブルの行でディスティンクトカウント動作を行なうステップを含む、方法。
2. 集約テーブルは複数の集約テーブルのうちの１つであって、集約テーブルは複数の集約テーブルのうち最も粒度が高い、請求項１に記載の方法。
3. コンピュータ可読記憶媒体であって、その記憶内容によってコンピュータは、
   詳細テーブルの識別子のディスティンクトカウントを要求するクエリを受取り、クエリは詳細テーブルのディメンションに対する０以上の限定を指定し、さらに、
   詳細テーブルに関連した集約テーブルを特定し、
   集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子を集約テーブルが含むか否かを判断し、
   ディスティンクトカウントされている識別子を集約テーブルが含むと判断することに応答して、
   識別子が集約テーブルのすべての行で異なるか否かを判断し、さらに、
   識別子が集約テーブルのすべての行で異なると判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行でカウント動作を行う、コンピュータ可読記憶媒体。
4. 各限定は詳細テーブルのディメンションにある、請求項３に記載のコンピュータ可読記憶媒体。
5. 各限定は独立ディメンションまたは従属ディメンションのいずれかにある、請求項４に記載のコンピュータ可読記憶媒体。
6. 各限定はそのディメンションの特定のレベルにある、請求項５に記載のコンピュータ可読記憶媒体。
7. 集約テーブルは複数の集約テーブルのうちの１つであって、集約テーブルは複数の集約テーブルのうち最も粒度が高い、請求項３に記載のコンピュータ可読記憶媒体。
8. 識別子が集約テーブルのすべての行で異なるわけではないと判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行でコンピュータにディスティンクトカウント動作を行なわせる記憶内容をさらに含む、請求項３に記載のコンピュータ可読記憶媒体。
9. 記憶内容をさらに含み、記憶内容によってコンピュータは、
   集約テーブルを特定することに応答して、集約テーブルの行がディスティンクトカウントされている識別子のカウントを含むか否かを判断し、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンション値はそのディメンションの特定のレベルにあり、さらに、
   集約テーブルの行がディスティンクトカウントされている識別子のカウントを含むと判断することに応答して、ディスティンクトカウントされている識別子に従属するディメンションのみを伴うディメンション数を集約テーブルが有するか否かを判断し、さらに、
   ディスティンクトカウントされている識別子に従属するディメンションのみを伴うディメンション数を集約テーブルが有すると判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれるカウントを合計する、請求項３に記載のコンピュータ可読記憶媒体。
10. 記憶内容をさらに含み、記憶内容によってコンピュータは、
    集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断し、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンションはそのディメンションの特定のレベルにあり、さらに、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、集約テーブルは、ディスティンクトカウントされている識別子に従属する少なくとも１つのディメンション、およびディスティンクトカウントされている識別子から独立した少なくとも１つのディメンションを有するか否かを判断し、さらに、
    ディスティンクトカウントされている識別子に従属する少なくとも１つのディメンション、およびディスティンクトカウントされている識別子から独立した少なくとも１つのディメンションを有するか否かを判断することに応答して、独立ディメンションの集約体の
    レベルとクエリとがレベルで一致するか否かを判断し、さらに、
    独立ディメンションの集約体のレベルとクエリとがレベルで一致するか否かを判断することに応答して、
    ディスティンクトカウントクエリに対する結果を得るために、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれるカウントを合計する、請求項３に記載のコンピュータ可読記憶媒体。
11. 記憶内容をさらに含み、記憶内容によってコンピュータは、
    集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断し、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンションはそのディメンションの特定のレベルにあり、さらに、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、ディスティンクトカウントされている識別子から独立したディメンションのみを伴うディメンション数を集約テーブルが有するか否かを判断し、さらに、
    ディスティンクトカウントされている識別子から独立したディメンションのみを伴うディメンション数の数を集約テーブルが有すると判断することに応答して、ディスティンクトカウントに対する結果を得るために、集約テーブルのレベルとクエリ限定とがレベルで正確に一致する場合にのみ、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれる集約カウントを用いる、請求項３に記載のコンピュータ可読記憶媒体。
12. ディスティンクトカウントメトリックを得るための計算システムの方法であって、
    詳細テーブルの識別子のディスティンクトカウントを要求するクエリを受取るステップを含み、クエリは詳細テーブルのディメンションに対する０以上の限定を指定し、さらに、
    詳細テーブルに関連した集約テーブルを特定するステップと、
    集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子を集約テーブルが含むか否かを判断するステップと、
    ディスティンクトカウントされている識別子を集約テーブルが含むと判断することに応答して、
    識別子が集約テーブルのすべての行で異なるか否かを判断するステップと、
    識別子が集約テーブルのすべての行で異なると判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行でカウント動作を実行するステップとを含む、方法。
13. 各限定は詳細テーブルのディメンションにある、請求項１２に記載の方法。
14. 各限定は独立ディメンションまたは従属ディメンションのいずれかにある、請求項１３に記載の方法。
15. 各限定はそのディメンションの特定のレベルにある、請求項１４に記載の方法。
16. 集約テーブルは複数の集約テーブルのうちの１つであって、集約テーブルは、複数の集約テーブルの中で最も粒度が高い、請求項１２に記載の方法。
17. 識別子が集約テーブルのすべての行で異なるわけではないと判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行でディスティンクトカウント動作を実行するステップをさらに含む、請求項１３に記載の方法。
18. 集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断するステップを含み、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンションはそのディメンションの特定のレベルにあり、さらに、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、ディスティンクトカウントされている識別子に従属するディメンションのみを伴うディメンション数を集約テーブルが有するか否かを判断するステップと、
    ディスティンクトカウントされている識別子に従属するディメンションのみを伴うディメンション数を集約テーブルが有すると判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれるカウントを合計するステップとをさらに含む、請求項１２に記載の方法
19. 集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断するステップを含み、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンションはそのディメンションの特定のレベルにあり、さらに、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、ディスティンクトカウントされている識別子に従属するディメンションのみを伴うディメンション数を集約テーブルが有するか否かを判断するステップと、
    独立ディメンションの集約体のレベルとクエリとがレベルで一致するか否かを判断するステップと、
    独立ディメンションの集約体のレベルとクエリとがレベルで一致すると判断することに応答して、ディスティンクトカウントクエリについて結果を得るために、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれるカウントを合計するステップとを含む、請求項１２に記載の方法。
20. 集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断するステップを含み、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンションはそのディメンションの特定のレベルにあり、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、ディスティンクトカウントされている識別子と独立ディメンションのみに関するディメンション数を集約テーブルが有するか否かを判断するステップと、
    ディスティンクトカウントされている識別子から独立したディメンションのみを伴うディメンション数を集約テーブルが有すると判断することに応答して、ディスティンクトカウントに対する結果を得るために、集約テーブルのレベルとクエリ限定とがレベルで正確に一致する場合にのみ、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれる集約カウントを用いるステップとをさらに含む、請求項１２に記載の方法。
21. ディスティンクトカウントメトリックを得るためのシステムであって、
    詳細テーブルの識別子のディスティンクトカウントを要求するクエリを受取るよう動作可能であるクエリ受信コンポーネントを含み、クエリは詳細テーブルのディメンションに対する０以上の限定を指定し、さらに、
    ディスティンクトカウントメトリックコンポーネントとを含み、ディスティンクトカウントメトリックコンポーネントは、
    詳細テーブルに関連した集約テーブルを特定するよう、
    集約テーブルの特定に応答して、ディスティンクトカウントされている識別子を集約テーブルが含むか否かを判断するよう、
    ディスティンクトカウントされている識別子を集約テーブルが含むと判断することに応答して、
    識別子が集約テーブルのすべての行で異なるか否かを判断するよう、
    識別子が集約テーブルのすべての行で異なると判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行でカウント動作を行なうよう動作可能である、システム。
22. ディスティンクトカウントメトリックコンポーネントはさらに、識別子が集約テーブルのすべての行で異なるわけではないと判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、指定された限定を満たす集約テーブルの行でディスティンクトカウント動作を実行するようさらに動作可能である、請求項２１に記載のシステム。
23. ディスティンクトカウントメトリックコンポーネントはさらに、
    集約テーブルの特定に応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断するようさらに動作可能であり、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンションはそのディメンションの特定のレベルにあり、さらに、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、指定された限定が、各々集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定であるか否かを判断するよう、
    指定された限定が各々集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定であると判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれるカウントを合計するよう、動作可能である、システム。
24. ディスティンクトカウントメトリックコンポーネントはさらに、
    集約テーブルの特定に応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断するようさらに動作可能であり、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンション値はそのディメンションの特定のレベルにあり、さらに、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、指定された限定は、各々集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定か、または集約テーブルのディメンション値と同じレベルの独立ディメンションの限定かを判断するよう、
    指定された限定が各々集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定、または集約テーブルのディメンション値と同じレベルの独立ディメンションの限定のいずれかであると判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれるカウントを合計するよう動作可能である、請求項２１に記載のシステム。
25. ディスティンクトカウントメトリックコンポーネントはさらに、
    集約テーブルを特定することに応答して、ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むか否かを判断するようさらに動作可能であり、各カウントは、識別子がディメンション値の異なる組合せについて詳細テーブルに生じる回数を表示し、各ディメンション値はそのディメンションの特定のレベルにあり、さらに、
    ディスティンクトカウントされている識別子のカウントを集約テーブルの行が含むと判断することに応答して、指定された限定は、各々集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定か、または集約テーブルのディメンション値と同じレベルの独立ディメンションの限定かを判断するよう、
    指定された限定が各々集約テーブルのディメンション値と同じまたはより高いレベルの従属ディメンションの限定、または集約テーブルのディメンション値と同じレベルの独立ディメンションの限定のいずれでもないと判断することに応答して、ディスティンクトカウントクエリに対する結果を得るために、集約テーブルのレベルとクエリ限定とがレベルで正確に一致する場合にのみ、そのディメンション値が指定された限定をすべて満たす集約テーブルの行に含まれる集約カウントを用いるステップをさらに含む、請求項２１に記載のシステム。

Images