JP2006526840A - 多次元データベースの照会及び視覚化のためのコンピュータシステム及び方法本発明は、スタンフォード大学（ＳｔａｎｄｆｏｒｄＵｎｉｖｅｒｓｉｔｙ）（「統合乱気流シミュレーションのためのセンタ（ＣｅｎｔｅｒｆｏｒＩｎｔｅｇｒａｔｅｄＴｕｒｂｕｌｅｎｃｅＳｉｍｕｌａｔｉｏｎ）」）とのエネルギー省ＡＳＣＩレベル１提携契約ＬＬＬ−Ｂ５２３５８３だけではなく、防衛高等研究計画局（ＤｅｆｅｎｓｅＡｄｖａｎｃｅｄＲｅｓｅａｒｃｈＰｒｏｊｅｃｔｓＡｇｅｎｃｙ）（「複雑なシステム及び環境の視覚化（ＶｉｓｕａｌｉｚａｔｉｏｎｏｆＣｏｍｐｌｅｘＳｙｓｔｅｍｓａｎｄＥｎｖｉｒｏｎｍｅｎｔｓ）」）、ＡＰＲＡ発注番号Ｅ２６９によっても部分的に支援された。米国政府は本発明に権利を有する可能性がある。 - Google Patents

Abstract

グラフィックスを作り出すための方法及びシステム。データベースの階層構造が決定される。複数のペインを含むビジュアルテーブルが、前記データベースの階層構造に基づいた言語での仕様を提供することにより構築される。いくつかのケースでは、この言語は前記データベース方式内にあるフィールドを含むことがある。前記データベースは前記仕様に従ってタプルの集合を取り出すために照会される。タプルの前記集合の部分集合は前記複数のペインと関連付けられる。

Description

本発明は、概して階層構造を有するデータベースの探査解析を容易にする対話型視覚探査ツールに関する。

過去数年間において、大型データベースは種々のアプリケーションで一般化してきた。企業はその営業の重要な面に関する履歴データの大きなデータウェアハウスを作成している。企業はその事業のいくつかの特殊な局面を調べるために作成されるデスクトップアプリケーションを使用して多くの小型データベースを作成している。ヒトゲノムプロジェクト（Ｈｕｍａｎ Ｇｅｎｏｍｅ Ｐｒｏｊｅｃｔ）及びスローンデジタルスカイサーベイ（Ｓｌｏｎｅ Ｄｉｇｉｔａｌ Ｓｋｙ Ｓｕｒｖｅｙ）などの国際研究プロジェクトが大量の科学データベースを生成している。これらのデータベースに関する１つの課題は、構造を発見するため、パターンを見つけ出すため、及び因果関係を引き出すためにそれらが含むデータから意味を抽出することである。これらのデータセットの全体の大きさによりこのタスクは複雑化する。各レコードをビジットすることを必要とする対話型計算は信頼できそうにない。また、アナリストがデータセット全体について推論し、その最も細かい詳細のレベルで表示することは実行不可能である。さらに、たとえデータセットが小さくても、その複雑度のため多くの場合、集約演算を適用、または簡略化要約を作成することなく意味を細かく調べることは困難である。
データベースに意味のある階層構造を課すことにより、コンピュータとアナリスト両方が利用できる抽象化のレベルが提供される。これら階層は複数の異なるソースから出現できる。いくつかの階層はデータベースの固有の性質によって提供される。決定木及びデータを分類し、それにより自動的に階層を引き出すクラスタリング技法などのデータマイニングアルゴリズムは、データベース階層を決定するために使用できる。自動的に生成された階層に対処する分析タスクの部分は、結果を理解し、信頼することである。例えば、その全体として参照することにより本書に組み込まれるデータマイニング及び知識発見における情報の視覚化（Ｉｎｆｏｒｍａｔｉｏｎ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｉｎ Ｄａｔａ Ｍｉｎｉｎｇ ａｎｄ Ｋｎｏｗｌｅｄｇｅ Ｄｉｓｃｏｖｅｒｙ）、Ｆａｙｙａｄ、Ｇｒｉｎｓｔｅｉｎ及びＷｉｅｒｓｅ編集、ＭｏｒｇａｎＫａＵｆｍａｎの２００１、Ｔｈｅａｒｌｉｎｇら、「データマイニングモデルの視覚化（Ｖｉｓｕａｌｉｚｉｎｇ Ｄａｔａ Ｍｉｎｉｎｇ Ｍｏｄｅｌｓ）」を参照すること。
図９は、時間領域１００のための階層を描く。時間領域１００内では、４つのレベル１１０がある。それらは「すべて」、年、四半期及び月である。図９に図示されるもののような簡略な階層は、スタースキーマを使用して一般的にモデル化される。次元階層全体が、基礎ファクトテーブルに加えられる単一のディメンションテーブルによって表される。この種の階層では、ただ１つの集約演算の経路があるだけである。しかしながら、集約演算経路が分岐することがあるさらに複雑な次元階層がある。例えば、時間領域は「日」から週と「月」の両方に集約する可能性がある。
スタースキーマの概念の別の図解を提供するために、データを領域と店舗で内訳することによりデパートの月次製品総売上高を分析することを望むケースを考える。未処理データは製品マネージャ（図１）及び地域マネージャ（図２）の四半期売上報告書の形で出すことができる。いったんデータが収集され、精緻化されると、それは大きなベーステーブルに常駐することがある。加えて、付属のルックアップテーブルが存在する場合がある。このベースデータのスタースキーマは図３に示されている。図３のテーブル方式は、中央のファクトテーブルが各次元を記述するディメンションテーブルのそれぞれで囲まれるように描かれるため、スタースキーマと呼ばれる。この例では、ベース売上高データテーブルはファクトテーブルであり、各ルックアップテーブルはディメンションテーブルである。
図３のファクトテーブルの店舗、週、及び製品の欄は数値を含む。ファクトテーブルは巨大な数の行に成長する可能性がある。ルックアップテーブルはそのより高いレベルの集約演算による各店舗、週、及び製品に関する階層情報を含む。例えば、図３のベーステーブルの店舗１は、それがリッジウッド（Ｒｉｄｇｅｗｏｏｄ）という名称を有する「店舗ルックアップ」と接続し、北東領域まで上方にスクロールする。ベーステーブルの製品２は、それがオリーブオイル石鹸という名称を有する「製品ルックアップ」テーブルと接続し、スキンケア製品グループ内の製品種別石鹸の中に上方にスクロールする。その全体として参照することにより本書に組み込まれるＴｈｏｍｓｅｎ、１９９７年、ＯＬＡＰ解決策：多次元情報システムの構築（ＯＬＡＰ Ｓｏｌｕｔｉｏｎｓ：Ｂｕｉｌｄｉｎｇ Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ）、ウィリーコンピュータ出版（Ｗｉｌｅｙ Ｃｏｍｐｕｔｅｒ Ｐｕｂｌｉｓｈｉｎｇ）ニューヨーク（Ｎｅｗ Ｙｏｒｋ）。
データベースで見つけ出される最も一般的なスキーマはスタースキーマとスノーフレークスキーマである。各スキーマはデータベースが構築される分析における関心のあるデータ項目（基準）を含むファクトテーブルを有する。これらのデータ項目は、ミューチュアルファンドに投資される額または販売トランザクションでの利益などのトランザクション量である可能性がある。ファクトテーブルは、さまざまな方法でファクトテーブルを要約するために使用される詳細な情報を含むディメンションテーブルに囲まれている。スタースキーマの図解が提供された（図３）。図４は、階層を含むスノーフレークスキーマを描く。スノーフレークとスタースキーマはデータベースの概念上の多次元ビューを提供する。データベースは相互に関係付けられたテーブルの集合よりむしろ多くの次元によって特徴付けられる約数のコア集合である。この編成は、多数のタプル上での製品、場所、またはデータなどの複数の特徴付け属性（つまり次元）によって利益または売上高などの数個の定量的な属性（つまり約数）を要約する典型的な分析照会と直接的に相関する。スタースキーマとスノーフレークスキーマの主要な相違点は、次元上でそれらがどのようにして階層構造をモデル化するかにおいて発生する。
次元階層内の値を参照するとき、階層のルートレベル「すべて」（図９）から指定値までの特定の経路を指定するために、ドット付き表記が使用できる。具体的には、階層のレベルｍでの値を参照するために、次元名が最初にオプションで一覧表示され、次に（ｍ−１）個の中間先祖値のゼロ個または１個以上、それから最後にｍ番目のレベルの値が、すべてピリオドで区切られ、一覧表示される。例えば、１９９８年１月に対応する時間階層におけるＭｏｎｔｈ（月）レベルでのＪａｎ（１月）ノードは、１９９８．Ｑｔｒ１．Ｊａｎと呼ぶことができる。この表記法が使用されるとき、基準は限定値と呼ばれる。値が（ルートノードへの任意の経路を使わずに）単にそのノード値によって記述されるとき、基準は非限定値と呼ばれる。

２．１ データベースのタイプ
データベースの１つの形式は、構造化問い合わせ言語（ＳＱＬ）データベースなどの関係ウェアハウスである。関係ウェアハウスはデータをテーブルに編成する。テーブルの各行は基本的なエンティティつまり事実に相当し、各列はそのエンティティの特性を表す。例えば、Ｔｈｏｍｓｅｎ、１９９７年、ＯＬＡＰ解決策：多次元情報システムの構築（ＯＬＡＰ Ｓｏｌｕｔｉｏｎｓ：Ｂｕｉｌｄｉｎｇ Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ）、ウィリーコンピュータ出版（Ｗｉｌｅｙ Ｃｏｍｐｕｔｅｒ Ｐｕｂｌｉｓｈｉｎｇ）ニューヨーク（Ｎｅｗ Ｙｏｒｋ）を参照すること。例えば、テーブルは銀行でのトランザクションを表してよく、各行が単一のトランザクションに相当する。このようにして、各トランザクションはトランザクション額、アカウント残高、銀行支店、及び顧客などの複数の特性を有してよい。ここに使用されるように、テーブル中の行はタプルまたはレコードと呼ばれ、関係内の列はフィールドと呼ばれる。このようなテーブルは関係とも呼ばれる。このようにして、関係はタプルの集合を含むデータベースタプルとして定義される。
関係ウェアハウスでディメンションテーブル及びスタースキーマを作成することが可能である。単一の関係ウェアハウスは多くの異種であるが、相互に関係付けられたテーブルを含むであろう。テーブル内のフィールド（列）は、次元と約数の２つの種類に区分できる。次元と約数は従来の分析における独立変数と従属変数に類似している。例えば、口座残高は約数であろうが、銀行の支店と顧客は次元である。
多次元データベースはＮ次元のデータキューブとして構造化される。データキューブ内の各次元は（例えば、スタースキーマ、スノーフレークスキーマ等の中など）リレーショナルスキーマ内の１つの次元に相当する。データキューブ内の各セルは次元ごとに値の一意の組み合わせに一致するリレーショナルスキーマ内のすべての約数を含む。データキューブ内の次元は多くの場合階層構造で補強される。この階層構造は、次元内の詳細の意味論的なレベルから引き出す、あるいは分類アルゴリズムから生成することができる。これらの階層を使用して、アナリストはベースファクトテーブルから計算される集約の複数の有意義なレベルでデータキューブを探査、解析できる（例えば、未処理データとのデータベースの関係）。データキューブ内の各セルは適切な詳細のレベルに集約されるベースファクトテーブルの約数に相当する。
集約レベルは、階層次元から決定される。各次元は複数のレベルのある木として構造化される。各レベルはその次元の詳細の異なる意味論的なレベルに相当する。木の各レベルの中には多くのノードがある。各ノードは、ノードがその中にある詳細のレベルのドメイン内の値に相当する。木は詳細の各レベルでドメイン値の間の親−子関係の集合を形成する。

２．２ データベースのデータ探査
視覚化は、単独で、及びデータマイニングアルゴリズムと結合されて大きなデータを探査するための強力なツールである。しかしながら、大きなデータベースを効果的に視覚化するタスクは視覚化システムへの人間−コンピュータインタフェースに対してかなりの要求を課す。探査プロセスは、仮説、実験及び発見の内の１つである。探査の経路は予測不可能であり、アナリストは表示されているデータとその視覚表現の両方を容易に変更できる必要がある。さらに、アナリストは最初に高い抽象化のレベルでデータについて推論し、次にかなりの詳細のレベルで関心のあるデータを探査するために迅速に掘り下げることができなければならない。次に、インタフェースはデータの根本的な階層構造を露呈し、視覚化の迅速な改良を支援しなければならない。
当該技術で既知の１つのツールはポラリス（Ｐｏｌａｒｉｓ）である。例えば、Ｓｔｏｌｔｅ、Ｔａｎｇ、及びＨａｎｒａｈａｎ、２００２、視覚化及びコンピュータグラフィックス８に関するＩＥＥＥ報告書（ＩＥＥＥ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｖｉｓｕａｌｉｚａｔｉｏｎ ａｎｄ Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ ８）を参照すること。ポラリスは、関係の視覚化を構築するために代数形式主義上に構築される。ユーザインタフェースの状態は視覚的な仕様である。この仕様は、結果として生じるタプル（データベース内のデータの行）のグラフィックマークへのマッピング及びレイアウトだけではなく、要求されたデータを取り出すために必要な一連の照会を決定するために前記形式主義に従って解釈される。しかしながら、ポラリスの元の形式は階層データベース内で発見される階層的に構造化された次元の構造を使用しない。したがって、ポラリスの元の形式は階層構造を有するデータベースの探査解析に満足の行く手段を提供しない。
当該分野で既知の他の技術は２つのカテゴリ、つまり（ｉ）データベースの視覚的な探査と（ｉｉ）データマイニングアルゴリズムと併せたデータ視覚化の使用に分類される。これら２つのカテゴリは以下に同様に検討される。

２．２．１ データベースの視覚的なデータ探査
ＶＱＥ（Ｍｅｒｔｈｉｃｋら、１９９７年「データ探査のための対話型視覚化環境（Ａｎ Ｉｎｔｅｒａｃｔｉｖｅ Ｖｉｓｕａｌｉｚａｔｉｏｎ Ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ Ｄａｔａ Ｅｘｐｌｏｒａｔｉｏｎ）」、データベースにおける知識発見の会議録（Ｐｒｏｃ． ｏｆ Ｋｎｏｗｌｅｄｇｅ Ｄｉｓｃｏｖｅｒｙ ｉｎ Ｄａｔａｂａｓｅｓ、２−９ページ）、Ｖｉｓａｇｅ（Ｒｏｔｈら、１９９６年、「Ｖｉｓａｇｅ：情報を探査するためのユーザインタフェース環境（Ｖｉｓａｇｅ：Ａ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ Ｅｎｖｉｒｏｎｍｅｎｔ ｆｏｒ Ｅｘｐｌｏｒｉｎｇ Ｉｎｆｏｒｍａｔｉｏｎ）」、情報視覚の会議録（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ Ｉｎｆｏｒｍａｔｉｏｎ Ｖｉｓｕａｌｉｚａｔｉｏｎ）、３−１２ページ）、ＤＥＶｉｓｅ Ｌｉｖｎｙら、１９９７年、「ＤＥＶｉｓｅ：大型データベースの統合照会及び視覚探査（Ｉｎｔｅｇｒａｔｅｄ Ｑｕｅｒｙｉｎｇ ａｎｄ Ｖｉｓｕａｌ Ｅｘｐｌｏｒａｔｉｏｎ ｏｆ Ｌａｒｇｅ Ｄａｔａｓｅｔｓ）」、ＡＣＭ ＳＩＧＭＯＤの会議録）、Ｔｉｏｇａ−２（Ｗｏｏｄｒｕｆｆら、２００１年、視覚言語及びコンピューティング誌、エンドユーザ向けの視覚言語及びドメイン特定プログラミングに関する特別号（Ｊｏｕｒｎａｌ ｏｆ Ｖｉｓｕａｌ Ｌａｎｇｕａｇｅｓ ａｎｄ Ｃｏｍｐｕｔｉｎｇ，Ｓｐｅｃｉａｌ Ｉｓｓｕｅ ｏｎ Ｖｉｓｕａｌ Ｌａｎｇｕａｇｅｓ ｆｏｒ Ｅｎｄ−ｕｓｅｒ ａｎｄ Ｄｏｍａｉｎ−Ｓｐｅｃｉｆｉｃ Ｐｒｏｇｒａｍｍｉｎｇ）１２、５５１から５７１ページ）などの視覚照会ツールは、視覚照会を通した対話型データベース探査を直接的にサポートする視覚化ツールの構築に焦点を当てている。ユーザは、インタフェースとのその対話を通して直接的に照会及び視覚化を構築できる。これらのシステムは、グラフに照会結果をマッピングするための柔軟な機構を有し、グラフ内のマークの網膜特性に対するデータベースタプルのマッピングをサポートする。これらのシステムの内、Ｔｉｏｇａ−２だけが詳細のさまざまなレベルで対話的にナビゲーションし、データを探査するための内蔵サポートを提供する。しかしながら、根本的な階層構造は視覚化プロセスの間にアナリストによってつくられなければならない。これらの視覚照会ツールはデータベース内ですでに符号化されている階層構造を利用しない。この欠点のため、ＶＱＥ、Ｖｉｓａｇｅ、ＤＥＶｉｓｅ及びＴｉｏｇａ−２は階層構造を有するデータベースの探査的な分析を容易にするための満足の行くツールではない。
ＸｍｄｖＴｏｏｌ（Ｗａｒｄ、１９９４年、「ＸｍｄｖＴｏｏｌ：多変量データを視覚化するための複数の方法の統合（ＸｍｄｖＴｏｏｌ：Ｉｎｔｅｇｒａｔｉｎｇ ｍｕｌｔｉｐｌｅ ｍｅｔｈｏｄｓ ｆｏｒ ｖｉｓｕａｌｉｚｉｎｇ ｍｕｌｔｉ−ｖａｒｉａｔｅ ｄａｔａ）」、ＩＥＥＥ視覚化の会議録、３２６−３３６ページ）、Ｓｐｏｔｆｉｒｅ（バイオノース、オタワ、カナダ、オンタリオ、（ＢｉｏＮｏｒｔｈ，Ｏｔｔａｗａ，Ｏｎｔａｒｉｏ、Ｃａｎａｄａ）、２００２年１１月）及びＸｇｏｂｉ（Ｂｕｊａら、１９９６年、計算及びグラフィック統計誌（Ｊｏｕｒｎａｌ ｏｆ Ｃｏｍｐｕｔａｔｉｏｎａｌ ａｎｄ Ｇｒａｐｈｉｃａｌ Ｓｔａｔｉｓｔｉｃｓ ５、７８−９９ページ）などのツールは、アナリストに散布図と平行座標などの所定の視覚化の集合を提供する。これらのシステムは照会を精緻化するために使用できる（例えば、ブラッシングとズーミングなどの）広範囲な対話技法で補強される。しかしながら、このような方法は分析プロセスに適応させるために広範囲のディスプレイを対話的に構築、精緻化するためのツールを提供しない。さらに、これらのシステムの内、ＸｍｄｖＴｏｏｌだけが階層的に構造化されたデータの探査をサポートする。ＸｍｏｄｖＴｏｏｌは、ユーザがディスプレイの詳細な大局的なレベルを制御し、（データの階層クラスタリングに基づいて）階層構造内のその近接さに基づいてレコードをブラッシングすることができるようにする構造ベースのブラシで補強されている（Ｆｕａｌら、情報視覚化の会議録（Ｐｒｏｃ．ｏｆ Ｉｎｆｏｒｍａｔｉｏｎ Ｖｉｓｕａｌｉｚａｔｉｏｎ）、１９９９年１０月、５８−６４ページ）。しかしながら、このような手法は、近接さを有意義にするために、このケースではデータの単一の階層構造化及びその階層の単一の配列の表示にユーザを制限する。この理由から、ＸｍｄｖＴｏｏｌ、Ｓｐｏｔｆｉｒｅ及びＸｇｏｂｉｈは、階層構造を有するデータベースの探査解析を容易にするための満足の行くツールではない。
別の既知の視覚化システム、ＶｉｓＤＢ（Ｋｅｉｍ及びＫｒｉｅｇｅｌ、１９９４年、ＩＥＥＥコンピュータグラフィックス及びアプリケーション（ＩＥＥＥ Ｃｏｍｐｕｔｅｒ Ｇｒａｐｈｉｃｓ ａｎｄ Ａｐｐｌｉｃａｔｉｏｎｓ）１４、４０−４９ページ）は、ユーザが自分の照会を精緻化するときにフィードバックを提供するために、可能な限り多くのタプル（データの行）を表示することに焦点を当てている。このシステムは照会を満たさないタプルも表示し、空間符号化及び色を使用して照会基準からのその「距離」を示している。この手法は、ユーザが選択された照会パラメータのすぐ外に入る重要なデータポイントを見失うのを回避するのに役立つ。しかしながら、ＶｉｓＤＢはデータベースの階層構造を利用できない。例えば、ＶｉｓＤＢはデータを掘り下げ、データを上方にスクロールし、それによりアナリストがデータベースの詳細な部分に集中する前にデータセットの完全な概要を取得できるようにする広範囲な能力は提供しない。このため、ＶｉｓＤＢは階層構造を有するデータベースの探査解析を容易にするために満足の行くツールではない。

