JP5826260B2 - 関連データセットの処理 - Google Patents

Description

関連出願の相互参照
本出願は２０１０年６月２２日出願の米国仮特許出願第６１／３５７，３７６号からの優先権を主張し、参照のためその全体を本明細書に援用する。

背景
本明細書は関連データセットの処理に関する。

データセットは、例えば任意の数の物理的記憶媒体上でホストされるデータ記憶システムに格納される（例えば、１つまたは複数のサーバー上でホストされるデータベースに格納される）データの集合である。その構造および格納場所などのデータセットの特性は、例えばファイルまたは他形式のオブジェクト（例えば、オブジェクト指向型データベースに格納されたオブジェクト）等のエンティティにより記述することができる。ある場合には、特定のデータセット（例えば、ファイル）を記述するエンティティもまたデータを当該データセット内に格納する。ある場合には、特定のデータセット（例えば、データベーステーブルを指すオブジェクト）を記述するエンティティは、必ずしもデータのすべてをそのデータセット内に格納するとは限らないが、データ記憶システム内の１つまたは複数の場所に格納されたデータを捜し出すために使用されることができる。

データセット内のデータは、個々のレコードに、可能性としてヌル値（例えば、フィールドが空であることを示す）を含むそれぞれのフィールド（「属性」または「列」とも呼ばれる）の値を与えるレコード構造を含む様々な構造の任意のものを使用して編成されてもよい。例えば、レコードはデータベースシステムのデータベーステーブル内の行またはスプレッドシートまたは他のフラットファイル内の行に対応することができる。所与のフォーマットで格納されたレコードにアクセスするために、データ処理システムは通常、フィールド名、レコード内のフィールドの順番、フィールド値を表すビット数、フィールド値のタイプ（例えば、ストリング、符号付き／符号無し整数）等の特徴を記述するある初期フォーマット情報から始まる。ある環境では、データセットのレコードフォーマットまたは他の構造的情報は当初知られていなくてもよく、データの分析後に判断されてもよい。

データセットは、様々なやり方のうちの任意のやり方で互いに関連させることができる。例えば、データベース内の第１のテーブルに対応する第１のデータセットは、データベース内の第２のテーブルのフィールドと主キー／外部キー関係を有するフィールドを含むことができる。第１のテーブル内の主キーフィールドは、第１のテーブル内の行を一意的に特定する値（例えば、異なる顧客に対応する行を一意的に特定する顧客ＩＤ値）を含んでよく、第１のテーブル内の主キーフィールドに対応する外部キーフィールドを含む第２のテーブル内の行（例えば、所与の顧客によりなされた取引（以下トランザクションとも呼ぶ）に対応する行）は、所与の顧客によりなされた取引を表す第２のテーブル内の１つまたは複数の行のそれぞれを特定するためにそれらの一意的な値の１つを使用してもよい。複数のデータセット間の参照整合性の維持は、外部キー／主キー関係を含む異なるフィールド間の関係、または１つのデータセットのフィールド内の値が別のデータセットのフィールド内の値に依存する他の関係を維持することを含んでよい。

要約
１つの態様では、通常、関連データセットの処理方法は、複数のデータセットから入力装置またはポート上でレコードを受信する工程であって、所与のデータセットのレコードは１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する、工程と、複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理する工程と、を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第２のデータセットからのレコードに適用される前に、変換が複数のデータセットの第１のデータセットからのレコードに適用され、第２のデータセットからのレコードに適用される変換は、第１のデータセットからのレコードに変換を適用した結果と、制約仕様により規定される第１のデータセットと第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからレコードへの変換の結果を格納または出力する工程と、を含む。

様々な態様は以下の特徴の１つまたは複数を含むことができる。

制約仕様により規定される参照整合性を維持するための少なくとも１つの制約は、第２のデータセットのフィールドの値の第１のデータセットのフィールドの値への依存性に基づく。

第１のデータセットのフィールドは主キーであり、第２のデータセットのフィールドは主キーを参照する外部キーである。

制約仕様は、第２のデータセットのフィールドと第１のデータセットのフィールド間の主キー対外部キー関係の表現を含む。

複数のデータセットの処理順序を決定する工程は、第２のデータセットのフィールドの値の第１のデータセットのフィールドの値への依存性に基づく処理順序で第１のデータセットが第２のデータセットの前に発生するということを決定することを含む。

変換はデータセットの第２のデータセットからのレコードに適用される前および第１のデータセットからのレコードに適用された後に複数のデータセットの第３のデータセットからのレコードに適用される。

制約仕様により規定される統計的一貫性を維持するための少なくとも１つの制約は、第２のデータセットのフィールドと第１のデータセットのフィールド間の等価性に基づく。

第１のデータセットのフィールドと第２のデータセットのフィールドは結合演算におけるキーである。

制約仕様は結合演算の表現を含む。

本方法はさらに、複数のフィールドに関連する統計を決定するために関連データセットのグループ内のデータセットをプロファイリングする工程であって、複数のフィールドは第１のデータセットの少なくとも１つのフィールドと、第１のデータセットのフィールドと等価であると制約仕様により示される第２のデータセットの少なくとも１つのフィールドと、を含む、工程を含む。

第２のデータセットからのレコードに適用される１つまたは複数の変換は、決定された統計と第１のデータセットからのレコードに変換を適用した結果とに従って、第１のデータセットのフィールド内の値の分布と第２のデータセットのフィールド内の値の分布との間の統計的一貫性を維持することに少なくとも部分的に基づいて適用される。

１つまたは複数の変換は、データ処理構成要素間のレコードの流れを表すリンクにより接続されたデータ処理構成要素を表すノードを含む少なくとも１つのデータフローグラフにより適用され、変換が適用される各データセットはデータフローグラフにレコードの入力フローを提供する。

データフローグラフは、決定された複数のデータセットの処理順序でレコードの入力フローを提供するために複数のデータセットのそれぞれの１つを使用することにより、複数回の繰り返しで連続的に実行される。

所与のデータセットのレコードに適用される１つまたは複数の変換は、所与のデータセットの少なくとも１つのフィールド内の値に基づき所与のデータセット内のレコードの数を低減するサブセット化変換を含む。

所与のデータセットのレコードに適用される１つまたは複数の変換は、データセットの少なくとも１つのフィールド内の値を修正する修正変換を含む。

所与のデータセットのレコードに適用される１つまたは複数の変換は、所与のデータセットの少なくとも１つのフィールド内の値の重複に基づき所与のデータセット内のレコードの数を増加する拡張変換を含む。

本方法はさらに、複数のデータセットのそれぞれからのレコードに変換を適用した結果のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、制約仕様は結果のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、１つまたは複数の変換を、決定された処理順序で、結果のデータセットのそれぞれからのレコードに適用する工程であって、変換が結果のデータセットの第２のデータセットからのレコードに適用される前に、変換が結果のデータセットの第１のデータセットからのレコードに適用され、第２のデータセットからのレコードに適用される変換は、第１のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第１のデータセットと第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、結果のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。

別の態様では、通常、コンピュータ可読媒体は関連データセットを処理するためのコンピュータプログラムを格納し、コンピュータプログラムは、コンピュータに、入力装置またはポート上で、複数のデータセットから、１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する所与のデータセットのレコードを受信させ、複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理させる、命令を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第２のデータセットからのレコードに適用される前に、変換が複数のデータセットの第１のデータセットからのレコードに適用され、第２のデータセットからのレコードに適用される変換は、第１のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第１のデータセットと第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。

別の態様では、通常、関連データセットを処理するためのデータ処理システムは、データ記憶システムと、複数のデータセットから、１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する所与のデータセットのレコードを受信するように構成される入力装置またはポートと、入力装置またはポートとデータ記憶システムと通信する少なくとも１つのプロセッサであって、複数のデータセットのそれぞれからのレコードを処理するように構成された少なくとも１つのプロセッサと、を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第２のデータセットからのレコードに適用される前に、変換が複数のデータセットの第１のデータセットからのレコードに適用され、第２のデータセットからのレコードに適用される変換は、第１のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第１のデータセットと第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。

別の態様では、通常、関連データセットを処理するためのデータ処理システムは、複数のデータセットからレコードを受信する手段であって、所与のデータセットのレコードは１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する、手段と、複数のデータセットのそれぞれからのレコードを処理する手段と、を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第２のデータセットからのレコードに適用される前に、変換が複数のデータセットの第１のデータセットからのレコードに適用され、第２のデータセットからのレコードに適用される変換は、第１のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第１のデータセットと第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。

様々な態様は、以下の利点の１つまたは複数を含むことができる。

本システムは、参照整合性、等価なフィールド（例えば、特性を結合することにより関連付けられたフィールド）の統計的一貫性、および他の制約等の制約を維持する一方で、相互に関連付けられたデータセットの集合を処理することができる。いくつかの実施態様では、本システムは、データフローグラフを使用してデータ処理アプリケーションを構築する開発者が、個々のデータセットから発するレコードフローに作用する流れを生成するために構成要素を個々に接続する必要なしに関連データセットを処理するアプリケーションを構築できるようにする。複数の相互に関連付けられたデータセットが処理を必要とする場合、開発者は、異なるデータセットのフィールド間の主キーと外部キーとの関係等の制約をシステムが認識できるようにするために、データセットのグループとこのデータセットに適用されるデータ処理変換の制約仕様を提供し、それらの制約に基づき参照整合性および統計的一貫性等の特性がほぼ維持されることを保証するやり方で変換を行なうことができる（例えば、所定の公差内で）。

本システムは、開発者が、「conspec」と呼ばれるデータ構造により表される制約仕様内のデータセットの集合間の制約を宣言し、conspecによりグループとして参照されるデータセットに作用する一連の処理タスクを構成および配置するやり方を提供する。これは、関連データセットの全集合に適用される前段階の処理タスクの結果にそれぞれが作用することができる複数の段階のタスクを連鎖すること（例えば、各段階を表す処理モジュールを「線でつなぐ」ことにより）を容易にする。所与のデータセットの特定の状態は「データセットインスタンス」と呼ばれる。conspecは、異なるデータセットの要素（例えば、フィールドまたはフィールドの組み合せ）間の依存関係および等価性関係等の制約を特定する。そのフィールドがconspecにより参照される特定のデータセットインスタンスは、参照フィールドが既存データセットインスタンスのフィールドに対応することを保証するように特定されることができるが、特定データセットインスタンスは、参照中のフィールドを後で既存データセットインスタンスのフィールドへマッピングすることができるので、必ずしも特定される必要はない。conspecは、例えば、データセットのフィールドの少なくともいくつかを論理的に表すフィールド識別子を有するフィールドを参照するデータセット記述子を使用することにより、そして参照フィールド間の異なる制約を表す様々なやり方でフィールド識別子を関連付けるリンクデータ構造を使用することにより、実施することができる。データセット記述子は、現存データセットインスタンスに対応するためには必ずしも必要とされない。したがって所与のconspecは、制約により参照中のフィールドがそれらのデータセットインスタンス内に存在する限り、任意の数のデータセットインスタンスに適用されてもよい。第１の状態における所与のデータセットを表す入力データセットインスタンスは、第２の状態における所与のデータセットを表す対応出力データセットインスタンスを与えるためにグループ内の他のデータセットと共に変換されることができる。変換が元のデータセットに作用する場合、出力データセットインスタンスは入力データセットインスタンスを交換することができ、あるいは変換が元のデータセットの複製物に作用する場合、出力データセットインスタンスは入力データセットインスタンスと共に存在することができる。

典型的な使用ケースの例は、様々なデータセット間の参照整合性をすべて維持する一方で複数のデータセットのグループからのレコードのフィルタリングと、それに続く拡張（expansion）、または新しいレコードを生成するためにレコードを複製することを含むテストデータの生成に関する。conspecは、システムが、データセットのグループに適用されるフィルタ処理としてこのタスクを実行し、続いてデータセットのグループに適用される拡張演算を実行できるようにするために、データセット間の関係についての十分な情報を提供する。第１の演算から流れ出る複数の出力データセットインスタンスは第２の演算に提供され、第２の組の出力データセットインスタンスを生じる。用語「データセット」は、conspecの文脈で使用される場合、レコードフォーマットと要素（例えば、主キー要素と外部キー要素）間の他の構造的関係とを含むデータセットのいくつかの特徴の定義を指し、用語「データセットインスタンス」は、所与の状態におけるデータセットのレコード（conspecにより規定されたフォーマットの）を表す物理的バイトの集合を指す。

一例では、conspecにより参照される２つのデータセット、すなわち「顧客」データセットと「トランザクション」データセットとが存在すると仮定する。さらに、トランザクションデータセットは、顧客データセット内のフィールドを参照する外部キーであるcustidフィールドを有すると仮定する。フィルタリングタスクは、顧客をフィルタリングすることに続いてトランザクションをフィルタリングすることを含んでもよいが、conspec内に定義されたキー関係のために、システムは、既に含まれている顧客を参照するトランザクションだけが含まれるようにトランザクションをフィルタリングする。本システムは、カスタマイズされたフィルタリング操作を各データセットに対し依然として行う一方でデータセット間の関係を維持することができる。

レコードを拡張する第２の演算に関しては、タスクは、「展開された値（fanned out values）」を有する新しいレコードを生成するためにトランザクションレコードを複製することを含んでもよいが、タスクは、可能ならば新しいトランザクションが新しい顧客を参照するように、新しいトランザクションを「その方向に曲げる（ｂｅｎｔ）」やり方でそのようにする。換言すれば、conspecは顧客とトランザクション間の親／子関係を定義するので、新しいトランザクションは可能であれば新しい顧客を参照することが望ましいかもしれない。本システムは、特定レコードの複製とフィールド変更演算を行う一方でこれらの関係を維持することができる。

