JP2022547519A - マルチファクトデータセットのデータ視覚化を生成するための適切な測度集計の活用 - Google Patents

Abstract

コンピュータが、データソースと、視覚変数と、データソースからのデータフィールドとを指定する視覚仕様を受信する。各視覚変数が、データフィールド（例えば、次元および／または測度）またはフィルタのどちらかに関連付けられている。コンピュータが、データソースを符号化するデータモデルを関連した論理テーブルのツリーとして取得する。各論理テーブルが、論理フィールドを含み、それらの各々は、データフィールドまたは論理テーブルに跨がる計算値のどちらかに対応する。コンピュータが、次元およびフィルタに対する次元サブクエリを生成する。また、コンピュータが、各測度に対して、次元によってグループ化された集計測度サブクエリも生成する。コンピュータが、次元サブクエリを集計測度サブクエリの各々に結合させることにより、最終クエリを形成する。その後、コンピュータが最終クエリを実行し、最終クエリの結果に従ったデータ視覚化を表示する。【選択図】図１

Description

開示された実装形態は、一般に、データ視覚化に関し、より具体的には、データセットのオブジェクトモデルを使用したデータセットのインタラクティブな視覚分析に関する。

データ視覚化アプリケーションによって、ユーザはビジネス上の意思決定をするのに重要な分布、傾向、異常値、および他の要因を含むデータセットを視覚的に理解することが可能となる。いくつかのデータ要素は、選択したデータセットからのデータに基づいて計算される必要がある。例えば、データ視覚化では、合計を使用してデータを集計することがよくある。いくつかのデータ視覚化アプリケーションによって、ユーザは「詳細度（Ｌｅｖｅｌ ｏｆ Ｄｅｔａｉｌ）」（ＬＯＤ）を指定することができ、これは、集計に対して使用することが可能である。しかしながら、データ視覚化に対して単一の詳細度を指定するだけでは、特定の計算を構築するには不十分である。

いくつかのデータ視覚化アプリケーションは、ユーザがデータフィールドを選択し、それらを特定のユーザインターフェース領域に配置してデータ視覚化を間接的に定義することによって、データソースから視覚化を構築することが可能なユーザインターフェースを提供する。例えば、２００３年６月２日に出願された発明名称「Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ ｔｈｅ Ｑｕｅｒｙ ａｎｄ Ｖｉｓｕａｌｉｚａｔｉｏｎ ｏｆ Ｍｕｌｔｉｄｉｍｅｎｓｉｏｎａｌ Ｄａｔａｂａｓｅｓ」の米国特許出願第１０／４５３，８３４号、現在は米国特許第７，０８９，２６６号を参照することで、その全体が本明細書に組み込まれる。しかしながら、複雑なデータソースおよび／または複数のデータソースが存在する場合、（もし、あるならば）ユーザの選択に基づいてどのような種類のデータ視覚化を生成すればよいのかがわからない場合がある。

加えて、システムによっては、ユーザが期待するものではないデータ視覚化を行うクエリを作成してしまう。場合によっては、データの一部の行が省略される（例えば、ファクトテーブルのうちの１つに対応するデータがない場合）。場合によっては、数値集計されたフィールドは、同一のデータ値が複数回カウントされているため、水増しされた合計を生成してしまう。エンドユーザが問題を認識していない、および／または何が問題を引き起こしているかがわからない可能性があるため、これらの問題は特に解決が困難になり得る。

特に複数のファクトテーブルがある場合、複数のテーブルからのデータを組み合わせたデータ視覚化を生成することが困難になり得る。場合によっては、データ視覚化を生成する前に、データのオブジェクトモデルを作成することが有益となり得る。事例によっては、あるヒトがデータの特定の専門家であり、そのヒトがオブジェクトモデルを作成することもある。その関係をオブジェクトモデルに格納することにより、データ視覚化アプリケーションはその情報を活用し、データにアクセスするすべてのユーザを、たとえ専門家でなくとも支援することができる。

オブジェクトは、名前の付いた属性の集まりである。オブジェクトは、多くの場合、Ｓｔｏｒｅなどの現実世界のオブジェクト、イベント、または概念に対応している。属性は、概念的にオブジェクトと１：１関係にあるオブジェクトの説明である。したがって、Ｓｔｏｒｅオブジェクトには、単一の［管理者名］または［従業員数］が関連付けられている場合がある。物理レベルでは、多くの場合、オブジェクトは関係テーブルの行として、またはＪＳＯＮのオブジェクトとして格納される。

クラスは、同一の属性を共有するオブジェクトの集まりである。クラス内のオブジェクトを比較し、それらを集計することは、分析的に意味のあるものでなければならない。物理レベルでは、多くの場合、クラスは関係テーブルとして、またはＪＳＯＮのオブジェクトの配列として格納される。

オブジェクトモデルは、クラスの集合と、それらの間の多対１関係の集合である。１対１関係で関連付けられているクラスは、ユーザにとって意味のある個別のものであっても、概念的には単一のクラスとして扱われる。加えて、１対１関係で関連付けられているクラスは、データ視覚化ユーザインターフェースで個別のクラスとして提示される場合がある。多対多関係は、関係を取り込む連想テーブルを追加することにより、概念的に２つの多対１関係に分割される。

オブジェクトモデルが作成されると、データ視覚化アプリケーションは様々な方法でユーザを支援することができる。いくつかの実装形態において、すでに選択されて、ユーザインターフェースのシェルフに配置されたデータフィールドに基づいて、データ視覚化アプリケーションは、追加のフィールドを推奨することができ、または、使用不可能な組み合わせを防止するために実行することができるアクションを制限することができる。いくつかの実装形態において、データ視覚化アプリケーションは、フィールドの選択においてユーザにかなりの自由度を与え、オブジェクトモデルを使用して、ユーザが選択した内容に従って１つ以上のデータ視覚化を構築する。

いくつかの実装形態に従って、方法はデータ視覚化を生成する。方法は、１つ以上のプロセッサおよびメモリを有するコンピュータで実施される。メモリが、１つ以上のプロセッサによる実行のために構成された１つ以上のプログラムを格納する。コンピュータが、データソース、複数の視覚変数、およびデータソースからの複数のデータフィールドを指定する視覚仕様を受信する。視覚変数の各々が、（ｉ）データフィールドのうちのそれぞれの１つ以上と、（ｉｉ）１つ以上のフィルタと、のどちらか一方に関連付けられ、データフィールドの各々が、次元または測度とのどちらかとして識別される。コンピュータが、データソースを符号化するデータモデル（またはオブジェクトモデル）を論理テーブルのツリーとして取得する。各論理テーブルが、その独自の物理表現を有し、それぞれの１つ以上の論理フィールドを含む。各論理フィールドが、データフィールドまたは１つ以上の論理テーブルに跨がる計算値のどちらかに対応する。ツリーの各エッジが、関連する２つの論理テーブルを接続する。コンピュータが、次元およびフィルタに対するデータフィールドを供給する論理テーブルに基づいて次元サブクエリを生成する。コンピュータが、各測定に対して、それぞれの測度およびフィルタに対するデータフィールドを供給する論理テーブルに基づいて、次元によってグループ化された集計測度サブクエリも生成する。コンピュータが、次元を使用して、集計測度サブクエリの各々に次元サブクエリを結合することにより、最終クエリを形成する。続いて、コンピュータが、データソースに対して最終クエリを実行して、データフィールドに対するデータ値の個別の順序付けられた組み合わせを含むタプルを検索する。次いで、コンピュータが、タプル内のデータフィールドに従って、かつ、データフィールドの各々が関連付けられている視覚変数に従って、データ視覚化を構築および表示する。

いくつかの実装形態において、コンピュータが、一連の演算を実施することにより、各集計測度サブクエリを生成する。コンピュータが、論理テーブルのツリーの測度サブツリーを計算する。測度サブツリーは、それぞれの測度に対するデータフィールドを提供するために必要とされる最小のサブツリーである。コンピュータが、論理テーブルのツリーの次元フィルタサブツリーも計算する。次元フィルタサブツリーは、次元およびフィルタに対する物理入力のすべてを供給するために必要とされる最小のサブツリーである。次元フィルタサブツリーが測度サブツリーといかなる論理テーブルをも共有していない場合、コンピュータが、測度サブツリーからの隣接する論理テーブルを次元フィルタサブツリーに追加する。コンピュータが、測度サブツリーをコンパイルして測度結合ツリーを取得し、かつ、次元フィルタサブツリーをコンパイルして次元フィルタ結合ツリーを取得する。コンピュータは、計算値およびフィルタを測度結合ツリーおよび次元フィルタ結合ツリーに層化させて、更新された測度サブツリーおよび更新された次元フィルタサブツリーをそれぞれ取得する。コンピュータが、次元と、（ｉ）論理テーブル間の関係からのキーと、（ｉｉ）次元および測度サブツリーと共有される計算値のデータフィールドとを含むリンクフィールドと、を使用するグループバイ（ｇｒｏｕｐ－ｂｙ）演算を適用することによって、更新された次元フィルタサブツリーを重複排除することで、重複排除された次元フィルタサブツリーを取得する。コンピュータが、重複排除された次元フィルタサブツリーと更新された測度サブツリーとを組み合わせて、集計測度サブクエリを取得する。

いくつかの実装形態において、コンピュータは、測度サブツリー内の論理テーブルを内部結合することによって測度サブツリーをコンパイルして、測度結合ツリーを取得する。

いくつかの実装形態において、コンピュータが、一連の演算を実施することによって次元フィルタサブツリーを計算する。コンピュータが、測度サブツリーと共有される次元フィルタサブツリー内の論理テーブルを内部結合し、かつ、測度サブツリーと共有されていない次元フィルタサブツリー内の論理テーブルを左結合（左外側結合とも称する）して、次元フィルタ結合ツリーを取得する。

いくつかの実装形態において、コンピュータが、一連の演算を実施することによって重複排除された次元フィルタサブツリーと更新された測度サブツリーとを組み合わせる。コンピュータが、重複排除された次元フィルタサブツリーがフィルタを含んでいるどうかを判定する。重複排除された次元フィルタサブツリーがフィルタを含んでいる場合、コンピュータが、更新された測度サブツリーを重複排除された次元フィルタサブツリーと内部結合する。重複排除された次元フィルタサブツリーがフィルタを含んでいない場合、コンピュータが、更新された測度サブツリーを重複排除された次元フィルタサブツリーと左外部結合する。

いくつかの実装形態において、コンピュータが、キーが第１の論理テーブルと第２の論理テーブルとの間の多対１の関係を示しているのか、または、１対１の関係を示しているのかを判定する。キーが、第１の論理テーブルと第２のテーブルとの間の多対１の関係を示している場合、コンピュータが、第１のテーブルおよび第２のテーブルを測度サブツリー内に含め、それによって、第１の論理テーブルおよび第２のテーブルの重複排除演算におけるグループバイを回避する。

