(57)【要約】  プロセスは、データソース、視覚変数、及びデータソースからのデータフィールドを指定する視覚的仕様を受信する。各視覚変数は１つ又は複数のデータフィールドに関連し、各データフィールドはディメンション又はメジャーである。メジャーｍごとに、プロセスは、データソースのためのオブジェクトモデル内の多対一関係のシーケンスによってメジャーから到達可能なディメンションで構成されるセットＲ（ｍ）を識別する。別個のセットＲごとに、プロセスは、Ｒ内の各ディメンション及び各メジャーｍで構成され、Ｒ（ｍ）＝Ｒが成立する、データフィールドセットＳを形成する。セットＳごとに及びセットＳ内のメジャーごとに、プロセスはＳ内のディメンションに従ってメジャーの値を集計する。プロセスは、セットＳ内のデータフィールド及びそれらが関連する視覚変数に従ってデータビジュアライゼーションを構築する。
2020537251.tif 000002
【特許請求の範囲】
【請求項１】
データビジュアライゼーションを生成する方法であって、
１つ又は複数のプロセッサ、及び前記１つ又は複数のプロセッサによって実行されるように構成される１つ又は複数のプログラムを記憶するメモリを有するコンピュータにおいて、
１つ又は複数のデータソース、複数の視覚変数、及び前記１つ又は複数のデータソースからの複数のデータフィールドを指定する視覚的仕様を受信することであって、各視覚変数は、前記データフィールドのそれぞれの１つ又は複数に関連し、前記データフィールドのそれぞれは、ディメンションｄ又はメジャーｍとして識別される、受信すること、
前記データフィールドのメジャーｍごとに、前記１つ又は複数のデータソースのための既定のオブジェクトモデル内の多対一関係のシーケンスによって前記それぞれのメジャーｍから到達可能な前記データフィールドの全てのディメンションｄで構成される、それぞれの到達可能ディメンションセットＲ（ｍ）を識別すること、
別個の到達可能ディメンションセットＲごとに、前記データフィールドの個々のデータフィールドセットＳを形成することであって、ＳはＲ内の各ディメンション及び前記データフィールドの各メジャーｍで構成され、Ｒ（ｍ）＝Ｒが成立する、形成すること、並びに
各データフィールドセットＳについて、
前記個々のデータフィールドセットＳ内のメジャーｍごとに、前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションによって指定される詳細レベルまで前記メジャーｍの値をロールアップすること、及び
前記それぞれのデータフィールドセットＳ内の前記データフィールドに従って、及びＳ内の前記データフィールドのそれぞれが関連する前記それぞれの視覚変数に従ってそれぞれのデータビジュアライゼーションを構築すること、
を含む、方法。
【請求項２】
前記視覚的仕様が、前記１つ又は複数のデータソースからの如何なるデータフィールドにも関連しない１つ又は複数の追加の視覚変数を更に含む、請求項１に記載の方法。
【請求項３】
前記それぞれのデータビジュアライゼーションを構築することが、前記視覚的仕様から生成される１つ又は複数のデータベースクエリを使用して前記１つ又は複数のデータソースからデータのタプルを取得することを更に含む、請求項１に記載の方法。
【請求項４】
前記タプルが、前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションに従って集計されるデータを含む、請求項３に記載の方法。
【請求項５】
前記コンピュータのグラフィカルユーザインタフェース内に前記それぞれのデータビジュアライゼーションを表示することを更に含む、請求項３に記載の方法。
【請求項６】
前記データビジュアライゼーションを表示することが複数の視覚マークを生成することを含み、各マークは前記１つ又は複数のデータソースから取得されるそれぞれのタプルに対応する、請求項５に記載の方法。
【請求項７】
前記グラフィカルユーザインタフェースがデータビジュアライゼーション領域を含み、前記方法が前記データビジュアライゼーション領域内に前記データビジュアライゼーションを表示することを更に含む、請求項５に記載の方法。
【請求項８】
前記視覚変数のそれぞれが行属性、列属性、フィルタ属性、色エンコード、サイズエンコード、形状エンコード、及びラベルエンコードで構成されるグループから選択される、請求項１に記載の方法。
【請求項９】
ディメンションｄ及びメジャーｍが前記既定のオブジェクトモデル内の同じクラス内にある場合、或いは前記メジャーｍが前記既定のオブジェクトモデル内の第１のクラスＣ１の属性であり、前記ディメンションｄはｎ≧２が成立する状態で前記オブジェクトモデル内のｎ番目のクラスＣｎの属性であり、前記既定のオブジェクトモデル内に一連のゼロ以上の中間クラスＣ２，．．．，Ｃｎ−１があり、そのためｉ＝１，２，．．．，ｎ−１ごとにクラスＣｉとクラスＣｉ＋１との間に多対一関係がある場合、前記ディメンションｄは前記メジャーｍから到達可能である、請求項１に記載の方法。
【請求項１０】
前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションによって指定される詳細レベルまで前記メジャーｍの値をロールアップすることが、前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションに従って前記メジャーｍを含むデータテーブルの行をグループに分割すること、及び単一の集計値をグループごとに計算することを含む、請求項１に記載の方法。
【請求項１１】
前記単一の集計値を計算することが、ＳＵＭ、ＣＯＵＮＴ、ＣＯＵＮＴＤ、ＭＩＮ、ＭＡＸ、ＡＶＧ、ＭＥＤＩＡＮ、ＡＴＴＲ、ＰＥＲＣＥＮＴＩＬＥ、ＳＴＤＥＶ、ＳＴＤＥＶＰ、ＶＡＲ、及びＶＡＲＰで構成されるグループから選択される集計関数を適用することを含む、請求項１０に記載の方法。
【請求項１２】
データビジュアライゼーションを生成するためのコンピュータシステムであって、
１つ又は複数のプロセッサと、
メモリと
を含み、前記メモリは前記１つ又は複数のプロセッサによって実行されるように構成される１つ又は複数のプログラムを記憶し、前記１つ又は複数のプログラムが、
１つ又は複数のデータソース、複数の視覚変数、及び前記１つ又は複数のデータソースからの複数のデータフィールドを指定する視覚的仕様を受信することであって、各視覚変数は、前記データフィールドのそれぞれの１つ又は複数に関連し、前記データフィールドのそれぞれはディメンションｄ又はメジャーｍとして識別される、受信すること、
前記データフィールドのメジャーｍごとに、前記１つ又は複数のデータソースのための既定のオブジェクトモデル内の多対一関係のシーケンスによって前記それぞれのメジャーｍから到達可能な前記データフィールドの全てのディメンションｄで構成される、それぞれの到達可能ディメンションセットＲ（ｍ）を識別すること、
別個の到達可能ディメンションセットＲごとに、前記データフィールドの個々のデータフィールドセットＳを形成することであって、ＳはＲ内の各ディメンション及び前記データフィールドの各メジャーｍで構成され、Ｒ（ｍ）＝Ｒが成立する、形成すること、並びに
各データフィールドセットＳについて、
前記個々のデータフィールドセットＳ内のメジャーｍごとに、前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションによって指定される詳細レベルまで前記メジャーｍの値をロールアップすること、及び
前記それぞれのデータフィールドセットＳ内の前記データフィールドに従って、及びＳ内の前記データフィールドのそれぞれが関連する前記それぞれの視覚変数に従ってそれぞれのデータビジュアライゼーションを構築すること、
を行うための命令を含む、コンピュータシステム。
【請求項１３】
前記それぞれのデータビジュアライゼーションを構築することが、前記視覚的仕様から生成される１つ又は複数のデータベースクエリを使用して前記１つ又は複数のデータソースからデータのタプルを取得することを更に含む、請求項１２に記載のコンピュータシステム。
【請求項１４】
前記タプルが、前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションに従って集計されるデータを含む、請求項１３に記載のコンピュータシステム。
【請求項１５】
前記１つ又は複数のプログラムが、前記コンピュータのグラフィカルユーザインタフェース内に前記それぞれのデータビジュアライゼーションを表示するための命令を更に含む、請求項１３に記載のコンピュータシステム。
【請求項１６】
前記データビジュアライゼーションを表示することが複数の視覚マークを生成することを含み、各マークは前記１つ又は複数のデータソースから取得されるそれぞれのタプルに対応する、請求項１５に記載のコンピュータシステム。
【請求項１７】
前記視覚変数のそれぞれが行属性、列属性、フィルタ属性、色エンコード、サイズエンコード、形状エンコード、及びラベルエンコードで構成されるグループから選択される、請求項１２に記載のコンピュータシステム。
【請求項１８】
ディメンションｄ及びメジャーｍが前記既定のオブジェクトモデル内の同じクラス内にある場合、或いは前記メジャーｍが前記既定のオブジェクトモデル内の第１のクラスＣ１の属性であり、前記ディメンションｄはｎ≧２が成立する状態で前記オブジェクトモデル内のｎ番目のクラスＣｎの属性であり、前記既定のオブジェクトモデル内に一連のゼロ以上の中間クラスＣ２，．．．，Ｃｎ−１があり、そのためｉ＝１，２，．．．，ｎ−１ごとにクラスＣｉとクラスＣｉ＋１との間に多対一関係がある場合、前記ディメンションｄは前記メジャーｍから到達可能である、請求項１２に記載のコンピュータシステム。
【請求項１９】
前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションによって指定される詳細レベルまで前記メジャーｍの値をロールアップすることが、前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションに従って前記メジャーｍを含むデータテーブルの行をグループに分割すること、及び単一の集計値をグループごとに計算することを含む、請求項１２に記載のコンピュータシステム。
【請求項２０】
ディスプレイ、１つ又は複数のプロセッサ、及びメモリを有するコンピュータシステムによって実行されるように構成される１つ又は複数のプログラムを記憶する非一時的コンピュータ可読記憶媒体であって、前記１つ又は複数のプログラムが、
１つ又は複数のデータソース、複数の視覚変数、及び前記１つ又は複数のデータソースからの複数のデータフィールドを指定する視覚的仕様を受信することであって、各視覚変数は、前記データフィールドのそれぞれの１つ又は複数に関連し、前記データフィールドのそれぞれはディメンションｄ又はメジャーｍとして識別される、受信すること、
前記データフィールドのメジャーｍごとに、前記１つ又は複数のデータソースのための既定のオブジェクトモデル内の多対一関係のシーケンスによって前記それぞれのメジャーｍから到達可能な前記データフィールドの全てのディメンションｄで構成される、それぞれの到達可能ディメンションセットＲ（ｍ）を識別すること、
別個の到達可能ディメンションセットＲごとに、前記データフィールドの個々のデータフィールドセットＳを形成することであって、ＳはＲ内の各ディメンション及び前記データフィールドの各メジャーｍで構成され、Ｒ（ｍ）＝Ｒが成立する、形成すること、並びに
各データフィールドセットＳについて、
前記個々のデータフィールドセットＳ内のメジャーｍごとに、前記それぞれのデータフィールドセットＳ内の前記それぞれのディメンションによって指定される詳細レベルまで前記メジャーｍの値をロールアップすること、及び
前記それぞれのデータフィールドセットＳ内の前記データフィールドに従って、及びＳ内の前記データフィールドのそれぞれが関連する前記それぞれの視覚変数に従ってそれぞれのデータビジュアライゼーションを構築すること、
を行うための命令を含む、非一時的コンピュータ可読記憶媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
技術分野
[0001]  開示する実装形態は、一般にデータビジュアライゼーションに関し、より詳細にはデータセットのオブジェクトモデルを用いたデータセットの対話型視覚分析に関する。
【背景技術】
【０００２】
背景
[0002]  データビジュアライゼーションアプリケーションは、経営的意思決定を行うのに重要な分散、傾向、異常値、及び他の要素を含むデータセットをユーザが視覚的に理解できるようにする。一部のデータ要素は被選択データセットからのデータに基づいて計算されなければならない。例えばデータビジュアライゼーションは、データを集計するために加算を頻繁に使用する。一部のデータビジュアライゼーションアプリケーションは、集計の計算に使用可能な「詳細レベル」（ＬＯＤ）をユーザが指定することを可能にする。しかし、データビジュアライゼーションのために単一の詳細レベルを指定することは特定の計算を構築するには不十分である。
【０００３】
[0003]  一部のデータビジュアライゼーションアプリケーションは、データフィールドを選択し、それらを特定のユーザインタフェース領域内に置いてデータビジュアライゼーションを間接的に定めることにより、ユーザがデータソースからビジュアライゼーションを構築することを可能にするユーザインタフェースを提供する。例えば、参照によりその全体を本明細書に援用する現在の米国特許第７，０８９，２６６号である、２００３年６月２日に出願され「多次元データベースのクエリ及び可視化のためのコンピュータシステム及び方法（Computer Systems and Methods for the Query and Visualization of Multidimensional Databases）」と題された米国特許出願第１０／４５３，８３４号を参照されたい。しかし、複雑なデータソース及び／又は複数のデータソースがある場合、ユーザの選択に基づいてどの種類のデータビジュアライゼーションを生成するのか（もしある場合）が不明瞭な場合がある。
【発明の概要】
【課題を解決するための手段】
【０００４】
概要
[0004]  複数のテーブルからのデータを組み合わせるデータビジュアライゼーションを生成することは、とりわけ複数のファクトテーブルがある場合に困難であり得る。一部の事例では、かかる生成は、データビジュアライゼーションを生成する前にデータのオブジェクトモデルを構築することを助け得る。一部の例では、或る人がデータに関する特殊な専門家であり、その人がオブジェクトモデルを作成する。オブジェクトモデル内に関係を記憶することにより、データビジュアライゼーションアプリケーションはその情報を活用してデータにアクセスする全てのユーザを、たとえそれらのユーザが専門家でなくても支援することができる。
【０００５】
[0005]  オブジェクトは名前付き属性の集合である。オブジェクトは、店舗等の現実世界のオブジェクト、イベント、又は概念にしばしば対応する。属性は、オブジェクトと概念的に１：１の関係にあるオブジェクトの記述である。従って、店舗オブジェクトには単一の［経営者の名前］又は［従業員人数］が関連付けられ得る。物理レベルでは、オブジェクトはリレーショナルテーブル内の行として、又はＪＳＯＮ内のオブジェクトとして記憶されることが多い。
【０００６】
[0006]  クラスは、同じ属性を共有するオブジェクトの集合である。クラス内のオブジェクトを比較し、それらを集計することは分析的に有意味でなければならない。物理レベルでは、クラスはリレーショナルテーブルとして、又はＪＳＯＮ内のオブジェクトのアレイとして記憶されることが多い。
【０００７】
[0007]  オブジェクトモデルは、１組のクラス及びそれらの間の１組の多対一関係である。１対１の関係によって関係付けられるクラスは、たとえそれがユーザにとって有意味に別個でも概念的に単一のクラスとして扱われる。加えて、１対１の関係によって関係付けられるクラスは、データビジュアライゼーションユーザインタフェース内で別個のクラスとして提示することができる。関係を捕捉する連想型テーブルを追加することにより、多対多関係が２つの多対一関係へと概念的に分割される。
【０００８】
[0008]  クラスモデルが構築されると、データビジュアライゼーションアプリケーションがユーザを様々なやり方で支援することができる。一部の実装形態では、既に選択され、ユーザインタフェース内のシェルフ上に置かれているデータフィールドに基づき、データビジュアライゼーションアプリケーションが追加のフィールドを推薦することができ、又は使用できない組み合わせを回避するために実行可能なアクションを制限することができる。一部の実装形態では、データビジュアライゼーションアプリケーションがフィールドを選択する際のかなりの自由度をユーザに与え、ユーザが選択した内容に従って１つ又は複数のデータビジュアライゼーションを構築するためにオブジェクトモデルを使用する。
【０００９】
[0009]  一部の実装形態によれば、プロセスがデータビジュアライゼーションを生成する。このプロセスは、１つ又は複数のプロセッサと、１つ又は複数のプロセッサによって実行されるように構成される１つ又は複数のプログラムを記憶するメモリとを有するコンピュータにおいて実行される。このプロセスは、１つ又は複数のデータソース、複数の視覚変数、及び１つ又は複数のデータソースからの複数のデータフィールドを指定する視覚的仕様を受信する。各視覚変数はデータフィールドの１つ又は複数に関連し、データフィールドのそれぞれはディメンションｄ又はメジャーｍとして識別される。一部の実装形態では、視覚的仕様はユーザインタフェース内のユーザ選択に基づいて埋められるデータ構造である。例えばユーザは、データフィールドのパレットから行のシェルフに、列のシェルフに、又はエンコードのシェルフ（例えば色又はサイズのエンコード）にフィールドをドラッグすることができる。シェルフのそれぞれは視覚的仕様内の視覚変数に対応し、シェルフ上のデータフィールドは視覚的仕様の一部として記憶される。一部の例では、同じシェルフに関連する２つ以上のデータフィールドがあり、そのため対応する視覚変数は２つ以上の関連データフィールドを有する。視覚変数に関連する２つ以上のデータフィールドがある場合、典型的には指定の順序がある。一部の例では、同じデータフィールドが２つ以上の別個の視覚変数に関連する。概して、個々のデータビジュアライゼーションは使用可能な視覚変数の全てを使用しない。つまり視覚的仕様は、典型的には１つ又は複数のデータソースからの如何なるデータフィールドにも関連しない１つ又は複数の追加の視覚変数を含む。一部の実装形態では、視覚変数のそれぞれが行属性、列属性、フィルタ属性、色エンコード、サイズエンコード、形状エンコード、又はラベルエンコードのうちの１つである。
【００１０】
[0010]  多くの事例において、メジャーは数字フィールドであり、ディメンションは文字列データ型を有するデータフィールドである。より重要なことには、「メジャー」及び「ディメンション」のラベルはデータフィールドがどのように使用されるのかを示す。
【００１１】
[0011]  データフィールドのメジャーｍごとに、このプロセスは、１つ又は複数のデータソースのための既定のオブジェクトモデル内の多対一関係のシーケンスによってそれぞれのメジャーｍから到達可能なデータフィールドの全てのディメンションｄで構成される、それぞれの到達可能ディメンションセットＲ（ｍ）を識別する。シーケンスの長さは、ディメンションｄ及びメジャーｍが同じクラス内にある場合を表すゼロとすることができることに留意されたい。一部の実装形態では、ディメンションｄ及びメジャーｍが既定のオブジェクトモデル内の同じクラス内にある場合、或いはメジャーｍが既定のオブジェクトモデル内の第１のクラスＣ１の属性であり、ディメンションｄはｎ≧２が成立する状態でオブジェクトモデル内のｎ番目のクラスＣｎの属性であり、既定のオブジェクトモデル内に一連のゼロ以上の中間クラスＣ２，．．．，Ｃｎ−１があり、そのためｉ＝１，２，．．．，ｎ−１ごとにクラスＣｉとクラスＣｉ＋１との間に多対一関係がある場合、ディメンションｄはメジャーｍから到達可能である。
【００１２】
[0012]  視覚変数に関連するディメンションがないこと、又はディメンションのどれにも到達できない幾つかのメジャーがあることを理由にＲ（ｍ）＝Φとなる自明の場合（trivial case）もあることに留意されたい。これは有効な到達可能ディメンションセットである。
【００１３】
[0013]  到達可能ディメンションセットを構築することはメジャーの分割をもたらす。とりわけ、ｍ１〜ｍ２  ｉｆｆ  Ｒ（ｍ１）＝Ｒ（ｍ２）によって定義される関係は等価関係である。殆どの場合は１つの分割しかない（即ちＲ（ｍ）がメジャーの全てについて同じである）が、一部の例では複数の分割がある。
【００１４】
[0014]  別個の到達可能ディメンションセットＲごとに、このプロセスは個々のデータフィールドセットＳを形成する。セットＳは、Ｒ内の各ディメンション及びデータフィールドの各メジャーｍで構成され、Ｒ（ｍ）＝Ｒが成立する。概して、データフィールドセットのそれぞれは少なくとも１つのメジャーを含む。一部の実装形態では、メジャーを有さない任意のデータフィールドセットを無視する。一部の実装形態では、メジャーを有さないデータフィールドセットＳが識別される場合、データビジュアライゼーションアプリケーションがエラーを発生させる。一部の実装形態では、データビジュアライゼーションアプリケーションが（１つ又は複数のメジャーを含むデータフィールドセットＳのそれぞれについて作成されるデータビジュアライゼーションに加えて）メジャーを有さないデータフィールドセットＳのそれぞれについて追加のデータビジュアライゼーションを構築する。
【００１５】
[0015]  各データフィールドセットＳについて、個々のデータフィールドセットＳ内のメジャーｍごとに、このプロセスはそれぞれのデータフィールドセットＳ内のそれぞれのディメンションによって指定される詳細レベルまでメジャーｍの値をロールアップする。次いでこのプロセスは、それぞれのデータフィールドセットＳ内のデータフィールドに従って、及びＳ内のデータフィールドのそれぞれが関連するそれぞれの視覚変数に従ってそれぞれのデータビジュアライゼーションを構築する。
【００１６】
[0016]  一部の実装形態では、それぞれのデータビジュアライゼーションを構築することが、視覚的仕様から生成される１つ又は複数のデータベースクエリを使用して１つ又は複数のデータソースからデータのタプルを取得することを含む。例えばＳＱＬデータソースでは、このプロセスはＳＱＬクエリを構築し、そのクエリを適切なＳＱＬデータベースエンジンに送信する。一部の例では、タプルが、それぞれのデータフィールドセットＳ内のそれぞれのディメンションに従って集計されるデータを含む。つまり、集計はデータソースによって行われる。
【００１７】
[0017]  概して、生成済みのデータビジュアライゼーションはコンピュータ上のグラフィカルユーザインタフェース（例えばデータビジュアライゼーションアプリケーションのためのユーザインタフェース）内に表示される。一部の実装形態では、データビジュアライゼーションを表示することが複数の視覚マークを生成することを含み、各マークは１つ又は複数のデータソースから取得されるそれぞれのタプルに対応する。一部の実装形態では、グラフィカルユーザインタフェースがデータビジュアライゼーション領域を含み、このプロセスはデータビジュアライゼーション領域内にデータビジュアライゼーションを表示する。
【００１８】
[0018]  一部の実装形態では、それぞれのデータフィールドセットＳ内のそれぞれのディメンションによって指定される詳細レベルまでメジャーｍの値をロールアップすることが、それぞれのデータフィールドセットＳ内のそれぞれのディメンションに従ってメジャーｍを含むデータテーブルの行をグループに分割すること、及び単一の集計値をグループごとに計算することを含む。
【００１９】
[0019]  一部の実装形態では、単一の集計値が、集計関数ＳＵＭ、ＣＯＵＮＴ、ＣＯＵＮＴＤ（個別要素数）、ＭＩＮ、ＭＡＸ、ＡＶＧ（平均）、ＭＥＤＩＡＮ、ＳＴＤＥＶ（標準偏差）、ＶＡＲ（分散）、ＰＥＲＣＥＮＴＩＬＥ（例えば四分位数）、ＡＴＴＲ、ＳＴＤＥＶＰ、及びＶＡＲＰの１つを使用して計算される。一部の実装形態では、ＡＴＴＲ（）集計演算子は全ての行について単一の値を有する場合は式の値を返し、さもなければアスタリスクを返す。一部の実装形態では、ＳＴＤＥＶＰ及びＶＡＲＰ集計演算子はバイアスをかけた母集団又は全母集団に基づく値を返す。一部の実装形態は、本明細書で挙げるよりも多くの又はそれと異なる集計演算子を含む。一部の実装形態は集計演算子に代替名を使用する。
【００２０】
[0020]  一部の実装形態では、データフィールドがどのように使用されているのかに基づいてデータフィールドが「ディメンション」又は「メジャー」として分類される。ディメンションはデータセットを分割するのに対し、メジャーは分割のそれぞれの中のデータを集計する。ＳＱＬの考え方からは、ディメンションはＧＲＯＵＰ  ＢＹ節内の要素であり、メジャーはＳＥＬＥＣＴ節内の要素である。通常、離散的カテゴリカルデータ（例えば州、地域、又は製品名を含むフィールド）が分割に使用されるのに対し、連続的数値データ（例えば収益又は売上高）が集計（例えば和の計算）に使用される。しかし、あらゆる種類のデータフィールドがディメンション又はメジャーとして使用可能である。例えば集計関数ＣＯＵＮＴＤ（固有値数）を適用することにより、製品名を含む離散的カテゴリカルフィールドをメジャーとして使用することができる。他方で人の身長を表す数値データをディメンションとして使用し、身長又は身長の範囲によって人を分割することができる。ＳＵＭ等の一部の集計関数は数値データにしか適用することができない。一部の実装形態では、アプリケーションがフィールドの生のデータの種類に基づいて既定の役割（ディメンション又はメジャー）を各フィールドに割り当てるが、その役割をユーザがオーバライドすることを可能にする。例えば一部のアプリケーションは、カテゴリカル（文字列）データフィールドに「ディメンション」の既定の役割を割り当て、数値フィールドに「メジャー」の既定の役割を割り当てる。一部の実装形態では日付フィールドが既定でディメンションとして使用され、それは日付フィールドが一般にデータを日付範囲に分割するために使用されるからである。
【００２１】
[0021]  ディメンション又はメジャーとしての分類は計算式にも適用される。例えばＹＥＡＲ（［購入日］）等の式は一般にディメンションとして使用され、基礎を成すデータを年に分割する。別の例として、（文字列として）製品コードフィールドを含むデータソースを検討されたい。製品コードの最初の３文字が製品の種類をエンコードする場合、データを製品の種類に分割するためのディメンションとしてＬＥＦＴ（［製品コード］，３）の式を使用することができる。
【００２２】
[0022]  一部の実装形態は、対話型グラフィカルユーザインタフェースを使用してユーザが複数の詳細レベルを指定することを可能にする。一部の例は２つの詳細レベルを使用するが、実装形態は典型的には無限数の詳細レベルを認める。一部の例では、或る詳細レベルにおける集計に従って計算されるデータが第２の詳細レベルにおける第２の集計に使用される。一部の実装形態では、集計を計算するために既定で使用される「ビジュアライゼーションの詳細レベル」をデータビジュアライゼーションが含む。これは最終的なデータビジュアライゼーションにおいて認識可能な詳細レベルである。実装形態は、一定のコンテキストにおいて特定の詳細レベルをユーザが指定することを可能にする詳細レベルの式も提供する。
【００２３】
[0023]  一部の実装形態は、所望のデータビジュアライゼーションの特性を決定する指定のシェルフ領域を有する。例えば、一部の実装形態は行のシェルフ領域及び列のシェルフ領域を含む。ユーザは（例えばスキーマ領域からフィールドをドラッグすることによって）これらのシェルフ領域内にフィールド名を置き、そのフィールド名はデータビジュアライゼーションの特性を定める。例えばユーザは、フィールドの別個の値ごとの列を列のシェルフ領域の中に置いた状態で縦棒グラフを選択することができる。それぞれの棒の高さは行のシェルフ領域内に置かれる別のフィールドによって定められる。
【００２４】
[0024]  一部の実装形態によれば、データビジュアライゼーションを生成し表示する方法がコンピュータにおいて実行される。コンピュータは、ディスプレイ、１つ又は複数のプロセッサ、及び１つ又は複数のプロセッサによって実行されるように構成される１つ又は複数のプログラムを記憶するメモリを有する。このプロセスは、ディスプレイ上にグラフィカルユーザインタフェースを表示する。グラフィカルユーザインタフェースは、データベースからの複数のフィールドを含むスキーマ情報領域を含む。このプロセスは、第１の集計を指定するためのユーザ入力をグラフィカルユーザインタフェース内で受信する。第１の集計の指定は、複数のフィールドのうちの第１の１組の１つ又は複数のフィールドによってデータをグループ化し、第１の集計によって作成される第１の集計済み出力フィールドを識別する。このプロセスは、第２の集計を指定するためのユーザ入力もグラフィカルユーザインタフェース内で受信する。一部の例では第２の集計の指定が第１の集計を参照する。第２の集計は、第２の１組の１つ又は複数のフィールドによってデータをグループ化する。第２の１組のフィールドは、複数のフィールド及び第１の集計済み出力フィールドから選択される。第２の１組のフィールドは第１の１組のフィールドと異なる。このプロセスは、第１の集計及び第２の集計の指定に基づいて視覚的仕様を構築する。
【００２５】
[0025]  一部の実装形態では、このプロセスは、視覚的仕様から生成される１つ又は複数のデータベースクエリを使用してデータベースからデータのタプルを取得することを含む。一部の実装形態では、タプルが第２の集計に基づいて計算されるデータを含む。一部の実装形態では、このプロセスが視覚的仕様に対応するデータビジュアライゼーションを表示することを含み、データビジュアライゼーションは第２の集計に基づいて計算されるデータを含む。一部の実装形態では、表示されるデータビジュアライゼーションが複数の視覚マークを含み、各マークはデータベースから取得されるそれぞれのタプルに対応する。一部の実装形態では、グラフィカルユーザインタフェースがデータビジュアライゼーション領域を含み、このプロセスがデータビジュアライゼーション領域内にデータビジュアライゼーションを表示する。
【００２６】
[0026]  一部の実装形態では、グラフィカルユーザインタフェースが列のシェルフ及び行のシェルフを含む。一部の実装形態では、このプロセスが、複数のフィールドのうちの１つ又は複数の第１のフィールドを列のシェルフに関連付け、複数のフィールドのうちの１つ又は複数の第２のフィールドを行のシェルフに関連付けるためのユーザアクションを検出する。次いでこのプロセスは、ユーザアクションに従ってデータビジュアライゼーション領域内に視覚テーブルを生成する。視覚テーブルは１つ又は複数のペインを含み、各ペインは列のシェルフに関連する１つ又は複数の第１のフィールドのデータに基づいて定められるｘ軸を有し、行のシェルフに関連する１つ又は複数の第２のフィールドのデータに基づいて定められるｙ軸を有する。一部の実装形態では、このプロセスは第２の集計を列のシェルフ又は行のシェルフに関連付けるためのユーザ入力を受信する。
【００２７】
[0027]  一部の実装形態では、このプロセスが、行のシェルフ及び列のシェルフに関連するフィールドに従ってデータベースからタプルを取得し、視覚テーブル内の視覚マークとして取得したタプルを表示する。一部の実装形態では、第１の集計及び第２の集計の各演算子がＳＵＭ、ＣＯＵＮＴ、ＣＯＵＮＴＤ、ＭＩＮ、ＭＡＸ、ＡＶＧ、ＭＥＤＩＡＮ、ＡＴＴＲ、ＰＥＲＣＥＮＴＩＬＥ、ＳＴＤＥＶ、ＳＴＤＥＶＰ、ＶＡＲ、又はＶＡＲＰの１つである。
【００２８】
[0028]  一部の例では、第１の集計済み出力フィールドがディメンションとして使用され、第２の組に含まれる。
【００２９】
[0029]  一部の実装形態では、第１の集計済み出力フィールドがメジャーとして使用され、第２の集計が第１の集計済み出力フィールドに集計演算子の１つを適用する。例えば一部の例では、第２の集計が第１の集計済み出力フィールドの値の平均を計算する。
【００３０】
[0030]  一部の実装形態では、このプロセスがコンピュータディスプレイ上にグラフィカルユーザインタフェースを表示する。グラフィカルユーザインタフェースは、スキーマ情報領域及びデータビジュアライゼーション領域を含む。スキーマ情報領域は複数のフィールド名を含み、各フィールド名は指定のデータベースからのデータフィールドに関連する。データビジュアライゼーション領域は、データビジュアライゼーションの特性を決定する複数のシェルフ領域を含む。各シェルフ領域は、スキーマ情報領域からのフィールド名の１つ又は複数のユーザ配置を受け付けるように構成される。このプロセスは、フィールド名の１つ又は複数をユーザが選択すること、及びデータビジュアライゼーション領域内のそれぞれのシェルフ領域内にユーザが選択した各フィールド名をユーザが配置することに従って視覚的仕様を構築する。
【００３１】
[0031]  一部の実装形態では、データビジュアライゼーションが複数の別個の構成要素のデータビジュアライゼーションを含むダッシュボードを含む。視覚的仕様は複数の構成要素の視覚的仕様を含み、それぞれの構成要素のデータビジュアライゼーションは構成要素の視覚的仕様のそれぞれに基づく。
【００３２】
[0032]  一部の実装形態では、視覚的仕様によって定められるデータビジュアライゼーションの特性がマークの種類及びマークのゼロ以上のエンコードを含む。一部の実装形態では、マークの種類が棒グラフ、線グラフ、散布図、テキストテーブル、又はマップの１つである。一部の実装形態では、エンコードがマークのサイズ、マークの色、及びマークのラベルから選択される。
【００３３】
[0033]  一部の実装形態によれば、データビジュアライゼーションを生成するためのシステムが１つ又は複数のプロセッサ、メモリ、及びメモリ内に記憶される１つ又は複数のプログラムを含む。プログラムは１つ又は複数のプロセッサによって実行されるように構成される。プログラムは本明細書に記載の方法の何れかを実行するための命令を含む。
【００３４】
[0034]  一部の実装形態によれば、非一時的コンピュータ可読記憶媒体が、１つ又は複数のプロセッサ及びメモリを有するコンピュータシステムによって実行されるように構成される１つ又は複数のプログラムを記憶する。１つ又は複数のプログラムは本明細書に記載の方法の何れかを実行するための命令を含む。
【００３５】
[0035]  従って、データセットの対話型視覚分析のための方法、システム、及びグラフィカルユーザインタフェースを提供する。
【００３６】
図面の簡単な説明
[0036]  本発明の上記の実装形態並びに追加の実装形態をよりよく理解するために、以下の図面に関連して以下の実装形態の説明を参照すべきであり、図面の全体を通して同様の参照番号が対応する部分を指す。
【００３７】
[0053]  図面の全体を通して同様の参照番号が対応する部分を指す。
【図面の簡単な説明】
【００３８】
【図１】[0037]一部の実装形態による、データビジュアライゼーションを構築するプロセスを概念的に示す。
【図２】[0038]一部の実装形態による、計算装置のブロック図である。
【図３】[0039]一部の実装形態による、データビジュアライゼーションサーバのブロック図である。
【図４】[0040]一部の実装形態による、データビジュアライゼーションユーザインタフェースの一例を示す。
【図５】[0041]一部の実装形態による、３つのクラスを有する単純なオブジェクトモデルを示す。
【図６】[0042]一部の実装形態による、別のクラスとの２つの別個の関係を有する単一のクラスを示す。
【図７Ａ】[0043]一部の実装形態による、４つのクラス間の１組の蝶ネクタイ型の関係及びこのコンテキストにおいて提示され得るデータビジュアライゼーションを示す。
【図７Ｂ】[0043]一部の実装形態による、４つのクラス間の１組の蝶ネクタイ型の関係及びこのコンテキストにおいて提示され得るデータビジュアライゼーションを示す。
【図８】[0044]一部の実装形態による、データビジュアライゼーションが単一のクラスについて作成される非常に単純なオブジェクトモデルを示す。
【図９Ａ】[0045]一部の実装形態による、階層的にネストされていない２つの別個のクラスからのディメンションを含むデータビジュアライゼーションの構築を示す。
【図９Ｂ】[0045]一部の実装形態による、階層的にネストされていない２つの別個のクラスからのディメンションを含むデータビジュアライゼーションの構築を示す。
【図９Ｃ】[0045]一部の実装形態による、階層的にネストされていない２つの別個のクラスからのディメンションを含むデータビジュアライゼーションの構築を示す。
【図１０】[0046]一部の実装形態による、オブジェクトモデル内の２つ以上の別個のクラスの属性であるメジャーのユーザ選択を示す。
【図１１】[0046]一部の実装形態による、オブジェクトモデル内の２つ以上の別個のクラスの属性であるメジャーのユーザ選択を示す。
【図１２Ａ】[0047]一部の実装形態による、１つ又は複数の被選択ディメンションよりも階層的に上の１つ又は複数のメジャーのユーザ選択、及び対応するデータビジュアライゼーションを示す。
【図１２Ｂ】[0047]一部の実装形態による、１つ又は複数の被選択ディメンションよりも階層的に上の１つ又は複数のメジャーのユーザ選択、及び対応するデータビジュアライゼーションを示す。
【図１２Ｃ】[0047]一部の実装形態による、１つ又は複数の被選択ディメンションよりも階層的に上の１つ又は複数のメジャーのユーザ選択、及び対応するデータビジュアライゼーションを示す。
【図１３Ａ】[0048]一部の実装形態による、データモデル内でつながっていないモデル内の２つ以上のクラスからのメジャー及びディメンションのユーザ選択、及び生成され得る対応するデータビジュアライゼーションを示す。
【図１３Ｂ】[0048]一部の実装形態による、データモデル内でつながっていないモデル内の２つ以上のクラスからのメジャー及びディメンションのユーザ選択、及び生成され得る対応するデータビジュアライゼーションを示す。
【図１３Ｃ】[0048]一部の実装形態による、データモデル内でつながっていないモデル内の２つ以上のクラスからのメジャー及びディメンションのユーザ選択、及び生成され得る対応するデータビジュアライゼーションを示す。
【図１３Ｄ】[0048]一部の実装形態による、データモデル内でつながっていないモデル内の２つ以上のクラスからのメジャー及びディメンションのユーザ選択、及び生成され得る対応するデータビジュアライゼーションを示す。
【図１４Ａ】[0049]一部の実装形態による、オブジェクトモデル内の２つ以上の別個のクラスからのメジャーのユーザ選択であって、少なくとも１つの階層クラスがそれらをつなぐ、ユーザ選択、並びにこのシナリオについて生成され得るデータビジュアライゼーションを示す。
【図１４Ｂ】[0049]一部の実装形態による、オブジェクトモデル内の２つ以上の別個のクラスからのメジャーのユーザ選択であって、少なくとも１つの階層クラスがそれらをつなぐ、ユーザ選択、並びにこのシナリオについて生成され得るデータビジュアライゼーションを示す。
【図１４Ｃ】[0049]一部の実装形態による、オブジェクトモデル内の２つ以上の別個のクラスからのメジャーのユーザ選択であって、少なくとも１つの階層クラスがそれらをつなぐ、ユーザ選択、並びにこのシナリオについて生成され得るデータビジュアライゼーションを示す。
【図１５】[0049]一部の実装形態による、オブジェクトモデル内の２つ以上の別個のクラスからのメジャーのユーザ選択であって、少なくとも１つの階層クラスがそれらをつなぐ、ユーザ選択、並びにこのシナリオについて生成され得るデータビジュアライゼーションを示す。
【図１６】[0050]一部の実装形態による、オブジェクトモデル内のどのディメンションが到達可能かを決定するための擬似コード記述を示す。
【図１７】[0051]一部の実装形態による、データビジュアライゼーションアプリケーション内のフィルタを定めるためのユーザインタフェースウィンドウのスクリーンショットである。
【図１８Ａ】[0052]一部の実装形態による、データビジュアライゼーションを構築するときにオブジェクトモデルを使用するプロセスの流れ図を示す。
【図１８Ｂ】[0052]一部の実装形態による、データビジュアライゼーションを構築するときにオブジェクトモデルを使用するプロセスの流れ図を示す。
【図１８Ｃ】[0052]一部の実装形態による、データビジュアライゼーションを構築するときにオブジェクトモデルを使用するプロセスの流れ図を示す。
【発明を実施するための形態】
【００３９】
[0054]  次に、添付図面にその例を示す実装形態を詳細に参照する。以下の詳細な説明では、本発明の完全な理解を与えるために数多くの具体的詳細を記載している。しかし、本発明はそれらの具体的詳細なしに実践できることが当業者には明らかである。
【００４０】
実装形態の説明
[0055]  対話型データビジュアライゼーションアプリケーションの一部の実装形態は、図１に示すように視覚的仕様１０４を構築するためにデータビジュアライゼーションユーザインタフェース１０２を使用する。視覚的仕様は、局所的に（例えばユーザインタフェース１０２を表示しているのと同じ装置上に）記憶され得る又は外部的に（例えばデータベースサーバ上に又はクラウド内に）記憶され得る１つ又は複数のデータソース１０６を識別する。視覚的仕様１０４は視覚変数も含む。視覚変数は、データソース１０６からの被選択データフィールドに従って所望のデータビジュアライゼーションの特性を間接的に指定する。具体的には、ユーザは視覚変数のそれぞれにゼロ以上のデータフィールドを割り当て、データフィールドの値が表示されるデータビジュアライゼーションを決定する。
【００４１】
[0056]  殆どの場合、視覚変数の全てが使用されるわけではない。一部の例では、視覚変数の一部が２つ以上の割り当てデータフィールドを有する。このシナリオでは、視覚変数に関する割り当てデータフィールドの順序（例えばデータフィールドがユーザによって視覚変数に割り当てられた順序）は、典型的にはデータビジュアライゼーションがどのように生成され表示されるのかに影響を及ぼす。
【００４２】
[0057]  一部の実装形態は、適切なデータビジュアライゼーションを構築するためにオブジェクトモデル１０８を使用する。一部の例では、オブジェクトモデルが１つのデータソース（例えば１つのＳＱＬデータベース又は１つのスプレッドシートファイル）に適用されるが、オブジェクトモデルは２つ以上のデータソースを包含し得る。典型的には、無関係のデータソースは別個のオブジェクトモデルを有する。一部の例では、オブジェクトモデルは物理データソースのデータモデルを密に模倣する（例えばＳＱＬデータベース内のテーブルに対応するオブジェクトモデル内のクラス）。しかし一部の事例では、オブジェクトモデルが物理データソースよりも正規化されている（又は正規化されていない）。オブジェクトモデルは、互いに１対１の関係を有する属性（例えばデータフィールド）をグループ化してクラスを形成し、それらのクラス間の多対一関係を識別する。以下の解説では、多対一関係が矢印を使って示されており、各関係の「多」の側は、その関係の「一」の側よりも鉛直下方にある。オブジェクトモデルは、データフィールド（属性）のそれぞれをディメンション又はメジャーとして識別する。以下、ディメンションを表すために「Ｄ」（又は「ｄ」）の文字を使用するのに対し、メジャーを表すために後者の「Ｍ」（又は「ｍ」）を使用する。オブジェクトモデル１０８が構築されると、オブジェクトモデル１０８はユーザが選択するデータフィールドに基づくデータビジュアライゼーションの構築を助けることができる。単一のデータモデルが他の無限数の人々によって使用可能なので、データソースに関するオブジェクトモデルを構築することはデータソースに対して相対的に専門家である人に概して委ねられる。
【００４３】
[0058]  ユーザが視覚的仕様にデータフィールドを（例えばグラフィカルユーザインタフェースを使用してデータフィールドをシェルフ上に置くことによって間接的に）追加すると、データビジュアライゼーションアプリケーション２２２（又はウェブアプリケーション３２２）はユーザが選択したデータフィールドをオブジェクトモデル１０８に従ってまとめる（１１０）。このグループをデータフィールドセット２９４と呼ぶ。多くの場合、ユーザが選択するデータフィールドの全てが単一のデータフィールドセット２９４内にある。一部の例では２つ以上のデータフィールドセット２９４がある。各メジャーｍは厳密に１つのデータフィールドセット２９４内にあるが、各ディメンションｄは複数のデータフィールドセット２９４内にあり得る。データフィールドセット２９４を構築するプロセスは、図１０、図１１、図１３Ａ〜図１３Ｃ、図１４Ａ〜図１４Ｃ、図１５、図１６、及び図１８Ａ〜図１８Ｃに関して以下でより詳細に説明している。
【００４４】
[0059]  データビジュアライゼーションアプリケーション２２２（又はウェブアプリケーション３２２）が第１のデータフィールドセット２９４についてデータソース１０６をクエリし（１１２）、取得したデータに対応する第１のデータビジュアライゼーション１２２を生成する。第１のデータビジュアライゼーション１２２は、第１のデータフィールドセット２９４から、割り当てデータフィールド２８４を有する視覚的仕様１０４内の視覚変数２８２に従って構築される。データフィールドセット２９４が１つしかない場合、視覚的仕様１０４内の情報の全てを使用して第１のデータビジュアライゼーション１２２を構築する。データフィールドセット２９４が２つ以上ある場合、第１のデータビジュアライゼーション１２２は、第１のデータフィールドセット２９４に関連する全ての情報で構成される第１の視覚的下位仕様に基づく。例えば、元の視覚的仕様１０４がデータフィールドｆを使用するフィルタを含むと仮定されたい。フィールドｆが第１のデータフィールドセット２９４内に含まれる場合、フィルタは第１の視覚的下位仕様の一部であり、従って第１のデータビジュアライゼーション１２２を生成するために使用される。
【００４５】
[0060]  第２の（又は後続の）データフィールドセット２９４がある場合、データビジュアライゼーションアプリケーション２２２（又はウェブアプリケーション３２２）が第２の（又は後続の）データフィールドセット２９４についてデータソース１０６をクエリし（１１４）、取得したデータに対応する第２の（又は後続の）データビジュアライゼーション１２４を生成する。このデータビジュアライゼーション１２４は、第２の（又は後続の）データフィールドセット２９４から、割り当てデータフィールド２８４を有する視覚的仕様１０４内の視覚変数２８２に従って構築される。
【００４６】
[0061]  図２は、データビジュアライゼーション１２２を表示するためにデータビジュアライゼーションアプリケーション２２２又はデータビジュアライゼーションウェブアプリケーション３２２を実行することができる計算装置２００を示すブロック図である。一部の実装形態では、この計算装置はデータビジュアライゼーションアプリケーション２２２のためのグラフィカルユーザインタフェース１０２を表示する。計算装置２００は、ディスプレイ及びデータビジュアライゼーションアプリケーション２２２を実行可能なプロセッサを有するデスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、及び他の計算装置を含む。計算装置２００は、典型的にはメモリ２１４内に記憶されるモジュール、プログラム、及び／又は命令を実行し、それにより処理操作を実行するための１つ又は複数の処理装置／コア（ＣＰＵ）２０２と、１つ又は複数のネットワーク又は他の通信インタフェース２０４と、メモリ２１４と、それらの構成要素を相互接続するための１つ又は複数の通信バス２１２とを含む。通信バス２１２は、システム構成要素間の通信を相互接続し制御する回路を含み得る。計算装置２００は、ディスプレイ２０８及び１つ又は複数の入力装置若しくは機構２１０を含むユーザインタフェース２０６を含む。一部の実装形態では、入力装置／機構がキーボードを含み、一部の実装形態では、入力装置／機構が必要に応じてディスプレイ２０８上に表示される「ソフト」キーボードを含み、ユーザがディスプレイ２０８上に表示される「キーを押す」ことを可能にする。一部の実装形態では、ディスプレイ２０８及び入力装置／機構２１０がタッチスクリーンディスプレイ（タッチセンスディスプレイとも呼ばれる）を含む。一部の実装形態では、ディスプレイが計算装置２００の統合された部分である。一部の実装形態では、ディスプレイが別個の表示装置である。
【００４７】
[0062]  一部の実装形態では、メモリ２１４が、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ  ＲＡＭ、又は他のランダムアクセス固体記憶装置等の高速ランダムアクセスメモリを含む。一部の実装形態では、メモリ２１４が、１つ又は複数の磁気ディスク記憶装置、光ディスク記憶装置、フラッシュメモリ装置、又は他の不揮発性固体記憶装置等の不揮発性メモリを含む。一部の実装形態では、メモリ２１４が、ＣＰＵ２０２から離れて位置する１つ又は複数の記憶装置を含む。メモリ２１４、或いはメモリ２１４内の不揮発性メモリ装置は非一時的コンピュータ可読記憶媒体を含む。一部の実装形態では、メモリ２１４、又はメモリ２１４のコンピュータ可読記憶媒体が以下のプログラム、モジュール、及びデータ構造、又はその部分集合を記憶する：
・様々な基本システムサービスを処理するための、及びハードウェア依存タスクを実行するための手続きを含むオペレーティングシステム２１６
・１つ又は複数の通信ネットワークインタフェース２０４（有線又は無線）、及びインターネット、他の広域ネットワーク、ローカルエリアネットワーク、都市圏ネットワーク等の１つ又は複数の通信ネットワークを介して計算装置２００を他のコンピュータ及び装置に接続するために使用される通信モジュール２１８
・リモートコンピュータ又は装置とネットワーク上でユーザが通信することを可能にするウェブブラウザ２２０（又は他のクライアントアプリケーション）
・ユーザが視覚的グラフィックス（例えば個々のデータビジュアライゼーション又は関係する複数のデータビジュアライゼーションを有するダッシュボード）を構築するためのグラフィカルユーザインタフェース１０２を提供するデータビジュアライゼーションアプリケーション２２２。一部の実装形態では、データビジュアライゼーションアプリケーション２２２が独立型アプリケーション（例えばデスクトップアプリケーション）として実行される。一部の実装形態では、データビジュアライゼーションアプリケーション２２２がウェブブラウザ２２０内で（例えばウェブアプリケーション３２２として）実行される。
・以下の図４で示すように要素を視覚的に指定することによってデータビジュアライゼーションをユーザが構築することを可能にするグラフィカルユーザインタフェース１０２
・一部の実装形態では、ユーザインタフェース１０２が、所望のデータビジュアライゼーションの特性を指定するために使用される複数のシェルフ領域２５０を含む。一部の実装形態では、シェルフ領域２５０が、所望のデータビジュアライゼーション内のデータの構成を指定するために使用される列のシェルフ２３０及び行のシェルフ２３２を含む。概して、列のシェルフ２３０上に置かれるフィールドはデータビジュアライゼーション内の列（例えば視覚マークのｘ座標）を定めるために使用される。同様に、行のシェルフ２３２上に置かれるフィールドはデータビジュアライゼーション内の行（例えば視覚マークのｙ座標）を定める。一部の実装形態では、シェルフ領域２５０がフィルタのシェルフ２６２を含み、このフィルタのシェルフ２６２は、被選択データフィールドに従ってユーザが閲覧データを限定すること（例えば特定のフィールドが特定の値を有する又は特定の範囲内の値を有する行にデータを限定すること）を可能にする。一部の実装形態では、シェルフ領域２５０が、データマークの様々なエンコードを指定するために使用されるマークのシェルフ２６４を含む。一部の実装形態では、マークのシェルフ２６４が（データフィールドに基づいてデータマークの色を指定するための）色エンコードアイコン２７０、（データフィールドに基づいてデータマークのサイズを指定するための）サイズエンコードアイコン２７２、（データマークに関連するラベルを指定するための）テキストエンコードアイコン、及び（データビジュアライゼーションの詳細レベルを指定し又は修正するための）ビューレベル詳細アイコン２２８を含む。
・所望のデータビジュアライゼーションの特性を定めるために使用される視覚的仕様１０４。一部の実装形態では、視覚的仕様１０４がユーザインタフェース１０２を使用して構築される。視覚的仕様は、データソース１０６を見つけるのに十分な情報（例えばデータソース名又はネットワークのフルパス名）を提供する識別済みデータソース２８０（即ちデータソースがどれなのかを指定する）を含む。視覚的仕様１０４は、視覚変数２８２及び視覚変数のそれぞれに関する割り当てデータフィールド２８４も含む。一部の実装形態では、視覚的仕様がシェルフ領域２５０のそれぞれに対応する視覚変数を有する。一部の実装形態では、視覚変数が、計算装置２００に関するコンテキスト情報、ユーザ設定情報、又はシェルフ領域として実装されていない他のデータビジュアライゼーション特徴（例えば分析的特徴）等の他の情報も含む。
・データソース１０６の構造を識別する１つ又は複数のオブジェクトモデル１０８。オブジェクトモデルでは、データフィールド（属性）がクラスに組織化され、各クラス内の属性は互いに１対１対応を有する。オブジェクトモデルはクラス間の多対一関係も含む。一部の例では、テーブル間の外部キー関係に対応するクラス間の多対一関係と共に、オブジェクトモデルがデータベース内の各テーブルをクラスにマップする。一部の例では、基礎を成すソースのデータモデルがこの単純なやり方でオブジェクトモデルに正常にマップせず、そのためオブジェクトモデルは生データを適切なクラスオブジェクトに変換する方法を指定する情報を含む。一部の例では、生データのソースは、複数のクラスに変換される単純なファイル（例えばスプレッドシート）である。
・視覚的仕様に従ってデータビジュアライゼーションを生成し表示するデータビジュアライゼーションジェネレータ２９０。一部の実装形態によれば、データビジュアライゼーションジェネレータ２９０はオブジェクトモデル１０８を使用して、視覚的仕様１０４内のどのディメンションが視覚的仕様内のデータフィールドから到達可能なのかを明らかにする。それぞれの視覚的仕様について、このプロセスは１つ又は複数の到達可能ディメンションセット２９２を形成する。これを図１０、図１１、図１３Ａ〜図１３Ｃ、図１４Ａ〜図１４Ｃ、図１５、図１６、及び図１８Ａ〜図１８Ｃにおいて以下で示す。各到達可能ディメンションセット２９２は、到達可能ディメンションセット２９２内の到達可能ディメンションに加えて１つ又は複数のメジャーを概して含むデータフィールドセット２９４に対応する。
・視覚的仕様１０４及びデータソース１０６によって提供される情報以外の、データビジュアライゼーションアプリケーション２２２によって使用される情報を含むビジュアライゼーションパラメータ２３６
・データビジュアライゼーションアプリケーション２２２によって使用されるゼロ以上のデータベース又はデータソース１０６（例えば第１のデータソース１０６−１）。一部の実装形態では、データソースがスプレッドシートファイル、ＣＳＶファイル、ＸＭＬファイル、フラットファイル、ＪＳＯＮファイル、リレーショナルデータベース内のテーブル、クラウドデータベース、又は統計的データベースとして記憶され得る。
【００４８】
[0063]  上記で識別した実行可能モジュール、アプリケーション、又は手続き集合のそれぞれは、先に述べたメモリ装置の１つ又は複数の中に記憶することができ、上記の機能を実行するための１組の命令に対応する。上記で識別したモジュール又はプログラム（即ち命令集合）は別個のソフトウェアプログラム、手続き、又はモジュールとして実装する必要はなく、従って様々な実装形態においてこれらのモジュールの様々な部分集合を組み合わせ或いは再構成することができる。一部の実装形態では、メモリ２１４が上記で識別したモジュール及びデータ構造の部分集合を記憶する。一部の実装形態では、メモリ２１４が上記で記載していない追加のモジュール又はデータ構造を記憶する。
【００４９】
[0064]  図２は計算装置２００を示すが、図２は本明細書に記載する実装形態の構造上の概略図ではなく、存在し得る様々な特徴の機能的説明であることをより意図する。実際には、及び当業者によって認識されるように、別々に示したアイテムを組み合わせることができ、一部のアイテムを分けることができる。
【００５０】
[0065]  図３は、一部の実装形態による、データビジュアライゼーションサーバ３００のブロック図である。データビジュアライゼーションサーバ３００は１つ又は複数のデータベース３２８をホストすることができ、又は様々な実行可能アプリケーション若しくはモジュールを提供することができる。サーバ３００は、典型的には１つ又は複数の処理装置／コア（ＣＰＵ）３０２、１つ又は複数のネットワークインタフェース３０４、メモリ３１４、及びそれらの構成要素を相互接続するための１つ又は複数の通信バス３１２を含む。一部の実装形態では、サーバ３００が、ディスプレイ３０８並びにキーボード及びマウス等の１つ又は複数の入力装置３１０を含むユーザインタフェース３０６を含む。一部の実装形態では、通信バス３１２が、システム構成要素間の通信を相互接続し制御する回路（チップセットと呼ぶ場合がある）を含む。
【００５１】
[0066]  一部の実装形態では、メモリ３１４が、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ  ＲＡＭ、又は他のランダムアクセス固体記憶装置等の高速ランダムアクセスメモリを含み、１つ又は複数の磁気ディスク記憶装置、光ディスク記憶装置、フラッシュメモリ装置、又は他の不揮発性固体記憶装置等の不揮発性メモリを含み得る。一部の実装形態では、メモリ３１４がＣＰＵ３０２から離れて位置する１つ又は複数の記憶装置を含む。メモリ３１４、或いはメモリ３１４内の不揮発性メモリ装置は非一時的コンピュータ可読記憶媒体を含む。
【００５２】
[0067]  一部の実装形態では、メモリ３１４、又はメモリ３１４のコンピュータ可読記憶媒体が以下のプログラム、モジュール、及びデータ構造、又はその部分集合を記憶する：
・様々な基本システムサービスを処理するための、及びハードウェア依存タスクを実行するための手続きを含むオペレーティングシステム３１６
・１つ又は複数の通信ネットワークインタフェース３０４（有線又は無線）、及びインターネット、他の広域ネットワーク、ローカルエリアネットワーク、都市圏ネットワーク等の１つ又は複数の通信ネットワークを介してサーバ３００を他のコンピュータに接続するために使用されるネットワーク通信モジュール３１８
・ユーザからウェブ要求を受信し、応答のウェブページ又は他の資源を提供することによって応答するウェブサーバ３２０（ＨＴＴＰサーバ等）
・ユーザの計算装置２００上のウェブブラウザ２２０によってダウンロードされ、実行され得るデータビジュアライゼーションウェブアプリケーション３２２。概してデータビジュアライゼーションウェブアプリケーション３２２は、デスクトップのデータビジュアライゼーションアプリケーション２２２と同じ機能を有するが、ネットワークの接続性を有する任意の位置における任意の装置からのアクセスの柔軟性を提供し、インストール及び保守を必要としない。一部の実装形態では、データビジュアライゼーションウェブアプリケーション３２２が特定のタスクを実行するための様々なソフトウェアモジュールを含む。一部の実装形態では、ウェブアプリケーション３２２が、ウェブアプリケーション３２２の全ての側面のためのユーザインタフェースを提供するユーザインタフェースモジュール３２４を含む。計算装置２００について上記で説明したように、一部の実装形態ではユーザインタフェースモジュール３２４がシェルフ領域２５０を指定する。
・ユーザは所望のデータビジュアライゼーションの特性を選択するので、データビジュアライゼーションウェブアプリケーションは視覚的仕様１０４も記憶する。視覚的仕様１０４及びそれらが記憶するデータについては計算装置２００に関して上記で説明した。
・計算装置２００に関して上記で説明した１つ又は複数のオブジェクトモデル１０８
・ユーザが選択したデータソース及びデータフィールド並びにデータソース１０６を表す１つ又は複数のオブジェクトモデルに従ってデータビジュアライゼーションを生成し表示するデータビジュアライゼーションジェネレータ２９０。データビジュアライゼーションジェネレータの動作については計算装置２００に関して上記で説明しており、図１０、図１１、図１３Ａ〜図１３Ｃ、図１４Ａ〜図１４Ｃ、図１５、図１６、及び図１８Ａ〜図１８Ｃにおいて以下で説明する。
・一部の実装形態では、ウェブアプリケーション３２２が、１つ又は複数のデータソース１０６からデータを取得するためのクエリを構築し実行するデータ取得モジュール３２６を含む。データソース１０６はサーバ３００上に局所的に又は外部データベース３２８内に記憶され得る。一部の実装形態では、２つ以上のデータソースからのデータをブレンドすることができる。図２の計算装置２００に関して上記で説明したように、一部の実装形態ではデータ取得モジュール３２６がクエリを構築するために視覚的仕様１０４を使用する。
・データビジュアライゼーションウェブアプリケーション３２２又はデータビジュアライゼーションアプリケーション２２２によって使用され又は作成されるデータを記憶する１つ又は複数のデータベース３２８。データベース３２８は、生成されるデータビジュアライゼーション内で使用されるデータを提供するデータソース１０６を記憶することができる。各データソース１０６は１つ又は複数のデータフィールド３３０を含む。一部の実装形態では、データベース３２８がユーザ設定を記憶する。一部の実装形態では、データベース３２８がデータビジュアライゼーション履歴ログ３３４を含む。一部の実装形態では、データビジュアライゼーションがデータビジュアライゼーションをレンダリングするたびに履歴ログ３３４が追跡する。
【００５３】
[0068]  データベース３２８は多くの異なる形式でデータを記憶することができ、一般に複数のデータフィールド３３０をそれぞれ有する多くの別個のテーブルを含む。一部のデータソースは単一のテーブルを含む。データフィールド３３０は、データソースからの生のフィールド（例えばデータベーステーブルからの列又はスプレッドシートからの列）、並びに１つ又は複数の他のフィールドから計算され又は構築され得る導出データフィールドの両方を含む。例えば導出データフィールドは、日付フィールドから月又は四半期を計算すること、２つの日付フィールド間の期間を計算すること、定量的フィールドの累計を計算すること、パーセントの増加を計算すること等を含む。一部の例では、導出データフィールドがデータベース内のストアドプロシージャ又はビューによってアクセスされる。一部の実装形態では、導出データフィールド３３０の定義がデータソース１０６から切り離して記憶される。一部の実装形態では、データベース３２８がユーザごとの１組のユーザ設定を記憶する。ユーザ設定は、１組のデータフィールド３３０をどのように閲覧するのかに関する推薦をデータビジュアライゼーションウェブアプリケーション３２２（又はアプリケーション２２２）が行うときに使用され得る。一部の実装形態では、データベース３２８が、生成された各データビジュアライゼーションに関する情報を記憶するデータビジュアライゼーション履歴ログ３３４を記憶する。一部の実装形態では、データベース３２８が、データビジュアライゼーションアプリケーション２２２又はデータビジュアライゼーションウェブアプリケーション３２２によって使用される他の情報を含む他の情報を記憶する。データベース３２８は、データビジュアライゼーションサーバ３００と切り離すことができ又はデータビジュアライゼーションサーバと共に含めることができる（又はその両方）。
【００５４】
[0069]  一部の実装形態では、データビジュアライゼーション履歴ログ３３４がユーザによって選択される視覚的仕様１０４を記憶し、視覚的仕様１０４はユーザ識別情報、データビジュアライゼーションの作成時のタイムスタンプ、データビジュアライゼーションに使用されるデータフィールドのリスト、データビジュアライゼーションの種類（「ビュータイプ」又は「チャートタイプ」と呼ぶ場合がある）、データのエンコード（例えばマークの色及びサイズ）、選択されたデータの関係、及びどのコネクタが使用されるのかを含み得る。一部の実装形態では、各データビジュアライゼーションの１つ又は複数のサムネイル画像も記憶される。一部の実装形態は、データソースの名前及び位置、データビジュアライゼーションに含められたデータソースの行数、データビジュアライゼーションソフトウェアのバージョン等、作成されるデータビジュアライゼーションに関する追加情報を記憶する。
【００５５】
[0070]  上記で識別した実行可能モジュール、アプリケーション、又は手続き集合のそれぞれは、先に述べたメモリ装置の１つ又は複数の中に記憶することができ、上記の機能を実行するための１組の命令に対応する。上記で識別したモジュール又はプログラム（即ち命令集合）は別個のソフトウェアプログラム、手続き、又はモジュールとして実装する必要はなく、従って様々な実装形態においてこれらのモジュールの様々な部分集合を組み合わせ或いは再構成することができる。一部の実装形態では、メモリ３１４が上記で識別したモジュール及びデータ構造の部分集合を記憶する。一部の実装形態では、メモリ３１４が上記で記載していない追加のモジュール又はデータ構造を記憶する。
【００５６】
[0071]  図３はデータビジュアライゼーションサーバ３００を示すが、図３は本明細書に記載する実装形態の構造上の概略図ではなく、存在し得る様々な特徴の機能的説明であることをより意図する。実際には、及び当業者によって認識されるように、別々に示したアイテムを組み合わせることができ、一部のアイテムを分けることができる。加えて、サーバ３００に関して上記で示したプログラム、機能、手続き、又はデータの一部は計算装置２００上に記憶し又はそこで実行することができる。一部の実装形態では、機能及び／又はデータを計算装置２００と１つ又は複数のサーバ３００との間で割り当てることができる。更に、図３は単一の物理装置を表す必要がないことを当業者なら認識されよう。一部の実装形態では、サーバの機能がサーバシステムを構成する複数の物理装置にわたって割り当てられる。本明細書で使用するとき、「サーバ」又は「データビジュアライゼーションサーバ」への言及は記載される機能を提供するサーバの様々なグループ、集合、又はアレイを含み、物理サーバは物理的に一緒に配置される必要はない（例えば個々の物理装置が米国中に又は世界中に散在し得る）。
【００５７】
[0072]  図４は、一部の実装形態による、データビジュアライゼーションユーザインタフェース１０２を示す。ユーザインタフェース１０２は、データペインとも呼ぶスキーマ情報領域４１０を含む。スキーマ情報領域４１０は、データビジュアライゼーションを構築するために選択され使用され得る名前付きデータ要素（例えばフィールド名）を提供する。一部の実装形態では、フィールド名のリストがディメンションのグループ及びメジャーのグループ（典型的には数量）に分けられる。一部の実装形態はパラメータのリストも含む。グラフィカルユーザインタフェース１０２はデータビジュアライゼーション領域４１２も含む。データビジュアライゼーション領域４１２は、列のシェルフ領域２３０及び行のシェルフ領域２３２等の複数のシェルフ領域２５０を含む。これらは列のシェルフ２３０及び行のシェルフ２３２とも呼ばれる。加えてこのユーザインタフェース１０２は、１つ又は複数のフィルタ４２４を含み得るフィルタのシェルフ２６２を含む。
【００５８】
[0073]  ここで図示されているように、データビジュアライゼーション領域４１２はビジュアルグラフィックを表示するための広い空間も有する。この図面ではデータ要素がまだ選択されていないので、空間はビジュアルグラフィックを最初は有さない。
【００５９】
[0074]  ユーザは、（計算装置２００上に記憶され得る又は遠隔的に記憶され得る）１つ又は複数のデータソース１０６を選択し、データソースからデータフィールドを選択し、選択したフィールドを使用してビジュアルグラフィックを定める。データビジュアライゼーションアプリケーション２２２（又はウェブアプリケーション３２２）は、生成したグラフィック１２２をデータビジュアライゼーション領域４１２内に表示する。一部の実装形態では、ユーザが提供する情報は視覚的仕様１０４として記憶される。
【００６０】
[0075]  一部の実装形態では、データビジュアライゼーション領域４１２がマークのシェルフ２６４を含む。マークのシェルフ２６４は、ユーザがデータマークの様々なエンコード４２６を指定することを可能にする。一部の実装形態では、マークのシェルフが色エンコードアイコン２７０、サイズエンコードアイコン２７２、テキストエンコードアイコン２７４、及び／又はデータビジュアライゼーションの詳細レベルを指定し若しくは修正するために使用可能なビューレベル詳細アイコン２２８を含む。
【００６１】
[0076]  オブジェクトモデルは、ノードとしてのクラス、及びエッジとしてのそれらの多対一関係を有するグラフとして描くことができる。本明細書で示すように、各関係の「多」の側が「一の側」よりも常に下にあるようにこれらのグラフは構成される。例えば図５では、オフィスクラス５０２が企業クラス５０４と多対一関係５１２を有し、オフィスクラス５０２は国クラス５０６とも多対一関係５１４を有する。このグラフでは企業が複数のオフィスを有することができ、国が複数のオフィスを有することができるが、個々のオフィスは単一の企業及び国に属する。図５のオブジェクトモデルはつながっているが、全てのオブジェクトモデルがつながっているわけではない。概して、データソース１０６のためのオブジェクトモデル１０８は事前に構築される。ユーザが後でデータビジュアライゼーションを構築するとき、オブジェクトモデル１０８の構造が適切なデータビジュアライゼーションの生成を支援する。
【００６２】
[0077]  典型的には、１対の任意のクラスが関係グラフを通る最大でも１つのパスによって結合される。複数のパスがあり得る場合、ユーザはどのパスを使用するのかを指定し又はデータセットをピボット解除して２つのパスを１つに組み合わせる必要があり得る。
【００６３】
[0078]  以下の図面の一部は様々なオブジェクトモデルを示し、オブジェクトモデル内のディメンションＤ及びメジャーＭのユーザ選択を示す。オブジェクトモデル内のディメンション及びメジャーの位置に基づき、データビジュアライゼーションジェネレータ２９０は別個のデータビジュアライゼーションを何個生成するのか及び何を構築するのかを決定する。この文脈では、オブジェクトモデル内の別のデータフィールドから到達可能であるディメンションの概念を定めることが有用である。具体的には、データフィールドを含むクラスから始まり、ディメンションを含むクラスで終わる一連の多対一関係がある場合、ディメンションＤはデータフィールドから到達可能である。加えて、ディメンションＤがクラスＣ内にある場合、ディメンションＤはクラスＣ内の他の全てのデータフィールドから到達可能である。この場合、データフィールドから始まりディメンションで終わる一連のゼロ個の多対一関係がある。
【００６４】
[0079]  「到達可能」のこの定義により、グラフ内の所与のノードから到達可能な１組のディメンションを定めることが可能になる。具体的には、視覚的仕様１０４内の各データフィールド（ディメンション又はメジャー）について、１組の到達可能なディメンション２９２は、所与のデータフィールドと同じ詳細レベル（ＬＯＤ）にある又はデータフィールドからグラフを上位方向に移動することによって到達可能な視覚的仕様内の全てのディメンションである。
【００６５】
[0080]  各データフィールドについて、１組の到達可能なビジュアライゼーションフィルタを識別することも有用である。これは到達可能なディメンションに対する全てのフィルタを含む。適切な詳細レベルにおいてメジャーフィルタはディメンションフィルタとして暗に扱うことができることに留意されたい。
【００６６】
[0081]  図１６は、オブジェクトモデル内のデータフィールド（ディメンション又はメジャー）ごとの到達可能ディメンションを決定するための擬似コードクエリを示す。
【００６７】
[0082]  各データフィールドについて、１組の到達可能ディメンション及び到達可能フィルタがデータフィールドを中心とした暗黙のスノーフレークスキーマを作る。これはつまり、データフィールドにフィルタを適用し、メジャーを集計する明確な且つ固有のやり方があることを意味する。各データフィールドのクエリの結果を表示すること自体が結果を解釈しやすくする。
【００６８】
[0083]  ユーザが所望のビジュアライゼーションを構築しやすくすることに加えて、到達可能ディメンションを使用することはデータ取得のパフォーマンスを高めることができる。クエリは、多対一関係によって到達可能なディメンション内で結合するだけでよいのでより高速になる。これは積極的な結合選別挙動の一般化された形式として理解することができる。クエリは、所望のビジュアライゼーションを作成するのに専ら必要なテーブルと接触するだけでよい。
【００６９】
[0084]  Ｎ個のデータフィールドを使用するデータビジュアライゼーションでは、このプロセスはＮ個の別個のクエリの理論上最大値をもたらし得る。しかしそれらの多くは冗長になる。或るクエリの結果が、１つ又は複数の他のクエリの結果に含まれる可能性がある。加えて、同じ詳細レベルでメジャーを計算するクエリは組み合わせることができる。従ってこのプロセスは通常、より少ないクエリを実行する。
【００７０】
[0085]  パフォーマンスの観点から、多対多の結合により単一のモノリシッククエリではなく複数の独立したクエリを生成することには、クエリを同時に実行できるという追加の利点がある。そのため一部の実装形態は、クエリの全てがその結果を返す前にデータビジュアライゼーションをレンダリングし始めることができる。
【００７１】
[0086]  上記のクエリのセマンティクスを所与とし、複数の詳細レベル及び複数のドメインという発生する２つの主な課題がある。まず、独立したクエリは様々な詳細レベルにおける結果をもたらし得る。詳細レベルがネストする場合（例えば州では（州，都市））、これは特に問題にならない。このプロセスは単純に細かいＬＯＤに粗いＬＯＤの値を複製することができる。ＬＯＤが部分的に重複する場合（例えば（州，都市）と（州，郵便番号））、又は共通の要素をもたない場合（例えば（州，都市）と（製品，下位製品））はより困難になる。第２に、独立したクエリは異なるドメインを有する結果をもたらし得る。例えば州ごとにＳＵＭ（人口）を計算することは（米国の人口テーブルが全て揃っている場合）５０州のそれぞれについて項目を返すことができる。しかし、州ごとにＳＵＭ（売上高）を計算することは売買取引がある州しか返さない。売上高テーブルが１０の州について取引を含まない場合、クエリは４０の州についてのみ結果を返す。
【００７２】
[0087]  複数の詳細レベルに対処するために、このプロセスは同じ詳細レベルにあるクエリ結果をコングロマリット結果テーブルへと組み合わせることから始める。このプロセスは、ネストされたクエリ結果（厳密に部分集合／拡張集合のＬＯＤ関係にあるもの）も組み合わせる。このように組み合わせることは、ネストされた結果の複写をもたらすが、合計を小計と比較することを可能にするので有害ではない。
【００７３】
[0088]  これらの全ての事例を組み合わせた後でさえ、詳細レベルが部分的に重複する場合又は共通の要素をもたない場合は複数の結果テーブルが伴う例がある。これらの例において、実装形態は結果を可視化するための様々な手法を使用する。
【００７４】
[0089]  複数の詳細レベルに対処することに加えて、実装形態は他のシナリオにも対処する。データフィールドが２つ以上の異なる値のドメインを有する場合がある。例えば、１組の全ての州は注文がある１組の州と異なる可能性があり、その注文がある１組の州は従業員を有する１組の州と異なる可能性がある。オブジェクトモデルは、単一の論理概念（例えば「州」）がそれに関連する複数のドメインを有することを可能にする。
【００７５】
[0090]  別のシナリオは、複数のルート（「ファクト」）テーブルがある場合である。複数のファクトテーブルがあることは、多対多関係及び複製（複写）を生ぜしめる場合がある。加えて、複数のファクトテーブルは結合をどのように実施するのかを変え得る。多くの場合、ツリーのように結合をレイアウトすることにより、スノーフレーク構造を有する単一のファクトテーブルをクエリすることができる。しかし複数のファクトテーブルがあると、スノーフレークの中心としてどのテーブルを指定するのかに関する特有の曖昧さがあり、このやり方でのテーブル内の結合はユーザのデータモデルの優れたビジュアライゼーションではない場合がある。
【００７６】
[0091]  １つのテーブルが同じテーブル（及びそのサブツリー）への２つ以上の参照を有する場合に別のシナリオが発生する。例えば、それぞれの注文が注文日及び発送日の両方を含むシナリオを検討されたい。このデータを構造化できる様々なやり方がある。最初の事例では、注文日及び発送日のどちらも注文テーブル自体の中のデータフィールドである。この場合、データのクエリは容易である。第２の事例では、別個の注文日及び発送日のテーブルがあり、そのため注文テーブルとそれらの別個のテーブルのそれぞれとの間に別個の結合がある。第３の事例では、図６に示すように注文日情報及び発送日情報が単一の日付テーブル６０４へと統合される。この場合、注文日に対応する行の第１の部分集合６０６（例えば「注文」の日付の種類を有する）と、発送日に対応する行の第２の部分集合６０８（例えば「発送」の日付の種類を有する）とがある。このシナリオでは、注文テーブル６０２が同じ日付テーブルへの２つの結合、つまり注文日を表す行への第１の結合６１６及び発送日を表す行への第２の結合６１８を有する。
【００７７】
[0092]  クラス又はデータベーステーブル間の関係は「蝶ネクタイ型」の構成を有することもできる。図７Ａのビジュアライゼーションは、商談金額、ケースの持続時間、製品、及び顧客名を使用する。この情報を表示するためには、製品７０２に対応する行をどちらも有する２つの連結されたデータビジュアライゼーション７０４及び７０６を使用する。図７Ｂに示すように、この形態はデータモデル（又はオブジェクトモデル）を用いたブレンドを利用する。ファクトテーブルｆａｃｔＣａｓｅ７２２及びｆａｃｔＯｐｐｏｒｔｕｎｉｔｙ７２４のそれぞれは、ディメンションテーブルｄｉｍＡｃｃｏｕｎｔ７１２及びディメンションテーブルｄｉｍＰｒｏｄｕｃｔ７２８の両方への独立した関係を有する。４つの関係７３０は蝶ネクタイのように見える。口語的に名付けられた「蝶ネクタイ」は、２つのファクトテーブルが２つのディメンションテーブルに両方とも関係し得る（その関係においてクロスを要求する）概念である。
【００７８】
[0093]  一部の実装形態は、「フラット」テーブルを正規化することにも対処する。例えばデータソース（データウェアハウス等）は複数の概念的クラスを表すデータを含み得る。一部の実装形態は、有意味のクラスを表すオブジェクトモデルを構築するためによく知られている正規化手法を使用する。
【００７９】
[0094]  各オブジェクトモデルの図において、現在の視覚的仕様１０４のディメンション及びメジャーのソースを「Ｄ」及び「Ｍ」でラベル付けする。最も単純な事例では、図８に示すように現在の視覚的仕様１０４からのディメンション及びメジャーの全てを含む単一のクラスがある。このシナリオでは、メジャー及びディメンションが同じクラスから生じ、計算のセマンティクスが自明である。このプロセスはディメンションの詳細レベルまでメジャーをロールアップする。それにより、ディメンション及び集計されたメジャーを含む単一のテーブルが得られる。
【００８０】
[0095]  単一のクラス内の属性間にモデリングされた関係がないので、この結果テーブルのための小さな多数のレイアウトを作成することは必ずしも明白ではない。しかしこの問題に対処するために、シェルフのモデル（行２３２及び列２３０）は１組のヒューリスティックスを提供する。同じシェルフ上のディメンションは（例えば図９Ｂにあるように）階層軸を作成するのに対し、異なるシェルフ上のディメンションはクロスされた軸を作成する。（図７Ａの２つの列７０４及び７０６によって示すように）同じ軸の複数のメジャーが連結される。他のシェルフはマークを作成し、マークの外観を定めるために使用される。
【００８１】
[0096]  図９Ａに示すように、スノーフレークモデルではメジャーが単一のクラスから生じる。ディメンションは、同じクラス又はメジャーのクラスから関係グラフを上位方向に移動することによって到達可能なクラスから生じる。このプロセスは、関係エッジ沿いのメジャークラスのクラスにディメンションを結合する。メジャーはディメンションの詳細レベルまで集計される。他の全てのクラスは無視される。例えば図９Ａでは、メジャーの全てが注文テーブル９０４から生じ、データビジュアライゼーションが製品クラス９０２及び地域クラス９０８の両方においてディメンションを有する。製品クラス９０２及び地域クラス９０８におけるディメンションは、注文クラス９０４からメジャーを集計するための詳細レベルを定める。この例では、州クラス９０６から生じるデータビジュアライゼーションのためのディメンション又はメジャーがなく、そのためそのデータは使用されない。しかし、注文クラス９０４から地域クラス９０８までメジャーをつなぐために州クラス９０６はクエリにおいて必要であり得る。
【００８２】
[0097]  このオブジェクトモデルは、一部の実装形態では既定の挙動を決定するために使用されるディメンション間のネスト関係又はクロス関係があるかどうかを示す。図９Ａの例では製品及び地域が互いに独立しており、そのためそれらが同じ軸上にあるかどうかに関係なく、それらは小さな多数のレイアウト内でクロスされるべきである。しかし、一部の実装形態はユーザが既定の挙動をオーバライドすることを可能にする。例えばモデルが独立したディメンション間のクロス関係を示しても、ユーザは実際のデータ値によって定められる関係に純粋に基づいてネストしたい場合がある。逆に、ネストが道理にかなう場合でさえ、ユーザはクロスしたビジュアライゼーションを示し、ネストされたディメンション間の対応するペアリングがない余白を投入したい場合がある。
【００８３】
[0098]  同じ軸上のクロスされたディメンションの表示を図９Ｂに示す。この事例では、ユーザが２つの独立したディメンションであるセグメント９２０及びカテゴリ９２２を同じシェルフ（列のシェルフ領域２３０）上に置いている。ユーザは売上高９２４のメジャーを行のシェルフ２３２上に置いており、このメジャーはここではＣＯＵＮＴ（）を使用して集計される。セグメント及びカテゴリのディメンションは独立しており、そのためこれらのディメンションは既定でクロスされる。上の列ヘッダ９４０がセグメントを列挙し、下の列ヘッダ９４２がカテゴリを列挙する。クロスが原因で、カテゴリのそれぞれがセグメントのそれぞれについて表示され、これは一部のセグメント／カテゴリの組み合わせに関してデータがない場合でさえ行われる。一部の実装形態では、ユーザインタフェース１０２がクロスを扱うためのユーザ対話に対処する。例えば一部の実装形態では、クロスされた軸において１つのヘッダ（例えば最初の家具のヘッダ９２６）を選択することが対応するデータの全て（例えば同じ家具のカテゴリを有する列の全ての家具データ９３０、９３２、及び９３４）を選択することをもたらす。
【００８４】
[0099]  一部の実装形態では、異なる軸上にネストされたディメンションがある場合、この表示は図９Ｃに示すように代替技法を使用して関連性のある組み合わせだけを示す。この事例では「サブカテゴリ」のデータフィールドが「カテゴリ」のデータフィールドの下位にネストされ、これらの２つのデータフィールドが別個の軸上にある。各カテゴリのサブカテゴリは完全に異なる（例えば家具カテゴリ内では書棚及び椅子だが事務用品カテゴリ内では用具、美術品、及びバインダ）。そのためこの表示は、データビジュアライゼーション内の行ごとに１組の別個の列ヘッダを含む。これをトレリスチャートと呼ぶことがある。このチャートは各サブカテゴリが適切なカテゴリ内でのみ表示されることを確実にする。
【００８５】
[00100]  ブレンドは、メジャーが複数のクラスから生じ得るスノーフレークの事例の一般化である。これを図１０に示す。ディメンションは、単一のクラス（「結合ＬＯＤ」と呼ばれることがある）を介して全てのメジャーから到達可能である。図１０では、州クラス１００４が「結合ＬＯＤ」である。
【００８６】
[00101]  各メジャーを独立に検討する場合、このシナリオはスノーフレークと同じである。各メジャーはディメンションのＬＯＤまで独立にロールアップすることができる。次いで、集計済みのメジャーをディメンションのＬＯＤにおいて結合することができる。例えば、注文テーブル１００２からのメジャーが地域クラス１００８内のディメンションに従って集計され、供給業者クラス１００６からのメジャーも地域クラス１００８内のディメンションに従って集計される。注文クラス１００２及び供給業者クラスの両方からのメジャーが同じ詳細レベルにおいて集計されるので、ディメンションのＬＯＤにおいて単一のテーブルを形成するために結果の組を直接結合することができる。
【００８７】
[00102]  データビジュアライゼーションがディメンションを有さない（例えば総計を示している）場合、全て（ゼロ）のディメンションが任意のメジャーから到達可能なので、それは自明のブレンドの事例である。この場合、全てのメジャーが空のディメンションのＬＯＤまでロールアップされ（即ち１つの集計済みのデータ値がメジャーごとに計算され）、集計が単一のビジュアライゼーション内に表示される。これはオブジェクトモデルがつながっていない場合にも機能する。
【００８８】
[00103]  全てのディメンションが同じクラスを介して到達可能であるという制限は緩和することができる。グラフを上位方向に移動することによって全てのディメンションが全てのメジャーから到達可能である限り、このプロセスは標準のブレンドと同じクエリのセマンティクス及び視覚的なレイアウトを使用することができる。これを図１１に示し、図１１では図１０に示すデータモデルに製品クラス１１１０が追加されている。この例では、注文１００２及び供給業者１００６の両方からのメジャーが、単一の結合ＬＯＤを通過していないにも関わらず地域クラス１００８及び製品クラス１１１０内のディメンションに従ってロールアップされ得る。
【００８９】
[00104]  ディメンションの互いに対する（クロス又はネスト）関係は使用される１組のメジャーと無関係であり、そのため小さな多数の表示のレイアウトはより単純なブレンドと同様に同じ規則を使用できることに留意されたい。
【００９０】
[00105]  図１２Ａに示すように、時としてメジャーはオブジェクトモデル内のディメンションの上位に定めることができる。この事例では、地域クラス１２０８内のメジャー（ことによると人口）が全く集計されない。代わりに、メジャーは属性として（注文クラス１２０２及び製品クラス１２１０内のディメンションに従って）ディメンションのＬＯＤに複製（複写）される。事実上、データビジュアライゼーションアプリケーションはこのメジャーを単に別のディメンションとして扱う。
【００９１】
[00106]  図１２Ｃに示すように、この挙動をユーザにとって明確にするために、一部の実装形態は行のシェルフ２３２又は列のシェルフ２３０上の対応するピルに対する集計関数を抑制する。ＳＵＭ（収益）１２５０を表示する代わりに、ユーザインタフェースは収益１２５２を表示する。一部の実装形態では、ユーザインタフェースが表現の見た目を視覚的に強調しないこと等の他のやり方で変える。加えて、クロス軸における複写されたヘッダ等、一部の実装形態は選択の複写を視覚的に認識する。例えば図１２Ｂでは、データビジュアライゼーション内の行１２３０の全てが売上高のカテゴリについて同じ値を示し（１つのデータ値だけがあり）、それらの行が閲覧時に一緒に強調表示される。
【００９２】
[00107]  ディメンションの全てが非属性メジャーの全てから到達可能ではない場合、より困難な詳細レベルの問題が生じる。例えば、企業クラス１３０２及び国クラス１３０４を有するがそれらの間に関係が定められていない図１３Ａのオブジェクトモデルを検討されたい。ユーザはオブジェクトが使用可能である前に２つのオブジェクト間の関係を定める必要はないので、これは見た目ほど奇妙なことではない。
【００９３】
[00108]  一部の実装形態では、このオブジェクトモデルは、図１３Ｂに示すような２つの縦方向に連結されたデータビジュアライゼーション１３２２及び１３２４をもたらす。一部の実装形態では、図１３Ｃ及び図１３Ｄに示すように２つの別個のデータビジュアライゼーションが横方向に連結される。図１３Ｃでは、２つのビジュアライゼーション１３３２及び１３３４の最上部が横方向に位置合わせされている。図１３Ｄでは、２つのデータビジュアライゼーション１３４２及び１３４４の最下部が横方向に位置合わせされている。図１３Ｃ及び図１３Ｄのプロットは軸を共有しないことに留意されたい。
【００９４】
[00109]  一部の実装形態では、複数のデータビジュアライゼーションがある場合、ビジュアライゼーションが１つずつ表示され、ユーザがビジュアライゼーションを次々変えることを可能にする。ビジュアライゼーションを作成するためにどのフィールドが使用されるのかをユーザが理解するのを助けるために、一部の実装形態は対応するビジュアライゼーションが表示されない場合又は注目されない場合に非使用のフィールド又はフィルタをグレー表示する。
【００９５】
[00110]  一部の例では、図１４Ａに示すようにディメンションとメジャーとが多対多関係によってリンクされる。この例では、顧客クラス１４０２からのディメンション及びメジャーが多対一関係によって州クラス１４０６につながれる。同様に、企業クラス１４０４からのディメンション及びメジャーが多対一関係によって州クラス１４０６につながれる。
【００９６】
[00111]  一番下位の２つのクラス１４０２及び１４０４の両方からディメンションが含められていることを除き、この事例はブレンドと非常に似ている。結果は、企業クラス１４０４からのディメンションは顧客クラス１４０２内のメジャーから到達できず、その逆も同様であることである。追加の州クラス１４０６が追加されていることを除き、この事例は図１３Ａのつながっていないグラフの事例と同様である。
【００９７】
[00112]  シナリオによっては、一部の実装形態がブレンドとつながっていない挙動とを組み合わせ、図１４Ｂに示すように州内でネストされる顧客及び企業に関する独立したデータビジュアライゼーションを表示する。図１４Ｂに示すように、州のディメンションは顧客クラス１４０２及び企業クラス１４０４の両方から到達可能であり、そのため全体的なビジュアライゼーションは州１４２０ごとに位置合わせされる。例えば、図１４Ｂの部分的なデータビジュアライゼーションはアラバマ１４２２及びアリゾナ１４２４のデータを表示する。州に関するそれぞれの横方向の領域内に、企業１４２６の一覧が企業ごとの売上高を表す視覚マーク１４２８と共にある。加えて、それぞれの横方向の州の領域は、顧客名１４３０の一覧もそれらの個々の顧客それぞれの収益を表す視覚マーク１４３２（例えばバー）と共に有する。これは州クラス１４０６からの共有ディメンションに基づく部分的な位置合わせを示す。
【００９８】
[00113]  図１４Ｃは、図１４Ａに示す同じオブジェクトモデルから、データフィールドの異なる選択を使用して一部の実装形態が作成するデータビジュアライゼーションを示す。図１４Ｃでは、ユーザが顧客クラス１４０２から売上高のメジャーを選択し、企業クラス１４０４からも売上高のメジャーを選択している。しかし、ユーザはこれらの２つのクラスの何れからもディメンションを全く選択していない。州のディメンションがメジャーの全てから到達可能なので、メジャーのそれぞれが州にロールアップされた状態で単一のデータビジュアライゼーションがある。しかし、２つのファクトテーブル及び限られた売上高により、どの州を表示するのかに関する問題が発生する。一部の実装形態では、既定の挙動は完全外部結合を行うことであり、州のそれぞれ並びに州のそれぞれについて企業の売上高及び顧客の売上高の両方を表示する（空白はゼロを示す）。例えば図１４Ｃでは、アラバマは企業又は顧客について売上高１４５０がない。他方でカルフォルニアは企業の売上高１４５２及び顧客の売上高１４５４の両方がある。フロリダが企業の売上高１４５６だけを有し、イリノイが顧客の売上高１４５８だけを有すること等、一部の州は一方だけ又は他方だけを有する。一部の実装形態では、どのデータを表示するのかをユーザが選択する（例えば顧客クラス１４０２又は企業クラス１４０４からのデータを有さない州を省く）ことができる。一部の実装形態では、企業又は顧客に関する活動がない州を既定で省く。
【００９９】
[00114]  図１５は、州クラス１５０６からのディメンションが省かれていることを除き、図１４Ａと同じであるシナリオを示す。このオブジェクトモデルにより、顧客クラス１５０２及び企業クラス１５０４が州クラス１５０６を介して多対多関係を有することが分かっている。しかし、ユーザは州をビジュアライゼーションに含めることを要求していない。
【０１００】
[00115]  このシナリオでは、一部の実装形態は州を介したリンクを単純に無視し、つながっていないシナリオ（図１３Ａ〜図１３Ｄ）にあるのと同じビジュアライゼーションを生成する。この手法は、データビジュアライゼーション内に州を有さないことから州を含めることへの移行が幾らか自然であるという利点を有する。ユーザは２つの独立したリストから開始し、州を追加することは各州について２つの独立したリストを作成する。
【０１０１】
[00116]  一部の実装形態は、このシナリオに別のやり方で対処する。一部の実装形態は別個のビジュアライゼーションを生成するが、州に関するリンク挙動を自動で強調表示する。一部の事例ではこれが有意味である。例えば顧客が同じ州内の企業によってサービス提供され得る場合、顧客リスト内の顧客をクリックすることはそれらの顧客にサービス提供することができるそれらの顧客の州内の企業を強調表示する。逆に、企業をクリックすることはその企業がサービス提供することができる顧客を強調表示する。他方で、そのような関心を引くセマンティクスがない場合、一部の顧客と同じ州内の企業を強調表示することは集中を妨げる又は逆効果のデフォルトである可能性がある。この種のクロス強調表示は計算コストが高い場合もあり、そのためかかる強調表示を既定の挙動にすることは計算資源が限られている装置上での実装には実用的でない。
【０１０２】
[00117]  これらの例に基づき、一部の実装形態は被選択ディメンション及びメジャー並びに対応するオブジェクトモデルに基づいて以下のステップを実行する。まずこのプロセスは、それぞれから到達可能な１組のディメンションによって視覚的仕様１０４内のメジャーを分割する（１つ又は複数の到達可能ディメンションセット２９２を作成する）。第２に、同じ１組のディメンションに到達可能なメジャーの組ごとに、このプロセスはディメンションの詳細レベルまでメジャーをロールアップする。各到達可能ディメンションセット２９２は、その対応するメジャーと共にデータフィールドセット２９４を形成する。第３にこのプロセスは、データフィールドセット内のディメンション及びメジャーに関連する視覚変数のマッピングを使用してデータフィールドセット２９４ごとに別個のデータビジュアライゼーションを作成する。このプロセスは他の全てのマッピングを無視する。
【０１０３】
[00118]  一部の実装形態は、図１４Ｂに示す状況にも対処する。その場合、独立した顧客及び企業のリストが州の中にネストされる。この事例では、共通のディメンション内に別個のビジュアライゼーションをネストするのが有用である。或る１組のメジャーの表示のマージンと共に又はその中にインタリーブされる小計又は総計として別の１組のメジャーを表示するのが有用である場合に同様のシナリオが発生する。
【０１０４】
[00119]  一部の実装形態は、上記のより容易なシナリオの１つにユーザを制限することにより、複数のビジュアライゼーションを伴うシナリオにユーザが陥るのを防ぐ。例えば一部の実装形態は、各シートについて「結合ＬＯＤ」オブジェクトを選択することを要求し、結合ＬＯＤからグラフを上がって行くことによって到達することができないディメンション及びツリーを下がって行くことによって到達することができないメジャーを無効にすることによってユーザをブレンドのシナリオに限定する。
【０１０５】
[00120]  ブレンドでは、多対一関係がどのように進むのかが常に明確ではない。ブレンドは、多対一関係が予期されるように進むとき正しく有用な結果を与える。予期される通りに進まない場合は「＊」が表示される。一部の実装形態は、本明細書のオブジェクトモデルの問題に対して同様の手法を取る。例えば独立したリストを作成する代わりに、一部の実装形態はリストの外積を表示し、メジャーを複写する。これについては以下でより詳細に論じる。
【０１０６】
[00121]  フィルタがどのように適用されるのかはドメインの問題と密に関係する。フィルタは、関係グラフの下方へ（一から多へ）確実に適用されるべきである。図５のオブジェクトモデルでは、企業に対するフィルタはオフィスにも適用されるべきである。グラフの上方へフィルタすること（例えばフィルタが英国内の全てのオフィスを除去する場合、英国もフィルタすべきか）の方が問題となる。
【０１０７】
[00122]  一部の実装形態では、各フィルタが割り当てられたＬＯＤを有し、その詳細レベルにおいて適用される。
【０１０８】
[00123]  一部の実装形態では、上記のプロセスが２つ以上の別個のデータビジュアライゼーションをもたらす場合、このプロセスは全てのコングロマリット結果セットの自然結合を行って単一のクロスされた結果テーブルを生成する。このコングロマリットは単一のテーブルであり、そのため通常のやり方でレイアウトすることができる。以下でより詳細に説明するように、これはデータブレンドの拡張形式である。この手法はデータを複写するが、複写は集計後に起こり、そのため分析的に間違う可能性は低い。
【０１０９】
[00124]  特定のフィールドがどのように計算されたのかをユーザが理解するのを助けるために、ユーザがシェルフ領域内のピルをクリックすると、一部の実装形態はそのピルから到達不能な全てのフィールド及びフィルタをグレー表示する。そのピルに関するホバーテキストは、例えば「ＳＵＭ（売上高）が州ごとに計算され、発送日によってフィルタされた（１つのディメンション及び２つのフィルタが使用されなかった）」ことを示す。
【０１１０】
[00125]  この手法は潜在的に多くのデータを複写する。かかる複写は、レンダリングパフォーマンスの問題を引き起こし得る多くのデータマークをもたらす可能性がある。しかし、複写は全ての計算が終わった後に行われ、そのためクエリ時間は影響を受けない。データの複写はユーザにとって幾らかの混乱を引き起こし得る。一部の実装形態は、ユーザのためにビジュアライゼーション内の複写データを対話式に強調表示することによってこの問題に対処する。或いは一部の実装形態は、複写されていることが分かっている場合にデータを自動でスタックするのを回避する。データを閲覧するとき、一部の実装形態は各データポイントの詳細レベルをユーザが理解するのを助けるために別個の結果セットを表示する。
【０１１１】
[00126]  一部の実装形態は、データビジュアライゼーションを構築するためにデータブレンドをオブジェクトモデルと組み合わせる。データブレンドは、ユーザが完全に異なる複数のデータソースに容易に接続し、それらの全てからのデータを使用するビジュアライゼーションを構築することを可能にするアドホックデータ統合機能である。この機能は、関連性のあるデータがTableau Server、企業データウェアハウス、スプレッドシートファイル、及びＣＳＶファイル等の様々な位置に記憶され得る場合、一般的な経営分析の質問にユーザが答えることを可能にする。
【０１１２】
[00127]  データブレンドは、一次データソースと二次データソースとの間の区別をなくす。データブレンドでは、一次データソースと二次データソースとの間にユーザが認識可能な区別はない。この対称性の１つの重要な含意は、ユーザがデータソースの「連鎖」を一緒にブレンドすることができ（例えばＣにブレンドされるＢにブレンドされるＡ）、非星型スキーマの作成を可能にすることである。
【０１１３】
[00128]  データブレンドは、一次データソースと全ての二次データソースとの間の左結合セマンティクスに限定されるのではなく、完全外部結合セマンティクスを提供する。従って、分析のドメインは一次データソース内の１組のエントリによって限定されない。データブレンドでは、デフォルトは全てのデータソースからの全てのデータを常に表示することである。ユーザは、データソース関係におけるフィルタ及び／又は設定によってこの挙動を制御することができる。加えて、関連フィールドは区別なく扱われ、元がどのデータソースなのかに関係なく全合体ドメインを常に表示する。例えば２つの別個のテーブルが州データフィールド上で結合される場合、どちらのテーブルからの州データフィールドも同じやり方で使用することができる。ユーザが入力データソースの１つにドメインを限定したい場合、ユーザはフィルタリングのシェルフ上に関連フィールドをドロップし、ドメインに寄与するデータソースの多重選択を可能にする専用のフィルタダイアログオプションを得ることができる。
【０１１４】
[00129]  データブレンドは、スキーマビューワ内のリンク状態を管理する必要性をなくす。スキーマビューワ内のリンクは、ブレンドされるデータソースが結合される詳細レベルをユーザが制御することを可能にする。データブレンドでは、外部結合セマンティクスにより、シートごとのリンクアイコンの必要性がなくなる。ユーザはデータソースの関係を依然として指定する必要があるが、指定用のＵＩが指定を容易にする。
【０１１５】
[00130]  データブレンドは、全ての計算及びデータモデリングの概念をあらゆる場所でサポートする。データブレンドにおいて一次的だと指定されるソースはないので、全ての計算が全てのデータソースに対して機能する。具体的には、ＣＯＵＮＴＤ及びＭＥＤＩＡＮ等の非加算集計が全てのデータソースに機能し、全てのデータソースからのディメンションが行レベルデータを使用してビューを分割し（ＡＴＴＲ集計は既定で使用されない）、クロスデータソース計算が行レベルデータに機能し、ディメンションとして使用されてもよく、ジオコーディングが全てのデータソースからのデータについて行われ、ビジュアライゼーション内のディメンションとして結果を使用することができ、どのデータソースから生じるのかに関係なくセット、グループ、ビン、結合されたフィールド、及びＬＯＤ式が一貫して機能する。
【０１１６】
[00131]  データブレンドは、リッチなデータソース関係を提供する。データブレンドでは、ユーザはジオコーディングの結果に基づいてブレンドすることができる（一部の実装形態ではユーザはテーブル計算を用いてブレンドすることができる）。更にユーザは、＜及び≠等のより標準的な演算子と共に空間的包含等の１組のよりリッチな関係演算子を指定することができる。
【０１１７】
[00132]  データブレンドのアドホックプロセスをデータ統合内で行われる結合と比較することは有用である。データブレンドに関係するデータ統合の少なくとも３つの部分がある。まず、データ統合セマンティクスは、典型的には結合がデータ処理パイプラインの最初に行われることを要求する。そのようにすることは、データブレンドでより上手く解決される幾つかの不所望の結果を有する。
【０１１８】
[00133]  データ統合のユーザエクスペリエンスはデータモデリングツール内で始まる。ユーザは、自らのデータソースにどのデータベーステーブルを含めるのか及びどの結合の種類を使用するのか等、自らのデータを見ることができる前に複雑な決定を下す必要がある。対照的にデータブレンドは、ユーザが自らの分析で使用する１組のテーブルを増分的に構築すること、及び必要な場合にのみ関係を定めることを可能にする。一部の実装形態は、それらのための幾らかの既定の関係も推論する。一部の実装形態では、データブレンドのこの側面は既定のエクスペリエンスである。ユーザは、例えば結合の複写挙動が実際に望ましい稀なシナリオでのみ特定の結合を定める必要がある。
【０１１９】
[00134]  集計前に結合することはデータを複写し、かかる複写は集計をしばしば間違ったものにする。この問題は、複写を取り消すためのＬＯＤ式を使用して回避できる場合がある。他方でデータブレンドでは、集計後に結合する挙動がはるかに広範な分析シナリオを解決し、より優れたデフォルトである。更に、集計後に結合を行う方が概してはるかに効率的である。
【０１２０】
[00135]  結合はユーザのデータを変更する。内部結合、左結合、及び右結合は入力データをフィルタし、ユーザのデータのドメインを変更する。左結合、右結合、及び外部結合はフィールド内にヌルを投入し、とりわけデータ内に既にヌルがある場合、これは非常に紛らわしい場合もある。パイプラインの後半に結合を遅らせることにより、及び結合の詳細をユーザにさらさないことにより、データブレンドはより優れた挙動を提供する柔軟性を既定で有する。
【０１２１】
[00136]  上記の理由から、一部の実装形態はブレンドのセマンティクスが既定であるユーザインタフェースを提供する。データソースの定義内の具体的な結合を指定することは許可されているが、それはほんの僅かなデータ統合使用事例を扱う高度なシナリオになる。
【０１２２】
[00137]  データ統合をデータブレンドと比較する第２のやり方は、データ準備ウィンドウ内の結合図ＵＩである。データブレンドの一部の実装形態は同じ基本結合図を利用する。
【０１２３】
[00138]  データ統合とデータブレンドとを比較する第３のやり方は、データフェデレーションに関する。データブレンドの一部の実装形態はデータフェデレーションを使用する。これはフェデレーションが行われる場所（例えばTableau data engine）にブレンドの計算を移動できることを意味する。
【０１２４】
[00139]  データブレンドでは、全てのデータソースが本質的に「一次」データソースのように振る舞う。この設計の重要な含意は、複数のデータソースからのディメンション間に多対多関係がある場合、データビジュアライゼーションジェネレータ２９０が複数のマークにわたってメジャーを視覚的に複写し得ることである。これは目的通りである。実際、これは正にＬＯＤ式が機能する方法である。２つのＬＯＤ式がビジュアライゼーションのＬＯＤよりも粗い集計を計算する場合、そのそれぞれがマークの全てにわたって複写される。
【０１２５】
[00140]  留意すべき１つの重要な点は、ブレンドのセマンティクスでは結合がマークの複写を生じさせる可能性があるが、集計値が依然として有意味であることである。対照的に、データ統合における結合はデータを最初に複写し、無意味な集計値及びマークの複写を往々にしてもたらす。従ってブレンドのセマンティクスが既定の挙動である。
【０１２６】
[00141]  ジオコーディングから生じる空間タイプのブレンドを可能にするために、ジオコーディングは両方のテーブルに最初に適用することができる。これは他の任意の計算上のブレンドのように扱われる。
【０１２７】
[00142]  データブレンド後に高密度化（densification）を適用する。全てのデータが両方のデータソースからプルされるので、完全外部結合セマンティクスを使用することは高密度化を最初に適用する必要性をなくす。
【０１２８】
[00143]  データブレンドを使用する場合、図１７に示すように全ての関連フィールドが、「全てを使用する」オプションを置換する「被選択データソースを使用する」オプション１７０２を有する。ここでは、関連フィールドのドメインを作成するためにどのデータソースのドメインを合体すべきかを明確に選択することができる。
【０１２９】
[00144]  関連フィールドに対する汎用フィルタは、（入力フィールドドメインのユニオンである）関連フィールドのドメインにわたり、全ての関連テーブルに対して行レベルで適用される。
【０１３０】
[00145]  関連フィールドに対する条件及び上位Ｎフィルタは、ソートの計算に使用されるフィールドを含むテーブルに対する非関連フィールドのフィルタのように扱われる。
【０１３１】
[00146]  非関連フィールドに対するフィルタは、常に行レベルでソーステーブルに適用される。
【０１３２】
[00147]  非関連フィールドに対するフィルタをソーステーブル上で計算し、次いでフィルタを通過する関連フィールドのドメインを得るために、関連フィールドのレベルまでテーブルをロールアップする。次いでこのフィルタを適用して、フィルタを通過しなかった値を除去する。重要なことに、このフィルタは関連テーブル内に存在するがソーステーブル内に存在しない値を除去するために使用されるのではない。
【０１３３】
[00148]  一部の実装形態は、データベースクエリのためのクエリツリーを生成する。高レベルにおいて、一部の実装形態は以下のパターンを使用してビジュアライゼーションのためのクエリを生成する：
・各データソースにデータソースフィルタを適用する。
・ジオコーディングを含むデータソース固有の計算を評価する。
・フィルタされるデータソースにわたる結合ツリーを作成するために、定められたブレンド関係を使用する。外部結合を使用しないとユーザが明確に指定しない場合は常に外部結合の使用を既定とする。必要に応じてクロスデータソース計算の評価をツリー内に挿入する（クロスデータソース計算を関係フィールドとして使用する場合、結合ツリーの途中で評価する必要がある）。等式によって関連付けられるフィールドは単一のフィールドへと合体する。
・ディメンションフィルタを適用する。重要なことに、「一致しない」値を明確に除外しないフィルタはそれらの値を保持すると仮定される。
・各データソースについて、データ関係フィールド及びビジュアライゼーションディメンションの別個の組み合わせをそのデータソースから選択する。結果は、そのデータソースの関係フィールド（「結合ＬＯＤ」）からビジュアライゼーションのＬＯＤにマップするテーブルである。
・このテーブルを対応するデータソースに再び結合し、「グループ化」を適用してビジュアライゼーションのＬＯＤまで結果をロールアップする。全ての集計が行レベルからビジュアライゼーションのＬＯＤまで直接ロールアップされる。
・結果として生じるテーブルの全てをビジュアライゼーションのＬＯＤの列にまとめて結合してビジュアライゼーションデータテーブルを作成する。
・メジャーフィルタとその後に続く標準クエリパイプラインの残りの部分を適用する。
【０１３４】
[00149]  ＬＯＤ式、集計条件を有するフィルタ、又は上位Ｎを有するフィルタでは、上記のツリーの一部を複製するサブクエリが生成される。
【０１３５】
[00150]  上記のパターンは任意のブレンドシナリオについてクエリツリーを構築するための全般的プロセスを規定するが、これをはるかに効率的な形式に変換する更なる最適化を適用することができる。
【０１３６】
[00151]  最適化を可能にするために、一部の実装形態は各テーブル内のデータフィールド間の関数従属性を追跡するメタデータを含む。一部の実装形態では、この情報はデータソース内の一次キー情報から又は計算済みのフィールド関係から入手することができる。抽出されるデータセットについて、一部の実装形態は抽出中にテーブルを前もって分析し、このメタデータをクエリパイプラインに提供している。
【０１３７】
[00152]  一部の実装形態は、一次キー／外部キー情報等の含有従属性も使用する。同じＳＱＬ接続からのテーブルについて、一部の実装形態はデータベースメタデータからこの情報を得る。他の事例ではユーザがこの情報を提供する。
【０１３８】
[00153]  一部の実装形態は、これらのメタデータ特性をデータビジュアライゼーション履歴ログ３３４から等、過去のクエリから知る。
【０１３９】
[00154]  一部の実装形態では、データインタプリタ内で専用のケース段階としてブレンドを行う代わりに、データブレンドがフェデレーションを使用する。データブレンドは、（幾らかの適切な最適化の拡張と共に）クエリパイプラインを使用してフェデレートされたツリーにコンパイルされるＡＱＬ（分析クエリ言語：Analytical Query Language）論理ツリーとして実装される。
【０１４０】
[00155]  一部の実装形態では、フェデレートされたツリーが最終的にTableau Data Engine内で主に実行される。空間分析シナリオを可能にするために、一部の実装形態はジオコーディングもTableau Data Engineに移す。
【０１４１】
[00156]  一部の実装形態は様々なパフォーマンスの最適化を含む。一部の実装形態では最適化が以下を含む：
・詳細レベルにわたってＭＩＮ／ＭＡＸ／ＳＵＭ／ＣＯＵＮＴを分割することであり、そのためこれらの集計は第２のパスを必要とすることなしに第１のクエリ内で要求され得る。
・含有従属性が分かっている場合、ドメインのサイズを増加しない完全外部結合を単純化し又は除去することができる。
・一部の関数従属性が分かっている場合、このプロセスは何もしないロールアップを回避することができる。
・一部の既存の最適化を一般化することができる。具体的には、フィルタプッシュダウンはパフォーマンスを改善することができる。
【０１４２】
[00157]  ブレンドの１つの仮定は、このプロセスがデータソースの行レベルデータからビュー（例えば１組のマーク）内のディメンションにマップするテーブルを作成できることである。データブレンドの一部の実装形態では、このテーブルを「結合テーブル」と呼ぶことがある。データブレンド内の全てのデータソースの一次テーブル挙動を可能にするために、このプロセスは進行中の集計を有する各データソースに対応する結合テーブルを送信する。
【０１４３】
[00158]  概念的に、結合テーブルはデータソースの関係する列からデータビジュアライゼーション内の進行中のディメンションにマップする。これは関係する列からマークインデックス（例えばディメンション値の各組み合わせの一意の整数）にマップするテーブルを代わりに作成することによって単純化することができる。そうすることでデータソースにディメンションを送信する必要がなくなる。ディメンション値は長い場合があり、複雑なクエリをもたらし得る。ディメンション値が（一般的なことである）文字列である場合、このプロセスはデータソース間でデータを移動するとき照合順序の問題に直面し得る。マークインデックスはこれらの問題を防ぐ。
【０１４４】
[00159]  関係する列からマークインデックスにマップする結合テーブルを所与とし、このプロセスは幾つかのやり方でその結合テーブルを遠隔データベースに結合することができる。関係する列がマークインデックスを関数的に決定する（最も一般的なシナリオである）場合、このプロセスはケースが多過ぎない限り結合を単純なcase式に変換することができる。関係する列がマークインデックスを関数的に決定しない場合、このプロセスはデータベースがテーブルリテラルをサポートし（例えばＳＱＬサーバ又はPostgres）、テーブル内に行が多過ぎない限り結合テーブルをテーブルリテラルに変換することができる。このプロセスは遠隔データベース上に一時的テーブルを作成し、そこでそれと結合することができる。これは一時的テーブルを作成する許可をユーザが有する場合にのみ機能する。最後に、このプロセスはTableau Data Engine内に遠隔データソースを引き込み、そこで結合を行うことができる。
【０１４５】
[00160]  図１８Ａ〜図１８Ｃは、一部の実装形態による、データビジュアライゼーションを生成する（１８０２）ためのプロセス１８００の流れ図を示す。この方法は、１つ又は複数のプロセッサ及びメモリを有する計算装置２００において実行される（１８０４）。メモリは、１つ又は複数のプロセッサによって実行されるように構成される１つ又は複数のプログラムを記憶する（１８０６）。
【０１４６】
[00161]  このプロセスは、１つ又は複数のデータソース１０６、複数の視覚変数２８２、及び１つ又は複数のデータソース１０６からの複数のデータフィールド２８４を指定する視覚的仕様１０４を受信する（１８０８）。複数の視覚変数２８２のそれぞれはデータフィールド２８４の個々の１つ又は複数に関連し（１８１０）、これらの割り当てデータフィールド２８４のそれぞれはディメンションｄ又はメジャーｍである。典型的には、視覚的仕様１０４は１つ又は複数のデータソース１０６からの如何なるデータフィールド３３０にも関連しない１つ又は複数の追加の視覚変数を含む（１８１２）。一部の実装形態では、視覚変数２８２のそれぞれが行属性、列属性、フィルタ属性、色エンコード、サイズエンコード、形状エンコード、又はラベルエンコードのうちの１つである（１８１４）。
【０１４７】
[00162]  データフィールドのメジャーｍごとに、このプロセスは、１つ又は複数のデータソースのための既定のオブジェクトモデル内の多対一関係のシーケンスによってそれぞれのメジャーｍから到達可能なデータフィールドの全てのディメンションｄで構成される、それぞれの到達可能ディメンションセットＲ（ｍ）２９２を識別する（１８１６）。シーケンスの長さは、ディメンション及びメジャーが同じクラス内にある事例を表す０とすることができる。一部の実装形態では、ディメンションｄ及びメジャーｍが既定のオブジェクトモデル内の同じクラス内にある場合、或いはメジャーｍが既定のオブジェクトモデル内の第１のクラスＣ１の属性であり、ディメンションｄはｎ≧２が成立する状態でオブジェクトモデル内のｎ番目のクラスＣｎの属性であり、既定のオブジェクトモデル内に一連のゼロ以上の中間クラスＣ２，．．．，Ｃｎ−１があり、そのためｉ＝１，２，．．．，ｎ−１ごとにクラスＣｉとクラスＣｉ＋１との間に多対一関係がある場合、ディメンションｄはメジャーｍから到達可能である（１８２０）。
【０１４８】
[00163]  別個の到達可能ディメンションセットＲ２９２ごとに、このプロセスはデータフィールドの個々のデータフィールドセットＳ２９４を形成し（１８２２）、ＳはＲ内の各ディメンション及びデータフィールドの各メジャーｍで構成され、Ｒ（ｍ）＝Ｒが成立する。
【０１４９】
[00164]  データフィールドセットＳ２９４のそれぞれについて（１８２４）、このプロセスはそれぞれのデータビジュアライゼーションを生成する。まず、個々のデータフィールドセットＳ内のメジャーｍごとに、このプロセスはそれぞれのデータフィールドセットＳ内のそれぞれのディメンションによって指定される詳細レベルまでメジャーｍの値をロールアップする（１８２６）。一部の実装形態では、それぞれのデータフィールドセットＳ内のそれぞれのディメンションによって指定される詳細レベルまでメジャーｍの値をロールアップすることが、それぞれのデータフィールドセットＳ内のそれぞれのディメンションに従ってメジャーｍを含むデータテーブルの行をグループに分割すること、及び単一の集計値をグループごとに計算することを含む（１８２８）。
【０１５０】
[00165]  典型的には、単一の集計を計算する演算子は、ＳＵＭ、ＣＯＵＮＴ、ＭＩＮ、ＭＡＸ、又はＡＶＥＲＡＧＥの１つである（１８３０）。一部の実装形態では、ＣＮＴ及びＡＶＧのキーワードがＣＯＵＮＴ及びＡＶＥＲＡＧＥの代わりに使用される。一部の実装形態は追加の集計演算子を提供する。例えば一部の実装形態はＡＴＴＲ（）集計演算子を提供する。グループごとに、ＡＴＴＲ（）演算子はグループ内の全ての値が同じかどうかを判定する。同じである場合、ＡＴＴＲ（）演算子はグループに関するその固有値を返し、さもなければそのグループに複数の値があることを示す「＊」を返す。一部の実装形態では、単一の集計演算子がＳＵＭ、ＣＯＵＮＴ、ＣＯＵＮＴＤ、ＭＩＮ、ＭＡＸ、ＡＶＧ、ＭＥＤＩＡＮ、ＡＴＴＲ、ＰＥＲＣＥＮＴＩＬＥ、ＳＴＤＥＶ、ＳＴＤＥＶＰ、ＶＡＲ、及びＶＡＲＰの１つである（１８３０）。
【０１５１】
[00166]  データフィールドセットＳ２９４ごとに（１８２４）、このプロセスはそれぞれのデータフィールドセットＳ２９４内のデータフィールドに従って、及びＳ内のデータフィールドのそれぞれが関連するそれぞれの視覚変数２８２に従ってそれぞれのデータビジュアライゼーションも構築する（１８３２）。一部の実装形態では、それぞれのデータビジュアライゼーションを構築することが、視覚的仕様１０４から生成される１つ又は複数のデータベースクエリを使用して１つ又は複数のデータソース１０６からデータのタプルを取得することを含む（１８３４）。一部の実装形態では、それらのタプルがデータフィールドセットＳ２９４内のそれぞれのディメンションに従って集計されるデータを含む（１８３６）。
【０１５２】
[00167]  一部の実装形態では、このプロセスは計算装置２００のグラフィカルユーザインタフェース１０２内にそれぞれのデータビジュアライゼーションを表示する（１８３８）。一部の実装形態では、データビジュアライゼーションを表示することが複数の視覚マークを生成することを含み、各マークは１つ又は複数のデータソースから取得されるそれぞれのタプルに対応する（１８４０）。一部の実装形態では、グラフィカルユーザインタフェース１０２がデータビジュアライゼーション領域４１２を含み、データビジュアライゼーション領域内にデータビジュアライゼーションが表示される。
【０１５３】
[00168]  本明細書の本発明の説明の中で使用した用語は特定の実装形態を説明するためのものに過ぎず、本発明を限定することは意図しない。本発明の説明及び添付の特許請求の範囲の中で使用するとき、単数形「a」、「an」、及び「the」は文脈が明らかに異なる場合を除いて複数形も含むことを意図する。本明細書で使用するとき、「and/or」という用語は列挙した関連アイテムの１つ又は複数の任意の及び全てのあり得る組み合わせを指し、かかる組み合わせを包含することも理解されよう。本明細書で使用するとき、「comprises」及び／又は「comprising」という用語は述べられた特徴、ステップ、操作、要素、及び／又は構成要素の存在を規定するが、１つ又は複数の他の特徴、ステップ、操作、要素、構成要素、及び／又はそのグループの存在又は追加を除外するものではないことが更に理解されよう。
【０１５４】
[00169]  上記の説明は特定の実装形態に関して説明目的で記載してきた。但し上記の例示的な解説は、網羅的であることも、本発明を開示した正確な形態に限定することも意図しない。上記の教示に照らして多くの修正及び改変が可能である。実装形態は、本発明の原理及びその実用的応用を最もよく説明し、それにより考えられる特定の用途に適した様々な修正と共に当業者が本発明及び様々な実装形態を最も上手く利用できるようにするために選び説明した。
【図１】
2020537251.tif 000003
【図２】
2020537251.tif 000004
【図３】
2020537251.tif 000005
【図４】
2020537251.tif 000006
【図５】
2020537251.tif 000007
【図６】
2020537251.tif 000008
【図７Ａ】
2020537251.tif 000009
【図７Ｂ】
2020537251.tif 000010
【図８】
2020537251.tif 000011
【図９Ａ】
2020537251.tif 000012
【図９Ｂ】
2020537251.tif 000013
【図９Ｃ】
2020537251.tif 000014
【図１０】
2020537251.tif 000015
【図１１】
2020537251.tif 000016
【図１２Ａ】
2020537251.tif 000017
【図１２Ｂ】
2020537251.tif 000018
【図１２Ｃ】
2020537251.tif 000019
【図１３Ａ】
2020537251.tif 000020
【図１３Ｂ】
2020537251.tif 000021
【図１３Ｃ】
2020537251.tif 000022
【図１３Ｄ】
2020537251.tif 000023
【図１４Ａ】
2020537251.tif 000024
【図１４Ｂ】
2020537251.tif 000025
【図１４Ｃ】
2020537251.tif 000026
【図１５】
2020537251.tif 000027
【図１６】
2020537251.tif 000028
【図１７】
2020537251.tif 000029
【図１８Ａ】
2020537251.tif 000030
【図１８Ｂ】
2020537251.tif 000031
【図１８Ｃ】
2020537251.tif 000032
【国際調査報告】
2020537251.tif 000033
2020537251.tif 000034