本発明の他の特徴と利点は以下の説明と特許請求範囲から明らかになる。

図面の説明
関連データセットを処理するためのシステムのブロック図である。 例示的なデータ処理手順のフローチャートである。 データ処理システムにより使用される異なるエンティティ間の関係を示す概略図である。 データ処理システムにより使用される異なるエンティティ間の関係を示す概略図である。 conspecデータ構造の概略図である。 conspecデータ構造の概略図である。 データセットに適用される変換を示す図である。 プロダクションプロセッサの演算を示すブロック図である。 データ処理を行うタスクをスケジューリングするためのプランの概略図である。 データフローグラフの概略図である。 データセット処理順序の選択を示すブロック図である。 conspecデータ構造の概略図である。 データフローグラフの概略図である。 ヒストグラムを示すプロットである。 データフローグラフの概略図である。 データフローグラフの概略図である。 データフローグラフの概略図である。 データフローグラフの概略図である。 データフローグラフの概略図である。 データフローグラフの概略図である。 度数分布を示すプロットである。 拡張演算を示す概略図である。 指標値の範囲を示す図である。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 パッケージファイルのリストを示す。 論理例を示す。 論理例を示す。 論理例を示す。 論理例を示す。

説明
図１に、データセット処理技術を使用することができる例示的なデータ処理システム１００を示す。システム１００は、それぞれが様々な格納フォーマット（例えば、データベーステーブル、スプレッドシートファイル、フラットテキストファイルまたはメインフレームにより使用される固有フォーマット）の任意のものでデータセットを格納することができる記憶装置またはオンラインデータストリームへの接続等の１つまたは複数のデータソースを含んでよいデータソース１０２を含む。実行環境１０４は前処理モジュール１０６と処理モジュール１１２を含む。実行環境１０４は、ＵＮＩＸ（登録商標）オペレーティングシステム等の好適なオペレーティングシステムの制御下で１つまたは複数の汎用コンピュータ上でホストされてもよい。例えば、実行環境１０４は、複数の中央処理装置（ＣＰＵ）を使用するコンピュータシステムの構成を含むマルチプルノードパラレルコンピューティング環境を含むことができる。この環境は、ローカル（例えば、ＳＭＰコンピュータ等のマルチプロセッサシステム）、または局地分散型（例えば、クラスタまたはＭＰＰとして結合されるマルチプルプロセッサ）、またはリモート、またはリモート分散型（例えば、ローカルエリアネットワーク（ＬＡＮ）および／または広域ネットワーク（ＷＡＮ）を介して結合される複数のプロセッサ）、またはその任意の組み合せのいずれかである。

前処理モジュール１０６は、実行環境１０４にアクセス可能なデータ記憶システム１１６内に格納されたデータ構造（conspec１１４）により表される制約仕様と、データ記憶システム１１６内に格納されたデータ構造（規則１１５）により表されるデータセットのグループのレコードへの変換を適用するための規則と、を読み取る。前処理モジュール１０６は、変換を適切なやり方で（例えば、所定順序で）レコードに適用し、その結果を格納または出力するために、処理モジュール１１２により使用される情報を出力する。処理モジュール１１２により処理されるレコードはデータソース１０２により提供される。データソース１０２を提供する記憶装置は、例えば、実行環境１０４を走らせるコンピュータに接続された記憶媒体（例えば、ハードドライブ１０８）上に格納された実行環境１０４に対してローカルであってもよいし、あるいは例えばリモート接続上で実行環境１０４を走らせるコンピュータと通信するリモートシステム（例えば、メインフレーム１１０）上でホストされる実行環境１０４に対してリモートであってもよい。

データ記憶システム１１６はまた、開発者１２０がconspec１１４と規則１１５を生成することができる開発環境１１８にアクセス可能である。開発環境１１８と実行環境１０４は、いくつかの実施態様では、データフローグラフとしてアプリケーションを開発し実行するように構成される。様々なタイプの計算は、有向グラフを介したデータフロー（「データフローグラフ」と呼ばれる）として表すことができ、計算の構成要素は、グラフのリンクに対応する構成要素（弧線、端部）間の作業要素（例えば、レコード）のグラフとデータフローの頂点と関連付けられる。頂点はデータ処理構成要素またはデータセットを表すことができる。データ処理構成要素は、１つまたは複数の入力ポートにおいてデータを受信し、データを処理し、１つまたは複数の出力ポートからデータと、作業要素のソースまたはシンクとして機能するデータセットと、を提供する。このようなグラフベースの計算を実施するシステムは米国特許第５，９６６，０７２号、表題「EXECUTING COMPUTATIONS EXPRESSED AS GRAPHS」に記載され、参照により本明細書に援用する。グラフベースのアプリケーションを開発するための開発環境の例は米国特許出願公開第２００７／００１１６６８号、表題「Managing Parameters for Graph-Based Applications」にさらに詳細に記載され、参照により本明細書に援用する。

図２に、例示的なデータセット処理手順２００のフローチャートを示す。手順２００は例えば前処理モジュール１０６と処理モジュール１１２により行われる。前処理モジュール１０６は複数のデータセットから（システムの入力装置またはポート上で）レコードを受信し（２００）、前処理モジュール１０６はデータ記憶システム１１６内に格納された制約仕様（conspec１１４）と１つまたは複数の変換（規則１１５）を受信する（２０４）。前処理モジュール１０６は、複数のデータセットの処理順序を決定するために制約仕様を分析する（２０６）。前処理モジュール１０６からの入力に基づき、処理モジュール１１２は、規則１１５に定義された１つまたは複数の変換を、決定した処理順序で複数のデータセットのそれぞれからのレコードに適用する。変換は、それぞれの繰り返しで、複数のデータセットの各データセットからのレコードに順番に適用される（２０８）。所与のデータセットからのレコードに適用される変換は、前に処理されたデータセットからのレコードに変換を適用した結果に少なくとも部分的に、そして前に処理されたデータセットと制約仕様により規定される所与のデータセット間の少なくとも１つの制約に、基づいて適用される。手順２００はさらなる組の変換が適用されるかどうかを判断し（２１０）（例えば、追加の組の規則に基づき）、もしそうならば、手順は前の組の変換から生成される出力データセットインスタンスを次の組の変換の入力データセットインスタンスとして使用する工程をループする。変換の終了後、システムは変換の結果を格納または出力する（２１２）。データ処理手順の他の例では、上記工程は、例えば、他の工程（例えば、さらに詳細に以下に説明されるようにデータセットをプロファイリングする工程）を含むように、または異なる順序で発生する（例えば、データセットが受信される前に複数のデータセットの処理順序を制約仕様に基づき決定することができる）ように変更されることができる。

１つの態様では、システムは、データセットの集合からのレコードに作用する計算モジュールを提供する。この計算モジュールは、規則１１５とconspec１１４により規定される制約とに基づき、conspec１１４において参照される複数のデータセットに関わる変換を定義する入力パラメータを使用して構成されるデータフローグラフを使用することにより、実施されてよい。データフローグラフのいくつかは「前処理グラフ」と呼ばれる前処理モジュール１０６の前処理に使用され、データフローグラフのいくつかは前処理グラフにより提供されるパラメータに従って構成されることにより処理モジュール１１２の処理に使用される。データフローグラフは例えば、さらに詳細に以下に説明されるように、データフローグラフの実行を制御するタスクスケジューリング環境であって、入力パラメータにより特定される一系列のデータセットインスタンスでレコードを処理するためにデータフローグラフを反復して実行することができるタスクスケジューリング環境を使用して、制御されることができる。

別の態様では、システムは、直列化され「メモリ内」表現に読み込まれる（例えば、実行環境１０４にアクセス可能なローカルメモリ内に格納される）ことができるconspecの標準表現を提供する。ここで、「メモリ内」表現は、前処理グラフが、関係に沿って、conspec内の個々のデータセットの処理順序などの変換論理と他の情報を書き込むことができるようにするものである。例えば、データフローグラフ内で実行することができる形式でデータを操作するための演算の定義を可能にするデータ操作言語（ＤＭＬ：Data Manipulation Language）を使用する表現は、前処理グラフにおける変換がconspecに定義されたデータセットのすべてを調べることができるようにするであろう。データ操作言語はさらに、マルチデータセット結合演算と共に主キーと外部キーとの関係に基づき、それらの親レコードのコンテキスト内の子レコードを処理するために必要な結合キー要素（結合演算におけるキーとして使用される要素）と共に、データセットの「親から子への」処理順序を決定する。

別の態様では、システムは、conspecにより参照されるデータセットのレコードに適用されてよい変換規則の標準表現を提供する。変換規則のこの表現は「プロダクション」と呼ばれる。プロダクションはまた、conspecに定義された制約から、特定の変換に関連してよい規則を分離する。例えば、ユーザはconspec内に主キーおよび外部キーとキー要素メンバーとの集合を定義し、次に「プロダクション」内に主キーフィールドに適用されるスクランブリングまたはマスキング規則を定義してもよい。conspecからの規則の分離により、ユーザは多くの異なるプロダクション規則を定義することができるようになる。プロダクション規則はすべてconspecから独立しており、しかも任意の特定のプロダクションが適用される場合、conspecに定義された制約のために、システムは、主キーフィールドがスクランブルされるだけでなく、他のデータセット内の外部キー参照もスクランブルされることを保証することになる。プロダクション規則は、例えばプロダクション変換として様々なやり方の１つで実施されることができる。

図３Ａに、conspec３０２と、プロダクション３０４と、これらの両方を読み取り入力データセットインスタンスのレコードに処理工程を適用する「プロダクションプロセッサ」３０６（例えば、データフローグラフを使用して実施される）との間の関係の例を示す。プロダクションは、各出力データセットインスタンス３１０のターゲット識別と場所だけでなく各入力データセットインスタンス３０８の場所を特定する責任を負う。

図３Ｂに、１つのプロダクション３１４の出力データセットインスタンスが次のプロダクション３１６への入力として機能するデイジーチェインプロダクションのシーケンスを示す。関与するデータセットインスタンス３１５、３２０、３２４はプロダクション間で同じとなる（各プロダクションに提供する同じconspec３１２のため）一方で、各工程におけるプロダクションプロセッサ３１８、３２２は、プロダクション規則の性質に依存して、前のプロダクションのものとは異なる処理順序を適用してもよい。

conspecは、単一のデータセット（特定のデータ集合を表す）の抽出のレベルより、conspecにより参照されるデータセットの集合の抽出の「より高いレベル」を提供し、フィルタリング、マスキング、データ拡張などの複数のconspecレベルの演算（規定された制約に従ってデータセットの集合に対し行われる演算）の連鎖を含むデータフローアプリケーションの開発を単純化する。システムは事前構築タイプのプロダクション規則の集合を含んでもよいが、開発者が追加のタイプの変換を定義できるように拡張点を提供してもよい。例えば、ユーザは、conspec内の複数のデータセットにわたってまとめた結果を提供する一方で個々のデータセットのチャートとレポートを生成するであろうデータレポートタイプのプロダクションを構築することを望むかもしれない。この新しいタイプのプロダクションは、すべてのプロダクション規則のための基本プロセッサ内に提供される基本順序走査機構（basic ordered traversal mechanism）を利用してもよいが、処理されたデータセットのそれぞれのデータ集約およびチャート生成機能を追加してもよい。

図４Ａに、conspecに関連する対応データセットインスタンス（例えば、conspecにより参照されるデータセットと同じフィールドを有するデータセットインスタンス）のレコードに適用されてよい典型的なプロダクション操作のための関連データセットの集合間の制約の例であるab_conspecと呼ばれるconspec４００を示す。conspec４００は２つの顧客データセット（a_customersとb_customers）、それらの子トランザクションデータセット（a_transactionsとb_transactions）、consumer_infoデータセットを示し、家庭情報を提供する。３元結合関連性は顧客とconsumer_infoのデータセットからキー間の「等価」特性を定義し、２つの関係は顧客とトランザクション間の親子「依存」特性を記述する。

図４Ｂに、conspecにより参照される複数のデータセット間の関係を定義するconspec４５０の例を示す。これはconspec群のうちの１つのconspecと解釈されてよい。

プロダクションに好適な典型的な１つの演算は、各データセットの要素間の依存性（例えば、外部キー／主キー関係）、等価性（例えば、同じエンティティを表すフィールド間の関連性）などの固有特性を破壊することなくデータセットインスタンスの集合のサイズを低減することである。例えば、図４Ａのab_conspecを参照すると、ユーザは特定のインスタンスにおけるa_customersの数を半分に短縮し、これと共に別のインスタンス内のa_transactionsの数も同様に半分に短縮することを望むかもしれない。しかしながら、ユーザがレコードの最初の５０％を任意に除去することにより各データセットインスタンスを短縮すれば、ユーザは処理された顧客データセットインスタンス内に存在しなくなった顧客を参照するトランザクションで恐らく終わるであろう。図５に、参照整合性を維持することにこだわることなくデータセットインスタンスを任意に短縮する効果を示す。

図４Ａに示すconspecに定義された特性（例えば、データセット要素間の依存性、データセット要素間の等価性）を維持するやり方でデータセットインスタンスを処理するためには、ユーザは各データセットインスタンスが処理される一方でこれらの特性を維持するように複数のデータセットインスタンスに順次に作用する処理グラフの一般的な組を含むプロダクションプロセッサを利用してもよい。