いくつかの実装形態において、次元フィルタサブツリーが測度サブツリーに対して多対１および１対１のリンクに沿って排他的に結合している場合、コンピュータが、測度サブツリーおよび次元フィルタサブツリーによって共有されるテーブルを重複排除された次元フィルタサブツリーと置き換える。

いくつかの実装形態において、コンピュータが、論理テーブルのツリー内の第１の１つ以上の論理テーブルを内部結合することによって、次元サブクエリを生成する。第１の１つ以上の論理テーブルの各論理テーブルが、次元および／またはフィルタに対するデータフィールドを供給する。

いくつかの実装形態において、コンピュータが、外部結合を使用して、次元に対する次元サブクエリおよび集計測度サブクエリを結合し、かつ、各外部結合の後に合体（ＣＯＡＬＥＳＣＥ）を適用することによって、最終クエリを形成する。

いくつかの実装形態において、視覚化が次元を有さない場合、コンピュータが、集計測度サブクエリ間で完全な結合を実施して、最終クエリを形成する。

いくつかの実装形態に従って、データ視覚化を生成するためのシステムが、１つ以上のプロセッサと、メモリと、メモリに格納された１つ以上のプログラムとを含む。プログラムが、１つ以上のプロセッサによって実行されるように構成される。プログラムは、本明細書に記載の方法のいずれかを実施するための命令を含む。

いくつかの実装形態に従って、非一時的コンピュータ可読記憶媒体は、１つ以上のプロセッサとメモリとを有するコンピュータシステムによる実行のために構成された１つ以上のプログラムを格納する。１つ以上のプログラムは、本明細書に記載の方法のいずれかを実施するための命令を含む。

したがって、方法、システム、およびグラフィカルユーザインターフェースは、データセットのインタラクティブな視覚分析のために提供される。

本発明の前述の実装形態、および追加の実装形態をよりよく理解するために、同様の参照番号が図全体を通して対応する部分を参照する以下の図面と併せて、以下の発明を実施するための形態を参照されたい。

いくつかの実装形態に従ったデータ視覚化を構築する処理を概念的に示す。 いくつかの実装形態に従ったコンピューティングデバイスのブロック図である。 いくつかの実装形態に従ったデータ視覚化サーバのブロック図である。 いくつかの実装形態に従ったデータ視覚化ユーザインターフェースの例を提供する。 いくつかの実装形態に従ったデータモデルの例（またはオブジェクトモデル）を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、データモデルまたはオブジェクトモデルの例を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、クエリの例を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、クエリの例を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、クエリの例を示す。 いくつかの実装形態に従った、クエリの例を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、クエリの例を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、データ視覚化を示す。 いくつかの実装形態に従った、クエリの例を示す。 いくつかの実装形態に従った、オブジェクトモデルを使用してデータ視覚化を生成する方法のフローチャートを提供する。

同様の参照番号は、図面全体の対応する部分を参照している。

ここで、添付の図面に例示されている実装形態を詳細に参照する。以下の詳細な説明では、本発明の徹底した理解を提供するために、数多くの特定の詳細が記載されている。しかしながら、当業者であれば、これらの特定の詳細がなくても本発明を実施することができることは明らかであろう。

図１に示すように、インタラクティブなデータ視覚化アプリケーションのいくつかの実装形態は、データ視覚化ユーザインターフェース１０２を使用して、視覚仕様１０４を構築する。視覚仕様は、１つ以上のデータソース１０６を識別し、これは、（例えば、ユーザインターフェース１０２を表示しているのと同一のデバイスに）局所的に格納され得るか、または外部（例えば、データベースサーバまたはクラウド）に格納され得る。視覚仕様１０４はまた、視覚変数も含む。視覚変数は、データソース１０６から選択されたデータフィールドに従って、間接的に所望のデータ視覚化の特性を指定する。特に、ユーザは視覚変数の各々に０個以上のデータフィールドを割り当て、データフィールドの値によって、表示されるデータ視覚化が判定される。

ほとんどの事例では、視覚変数のすべてが使用されるわけではない。いくつかの事例において、一部の視覚変数は、２つ以上の割り当てられたデータフィールドを有する。このシナリオでは、視覚変数に対して割り当てられたデータフィールドの順序（例えば、データフィールドがユーザによって視覚変数に割り当てられた順序）は、通常、データ視覚化がどのように生成され、表示されるかに影響を及ぼす。

いくつかの実装形態において、オブジェクトモデル１０８（場合によってはデータモデルと称する）を使用して、適切なデータ視覚化を構築する。事例によっては、オブジェクトモデルは１つのデータソース（例えば、１つのＳＱＬデータベースまたは１つのスプレッドシートファイル）に与えられるが、オブジェクトモデルは２つ以上のデータソースを包含してよい。通常、無関係のデータソースは、個別のオブジェクトモデルを有する。いくつかの事例において、オブジェクトモデルは、物理的データソースのデータモデル（例えば、ＳＱＬデータベースのテーブルに対応するオブジェクトモデルのクラス）を厳密に模倣する。しかしながら、場合によっては、オブジェクトモデルは、物理的データソースよりも正規化されている（または正規化されていない）。オブジェクトモデルは、相互に１対１関係を有する属性（例えば、データフィールド）をグループ化してクラスを形成し、クラス間の多対１関係を識別する。以下の図では、多対１関係が矢印で示され、各関係の「多」側が、関係の「１」側よりも垂直方向に低くなっている。オブジェクトモデルはまた、データフィールド（属性）の各々を次元または測度のどちらかとして識別する。以下では、文字「Ｄ」（または「ｄ」）を使用して次元を表し、後者の「Ｍ」（または「ｍ」）を使用して測度を表す。オブジェクトモデル１０８が作成される場合、それによってユーザが選択するデータフィールドに基づいたデータ視覚化の構築が容易になり得る。単一のオブジェクトモデルは無制限の数の他の人々が使用できるため、データソースに対するオブジェクトモデルを構築することは通常、データソースの比較的専門家であるヒトに委任される。

ユーザが（例えば、グラフィカルユーザインターフェースを使用して、データフィールドをシェルフに配置することによって間接的に）データフィールドを視覚仕様に追加すると、データ視覚化アプリケーション２２２（またはウェブアプリケーション３２２）は、オブジェクトモデル１０８に従ってユーザが選択したデータフィールドをグループ化する（１１０）。このようなグループを、データフィールドセットと称する。多くの場合、ユーザが選択したデータフィールドはすべてが単一のデータフィールドセット内にある。事例によっては、２つ以上のデータフィールドセットが存在する。各測度ｍは、正確に１つのデータフィールドセット内にあるが、各次元ｄは、２つ以上のデータフィールドセット内にあり得る。

データ視覚化アプリケーション２２２（またはウェブアプリケーション３２２）は、第１のデータフィールドセットに対してデータソース１０６に照会し（１１２）、次いで、検索されたデータに対応する第１のデータ視覚化１２２を生成する。第１のデータ視覚化１２２は、第１のデータフィールドセットからデータフィールド２８４を割り当てた視覚仕様１０４における視覚変数２８２に従って作成される。データフィールドセットが１つしかない場合、視覚仕様１０４における情報のすべては、第１のデータ視覚化１２２を構築するために使用される。２つ以上のデータフィールドセットが存在する場合、第１のデータ視覚化１２２は、第１のデータフィールドセットに関連するすべての情報からなる第１の視覚副仕様に基づく。例えば、元の視覚仕様１０４が、データフィールドｆを使用するフィルタを含むと仮定する。フィールドｆが第１のデータフィールドセットに含まれる場合、フィルタは第１の視覚的副仕様の一部であり、したがって、第１のデータ視覚化１２２を生成するために使用される。

第２の（または後続の）データフィールドセットが存在する場合、データ視覚化アプリケーション２２２（またはウェブアプリケーション３２２）は、第２の（または後続の）データフィールドセットに対してデータソース１０６に照会し（１１４）、次に、検索されたデータに対応する第２の（または後続の）データ視覚化１２４を生成する。このデータ視覚化１２４は、第２の（または後続の）データフィールドセットからデータフィールド２８４を割り当てた視覚仕様１０４における視覚変数２８２に従って作成される。

図２は、データ視覚化アプリケーション２２２またはデータ視覚化ウェブアプリケーション３２２を実行してデータ視覚化１２２を表示することができるコンピューティングデバイス２００を示すブロック図である。いくつかの実装形態において、コンピューティングデバイスは、データ視覚化アプリケーション２２２に対するグラフィカルユーザインターフェース１０２を表示する。コンピューティングデバイス２００は、デスクトップコンピュータと、ラップトップコンピュータと、タブレットコンピュータと、ディスプレイおよびデータ視覚化アプリケーション２２２を実行できるプロセッサを備えた他のコンピューティングデバイスと、を含む。コンピューティングデバイス２００は、通常、メモリ２１４に格納されたモジュール、プログラムおよび／または命令を実行し、ならびに、それによって処理演算を実施するための１つ以上の処理ユニット／コア（ＣＰＵ）２０２と、１つ以上のネットワークまたは他の通信インターフェース２０４と、メモリ２１４と、これらの構成要素を相互接続するための１つ以上の通信バス２１２と、を含む。通信バス２１２は、システム構成要素間の通信を相互接続および制御する回路網を含み得る。コンピューティングデバイス２００は、ディスプレイ２０８および１つ以上の入力デバイスまたは機構２１０を含むユーザインターフェース２０６を含む。いくつかの実装形態において、入力デバイス／機構はキーボードを含み、いくつかの実装形態において、入力デバイス／機構は「ソフト」キーボードを含み、これは、ディスプレイ２０８に必要に応じて表示され、それにより、ユーザがディスプレイ２０８に現れる「キーを押す」ことが可能になる。いくつかの実装形態において、ディスプレイ２０８および入力デバイス／機構２１０は、タッチスクリーンディスプレイ（タッチセンシティブディスプレイとも称される）を備える。いくつかの実装形態において、ディスプレイは、コンピューティングデバイス２００の一体化された部分である。いくつかの実装形態において、ディスプレイは別個のディスプレイデバイスである。