２．２．２ 視覚化及びデータマイニング
多くの研究システム及び商業システムは自動化されたデータマイニングアルゴリズムとともに視覚化を使用している。データマイニングとの視覚化の１つの共通の応用例は、アナリストがデータマイニングプロセスによって生成されるモデルを理解するのを手助けすることにある。例えば、複数の研究者が特に決定木、ベイズ的な分類子、及び決定テーブル分類子（Ｂｅｃｋｅｒ、１９９８年情報視覚化の会議録（Ｐｒｏｃ．ｏｆ Ｉｎｆｏｒｍａｔｉｏｎ Ｖｉｓｕａｌｉｚａｔｉｏｎ、１０２−１０５ページ）を表示するための技法を開発し、これらの視覚化技法はＳＧＩのＭｉｎｅＳｅｔ（Ｂｒｕｎｋら、「Ｍｉｎｅｓｅｔ：データマイニングのための統合システム（Ｍｉｎｅｓｅｔ：ａｎ ｉｎｔｅｇｒａｔｅｄ ｓｙｓｔｅｍ ｆｏｒ ｄａｔａ ｍｉｎｉｎｇ）」、知識発見及びデータマイニングに関する第３回国際会議（３ｒｄ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｋｎｏｗｌｅｄｇｅ Ｄｉｓｃｏｖｅｒｙ ａｎｄ Ｄａｔａ Ｍｉｎｉｎｇ、１３５−１３８ページ））などの製品に組み込まれている。
視覚化とデータマイニングを結合する他の手法は、従来焦点が当てられたドメイン内で利用されている。１つの手法はデータベースの初期理解を得て、それからアルゴリズム分析を関心のある特定された分野に適用するために視覚化を使用することである。例えば、Ｔｈｅｒｌｉｎｇら、２００１年、「データマイニングモデルの視覚化（Ｖｉｓｕａｌｉｚｉｎｇ Ｄａｔａ Ｍｉｎｉｎｇ Ｍｏｄｅｌｓ）」、データマイニング及び知識発見における情報視覚化（Ｉｎｆｏｒｍａｔｉｏｎ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｉｎ Ｄａｔａ Ｍｉｎｉｎｇ ａｎｄ Ｋｎｏｗｌｅｄｇｅ Ｄｉｓｃｏｖｅｒｙ）、Ｆａｙｙａｄ、Ｆｒｉｎｓｔｅｉｎ及びＷｉｅｒｓｅ、編集、Ｍｏｒｇａｎ Ｋａｕｆｍａｎｎだけではなく、Ｋｏｈａｖｉ「データマイニング及び視覚化（Ｄａｔａ Ｍｉｎｉｎｇ ａｎｄ Ｖｉｓｕａｌｉｚａｔｉｏｎ）」、フロンティアズオブエンジニアリング：エンジニアリングの最前線に関する２０００年ＮＡＥシンポジウムからの先端エンジニアリングに関する報告書（Ｆｒｏｎｔｉｅｒｓ ｏｆ Ｅｎｇｉｎｅｅｒｉｎｇ：Ｒｅｐｏｒｔｓ ｏｎ Ｌｅａｄｉｎｇ−Ｅｄｇｅ Ｅｎｇｉｎｅｅｒｉｎｇ ｆｒｏｍ ｔｈｅ ２０００ ＮＡＥ ｓｙｍｐｏｓｉｕｍ ｏｎ Ｆｒｏｎｔｉｅｒｓ ｏｆ Ｅｎｇｉｎｅｅｒｉｎｇ）、ナショナルアカデミー出版（Ｎａｔｉｏｎａｌ Ａｃａｄｅｍｙ Ｐｒｅｓｓ）２００１年も参照すること。他の主要な手法はデータのサイズと次元を圧縮するためにデータマイニングを使用し、次に結果を探査するために集中視覚化ツールを使用することである。例えば、Ｗｅｌｌｉｎｇ及びＤｅｒｔｈｉｃｋ、２０００年「大型多次元データセットの視覚化（Ｖｉｓｕａｌｉｚａｔｉｏｎ ｏｆ Ｌａｒｇｅ Ｍｕｌｔｉ−ｄｉｍｅｎｓｉｏｎａｌ ｄａｔａｓｅｔｓ）」、将来の仮想観測所の会議録（Ｐｒｏｃｅｅｄｉｎｇｓ ｏｆ Ｖｉｒｔｕａｌ Ｏｂｓｅｒｖａｔｏｒｉｅｓ ｏｆ ｔｈｅ Ｆｕｔｕｒｅ）だけではなく、Ｈｅａｌｅｙ、１９９８年、グラフィックスインタフェースの会議録（Ｐｒｏｃ．Ｇｒａｐｈｉｃｓ Ｉｎｔｅｒｆａｃｅ，１７７−１８４ページ）も参照すること。
本項に説明される手法の欠点は、それらがある特定のアルゴリズムまたは発見プロセスの単一の段階に集中しているという点である。これらの理由から、既知の視覚化ツール及びデータマイニングツールは、階層構造を有するデータベースを探査、解析するための満足の行く方法とならない。

２．２．３ テーブルベースの表示
関係する研究の別の分野は、テーブルベースの表示を使用する視覚化システムである。散布図行列（Ｈａｒｔｉｇａｎ、統計計算及びシミュレーション誌（Ｊｏｕｒｎａｌ ｏｆ Ｓｔａｔｉｓｔｉｃａｌ Ｃｏｍｐｕｔａｉｏｎ ａｎｄ Ｓｉｍｕｌｔａｔｉｏｎ）４、１８７−２１３ページ）及びトレリス表示（Ｂｅｃｋｅｒ、表示：データマイニングのための多次元データ視覚化ツール（Ｄｉｓｐｌａｙｓ：Ａ Ｍｕｌｔｉ−Ｄｉｍｅｎｓｉｏｎａｌ Ｄａｔａ Ｖｉｓｕａｌｉｚａｔｉｏｎ Ｔｏｏｌ ｆｏｒ Ｄａｔａ Ｍｉｎｉｎｇ）、データベースの知識発見に関する第３回年次会議（Ｔｈｉｒｄ Ａｎｎｕａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｋｎｏｗｌｅｄｇｅ Ｄｉｓｃｏｖｅｒｙ ｉｎ Ｄａｔａｂａｓｅｓ）、１９９７年８月）などのテーブル表示は統計データ分析で広範囲に使用された。しかしながら、このような視覚化の欠点は、それらがデータベース照会を精緻化するため、あるいはそれ以外の場合データベースコンテンツを探査するために、対話することができない静的なグラフィックスを提示するという点である。
対話型テーブル表示も開発された。ピボットテーブルは、アナリストがテーブル軸へのフィールドの割り当てを対話的に指定することによって大型多次元データセットのさまざまな予測を探査できるようにする。しかしながら、ピボットテーブルはテキストベースの表示に限定される。
テーブルレンズ（Ｔａｂｌｅ Ｌｅｎｓ）（Ｒａｏ及びＣａｒｄ、ＳＩＧＣＨＩの会議録１９９４年内のテーブルレンズ：表形式情報の対話型焦点＋コンテキスト視覚化におけるグラフィック表記と記号表記のマージ（Ｔｈｅ Ｔａｂｌｅ Ｌｅｎｓ：Ｍｅｒｇｉｎｇ Ｇｒａｐｈｉｃａｌ ａｎｄ Ｓｙｍｂｏｌｉｃ Ｒｅｐｒｅｓｅｎｔａｔｉｏｎｓ ｉｎ ａｎ Ｉｎｔｅｒａｃｔｉｖｅ Ｆｏｃｕｓ ＋ Ｃｏｎｔｅｘｔ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｆｏｒ Ｔａｂｕｌａｒ Ｉｎ−ｆｏｒｍａｔｉｏｎ））、３１８−３２２ページ）及びＦＯＣＵＳ（ユーザインタフェースソフトウェア及び技術に関するＡＣＭシンポジウムの会議録（Ｐｒｏｃ．ｏｆ ｔｈｅ ＡＣＭ Ｓｙｍｐｏｓｉｕｍ ｏｎ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ Ｓｏｆｔｗａｒｅ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ）、１９９６年１１月）内のＳｐｅｎｋｅら、製品比較及び選択のための対話型テーブル（ＦＯＣＵＳ：Ｔｈｅ ｉｎｔｅｒａｃｔｉｖｅ Ｔａｂｌｅ ｆｏｒ Ｐｒｏｄｕｃｔ Ｃｏｍｐａｒｉｓｏｎ ａｎｄ Ｓｅｌｅｃｔｉｏｎ））視覚化システムは、定量値を伝達するためにセル内の単純なグラフィックスを使用してリレーショナルテーブルビューにデータを提示するテーブル表示を提供する。しかしながら、テーブルレンズは照会をサポートしない。加えて、ＦＯＣＵＳは階層構造を有さないオブジェクト属性テーブルに制限されている。

２．３ 正式のグラフィックプレゼンテーション
多様なソフトウェアプログラムに加えて、既知の技術はさらに正式なグラフプレゼンテーションを提供する。Ｂｅｒｔｉｎのグラフィックスの記号学（Ｓｅｍｉｏｌｏｇｙ ｏｆ Ｇｒａｐｈｉｃｓ）、１９９３年、ウィスコンシン大学出版（Ｕｎｉｖｅｒｓｉｔｙ ｏｆ Ｗｉｓｃｏｎｓｉｎ Ｐｒｅｓｓ）、Ｍａｄｉｓｏｎ Ｗｉｓｃｏｎｓｉｎは、正式化グラフィック技法の早期試みである。Ｂｅｒｔｉｎは、データを記述するための語彙と、前記データをグラフィックに符号化するための技法を開発した。Ｂｅｒｔｉｎは、データが符号化できる網膜の変数（位置、色、サイズ等）を特定する。Ｃｌｅｖｅｌａｎｄ（グラフ化データの要素（Ｔｈｅ Ｅｌｅｍｅｎｔｓ ｏｆ Ｇｒａｐｈｉｎｇ Ｄａｔａ）、１９８５年、ワッズワースアドバンストブックスアンドソフトウェア（Ｗａｄｓｗｏｒｔｈ Ｂｏｏｋｓ ａｎｄ Ｓｏｆｔｗａｒｅ）、カリフォルニア、パシフィックグローブ（Ｐａｃｉｆｉｃ Ｇｒｏｖｅ，Ｃａｌｉｆｏｒｎｉａ）、視覚化データ（Ｖｉｓｕａｌｉｚｉｇ Ｄａｔａ）１９９３年、ホバート出版者（Ｈｏｂａｒｔ Ｐｒｅｓｓ）は、定量的な変動を比較するために人がこれらの異なる網膜特性をどれほどよく使用できるのかを判断するために理論的な結果及び実験的な結果を使用した。
ＭａｃｋｉｎｌａｙのＡＰＴシステム（ＡＣＭ報告書、グラフィックス（ＡＣＭ Ｔｒａｎｓ．Ｇｒａｐｈｉｃｓ、１１０−１４１ページ、１９８６年４月）は、コンピュータ生成表示に対する正式なグラフィック仕様の最初の応用例の１つである。ＡＰＴはリレーショナルデータの二次元表示を自動的に生成するためにグラフィック言語及び組成規則の集合を使用する。Ｓａｇｅシステム（Ｒｏｔｈら、１９９４年、ＳＩＧＣＨＩ会議録（Ｐｒｏｃ．ＳＩＧＣＨＩ）９４年、１１２−１１７ページ）は、ＡＰＴの概念を拡大し、データ特徴付けのより豊富な集合を提供し、より幅広い範囲の表示を生成する）。
Ｌｉｎｙら（ＡＣＭ ＳＩＧＭＯＤ議事録、１９９７年５月）は、視覚照会のデータベース様式処理のための基礎を提供する視覚化モデルを説明している。このモデルの中では、視覚化を生成するために必要な関係照会とグラフィックマッピングが、関係演算子の集合によって定義される。Ｒｉｖｅｔ視覚化環境（Ｂｏｓｃｈら、２０００年、コンピュータグラフィックス、６８−７３ページ）が、柔軟なデータベース視覚化ツールを提供するために類似する概念を適用する。
Ｗｉｌｋｉｎｓｏｎ（グラフィックスの文法（Ｔｈｅ Ｇｒａｍｍｅｒ ｏｆ Ｇｒａｐｈｉｃｓ）、ニューヨーク（Ｎｅｗ Ｙｏｒｋ）、スプリンガー（Ｓｐｒｉｎｇｅｒ）、１９９９年、米国特許第６，４９２，９８９号）は、従来の統計グラフを記述するための言語を開発した。さらに、Ｗｉｌｋｉｎｓｏｎは、その言語で表現できる仕様の部分集合を生成するためのインタフェースを提案している。
これらの既知の正式なグラフィック仕様の欠点とは、それらがデータベース照会を生成するためにいかなるツールを提供しない点である。さらに、Ｂｅｒｔｉｎの研究は純粋に理論的であり、コンピュータプログラムとして実現されたことはなかった。ＡＰＴは既定のデータベース構造を想定し、ユーザの関与なく、またはユーザ関与のための支援なしにグラフィックを自動的に生成する。このようにして、これらの既知の正式なグラフィック仕様はデータベースを分析するための満足の行く方法を提供しない。

２．４ 既知の技術の状態
データベースを視覚的に探査するために使用されるプログラムが説明されてきた。この調査から、既知の視覚化ツール及びデータマイニングツールが階層構造を有するデータベースを探査、解析する満足の行く方法を提供していないことは明らかである。したがって、前記背景を考慮すると、当該技術で必要とされているのは、階層構造を有するデータベースの探査解析を容易にする対話型視覚探査ツールである。

本発明は、既知の技術の欠点に対処する。データベースの探査解析を容易にする対話型視覚探査ツールが提供される。本発明のシステム及び方法は特定のアルゴリズム、発見プロセスの単一の段階、または狭いアプリケーションドメインに集中していない。むしろ、本発明のシステム及び方法は、データベースの初期の理解を得るため、データベースを視覚的に探査するため、データベースの分野間の関係性を理解するため、アルゴリズム出力を理解する為あるいはマイニングモデルを対話的に探査するために使用できる。本発明のシステム及び方法は、アナリストが、さまざまな次元がプレカーサとしてどの程度自動化された発見に関係するのかに関する初期の理解を得るのを支援するためにテーブルレイアウトの多数の次元を符号化する能力を提供する。さらに、本発明のシステム及び方法は視覚マイニングツールとして直接的に使用できる。決定木と分類ネットワークを次元階層としてデータベースに統合することによって、本発明は、これらのモデルがどのようにしてデータを分類するのかに関する理解を得るためにアナリストによって使用されることができる。
本発明は、データを掘り下げ、データを上方へスクロールする広範囲な能力を提供するためにデータベースの階層構造を利用する。データベースが明確に定義された階層構造を有さない例では、本発明は、データベース階層の構築に対処する。いくつかのケースでは、これはユーザ入力と達成される。本発明の方法は、アナリストがデータベースの詳細な部分に集中する前にデータセットの完全な概要を得ることができるようにする新規の形式主義を提供する。本発明は、さらに（意味論的な意味またはアルゴリズム分析から引き出される）複数の階層の同時探査と必要に応じて階層を並べ替える能力の両方をサポートする。
本発明のある態様はグラフィックスを作成するための方法を提供する。前記方法では、第１のデータベースの階層構造が決定される。次に、１つまたは複数のペインを備える視覚的なテーブルが、第１のデータベースの階層構造に基づく言語での仕様を提供することによって構築される。第１のデータベースは、仕様に従ってタプルの集合を検索するために照会され、タプルのこの集合の部分集合は１つまたは複数のペイン内の一つのペインと関連付けられている。いくつかの実施形態では、前記方法はグラフィックマークとしてペイン内のタプルの集合の部分集合内でタプルを符号化することをさらに備える。
いくつかの実施形態では、仕様は、前記１つまたは複数のペインを、要すれば階層的に編成される複数の行及び複数の列に編成する。いくつかの実施形態では、仕様は、前記１つまたは複数のペインを、要すれば階層的に編成される複数の層に編成する。いくつかの実施形態では、仕様は、前記１つまたは複数のペインを階層的に編成される別々のページに編成する。
いくつかの実施形態では、仕様はオペランドを含む代数式を備え、前記代数式は前記第１のデータベースの階層構造における演算を表す。このオペランドは、例えば階層構造の中に出現する型である場合がある。代数式は評価され、それによりタプルの並べられた集合を得る。タプルの順序付けられた集合は、次に、視覚的なテーブルの中で行、列、または層にマッピングされる。このような例では、行、列、または層はタプルの前記並べられた集合内にある同じ順序で提示される。いくつかの例では、代数式は、交差積、和集合、選択または並べ替えなどの関係演算子を含む。いくつかの例では、関係演算子の優先順位はネスト操作（例えば、括弧のｔｈｅ ｕｓｅｄ）により指定される。
本発明のいくつかの実施形態では、仕様は前記１つまたは複数のペインを複数の行及び複数の列に編成し、前記仕様は前記複数の行の第１の代数式と前記複数の列の第２の代数式を備える。このような実施形態では、第１の代数式と第２の代数式の少なくとも１つが第１のデータベースの階層構造における演算を表す。いくつかの実施形態では、仕様は前記１つまたは複数のペインを複数の層に編成し、前記仕様は複数の層の第３の代数式をさらに備える。
本発明のある態様では、第２のデータベースの階層構造が決定される。本発明のこの態様では、仕様が第１のデータベースの階層構造の要素と、第２のデータベースの階層構造の要素とを備える。さらに、仕様は第１のデータベースまたは第２のデータベースから引き出されるタイプタプルとして符号化されるオペランドを含む。
本発明の別の態様では、ビジュアルテーブルのペインと関連付けられたタプルの部分集合内のあるタプルがフィールドを備える。いくつかの例では、前記フィールドは色，値，サイズ、形状、句または記号などのグラフィック属性にマッピングされる。いくつかの例では、フィールドは定量的または序数として分類される。フィールドが定量的と分類されるとき、フィールドは第１のグラフィック属性にマッピングされる。フィールドは、フィールドが序数として分類されるとき、第２のグラフィック属性にマッピングされる。さらに他の例では，フィールドは独立または従属として分類される。フィールドは、フィールドが独立として分類されるとき第１のグラフィック属性にマッピングされる。フィールドは、フィールドが従属として分類されるとき第２のグラフィック属性にマッピングされる。ここでは、第１のグラフィック属性及び第２のグラフィック属性は、それぞれ独立して色、値、サイズ、形状、句、または記号である。
本発明のさらに別の態様では、グループはタプルの集合内のタプルのすべてまたは一部で作成され、グラフィックはグループに基づいて形成される。このグラフィックは、例えば、グループ内の各タプルを結合する線である場合がある。別の例では、グラフィックは、グループ内の各タプルを封入する領域である。いくつかの実施形態では、（例えば、線及び多角形の）複数タプルマークがステップ６１６で作成される。このような例では、複数のタプルに基づく単一のマークが作成される。例えば、米国の州を表現する多角形は単一のマークとして処理できる。
本発明のさらに別の態様では、第１のデータベースが仕様に基づく照会で問い合わされる。本発明のこの態様に従ったいくつかの実施形態では、問い合わせは、構造化問合せ言語（ＳＱＬ）照会またはデータキューブ照会（例えばＭＤＸ照会）などの関係代数演算子に照会をマッピングすることをさらに備える。いくつかの例では、仕様は処理され、それにより本発明の問い合わせプロセスによって実行される照会の数を削減する。ある例では、照会は仕様内の式に横線を引き、仕様内の式を項和に変換し、項和内の項から照会を形成することによって処理される。
本発明のある態様では、複数のデータベース内の各データベースの階層構造が決定される。さらに、仕様は複数のデータベース内の１つまたは複数のデータベースの階層構造に基づいた言語で作成される。本発明のこの態様では、問い合わせは複数のデータベース内のデータベースのすべてまたは一部を備える。
本発明に従った別の態様では、複数のデータベース内の各データベースの階層構造が決定される。さらに、言語は前記複数のデータベース内のデータベースのすべてまたは一部の階層構造に基づいている。前記複数のデータベースのすべてまたは一部は問い合わせされる。さらに、タプルの集合は前記複数のデータベースのすべてまたは一部から引き出されるタプルを含む。本発明のこの態様による１つの実施形態では、仕様が前記１つまたは複数のペインを複数の層に編成し、前記複数の層の各層が前記複数のデータベース内の別のデータベースからタプルに割り当てられる。本発明のこの態様による別の実施形態では、仕様は複数の列及び複数の行に編成し、前記複数の列の各列が前記複数のデータベース内の別のデータベースからタプルに割り当てられる。本発明のこの態様に従うさらに別の実施形態では、仕様は前記１つまたは複数のペインを複数の列と複数の行に編成し、前記複数の行の各行は前記複数のデータベース内の別のデータベースからタプルに割り当てられる。本発明のこの態様に従ったさらに別の実施形態では、仕様は、前記１つまたは複数のペインを複数のページに編成し、前記複数のページ内の各ページは前記複数のデータベース内の別のデータベースからタプルに割り当てられる。
本発明のさらに別の態様では、第１のデータベースの前記階層構造が複数のスキーマフィールドを含む。本発明のこの態様では、視覚的なテーブルの構築が、前記仕様に基づいて前記１つまたは複数のペイン内の１つのペインに前記複数のスキーマフィールド内のスキーマフィールドを割り当てることをさらに備える。さらに、前記ペインに関連付けられるタプルの集合の部分集合が選択関数によって決定される。いくつかの実施形態では、前記選択関数が前記スキーマフィールドのアイデンティティを使用する。いくつかの実施形態では、選択関数は部分集合を形成するために（選択演算子またはグループ化演算子などの）関係演算子を使用する。いくつかの実施形態では、選択関数はペインと関連付けられるタプルの部分集合から新しいタプルを作成するために（並べ替え演算子、集約演算子、変換演算子等の）関係演算子を使用する。
本発明の別の態様では、ビジュアルテーブルを前記構築すること、データベースの前記問い合わせ、及びタプルの部分集合のペインへの前記関連付けが、前記ペインと関連付けられるタプルの集合の部分集合によって決定される仕様を使用して繰り返される。いくつかの例では、これらのステップは、ユーザによって選択されるタプルの部分集合内の１つまたは複数のタプルを使用して繰り返される。
本発明のさらに別の態様では、第１のデータベースがスキーマを有し、言語はこのスキーマの複数のフィールドを備える。さらに、ビジュアルテーブルは複数の軸を備え、前記複数の軸の内の各軸がシェルフによって表される。仕様は１つまたは複数の代数式を備える。１つのこのような代数式は、ビジュアルテーブルの軸を表すシェルフの上にデータベーススキーマ内の複数のフィールドの内の１つのフィールドをドラッグし、それにより仕様内の代数式を構築することによって作成される。
本発明のさらに別の態様では、仕様は（例えば、ブックマーク、取消操作、やり直し操作等として）記憶される。いくつかの実施形態では、第１のデータベースはフラットファイル、関係型データベース、またはオンライン分析処理データベースである。いくつかの実施形態では、第１のデータベースは階層オンライン分析処理データキューブである。いくつかの実施形態では、第１のデータベースは明白に定義された階層を有していない。これが当てはまるとき、第１のデータベース内のデータフィールドはデータベース内の階層構造を決定するために分析される。いくつかの実施形態では、第１のデータベースはデータベースの階層構造を決定するために分析されるスタースキーマを有する。いくつかの実施形態では、第１のデータベースがリモートコンピュータによってホストされる。
本発明のさらに別の態様は、コンピュータシステムと関連して使用するためのコンピュータプログラム製品を提供する。コンピュータプログラム製品はコンピュータ読み取り可能記憶媒体と、その中に埋め込まれるコンピュータプログラム機構を備える。コンピュータプログラム機構は、（ｉ）第１のデータベースと、（ｉｉ）第１のデータベースの階層構造を決定するための命令を備えるデータベース階層モジュールと、（ｉｉｉ）第１のデータベースの階層構造に基づいた言語での仕様をユーザから取得することによって、１つまたは複数のペインから構成される、ビジュアルテーブルを構築するための命令を備えるユーザインタフェースモジュールと、（ｉｖ）仕様に従ってタプルの集合を取り出すために第１のデータベースを問い合わせするための命令を備えるデータインタプリタモジュールと、（ｖ）１つまたは複数のペイン内の１つのペインとタプルの集合の部分集合を関連付けるための命令を備えるビジュアルインタプリタモジュールとを備える。
本発明のさらに別の態様は、グラフィックスを作り出すためのコンピュータシステムを提供する。コンピュータシステムは中央処理装置及び中央処理装置に結合されるメモリを備える。前記メモリは、（ｉ）第１のデータベースと、（ｉｉ）第１のデータベースの階層構造を決定するための命令を備えるデータベース階層モジュールと、（ｉｉｉ）第１のデータベースの階層構造に基づいた言語での仕様をユーザから得ることによって、ビジュアルテーブルを構築するための命令を備え、１つまたは複数のペインから構成されるユーザインタフェースモジュールと、（ｉｖ）仕様に従ってタプルの集合を取り出すことによって、第１のデータベースに問い合わせるための命令を備えるデータインタプリタモジュールと、（ｖ）タプルの集合の部分集合を１つまたは複数のペイン内の１つのペインと関連付けるための命令を備えるビジュアルインタプリタモジュールとを記憶する。