この例では、a_customersとa_transactionsを低減する望ましいやり方は、トランザクションが顧客を参照するので顧客を最初に処理しなければならないと判断することかもしれない。さらに、顧客が５０％低減されると、トランザクションは、残りの顧客に一致するトランザクションだけを選択するように既に処理された顧客と内部結合されなければならない。参照整合性を維持する目的のためにトランザクションがフィルタリングされると、ユーザはさらに、プロダクション規則にこれまでに定義された（これはあり得る）元の数の５０％または既に減少された数の５０％のいずれかを維持するようにトランザクションをフィルタリングしてもよい。参照整合性フィルタはすべてのトランザクションを除去させ、これにより元の数の５０％までさらにフィルタリングすることを不可能にしてもよい。

図５に、conspecab_conspecに定義されるように、データセットインスタンス間の参照整合性を維持する一方でa_customersとa_transactionsを低減する効果を示す。この例では、ユーザは「レコードを５０％低減する」などのような規則を規定し、プロダクションプロセッサが参照conspecに宣言される様々な特性を維持することを期待してよい。これは、複数の関連データセットインスタンスに適用される変換（５０％低減）を扱う２つの異なるやり方の比較である。ここで第１の方法は参照整合性を維持することができなく、第２の方法は参照整合性を維持する。元のデータセットインスタンス５０２、５０４に適用された１つの結果５１０は、各データセットインスタンスを５０％だけ任意に削減した後の結果を表す。太字のトランザクションは、存在しない顧客への誤った参照を強調表示している。別の結果５２０は、顧客を５０％削減し、次に参照整合性を維持するためにトランザクションをフィルタリングし、次に元のデータセットインスタンスの５０％を保持するためにこの組をフィルタリングした後の結果を表す。

図６は、プロダクションプロセッサ６００が、どのようにして、conspec６０２を特定するプロダクションを読み取り、次に特定されたconspecを読み取り、次に一組の一意的識別名（ここでは、プロダクションは一意的名前添字を単純に与える）に従ってデータセットインスタンス６０４、６０６の集合を読み取り、続いて、プロダクション６０８内に定義された規則に従ってデータセットインスタンスを処理し、続いて、プロダクション内にも定義されたターゲット名に従って新しい組のデータセットインスタンス６１０、６１２を書き込むかを示す。総じて、図６は、所与の名前添字を有するデータセットインスタンスを読み取り、プロダクション規則に従ってレコードを削減し、conspec特性（すなわち参照整合性）を維持し、所与の名前添字を使用して、ターゲットデータセットインスタンスに結果を書き込むプロダクションプロセッサの動作を表す。

プロダクションプロセッサの役割は、プロダクション内に規定された規則を、十分な「親結合」および「フィルタ」変換を含む１つまたは複数の一般的かつ構成可能なグラフに注入することであり、この結果、データセットは、conspecに宣言された参照整合性と他の特性を維持するためにユーザに専用グラフを符号化させる必要無しに、プロダクション規則と共に処理されるようになる。

一般的なプロダクション実行グラフ（すなわちprod_run）の基本原理は、処理中の各データセットインスタンスが、プロダクションプロセッサの実行中に既に処理されたすべての先行データセットインスタンスにアクセスできるようにすることである。prod_runグラフは、データセットインスタンスを前に処理された他のデータセットインスタンスへリンクする一般的結合を含んでもよい。したがってプロダクションプロセッサ全体としてのジョブは、関与するデータセットインスタンスの処理順序を決定し、prod_runグラフを構成する各データセットのパラメータを書き込むことである。

この例では、プロダクションプロセッサは、a_customersは処理される必要があり、親を有しないこと、次にa_transactionsは処理される必要があること、親または先行データセットはa_customersであること、を最初に決定してもよい。ある場合には、先行点は、外部／主キーの観点からは親ではないかもしれなく、単に最初に処理されたデータセットかもしれなく、したがって先行点はそのフィールドの１つまたは複数を先行点のものに関連付ける等価特性を有してもよい後続のデータセットにある程度役に立つかもしれないということに注意されたい。

したがって、基本的なケースでは、プロダクションプロセッサは、処理順序が［vector a_customers、a_transactions］形式のデータセット名のベクトルであるということ、a_customersデータセットインスタンスを処理するためのパラメータはdataset_name：a_customers， parents: [vector]であること、a_transactionsを処理するためのパラメータはdataset_name: a_transactions, parents: [vector a_customers]であること、を決定してもよい。

以下の例は、各データセットインスタンスを処理するためにprod_runグラフにより実行される多くのタスクと共に、プロダクションラングラフにより使用される処理順序と様々なパラメータを導出するタスクを説明する。

conspecデータ構造は、一組のデータセットとそれらの制約を、それらのフィールド間の様々なタイプの関係に基づき記述するメタデータのスタンドアロン表現である。いくつかの実施態様では、conspecは、前処理グラフが、一組の共通のＤＭＬ関数を使用する標準的やり方で一組のデータセット間の制約を読み取りナビゲートすることができるようにする。前処理グラフは、下流のデータフローグラフの操作を駆動する構成パラメータを生成することができる。そのため、前処理グラフは通常、レコードセットよりむしろ操作情報を読み取り、下流のグラフおよびプランに供給される「パラメータセット」（または「psets」）と呼ばれるパラメータの組を生成する。パラメータセット内のパラメータは、データフローグラフ中の構成要素の機能にメタデータを与えそれを構成するために使用される。

conspecが前処理グラフと共にどのように使用され得るかの考えを得るために、我々は、主キーと外部キー間の参照整合性を維持する一方でデータセットの集合をフィルタリングする例を取り上げることにする。

この例では、２つのデータセットが顧客とトランザクションを表すと仮定する。トランザクションデータセットでは、フィールドの１つが顧客データセット内の主キーである顧客idを参照する外部キーであると考える。フィルタリング操作の目的は、顧客データセットとトランザクションデータセットの両方からレコードを取り除くが、フィルタリングで除かれた顧客レコードの顧客識別子（ＩＤ）を参照する生成トランザクションレコードが存在しないようにこれら２つの間の参照整合性を維持することである。

このフィルタリング操作を正しく実行するために、システムは処理順序を決定するとともにその順序の関数であるいくつかの制約を維持することができる。例えば、プロセッサは、既に除去された顧客を参照するいかなるトランザクションも含まれないように、顧客を最初に処理し次にトランザクションをフィルタリングすることを決定してもよい。あるいは、プロセッサは、選択されたトランザクションにより参照されるいかなる顧客も除去されないように、トランザクションを最初にフィルタリングするが次に顧客を処理することを決定してもよい。

この例の前処理グラフのジョブは、データセットの処理順序を決定することと、各データセットを処理するグラフの振る舞いを管理する規則を書き込むことである。conspecは、これらの生成タスクを実行するために必要とする情報を前処理グラフに提供する。

conspecの内容は、単一のデータセット内に含まれるフィールドを記述するＤＭＬレコードフォーマットの内容の範囲を越える。ここで、我々は関連するが別個であるデータセット内のフィールドの集合間の関係と関連性について論じている。これは、主キー／外部キー関係などのキー対キー関係だけでなく順序化されたフィールド（すなわち、キー）のグループの定義と、Ｎ個のデータセット間のソートキーに関わる結合と、を含む。

conspecは、一組のレコードベースファイルとして実施されてもよい。この形式では、グラフは、これらのファイルを読み取り、ＤＭＬ関数において使用されるconspecのメモリ内ベクトルベース表現をインスタンス化することができるであろう。別の表現では、conspecは注釈付きＤＭＬパッケージファイルの形式を取ってもよい。このファイルは、キー、キー要素メンバー、関係と関連性を定義する一組の注釈と共にデータセットのそれぞれのＤＭＬレコードフォーマットを含むだろう。この種類の表現は、人間が読むことができかつ編集可能だろう。

システムは、直列化されたconspecを読み取りベクトルの集合を例示するＤＭＬ関数ライブラリを含む。ライブラリは、conspecへの書き込みだけでなくconspec内の関係をトラバースするための関数の組を含む。前処理グラフからの以下のＤＭＬ変換コードは、ファイルからconspecをロードするための呼と引数としてconspecとデータセット名を取る関数とを示し、主キー要素の最大および最小キー値を調べるためのＳＱＬ選択ステートメントを生成する。conspecＤＭＬライブラリは、規定データセットの主キーに関連する要素を得るための関数を提供する。例示的なＤＭＬ関数を図１６と図１７Ａ〜図１７Ｉに示す。

図４Ａに戻って参照すると、図は、５つのデータセットと２つの主キー／外部キー関係と一組のマルチフィールドソートキー間の１つの３元結合関係とを含むconspecを描いて示されている。同図は、conspecのメモリ内表現を読み取るとともに「.svg」ファイルとしてレンダリングに好適な「graphviz」ドットファイルを書き出す一組のＤＭＬ関数により生成された。矢印は２重の目的に役立つ。すなわち矢印は、外部キーと主キー間のフロム・トゥー（from-to）関係を示し、結合関連におけるキーメンバーシップを示す。

conspecが一組のレコードベースデータセットとして実施されるケースに関しては、ユーザはこれらのデータセット間の関係を記述するconspecを生成してよい。これは本質的にconspec群を代表するconspecである。

図４Ｂに戻って参照すると、５つのデータセットの集合を関連付けるconspecが示されている。左側の「dml_dataset」と名付けられたデータセットは一組のデータセットを定義するために使用される。中央上部の「dml_dataelement」データセットは、これらのデータセットのそれぞれの中の要素を定義するために使用される。「dml_datakey」データセットは各データセット内のキーを定義する。「dml_datakeyelement」データセットは、要素メンバーシップに対するキーを定義する。残りのデータセットは、キー間の関係と関連性を定義する。

conspecは、人間が読むことができるやり方で表すことができる。図１６、図１７Ａ〜図１７Ｉに、a-customers、b-customers、それらのトランザクションおよび関係するconsumer_informationからなる図４Ａに示すconspecを記述する注釈付きＤＭＬパッケージファイルのリスト（実行可能コードの一部）を示す。図１６に、conspecと共に使用することができるデータベース照会（例えば、ＳＱＬを支援するデータベースと共に使用されるＳＱＬ照会）を設定するＤＭＬ関数のリスト１６００を示す。図１７Ａに示すリスト１７０２では、キーとフィールド・トゥー・キーメンバーシップ（field-to-key membership）は、ＤＭＬ型定義内のフィールドの右に注釈される。上部の注釈のブロックはキー間の関係と関連性を符号化する。図１７Ｂに示すリスト１７０４は、conspec群のうちの１つのconspecの例を示す。

様々なやり方でconspecを表すことができる。以下の例は、conspecの表現を記述するために、ある専門用語を使用する。conspecは、一組のデータセット間の構造と関係との記述である。conspecインスタンスは、conspecにおいて参照されるデータセットのデータセットインスタンスの集合である。データセットインスタンスは、特定のデータセット（通常はファイルまたはデータベーステーブル内に提供されるレコードの集合等）である。

conspecは、注釈付きパッケージファイルとしてまたは多様なレコードフォーマットに続くレコードの集合として格納されてもよい。いくつかの実施態様では、conspecはルックアップファイルの集合として格納される。構造とこれらのルックアップファイル間の関係は、図４Ｂのconspec群のうちの１つのconspecにより示されるように、conspecを使用して記述することができる。

conspec群のこれらの２つの直列化可能表現（例えば、注釈付きパッケージファイル、またはルックアップファイルの集合（すなわちconspecインスタンス））が与えられると、ＤＭＬ関数の集合によりナビゲートまたは変更されることができるconspecのメモリ内ＤＭＬ表現を提供することができる。このメモリ内表現は、図１７Ｃに示すリスト１７０６の形式を取ることができる。

これは、図１７Ｄに示すリスト１７０８により示されるように、conspecのＤＭＬパッケージファイル表現を分解し、名前によりデータセットを発見し、次にそのデータセットの外部キーを取り出すことを可能にするＤＭＬ関数ライブラリの開発を可能にする。

サブセット化、マスキング、拡張の操作はすべて、ユーザがデータセットの集合とそれらの関連するconspecに適用してよい処理である。これらの操作をconspecプロダクションと考えてもよい。プロダクションは、ソースデータセットインスタンスの場所と識別子およびターゲットデータセットインスタンスの所望の場所と識別子を含むconspecに関連する規則の集合である。ここで、データセットインスタンスは、conspecに記述されたデータセットの実データを参照する。

一組のデータセット間の構造と関係を定義するconspecとは異なり、プロダクションは、そのフィールドが、あるconspecにより定義された制約に従うデータセットインスタンスの集合（例えば、ファイル、ｄｂテーブル等）を処理するための一組の規則を定義する。

conspecはデータセット内のレコード間の依存性等の制約を定義するので、データセットインスタンスの集合内のデータを処理する任意の種類のプロダクションはconspecを使用することより依存性を重んずる順序でそのようにする。例えば、顧客をフィルタで除去することを要求するプロダクションはこの操作を最初に行い、次に従属データセットインスタンスからレコード（トランザクション等）をフィルタで除去する。あるいは、新しい顧客とトランザクションを生成したプロダクションがあれば、システムは第１の顧客データセットインスタンス内に新しいレコードを生成し、次に新しい顧客を参照するためにトランザクションデータセットインスタンス内の新しいレコードを線でつなぐだろう。顧客が既に存在すれば、システムは多分、新しい顧客を生成することなく新しいトランザクションを既存客に線でつなぐことができるだろう。いずれの場合も、conspec内の依存性は、プロダクション規則の性質に依存して参照整合性を実質的に維持するために重んずることができる親から子への処理順序を暗示する。