いくつかの実装形態において、メモリ２１４は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ、または他のランダムアクセス固体メモリデバイスなどの高速ランダムアクセスメモリを含む。いくつかの実装形態において、メモリ２１４は、１つ以上の磁気ディスク記憶デバイス、光ディスク記憶デバイス、フラッシュメモリデバイス、または他の不揮発性固体記憶デバイスなどの不揮発性メモリを含む。いくつかの実装形態において、メモリ２１４は、ＣＰＵ２０２から遠隔に位置する１つ以上の記憶デバイスを含む。メモリ２１４、または代替的にメモリ２１４内の不揮発性メモリデバイスは、非一時的なコンピュータ可読記憶媒体を含む。いくつかの実装形態において、メモリ２１４、またはメモリ２１４のコンピュータ可読記憶媒体は、以下のプログラム、モジュール、およびデータ構造、またはそれらのサブセットを格納する。
・オペレーティングシステム２１６、それは、様々な基本的なシステムサービスを処理し、ハードウェアに依存するタスクを実施するための手順を含む。
・通信モジュール２１８、それは、１つ以上の通信ネットワークインターフェース２０４（有線または無線）およびインターネット、他の広域ネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなどのような１つ以上の通信ネットワークを介して、コンピューティングデバイス２００を他のコンピュータおよびデバイスに接続するために使用される。
・ウェブブラウザ２２０（または他のクライアントアプリケーション）、それにより、ユーザはネットワークを用いて遠隔のコンピュータまたはデバイスと通信することができる。
・データ視覚化アプリケーション２２２、それは、ユーザが視覚グラフィックス（例えば、個々のデータ視覚化または複数の関連するデータ視覚化を備えたダッシュボード）を作成するためのグラフィカルユーザインターフェース１０２を提供する。いくつかの実装形態において、データ視覚化アプリケーション２２２は、スタンドアロンアプリケーション（例えば、デスクトップアプリケーション）として実行する。いくつかの実装形態において、データ視覚化アプリケーション２２２は、ウェブブラウザ２２０内で（例えば、ウェブアプリケーション３２２として）以下を実行する。
・グラフィカルユーザインターフェース１０２、それにより、以下の図４に示されるように、ユーザは要素を視覚的に指定することによってデータ視覚化を構築することができる。
・いくつかの実装形態において、ユーザインターフェース１０２は、所望のデータ視覚化の特性を指定するために使用される複数のシェルフ領域２５０を含む。いくつかの実装形態において、シェルフ領域２５０は、列シェルフ２３０および行シェルフ２３２を含み、これらは、所望のデータ視覚化におけるデータの配置を指定するために使用される。一般に、列シェルフ２３０に配置されたフィールドは、データ視覚化における列を定義するために使用される（例えば、視覚マークのｘ座標）。同様に、行シェルフ２３２に配置されたフィールドは、データ視覚化における行を定義する（例えば、視覚マークのｙ座標）。いくつかの実装形態において、シェルフ領域２５０は、フィルタシェルフ２６２を含み、これにより、ユーザは、選択されたデータフィールドに従って表示されるデータを制限することが可能になる（例えば、所定のフィールドが特定の値を有するか、または、特定の範囲内の値を有する行にデータを制限する）。いくつかの実装形態において、シェルフ領域２５０は、データマークの様々な符号化を指定するために使用されるマークシェルフ２６４を含む。いくつかの実装形態において、マークシェルフ２６４は、（データフィールドに基づいてデータマークの色を指定するための）色符号化アイコン２７０と、（データフィールドに基づいてデータマークのサイズを指定するための）サイズ符号化アイコン２７２と、（データマークに関連付けられたラベルを指定するための）テキスト符号化アイコンと、（データ視覚化に対する詳細レベルを指定または修正するための）視覚レベル詳細アイコン２２８と、を含む。
・視覚仕様１０４、それらは、所望のデータ視覚化の特性を定義するために使用される。いくつかの実装形態において、視覚仕様１０４は、ユーザインターフェース１０２を使用して構築される。視覚仕様は、識別されたデータソース２８０を含み（すなわち、データソースが何であるかを指定する）、これは、データソース１０６を見つけるのに十分な情報（例えば、データソース名またはネットワークフルパス名）を提供する。視覚仕様１０４はまた、視覚変数２８２と、視覚変数の各々に対して割り当てられたデータフィールド２８４と、を含む。いくつかの実装形態において、視覚仕様は、シェルフ領域２５０の各々に対応する視覚変数を有する。いくつかの実装形態において、視覚変数は、コンピューティングデバイス２００に関するコンテキスト情報、ユーザ選好情報、またはシェルフ領域として実装されていない他のデータ視覚化機能（例えば、分析機能）などの他の情報も含む。
・１つ以上のオブジェクトモデル１０８、それはデータソース１０６の構造を識別する。オブジェクトモデルでは、データフィールド（属性）はクラスに編成され、各クラスにおける属性は相互に１対１で対応する。オブジェクトモデルは、クラス間の多対１関係も含む。事例によっては、オブジェクトモデルは、データベース内の各テーブルをクラスにマッピングし、クラス間の多対１関係は、テーブル間の外部キー関係に対応する。事例によっては、基礎となるソースのデータモデルが、この単純な方法でオブジェクトモデルにきれいにマッピングされないため、オブジェクトモデルは、生データを適切なクラスオブジェクトに変換する方法を指定する情報が含む。事例によっては、生データソースは単純なファイル（例えば、スプレッドシート）であり、複数のクラスに変換される。
・データ視覚化ジェネレータ２９０、それは、視覚仕様に従ってデータ視覚化を生成し、かつ、表示する。いくつかの実装形態によれば、データ視覚化ジェネレータ２９０は、オブジェクトモデル１０８を使用して、クエリ２９４（例えば、次元サブクエリ、集計測度サブクエリ、および／または最終クエリ）を生成し、かつ／または、クエリオプティマイザ２９２を使用してクエリを最適化する。クエリの生成と最適化の手法の詳細は、いくつかの実装形態に従って、図５Ａ－１１を参照して以下に説明される。
・視覚化パラメータ２３６、それは、視覚仕様１０４およびデータソース１０６によって提供される情報以外の、データ視覚化アプリケーション２２２によって使用される情報を含む。
・０個以上のデータベースまたはデータソース１０６（例えば、第１のデータソース１０６－１）、それは、データ視覚化アプリケーション２２２によって使用される。いくつかの実装形態において、データソースは、スプレッドシートファイル、ＣＳＶファイル、ＸＭＬファイル、フラットファイル、ＪＳＯＮファイル、リレーショナルデータベースのテーブル、クラウドデータベース、または、統計データベースとして格納され得る。

上述の識別された実行可能モジュール、アプリケーション、または一式の手順の各々は、１つ以上の上述のメモリデバイスに格納され得、上述の機能を実施するための一式の命令に対応する。上述の識別されたモジュールまたはプログラム（すなわち、一式の命令）は、別個のソフトウェアプログラム、手順、またはモジュールとして実装される必要はなく、したがって、これらのモジュールの様々なサブセットは、様々な実装形態において組み合わされるか、さもなければ再配置され得る。いくつかの実装形態において、メモリ２１４は、上述の識別されたモジュールおよびデータ構造のサブセットを格納する。いくつかの実装形態において、メモリ２１４は、上述されていない追加のモジュールまたはデータ構造を格納する。

図２は、コンピューティングデバイス２００を示しているが、図２は、本明細書で説明されている実装形態の構造的概略としてではなく、むしろ存在し得る様々な特徴の機能的説明としてより意図されている。実際には、当業者によって認識されるように、別個に示されたアイテムを組み合わせることができ、いくつかのアイテムを分離させることができ得る。

図３は、いくつかの実装形態に従ったデータ視覚化サーバ３００のブロック図である。データ視覚化サーバ３００は、１つ以上のデータベース３２８のホストとして動作し得、または、様々な実行可能アプリケーションまたはモジュールを提供し得る。サーバ３００は、通常、１つ以上の処理ユニット／コア（ＣＰＵ）３０２と、１つ以上のネットワークインターフェース３０４と、メモリ３１４と、これらのコンポーネントを相互接続するための１つ以上の通信バス３１２と、を含む。いくつかの実装形態において、サーバ３００はユーザインターフェース３０６を備え、それは、ディスプレイ３０８と、キーボードおよびマウスなどの１つ以上の入力デバイス３１０と、を含む。いくつかの実装形態において、通信バス３１２は、システムコンポーネント間の通信を相互接続および制御する回路（チップセットとも称する）を含む。

いくつかの実装形態において、メモリ３１４は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ、または他のランダムアクセス固体メモリデバイスなどの高速ランダムアクセスメモリを含み、１つ以上の磁気ディスク記憶デバイス、光ディスク記憶デバイス、フラッシュメモリデバイス、または他の不揮発性固体記憶デバイスなどの不揮発性メモリを含んでもよい。いくつかの実装形態において、メモリ３１４は、ＣＰＵ３０２から遠隔に位置する１つ以上の記憶デバイスを含む。メモリ３１４、または代替的にメモリ３１４内の不揮発性メモリデバイスは、非一時的なコンピュータ可読記憶媒体を含む。

いくつかの実装形態において、メモリ３１４、またはメモリ３１４のコンピュータ可読記憶媒体は、以下のプログラム、モジュール、およびデータ構造、またはそれらのサブセットを格納する。
・オペレーティングシステム３１６、それは、様々な基本的なシステムサービスを処理し、ハードウェアに依存するタスクを実施するための手順を含む。
・ネットワーク通信モジュール３１８、それは、１つ以上の通信ネットワークインターフェース３０４（有線または無線）およびインターネット、他の広域ネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなどのような１つ以上の通信ネットワークを介して、サーバ３００を他のコンピュータに接続するために使用される。
・（ＨＴＴＰサーバなどの）ウェブサーバ３２０、それは、ユーザからのウェブ要求を受信し、応答ウェブページまたは他のリソースを提供することで応答する。
・データ視覚化ウェブアプリケーション３２２、それは、ユーザのコンピューティングデバイス２００上のウェブブラウザ２２０によってダウンロードされ、実行され得る。一般に、データ視覚化ウェブアプリケーション３２２は、デスクトップデータ視覚化アプリケーション２２２と同一の機能を有するが、ネットワーク接続を備えた任意の場所の任意のデバイスからのアクセスの柔軟性を提供し、インストールおよびメンテナンスを必要としない。いくつかの実装形態において、データ視覚化ウェブアプリケーション３２２は、特定のタスクを実施するための様々なソフトウェアモジュールを含む。いくつかの実装形態において、ウェブアプリケーション３２２は、ウェブアプリケーション３２２のすべての態様に対してユーザインターフェースを提供するユーザインターフェースモジュール３２４を含む。いくつかの実装形態において、ユーザインターフェースモジュール３２４は、コンピューティングデバイス２００に対して上述したようなシェルフ領域２５０を指定する。
・データ視覚化ウェブアプリケーションは、ユーザが所望のデータ視覚化の特性を選択するときに、視覚仕様１０４も格納する。視覚仕様１０４、およびそれらが格納するデータは、コンピューティングデバイス２００に対して上述されている。
・コンピューティングデバイス２００に対して上述された１つ以上のオブジェクトモデル１０８。
・データ視覚化ジェネレータ２９０、それは、ユーザが選択したデータソースおよびデータフィールド、ならびにデータソース１０６を記述する１つ以上のオブジェクトモデルに従ってデータ視覚化を生成および表示する。データ視覚化ジェネレータの演算は、コンピューティングデバイス２００に関して上述されている。
・いくつかの実装形態において、ウェブアプリケーション３２２はデータ検索モジュール３２６を含み、それは、クエリを構築および実行して、１つ以上のデータソース１０６からデータを検索する。データソース１０６は、サーバ３００上に局所的に格納され得るか、または外部データベース３２８に格納され得る。いくつかの実装形態において、２つ以上のデータソースからのデータが混合される場合がある。いくつかの実装形態において、データ検索モジュール３２６は、図２のコンピューティングデバイス２００に対して上述したように視覚仕様１０４を使用してクエリを構築する。
・いくつかの実装形態において、メモリは、コンピューティングデバイス２００の前に上述したように、視覚化パラメータ２３６を格納する。
・１つ以上のデータベース３２８、それはデータ視覚化ウェブアプリケーション３２２またはデータ視覚化アプリケーション２２２によって使用または作成されたデータを格納する。データベース３２８は、データソース１０６を格納してよく、それは生成されたデータ視覚化で使用されるデータを提供する。各データソース１０６は、１つ以上のデータフィールド３３０を含む。いくつかの実装形態において、データベース３２８は、ユーザ選好を格納する。いくつかの実装形態において、データベース３２８は、データ視覚化履歴ログ３３４を含む。いくつかの実装形態において、履歴ログ３３４は、データ視覚化がデータ視覚化をレンダリングするたびに追跡する。