本発明は、データベース内に存在する階層情報を、このようなデータベースの探査を容易にするために利用する方法を提供する。本発明はこのタスクを達成するために新規の公式主義を使用する。ユーザは、本発明の新規の形式主義と一貫している検索照会を入力できる。このような検索照会が構築されると、本発明のシステム及び方法は、既知のデータ探査プログラム及び技法で発見されるデータベース関数を消費するより少ない存在走査及び他の時間のかかるデータベース関数を使用して、照会にサービスを提供するためにターゲットデータベースと関連付けられる形式主義及び階層情報を利用する。本発明の追加の特徴及び優位点は以下の項に説明される。

５．１ 例示的なシステムの概要
図５は、本発明のある実施形態に従って、データウェアハウスなどのデータベースの探査解析を容易にするシステム５００を示す。
システム５００は、好ましくは、
・中央演算処理装置５２２
・好ましくはソフトウェアとデータを記憶するための１つまたは複数のハードディスクドライブ含むメイン不揮発性記憶装置５３４であって、ディスクコントローラ５３２によって通常制御される記憶装置５３４と、
・不揮発性記憶装置５３４からロードされるプログラム及びデータを含むシステム制御プログラム、データ、及びアプリケーションプログラムを記憶するための好ましくは高速ランダムアクセスメモリ（ＲＡＭ）であるシステムメモリ５３８であって、読取専用メモリ（ＲＯＭ）も含むシステムメモリ５３８と、
・マウス５２６、キーパッド５３０、及びディスプレイ５２８などの１つまたは複数の入力装置を含むユーザインタフェース５２４と、
・任意の結線された通信網と無線通信網に接続するためのオプションのネットワークインタフェースカード５３６と、
・システムの前述の要素を相互接続するための内部バス５３３と、
を含むコンピュータ５０２を備える。
コンピュータ５０２の動作は、おもに、中央処理装置５２２によって実行されるオペレーティングシステム５４０によって制御される。オペレーティングシステム５４０は、システムメモリ５３８に記憶できる。オペレーティングシステム５４０に加えて、システムメモリ５３８の典型的なインプリメンテーションは、
・本発明により使用される多様なファイル及びデータ構造へのアクセスを制御するためのファイルシステム５４２と、
・（例えば、データベーススキーマを解釈することによって）データベース５５８の階層を解釈するためのデータベース階層モジュール５４４と、
・データベース５５８の階層構造に基づいた言語での仕様をユーザから得ることによって、１つまたは複数のペインから構成される、ビジュアルテーブルを構築するための）ユーザから視覚的仕様（仕様）を得るためのユーザインタフェースモジュール５４６と、
・（仕様に従ってタプルの集合を取り出すためにデータベース５５８に問い合わせるための）仕様に基づいてデータベース照会を公式化するためのデータインタプリタモジュール５５２と、
・（１つまたは複数のペイン内の１つのペインとタプルの集合の部分集合を関連付けるための）仕様に従って、データベース照会結果を処理し、これらの結果を表示するためのビジュアルインタプリタモジュール５５６と、
を含む。
好適実施形態では、ユーザインタフェースモジュール５４６は、
・データベース５５８の階層に対応するデータベース階層５４８と、
・システムによって実行される正確な分析動作、照会動作、及び描画動作を決定するために使用できる形式主義を指定する視覚的仕様５５０と、
を含む。
好適実施形態では、データインタプリタモジュール５５２は、
・データベースを照会するために使用される１つまたは複数の照会記述５５４と、
・データベース照会結果を記憶するために使用される照会キャッシュ５５５と、
・ビジュアルインタプリタモジュール５５６によって表示されるビジュアルテーブル７２０内の各ペイン７２２（図７）のための別個のデータ構造を記憶するために使用されるペイン−データ−キャッシュ５５７と、
を含む。
システム５００は１つまたは複数のデータベース５５８を含む。ある実施形態では、データベース５５８は、多次元データキューブとして概念的に表示できるＯＬＡＰデータである。例えば、第５．３項を参照すること。さらに一般的には、データベース５５８は、フラットファイル、関係型データベース（ＳＱＬ）、及びＯＬＡＰデータベース（ＭＤＸ及び／またはその変形）を含むがこれらに限定されない任意の形式のデータ記憶装置システムである。いくつかの特定の実施形態では、データベース５５８は階層ＯＬＡＰキューブである。いくつかの特定の実施形態では、データベース５５８はキューブとして記憶されないが、階層を定義するディメンションテーブルを有するスタースキーマを備える。なおさらに、いくつかの実施形態では、データベース５５８は、（ディメンションテーブルは階層的に配列されないなど）根本的なデータベースまたはデータベーススキーマ内で明示的に出現しない階層を有する。このような実施形態では、それぞれのデータベース５５８の階層情報を引き出すことができる。例えば、いくつかの実施形態では、データベース階層モジュール５４４は、データベース５５８を読み取り、データベースに記憶されるデータを表す階層を作成する。いくつかの実施形態では、この外部プログラムはユーザ入力とともに実行される。いくつかの実施形態では、単一のデータベース５５８しかない。
典型的な実施形態では、データベース５５８の１つまたは複数はコンピュータ５０２によってホストされない。むしろ、典型的な実施形態では、データベース５５８はネットワークインタフェース５３６を使用してコンピュータ５０２によってアクセスされる。いくつかの実施形態では、属性ファイル５８０が各データベース５５８と関連付けられる。属性は以下の第５．３．６項に説明される。
図５に描かれているモジュールの多くはリモートコンピュータ上に位置できることが理解されるであろう。例えば、本願のいくつかの実施形態はウェブサービス型のインプリメンテーションである。このような実施形態では、ユーザインタフェースモジュール５４６は、ネットワーク（不図示）を介してコンピュータ５０２と通信するクライアントコンピュータに常駐できる。いくつかの実施形態では、ユーザインタフェースモジュール５４６がクライアントコンピュータにコンピュータ５０２によってサービスを提供される対話型ウェブページである場合がある。さらに、ビジュアルインタプリタモジュール５５６の構成要素のいくつかまたはすべては、照会の結果がクライアントコンピュータに表示されるようにクライアントコンピュータに常駐できる。このようにして、本発明は、リモートサイトから本発明の技法及び方法を使用して１つまたは複数のデータベース５５８を探査できるインプリメンテーションの幅広いアレイを完全に含む。単一の中央コンピュータ内の図５のモジュールの例証は、本発明の多様な実施形態で使用され、決して制限的ではない特定のソフトウェアモジュール及びデータ構造を簡潔に図解するために提示されているにすぎない。当業者は、多数の他の構成が考えられ、すべてのこのような構成は本発明の範囲内にあることを理解する。
本発明の１つの実施形態に従ったシステム５００の概要は説明されたので、本発明にかかる多様な有利な方法が以下の項で開示される。

