"関連データセットの処理方法であって、入力装置またはポート上で、複数のデータセットから1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する所与のデータセットのレコードを受信する工程と、前記複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理する工程とを含み、前記処理は、前記複数のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、前記変換が複数のデータセットの第2のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第1のデータセットからのレコードに適用され、前記第2のデータセットからの前記レコードに適用される前記変換は、前記第1のデータセットからの前記レコードに前記変換を適用した結果と、前記制約仕様により規定された前記第1のデータセットと前記第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む方法。前記制約仕様により規定される参照整合性を維持するための少なくとも1つの制約は、前記第2のデータセットのフィールドの値の前記第1のデータセットのフィールドの値への依存性に基づく、請求項1に記載の方法。前記第1のデータセットの前記フィールドは主キーであり、前記第2のデータセットの前記フィールドは前記主キーを参照する外部キーである、請求項2に記載の方法。前記制約仕様は、前記第2のデータセットの前記フィールドと前記第1のデータセットの前記フィールドとの間の主キー対外部キーの関係の表現を含む、請求項3に記載の方法。前記複数のデータセットの前記処理順序を決定する工程は、前記第2のデータセットの前記フィールドの値の前記第1のデータセットの前記フィールドの値への依存性に基づき、前記処理順序で、前記第1のデータセットが前記第2のデータセットの前に発生するということを決定することを含む、請求項2に記載の方法。前記変換が前記第2のデータセットからのレコードに適用される前に、および前記変換が前記第1のデータセットからのレコードに適用された後に、前記変換は前記複数のデータセットの第3のデータセットからのレコードに適用される、請求項1に記載の方法。前記制約仕様により規定される統計的一貫性を維持するための少なくとも1つの制約は、前記第2のデータセットのフィールドと前記第1のデータセットのフィールドとの間の等価性に基づく、請求項1に記載の方法。前記第1のデータセットの前記フィールドと前記第2のデータセットの前記フィールドとは、結合演算におけるキーである、請求項7に記載の方法。前記制約仕様は前記結合演算の表現を含む、請求項8に記載の方法。複数のフィールドに関連する統計を決定するために、関連データセットの前記グループ内の前記データセットをプロファイリングする工程をさらに含み、前記複数のフィールドは、前記第1のデータセットの少なくとも1つのフィールドと、前記第1のデータセットの前記フィールドと等価であると前記制約仕様により示される前記第2のデータセットの少なくとも1つのフィールドとを含む、請求項1に記載の方法。前記第2のデータセットからの前記レコードに適用される前記1つまたは複数の変換は、前記決定された統計と前記第1のデータセットからの前記レコードに前記変換を適用した結果とに従って前記第1のデータセットの前記フィールド内の値の分布と前記第2のデータセットの前記フィールド内の値の分布との間の統計的一貫性を維持することに少なくとも部分的に基づいて適用される、請求項10に記載の方法。前記1つまたは複数の変換は、データ処理構成要素間のレコードの流れを表すリンクにより接続されたデータ処理構成要素を表すノードを含む少なくとも1つのデータフローグラフにより適用され、前記変換が適用される各データセットは前記データフローグラフにレコードの入力フローを提供する、請求項1に記載の方法。前記データフローグラフは、前記決定された前記複数のデータセットの処理順序でレコードの入力フローを提供するために前記複数のデータセットのそれぞれの1つを使用することにより、複数回の繰り返しで連続的に実行される、請求項12に記載の方法。所与のデータセットのレコードに適用される前記1つまたは複数の変換は、前記所与のデータセットの少なくとも1つのフィールド内の値に基づき前記所与のデータセット内のレコードの数を低減するサブセット化変換を含む、請求項1に記載の方法。所与のデータセットのレコードに適用される前記1つまたは複数の変換は、前記データセットの少なくとも1つのフィールド内の値を修正する修正変換を含む、請求項1に記載の方法。所与のデータセットのレコードに適用される前記1つまたは複数の変換は、前記所与のデータセットの少なくとも1つのフィールド内の値の重複に基づき前記所与のデータセット内のレコードの数を増加する拡張変換を含む、請求項1に記載の方法。変換を複数のデータセットのそれぞれからのレコードに適用した結果のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、前記制約仕様は前記結果のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、1つまたは複数の変換を、前記決定された処理順序で、前記結果のデータセットのそれぞれからのレコードに適用する工程であって、前記変換が前記結果のデータセットの第2のデータセットからのレコードに適用される前に、前記変換が前記結果のデータセットの第1のデータセットからのレコードに適用され、前記第2のデータセットからの前記レコードに適用される変換は、前記第1のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第1のデータセットと前記第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、前記結果のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、をさらに含む請求項1に記載の方法。関連データセットを処理するためのコンピュータプログラムを格納するコンピュータ可読媒体であって、前記コンピュータプログラムはコンピュータに、入力装置またはポート上で、複数のデータセットから1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する所与のデータセットのレコードを受信させ、前記複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理させる、命令を含み、前記処理は、前記複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、前記変換が前記複数のデータセットの第2のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第1のデータセットからのレコードに適用され、前記第2のデータセットからの前記レコードに適用される変換は、前記第1のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第1のデータセットと前記第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む、コンピュータ可読媒体。関連データセットを処理するためのデータ処理システムであって、前記システムは、データ記憶システムと、複数のデータセットから1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する所与のデータセットのレコードを受信するように構成された入力装置またはポートと、前記入力装置またはポートと前記データ記憶システムと通信する少なくとも1つのプロセッサであって、前記複数のデータセットのそれぞれからのレコードを処理するように構成された少なくとも1つのプロセッサと、を含み、前記処理は、前記複数のデータセットの処理順序を決定するために前記データ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、前記変換が前記複数のデータセットの第2のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第1のデータセットからのレコードに適用され、前記第2のデータセットからの前記レコードに適用される変換は、前記第1のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第1のデータセットと前記第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む、システム。関連データセットを処理するためのデータ処理システムであって、前記システムは、複数のデータセットからレコードを受信する手段であって、所与のデータセットの前記レコードは1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する、手段と、前記複数のデータセットのそれぞれからのレコードを処理する手段と、を含み、前記処理は、前記複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、前記制約仕様は前記複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、前記決定された処理順序で、前記複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、前記変換が前記複数のデータセットの第2のデータセットからのレコードに適用される前に、前記変換が前記複数のデータセットの第1のデータセットからのレコードに適用され、前記第2のデータセットからの前記レコードに適用される変換は、前記第1のデータセットからの前記レコードに変換を適用した結果と、前記制約仕様により規定された前記第1のデータセットと前記第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、前記複数のデータセットのそれぞれからの前記レコードへの前記変換の結果を格納または出力する工程と、を含む、システム。要約1つの態様では、通常、関連データセットの処理方法は、複数のデータセットから入力装置またはポート上でレコードを受信する工程であって、所与のデータセットのレコードは1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する、工程と、複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理する工程と、を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第2のデータセットからのレコードに適用される前に、変換が複数のデータセットの第1のデータセットからのレコードに適用され、第2のデータセットからのレコードに適用される変換は、第1のデータセットからのレコードに変換を適用した結果と、制約仕様により規定される第1のデータセットと第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからレコードへの変換の結果を格納または出力する工程と、を含む。様々な態様は以下の特徴の1つまたは複数を含むことができる。制約仕様により規定される参照整合性を維持するための少なくとも1つの制約は、第2のデータセットのフィールドの値の第1のデータセットのフィールドの値への依存性に基づく。第1のデータセットのフィールドは主キーであり、第2のデータセットのフィールドは主キーを参照する外部キーである。制約仕様は、第2のデータセットのフィールドと第1のデータセットのフィールド間の主キー対外部キー関係の表現を含む。複数のデータセットの処理順序を決定する工程は、第2のデータセットのフィールドの値の第1のデータセットのフィールドの値への依存性に基づく処理順序で第1のデータセットが第2のデータセットの前に発生するということを決定することを含む。変換はデータセットの第2のデータセットからのレコードに適用される前および第1のデータセットからのレコードに適用された後に複数のデータセットの第3のデータセットからのレコードに適用される。制約仕様により規定される統計的一貫性を維持するための少なくとも1つの制約は、第2のデータセットのフィールドと第1のデータセットのフィールド間の等価性に基づく。第1のデータセットのフィールドと第2のデータセットのフィールドは結合演算におけるキーである。制約仕様は結合演算の表現を含む。本方法はさらに、複数のフィールドに関連する統計を決定するために関連データセットのグループ内のデータセットをプロファイリングする工程であって、複数のフィールドは第1のデータセットの少なくとも1つのフィールドと、第1のデータセットのフィールドと等価であると制約仕様により示される第2のデータセットの少なくとも1つのフィールドと、を含む、工程を含む。第2のデータセットからのレコードに適用される1つまたは複数の変換は、決定された統計と第1のデータセットからのレコードに変換を適用した結果とに従って、第1のデータセットのフィールド内の値の分布と第2のデータセットのフィールド内の値の分布との間の統計的一貫性を維持することに少なくとも部分的に基づいて適用される。1つまたは複数の変換は、データ処理構成要素間のレコードの流れを表すリンクにより接続されたデータ処理構成要素を表すノードを含む少なくとも1つのデータフローグラフにより適用され、変換が適用される各データセットはデータフローグラフにレコードの入力フローを提供する。データフローグラフは、決定された複数のデータセットの処理順序でレコードの入力フローを提供するために複数のデータセットのそれぞれの1つを使用することにより、複数回の繰り返しで連続的に実行される。所与のデータセットのレコードに適用される1つまたは複数の変換は、所与のデータセットの少なくとも1つのフィールド内の値に基づき所与のデータセット内のレコードの数を低減するサブセット化変換を含む。所与のデータセットのレコードに適用される1つまたは複数の変換は、データセットの少なくとも1つのフィールド内の値を修正する修正変換を含む。所与のデータセットのレコードに適用される1つまたは複数の変換は、所与のデータセットの少なくとも1つのフィールド内の値の重複に基づき所与のデータセット内のレコードの数を増加する拡張変換を含む。本方法はさらに、複数のデータセットのそれぞれからのレコードに変換を適用した結果のデータセットの処理順序を決定するために、データ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、制約仕様は結果のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、1つまたは複数の変換を、決定された処理順序で、結果のデータセットのそれぞれからのレコードに適用する工程であって、変換が結果のデータセットの第2のデータセットからのレコードに適用される前に、変換が結果のデータセットの第1のデータセットからのレコードに適用され、第2のデータセットからのレコードに適用される変換は、第1のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第1のデータセットと第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、結果のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。別の態様では、通常、コンピュータ可読媒体は関連データセットを処理するためのコンピュータプログラムを格納し、コンピュータプログラムは、コンピュータに、入力装置またはポート上で、複数のデータセットから、1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する所与のデータセットのレコードを受信させ、複数のデータセットのそれぞれからのレコードをデータ処理システムにおいて処理させる、命令を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第2のデータセットからのレコードに適用される前に、変換が複数のデータセットの第1のデータセットからのレコードに適用され、第2のデータセットからのレコードに適用される変換は、第1のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第1のデータセットと第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。別の態様では、通常、関連データセットを処理するためのデータ処理システムは、データ記憶システムと、複数のデータセットから、1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する所与のデータセットのレコードを受信するように構成される入力装置またはポートと、入力装置またはポートとデータ記憶システムと通信する少なくとも1つのプロセッサであって、複数のデータセットのそれぞれからのレコードを処理するように構成された少なくとも1つのプロセッサと、を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第2のデータセットからのレコードに適用される前に、変換が複数のデータセットの第1のデータセットからのレコードに適用され、第2のデータセットからのレコードに適用される変換は、第1のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第1のデータセットと第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。別の態様では、通常、関連データセットを処理するためのデータ処理システムは、複数のデータセットからレコードを受信する手段であって、所与のデータセットのレコードは1つまたは複数のそれぞれのフィールドの1つまたは複数の値を有する、手段と、複数のデータセットのそれぞれからのレコードを処理する手段と、を含む。この処理は、複数のデータセットの処理順序を決定するためにデータ記憶システム内に格納された少なくとも1つの制約仕様を分析する工程であって、制約仕様は複数のデータセットを含む関連データセットのグループ間の参照整合性または統計的一貫性を維持するための1つまたは複数の制約を規定する、工程と、決定された処理順序で、複数のデータセットのそれぞれからのレコードに1つまたは複数の変換を適用する工程であって、変換が複数のデータセットの第2のデータセットからのレコードに適用される前に、変換が複数のデータセットの第1のデータセットからのレコードに適用され、第2のデータセットからのレコードに適用される変換は、第1のデータセットからのレコードに変換を適用した結果と、制約仕様により規定された第1のデータセットと第2のデータセットとの間の少なくとも1つの制約と、に少なくとも部分的に基づいて適用される、工程と、複数のデータセットのそれぞれからのレコードへの変換の結果を格納または出力する工程と、を含む。様々な態様は、以下の利点の1つまたは複数を含むことができる。本システムは、参照整合性、等価なフィールド例えば、特性を結合することにより関連付けられたフィールドの統計的一貫性、および他の制約等の制約を維持する一方で、相互に関連付けられたデータセットの集合を処理することができる。いくつかの実施態様では、本システムは、データフローグラフを使用してデータ処理アプリケーションを構築する開発者が、個々のデータセットから発するレコードフローに作用する流れを生成するために構成要素を個々に接続する必要なしに関連データセットを処理するアプリケーションを構築できるようにする。複数の相互に関連付けられたデータセットが処理を必要とする場合、開発者は、異なるデータセットのフィールド間の主キーと外部キーとの関係等の制約をシステムが認識できるようにするために、データセットのグループとこのデータセットに適用されるデータ処理変換の制約仕様を提供し、それらの制約に基づき参照整合性および統計的一貫性等の特性がほぼ維持されることを保証するやり方で変換を行なうことができる例えば、所定の公差内で。本システムは、開発者が、conspecと呼ばれるデータ構造により表される制約仕様内のデータセットの集合間の制約を宣言し、conspecによりグループとして参照されるデータセットに作用する一連の処理タスクを構成および配置するやり方を提供する。これは、関連データセットの全集合に適用される前段階の処理タスクの結果にそれぞれが作用することができる複数の段階のタスクを連鎖すること例えば、各段階を表す処理モジュールを線でつなぐことによりを容易にする。所与のデータセットの特定の状態はデータセットインスタンスと呼ばれる。conspecは、異なるデータセットの要素例えば、フィールドまたはフィールドの組み合せ間の依存関係および等価性関係等の制約を特定する。そのフィールドがconspecにより参照される特定のデータセットインスタンスは、参照フィールドが既存データセットインスタンスのフィールドに対応することを保証するように特定されることができるが、特定データセットインスタンスは、参照中のフィールドを後で既存データセットインスタンスのフィールドへマッピングすることができるので、必ずしも特定される必要はない。conspecは、例えば、データセットのフィールドの少なくともいくつかを論理的に表すフィールド識別子を有するフィールドを参照するデータセット記述子を使用することにより、そして参照フィールド間の異なる制約を表す様々なやり方でフィールド識別子を関連付けるリンクデータ構造を使用することにより、実施することができる。データセット記述子は、現存データセットインスタンスに対応するためには必ずしも必要とされない。したがって所与のconspecは、制約により参照中のフィールドがそれらのデータセットインスタンス内に存在する限り、任意の数のデータセットインスタンスに適用されてもよい。第1の状態における所与のデータセットを表す入力データセットインスタンスは、第2の状態における所与のデータセットを表す対応出力データセットインスタンスを与えるためにグループ内の他のデータセットと共に変換されることができる。変換が元のデータセットに作用する場合、出力データセットインスタンスは入力データセットインスタンスを交換することができ、あるいは変換が元のデータセットの複製物に作用する場合、出力データセットインスタンスは入力データセットインスタンスと共に存在することができる。典型的な使用ケースの例は、様々なデータセット間の参照整合性をすべて維持する一方で複数のデータセットのグループからのレコードのフィルタリングと、それに続く拡張expansion、または新しいレコードを生成するためにレコードを複製することを含むテストデータの生成に関する。conspecは、システムが、データセットのグループに適用されるフィルタ処理としてこのタスクを実行し、続いてデータセットのグループに適用される拡張演算を実行できるようにするために、データセット間の関係についての十分な情報を提供する。第1の演算から流れ出る複数の出力データセットインスタンスは第2の演算に提供され、第2の組の出力データセットインスタンスを生じる。用語データセットは、conspecの文脈で使用される場合、レコードフォーマットと要素例えば、主キー要素と外部キー要素間の他の構造的関係とを含むデータセットのいくつかの特徴の定義を指し、用語データセットインスタンスは、所与の状態におけるデータセットのレコードconspecにより規定されたフォーマットのを表す物理的バイトの集合を指す。一例では、conspecにより参照される2つのデータセット、すなわち顧客データセットとトランザクションデータセットとが存在すると仮定する。さらに、トランザクションデータセットは、顧客データセット内のフィールドを参照する外部キーであるcustidフィールドを有すると仮定する。フィルタリングタスクは、顧客をフィルタリングすることに続いてトランザクションをフィルタリングすることを含んでもよいが、conspec内に定義されたキー関係のために、システムは、既に含まれている顧客を参照するトランザクションだけが含まれるようにトランザクションをフィルタリングする。本システムは、カスタマイズされたフィルタリング操作を各データセットに対し依然として行う一方でデータセット間の関係を維持することができる。レコードを拡張する第2の演算に関しては、タスクは、展開された値fannedoutvaluesを有する新しいレコードを生成するためにトランザクションレコードを複製することを含んでもよいが、タスクは、可能ならば新しいトランザクションが新しい顧客を参照するように、新しいトランザクションをその方向に曲げるbentやり方でそのようにする。換言すれば、conspecは顧客とトランザクション間の親/子関係を定義するので、新しいトランザクションは可能であれば新しい顧客を参照することが望ましいかもしれない。本システムは、特定レコードの複製とフィールド変更演算を行う一方でこれらの関係を維持することができる。本発明の他の特徴と利点は以下の説明と特許請求範囲から明らかになる。説明図1に、データセット処理技術を使用することができる例示的なデータ処理システム100を示す。システム100は、それぞれが様々な格納フォーマット例えば、データベーステーブル、スプレッドシートファイル、フラットテキストファイルまたはメインフレームにより使用される固有フォーマットの任意のものでデータセットを格納することができる記憶装置またはオンラインデータストリームへの接続等の1つまたは複数のデータソースを含んでよいデータソース102を含む。実行環境104は前処理モジュール106と処理モジュール112を含む。実行環境104は、UNIX登録商標オペレーティングシステム等の好適なオペレーティングシステムの制御下で1つまたは複数の汎用コンピュータ上でホストされてもよい。例えば、実行環境104は、複数の中央処理装置CPUを使用するコンピュータシステムの構成を含むマルチプルノードパラレルコンピューティング環境を含むことができる。この環境は、ローカル例えば、SMPコンピュータ等のマルチプロセッサシステム、または局地分散型例えば、クラスタまたはMPPとして結合されるマルチプルプロセッサ、またはリモート、またはリモート分散型例えば、ローカルエリアネットワークLANおよび/または広域ネットワークWANを介して結合される複数のプロセッサ、またはその任意の組み合せのいずれかである。前処理モジュール106は、実行環境104にアクセス可能なデータ記憶システム116内に格納されたデータ構造conspec114により表される制約仕様と、データ記憶システム116内に格納されたデータ構造規則115により表されるデータセットのグループのレコードへの変換を適用するための規則と、を読み取る。前処理モジュール106は、変換を適切なやり方で例えば、所定順序でレコードに適用し、その結果を格納または出力するために、処理モジュール112により使用される情報を出力する。処理モジュール112により処理されるレコードはデータソース102により提供される。データソース102を提供する記憶装置は、例えば、実行環境104を走らせるコンピュータに接続された記憶媒体例えば、ハードドライブ108上に格納された実行環境104に対してローカルであってもよいし、あるいは例えばリモート接続上で実行環境104を走らせるコンピュータと通信するリモートシステム例えば、メインフレーム110上でホストされる実行環境104に対してリモートであってもよい。データ記憶システム116はまた、開発者120がconspec114と規則115を生成することができる開発環境118にアクセス可能である。開発環境118と実行環境104は、いくつかの実施態様では、データフローグラフとしてアプリケーションを開発し実行するように構成される。様々なタイプの計算は、有向グラフを介したデータフローデータフローグラフと呼ばれるとして表すことができ、計算の構成要素は、グラフのリンクに対応する構成要素弧線、端部間の作業要素例えば、レコードのグラフとデータフローの頂点と関連付けられる。頂点はデータ処理構成要素またはデータセットを表すことができる。データ処理構成要素は、1つまたは複数の入力ポートにおいてデータを受信し、データを処理し、1つまたは複数の出力ポートからデータと、作業要素のソースまたはシンクとして機能するデータセットと、を提供する。このようなグラフベースの計算を実施するシステムは米国特許第5,966,072号、表題EXECUTINGCOMPUTATIONSEXPRESSEDASGRAPHSに記載され、参照により本明細書に援用する。グラフベースのアプリケーションを開発するための開発環境の例は米国特許出願公開第2007/0011668号、表題ManagingParametersforGraphBasedApplicationsにさらに詳細に記載され、参照により本明細書に援用する。図2に、例示的なデータセット処理手順200のフローチャートを示す。手順200は例えば前処理モジュール106と処理モジュール112により行われる。前処理モジュール106は複数のデータセットからシステムの入力装置またはポート上でレコードを受信し200、前処理モジュール106はデータ記憶システム116内に格納された制約仕様conspec114と1つまたは複数の変換規則115を受信する204。前処理モジュール106は、複数のデータセットの処理順序を決定するために制約仕様を分析する206。前処理モジュール106からの入力に基づき、処理モジュール112は、規則115に定義された1つまたは複数の変換を、決定した処理順序で複数のデータセットのそれぞれからのレコードに適用する。変換は、それぞれの繰り返しで、複数のデータセットの各データセットからのレコードに順番に適用される208。所与のデータセットからのレコードに適用される変換は、前に処理されたデータセットからのレコードに変換を適用した結果に少なくとも部分的に、そして前に処理されたデータセットと制約仕様により規定される所与のデータセット間の少なくとも1つの制約に、基づいて適用される。手順200はさらなる組の変換が適用されるかどうかを判断し210例えば、追加の組の規則に基づき、もしそうならば、手順は前の組の変換から生成される出力データセットインスタンスを次の組の変換の入力データセットインスタンスとして使用する工程をループする。変換の終了後、システムは変換の結果を格納または出力する212。データ処理手順の他の例では、上記工程は、例えば、他の工程例えば、さらに詳細に以下に説明されるようにデータセットをプロファイリングする工程を含むように、または異なる順序で発生する例えば、データセットが受信される前に複数のデータセットの処理順序を制約仕様に基づき決定することができるように変更されることができる。1つの態様では、システムは、データセットの集合からのレコードに作用する計算モジュールを提供する。この計算モジュールは、規則115とconspec114により規定される制約とに基づき、conspec114において参照される複数のデータセットに関わる変換を定義する入力パラメータを使用して構成されるデータフローグラフを使用することにより、実施されてよい。データフローグラフのいくつかは前処理グラフと呼ばれる前処理モジュール106の前処理に使用され、データフローグラフのいくつかは前処理グラフにより提供されるパラメータに従って構成されることにより処理モジュール112の処理に使用される。データフローグラフは例えば、さらに詳細に以下に説明されるように、データフローグラフの実行を制御するタスクスケジューリング環境であって、入力パラメータにより特定される一系列のデータセットインスタンスでレコードを処理するためにデータフローグラフを反復して実行することができるタスクスケジューリング環境を使用して、制御されることができる。別の態様では、システムは、直列化されメモリ内表現に読み込まれる例えば、実行環境104にアクセス可能なローカルメモリ内に格納されることができるconspecの標準表現を提供する。ここで、メモリ内表現は、前処理グラフが、関係に沿って、conspec内の個々のデータセットの処理順序などの変換論理と他の情報を書き込むことができるようにするものである。例えば、データフローグラフ内で実行することができる形式でデータを操作するための演算の定義を可能にするデータ操作言語DML:DataManipulationLanguageを使用する表現は、前処理グラフにおける変換がconspecに定義されたデータセットのすべてを調べることができるようにするであろう。データ操作言語はさらに、マルチデータセット結合演算と共に主キーと外部キーとの関係に基づき、それらの親レコードのコンテキスト内の子レコードを処理するために必要な結合キー要素結合演算におけるキーとして使用される要素と共に、データセットの親から子への処理順序を決定する。別の態様では、システムは、conspecにより参照されるデータセットのレコードに適用されてよい変換規則の標準表現を提供する。変換規則のこの表現はプロダクションと呼ばれる。プロダクションはまた、conspecに定義された制約から、特定の変換に関連してよい規則を分離する。例えば、ユーザはconspec内に主キーおよび外部キーとキー要素メンバーとの集合を定義し、次にプロダクション内に主キーフィールドに適用されるスクランブリングまたはマスキング規則を定義してもよい。conspecからの規則の分離により、ユーザは多くの異なるプロダクション規則を定義することができるようになる。プロダクション規則はすべてconspecから独立しており、しかも任意の特定のプロダクションが適用される場合、conspecに定義された制約のために、システムは、主キーフィールドがスクランブルされるだけでなく、他のデータセット内の外部キー参照もスクランブルされることを保証することになる。プロダクション規則は、例えばプロダクション変換として様々なやり方の1つで実施されることができる。図3Aに、conspec302と、プロダクション304と、これらの両方を読み取り入力データセットインスタンスのレコードに処理工程を適用するプロダクションプロセッサ306例えば、データフローグラフを使用して実施されるとの間の関係の例を示す。プロダクションは、各出力データセットインスタンス310のターゲット識別と場所だけでなく各入力データセットインスタンス308の場所を特定する責任を負う。図3Bに、1つのプロダクション314の出力データセットインスタンスが次のプロダクション316への入力として機能するデイジーチェインプロダクションのシーケンスを示す。関与するデータセットインスタンス315、320、324はプロダクション間で同じとなる各プロダクションに提供する同じconspec312のため一方で、各工程におけるプロダクションプロセッサ318、322は、プロダクション規則の性質に依存して、前のプロダクションのものとは異なる処理順序を適用してもよい。conspecは、単一のデータセット特定のデータ集合を表すの抽出のレベルより、conspecにより参照されるデータセットの集合の抽出のより高いレベルを提供し、フィルタリング、マスキング、データ拡張などの複数のconspecレベルの演算規定された制約に従ってデータセットの集合に対し行われる演算の連鎖を含むデータフローアプリケーションの開発を単純化する。システムは事前構築タイプのプロダクション規則の集合を含んでもよいが、開発者が追加のタイプの変換を定義できるように拡張点を提供してもよい。例えば、ユーザは、conspec内の複数のデータセットにわたってまとめた結果を提供する一方で個々のデータセットのチャートとレポートを生成するであろうデータレポートタイプのプロダクションを構築することを望むかもしれない。この新しいタイプのプロダクションは、すべてのプロダクション規則のための基本プロセッサ内に提供される基本順序走査機構basicorderedtraversalmechanismを利用してもよいが、処理されたデータセットのそれぞれのデータ集約およびチャート生成機能を追加してもよい。図4Aに、conspecに関連する対応データセットインスタンス例えば、conspecにより参照されるデータセットと同じフィールドを有するデータセットインスタンスのレコードに適用されてよい典型的なプロダクション操作のための関連データセットの集合間の制約の例であるabconspecと呼ばれるconspec400を示す。conspec400は2つの顧客データセットacustomersとbcustomers、それらの子トランザクションデータセットatransactionsとbtransactions、consumerinfoデータセットを示し、家庭情報を提供する。3元結合関連性は顧客とconsumerinfoのデータセットからキー間の等価特性を定義し、2つの関係は顧客とトランザクション間の親子依存特性を記述する。図4Bに、conspecにより参照される複数のデータセット間の関係を定義するconspec450の例を示す。これはconspec群のうちの1つのconspecと解釈されてよい。プロダクションに好適な典型的な1つの演算は、各データセットの要素間の依存性例えば、外部キー/主キー関係、等価性例えば、同じエンティティを表すフィールド間の関連性などの固有特性を破壊することなくデータセットインスタンスの集合のサイズを低減することである。例えば、図4Aのabconspecを参照すると、ユーザは特定のインスタンスにおけるacustomersの数を半分に短縮し、これと共に別のインスタンス内のatransactionsの数も同様に半分に短縮することを望むかもしれない。しかしながら、ユーザがレコードの最初の50を任意に除去することにより各データセットインスタンスを短縮すれば、ユーザは処理された顧客データセットインスタンス内に存在しなくなった顧客を参照するトランザクションで恐らく終わるであろう。図5に、参照整合性を維持することにこだわることなくデータセットインスタンスを任意に短縮する効果を示す。図4Aに示すconspecに定義された特性例えば、データセット要素間の依存性、データセット要素間の等価性を維持するやり方でデータセットインスタンスを処理するためには、ユーザは各データセットインスタンスが処理される一方でこれらの特性を維持するように複数のデータセットインスタンスに順次に作用する処理グラフの一般的な組を含むプロダクションプロセッサを利用してもよい。この例では、acustomersとatransactionsを低減する望ましいやり方は、トランザクションが顧客を参照するので顧客を最初に処理しなければならないと判断することかもしれない。さらに、顧客が50低減されると、トランザクションは、残りの顧客に一致するトランザクションだけを選択するように既に処理された顧客と内部結合されなければならない。参照整合性を維持する目的のためにトランザクションがフィルタリングされると、ユーザはさらに、プロダクション規則にこれまでに定義されたこれはあり得る元の数の50または既に減少された数の50のいずれかを維持するようにトランザクションをフィルタリングしてもよい。参照整合性フィルタはすべてのトランザクションを除去させ、これにより元の数の50までさらにフィルタリングすることを不可能にしてもよい。図5に、conspecabconspecに定義されるように、データセットインスタンス間の参照整合性を維持する一方でacustomersとatransactionsを低減する効果を示す。この例では、ユーザはレコードを50低減するなどのような規則を規定し、プロダクションプロセッサが参照conspecに宣言される様々な特性を維持することを期待してよい。これは、複数の関連データセットインスタンスに適用される変換50低減を扱う2つの異なるやり方の比較である。ここで第1の方法は参照整合性を維持することができなく、第2の方法は参照整合性を維持する。元のデータセットインスタンス502、504に適用された1つの結果510は、各データセットインスタンスを50だけ任意に削減した後の結果を表す。太字のトランザクションは、存在しない顧客への誤った参照を強調表示している。別の結果520は、顧客を50削減し、次に参照整合性を維持するためにトランザクションをフィルタリングし、次に元のデータセットインスタンスの50を保持するためにこの組をフィルタリングした後の結果を表す。図6は、プロダクションプロセッサ600が、どのようにして、conspec602を特定するプロダクションを読み取り、次に特定されたconspecを読み取り、次に一組の一意的識別名ここでは、プロダクションは一意的名前添字を単純に与えるに従ってデータセットインスタンス604、606の集合を読み取り、続いて、プロダクション608内に定義された規則に従ってデータセットインスタンスを処理し、続いて、プロダクション内にも定義されたターゲット名に従って新しい組のデータセットインスタンス610、612を書き込むかを示す。総じて、図6は、所与の名前添字を有するデータセットインスタンスを読み取り、プロダクション規則に従ってレコードを削減し、conspec特性すなわち参照整合性を維持し、所与の名前添字を使用して、ターゲットデータセットインスタンスに結果を書き込むプロダクションプロセッサの動作を表す。プロダクションプロセッサの役割は、プロダクション内に規定された規則を、十分な親結合およびフィルタ変換を含む1つまたは複数の一般的かつ構成可能なグラフに注入することであり、この結果、データセットは、conspecに宣言された参照整合性と他の特性を維持するためにユーザに専用グラフを符号化させる必要無しに、プロダクション規則と共に処理されるようになる。一般的なプロダクション実行グラフすなわちprodrunの基本原理は、処理中の各データセットインスタンスが、プロダクションプロセッサの実行中に既に処理されたすべての先行データセットインスタンスにアクセスできるようにすることである。prodrunグラフは、データセットインスタンスを前に処理された他のデータセットインスタンスへリンクする一般的結合を含んでもよい。したがってプロダクションプロセッサ全体としてのジョブは、関与するデータセットインスタンスの処理順序を決定し、prodrunグラフを構成する各データセットのパラメータを書き込むことである。この例では、プロダクションプロセッサは、acustomersは処理される必要があり、親を有しないこと、次にatransactionsは処理される必要があること、親または先行データセットはacustomersであること、を最初に決定してもよい。ある場合には、先行点は、外部/主キーの観点からは親ではないかもしれなく、単に最初に処理されたデータセットかもしれなく、したがって先行点はそのフィールドの1つまたは複数を先行点のものに関連付ける等価特性を有してもよい後続のデータセットにある程度役に立つかもしれないということに注意されたい。したがって、基本的なケースでは、プロダクションプロセッサは、処理順序が[vectoracustomers、atransactions]形式のデータセット名のベクトルであるということ、acustomersデータセットインスタンスを処理するためのパラメータはdatasetname:acustomers,parentsvectorであること、atransactionsを処理するためのパラメータはdatasetnameatransactionsparentsvectoracustomersであること、を決定してもよい。以下の例は、各データセットインスタンスを処理するためにprodrunグラフにより実行される多くのタスクと共に、プロダクションラングラフにより使用される処理順序と様々なパラメータを導出するタスクを説明する。conspecデータ構造は、一組のデータセットとそれらの制約を、それらのフィールド間の様々なタイプの関係に基づき記述するメタデータのスタンドアロン表現である。いくつかの実施態様では、conspecは、前処理グラフが、一組の共通のDML関数を使用する標準的やり方で一組のデータセット間の制約を読み取りナビゲートすることができるようにする。前処理グラフは、下流のデータフローグラフの操作を駆動する構成パラメータを生成することができる。そのため、前処理グラフは通常、レコードセットよりむしろ操作情報を読み取り、下流のグラフおよびプランに供給されるパラメータセットまたはpsetsと呼ばれるパラメータの組を生成する。パラメータセット内のパラメータは、データフローグラフ中の構成要素の機能にメタデータを与えそれを構成するために使用される。conspecが前処理グラフと共にどのように使用され得るかの考えを得るために、我々は、主キーと外部キー間の参照整合性を維持する一方でデータセットの集合をフィルタリングする例を取り上げることにする。この例では、2つのデータセットが顧客とトランザクションを表すと仮定する。トランザクションデータセットでは、フィールドの1つが顧客データセット内の主キーである顧客idを参照する外部キーであると考える。フィルタリング操作の目的は、顧客データセットとトランザクションデータセットの両方からレコードを取り除くが、フィルタリングで除かれた顧客レコードの顧客識別子IDを参照する生成トランザクションレコードが存在しないようにこれら2つの間の参照整合性を維持することである。このフィルタリング操作を正しく実行するために、システムは処理順序を決定するとともにその順序の関数であるいくつかの制約を維持することができる。例えば、プロセッサは、既に除去された顧客を参照するいかなるトランザクションも含まれないように、顧客を最初に処理し次にトランザクションをフィルタリングすることを決定してもよい。あるいは、プロセッサは、選択されたトランザクションにより参照されるいかなる顧客も除去されないように、トランザクションを最初にフィルタリングするが次に顧客を処理することを決定してもよい。この例の前処理グラフのジョブは、データセットの処理順序を決定することと、各データセットを処理するグラフの振る舞いを管理する規則を書き込むことである。conspecは、これらの生成タスクを実行するために必要とする情報を前処理グラフに提供する。conspecの内容は、単一のデータセット内に含まれるフィールドを記述するDMLレコードフォーマットの内容の範囲を越える。ここで、我々は関連するが別個であるデータセット内のフィールドの集合間の関係と関連性について論じている。これは、主キー/外部キー関係などのキー対キー関係だけでなく順序化されたフィールドすなわち、キーのグループの定義と、N個のデータセット間のソートキーに関わる結合と、を含む。conspecは、一組のレコードベースファイルとして実施されてもよい。この形式では、グラフは、これらのファイルを読み取り、DML関数において使用されるconspecのメモリ内ベクトルベース表現をインスタンス化することができるであろう。別の表現では、conspecは注釈付きDMLパッケージファイルの形式を取ってもよい。このファイルは、キー、キー要素メンバー、関係と関連性を定義する一組の注釈と共にデータセットのそれぞれのDMLレコードフォーマットを含むだろう。この種類の表現は、人間が読むことができかつ編集可能だろう。システムは、直列化されたconspecを読み取りベクトルの集合を例示するDML関数ライブラリを含む。ライブラリは、conspecへの書き込みだけでなくconspec内の関係をトラバースするための関数の組を含む。前処理グラフからの以下のDML変換コードは、ファイルからconspecをロードするための呼と引数としてconspecとデータセット名を取る関数とを示し、主キー要素の最大および最小キー値を調べるためのSQL選択ステートメントを生成する。conspecDMLライブラリは、規定データセットの主キーに関連する要素を得るための関数を提供する。例示的なDML関数を図16と図17A~図17Iに示す。図4Aに戻って参照すると、図は、5つのデータセットと2つの主キー/外部キー関係と一組のマルチフィールドソートキー間の1つの3元結合関係とを含むconspecを描いて示されている。同図は、conspecのメモリ内表現を読み取るとともにsvgファイルとしてレンダリングに好適なgraphvizドットファイルを書き出す一組のDML関数により生成された。矢印は2重の目的に役立つ。すなわち矢印は、外部キーと主キー間のフロムトゥーfromto関係を示し、結合関連におけるキーメンバーシップを示す。conspecが一組のレコードベースデータセットとして実施されるケースに関しては、ユーザはこれらのデータセット間の関係を記述するconspecを生成してよい。これは本質的にconspec群を代表するconspecである。図4Bに戻って参照すると、5つのデータセットの集合を関連付けるconspecが示されている。左側のdmldatasetと名付けられたデータセットは一組のデータセットを定義するために使用される。中央上部のdmldataelementデータセットは、これらのデータセットのそれぞれの中の要素を定義するために使用される。dmldatakeyデータセットは各データセット内のキーを定義する。dmldatakeyelementデータセットは、要素メンバーシップに対するキーを定義する。残りのデータセットは、キー間の関係と関連性を定義する。conspecは、人間が読むことができるやり方で表すことができる。図16、図17A~図17Iに、acustomers、bcustomers、それらのトランザクションおよび関係するconsumerinformationからなる図4Aに示すconspecを記述する注釈付きDMLパッケージファイルのリスト実行可能コードの一部を示す。図16に、conspecと共に使用することができるデータベース照会例えば、SQLを支援するデータベースと共に使用されるSQL照会を設定するDML関数のリスト1600を示す。図17Aに示すリスト1702では、キーとフィールドトゥーキーメンバーシップfieldtokeymembershipは、DML型定義内のフィールドの右に注釈される。上部の注釈のブロックはキー間の関係と関連性を符号化する。図17Bに示すリスト1704は、conspec群のうちの1つのconspecの例を示す。様々なやり方でconspecを表すことができる。以下の例は、conspecの表現を記述するために、ある専門用語を使用する。conspecは、一組のデータセット間の構造と関係との記述である。conspecインスタンスは、conspecにおいて参照されるデータセットのデータセットインスタンスの集合である。データセットインスタンスは、特定のデータセット通常はファイルまたはデータベーステーブル内に提供されるレコードの集合等である。conspecは、注釈付きパッケージファイルとしてまたは多様なレコードフォーマットに続くレコードの集合として格納されてもよい。いくつかの実施態様では、conspecはルックアップファイルの集合として格納される。構造とこれらのルックアップファイル間の関係は、図4Bのconspec群のうちの1つのconspecにより示されるように、conspecを使用して記述することができる。conspec群のこれらの2つの直列化可能表現例えば、注釈付きパッケージファイル、またはルックアップファイルの集合すなわちconspecインスタンスが与えられると、DML関数の集合によりナビゲートまたは変更されることができるconspecのメモリ内DML表現を提供することができる。このメモリ内表現は、図17Cに示すリスト1706の形式を取ることができる。これは、図17Dに示すリスト1708により示されるように、conspecのDMLパッケージファイル表現を分解し、名前によりデータセットを発見し、次にそのデータセットの外部キーを取り出すことを可能にするDML関数ライブラリの開発を可能にする。サブセット化、マスキング、拡張の操作はすべて、ユーザがデータセットの集合とそれらの関連するconspecに適用してよい処理である。これらの操作をconspecプロダクションと考えてもよい。プロダクションは、ソースデータセットインスタンスの場所と識別子およびターゲットデータセットインスタンスの所望の場所と識別子を含むconspecに関連する規則の集合である。ここで、データセットインスタンスは、conspecに記述されたデータセットの実データを参照する。一組のデータセット間の構造と関係を定義するconspecとは異なり、プロダクションは、そのフィールドが、あるconspecにより定義された制約に従うデータセットインスタンスの集合例えば、ファイル、dbテーブル等を処理するための一組の規則を定義する。conspecはデータセット内のレコード間の依存性等の制約を定義するので、データセットインスタンスの集合内のデータを処理する任意の種類のプロダクションはconspecを使用することより依存性を重んずる順序でそのようにする。例えば、顧客をフィルタで除去することを要求するプロダクションはこの操作を最初に行い、次に従属データセットインスタンスからレコードトランザクション等をフィルタで除去する。あるいは、新しい顧客とトランザクションを生成したプロダクションがあれば、システムは第1の顧客データセットインスタンス内に新しいレコードを生成し、次に新しい顧客を参照するためにトランザクションデータセットインスタンス内の新しいレコードを線でつなぐだろう。顧客が既に存在すれば、システムは多分、新しい顧客を生成することなく新しいトランザクションを既存客に線でつなぐことができるだろう。いずれの場合も、conspec内の依存性は、プロダクション規則の性質に依存して参照整合性を実質的に維持するために重んずることができる親から子への処理順序を暗示する。プロダクション同士を線でつなぐのを支援するために、一般的なプロセッサはプロダクションに固有な署名を使用することにより新しいレコードにIDを割り当てる。これにより、1つのプロダクションにより割り当てられたIDが次のプロダクションにおいて割り当てられるIDと競合しないことを保証する。これの詳細な検討は主キー割り当てに関する章に続く。図7に、プロダクションプロセッサのタスクを実行することができるプラン700を示す。プランは、そのノードが実行されるタスクを表しそのリンクがタスクを呼び出す順序を表す有向グラフである。プラン700は、prodsetupグラフを呼び出すことにより動作し、次に処理順序でprodprofileの実行とデータセット毎のprodrunpsets、そしてconspecに定義された依存性と等価性毎のprodanalyzepsetsをループスルーする。プランは、プロダクションの規則に従う処理順序で名前を付けられた各データセットインスタンスをプロファイリングし、分析し、処理するのに必要なパラメータセットと共に、conspecにおけるデータセットインスタンスの処理順序を生成する責任を負うprodsetupと呼ばれるグラフ702を実行することにより始まる。prodsetupグラフ702は、処理順序、prodprofile、prodanalysis、prodrunpsetsを生成する。prodsetupグラフ702は図8においてさらに詳細に示される。図7に示すプラン700により表されるプロダクションプロセッサの第2番目の工程704は、データセットのそれぞれを処理順序でプロファイリングするために使用されるデータフローグラフpsetsにより構成されるの実行をループスルーすることである。様々な技術の任意のものを、データフローグラフ例えば、参照により本明細書に援用する米国特許出願公開第2005/0114369号に記載されたを使用してデータセットをプロファイリングするために使用することができる。プロファイリングは、プロダクションがデータベースに対しレコードをアンロードまたは更新することを要求してもよい場合と、任意のアップロードを実行する前にデータベース内の主キーの開始および終了指標値を知ることが重要な場合に、必要かもしれない。これは、プロダクションがレコードを拡張または複製することを要求するかもしれない場合に重要である。レコードが複製される場合、各主キーメンバーの新しい主キー値が割り当てられる必要があり、したがってプロダクションプロセッサは、データベース内に既に存在する値と干渉しない新しい値が選択されることを保証するためにデータベースにより使用される既存のキー値の知識を利用してもよい。処理のプロファイリング段階は、処理順序で名前を付けられたデータセット毎の主キー指標のそれぞれの最小および最大値を生成してもよい。プロファイリンググラフは、個々のデータセットを処理するために利用される後続のグラフにより使用されるファイルにデータセットインスタンス毎に最小および最大値を書き込んでよい。単純な場合、prodrunグラフは、レコードを複製してN個の新しいレコードを生成し、最大値と最小値の差に跨る範囲のブロック内において新しい主キー値を割り当て、これによりデータベースにアップロードされた新しいレコードがデータベース内に既に存在する値と競合しないことを保証してもよい。図7に示すプラン700により表されるプロダクションプロセッサの第3番目の工程706は、conspecに定義された依存および等価特性のそれぞれを分析することである。図4Aに示すabconspecの例では、結合関連性は3つのデータセット、acustomers、bcustomers、consumerinfo間の等価性を定義する。この工程では、プロダクションプロセッサはデータセットインスタンスのそれぞれを読み取り外部結合を実行することによりこの特性を分析する。外部結合の重複結果は集められ、フィルタリングを行なうためにprodrunグラフにより用いられる分布分析ファイルに書き込まれる。この工程の詳細は図10と図11の検討時にカバーされる。図7に示すプラン700により表されるプロダクションプロセッサの第4番目の工程708は、各データセットインスタンスを処理するために使用されるデータフローグラフpsetsにより構成されるの実行をループスルーすることである。この工程は、後続の図12B~図12Fに示す副工程を有する図12Aに示すグラフprodrunを呼び出すことを含む。図18Aと図18Bに、考慮すべきデータセットの初期シードセットと走査および包含traversalandinclusionから除外すべき一組のデータセットが与えられたとして、親から子までの処理順序を生成するためにプロダクションプロセッサにより使用されてよい論理1802、1804の例を示す。シードおよび除外データセットseedandexclusiondatasetsをプロダクションの一部としての規則として渡してもよいということに留意されたい。conspecは、処理順序を含む際に考慮されるすべてのデータセットのスーパーセットを定義してもよい。acustomers、bcustomers、atransactionsなどを含むabconspecを参照して、ユーザはatransactionsを除外することを選択してもよい。この場合、処理順序はacustomersから始まるが、atransactionsを含まないだろう。同様に、ユーザがソースのリスト内にacustomersを含まないことを選択すれば、acustomersもatransactionsも処理順序に含まれないだろう。図18Aと図18Bは、プログラミング機能のように見えるように擬似コード形式の論理1802、1804を提示する。論理1802のmain関数は、空のprocessingorderベクトルを初期化し、次に処理順序を投入する関数を呼び出すことにより始まる。このmain関数は、タスクが完了するまでprocessingorderベクトル内に書き込む。main関数は、名前を付けられたソース内の各データセットをループスルーしデータセット毎にデータセットのベクトルとそのすべての子を再帰的に導出するgenprocessingorder関数を利用する。main関数は次に、結果をallresultsベクトルに加え、重複値がないことを確認する。順序はこの時点では重要ではなく、再帰的にすべての子を包含することだけが重要である。genprocessingorderがすべての関与データセットのリストを導出すると、genprocessingorderは、最も高いレベルの親すなわち、allresultsの組にも含まれる親を有しない親を決定することに進む。これを決定する関数はupdateprocessingorderである。この関数は、allresultsの組において最も高いレベルの親に達するまで親を昇ることにより再帰的に作用し、次にこの最も高い親データセットをprocessingorderベクトル内にダンプする。次に、残りのデータセットはprocessingorderベクトル内にそれを順にダンプすることができるまで最も高いレベルの残りの親を発見するために再び再帰的に昇ることにより処理される。関数getdatasetanditschildrenrecursivelyは、直接の子に作用し次にそれ自身を呼び出す再帰関数を呼び出す先頭の関数として機能する。ここでトップレベルの関数は、再帰的にすべての子のリストになる当初空のベクトルを有するgetdatasetanditschildrenを呼び出す。この関数getdatasetanditschildrenはソースデータセットの直接の子に働きかけ、それ自身を呼び出し、累積データセットのベクトルをその再帰呼出しに伝える。全体処理は最初に、すべてのallresultsの組を得るために子を再帰的に得ることを含む。但し、この処理はこのすべてのソースの組から親を再帰的に得ることにより終了する。図9Aと図9Bに、この論理を使用する処理順序と、順序を導出するために使用される付随conspec群との例を示す。図9Aは、子が処理される前にすべての親が処理されることを保証する処理順序902の例である。示された処理順序はA、C、F、E、D、Bである。図9Bに、子が処理される前にすべての親が処理されることを保証する処理順序を示す複雑なconspec904を示す。示された処理順序はOpJobDefinition、JobDefinitionPropertyValue、OpTimeConstraint、OpDay、OpJobDefinitionDependency、OpFileAndEventConstraint、OpJobDefinitionAction、OpJobDefinitionActionArgumentである。処理順序を生成するための論理の他の実施形態は子から親への順序を決定することを含んでもよい。図7のprodanalyze工程706は、conspec内の各依存性と等価性がプロダクションにおいて特定されるデータセットインスタンスの組に関し分析され得る工程である。conspecに関連するデータセットインスタンスの各集合は、特性毎に異なる重複の分布を提示するかもしれない。例えば、acustomersとatransactions間などの依存性により、ある組のインスタンスの比較的少数の顧客に関連する多くのトランザクションが存在する可能性がある。しかしながら別の組のインスタンスでは、顧客毎には比較的少数のトランザクションであるがすべての顧客全体にわたってより均一な分布が存在するかもしれない。このような依存性の特徴を知ることは、既にフィルタリングされた先行点のデータセットインスタンスと比較する際にどのレコードをソースデータセットインスタンス内に保つかを判断するのに有用かもしれない。依存特性と同様に、等価特性は、データセット間のキー対キー等価性を定義する。しかしながら依存特性と異なって、等価特性はフロム-ツーとは対照的に、多対多と考えてよい。例えば、abconspec図4Aでは、結合1等価性は3つのデータセットを含むように定義される。これらのデータセットのそれぞれは、他のデータセット内のキーと等価であると考えられ得るキーを有する。等価性は、等価性が依存特性を伴うであろうように、1つのデータセット内のレコードの存在が別のデータセット内のレコードの存在を強要しなければならないことを示唆しなく、むしろ、関与データセットからの2つのレコードが同じキー値を共有すればそれらは同じ意味を有し等価である。図10と図11は、等価特性を分析するための処理工程と結果を示す例えば、図7に示すプラン700により表されるプロダクションプロセッサの第3番目の工程706の一部として実行される。図10は、最大3元結合分析器の構成を示す。特に、これは、conspecに定義された結合依存性と等価特性を分析するために使用されるprodanalyzeグラフ1000である。その結果は、関与データセットインスタンスの外部結合重複データと分布ヒストグラムである。別の実施形態では、このメカニズムは最大N個の同時結合を支援し、conspec内に等価特性に対して定義されるように、異なる数のデータセットインスタンスを支援するように構成可能であってよい。処理における外部結合1002は各入力データセットをそのそれぞれのキー要素メンバーについてソートするように構成されてもよい。prodsetupグラフはさらに、データセットインスタンスのそれぞれのソートキーのそれぞれを示すprodanalyzeグラフを提供するpset内に既に書き込まれたパラメータを有してもよい。abconspecの例では、acustomers、bcustomers、およびconsumerinfoデータセットはすべて、そのメンバーがplacebuildingnum}であるキーを有するが、キーメンバーはデータセットインスタンス毎に異なってもよい。外部結合1002は、各データセットインスタンスからのレコードヒットを結合し、次に関与データセットインスタンスのヒットステータスを有するキー値組み合せの発生を一意的に特定してよいキー値のハッシュ値を計算する役目を果たす。例えば、1つのキー値組み合せがplacefooとbuildingnumbarならば、これは例えば12345のaggregatevalueハッシュを生成し、出力レコードは各データセットのヒットステータスを含むだろう。すなわちsourcedataset1は実際に当該値などを有していた。図17Eに示すリスト1710は、関与データセットインスタンスの集約ハッシュ値とヒットステータスを計算するために使用されてよい関数の例である。prodsetupグラフ702はこの変換を生成し、prodanalyzeグラフ例えば、図7に示す工程706をターゲットとするpset内のパラメータ値としてそれを渡してもよい。このパラメータ値は、関与データセットのそれぞれの生成されたキーパラメータ値の組を伴ってもよい。分析ヒストグラム生成工程1004は、外部結合1002の出力を取り、ヒット結果の集約を行う。出力レコードのストリームは外部結合から一意的集約値すなわち外部結合からのキー値の一意的組み合せを示す。このようなレコードのストリームは次にヒットフィールド:source1hitsourceNhitによりソートされ、スキャンおよびロールアップ構成要素内に供給される。この時点で、各レコードは、各データセットソースが当該キー値組み合せを有することに関与したかどうかのヒットステータスに加えて、外部結合内のキーの一意的集約値を示す。ヒットフィールドによりレコードをソートし、それらをスキャンおよびロールアップ内に渡すことにより、システムは、各レコードにおいて発見されたヒットステータスの組み合せのランニングカウントと合計カウントを決定することができる。したがって例えば、最初のレコードがplacefooとbuildingnumbarの集約値を有すれば、スキャン/ロールアップは、データセット1とデータセット3の両方がキー値の当該組み合せを有することに関与したことを示す組み合せヒット1,0,1を探索するであろう。構成要素はまた、探査してこれがこのヒットの組み合せの最初の発生だったことを理解し、このレコードに1のランニングカウントと1の合計カウントを割り当てるだろう。第2番目の集約値レコードが異なるヒットの組み合せを伴って来れば、第2番目の集約値レコードにも1のランニングカウントと1の合計カウントが割り当てられるだろう。第3番目の集約値レコードが最初のレコードと同じヒットの組み合わせを伴って来れば、第3番目の集約値レコードには2のランニングカウントと2の合計カウントが割り当てられるだろう。この処理の結果は、外部結合1002の一意的キー値の組み合せを表す一組のレコード結合分析レコードと呼ばれるである。レコード毎に、システムはまた、どのソースデータセットインスタンスが結合に関与したかと、どれだけの合計カウントのレコードが、だけでなくそれぞれがこのヒットの組み合せを有して表されるどれだけのランニングカウントが、このヒットの組み合せと共に発生したかと、を知ってもよい。この情報はprodrunグラフにおいて実行される下流操作にとって有用かもしれない。例えば、prodrunグラフは、この結合分析に関連するデータセットインスタンスの1つを結合結果に結合させるように構成されてもよい。結合は、ソースデータセットインスタンスにおける関与キー要素値を使用して対応計算値と結合された分析結果からの集約値キーを使用することにより実行されてもよい。結合は、ソースデータセットのレコード毎に、類似キー値を有するレコードが、conspecに定義された等価特性例えば、関連性に関与する他のデータセットインスタンスのいずれかにおいて発生したかどうかを示す。図11に、abconspecに関連するプロダクション内に定義されたデータセットインスタンスの集合のチャート化ヒストグラム結果1100を示す。これは、重複した依存性または等価性の結合において定義された関与データセットインスタンスからのレコードの数を示すprodanalyze分布ヒストグラムである。1は、データセットインスタンスが当該グループ内にレコードを有したということを示す。グループは、結合キー上に一致値を有するレコードの集合である。この例は、図4Aのabconspecに定義されたacustomers、bcustomers、consumerinfo結合からの結果を示す。これらの結果1100は、abconspecに定義された結合1関連性に適用されるプロダクション分析処理例えば、図7のprodanalyze工程706の結果である。3つのデータセットは他のデータセットからのいかなる対応レコードとも一致しない多数のレコードを有すると理解してよい。キー値の組み合せのうちのいくつかだけが、データセットインスタンスうちの2つからの、または3つすべてからのレコードを有する。したがって、これらの結果から、ユーザがacustomersデータセットインスタンスからのレコードをフィルタリングして、プロダクション/conspecに関連する他の2つのデータセットインスタンスと共にヒットの組み合せの分布を維持することを望めば、そのキー値が1-0-1と1-1-0グループに入るレコードを含むように注意しなければならないであろう。換言すれば、ユーザがこれらの結果を使用することなくacustomersからのレコードを不注意に選択すれば、bcustomersとconsumerinfo内に一致するレコードを有したレコードの大部分またはすべてを取り落とし易いであろう。このような不注意なacustomersからのレコードの選択は、conspecに定義された結合特性により表された外部結合分布特徴とプロダクションにおいて特定されたデータセットインスタンスにより表された特定値とを壊すだろう。prodanalyzeグラフ例えば、図7のprodanalyze工程706が、conspecに定義された等価特性例えば、その値が等価な意味を有するフィールド間の関連性のそれぞれの分析結果を生成したならば、図7に示すプロダクションプロセッサプラン700は、処理順序で特定される各データセットインスタンスに関連するpset毎にprodrunグラフ例えば、工程708を呼び出してもよい。図12Aに、psetにより提供される入力値の集合を使用してデータセットインスタンスを処理することに関与する工程を示す。この工程は、処理順序でデータセットインスタンス毎に実行されるprodrunグラフ1200の構成要素として表される。図12Aの例の最初の工程1202は、プロダクション内のデータセットインスタンス毎に提供される命名規則に従って入力ソースデータセットインスタンスをロードすることである。データセットインスタンスの名前と発生元はそのpsetパラメータの1つとしてprodrunグラフに提供されてもよい。データセットインスタンスはファイルに由来する必要はない。あるいは、データセットインスタンスは、プロダクションにおける入力として提供されるSQLステートメントを使用してデータベーステーブルからアンロードされてもよい。任意の可能なデータソースが、ウェブサービス、連続的流れからのデータのスナップショット、データベース、フラットファイル、または別のデータソース等のデータセットインスタンスとなってよい。プロダクションは、プロダクションから読み出されてprodrunpset内に書き込まれるパラメータを介し様々なタイプのデータセットインスタンスのそれぞれを見つけてロードするために、プロダクションプロセッサに十分な情報を提供する。prodsetupグラフは、プロダクションから各データセットインスタンスの場所の情報を抽出し、このデータを入力パラメータとして、prodrunグラフを提供するpsetに書き込む。図12Bに、prodrunグラフ1200のデータ読み取り工程1202の詳細を示す。この例は、データベーステーブルまたはフラットファイルのいずれかを含むローディングフローである。より完全なロード構成要素が、他のタイプのソースからデータセットインスタンスをロードできるようにしてもよい。さらに、conspecにおいて特定される各データセットインスタンスは他とは異なる表現と場所を有してもよい。換言すれば、プロダクションは、プロダクションプロセッサに指示してフラットファイルから第1のデータセットインスタンスそしてデータベーステーブルから第2のデータセットインスタンスをロードさせてもよい。加えて、conspecAに関連する第1のプロダクションがファイルからデータセット1のインスタンスをロードすることを要求し、一方、同じこのconspecAに関連する第2のプロダクションはデータベーステーブルなどの異なるソースからデータセット1の異なるインスタンスをロードすることを要求していてもよい。図12Aに戻って参照すると、データセットインスタンスがprodrunグラフ1200によりロードされると、第2番目の処理工程1204はprodanalyzeグラフ例えば、図7の工程706により生成された依存性と等価性結合結果のそれぞれに対して1つまたは複数の結合操作を実行する。acustomersの場合例えば、図4Aに示すように、本明細書に記載の結合1分析結果に対して実行された結合があるかもしれなく、これによりprodrunグラフ1200が、bcustomersとconsumerinfo内の等価なレコードを共有したacustomersからレコードを特定できるようにしてもよい。次にprodrunグラフ1200は、前に処理されたbcustomersまたはconsumerinfoデータセットインスタンスからのレコードとの同じ重複を維持するように、acustomersデータセットインスタンスから所望の割合のレコードを包含及び除外してもよい。ソースデータセットインスタンスとprodanalyze処理からの1つまたは複数の結合分析結果セットとを結合させることの代替として、prodrunグラフ1200は既に処理された親データセットインスタンスと直接結合してもよい。次にprodrunグラフ1200は内部結合を実行し、当該の一致を有しないソースデータセットレコードを単純に除去してもよい例えば、conspecに定義された依存特性に基づき。プロダクションプロセッサ例えば、図6に示すプロダクションプロセッサ600の機能の1つは、データセット毎に処理されたデータセットインスタンスを処理順序で書き出すことと、処理されると後続データセットインスタンスに結合されるようにこれらの処理されたインスタンスを線でつなぐことである。加えて、プロダクションプロセッサの第2の機能は、conspecにおいて特定された依存性と等価特性を分析することと、当該データセットインスタンスの内部結合特徴と外部結合特徴を説明するこれらのヒストグラム結果を書き込むことである。さらに、プロダクションプロセッサの第3の機能は、既に処理されたデータセットインスタンス内の等価または依存性レコードを共有してよいレコードをprodrunグラフ1200が特定できるように、これらのヒストグラム結果と各ソースデータセットインスタンス間の結合を線でつなぐことである。用語線でつなぐは、処理順序でデータセット毎にprodrunpsetsに特定パラメータ値を書き出すことによるprodsetupグラフ例えば、図7に示すグラフ702の実行を指す。これらの特定値は、処理されたデータセットインスタンスの名前を識別し、conspecの依存性と等価特性により定義される主キー値を含む。これらの値は、prodrunなどの一般的グラフが、既に処理されたデータセットインスタンスに対してロードおよび結合するように動的に構成できるようにする。依存性結合を実行する工程例えば、工程1204の間、prodrunグラフ1200は、prodrunグラフの先行実行から零または複数個の出力データセットインスタンスをロードする。prodsetupグラフ702図7は、特定のソースデータセット用にN個の先行データセットインスタンスすなわち、一実施形態における親をロードする必要があると判断したかもしれない。prodsetupグラフ702は、prodrunグラフ1200のソースデータセットの入力pset内のパラメータとして対応出力データセットインスタンスの場所を書き込むことができる。加えて、prodsetupグラフ702は、どれだけの数の先行データセットインスタンスをロードする必要があるかもしれないことを示すためにパラメータを書き込むことができる。依存性および等価性結合と名付けられた図12Aの第2番目の工程1204は、可変数の先行データセットインスタンスをロードする役目を果たしてもよい結合メカニズムの実施形態を示す。この工程1204の詳細を図12Cに示す。入力pset内に提供されたパラメータに依存して、このメカニズムは、先行データセットインスタンス毎に1つの結合ソースを活性化してもよい。この処理は、対応先行データセットインスタンスの1つまたは複数のインスタンスからのレコードを正常に内部結合するまたはそれに一致すれば、ソースレコードを選択できるようにしてもよい。各先行データセットインスタンスにこの結合を実行するために、prodrunグラフは、ソースデータセット内の外部キーソート要素の知識と各先行データセット内の対応主キーソース要素とを与えられる。この情報はprodsetupグラフにより計算され、追加のpsetパラメータとしてprodrunグラフに渡される。この結合工程は、conspecに定義された依存すなわち関係および等価すなわち関連特性を共有する他のデータセットインスタンスと一致または一致しないレコードの分布を維持する目的のためにソースデータセットインスタンスに作用する。この例では、atransactionsがソースデータセットと考えられる場合、この結合メカニズムは、prodrunグラフの先行操作において既にフィルタで除去されたacustomersデータセットインスタンスからのレコードと一致しないatransactionsデータセットインスタンスからのレコードを除去することを保証してもよい。これは、内部結合特性を維持する工程と呼ばれる。この例では、これは、acustomersからのいくつかの参照レコードが既に除去されたとすれば有効でないかもしれないレコードをatransactionsから除去することが重要であることを意味する。依存特性のフィルタリングに加え、この結合メカニズムはまた、等価特性をフィルタリングしてもよい。図4Aのabconspec400における等価特性の例は、acustomers、bcustomers、consumerinfo間で定義された結合1等価性である。図11に示すヒストグラム結果1100を生成した分布分析は、acustomersおよびbcustomersなどの既に処理されたデータセットインスタンスに対するconsumerinfoなどのソースのレコードの分布をも維持するために、この結合工程により利用されてよい。換言すれば、この結合メカニズムは一組のピア関係データセットインスタンス間の外部結合特徴が維持されることを保証してもよい。したがって、元のacustomersとconsumerinfoからのレコード間に高程度の重複があるが元のacustomersとbcustomersからのレコード間に低程度の重複があれば、この結合はbcustomersとconsumerinfoの2つの既に処理された集合を評価し、そしてその結果が元のものと同様な分布を維持するように一組のacustomersをフィルタリングしてもよい。一般的には、これは、元のデータセットが必要としたように、処理されたデータセットが処理されたデータセット間で同じ種類の重複を有する必要がある場合に重要である。プロダクションプロセッサのタスクの1つは、プロダクション内に定義された規則の集合により規定されるように、様々なデータセットインスタンス内のレコードへの変換をすべて完全に実行する一方で、conspecに記載された等価性と依存特性により表される分布パターンを維持することである。図4Aに示すabconspec400からのacustomersとatransactionsの例を参照し、我々は、ソースデータセットがatransactionsである場合であって、かつatransactionsすなわち、acustomersに対する1つの先行点が存在するとprodsetupグラフ702が既に判断した場合を考えてもよい。prodsetupグラフはatransactionsacustomersを参照するものの外部キー要素をソートキーの形式{custid}で書き込んだかもしれない。さらに、prodsetupグラフはacustomersデータセットの主キー要素をソートキーの形式{custid}で書き込んだかもしれない。これらの異なるソートキーは、その対応データセットとは異なる名前の要素を参照してもよいので、異なる値を有してもよい。特定の先行データセットの外部キー要素とその対応する主キー要素とを決定するためにprodsetupグラフにより必要とされる情報は、プロダクションプロセッサの設定処理の一部として読み取られてよいconspec内で発見されるかもしれないということに留意されたい。1つまたは複数の先行データセットインスタンスに対してソースデータセットインスタンスの結合およびフィルタ処理を実行するために、prodrunグラフ1200はそれぞれのソートキーを必要とするかもしれない。図18Cと図18Dは、conspecにおいて概要を述べたようにソースデータセットと外部キー/主キー依存性を共有するそのN個の先行データセットとの間の結合リンクとして機能するソートキーを生成するために使用される論理1806、1808の例を示す。これらの機能は、プロダクションプロセッサ例えば、図7に示すプラン700により表されるプロダクションプロセッサのprodsetupグラフ702において実施されソースデータセットのprodrunグラフ1200のpset値を生成する処理の一部と呼んでもよい。これらの例における論理は、ソースデータセットとその先行データセットのうちの1つとの間の第N番目の依存性関係を特定するために提供される指数を利用してもよい。我々のacustomersとatransactionsの例では、atransactionsからacustomersへの1つの依存性関係だけが存在し、したがってこの指標はただ1つの値0を有することになる。getfkeysortelementsと呼ばれる第1の関数は、prodsetupにより導出されるprocessingorderベクトルに含まれる親データセットを発見することから始まる。次に、上記関数は、これらの親を参照するソースデータセット内の外部キーを発見するためにこれらのデータセットを使用する。一組のキーから、上記関数は第N番目のキーを獲得し、ソースデータセット内のキー要素を抽出する。マルチパートソートキーを書き出すためにこれらのキーの順序を読み取って使用してよい。同様に、getpkeysortelements関数は、親データセットのうちの1つにおいて主キーソート要素を生成するために呼び出されてもよい。図18Dに示す論理1808は、処理順序で同時に発生する親データセットこれらの親データセットは既に処理されているかもしれないを探索するためにソースデータセットを使用する例である。親が与えられると、上記機能は、ソースデータセット内の外部キーを探索し、ソース親を指す外部キーを選択してもよい。この外部キーのセットが与えられると、上記関数は第N番目のキーを選択し、次にソース親内のその対応主キーを見出してもよい。この主キーから、上記関数は、キー要素メンバーのシーケンスを発見し、マルチパートソートキーを書き出してもよい。これらの2つの関数は、prodsetupグラフ1200がソースデータセットの外部キーを周期的に繰り返して、ソースと親データセットペア毎にソートキーのグループを生成できるようにする。次にprodsetupグラフは、ソースデータセット毎にprodrunpsetにパラメータとしてこれらのキー値を書き込んでもよい。prodrunグラフ1200の第3、第4、第5番目の処理工程1206、1208、1210はプロダクションにより提供されるカスタム変換規則を適用するために使用される。データセットインスタンスに適用されてもよい3種類の変換が基本的に存在する。工程1206サブセット化は、ソースデータセットインスタンスからのレコードを削除しなくてはならないかどうかを判断することを含む。別の工程1208修正は、同じインスタンスからのレコードが変更されなければならないかどうかを判断することを含む。変更は、要素を追加または除去することおよび/または要素の値を修正することを含んでもよい。別の工程1210拡張は、同じインスタンスからのレコードがN個の新しいレコードに複製されなければならないかどうかと、新しいレコード毎に新しい値は何でなければならないかと、を判断することを含む。単一のプロダクションは、これらのタイプの変換のうちの任意のものを要求してもよい。これらの変換は、プロダクションプロセッサにより連続して適用されてもよい。例えば、プロダクションは、prodidと価格の要素に関する度数分布などの特性により特徴付けられるような統計的一貫性を維持するために一組のatransactionsを最初にサブセット化することを要求し、次に残りのレコードを複製するためにサブセット化結果を拡張し、新しい値を展開して様々な取引期日を有してよい。用語展開は、ある範囲全体にわたって新しい値を分布させる式を使用してN個の新しい複製レコード内の要素の値を修正する行為を指す。したがって、取引期日などの期日を展開する場合、プロダクションは当該期日にM日を加えることにより期日を展開するように規定してもよい。ここで、MはN個の複製された新しいレコードの指標である。プロダクションプロセッサの機能はプロダクションにより規定されるように、任意のサブセットの組み合わせを適用するための一般的メカニズムを提供し、修正しそして変換を拡張することである。これらの変換のそれぞれはプロダクションにより提供される論理を組み込んでもよいが、それぞれがまた、先行の処理済みデータセットインスタンスの結果を利用することを含んでもよい。プロダクションプロセッサは、プロダクション規則と共に先行の処理済みデータセットインスタンスの結果を取り込んでもよい。例えば、プロダクションは、atransactionsを複製することと取引期日フィールドを展開することとを要求してもよい。この例では、プロダクションは図4Aに示すabconspec400と関連付けられてもよいであろう。atransactionsの拡張は、複数の要因のうちの任意のものに依存してもよいであろう。例えば、プロダクションはatransactionsだけでなくacustomersも変換することを要求してもよい。一例では、acustomersは、顧客毎にそれぞれの主キーの対応する新しいかつ一意的custid値を有するN人の新しい顧客が存在するように最初に拡張されてもよい。atransactionsが拡張される場合、新しいatransactionレコードを取り扱う少なくとも2つのやり方が可能かもしれない。1つのやり方は、新しいacustomerレコードの1つを参照するためにそれぞれの新しいatransactioncustid値を修正することを含み、別のやり方は、元のatransactionレコードが指したのと同じacustomerレコードを指すためにそれぞれの新しいatransactionレコードを残すことを含む。あるいは、acustomersが拡張されずむしろ低減されれば、拡張されるatransactionレコードは、含まれたacustomerレコードだけを参照するために最初にサブセット化されていなければならなく、含まれたacustomersだけを参照するようにcustid値を未変更のままにして拡張されてよいであろう。プロダクションプロセッサは、conspecに定義された依存および等価特性に従って参照整合性のメンテナンスを扱う。いくつかの例では、サブセット化プロダクションは、子を介してレコードを再帰的にフィルタリングすることができる。例えば、単一のプロダクションは、conspec内のデータセットの1つに適用される単一のフィルタリング規則を含んでもよい。加えて、プロダクションはまた参照整合性を維持するすべてのデータセットインスタンス間の最少組のレコードだけを残して他のデータセットインスタンスからのレコードを除去するという暗黙規則があってもよい。一例として、図4Aに示すconspec400を参照すると、ユーザは、顧客場所フィールドがAtlanticの値を有した顧客とトランザクションだけを保持するようにしてよい。ユーザは新しいプロダクションを定義し、それをabdemoconspecに関連付け、次に2つのフィルタ規則、すなわちacustomersデータセットに関するものとbcustomersデータセットに関するものとを表すだろう。規則は、placeAtlanticを示すフィールドレベルの制約であろう。フィルタ規則を提供することに加え、ユーザはまた、参照整合性を維持するためにすべてのデータセットインスタンス全体にわたる最大組のレコードを保持することを要求するグローバル規則を規定してもよい。最後に、ユーザは、データセットインスタンスファイル、データベーステーブル、またはconspecに定義されたデータセットのそれぞれの他のデータソースの識別子と場所を規定するだろう。このプロダクションが与えられると、一般的プロダクションプロセッサはconspecとプロダクション規則の両方を解釈し、データセットインスタンスの処理順序を最初に決定するだろう。フィルタ規則はフィルタ規則に依存する子データセットを有するデータセットに適用されるので、プロセッサは、顧客データセットインスタンスから始まる処理順序を最初に導出するだろう。一般的プロセッサが実行する必要のある作業の最初の部分は、任意の変換、結合、または各データセット処理タスクにより必要とされる他のメタデータと共に、全体の処理順序の生成である。この例では、プロセッサは、結合される親を有しない顧客に最初に作用する必要がある。しかしながら、トランザクションレコードのそれぞれは、選択された顧客に正確に一致する最大組のトランザクションを生成するように、対応する選択された顧客と内部結合される必要があるので、顧客処理の出力は保存されトランザクション処理工程に使用可能とされる必要がある。処理の最初の部分がデータセット処理順序とすべての結合論理、変換などを生成すると、プロセッサはループサブプラン内のグラフにより各データセットインスタンスの処理を渡してもよい。図12Dに、prodsetupグラフ702によりパラメータとして提供される変換関数を適用するサブセット化変換工程1206の一実施形態を示す。フィルタは、これらに限定しないが単一レコードと度数分布を含む複数タイプのものであってよい。単一レコードフィルタにより、レコードを選択または削除するために各レコード内の値だけを使用することができる。このタイプのレコードの例は、プロダクションの一部として提供される図17Fに示すリスト1712内に示す変換関数に示される。この例では、acustomersデータセットからのレコードはすべて選択されるが、bcustomersデータセットからのレコードは、place要素が文字Mから始まる場合に限り選択される。prodsetupグラフ702はプロダクションからこの関数を読み取り、次にデータセット毎に関数を呼び出しデータセット毎にサブセット化フィルタの値を得てもよい。第2のタイプのフィルタ度数分布は、統計的一貫性を維持するための制約に基づく変換の例であり、データセットインスタンス内のいくつかの名前付き要素全体にわたる値の度数分布を分析することを含む。度数ベースのフィルタリングの目標は、一組の要素値の組み合せ全体にわたる値の分布を依然として維持する一方で、ソースデータセットインスタンスからレコードを除去することである。例えば、ユーザはatransactionsをフィルタリングすることに関心を持ってもよいが、元のデータセットインスタンスにおける値の度数分布と同じである価格、prodid、transtypeフィールド全体にわたる度数分布を維持するやり方でフィルタリングしてよい。プロダクションの一部として提供される図17Gに示すリスト1714内に示す変換関数は、度数分布フィルタリングのために考慮されなければならないデータセットから要素の名前を獲得するためにprodsetupグラフにより使用されてもよい。加えて、この変換は、連続要素を列挙値にバケット化するデータセットインスタンスが無限数個の値を有してよいことを意味する式を与える。これにより、prodrunグラフサブセット化変換工程1206が、名前付き度数分布要素の1つまたは複数の要素の値の離散集合によりレコードをサブセット化できるようにする。このようにして値がバケット化されると、システムは各バケットグループに入るレコードのカウントに基づきサブセット化を実行してもよい。この例では、プロダクションはatransactionsとbtransactionsの価格をバケット化するとともにconsumerinfoのestincome要素をバケット化する式を提供する。式が要素の値を単に戻す場合、これは、一組の値が適度なサイズの列挙であると既に考えられたことを意味する。図12Dに示す工程は、プロダクションにおいて名付けられた度数分布フィルタ要素の値の一意的組み合せを有するレコードのカウントを評価しロールアップするタスクを実行する。スキャンとロールアップが実行されると、レコードは単一レコード規則と度数分布規則の両方に従ってフィルタリングされる。このとき、サブセット化レコードの元レコードに対する一致性を示すために別の度数分析が生成レコードに対しなされる。このデータは、ヒストグラム図に書き込むことができる例えば、図13に示すように。いくつかの例では、プロダクションプロセッサの機能は、プロダクションにおいて名付けられたデータセットインスタンスのそれぞれの新しい処理済みデータセットインスタンスを書き出すのではなくむしろ、処理工程のそれぞれから導出されるレポート情報を書き出すことである。図13に、placeおよびestincome要素に関する度数分布により特徴付けられるような統計的一貫性を維持しつつ1/5の低減を要求するプロダクション規則を使用してサブセット化変換を適用した結果の生成されたヒストグラム1300を示す。ヒストグラム1300は、consumerinfoデータセットに適用されたサブセット化操作からの度数分布結果を示す。図12Eに、ソースデータセットインスタンスにおけるN個の複製レコードのそれぞれに対しカスタム展開規則を適用することができる拡張変換処理工程1210の実施形態を示す。拡張は、1つまたは複数のデータセットインスタンス内に新しいレコードを生成する処理である。このレコードは、最初から、または既存のレコードの複製により生成されてもよい。複製中のレコードが他のデータセット内のレコードに対する依存性を有すればconspecに定義されたように、プロダクションは、子データセットインスタンス内の新しいレコードを親データセットインスタンス内のものへ線でつなぐかどうかを判断する。あるいは、プロダクションは親レコードも同様に複製し、そして新しい親を指すために新しい子を線でつないでもよい。このようにして、関係レコードの集合は参照整合性を維持しながら複製されてよい。図12Fに、prodrunグラフ1200の最終工程1212である書き込データ機能を示す。図14に、conspecこの例では、データフローグラフにより実行されるジョブのランタイム実行の監視を可能にするアプリケーションに関連するconspecにおける複数のデータセット内のレコードが拡張される拡張1400を示す。この場合、プロダクションはジョブ定義とアプリケーションを最初に複製し、次にジョブを複製する。各新しいジョブは、各新しいジョブ定義とアプリケーションを参照するように線でつながれる。各データセットインスタンス内のレコードを拡張するジョブに取り組む前に、プロダクションは、データセットの全体処理順序を最初に決定する。この場合、すべての依存する親が処理される前にいかなる子も処理されてはならない。ここで、子は、親データセット内の主キーに対する外部キー参照を有するデータセットである。最も基本的な拡張では、プロダクションプロセッサは、テンプレートとして各元レコードを使用することによりN個の新しいレコードを複製してよい。各新しいレコードの各フィールドは、主キー、外部および/または一意キーを含む場合に新しい値を得ることを保証するように処理される。主キーの場合、新しい値は既存のキー値と競合しないように選択される。外部キーの場合、値は新しい拡張された親レコードの対応する新しい主キー値を指すために変更される。一意キーの場合、値は、当該タイプのすべてのレコードの空間内の一意性を保証するために元のものから変更される。例えば、GUIDフィールドを一意的なものにすることができる。これらのフィールド拡張規則の実行に加えて、拡張プロダクションプロセッサはまた、タイプ毎ベースでユーザ定義フィールド拡張規則の入力を支援する。ここでの目標は、プロセッサが多次元にわたってフィールド値を拡張すると同時に広げることができるようにすることである。例えば、ユーザは一組のジョブ定義の拡張を望むかもしれない。しかしながら、各新しいジョブ定義は、そのスケジュールされた開始時間が、元のスケジュールされた開始時間から一定量だけインクリメントされることを必要するかもしれない。フィールド拡張規則を規定する1つのやり方はプロダクション内にDML関数を埋め込むことによるものである。図17Hに示すリスト1716内に示す例示的DML関数は、ジョブに対してスケジュールされた開始時間を除いたすべての場合のディフォルト規則とジョブ定義依存性に関するGUIDフィールドとを出力するカスタム拡張規則生成器を示す。第1の場合、上記関数は、新しいレコードのスケジュールされた開始時間に現在の拡張指標値に対応する第2の数を加える規則を構築する。この規則により、新しいジョブは、拡張のサイズに対応する秒数にわたって均一に分散されたインクリメントされた開始時間を得る。GUIDの場合、上記関数は、GUIDがあたかも外部キー参照であるかのように振る舞うことになるのでプロダクションプロセッサのキー生成関数を呼び出す。この関数を呼び出した結果として、規則は、拡張されたソーステーブル内のGUIDに割り当てられたように、同じ拡張されたキー値をGUID値に割り当てることになる。関数getExpandedKeyRuleは、拡張プロダクションプロセッサにより支援されるシステム関数の1つである。いくつかの子データセットタイプは、ソースとしての包含から明示的に阻止されることができる。いくつかの拡張は、拡張処理から除外するためにユーザが子を規定できることを必要とする。例えば、ジョブスケジューリングアプリケーションに関連するconspecに関し、ユーザは、前日に実行したジョブの集合を既に有するかもしれないジョブ定義の拡張を望むかもしれない。ユーザはジョブ定義の拡張を望むかもしれないが、ジョブの拡張を望まないかもしれない。子オブジェクトのオプション除外を支援するために、ツールは、除外すべき子のリストを宣言するための入力パラメータを受け付けてもよい。ソースは、拡張から明示的に除外されることができるが、子を再帰的にトラバースするために依然として使用されることができる。いくつかの拡張は、テーブルがソースとして選択されることを必要とするかもしれなく、さらに、このテーブルからオブジェクトがフィルタリングされることを必要とするかもしれない。加えて、拡張は、子オブジェクトの選択肢を狭めるために、フィルタリングされた選択肢が使用されることを必要とするかもしれない。同時に、ユーザはソース親オブジェクトの拡張を望まないかもしれないが、その代りに、選択された子オブジェクトの組の拡張だけを望むかもしれない。この場合、ユーザは子の選択肢を狭める手段としてソースを規定するが、このときソースを拡張すなわち選択されたオブジェクトの複製から除外する。例えば、ジョブスケジューリングアプリケーションに関連するconspecに関し、ユーザは、その名前がストリングCanadaで始まるジョブ定義に関連するジョブの拡張を望むかもしれない。ユーザは、ソースとなるためのジョブ定義を規定し、ソース選択肢からその子のすべてを明示的に除外するだろうジョブを除いて。ユーザは、ジョブ定義の選択フィルタを規定するだろう。最後に、ユーザはジョブ定義を拡張から除外することを規定するであろうこの手法は、いくつかのタイプがフィルタリングと子検出のソースとして関与できるようにするだけでなく、また拡張処理から除外できるようにする。修正マスキングとも呼ばれるは、レコードの1つまたは複数のフィールド内の値を置換する処理である。ある場合には、フィールドのグループは、レコード内の一貫性制約を維持するために一斉に操作され市と郵便番号などで、一方、他のケースでは、データセット全体にわたるフィールド値が参照整合性を維持するために一斉に操作される。以下の章では、一般的マスキングプロダクションプロセッサにより支援されてよい様々な種類のプロダクション規則の概要について説明する。シャッフリングアルゴリズムは、データセット内の他のレコードからの値を使用して1つまたは複数のフィールド内の値を交換する。新しい値の選択はキーまたはルックアップベースマッピング機能のいずれかにより駆動されてよい下記参照。このアルゴリズムもまた元データ内の値の度数分布を維持するか、あるいはマスク値のフラット分布を生成してもよい。マスキングプロダクションプロセッサはまた、マルチフィールドシャッフリングを支援し、これにより1つのレコードからのいくつかのブロックのフィールド値が別のレコードからの対応値の間でシャッフルされる。これは、男性および女性名が論理的タイトルと性別に関連付けられることと、郵便番号が有効な市と州に関連付けられることと、を保証するのに特に有用である。置換アルゴリズムは外部の仮想値供給元から値を選択する。シャッフリングとは異なり、元値は使用されなく、これにより特定値が元データ内に存在するどのレコードかにかかわらずかどうかを隠すことを可能にする。生成アルゴリズムは、特定タイプのフィールド用に設計されたドメイン専用式を使用する。クレジットカード、社会保険、電話、日付、電子メールなどのフィールドタイプの標準式が存在する。加えて、式は、ランダム化が値の一部に対して使用される場合にチェックサムを導出するために使用されてもよい。暗号は、元の値を解読する能力を有する直接的マスキング手段を提供する。暗号値は、アプリケーションをパススルーするかもしれないが、通常は、いくつかのタイプのフィールドの有効データとしてパスすることはない。ランダム化アルゴリズムはランダムな文字列および/または数列を生成する。これは反復可能または反復不能なやり方で行うことができる。すなわち、ユーザは同じソースストリングを同じマスクされたストリングに常にマッピングすることを選択してもよい。オフセットアルゴリズムは、許容出力範囲内の入力値を変換する。この手法は、日付、量、通貨などのフィールドを、所望のグローバル特徴を維持する少量だけ変更するために使用されてもよい。例えば、ユーザは顧客間で大きなトランザクション値対小さなトランザクション値のパターンを維持してもよいが、値を少しだけ変更してもよい。別の例では、ユーザは全体の年令分布を維持しながら年令を変更してもよい。スクラブアルゴリズムはフィールドを、あるいは共通値またはヌル値を有するその内容の一部を、取り除く。カスタム機能が特定フィールドに関連付けられてよく、これらの機能はマスキングされたレコードから1つまたは複数のフィールドにアクセスしてもよい。マスキングプロダクションプロセッサは、ルックアップ指標を導出するために暗号的にセキュアなハッシングアルゴリズムまたは偽似乱数置換関数を使用してもよい。マスクされた値に指標をマッピングするルックアップテーブルは、指標を導出するために使用されるキーがその代りにセキュアにされるので、維持される必要はない。暗号ハッシングが、無限領域データに、または名前とアドレスなどの不均等分布を有するデータに、十分に適用される。擬似乱数的交換は、一定のドメインデータ、またはIDなどの均等分布を有するデータに対し十分に適用される。マスキングプロダクションプロセッサは各入力値のマスクされた値を導出するためにハッシングまたは置換関数を使用してもよく、次に、元値からマスクされた値へのマッピングをセキュアなルックアップテーブルに格納する。このテーブルは、マスクされた値とマスクされない値間のマッピングを明示的に維持するので、セキュアな環境において維持される必要がある。他のプロダクションプロセッサ関数は処理の方向例えば、親から子または子から親を含むことができる。conspecは多くの相互依存データセットを含むので、プロダクションのコア機能の1つはデータセットインスタンスを処理する順序を決定することである。プロダクションに規定された規則に依存して、プロダクションプロセッサは親を最初に続いて子を再帰的に処理する、あるいは子を最初に続いて親を再帰的に処理する必要があるかもしれない。前章では、プロダクションは、選択された親に依存して子だけで終わるために顧客を最初に次に親を選択することを要求した。別のシナリオでは、ユーザは、値Xより大きな値の高いドル金額トランザクションを選択し、これらのトランザクションをバックアップする必要がある顧客だけで終わることを規定してもよいであろう。この場合、プロセッサは子を最初に処理し続いて親を処理しなければならないであろう。プロセッサは、正しい処理順序を検出し必要に応じそれを適用する能力を有する。時には、ユーザは、ソースとしてデータセットのサブセットを規定することにより処理の範囲を狭めることを望む。加えて、ユーザは、親または子として包含するためにいくつかのデータセットを明示的に除外することを望むかもしれない。処理順を決定するための一般的関数は引数としてこれらのパラメータを受け付けなければならない。主キー割り当ては、プロダクション全体にわたる識別子IDの競合を回避するための技術である。プロダクションは、データセットインスタンス内に新しいレコードを最初からまたは複製によりのいずれかで生成してもよい。これらの新しいレコードはしばしば新しいIDを必要とすることになるので、プロダクションは新しいID値が既存のID値と競合しないことを保証する。加えて、プロダクションは、1回の実行内に生成するID値がその後の実行内に生成するかもしれないID値と競合しないことを保証する。プロダクションの各実行に対し一意的なネームスペース内にIDが入ることを保証する多くのやり方がある。以下は、複数の実行にわたってだけでなく1つの実行内においても競合しない数値的IDを生成するための手法の例である。数値的主キーに関しては、プロダクションはデータセットインスタンス内の主キーフィールドの現在の最小および最大値を計算することで始まってよい。図15では、現在の範囲1502は陰影を付けられて示される。例えば、プロダクションは、既存レコードのそれぞれをN回複製する規則を有する。任意のレコードを複製する前に、プロダクションは、新しいレコードを保持するために、未使用IDのN個の新しい範囲の組を論理的に編制するまたは取っておく必要がある。次に、既存レコードのそれぞれのN個の新しいレコードのそれぞれはN個の範囲の1つからのID値を割り当てられるだろう。従って例えば、キーの既存指標値が321であれば、プロダクションは、321に対してN個の新しいレコードを生成し、これらには1205,2089,...,321884×NのID値が与えられるだろう。換言すれば、各新しいレコードは以下に示す青色範囲バケットの1つにダンプされるだろう。同様に、ID322を有する第2のレコードに関しては、プロダクションは1206,2090,...,322884×Nの値を有するN個の新しいオブジェクトを生成するだろう。GUIDなどの非数値的キーフィールドに関しては、プロダクションは最初に、実行の初めに一意的なRANDOMRUNSEEDを生成し、このキーと拡張指数とを各GUIDに追加してもよい。プロダクションが再び実行されると、プロダクションは、キーがプロダクションの複数階層実行にわたって一意的であることを保証するであろう異なるランダムシードを使用するだろう。図17Iに示すリスト1718は、ジョブスケジューリングアプリケーションに関連するconspecに関する、拡張ジョブレコードに新しいGUIDを割り当てるために生成された変換規則の例である。pNはRANDOMRUNSEEDの値である。拡張キー生成のためのこれらの手法はプロダクションの実行全体にわたって一意性を保証する。これにより、ユーザはプロダクションを複数回実行できるようになるか、あるいは異なるタイプのプロダクションを連鎖できるようにする。上に説明されたデータセット処理技術は、コンピュータ上で実行されるソフトウェアを使用して実施することができる。例えば、ソフトウェアは、それぞれが少なくとも1つのプロセッサ、少なくとも1つのデータ記憶システム揮発性および不揮発性メモリおよび/または記憶素子を含む、少なくとも1つの入力装置またはポート、および少なくとも1つの出力装置またはポートを含む1つまたは複数のプログラムされたまたはプログラム可能なコンピュータシステム分散型、クライアント/サーバーまたはグリッドなどの様々なアーキテクチャであってよい上で実行する1つまたは複数のコンピュータプログラム内の手順を形成する。例えば、ソフトウェアは、データフローグラフの設計と構成に関係する他のサービスを提供するより大きなプログラムの1つまたは複数のモジュールを形成してもよい。グラフのノードと要素は、データレポジトリに格納されたデータモデルに準拠するコンピュータ可読媒体または他の編成データ内に格納されたデータ構造として実施することができる。ソフトウェアは、汎用または専用プログラム可能コンピュータにより読み出し可能なCD-ROMなどの記憶媒体上に提供されてもよいし、あるいはネットワークの通信媒体上で、ソフトウェアが実行されるコンピュータに配送されてもよい伝播信号に符号化されてもよい。機能のすべては、専用コンピュータ上で、またはコプロセサなどの専用ハードウェアを使用することより、実行されてもよい。ソフトウェアは、ソフトウェアにより規定された計算の異なる部分が異なるコンピュータにより実行される分散的やり方で実施されてもよい。このような各コンピュータプログラムは、記憶媒体または装置が本明細書に記載の手順を実行するためにコンピュータシステムにより読み取られるとコンピュータを構成し動作させる汎用または専用のプログラム可能コンピュータにより読出し可能な記憶媒体または装置例えば、固体メモリまたは媒体、あるいは磁気または光学的媒体上に格納されるあるいはそれにダウンロードされることが好ましい。本発明のシステムはまた、コンピュータプログラムにより構成されたコンピュータ可読記憶媒体として実施されると考えてもよい。ここでは、そのように構成された記憶媒体は本明細書に記載の機能を実行するために特定および所定のやり方でコンピュータシステムを動作させる。本発明の多くの実施形態が説明された。それにもかかわらず、本発明の精神及び範囲を逸脱することなく他の様々な変更が可能であることが理解されるであろう。例えば、上に記載された工程のいくつかは、順序に無関係であってもよく、したがって記載されたものと異なる順序で実行することができる。これまでの説明は、例証することを意図していること、そして添付の請求項の範囲により定義される本発明の範囲を制限しないように意図されていることと、を理解すべきである。例えば、上に記載された多くの機能工程は、全体処理に実質的に影響を与えることなく異なる順序で実行されてもよい。他の実施形態は以下の特許請求範囲に含まれる。"