データベース３２８は、多くの異なるフォーマットでデータを格納してよく、一般に、各々が複数のデータフィールド３３０を有する多くの個別のテーブルを含む。いくつかのデータソースは、単一のテーブルを含む。データフィールド３３０は、データソースからの生フィールド（例えば、データベーステーブルからの列またはスプレッドシートからの列）と、１つ以上の他のフィールドから計算または作成され得る派生データフィールドとの双方を含む。例えば、派生データフィールドは、日付フィールドからの月または四半期の計算、２つの日付フィールド間の期間の計算、定量フィールドの累積合計の計算、成長率の計算などを含む。事例によっては、派生データフィールドは、データベース内の格納された手続きまたはビューによってアクセスされる。いくつかの実装形態において、派生データフィールド３３０の定義は、データソース１０６とは別個に格納される。いくつかの実装形態において、データベース３２８は、各ユーザに対する一式のユーザ選好を格納する。ユーザ選好は、データ視覚化ウェブアプリケーション３２２（またはアプリケーション２２２）が一式のデータフィールド３３０を表示する方法について推奨を行うときに使用され得る。いくつかの実装形態において、データベース３２８は、生成された各データ視覚化に関する情報を格納するデータ視覚化履歴ログ３３４を格納する。いくつかの実装形態において、データベース３２８は、データ視覚化アプリケーション２２２またはデータ視覚化ウェブアプリケーション３２２によって使用される他の情報を含む、他の情報を格納する。データベース３２８は、データ視覚化サーバ３００から分離されてよく、またはデータ視覚化サーバ（またはその両方）とともに含まれてもよい。

いくつかの実装形態において、データ視覚化履歴ログ３３４は、ユーザによって選択された視覚仕様１０４を格納し、これは、ユーザ識別子と、データ視覚化が作成されたときのタイムスタンプと、データ視覚化で使用されるデータフィールドのリストと、データ視覚化の種類（「ビュータイプ」または「チャートタイプ」とも称する）と、データ符号化（例えば、マークの色とサイズ）と、選択したデータの関係と、使用するコネクタと、を含んでよい。いくつかの実装形態において、各データ視覚化の１つ以上のサムネイル画像も格納される。実装形態によっては、データソースの名前と場所、データ視覚化に含まれていたデータソースの行数、データ視覚化ソフトウェアのバージョンなど、作成されたデータ視覚化に関する追加情報を格納する。

上述の識別された実行可能モジュール、アプリケーション、または一式の手順の各々は、１つ以上のメモリデバイスに格納され得、上述の機能を実施するための一式の命令に対応する。上述の識別されたモジュールまたはプログラム（すなわち、一式の命令）は、別個のソフトウェアプログラム、手順、またはモジュールとして実装される必要はなく、したがって、これらのモジュールの様々なサブセットは、様々な実装形態において組み合わされるか、または別様に再配置され得る。いくつかの実装形態において、メモリ３１４は、上述の識別されたモジュールおよびデータ構造のサブセットを格納する。いくつかの実装形態において、メモリ３１４は、上述されていない追加のモジュールまたはデータ構造を格納し得る。

図３は、データ視覚化サーバ３００を示しているが、図３は、本明細書で説明されている実装形態の構造的概略としてではなく、むしろ存在し得る様々な特徴の機能的説明としてより意図されている。実際には、当業者によって認識されるように、別個に示されたアイテムを組み合わせることができ、いくつかのアイテムを分離することができる。加えて、サーバ３００に関して上に示したプログラム、機能、手順、またはデータのいくつかは、コンピューティングデバイス２００上に格納または実行され得る。いくつかの実装形態において、機能および／またはデータは、コンピューティングデバイス２００と１つ以上のサーバ３００との間で割り当てられ得る。さらに、当業者は、図３が単一の物理デバイスを表す必要がないことを認識している。いくつかの実装形態において、サーバ機能は、サーバシステムを含む複数の物理デバイスに渡って割り当てられる。本明細書で使用される場合、「サーバ」または「データ視覚化サーバ」への言及は、説明された機能を提供するサーバの様々なグループ、集まり、または配列を含み、物理サーバは物理的に併置される必要はない（例えば、個々の物理デバイスは米国全体または世界中に広がり得る）。

図４は、いくつかの実装形態に従った、データ視覚化ユーザインターフェース１０２を示す。ユーザインターフェース１０２は、データペインとも称されるスキーマ情報領域４１０を含む。スキーマ情報領域４１０は、データ視覚化を構築するために選択および使用され得る名前付きのデータ要素（例えば、フィールド名）を提供する。いくつかの実装形態において、フィールド名のリストは、次元のグループと測度のグループ（通常は数量）とに分けられる。いくつかの実装形態には、パラメータのリストも含まれる。グラフィカルユーザインターフェース１０２はまた、データ視覚化領域４１２も含む。データ視覚化領域４１２は、列シェルフ領域２３０および行シェルフ領域２３２などの複数のシェルフ領域２５０を含む。これらは、列シェルフ２３０および行シェルフ２３２とも称される。加えて、このユーザインターフェース１０２は、１つ以上のフィルタ４２４を含み得るフィルタシェルフ２６２を備える。

ここに示すように、データ視覚化領域４１２はまた、視覚グラフィックを表示するための大きなスペースを有する。この図ではまだデータ要素が選択されていないため、スペースには最初は視覚グラフィックを有していない。

ユーザは、１つ以上のデータソース１０６（コンピューティングデバイス２００に格納され得るか、または遠隔で格納され得る）を選択し、データソースからデータフィールドを選択し、選択されたフィールドを使用して視覚グラフィックを定義する。データ視覚化アプリケーション２２２（またはウェブアプリケーション３２２）は、生成されたグラフィック１２２をデータ視覚化領域４１２に表示する。いくつかの実装形態において、ユーザが提供する情報は、視覚仕様１０４として格納される。

いくつかの実装形態において、データ視覚化領域４１２は、マークシェルフ２６４を含む。マークシェルフ２６４によって、ユーザはデータマークの様々な符号化４２６を指定することができる。いくつかの実装形態において、マークシェルフは、色符号化アイコン２７０、サイズ符号化アイコン２７２、テキスト符号化アイコン２７４、および／または視覚レベル詳細アイコン２２８を含み、これらは、データ視覚化に対する詳細レベルを指定または変更するために使用され得る。

いくつかの実装形態において、データ視覚化プラットフォームによって、データが複数の物理テーブルからのものである場合であっても、ユーザは単一の論理テーブルを使用してドラッグアンドドロップアクションで視覚化を構築することができる。論理テーブルは、ピボット、結合、および併合を含むことができる物理モデリングによって作成され得る。物理モデリングによって結合されたテーブルは、論理テーブル自体を表す。Ｔａｂｌｅａｕなどの一部のデータ視覚化プラットフォームでは、クエリ生成モデルがユーザアクションを物理テーブルからのデータの基になるクエリに自動的にマップする。

いくつかの実装形態において、分析者がオブジェクトモデルを作成する。その例を図５Ａに示し、６つの論理テーブルを有する。図５Ａの例では、各テーブルにその独自の測度粒度があり、データの実際の物理的な格納とは無関係に、論理テーブルとしてより適切にモデル化されている。例示的なオブジェクトモデルは、注文テーブル５０４への結合５１４および製品テーブル５０６への別の結合５１６を有するラインアイテムテーブル５０２を含む。この例はまた、住所テーブル５０８への結合５１８および顧客テーブル５１０への別の結合５２０を有する注文テーブル５０４も示す。住所テーブル５０８は、州テーブル５１２への結合５２２を有する。

ユーザが図５Ｂに示す視覚化５３０を作成すると仮定する。この場合、売上高５２４はラインアイテムテーブル５０２の測度であり、人口５２６は州テーブル５１２の測度である。売上高に対する正しい結果を導き出すことは可能であるが、データ視覚化は、人口の測度値を誇張している。この例では、人口は一部の州に対して数十億の人々５２８として示されている。この重複の理由は、データ視覚化フレームワークが結合されたすべてのテーブルを照会したためである。この結合ツリーの粒度は、ラインアイテム５０２の粒度である。つまり、各行はラインアイテムを表し、ラインアイテムが発生した州の人口を含む列が含む。したがって、総（人口）は、州の人口にその州に対するラインアイテムの数を掛けたものになる。この問題は、６つの概念上の論理テーブルが単一の論理テーブルとして扱われたために発生する。

測度の重複を修正する１つの解決策は、詳細レベルの計算を使用することである。例えば、計算｛Ｆｉｘｅｄ［州］：ＭＩＮ（［人口］）｝を書き直して、人口をネイティブの粒度に集計することができる。図５Ｃは、いくつかの実装形態に従って、詳細レベル計算５３２を使用した後のデータ視覚化５４０を示す。示されているように、人口は（図５Ｂで誤って表示された数十億の代わりに）数百万５３６で正しく表示される。しかしながら、このアプローチの主な不都合な点は、分析者が重複を認識し、これらの計算のセマンティクスを理解する必要があることである。加えて、デフォルトの軸ラベル５３４は、「人口」ではなく複雑な圧縮である。開示された実装形態は、データ視覚化アプリケーションによって自動的に実施される代替の解決策を提供する。

これらの問題の少なくとも一部を克服するために、いくつかの実装形態は、ドラッグアンドドロップアクションをより詳細な論理モデルにマッピングする方法を含む。いくつかの実装形態は、単一の論理テーブルの代わりに、各ノードが（その独自の物理表現を持つ）論理テーブルであり、各エッジが２つのテーブル間のリンクである論理テーブルのツリーを操作する。

いくつかの実装形態は、１つ以上の論理テーブルに対する主キーが不明であるか、（より複雑な分析なしでは）確認できない状況を処理する。つまり、論理テーブルに対する主キーが存在しない。主キーは、テーブルの粒度を回復するための強力なツールである。