５．２ 例示的な方法
図６を参照すると、本発明のある実施形態にかかる例示的な方法が図解される。
ステップ６０２。ステップ６０２では、それぞれの選択されたデータベース５５８の階層が特徴付けられる。選択されたデータベース５５８がこのような階層情報を含むスキーマ５６０を有する実施形態では、スキーマ５６０はデータベース階層モジュール５４４によって直接的に読み取ることができ、このスキーマ５６０のデータベース階層５６２を特徴付けることができる。第５．３項は、データベース階層５６２の例示的なタイプとデータ編成を説明する。いくつかの実施形態では、複数のデータベース５５８は同時に分析される。このような実施形態では、複数のデータベース５５８のそれぞれのデータベーススキーマ５６０がデータベースモジュール５４４によって直接的に読み取られ、特徴付けられる。いくつかの実施形態では、選択されたデータベース５５８は、根本的なそれぞれのデータベース５５８に明示的に定義される階層を有さない。このような実施形態では、データベース階層モジュール５４４はそれぞれの選択されたデータベース５５８を分析し、それぞれのデータベースごとにデータベース階層情報を構築する。いくつかの例では、この分析はユーザからの入力によって支援される、及び／またはデータベースに記憶されるデータの分析を必要とする。
いくつかの実施形態では、データベース５５８の階層構造は、データベース５５８のためのデータベーススキーマから引き出される。このデータベーススキーマはスキーマフィールドを備える。いくつかの実施形態では、各スキーマフィールドは（例えば、ベース型またはアレイ型などの）型を有する。代表的なベース型は、文字列、整数、短整数、倍整数、単精度浮動小数点数、 倍精度浮動小数点数、及びオブジェクトハンドルを含むが、これらに限定されない。代表的なアレイ型は、倍長整数のアレイ、短整数のアレイ、単精度浮動小数点数のアレイ、倍精度浮動小数点数のアレイ、及びオブジェクトハンドルのアレイを含むが、これらに限定されない。
ステップ６０４。ステップ６０４では、視覚的仕様（仕様）５５０がユーザインタフェースモジュール５４６によってユーザから得られる。好適実施形態では、視覚的仕様５５０は、ユーザインタフェースモジュール５４６によって提供されるドラッグアンドドロップインタフェースを使用して作成される。例示的なユーザインタフェースモジュール５４６が図７に描かれている。ユーザは、スキーマボックス７０２から多様なシェルフ７０８まで、インタフェース全体でオペランド名をドラッグすることにより視覚的仕様を作成する。これらのオペランド名は、ステップ６０２で特徴付けられた各選択データベース５５８の階層構造から引き出される。例えば、データベース内での探査のために使用可能な次元の１つは「時間」であろう。次に、スキーマボックス７０２で使用可能な可能性があるオペランド名は、「年」、「四半期」、「月」及び「日」であろう。これらのオペランド名のそれぞれはタイプタプルと呼ばれる。いくつかの実施形態では、ステップ６０２で複数のデータベース６０２が特徴付けられる。さらに、仕様５５０はステップ６０２に特徴付けられる第１のデータベース５５８の階層構造の第１の要素と、ステップ６０２で特徴付けられる第２のデータベースの階層構造の第２の要素とを備えることがある。第１の要素は第１のデータベース５５８から引き出されるタイプタプルを備え、第２の要素は第２のデータベース５５８から引き出されるタイプタプルを備える。
図７のスキーマボックス７０２は、分析されている１つまたは複数のデータベース５５８のそれぞれのデータベーススキーマの表現を含む。スキーマボックス７０２は、分析されている各データベース５５８の各スキーマ５６０で表現される各次元７０４を含む。例えば、図７では、次元「時間」７０４−１、「製品」７０４−２、及び「場所」７０４−３を含む単一のデータベースが分析される。時限のレベルの順序付けられたリストは各次元の下に配置される。例えば、時間７０４−１のケースでは、順序付けられたリストが次元レベル「年」、「四半期」及び「月」を含む。製品のケースでは、順序付けられたリストは次元レベル「ｐｒｏｄｕｃｔｔｙｐｅ（製品種別）」と「製品」を含む。場所のケースでは、順序付けられたリストは次元レベル「マーケット」と「州」を含む。
ユーザは、シェルフ７０８のインタフェースの中に任意の次元レベルをドロップできる。しかしながら、次元７０４はシェルフの中にドラッグできない。シェルフ７０８−４と７０８−５は軸シェルフである。（例えば、年、四半期、月、製品種別、製品、市場、州などの）シェルフ７０８−４と７０８−５に配置されるオペランドは、ビジュアルテーブル７２０の構造と、ビジュアルテーブル７２０の各ペイン７２２に配置されるグラフのタイプを決定する。例えば、図７では、次元「製品種別」に属する値「売上高」がシェルフ７０８−４に配置される。したがって、ビジュアルテーブル７２０のｙ軸は「製品種別」ごとの売上高の内訳である。有効な製品種別は「コーヒー」、「エスプレッソ」、「ハーブティー」、及び「お茶」を含む。このようにしてビジュアルテーブル７２０のｙ軸はこれらの製品のそれぞれの売上高を表す。図７では、（次元「時間」の一部である）オペランド「Ｑｕａｒｔｅｒ（四半期）」に属する値「ｐｒｏｆｉｔ（利益）」がシェルフ７０８−５に配置された。このようにして、ビジュアルテーブル７２０のｘ軸は利益を表す。詳細シェルフ７０８−２のレベルは州に設定された。相応して、ビジュアルテーブル７２０内の各ペイン７２２の各マークがある特定の集のデータを表す。
シェルフ７０８（図７）上のオペランドの構成は、視覚的仕様５５０（図５）を形成する。最小限で、視覚的仕様５５０がｘ軸式とｙ軸式を含む。さらに通常、視覚的仕様５５０は、さらにシェルフ７０８−１に設置されるｚ軸及び詳細な説明のレベルｚ軸式を含む。代表的な視覚的な仕様５５０は、図１１（要素５５０）に提供される。視覚的な仕様は以下の式を含み、
ｘ：Ｃ＊（Ａ＋Ｂ）
ｙ：Ｄ＋Ｅ
ｚ：Ｆ
各ペイン７２２内の詳細のレベルは以下に設定される。
詳細なレベル：Ｇ
いくつかの実施形態では、ユーザは第５．４項に説明される代数（例えば、序数の連結等の）のいずれかを指定できる。いくつかの実施形態では、図７に描かれているものなどのユーザインタフェースを直接的に使用する代数のユーザ型は、次に解釈されるファイルの中にそれを含むか、当該技術で既知のなんらかの他の形式のデータエントリを使用する。
いくつかの実施形態では、ビジュアルテーブル７２０の軸を表す各シェルフ７０８は自動的に対応する式に変換される。例えば、ｘ軸を表すシェルフ７０８の内容は、ビジュアルテーブル７２０のｘ軸を表す式に変換され、ｙ軸を表すシェルフ７０８は、ビジュアルテーブル７２０のｙ軸を表す式に変換され、層を表すシェルフ７０８は、ビジュアルテーブル７２０のｚ軸を表す式に変換される。各軸シェルフ７０８の内容はデータベースフィールド名の並べられたリストである。いくつかの実施形態では、データベースフィールド名の順序は、すべての名目フィールドと序数フィールドがシェルフ内のすべての定量的なフィールドに先行するように制約される。例示的な名目フィールドは、製品、領域、アカウント番号、人を含むがそれらに限定されない。例示的な序数フィールドは、日付と優先順位ランキングを含むが、これらに限定されない。例示的な定量フィールドは、利益、売上高、口座残高、速度または頻度を含むが、これらに限定されない。データベースフィールド名の順序が、すべての名目フィールドと序数フィールドがシェルフ７０８内のすべての定量フィールドに先行するように制約される実施形態では、名目フィールドは配列を割り当てられ、序数として処理される。この配列は（アルファベット、数値などの）自然な配列またはユーザによって指定される配列のどちらかである。次に、それぞれのシェルフ内のフィールドのリストが以下の形式の式に変換される。
（Ｑ₁×Ｑ_２．．．×Ｑ_ｎ）×（Ｑ₁×Ｑ_２．．．×Ｑ_ｍ）
さらに、任意の２つの隣接するカテゴリのフィールドが同じ次元を表す場合には、それらの間の交差「ｘ」演算子（第５．４．２２項を参照すること）はドット「．」演算子（第５．２．４．２項を参照すること）で置換される。仕様はビジュアルインタプリタモジュール５５６によってデータベース５５８から視覚プロパティにデータ値をマッピングするために使用される。「単位のペイン内のグループ」（不図示）及び「単位のペイン内のソート」（７０８−３、図７）と名付けられる追加のシェルフが視覚的仕様の「グループ」と「ソート順」を定める。
いくつかの実施形態では、仕様は、ステップ６０２で特徴付けられた前記１つまたは複数のデータベース５５８のメタデータ（例えば階層構造）に基づく言語で作成される。最小でも、この言語は前記１つまたは複数のデータベース５５８の階層を構成する次元レベルのすべてまたは一部を備える。次元レベル（例えば、年、四半期、月等）の例は説明された。通常、これらの次元レベルは、図７に示されているようにユーザインタフェース５２４に表示される。いくつかの実施形態では、言語が、ユーザが１つまたは複数のペイン７２２から構成される複雑なビジュアルテーブルを形成できるようにする（図７）以下の第５．４項に説明される代数などのテーブル代数をさらに含む。仕様５５０が、代数式の形式のテーブル代数を利用する実施形態では、仕様は少なくとも１つのオペランドを含む。オペランドは、代数式に包含するために選択されたデータベーススキーマ（または他のデータベースメタデータ）からの次元レベルまたは約数／定量変数である。前記少なくとも１つのオペランドに加えて、代数式は、ステップ６０２で特徴付けられた前記１つまたは複数のデータベース５５８のメタデータに対する演算を表す１つまたは複数の演算子を含む。このような演算子の例は、交差積（第５．４．２．２項）、和集合、選択または並べ替えなどの関係演算子を含むが、これらに限定されない。演算子の他の例は、ネスト演算子（第５．４．２．３項）、及びドット演算子（第５．４．２．４項）を含むが、これらに限定されない。ネスト演算子はデータベース内のファクトテーブルを解析するが、ドット演算子（第５．４．２．４項）を含むが、これらに限定されない。前記ネスト演算子はデータベース内のファクトテーブルを分析するが、ドット演算子がデータベース５５８階層を定めるデータベース５５８と関連付けられるディメンションテーブル（つまり同等なデータ構造）を分析する。ネスト演算子（第５．４．２．３項）単位のファクトテーブルまたはドット演算子（第５．４．２．４項）単位のディメンションテーブル（または同等なデータ構造）の分析は、前記関連データベース５５８の前記階層構造に対する演算を表す。前記代数式内の演算及び演算子はネスト化できる。例えば、１つの実施形態では、演算子が検討される順序を改変するために括弧が使用される。
本発明の好適態様では、視覚的仕様５５０は、複数の行と複数の列にペイン７２２を編成する。本発明のこの態様に従った実施形態では、視覚的仕様５５０は前記複数の行の第１の代数式と、前記複数の列の第２の代数式を含む。前記第１の代数式と第２の代数式の両方は、それぞれ、ステップ６０２で特徴付けられた（例えば階層構造などの）データベース５５８のメタデータに対する演算を表す。本発明のこの態様に従ったいくつかの例では、仕様は複数の層に１つまたは複数のペイン７２２をさらに編成する。これを達成するためには、仕様５５０は複数の層のための第３の代数式をさらに備える。第３の代数式はステップ６０２に特徴付けられたデータベース５５８の１つまたは複数のメタデータの演算を表す。例えば、第１の２つの代数式はすべての積についての収益をカバーできるであろうが、第３の代数式は、各層が状態ごとの積によって収益を表すように次元「州」を追加できるであろう。
本発明の方法を使用すると、各視覚的仕様５５０は、システム５００によって実行される正確な分析演算、照会演算及び描画演算を決定するために解釈できる。好適実施形態では、描画演算はビジュアルテーブル７２０の各ペイン７２２では独立して実行される。
ビジュアルテーブル７２０は、３本の軸を含む。ｘ軸とｙ軸はそれぞれ、前述されたようにシェルフ７０８−５と７０８−４によって決定される。ｚ軸はシェルフ７０８−１（図７）によって決定される。ｘ軸、ｙ軸及びｚ軸の各交点が、テーブルペイン７２２を生じさせる。各ペイン７２２は、データベース５５８に問い合わせすることによって得られるレコードの集合を含む。シェルフ７０８−１、７０８−４、及び７０８−５はビジュアルテーブル７２０の外側レイアウトを決定するが、ディスプレイ７００内の他のシェルフ７０８がペイン７２２内のレイアウトを決定する。いくつかの実施形態では、この内側レイアウトはオペランドの並べ替え及びフィルタリング、ビジュアルテーブル７２０のｚ軸の特定の層に対する特定のデータベース５５８のマッピング、ペイン７２２内のデータのグループ化、及び統計特性と引き出されたフィールド、各ペイン７２２に表示されるグラフィックのタイプ（例えば、円、バー、グリフ等）の計算、及び（例えば、マークのサイズに「利益」をマッピングし、「四半期」を色にマッピングするなどの）ビジュアルテーブル内のマークの網膜特性へのデータフィールドのマッピングを含む。
ステップ６０６。ステップ６０６では、効率的な照会の集合は、仕様５５０に基づくデータインタプリタモジュール５５２によって形成される。データベースに特定の照会を生成する前に、データインタプリタモジュール５５２は、視覚的仕様５５０に指定される値（例えばシェルフ７０８−１、７０８−４及び７０８−５に配置される値）を使用して必要とされる照会を記述する１つまたは複数の抽象的な照会記述５５４の集合を生成する。照会記述５５４は、データベース５５８のタプルの所望されるフィルタリング、並べ替え及びグルーピングを正確に記述する。
単一の視覚的仕様５５０について生成される異なった照会記述５５４の数は視覚的仕様５５０に指定される詳細のレベルにより決定される。例えば、ビジュアルテーブル（図１０）は、ビジュアルテーブル７２０（図１０）はｙ軸式の連結演算子を使用するために、２つの別々の照会が生成することを必要とする単純テキストベースのビジュアルテーブル７２０を示す。いくつかの実施形態では、ビジュアルテーブル７２０内のペイン７２２内の詳細のレベルは詳細のレベルシェルフ７０８−２とシェルフ７０８−１、７０８−４、及び７０８−５（図７）に形成されるテーブル代数式の両方によって決定される。
各ペイン７２２は別の詳細のレベル、したがって別の照会に対応することができるが、一般的な状況では、さらに多数のペイン７２２（図７）が、同じ詳細のレベルに対応し、タプルがどのようにしてフィルタリングされるかによってのみ異なる。効率化のため、グループと同じレベルの詳細を必要とし、適切なタプルを要求するデータベース５５８に単一の照会を送信するペイン７２２を考慮することが好ましい。タプルは、次に以後の処理ステップで局所的にペイン７２２に区分できる。したがって、本発明の１つの態様では、データベース照会がグループ化される。いくつかの実施形態では、これは既定のビジュアルテーブル７２０に必要とされる照会を決定するために視覚的仕様５５０を代数的に操作することにより達成される。本発明の代数で使用される代数演算子のすべての内（例えば、以下の第５．４項を参照すること）、予測または詳細のレベルが異なる隣接するペイン７２２を生成できる演算子は、連結演算子である。以下の第５．４項にさらに詳細に説明されるネスト、交差、及びドットは各出力ｐ−タプルにすべての入力次元レベルを含む。連結は含まない。したがって、視覚的仕様５５０内の各軸の式が項和形式に縮小される場合、結果として生じる項は、１つまたは複数のデータベース５５８から取り出される必要がある照会の集合に対応するであろう。
各軸の項和の縮小を図解するためには、図１１で例示的な視覚的仕様５５０を検討し、
ｘ：Ｃ*（Ａ＋Ｂ）
ｙ：Ｄ＋Ｅ
ｚ：Ｆ
各ペイン７２２内の詳細のレベルがＧに設定される。これらの式を、以下の第５．４項に指定されるテーブル代数に従って横線を引き、次に項和形式に縮小すると、以下が生じる。
（Ａ*Ｃ*Ｄ*Ｆ*Ｇ）＋（Ａ*Ｃ*Ｅ*Ｆ*Ｇ）＋（Ｂ*Ｃ*Ｄ*Ｆ*Ｇ）＋（Ｂ*Ｃ*Ｅ*Ｇ）
したがって、この例では、以下の４つのデータベース照会が行われる。
（Ａ*Ｃ*Ｄ*Ｆ*Ｇ） 照会１
（Ａ*Ｃ*Ｅ*Ｆ*Ｇ） 照会２
（Ｂ*Ｃ*Ｄ*Ｆ*Ｇ 照会３
（Ｂ*Ｃ*Ｅ*Ｇ） 照会４
大部分の典型的な多次元照会言語は、照会１−４で発見される形式の照会を生成するための機構を提供する。例えば、照会１−４のそれぞれは、単一の多次元式（ＭＤＸ）照会である場合がある。ＭＤＸ（マイクロソフト、レドモンド、ワシントン（Ｍｉｃｒｏｓｏｆｔ、Ｒｅｄｍｏｎｄ Ｗａｓｈｉｎｇｔｏｎ））は、多次元オブジェクトとデータの定義及び操作をサポートする構文である。ＭＤＸは、構造照会言語（ＳＱＬ）構文に類似しているが、ＳＱＬ言語の拡張ではない。ＳＱＬ照会でのように、各ＭＤＸ照会はデータ要求（ＳＥＬＥＣＴ節）、開始点（ＦＲＯＭ節）、及びフィルタ（ＷＨＥＲＥ節）を必要とする。これらの及び他のキーワードは、分析のための階層データベース（例えば、立方体）からデータの特定の部分を抽出するために使用されるツールを提供する。要約すると、各照会はＳＱＰ照会などの関係代数演算子に、または（例えばＭＤＸ照会などの）データキューブ照会にマッピングできる。
どのように視覚的仕様５５０が照会の効率的な集合に縮小されるのかの概要が提示されたので、本発明の１つの実施形態で使用される詳細なアルゴリズムが説明される。アルゴリズムは以下の擬似コードに述べられる。
１０１：ｘ−項＝ｘ軸式の項和からの項のリスト
１０２：ｙ−項＝ｙ軸式の項和からの項のリスト
１０３：ｚ−項＝ｚ軸式の項和からの項のリスト
１０４：各層の場合｛
１０５： ｘ項内の各ｘ項の場合｛
１０６： ｙ項内の各ｙ項の場合｛
１０７： ｚ項内の各ｚ項の場合｛
１０８： ｐ−ルックアップ＝純粋探索記述子（ＰｕｒｅＬｏｏｋｕｐＤｅｓｃｒｉｐｔｏｒ）（ｘ項、ｙ項、ｚ項）
１０９：ｐ−ｓｐｅｃ＝ｐ−ルックアップに適用するペイン仕様（ＰａｎｅＳｐｅｃｉｆｉｃａｔｉｏｎ）
１１０：ｑｄ＝新しい照会説明（ＱｕｅｒｙＤｅｓｃｒｉｐｔｉｏｎ）
１１１：ｘ項内のすべてのフィールドをｑｄに追加する
１１２：ｙ項内のすべてのフィールドをｑｄに追加する
１１３：ｚ項内のすべてのフィールドをｑｄに追加する
１１４：ｐスペック内のデータフィールドのすべてのレベルをｑｄに追加する
１１５：ｐスペック内のすべての描画順序フィールドをｑｄに追加する
１１６：ｐスペック内のすべての符号化フィールドをｑｄに追加する
１１７：ｑｄ内のフィールドを含む視覚的仕様内のすべてのフィールドをｑｄに追加する
１１８：ｑｄではフィールドを含む視覚的な仕様内のすべてのフィールドをｑｄに追加する
１１９：（ｑｄがデータキャッシュ内のデータに一致する）場合
１２０：結果＝データキャッシュからデータを取り出す
１２１：さもないと
１２２：結果＝データベースサーバからデータを取り出す
１２３：ｑｄ単位で索引が付けられたデータキャッシュに結果を追加する
１２４：グループ−ｔｓｆ＝グループ変換（ＧｒｏｕｐｉｎｇＴｒａｎｓｆｏｒｍ）を作成する
１２５：グループ−ｔｓｆを実行する
１２６：グループ−ｔｓｆからペイン−データ−キャッシュに各出力データ構造を追加する｝｝｝
擬似コードのライン１０１から１０３は、視覚的仕様５５０の各軸が項和に縮小されるケースを表現する。ライン１０４から１０７は、項ｉのそれぞれを個別に検討するために使用される。個々に、各項ｉが視覚的なテーブル７２０の中に行の集合、列の集合、または層の集合のどれかを記述する。ともに、項は、すべて同じ詳細のレベル７０８−６（図７）にあるペイン７２２の集合を定める。したがって、ライン１０４から１０７は「各ｘ項、ｙ項、ｚ項の組み合わせごとに」と読み取ることができる。
ライン１０８と１０９は、ある特定のｘ項、ｙ項、ｚ項の組み合わせによって定められるペイン７２２についてマーク、符号化等を定めるペイン仕様を見つけるために使用される。これは視覚的仕様内の各ペイン仕様内の選択基準多項式術語に突き合わせてｐ−ｌｏｏｋｕｐを試験することにより行われる。
ライン１１０から１１８は、特定のｘ項、ｙ項、ｚ項の組み合わせの照会を構築する。ライン１１０は照会を保持するために変数「ｑｄ」を生じさせ、ライン１１１から１１３は特定のｘ項、ｙ項、ｚ項の組み合わせでｘ項、ｙ項及びｚ項内のすべてのフィールドを追加する。ライン１１４から１１８は詳細のレベルなどの視覚的仕様５５０から追加の項を照会に追加する。
次に、ライン１１９から１２２では、ライン１１０から１１８によって構築される形式の照会がデータキャッシュ（照会キャッシュ５５５、図５）内にすでに存在するかどうかに関して決定が下される。すでに存在する場合には、結果がデータキャッシュから取り出される（ライン１２０、照会キャッシュ５５５から、図５）。すでに存在しない場合、ターゲットデータベース５５８をホストするサーバがライン１１０から１１８によって構築される照会を使用して問い合わせされる（ライン１２２）。このようなデータベース照会が行われると、データインタプリタモジュール５５２は、データベースに特殊な様式で照会を公式化するであろう。例えば、特定の例では、データインタプリタモジュール５５２はＳＱＬ照会を公式化するが、他の例ではデータインタプリタモジュール５５２はＭＤＸ照会を公式化するであろう。ライン１２３では、照会の結果はデータキャッシュに追加される（照会キャッシュ５５５、図５）。
前記処理ステップで検索されるデータがペイン７２２の集合についてデータを含む場合がある。これが当てはまるとき、データは集約演算を実行するよりむしろグループごとに別々のデータ構造が作成されるのを除き、ＳＱＬで「ＧＲＯＵＰ ＢＹ」と概念上同じであるグループ化変換（ライン１２４から１２５）を使用してペイン７２２ごとに別々のデータ構造に区分化される。ライン１２６では、グループ−ｔｓｆからの各出力データ構造が、ビジュアルインタプリタモジュール５５６による後の使用のためにペイン−データ−キャッシュ５５７（図５）に追加される。
ステップ６０８。ステップ６０８では、ステップ６０８で作成される照会は、１つまたは複数のデータベース５５８に問い合わせをするために使用される。このようなデータベース５５８はメモリ５４８に記憶できる。しかしながら、さらに好適の実施形態では、これらのデータベース５５８はリモートサーバに記憶される。
ステップ６１０。ステップ６１０では、ビジュアルインタプリタモジュール５５６が、データインタプリタモジュール５５２により生成された照会を処理する。これらの照会を処理するために多くのステップが実行される。これらのステップの概要は図１１に描かれている。ステップ６１２では、視覚的仕様５５０が正規化集合形式１１０４に縮小される。ステップ６１４では、ビジュアルテーブル７２０は正規化集合形式を使用して構築される。ステップ６１６では、照会結果はビジュアルテーブル７２０のペイン７２２に対応するタプルに区分化される。これらのステップのそれぞれは、ここで本発明の優位点を理解できるようにさらに詳細に説明される。
ステップ６１２−正規化集合形式への視覚的仕様の縮小。ステップ６０４では、視覚的仕様５５０がユーザインタフェースモジュール５４６によって取得された。視覚的仕様５５０は、ユーザによって投入されたシェルフ７０８の値を備える。ステップ６１２では、視覚的仕様５５０は、ビジュアルテーブル７２０がどのようにして行、列、及び層に区分されるのかを定義する代数式を構築するために使用され、ビジュアルテーブル７２０の各ペイン７２２内の空間的な符号化をさらに定義する。このようにして、視覚的仕様５５０は複数の行と複数の列に１つまたは複数のペイン７２２を編成する。いくつかの実施形態では、前記複数の行と複数の列が階層的に編成される。さらに、いくつかの実施形態では、仕様５５０はまた前記１つまたは複数のペイン７２２を要すれば階層的に編成される複数の層に編成する。さらに、いくつかの実施形態では、仕様が前記１つまたは複数のペイン７２２を要すれば階層的に編成される別々のページに編成する。
ビジュアルテーブル７２０の完全な代数式は「テーブル構成」と呼ばれる。言い換えると、ステップ６１２では、それぞれビジュアルテーブル７２０のｘ軸、ｙ軸及びｚ軸を定義する視覚的仕様５５０の３つの別々の式が、ビジュアルテーブル７２０の行、列、及び層を区分するために集合形式（解釈された集合）に正規化される。正規化集合形式を作成するために、３つの別々の式内の各オペランドが集合形式に評価される。各式内の演算子は式内の各集合を評価する方法を定義する。したがって、集合形式への正規化が単一の集合（正規化集合形式）を生じさせ、正規化集合形式の各要素がビジュアルテーブル７２０の単一の行、列または層に対応する。いくつかの実施形態では、この正規化プロセスはさらに別の次元、項「ページ」によって拡大される。
ｘ軸、ｙ軸及びｚ軸を定める視覚的仕様５５０の３つの別個の式内の各式がデータベーススキーマのオペランド（例えばフィールド）から引き出されることを思い出すこと。前記正規化集合形式を作成するために使用される代数は、データベーススキーマ（またはデータベース構造のなんらかの他の表現）内のオペランドのそれぞれを２つの型、つまり次元レベルと約数に特徴付ける。オペランドが次元レベルであるのか、あるいは約数であるのかはオペランドの型に依存する。オペランドの集合解釈はオペランドの他のドメインの部材から構成される。約数オペランドの集合解釈は前記オペランド名を含む単一要素集合である。例えば、「利益」オペランドの集合解釈は｛利益｝である。
異なる型のオペランドへの集合の割り当ては、２種類のオペランドがどのようにしてビジュアルテーブル７２０の構造に符号化されるのかの相違点を反映する。次元レベルのオペランドはテーブルを行と列に区分するのに対し、約数オペランドはテーブルペイン内の軸として空間的に符号化される。集合解釈の例と、代表的な式の結果として生じるテーブル構造は図８に描かれている。
本発明で使用される代数の有効な式は、隣接するオペランドの各組の間の演算子との１つまたは複数のオペランドの順序付けられたシーケンスである。優先順位順であるこの代数の演算子は、交差（ｘ）、ネスト（／）、及び連結（＋）である。前記優先順位を改変するためには括弧を使用できる。各オペランドは順序付けられた集合として解釈されるため、各オペレータの正確な意味論は、それらが図８に描かれているように、２つの集合（左オペランドと右オペランドから１つづつ）を単一の集合にどのように組み合わせるのかに関して定められる。
このようにして、視覚的仕様５５０内のあらゆる式は単純な集合に縮小することができ、前記集合内の各項目は、ゼロ個または複数個の約数オペランド名が後に続くゼロ個または複数個の次元レベル値の順序付けられた連結である。例えば、式の正規化集合形式は「月ｘ利益」は｛（１月、利益）、（２月、利益），．．．，（１２月、利益）｝である。式の正規化集合形式は、ビジュアルテーブル７２０の１つの軸を決定する。前記テーブルの軸は、前記正規化集合内の列とエントリの間の１対１の対応があるように列（または行または層）に区分化する。
ステップ６１２の概要が記述されたので、例があげられる。図１１の例示的な視覚的仕様５５０を考える。
ｘ：Ｃ*（Ａ＋Ｂ）
ｙ：Ｄ＋Ｅ
ｚ：Ｆ
ステップ６１２に従ったこの視覚的仕様の正規化集合形式の計算は、以下を提供する。
ｘ：｛（ｃ_１，ａ_１）．．．（ｃ_ｋ，ｂ_ｊ）｝
ｙ：｛（ｄ_１），．．．，（ｄ_１），（ｅ_１），．．．，（ｅ_ｍ）｝
ｚ：｛（ｆ_１），．．．，（ｆ_１）｝
有利なことに、本発明の代数形式主義は、特に次元レベルと連動するように設計されたドット演算子と呼ばれる演算子を利用できる。したがって、代数形式主義は、本発明のデータベース階層の使用及び探査に対する直接的なサポートを提供する。ドット演算子の優位点の１つは、それがデータベースファクトテーブルを分析せずに階層情報を推論できるという点である。ドット演算子の追加の優位点は、以下の第５．４．２．４項に説明される。
ステップ６１４−正規化集合形式を使用するビジュアルテーブル７２０の構築。ステップ６１４（図６、図１１）では、ビジュアルインタプリタ５５６が視覚的仕様５５０から得られたｘ軸、ｙ軸及びｚ軸の式の正規化集合形式を使用してビジュアルテーブル７２０を構築する。ｘ軸、ｙ軸及びｚ軸の式の正規化集合形式内の各要素は単一の行、列または層に相当する。
図１２は、視覚使用の正規化集合形式から生成されたビジュアルテーブル７２０の構成を示す。図１２は、コーヒーチェーンデータセット（ＣＯＦＦＥＥ）のためのＰｒｏｆｉｔ（利益）情報を表示する。ｙ軸は、式Ｐｒｏｆｉｔ（利益）＋（Ｍａｒｋｅｔ（市場）×ＰｒｏｄｕｃｔＴｙｐｅ（製品種別））によって定義され、ｘ軸は式（四半期／月）によって定義される。ｚ軸は図１２に描かれていない。
図１２に描かれたように、式１２０２と１２０４が演算子によって結合されるオペランドから構成される。各オペランドはｐ−タプル（集合解釈）の数学的なシーケンスに評価される。数学的なシーケンスは、重複部材を可能にする要素の順序付けられたリストである。各オペランドの間の演算子は２つのシーケンスをどのようにして結合するのかを定義する。したがって、各式は、単一のシーケンス（正規化集合形式）として解釈することができ、前記シーケンス内の各要素は単一の行、列または層に対応する。
いくつかの実施形態では、ステップ６１２で生成された正規化集合形式はｐ−エントリとｐ−タプルとしてさらに正式に定義される。オペランドの集合解釈は異種ｐ−タプルの有限（おそらく空の）シーケンスである。集合解釈内の各ｐ−タプルはビジュアルテーブル７２０の行（または列または層）を定義する。言い換えると、各ｐ−タプルは、ビジュアルテーブル７２０の行、列、または層にマッピングする。ｐ−タプルはｐ−エントリの有限シーケンスである。単一のｐ−タプルは単一行（または列または層）を定義する。ｐ−タプルのエントリは、データベース５５８のファクトテーブル上での行内の空間符号化（軸）と選択基準を定める。ｐ−エントリは、タグが１組の値構成要素の意味と考えられる値を定める順序付けられた「タグ−値」組である。エントリは、ｆｉｅｌｄ：Ｐｒｏｆｉｔ（フィールド：利益）などｔａｇ：ｖａｌｕｅ（タグ：値）として作成される。タグは第５．４項にさらに詳しく説明されるようにフィールド、定数、またはフィールド名である場合がある。いくつかの実施形態では、タプル（ｐ−タプル）の順序付けられた集合がマッピングされる行、列または層のペイン７２２がｐ−タプル内に提示される同じ順序で視覚的なテーブル７２０内の行、列または層の中で並べられる。
要約すると、ビジュアルテーブル７２０の各軸は、正規化集合形式で作成し直された視覚的仕様５５０からの式によって定められる。この正規化集合形式の基数は、正規化集合が空のシーケンスであるときの例外で、軸に沿った行（または列または層）の数を決定する。好適実施形態では、正規化集合が空のシーケンスであるとき、単一の行または列はゼロ行または列よりむしろ作成される。正規化集合内の各ｐ−タプルは、行（または列または層）を定める。各ｐ−タプル内のｐ−エントリは、行に表示されるタプルを選択するデータベース５５８ファクトテーブル上の選択基準と、データベースタプルを視覚化するために使用されるグラフィックマークの位置を定める行内の空間符号化の両方を定める。集合解釈に関するさらに多くの情報は以下の第５．４項に記載される。
いくつかの実施形態では、ビジュアルテーブル７２０はウェブインタフェースとして提示される．いくつかの実施形態では、ユーザインタフェースモジュール５４６のすべてまたは一部が実行され、ウェブインタフェースとしてビジュアルテーブル７２０の提示を容易にするためにリモートユーザコンピュータ上で表示される。
ステップ６１６−ビジュアルテーブル７２０内のペイン７２２に対応するタプルに照会結果を分割する。ステップ６１６（図６、図１１）では、ビジュアルインタプリタモジュール５５６がデータインタプリタモジュール５５２によって戻される照会結果を処理する。これらの照会結果がタプルと呼ばれる。本発明のいくつかの実施形態では、ビジュアルインタプリタモジュール５５６が以下のアルゴリズムを実行する。
２０１：ｘ集合＝ｘ軸式の正規化集合形式を計算する
２０２：ｙ集合＝ｙ軸式の正規化集合形式を計算する
２０３：ｚ集合＝ｚ軸式の正規化集合形式を計算する
２０４：ｘ集合内のｘ−エントリごとに｛
２０５： ｙ集合内のｙ−エントリごとに｛
２０６： ｚ集合内のｚ−エントリごとに｛
２０７：ｐ−ｌｏｏｋｕｐ＝新規ペイン探索記述子（ＰａｎｅＬｏｏｋｕｐＤｅｓｃｒｉｐｔｏｒ）（ｘ−エントリ、ｙ−エントリ、ｚ−エントリ）
２０８：ｐ−ｓｐｅｃ＝ｐ−探索（ｌｏｏｋｕｐ）に適用する（ペイン仕様）ＰａｎｅＳｐｅｃｉｆｉｃａｔｉｏｎ
２０９：前記ペイングラフィックを作成する
２１０：タプルをレンダリングするための基本オブジェクトを作成する
２１１：視覚プロパティのための符号化オブジェクトを作成し、基本オブジェクトに追加する
２１２：タプルを描画順に並べ替えるペインごとの変形を作成する
２１３：ｐ−ｌｏｏｋｕｐを使用してペイン−データ−キャッシュからデータを取り出す
２１４：ｐ−ｌｏｏｋｕｐを使用してペイン−データ−キャッシュからデータを結び付ける
２１５：ペインをデータに結び付ける｝｝｝
ライン２０１から２０３はステップ６１２で実行される（図６）。ライン２０４から２０６は、ビジュアルテーブル７０２内の各ペイン７２２を個々に検討する３つのｆｏｒループである。ペインｉごとに、ライン２０７から２１４が実行される。
ライン２０７と２０８では、ペインｉのペイン仕様が位置する。ペイン仕様は視覚的仕様５５０から最終的に引き出される。ペインｉのためのペイン仕様は、前記ペインのためのマーク、符号化等を定義する。
ライン２０９から２１２では、ペインｉのペイングラフィックは、ペインｉに適用するペイン仕様を使用して作成される。ライン２１０では、ペインｉの中でタプルをレンダリングするための基本オブジェクトが作成される。ペイン基本オブジェクトの例はバーチャート内のバーである。ライン２１１では、ライン２１０で作成される各それぞれの基本オブジェクトの視覚特性のための符号化オブジェクトが作成され、前記対応する基本オブジェクトに追加される。バーのケースでの例示的な符号化オブジェクトはバーの色とサイズである。ライン２１２では、タプルを描画順に並べ替えるペインごとの変換が適用される。言い換えると、ペインごとの変換はペインｉの中にタプルがどのようにして表示されるのかを記述するために使用される。
ライン２１３では、ペインｉのためのデータがｐ−ｌｏｏｋｕｐを使用してペイン−データ−キャッシュ５５７から取り出される。ライン２１４から２１５では、ペインｉのデータ（例えば、データベース５５８の照会から取り出されたタプルの集合の部分集合）がペインｉに結合される。このようにして、データベース５５８の照会からのデータはビジュアルインタプリタモジュール５５６によってビジュアルテーブル７２０に結合される。
言い換えると、ライン２０９から２１２では、ペインｉと関連付けられるタプルの部分集合内のタプルがグラフィックマークとして符号化される。いくつかの例では、タプルの部分集合内のタプルは（例えば、色、値、サイズ、形状、句、または記号などの）グラフィック属性に次にマッピングされるフィールドを備える。いくつかの実施形態ではフィールドが定量的または序数として分類され、（ｉ）フィールドが定量的として分類されるとき、それは第１のグラフィック属性にマッピングされ、（ｉｉ）フィールドが序数として分類されるとき、それは第２のグラフィック属性にマッピングされる。いくつかの実施形態では、フィールドは独立または従属として分類され、（ｉ）フィールドが独立として分類されるとき、それは第１のグラフィック属性にマッピングされ、（ｉｉ）フィールドが従属として分類されるとき、それは第２のグラフィック属性にマッピングされる。第１の属性と第２の属性は、それぞれ、無関係に色、値、サイズ、形状、句または記号である。
いくつかの実施形態では、ペインｉと関連付けられるタプルの部分集合は選択関数によって決定される。いくつかの実施形態では、前記選択関数はタプルの部分集合を形成するためにステップ６０２で特徴付けられるデータベース５５８のメタデータ内に存在するスキーマフィールドのアイデンティティを使用する。例えば、特定のスキーマフィールドタイプに属するすべてのタプルをペインｉに割り当ててよい。いくつかの実施形態では、選択関数は、ペインｉと関連付けられるタプルの部分集合を形成するために（例えば、選択演算子またはグループ化演算子などの）関係演算子を使用する。さらに、ビジュアルテーブル７２０内の行と列の配列も制御し、フィルタリングできる。
ライン２０１から２１５に記述されるアルゴリズムは、５５８の各照会がペイン−データ−キャッシュ５５７で使用可能であることを仮定する。本発明の重要な優位点が、照会が通常いくつかのペイン全体でグループ化されていることを思い出すこと。照会をペインごとの別個のテーブルに分割し、次にペイン−データ−キャッシュ５５７に配置する必要がある。本発明は、どのソフトウェアモジュールがこのグループ化変換を実行するのかに関して制限を課さないが、本発明のある実施形態では、グループ化変換がデータベース５５８に問い合わせするための一般化されたアルゴリズムの一部としてデータインタプリタモジュール５５２によって実行される。例えば、前記のステップ６０６に記述されるアルゴリズムを参照すること。
本発明のいくつかの実施形態では、ステップ６０８がタプルの集合を戻す。次にステップ６１０では、新しいタプルがタプルの集合から引き出される。次に、この新しいタプルは、視覚的仕様５５０によって指定されるグラフィック内の１つまたは複数のペイン７２２との考えられる関連付けのためにタプルの集合の中に組み込まれる。いくつかの例では、（例えば、並べ替え演算子、集約演算子、または変換演算子などの）関係演算子は、新しいタプルを作成するために使用される。この例は、照会言語を増加するために実行される追加の変換である。例えば、この集約演算は階層の上下で発生するため、ＭＤＸ照会が１年の全１２ヶ月を年合計に、次に例えば複数年を多年合計に容易に集約できることは既知である。しかしながら、ＭＤＸは階層全体で容易に集約できない（例えば、年に関係なくすべての１月の合計）。本発明は、（例えば、１つまたは複数のＭＤＸ照会から返されるタプルの集合など）返されるタプルの集合に１つまたは複数の局所変換を適用することによって階層全体で集約演算に対処する。例えば、年に関係なくすべての１月の合計を得るために、１つまたは複数のＭＤＸ照会が行われ、関連するタプルを取得し、次に１月という月がＭＤＸ照会結果のそれぞれの年全体で集約される。
本発明のいくつかの実施形態では、ステップ６０８がタプルの集合を返す。グループはタプルの集合内のタプルのすべてまたは一部を使用して形成される。次に、グループに基づいたグラフィックが形成される。このような実施形態は、複数ペイングラフィックが構築される例で有効である。このようなグラフィックの例は、グループの中に各タプルを封入するグループまたは領域内で各タプルを結合するラインを含む。
いくつかの実施形態では、仕様５５０は、１つまたは複数のペイン７２２を複数の層に編成し、前記複数の層内の各層にはステップ６０２で特徴付けられた別のデータベース５５８からタプルが割り当てられる。いくつかの実施形態では、仕様５５０は１つまたは複数のペイン７２２を複数の列と複数の行に編成し、前記複数の列内の各列にステップ６０２で特徴化された別のデータベース５５８からタプルが割り当てられる。さらに他の実施形態では、仕様が前記１つまたは複数のペインを複数の列と複数の行に編成し、前記複数の行内の各行にはステップ６０２で特徴付けられた別のデータベースからタプルが割り当てられる。さらに追加の実施形態では、仕様は前記１つまたは複数のペインを複数のページに編成し、前記複数のページ内の各ページは、ステップ６０２に特徴付けられた別のデータベース５５８からタプルに割り当てられる。
本発明の１つの実施形態にしたがって実行されたステップの概要が提供された。本発明は、ユーザがデータベース５５８をさらに効率的に探査できるようにするために、１つまたは複数のターゲットデータベース５５８の根本的な階層を利用するためきわめて有利である。ユーザは各ターゲットデータベース５５８内の階層的な層を迅速に掘り下げることができる。例えば、本発明のある実施形態では、インタフェースは「▼」アイコン７０８−６（図７）を含む。ユーザが「▼」アイコン７０８−６を押すと、ユーザには（ターゲットデータベース内の複雑な次元階層における多岐に渡るレベルを含む）次元のすべてのレベルのリスティングが提示される。新しいレベルが選択されると、これはその次元に沿った掘り下げ（または上方スクロール）動作として解釈され、現在のレベルは（同じ適格化を用いて）選択されたレベルと自動的に置き換えられる。このようにして、本発明は、ユーザがある次元に沿って詳細の異なるレベル間を迅速に移動できるようにし、ユーザがナビゲーションするにつれて仮想仕様５５０を精緻化する。各レベルでは、本発明は本発明の新規テーブル代数を使用して効率的なデータベース照会を形成する。本発明の別の優位点とは、ステップ６１６内のペインと関連付けられるタプルの部分集合がステップ６０５から６１６の新規反復内の視覚的仕様５５０として使用できる。例えば、ユーザは新規仕様のための基礎としてペインと関連付けられるタプルの部分集合内で１つまたは複数のタプルを選択できる。次に、ステップ６０６から６１６は新しい仕様を使用して繰り返すことができる。本発明のさらに別の優位点は、各仕様５５０が後の使用のために記憶できる形式で表現できるという点である。仕様５５０の記憶は、仕様「アンドゥ」と「リドゥ」に対するサポートだけではなく、好みの仕様のブックマーキングなどのサービスにも対処する。仕様「アンドゥ」では、例えば、ステップ６０４の過去のインスタンスで使用された仕様５５０がステップ６０６から６１６を実行するために取得され、使用される。

