JP7304480B2 - インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード - Google Patents

インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード Download PDF

Info

Publication number
JP7304480B2
JP7304480B2 JP2022203797A JP2022203797A JP7304480B2 JP 7304480 B2 JP7304480 B2 JP 7304480B2 JP 2022203797 A JP2022203797 A JP 2022203797A JP 2022203797 A JP2022203797 A JP 2022203797A JP 7304480 B2 JP7304480 B2 JP 7304480B2
Authority
JP
Japan
Prior art keywords
data
pane
flow
user
rows
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2022203797A
Other languages
English (en)
Other versions
JP2023040041A (ja
Inventor
ピュー，ウィリアム
チェン，メンシ
キューネン，アイザック
Original Assignee
タブロー ソフトウェア，エルエルシー
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US16/155,818 external-priority patent/US10885057B2/en
Application filed by タブロー ソフトウェア，エルエルシー filed Critical タブロー ソフトウェア，エルエルシー
Publication of JP2023040041A publication Critical patent/JP2023040041A/ja
Application granted granted Critical
Publication of JP7304480B2 publication Critical patent/JP7304480B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/25—Integrating or interfacing systems involving database management systems
    • G06F16/252—Integrating or interfacing systems involving database management systems between a Database Management System and a front-end application
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/26—Visual data mining; Browsing structured data

Landscapes

  • Engineering & Computer Science (AREA)
  • Databases & Information Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • User Interface Of Digital Computer (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Description

開示された実装形態は、概してデータ視覚化に関連するものであり、より具体的には、データ視覚化アプリケーションによって使用されるデータを準備およびキュレートするためのシステム、方法、およびユーザインターフェースに関連する。
データ可視化アプリケーションは、ユーザが、ビジネス上の意思決定をするのに重要な分布、傾向、外れ値、および他の要因を含むデータセットを視覚的に理解することを可能にする。いくつかのデータセットは、非常に大きいかまたは複雑であり、多くのデータフィールドを含む。複数のデータを視覚化したダッシュボードなど、様々なツールを使用してデータを理解および分析することができる。ただし、データ視覚化アプリケーションで容易に使用できるフォーマットにするには、しばしば、データを操作または加工する必要がある。使用可能なデータソースを構築するために、様々なＥＴＬ（抽出／変換／読み込み）ツールが使用されることがある。
現在、ＥＴＬおよびデータプレパレーションの分野には２つの主要なモデルが存在する。データフロースタイルのシステムは、システムを介したデータの操作およびフローにユーザを集中させる。これにより、ジョブの全体的な構造が明確になり、ユーザがこれらのステップを容易に制御できるようになる。ただし、これらのシステムは概して、ユーザに実際のデータを表示することが不十分であり、ユーザがデータに対して何を行う必要があるのか、または何をする必要があるのかを実際に理解するのが困難になる可能性がある。これらのシステムは、ノードの爆発的な増加の影響を受ける可能性がある。各小さな操作がダイアグラム内で独自のノードを取得すると、適度に複雑なフローであっても、ノードおよびエッジのネズミの巣（ｒａｔ’ｓ ｎｅｓｔ）となり混乱を招く可能性がある。
一方、ポッターズホイール（Ｐｏｔｔｅｒ’ｓ Ｗｈｅｅｌ）スタイルのシステムは、実際のデータへの非常に具体的なスプレッドシートスタイルのインターフェースをユーザに提供し、ユーザが直接のアクションを通じてデータをスカルプトできるようにする。ユーザが実際にこれらのシステムでデータフローを作成している間、そのフローは概して遮断されており、ユーザがジョブの全体的な構造を理解して制御することが困難になる。
大規模なデータセットの場合、一部のデータプレパレーションツールでは、データの読み込みに非常に時間がかかる。例えば、同期して実行されるクエリが複数ある場合、ユーザは全てのデータが読み込まれるのを待つ必要がある。一部のシステムは、クエリを非同期で実行してデータを読み込むことにより、速度が低下したという印象を軽減しようとする。ただし、非同期読み込みでは、ユーザによるデータの操作が妨げられ、インターフェースは個別の非同期クエリの各々のデータを個別に表示するため、インターフェースに一貫性のないデータが表示される場合がある。
開示された実装形態は、複数の方法で既存のデータプレパレーションツールの問題に対処するものである。複数の非同期クエリを実行することで、データの読み込み時間が短縮され、複数のクエリからのデータが調整されるため、ユーザインターフェースには常に一貫性のあるデータが表示される。加えて、ユーザは、データの読み込み中、直ちにデータを操作して必要な変更を加えることができる。変更は、すでに表示されているデータに適用され、クエリからの新しいデータが到着すると、同じ変更がデータの新しい行にも適用される。
一部の実装形態によれば、後続の分析のためにデータを準備するためのコンピュータシステムは、１つ以上のプロセッサおよびメモリを有する。メモリは、１つ以上のプロセッサによる実行用に構成された１つ以上のプログラムを格納する。１つ以上のプログラムは、実行可能命令を含む。システムは、データフローペイン、プロファイルペイン、およびデータペインを含むユーザインターフェースを表示する。データフローペインには、データソースを識別するノード／リンクフローダイアグラムが表示される。データソースに対する複数のクエリの各々について、システムは、行数を指定する初期ブロックサイズを使用して、データソースに対して非同期にクエリを発行する。それぞれのクエリを満たすデータソースから行の初期セットが取得されると、システムは、クエリを満たす全ての行が取得されるまで、更新されたブロックサイズで非同期にクエリを繰り返す。システムは、それぞれのクエリを満たす取得された行をローカルキャッシュに格納する。定期的に（例えば、タイマーに基づいて、またはクエリのうちの１つからのクエリ結果の受信によってトリガーされて）、システムは、全てのクエリの、ローカルキャッシュに取得および保存されたデータソースの行を識別する一意の識別子を決定する。この一意の識別子は、高水準点（ｈｉｇｈ ｗａｔｅｒ ｍａｒｋ）と称されることもある。一意の識別子が変更されると、システムはプロファイルペインを更新して、データソース内の複数のデータフィールドのデータ値ヒストグラムを表示する。各データ値ヒストグラムの各バーは、（ｉ）一意の識別子によって指定され、（ｉｉ）それぞれのデータフィールドに対して単一の特定のデータ値またはデータ値の範囲を有するデータソースの行数を示す。このようにして、複数の独立したクエリが非同期で実行されている間、システムは、プロファイルペインにデータの一貫したビューを提供する。
一部の実装形態では、データソースに対するそれぞれのクエリの各繰り返しは、それぞれのクエリの過去のブロックサイズよりも大きいブロックサイズを指定する。一部の実装形態では、データソースに対するそれぞれのクエリの各繰り返しは、それぞれのクエリの過去のブロックサイズの２倍のブロックサイズを指定する。
一部の実装形態では、一意の識別子の定期的な決定は、それが１秒に１回以下発生するように調整される。
一部の実装形態では、一意の識別子が変更された場合、システムは、一意の識別子に従ってデータペインに表示されたデータソースからデータの行を更新する。
場合によっては、フローダイアグラムの第１のノードが最初に選択され、プロファイルペインに表示されるデータ値のヒストグラムは、第１のノードの計算されたデータセットに対応する。場合によっては、ユーザは、非同期クエリの実行中に、フローダイアグラムの第２のノードを選択する。ユーザ選択に応じて、システムは、プロファイルペインを更新して、第２のノードの結果セットからの複数のデータフィールドの新しいデータ値ヒストグラムを表示する。各データ値ヒストグラムの各バーは、それぞれのデータフィールドに対して単一の特定のデータ値またはデータ値の範囲を有する結果セットの行数を示す。
一部の実装形態では、一意の識別子は、データソースの主キーフィールドの主キー値であり、データソースの行は、行に対応するキー値が主キー値よりも小さい場合に、一意の識別子によって指定される。一部の実装形態では、一意の識別子は、高水準の行番号であり、データソースの行は、その行に対応する行番号が高水準の行番号以下である場合に、一意の識別子によって指定される。一部の実装形態では、クエリの各々のソート順序は同じである。
場合によっては、１つ以上の非同期クエリの実行中に、ユーザは、プロファイルペインに表示されるデータを変更する。ユーザ入力に応答して、システムはユーザ入力をデータソースから取得された行に適用される操作に変換し、操作の定義を保存する。一意の識別子が変更された場合、プロファイルペインを更新することは、クエリによって取得された行に定義された操作を適用することを含む。
ユーザは、プロファイルペインでデータに様々な変更を加えることができる。場合によっては、ユーザ入力は、最初のデータフィールドの最初のデータ値ビンに対応するデータ値ヒストグラムの単一のバーの選択であり、これにより、プロファイルペインに表示されるデータを、最初のフィールドのデータ値が最初のデータ値ビンに対応するデータソースの行にフィルタ処理する。保存された操作により、プロファイルペインに表示されたデータは、最初のフィールドのデータ値が最初のデータ値ビンに対応するデータソースの行にフィルタ処理するフィルタに適用される。
場合によっては、ユーザ入力により、最初のデータフィールドに対応するデータ値ヒストグラムがプロファイルペインから削除される。一意の識別子が変更された場合にプロファイルペインを更新することは、データペインから最初のデータフィールドを省略することを含む。
場合によっては、ユーザ入力により、クエリによって取得された１つ以上の他の列の関数として計算された、対応するデータ値ヒストグラムを備えた計算列がプロファイルペインに追加される。一意の識別子が変更された場合にプロファイルペインを更新することは、関数およびデータソースから取得された追加の行に従って計算列のデータ値ヒストグラムを更新することを含む。
場合によっては、ユーザ入力により、プロファイルペインの最初のデータ列の名前が新しい名前に変更される。一意の識別子が変更された場合にプロファイルペインを更新することは、最初のデータ列の新しい名前を保持することを含む。
場合によっては、ユーザ入力により、変換関数に従って、プロファイルペインの最初のデータ列のデータ型が新しいデータ型に変換される。一意の識別子が変更された場合にプロファイルペインを更新することは、データソースから取得した追加の行の最初のデータ列に変換関数を適用することを含む。
場合によっては、ユーザ入力により、プロファイルペインの最初のデータ列のビンに対応するヒストグラムバーが削除される。一意の識別子が変更された場合にプロファイルペインを更新することは、行がビンに一致する最初のデータ列のデータ値を有する場合、取得した追加の行を削除することを含む。一部の実装形態では、各ビンは、個々のデータ値またはデータ値の連続範囲に対応する。
一部の実装形態によれば、プロセスはフローダイアグラムをリファクタリングする。プロセスは、ディスプレイ、１つ以上のプロセッサ、および１つ以上のプロセッサによって実行されるように構成された１つ以上のプログラムを格納するメモリを有するコンピュータシステムにおいて実行される。プロセスは、データフローペインおよびパレットペインを含む複数のペインを含むユーザインターフェースを表示することを含む。データフローペインは、複数の既存のノードを有するフローダイアグラムを含み、各ノードは、それぞれのデータソースからデータを取得するためのそれぞれの操作を指定するか、データを変換するためのそれぞれの操作を指定するか、またはそれぞれの出力データセットを作成するためのそれぞれの操作を指定する。また、パレットペインは、複数のフロー要素テンプレートを含む。プロセスは、第１のユーザ入力を受信して、フローダイアグラムから既存のノードを選択するか、またはパレットペインからフロー要素テンプレートを選択することと、第１のユーザ入力に応答して、（ｉ）配置のための新しいノードを表す移動可能なアイコンを表示することであって、フローダイアグラムにおいて、新しいノードが、選択された既存のノードまたは選択されたフロー要素テンプレートに対応するデータフロー操作を指定する、表示すること、および（ｉｉ）新しいノードのデータフロー操作と複数の既存ノードの操作との間の依存関係に従って、フローダイアグラムに１つ以上のドロップターゲットを表示することと、をさらに含む。プロセスは、移動可能なアイコンをドロップターゲットの第１のドロップターゲット上に配置するための第２のユーザ入力を受信し、第２のユーザ入力の検出を停止することをさらに含む。第２のユーザ入力の検出を停止したことに応答して、プロセスは新しいノードを最初のドロップターゲットのフローダイアグラムに挿入する。新しいノードは、指定されたデータフロー操作を実行する。
一部の実装形態によれば、既存のノードの各々は、指定されたそれぞれの操作に従って計算されたそれぞれの中間データセットを有し、最初のドロップターゲットでフローダイアグラムに新しいノードを挿入することは、指定されたデータフロー操作に従って新しいノードの中間データセットを計算することを含む。
一部の実装形態によれば、新しいノードは、第１の中間データセットを有する第１の既存ノードの後にフローダイアグラムに配置され、新しいノードの中間データセットの計算は、データフロー操作を第１の中間データセットに適用することを含む。
一部の実装形態によれば、新しいノードは、フローダイアグラムに先行ノードを有さず、新しいノードの中間データセットの計算には、データソースからデータを取得して中間データセットを形成することが含まれる。
一部の実装形態によれば、プロセスは、第２のユーザ入力の検出を停止することに応答して、ユーザインターフェースのデータペインに中間データセットからのデータのサンプリングを表示することをさらに含む。データペインは、複数のペインのうちの１つである。
一部の実装形態によれば、データフロー操作は、第１のデータフィールドの値に基づいてデータの行をフィルタ処理し、１つ以上のドロップターゲットを表示することは、中間データセットが第１のデータフィールドを含む既存のノードの直後に１つ以上のドロップターゲットを表示することを含む。
一部の実装形態によれば、第１のユーザ入力により、フローダイアグラムから既存のノードが選択され、最初のドロップターゲットでフローダイアグラムに新しいノードを挿入すると、既存のノードのコピーが作成される。
一部の実装形態によれば、最初のドロップターゲットでフローダイアグラムに新しいノードを挿入することは、フローダイアグラムから既存のノードを削除することをさらに含む。
一部の実装形態によれば、データフロー操作は、指定された順序で実行される複数の操作を含む。
一部の実装形態では、非一時的コンピュータ可読記憶媒体は、１つ以上のプロセッサ、メモリ、およびディスプレイを有するコンピュータシステムによって実行するように構成された１つ以上のプログラムを格納する。１つ以上のプログラムは、本明細書で説明されるようにフローダイアグラムをリファクタリングするシステムを実装するための命令を含む。
一部の実装形態によれば、コンピュータシステムは、分析のためにデータを準備する。コンピュータシステムは、１つ以上のプロセッサ、メモリ、およびメモリに格納された１つ以上のプログラムを含む。プログラムは、１つ以上のプロセッサによって実行されるように構成される。プログラムは、データプレパレーションアプリケーションのユーザインターフェースを表示する。ユーザインターフェースには、データフローペイン、ツールペイン、プロファイルペイン、およびデータペインが含まれる。データフローペインには、データソース、操作、および出力データセットを識別するノード／リンクフローダイアグラムが表示される。ツールペインには、ユーザがフローダイアグラムにデータソースを追加できるようにするデータソースセレクタが含まれ、ユーザが特定の変換操作を実行するためにフローダイアグラムにノードを挿入できるようにする操作パレットと、ユーザがフローダイアグラムに組み込むことができる他のフローダイアグラムのパレットとが含まれている。プロファイルペインには、データフィールドに関する情報およびデータフィールドのデータ値に関する統計情報など、フローダイアグラムで選択したノードに対応するスキーマが表示され、ユーザは、個々のデータ要素を操作してフローダイアグラムを変更できる。データペインには、フローダイアグラムで選択したノードに対応するデータの行が表示され、ユーザは、個々のデータ値を操作してフローダイアグラムを変更できる。
一部の実装形態では、プロファイルペインに表示されるデータフィールドに関する情報には、最初のデータフィールドのデータ範囲が含まれる。
一部の実装形態では、プロファイルペインの最初のデータフィールドの最初のデータ範囲に対する最初のユーザアクションに応答して、データを最初のデータ範囲にフィルタ処理する新しいノードがフローダイアグラムに追加される。
一部の実装形態では、プロファイルペインを使用すると、ユーザは、最初のデータフィールドのデータ範囲を指定された値にマッピングすることができる。これにより、ユーザ指定のマッピングを実行するフローダイアグラムに新しいノードが追加される。
一部の実装形態では、データペイン内の最初のデータ値との最初のユーザインタラクションに応答して、データを最初のデータ値にフィルタ処理するノードがフローダイアグラムに追加される。
一部の実装形態では、ユーザがデータペインの最初のデータフィールドの最初のデータ値を変更したことに応じて、最初のデータフィールドのデータ値が最初のデータ値と等しいデータの各行に変更を実行する新しいノードがフローダイアグラムに追加される。
一部の実装形態では、データペインの最初のデータフィールドに対する最初のユーザアクションに応答して、最初のデータフィールドを２つ以上の別個のデータフィールドに分割するノードがフローダイアグラムに追加される。
一部の実装形態では、データフローペインで第１のノードをツールペインにドラッグする最初のユーザアクションに応答して、新しい操作が操作パレットに追加される。新しい操作は第１のノードに対応する。
一部の実装形態では、プロファイルペインおよびデータペインは、データフローペインで選択が行われると非同期に更新されるように構成されている。
一部の実装形態では、プロファイルペインに表示されるデータフィールドに関する情報には、データフィールドのデータ値の分布を表示する１つ以上のヒストグラムが含まれる。
一部の実装形態によれば、方法は、ディスプレイを備えた電子デバイスで実行される。例えば、電子デバイスは、スマートフォン、タブレット、ノートブックコンピュータ、またはデスクトップコンピュータであり得る。本方法は、本明細書に記載のコンピュータシステムのいずれかを実装する。
一部の実装形態では、非一時的コンピュータ可読記憶媒体は、１つ以上のプロセッサ、メモリ、およびディスプレイを有するコンピュータシステムによって実行するように構成された１つ以上のプログラムを格納する。１つ以上のプログラムは、本明細書に記載されるように分析のためにデータを準備するシステムを実装するための命令を含む。
このように、ユーザがデータを分析、準備、およびキュレートすること、ならびに既存のデータフローをリファクタリングすることを可能にする方法、システム、およびグラフィカルユーザインターフェースが開示される。
前述のシステム、メソッド、およびグラフィカルユーザインターフェース、ならびにデータ視覚化分析およびデータプレパレーションを提供する追加のシステム、方法、ならびにグラフィカルユーザインターフェースをよりよく理解するために、以下の図面と併せて、以下の実装形態の説明を参照する必要がある。これらの図面では、同様の参照番号が図全体の対応する部分を参照している。
一部の実装形態で使用されるグラフィカルユーザインターフェースを示す。 一部の実装形態による、コンピューティングデバイスのブロック図である。 一部の実装形態よる、データプレパレーションアプリケーションのユーザインターフェースを示す。 図３Ａおよび図３Ｂに示すユーザインターフェースの一部の機能を説明する。 一部の実装形態による、サンプルフローダイアグラムを示す。 一部の実装形態による、一緒に機能するが異なる頻度で実行される一対のフローを示す。 一部の実装形態による、データプレパレーションアプリケーションを使用して結合を構築することを説明する。 一部の実装形態による、ログファイルの一部を示す。 一部の実装形態による、ルックアップテーブルの一部を示す。 一部の実装形態による、フローの一部の操作、入力、および出力を示す。 一部の実装形態による、データプレパレーションシステムの一部のコンポーネントを示す。 一部の実装形態による、分析または実行のいずれかのためにフローを評価することを示す。 一部のデータプレパレーションの実装形態で使用される非同期サブシステムを概略的に表す。 一部の実装形態による、一連のフロー操作を示す。 一部の実装形態による、型システムの３つの態様を示す。 一部の実装形態による、型環境のプロパティを示す。 一部の実装形態による、既知の全てのデータ型のフローに基づく単純な型チェックを示す。 一部の実装形態による、完全に既知の型による単純な型の失敗を示す。 一部の実装形態による、部分フローの単純な型環境計算を示す。 一部の実装形態による、パッケージ化されたコンテナノードの型を示す。 一部の実装形態による、より複雑な型環境シナリオを示す。 一部の実装形態による、より複雑な型環境シナリオを再利用する方法を示す。 一部の実装形態による、最も一般的に使用される多くの演算子のプロパティを示す。 一部の実装形態による、フローおよび対応する実行プロセスを示す。 一部の実装形態に従って、フロー全体の実行が、入力ノードおよび出力ノードでの暗黙の物理モデルから開始することを示す。 一部の実装形態に従って、部分フローを実行すると、結果とともに物理モデルが具現化されることを示す。 一部の実装形態に従って、過去の結果に基づいてフローの一部を実行することを示す。 一部の実装形態に従って、固定されたノード８６０を用いてフローを評価することを示す。 一部の実装形態による、フローダイアグラムの一部を示す。 一部の実装形態による、複数の非同期クエリから取得された結果セットの高水準点を確立するプロセスを示す。 一部の実装形態に従って、データがデータソースから読み込まれている間にデータプレパレーションユーザインターフェースがどのように更新されるかを示す。 一部の実装形態による、データプレパレーションユーザインターフェースで部分的に読み込まれたデータとのユーザインタラクションと、追加データが非同期で到着したときのユーザインターフェースへの後続の更新とを示す。 一部の実装形態による、データプレパレーションユーザインターフェースのプロファイルペインの例である。
ここで、実装形態を参照すると、その例は、添付の図面に示されている。以下の説明では、本発明の徹底した理解を提供するために、数多くの特定の詳細が記載される。しかしながら、本発明がこれらの特定の詳細を必要とせずに実施され得ることは当業者には明らかであろう。
図１は、インタラクティブなデータ分析のためのグラフィカルユーザインターフェース１００を示している。ユーザインターフェース１００は、一部の実装形態によれば、データタブ１１４および分析タブ１１６を含む。データタブ１１４が選択されると、ユーザインターフェース１００は、データペインとも称されるスキーマ情報領域１１０を表示する。スキーマ情報領域１１０は、データ可視化を構築するために選択および使用され得るデータフィールドを提供する。一部の実装形態では、フィールド名のリストは、ディメンションのグループ（カテゴリデータなど）とメジャーのグループ（数値など）とに分けられる。一部の実装形態には、パラメータのリストも含まれている。分析タブ１１６が選択されると、ユーザインターフェースは、データ要素（図示せず）の代わりに分析機能のリストを表示する。
グラフィカルユーザインターフェース１００はまた、データ視覚化領域１１２を含む。データ視覚化領域１１２は、列棚領域１２０および行棚領域１２２などの複数の棚領域を含む。これらは、列棚１２０および行棚１２２とも称される。ここに示すように、データ視覚化領域１１２はまた、視覚的グラフィックを表示するための大きなスペースを有する。データ要素がまだ選択されていないため、最初は、スペースに視覚的なグラフィックがない。一部の実装形態では、データ視覚化領域１１２は、シートと称される複数の層を有する。
図２は、一部の実装形態によるグラフィカルユーザインターフェース１００を表示し得るコンピューティングデバイス２００を示すブロック図である。コンピューティングデバイスは、データプレパレーション（「データプレップ」）アプリケーション２５０によっても使用することができる。コンピューティングデバイス２００の様々な例としては、デスクトップコンピュータ、ラップトップコンピュータ、タブレットコンピュータ、およびデータ可視化アプリケーション２２２を実行することができるディスプレイおよびプロセッサを有する他のコンピューティングデバイスが挙げられる。コンピューティングデバイス２００は、典型的には、メモリ２１４に格納されたモジュール、プログラム、および／または命令を実行し、それによって処理動作を実行するための１つ以上の処理ユニット／コア（ＣＰＵ）２０２と、１つ以上のネットワークまたは他の通信インターフェース２０４と、メモリ２１４と、これらのコンポーネントを相互接続するための１つ以上の通信バス２１２と、を含む。通信バス２１２は、システムコンポーネント間の通信を相互接続および制御する回路網を含み得る。
コンピューティングデバイス２００は、ディスプレイデバイス２０８および１つ以上の入力デバイスまたは機構２１０を備えるユーザインターフェース２０６を含む。一部の実装形態では、入力デバイス／機構はキーボードを含む。一部の実装形態では、入力デバイス／機構は、ディスプレイデバイス２０８に必要に応じて表示される「ソフト」キーボードを含み、ユーザがディスプレイ２０８に表示される「キーを押す」ことを可能にする。一部の実装形態では、ディスプレイ２０８および入力デバイス／機構２１０は、タッチスクリーンディスプレイ（タッチセンシティブディスプレイとも称される）を含む。
一部の実装形態では、メモリ２１４は、ＤＲＡＭ、ＳＲＡＭ、ＤＤＲ ＲＡＭ、または他のランダムアクセス固体メモリデバイスなどの高速ランダムアクセスメモリを含む。一部の実装形態では、メモリ２１４は、１つ以上の磁気ディスク記憶デバイス、光ディスク記憶デバイス、フラッシュメモリデバイス、または他の不揮発性固体記憶デバイスなどの不揮発性メモリを含む。一部の実装形態では、メモリ２１４は、ＣＰＵ（複数可）２０２から遠隔に位置する１つ以上の記憶デバイスを含む。メモリ２１４、または代替的にメモリ２１４内の不揮発性メモリデバイス（複数可）は、非一時的コンピュータ可読記憶媒体を含む。一部の実装形態では、メモリ２１４、またはメモリ２１４のコンピュータ可読記憶媒体は、以下のプログラム、モジュール、およびデータ構造、またはそれらのサブセットを格納する。
●様々な基本的なシステムサービスを処理し、ハードウェアに依存するタスクを実行するための手順を含むオペレーティングシステム２１６。
●１つ以上の通信ネットワークインターフェース２０４（有線または無線）およびインターネット、他の広域ネットワーク、ローカルエリアネットワーク、メトロポリタンエリアネットワークなど、１つ以上の通信ネットワークを介してコンピューティングデバイス２００を他のコンピュータおよびデバイスに接続するために使用される通信モジュール２１８。
●ユーザがネットワークを介して遠隔のコンピュータまたはデバイスと通信することを可能にするブラウザ（またはウェブページを表示することができる他のアプリケーション）２２０。
●ユーザが視覚的グラフィックスを構築するためのグラフィカルユーザインターフェース１００を提供するデータ視覚化アプリケーション２２２。例えば、ユーザは、１つ以上のデータソース２４０（コンピューティングデバイス２００に格納され得るか、またはリモートに格納され得る）を選択し、データソース（複数可）からデータフィールドを選択し、選択されたフィールドを使用して視覚的グラフィックを定義する。一部の実装形態では、ユーザが提供する情報は、視覚的仕様２２８として格納される。データ視覚化アプリケーション２２２は、データ視覚化生成モジュール２２６を含み、これは、ユーザ入力（例えば、視覚的仕様２２８）を受信し、対応する視覚的グラフィック（「データ視覚化」または「データビズ」とも称される）を生成する。次に、データ可視化アプリケーション２２２は、生成された視覚的グラフィックをユーザインターフェース１００に表示する。一部の実装形態では、データ可視化アプリケーション２２２は、スタンドアロンアプリケーション（例えば、デスクトップアプリケーション）として実行される。一部の実装形態では、データ可視化アプリケーション２２２は、ウェブブラウザ２２０またはウェブサーバによって提供されるウェブページを使用する別のアプリケーション内で、以下を実行する。
●データ可視化アプリケーション２２２によって使用される、ゼロ個以上のデータベースまたはデータソース２４０（例えば、第１のデータソース２４０－１および第２のデータソース２４０－２）。一部の実装形態では、データソースは、スプレッドシートファイル、ＣＳＶファイル、ＸＭＬファイル、もしくはフラットファイルとして格納されるか、またはリレーショナルデータベースに格納される。
場合によっては、コンピューティングデバイス２００は、データプレップアプリケーション２５０を格納し、これを使用して、データを分析し、（例えば、データ視覚化アプリケーション２２２によって）後続の分析のために加工することができる。図３Ｂは、データプレップアプリケーション２５０によって使用されるユーザインターフェース２５１の一例を示している。以下でより詳細に説明されるように、データプレップアプリケーション２５０により、ユーザがフロー３２３を構築することが可能となる。
上述の識別された実行可能モジュール、アプリケーション、または手順のセットの各々は、１つ以上のメモリデバイスに格納され得、かつ上述の機能を実行するための命令のセットに対応する。上述の識別されたモジュールまたはプログラム（すなわち、命令のセット）は、別個のソフトウェアプログラム、手順、またはモジュールとして実装される必要はなく、したがって、これらのモジュールの様々なサブセットは、様々な実装形態において組み合わされるか、または別様に再配置され得る。一部の実装形態では、メモリ２１４は、上述の識別されたモジュールおよびデータ構造のサブセットを格納する。さらに、メモリ２１４は、上述されていない追加のモジュールまたはデータ構造を格納し得る。
図２は、コンピューティングデバイス２００を示しているが、図２は、本明細書で説明されている実装形態の構造的概略としてではなく、存在し得る様々な特徴の機能的説明としてより意図されている。実際には、当業者によって認識されるように、別々に示されたアイテムを組み合わせることができ、いくつかのアイテムを分離することができる。
図３Ａおよび図３Ｂは、一部の実装形態によるデータを準備するためのユーザインターフェースを示している。これらの実装形態には、異なる機能を有する少なくとも５つの領域がある。図３Ａは、これを、メニューバー領域３０１、左側ペイン３０２、フローペイン３０３、プロファイルペイン３０４、およびデータペイン３０５として概念的に示している。一部の実装形態では、プロファイルペイン３０４は、スキーマペインとも称される。一部の実装形態では、「左側ペイン」３０２の機能は、メニューペイン３０１の下またはデータペイン３０５の下などの代替の場所に位置している。
このインターフェースは、ユーザが何をする必要があるかを見て理解することができるように、複数の合理化された調整されたビューをユーザに提供する。この斬新なユーザインターフェースは、ユーザにフローおよびデータの複数のビューを提供し、ユーザがアクションを実行するだけでなく、実行する必要のあるアクションを発見するのにも役立つ。フローペイン３０３のフローダイアグラムは、アクションを組み合わせて要約し、フローをより読みやすくするものであり、プロファイルペイン３０４およびデータペイン３０５の実際のデータのビューとともに調整される。データペイン３０５は、論理フローの全てのポイントでのデータの代表的なサンプルを提供し、プロファイルペインは、データのドメインのヒストグラムを提供する。
一部の実装形態では、メニューバー３０１は、ファイルメニューを有し、ファイルメニューは、新しいデータフロー仕様を作成し、データフロー仕様を保存し、過去に作成されたデータフロー仕様を読み込むためのオプションを備える。場合によっては、フロー仕様はフローと称される。フロー仕様により、１つ以上のデータソースからの入力データを操作してターゲットデータセットを作成する方法が説明される。ターゲットデータセットは典型的に、データ視覚化アプリケーションを使用した後続のデータ分析で使用される。
一部の実装形態では、左側ペイン３０２は、直近のデータソース接続のリストと、新しいデータソースに接続するためのボタンとを含む。
一部の実装形態では、フローペイン３０３は、フロー仕様の視覚的表現（フローダイアグラムまたはフロー）を含む。一部の実装形態では、フローは、データソース、実行される操作、およびフローのターゲット出力を示すノード／リンクダイアグラムである。
一部の実装形態では、フローの一部を宣言型クエリとして扱うことにより、フローを柔軟に実行できる。つまり、ユーザに全ての計算の詳細を指定させるのではなく、ユーザが目的（入力および出力など）を指定する。フローを実行するプロセスは、プランを最適化して、パフォーマンスを向上させる実行ストラテジを選択する。実装形態により、ユーザはこの動作を選択的に禁止して実行を制御することもできる。
一部の実装形態では、プロファイルペイン３０４は、フローペイン３０３で選択されたノードのスキーマおよび関連する統計および／または視覚化を表示する。一部の実装形態は、同時に複数のノードの選択をサポートするが、他の実装形態は一度に１つのノードのみの選択をサポートする。
一部の実装形態では、データペイン３０５は、フローペイン３０３で選択されたノードの行レベルのデータを表示する。
一部の実装形態では、ユーザはメニューバーの［ファイル］－＞［新しいフロー］オプションを使用して新しいフローを作成する。ユーザは、データソースをフローに追加することもできる。場合によっては、データソースはリレーショナルデータベースである。場合によっては、１つ以上のデータソースは、ＣＳＶファイルまたはスプレッドシートファイルなどのファイルベースである。一部の実装形態では、ユーザは、左側ペイン３０２のファイル接続アフォーダンスを使用して、ファイルベースのソースをフローに追加する。これにより、ユーザにファイルの選択を求めるファイルダイアログが開く。一部の実装形態では、左側ペイン３０２はまた、データベース接続アフォーダンスを含み、これは、ユーザがデータベース（例えば、ＳＱＬデータベース）に接続することを可能にする。
ユーザがフローペイン３０３でノード（例えば、テーブル）を選択すると、ノードのスキーマがプロファイルペイン３０４に表示される。一部の実装形態では、プロファイルペイン３０４は、（例えば、ヒストグラムまたは円グラフとして）フィールドのデータ値の分布などの統計または視覚化を含む。フローペイン３０３で複数のノードの選択を可能にする実装形態において、選択されたノードの各々のスキーマがプロファイルペイン３０４に表示される。
また、フローペイン３０３でノードを選択すると、そのノードのデータがデータペイン３０５に表示される。データペイン３０５は、典型的に、行および列としてデータを表示する。
実装形態により、フローペイン３０３、プロファイルペイン３０４、またはデータペイン３０５を使用してフローを容易に編集することができる。例えば、一部の実装形態では、これら３つのペインのいずれかでノード／テーブルの右クリック操作を有効にし、そのテーブルの既存の列に対するスカラー計算に基づいて新しい列を追加する。例えば、スカラー演算は、３つの数値列の合計を計算する数学演算、文字列である２つの列からの文字列データを連結する文字列演算、または（日付がデータソースで文字列として符号化されている場合）文字列の列を日付列に変換する変換演算であり得る。一部の実装形態では、右クリックメニュー（フローペイン３０３、プロファイルペイン３０４、またはデータペイン３０５のテーブル／ノードからアクセス）に「計算フィールドの作成…」というオプションが提供される。このオプションを選択すると、計算を作成するためのダイアログが表示される。一部の実装形態では、計算は、（例えば、集計、カスタム詳細レベル計算、およびテーブル計算を除いて）スカラー計算に制限される。新しい列が作成されると、ユーザインターフェースは、フローペイン３０３に計算されたノードを追加し、新しいノードをその先行するノードに接続して、この新しいノードを選択する。一部の実装形態では、フローダイアグラムのノードの数が大きくなると、フローペイン３０３にはスクロールボックスが追加される。一部の実装形態では、フローダイアグラムのノードをグループ化してラベルを付けることができる。これは階層的に表示される（例えば、最初に高レベルのフローを表示し、ドリルダウンして選択したノードの詳細を表示する）。
ユーザは、フローペイン３０３、プロファイルペイン３０４、またはデータペイン３０５を操作して（例えば、列を右クリックして［列の削除］オプションを選択することによって）列を削除することもできる。列を削除すると、フローペイン３０３にノードが追加され、新しいノードが適切に接続され、新しいノードが選択される。
フローペイン３０３で、ユーザは、ノードを選択し、「名前を付けて出力」を選択して、新しい出力データセットを作成することができる。一部の実装形態では、これは右クリックで実行される。これにより、ユーザがターゲットファイル名およびディレクトリ（またはデータベースおよびテーブル名）を選択できるファイルダイアログが表示される。これを行うと、フローペイン３０３に新しいノードが追加されるが、実際にはターゲットデータセットは作成されない。一部の実装形態では、ターゲットデータセットには、データを含む最初のファイル（タブローデータ抽出（Ｔａｂｌｅａｕ Ｄａｔａ Ｅｘｔｒａｃｔ）またはＴＤＥ）と、データファイルを指す対応するインデックスまたはポインタエントリ（タブローデータソース（Ｔａｂｌｅａｕ Ｄａｔａ Ｓｏｕｒｃｅ）またはＴＤＳ）とを含む２つのコンポーネントがある。
実際の出力データファイルは、フローの実行時に作成される。一部の実装形態では、ユーザは、メニューバー３０１から「ファイル－＞フローの実行」を選択してフローを実行する。１つのフローで複数の出力データファイルを生成できることに留意されたい。一部の実装形態では、フローダイアグラムにより、実行時に視覚的なフィードバックが提供される。
一部の実装形態では、メニューバー３０１には、「ファイル」メニューに「保存」または「名前を付けて保存」するオプションが含まれ、これにより、ユーザは、フローを保存することができる。一部の実装形態では、フローは「．ｌｏｏｍ」ファイルとして保存される。このファイルには、読み込み時にフローを再作成するために必要な全てのものが含まれている。フローが保存されると、後で「ファイル」メニューの「読み込み」メニューオプションを使用してリロードできる。これにより、ファイルピッカーダイアログが表示され、ユーザは過去のフローを読み込むことができる。
図３Ｂは、データプレパレーション用のユーザインターフェースを示すものであり、ペインの各々のユーザインターフェース要素を示している。メニューバー３１１には、ファイルメニューおよび編集メニューなどの１つ以上のメニューが含まれる。編集メニューが利用可能となっているが、フローペイン３１３、プロファイルペイン３１４、またはデータペイン３１５とインタラクションを有することによって、フローへのさらなる変更が実行される。
一部の実装形態では、左側ペイン３１２には、データソースパレット／セレクタが含まれ、これには、データを発見して接続するためのアフォーダンスが含まれる。コネクタのセットには、キューブを含む抽出専用コネクタが含まれている。実装形態は、カスタムＳＱＬ式を、それをサポートする任意のデータソースに発行できる。
左側ペイン３１２はまた、フローに配置され得る操作を表示する操作パレットを含む。これには、任意の結合（任意の型の結合および様々な述語を用いた結合）、ユニオン、ピボット、列の名前変更および制限、スカラー計算の射影、フィルタ、集計、データ型変換、データ解析、合体、マージ、分割、集計、値の置換、ならびにサンプリングが含まれる。一部の実装形態では、セットの作成（例えば、データフィールドのデータ値をセットに分割する）、ビニング（例えば、データフィールドの数値データ値を範囲のセットにグループ化する）、およびテーブル計算（例えば、行のデータ値だけでなく、テーブル内の他のデータ値にも依存する各行のデータ値（例えば、全体の割合）を計算する）を行う演算子もサポートしている。
左側ペイン３１２はまた、全体的または部分的に現在のフローに組み込み得る他のフローのパレットを含む。これにより、ユーザは、フローのコンポーネントを再利用して新しいフローを作成することができる。例えば、１０個のステップの組み合わせを使用して特定の型の入力をスクラブするフローの一部が作成された場合、その１０個のステップのフロー部分を保存して、同じフローまたは完全に別のフローで再利用することができる。
フローペイン３１３には、現在のフローの視覚的表現（例えば、ノード／リンクフローダイアグラム）３２３が表示される。フローペイン３１３により、プロセスのドキュメント化に役立つフローの概要が提供される。既存の製品では、フローが非常に複雑であるため、理解が妨げられるものが多い。開示された実装形態は、ノードを合体させることで理解を促進し、全体的なフローをより単純かつ簡潔に保つ。上記のように、ノードの数が増えると、実装形態は典型的に、スクロールボックスを追加する。スクロールバーの必要性は、コンテナノードとも称されるスーパーノードに複数の関連ノードを合体させることによって削減される。これにより、ユーザは、フロー全体をより概念的に見ることができ、必要な場合にのみ詳細を掘り下げることができる。一部の実装形態では、「スーパーノード」が展開されると、フローペイン３１３は、スーパーノード内のノードのみを示し、フローペイン３１３は、見出しを有し、この見出しにより、フローのどの部分が表示されているかが識別される。実装形態は典型的に、複数の階層レベルを有効にする。複雑なフローには、複数のレベルのノードのネストが含まれる可能性がある。
上記のように、プロファイルペイン３１４は、フローペイン３１３において現在選択されている単一のノード（または複数のノード）のデータに関するスキーマ情報を含む。ここに示されているように、スキーマ情報は、フィールドの各々のデータ分布のヒストグラム３２４など、データに関する統計情報を提供する。ユーザは、プロファイルペインと直接対話して、（例えば、そのデータフィールドの値に基づいてデータの行をフィルタ処理するためのデータフィールドを選択することによって）フロー３２３を変更することができる。プロファイルペイン３１４はまた、現在選択されている単一のノード（または複数のノード）に関する関連データ、およびユーザの作業を導く視覚化をユーザに提供する。例えば、ヒストグラム３２４は、各列のドメインの分布を示している。一部の実装形態では、ブラッシングを使用して、これらのドメインが互いにどのようにインタラクションを有するかを示す。
ここでの例は、ユーザがフロー内のデータを直接操作し得るようにすることで、プロセスが典型的な実装形態とどのように異なるかを示している。データの特定の行をフィルタ処理する２つの代替方法を検討する。この場合、ユーザはカリフォルニア州を検討対象から除外したいと考えている。一般的なツールを使用して、ユーザは、「フィルタ」ノードを選択し、フィルタをフローの特定の場所に配置してから、ダイアログボックスを表示し、「ｓｔａｔｅ＿ｎａｍｅ＜＞’ＣＡ’」などの計算式を入力する。ここに開示された実装形態では、ユーザは、プロファイルペイン３１４（例えば、フィールド値「ＣＡ」およびそのフィールド値を有する行数を示す）およびデータペイン３１５（例えば、ｓｔａｔｅ＿ｎａｍｅの値として「ＣＡ」を有する個々の行）においてデータ値を見ることができる。一部の実装形態では、ユーザは、プロファイルペイン３１４（またはデータペイン３１５）の州の名称のリストで［ＣＡ］を右クリックし、ドロップダウンから［除外］を選択できる。ユーザは、データと対話するフロー要素ではなく、データ自体と対話する。実装形態により、計算、結合、ユニオン、集計などに同様の機能が提供される。このアプローチの別の利点は、結果が直ちに得られることである。「ＣＡ」がフィルタ処理により除外されると、フィルタは直ちに適用される。操作の完了に時間がかかる場合、操作は非同期で実行され、ユーザは、ジョブがバックグラウンドで実行されている間も作業を続行することができる。
データペイン３１５は、フローペイン３１３において選択されたノード（複数可）に対応するデータの行を表示する。列３１５の各々は、データフィールドのうちの１つに対応する。ユーザは、データペイン内のデータと直接対話して、フローペイン３１３内のフロー３２３を変更することができる。ユーザは、データペインを直接操作して、個々のフィールド値を変更することもできる。一部の実装形態では、ユーザが１つのフィールド値に変更を加えると、ユーザインターフェースは、同じ列の他の全ての値に同じ変更を適用し、この値（またはパターン）は、ユーザが変更したばかりの値と一致する。例えば、ユーザがＳｔａｔｅデータ列の１つのフィールド値に対して「ＷＡ」を「Ｗａｓｈｉｎｇｔｏｎ」に変更した場合、一部の実装形態では、同じ列の他の全ての「ＷＡ」値が「Ｗａｓｈｉｎｇｔｏｎ」に更新される。一部の実装形態では、さらに列が更新されて、列内の州の省略形が完全な州の名称に置き換えられる（例えば、「ＯＲ」が「Ｏｒｅｇｏｎ」に置き換えられる）。一部の実装形態では、列全体にグローバルな変更を適用する前に、ユーザに確認を求めるプロンプトが表示される。一部の実装形態では、１つの列の１つの値への変更を、他の列にも（自動で、または疑似的に自動で）適用することができる。例えば、データソースには、居住地の州および請求先の州の両方が含まれる場合がある。次に、州のフォーマットの変更を両方に適用することができる。
データペイン３１５内のデータのサンプリングは、ユーザに貴重な情報を提供するために選択される。例えば、一部の実装形態では、データフィールド（外れ値を含む）の値の全範囲を表示する行が選択される。別の例として、ユーザが２つ以上のデータテーブルを有するノードを選択した場合、一部の実装形態では、２つのテーブルの結合を支援する行が選択される。データペイン３１５に表示される行は、２つのテーブル間で一致する行および一致しない行の両方を表示するように選択される。これは、結合に使用するフィールドを決定し、かつ／または使用する結合型（例えば、内部結合、左外部結合、右外部結合、または完全外部結合）を決定するのに役立つ。
図３Ｃは、ユーザインターフェースに表示される機能の一部および機能によって表示されるものを示している。上記の図３Ｂに示されているように、フローダイアグラム３２３は、常にフローペイン３１３に表示されている。プロファイルペイン３１４およびデータペイン３１５も常に示されているが、これらのペインの内容は、フローペイン３１３で選択されているノード（複数可）に基づいて変化する。場合によっては、フローペイン３１３でノードが選択されると、１つ以上のノード固有のペインが表示される（図３Ａまたは図３Ｂには図示せず）。表示されると、ノード固有のペインが他のペインに追加される。一部の実装形態では、ノード固有のペインは、移動可能なフローティングポップアップとして表示される。一部の実装形態では、ノード固有のペインがユーザインターフェース内の固定された場所に表示される。上記のように、左側ペイン３１２は、データソースを選択または開くためのデータソースパレット／チューザ、ならびにフローダイアグラム３２３に適用され得る操作を選択するための操作パレットを含む。一部の実装形態はまた、「他のフローパレット」を含み、これにより、ユーザは、別のフローの全てまたは一部を現在のフロー３２３にインポートすることが可能となる。
フローダイアグラム３２３内の異なるノードは、異なるタスクを実行し、このため、ノードの内部情報は異なる。加えて、一部の実装形態では、ノードが選択されているかどうかに応じて異なる情報が表示される。例えば、選択されていないノードには簡単な説明またはラベルが含まれるが、選択されているノードにはより詳細な情報が表示される。一部の実装形態では、操作のステータスも表示される。例えば、一部の実装形態は、ノードの操作が実行されたかどうかに応じて、フローダイアグラム３２３内のノードを異なるように表示する。加えて、操作パレット内の一部の実装形態では、現在選択されているノードで使用できるかどうかによって、操作の表示が異なる。
フローダイアグラム３２３は、データがどのように処理されているかを理解するための容易で視覚的な方法を提供するものであり、ユーザにとって論理的な方法でプロセスを編成する。ユーザは、フローペイン３１３で直接フローダイアグラム３２３を編集することができるが、操作への変更は、典型的に、より迅速な方法で行われ、プロファイルペイン３１４またはデータペイン３１５内のデータまたはスキーマが直接操作される（例えば、プロファイルペイン内のデータフィールドの統計を右クリックして、フローに列を追加または削除する）。
ユーザは、軽微な操作ごとにノードを表示するのではなく、操作を、少数のより重要なノードにグループ化できる。例えば、結合およびそれに続く２つの列の削除は、３つの個別のノードではなく、１つのノードに実装できる。
フローペイン３１３内で、ユーザは、以下を含む様々なタスクを実行することができる。
●ノード選択の変更。これにより、残りのユーザインターフェースに表示されるデータが決まる。
●ピンフロー操作。これにより、ユーザは、フローの一部を最初に実行する必要があるものとして、順序を変更できないように指定できる。
●分割および組み合わせ操作。ユーザは、進行中の論理モデルに一致するように操作を容易に再編成できる。例えば、ユーザは「病院コードの正規化」と称される１つのノードを作成したい場合がある。このノードには、多くの操作および特殊なケースが含まれている。ユーザは、最初に個々の操作を作成し、次に個々の操作を表すノードをスーパーノード「病院コードの正規化」と合体することができる。逆に、多くの個別の操作を含むノードを作成した後、ユーザは、（例えば、より一般的に再利用できるノードを作成するために）１つ以上の操作を分割することを選択することができる。
プロファイルペイン３１４により、変換の結果が期待どおりかどうかをユーザが理解するための迅速な方法が提供される。外れ値および誤り値は、典型的に、ノード内の他の両方の値との比較に基づいて、または他のノードの値の比較に基づいて、視覚的に「ポップアウト」される。プロファイルペインは、問題の原因が誤った変換またはダーティデータであるかどうかに関係なく、ユーザがデータの問題を特定するのに役立つ。プロファイルペインでは、ユーザが不良データを見出すのに役立つだけでなく、直接対話して発見された問題を修正することもできる。一部の実装形態では、プロファイルペイン３１４は非同期的に更新される。フローペインでノードが選択されると、ユーザインターフェースにより、時間の経過とともに改善される部分値（データ値分布ヒストグラムなど）の入力が開始される。一部の実装形態では、プロファイルペインには、完了したかどうかをユーザに警告するためのインジケータが含まれている。非常に大きなデータセットでは、一部の実装形態は、サンプルデータのみに基づいてプロファイルを構築する。
プロファイルペイン３１４内で、ユーザは、以下を含む様々なタスクを実行することができる。
●データ範囲および相関関係の調査。ユーザは、プロファイルペイン３１４を使用して、直接ナビゲーションを使用して特定のデータまたは列の関係性に着目することができる。
●データまたはデータ範囲のフィルタ処理。ユーザは、直接の対話を通じてフロー３２３にフィルタ操作を追加することができる。これにより、フローペイン３１３に新しいノードが作成される。
●データの変換。ユーザは、ある範囲から別の値に値をマッピングするために、プロファイルペイン３１４と直接対話することができる。これにより、フローペイン３１３に新しいノードが作成される。
データペイン３１５により、ユーザがフローから生じる行を表示および変更するための方法が提供される。典型的に、データペインにより、選択したノードに対応する行のサンプリングが選択される（例えば、１００万行ではなく、１０、５０、または１００行のサンプル）。一部の実装形態では、様々な機能を表示するために行がサンプリングされる。一部の実装形態では、ｎ行ごとなど、行が統計的にサンプリングされる。
データペイン３１５は、典型的に、（例えば、ソースデータがクリーンでない場合）ユーザがデータをクリーンアップする場所である。プロファイルペインと同様に、データペインは非同期で更新される。ノードが最初に選択されると、データペイン３１５の行が表示され始め、時間が経つにつれてサンプリングが改善する。大部分のデータセットには、（データセットが小さい場合を除き）ここで使用することができるデータのサブセットしか存在しない。
データペイン３１５内で、ユーザは、以下を含む様々なタスクを実行することができる。
●ナビゲーション用の並べ替え。ユーザは、列に基づいてデータペインのデータを並べ替えることができるが、フローには影響しない。目的は、データペインのデータのナビゲートを支援することである。
●ナビゲーション用のフィルタ処理。ユーザは、ビュー内のデータをフィルタ処理することができるが、フローにフィルタは追加されない。
●フローにフィルタを追加。ユーザは、フローに適用するフィルタを作成することもできる。例えば、ユーザは特定のデータフィールドの個々のデータ値を選択し、その値に従ってデータをフィルタ処理するアクションを実行することができる（例えば、その値を除外するか、その値のみを含める）。この場合、ユーザインタラクションにより、データフロー３２３に新しいノードが作成される。一部の実装形態では、ユーザが１つの列で複数のデータ値を選択し、選択した値のセットに基づいてフィルタを作成することができる（例えば、セットを除外するか、そのセットのみに制限する）。
●行データの変更。ユーザは行を直接変更することができる。例えば、特定の行の特定のフィールドのデータ値を３から４に変更する。
●ある値を別の値へのマッピング。ユーザは、特定の列のデータ値を変更し、その変更を伝播させて、特定の列のその値を有する全ての行を変更することができる。例えば、州を表す列全体の「Ｎ．Ｙ．」を「ＮＹ」に置き換える。
●列の分割。例えば、日付が「２０１５年１１月１４日」のようにフォーマットされていることをユーザが確認した場合、ユーザはこのフィールドを日、月、年の３つの別々のフィールドに分割することができる。
●列のマージ。ユーザは、２つ以上の列をマージして、単一の組み合わされた列を作成することができる。
ノード固有のペインには、フロー内の選択したノードに固有の情報が表示される。多くの場合、ノード固有のペインは必要ないため、ユーザインターフェースは典型的に、この用途専用のユーザインターフェースを備えた領域を指定しない。代わりに、ノード固有のペインが必要に応じて表示され、典型的に、ユーザインターフェースの他の領域にフローティングするポップアップが使用される。例えば、一部の実装形態では、ノード固有のペインを使用して、結合、ユニオン、ピボット、ピボット解除、Ｐｙｔｈｏｎスクリプトの実行、ログファイルの解析、またはＪＳＯＮオブジェクトの表形式への変換に特定のユーザインターフェースが提供される。
データソースパレット／チューザを使用すると、ユーザは、様々なデータソースからデータを取り込むことができる。一部の実装形態では、データソースパレット／チューザは左側ペイン３１２にある。ユーザは、データソースパレット／チューザを使用して、次のような様々なタスクを実行することができる。
●データソース接続の確立。これにより、ユーザは、ＳＱＬデータベース、ＣＳＶまたはスプレッドシートなどのデータファイル、非リレーショナルデータベース、Ｗｅｂサービス、他のデータソースなどのデータソースからデータをプルすることができる。
●接続プロパティの設定。ユーザは、データソースへの接続に必要な資格情報および他のプロパティを指定することができる。一部のデータソースの場合、プロパティには特定のデータ（例えば、データベース内の特定のテーブルまたはワークブックファイルからの特定のシート）の選択が含まれる。
多くの場合、上記のように、ユーザは、プロファイルペイン３１４とデータペイン３１５とのユーザインタラクションに基づいて、フロー内のノードに対する操作を呼び出す。加えて、左側ペイン３１２により、操作パレットが提供され、これにより、ユーザが特定の操作を呼び出すことが可能となる。例えば、一部の実装形態では、操作パレットに「Ｐｙｔｈｏｎスクリプトを呼び出す」オプションが含まれている。加えて、ユーザが再利用するノードを作成するときに、操作パレットで使用可能な操作としてそれらを保存することができる。操作パレットにより、（ユーザ定義の操作を含む）既知の操作のリストが提供され、これにより、ユーザがユーザインターフェースジェスチャ（ドラッグアンドドロップなど）を使用して操作をフローに組み込むことが可能となる。
一部の実装形態では、他のフローパレット／チューザが提供される。これにより、ユーザは、自分が作成したフローまたは他人が作成したフローを容易に再利用することができる。他のフローパレットは、ユーザが開始または組み込むことができる他のフローのリストを提供する。一部の実装形態では、フロー全体の選択に加えて、他のフローの一部の選択もサポートされている。ユーザは、ドラッグおよびドロップなどのユーザインターフェースジェスチャを使用して、他のフローを組み込むことができる。
ノード内部では、ノードで実行されている操作が正確に指定される。ユーザがフローを「リファクタリング」するか、またはフローをより詳細に理解するのに十分な情報が存在する。ユーザは、ノード内にあるもの（例えば、実行される操作）を正確に表示でき、操作をノードから別のノードに移動できる。
一部の実装形態には、ユーザが複数のフローを１つの「プロジェクト」または「ワークブック」にグループ化することができるプロジェクトモデルが含まれている。複雑なフローの場合、ユーザは、フロー全体をより理解しやすいコンポーネントに分割することができる。
一部の実装形態では、操作ステータスは左側ペイン３１２に表示される。多くの操作はバックグラウンドで非同期に実行されるため、操作ステータス領域は、進行中の操作および進行状況（１％完了、５０％完了、１００％完了など）をユーザに示す。操作ステータスにより、バックグラウンドで実行されている操作が示され、ユーザは、操作をキャンセルすることができ、データを更新することができ、部分的な結果を最後まで実行することができるようになる。
図３Ｂのフロー３２３などのフローは、元のデータソースから変換を介してターゲットデータセットに通過する行のパイプラインを表す。例えば、図３Ｄは、フロー３３８の簡単な例を示している。このフローは、車両に関する交通事故に基づいている。関連データは、ＳＱＬデータベースの事故テーブルおよび車両テーブルに保存される。このフローでは、第１のノード３４０が事故テーブルからデータを読み取り、第２のノード３４４が車両テーブルからデータを読み取る。この例では、事故テーブルが正規化され（３４２）、１つ以上のキーフィールドが識別される（３４２）。同様に、車両データに対して１つ以上のキーフィールドが識別される（３４６）。２つのテーブルは共有キーを使用して結合され（３４８）、結果はターゲットデータセットに書き込まれる（３５０）。事故テーブルおよび車両テーブルの両方が同じＳＱＬデータベースにある場合、別の方法として、１つのクエリで２つのテーブルからデータを読み取る単一のノードを作成する。クエリでは、選択するデータフィールドと、データを１つ以上のフィルタ（ＷＨＥＲＥ句など）で制限するかどうかを指定することができる。場合によっては、テーブルの結合に使用されるデータを変更する必要があるため、フロー３３８に示されているように、データが取得され、ローカルで結合される。例えば、車両テーブルの主キーは整数データ型であり得るのに対し、事故テーブルはゼロが埋め込まれた文字フィールドを使用して関係する車両を指定する場合がある。
図３Ｄに示すようなフローの抽象化は、大部分のＥＴＬおよびデータプレパレーション製品に共通である。このフローモデルにより、ユーザは変換を論理的に制御することができる。かかるフローは、概して命令型プログラムとして解釈され、プラットフォームによる変更をほとんど行わずに、またはまったく行わずに実行される。つまり、ユーザは、実行に対する物理的な制御を定義するための特定の詳細を提供したことになる。例えば、このフローで動作する一般的なＥＴＬシステムにより、指定されたとおりにデータベースから２つのテーブルがプルダウンされ、指定されたとおりにデータが整形され、ＥＴＬエンジンでテーブルを結合して、結果がターゲットデータセットに書き込まれる。物理プランを完全に制御することは、有用であり得るが、パフォーマンスを向上させるためにプランを変更または最適化（例えば、ＳＱＬサーバーで前述のフローを実行）するシステムの機能が排除される。多くの場合、顧客は実行の詳細を制御する必要がないため、本実装形態により、操作を宣言的に表現することができる。
ここでの一部の実装形態は、完全な宣言型クエリから命令型プログラムまでの範囲に及ぶ。一部の実装形態では、内部分析クエリ言語（ＡＱＬ）およびフェデレーションエバリュエータを利用する。デフォルトでは、フローは可能な限り単一の宣言型クエリ仕様として解釈される。この宣言型クエリは、ＡＱＬに変換され、クエリエバリュエータに渡される。クエリエバリュエータは、最終的に演算子を分割し、分散して実行する。上記の図３Ｄの例では、フロー全体を１つのクエリとしてキャストすることができる。両方のテーブルが同じサーバーからのものである場合、この操作全体がリモートデータベースにプッシュされる可能性が高く、パフォーマンスが大幅に向上する。この柔軟性により、最適化および配布フローの実行が可能になるだけでなく、ライブデータソース（例えば、データウェアハウスだけでなくトランザクションデータベースから）に対するクエリの実行も可能になる。
ユーザが（パフォーマンス上の理由などのために）フローの実際の実行の順序を制御したい場合、ユーザは操作を固定することができる。固定することによって、フロー実行モジュールは、プランのそのポイントを超えて操作を移動しないように指示される。場合によっては、ユーザは、（例えば、フローのオーサリングまたはデバッグ中など）一時的に順序を極端に制御したい場合がある。この場合、全ての演算子を固定することができ、フローはユーザが指定した順序で正確に実行される。
図３Ｅに示すように、全てのフローが単一のＡＱＬクエリに分解できるわけではないことに留意されたい。このフローでは、毎時実行される毎時ドロップ３５２があり（３６２）、ステージングデータベースに追加（３５６）する前にデータが正規化（３５４）される。次に、毎日（３６４）、ステージングデータベースからのデータが集計され（３５８）、ターゲットデータセットとして書き出される（３６０）。この場合、時間別スケジュールと日次スケジュールとは別々の部分として残す必要がある。
図４Ａ～図４Ｖは、一部の実装形態による、フローに結合を追加する一部の態様を示している。図４Ａに示されるように、ユーザインターフェースは、左ペイン３１２、フローエリア３１３、プロファイルエリア３１４、およびデータグリッド３１５を含む。図４Ａ～図４Ｖの例では、ユーザは、最初に左側ペイン３１２の接続パレットを使用してＳＱＬデータベースに接続する。この場合、データベースには、米国運輸省道路交通安全局から提供された死亡率分析報告システム（ＦＡＲＳ）データが含まれている。図４Ｂに示されるように、ユーザは、利用可能なテーブルのリスト４０２から「事故」テーブル４０４を選択する。図４Ｃでは、ユーザは、事故テーブルアイコン４０６をフローエリア３１３にドラッグする。テーブルアイコン４０６がフローエリア３１３にドロップされると、図４Ｄに示されるように、ノード４０８が作成されてテーブルを表す。このポイントで、事故テーブルのデータが読み込まれ、事故テーブルのプロファイル情報がプロファイルペイン３１４に表示される。
プロファイルペイン３１４は、図４Ｅに示されるように、州の列４１０を含む列の各々の分布データを提供する。一部の実装形態では、プロファイルペインのデータの各列に、データの分布を示すヒストグラムが表示される。例えば、カリフォルニア州、フロリダ州、およびジョージア州は事故件数が多いのに対し、デラウェア州は事故件数が少ない。プロファイルペインでは、各列の上部にあるキーアイコン４１２を使用して、キーまたは部分キーである列を容易に識別することができる。図４Ｆに示されるように、一部の実装形態では、３つの異なるアイコンを使用して、列がデータベースキー、システムキー４１４、または「ほぼ」システムキー４１６であるかどうかを指定する。一部の実装形態では、１つ以上の他の列と組み合わせた列がシステムキーである場合、列は、ほぼシステムキーである。一部の実装形態では、ｎｕｌｌ値の行が除外された場合に列がシステムキーになる場合、列は、ほぼシステムキーである。この例では、「ＳＴケース」と「ケース番号」の両方が、ほぼシステムキーである。
図４Ｇでは、ユーザは、左側ペイン３１２で「人物」テーブル４１８を選択している。図４Ｈでは、ユーザは、人物テーブル４１８をフローエリア３１３にドラッグし、これは、ドラッグされている間、移動可能なアイコン４１９として表示される。人物テーブルアイコン４１９をフローエリア３１３にドロップした後、図４Ｉに示されるように、人物ノード４２２がフローエリアに作成される。この段階では、事故ノード４０８と人物ノード４２２との間に接続はない。この例では、両方のノードが選択されているため、プロファイルペイン３１４は２つの部分に分割される。第１の部分４２０は事故ノード４０８のプロファイル情報を示し、第２の部分４２１は人物ノード４２２のプロファイル情報を示す。
図４Ｊは、フローペイン３１３およびプロファイルペイン３１４の拡大図を提供する。プロファイルペイン３１４は、結合列の候補（すなわち、２つのノードからのデータを結合する可能性）を表示するためのオプション４２４を含む。このオプションを選択した後、図４Ｋに示すように、結合候補であるデータフィールドがプロファイルペイン３１４に表示される。これで結合候補が表示されるので、プロファイルペイン３１４は、結合列の候補を非表示にするためのオプション４２６を表示する。この例では、プロファイルペイン３１４は、人物テーブルの列ＳＴケースが事故テーブルのＳＴケースフィールドと結合される可能性があることを示している（４３０）。プロファイルペインには、事故テーブルに３つの追加の結合候補があること（４２８）、および人物テーブルに２つの追加の結合候補があること（４３２）も示される。図４Ｌでは、ユーザは、ヒントアイコンをクリック（４３３）し、それに応じて、図４Ｍに示すように、プロファイルペインに２つの候補列が隣接して配置される。事故テーブルのＳＴケース列のヘッダ４３４は、人物テーブルのＳＴケース列と結合できることを示している。
図４Ｎは、複数のノードのデータを結合する別の方法を示している。この例では、ユーザは、事故テーブルデータ４０８および人口テーブルデータ４４１をフローエリア３１３に読み込んでいる。人口ノード４４１を事故ノード４０８の上にドラッグするだけで、結合が自動的に作成され、結合エクスペリエンスペイン４４２が表示され、ユーザは結合を確認および／または変更することができる。一部の実装形態では、結合エクスペリエンスはプロファイルペイン３１４に配置される。他の実装形態では、結合エクスペリエンスは、一時的にプロファイルペイン３１４を置き換える。結合が作成されると、新しいノード４４０がフローに追加され、これは、２つのノード４０８と４４１との間の接続の作成をグラフィカルに表示する。
結合エクスペリエンス４４２は、図４Ｏに示されるように、様々なアイコンを備えたツールバー領域４４８を含む。結合候補アイコン４５０が選択されると、インターフェースにより、各テーブルのどのフィールドが結合候補であるかが識別される。一部の実装形態は、お気に入りアイコン４５２を含み、これにより、（例えば、過去にユーザによって選択された、過去にユーザによって重要であると識別された、または過去にユーザによって一般的に選択された）強調表示された「お気に入り」データフィールドが表示される。一部の実装形態では、お気に入りアイコン４５２は、特定のデータフィールドをお気に入りとして指定するために使用される。プロファイルペイン３１４およびデータペイン３１５に列を表示するためのスペースが限られているので、一部の実装形態は、お気に入りのデータフィールドに関する情報を使用して、デフォルトで表示される列を選択する。
一部の実装形態では、「キーの表示」アイコン４５４の選択により、インターフェースは、どのデータ列がキーであるか、または複数のデータフィールドからなるキーの一部であるかを識別する。一部の実装形態は、データ／メタデータトグルアイコン４５６を含み、これは、データに関する情報のディスプレイからメタデータに関するディスプレイに表示を切り替える。一部の実装形態では、データは常に表示されており、メタデータアイコン４５６は、データに加えてメタデータが表示されるかどうかを切り替える。一部の実装形態は、データグリッドアイコン４５８を含み、これは、データグリッド３１５のディスプレイを切り替える。図４Ｏでは、データグリッドが現在表示されているので、データグリッドアイコン４５８を選択すると、データグリッドが表示されない。実装形態には典型的に、検索ウィンドウを表示する検索アイコン４６０も含まれる。デフォルトでは、検索は、データおよびメタデータの両方（例えば、データフィールドの名前とフィールドのデータ値の両方）に適用される。一部の実装形態には、検索対象をより正確に指定するための高度な検索のオプションが含まれている。
結合エクスペリエンス４４２の左側には、結合型４６４の仕様を含む一連の結合コントロールがある。当技術分野で知られているように、結合は、典型的に、左外部結合、内部結合、右外部結合、または完全外部結合である。これらは、結合アイコン４６４によってグラフィカルに示されている。現在の結合型が強調表示されているが、ユーザは、別のアイコンを選択することで結合型を変更できる。
一部の実装形態では、結合句の概要４６６が提供される。これは、結合の両側のフィールドの名前と、結合の両側のデータフィールドのデータ値のヒストグラムの両方を表示する。結合に複数のデータフィールドがある場合、一部の実装形態では、関連する全てのデータフィールドが表示される。他の実装形態には、結合内のデータフィールドをスクロールするためのユーザインターフェースコントロール（図示せず）が含まれる。一部の実装形態にはまた、結合条件の型に基づいて結合されるテーブルの各々の行数を示す概要コントロール４６８も含まれている。このコントロール内の部分の選択は、プロファイルペイン３１４およびデータグリッド３１５に表示されるものを決定する。
図４Ｐ、図４Ｑ、および図４Ｒは、結合コントロール領域４６２のための代替のユーザインターフェースを示している。いずれの場合も、結合型が上部に表示される。いずれの場合も、結合に含まれるデータフィールドの視覚的表現が存在する。ここでは、結合には、ＳＴケースおよび年の２つのデータフィールドが存在する。これらの選択肢の各々には、結合された各テーブルの行の割合をグラフィカルに示すセクションも存在する。図４Ｑの上側部分は、その下の図４Ｕに表示されている。
図４Ｒには、２つのテーブルがどのように関連しているかを示す下側部分が含まれる。分割バー４７２は事故テーブルの行を表し、分割バー４７４は人口テーブルを表す。中央の大きなバー４７７は、２つのテーブル間の内部結合によって接続されている行を表している。現在選択されている結合型は左外部結合であるため、結合結果セット４７６には、人口テーブルのどの行にもリンクされていない事故テーブルの行を表す部分４７８も含まれている。下部には、別の長方形４８０がある。これは、事故テーブルのどの行にもリンクされていない人口テーブルの行を表す。現在の結合型は左外部結合であるため、部分４８０は、結果セット４７６に含まれない（下の長方形４８０の行は、右外部結合または完全外部結合に含まれる）。ユーザはこの図の任意の部分を選択でき、選択した部分がプロファイルペインおよびデータペインに表示される。例えば、ユーザは、「左外側部分」の長方形４７８を選択し、次に、データペインの行を見て、それらの行がユーザの分析に関連するかどうかを確認することができる。
図４Ｓは、結合コントロールセレクタ４６４を含む、図４Ｒに示される結合コントロールインターフェース要素を使用する結合エクスペリエンスを示している。ここでは、図４Ｔの拡大図でより明確に示されているように、左外側結合アイコン４８２が強調表示されている。この例では、第１のテーブルは事故テーブルであり、第２のテーブルはファクターテーブルである。図４Ｕに示すように、インターフェースには、結合されている行数４８６と結合されていない行数４８８の両方が表示される。この例には、結合されていない行が多数ある。ユーザは、結合されていないバー４８８を選択して、図４Ｖのディスプレイを表示することができる。プロファイルのブラッシングおよびデータグリッドのフィルタ処理により、ユーザは、２０１０より前のファクターテーブルにエントリがないことから、ｎｕｌｌが左外部結合と一致しない値の結果であることがわかる。
開示された実装形態は、様々なシナリオを支援する多くの機能をサポートする。多くの機能は上述のとおりであるが、次の複数のシナリオは機能を説明するものである。
シナリオ１：イベントログの収集
アレックスはＩＴ部門に勤務しており、彼の仕事の１つは、インフラストラクチャ内のマシンからログを収集して準備し、ＩＴ企業の様々なデバッグおよび分析に使用される共有データセットを作成することである。
マシンはＷｉｎｄｏｗｓ（登録商標）を実行しており、アレックスはアプリケーションログを収集する必要がある。エージェントがすでに存在しており、これは、毎晩実行され、ログのＣＳＶエクスポートを共有ディレクトリにダンピングする。各日のデータは別のディレクトリに出力され、マシン名を示すフォーマットで出力される。アプリケーションログの抜粋を図５Ａに示す。
アプリケーションログの抜粋には、いくつかの興味深い特徴がある。
●１行目にはヘッダ情報が含まれている。これは、一般的に該当する場合があるか、または該当しない場合がある。
●データの各行には６つの列があるが、ヘッダには５つの列がある。
●ここでの区切り文字は明らかに「，」である。
●最後の列には、引用符で囲まれた複数行の文字列が使用される場合がある。ここの３～９行目は全て、１つの行の一部であることに留意されたい。また、このフィールドでは、引用符を示すために二重引用符を使用しており、文字通りに解釈する必要があることに留意されたい。
アレックスは、特定のディレクトリ内の全てのＣＳＶファイルを読み込み、それらに対してギザギザ型（ｊａｇｇｅｄ）のユニオンを実行するフローを作成する（例えば、ＣＳＶファイルの少なくとも１つにデータフィールドが存在する場合は、データフィールドを作成するが、同じデータフィールドが２つ以上のＣＳＶファイルに存在する場合は、そのデータフィールドのインスタンスを１つだけ作成する）。ＣＳＶ入力ルーチンでは、５列の読み込みはうまくいくが、６列目の引用符が詰まってしまい、複数の列として読み込まれる。
その後、アレックスは、
●データペインで列を選択し、それらをマージして元に戻す。
●ファイル名から取得したマシン名を追加する。彼は、データの例でマシン名を選択し、「新しい列として抽出」を選択することでこれを行う。システムは、このアクションからパターンを推測する。
●右クリックして「識別子の追加」を選択すると、行ごとに一意の識別子が生成される。
●データペインで列名および型を直接編集する。
これは全て、データペイン３１５内のデータに対する直接アクションによって達成されるが、この結果として、ロジックがフローペイン３１３内のフローに挿入される。
次に、アレックスは、ターゲットデータリポジトリをフローペインにドラッグし、出力をワイヤリングして、ログの完全なレコードを含むキャッシュにこれらのレコードを追加する。
最後に、アレックスのフローにより、このターゲットデータセットにクエリが実行され、前日に報告したマシンのセットが見出される。これを現在のマシンと比較して、報告しなかったと予想されるマシンのリストとともに警告がアレックスに出力される。
アレックスは、様々な方法で同じ結果を達成し得る可能性があることに留意されたい。例えば、
●アレックスは２つの別々のフローを作成することができる。１つは取り込みを実行するものであり、１つは、各日のマシンを前日のマシンと比較し、その結果をアレックスに警告するものである。
●アレックスは、１つのステージで取り込みを実行するフローを作成することができる。それが完了すると、アレックスは、第２のフローを実行することができ、データベースにクエリを実行し、各日を前日と比較してアレックスに警告する。
●アレックスは、ターゲットを入力と出力の両方として有するフローを作成することができる。このフローは、取り込みを実行し、それをデータベースに書き込み、さらに集計してその日のマシンを見出す。また、ターゲットにクエリを実行して前日の結果を取得し、比較を実行して、警告を発生させる。
アレックスは、マシンが一晩で報告を行う必要があることを知っているので、アレックスは、毎朝最初にフローを実行する。その後、朝の残りの時間を使って、報告しなかったマシンをチェックする。
シナリオ２：ＦＡＲＳの収集および統合
ボニーは保険会社に勤務しており、分析のコンポーネントとして死亡率分析報告システム（ＦＡＲＳ）データをプルしたいと考えている。ＦＡＲＳデータはＦＴＰ経由で利用可能であり、ボニーはそれを取得して組み立てる方法を理解する必要がある。彼女は、データプレップアプリケーション２５０を使用してこれを行うこととした。
ボニーは、ＦＡＲＳが公開している一連のフォーマットを調べて、ＤＢＦファイルを使用することにした。これらのＤＢＦファイルはＦＴＰサイト全体に分散しており、圧縮されたＺＩＰアーカイブでのみ利用することができる。ボニーはツリービューを調べて、ダウンロードしたいファイルを選択する。データがダウンロードされると、ボニーはフローの次のステップを開始する。彼女はファイルのコレクションを選択し、「抽出」を選択する。これにより、ファイルを年でラベル付けされた個別のディレクトリに解凍するステップが追加される。
データが集まり始めると、ボニーには問題が見えてくる。
●最初の年には、事故、人物、および車両の３つのテーブルに対応する３つのファイルがある。その後の年には、これらの他にさらに多くのテーブルも存在する。
●ファイル名が統一されていない。例えば、事故ファイルの名前は１９７５年～１９８２年と１９９４年～２０１４年とでは「ａｃｃｉｄｅｎｔ．ｄｂｆ」であるが、その間の年では「ａｃｃＹＹＹＹ．ｄｂｆ」（ＹＹＹＹは４桁の年）という名前である。
●テーブル名が同じでも、時間の経過とともに構造が若干変化する。最新のテーブルには、以前のデータには存在しない追加の列が含まれている。
ボニーは、全ての年に存在する事故テーブルから手を付ける。彼女はファイルを選択して右クリックし、「ユニオン」を選択する。これによりギザギザ型のユニオンが実行され、列が保持される。彼女はこれを、全ての年に存在する他の３つのテーブルで繰り返し、次に残りのテーブルについて繰り返す。彼女がこれを完了すると、彼女のフローの最終段階で、１９個の個別のテーブルが作成される。
これを取得したら、彼女はデータの組み立てを試みる。共通の結合キーはＳＴ＿ＣＡＳＥという列であり得るように見えるが、事故テーブルのプロファイルペインを見るだけで、これがどこのキー列でもないことがわかる。ＳＴ＿ＣＡＳＥは重要ではないが、年をクリックすると、ＳＴ＿ＣＡＳＥが１年に１つしか存在しないことが容易に理解できる。同様に、年およびＳＴ＿ＣＡＳＥは良好な結合キーのように見える。
彼女は、人物テーブルに手を付ける。このテーブルに結合する前に、テーブルの各々には年が必要とされるが、それは存在していない。ただし、ファイルパスには年があるため、データペインでこのデータを選択し、［新しい列として抽出］を選択することができる。システムはこれに対する正しいパターンを推測し、各行の年を抽出する。次に、フロー内の両方のテーブルを選択し、一方の列およびＳＴ＿ＣＡＳＥ列を選択して、それらをもう一方のテーブルにドラッグし、結合が作成される。
キーを取得したので、結合を作成し続けて、ＦＡＲＳデータがフラット化される。完了したら、チームがデータを使用することができるように、データをＴＤＥ（タブローデータ抽出）としてタブローサーバー（Ｔａｂｌｅａｕ Ｓｅｒｖｅｒ）に公開する。
シナリオ３：ＦＡＲＳクリーンアップ
コリンは、ボニーと同じ部門の別の従業員である。ボニーのフローが生成するデータを使おうとしている人もいるが、そこには多くの暗号的な値が含まれている。ボニーが別の会社に移ってしまったことに気づき、彼らはコリンに頼ることになる。
フローを見ると、コリンはその全体的なロジックを容易に確認することができ、暗号化されたコード化データも確認することができる。彼が暗号的なルックアップテーブル（ＬＵＴ）を含む２００ページのＰＤＦマニュアルを見つけたとき、そのプロセスは困難なものに思えた。ＰＤＦのルックアップテーブルの例を図５Ｂに示す。単純なものもあれば、非常に複雑なものもある。
コリンは、一部のより重要なテーブルから手を付ける。彼は、ＰＤＦファイル内のテーブルを選択してフローペイン３１３に貼り付けることができることを見出した。場合によっては、テーブル内のデータが完全に正しいわけではないが、これが上手く機能するので、コリンはデータペイン３１５で結果を手動でパッチすることができ、かなりの時間を節約できることになる。彼の仕事は、目に見えて成果が出るものである。テーブルが整列していない場合でも、すぐそれが判明する。
最終的に、コリンは、チームが実行する分析に特に関連すると思われる１２個のＬＵＴを取り込み、結果を公開して、チームがデータを使用できるようにする。特定の列に関する詳細情報が求められると、コリンは、フローをさらに拡張して、追加のＬＵＴを取り込むことができる。
シナリオ４：データエラーの発見
大手ソフトウェア会社の開発者であるダニエルは、ビルド時間を表すデータを調べている。ダニエルは、データのフォーマットを細かく制御することができ、使いやすいＣＳＶフォーマットでデータを作成したが、データを読み込んで、作成したデータベースに追加したいと考えている。
データを読み込むとき、彼女はプロファイルビュー３１４をスキャンする。彼女が直ちに奇妙と感じたのは、負の時間のビルドがいくつか存在することである。明らかに何らかの問題が存在しているので、彼女は問題をデバッグしたいと考えているが、分析のためにデータをプルしてまとめたいとも考えている。
彼女は、プロファイルビューで負の時間を選択し、「保持のみ」をクリックしてエラーのある行のみを保持する。彼女は、これらをファイルに通過させるためのターゲットを追加する。彼女は、それらの生の行を使用してデバッグをガイドする。
フローに戻ると、彼女はフィルタの直前に別のブランチを追加する。彼女は（例えば、プロファイルペイン３１４またはデータペイン３１５で）再び負の値を選択し、次に単に「削除」を押す。これにより、値がｎｕｌｌに置き換えられる。これは、実際の値が単に不明であることを示す良い指標である。彼女は残りの単純なフローを続行し、ビルドデータをデータベースに追加し、その後で、負の値を調べる。
シナリオ５：車両部品の追跡
アールは自動車メーカーに勤務しており、各車両および工場の主要部品の現在のステータスを示すデータセットの維持を担当している。データは複数の運用ストアに報告されるが、これらの運用ストアは非常に大規模なものである。数十万の部品が存在しており、自動化された施設として、工場を通過する際に、車両または部品ごとに数千のレコードが機械的に作成される。これらの運用ストアには、部品のステータスとは関係のない、その他の運用情報（例えば、「バルブ１３４の圧力は５００ｋＰａである」）などのレコードも多く含まれている。各部品について、迅速で簡潔なレコードがビジネス上必要である。
アールは、３つのリレーショナル運用ストアの各々のテーブルをフローペイン３１３にドラッグする。それらのうちの２つは、ログレコードを含む単一のテーブルとしてデータを格納する。３つ目として、小さなスタースキーマがあり、アールは、ドラッグアンドドロップして結合を作成することで迅速にフラット化を行う。
次に、追加のドラッグアンドドロップにより、アールはギザギザ型のテーブルのユニオンを迅速に実行することができる。その結果、彼は、列を一緒にドラッグアンドドロップすることができ、インターフェースにより結果が合体される。
部品識別番号には、若干の問題があり、１つのシステムの値にハイフンが含まれている。アールは、データペイン３１５内の値のうちの１つを取得し、ハイフンを選択し、そして削除を押す。インターフェースにより、この列からハイフンを削除するルールが推測され、その列の全てのデータのハイフンを削除するルールがフローに挿入される。
アールは、現在のプロジェクトに関連していないため、ほとんどのステータスコードを必要としない。彼は単に、部品に関連するステータスコードを求めている。彼は、ステータスコードに関する情報を含むテーブルをプルし、それをフローの最後のノードにドロップする。その結果、ステータスコードに新しい結合が作成される。彼はここで、「ターゲット型」が「部品」に等しい行のみを選択し、「保持のみ」を選択して他の値をフィルタ処理して除外する。このフィルタ処理は、プロファイルペイン３１４またはデータペイン３１５で行われる。
最後に、アールは、各部品の最後の値のみを必要とする。彼は直接のジェスチャで、データペインのデータを日付で並べ替え、部品番号でグループ化し、「ｔｏｐ－ｎ」テーブル計算を追加して、各部品の最終更新のみを取得する。
アールは、フローを実行し、実行に４時間かかることを発見した。しかし、彼はこれを加速させる方法を知っている。彼は、最後にフローを実行した時間を記録することができ、後続の各実行においてのみ、新しいレコードを組み込むことができる。ただし、これを行うには、累積セット内の既存の行を更新し、それらが新しい部品を表す場合にのみ行を追加する必要がある。彼は「マージ」操作を必要とする。
アールは、部品番号を使用して一致するものを識別し、一致が発生した場合と発生しなかった場合のアクションを提供する。更新ロジックを使用することで、アールのフローの実行にかかる時間はわずか１５分となる。時間を節約することで、その会社は、部品が倉庫のどこにあるか、そしてそれらのステータスがどのような状態であるかをより厳密に追跡することができる。
その後、アールは、このジョブをサーバーにプッシュして、スケジュールを立てて一元的に実行できるようにする。また、スケジュールされたタスクをデスクトップマシンに作成することもでき、デスクトップマシンにより、コマンドラインインターフェースを使用してフローが実行される。
シナリオ６：投資ブローカー
ガストンは、ＩＴ部門によって生成されたデータを取得してダイジェスト化するチームの投資ブローカーに勤務しており、データを、顧客と連携する様々なチームが使用できるようにしている。ＩＴ部門により、顧客のポートフォリオの一部（債券ポジション、株式ポジションなど）を示す様々なデータセットが作成されるが、各々のみではガストンの顧客が必要とするものとならない。
ハーマインが率いる１つのチームは、顧客が電話をかけたときにチームが質問に答えられるように、全ての顧客位置データをプルしてまとめる必要がある。データプレパレーションはそれほど複雑ではない。
ガストンは、ＩＴ部門により生成される夜間のデータベースドロップを加工し、それらをユニオン化し、データに問題ないことを確認するためにいくつかの簡単なチェックを行う。次に、ハーマインのチームが必要とするものにフィルタ処理し、チームが使用するＴＤＥを作成する。
過去のツールでは、ガストンは毎朝、フローを実行することを忘れていた。しかし、新しいデータプレップアプリケーション２５０を使用すると、このフローを宣言的に処理することができる。彼は、ハーマインのチームが使用するＴＤＳをハーマインに送信する。これにより、ハーマインのチームが作成する全てのデータ視覚化は、データベースに対して直接実行される。これは、ガストンがデータの更新について心配する必要がなくなり、迅速に実行されることを意味する。
イアンが率いる別のチームは、同様のデータを使用して、顧客のアカウントのパフォーマンスレビューを行っている。このデータを生成するために、ガストンは、ハーマインのために行った作業を再利用するが、データをイアンのチームのアカウントにフィルタ処理し、追加のフローを実行して、イアンのチームが分析を実行することができるように、データを様々なインデックスおよびパフォーマンス指標と結合する。この作業は費用がかかり、ライブではうまく機能しないように思われる。彼がフローを実行する場合、完了するまでに数時間かかるが、イアンのチームはこれを月に１回だけ必要とする。ガストンは、サーバー上に定期的なカレンダーアイテムを設定して、月に１回これを実行する。
シナリオ７：顧客データのスクラブ
カールは、大手ソフトウェア会社の戦略的アカウントマネージャーである。彼はタブロー（Ｔａｂｌｅａｕ）を使用して、業界会議の参加者、彼らが誰のために働いているのか、彼らの代表者は誰か、彼らがアクティブな顧客なのかまたは見込み客か、会社が小規模かまたは大規模か、などに関する情報を視覚化しようとしている。
カールは、会議の参加者のリストを有しているが、過去も同様のことを経験していた。彼の最後の経験では、リストをクリーンアップするのに８時間を要し、視覚化の構築を完了するのに１５分を要した。今回、彼は、データプレパレーションアプリケーション２５０を使用して、プロセスを高速化および自動化する。
カールは、最初に会社名をクリーンアップしたいと考えている。データを見てみると、予想通り、同じ会社が複数の異なるフォーマットで掲載されていることが多く、中には誤字脱字もある。彼は、操作パレットで提供されるファジー重複排除ルーチンを呼び出して、潜在的な重複を識別する。彼は結果を確認し、アルゴリズムが過大評価されていた複数のケースを修正する。彼はまた、アルゴリズムが見逃した複数のケースを見つけ、それらをグループ化する。これにより、正規の会社名を含む顧客リストが生成される。
次に、タブローサーバーのデータソースに保持されている企業のリストとデータの結合を試みる。彼は、各企業が複数のリストを有していることを発見した。複数の異なる会社が同じ名前を有している場合があり、１つの会社が地域に基づいて複数のアカウントを有している場合がある。
これを整理するために、カールは、発見したＬｉｎｋｅｄＩｎ（商標）用のＲＥＳＴコネクタを使用し、それをデータ内の各電子メールアドレスに渡して、各人物の国および州を取得する。この手順では、彼が有している情報（例えば、その人物の名前、会社、役職）を取得し、ＬｉｎｋｅｄＩｎの検索機能を使用して、各エントリの最良の結果を導き出す。次に、会社および場所のデータをサーバー内のデータに結合して、正しいアカウントを見出す。
カールは、彼の結合が常に上手く機能するとは限らないことを発見した。彼が選んだ正規の会社名は、彼のアカウントデータベースにあるものと常に一致するとは限らない。彼は自分の結合をファジー結合に変換し、ファジー一致を確認し、さらに手動で結果を修正する。
データをクリーンアップしたので、タブローでデータを開いて、データの視覚化を作成する。
一般的に使用されるフローの機能は、次のとおりである。
●ユーザが操作の論理順序を正確に制御する必要がある、複数レベルのユニオン、結合、および集計。
●理解を深めるためにユーザが配置および注釈を付けたレイアウト。
●データがフローを進むにつれて、データの構造を明確にする必要がある。
●フローの一部を再利用して、２つの異なる出力を生成する。
●２人以上の他のユーザのために、場合によっては別々のチームでデータを準備する作成者。
●フローを自動的に実行するようにスケジュールする。
データプレパレーションアプリケーションは、ＥＴＬ（抽出、変換、および読み込み）システムとして分類される場合がある。３つのフェーズは各々、異なる型のタスクを実行する。
抽出フェーズでは、ユーザは、１つ以上の利用可能なデータソースからデータをプルする。通常、ユーザは次のタスクを実行する。
●単なるファイルの移動。例えば、ユーザは、他の処理の前にＦＴＰソースからファイルを取得することができる。
●構造（例えば、リレーショナル、半構造化、または非構造化）、フォーマット（例えば、構造化ストレージ、ＣＳＶファイル、またはＪＳＯＮファイル）、およびソース（例えば、ファイルシステムまたは正式なデータベース）が大きく異なるデータを取り込む。
●ソース全体、またはソースの一部を選択して読み取る。部分的な読み取りは、前回の取り込み時よりも新しいデータまたは変更されたデータをプルする場合か、またはパフォーマンス上の理由でチャンクをサンプリングするか、もしくはプルする場合によく行われる。
変換フェーズでは、ユーザは、様々な方法でデータを変換する。通常、変換には次のタスクが含まれる。
●エラーの修正、値の欠落または重複の処理、同一であるべきバリアント値の調整、規格への適合など、データのクリーニングを行う。
●スカラーおよびテーブルの計算、集計、行および列のフィルタ処理、ピボット（解除）、または外部データの組み込み（ジオコーディングなど）を通じて、データを拡張または強化する。
●ユニオンまたは結合（ファジー結合を含む）を介して複数のソースを組み合わせる。
●個別の処理のために（行または列のいずれかで）まとめられた複数の型のデータをデインターリーブする。
●データのプロファイルまたはデータに関するメトリックを抽出して、データをよりよく理解する。
読み込みフェーズでは、ユーザは結果を保存して、結果を分析できるようにする。これには、以下が含まれる。
●タブローデータ抽出（ＴＤＥ）、フォーマットされたファイル（ＣＳＶもしくはＥｘｃｅｌなど）、または外部データベースへのデータの書き込み。
●スケジュールに従ってスナップショットを作成する。
●新しい結果または変更された結果でデータを追加または更新する。
ユーザがデータを準備するためのフローを構築した後、ユーザは多くの場合、次のことを行う必要がある。
●指定された時間に、または他のフローと協調して実行するようにフローをスケジュールする。
●フローの結果を他人と共有する。
●フロー自体を他のユーザと共有して、他のユーザがフローを調べたり、変更したり、複製したり、管理したりできるようにする。これには、フローまたはデータをＩＴ部門と共有して、ＩＴ部門がそれを改善および管理できるようにすることが含まれる。
開示されたシステム２５０により、ユーザは制御が与えられる。多くの場合、データプレップアプリケーションはユーザに対してインテリジェントな選択を行うが、ユーザは、常に制御を表明できる。多くの場合、制御には２つの異なる態様がある。操作の論理的な順序の制御（結果が正しく、ユーザの希望するセマンティクスと一致することを保証するために使用される）および物理的な制御（主にパフォーマンスを確保するために使用される）である。
開示されたデータプレップアプリケーション２５０はまた、自由度を提供する。ユーザは、必要なデータの形状を実現するために、データ生成コンポーネントを任意の方法でアセンブルおよび再アセンブルできる。
開示されたデータプレップアプリケーション２５０は、増分的なインタラクションおよび即時のフィードバックを提供する。ユーザがアクションを実行すると、システムにより、ユーザのデータのサンプルに関する即時の結果ならびに視覚的なフィードバックを通じてフィードバックが提供される。
典型的に、ＥＴＬツールは命令型セマンティクスを使用する。つまり、ユーザは、全ての操作の詳細と操作を実行する順序とを指定する。これにより、ユーザは完全に制御を行うことができる。対照的に、ＳＱＬデータベースエンジンは宣言型クエリを評価し、クエリによって要求されたデータに基づいて最適な実行プランを選択することができる。
開示された実装形態は、命令型および宣言型の両方の操作をサポートしており、ユーザは、これら２つの実行オプションから様々なレベルの粒度で選択することができる。例えば、ユーザは、新しいデータセットについて学習しながら、最初にフローを完全に制御することを望む場合がある。ユーザが結果に満足したら、その後、実行速度を最適化するために、ユーザは制御の全てまたは一部をデータプレップアプリケーションに放棄することができる。一部の実装形態では、ユーザは各フローのデフォルトの動作（命令型または宣言型）を指定し、個々のノードのデフォルトの動作をオーバーライドすることができる。
開示された実装形態は、ＴＤＥ、ＳＱＬサーバー、Ｏｒａｃｌｅ、Ｒｅｄｓｈｉｆｔ、フラットファイルなどを含む多くの異なるターゲットデータベースにデータを書き込むことができる。場合によっては、フローによってターゲットシステムに新しいデータセットが作成される。他の例では、フローは、新しい行の追加、既存の行の更新、行の挿入、または行の削除によって既存のデータセットを変更する。
フローの実行中にエラーが発生する可能性がある。エラーには、一時的なシステムの問題、ユーザが修正措置を符号化する可能性のあるデータ内の潜在的な既知のエラー状態、および作成者が考慮しなかった暗黙の制約が含まれる場合がある。開示された実装形態は概して、可能な場合、これらのエラー状態を自動的に処理する。例えば、過去に同じエラー状態が発生した場合、一部の実装形態では既知のソリューションが再適用される。
フローは本質的にデータ変換であるが、実装形態により、ユーザは、宣言型モデリング情報で出力に注釈を付けて、出力の使用、表示、検証、または組み合わせの方法を説明することができる。例として、以下が挙げられる。
●デフォルトの色または書式など、タブローでの値の表示方法に影響を与える注釈。
●単位または系統を示すフィールド上の注釈。
●エイリアスおよびグループの作成。
●テーブル間の主キーおよび外部キーなどの機能上の制約。
●フィールドが正であることを要求するなど、ドメインの制約。
開示されている実装形態には、概して、次のコンポーネントが含まれている。
●フローを表示、構築、編集、および実行するためにユーザが対話するフロントエンド領域。
●抽象フロー言語（ＡＦＬ）。これは、ソースへの接続、計算およびその他の変換、モデリング操作、フローの結果である行の処理など、フロー内の全てのロジックを表現する内部言語である。
●実行エンジン。このエンジンは、ＡＦＬプログラムを解釈して実行する。一部の実装形態では、このエンジンはローカルで実行される。クエリはリモートサーバーにプッシュされる場合があるが、結果およびその後の処理はローカルリソースを使用して行われる。サーバー環境では、サーバーはフローの共有分散実行環境を提供する。このサーバーは、多くのユーザからのフローをスケジュールおよび実行でき、ＡＦＬフローを自動的に分析およびスケールアウトできる。
●他人へのフローの公開を許可するカタログサーバー。
一部のデータ視覚化アプリケーションは、データプレップフローを実行することができ、ＴＤＥまたは他の作成されたデータセットを使用してデータ視覚化を構築することができる。
開示された実装形態は、他のアプリケーションによって作成された（例えば、ＥＴＬツールで作成された）一部のデータフローをインポートすることもできる。
実装形態により、ユーザは次のことが可能になる。
●図６Ｂに示すように、データソースに接続して、それをデータソースから読み取る。
●サポートされている操作（図６Ａを参照）を任意の順序および組み合わせにおいて組み合わせたフローを構築する。
●フローの各ステップでデータがどのように変換されるかについての合理的なサンプルを（例えば、プロファイルペインおよびデータペインで）確認する。
●フローの全てのステップでのデータのクラフト視覚化。
●完成したフローをローカルで実行して、ＴＤＥまたはＣＳＶ出力などの出力を生成する（図６Ｃを参照）。
●パイプラインまたはＴＤＥの結果をカタログサーバーに公開する。
●データプレップで作成したＴＤＳ（タブローデータソース）を明示的なフローとしてインポートする。
構成済みのサーバーにアクセスすると、ユーザは次のことができる。
●ＴＤＥを他人と共有する。
●データプレップのパイプライン（フロー）を適切なセキュリティで他のユーザと共有する。
●サーバー環境でデータプレップのパイプラインを実行して、手動またはスケジュールに従ってＴＤＥを作成する。
ノードの出力は、複数の後続ノードに送信できる。ここには２つの基本的なケースが存在する。第１のケースでは、フローは発散し、元に戻ることはない。フローが収束しない場合、フローからの出力はいくつか存在する。この場合、各ブランチは事実上、ツリー内の全ての先行クエリで構成される個別のクエリである。可能な場合、実装形態により、これが最適化され、フローの共有部分が複数回実行されないようにする。
第２のケースでは、フローは収束する。意味的には、これは行が両方のパスを通過することを意味する。繰り返すが、フローの実行は概して、その前身のフローを二重に実行することはない。１つのフローでこれらの両方のケースが発生する可能性があることに留意されたい。
ユーザインターフェースにより、以下のことが可能となる。
●ユーザは、フロー内にフォークを作成できるようになる。新しいノードが追加されると、ユーザは、新しいノードが選択したノードにフォークを作成するか、既存の一連の操作の中間ノードとして挿入するかを指定することができる。例えば、現在、ノードＡからノードＢへのパスが存在し、ユーザがＡに新しいノードを挿入することを選択した場合、ユーザは、新しいノードへの第２のパスを作成するか、ＡとＢとの間に新しいノードを挿入するかを選択することができる。
●ユーザは、フロー全体ではなく、フローの個々の出力を実行することができるようになる。
ユーザは、任意の複雑なフローにフィルタを追加できる。例えば、ユーザはフローのあるポイントでクリックしてフィルタを追加し、その後、述語として機能する計算を入力することができる。一部の実装形態では、計算式はスカラー関数に制限されている。ただし、一部の実装形態では、集計、テーブル計算、詳細レベル式など、より複雑な式が有効になっている。
ユーザは、システムによって推測された場合でも、任意のフィルタを編集することができる。特に、全てのフィルタは式として表される。
プロファイルペイン３１４およびデータペイン３１５により、フィルタを作成する簡単な方法が提供される。例えば、一部の実装形態では、ユーザがデータペインの列に１つ以上のデータ値を選択し、右クリックして「保持のみ」または「除外」を選択できる。これにより、現在選択されているノードのフローにフィルタが挿入される。システムにより、フィルタを実装するための式が推測され、式が保存される。後にユーザがフィルタを変更する必要がある場合、すぐであるか、１年後であるかに関係なく、容易に変更することができる。
プロファイルペイン３１４において、ユーザは、データフィールドの値の範囲を指定するバケットを選択することができる。例えば、カテゴリフィールドの場合、この範囲は典型的に、値のリストとして指定される。数値フィールドの場合、この範囲は典型的に、上限または下限のある連続した範囲として指定される。ユーザは、バケットを選択して、フィールドの値が範囲内にある全ての行を選択（または除外）するフィルタを容易に作成することができる。
ユーザが１つの列の複数の値または１つの列の複数のバケットに基づいてフィルタを作成する場合、フィルタ式はＯＲを使用する。つまり、行が値または範囲のいずれか１つに一致する場合、その行は式に一致する。
ユーザは、データペインの単一行の複数のデータ値に基づいてフィルタを作成することもできる。この場合、フィルタ式はＡＮＤを使用する。つまり、指定された全ての値に一致する行のみが式に一致する。これは、プロファイルペインのバケットにも適用することができる。この場合、行は選択したバケット範囲の各々で一致する必要がある。
また、一部の実装形態により、２つ以上の行を含み、２つ以上の列を含む複数のデータ値に基づいてフィルタを作成することが可能となる。この場合、作成される式は選言標準形であり、各選言は選択されたデータ値を有する行の１つに対応する。一部の実装形態では、プロファイルウィンドウの範囲選択にも同じ手法が適用される。
これらのケースの各々で、ユーザはデータ値またはバケットを視覚的に選択し、簡単なジェスチャ（例えば、右クリックおよびメニュー選択）を使用して、行を選択した値のみに制限するか、選択した値を除外するフィルタを作成することに留意されたい。ユーザは、正しいブール論理で式を記述する方法を理解する必要はない。
図４Ａ～図４Ｖに関して上に示したように、ユーザは結合を作成することができる。以下の図９に示すように、宣言型実行が有効になっているかどうかによって、結合がリモートサーバーにプッシュされて実行される場合がある。
一部の実装形態では、フローの簡略化バージョンまたは要約バージョンがノードおよび注釈として提供される。一部の実装形態では、ユーザは、フルビューもしくは要約ビューを切り替えるか、または個々のノードを切り替えてノード内の詳細を非表示もしくは表示することができる。例えば、１つのノードに、特定のソースファイルのクリーンアップを実行するための１２個の操作が含まれる場合がある。クリーンアップ手順を数回繰り返した後、それらは正常に機能しており、ユーザは概して、詳細の確認を望むことはない。詳細はそのままであっても、ユーザは、ノードの要約バージョンだけを表示することで、乱雑さを隠すことができる。
一部の実装形態では、ファンアウトしない運用ノードは、ノード上の注釈にまとめて折りたたまれる。結合および分割などの操作により、追加のノードでフローが中断される。一部の実装形態では、圧縮ビューのレイアウトは自動である。一部の実装形態では、ユーザは要約ビューでノードを再配置することができる。
プロファイルペインおよびデータペインはどちらも、フローペインで現在選択されているノードに関連付けられている行のセットに関する有用な情報を提供する。例えば、プロファイルペインには、データ内の様々なデータ値（例えば、各データ値を有する行数を示すヒストグラム）のカーディナリティが表示される。複数のデータフィールドの値の分布が表示される。プロファイルペインに表示されるデータの量に起因して、データの取得は通常、非同期で実行される。
一部の実装形態では、ユーザは、プロファイルペインでデータ値をクリックして、他のアイテムの比例ブラッシングを確認することができる。ユーザが特定のデータ値を選択すると、ユーザインターフェースにより、以下が行われる。
●選択を示す。
●比例ブラッシングを使用して、そのテーブルの他の列との相関関係を示す。
●関連するデータペインをフィルタ処理または強調表示して、値が選択に一致する行のみを表示する。（これにより、データペインに表示されているデータがフィルタ処理される。フローペインにフィルタノードは作成されない。）
●プロファイルペインで複数の値が選択されている場合、選択された全ての値が表示され、それに応じてデータペインがフィルタ処理される（つまり、いずれか１つの値に一致する行にフィルタ処理される）。
一部の実装形態では、ユーザから特に要求されない限り、行はデータペインに表示されない。一部の実装形態では、データペインは常に自動的に入力され、プロセスは非同期で進行する。一部の実装形態では、選択したノードの行のカーディナリティに基づいて異なる規格が適用される。例えば、一部の実装形態では、カーディナリティが閾値を下回っている場合に行を表示し、カーディナリティが閾値を上回っている場合は行を表示しないか、非同期で続行する。一部の実装形態では、２つの閾値を指定して、行のセットを小、大、または特大に指定する。一部の実装形態では、インターフェースは小さいカーディナリティの行を表示し、大きいカーディナリティの行を非同期に表示し、非常に大きいカーディナリティの結果を表示しない。無論、データペインには、少数の行しか表示することはできない。これは通常、サンプリングによって（例えば、ｎ行ごとに）選択される。一部の実装形態では、データペインにより、不明な量のデータに対応するために無限スクロールが実装される。
開示されたデータプレップアプリケーションにより、ユーザインターフェースがネイティブに読み取り、変更し、操作するドキュメントモデルが提供される。このモデルは、ＵＩのフォーマットを提供しながら、ユーザへのフローを記述する。このモデルは、ＡＱＬとフェデレーションエバリュエータを使用して、実行するタブローモデルに変換することができる。このモデルは、信頼性の高いキャッシュおよび中間結果の再利用も可能にする。
図７Ａに示すように、データモデルには３つのサブモデルが含まれ、サブモデルの各々は評価の適切な段階でのフローを記述する。第１のサブモデルは「Ｌｏｏｍ Ｄｏｃ」７０２である。（一部の実装形態では、データプレップアプリケーションを「Ｌｏｏｍ」と称する。）
Ｌｏｏｍ ｄｏｃ７０２は、フローを説明するモデルであり、フローは、ユーザが直接確認して操作するフローである。Ｌｏｏｍ ｄｏｃ７０２には、全てのＥＴＬ操作および型チェックを実行するために必要な全ての情報が含まれている。典型的に、Ｌｏｏｍ ｄｏｃ７０２には、フローのレンダリングまたは編集に純粋に必要な情報は含まれていない。Ｌｏｏｍ ｄｏｃ７０２はフローとして構築される。各操作には次のものがある。
●操作の実行方法を説明する一連のプロパティ。
●操作を実行するデータを説明するゼロ以上の入力。
●この操作の結果のデータを説明するゼロ以上の出力。
操作には、入力操作、変換操作、出力操作、およびコンテナ操作の４つの主要な型が存在する。
入力操作は、ＥＴＬの「抽出」部分を実行する。これらはフローをデータソースにバインドし、そのソースからデータをプルしてそのデータをフローに公開するように構成されている。入力操作には、ＣＳＶファイルの読み込みまたはＳＱＬデータベースへの接続が含まれる。入力操作のノードは、典型的に、入力がゼロであり、少なくとも１つの出力を有する。
変換操作は、ＥＴＬの「変換」部分を実行する。これらは、データのストリームに対して「機能的」操作を提供し、それを変換する。変換操作の例には、「計算を’［ＨｏｓｐｉｔａｌＮａｍｅ］－［Ｙｅａｒ］’として作成」、「ｈｏｓｐｉｔａｌＩｄ＝’ＨａｒｂｏｕｒＶｉｅｗ’を有する行をフィルタ処理する」などが挙げられる。変換ノードには、少なくとも１つの入力および少なくとも１つの出力がある。
出力操作は、ＥＴＬの「読み込み」部分を提供する。これらは、到着するデータストリームでダウンストリームデータソースを実際に更新するという副次的な役割を担っている。これらのノードには１つの入力があり、出力はない（フロー内の後続のノードへの「出力」はない）。
コンテナ操作は、他の操作を論理グループにグループ化する。これらは、フローのドキュメント化を容易にするために使用される。コンテナ操作は、フローペインの「ノード」としてユーザに公開される。各コンテナノードには、他のフロー要素（例えば、一連の通常のノード）と、ドキュメント用のフィールドとが含まれている。コンテナノードは、任意の数の入力と任意の数の出力とを有することができる。
データストリームは、あるノードから別のノードへとフローを横切って移動するデータの実際の行を表す。論理的には、これらは行として表示することができるが、操作上、データストリームは様々な方法で実装することができる。例えば、一部のフローは、単純にＡＱＬ（分析クエリ言語）にコンパイルされる。
拡張可能な操作とは、データプレップアプリケーションでは評価方法が直接知られていない操作のことであり、サードパーティのプロセスまたはコードを呼び出すものである。これらは、フェデレーションエバリュエータの一部としては実行されない操作である。
論理モデル７０４は、全てのエンティティ、フィールド、関係性、および制約を含むモデルである。これは、フローを実行することによって構築され、フローの任意の部分で構築されるモデルを定義する。論理モデルのフィールドは、結果の列である。一部のエンティティは、他のエンティティで構成されているが、論理モデルのエンティティは、結果のテーブルを表す。例えば、ユニオンには、他のエンティティの結果であるエンティティがある。論理モデルの制約は、フィルタなどの追加の制約を表す。論理モデルの関係性は、エンティティ間の関係性を表し、それらを組み合わせるのに十分な情報を提供する。
第３のサブモデルは、物理モデル７０６である。物理モデルには、フローを再実行する必要があるかどうかを識別する情報、ならびに結果データベースにフローを直接照会する方法など、キャッシュ用のメタデータが含まれている。メタデータには次のものが含まれる。
●このポイントでの論理モデルのハッシュ。
●各ルートデータソースのタイムスタンプ、および最後にクエリされた日時。
●結果データの場所を説明するパスまたはＵＲＩ。
このデータは、フローを最適化するだけでなく、より高速な結果のナビゲーションを可能にするために使用される。
物理モデルには、この物理モデルの作成に使用される論理モデルへの参照（ファイルまたはデータストアへのポインタなど）が含まれる。物理モデル７０６はまた、モデルを評価するために使用されるデータソースを識別するタブローデータソース（ＴＤＳ）を含む。典型的に、これは論理モデル７０４から生成される。
物理モデルには、指定されたデータソースからデータを抽出するために使用されるＡＱＬ（分析クエリ言語）クエリも含まれている。
図７Ａに示されるように、ｌｏｏｍ ｄｏｃ７０２は、論理モデル７０４を形成するためにコンパイルされ（７２２）、論理モデル７０４は、物理モデルを形成するために評価される（７２４）。
図７Ｂは、一部の実装形態によって使用されるファイルフォーマット７１０を示している。ファイルフォーマット７１０は、ローカル実行およびリモート実行の両方で使用される。ファイルフォーマットにはデータおよびフローの両方が含まれていることに留意されたい。場合によっては、フローはコピー／貼り付けを実行してデータを作成することがある。このような場合、データはフローの一部になる。ファイルフォーマットは、基になるフローとは別に、ＵＩ状態を保持する。一部のディスプレイはアプリケーションとともに保存される。レイアウトの他の部分はユーザ固有であり、アプリケーションの外部に保存される。ファイルフォーマットは、バージョン管理することができる。
ファイルフォーマットには、マルチドキュメントフォーマットがある。一部の実装形態では、図７Ｂに示すように、ファイルフォーマットには３つの主要な部分がある。一部の実装形態では、ファイルフォーマット７１０は、編集情報７１２を含む。このセクションは、デバイス間および編集セッション間で編集エクスペリエンスを継続させる役割を担っている。このセクションには、フローの評価には必要ないが、ユーザのＵＩを再構築するために必要なデータが格納される。編集情報７１２は、アンドゥ（Ｕｎｄｏ）履歴を含んでおり、アンドゥ履歴には、編集セッションが閉じられ、再び開かれた後にユーザが操作を元に戻すことを可能にする永続的なアンドゥバッファが含まれる。編集情報には、表示されているペイン、フローノードのｘ／ｙ座標など、フローの実行方法に反映されていないＵＩ状態も含まれる。ユーザがＵＩを再度開くと、ユーザは過去にあったものを確認することができるため、作業を再開しやすくなる。
ファイルフォーマット７１０は、図７Ａに関して上で説明したように、Ｌｏｏｍ Ｄｏｃ７０２を含む。これは、必要とされるファイルフォーマットの唯一のセクションである。このセクションにはフローが含まれている。
ファイルフォーマット７１０はまた、ローカルデータ７１４を含み、ローカルデータ７１４は、フローを実行するために必要な任意のテーブルまたはローカルデータを含む。このデータは、ＨＴＭＬテーブルをデータプレップアプリケーションに貼り付けるなどのユーザインタラクションを通じて作成することができるか、またはフローが評価のためにサーバーにアップロードする必要があるローカルＣＳＶファイルを使用する場合に作成することができる。
評価サブシステムを図７Ｃに示す。評価サブシステムにより、フローを評価するための信頼できる方法が提供される。評価サブシステムにより、過去の実行の結果を操作するか、またはフローの操作の上に操作を重ねる簡単な方法も提供される。加えて、評価サブシステムは、フローの後半部分を実行するときに、フローの一部からの結果を再利用する自然な方法を提供する。評価サブシステムにより、キャッシュされた結果に対して実行するための高速な方法も提供される。
図７Ｃに示すように、フローを評価するための２つの基本的なコンテキストが存在する。フローを実行（７４０）すると、プロセスはフローを評価し、結果を出力ノードに流し込む。デバッグモードで実行している場合、プロセスは、一時データベースに結果を書き込み、一時データベースは、ナビゲーション、分析、および部分フローの実行を高速化するために使用することができる。
ナビゲーションおよび分析（７３０）では、ユーザはデータセットを調査している。これには、データ分布の確認、ダーティデータの検索などが含まれる。これらのシナリオでは、エバリュエータは概して、フロー全体の実行を回避し、代わりに、過去のフローの実行から作成された一時データベースに対して直接、より高速なクエリを実行する。
これらのプロセスは、スマートキャッシングの決定が可能であることを確認するために、キャッシングに関する優れたメタデータを利用する。
図７Ｄに示すように、一部の実装形態には非同期サブシステムが含まれている。非同期サブシステムは、ユーザに非ブロッキング動作を提供する。ユーザが行の取得を必要としない操作を大量に行っている場合、ユーザは行の取得をブロックされない。非同期サブシステムにより、増分的結果が提供される。多くの場合、ユーザは、結果の検証または理解を開始するためにデータの完全なセットを必要としない。このような場合、非同期サブシステムにより、到着時に最良の結果が得られる。非同期サブシステムは、進行中のクエリに対して信頼性の高い「キャンセル」操作も提供する。
一部の実装形態では、非同期モデルには、４つの主要コンポーネントが含まれている。
●ブラウザレイヤー。このレイヤーは、開始する非同期タスクからＵＵＩＤおよび更新バージョンを取得する。次に、ＵＵＩＤを使用して更新を取得する。
●ＲＥＳＴ ＡＰＩ。このレイヤーは、スレッドプールでタスクを開始する。スレッドプール内のタスクは、更新を取得するとステータスサービスを更新する。ブラウザレイヤーは、更新があるかどうかを知りたい場合、ＲＥＳＴ ＡＰＩプロシージャを呼び出して最新のステータスを取得する。
●ＡｑｌＡＰＩ。このレイヤーは、あたかもコールバックを含む同期呼び出しのように呼び出される。呼び出しは、基になる要求が終了したときにのみ終了する。ただし、コールバックでは、行がすでに処理された状態でステータスサービスを更新することができる。これにより、ユーザに段階的な進行状況を提供することができる。
●フェデレーションエバリュエータ。ＡｑｌＡｐｉは、新しいプロセスとして実行されるため、非同期の別のレイヤーを提供するフェデレーションエバリュエータを呼び出す。
キャンセル操作の実装形態は、キャンセルが発生する場所によって異なる。ブラウザレイヤーでは、容易にキャンセル要求を送信して、結果のポーリングが停止される。ＲＥＳＴ ＡＰＩでは、実行中のスレッドにキャンセルイベントを容易に送信することができる。
一部の実装形態では、フローがすでに作成された後、フローを安全かつ容易に「リファクタリング」することができる。現在のＥＴＬツールでは、最初は単純に見えても、規模が大きくなると変更できなくなるようなフローを作ることができる。これは、変更がフローにどのように影響するかを人々が理解するのが難しく、動作のチャンクをビジネス要件に関連する断片に分割するのが難しいためである。これの多くはユーザインターフェースが原因であるが、基盤となる言語では、ＵＩに必要な情報を提供する必要がある。
開示された実装形態により、ユーザは容易にリファクタリングできるフローを作成することができる。これは、ユーザが操作またはノードを容易に実行することができることを意味する。
●操作を移動し、論理的に並べ替える。実装形態により、これらの操作がエラーを作成するかどうかについて直接フィードバックが提供される。例えば、ユーザがＡＤＤ＿ＣＯＬＵＭＮ－＞ＦＩＬＴＥＲのフローを有するとする。ＦＩＬＴＥＲが追加された列を使用しない限り、ユーザはＡＤＤ＿ＣＯＬＵＭＮノードの前にＦＩＬＴＥＲノードをドラッグすることができる。ＦＩＬＴＥＲが新しい列を使用する場合、インターフェースは即座にエラーを発生し、ユーザに問題を通知する。
●複数の操作およびノードを１つの新しいノード（再利用可能）にまとめる。この新しいノードには、受け入れる「型」と返される「型」がある。例えば、ユーザがＪＯＩＮ＿ＴＡＢＬＥＳ－＞ＡＬＴＥＲ＿ＣＯＬＵＭＮ－＞ＡＬＴＥＲ＿ＣＯＬＵＭＮ－＞ＡＬＴＥＲ＿ＣＯＬＵＭＮを含むフローのスニペットを有しているとする。実装形態により、ユーザはこれらの４つのステップを１つのノードに組み合わせて、ノードに「ＦＩＸＵＰ＿ＣＯＤＥＳ」などの意味のある名前を割り当てることができる。新しいノードは２つのテーブルを入力として受け取り、テーブルを返す。入力テーブルの型には、それらが結合された列と、ＡＬＴＥＲ＿ＣＯＬＵＭＮＳで使用されることになった任意の列とが含まれる。出力テーブルの型は、操作の結果として生じる型である。
●ノードから操作を分割する。ここでは、ユーザは、即時操作中にノードに有機的に追加された操作を再編成することができる。例えば、ユーザが２０の操作を有する巨大なノードを有していて、病院コードの修正に関連する１０の操作を独自のノードへの分割を望んでいるとする。ユーザはそれらのノードを選択し、それらをプルすることができる。削除される操作に依存する他の操作がノードにある場合、システムはエラーを表示し、ＦｉｘｕｐＨｏｓｐｉｔａｌＣｏｄｅｓノードの後に新しいノードを作成する修正を提案する。
●既存のノードへのインライン化操作。ユーザがクリーニングを行った後、フローの別の部分に属する作業が行われる場合がある。例えば、ユーザが保険コードをクリーンアップすると、病院コードにいくつかの問題が見つかり、クリーンアップする。次に、ユーザは、病院コードのクリーンアップをＦｉｘｕｐＨｏｓｐｉｔａｌＣｏｄｅｓノードに移動したいと考えている。これは、簡単なドラッグアンドドロップ操作を使用して実行される。ユーザが、依存する操作の前にフロー内の場所に操作をドロップしようとすると、インターフェースにより、提案されたドロップ場所が機能しないことが即座に視覚的にフィードバックされる。
●型を変更して、フローの一部が壊れていないか直ちに確認する。ユーザは、フローを使用してから、列のうちの１つの型を変更することを決定することができる。実装形態により、フローを実行する前であっても、問題があれば直ちにユーザに通知される。
一部の実装形態では、ユーザがフローをリファクタリングしているときに、システムは、ドロップターゲットを識別することで支援を行う。例えば、ユーザがノードを選択してフローペイン内でドラッグし始めた場合、一部の実装形態では、ノードを移動させることができる場所が（例えば、強調表示されて）表示される。
開示されたデータプレップアプリケーションは、次の３つの態様を有する言語を使用する。
●式言語。これは、ユーザが計算を定義する方法である。
●データフロー言語。これは、ユーザがフローの入力、変換、関係性、および出力を定義する方法である。これらの操作は、データモデルを直接変更する。この言語の型は、個々の列ではなく、エンティティ（テーブル）および関係性である。ユーザはこの言語を直接確認することはないが、ＵＩでノードと操作を作成することで間接的に使用する。例としては、テーブルの結合および列の削除などが挙げられる。
●制御フロー言語。これらはデータフローの周囲で発生し得る操作であるが、実際にはデータフローではない。例えば、ファイル共有からｚｉｐをコピーして解凍すること、書き出されたＴＤＥを取得して共有にコピーすること、データソースの任意のリストに対してデータフローを実行するなどが挙げられる。
これらの言語は異なるが、互いに重なり合っている。式言語はフロー言語によって使用され、フロー言語は制御フロー言語によって使用できる。
この言語は、図８Ａに示すように、論理的に左から右に進む操作のフローを記述する。ただし、フローの評価方法により、実際の実装形態では、パフォーマンスを向上させるために操作を再配置できる。例えば、データの抽出時にフィルタをリモートデータベースに移動すると、全体的な実行速度を大幅に向上させることができる。
データフロー言語は、ＥＴＬに直接影響するフローおよび関係性を記述するため、大部分の人がデータプレップアプリケーションに関連付けている言語である。言語のこの部分には、モデルおよびノード／操作の２つの主要なコンポーネントがある。これは、標準のＥＴＬツールとは異なる。データを直接操作するフロー（例えば、「フィルタ」操作から「フィールドの追加」操作への実際の行のフロー）の代わりに、開示されたフローは、作成するものを指定する論理モデルと、論理モデルを具現化する方法を定義する物理モデルとを定義する。この抽象化により、最適化に関してより多くの余裕が提供される。
モデルは、基本的な名詞である。モデルは、操作されているデータのスキーマおよび関係性を記述する。上記のように、論理モデルおよび個別の物理モデルが存在する。論理モデルは、特定のポイントでのフローの基本的な「型」を提供する。変換されるデータを説明するフィールド、エンティティ、および関係性について説明する。このモデルには、セットおよびグループなどが含まれる。論理モデルは、必要なものを指定するが、具現化は指定しない。このモデルのコアパーツは次のとおりである。
●フィールド：出力のデータフィールドに変換される（または計算を支援する）実際のフィールドである。各フィールドは、エンティティおよび式に関連付けられている。フィールドは必ずしも全てが表示されている必要はない。フィールドには、物理フィールド、計算フィールド、および一時フィールドの３つの型がある。物理フィールドは、結果のデータセットに具現化される。これらは、適切なフィールドまたは計算のいずれかである。計算フィールドは、結果のＴＤＳに計算フィールドとして書き込まれるため、具現化されることはない。一時フィールドは、物理フィールドの計算をより良好に行うために作成される。それらは決して書き出されない。一時フィールドが計算フィールドによって参照されている場合、言語により警告が発行され、このフィールドは計算フィールドとして扱われる。
●エンティティ：論理モデルの名前空間を記述するオブジェクトである。エンティティは、テーブルのスキーマが到着することによって作成されるか、関係性によって一緒に関連付けられているエンティティのコレクションで構成することができる。
●関係性：様々なエンティティが互いにどのように関係しているかを説明するオブジェクトである。これらを使用して、複数のエンティティを新しい複合エンティティに組み合わせることができる。
●制約：エンティティに追加される制約について説明する。制約には、エンティティの結果を実際に制限するフィルタが含まれる。いくつかの制約が適用されている。強制制約は、一意制約またはｎｕｌｌ以外の制約など、アップストリームソースから保証される。いくつかの制約が表明されている。これらは、真であると信じられている制約である。データがこの制約に違反していることが判明した場合は常に、何らかの方法でユーザに通知される。
フローには、論理モデルに１つ以上のフォークを含めることができる。フローのフォークは、各フォークに同じ論理モデルを使用する。ただし、フォークの両側のカバーの下に新しいエンティティがある。これらのエンティティは、列が投影または削除されない限り、基本的に元のエンティティに渡される。
新しいエンティティを作成する理由の１つは、エンティティ間の関係性を追跡することである。これらの関係性は、どのフィールドが変更されない場合でも引き続き有効である。ただし、フィールドが変更されると、それは新しいエンティティの新しいフィールドになるため、関係性が機能しなくなったことがわかる。
一部の実装形態では、ノードまたは操作を固定できる。フローは一連の操作の論理的な順序を記述するが、システムは、物理的な順序を異なるものにすることで処理を自由に最適化できる。ただし、ユーザは、論理的順序と物理的順序とが完全に同じであることを確認したい場合がある。かかる場合、ユーザはノードを「固定」することができる。ノードが固定されると、システムは、固定前の操作が固定後の操作の前に物理的に発生することを保証する。場合によっては、これは何らかの形態の具現化をもたらす。ただし、システムは可能な限りこれを介してストリーミングする。
物理モデルは、特定のポイントでの論理モデルの具現化を記述する。各物理モデルは、それを生成するために使用された論理モデルへの参照を有する。物理モデルは、キャッシング、増分フロー実行、および読み込み操作にとって重要である。物理モデルには、フローの結果を含むファイルへの参照が含まれる。これは、このポイントまでの論理モデルを説明する一意のハッシュである。物理モデルは、実行用に生成されたＴＤＳ（タブローデータソース）およびＡＱＬ（分析クエリ言語）も指定する。
ノードおよび操作は、基本的な動詞である。モデル内のノードには、データの整形、計算、およびフィルタ処理の方法を定義する操作が含まれている。ＵＩ言語との一貫性を保つために、「操作」という用語は、何かを実行するフロー内の「ノード」の１つを指す。ノードは、操作を含むコンテナを参照し、ＵＩのフローペインにユーザに表示されるものにマップするために使用される。各特殊なノード／操作には、操作方法を説明するプロパティが関連付けられている。
ノードには、入力操作、変換操作、出力操作、およびコンテナノードの４つの基本的な型がある。入力操作は、外部ソースから論理モデルを作成する。例として、ＣＳＶをインポートする操作が挙げられる。入力操作は、ＥＴＬのＥ（抽出）を表す。変換操作は、論理モデルを新しい論理モデルに変換する。変換操作は論理モデルを取り込んで、新しい論理モデルを返す。変換ノードは、ＥＴＬのＴ（変換）を表す。例として、既存の論理モデルに列を追加するプロジェクト操作が挙げられる。出力操作は論理モデルを取り込んで、それを他のデータストアに具現化する。例えば、論理モデルを取得し、その結果をＴＤＥに具現化する操作である。これらの操作は、ＥＴＬのＬ（読み込み）を表す。コンテナノードは、フロー全体で構成がどのように行われるかに関する基本的な抽象化であり、ノードがＵＩに表示されるときに表示される内容の抽象化も提供する。
図８Ｂに示すように、型システムは３つの主要な概念で構成されている。
●操作はアトミックアクションであり、それぞれに入力ならびに出力、および必須のフィールドセットがある。
●必須フィールドは、操作に必要なフィールドである。必須フィールドは、空の型環境で操作を評価し、「想定される」フィールドのいずれかを収集することによって決定することができる。
●型環境（Ｔｙｐｅ Ｅｎｖｉｒｏｎｍｅｎｔ）は、フロー内の特定のポイントの型を検索する方法を決定する構造である。フローグラフの各「エッジ」は、型環境を表す。
型チェックは２段階で実行される。型環境の作成フェーズでは、システムはフローの方向にフローを実行する。システムにより、各ノードに必要な型と、ノードが出力する型環境とが把握される。フローが抽象的である場合（例えば、実際にはどの入力ノードにも接続しない場合）、空の型環境が使用される。型の改良は第２の段階である。このフェーズでは、システムは最初のフェーズから型環境を取得し、それらを「逆方向」にフローして、型環境の作成で発生した型のナローイングによって型の競合が発生したかどうかを確認する。このフェーズでは、システムはサブフロー全体に必要な一連のフィールドも作成する。
各操作には、型環境が関連付けられている。この環境には、アクセス可能な全てのフィールドおよびその型が含まれている。図８Ｃに示すように、型環境には５つのプロパティがある。
環境は「オープン（Ｏｐｅｎ）」または「クローズ（Ｃｌｏｓｅｄ）」のいずれかであり得る。環境がオープンの場合、未知のフィールドがあり得ると想定される。この場合、不明なフィールドは全て型であると見なされる。これらのフィールドは、想定型（ＡｓｓｕｍｅｄＴｙｐｅｓ）フィールドに追加される。環境がクローズである場合、環境は全てのフィールドが既知であると想定されるため、未知のフィールドは全て失敗となる。
既知の型は全て型（Ｔｙｐｅｓ）メンバーにある。これは、フィールド名からその型へのマッピングである。型は、別の型環境にすることができるか、またはフィールドにすることができる。フィールドは最も基本的な型である。
各フィールドは２つの部分で構成されている。ｂａｓｉｃＴｙｐｅｓは、フィールドの可能な型のセットを説明する型のセットである。このセットに要素が１つしかない場合は、その型が判明する。セットが空の場合、型エラーが発生する。セットに複数の要素がある場合、複数の可能な型が存在する。システムは、必要に応じて解決し、さらに型のナローイングを行うことができる。ｄｅｒｉｖｅｄＦｒｏｍは、これを派生させるために使用されたフィールドへの参照である。
スコープ内の各フィールドには、潜在的な型のセットがある。各型は、ブール値、文字列、整数、１０進数、日付、日時、倍精度浮動小数点数、ジオメトリ、および期間の任意の組み合わせであり得る。「Ａｎｙ」型も存在する。これは、任意の型の省略形である。
オープン型環境の場合、存在しないことが判明しているフィールドである場合がある。例えば、「ｒｅｍｏｖｅＦｉｅｌｄ」操作の後、システムは、型環境の全てのフィールドを（オープンであるために）認識しない可能性があるが、システムは、削除されたばかりのフィールドが存在しないことは認識している。型環境のプロパティ「非存在（ＮｏｔＰｒｅｓｅｎｔ）」は、かかるフィールドを識別するために使用される。
ＡｓｓｕｍｅｄＴｙｐｅｓプロパティは、定義されているために追加された型ではなく、参照されているために追加された型のリストである。例えば、オープン型環境で評価される式［Ａ］＋［Ｂ］がある場合、システムはＡおよびＢの２つのフィールドがあると想定する。ＡｓｓｕｍｅｄＴｙｐｅｓプロパティを使用すると、システムはこの方法で追加された内容を追跡できる。これらのフィールドをロールアップして、さらに型を選別し、ならびにコンテナに必要なフィールドを決定することができる。
「過去（Ｐｒｅｖｉｏｕｓ）」型環境プロパティは、これが派生した型環境への参照である。これは、型の不整合を探すフローを逆方向にトラバースするときに、型の改良段階で使用される。
型環境はまた、構成することができる。これは、複数の入力を受信する操作で発生する。型環境がマージされると、各型環境がその型のコレクションの値にマッピングされる。その後、さらなる型ソリューションが個々の型環境に委任される。次に、オペレータがこの型環境を出力型環境に変換する役割を担う。多くの場合、型環境を何らかの方法で「フラット化」して、型としてフィールドのみを有する新しい型環境を作成する。
これは、Ｊｏｉｎ演算子およびＵｎｉｏｎ演算子によって使用され、様々な環境の全てのフィールドを独自の式で正確に使用し、環境を出力型環境にマップする方法を提供する。
入力ノードによって作成された型環境は、それが読み取っているデータソースによって返されるスキーマである。ＳＱＬデータベースの場合、これは、抽出するテーブル、クエリ、ストアドプロシージャ、またはビューのスキーマになる。ＣＳＶファイルの場合、これは、ユーザが列に関連付けた型に関係なく、ファイルからプルされるスキーマになる。各列およびその型は、フィールド／型マッピングに変換される。加えて、型環境はクローズとしてマークされる。
変換ノードの型環境は、その入力の環境である。複数の入力がある場合は、それらをマージして、操作の型環境を作成する。出力は、演算子に基づく単一型環境である。図８Ｊ－１～図８Ｊ－３の表に、多くの操作が示されている。
コンテナノードは複数の入力を有し得るため、その型環境は、適切な子型環境を適切な出力ノードにルーティングする複合型環境になる。コンテナをプルして再利用すると、入力ごとに空の型環境で解決され、依存関係が判別される。
一部の実装形態では、コンテナノードは、２つ以上の出力を有することができる唯一の型のノードである。この場合、複数の出力型環境が存在する可能性がある。これは、どのノードでも発生する可能性がある出力の分岐と混同してはならない。ただし、出力を分岐する場合、出力エッジの各々は同じ型環境になる。
システムがフィールドの競合する要件を検出したときに、型エラーにフラグが立てられる場合がいくつか存在する。この段階は、入力が制限されていないフローで発生する可能性があるため、未解決のフィールドはこの段階ではエラーとして扱われない。ただし、ユーザがフローを実行しようとすると、未解決の変数が問題として報告される。
入力の多くには、型の特定の定義がある。例えば、特定の定義には、ＶＡＲＣＨＡＲ（２０００）の代わりにＣＨＡＲ（１０）を使用すること、フィールドが使用する照合、または１０進型のスケールおよび精度が含まれる。一部の実装形態では、これらを型システムの一部として追跡しないが、ランタイム情報の一部として追跡する。
ＵＩおよび中間層は、ランタイム型で取得できる。この情報は、通常のコールバックを通過するだけでなく、（例えば、システムがキャッシュされた実行からデータを入力している場合に）ｔｅｍｐｄｂの型に埋め込まれる。ＵＩは、より具体的な既知の型をユーザに表示するが、それらに基づく型チェックは行わない。これにより、より具体的な型を使用するＯｕｔｐｕｔＮｏｄｅを作成することができると同時に、システムの他の部分がより単純化された型を使用することができるようになる。
図８Ｄは、既知の全てのデータ型のフローに基づく単純な型チェックを示している。図８Ｅは、完全に既知の型による単純な型の失敗を示している。図８Ｆは、部分フローの単純な型環境計算を示している。図８Ｇは、パッケージ化されたコンテナノードの型を示している。図８Ｈは、より複雑な型環境シナリオを示している。図８Ｉは、より複雑な型環境シナリオの再利用を示している。
一部の実装形態では、データ型を推測し、推測されたデータ型を使用してデータフローを最適化または検証する。これは、ＸＬＳファイルまたはＣＳＶファイルなどのテキストベースのデータソースに特に役立つ。フローの後半でデータ要素がどのように使用されるかに基づいて、データ型を推測し得る場合があり、推測されたデータ型をフローの早い段階で使用できる。一部の実装形態では、テキスト文字列として受信したデータ要素を、データソースから取得した直後に適切なデータ型としてキャストすることができる。場合によっては、データ型の推測は再帰的である。つまり、１つのデータ要素のデータ型を推測することにより、システムは、１つ以上の追加のデータ要素のデータ型を推測できる。場合によっては、データ型の推測により、正確なデータ型（例えば、データ要素が数値であると判別しても、整数であるか、または浮動小数点数であるかを判別することができない型）を判別せずに１つ以上のデータ型を除外できる。
大部分の型エラーは、型チェック段階で発見される。これは、初期型環境を計算した直後に行われ、各型について既知であることに基づいてスコープが調整される。
このフェーズは、全ての端末の型環境から開始する。型環境ごとに、システムは過去の環境に戻る。プロセスは、閉じた環境または過去の環境がない環境に到達するまで戻る。次に、プロセスは、各環境の型をチェックして、型が異なるフィールドがあるかどうかを判別する。その場合、それらの共通部分がｎｕｌｌの場合、プロセスは型エラーを発生させる。いずれかのフィールドの型が異なり、共通部分がｎｕｌｌでない場合、プロセスは、型を共通部分に設定し、影響を受けるノードの型環境が再計算される。加えて、「想定」されている型は全て過去の型環境に追加され、型環境が再計算される。
いくつかの仔細な点が追跡される。まず、ユーザはフィールドを別の任意の型で上書きすることができるため、フィールド名自体は必ずしも一意ではない。その結果、プロセスは、型からそれを生成するために使用された型へのポインタを使用し、それによってグラフの異なる部分で同じ名前に解決される無関係なものに惑わされないようにしている。例えば、フィールドＡの型が［ｉｎｔ，ｄｅｃｉｍａｌ］であるが、Ａを文字列にするプロジェクトを実行するノードがあるとする。過去のバージョンのＡに戻って、型が機能しないと言うことはエラーになる。代わりに、このポイントでのバックトラックは、ａｄｄＦｉｅｌｄ操作を過ぎてもＡをバックトラックしない。
型チェックにより、一度に１つの変数がナローイングされる。上記のステップでは、既知の変数を再計算する前に、型チェックが１つの変数にのみ適用される。これは、Ｆｕｎｃｔｉｏｎ１（ｓｔｒｉｎｇ，ｉｎｔ）およびＦｕｎｃｔｉｏｎ１（ｉｎｔ，ｓｔｒｉｎｇ）など、複数のシグニチャを有するオーバーロードされた関数がある場合に安全である。これがＦｕｎｃｔｉｏｎ１（［Ａ］，［Ｂ］）として呼び出されたとする。プロセスは、型がＡ：［Ｓｔｒｉｎｇ，ｉｎｔ］およびＢ：［Ｓｔｒｉｎｇ，ｉｎｔ］であると判別する。ただし、ＡがＳｔｒｉｎｇの場合、Ｂはｉｎｔである必要があるため、型がＡ：［Ｓｔｒｉｎｇ］およびＢ：［Ｓｔｒｉｎｇ］に解決されることは無効である。一部の実装形態では、型をナローイングするたびに型環境の計算を再実行することで、この型の依存関係を処理する。
一部の実装形態では、ナローイングされた変数を含む必須フィールドが実際にあるノードでのみ作業を行うことにより、実行する作業を最適化する。ここにはわずかに仔細な点が存在する。Ａを狭くすると、Ｂも狭くなる可能性がある。上記のＦｕｎｃｔｉｏｎ１の例を参照されたい。かかる場合、システムはＢがいつ変更されたかを認識し、そのナローイングもチェックする必要がある。
オペレータがどのように動作するかを確認する場合、ここでは「オープン（Ｉｓ Ｏｐｅｎ）」、「マルチ入力（Ｍｕｌｔｉ－Ｉｎｐｕｔ）」、「入力型（Ｉｎｐｕｔ Ｔｙｐｅ）」、「結果型（Ｒｅｓｕｌｔｉｎｇ Ｔｙｐｅ）」として識別される４つの主要なプロパティの観点からそれらを考えるのが最善である。
操作は、列を通過するときにオープンとして指定される。例えば、「フィルタ」はオープン操作である。これは、入力にある全ての列が出力にも含まれるためである。集計またはグループ化されていない列は結果の型に含まれないため、Ｇｒｏｕｐ ｂｙはオープンではない。
「マルチ入力」プロパティは、この操作が複数の入力エンティティを受信するかどうかを指定する。例えば、結合は２つのエンティティを取り、それらを１つにするため、マルチ入力である。ユニオンは、マルチ入力の別の操作である。
「入力型」プロパティは、ノードに必要な型を指定する。マルチ入力操作の場合、これは各入力に独自の型が含まれる複合型である。
「結果型」プロパティは、この操作の結果として生じる出力型を指定する。
図８Ｊ－１、図８Ｊ－２、および図８Ｊ－３の表は、最も一般的に使用される多くの演算子のプロパティを示している。
多くの場合、フローは、ニーズの変化に応じて時間の経過とともに作成される。フローが有機的な進化によって成長する場合、それは大きくて複雑になる可能性がある。ユーザは、変化するニーズに対応するため、またはフローを再編成して理解しやすくするために、フローを変更する必要があり得る。かかるフローのリファクタリングは、多くのＥＴＬツールでは困難または不可能である。
本実装形態は、リファクタリングを可能にするだけでなく、ユーザがリファクタリングを行うのを支援する。ある技術レベルでは、システムは任意のノード（またはノードのシーケンス）のＲｅｑｕｉｒｅＦｉｅｌｄｓを取得し、それに対応できる型環境を有する任意のポイントでドロップターゲットを点灯させることができる。
別のシナリオでは、フロー内の既存のノードが再利用される。例えば、ユーザが一連の操作を実行してカスタムノードの作成を望んでいるとする。カスタムノードは、「保険コードの正規化」を行うように動作する。ユーザは、複数の操作を含むコンテナノードを作成することができる。その後、システムはそれに必要なフィールドを計算することができる。ユーザは、ｓａｖｅコマンドを使用するか、コンテナノードを左側ペイン３１２にドラッグすることにより、将来の使用のためにノードを保存することができる。ここで、左側ペインのパレットからノードを選択すると、システムがフロー内のドロップターゲットを点灯し、ユーザは、（例えば、上記のリファクタリングの例のように）ノードをドロップターゲットの１つにドロップすることができる。
ＥＴＬは煩雑になる可能性があるため、本実装形態により、様々なシステム拡張機能が可能になる。拡張機能として、以下が挙げられる。
●ユーザ定義のフロー操作。ユーザは、入力、出力、および変換操作を使用してデータフローを拡張することができる。これらの操作では、カスタムロジックまたは分析を使用して、行の内容を変更することができる。
●制御フロースクリプト。ユーザは、共有からのファイルのダウンロード、ファイルの解凍、ディレクトリ内の全てのファイルのフローの実行など、データフロー以外の操作を実行するスクリプトを構築することができる。
●コマンドラインスクリプト。ユーザはコマンドラインからフローを実行することができる。
本実装形態は、提供された拡張性を人々がどのように使用するかという点で、言語に依存しないアプローチを採用している。
最初の拡張機能により、ユーザは、フローに適合するカスタムノードを構築することができる。拡張ノードの作成には、次の２つの部分がある。
●出力の型を定義する。例えば、「新しい列「ｆｏｏ」だけでなく、到着する全てのもの」などである。
●実際に変換を実行するためのスクリプトまたは実行可能ファイルを提供する。
一部の実装形態では、ユーザ定義の拡張を可能にする２つのノード型を定義している。「ＳｃｒｉｐｔＮｏｄｅ」は、ユーザが行を操作してそれらを返すためのスクリプトを記述できるノードである。システムはＡＰＩ関数を提供する。その後、ユーザは変換（または入力または出力）ノードをスクリプトとして（ＰｙｔｈｏｎまたはＪａｖａｓｃｒｉｐｔ（登録商標）などで）作成することができる。「ＳｈｅｌｌＮｏｄｅ」は、ユーザが実行する実行可能プログラムを定義し、行を実行可能ファイルにパイプすることができるノードである。次に、実行可能プログラムにより、結果がｓｔｄｏｕｔに書き込まれ、エラーがｓｔｄｅｒｒに書き込まれ、完了したら終了される。
ユーザがフローの拡張機能を作成する場合、内部処理はより複雑になる。全てを１つのＡＱＬステートメントにコンパイルする代わりに、プロセスは評価をカスタムノードの周りの２つの部分に分割し、最初の部分からの結果をノードに送信する。これは、図８Ｋおよび図８Ｌに示されており、ユーザ定義ノード８５０により、フローが２つの部分に分割される。フロー評価中に、ユーザ定義スクリプトノード８５２は、フローの第１の部分からデータを受信し、フローの第２の部分に出力を提供する。
フローデータを何らかの方法で変更するカスタマイズに加えて、ユーザは、フローの実行方法を制御するスクリプトを作成することができる。例えば、ユーザがスプレッドシートを毎日公開している共有からデータをプルする必要があるとする。定義されたフローでは、ＣＳＶまたはＥｘｃｅｌファイルの処理方法はすでに既知である。ユーザは、リモート共有を反復処理し、関連するファイルをプルダウンしてから、それらのファイルを実行する制御スクリプトを作成することができる。
パターンユニオンなど、ユーザがデータフローノードに追加できる多数一般的な操作が存在する。ただし、テクノロジーが進化し続けるにつれて、常に、システム定義のデータフローノードに対応していないデータを取得または保存する方法が存在する。これらは、制御フロースクリプトが適用可能な場合である。これらのスクリプトは、フローの一部として実行される。
上記のように、フローはコマンドラインから呼び出すこともできる。これにより、他のプロセスまたは夜間のジョブにスクリプトを埋め込むことができる。
実装形態には、多くの便利な機能を提供するフロー評価プロセスがある。これらの機能には、以下が含まれる。
●フローを最後まで実行する。
●順序または「固定」操作を確実にするために、フローを分割する。
●フローを分割して、サードパーティのコードを実行することができるようにする。
●フローを実行するが、アップストリームのデータソースに戻るのではなく、過去に実行したフローの出力からフローを実行する。
●フローの一部を事前実行して、ローカルキャッシュにデータを入力する。
評価プロセスは、論理モデルと物理モデルとの間のインタラクションに基づいて機能する。具現化された物理モデルは、フローの開始点になる。ただし、言語ランタイムは、実行するフローのサブセクションを定義するための抽象化を提供する。概して、ランタイムは、サブフローおよびフルフローをいつ実行するかを決定するものではない。それは、他のコンポーネントによって決定される。
図８Ｍは、フロー全体の実行が、入力ノードおよび出力ノードでの暗黙の物理モデルから開始することを示している。図８Ｎは、部分フローを実行すると、物理モデルが結果とともに具現化されることを示している。図８Ｏは、過去の結果に基づいたフローの実行部分を示している。
物理モデルを並べ替えして処理を最適化することができるが、論理モデルは一般的に関連性がないため、これらの詳細をユーザから隠す。フローエバリュエータは、ノードがフローに表示されている順序で評価されているように見せる。ノードが固定されている場合、実際にはフローがそこで具現化され、左側の部分が右側の部分よりも先に評価されることが保証される。フォークフローでは、一般的なプリフローは１回だけ実行される。このプロセスは、冪等性である。つまり、失敗によって入力演算子が再度呼び出されても失敗しないことを意味する。返されるデータが最初のデータとまったく同じである必要はない（つまり、アップストリームデータソースのデータが１回目の試行と２回目の試行との間で変更された場合）ことに留意されたい。
変換演算子の実行には副次的な効果はない。一方、抽出演算子は典型的に、副次的な効果を有する。フロー内のデータソースの前にデータソースを変更する操作は、フローの次の実行まで表示されない。読み込み演算子には概して、副次的な効果はないが、例外がある。実際、一部の読み込み演算子には、副次的な効果を必要とする。例えば、共有からファイルをプルダウンして解凍すると、副次的な効果と見なされる。
一部の実装形態では、列名に関して大文字と小文字とが区別されるが、そうでない実装形態もある。一部の実装形態では、列名で大文字と小文字とを区別するかどうかを指定するためのユーザ構成可能なパラメータが提供される。
概して、キャッシュされたオブジェクトのビューは常に時間的に「前進」する。
図８Ｐおよび図８Ｑは、固定されたノード８６０を用いたフローの評価を示している。フロー評価中、ピンの前のノードが最初に実行されてユーザノード結果８６２が作成され、ユーザノード結果８６２がフローの後半部分で使用される。固定は、各々の部分内での実行の再配置を妨げるものではないことに留意されたい。固定されたノードは、事実上、論理的なチェックポイントである。
ユーザによって固定されたノードに加えて、一部のノードは、実行する操作に基づいて本質的に固定される。例えば、ノードがカスタムコード（Ｊａｖａ（登録商標）プロセスなど）を呼び出す場合、論理操作をノード間で移動することはできない。カスタムコードは「ブラックボックス」であるため、その入力および出力は明確に定義する必要がある。
場合によっては、操作を移動することでパフォーマンスを向上させることができるが、一貫性が低下するという副次的な効果が発生する。場合によっては、ユーザは一貫性を保証する方法として固定を使用することができるが、パフォーマンスが犠牲になる。
上記のように、ユーザは、データグリッド３１５で直接データ値を編集することができる。場合によっては、システムにより、ユーザの編集に基づいて一般的なルールが推測される。例えば、ユーザが、文字列「１９」をデータ値「７５」に追加して「１９７５」を作成する場合がある。システムは、データおよびユーザの編集内容に基づいて、ユーザが文字列を記入して、世紀が欠けている２つの文字年号に対して４つの文字年号を形成することを望んでいるというルールを推測することができる。場合によっては、推測は、変更自体のみに基づいて行われる（例えば、「１９」を先頭に追加）が、他の場合には、システムは列のデータ（例えば、列の値が「７４」－「９９」であること）にも基づいて推測を行う。一部の実装形態では、列内の他のデータ値にルールを適用する前に、ユーザはルールを確認するように求められる。一部の実装形態では、ユーザは、同じルールを他の列に適用することも選択することができる。
ユーザによるデータ値の編集には、ここで説明したように、現在のデータ値に追加するか、文字列の一部を削除するか、特定の部分文字列を別の部分文字列に置き換えるか、またはこれらの任意の組み合わせを含めることができる。例えば、電話番号は、（ＸＸＸ）ＹＹＹ－ＺＺＺＺなどの様々なフォーマットで指定することができる。ユーザは、１つの特定のデータ値を編集して括弧とダッシュを削除し、ドットを追加してＸＸＸ．ＹＹＹ．ＺＺＺＺを作成する場合がある。システムは、データ値を編集する単一のインスタンスに基づいてルールを推測し、列全体にルールを適用することができる。
別の例として、数値フィールドにもルールを推測することができる。例えば、ユーザが負の値をゼロに置き換えると、システムは、全ての負の値をゼロにする必要があると推測してもよい。
一部の実装形態では、２つ以上のデータ値が共有ルールに従ってデータグリッド３１５の単一の列で編集されるときにルールが推測される。
図９は、操作が命令型として指定されているか宣言型として指定されているかに応じて、論理フロー３２３を様々な方法で実行する方法を示している。このフローには、データセットＡ９０２およびデータセットＢ９０４の２つの入力データセットが存在する。このフローでは、これらのデータセットはデータソースから直接取得される。フローによれば、２つのデータセット９０２および９０４は、結合操作９０６を使用して組み合わされて、中間データセットを生成する。結合操作の後、フロー３２３は、フィルタ９０８を適用する。これにより、結合操作９０６によって作成された第１の中間データセットよりも少ない行で、別の中間データセットが作成される。
このフロー内の全てのノードが必須として指定されている場合、フローを実行すると、ノードが指定したとおりに実行される。データセット９０２および９０４はデータソースから取得され、これらのデータセットはローカルで組み合わされ、次に行数がフィルタによって削減される。
このフロー内のノードが宣言型実行（概してデフォルト）を有するように指定されている場合、実行オプティマイザにより、物理フローが再編成され得る。第１のシナリオでは、データセット９０２および９０４は別個のデータソースからのものであり、フィルタ９０８がデータセットＡ９０２のフィールドにのみ適用されると想定している。この場合、フィルタをデータセットＡ９０２を取得したクエリにプッシュバックすることができるため、取得および処理されるデータの量を減らすことができる。これは、データセットＡ９０２がリモートサーバーから取得され、かつ／またはフィルタによって著しい数の行が削除される場合に特に役立つ。
第２のシナリオでは、再び宣言型の実行が想定されるが、データセットＡ９０２およびデータセットＢ９０２の両方が同じデータソースから取得されると想定する（例えば、これらのデータセットの各々は、同じデータベースサーバー上の同じデータベース内のテーブルに対応する）。この場合、フローオプティマイザは実行全体をリモートサーバーにプッシュバックし、２つのテーブルを結合し、フィルタノード９０８によって指定されたフィルタ操作を適用するＷＨＥＲＥ句を含む単一のＳＱＬクエリを構築することができる。この実行の柔軟性により、全体的な実行時間を大幅に短縮することができる。
ユーザは、時間の経過とともにデータフローを構築および変更するため、一部の実装形態では、増分フロー実行が提供される。各ノードの中間結果が保存され、必要な場合にのみ再計算される。
ノードを再計算する必要があるかどうかを判別するために、一部の実装形態ではフローハッシュおよびベクタークロックを使用する。フロー３２３の各ノードは、それ自身のフローハッシュおよびベクトルクロックを有する。
特定のノードのフローハッシュは、特定のノードまでのフロー内の全ての操作を識別するハッシュ値である。フロー定義のいずれかの態様が変更（例えば、ノードの追加、ノードの削除、またはいずれかのノードでの操作の変更）された場合、ハッシュは異なるものとなる。フローハッシュはフロー定義を追跡するだけであり、基になるデータは調べないことに留意されたい。
ベクタークロックは、ノードが使用するデータのバージョン管理を追跡する。特定のノードが複数のソースからのデータを使用する可能性があるため、これはベクトルである。データソースには、特定のノードまでの任意のノードによってアクセスされる任意のデータソースが含まれる。ベクトルには、データソースの各々の単調に増加するバージョン値が含まれる。場合によっては、単調に増加する値は、データソースからのタイムスタンプである。値はデータソースに対応するものであり、データがフロー内のノードによって処理されたときのものではないことに留意されたい。場合によっては、データソースは、単調に増加するバージョン値を提供できる（例えば、データソースは編集タイムスタンプを有する）。データソースがかかるバージョン数を提供することができない場合、データプレップアプリケーション２５０は、（例えば、いつクエリがデータソースに送信されたか、またはいつデータソースから取得されたかの）代理値を計算する。概して、データプレップアプリケーションが最後にデータを照会した日時を示す値ではなく、データが最後に変更された日時を示すバージョン値を使用することが好ましい。
フローハッシュおよびベクトルクロックを使用することにより、データプレップアプリケーション２５０は、再計算の必要があるノードの数を制限する。
図１０は、一部の実装形態による、複数の非同期クエリから取得された結果セットの高水準点を確立するプロセスを示している。４本の棒の各群は、ある時点を表し、時間は、Ｔ１、Ｔ２、Ｔ３、およびＴ４の順序で増加する。各群の４つのバーは、非同期で実行されている４つの異なるクエリの部分的な結果を表している。各群の点線は、全てのクエリでデータソースから取得されたデータの行を表している。点線は、高水準点と称されることもある。高水準点は典型的に、一意の識別子で指定される。一部の実装形態では、一意の識別子は、データソースからの主キー値である。例えば、４つのクエリの各々が同じデータソースから主キーの順序でデータを取得する場合、主キーの値を高水準点として使用できる。一部の実装形態では、一意の識別子は、行番号である。
第１の時間Ｔ１において、第４の結果セット１００８－１は、４つの結果セット１００２－１、１００４－１、１００６－１、および１００８－１の中で最小の行を有している。よって、Ｔ１での高水準点１０１０－１は、第４の結果セット１００８－１によって決定される。第２の時間Ｔ２では、第２の結果セット１００４－２および第３の結果セット１００６－２についてより多くの結果が受信されたが、第１の結果セット１００２－２および第４の結果セット１００８－２は同じままである。このため、高水準点１０１０－２も同じままである。第３の時間Ｔ３において、第１の結果セット１００２－３は追加のデータ行を受信したが、第２の結果セット１００４－３、第３の結果セット１００６－３、および第４の結果セット１００８－３は同じままである。このため、高水準点１０１０－３も同じままである。第４の時間Ｔ４において、第１の結果セット１００２－４、第２の結果セット１００４－４、および第３の結果セット１００６－４は同じままであるが、第４の結果セット１００８－４では追加の行が取得される。この時点で、第４の結果セット１００８－４の行は、第２の結果セット１００４－４の行よりも多いので、高水準点１０１０－４は、第２の結果セット１００４－４によって決定される。
一部の実装形態では、クエリのいずれかで新しい行が受信されると、高水準点の再計算がトリガーされる。一部の実装形態では、高水準点の再計算は、タイマー（例えば、１秒に１回）に基づいてトリガーされる。タイマーを使用する一部の実装形態では、最初のテストで、最新の更新（またはテスト）以降に結果セットが変更されたかどうかを判別する。一部の実装形態では、タイミング間隔は非線形である。例えば、１／２秒後に第１のテスト／更新を実行し、さらに１秒後に第２のテスト／更新を実行し、さらに２秒後に第３の更新を実行する。
図１１は、一部の実装形態に従って、データがデータソースから読み込まれている間にデータプレパレーションユーザインターフェースがどのように更新されるかを示している。コンピュータシステム２００は、データプレップアプリケーション２５０と、部分的なクエリ結果を格納するキャッシュ１１１２とを含む。データプレップアプリケーション２５０は、ユーザインターフェース１００を表示し、これにより、ユーザは、データベース２４０に格納されたデータソースから受信したデータと対話し、それを変更することができる。データベース２４０は、コンピュータシステム２００に格納され得るか、またはリモートで（例えば、データベースサーバー上に）格納され得る。データは、複数の非同期クエリ１１２０を使用して取得され、部分的なクエリ結果１１２２として（例えば、データプレップアプリケーション２５０によって指定されたブロックで）受信される。典型的に、クエリの各々の初期ブロックは小さいため、データをユーザインターフェースに迅速に読み込むことができる。これにより、ユーザはデータの操作を直ちに開始できる。ブロックサイズは、典型的には増加し、例えば、行のブロックが受信されるたびに２倍になる。
データ更新モジュール１１１０は、データの新しい行が到着すると、ユーザインターフェース１００を更新する。データリフレッシュモジュール１１１０には複数の態様が存在する。まず、実装形態はデータ更新モジュールの実行時間を構成することができる。一部の実装形態では、データ更新モジュールは、クエリ１１２０のいずれかについてデータの新しい行が受信されるたびに実行される。一部の実装形態では、データ更新モジュールはタイマー（例えば、１秒に１回）によってトリガーされる。タイマーによってトリガーされる一部の実装形態では、最初のテストが実行され、データ更新モジュールが最後に実行されてから結果セットのいずれかが変更されたかどうかが判別される。次に、データ更新モジュールは高水準点を計算し、それを過去の高水準点と比較する。それらが同じである場合、この時点で実行するアクションはない。
高水準点が変化している場合、データ更新モジュール１１１０は、新しい高水準点に従ってユーザインターフェース１００を更新する。データが表示される全ての場所（例えば、図１３のヒストグラム１３１０などのプロファイルペインのデータ値ヒストグラム）で、データが更新される。場合によっては、図１２および図１３に示すように、ユーザはデータを編集し、かつ／または、データの表示方法に関するパラメータを変更するためのアクション（スクロール位置またはオブジェクトの選択など）を実行する。これらの場合、データ更新モジュール１１１０は、ユーザが見ているもの（例えば、ユーザインターフェース１００にワイルドジャンプがないこと）を保持するために、データ変更およびビューパラメータに従ってデータを更新する。
図１２は、一部の実装形態による、データプレパレーションユーザインターフェースで部分的に読み込まれたデータとのユーザインタラクションと、追加データが非同期で到着したときのユーザインターフェースへの後続の更新とを示している。図１１に示されるように、部分的な結果１１２２は、データベース２４０から取得され、キャッシュ１１１２に格納される。キャッシュからのデータにより、１回目に１２００－１でユーザインターフェース１００が更新される。一部のデータが表示されると、ユーザは、データのフィルタ処理、特定のデータの除外、データのブラッシング、列の削除、新しい列の追加、列の名前の変更、列のデータ型の変更、または列への変換関数の適用など、データに変更１２１２を加えることができる。これらの変更は、２回目の１２００－２でデータに適用される。データ（またはデータの表示）に対するこれらの変更は、キャッシュと現在の高水準点に基づいている。この変更はまた、（例えば、対応するフローダイアグラムのうちの１つ以上のノードの一部として）一連の格納された操作１２１４として格納される。追加のデータが受信され、高水準点が変更されると、データ更新モジュール１１１０は、キャッシュから更新された行のセット（新しい高水準点まで）を使用し、格納された操作１２１４を取得されたデータに適用して、ユーザインターフェース１００を更新（１２１６）する。このようにして、３回目の１２００－３でも、ユーザには変更が表示され、変更はデータの新しい行に適用される。換言すれば、更新されたデータによってユーザのアクション１２１２が元に戻されるか、取り消されるか、または無視されることはない。
図１３は、一部の実装形態による、データプレパレーションユーザインターフェースのプロファイルペインの例である。プロファイルペインには、フィールド「曜日」（事故データセットで各々の事故が発生した曜日を識別する）のヒストグラム１３１０など、表示された各データフィールドのデータ値ヒストグラムが含まれる。データ値ヒストグラムの各バーは、個々のデータ値またはデータ値の範囲に対応する「ビン」である。ディメンションデータフィールドの場合、典型的に、各ビンには単一のデータ値があるが、数値フィールドは典型的に、値の範囲によってビニングされる。
Ｓｔａｔｅデータフィールドには、カリフォルニア州のビン１３０２を含む、州ごとのビンがある。ユーザは、カリフォルニア州のビン１３０２を選択し、カリフォルニア州で事故が発生した事故テーブルの行のみにディスプレイ州をフィルタ処理することができる（またはカリフォルニア州の行を除外することができる）。選択が行われると、他のデータフィールドのデータ値ヒストグラムには、ブラッシングが使用され、各バーのどの割合がＳｔａｔｅ＝「Ｃａｌｉｆｏｒｎｉａ」の行に対応するかが示される。
ユーザは、列を削除するか、または列の名前を変更することができる。例えば、ユーザは、「Ｒｏａｄ Ｆｎｃ」列１３０４を選択して、それをディスプレイから取り除くことができる。代替的に、ユーザは、「Ｒｏａｄ Ｃｏｎｄｉｔｉｏｎ」など、異なる列名を選択することもできる。場合によっては、選択したデータフィールドのデータ型を変更することも理にかなっている。ユーザは、場所１３０６に新しい列を追加するなど、新しい列を追加することもできる。新しい列を追加する場合、その列のデータは通常、他の列の関数として表される。例えば、各行のＳｔａｔｅデータの値に対応する２文字の州の略語を計算する列を新たに追加する。
ユーザは、既存の列のデータ値を変更することもできる。例えば、曜日のデータ値１３１２は、このデータセットの数値１～７として符号化されている。多くのユーザにとって、これらを曜日の名前に変換すると便利である（例えば、１を「月曜日」に置き換え、２を「火曜日」に置き換えるなど）。ユーザは、データプレップユーザインターフェース１００のプロファイルペインにおいて、データに対して直接これらの編集を行うことができる。
これらの変更は全て、格納された操作１２１４の一部として格納され、それらが受信および更新されるときにデータの新しい行に適用される。例えば、「曜日」データフィールドのデータ値１が「月曜日」に置き換えられた場合、この同じ変換が、曜日として「１」を有する受信された全ての新しいデータ行に適用される。
開示された実装形態には、次の利点がある。
●利用可能な場合、ユーザの増分的結果を表示する。
●ユーザは、スクロール、選択、ブラッシングなどを通じて、到着したデータを探索することができる。
●アクションが到着するデータに影響を与える場合でも、ユーザがデータの到着時にフローに基づいたアクションを実行することができるようになる。
データが到着すると、プロファイルおよびデータペインは定期的に更新され、新しいデータが反映される。
データの読み込み中、ユーザは、データを操作してデータを表示および変更することができる。例えば、ユーザは次のことが可能となる。
●プロファイルペインを垂直方向および水平方向の両方にパンする。これを行うと、ビュー内プロファイルが読み込まれ、キャッシュの現在の状態が表示される。
●データペインを垂直方向および水平方向の両方にパンする。これにより、キャッシュの現在のビューが表示される。
●データが完全に読み込まれたかのように、プロファイルペインで選択を実行する。これらの選択はフィルタを意味する。フィルタは、追加のデータ／ドメインに対してすでに堅牢である必要がある。これらのフィルタは、ユーザインタラクションを促進するために適用および使用される。注：これらの選択は典型的に、位置ではなく、選択された値に基づいている。例えば、ユーザがフィールド「ｆｏｏ」で１～５の範囲を示すビン（バケットとも称される）を選択するとする。これは、ｆｏｏのフィルタが［１，５］の範囲にあることを意味する。これにより、プロファイルペインでブラッシングが発生し、データペインでフィルタ処理が発生する。このフィルタは、より多くのデータが到着しても保持される。選択したビンがより大きなビンに統合されている場合、このビンには、選択した範囲が含まれていても、部分的にブラッシングが行われる。
●他の全てのビューステートオプション（並べ替えなど）は機能し続け、増分ロードをブロックしない。
●全てのノードのビューがライブに保たれる。例えば、結合ノードの結合サマリ領域では、データの読み込み中にユーザが結合パーツを選択することができる。
データが到着すると、ユーザはデータを編集することができる。
●列内の特定のデータに依存しない編集を行うことができる。例えば、列を削除もしくは追加し、列の名前を変更し、または列の型を変更することができる。
●列内の特定のデータに応じて編集することができる。例えば、プロファイルペインでビンを右クリック／削除することができる。これらの操作には、暗黙の選択範囲があり、範囲は、選択されたアイテムがより広い範囲に統合されている場合でも、最初の選択時に推測される。
●結合および集計などの操作の構成を行うことができる。
データの読み込みに加えて複数のアクションを連鎖させることで、ここで概説した動作が維持される。例えば、
１．ユーザがＳＱＬサーバーからテーブルＴを読み込む。
２．メタデータが読み込まれた後、読み込みが完了する前に、ユーザは列ｃを削除する。
３．システムはＴの読み込みを続行し、Ｔ－｛ｃ｝の計算も開始する。ユーザは、このノードのメタデータが表示されるのを確認し、アクション（例えば、列ｄを削除）を実行することができる。
４．システムは、Ｔの読み込みを続行するが、Ｔ－｛ｃ｝の計算を中止し、代わりにＴからＴ－｛ｃ，ｄ｝を直接計算することを決定する。代替的に、システムは、Ｔの読み込みを継続してＴ－｛ｃ｝を計算し、その上でＴ－｛ｃ，ｄ｝を計算することを決定する。
５．ユーザは、Ｔ－｛ｃ，ｄ｝が利用可能になったときに、その状態を引き続き変更することができる。
部分的な結果のみが読み込まれた状態でデータを変更するユーザアクションに加えて、ユーザは、より多くのデータが到着したときに保持されるユーザインターフェースにおいて他のアクションを実行することができる。例えば、ビューステートを選択、スクロール、または変更するためのユーザアクションは保持される。垂直スクロールおよび水平スクロールは、プロファイルペインおよびデータペインの両方に適用される。ユーザがいずれかのペインで特定のオブジェクトを選択した場合、新しいデータが到着してもその選択は保持される。ブラッシングおよびフィルタなど、ビューの状態が維持される。
本明細書で本発明の説明に使用される専門用語は、特定の実装形態を説明することのみを目的としており、本発明を限定することを意図するものではない。本発明の説明および添付の特許請求の範囲で使用される場合、単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、特に文脈が明示しない限り、複数形も含むことが意図される。本明細書で使用される「および／または」という用語は、１つ以上の関連するリストされたアイテムのありとあらゆる可能な組み合わせを指し、それらを包含することも理解されよう。本明細書で使用される場合、「含む」および／または「含んでいる」という用語は、述べられた特徴、ステップ、動作、要素、および／または構成要素の存在を指定するが、１つ以上の他の特徴、ステップ、動作、要素、構成要素、および／またはそれらの群の存在または追加を排除しないことがさらに理解されよう。
前述の記載は、説明の目的で、特定の実装形態を参照して記載されてきた。しかしながら、上記の例示的な論議は、網羅的であること、または本発明を開示された正確な形態に限定することを意図していない。上記の教示を考慮して、多くの修正および変形が可能である。実装形態は、本発明の原理およびその実際の応用を最もよく解説するために選択および記載され、それにより、当業者は、本発明および企図される特定の用途に好適な様々な修正を伴う様々な実装形態を最大限に利用することができる。

Claims (20)

  1. 後続の分析のためにデータを準備するためのコンピュータシステムであって、
    １つ以上のプロセッサと、
    メモリと、
    前記メモリに格納され、前記１つ以上のプロセッサによって実行されるように構成された１つ以上のプログラムと、を含み、前記１つ以上のプログラムが、
    （ｉ）データソースを識別するノード／リンクフローダイアグラムを表示するデータフローペインおよび（ｉｉ）前記データソース内の複数のデータフィールドのデータ値の統計分布を提供するプロファイルペインを含むユーザインターフェースを表示することと、
    前記データソースに対する複数のクエリの各々について、
    行数を指定するブロックサイズを用いて、前記データソースに対して非同期で前記それぞれのクエリを発行すること、
    前記それぞれのクエリを満たす前記データソースからそれぞれの行の初期セットを取得すると、前記クエリを満たす全ての前記行が取得されるまで、前記それぞれのクエリを非同期的に繰り返すこと、および
    前記それぞれのクエリを満たす取得された行をローカルキャッシュに格納することと、
    定期的に、
    全ての前記クエリで前記ローカルキャッシュに取得および保存された前記データソースの行を識別する一意の識別子を決定すること、および
    前記一意の識別子が変更された場合、前記プロファイルペインにおいて前記データ値の統計分布を更新することであって、各統計分布要素が、（ｉ）前記一意の識別子によって指定され、（ｉｉ）それぞれのデータフィールドに対して単一の特定のデータ値またはデータ値の範囲を有する前記データソースのそれぞれの行数を示す、表示することと、
    これにより、複数の独立したクエリが非同期で実行されている間、前記プロファイルペインにデータの一貫したビューを提供することと、を行うための命令を含む、コンピュータシステム。
  2. 前記データソースに対するそれぞれのクエリの各繰り返しが、前記それぞれのクエリの過去のブロックサイズよりも大きいそれぞれのブロックサイズを指定する、請求項１に記載のコンピュータシステム。
  3. 前記データソースに対するそれぞれのクエリの各繰り返しが、前記それぞれのクエリの過去のブロックサイズの２倍のサイズであるそれぞれのブロックサイズを指定する、請求項２に記載のコンピュータシステム。
  4. 前記一意の識別子の前記定期的な決定は、それが１秒に１回以下発生するように調整される、請求項１に記載のコンピュータシステム。
  5. 前記ユーザインターフェースが、前記データソースからのデータの行を表示するデータペインをさらに含み、前記一意の識別子が変更された場合、前記一意の識別子に従って前記データペインに表示された前記データソースからのデータの行を更新することをさらに含む、請求項１に記載のコンピュータシステム。
  6. 前記ノード／リンクフローダイアグラムの第１のノードが最初に選択され、前記プロファイルペインに表示される前記データ値の統計分布が、前記第１のノードの計算されたデータセットに対応する、請求項１に記載のコンピュータシステム。
  7. 前記クエリのうちの１つ以上の実行中に、前記ノード／リンクフローダイアグラムの第２のノードのユーザ選択を受信することと、
    前記ユーザ選択に応じて、前記プロファイルペインを更新して、前記第２のノードの結果セットからの複数のデータフィールドの新しいデータ値の統計分布を表示することであって、各統計分布要素が、それぞれのデータフィールドに対して単一の特定のデータ値またはデータ値の範囲を有する前記結果セットの行数を示す、表示することと、をさらに含む、請求項６に記載のコンピュータシステム。
  8. 前記一意の識別子が、前記データソースの主キーフィールドの主キー値であり、前記データソースの行が、前記行に対応するキー値が前記主キー値よりも小さい場合に、前記一意の識別子によって指定される、請求項１に記載のコンピュータシステム。
  9. 前記一意の識別子が、高水準の行番号であり、前記データソースの行が、前記行に対応する行番号が前記高水準の行番号以下である場合に、前記一意の識別子によって指定される、請求項１に記載のコンピュータシステム。
  10. 前記クエリの各々が、同じソート順序を有する、請求項９に記載のコンピュータシステム。
  11. 前記クエリのうちの１つ以上が実行されている間、
    ユーザ入力を受信して、前記プロファイルペインに表示されるデータを変更することと、
    前記ユーザ入力に応答して、前記ユーザ入力を前記データソースから前記取得した行に適用される操作に変換し、前記操作の定義を保存することと、をさらに含み、
    前記一意の識別子が変更された場合、前記プロファイルペインを更新することが、前記プロファイルペインに表示される前記データが変更された後に、前記クエリによって取得された追加の行に前記定義された操作を適用することを含む、請求項１に記載のコンピュータシステム。
  12. 前記ユーザ入力が、最初のデータフィールドの最初のデータ値ビンに対応する単一の統計分布要素の選択であり、これにより、前記プロファイルペインに表示された前記データを、前記最初のフィールドのデータ値が前記最初のデータ値ビンに対応する前記データソースの行にフィルタ処理し、
    前記保存された操作により、前記プロファイルペインに表示された前記データが、前記最初のフィールドのデータ値が前記最初のデータ値ビンに対応する前記データソースの行にフィルタ処理するフィルタに適用される、請求項１１に記載のコンピュータシステム。
  13. 前記ユーザインターフェースが、前記データソースからのデータの行を表示するデータペインをさらに含み、
    前記ユーザ入力により、最初のデータフィールドに対応する統計分布が前記プロファイルペインから削除され、
    前記一意の識別子が変更された場合に前記プロファイルペインを更新することが、前記データペインから前記最初のデータフィールドを省略することを含む、請求項１１に記載のコンピュータシステム。
  14. 前記ユーザ入力により、前記クエリによって取得された１つ以上の他の列の関数として計算された、対応する統計分布を備えた計算列が前記プロファイルペインに追加され、
    前記一意の識別子が変更された場合に前記プロファイルペインを更新することが、前記関数および前記データソースから取得された前記追加の行に従って前記計算列の前記統計分布を更新することを含む、請求項１１に記載のコンピュータシステム。
  15. 前記ユーザ入力により、前記プロファイルペインの最初のデータ列の名前が新しい名前に変更され、
    前記一意の識別子が変更された場合に前記プロファイルペインを更新することが、前記最初のデータ列の前記新しい名前を保持することを含む、請求項１１に記載のコンピュータシステム。
  16. 前記ユーザ入力により、変換関数に従って、前記プロファイルペインの最初のデータ列のデータ型が新しいデータ型に変換され、
    前記一意の識別子が変更された場合に前記プロファイルペインを更新することが、前記データソースから取得した前記追加の行の前記最初のデータ列に前記変換関数を適用することを含む、請求項１１に記載のコンピュータシステム。
  17. 前記ユーザ入力により、前記プロファイルペインの最初のデータ列のビンに対応する統計分布要素が削除され、
    前記一意の識別子が変更された場合に前記プロファイルペインを更新することが、前記最初のデータ列のデータ値が前記ビンに一致する前記追加の行のいずれかを削除することを含む、請求項１１に記載のコンピュータシステム。
  18. 前記ビンが、個々のデータ値またはデータ値の連続範囲に対応する、請求項１７に記載のコンピュータシステム。
  19. １つ以上のプロセッサ、メモリ、およびディスプレイを有するコンピュータシステムによって実行するように構成された１つ以上のプログラムを格納する非一時的コンピュータ可読記憶媒体であって、前記１つ以上のプログラムが、
    （ｉ）データソースを識別するノード／リンクフローダイアグラムを表示するデータフローペインおよび（ｉｉ）前記データソース内の複数のデータフィールドのデータ値の統計分布を提供するプロファイルペインを含むユーザインターフェースを表示することと、
    前記データソースに対する複数のクエリの各々について、
    行数を指定するブロックサイズを用いて、前記データソースに対して非同期で前記それぞれのクエリを発行すること、
    前記それぞれのクエリを満たす前記データソースからそれぞれの行の初期セットを取得すると、前記クエリを満たす全ての前記行が取得されるまで、前記それぞれのクエリを非同期的に繰り返すこと、および
    前記それぞれのクエリを満たす取得された行をローカルキャッシュに格納することと、
    定期的に、
    全ての前記クエリで前記ローカルキャッシュに取得および保存された前記データソースの行を識別する一意の識別子を決定すること、および
    前記一意の識別子が変更された場合、前記プロファイルペインにおいて前記データ値の統計分布を更新することであって、各統計分布要素が、（ｉ）前記一意の識別子によって指定され、（ｉｉ）それぞれのデータフィールドに対して単一の特定のデータ値またはデータ値の範囲を有する前記データソースのそれぞれの行数を示す、表示することと、
    これにより、複数の独立したクエリが非同期で実行されている間、前記プロファイルペインにデータの一貫したビューを提供することと、を行うための命令を含む、非一時的コンピュータ可読記憶媒体。
  20. 後続の分析のためにデータを準備する方法であって、
    ディスプレイ、１つ以上のプロセッサ、および前記１つ以上のプロセッサによって実行されるように構成された１つ以上のプログラムを格納するメモリを有するコンピュータシステムにおいて、
    （ｉ）データソースを識別するノード／リンクフローダイアグラムを表示するデータフローペインおよび（ｉｉ）前記データソース内の複数のデータフィールドのデータ値の統計分布を提供するプロファイルペインを含むユーザインターフェースを表示することと、
    前記データソースに対する複数のクエリの各々について、
    行数を指定するブロックサイズを用いて、前記データソースに対して非同期で前記それぞれのクエリを発行すること、
    前記それぞれのクエリを満たす前記データソースからそれぞれの行の初期セットを取得すると、前記クエリを満たす全ての前記行が取得されるまで、前記それぞれのクエリを非同期的に繰り返すこと、および
    前記それぞれのクエリを満たす取得された行をローカルキャッシュに格納することと、
    定期的に、
    全ての前記クエリで前記ローカルキャッシュに取得および保存された前記データソースの行を識別する一意の識別子を決定すること、および
    前記一意の識別子が変更された場合、前記プロファイルペインにおいて前記データ値の統計分布を更新することであって、各統計分布要素が、（ｉ）前記一意の識別子によって指定され、（ｉｉ）それぞれのデータフィールドに対して単一の特定のデータ値またはデータ値の範囲を有する前記データソースのそれぞれの行数を示す、表示することと、
    これにより、複数の独立したクエリが非同期で実行されている間、前記プロファイルペインにデータの一貫したビューを提供することと、を含む、方法。
JP2022203797A 2018-10-09 2022-12-20 インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード Active JP7304480B2 (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US16/155,818 US10885057B2 (en) 2016-11-07 2018-10-09 Correlated incremental loading of multiple data sets for an interactive data prep application
US16/155,818 2018-10-09
PCT/US2019/053935 WO2020076546A1 (en) 2018-10-09 2019-10-01 Correlated incremental loading of multiple data sets for an interactive data prep application
JP2021518509A JP7199522B2 (ja) 2018-10-09 2019-10-01 インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2021518509A Division JP7199522B2 (ja) 2018-10-09 2019-10-01 インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード

Publications (2)

Publication Number Publication Date
JP2023040041A JP2023040041A (ja) 2023-03-22
JP7304480B2 true JP7304480B2 (ja) 2023-07-06

Family

ID=68318939

Family Applications (2)

Application Number Title Priority Date Filing Date
JP2021518509A Active JP7199522B2 (ja) 2018-10-09 2019-10-01 インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード
JP2022203797A Active JP7304480B2 (ja) 2018-10-09 2022-12-20 インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード

Family Applications Before (1)

Application Number Title Priority Date Filing Date
JP2021518509A Active JP7199522B2 (ja) 2018-10-09 2019-10-01 インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード

Country Status (7)

Country Link
EP (1) EP3864521A1 (ja)
JP (2) JP7199522B2 (ja)
CN (1) CN113168413B (ja)
AU (2) AU2019356745B2 (ja)
BR (1) BR112021006722A2 (ja)
CA (1) CA3115220C (ja)
WO (1) WO2020076546A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111666740A (zh) * 2020-06-22 2020-09-15 深圳壹账通智能科技有限公司 流程图生成方法、装置、计算机设备和存储介质
TWI772233B (zh) * 2021-11-29 2022-07-21 大陸商常州欣盛半導體技術股份有限公司 Cof測試資料的自動整合方法
US20240070147A1 (en) * 2022-08-26 2024-02-29 Oracle International Corporation Dynamic Inclusion of Metadata Configurations into a Logical Model
CN117056359B (zh) * 2023-10-09 2024-01-09 宁波银行股份有限公司 一种表格重建方法、装置、电子设备及存储介质

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011138382A (ja) 2009-12-28 2011-07-14 Sharp Corp 画像処理装置、画像処理方法、プログラム、及び記録媒体
US20180129374A1 (en) 2016-11-07 2018-05-10 Tableau Software, Inc. Generating and Applying Data Transformations in a Data Import Engine

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH0887433A (ja) * 1994-09-20 1996-04-02 Matsushita Electric Ind Co Ltd ファイルシステムのブロック管理システム
US20030220928A1 (en) * 2002-05-21 2003-11-27 Patrick Durand Method for organizing and querying a genomic and proteomic databases
US8069188B2 (en) * 2007-05-07 2011-11-29 Applied Technical Systems, Inc. Database system storing a data structure that includes data nodes connected by context nodes and related method
CN101626313A (zh) * 2009-08-10 2010-01-13 中兴通讯股份有限公司 网管系统客户端性能数据显示方法和网管系统客户端
CN101916254B (zh) * 2010-06-29 2016-07-06 用友软件股份有限公司 表单统计方法和装置
US9501540B2 (en) * 2011-11-04 2016-11-22 BigML, Inc. Interactive visualization of big data sets and models including textual data
US20140046923A1 (en) * 2012-08-10 2014-02-13 Microsoft Corporation Generating queries based upon data points in a spreadsheet application
CN104750727B (zh) * 2013-12-30 2019-03-26 沈阳亿阳计算机技术有限责任公司 一种列式内存存储查询装置及列式内存存储查询方法
CN105512139B (zh) * 2014-09-26 2019-11-05 阿里巴巴集团控股有限公司 数据可视化的实现方法及装置
US10409802B2 (en) * 2015-06-12 2019-09-10 Ab Initio Technology Llc Data quality analysis
US10558681B2 (en) * 2016-01-26 2020-02-11 Socrata, Inc. Automated computer visualization and interaction with big data

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2011138382A (ja) 2009-12-28 2011-07-14 Sharp Corp 画像処理装置、画像処理方法、プログラム、及び記録媒体
US20180129374A1 (en) 2016-11-07 2018-05-10 Tableau Software, Inc. Generating and Applying Data Transformations in a Data Import Engine

Also Published As

Publication number Publication date
AU2022202376B2 (en) 2022-06-09
WO2020076546A1 (en) 2020-04-16
CA3115220A1 (en) 2020-04-16
AU2022202376A1 (en) 2022-05-05
JP2022504205A (ja) 2022-01-13
EP3864521A1 (en) 2021-08-18
CA3115220C (en) 2023-07-18
AU2019356745B2 (en) 2022-01-13
CN113168413B (zh) 2022-07-01
JP7199522B2 (ja) 2023-01-05
BR112021006722A2 (pt) 2021-07-27
CN113168413A (zh) 2021-07-23
AU2019356745A1 (en) 2021-05-13
JP2023040041A (ja) 2023-03-22

Similar Documents

Publication Publication Date Title
JP7166483B1 (ja) 続く分析に向けてデータを準備しキュレートするユーザインターフェース
US10719528B2 (en) Data preparation with shared data flows
US11188556B2 (en) Correlated incremental loading of multiple data sets for an interactive data prep application
US10394691B1 (en) Resolution of data flow errors using the lineage of detected error conditions
JP7304480B2 (ja) インタラクティブなデータプレップアプリケーションのための複数のデータセットの相関増分ロード

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230118

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230118

A871 Explanation of circumstances concerning accelerated examination

Free format text: JAPANESE INTERMEDIATE CODE: A871

Effective date: 20230118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20230301

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20230328

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20230529

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20230626

R150 Certificate of patent or registration of utility model

Ref document number: 7304480

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150