いつかの実装形態は、論理テーブル間の複数の関係濃度を処理する。関係は、多対１、１対１、または多対多の場合がある。いつかの実装形態は、未知の関係タイプを多対多として扱う。いつかの実装形態は、関係情報を使用して主キーを回復する。例えば、関係の「一方」側のフィールドは主キーが含む。

以下の説明では、論理フィールドとは、論理テーブル内の基礎となる表現から生じるデータフィールド（例えば、論理テーブルをサポートする物理データベーステーブルのフィールド）、または論理テーブルに跨がる入力を有する計算値のどちらかを意味する。

図６Ａは、いくつかの実装形態に従った、論理ツリーとしてのオブジェクトモデルを示す。数字で示されているように、テーブルは図５Ａに示されている例の表に対応している。各論理テーブルは、右側の隣接テーブルと多対１の関係を有する。場合によっては、関係が未知の濃度を有する。

いつかの実装形態は、ユーザアクションを適切な測度集計を有する視覚化にマップする。いつかの実装形態は、論理ツリー構造を利用して、ネイティブの粒度で集計された測度を使用した視覚化（その例は図６Ｂに示す）を生成する。したがって、図５Ａを参照した上述の例に対して、分析者は、新しい計算値を追加することなく、適切な母集団の値を取得できる。

いつかの実装形態は、完全なドメイン値を計算する。説明のために、完全な一式の州が州テーブル５１２内に含まれていると仮定する。図６Ｂの視覚化では、すべての州が売上高を有するわけではない。その結果、すべてのテーブルが内部結合を使用して結合されている場合、視覚化フレームワークは売上高なしで州をドロップできる（例えば、アラスカおよびハワイ）。１つの解決策は、部分的または完全な外部結合を使用してすべての州を保持することである。いつかの実装形態は、最初に次元値の計算に必要な論理テーブルを照会することにより、完全なドメインを含む視覚化を生成する。

いつかの実装形態は、新しい次元が追加されても、測度値が表示または保持される。例えば、外部キーの欠落または不正な形式が原因で、販売が州を有さない場合がある。テーブルが内部結合されている場合、売上高は低下する。いつかの実装形態は、完全な測度値を取得するために必要なテーブルを照会し、左結合を使用して、次元が欠落しているために測度が減少しないようにすることで、この問題を回避している。上記の例では、州のない売上高は「ナル（Ｎｕｌｌ）」州によって符号化される。

いつかの実装形態は、論理テーブルのツリーを使用しない解決策で必要となるよりも少ないテーブルを照会する。上記の例では、代替フレームワークは、図６Ａに示されている６つのテーブルすべての結合ツリーを照会する。本明細書に開示される手法を用いて、データ視覚化フレームワークは、ラインアイテムテーブル５０２、注文テーブル５０４、住所テーブル５０８、および州テーブル５１２のみを照会する必要があることを認識することができる。なぜならば、これらは次元および測度値を含む論理テーブルであるか、これらのテーブルに対する結合パスに沿ったものであるためである。

いつかの実装形態は、主キーと濃度の情報が利用可能な場合にその情報を使用または組み込める。しかしながら、その手法は、最悪の場合（例えば、論理テーブル間のすべてのリンクまたは関係が多対多の場合、または、論理テーブルに対して既知の主キーが存在しない場合）であっても正しい結果を得る。いくつかの実装形態は、このような情報を組み込んで、より単純なクエリを生成する。

いつかの実装形態は、視覚化の記述を、次元と、測度と、フィルタとを含む高レベルのクエリ表現にマップする。従来の実装形態は、この表現を低レベルのクエリ表現に変換する際に、単一の論理テーブルを想定している。一方、ここで説明する手法は、論理テーブルのツリーのセマンティクスを符号化するクエリを生成する。いつかの実装形態は、次元を含むサブクエリと、（次元によってグループ化された）集計測度に対するサブクエリを生成する。以下でさらに説明するように、いつかの実装形態は、これらのサブクエリを次元で結合する。

サブクエリの生成
次元サブクエリを生成するために、いつかの実装形態は、次元フィールドを含むすべての論理テーブルを結合するか、これらのテーブルを結合して、設定された次元でグループ化する。測度サブクエリを生成する場合、いつかの実装形態は、（論理測度の場合）測度の入力フィールドと次元とを含む測度の粒度でフラットテーブルを生成する。いつかの実装形態は、次元にグループバイ（ｇｒｏｕｐ ｂｙ）を使用して集計を適用する。以下の説明では、非論理フィールド（つまり、計算されていないフィールド）は物理フィールドと称されることもあり、論理テーブルはテーブルと称されることもある。

いつかの実装形態は、各測度に対して、アルゴリズムを使用した測度の粒度でフラットテーブルを生成する。アルゴリズムは、次元と、測度と、フィルタとに対する物理入力フィールドの収集を含む。このアルゴリズムには、すべての物理入力フィールドに対して必要な最小サブツリー（物理サブツリーと称される）の計算も含む。アルゴリズムは、測度に対するすべての物理入力を提供するために必要な別の最小サブツリー（測度サブツリーと称される）の計算をさらに含む。

アルゴリズムは、サブツリーをサブツリー構成要素に分割することをさらに含む。測度サブツリーから発生するツリーは、次元フィルタサブツリーと称される。この時点で、測度と次元フィルタのサブツリーは相互に結合されていない。論理フィールドまたはフィルタが測度サブツリー内または測度サブツリー渡って跨がる可能性がある。その場合、アルゴリズムには、１つ以上の次元フィルタサブツリーを測度サブツリーからの最小式のテーブル（隣接するテーブルなど）と合成する次元測度サブツリーの作成を含む。

また、アルゴリズムは、すべての入力を含むサブツリーに論理フィールドとフィルタとを割り当てることも含む。このアルゴリズムには、サブツリー内で結合されたすべてのテーブルからなる結合ツリーの上に論理フィールドおよびフィルタを層化させてことをさらに含む。いつかの実装形態は、測度サブツリーにあるテーブルを内部結合し、かつ、測度テーブルから発生するパスに沿って他のテーブルを左外部結合する。

いつかの実装形態は、次元上で、かつ、リンクフィールドを使用して、各次元（および該当する場合は次元／測度）サブツリーを重複排除する。重複排除ステップの構造は、一連のフィールドでは「グループバイ」であり、残りのフィールドではＭＡＸである。いつかの実装形態は、（ｉ）論理次元フィールドおよびフィルタの計算に必要な測度テーブルの物理フィールド（物理入力フィールドまたはデータフィールドとも称する）と、（ｉｉ）このサブツリーを測度サブツリーにリンクさせる関係フィールドと、を含む一式のリンクフィールドを使用する。いつかの実装形態は、測度サブツリーから始めて、すべてのサブツリーを左外部結合する。次元サブツリーがフィルタを有する場合、いつかの実装形態は、次元サブツリーに定数計算を追加し、結合の上にフィルタを追加して、この計算がナルではないことを判定する。

次の例は、いくつかの実装形態に従った、上記のアルゴリズムのアプリケーションを示す。図５Ａ～５Ｃおよび６Ａ～６Ｂを参照して上述した視覚化の例では、州および人口に対する事前集計サブクエリは単に州テーブル５１２である。いくつかの実装形態に従った、州および売上高に対するクエリを図７に示す。物理サブツリーは、（測度用の）ラインアイテムテーブル５０２および（次元用の）州テーブル５１２、ならびに注文テーブル５０４および住所テーブル５０８からなる。これらのテーブルは、物理入力フィールドを提供するために必要である。この例に対して、測度サブツリーはラインアイテムであり、他の３つのテーブルを含む単一次元サブツリーがある。いくつかの実装形態は、ラインアイテムテーブル５０２と次元サブツリーとの間のスパン関係から、次元（州）およびキー（主キーに対して「ＰＫ」として示される）によって次元サブツリーをグループ化（７０４）する。この場合、次元サブツリーは、ラインアイテムテーブル５０２と注文テーブル５０４との間のリンクを介して結合する（７０２）。いくつかの実装形態は、このリンクを介して測度と次元サブツリーとを結合する。結合７０２、７０６、および７０８は、測度サブツリーから発生する左外部結合であり、州が欠落しているラインアイテムテーブルの行が確実に失われないようにする。

次に、図８Ａおよび８Ｂを参照して、ユーザが［都市のフルネーム］＝［都市名］＋“、”＋［州名］などの論理テーブルに跨がる計算を作成したとする。ここで、［都市名］は住所テーブル５０８から取得され、［州名］は州テーブル５１２から取得される。図８Ａは、いくつかの実装形態に従った、このシナリオにおけるデータ視覚化８００を示す。いくつかの実装形態に従った、視覚化に対するクエリを図８Ｂに示す。物理結合ツリーは、（測度および次元用の）州テーブル５１２と、（次元用の）住所テーブル５０８とを含む。

この例では、測度サブツリーは州であり、次元サブツリーは、住所テーブル５０８と州テーブル５１２とに跨がる論理次元フィールド８０４を含む。したがって、この例は、次元測度サブツリーのインスタンスを示す。いつかの実装形態は、測度テーブルと次元－測度サブツリー内の残りのテーブルの間の関係を使用して、このサブツリーを測度サブツリーに結合（８０２）する。いつかの実装形態は、次元（都市のフルネーム）、結合関係（州外部キー（ＦＫ））、および次元測度サブツリー（州名）の測度部分に含まれる物理入力を使用して、次元－測度サブツリーを重複排除（８０６）する。続いて、いくつかの実装形態は、関係からのキーと物理入力フィールドを使用して結合する（８０８）。

次に、図９Ａおよび９Ｂを参照して、ユーザがカテゴリ「技術」にフィルタリングされた、出荷モードごとの売上高の合計の視覚化９００を作成したいと仮定する。いつかの実装形態は、図９Ｂに示すクエリを生成する。物理的な結合ツリーは、（測度用の）ラインアイテムテーブル５０２、（次元用の）注文テーブル５０４、および（フィルタ用の）製品テーブル５０６である。測度サブツリーは、ラインアイテムテーブル５０２である。この場合、２つの相互に結合されていない次元サブクエリが存在する。（次元用の）注文および（フィルタ９０６用の）製品である。いつかの実装形態は、関係からのキーに対して、測度サブクエリ（測度サブツリーとも称される）と重複排除されたシップモード次元サブクエリ９０４とを左外部結合（９０２）する。次に、いくつかの実装形態は、この結果を重複排除された次元サブクエリ９０８に左結合（９１２）する。いくつかの実装形態は、フィルタ（例えば、フィルタ９０６および９１４）の上にセンチネル計算（例えば、センチネル９１０）を追加する。いつかの実装形態は、センチネル値がナルではない行のみを保持するフィルタを追加し、左外部結合の際にフィルタが確実に考慮されるようにする。いつかの実装形態は、同一の結果を取得しながら、次元－次元測度のサブグラフを結合する順序を入れ替えている。