５．３ データベース階層及びデータベース編成の例示的なタイプ
本発明は、データベース５５８に記憶されている多次元分析データの探査及び分析のための視覚化技法を提供する。データベース５５８の１つの形式はデータウェアハウスである。データウェアハウスは、関係型データベースまたは多次元データキューブのどちらかとして通常構造化される。本項では、本発明に関連する関係型データベース及び多次元データキューブの態様が説明される。関係型データベース及び多次元データキューブに関する詳細については、Ｂｅｒｓｏｎ及びＳｍｉｔｈ、１９９７年、データウェアハウジング、データマイニング及びＯＬＡＰ（Ｄａｔａ Ｗａｒｅｈｏｕｓｉｎｇ，Ｄａｔａ Ｍｉｎｉｎｇ ａｎｄ ＯＬＡＰ）、マクグローヒル（ＭｃＧｒａｗ−Ｈｉｌｌ）、ニューヨーク（Ｎｅｗ Ｙｏｒｋ）、フリーズ（Ｆｒｅｅｚｅ）２０００年、マイクロソフトＳＱＬサーバ及びエクセル２０００を用いてＯＬＡＰをアンロックする（Ｕｎｌｏｃｋｉｎｇ ＯＬＡＰ ｗｉｔｈ Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒ ａｎｄ Ｅｘｃｅｌ ２０００）、ＩＤＧブックスワールドワイド社（ＩＤＧ Ｂｏｏｋｓ Ｗｏｒｌｄｗｉｄｅ，Ｉｎｃ．）、フォスターシティ、カリフォルニア（Ｆｏｓｔｅｒ Ｃｉｔｙ，Ｃａｌｉｆｏｒｎｉａ）、及びトムソン、１９９７年、ＯＬＡＰ解決策：多次元情報システムの構築（ＯＬＡＰ Ｓｏｌｕｔｉｏｎｓ：Ｂｕｉｌｄｉｎｇ Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｓｙｓｔｅｍｓ）、ウィリーコンピュータ出版（Ｗｉｌｅｙ Ｃｏｍｐｕｔｅｒ Ｐｕｂｌｉｓｈｉｎｇ）、ニューヨーク（Ｎｅｗ Ｙｏｒｋ）を参照すること。

５．３．１ データ編成
データベースは、通常、注文入力、会計及び在庫管理などの操作目的（ＯＬＴＰ）のために使用されてきた。さらに最近では、企業プロジェクトと科学プロジェクトが、探査及び分析の目的のために明示的に、データウェアハウス、つまり大型オンライン解析処理（ＯＬＡＰ）データベースと呼ばれるデータベースを構築している。「データウェハウス」は、管理決定を支持したデータの主題指向型の統合された時変不揮発収集として説明できる。データウェアハウスの重要な態様は、それがトランザクションデータまたは操作データより寧ろ解析データのためのレポジトリであるという点である。データウェアハウスに含まれるデータは、通常、事業またはプロジェクトのなんらかの重要な関心についての、例えば経時的なトランザクションなどの履歴データを表す。このデータは通常、操作データベース、シミュレーション、データ収集ツール（例えばｔｑｄｕｍｐ）及び他の外部ソースなどの多く異なるソースから収集される。
データウェアハウスは、関係型データベースと、データキューブと呼ばれる特殊化された多次元構造の両方を使用して構築される。本副項では、データベーススキーマなどのこれらのデータベース内部のデータの編成は、意味論的な階層の使用、及びデータキューブの構造が説明される。次の副項では、ＯＬＡＰデータベースとＯＬＴＰデータベースの編成の間の相違点が説明される。

５．３．２ 関係型データベース
関係型データベースは、各行が事実の基本的なエンティティに相当し、各列がそのエンティティの特性を表すテーブルにデータを編成する。例えば、テーブルは銀行内のトランザクションを表す場合があり、そこでは各行は単一のトランザクションに対応し、トランザクション量、口座残高、銀行支店及び顧客などの各トランザクションは複数の属性を有する。テーブルは、関係、タプルとしての行、及び属性またはフィールドとしての列と呼ばれる。関係内の属性は次元及び約数という２つの型に分割できる。次元と約数は従来の分析の独立変数と従属変数に類似している。例えば、銀行支店と顧客は次元であるが、口座残高は約数であろう。単一の関係型データベースは、多くの場合多くの異種であるが相互に関連付けられたエンティティを含んでいる。例えば、コーヒーチェーン向けに作られるデータベースは、従業員、製品及び売上高についての情報を維持する可能性がある。データベーススキーマは、データベース内での関係（テーブル）、それらの関係の関係性、及び関係がどのようにして関心のあるエンティティをモデル化するのかを定義する。

５．３．３ 階層構造
データベースにおける大部分の次元は階層構造を有する。この階層構造は、次元内の詳細の意味論的なレベルから引き出される、あるいは分類アルゴリズムから生成される。本発明のシステム及び方法は、アナリストがファクトテーブルから計算された詳細の複数のレベルでデータを探査し、分析するために使用できるツールを提供するためにこれらの階層を使用する。例えば、単一の次元「状態」を有するよりむしろ、３つのレベルを有する階層次元「場所」が、国、州、及び群に１つづつ使用できる。次に、アナリストは、これらのレベルのどれかにとって重要な約数を集約できる。集約演算のレベルは、複数のレベルのあるツリーとして構造化される、階層次元から決定される。最高レベルは最も集約され、最低レベルは最も集約されていない。各レベルはその次元の詳細の別の意味論的なレベルに相当する。ツリーの各レベルの中では、多くのノードがあり、それぞれのノードがその次元のその詳細のレベルのドメイン内の値に対応する。前記ツリーは、各詳細のレベルのドメイン値間の親−子関係性の集合を形成する。これらの関係性は、次元階層内での集約動作、掘り下げ動作及び上方スクロール動作のための基礎である。図９は、Ｔｉｍｅ（時間）次元の次元階層を描いている。単純な階層は、図９に示されるものように、一般的にスタースキーマを使用してモデル化される。次元階層全体は、単一ディメンションテーブルにより表される。この種の階層では、集約演算の１つの経路しかない。しかしながら、集約経路が分岐できるさらに複雑な次元階層がある。例えば、時間の次元は日から週と月の両方に集約される可能性がある。これらの複雑な階層は、通常、第２項に記述されるように、多岐に渡る階層を表すために複数の関係（テーブル）を使用するスノーフレークスキーマを使用して表現される。

５．３．４ データキューブ
データウェアハウスは、スタースキーマまたはスノーフレークスキーマのどちらかを使用して関係型データベースとして構築でき、多次元データセットの概念モデルを提供する。しかしながら、要約または集約演算などの典型的な分析動作はリレーショナルモデルによって十分にサポートされていない。照会は、ＳＱＬなどの言語で書き込むことが困難であり、照会性能は理想的ではない。その結果として、通常、ファクトテーブルとディメンションテーブルは分析に直接的に使用されず、むしろデータキューブと呼ばれる多次元データベースを構築する基礎として使用される。
データキューブ内の各軸はリレーショナルスキーマ内の次元に対応し、その次元の考えられるあらゆる値から構成されている。例えば、州に対応する軸は州ごとに１つ五十の値を有するであろう。データキューブ内の各セルは次元の値の一意の組み合わせに相当する。例えば、２つの次元「Ｓｔａｔｅ（州）」と「Ｐｒｏｄｕｃｔ（製品）」がある場合には、例えば（Ｃａｌｉｆｏｒｎｉａ，Ｔｅａ（カリフォルニア、茶））、（Ｃａｌｉｆｏｒｎｉａ，Ｃｏｆｆｅｅ（カリフォルニア、コーヒー））、（Ｆｌｏｒｉｄａ，Ｔｅａ（フロリダ、茶））、（Ｆｌｏｒｉｄａ，Ｃｏｆｆｅｅ（フロリダ、コーヒー））等の前記２つのあらゆる一意の組み合わせにつき１つのセルがある。各セルはデータキューブの約数ごとに１つの値を含む。したがって、製品の製造及び消費の情報が必要とされる場合には、各セルが、その州で消費される各種の製品の数の値と、その州で生産される各種の製品の数の値という２つの値を含むであろう。図１３は、仮想の全国のコーヒーチェーンデータウェアハウスのデータキューブを描いている。データキューブの各セルは、各次元の前記対応する値のベースファクトテーブルのすべての約数を要約する。
データウェアハウス内の次元は多くの場合、階層構造で拡大される。本発明の前記システム及び方法は、複数の有意義なレベルの集約演算でデータキューブを探査、解析するために使用できるツールを提供するためにこれらの階層を使用する。その結果、データキューブ内の各セルは、適切な詳細のレベルに集約されるベースファクトテーブルの約数に対応する。各次元が階層構造を有する場合には、データウェアハウスは単一のデータキューブではなく、むしろ各キューブが各次元の詳細のレベルの組み合わせによって定められる（図１４）データキューブの格子である。図１４では、各次元（時間、製品、場所）の階層構造が立方体の格子を定義する。前記格子の中では、各立方体は次元ごとの詳細のレベルの組み合わせによって定められる。格子の底部にある立方体には最も詳細な情報が含まれるのに対し、格子の上部にある立方体は最も抽象的である。

５．３．５ ＯＬＡＰ体ＯＬＴＰ
前記項では、関係型データベースとデータキューブの両方がどのようにして分析目的のために編成、使用できる（ＯＬＡＰ）のかを説明した。しかしながら、従来、関係型データベースは日々の操作目的のために使用されてきた。これらのＯＬＴＰデータベースは、ＯＬＡＰデータベースまたはデータウェアハウスとは異なる問題に対処し、その結果、きわめて異なるスキーマ及び使用パターンを有する。ＯＬＡＰ視覚化ツールの設計に影響を及ぼす問題を理解するためには、これらの２種類のデータベース間の相違点を理解する必要がある。
ＯＬＴＰデータベースは、データを照会する、または修正するかのどちらかのために短いトランザクションを処理し、おそらく複数のシステムと対話し、多くの同時結合をサポートするときに性能のために最適化される。さらに、照会性能は、通常、データ冗長性を回避し、更新をサポートするような問題には二次的である。典型的なＯＬＴＰ照会はほんの数個の関係から数十のタプルを取り出し、次に前記タプルの内のいくつかを更新する。例えば、典型的な照会はその口座番号に基づいた単一の顧客のレコードを取り出すか、あるいは売上発生時に売上関係に単一のトランザクションを追加する。操作データベースのためのデータベーススキーマ定義は、同時並行性を最大限にし、挿入、更新、及び削除の性能を最適化することに焦点を当てている。その結果、スキーマは多くの場合正規化され、それぞれが異なるエンティティ集合を記述する多くの関係のあるデータベースが生じる。
対照的に、更新可能なトランザクションデータを維持するために使用されるより寧ろ、ユーザはＯＬＡＰデータベースに対話的に問い合わせし、探査することができる必要がある。ＯＬＡＰの照会は、それらが通常情報の数千の行を取り出し、それらのどれも修正しないという点で非常に異なっている。照会は大きく、複雑、場当たり的で、データ集約的である。操作スキーマは根本的なデータを多くの関係に分離するため、これらの分析照会を操作スキーマに基づいてデータベースにこれらの分析照会を実行すると、多くの高価な結合計算を必要とするであろう。分析データベースは通常読取専用であるので、及び照会性能は主要な懸念であるため、ＯＬＡＰデータベースは、通常は、スタースキーマまたはスノーフレークスキーマを使用して、データベースを非常に少数の関係に非正規化することによって冗長性を犠牲にし、更新性能し、照会を増進する。外部ツールは、通常、データキューブまたは単一の大きな関係（テーブル）のどちらかとしてＯＬＡＰデータベースを表示できる。

５．３．６ 多次元分析動作
いくつかの実施形態では、データベース５５８は通常きわめて大きく、多くの次元から構成され、それぞれが階層構造と、多くの場合多くの構成要素を備える。データキューブの結果として生じる格子をナビゲーションし、分析のためにデータを抽出するために次元縮小を実行するためには、使用される多くの多次元分析動作がある。本項ではこのような動作を説明する。
掘り下げは、さらに詳細な方向でデータキューブの格子を通してナビゲーションするプロセスを指す。それは一個の情報をさらに小さく、さらに詳細なパーツに分けるために使用される技法である。上方スクロールは、掘り下げの逆であり、詳細なデータをより粗い要素に集約する。予測（図１５に描かれる）は、次元全体で集約することによって、ｎ次元データキューブの次元性を（ｎ−１）に縮小する。例えば、図１５では、第１の予測「場所」全体で要約し、三次元立方体を二次元立方体に縮小する。
予測が集約演算を介して次元性を縮小すると、（図１６に描かれている）スライシングが単一の値に次元をフィルタリングすることによって次元性を縮小する。言い換えると、１つの次元は、その次元全体でスライスを生成するために一定に保持される。図１６に描かれている例では、「Ｑｔｒ２」のデータに相当する二次元スライスが「時間」次元から取り出される。

５．３．７ 視覚化のためのデータ特徴付け
本発明のいくつかの実施形態によって使用されるＯＬＡデータがどのようにして編成されるのかを説明したので、本発明のいくつかの視覚化プロセスをサポートするために使用される追加のデータ特徴付けがここで説明される。視覚化のためには、データベースシステムによって通常捕捉されるより属性について多くが必要とされる。データベースは、通常、フィールドが次元であるのか約数であるのかに関係なくその名称、及びその型（例えば、時間、整数、フロート、文字）などのフィールドについて限定された性能を提供する。
本発明のいくつかの実施形態では、次元は、視覚特性を使用してビジュアルテーブル内のフィールドを符号化する方法を決定するために、ビジュアルテーブル内のデータベースフィールド（オペランド）テーブルが名目であるのか、序数であるのか、あるいは定量的であるのかどうかに関して決定が下される。代表的な視覚的な特性は、色、大きさまたは位置を含むが、これらに限定されない。この特徴付けは測定のスチーブンスのスケールの簡略化に基づいている。Ｓｔｅｖｅｎｓ、測定のスケールの理論について（Ｏｎ ｔｈｅ ｔｈｅｏｒｙ ｏｆ ｓｃａｌｅｓ ｏｆ ｍｅａｓｕｒｅｍｅｎｔ）、インサイエンス（１０３）、６７７から６８０ページを参照すること。いくつかの実施形態では、この特徴付けは、コンテキストが離散データと連続データの相違点を強調するかどうか、コンテキストがフィールドが配列を有するかどうかを強調するかどうかに応じてさらに簡略化される。１つの例では、フィールドを空間的に符号化するときに、前記フィールドが離散値を有するかどうかが強調される。さらに、フィールドが軸に割り当てられるとき、それは配列を有する。したがってこれに関連して、普通は序列を有さない名目フィールドには１（ｏｎｅ）が割り当てられ、次に本発明のいくつかの実施形態では序数フィールドとして処理される。結果として生じる特徴付けは断定的であると判断される。対照的に、フィールドに色などの視覚特性を割り当てるときには、重要な特徴的な特徴付けが適切である。これに関連して、本発明のいくつかの実施形態では、序数フィールドと定量フィールドは単一の特徴付けとして処理され、名目フィールドは別個に考えられる。さらに、属性は関連つけられたユニットと意味論的なドメインとを有する。例えば、属性は時間、緯度などの地理学的な単位、または物理的な測定値を符号化できる。この情報が入手できる場合、それはより効果的な視覚符号化を生成し、ビジュアルテーブル７２０の幾何学形状（例えば、アスペクト比）を決定するのに役立つように使用できる。例えば、視覚的なテーブル７２０のｘ軸とｙ軸が、利益と売上高よりむしろ緯度と経度に相当すると知っていることは、適切な幾何学形状の決定に影響を及ぼすであろう。
データベースは、通常、フィールド−データベース内に現在存在する値−の現在のドメインだけを配列なしに記憶する。しかしながら、分析のためには、考えられる値とその固有の（前記当する場合）配列などフィールドの実際のドメインを理解することが重要である。属性をビジュアルテーブル７２０の軸として符号化するために、すべての考えられる値とそれらの配列は、データがいつ見失われているのかの表示を行うことができるように決定され、アルファベットなどの任意の配列を使用するよりむしろその意味論的な文脈内でデータを提示する必要がある。いくつかの実施形態では、この追加のデータ特徴付けはデータベース５５８（図５）と関連付けられる属性ファイル５８０（例えば、ＸＭＬ文書）内で捕捉される。