プロダクション同士を線でつなぐのを支援するために、一般的なプロセッサはプロダクションに固有な署名を使用することにより新しいレコードにＩＤを割り当てる。これにより、１つのプロダクションにより割り当てられたＩＤが次のプロダクションにおいて割り当てられるＩＤと競合しないことを保証する。これの詳細な検討は主キー割り当てに関する章に続く。

図７に、プロダクションプロセッサのタスクを実行することができるプラン７００を示す。プランは、そのノードが実行されるタスクを表しそのリンクがタスクを呼び出す順序を表す有向グラフである。プラン７００は、prod_setupグラフを呼び出すことにより動作し、次に処理順序でprod_profileの実行とデータセット毎のprod_run psets、そしてconspecに定義された依存性と等価性毎のprod_analyze psetsをループスルーする。

プランは、プロダクションの規則に従う処理順序で名前を付けられた各データセットインスタンスをプロファイリングし、分析し、処理するのに必要なパラメータセットと共に、conspecにおけるデータセットインスタンスの処理順序を生成する責任を負うprod_setupと呼ばれるグラフ７０２を実行することにより始まる。prod_setupグラフ７０２は、処理順序、prod_profile、prod_analysis、prod_run psetsを生成する。prod_setupグラフ７０２は図８においてさらに詳細に示される。

図７に示すプラン７００により表されるプロダクションプロセッサの第２番目の工程７０４は、データセットのそれぞれを処理順序でプロファイリングするために使用されるデータフローグラフ（psetsにより構成される）の実行をループスルーすることである。様々な技術の任意のものを、データフローグラフ（例えば、参照により本明細書に援用する米国特許出願公開第２００５／０１１４３６９号に記載された）を使用してデータセットをプロファイリングするために使用することができる。プロファイリングは、プロダクションがデータベースに対しレコードをアンロードまたは更新することを要求してもよい場合と、任意のアップロードを実行する前にデータベース内の主キーの開始および終了指標値を知ることが重要な場合に、必要かもしれない。これは、プロダクションがレコードを拡張または複製することを要求するかもしれない場合に重要である。レコードが複製される場合、各主キーメンバーの新しい主キー値が割り当てられる必要があり、したがってプロダクションプロセッサは、データベース内に既に存在する値と干渉しない新しい値が選択されることを保証するためにデータベースにより使用される既存のキー値の知識を利用してもよい。処理のプロファイリング段階は、処理順序で名前を付けられたデータセット毎の主キー指標のそれぞれの最小および最大値を生成してもよい。プロファイリンググラフは、個々のデータセットを処理するために利用される後続のグラフにより使用されるファイルにデータセットインスタンス毎に最小および最大値を書き込んでよい。単純な場合、prod_runグラフは、レコードを複製してＮ個の新しいレコードを生成し、最大値と最小値の差に跨る範囲のブロック内において新しい主キー値を割り当て、これによりデータベースにアップロードされた新しいレコードがデータベース内に既に存在する値と競合しないことを保証してもよい。

図７に示すプラン７００により表されるプロダクションプロセッサの第３番目の工程７０６は、conspecに定義された依存および等価特性のそれぞれを分析することである。図４Ａに示すab_conspecの例では、結合関連性は３つのデータセット、a_customers、b_customers、consumer_info間の等価性を定義する。この工程では、プロダクションプロセッサはデータセットインスタンスのそれぞれを読み取り外部結合を実行することによりこの特性を分析する。外部結合の重複結果は集められ、フィルタリングを行なうためにprod_runグラフにより用いられる分布分析ファイルに書き込まれる。この工程の詳細は図１０と図１１の検討時にカバーされる。

図７に示すプラン７００により表されるプロダクションプロセッサの第４番目の工程７０８は、各データセットインスタンスを処理するために使用されるデータフローグラフ（psetsにより構成される）の実行をループスルーすることである。この工程は、後続の図１２Ｂ〜図１２Ｆに示す副工程を有する図１２Ａに示すグラフprod_runを呼び出すことを含む。

図１８Ａと図１８Ｂに、考慮すべきデータセットの初期シードセットと走査および包含（traversal and inclusion）から除外すべき一組のデータセットが与えられたとして、親から子までの処理順序を生成するためにプロダクションプロセッサにより使用されてよい論理１８０２、１８０４の例を示す。シードおよび除外データセット（seed and exclusion datasets）をプロダクションの一部としての規則として渡してもよいということに留意されたい。conspecは、処理順序を含む際に考慮されるすべてのデータセットのスーパーセットを定義してもよい。

a_customers、b_customers、a_transactionsなどを含むab_conspecを参照して、ユーザはa_transactionsを除外することを選択してもよい。この場合、処理順序はa_customersから始まるが、a_transactionsを含まないだろう。同様に、ユーザがソースのリスト内にa_customersを含まないことを選択すれば、a_customersもa_transactionsも処理順序に含まれないだろう。

図１８Ａと図１８Ｂは、プログラミング機能のように見えるように擬似コード形式の論理１８０２、１８０４を提示する。論理１８０２のmain関数は、空のprocessing_orderベクトルを初期化し、次に処理順序を投入する関数を呼び出すことにより始まる。このmain関数は、タスクが完了するまでprocessing_orderベクトル内に書き込む。

main関数は、名前を付けられたソース内の各データセットをループスルーしデータセット毎にデータセットのベクトルとそのすべての子を再帰的に導出するgen_processing_order関数を利用する。main関数は次に、結果をall_resultsベクトルに加え、重複値がないことを確認する。順序はこの時点では重要ではなく、再帰的にすべての子を包含することだけが重要である。

gen_processing_orderがすべての関与データセットのリストを導出すると、gen_processing_orderは、最も高いレベルの親（すなわち、all_ resultsの組にも含まれる親を有しない親）を決定することに進む。これを決定する関数はupdate_processing_orderである。この関数は、all_ resultsの組において最も高いレベルの親に達するまで親を昇ることにより再帰的に作用し、次にこの最も高い親データセットをprocessing_orderベクトル内にダンプする。次に、残りのデータセットはprocessing_orderベクトル内にそれを順にダンプすることができるまで最も高いレベルの残りの親を発見するために再び再帰的に昇ることにより処理される。

関数get_dataset_and_its_children_recursivelyは、直接の子に作用し次にそれ自身を呼び出す再帰関数を呼び出す先頭の関数として機能する。ここでトップレベルの関数は、再帰的にすべての子のリストになる当初空のベクトルを有するget_dataset_and_its_childrenを呼び出す。この関数get_dataset_and_its_childrenはソースデータセットの直接の子に働きかけ、それ自身を呼び出し、累積データセットのベクトルをその再帰呼出しに伝える。

全体処理は最初に、すべてのall_resultsの組を得るために子を再帰的に得ることを含む。但し、この処理はこのすべてのソースの組から親を再帰的に得ることにより終了する。

図９Ａと図９Ｂに、この論理を使用する処理順序と、順序を導出するために使用される付随conspec群との例を示す。図９Ａは、子が処理される前にすべての親が処理されることを保証する処理順序９０２の例である。示された処理順序はＡ、Ｃ、Ｆ、Ｅ、Ｄ、Ｂである。図９Ｂに、子が処理される前にすべての親が処理されることを保証する処理順序を示す複雑なconspec９０４を示す。示された処理順序はOpJobDefinition、JobDefinitionPropertyValue、OpTimeConstraint、OpDay、OpJobDefinitionDependency、OpFileAndEventConstraint、OpJobDefinitionAction、OpJobDefinitionActionArgumentである。処理順序を生成するための論理の他の実施形態は子から親への順序を決定することを含んでもよい。

図７のprod_analyze工程706は、conspec内の各依存性と等価性がプロダクションにおいて特定されるデータセットインスタンスの組に関し分析され得る工程である。conspecに関連するデータセットインスタンスの各集合は、特性毎に異なる重複の分布を提示するかもしれない。例えば、a_customersとa_transactions間などの依存性により、ある組のインスタンスの比較的少数の顧客に関連する多くのトランザクションが存在する可能性がある。しかしながら別の組のインスタンスでは、顧客毎には比較的少数のトランザクションであるがすべての顧客全体にわたってより均一な分布が存在するかもしれない。このような依存性の特徴を知ることは、既にフィルタリングされた先行点のデータセットインスタンスと比較する際にどのレコードをソースデータセットインスタンス内に保つかを判断するのに有用かもしれない。

依存特性と同様に、等価特性は、データセット間のキー対キー等価性を定義する。しかしながら依存特性と異なって、等価特性はフロム−ツーとは対照的に、多対多と考えてよい。例えば、ab_conspec（図４Ａ）では、結合１等価性は３つのデータセットを含むように定義される。これらのデータセットのそれぞれは、他のデータセット内のキーと等価であると考えられ得るキーを有する。等価性は、等価性が依存特性を伴うであろうように、１つのデータセット内のレコードの存在が別のデータセット内のレコードの存在を強要しなければならないことを示唆しなく、むしろ、関与データセットからの２つのレコードが同じキー値を共有すればそれらは同じ意味を有し等価である。

図１０と図１１は、等価特性を分析するための処理工程と結果を示す（例えば、図７に示すプラン７００により表されるプロダクションプロセッサの第３番目の工程７０６の一部として実行される）。図１０は、「最大３元」結合分析器の構成を示す。特に、これは、conspecに定義された結合依存性と等価特性を分析するために使用されるprod_analyzeグラフ１０００である。その結果は、関与データセットインスタンスの外部結合重複データと分布ヒストグラムである。

別の実施形態では、このメカニズムは最大Ｎ個の同時結合を支援し、conspec内に等価特性に対して定義されるように、異なる数のデータセットインスタンスを支援するように構成可能であってよい。

