JP2022504865A - 選択したデータソースのオブジェクトモデルに従ったデータ視覚化の生成 - 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