５．４ 代数
前述されたように、完全なテーブル構成は三つの別々の式から構成される。式の内の２つはビジュアルテーブル７２０のｘ軸とｙ軸の構成を定義し、テーブルを行と列に分割する。第３の式は、折り重なって合成されるｘ−ｙテーブルの層に表示を分割するビジュアルテーブル７２０のｚ軸を定める。本項では、その構文と意味論を含む、本発明のいくつかの実施形態のこれらの三つの式で使用される、代数を述べる。前述されたように、本発明のいくつかの実施形態で使用される代数の各式は演算子により接続されるオペランドから構成される。オペランド及び演算子は、以下の項で同様に説明される。

５．４．１ オペランド
本項で説明されるテーブル代数のオペランドはデータベース５５８のフィールドの名称（フィールドオペランド）及びｐ−タプルの所定の一定のシーケンス（定数オペランド）の名称である。いくつかの実施形態ではフィールドタイプの分類は、すべての名目フィールドにデフォルトのアルファベット配列を割り当て、次に序数としてそれらを処理することによって序数と定量的に縮小される。このような実施形態では、３つのクラスのオペランド、つまり（１）序数フィールドオペランド、（２）定量フィールドオペランド、及び（３）定数オペランドがある。本項の残りを通して、項ＡとＢは序数フィールドオペランドを表し、ＰとＱは定量的なフィールドオペランドを表し、Ｃは定数オペランド、及びｘ、Ｙ及びＺを表す。

５．４．１．１ 集合解釈
集合解釈は以下のようにそれぞれのオペランド記号に割り当てられる。序数フィールドはフィールドの順序付けられたドメインの構成要素を割り当てられる。定量的なフィールドはフィールド名を含む単一要素集合を割り当てられる。定数オペランドはその所定の集合解釈を割り当てられる。
Ａ＝領域（Ａ）＝＜（Ａ：ａ），．．．，（Ａ：ａｎ）＞
Ｐ＝＜（フィールド：Ｐ）＞
Ｃ＝＜（定数：ｃ），．．．，（定数：ｃｍ）＞
説明を簡略にするために、タグは、必要な場合を除き本項内で残りの集合解釈には含まれない。
集合をフィールドオペランドに割り当てると、前記２つのタイプのフィールドがどのようにしてビジュアルテーブル７２０の構造で符号化されるのかが反映される。序数フィールドは、ビジュアルテーブル７２０（及びデータベースタプル）を行と列に分割するのに対し、定量フィールドはペイン７２２内の軸として別々に符号化される。

５．４．１．２ 定数オペランド
定数オペランドは選択基準も空間符号化も定義しない。代わりに、それらはデータベースタプルを分割しないで追加行を生成するために使用できる。これは異種データベースの層化を容易にする。いくつかの実施形態では、定数オペランドはビジュアルファクトテーブルを定めてから、このビジュアルファクトテーブルを基準にして演算子を定めることによって序数フィールドオペランドとして処理される。（Ｃ，．．．，Ｃｎ）を定数オペランドの集合とし、ＲｃをそのドメインがＣｉの所定の集合解釈に対応する単一の属性（Ｃｉ）との関係とし、ＦＴをデータベース５５８のファクトテーブルとする。ビジュアルファクトテーブルＶＦＴは、定数オペランドの既定の集合を基準にして以下として定められ、
ＶＦＴ＝ＦＴ×Ｒｃ_１．．．×Ｒｃ_i
この代数は、１つの所定の定数オペランド、つまり空のシーケンスを含む。

５．４．１．３ フィールドオペランドのフィルタリング及び並べ替え
フィールドがフィルタリングされる（並べ替えられる）場合、フィルタリングされ、並べ替えられたドメインは説明のフィールドオペランドの後に直接的に一覧表示され、実際にはオペランドの集合解釈を指定する。ドメイン（Ａ）＝＜（ａ），．．．，（ａ_ｎ）＞の序数フィールドＡを考慮すると、オペランドはフィルタリングされ、並べ替えられたドメイン（＜ｂ，．．．，ｂ_ｊ＞ｂ_ｉ∈ドメイン（Ａ））を序数オペランドの直後で述べることによって式の中でフィルタリングし、並べ替えることができ、集合解釈は一覧表示されたドメインである。
Ａ［ｂ，．．．，ｂ_ｊ］＝＜ｂ，．．．，ｂ_ｊ＞
同様に、フィルタリングされたドメインは、所望されるドメインの最小値と最大値を一覧表示することによって定量フィールドに指定できる。この情報は生成された集合に含まれる。
Ｐ［最小、最大］＝＜（フィールド：Ｐ［最小、最大］）＞
オペランド及びその集合解釈の生成を定義したら、本発明の代数の４つの演算子を定めることができる。

５．４．２ オペランド
前述されたように、代数内の有効な式は、隣接するオペランドのそれぞれの組の間の演算子とともに１つまたは複数のオペランドの順序付けられたシーケンスである。この代数での演算は、優先順位順で、ドット（．）、交差（ｘ）、ネスト（／）、及び連結（＋）である。括弧は優先順位を改変するために使用できる。各オペランドはシーケンスとして解釈されるため、各演算子の正確な意味は、それが２つのシーケンス（左オペランドと右オペランドから１つづつ）を単一のシーケンスに結合するのかに関して定められる。ドット演算子、交差演算子、ネスト演算子、及び連結演算子の定義は以下に示される。以下に示される正確な定義は単に例示的にすぎず、各演算子の特徴と矛盾しない他の定義は本発明の範囲内である。

５．４．２．１ 連結
連結演算子は、２つのオペランドの集合解釈の順序付けられた和集合を演算子、あらゆる２つのオペランドまたは式に適用できる。
Ａ＋Ｂ＝＜（ａ），．．．，（ａ_ｎ）＞∪＜（ｂ），．．．，（ｂ_ｍ）＞
＝＜（ａ），．．．，（ａ_ｎ）＞，＜（ｂ），．．．，（ｂ_ｍ）＞
Ｐ＋Ｑ＝＜（Ｐ）＞∪＜（Ｑ）＞
＝＜（Ｐ），（Ｑ）＞
Ａ＋Ｐ＝＜（ａ），．．．，（ａ_ｎ）＞∪＜（Ｐ）＞
＝＜（Ｐ），（ａ），．．．，（ａ_ｎ），（Ｐ）＞
Ｐ＋Ａ＝＜（Ｐ）＞∪＜（ａ），．．．，（ａ_ｎ）＞
＝＜（Ｐ），（ａ），．．．，（ａ_ｎ）＞
Ｘ＋Ｙ＝＜（ｘ，．．．，ｘ_ｉ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ）＞∪＜（ｙ，．．．，ｙ_ｍ），．．．，（ｙ_ｎ，．．．，ｙ_ｎｏ）＞
＝＜（ｘ，．．．，ｘ_ｉ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ），（ｙ，．．．，ｙ_ｍ），．．．，（ｙ_ｎ，．．．，ｙ_ｎｏ）＞

連結演算子に当てはまる有一の代数特性は、連想的に以下のとおりである。
（Ｘ＋Ｙ）＋Ｚ＝（＜（ｘ，．．．，ｘ_ｉ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ）＞∪＜（ｙ，．．．，ｙ_ｍ），．．．，（ｙ_ｎ，．．．，ｙ_ｎｏ）＞）∪＜（ｚ，．．．，ｚ_ｐ），．．．，（ｚ_ｑ，．．．，ｚ_ｑｒ）＞
＝＜（ｘ，．．．，ｘ_ｉ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ）＞∪（＜（ｙ，．．．，ｙ_ｍ），．．．，（ｙ_ｎ，．．．，ｙ_ｎｏ）＞∪＜（ｚ，．．．，ｚ_ｐ），．．．，（ｚ_ｑ，．．．，ｚ_ｑｒ）＞）
＝Ｘ＋（Ｙ＋Ｚ）
連結演算子は、２つのシーケンスの順序付けられた和集合が可換ではないため、可換ではない。

５．４．２．２ 交差
交差演算子は、２つの記号の集合のデカルト積を実行する。
Ａ×Ｂ＝＜（ａ），．．．，（ａ_ｎ）＞×＜（ｂ），．．．，（ｂ_ｍ）＞
＝＜（ａ，ｂ），．．．，（ａ，ｂ_ｍ），．．．，（ａ_ｎ，ｂ），．．．，（ａ_ｎ，ｂ_ｍ）
Ａ×Ｐ＝＜（ａ），．．．，（ａ_ｎ）＞×＜（Ｐ）＞
＝＜（ａ，Ｐ），．．．，（ａ_ｎ，Ｐ）＞
Ｘ×Ｙ＝＜（ｘ，．．．，ｘ_ｉ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ）＞×＜（ｙ，．．．，ｙ_ｍ），．．．，（ｙ_ｎ，．．．，ｙ_ｎｏ）＞
＝＜（ｘ，．．．，ｘ_ｉ，ｙ，．．．，ｙ_ｍ），．．．，（ｘ，．．．，ｘ_ｉ，ｙ_ｎ，．．．，ｙ_ｎｏ）
．．．
（ｘ_ｊ，．．．，ｘ_ｉｋ，ｙ，．．．，ｙ_ｍ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ，ｙ_ｎ，．．．，ｙ_ｎｏ）＞
量子フィールドと式は、交差演算子が適用されると、右側オペランドとしてのみ表示されてよい。交差演算子も連想的であるが、（順序付けられたデカルト積が可換ではないため）可換ではない。
（Ｘ＋Ｙ）＋Ｚ＝＜（ｘ，．．．，ｘ_ｉ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ）＞×＜（ｙ，．．．，ｙ_ｍ），．．．，（ｙ_ｎ，．．．，ｙ_ｎｏ）＞×＜（ｚ，．．．，ｚ_ｐ），．．．，（ｚ_ｑ，．．．，ｚ_ｑｒ）＞
＝＜（ｘ，．．．，ｘ_ｉ），．．．，（ｘ_ｊ，．．．，ｘ_ｉｋ）＞×（＜（ｙ，．．．，ｙ_ｍ），．．．，（ｙ_ｎ，．．．，ｙ_ｎｏ）＞×＜（ｚ，．．．，ｚ_ｐ），．．．，（ｚ_ｑ，．．．，ｚ_ｑｒ）＞）
＝Ｘ＋（Ｙ×Ｚ）

５．４．２．３ ネスト
ネスト演算子は交差演算子に類似しているが、それは同じドメイン値でデータベースタプルが存在する集合エントリを作成するだけである。ＶＦＴが式ＸとＹ内のすべての定数オペランドを基準にして分析されるデータベースのビジュアルファクトテーブルであると定められ、ｔがタプルであり、タプルｔのｔ（Ｘ．．．，Ｘ_ｎ）がフィールドＸからＸｎの値である場合、ネスト演算は以下のとおりに定義できる。
Ａ／Ｂ＝＜（ａ，ｂ）|∃ｔ∈ＶＦＴｓｔ
＝（（ａ）∈Ａ）＆（ｔ（Ａ）＝ａ）＆（ｂ）∈Ｂ）＆（ｔ（Ｂ）＝ｂ）＞
Ｘ／Ｙ＝＜（ｘ，．．．，ｘ_ｎ，ａ）|∃ｔ∈ＶＦＴｓｔ
＝（（ｘ，．．．，ｘ_ｎ）∈Ｘ）＆（ｔ（Ｘ．．．，Ｘ_ｎ）＝（ｘ，．．．，ｘ_ｎ））＆
＝（（ａ）∈Ａ）＆（ｔ（Ａ）＝ａ）
Ａ／Ｙ＝＜（ａ，ｙ，．．．，ｙ_ｍ）|∃ｔ∈ＶＦＴｓｔ
＝（（ａ）∈Ａ）＆（ｔ（Ａ）＝（ａ））＆
＝（（ｙ，．．．，ｙ_ｍ∈Ｙ）＆（ｔＹ，．．．，Ｙ_ｍ）＝（ｙ，．．．ｙ_ｍ））＞
Ｘ／Ｙ＝＜（ｘ，．．．，ｘ_ｎ，ｙ，．．．，ｙ_ｍ）|∃ｔ∈ＶＦＴｓｔ
＝（（ｘ，．．．，ｘ_ｎ）∈Ｘ）＆（ｔ（Ｘ．．．，Ｘ_ｎ）＝（ｘ，．．．，ｘ_ｎ））＆
＝（（ｙ，．．．，ｙ_ｍ∈Ｙ）＆（ｔＹ，．．．，Ｙ_ｍ）＝（ｙ，．．．ｙ_ｍ））＞

ネスト演算子の適用により生じるシーケンス内のｐ−タプルの配列は、同じオペランドに交差演算子を適用することにより生じるシーケンス内にあるのと同じであろう。
ネスト演算子の本能的な解釈は「Ａ内のＢ」である。例えば、フィールドＱｕａｒｔｅｒ（四半期）とＭｏｎｔｈ（月）を考慮すると、式Ｑｕａｒｔｅｒ／Ｍｏｎｔｈ（四半期／月）は、各四半期内のそれらの月として解釈され、（ファクトテーブルのすべての月にデータが存在すると仮定して）四半期ごとに３つのエントリを生じさせる。対照的に、Ｑｕａｒｔｅｒ ｘ Ｍｏｎｔｈ（四半期ｘ月）は四半期ごとに１２のエントリを生じさせるであろう。ネスト演算子は、序数オペランドと式だけに適用されてよいにすぎない。ネストは連想演算子である。

５．４．２．４ ドット
交差演算子及びネスト演算子は、特別な断定的な階層を生成するためのツールを提供する。しかしながら、データウェアハウスは多くの場合明示的な意味論的な階層を持つ次元を含む。ドット演算子は、本発明の代数でのこれらの階層構造を利用するための機構となる。ドット演算子はネスト演算子に類似しているが、「階層認識」している。
ＤＴがレベルＡとＢを含む階層を定義するリレーショナルディメンションテーブルであると定義され、ＡがＤＴのスキーマにおいてＢに先行する場合、
Ａ．Ｂ＝＜（ａ，ｂ）|∃ｔ∈ＤＴｓｔ ｔ（Ａ）＝ａ＆ｔ（Ｂ）＝ｂ＞＆ｔ（Ａ）＝ａ＞

同様に、ドットは、同じ次元階層からドット演算子及びレベルだけを含む式Ｘを基準にしてドットが定められる。ＤＴはＸ内のすべてのレベル及び次元レベルＡを含む次元を定義する関係ディメンションテーブルであると定義される。加えて、Ｘ内のすべてのレベルは、それらがＸに表示される順序においてＤＴのスキーマの中に出現しなければならず、それらはＤＴのスキーマでＡに先行しなければならない。その結果、
Ｘ．Ａ＝＜（ｘ，．．．，ｘ_ｎ，ａ）|∃ｔ∈ＤＴｓｔ ｔ（Ｘ．．．，Ｘ_ｎ）＝（ｘ，．．．，ｘ_ｎ）
ドット演算子も関連であるが、可換ではない。
ネストは階層の中に掘り下げるために使用できるであろうが、この使用には欠点があるであろう。ネスト演算子は、次元レベルの間の任意の定められた階層関係性を認識していない。代わりに、それはファクトテーブル内のタプルに基づいた関係性を引き出す。この手法は非効率的であるばかりではなく、ファクトテーブルは多くの場合きわめて大きいため、それは不正確な結果も生じさせることがある。例えば、１１月の何のデータも記録されていなかった状況を考える。ネスト演算子をＱｕａｒｔｅｒ（四半期）とＭｏｎｔｈ（月）に適用すると、Ｑｕａｒｔｅｒ ４（第４四半期）の子としてＮｏｖｅｍｂｅｒ（１１月）を含まなかった間違って引き出された階層が生じるであろう。
ドット演算子はデータベース５５８の階層と連動するための特に有利な方法を提供する。これは、ドット演算子が階層情報を使用しているためである。（ｉ）データベース５５８ディメンションテーブル内で定義される、または（ｉｉ）データベース５５８がディメンションテーブルを有さない場合に、（考えられるユーザ介入により）データベース階層モジュール５４４によって構築されるかのどちらかである階層情報を使用するためである。対照的に、ネスト演算子は、次元レベル及び／またはデータベース階層モジュール５４２によって構築される階層の間の定義された階層関係性を認識していない。代わりに、ネスト演算子は、データベース５５８ファクトテーブル内のタプルの存在走査に基づいてデータベース内の階層型関係性を引き出すことにより作用する。これは、ファクトテーブルがきわめて大きいことがあるため、階層情報を引き出す非効率的な方法である。有利なことにドット演算子は存在走査に基づいてデータベース内の階層型関係性を引き出さない。むしろ、ドット演算子はデータベース階層を定めるデータベース５５８と関連付けられるメタデータを使用する。このメタデータの形式は、データベース５５８の正確な性質に依存するであろう。いくつかの実施形態では、メタデータは、例えばスタースキーマを備える。データベース５５８が（データベース５５８がフラットファイルであるケースなど）このような定められた階層関係にない場合、メタデータはデータベース階層モジュールによって構築される。

５．４．２．５ まとめ
各演算子に前記に設定された意味論を使用すると、代数内のあらゆる式は、各エントリが順序付けられたｐ−タプルである集合内にある単一の集合に縮小できる。我々は式のこの集合評価を正規化集合形式と呼ぶ。式の前記正規化集合形式は、テーブルの１つの軸を決定する。つまり前記テーブルの軸は、正規化集合と列内の集合エントリ間に１対１の対応があるように、列（または行または層）に分割される。図８は、複数の式から生じる軸の構成を描いている。

５．４．３ 代数特性
本発明では、代数式は（ｉ）ビジュアルテーブル７２０の根本的な表構造を決定するため、及び（ｉｉ）データベース５５８から引き出されるタプルを決定するための２つの目的のための集合として解釈されている。前者のケースでは、正規化集合形式内のｐ−タプルの配列は、それがビジュアルテーブル７２０の列、行及び層の配列を決定するために有意義である。その結果、我々の演算子に当てはまる唯一の代数特性は結合性である。可換演算子または分配演算子は正規化集合形式の配列を交換する代数走査を可能にするであろう。しかしながら、どのデータベースタプルを検索すべきかを決定するために解釈を実行するときには、集合解釈内のｐ−タプルの配列はデータベース照会のコンテキストでは有意義ではないため、演算子の特性に対するこれらの制約が緩和できる。具体的には、この目的のためだけに、集合解釈はシーケンスの代わりにバッグ（ｂａｇｓ）として処理され（したがって配列を廃棄し）、以下の代数特性を可能にする。
関連
（Ａ＋Ｂ）＋Ｃ＝Ａ＋（Ｂ＋Ｃ）
（Ａ．Ｂ）．Ｃ＝Ａ．（Ｂ．Ｃ）
（Ａ×Ｂ）×Ｃ＝Ａ×（Ｂ×Ｃ）
（Ａ／Ｂ）／Ｃ＝Ａ／（Ｂ／Ｃ）
分配
Ａ×（Ｂ＋Ｃ）＝（Ａ×Ｂ）＋（Ａ×Ｃ）
Ａ／（Ｂ＋Ｃ）＝（Ａ／Ｂ）＋（Ａ／Ｃ）
可換
Ａ＋Ｂ＝Ｂ＋Ａ
Ａ×Ｂ＝Ｂ×Ａ
Ａ／Ｂ＝Ｂ／Ａ
演算子がこれらの代数特性を可能にするために変更されると、演算子がビジュアルテーブル７２０を作成するために必要とされるデータベース照会またはデータキューブ予測を迅速に決定するために使用できる。

５．４．４
前記の項では、本発明にかかる代数の構文は演算子によって分離されるオペランドのシーケンスとして定められた。演算子の適用に対するいくつかの制約も与えられた。本項では、構文は文法を使用することにより正確にされる。文法を定義するため、終端記号の集合、非終端記号（ｎｏｎ−ｔｅｒｍｉｎａｌｓ）の集合、制作規則の集合、及び開始記号という４つのことが定められる。このようにして本発明による文法は、１０個の端末記号を有する。
記号 定義
ｑ_{ｆｉｅｌｄ} 定量フィールドの名称
ｏ_{ｆｉｅｌｄ} 序数フィールドの名称
ｑ_ｄｉｍ 定量次元レベルの名称
Ｏ_ｄｉｍ 序数次元レベルの名称
Ｃ 定数オペランド
．ｘ／＋ 代数の演算子
（） 括弧

以下は、文法のための制作規則である（Ｅは開始記号である）。
Ｅ → Ｏ_ｅｘｐ|Ｑ_ｅｘｐ
Ｏ_ｅｘｐ → （Ｏ_ｅｘｐ）|Ｏ_ｅｘｐ＋Ｏ_ｅｘｐ|Ｏ_ｅｘｐ×Ｏ_ｅｘｐ|Ｏ_ｅｘｐ／Ｏ_ｅｘｐ|Ｏ
Ｑ_ｅｘｐ → （Ｑ_ｅｘｐ）|Ｅ＋Ｑ_ｅｘｐ|Ｑ_ｅｘｐ＋Ｅ|（Ｑ_ｅｘｐ×Ｑ_ｅｘｐ|Ｑ
Ｏ → Ｏ_ｈｉｅｒ|ｏ_{ｆｉｅｌｄ}|ｃ
Ｏ_ｈｉｅｒ → Ｏ_ｈｉｅｒ．ｏ_ｄｉｍ|ｏ_ｄｉｍ
Ｑ → Ｏ_ｈｉｅｒ|ｑ_{ｆｉｅｌｄ}
Ｑ_ｈｉｅｒ → Ｏ_ｈｉｅｒ．ｑ_ｄｉｍ|ｑ_ｄｉｍ
以下はこの文法で表現される演算子に対する主要な構文制約である。
交差：定量オペランド、または定量オペランドを含む式は、交差演算子の右側オペランドだけである場合がある。
ネスト：ネスト演算子は序数オペランドまたは式に適用できるにすぎない。
ドット：ドット演算子は次元レベルに適用できるにすぎない。さらに、定量次元レベル次元階層の葉のレベルとしてだけ可能であるため、定量フィールドはドット演算子の一番右側のオペランドとして表示できるにすぎない。
連結：連結は任意のオペランドに適用できる。
ここまでは、代数式がテーブルを行と列にどのように分割するのかが説明された。代数がどのようにして層を扱うのかがここで説明される。