図１０Ａおよび１０Ｂは、いくつかの実装形態に従って、最適化されたクエリの例を示す。いつかの実装形態は、関係の濃度や主キーに関する情報が利用可能な場合に、最適化されたクエリが生成される。

いつかの実装形態は、測度サブツリー構成要素を計算するときに、システムは、多対１または１対１のリンクのチェーンを介して到達できるテーブルを取得する。説明のために、図７を参照して上述した州およびラインアイテムサブクエリに対して、いつかの実装形態は、すべてのリンクが多対１であるという事実を利用して、すべてのテーブルを含むように測度サブツリーを拡張する。図１０Ａに示されているこのクエリは、以前よりも単純である。特に、図７のクエリとは異なり、図１０Ａに示すクエリは、「フループバイ」演算（例えば、演算７０４）を有さない。いつかの実装形態は、エッジのすべての濃度を知らなくてもこの最適化を実施する。例えば、最適化は、テーブル５０２、５０４、５０８、５１２間の３つの関係が多対１であることを知ることが必要であり、ツリーの残りの部分（図５Ａに示されたオブジェクトモデル）に関する情報を知る必要はない。部分的な情報があっても、いくつかの実装形態は最適化されたクエリを生成する。例えば、ラインアイテム－注文リンクが多対１であることがわかっている場合、いつかの実装形態は、ラインアイテムテーブルと注文テーブルとを測度サブツリーに含め、州テーブルに結合された住所テーブルを測度サブツリーに含めることで、部分的な最適化を実施する。

いつかの実装形態は、次元／測度サブツリーが多対１および１対１のリンクに沿って排他的に測度サブツリーに対して結合する場合、測度サブツリーを計算するときに、測度および次元／測度サブツリーによって共有される一式のテーブルが重複排除された次元／測度サブツリーに置き換えられる。説明のために、図８Ｂを参照した上述の例のクエリに対して、住所と州との関係が多対１であることがわかっている場合、いつかの実装形態は、図１０Ｂに示すようにクエリを簡略化する。この最適化は、次元－測度サブツリーが多対１リンク（この場合は住所－州）を介して測度サブツリーに排他的にリンクするという事実に基づいている。

サブクエリの組み合わせ
次元サブツリーと各集計された測度のサブツリーが与えられた場合、いつかの実装形態は、これらのクエリを組み合わせて、外部結合を使用して最終クエリを形成する。いくつかの実装形態は、視覚化の次元に対して結合し、各結合後に、各次元の左右のインスタンスに合体（ＣＯＡＬＥＳＣＥ）を適用する。図１１Ａは、地域およびカテゴリによってグループ化された、（上記の）人口および売上高の合計を表示するデータ視覚化１１００を示す。いくつかの実装形態は、図１１Ａに示される視覚化に対して、図１１Ｂに示されるように、サブクエリを組み合わせて最終クエリ１１０２を形成する。いくつかの実装形態において、各サブクエリ（例えば、サブクエリ１１０４および１１０６）は、異なるドメインを有する。図１１Ｃは、いくつかの実装形態に従った、（図１１Ｂの例に対して）次元サブクエリのデータ視覚化１１２０を示す。図１１Ｄは、いくつかの実装形態に従った、（次元を有する）売上高の合計に対するサブクエリのためのデータ視覚化１１３０を示す。図１１Ｅは、いくつかの実装形態に従った、（次元を有する）人口の合計に対するサブクエリのデータ視覚化１１４０を示す。

いつかの実装形態において、外部結合により、少なくとも１つのサブクエリに表示される次元のすべての組み合わせが確実に表現される。合体により、結合後に各次元に対するナル以外のすべての値が確実に表現される。例えば、（地域、カテゴリ）＝（中央、ナル）は、クエリの残りの部分に対して人口サブクエリ内で結合する場合、外部結合の右側にのみに表示される。次元の左側のバージョンを選択すると、誤った結果（（ナル、ナル））となるであろう。同様に、次元の右側のバージョンが選択された場合、売上高の合計サブクエリから（ナル、家具）になるであろう。

いつかの実装形態は、（例えば、売上高の合計および人口の合計に対応する図１１Ｆに示す視覚化１１５０に対して）次元のない視覚化に対する測度サブクエリ間で完全結合を実施する。

いつかの実装形態は、複雑なクエリに対するオブジェクトモデルに基づいて視覚化を生成する。説明のために、ユーザが［税調整後売上高］＝［売上高］×［消費税率］などの論理テーブルに跨がる計算を作成したと仮定する。ここで、［売上高］はラインアイテムテーブル５０２から取得され、［消費税率］は州テーブル５１２から取得される。クエリが［区分］＝「本社」および［地域］＝「東」のフィルタ述語計算も含んでいると仮定する。ここで、［区分］は顧客テーブル５１０から、［地域］は住所テーブル５０８から取得される。ここで、さらに、ユーザがカテゴリ別にグループ化された視覚化総（［税調整後売上高］）を作成したいと仮定する。ここで、フィルタ述語は真（ｔｒｕｅ）である。図１２Ａは、いくつかの実装形態に従って、本明細書で説明される手法を使用して生成されたデータ視覚化１２００を示す。

関係の濃度が不明であると想定すると、いつかの実装形態は、図１２Ｂに示す最終クエリ１２０２を生成して、ネイティブの粒度で測度を計算する。この例は、物理的な結合ツリーには、ラインアイテムテーブル５０２、注文テーブル５０４、住所テーブル５０８、（測度用の）州テーブル５１２、（次元用の）製品テーブル５０６、（フィルタに必要な）顧客テーブル５１０を含む。測度は、ラインアイテム、注文、住所、および州テーブルに跨がる論理フィールドである。ぬ測度サブツリーは、内部結合されたこれらのテーブルを備える。いくつかの実装形態は、［税調整後売上高］の定義に対して層化もする。

いくつかの実装形態は、製品および顧客の２つの次元サブツリーで始まる。述語のフィルタは顧客から住所に及ぶため、いつかの実装形態は、注文、住所、顧客の次元測度サブツリーを生成する。カテゴリに対応するサブツリーに対して、いつかの実装形態は、製品をカテゴリとリンクキー（製品ＰＫ）とでグループ化し、これを測度サブツリーに左結合する。次元－測度サブツリーに対して、いくつかの実装形態は測度サブツリーからのテーブルを内部結合し、顧客を左結合する。いつかの実装形態は、フィルタ述語論理フィールドを追加し、フィルタを適用する。フィルタ述語は、測度サブツリー［地域］への物理入力を使用した計算値である。したがって、いつかの実装形態は、顧客－注文リンク（次元のみのオブジェクトが測度オブジェクトにリンクするリンクであるため）および［地域］の関係フィールドでこのサブツリーを重複排除する。いくつかの実装形態は、これらのフィールドも使用して、残りのクエリに対して次元測度サブツリーを結合する。

いつかの実装形態は、図１２Ｂを参照して上記のクエリを簡略化する。注文－顧客リンクが多対１であることがわかっている場合、（図１０Ａを参照して上述したように、粒度に影響を及ぼすことなく、顧客を測度サブツリーに安全に結合可能なことがわかっているため）いつかの実装形態は、次元サブクエリの必要性を取り除くことによってクエリを簡素化する。図１２Ｃは、いくつかの実装形態に従った、最適化されたクエリ１２０４の例を示す。同様に、ラインアイテム－製品リンクが多対１であることがわかっている場合、いつかの実装形態は、図１２Ｄの最適化されたクエリ１２０６に示すように、同様のロジックを与えてクエリをさらに削減または簡素化する。

図１３Ａ～１３Ｄは、いくつかの実装形態に従った、上記の手法に準じたオブジェクトモデルを使用してデータ視覚化を生成する（１３０２）ための方法１３００のフローチャートを提供する。方法１３００は、１つ以上のプロセッサおよびメモリを有するコンピューティングデバイス２００において実施される（１３０４）。メモリは、１つ以上のプロセッサによる実行のために構成された１つ以上のプログラムを格納する（１３０６）。

コンピュータが、１つ以上のデータソース１０６、複数の視覚変数２８２、複数のデータフィールド２８４を指定する視覚仕様１０４を１つ以上のデータソース１０６から受信する（１３０８）。視覚変数２８２の各々が、（ｉ）データフィールド２８４のうちのそれぞれの１つ以上、または（ｉｉ）１つ以上のフィルタのどちらかに関連付けられ、データフィールド２８４の各々が、次元または測度のどちらかとして識別される。いくつかの実装形態において、視覚仕様１０４が、１つ以上のデータソース１０６からのいずれかのデータフィールド３３０に関連付けられていない１つ以上の追加の視覚変数を含む。いくつかの実装形態において、視覚変数２８２の各々は、行属性、列属性、フィルタ属性、色符号化、サイズ符号化、形状符号化、またはラベル符号化のうちの１つである。

コンピュータが、データソースを論理テーブルのツリーとして符号化するデータモデルを取得する（１３１０）。各論理テーブルが、その独自の物理表現を有し、それぞれ１つ以上の論理フィールドを含む。各論理フィールドが、データフィールドまたは１つ以上の論理テーブルに跨がる計算値のどちらかに対応する。ツリーの各エッジが、関連する２つの論理テーブルを接続する。コンピュータが、次元およびフィルタに対するデータフィールドを供給する論理テーブルに基づいて次元サブクエリを生成する（１３１２）。いくつかの実装形態において、コンピュータが、論理テーブルのツリー内の第１の１つ以上の論理テーブルを内部結合する（１３１４）ことによって次元サブクエリを生成し、第１の１つ以上の論理テーブルの各論理テーブルが、次元またはフィルタに対するデータフィールドを供給する。

コンピュータが、各測度に対して、それぞれの測度およびフィルタに対してデータフィールドを供給する論理テーブルに基づいて、次元によってグループ化された集計測度サブクエリも生成する（１３１６）。

次に、図１３Ｂを参照すると、コンピュータが、次元を使用して、集計測度サブクエリの各々に次元サブクエリを結合することにより、最終クエリを形成する（１３１８）。いくつかの実装形態において、コンピュータが、外部結合を使用して次元サブクエリと集計測度サブクエリとを結合し（１３２０）、かつ、各外部結合の後に合体（ＣＯＡＬＥＳＣＥ）を適用することによって、最終クエリを形成する。いくつかの実装形態において、視覚化が次元有さない場合、コンピュータが、集計測度サブクエリ間で完全な結合を実施し（１３２２）、最終クエリを形成する。いくつかの実装形態は、次元を有しない視覚化を表すために、空のスキーマと単一の行とを有する特殊なテーブル（Ｔａｂｌｅａｕの製品においてはＴａｂｌｅ Ｄｅｅと称する）を使用し、次元サブクエリのベーステーブルが特殊なテーブルであるかどうかを確認することによって、与えられた視覚化が次元を有さないかどうかを判定する。いつかの実装形態は、定数値に対して特別なテーブルも使用する。例えば、総（１）は、特別なテーブルの上に投影された値１に評価される。特殊テーブルには１つの行があるため、総（１）は値１に評価される。いつかの実装形態にいて、論理フィールドの入力がいずれのテーブルにも属していない場合、フィールドは特別なテーブルを使用して評価される。