処理における外部結合１００２は各入力データセットをそのそれぞれのキー要素メンバーについてソートするように構成されてもよい。prod_setupグラフはさらに、データセットインスタンスのそれぞれのソートキーのそれぞれを示すprod_analyzeグラフを提供するpset内に既に書き込まれたパラメータを有してもよい。ab_conspecの例では、a_customers、b_customers、およびconsumer_infoデータセットはすべて、そのメンバーが{place;building_num｝であるキーを有するが、キーメンバーはデータセットインスタンス毎に異なってもよい。

外部結合１００２は、各データセットインスタンスからのレコードヒットを結合し、次に関与データセットインスタンスのヒットステータスを有するキー値組み合せの発生を一意的に特定してよいキー値のハッシュ値を計算する役目を果たす。例えば、１つのキー値組み合せがplace=”foo”とbuilding_num=”bar”ならば、これは例えば「１２３４５」のaggregate_valueハッシュを生成し、出力レコードは各データセットのヒットステータスを含むだろう。すなわちsource_dataset_1は実際に当該値などを有していた。

図１７Ｅに示すリスト１７１０は、関与データセットインスタンスの集約ハッシュ値とヒットステータスを計算するために使用されてよい関数の例である。

prod_setupグラフ７０２はこの変換を生成し、prod_analyzeグラフ（例えば、図７に示す工程７０６）をターゲットとするpset内のパラメータ値としてそれを渡してもよい。このパラメータ値は、関与データセットのそれぞれの生成されたキーパラメータ値の組を伴ってもよい。

分析ヒストグラム生成工程１００４は、外部結合１００２の出力を取り、ヒット結果の集約を行う。出力レコードのストリームは外部結合から一意的集約値（すなわち外部結合からのキー値の一意的組み合せ）を示す。このようなレコードのストリームは次にヒットフィールド：source_1_hit, ..., source_N_hitによりソートされ、スキャンおよびロールアップ構成要素内に供給される。この時点で、各レコードは、各データセットソースが当該キー値組み合せを有することに関与したかどうかのヒットステータスに加えて、外部結合内のキーの一意的集約値を示す。ヒットフィールドによりレコードをソートし、それらをスキャンおよびロールアップ内に渡すことにより、システムは、各レコードにおいて発見されたヒットステータスの組み合せのランニングカウントと合計カウントを決定することができる。したがって例えば、最初のレコードがplace=”foo”とbuilding_num=”bar”の集約値を有すれば、スキャン／ロールアップは、データセット１とデータセット３の両方がキー値の当該組み合せを有することに関与したことを示す組み合せヒット（１，０，１）を探索するであろう。構成要素はまた、探査してこれがこのヒットの組み合せの最初の発生だったことを理解し、このレコードに１のランニングカウントと１の合計カウントを割り当てるだろう。第２番目の集約値レコードが異なるヒットの組み合せを伴って来れば、第２番目の集約値レコードにも１のランニングカウントと１の合計カウントが割り当てられるだろう。第３番目の集約値レコードが最初のレコードと同じヒットの組み合わせを伴って来れば、第３番目の集約値レコードには２のランニングカウントと２の合計カウントが割り当てられるだろう。

この処理の結果は、外部結合１００２の一意的キー値の組み合せを表す一組のレコード（結合分析レコードと呼ばれる）である。レコード毎に、システムはまた、どのソースデータセットインスタンスが結合に関与したかと、どれだけの合計カウントのレコードが、だけでなくそれぞれがこのヒットの組み合せを有して表されるどれだけのランニングカウントが、このヒットの組み合せと共に発生したかと、を知ってもよい。この情報はprod_runグラフにおいて実行される下流操作にとって有用かもしれない。例えば、prod_runグラフは、この結合分析に関連するデータセットインスタンスの１つを結合結果に結合させるように構成されてもよい。結合は、ソースデータセットインスタンスにおける関与キー要素値を使用して対応計算値と結合された分析結果からの集約値キーを使用することにより実行されてもよい。結合は、ソースデータセットのレコード毎に、類似キー値を有するレコードが、conspecに定義された等価特性（例えば、関連性）に関与する他のデータセットインスタンスのいずれかにおいて発生したかどうかを示す。

図１１に、ab_conspecに関連するプロダクション内に定義されたデータセットインスタンスの集合のチャート化ヒストグラム結果１１００を示す。これは、重複した依存性または等価性の結合において定義された関与データセットインスタンスからのレコードの数を示すprod_analyze分布ヒストグラムである。「１」は、データセットインスタンスが当該グループ内にレコードを有したということを示す。グループは、結合キー上に一致値を有するレコードの集合である。この例は、図４Ａのab_conspecに定義されたa_customers、b_customers、consumer_info結合からの結果を示す。

これらの結果１１００は、ab_conspecに定義された結合１関連性に適用されるプロダクション分析処理（例えば、図７のprod_analyze工程７０６）の結果である。３つのデータセットは他のデータセットからのいかなる対応レコードとも一致しない多数のレコードを有すると理解してよい。キー値の組み合せのうちのいくつかだけが、データセットインスタンスうちの２つからの、または３つすべてからのレコードを有する。したがって、これらの結果から、ユーザがa_customersデータセットインスタンスからのレコードをフィルタリングして、プロダクション／conspecに関連する他の２つのデータセットインスタンスと共にヒットの組み合せの分布を維持することを望めば、そのキー値が１−０−１と１−１−０グループに入るレコードを含むように注意しなければならないであろう。換言すれば、ユーザがこれらの結果を使用することなくa_customersからのレコードを不注意に選択すれば、b_customersとconsumer_info内に一致するレコードを有したレコードの大部分またはすべてを取り落とし易いであろう。このような不注意なa_customersからのレコードの選択は、conspecに定義された結合特性により表された外部結合分布特徴とプロダクションにおいて特定されたデータセットインスタンスにより表された特定値とを壊すだろう。

prod_analyzeグラフ（例えば、図７のprod_analyze工程７０６）が、conspecに定義された等価特性（例えば、その値が等価な意味を有するフィールド間の関連性）のそれぞれの分析結果を生成したならば、図７に示すプロダクションプロセッサプラン７００は、処理順序で特定される各データセットインスタンスに関連するpset毎にprod_runグラフ（例えば、工程７０８）を呼び出してもよい。図１２Ａに、psetにより提供される入力値の集合を使用してデータセットインスタンスを処理することに関与する工程を示す。この工程は、処理順序でデータセットインスタンス毎に実行されるprod_runグラフ１２００の構成要素として表される。

図１２Ａの例の最初の工程１２０２は、プロダクション内のデータセットインスタンス毎に提供される命名規則に従って入力「ソース」データセットインスタンスをロードすることである。データセットインスタンスの名前と発生元はそのpsetパラメータの１つとしてprod_runグラフに提供されてもよい。データセットインスタンスはファイルに由来する必要はない。あるいは、データセットインスタンスは、プロダクションにおける入力として提供されるＳＱＬステートメントを使用してデータベーステーブルからアンロードされてもよい。任意の可能なデータソースが、ウェブサービス、連続的流れからのデータのスナップショット、データベース、フラットファイル、または別のデータソース等のデータセットインスタンスとなってよい。プロダクションは、プロダクションから読み出されてprod_run pset内に書き込まれるパラメータを介し様々なタイプのデータセットインスタンスのそれぞれを見つけてロードするために、プロダクションプロセッサに十分な情報を提供する。prod_setupグラフは、プロダクションから各データセットインスタンスの場所の情報を抽出し、このデータを入力パラメータとして、prod_runグラフを提供するpsetに書き込む。

図１２Ｂに、prod_runグラフ１２００のデータ読み取り工程１２０２の詳細を示す。この例は、データベーステーブルまたはフラットファイルのいずれかを含むローディングフローである。より完全なロード構成要素が、他のタイプのソースからデータセットインスタンスをロードできるようにしてもよい。さらに、conspecにおいて特定される各データセットインスタンスは他とは異なる表現と場所を有してもよい。換言すれば、プロダクションは、プロダクションプロセッサに指示してフラットファイルから第１のデータセットインスタンスそしてデータベーステーブルから第２のデータセットインスタンスをロードさせてもよい。加えて、conspecＡに関連する第１のプロダクションがファイルからデータセット１のインスタンスをロードすることを要求し、一方、同じこのconspecＡに関連する第２のプロダクションはデータベーステーブルなどの異なるソースからデータセット１の異なるインスタンスをロードすることを要求していてもよい。

図１２Ａに戻って参照すると、データセットインスタンスがprod_runグラフ１２００によりロードされると、第２番目の処理工程１２０４はprod_analyzeグラフ（例えば、図７の工程７０６）により生成された依存性と等価性結合結果のそれぞれに対して１つまたは複数の結合操作を実行する。a_customersの場合（例えば、図４Ａに示すように）、本明細書に記載の結合１分析結果に対して実行された結合があるかもしれなく、これによりprod_runグラフ１２００が、b_customersとconsumer_info内の等価なレコードを共有したa_customersからレコードを特定できるようにしてもよい。次にprod_runグラフ１２００は、前に処理されたb_customersまたはconsumer_infoデータセットインスタンスからのレコードとの同じ重複を維持するように、a_customersデータセットインスタンスから所望の割合のレコードを包含及び除外してもよい。

ソースデータセットインスタンスとprod_analyze処理からの１つまたは複数の結合分析結果セットとを結合させることの代替として、prod_runグラフ１２００は既に処理された親データセットインスタンスと直接結合してもよい。次にprod_runグラフ１２００は内部結合を実行し、当該の一致を有しないソースデータセットレコードを単純に除去してもよい（例えば、conspecに定義された依存特性に基づき）。

プロダクションプロセッサ（例えば、図６に示すプロダクションプロセッサ６００）の機能の１つは、データセット毎に処理されたデータセットインスタンスを処理順序で書き出すことと、処理されると後続データセットインスタンスに結合されるようにこれらの処理されたインスタンスを「線でつなぐ」ことである。加えて、プロダクションプロセッサの第２の機能は、conspecにおいて特定された依存性と等価特性を分析することと、当該データセットインスタンスの内部結合特徴と外部結合特徴を説明するこれらのヒストグラム結果を書き込むことである。さらに、プロダクションプロセッサの第３の機能は、既に処理されたデータセットインスタンス内の等価または依存性レコードを共有してよいレコードをprod_runグラフ１２００が特定できるように、これらのヒストグラム結果と各ソースデータセットインスタンス間の結合を「線でつなぐ」ことである。

用語「線でつなぐ」は、処理順序でデータセット毎にprod_run psetsに特定パラメータ値を書き出すことによるprod_setupグラフ（例えば、図７に示すグラフ７０２）の実行を指す。これらの特定値は、処理されたデータセットインスタンスの名前を識別し、conspecの依存性と等価特性により定義される主キー値を含む。これらの値は、prod_runなどの一般的グラフが、既に処理されたデータセットインスタンスに対してロードおよび結合するように動的に構成できるようにする。

依存性結合を実行する工程（例えば、工程１２０４）の間、prod_runグラフ１２００は、prod_runグラフの先行実行から零または複数個の出力データセットインスタンスをロードする。prod_setupグラフ７０２（図７）は、特定のソースデータセット用にＮ個の先行データセットインスタンス（すなわち、一実施形態における親）をロードする必要があると判断したかもしれない。prod_setupグラフ７０２は、prod_runグラフ１２００のソースデータセットの入力pset内のパラメータとして対応出力データセットインスタンスの場所を書き込むことができる。加えて、prod_setupグラフ７０２は、どれだけの数の先行データセットインスタンスをロードする必要があるかもしれないことを示すためにパラメータを書き込むことができる。

「依存性および等価性結合」と名付けられた図１２Ａの第２番目の工程１２０４は、可変数の先行データセットインスタンスをロードする役目を果たしてもよい結合メカニズムの実施形態を示す。この工程１２０４の詳細を図１２Ｃに示す。入力pset内に提供されたパラメータに依存して、このメカニズムは、先行データセットインスタンス毎に１つの結合ソースを活性化してもよい。この処理は、対応先行データセットインスタンスの１つまたは複数のインスタンスからのレコードを正常に「内部結合する」またはそれに一致すれば、ソースレコードを選択できるようにしてもよい。各先行データセットインスタンスにこの結合を実行するために、prod_runグラフは、ソースデータセット内の外部キーソート要素の知識と各先行データセット内の対応主キーソース要素とを与えられる。この情報はprod_setupグラフにより計算され、追加のpsetパラメータとしてprod_runグラフに渡される。

この結合工程は、conspecに定義された依存（すなわち関係）および等価（すなわち関連）特性を共有する他のデータセットインスタンスと一致または一致しないレコードの分布を維持する目的のためにソースデータセットインスタンスに作用する。この例では、a_transactionsがソースデータセットと考えられる場合、この結合メカニズムは、prod_runグラフの先行操作において既にフィルタで除去されたa_customersデータセットインスタンスからのレコードと一致しないa_transactionsデータセットインスタンスからのレコードを除去することを保証してもよい。これは、「内部結合」特性を維持する工程と呼ばれる。この例では、これは、a_customersからのいくつかの参照レコードが既に除去されたとすれば有効でないかもしれないレコードをa_transactionsから除去することが重要であることを意味する。

依存特性のフィルタリングに加え、この結合メカニズムはまた、等価特性をフィルタリングしてもよい。図４Ａのab_conspec４００における等価特性の例は、a_customers、b_customers、consumer_info間で定義された結合１等価性である。図１１に示すヒストグラム結果１１００を生成した分布分析は、a_customersおよびb_customersなどの既に処理されたデータセットインスタンスに対するconsumer_infoなどのソースのレコードの分布をも維持するために、この結合工程により利用されてよい。換言すれば、この結合メカニズムは一組のピア関係データセットインスタンス間の「外部結合」特徴が維持されることを保証してもよい。したがって、元のa_customersとconsumer_infoからのレコード間に高程度の重複があるが元のa_customersとb_customersからのレコード間に低程度の重複があれば、この結合はb_customersとconsumer_infoの２つの既に処理された集合を評価し、そしてその結果が元のものと同様な分布を維持するように一組のa_customersをフィルタリングしてもよい。一般的には、これは、元のデータセットが必要としたように、処理されたデータセットが処理されたデータセット間で同じ種類の重複を有する必要がある場合に重要である。

プロダクションプロセッサのタスクの１つは、プロダクション内に定義された規則の集合により規定されるように、様々なデータセットインスタンス内のレコードへの変換をすべて完全に実行する一方で、conspecに記載された等価性と依存特性により表される分布パターンを維持することである。

図４Ａに示すab_conspec４００からのa_customersとa_transactionsの例を参照し、我々は、ソースデータセットがa_transactionsである場合であって、かつa_transactions（すなわち、a_customers）に対する１つの先行点が存在するとprod_setupグラフ７０２が既に判断した場合を考えてもよい。prod_setupグラフはa_transactions（a_customersを参照するもの）の外部キー要素をソートキーの形式｛custid｝で書き込んだかもしれない。さらに、prod_setupグラフはa_customersデータセットの主キー要素をソートキーの形式｛custid｝で書き込んだかもしれない。これらの異なるソートキーは、その対応データセットとは異なる名前の要素を参照してもよいので、異なる値を有してもよい。特定の先行データセットの外部キー要素とその対応する主キー要素とを決定するためにprod_setupグラフにより必要とされる情報は、プロダクションプロセッサの設定処理の一部として読み取られてよいconspec内で発見されるかもしれないということに留意されたい。

１つまたは複数の先行データセットインスタンスに対してソースデータセットインスタンスの結合およびフィルタ処理を実行するために、prod_runグラフ１２００はそれぞれのソートキーを必要とするかもしれない。図１８Ｃと図１８Ｄは、conspecにおいて概要を述べたようにソースデータセットと外部キー／主キー依存性を共有するそのＮ個の先行データセットとの間の結合リンクとして機能するソートキーを生成するために使用される論理１８０６、１８０８の例を示す。これらの機能は、プロダクションプロセッサ（例えば、図７に示すプラン７００により表されるプロダクションプロセッサ）のprod_setupグラフ７０２において実施されソースデータセットのprod_runグラフ１２００のpset値を生成する処理の一部と呼んでもよい。

これらの例における論理は、ソースデータセットとその先行データセットのうちの１つとの間の第Ｎ番目の依存性関係を特定するために提供される指数を利用してもよい。我々のa_customersとa_transactionsの例では、a_transactionsからa_customersへの１つの依存性関係だけが存在し、したがってこの指標はただ１つの値０を有することになる。

get_fkey_sort_elementsと呼ばれる第１の関数は、prod_setupにより導出されるprocessing_orderベクトルに含まれる親データセットを発見することから始まる。次に、上記関数は、これらの親を参照するソースデータセット内の外部キーを発見するためにこれらのデータセットを使用する。一組のキーから、上記関数は第Ｎ番目のキーを獲得し、ソースデータセット内のキー要素を抽出する。マルチパートソートキーを書き出すためにこれらのキーの順序を読み取って使用してよい。

同様に、get_pkey_sort_elements関数は、親データセットのうちの１つにおいて主キーソート要素を生成するために呼び出されてもよい。図１８Ｄに示す論理１８０８は、処理順序で同時に発生する親データセット（これらの親データセットは既に処理されているかもしれない）を探索するためにソースデータセットを使用する例である。親が与えられると、上記機能は、ソースデータセット内の外部キーを探索し、ソース親を指す外部キーを選択してもよい。この外部キーのセットが与えられると、上記関数は第Ｎ番目のキーを選択し、次にソース親内のその対応主キーを見出してもよい。この主キーから、上記関数は、キー要素メンバーのシーケンスを発見し、マルチパートソートキーを書き出してもよい。

これらの２つの関数は、prod_setupグラフ１２００がソースデータセットの外部キーを周期的に繰り返して、ソースと親データセットペア毎にソートキーのグループを生成できるようにする。次にprod_setupグラフは、ソースデータセット毎にprod_run psetにパラメータとしてこれらのキー値を書き込んでもよい。

prod_runグラフ１２００の第３、第４、第５番目の処理工程１２０６、１２０８、１２１０はプロダクションにより提供されるカスタム変換規則を適用するために使用される。データセットインスタンスに適用されてもよい３種類の変換が基本的に存在する。工程１２０６（サブセット化）は、ソースデータセットインスタンスからのレコードを削除しなくてはならないかどうかを判断することを含む。別の工程１２０８（修正）は、同じインスタンスからのレコードが変更されなければならないかどうかを判断することを含む。変更は、要素を追加または除去することおよび／または要素の値を修正することを含んでもよい。別の工程１２１０（拡張）は、同じインスタンスからのレコードがＮ個の新しいレコードに複製されなければならないかどうかと、新しいレコード毎に新しい値は何でなければならないかと、を判断することを含む。

単一のプロダクションは、これらのタイプの変換のうちの任意のものを要求してもよい。これらの変換は、プロダクションプロセッサにより連続して適用されてもよい。例えば、プロダクションは、prodidと価格の要素に関する度数分布などの特性により特徴付けられるような統計的一貫性を維持するために一組のa_transactionsを最初にサブセット化することを要求し、次に残りのレコードを複製するためにサブセット化結果を拡張し、新しい値を「展開」して様々な取引期日を有してよい。用語「展開」は、ある範囲全体にわたって新しい値を分布させる式を使用してＮ個の新しい複製レコード内の要素の値を修正する行為を指す。したがって、取引期日などの期日を展開する場合、プロダクションは当該期日にＭ日を加えることにより期日を展開するように規定してもよい。ここで、ＭはＮ個の複製された新しいレコードの指標である。

プロダクションプロセッサの機能はプロダクションにより規定されるように、任意のサブセットの組み合わせを適用するための一般的メカニズムを提供し、修正しそして変換を拡張することである。これらの変換のそれぞれはプロダクションにより提供される論理を組み込んでもよいが、それぞれがまた、先行の処理済みデータセットインスタンスの結果を利用することを含んでもよい。

プロダクションプロセッサは、プロダクション規則と共に先行の処理済みデータセットインスタンスの結果を取り込んでもよい。例えば、プロダクションは、a_transactionsを複製することと取引期日フィールドを展開することとを要求してもよい。この例では、プロダクションは図４Ａに示すab_conspec４００と関連付けられてもよいであろう。

a_transactionsの拡張は、複数の要因のうちの任意のものに依存してもよいであろう。例えば、プロダクションはa_transactionsだけでなくa_customersも変換することを要求してもよい。一例では、a_customersは、顧客毎にそれぞれの主キーの対応する新しいかつ一意的custid値を有するＮ人の新しい顧客が存在するように最初に拡張されてもよい。a_transactionsが拡張される場合、新しいa_transactionレコードを取り扱う少なくとも２つのやり方が可能かもしれない。１つのやり方は、新しいa_customerレコードの１つを参照するためにそれぞれの新しいa_transaction custid値を修正することを含み、別のやり方は、元のa_transactionレコードが指したのと同じa_customerレコードを指すためにそれぞれの新しいa_transactionレコードを残すことを含む。あるいは、a_customersが拡張されずむしろ低減されれば、拡張されるa_transactionレコードは、含まれたa_customerレコードだけを参照するために最初にサブセット化されていなければならなく、含まれたa_customersだけを参照するようにcustid値を未変更のままにして拡張されてよいであろう。

プロダクションプロセッサは、conspecに定義された依存および等価特性に従って参照整合性のメンテナンスを扱う。

いくつかの例では、サブセット化プロダクションは、子を介してレコードを再帰的にフィルタリングすることができる。例えば、単一のプロダクションは、conspec内のデータセットの１つに適用される単一のフィルタリング規則を含んでもよい。加えて、プロダクションはまた参照整合性を維持するすべてのデータセットインスタンス間の最少組のレコードだけを残して他のデータセットインスタンスからのレコードを除去するという暗黙規則があってもよい。

一例として、図４Ａに示すconspec４００を参照すると、ユーザは、顧客場所フィールドが「Atlantic」の値を有した顧客とトランザクションだけを保持するようにしてよい。ユーザは新しいプロダクションを定義し、それをab_demo conspecに関連付け、次に２つのフィルタ規則、すなわちa-customersデータセットに関するものとb-customersデータセットに関するものとを表すだろう。規則は、place=”Atlantic”を示すフィールドレベルの制約であろう。

フィルタ規則を提供することに加え、ユーザはまた、参照整合性を維持するためにすべてのデータセットインスタンス全体にわたる最大組のレコードを保持することを要求する「グローバル規則」を規定してもよい。

最後に、ユーザは、データセットインスタンスファイル、データベーステーブル、またはconspecに定義されたデータセットのそれぞれの他のデータソースの識別子と場所を規定するだろう。

このプロダクションが与えられると、一般的プロダクションプロセッサはconspecとプロダクション規則の両方を解釈し、データセットインスタンスの処理順序を最初に決定するだろう。フィルタ規則はフィルタ規則に依存する子データセットを有するデータセットに適用されるので、プロセッサは、顧客データセットインスタンスから始まる処理順序を最初に導出するだろう。

一般的プロセッサが実行する必要のある作業の最初の部分は、任意の変換、結合、または各データセット処理タスクにより必要とされる他のメタデータと共に、全体の処理順序の生成である。この例では、プロセッサは、結合される親を有しない顧客に最初に作用する必要がある。しかしながら、トランザクションレコードのそれぞれは、選択された顧客に正確に一致する最大組のトランザクションを生成するように、対応する選択された顧客と内部結合される必要があるので、顧客処理の出力は保存されトランザクション処理工程に使用可能とされる必要がある。

処理の最初の部分がデータセット処理順序とすべての結合論理、変換などを生成すると、プロセッサはループサブプラン内のグラフにより各データセットインスタンスの処理を渡してもよい。

図１２Ｄに、prod_setupグラフ７０２によりパラメータとして提供される変換関数を適用するサブセット化変換工程１２０６の一実施形態を示す。フィルタは、これらに限定しないが単一レコードと度数分布を含む複数タイプのものであってよい。

単一レコードフィルタにより、レコードを選択または削除するために各レコード内の値だけを使用することができる。このタイプのレコードの例は、プロダクションの一部として提供される図１７Ｆに示すリスト１７１２内に示す変換関数に示される。この例では、a_customersデータセットからのレコードはすべて選択されるが、b_customersデータセットからのレコードは、「place」要素が文字「Ｍ」から始まる場合に限り選択される。prod_setupグラフ702はプロダクションからこの関数を読み取り、次にデータセット毎に関数を呼び出しデータセット毎にサブセット化フィルタの値を得てもよい。

第２のタイプのフィルタ（度数分布）は、統計的一貫性を維持するための制約に基づく変換の例であり、データセットインスタンス内のいくつかの名前付き要素全体にわたる値の度数分布を分析することを含む。度数ベースのフィルタリングの目標は、一組の要素値の組み合せ全体にわたる値の分布を依然として維持する一方で、ソースデータセットインスタンスからレコードを除去することである。例えば、ユーザはa_transactionsをフィルタリングすることに関心を持ってもよいが、元のデータセットインスタンスにおける値の度数分布と同じである価格、prodid、transtypeフィールド全体にわたる度数分布を維持するやり方でフィルタリングしてよい。プロダクションの一部として提供される図１７Ｇに示すリスト１７１４内に示す変換関数は、度数分布フィルタリングのために考慮されなければならないデータセットから要素の名前を獲得するためにprod_setupグラフにより使用されてもよい。加えて、この変換は、連続要素を列挙値に「バケット化する」（データセットインスタンスが無限数個の値を有してよいことを意味する）式を与える。これにより、prod_runグラフサブセット化変換工程１２０６が、名前付き度数分布要素の１つまたは複数の要素の値の離散集合によりレコードをサブセット化できるようにする。このようにして値がバケット化されると、システムは各バケットグループに入るレコードのカウントに基づきサブセット化を実行してもよい。この例では、プロダクションはa_transactionsとb_transactionsの価格をバケット化するとともにconsumer_infoのest_income要素をバケット化する式を提供する。式が要素の値を単に戻す場合、これは、一組の値が適度なサイズの列挙であると既に考えられたことを意味する。

図１２Ｄに示す工程は、プロダクションにおいて名付けられた度数分布フィルタ要素の値の一意的組み合せを有するレコードのカウントを評価しロールアップするタスクを実行する。スキャンとロールアップが実行されると、レコードは単一レコード規則と度数分布規則の両方に従ってフィルタリングされる。このとき、サブセット化レコードの元レコードに対する一致性を示すために別の度数分析が生成レコードに対しなされる。このデータは、ヒストグラム図に書き込むことができる（例えば、図１３に示すように）。

いくつかの例では、プロダクションプロセッサの機能は、プロダクションにおいて名付けられたデータセットインスタンスのそれぞれの新しい処理済みデータセットインスタンスを書き出すのではなくむしろ、処理工程のそれぞれから導出されるレポート情報を書き出すことである。

図１３に、placeおよびest_income要素に関する度数分布により特徴付けられるような統計的一貫性を維持しつつ１／５の低減を要求するプロダクション規則を使用してサブセット化変換を適用した結果の生成されたヒストグラム１３００を示す。ヒストグラム１３００は、consumer_infoデータセットに適用されたサブセット化操作からの度数分布結果を示す。

図１２Ｅに、ソースデータセットインスタンスにおけるＮ個の複製レコードのそれぞれに対しカスタム展開規則を適用することができる拡張変換処理工程１２１０の実施形態を示す。

拡張は、１つまたは複数のデータセットインスタンス内に新しいレコードを生成する処理である。このレコードは、最初から、または既存のレコードの複製により生成されてもよい。複製中のレコードが他のデータセット内のレコードに対する依存性を有すれば（conspecに定義されたように）、プロダクションは、子データセットインスタンス内の新しいレコードを親データセットインスタンス内のものへ「線でつなぐ」かどうかを判断する。あるいは、プロダクションは親レコードも同様に複製し、そして新しい親を指すために新しい子を線でつないでもよい。このようにして、関係レコードの集合は参照整合性を維持しながら複製されてよい。

図１２Ｆに、prod_runグラフ１２００の最終工程１２１２である書き込データ機能を示す。

図１４に、conspec（この例では、データフローグラフにより実行されるジョブのランタイム実行の監視を可能にするアプリケーションに関連するconspec）における複数のデータセット内のレコードが拡張される拡張１４００を示す。この場合、プロダクションはジョブ定義とアプリケーションを最初に複製し、次にジョブを複製する。各新しいジョブは、各新しいジョブ定義とアプリケーションを参照するように線でつながれる。各データセットインスタンス内のレコードを拡張するジョブに取り組む前に、プロダクションは、データセットの全体処理順序を最初に決定する。この場合、すべての依存する親が処理される前にいかなる子も処理されてはならない。ここで、子は、親データセット内の主キーに対する外部キー参照を有するデータセットである。

最も基本的な拡張では、プロダクションプロセッサは、テンプレートとして各元レコードを使用することによりＮ個の新しいレコードを複製してよい。各新しいレコードの各フィールドは、主キー、外部および／または一意キーを含む場合に新しい値を得ることを保証するように処理される。主キーの場合、新しい値は既存のキー値と競合しないように選択される。外部キーの場合、値は新しい拡張された親レコードの対応する新しい主キー値を指すために変更される。一意キーの場合、値は、当該タイプのすべてのレコードの空間内の一意性を保証するために元のものから変更される。例えば、ＧＵＩＤフィールドを一意的なものにすることができる。

これらのフィールド拡張規則の実行に加えて、拡張プロダクションプロセッサはまた、タイプ毎ベースでユーザ定義フィールド拡張規則の入力を支援する。ここでの目標は、プロセッサが多次元にわたってフィールド値を拡張すると同時に「広げる」ことができるようにすることである。例えば、ユーザは一組のジョブ定義の拡張を望むかもしれない。しかしながら、各新しいジョブ定義は、そのスケジュールされた開始時間が、元のスケジュールされた開始時間から一定量だけインクリメントされることを必要するかもしれない。

フィールド拡張規則を規定する１つのやり方はプロダクション内にＤＭＬ関数を埋め込むことによるものである。図１７Ｈに示すリスト１７１６内に示す例示的ＤＭＬ関数は、ジョブに対してスケジュールされた開始時間を除いたすべての場合のディフォルト規則とジョブ定義依存性に関するＧＵＩＤフィールドとを出力するカスタム拡張規則生成器を示す。第１の場合、上記関数は、新しいレコードのスケジュールされた開始時間に現在の拡張指標値に対応する第２の数を加える規則を構築する。この規則により、新しいジョブは、拡張のサイズに対応する秒数にわたって均一に分散されたインクリメントされた開始時間を得る。ＧＵＩＤの場合、上記関数は、ＧＵＩＤがあたかも外部キー参照であるかのように振る舞うことになるのでプロダクションプロセッサのキー生成関数を呼び出す。この関数を呼び出した結果として、規則は、拡張されたソーステーブル内のＧＵＩＤに割り当てられたように、同じ拡張されたキー値をＧＵＩＤ値に割り当てることになる。関数「getExpandedKeyRule()」は、拡張プロダクションプロセッサにより支援されるシステム関数の１つである。

いくつかの子データセットタイプは、ソースとしての包含から明示的に阻止されることができる。いくつかの拡張は、拡張処理から除外するためにユーザが子を規定できることを必要とする。例えば、ジョブスケジューリングアプリケーションに関連するconspecに関し、ユーザは、前日に実行したジョブの集合を既に有するかもしれないジョブ定義の拡張を望むかもしれない。ユーザはジョブ定義の拡張を望むかもしれないが、ジョブの拡張を望まないかもしれない。子オブジェクトのオプション除外を支援するために、ツールは、除外すべき子のリストを宣言するための入力パラメータを受け付けてもよい。

ソースは、拡張から明示的に除外されることができるが、子を再帰的にトラバースするために依然として使用されることができる。いくつかの拡張は、テーブルがソースとして選択されることを必要とするかもしれなく、さらに、このテーブルからオブジェクトがフィルタリングされることを必要とするかもしれない。加えて、拡張は、子オブジェクトの選択肢を狭めるために、フィルタリングされた選択肢が使用されることを必要とするかもしれない。同時に、ユーザはソース親オブジェクトの拡張を望まないかもしれないが、その代りに、選択された子オブジェクトの組の拡張だけを望むかもしれない。この場合、ユーザは子の選択肢を狭める手段としてソースを規定するが、このときソースを拡張（すなわち選択されたオブジェクトの複製）から除外する。

例えば、ジョブスケジューリングアプリケーションに関連するconspecに関し、ユーザは、その名前がストリング「Canada」で始まるジョブ定義に関連するジョブの拡張を望むかもしれない。ユーザは、ソースとなるためのジョブ定義を規定し、ソース選択肢からその子のすべてを明示的に除外するだろう（ジョブを除いて）。ユーザは、ジョブ定義の選択フィルタを規定するだろう。最後に、ユーザはジョブ定義を拡張から除外することを規定するであろう

この手法は、いくつかのタイプがフィルタリングと子検出のソースとして関与できるようにするだけでなく、また拡張処理から除外できるようにする。

修正（「マスキング」とも呼ばれる）は、レコードの１つまたは複数のフィールド内の値を置換する処理である。ある場合には、フィールドのグループは、レコード内の一貫性制約を維持するために一斉に操作され（市と郵便番号などで）、一方、他のケースでは、データセット全体にわたるフィールド値が参照整合性を維持するために一斉に操作される。以下の章では、一般的マスキングプロダクションプロセッサにより支援されてよい様々な種類のプロダクション規則の概要について説明する。

シャッフリングアルゴリズムは、データセット内の他のレコードからの値を使用して１つまたは複数のフィールド内の値を交換する。新しい値の選択はキーまたはルックアップベースマッピング機能のいずれかにより駆動されてよい（下記参照）。このアルゴリズムもまた元データ内の値の度数分布を維持するか、あるいはマスク値のフラット分布を生成してもよい。

マスキングプロダクションプロセッサはまた、マルチフィールドシャッフリングを支援し、これにより１つのレコードからのいくつかのブロックのフィールド値が別のレコードからの対応値の間でシャッフルされる。これは、男性および女性名が論理的タイトルと性別に関連付けられることと、郵便番号が有効な市と州に関連付けられることと、を保証するのに特に有用である。

置換アルゴリズムは外部の仮想値供給元から値を選択する。シャッフリングとは異なり、元値は使用されなく、これにより特定値が元データ内に存在する（どのレコードかにかかわらず）かどうかを隠すことを可能にする。

生成アルゴリズムは、特定タイプのフィールド用に設計されたドメイン専用式を使用する。クレジットカード、社会保険、電話、日付、電子メールなどのフィールドタイプの標準式が存在する。加えて、式は、ランダム化が値の一部に対して使用される場合にチェックサムを導出するために使用されてもよい。

暗号は、元の値を解読する能力を有する直接的マスキング手段を提供する。暗号値は、アプリケーションをパススルーするかもしれないが、通常は、いくつかのタイプのフィールドの有効データとしてパスすることはない。

ランダム化アルゴリズムはランダムな文字列および／または数列を生成する。これは反復可能または反復不能なやり方で行うことができる。すなわち、ユーザは同じソースストリングを同じマスクされたストリングに常にマッピングすることを選択してもよい。

オフセットアルゴリズムは、許容出力範囲内の入力値を変換する。この手法は、日付、量、通貨などのフィールドを、所望のグローバル特徴を維持する少量だけ変更するために使用されてもよい。例えば、ユーザは顧客間で「大きなトランザクション値対小さなトランザクション値」のパターンを維持してもよいが、値を少しだけ変更してもよい。別の例では、ユーザは全体の年令分布を維持しながら年令を変更してもよい。

スクラブアルゴリズムはフィールドを、あるいは共通値またはヌル値を有するその内容の一部を、取り除く。

カスタム機能が特定フィールドに関連付けられてよく、これらの機能はマスキングされたレコードから１つまたは複数のフィールドにアクセスしてもよい。

マスキングプロダクションプロセッサは、ルックアップ指標を導出するために暗号的にセキュアなハッシングアルゴリズムまたは偽似乱数置換関数を使用してもよい。マスクされた値に指標をマッピングするルックアップテーブルは、指標を導出するために使用されるキーがその代りにセキュアにされるので、維持される必要はない。暗号ハッシングが、無限領域データに、または名前とアドレスなどの不均等分布を有するデータに、十分に適用される。擬似乱数的交換は、一定のドメインデータ、またはＩＤなどの均等分布を有するデータに対し十分に適用される。

マスキングプロダクションプロセッサは各入力値のマスクされた値を導出するためにハッシングまたは置換関数を使用してもよく、次に、元値からマスクされた値へのマッピングをセキュアなルックアップテーブルに格納する。このテーブルは、マスクされた値とマスクされない値間のマッピングを明示的に維持するので、セキュアな環境において維持される必要がある。

他のプロダクションプロセッサ関数は処理の方向（例えば、親から子または子から親）を含むことができる。conspecは多くの相互依存データセットを含むので、プロダクションのコア機能の１つはデータセットインスタンスを処理する順序を決定することである。

プロダクションに規定された規則に依存して、プロダクションプロセッサは親を最初に続いて子を再帰的に処理する、あるいは子を最初に続いて親を再帰的に処理する必要があるかもしれない。前章では、プロダクションは、選択された親に依存して子だけで終わるために顧客を最初に次に親を選択することを要求した。別のシナリオでは、ユーザは、値Ｘより大きな値の高いドル金額トランザクションを選択し、これらのトランザクションをバックアップする必要がある顧客だけで終わることを規定してもよいであろう。この場合、プロセッサは子を最初に処理し続いて親を処理しなければならないであろう。プロセッサは、正しい処理順序を検出し必要に応じそれを適用する能力を有する。

時には、ユーザは、ソースとしてデータセットのサブセットを規定することにより処理の範囲を狭めることを望む。加えて、ユーザは、親または子として包含するためにいくつかのデータセットを明示的に除外することを望むかもしれない。処理順を決定するための一般的関数は引数としてこれらのパラメータを受け付けなければならない。

主キー割り当ては、プロダクション全体にわたる識別子（ＩＤ）の競合を回避するための技術である。プロダクションは、データセットインスタンス内に新しいレコードを最初からまたは複製によりのいずれかで生成してもよい。これらの新しいレコードはしばしば新しいＩＤを必要とすることになるので、プロダクションは新しいＩＤ値が既存のＩＤ値と競合しないことを保証する。加えて、プロダクションは、１回の実行内に生成するＩＤ値がその後の実行内に生成するかもしれないＩＤ値と競合しないことを保証する。

プロダクションの各実行に対し一意的なネームスペース内にＩＤが入ることを保証する多くのやり方がある。以下は、複数の実行にわたってだけでなく１つの実行内においても競合しない数値的ＩＤを生成するための手法の例である。

数値的主キーに関しては、プロダクションはデータセットインスタンス内の主キーフィールドの現在の最小および最大値を計算することで始まってよい。図１５では、現在の範囲１５０２は陰影を付けられて示される。例えば、プロダクションは、既存レコードのそれぞれをＮ回複製する規則を有する。任意のレコードを複製する前に、プロダクションは、新しいレコードを保持するために、未使用ＩＤのＮ個の新しい範囲の組を論理的に編制するまたは取っておく必要がある。次に、既存レコードのそれぞれのＮ個の新しいレコードのそれぞれはＮ個の範囲の１つからのＩＤ値を割り当てられるだろう。従って例えば、キーの既存指標値が３２１であれば、プロダクションは、３２１に対してＮ個の新しいレコードを生成し、これらには１２０５，２０８９，．．．，３２１＋８８４×ＮのＩＤ値が与えられるだろう。換言すれば、各新しいレコードは以下に示す青色範囲バケットの１つにダンプされるだろう。同様に、ＩＤ３２２を有する第２のレコードに関しては、プロダクションは１２０６，２０９０，．．．，３２２＋８８４×Ｎの値を有するＮ個の新しいオブジェクトを生成するだろう。

ＧＵＩＤなどの非数値的キーフィールドに関しては、プロダクションは最初に、実行の初めに一意的なRANDOM_RUN_SEEDを生成し、このキーと拡張指数とを各ＧＵＩＤに追加してもよい。プロダクションが再び実行されると、プロダクションは、キーがプロダクションの複数階層実行にわたって一意的であることを保証するであろう異なるランダムシードを使用するだろう。

図１７Ｉに示すリスト１７１８は、ジョブスケジューリングアプリケーションに関連するconspecに関する、拡張ジョブレコードに新しいＧＵＩＤを割り当てるために生成された変換規則の例である。「ｐＮ」はRANDOM_RUN_SEEDの値である。

拡張キー生成のためのこれらの手法はプロダクションの実行全体にわたって一意性を保証する。これにより、ユーザはプロダクションを複数回実行できるようになるか、あるいは異なるタイプのプロダクションを連鎖できるようにする。

上に説明されたデータセット処理技術は、コンピュータ上で実行されるソフトウェアを使用して実施することができる。例えば、ソフトウェアは、それぞれが少なくとも１つのプロセッサ、少なくとも１つのデータ記憶システム（揮発性および不揮発性メモリおよび／または記憶素子を含む）、少なくとも１つの入力装置またはポート、および少なくとも１つの出力装置またはポートを含む１つまたは複数のプログラムされたまたはプログラム可能なコンピュータシステム（分散型、クライアント／サーバーまたはグリッドなどの様々なアーキテクチャであってよい）上で実行する１つまたは複数のコンピュータプログラム内の手順を形成する。例えば、ソフトウェアは、データフローグラフの設計と構成に関係する他のサービスを提供するより大きなプログラムの１つまたは複数のモジュールを形成してもよい。グラフのノードと要素は、データレポジトリに格納されたデータモデルに準拠するコンピュータ可読媒体または他の編成データ内に格納されたデータ構造として実施することができる。

ソフトウェアは、汎用または専用プログラム可能コンピュータにより読み出し可能なＣＤ−ＲＯＭなどの記憶媒体上に提供されてもよいし、あるいはネットワークの通信媒体上で、ソフトウェアが実行されるコンピュータに配送されてもよい（伝播信号に符号化されてもよい）。機能のすべては、専用コンピュータ上で、またはコプロセサなどの専用ハードウェアを使用することより、実行されてもよい。ソフトウェアは、ソフトウェアにより規定された計算の異なる部分が異なるコンピュータにより実行される分散的やり方で実施されてもよい。このような各コンピュータプログラムは、記憶媒体または装置が本明細書に記載の手順を実行するためにコンピュータシステムにより読み取られるとコンピュータを構成し動作させる汎用または専用のプログラム可能コンピュータにより読出し可能な記憶媒体または装置（例えば、固体メモリまたは媒体、あるいは磁気または光学的媒体）上に格納されるあるいはそれにダウンロードされることが好ましい。本発明のシステムはまた、コンピュータプログラムにより構成されたコンピュータ可読記憶媒体として実施されると考えてもよい。ここでは、そのように構成された記憶媒体は本明細書に記載の機能を実行するために特定および所定のやり方でコンピュータシステムを動作させる。

本発明の多くの実施形態が説明された。それにもかかわらず、本発明の精神及び範囲を逸脱することなく他の様々な変更が可能であることが理解されるであろう。例えば、上に記載された工程のいくつかは、順序に無関係であってもよく、したがって記載されたものと異なる順序で実行することができる。

これまでの説明は、例証することを意図していること、そして添付の請求項の範囲により定義される本発明の範囲を制限しないように意図されていることと、を理解すべきである。例えば、上に記載された多くの機能工程は、全体処理に実質的に影響を与えることなく異なる順序で実行されてもよい。他の実施形態は以下の特許請求範囲に含まれる。

Claims (48)

1. 関連データセットの処理方法であって、
   入力装置またはポート上で、複数のデータセットから１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する所与のデータセットのレコードを受信する工程と、
   前記複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理する工程とを含み、前記処理は、
   前記複数のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、
   前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、前記変換が複数のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される前記変換は、前記第１のデータセットからの前記レコードに前記変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、
   前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む方法。
2. 前記制約仕様により規定される参照整合性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドの値の前記第１のデータセットのフィールドの値への依存性に基づく、請求項１に記載の方法。
3. 前記変換が前記第２のデータセットからのレコードに適用される前に、および前記変換が前記第１のデータセットからのレコードに適用された後に、前記変換は前記複数のデータセットの第３のデータセットからのレコードに適用される、請求項１に記載の方法。
4. 前記制約仕様により規定される統計的一貫性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドと前記第１のデータセットのフィールドとの間の関係に基づく、請求項１に記載の方法。
5. 前記第１のデータセットの前記フィールドと前記第２のデータセットの前記フィールドは、結合演算のためのキーを導出するために使用可能である、請求項４に記載の方法。
6. 複数のフィールドに関連する統計を決定するために、関連データセットの前記グループ内の前記データセットをプロファイリングする工程をさらに含み、前記複数のフィールドは、前記第１のデータセットの少なくとも１つのフィールドと、前記第１のデータセットの前記フィールドと等価であると前記制約仕様により示される前記第２のデータセットの少なくとも１つのフィールドとを含む、請求項１に記載の方法。
7. 前記第２のデータセットからの前記レコードに適用される前記１つまたは複数の変換は、前記決定された統計と前記第１のデータセットからの前記レコードに前記変換を適用した結果とに従って前記第１のデータセットの前記フィールド内の値の分布と前記第２のデータセットの前記フィールド内の値の分布との間の統計的一貫性を維持することに少なくとも部分的に基づいて適用される、請求項６に記載の方法。
8. 前記１つまたは複数の変換は、データ処理構成要素間のレコードの流れを表すリンクにより接続されたデータ処理構成要素を表すノードを含む少なくとも１つのデータフローグラフにより適用され、前記変換が適用される各データセットは前記データフローグラフにレコードの入力フローを提供する、請求項１に記載の方法。
9. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値に基づき前記所与のデータセット内のレコードの数を低減するサブセット化変換を含む、請求項１に記載の方法。
10. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記データセットの少なくとも１つのフィールド内の値を修正する修正変換を含む、請求項１に記載の方法。
11. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値の重複に基づき前記所与のデータセット内のレコードの数を増加する拡張変換を含む、請求項１に記載の方法。
12. 変換を複数のデータセットのそれぞれからのレコードに適用した結果のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、前記制約仕様は前記結果のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、
    １つまたは複数の変換を、前記決定された処理順序で、前記結果のデータセットのそれぞれからのレコードに適用する工程であって、前記変換が前記結果のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記結果のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される変換は、前記第１のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、
    前記結果のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、をさらに含む請求項１に記載の方法。
13. 関連データセットを処理するためのコンピュータプログラムであって、前記コンピュータプログラムはコンピュータに、
    入力装置またはポート上で、複数のデータセットから１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する所与のデータセットのレコードを受信させ、
    前記複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理させる、命令を含み、前記処理は、
    前記複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、
    前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、前記変換が前記複数のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される変換は、前記第１のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、
    前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む、コンピュータプログラム。
14. 関連データセットを処理するためのデータ処理システムであって、前記システムは、
    データ記憶システムと、
    複数のデータセットから１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する所与のデータセットのレコードを受信するように構成された入力装置またはポートと、
    前記入力装置またはポートと前記データ記憶システムと通信する少なくとも１つのプロセッサであって、前記複数のデータセットのそれぞれからのレコードを処理するように構成された少なくとも１つのプロセッサと、を含み、前記処理は、
    前記複数のデータセットの処理順序を決定するために前記データ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、
    前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、前記変換が前記複数のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される変換は、前記第１のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、
    前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む、システム。
15. 関連データセットを処理するためのデータ処理システムであって、前記システムは、
    複数のデータセットからレコードを受信する手段であって、所与のデータセットの前記レコードは１つまたは複数のそれぞれのフィールドの１つまたは複数の値を有する、手段と、
    前記複数のデータセットのそれぞれからのレコードを処理する手段と、を含み、前記処理は、
    前記複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、
    前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに１つまたは複数の変換を適用する工程であって、前記変換が前記複数のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される変換は、前記第１のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、
    前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む、システム。
16. 前記制約仕様により規定される参照整合性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドの値の前記第１のデータセットのフィールドの値への依存性に基づく、請求項１４に記載のシステム。
17. 前記変換が前記第２のデータセットからのレコードに適用される前に、および前記変換が前記第１のデータセットからのレコードに適用された後に、前記変換は前記複数のデータセットの第３のデータセットからのレコードに適用される、請求項１４に記載のシステム。
18. 前記制約仕様により規定される統計的一貫性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドと前記第１のデータセットのフィールドとの間の関係に基づく、請求項１４に記載のシステム。
19. 前記第１のデータセットの前記フィールドと前記第２のデータセットの前記フィールドは、結合演算のためのキーを導出するために使用可能である、請求項１８に記載のシステム。
20. 前記処理は、複数のフィールドに関連する統計を決定するために、関連データセットの前記グループ内の前記データセットをプロファイリングする工程をさらに含み、前記複数のフィールドは、前記第１のデータセットの少なくとも１つのフィールドと、前記第１のデータセットの前記フィールドと等価であると前記制約仕様により示される前記第２のデータセットの少なくとも１つのフィールドとを含む、請求項１４に記載のシステム。
21. 前記第２のデータセットからの前記レコードに適用される前記１つまたは複数の変換は、前記決定された統計と前記第１のデータセットからの前記レコードに前記変換を適用した結果とに従って前記第１のデータセットの前記フィールド内の値の分布と前記第２のデータセットの前記フィールド内の値の分布との間の統計的一貫性を維持することに少なくとも部分的に基づいて適用される、請求項２０に記載のシステム。
22. 前記１つまたは複数の変換は、データ処理構成要素間のレコードの流れを表すリンクにより接続されたデータ処理構成要素を表すノードを含む少なくとも１つのデータフローグラフにより適用され、前記変換が適用される各データセットは前記データフローグラフにレコードの入力フローを提供する、請求項１４に記載のシステム。
23. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値に基づき前記所与のデータセット内のレコードの数を低減するサブセット化変換を含む、請求項１４に記載のシステム。
24. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記データセットの少なくとも１つのフィールド内の値を修正する修正変換を含む、請求項１４に記載のシステム。
25. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値の重複に基づき前記所与のデータセット内のレコードの数を増加する拡張変換を含む、請求項１４に記載のシステム。
26. 前記処理は、
    変換を複数のデータセットのそれぞれからのレコードに適用した結果のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも１つの制約仕様を分析する工程であって、前記制約仕様は前記結果のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、
    １つまたは複数の変換を、前記決定された処理順序で、前記結果のデータセットのそれぞれからのレコードに適用する工程であって、前記変換が前記結果のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記結果のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される変換は、前記第１のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、
    前記結果のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、をさらに含む請求項１４に記載のシステム。
27. 前記制約仕様により規定される参照整合性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドの値の前記第１のデータセットのフィールドの値への依存性に基づく、請求項１５に記載のシステム。
28. 前記変換が前記第２のデータセットからのレコードに適用される前に、および前記変換が前記第１のデータセットからのレコードに適用された後に、前記変換は前記複数のデータセットの第３のデータセットからのレコードに適用される、請求項１５に記載のシステム。
29. 前記制約仕様により規定される統計的一貫性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドと前記第１のデータセットのフィールドとの間の関係に基づく、請求項１５に記載のシステム。
30. 前記第１のデータセットの前記フィールドと前記第２のデータセットの前記フィールドは、結合演算のためのキーを導出するために使用可能である、請求項２９に記載のシステム。
31. 複数のフィールドに関連する統計を決定するために、関連データセットの前記グループ内の前記データセットをプロファイリングする手段をさらに含み、前記複数のフィールドは、前記第１のデータセットの少なくとも１つのフィールドと、前記第１のデータセットの前記フィールドと等価であると前記制約仕様により示される前記第２のデータセットの少なくとも１つのフィールドとを含む、請求項１５に記載のシステム。
32. 前記第２のデータセットからの前記レコードに適用される前記１つまたは複数の変換は、前記決定された統計と前記第１のデータセットからの前記レコードに前記変換を適用した結果とに従って前記第１のデータセットの前記フィールド内の値の分布と前記第２のデータセットの前記フィールド内の値の分布との間の統計的一貫性を維持することに少なくとも部分的に基づいて適用される、請求項３１に記載のシステム。
33. 前記１つまたは複数の変換は、データ処理構成要素間のレコードの流れを表すリンクにより接続されたデータ処理構成要素を表すノードを含む少なくとも１つのデータフローグラフにより適用され、前記変換が適用される各データセットは前記データフローグラフにレコードの入力フローを提供する、請求項１５に記載のシステム。
34. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値に基づき前記所与のデータセット内のレコードの数を低減するサブセット化変換を含む、請求項１５に記載のシステム。
35. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記データセットの少なくとも１つのフィールド内の値を修正する修正変換を含む、請求項１５に記載のシステム。
36. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値の重複に基づき前記所与のデータセット内のレコードの数を増加する拡張変換を含む、請求項１５に記載のシステム。
37. 変換を複数のデータセットのそれぞれからのレコードに適用した結果のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも１つの制約仕様を分析する手段であって、前記制約仕様は前記結果のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、手段と、
    １つまたは複数の変換を、前記決定された処理順序で、前記結果のデータセットのそれぞれからのレコードに適用する手段であって、前記変換が前記結果のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記結果のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される変換は、前記第１のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、手段と、
    前記結果のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する手段と、をさらに含む請求項１５に記載のシステム。
38. 前記制約仕様により規定される参照整合性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドの値の前記第１のデータセットのフィールドの値への依存性に基づく、請求項１３に記載のコンピュータプログラム。
39. 前記変換が前記第２のデータセットからのレコードに適用される前に、および前記変換が前記第１のデータセットからのレコードに適用された後に、前記変換は前記複数のデータセットの第３のデータセットからのレコードに適用される、請求項１３に記載のコンピュータプログラム。
40. 前記制約仕様により規定される統計的一貫性を維持するための少なくとも１つの制約は、前記第２のデータセットのフィールドと前記第１のデータセットのフィールドとの間の関係に基づく、請求項１３に記載のコンピュータプログラム。
41. 前記第１のデータセットの前記フィールドと前記第２のデータセットの前記フィールドは、結合演算のためのキーを導出するために使用可能である、請求項４０に記載のコンピュータプログラム。
42. 前記処理は、複数のフィールドに関連する統計を決定するために、関連データセットの前記グループ内の前記データセットをプロファイリングする工程をさらに含み、前記複数のフィールドは、前記第１のデータセットの少なくとも１つのフィールドと、前記第１のデータセットの前記フィールドと等価であると前記制約仕様により示される前記第２のデータセットの少なくとも１つのフィールドとを含む、請求項１３に記載のコンピュータプログラム。
43. 前記第２のデータセットからの前記レコードに適用される前記１つまたは複数の変換は、前記決定された統計と前記第１のデータセットからの前記レコードに前記変換を適用した結果とに従って前記第１のデータセットの前記フィールド内の値の分布と前記第２のデータセットの前記フィールド内の値の分布との間の統計的一貫性を維持することに少なくとも部分的に基づいて適用される、請求項４２に記載のコンピュータプログラム。
44. 前記１つまたは複数の変換は、データ処理構成要素間のレコードの流れを表すリンクにより接続されたデータ処理構成要素を表すノードを含む少なくとも１つのデータフローグラフにより適用され、前記変換が適用される各データセットは前記データフローグラフにレコードの入力フローを提供する、請求項１３に記載のコンピュータプログラム。
45. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値に基づき前記所与のデータセット内のレコードの数を低減するサブセット化変換を含む、請求項１３に記載のコンピュータプログラム。
46. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記データセットの少なくとも１つのフィールド内の値を修正する修正変換を含む、請求項１３に記載のコンピュータプログラム。
47. 所与のデータセットのレコードに適用される前記１つまたは複数の変換は、前記所与のデータセットの少なくとも１つのフィールド内の値の重複に基づき前記所与のデータセット内のレコードの数を増加する拡張変換を含む、請求項１３に記載のコンピュータプログラム。
48. 前記処理は、
    変換を複数のデータセットのそれぞれからのレコードに適用した結果のデータセットの処理順序を決定するために、データ記憶媒体内に格納された少なくとも１つの制約仕様を分析する工程であって、前記制約仕様は前記結果のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための１つまたは複数の制約を規定する、工程と、
    １つまたは複数の変換を、前記決定された処理順序で、前記結果のデータセットのそれぞれからのレコードに適用する工程であって、前記変換が前記結果のデータセットの第２のデータセットからのレコードに適用される前に、前記変換が前記結果のデータセットの第１のデータセットからのレコードに適用され、前記第２のデータセットからの前記レコードに適用される変換は、前記第１のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第１のデータセットと前記第２のデータセットとの間の少なくとも１つの制約と、に少なくとも部分的に基づいて適用される、工程と、
    前記結果のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、をさらに含む請求項１３に記載のコンピュータプログラム。

Images