５．４．５ 層
本発明では、ビジュアルテーブル７２０内の層は、その構造がｘ軸式とｙ軸式によって定められる単一のｘ−ｙテーブルである。仕様内のあらゆる層は最終的な視覚化を形成するために前後逆にともに合成される。単一の視覚化は複数のデータソースを結合できる。各データソースは、異なる層または層の集合にマッピングされる。すべてのデータソースと層はテーブルのｘ軸とｙ軸に同じ構成を共用するが、各データソースはそのデータを層の中に分割するために別の式（ｚ軸）を有することがある。複数のデータソースの層化と層の分割は図１７に描かれている。本発明のいくつかの実施形態では、視覚化の各データソースが別の層にマッピングされる。データソースの層はそのデータソースのためのｚ軸式によって追加の層に分割できる。仕様内のすべての層は最終的な視覚化を形成するために前後逆にともに合成される。
定数オペランドは層化の重要な態様である。単一の視覚化は、複数の異種のデータベース５５８から構成されてよく、それぞれは別個の層にマッピングされ、すべての層はｘ軸とｙ軸にとって同じ式を共用しなければならない。しかしながら、視覚化されたデータベースの唯一の部分集合内に存在するｘ軸式とｙ軸式で序数フィールドを含むことが望ましいこともある。これが発生すると、定数オペランドは、フィールドが実際に出現する層内の序数フィールドのドメインに一致する所定の集合解釈を備える他の層のために生成される。したがって、式は層ごとに適切に評価できる。
データソースのｚ軸式はｘ軸とｙ軸の式よりさらに制約されている。具体的には、層化は別個でなければならないので、ｚ軸式は定量オペランドではなく、序数オペランドだけを含むことができる。言い換えると、ｚ軸式は、本発明の文法でＱ_ｅｘｐｒ製作規則に制約される。

５．４．６ まとめ
本発明の代数は、ビジュアルテーブル７２０の根本的な構造を記述するために簡潔であるが強力な表記を提供する。代数式は、テーブルが行、列及び層にどのように分割されるのかを定義し、さらにテーブルの各ペイン７２２内の空間符号化を定義する。
この点では、概念上のデータフローを考慮することが有効である。ビジュアルテーブル７２０構造を定義するだけではなく、（シェルフ７０８−１、７０８−４及び７０８−５に形成される）視覚的仕様の代数表現は、データベース５５８のどのタプルを選択し、各ペイン７２２の中にマッピングする必要があるのかを定義する。仕様が解釈されると、１つまたは複数の照会がデータベースからタプルを取り出すために生成される（図６、ステップ６０８、図１８、ステップ１８０２）。結果として生じるタプルは層とペインの中に区分される（図１８、ステップ１８０４）。それから、各ペイン内のタプルがグループ化され、並べ替えられ、集約される（図１８、ステップ１８０６）。いったんタプルがペイン７２２の中に並べ替えられると、それらは知覚可能なディスプレイを生じさせるためにグラフィックマークにマッピングされる。

５．５ 例示的な視覚的仕様
ドット演算子の優位点を理解するために、次元レベルが作成する問題点が説明される。図９に描かれている時間階層内のＭｏｎｔｈ（月）次元レベルを考慮する。Ｍｏｎｔｈ（月）次元レベルを評価するための考えられる方法は、例えば、｛１９９８．Ｑｔｒｌ．Ｊａｎ，．．．，１９９９．Ｑｔｒ４，Ｄｅｃ｝など、深度第１で次元階層を走査することで順序付けられ、一意性のためのルートまでのその経路を含む、各ノード値を一覧表示することであろう。この手法は次元レベルごとに一意の集合解釈を提供するが、それは代数の表現の豊かさを制限する。Ｍｏｎｔｈ（月）含むように構築される任意のビジュアルテーブル７２０もＹｅａｒ（年）を含まなければならない。複数年に渡る月次の値を要約する表示、つまりロバストシステム内でサポートされなければならない有効なビューを作成することは不可能である。しかしながら、興味深いことに、複数年に渡る月次値を要約することは、それは階層レベル全体での集約を必要とするため、データキューブなどの階層データベースの標準的な予測ではない。
単一集合まで次元レベルを縮小する方法の問題点に対する解決策はドット（「．」）演算子である。ＤＴがレベルＡとＢを含む階層を定義するディメンションテーブルであると定義され、ＤＴのスキーマの中でＡがＢに先行する場合には、
Ａ．Ｂ＝{（ａ．ｂ）|∃ｔ∈ＤＴｓｔＡ（ｒ）＝ａ＆Ｂ（ｒ）＝ｂ}
ここではｒはレコードであり、Ａ（ｒ）はレコードｒのオペランドＡの値である。したがって、ドットは、それぞれが適格化された値を含む単一値のタプルの集合を生じさせる。前記２つのオペランドが同じ次元階層のレベル（あるいは同じ階層のレベル上の動作の集合解釈）ではないか、あるいはＡがＤＴの方式の中でＢに先行しない（例えば、ＡがＤＴによって定義されるツリーの先祖レベルでなければならない）場合には、ドット演算子は空集合に評価される。この定義を用いると２つの式「月」と「年．月」は同等ではない。「月」は｛１月、２月，．．．，１２月｝として解釈されるのに対し、｛Ｙｅａｒ．Ｍｏｎｔｈ（年．月）｝は｛１９９８．Ｊａｎ，１９９８．Ｆｅｂ，．．．，１９９９．Ｄｅｃ．（１９９８．１月、１９９８．２月，．．，１９９８．１２月）｝として解釈される。完全に投入されたファクトテーブルにより、Ｙｅａｒ．Ｍｏｎｔｈ（年．月）はＹｅａｒ／Ｍｏｎｔｈ（年／月）に同等である（ここでは「／」は第５．４項に定められるネスト演算子である）。

５．６ 例
以下の例のそれぞれは、データベース分析が、データの詳細なビューに対する高度抽象化から進歩できる。さらに、各例は、表示されているデータ、ピボット次元を容易に変更し、分析プロセスの間のデータベース階層を掘り下げることができる重要性を示す。

５．６．１ 例１−携帯電話ネットワークの使用
図１９は、スタンフォード大学にあるゲーツ（Ｇａｔｅｓ）ビルのモバイルネットワークに入った、または出たあらゆるパケットの１２週の追跡を分析したものを示す。この追跡の詳細については、ＴａｎｇとＢａｋｅｒ「局所領域無線網の分析（Ａｎａｌｙｓｉｓ ｏｆ ａ Ｌｏｃａｌ−Ａｒｅａ Ｗｉｒｅｌｅｓｓ Ｎｅｔｗｏｒｋ）、モバイルコンピューティング及びネットワーキングに関する第６回国際会議の会議録（Ｐｒｏｃ．ｏｆ ｔｈｅ ６ｔｈ Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｃｏｎｆｅｒｅｎｃｅ ｏｎ Ｍｏｂｉｌｅ Ｃｏｍｐｕｔｉｎｇ ａｎｄ Ｎｅｔｗｏｒｋｉｎｇ）」、２０００年８月、１−１０ページを参照すること。１２週間にわたって、７８００万パケットヘッダが収集された。分析目標はモバイルネットワークの使用パターンを理解することである。このデータは、それぞれが複数の詳細レベルの多くの他の次元（ユーザ、時間、遠隔ホスト、トラフィック方向及びアプリケーション）のあるデータキューブに記憶される。この分析では，ユーザがシェフルの上にフィールドをドロップしたときに生成される照会は実行するために１秒から２秒を要し、数百から数万タプルを戻した。
分析を開始するために、アナリストは最初に、時間内のあらゆるパターンが、トラフィックの方向ごとに打ち分けられ、彩色された大部分の一般的な用途のパケットカウントとサイズ対時間を示す図１９Ａ内の一連の折れ線グラフを作成することによって見出すことができるかどうかを確かめる。これらのチャートでは、アナリストは、セッションはほぼ一貫しているが、ウェブが最も一貫して使用されたアプリケーションであることを確かめることができる。ファイル転送は最も一貫性がないが、入信ｆｔｐトラフィックと発信ｆｔｐトラフィック両方で最高のピークのいくらかも有する。ｙ軸上のログスケールに注意する。
トラフィックパターンのこの幅広い理解を考えると、アナリストによって提起される次の問題は、アプリケーションミックスが研究分野に応じてどのようにして変化するのかである。アナリストは経時的に研究分野ごとにパケットカウントの単一の折れ線グラフを作成するために表示を旋回する（曲線１９０２がウェブであり、曲線１９０４がセッションであり、曲線１９０６がｆｔｐである図１９Ｂ）。この内訳から、アナリストは、グラフィックスグループが大きな入信及び発信ファイル転送を担当し、システムグループが型にはまらずに高セッショントラフィックを有していたことが分かる。
好奇心をもって、アナリストは次に個々のプロジェクトグループ（図１９Ｃ）を確かめるためにさらに掘り下げ、ロボティックスラボは、特定のグループ（例えば学習グループはさらに多くのウェブトラフィックを有していたが、セッショントラフィックによって決定付けられるｍｏｂグループ）に応じて非常に異なる動作を有していたが、大きなファイル転送がグラフィックスラボ内のレンダリンググループのためであったことを発見した。

５．６．２ 例２−２０００年大統領選挙の結果
図２０は、２０００年の大統領選挙の結果を探査、解析するために使用されている本発明のシステム及び方法を示す。それを探査するために使用される視覚化は２つの別々のデータセットから作成されるため、このデータは特に興味深い。第１のデータセットは、米国内の州及び郡の詳細な多角形外形を記述する（マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）のＳＱＬＳｅｒｖｅｒに記憶される）約５００，０００タプルの関係型データベースである。追加の詳細レベルは、多角形の簡略化により構築され、結果として生じた詳細のレベルがＬｏｃａｔｉｏｎ（場所）階層を形成する。第２のデータセットは（マイクロソフト（Ｍｉｃｒｏｓｏｆｔ）のアナリシスサーバ（Ａｎａｌｙｓｉｓ Ｓｅｒｖｅｒ）内の）データキューブとして記憶され、（Ｌｏｃａｔｉｏｎ（場所）次元とともに）詳細な郡別投票結果も含んでいる。第１の２つの視覚化（図２０Ａと図２０Ｂ）内では、これらのデータセットは分析の前に明示的に結合される。最終的な視覚化（図２０Ｃ）では、本発明の層を使用してデータセットを視覚的に結合する能力に依存する。この分析では、概要視覚化のための１秒未満から照会のための実行時間は詳細な視覚化のための２秒に変化し、取り出された関係が数万のタプルを含んだ。
図２０Ａでは、アナリストは、Ｌｏｃａｔｉｏｎ（場所）階層のＳｔａｔｅ（州）レベルで郡全体の概要を作成し、どの候補がその州を勝ち取ったのかで各州を彩色した。アナリストはフロリダ州のさらに詳細な結果に関心があるため、分析はフロリダに焦点を当てるために緯度と経度の約数でフィルタリングし、詳細レベルを郡に偏光し、図２０Ｂを作成した。図２Ｃに示される最終的な視覚化では、アナリストは（再び緯度と経度約数をフィルタリングすることによって）さらにフロリダの南端に焦点を当てる。さらに、アナリストは視覚化に（直接的にデータキューブから読み取られる）２つの追加の層を付け加え、名前と各州で数えられた投票総数の両方を表示する。

５．６．３ 例３−コーヒーチェーンの履歴利益／売上高
例は図２１に描かれている。分析されているデータは、仮想の全国コーヒーチェーンのための事業測定基準の２年間であり、データキューブに記憶される約５，０００タプルを含んでいる。データは３つの主要な次元（Ｔｉｍｅ（時間）、Ｐｒｏｄｕｃｔｓ（製品）、及びＬｏｃａｔｉｏｎ（場所））で特徴付けられ、それぞれが複数の詳細レベルを備える。我々は、アナリストがマーケティング費用を削減することに関心があり、利益を出していない製品及びそのマーケティング費用に比例した売上高を特定しようとしているというシナリオを検討する。このシナリオで作成される視覚化のための典型的な照会時間は０．１秒と０．２秒の間であった。
作成された第１の視覚化、図２１Ａは、散布図行列としての３つの重要な約数（Ｐｒｏｆｉｔ（利益）、Ｓａｌｅｓ（売上高）、及びＭａｒｋｅｔｉｎｇ（マーケティング）の概要である。アナリストは詳細レベルのシェルフを使用して製品と州のレベルに掘り下げた。前記２つの円グラフは、分布のいくつかが、アナリストが期待していた正の相関関係を反映しないことに丸を付けた。さらに調べるために、アナリストは散布図行列を２つのグラフに縮小し、Ｍａｒｋｅｔ（市場）とＰｒｏｄｕｃｔｔｙｐｅ（製品種別）（図２１Ｂ）ごとにレコードに彩色し、このようにして東部領域内のエスプレッソ製品と西部領域内の茶製品を、（図２１Ｂで丸を付けられた）最悪のマーケティング費対利益率を有するとして特定する。
最終的な視覚化、図２１Ｃでは、アナリストは、Ｍａｒｋｅｔ（市場）とＰｒｏｄｕｃｔｔｙｐｅ（製品種別）ごとに１つ、積み重ね折れ線グラフの小さい複数の集合を作成することによって相関のさらに詳細な理解を得るためにデータを掘り下げる。各チャートの中では、データが個々の製品と州でさらに掘り下げられる。最後に、各バーはマーケティング費用で彩色される。視覚化で確かめることができるように、東部の「カフェモカ（Ｃａｆｆｅ Ｍｏｃｈａ）」などの複数の製品は高いマーケティングコストでマイナスの利益（下降するバー）を有する。このような業績不振の製品を特定すれば、アナリストはそれらに割り当てられるマーケティングコストを修正できる。

５．７ 引用された参考資料
本命際書中に引用されたすべての参考資料は、それぞれの個々の出版物または特許または特許明細書が具体的に且つ個別にすべての目的のために全体が参照することにより本書に組み込まれることが示された場合と同程度まで、その全体により、及びあらゆる目的で参照することにより本書に組み込まれる。

５．８ 代替実施形態
本発明は、コンピュータ読み取り可能記憶媒体に埋めこまれるコンピュータプログラム機構を備えるコンピュータプログラム製品として実現され得る。例えば、コンピュータプログラム製品は図５に示されるプログラムモジュールを含むことができるであろう。これらのプログラムモジュールはＣＤ−ＲＯＭ、磁気ディスク記憶製品、または他のコンピュータ読み取り可能データまたはプログラム記憶装置製品に記憶されてよい。コンピュータプログラム製品内のソフトウェアモジュールは、電子的にも、インターネットを介しても、あるいはそれ以外の場合搬送波上の（ソフトウェアモジュールが埋め込まれている）コンピュータデータ信号の伝送によっても電子的に分散できる。
本発明の多くの修正及び変形は、当業者に明らかなようにその精神及び範囲から逸脱することなく作成できる。ここに説明される特定の実施形態は、例示によってのみ提供され、本発明は、このようなクレームが資格が与えられる同等の完全な範囲とともに、添付の特許明細書に関してのみ制限されるべきである。

従来の技術に係る製品マネージャの四半期売上報告書の形式の未処理データを描く。 従来の技術に係る地域マネージャの四半期売上報告書の形式の未処理データを描く。 従来の技術に係るデータベースのためのスタースキーマを描く。 従来の技術に係るデータベースのスノーフレークスキーマを描く。 本発明のある実施形態に係る階層構造を有するデータベースの探査分析を容易にするコンピュータシステムを描く。 本発明のある実施形態による処理ステップを描く。 本発明のある実施形態による視覚的仕様を作成するためのユーザインタフェースを描く。 本発明の１つの実施形態による代表的な式の集合解釈及び結果として生じるテーブル構造の例を示す。 時間のための階層を描く。 本発明によるテーブルを描く。 本発明のある実施形態による処理ステップの例示的な図を提供する。 本発明のある実施形態による視覚的仕様の正規化集合形式から生成されたテブルのための構成を描く。 従来の技術に従って、データキューブ内の各軸がデータベーススキーマ内の次元（製品、場所、時刻）の詳細のレベルに対応する仮説コーヒーチェーンのデータキューブを描く。 従来の技術に従って、各次元が階層構造を有する特定のデータベーススキーマのためのデータキューブの格子を描く。 従来の技術に従って、三次元データキューブの投射、それにより分析にとって重要ではない次元全体で集約することによりデータベースの次元性を削減することを描く。 従来の技術に従って、キューブの１つまたは複数の次元の部材をフィルタリングすることによるデータキューブのスライスの構築を描く。 本発明のある実施形態に係る複数のデータソースの層化及び区分化を描く。 本発明のある実施形態に係るビジュアルテーブル内の１つまたは複数のペインとタプルの部分集合の関連付けを描く。 本発明の実施形態に係るネットワーク使用量の分析を描く。 本発明の実施形態に係る２０００年大統領選挙の結果の分析を描く。 本発明の実施形態に係る仮説のコーヒーチェーンの売上データの分析を描く。

Claims (132)

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. 前記仕様は前記複数のペインを複数のページに編成し、前記複数のページの各ページが前記複数のデータベース内のデータベースからタプルに割り当てられる、請求項２２に記載の方法。
26. 前記階層構造が複数のスキーマフィールドを含み、
    ビジュアルテーブルステップ（Ｂ）を前記構築することが、前記仕様に基づいた前記複数のペイン内の１つのペインに前記複数のスキーマフィールド内のスキーマフィールドを割り当てることをさらに含み、
    前記関連するステップ（Ｄ）内の前記ペインと関連付けられる前記タプルの前記部分集合が選択関数によって決定される、請求項１に記載の方法。
27. 前記選択関数が前記関係演算子または前記スキーマフィールドのアイデンティティを使用して、タプルの部分集合を形成する、請求項２６に記載の方法。
28. 前記関係演算子が選択演算子またはグループ化演算子である請求項２７に記載の方法。
29. 前記選択関数が、関係演算子を使用して、前記ペインと関連付けられるタプルの前記部分集合から新しいタプルを作成し、関係演算子が、並べ替え演算子、集約演算子、または変換演算子からなる群から選択される、請求項２６に記載の方法。
30. 及び前記ペインと関連付けられるタプルの前記部分集合により決定される、あるいはユーザによって選択される前記ペインと関連付けられるタプルの前記部分集合内の１つまたは複数のタプルによって決定される仕様を使用して前記構築するステップ（Ｂ）と、前記照会するステップ（Ｃ）と、前記関連付けるステップ（Ｄ）とを繰り返すことを含む、請求項１に記載の方法。
31. 前記ビジュアルテーブルが複数の軸を備え、前記複数の軸内の各軸がシェルフによって表わされる、請求項１に記載の方法。
32. 前記第１のデータベースがスキーマを備え、
    前記言語が前記スキーマの複数のフィールドを備え、
    前記ビジュアルテーブルが複数の軸を備え、前記複数の軸内の各軸がシェルフによって表され、
    前記仕様が、１つまたは複数の代数式を備え、前記仕様を前記提供することが、前記複数のフィールドの内の一つのフィールドを前記ビジュアルテーブルの軸を表すシェルフの上にドラッグし、それによって前記仕様の代数式を構築することとを含む、請求項１に記載の方法。
33. 前記第１のデータベースの前記階層構造を表示することをさらに含む、請求項１に記載の方法。
34. 前記仕様を記憶することをさらに含む、請求項１に記載の方法。
35. 前記記憶された仕様がブックマークとして使用可能とされる、請求項３４に記載の方法。
36. 前記記憶された仕様が取消操作またはやり直し操作を容易にする、請求項３４に記載の方法。
37. 前記第１のデータベースの前記階層構造は、前記第１のデータベースのデータベーススキーマから引き出され、前記データベーススキーマがスキーマフィールドを含む、請求項１に記載の方法。
38. 前記スキーマフィールドは、文字列、整数、短整数、倍整数、単精度浮動小数点数、倍精度浮動小数点数、及びオブジェクトハンドルからなる群から選択されるベースタイプであるか、あるいは整数のアレイ、倍整数のアレイ、短整数のアレイ、単精度浮動小数点数のアレイ、倍精度浮動小数点数のアレイ、及びオブジェクトハンドルのアレイからなる群から選択されるアレイタイプである、請求項３７に記載の方法。
39. 前記ビジュアルテーブルがウェブページに表示される、請求項１に記載の方法。
40. 前記第１のデータベースがフラットファイル、階層オンライン分析処理データキューブ、関係型データベース、またはオンライン分析処理データベースである、請求項１に記載の方法。
41. 前記第１のデータベースが明示的に定義される階層を有さず、前記決定するステップ（Ａ）が前記階層構造を決定するために前記第１のデータベースでデータフィールドを分析することを含む、請求項１に記載の方法。
42. 前記第１のデータベースがスタースキーマを有し、前記決定するステップ（Ａ）が前記階層構造を決定するために前記スタースキーマを分析することを含む、請求項１に記載の方法。
43. 前記第１のデータベースがリモートコンピュータによってホストされる、請求項１に記載の方法。
44. 属性ファイルが前記第１データベースと関連付けられる、請求項１に記載の方法。
45. コンピュータシステムと併せて使用されるコンピュータプログラム製品であって、前記コンピュータプログラム製品がコンピュータ読み取り可能記憶媒体とその中に埋め込まれたコンピュータプログラム機構とを備え、前記コンピュータプログラム機構が、
    第１のデータベースと、
    前記第１のデータベースの階層構造を決定するための命令を備えるデータベース階層モジュールと、
    前記第１のデータベースの階層構造に基づいた言語での仕様を取得することによって、ビジュアルテーブルを構築するための命令を備えるユーザインタフェースモジュールであって、前記ビジュアルテーブルが複数のペインから構成されるユーザインタフェースモジュールと、
    前記仕様に従ってタプルの集合を取り出すために前記第１のデータベースに問い合わせをするための命令を含むデータインタプリタモジュールと、
    前記１つまたは複数のペイン内の一つのペインと、前記タプルの集合の部分集合を関連付けるための命令を備えるビジュアルインタプリタモジュールと、
    グラフィックマークとして前記ペインのタプルの前記部分集合内の一つのタプルを符号化するための命令とを備える、コンピュータプログラム製品。
46. 前記タプルの集合内の複数のタプルが前記グラフィックマークで符号化される、請求項４５に記載のコンピュータプログラム製品。
47. 前記データインタプリタモジュールが、
    前記タプルの集合から新しいタプルを引き出すための命令と、
    前記タプルの集合に前記新しいタプルを組み込むための命令とをさらに備える、請求項４５に記載のコンピュータプログラム製品。