続いて、コンピュータが、データソースに対して最終クエリを実行して（１３２４）、データフィールドのデータ値の個別の順序付けられた組み合わせを含むタプルを検索する。次に、コンピュータが、拡張タプルのデータフィールドに従って、かつ、データフィールドの各々が関連付けられている視覚変数に従って、（例えば、コンピューティングデバイス２００に対するグラフィカルユーザインターフェース１０２において）、データ視覚化を構築および表示する（１３２６）。

次に、図１３Ｃを参照すると、いくつかの実装形態において、コンピュータが、一連の演算を実施することにより、各集計測度サブクエリを生成する。コンピュータが、論理テーブルのツリーの測度サブツリーを計算する（１３２８）。測度サブツリーは、それぞれの測度に対するデータフィールドを提供するために必要とされる最小のサブツリーである。いくつかの実装形態において、コンピュータが、測度サブツリー内の論理テーブルを内部結合することによって測度サブツリーをコンパイルして（１３３０）、測度結合ツリーを取得する。内部結合を使用すると、結合の順序が重要ではなくなるため、粒度を計算するときに一貫したセマンティクスが提供される。内部結合は、測度に対するネイティブレベルの粒度を提供する。計算の場合にのみ、測度サブツリーに複数のテーブルが存在する。ただし、ほとんどの場合、測度サブツリーが単一のテーブルを含む。計算されたフィールドが複数のテーブルに跨がる場合、フィールドのネイティブの粒度は、入力が結合されたものである。コンピュータは、論理テーブルのツリーから次元フィルタサブツリーも計算する（１３３２）。次元フィルタサブツリーは、次元およびフィルタに対するすべての物理入力を供給するために必要とされる最小のサブツリーである。（計算されていない次元フィールドに対して、物理入力は次元フィールド自体である。計算された次元に対して、物理入力は次元の計算に必要なすべてのデータフィールドである。）いつかの実装形態において、コンピュータが、測度サブツリーと共有される次元フィルタサブツリー内の論理テーブルを内部結合し（１３３４）、かつ、測度サブツリーと共有されていない次元フィルタサブツリー内の論理テーブルを左結合することによって、次元フィルタサブツリーを計算して、次元フィルタ結合ツリーを取得する。多対１の関係で複数のテーブルに跨がる計算された測度があると仮定する。組み合わせることができる行のすべての個別の組み合わせに対して、その計算の別個のインスタンスが必要である。内部結合は、その一式の行を生成する。

次元フィルタサブツリーが測度サブツリーといかなる論理テーブルをも共有していない場合、コンピュータが、測度サブツリーからの隣接する論理テーブルを次元フィルタサブツリーに追加する（１３３６）。コンピュータが、測度サブツリーをコンパイルして（１３３８）、測度結合ツリーを取得し、かつ、次元フィルタサブツリーをコンパイルして、次元フィルタ結合ツリーを取得する。次に、図１３Ｄを参照すると、コンピュータが、計算値およびフィルタを測度結合ツリーおよび次元フィルタ結合ツリーに層化させて（１３４０）、更新された測度サブツリーおよび更新された次元フィルタサブツリーをそれぞれ取得する。コンピュータが、次元と、（ｉ）論理テーブル間の関係（例えば、主キーと外部キーとが等しい）からのキー、および（ｉｉ）次元および測度サブツリーと共有される計算値のデータフィールドを含むリンクフィールドと、を使用するグループバイ（Ｇｒｏｕｐ－Ｂｙ）演算（ＧＢ）を適用することによって、更新された次元フィルタサブツリーを重複排除して（１３４２）、重複排除された次元フィルタサブツリーを取得する。計算である次元が存在すると仮定する。さらに、次元フィルタサブツリーの測度部分にある物理入力フィールド（データフィールドとも称する）が計算に含まれていると仮定する。これらのフィールドは、リンクフィールドでもある。フループバイ演算は、一意の一式の次元を探索する。いつかの実装形態は、リンクフィールドを使用して結合し直す。事例によっては、測度サブツリーとフィールドを共有する計算が存在する場合、いくつかの実装形態は、測度が得られる一意の行を回復させる。このような事例において、結合は、測度サブツリーに対して主キーを疑似パックするように機能する。

続いて、コンピュータが、重複排除された次元フィルタサブツリーと更新された測度サブツリーとを組み合わせて（１３４４）、集計測度サブクエリを取得する。

主キーが存在する場合、いくつかの実装形態は次元フィルタサブツリーを使用しない。このような場合、いつかの実装形態は、測度サブツリーのすべてのテーブルの主キーを組み合わせる。

いくつかの実装形態において、コンピュータが、一連の演算を実施することによって重複排除された次元フィルタサブツリーと更新された測度サブツリーとを組み合わせる。コンピュータが、重複排除された次元フィルタサブツリーがフィルタを含んでいるどうかを判定する。重複排除された次元フィルタサブツリーがフィルタを含んでいる場合、コンピュータ（１３４６）は、更新された測度サブツリーと重複排除された次元フィルタサブツリーとを内部結合させる。重複排除された次元フィルタサブツリーがフィルタを含んでいない場合、コンピュータが、更新された測度サブツリーを重複排除された次元フィルタサブツリーと左外部結合する（１３４８）。

いくつかの実装形態において、コンピュータは、キーが第１の論理テーブルと第２の論理テーブルとの間の多対１の関係を示しているのか、または、１対１の関係を示しているのかを判定する。キーが、第１の論理テーブルと第２のテーブルとの間の多対１の関係を示している場合、コンピュータが、測度サブツリー内に第１の論理テーブルおよび第２のテーブルを含め（１３５０）、それによって、第１の論理テーブルおよび第２のテーブルに対する重複排除演算のグループバイを回避する。

いくつかの実装形態において、次元フィルタサブツリーが測度サブツリーに対して多対１および１対１のリンクに沿って排他的に結合している場合、コンピュータが、測度サブツリーおよび次元フィルタサブツリーによって共有されるテーブルを、重複排除された次元フィルタサブツリーと置き換える（１３５２）。

本明細書で本発明の説明に使用される専門用語は、特定の実装形態を説明することのみを目的としており、本発明を限定することを意図するものではない。本発明の説明および添付の特許請求の範囲で使用される場合、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、特に文脈が明示しない限り、複数形も含むことが意図される。本明細書で使用される「および／または」という用語は、１つ以上の関連するリストされたアイテムのありとあらゆる可能な組み合わせを指し、それらを包含することも理解されよう。本明細書で使用される場合、「含む」および／または「含んでいる」という用語は、述べられた特徴、ステップ、動作、要素、および／または構成要素の存在を指定するが、１つ以上の他の特徴、ステップ、演算、要素、構成要素、および／またはそれらの群の存在または追加を排除しないことがさらに理解されよう。

前述の記載は、説明の目的で、特定の実装形態を参照して記載されてきた。しかしながら、上記の例示的な論議は、網羅的であること、または本発明を開示された正確な形態に限定することを意図していない。上記の教示を考慮して、多くの修正および変形が可能である。実装形態は、本発明の原理およびその実際の応用を最もよく解説するために選択および記載され、それにより、当業者は、本発明および企図される特定の用途に好適な様々な修正を伴う様々な実装形態を最大限に利用することができる。

Claims (20)

1. データ視覚化を生成する方法であって、
   ディスプレイと、１つ以上のプロセッサと、前記１つ以上のプロセッサによる実行のために構成された１つ以上のプログラムを格納するメモリと、を有する、コンピュータにおいて、
   データソースと、複数の視覚変数と、前記データソースからの複数のデータフィールドと、を指定する、視覚仕様を受信することであって、前記視覚変数の各々が、（ｉ）前記データフィールドのうちのそれぞれの１つ以上、または（ｉｉ）１つ以上のフィルタのどちらかに関連付けられ、前記データフィールドの各々が、次元または測度のどちらかとして識別されることと、
   前記データソースを符号化するデータモデルを論理テーブルのツリーとして取得することであって、前記各論理テーブルが、その独自の物理表現を有し、かつ、それぞれの１つ以上の論理フィールドを含み、前記各論理フィールドが、データフィールドまたは１つ以上の論理テーブルに跨がる計算値のどちらかに対応し、前記ツリーの各エッジが、関連する２つの論理テーブルを接続することと、
   前記次元および前記フィルタに対する前記データフィールドを供給する論理テーブルに基づいて、次元サブクエリを生成することと、
   各測度に対して、前記それぞれの測度および前記フィルタに対する前記データフィールドを供給する前記論理テーブルに基づいて、前記次元によってグループ化された集計測度サブクエリを生成することと、
   前記次元を使用して、前記集計測度サブクエリの各々に前記次元サブクエリを結合することにより、最終クエリを形成することと、
   前記データソースに対して前記最終クエリを実行して、前記データフィールドに対するデータ値の個別の順序付けられた組み合わせを含むタプルを検索することと、
   前記タプル内の前記データフィールドに従って、かつ、前記データフィールドの各々が関連付けられている前記視覚変数に従って、データ視覚化を構築および表示することと、を含む、方法。
2. 前記各集計測度サブクエリを生成することが、
   前記論理テーブルのツリーの測度サブツリーを計算することであって、前記測度サブツリーが、それぞれの測度に対する前記データフィールドを供給するために必要とされる最小のサブツリーである、計算することと、
   前記論理テーブルのツリーの次元フィルタサブツリーを計算することであって、前記次元フィルタサブツリーが、前記次元および前記フィルタの物理入力のすべてを供給するために必要とされる最小のサブツリーであることと、
   前記次元フィルタサブツリーが前記測度サブツリーといかなる論理テーブルも共有していないという判定に従って、前記測度サブツリーからの隣接する論理テーブルを前記次元フィルタサブツリーに追加することと、
   前記測度サブツリーをコンパイルして、測度結合ツリーを取得し、かつ、前記次元フィルタサブツリーをコンパイルして、次元フィルタ結合ツリーを取得することと、
   計算値およびフィルタを前記測度結合ツリーおよび前記次元フィルタ結合ツリー上に層化させて、更新された測度サブツリーおよび更新された次元フィルタサブツリーをそれぞれ取得することと、
   前記次元と、（ｉ）前記論理テーブル間の関係からのキーと、（ｉｉ）前記測度サブツリーと共有される計算値のデータフィールドと、を含む、リンクフィールドと、を使用する、グループバイ（ｇｒｏｕｐ－ｂｙ）演算を適用することによって、前記更新された次元フィルタサブツリーを重複排除して、重複排除された次元フィルタサブツリーを取得することと、
   前記重複排除された次元フィルタサブツリーを前記更新された測度サブツリーと組み合わせて、前記集計測度サブクエリを取得することと、を含む、請求項１に記載の方法。