48. ビジュアルテーブルを構築するための前記命令が、前記仕様を使用して、複数の行と複数の列、複数の層、及び複数のページからなる群から選択される形式に前記複数のペインを編成するための命令を含む、請求項４５に記載のコンピュータプログラム製品。
49. 前記形式が階層的に編成される、請求項４８に記載のコンピュータプログラム製品。
50. 前記仕様がオペランドを含む代数式を備え、前記代数式が前記第１のデータベースの前記階層構造での動作を表し、前記オペランドが前記階層構造に出現するタイプである、請求項４５に記載のコンピュータプログラム製品。
51. 前記ユーザインプリタモジュールが、
    前記代数式を評価し、それによりタプルの順序付けられた集合を取得するための命令と、
    前記ビジュアルテーブル内の行、列、または層に前記タプルの順序付けられた集合をマッピングするための命令であって、前記行、前記列または前記層がタプルの前記順序付けられたタプル内の順序に基づいて順序付けられる複数のペインを備える命令とを備える、請求項５０に記載のコンピュータプログラム製品。
52. 前記代数式が、交差積、和集合、選択及び並べ替えからなる群から選択される関係演算子を含む、請求項５０に記載のコンピュータプログラム製品。
53. 前記関係演算子の優先順位がネスト操作によって指定される、請求項５２に記載のコンピュータプログラム製品。
54. 前記データベース階層モジュールが、第２のデータベースの階層構造を決定するための命令をさらに備え、
    前記仕様が前記第１のデータベースの階層構造の要素と、前記第２のデータベースの階層構造の要素とを備え、前記第１の要素が前記第１のデータベースから引き出される型タプルとして符号化されるオペランドを含み、前記第２の要素が前記第２のデータベースから引き出される型タプルとして符号化されるオペランドを含む、請求項４５に記載のコンピュータプログラム製品。
55. タプルの前記部分集合内のタプルがフィールドを備え、前記ビジュアルインタプリタモジュールが、色、値、サイズ、形状、句、または記号からなる群から選択されるグラフィック属性に前記フィールドをマッピングするための命令をさらに備える、請求項４５に記載のコンピュータプログラム製品。
56. タプルの前記部分集合内のタプルがフィールドを備え、前記フィールドが定量または序数として分類され、前記ビジュアルインタプリタモジュールが、
    前記フィールドが定量として分類される場合第１のグラフィック属性に前記フィールドをマッピングするための命令と、
    前記フィールドが序数として分類される場合第２のグラフィック属性に前記フィールドをマッピングするための命令とをさらに備える、請求項４５に記載のコンピュータプログラム製品。
57. タプルの前記部分集合内のタプルがフィールドを備え、前記フィールドが独立または従属として分類され、前記ビジュアルインタプリタモジュールが
    前記フィールドが独立として分類される場合第１のグラフィック属性に前記フィールドをマッピングするための命令と、
    前記フィールドが従属として分類されるときに第２のグラフィック属性に前記フィールドをマッピングするための命令とをさらに備える、請求項５６に記載のコンピュータプログラム製品。
58. 前記第１のグラフィック属性と前記第２のグラフィック属性が、それぞれ独立して色、値、サイズ、形状、句または記号である、請求項５６または５７に記載のコンピュータプログラム製品。
59. ビジュアルインタプリタモジュールが、
    前記タプルの集合内のタプルのすべてまたは一部とグループを形成するための命令と、
    前記グループに基づいてグラフィックを形成するための命令とをさらに備える、請求項４５に記載のコンピュータプログラム製品。
60. 前記グラフィックが、前記グループ内の各タプルを結合するための線であるか、前記グラフィックが前記グループ内の各タプルを封入する領域である、請求項５９に記載のコンピュータプログラム製品。
61. 前記データインタプリタモジュールが、前記仕様に基づいて照会を作成するための命令をさらに備える、請求項４５に記載のコンピュータプログラム製品。
62. 前記データインタプリタモジュールが、構造化照会言語（ＳＱＬ）照会、データベース照会、及びＭＤＸ照会からなる群から選択される関係代数演算子に前記照会をマッピングするための命令をさらに備える、請求項６１に記載のコンピュータプログラム製品。
63. 前記データインタプリタモジュールが、前記仕様を処理し、それによって問い合わせをするための前記命令によって実行される照会の数を削減するための命令をさらに備え、前記処理するための命令が、
    前記仕様内の式に横線を引くための命令と、
    前記仕様内の式を項和に変換するための命令と、
    前記項和内の項から照会を形成するための命令とを備える、請求項６２に記載のコンピュータプログラム製品。
64. 前記データインタプリタモジュールがネットワークを使用して前記第１のデータベースにアクセスするための命令を含む、請求項６２に記載のコンピュータプログラム製品。
65. 前記データベース階層モジュールが、複数のデータベース内の各データベースの階層構造を決定するための命令をさらに備え、前記複数のデータベースは前記第１のデータベースを含み、
    前記仕様は前記複数のデータベース内の１つまたは複数のデータベースの階層構造に基づいた言語で作成され、
    前記複数のデータベース内のデータベースのすべてまたは一部にアクセスするための命令をさらに備える、請求項４５に記載のコンピュータプログラム製品。
66. 前記データベース階層モジュールは、複数のデータベース内の各データベースの階層構造を決定するための命令をさらに備え、前記複数のデータベースが前記第１のデータベースを含み、
    前記言語は前記複数のデータベースのデータベースのすべてまたは一部の階層構造に基づき、
    前記データインタプリタモジュールは、前記第１のデータベースを含む前記複数のデータベースのすべてまたは前記一部に問い合わせするための命令をさらに備え、
    前記タプルの集合が前記複数のデータベースの前記すべてまたは前記一部から引き出されるタプルを含む、請求項４５に記載のコンピュータプログラム製品。
67. 前記仕様が複数の層の中に前記複数のペインを編成し、前記複数の層内の各層が前記複数のデータベース内の別のデータベースからタプルに割り当てられる、請求項６６に記載のコンピュータプログラム製品。
68. 前記仕様が前記複数のペインを複数の列と複数の行に編成し、前記複数の各列または前記複数の行内の各行が前記複数のデータベース内の別のデータベースからタプルに割り当てられる、請求項６６に記載のコンピュータプログラム製品。
69. 前記仕様が前記複数のペインを複数のページに編成し、前記複数のページ内の各ページが前記複数のデータベース内の別のデータベースからタプルに割り当てられる、請求項６６に記載のコンピュータプログラム製品。
70. 前記階層構造が複数のスキーマフィールドを含み、
    前記ユーザインタフェースモジュールが、前記仕様に基づいて前記複数のペインの一つのペインに前記複数のスキーマフィールドの１つのスキーマフィールドを割り当てるための命令をさらに備え、
    前記ビジュアルインタプリタモジュールが、選択関数を使用して前記ペインと関連付けられる前記タプルの前記部分集合を決定するための命令をさらに含む、請求項４５に記載の前記コンピュータプログラム製品。
71. 前記選択関数が、関係演算子または前記スキーマフィールドのアイデンティティを使用して、タプルの前記部分集合を形成する、請求項７０に記載のコンピュータプログラム製品。
72. 前記関係演算子が選択演算子またはグループ化演算子である、請求項７１に記載のコンピュータプログラム製品。
73. 前記選択関数が、関係演算子を使用して、前記ペインと関連付けられるタプルの前記部分集合から新しいタプルを作成し、前記関係演算子が並べ替え演算子、集約演算子、または変換演算子からなる群から選択される、請求項７０に記載のコンピュータプログラム製品。
74. 前記コンピュータプログラム機構が、前記ペインと関連付けられるタプルの前記部分集合により決定されるか、あるいはユーザによって選択される前記ペインと関連付けられるタプルの前記部分集合内の１つまたは複数のタプルによって決定される仕様を使用して、前記ユーザインタフェースモジュールの命令と、前記データインタプリタモジュールの命令と、前記ビジュアルインタプリタモジュールの命令とを繰り返すための命令をさらに備える、請求項４５に記載のコンピュータプログラム製品。
75. 前記ビジュアルテーブルが複数の軸を備え、前記複数の軸の各軸がシェルフによって表される、請求項４５に記載のコンピュータプログラム製品。
76. 前記第１のデータベースがスキーマを備え、
    前記言語が前記スキーマの中に複数のフィールドを備え、
    前記ビジュアルテーブルが複数の軸を備え、前記複数の軸の各軸がシェルフによって表され、
    前記仕様が１つまたは複数の代数式を備え、前記ユーザインタフェースモジュールが、
    ユーザが前記ビジュアルテーブルの軸を表すシェルフの上に前記複数のフィールド内のフィールドをドラッグし、それにより前記仕様の中に代数式を構築できるようにするための命令とをさらに備える、請求項４５に記載のコンピュータプログラム製品。
77. 前記コンピュータプログラム機構が前記第１のデータベースの階層構造を表示するための命令をさらに備える、請求項４５に記載のコンピュータプログラム製品。
78. 前記コンピュータプログラム機構が前記仕様を記憶するための命令をさらに備える、請求項４６に記載のコンピュータプログラム製品。
79. 前記記憶された仕様がブックマークとして使用可能とされる、請求項７８に記載のコンピュータプログラム製品。
80. 前記記憶された仕様が取消操作またはやり直し操作を容易にする、請求項７８に記載のコンピュータプログラム製品。
81. 前記第１のデータベースの前記階層構造が前記第１のデータベースのためのデータスキーマから引き出され、前記データベーススキーマがスキーマフィールドを含む、請求項４５に記載のコンピュータプログラム製品。
82. 前記スキーマフィールドが、文字列、整数、短整数、倍整数、単精度浮動小数点数、 倍精度浮動小数点数、及びオブジェクトハンドルからなる群から選択されるベースタイプであるか、整数のアレイ、あるいは倍整数のアレイ、短整数のアレイ単精度浮動小数点数のアレイ、倍精度浮動小数点数のアレイ、オブジェクトハンドルのアレイからなる群から選択されるアレイタイプである、請求項８１に記載のコンピュータプログラム製品。
83. 前記ビジュアルテーブルがウェブページに表示される、請求項４５に記載のコンピュータプログラム製品。
84. 前記第１のデータベースがフラットファイル、階層オンライン分析処理データキューブ、関係型データベース、またはオンライン分析処理データベースである、請求項４５に記載のコンピュータプログラム製品。
85. 前記第１のデータベースが明示的に定義される階層を有さず、前記データベース階層モジュールが前記階層構造を決定するために前記第１のデータベース内のデータフィールドを分析するための命令をさらに備える、請求孔４５に記載のコンピュータプログラム製品。
86. 前記第１のデータベースがスタースキーマを有し、前記データベース階層モジュールが前記階層構造を決定するために前記スタースキーマを分析するための命令を備える、請求項４５に記載のコンピュータプログラム製品。
87. 前記第１のデータベースがリモートコンピュータによってホストされる、請求項４５に記載のコンピュータプログラム製品。
88. 属性ファイルが前記第１データベースと関連付けられる、請求項４５に記載のコンピュータプログラム製品。
89. 中央演算処理装置と、
    前記中央演算処理装置に結合されるメモリを備えるグラフィックスを作成する為のコンピュータシステムであって、前記メモリが
    第１のデータベースと、
    前記第１のデータベースの階層構造を決定するための命令を備えるデータ階層モジュールと、
    前記第１のデータベースの階層構造に基づいた言語での仕様を取得することによって、ビジュアルテーブルを構築するための命令を備えるユーザインタフェースモジュールであって、前記ビジュアルテーブルが複数のペインから構成されるユーザインタフェースモジュールと、
    前記仕様に従ってタプルの集合を取り出すために前記第１のデータベースに問い合わせするための命令を備えるデータインタプリタモジュールと、
    前記タプルの集合の部分集合を前記複数のペイン内の１つのペインと関連付けるための命令を備えるビジュアルインタプリタモジュールと、
    グラフィックマークとして前記ペインのタプルの前記部分集合内のタプルを符号化するための命令とを備える、コンピュータシステム。
90. 前記タプルの集合内の複数のタプルが前記グラフィックマークで符号化される、請求項８９に記載のコンピュータシステム。
91. 前記データインタプリタモジュールが、
    前記タプルの集合から新しいタプルを引き出すための命令と、
    前記タプルの集合の中に前記新しいタプルを組み込むための命令とをさらに備える、請求項８９に記載のコンピュータシステム。
92. 前記テーブルを構築するための前記命令が、前記仕様を使用して複数の行と複数の列と、複数の層と複数のページからなる群から選択される形式に、前記複数のペインを編成するための命令を備える、請求項８９に記載のコンピュータシステム。
93. 前記形式が階層的に編成される、請求項９２に記載のコンピュータシステム。
94. 前記仕様がオペランドを含む代数式を備え、前記代数式が前記第１のデータベースの前記階層構造での演算を表し、前記オペランドが前記階層構造内に出現する型である、請求項８９に記載のコンピュータシステム。
95. 前記ユーザインタプリタモジュールが、
    前記代数式を評価し、それによりタプルの順序付けされた集合を取得するための命令と、
    前記ビジュアルテーブル内の行、列または層に前記タプルの順序付けられた集合をマッピングするための命令であって、
    前記行、前記列または前記層が、前記タプルの順序付けられた集合内の順序に基づいて順序付けられる複数のペインを備える命令とを備える、請求項９４に記載のコンピュータシステム。
96. 前記代数式が、交差積と、和集合と、選択または並べ替えとからなる群から選択される関係演算子を含む、請求項９４に記載のコンピュータシステム。
97. 前記関係演算子の優先順位がネスト操作によって指定される、請求項９６に記載のコンピュータシステム。
98. 前記データベース階層モジュールが第２のデータベースの階層構造を決定するための命令をさらに備え、
    前記仕様が前記第１のデータベースの階層構造の要素と、前記第２のデータベースの階層構造の要素とを備え、前記第１の要素が前記第１のデータベースから引き出される型タプルとして符号化されるオペランドを含み、前記第２の要素が前記第２のデータベースから引き出される型タプルとして符号化されるオペランドを含む、請求項８９に記載のコンピュータシステム。
99. タプルの前記部分集合内のタプルがフィールドを備え、前記ビジュアルインタプリタモジュールが、色、値、サイズ、形状、句、または記号からなる群から選択されるグラフィック属性に前記フィールドをマッピングするための命令をさらに備える、請求項８９に記載のコンピュータシステム。
100. タプルの前記部分集合内のタプルがフィールドを備え、前記フィールドが定量または序数として分類され、前記ビジュアルインタプリタモジュールが
     前記フィールドが定量として分類されるときに第１のグラフィック属性に前記フィールドをマッピングするための命令と、
     前記フィールドが序数として分類される場合前記フィールドを第２のグラフィック属性にマッピングするための命令とをさらに備える、請求項８９に記載のコンピュータシステム。
101. タプルの前記部分集合内のタプルがフィールドを備え、前記フィールドが独立または従属として分類され、前記ビジュアルインタプリタモジュールが、
     前記フィールドが独立として分類される場合第１のグラフィック属性に前記フィールドをマッピングするための命令と、
     前記フィールドが従属として分類される場合第２のグラフィック属性に前記フィールドをマッピングするための命令とをさらに備える、請求項８９に記載のコンピュータシステム。
102. 前記第１のグラフィック属性と前記第２のグラフィック属性がそれぞれ独立して、色、値、サイズ、形状、句または記号である、請求項１００または１０１に記載のコンピュータシステム。
103. 前記ビジュアルインタプリタモジュールが、
     前記タプルの集合内のタプルのすべてまたは一部でグループを形成するための命令と、
     前記グループに基づいてグラフィックを形成するための命令とをさらに備える、請求項８９に記載のコンピュータシステム。
104. 前記グラフィックが前記グループ内の各タプルを結合する線であるか、あるいは、前記グラフィックが前記グループ内の各タプルを封入する領域である、請求項１０３に記載のコンピュータシステム。
105. 前記データインタプリタモジュールが、前記仕様に基づいて照会を作成するための命令をさらに備える、請求項８９に記載のコンピュータシステム。
106. 前記データインタプリタモジュールが、構造化照会言語（ＳＱＬ）照会と、データキューブ照会と、ＭＤＸ照会とからなる群から選択される関係代数演算子に前記照会をマッピングするための命令をさらに備える、請求項１０５に記載のコンピュータシステム。
107. 前記データインタプリタモジュールが、前記仕様を処理し、それによって問い合わせのための前記照会によって実行される照会の数を削減するための命令をさらに備え、前記処理するための命令が、
     前記仕様の式に横線を引くための命令と、
     前記仕様内の式を項和に変換するための命令と、
     前記項和内の項から照会を形成するための命令とを備える、請求項１０５に記載のコンピュータシステム。
108. 前記データインタプリタモジュールが、ネットワークを使用して前記第１のデータベースにアクセスするための命令を含む、請求項１０５に記載のコンピュータシステム。
109. 前記データベース階層モジュールが複数のデータベース内の各データベースの階層構造を決定するための命令をさらに備え、前記複数のデータベースが前記第１のデータベースを含み、
     前記仕様が前記複数のデータベース内の１つまたは複数のデータベースの階層構造に基づいた言語で作成され、
     前記データインタプリタモジュールが前記複数のデータベース内のデータベースのすべてまたは一部にアクセスするための命令をさらに備える、請求項８９に記載のコンピュータシステム。
110. 前記データベース階層モジュールが、複数のデータベース内の各データベースの階層構造を決定するための命令をさらに備え、前記複数のデータベースが前記第１のデータベースを含み、
     前記言語が前記複数のデータベース内のデータベースのすべてまたは一部の階層構造に基づき、
     前記データインタプリタモジュールが前記第１のデータベースを含む前記複数のデータベースのすべてまたは前記一部に問い合わせるための命令をさらに備え、
     前記タプルの集合が前記複数のデータベースの前記すべてまたは前記一部から引き出されるタプルを含む、請求項８９に記載のコンピュータシステム。
111. 前記仕様が前記複数のペインを複数の層に編成し、前記複数の層の各層が前記複数のデータベース内の別のデータベースからのタプルに割り当てられる、請求項１１０に記載のコンピュータシステム。
112. 前記仕様が前記複数のペインを複数の列と複数の行に編成し、前記複数の列内の各列または前記複数の行内の各行が前記複数のデータベース内の別のデータベースからのタプルに割り当てられる、請求項１１０に記載のコンピュータシステム。
113. 前記仕様は前記複数のペインを複数のページに編成し、前記複数のページの各ページは前記複数のデータベース内の別のデータベースからのタプルに割り当てられる、請求項１１０に記載のコンピュータシステム。
114. 前記階層構造が複数のスキーマフィールドを含み、
     前記ユーザインタフェースモジュールが、前記仕様に基づいて前記複数のスキーマフィールド内の１つのスキーマフィールドを前記複数のペイン内の１つのペインに割り当てるための命令をさらに備え、
     前記ビジュアルインタプリタモジュールが、選択関数を使用して前記ペインと関連付けられるタプルの前記部分集合を決定するための命令をさらに備える、請求項８９に記載のコンピュータシステム。
115. 前記選択関数は、関係演算子または前記スキーマフィールドのアイデンティティを使用して、タプルの前記部分集合を形成する、請求項１１４に記載のコンピュータシステム。
116. 前記関係演算子が選択演算子またはグループ化演算子である、請求項１１５に記載のコンピュータシステム。
117. 前記選択関数が、関係演算子を使用して前記ペインと関連付けられるタプルの前記部分集合から新しいタプルを作成し、前記関係演算子が、並べ替え演算子、集約演算子、及び変換演算子からなる群から選択される、請求項１１４に記載のコンピュータシステム。
118. 前記メモリが、前記ペインと関連付けられるタプルの前記部分集合により決定される、あるいはユーザによって選択される前記ペインと関連付けられるタプルの前記部分集合の１つまたは複数のタプルによって決定される仕様を使用して、前記ユーザインタフェースモジュールの命令と、前記データインタプリタモジュールの命令と、前記ビジュアルインタプリタモジュールの命令とを繰り返すための命令をさらに備える、請求項８９に記載のコンピュータシステム。
119. 前記ビジュアルテーブルが複数の軸を備え、前記複数の軸内の各軸がシェルフによって表される、請求項８９に記載のコンピュータシステム。
120. 前記第１のデータベースがスキーマを備え、
     前記言語が前記スキーマの複数のフィールドを備え、
     前記ビジュアルテーブルが複数の軸を備え、前記複数の軸内の各軸がシェルフによって表され、
     前記仕様が１つまたは複数の代数式を備え、前記ユーザインタフェースモジュールが、
     ユーザが、前記ビジュアルテーブルの軸を表すシェルフの上に前記複数のフィールド１つのフィールドをドラッグし、それによって前記仕様の中で代数式を構築することができるようにするための命令をさらに備える、請求項８９に記載のコンピュータシステム。
121. 前記メモリが前記第１のデータベースの前記階層構造を表示するための命令をさらに備える、請求項８９に記載のコンピュータシステム。
122. 前記メモリが前記仕様を記憶するための命令をさらに備える、請求項８９に記載のコンピュータシステム。
123. 前記記憶された仕様がブックマークとして使用可能にされる、請求項１２２に記載のコンピュータシステム。
124. 前記記憶された仕様が取消操作またはやり直し操作を容易にする、請求項１２２に記載のコンピュータシステム。
125. 前記第１のデータベースの前記階層構造が、前記第１のデータベースのためのデータベーススキーマから引き出され、前記データベーススキーマがスキーマフィールドを含む、請求項８９に記載のコンピュータシステム。
126. 前記スキーマフィールドが、文字列、整数、短整数、倍整数、単精度浮動小数点数、 倍精度浮動小数点数、及びオブジェクトハンドルからなる群から選択されるベースタイプ、あるいは整数のアレイ、倍整数のアレイ、短整数のアレイ、単精度浮動小数点数のアレイ、 倍精度浮動小数点数のアレイ、及びオブジェクトハンドルのアレイからなる群から選択されるアレイタイプである、請求項１２５に記載のコンピュータシステム。
127. 前記ビジュアルテーブルがウェブページに表示される、請求項８９に記載のコンピュータシステム。
128. 前記第１のデータベースが、フラットファイル、階層オンライン分析処理データキューブ、関係型データベース、またはオンライン解析処理データベースからなる群から選択される、請求項８９に記載のコンピュータシステム。
129. 前記第１のデータベースが明示的に定義された階層を有さず、前記データベース階層モジュールが、前記階層構造を決定するために前記第１のデータベース内のデータフィールドを分析するための命令をさらに備える、請求項８９に記載のコンピュータシステム。
130. 前記第１のデータベースがスタースキーマを有し、前記データベース階層モジュールが、前記階層構造を決定するために、前記スタースキーマを分析するための命令を備える、請求項８９に記載のコンピュータシステム。
131. 前記第１のデータベースがリモートコンピュータによってホストされる、請求項８９に記載のコンピュータシステム。
132. 属性ファイルが前記第１のデータベースと関連付けられる、請求項８９に記載のコンピュータシステム。

Images