3. 前記測度サブツリーをコンパイルすることが、前記測度サブツリー内の論理テーブルを内部結合して、前記測度結合ツリーを取得すること含む、請求項２に記載の方法。
4. 前記次元フィルタサブツリーを計算することが、前記測度サブツリーと共有される前記次元フィルタサブツリー内の論理テーブルを内部結合し、かつ、前記測度サブツリーと共有されていない前記次元フィルタサブツリー内の論理テーブルを左結合して、前記次元フィルタ結合ツリーを取得することを含む、請求項２に記載の方法。
5. 前記重複排除された次元フィルタサブツリーを前記更新された測度サブツリーと組み合わせることが、
   前記重複排除された次元フィルタサブツリーがフィルタを含んでいるどうかを判定することと、
   前記重複排除された次元フィルタサブツリーがフィルタを含んでいるという判定に従って、前記更新された測度サブツリーを、前記重複排除された次元フィルタサブツリーと内部結合することと、
   前記重複排除された次元フィルタサブツリーがフィルタを含んでいないという判定に従って、前記更新された測度サブツリーを前記重複排除された次元フィルタサブツリーと左外部結合することと、を含む、請求項２に記載の方法。
6. 前記キーが、前記第１の論理テーブルと前記第２のテーブルとの間の多対１の関係を示すという判定に従って、前記第１のテーブルおよび前記第２のテーブルを前記測度サブツリー内に含め、それによって、前記第１の論理テーブルおよび前記第２のテーブルの重複排除演算における前記グループバイを回避することをさらに含む、請求項２に記載の方法。
7. 前記次元フィルタサブツリーが前記測度サブツリーに対して多対１および１対１のリンクに沿って排他的に結合しているという判定に従って、前記測度サブツリーおよび前記次元フィルタサブツリーによって共有されるテーブルを、前記重複排除された次元フィルタサブツリーと置き換えることをさらに含む、請求項２に記載の方法。
8. 前記次元サブクエリを生成することが、前記論理テーブルのツリー内の第１の１つ以上の論理テーブルを内部結合することを含み、前記第１の１つ以上の論理テーブルの各論理テーブルが、次元またはフィルタに対する前記データフィールドを供給する、請求項１に記載の方法。
9. 前記最終クエリを形成することが、外部結合を使用して、前記次元に対する前記次元サブクエリおよび前記集計測度サブクエリを結合することと、前記各外部結合に合体（ＣＯＡＬＥＳＣＥ）を適用することと、を含む、請求項１に記載の方法。
10. 前記最終クエリを形成することが、視覚化が次元を有しないという判定に従って、前記集計測度サブクエリ間で完全な外部結合を実施することを含む、請求項１に記載の方法。
11. データ視覚化を生成するためのコンピュータシステムであって、
    １つ以上のプロセッサと、
    メモリと、を含み、
    前記メモリが、前記１つ以上のプロセッサによる実行のために構成された１つ以上のプログラムを格納し、前記１つ以上のプログラムが、
    データソースと、複数の視覚変数と、前記データソースからの複数のデータフィールドと、を指定する、視覚仕様を受信することであって、前記視覚変数の各々が、（ｉ）前記データフィールドのうちのそれぞれの１つ以上、または（ｉｉ）１つ以上のフィルタのどちらかに関連付けられ、前記データフィールドの各々が、次元または測度のどちらかとして識別されること、
    前記データソースを符号化するデータモデルを論理テーブルのツリーとして取得することであって、前記各論理テーブルが、その独自の物理表現を有し、かつ、それぞれの１つ以上の論理フィールドを含み、前記各論理フィールドが、データフィールドまたは１つ以上の論理テーブルに跨がる計算値のどちらかに対応し、前記ツリーの各エッジが、関連する２つの論理テーブルを接続すること、
    前記次元および前記フィルタに対する前記データフィールドを供給する論理テーブルに基づいて、次元サブクエリを生成すること、
    各測度に対して、前記それぞれの測度および前記フィルタに対する前記データフィールドを供給する前記論理テーブルに基づいて、前記次元によってグループ化された集計測度サブクエリを生成すること、
    前記次元を使用して、前記集計測度サブクエリの各々に前記次元サブクエリを結合することにより、最終クエリを形成すること、
    前記データソースに対して前記最終クエリを実行して、前記データフィールドに対するデータ値の個別の順序付けられた組み合わせを含むタプルを検索すること、
    前記タプル内の前記データフィールドに従って、かつ、前記データフィールドの各々が関連付けられている前記視覚変数に従って、データ視覚化を構築および表示すること、のための命令を含む、コンピュータシステム。
12. 前記各集計測度サブクエリを生成することが、
    前記論理テーブルのツリーの測度サブツリーを計算することであって、前記測度サブツリーが、それぞれの測度に対する前記データフィールドを供給するために必要とされる最小のサブツリーであることと、
    前記論理テーブルのツリーの次元フィルタサブツリーを計算することであって、前記次元フィルタサブツリーが、前記次元および前記フィルタの物理入力のすべてを供給するために必要とされる最小のサブツリーであることと、
    前記次元フィルタサブツリーが前記測度サブツリーといかなる論理テーブルも共有していないという判定に従って、前記測度サブツリーからの隣接する論理テーブルを前記次元フィルタサブツリーに追加することと、
    前記測度サブツリーをコンパイルして、測度結合ツリーを取得し、かつ、前記次元フィルタサブツリーをコンパイルして、次元フィルタ結合ツリーを取得することと、
    計算値およびフィルタを前記測度結合ツリーおよび前記次元フィルタ結合ツリー上に層化させて、更新された測度サブツリーおよび更新された次元フィルタサブツリーをそれぞれ取得することと、
    前記次元と、（ｉ）前記論理テーブル間の関係からのキーと、（ｉｉ）前記測度サブツリーと共有される前記計算値の前記物理入力フィールドと、を含む、リンクフィールドと、を使用する、グループバイ（ｇｒｏｕｐ－ｂｙ）演算を適用することによって、前記更新された次元フィルタサブツリーを重複排除して、重複排除された次元フィルタサブツリーを取得することと、
    前記重複排除された次元フィルタサブツリーを前記更新された測度サブツリーと組み合わせて、前記集計測度サブクエリを取得することと、を含む、請求項１１に記載のコンピュータシステム。
13. 前記測度サブツリーをコンパイルすることが、前記測度サブツリー内の論理テーブルを内部結合して、前記測度結合ツリーを取得すること含む、請求項１２に記載のコンピュータシステム。
14. 前記次元フィルタサブツリーをコンパイルすることが、前記測度サブツリーと共有される前記次元フィルタサブツリー内の論理テーブルを内部結合し、かつ、前記測度サブツリーと共有されていない前記次元フィルタサブツリー内の論理テーブルを左結合して、前記次元フィルタ結合ツリーを取得することを含む、請求項１２に記載のコンピュータシステム。
15. 前記重複排除された次元フィルタサブツリーを前記更新された測度サブツリーと組み合わせることが、
    前記重複排除された次元フィルタサブツリーがフィルタを含んでいるどうかを判定することと、
    前記重複排除された次元フィルタサブツリーがフィルタを含んでいるという判定に従って、前記更新された測度サブツリーを、前記重複排除された次元フィルタサブツリーと内部結合することと、
    前記重複排除された次元フィルタサブツリーがフィルタを含んでいないという判定に従って、前記更新された測度サブツリーを前記重複排除された次元フィルタサブツリーと左外部結合することと、を含む、請求項１２に記載のコンピュータシステム。
16. 前記１つ以上のプログラムが、
    前記キーが第１の論理テーブルと第２の論理テーブルとの間の多対１の関係を示しているのか、または、１対１の関係を示しているのかを判定すること、
    前記キーが、前記第１の論理テーブルと前記第２のテーブルとの間の多対１の関係を示すという判定に従って、前記第１のテーブルおよび前記第２のテーブルを前記測度サブツリー内に含め、それによって、前記第１の論理テーブルおよび前記第２のテーブルの重複排除演算における前記グループバイを回避すること、のための命令をさらに含む、請求項１２に記載のコンピュータシステム。
17. 前記１つ以上のプログラムが、
    前記次元フィルタサブツリーが前記測度サブツリーに対して多対１および１対１のリンクに沿って排他的に結合しているという判定に従って、前記測度サブツリーおよび前記次元フィルタサブツリーによって共有されるテーブルを、前記重複排除された次元フィルタサブツリーと置き換えること、のための命令をさらに含む、請求項１２に記載のコンピュータシステム。
18. 前記次元サブクエリを生成することが、前記論理テーブルのツリー内の第１の１つ以上の論理テーブルを内部結合することを含み、前記第１の１つ以上の論理テーブルの各論理テーブルが、次元またはフィルタに対する前記データフィールドを供給する、請求項１１に記載のコンピュータシステム。
19. 前記最終クエリを形成することが、外部結合を使用して、前記次元に対する前記次元サブクエリおよび前記集計測度サブクエリを結合することと、前記各外部結合の後に合体（ＣＯＡＬＥＳＣＥ）を適用することと、を含む、請求項１１に記載のコンピュータシステム。
20. ディスプレイと、１つ以上のプロセッサと、メモリとを備えるコンピュータシステムによる実行のために構成された１つ以上のプログラムを格納する非一時的コンピュータ可読記憶媒体であって、前記１つ以上のプログラムが、
    データソースと、複数の視覚変数と、前記データソースからの複数のデータフィールドと、を指定する、視覚仕様を受信することであって、前記視覚変数の各々が、（ｉ）前記データフィールドのうちのそれぞれの１つ以上、または（ｉｉ）１つ以上のフィルタのどちらかに関連付けられ、前記データフィールドの各々が、次元または測度のどちらかとして識別されること、
    前記データソースを符号化するデータモデルを論理テーブルのツリーとして取得することであって、前記各論理テーブルが、その独自の物理表現を有し、かつ、それぞれの１つ以上の論理フィールドを含み、前記各論理フィールドが、データフィールドまたは１つ以上の論理テーブルに跨がる計算値のどちらかに対応し、前記ツリーの各エッジが、関連する２つの論理テーブルを接続すること、
    前記次元および前記フィルタに対する前記データフィールドを供給する論理テーブルに基づいて、次元サブクエリを生成すること、
    各測度に対して、前記それぞれの測度および前記フィルタに対する前記データフィールドを供給する前記論理テーブルに基づいて、前記次元によってグループ化された集計測度サブクエリを生成すること、
    前記次元を使用して、前記集計測度サブクエリの各々に前記次元サブクエリを結合することにより、最終クエリを形成することと、
    前記データソースに対して前記最終クエリを実行して、前記データフィールドに対するデータ値の個別の順序付けられた組み合わせを含むタプルを検索すること、
    前記タプル内の前記データフィールドに従って、かつ、前記データフィールドの各々が関連付けられている前記視覚変数に従って、データ視覚化を構築および表示すること、のための命令を含む、非一時的コンピュータ可読記憶媒体。

Images