JP5963845B2 - 一時的なデータウェアハウスにデータをロードするための方法およびシステム - Google Patents

Description

本開示の分野は一般的にコンピュータデータウェアハウス（ＣＤＷ）に関し、より具体的には、一時的に正規化されたデータウェアハウスのメタデータ駆動型データキャプチャの方法およびシステムに関する。

シーケンシャルな方法に頼ることなく単一の汎用設計で入力データの迅速なロードおよびタイムシーケンス変化ボリュームへの必要性が存在する。シーケンシャルな方法は一般的に初期化のためおよびより高いボリューム入力データイベントで使用するためには効率的な手段ではない。さらに、データ内の変更を検出する集中的前処理を時には低減するおよび／またはインターフェースタイプに関係なくすべての目標テーブルの候補行のロードセットの作成を可能にするために一意の有効期間を保証する必要がある。最後に、データストレージに関連するコストのため、すべてのタイプのデータの変更を識別し、新たなオーサリングタイムスタンプ（有効期間）を超える新たなコンテンツがない新たなデータ行のロードを避ける必要性がある。このような行為は期間内のデータの連続する重複行を折り畳むことによりストレージの使用量を減らすのを助けるかもしれない。

現在、大規模な外部のアプリケーションサーバ上で典型的に実行されている複雑なカスタムデータロードプログラムは一時的なデータウェアハウスをロードするための試みで実装されている解決策である。このようなプログラムは主キーにより順次にデータを処理および適用し、結果として長い実行時間および目標テーブルへの広範な相対的に邪魔なアップデートになることがある。いくつかの例では、ユーザを継続的にサポートするため、ローディングが完了したときに目標テーブルの２つのセットが使用されスワップされる。しかしながら、このようなシステムでは、典型的にデータベース内の一部のデータが既に削除され、入力データと共にアプリケーションサーバ上で外部的に処理され、ネットワークおよびデータベースをさらに強調するデータロードを達成するために再ロードされる。他の既知の既存の解決策はまた、予期しない場合ロードを止める、中止する、またはデータを拒否するすべての可能性のある状況ではなく所期の状況のみに適応する傾向がある（例えば、主キー内の有効期間関係）。

その他の熟考された解決策は一般的に他の欠点を有している。例えば、入力データおよび正確な目標スキーマの特定のタイプを受け入れるようにハードコーディングされている設計は開発コストのために望ましくない。さらに、メンテナンスコストはデータソース、データ目標、またはインターフェースの方法への主キーまたは属性変更を扱う際に懸念事項となるかもしれない。サーバ上のデータベースの外部作業を実行する抽出（ｅｘｔｒａｃｔ）、変換（ｔｒａｎｓｆｏｒｍ）、およびロード（ｌｏａｄ）（ＥＴＬ）ツールの使用は一つの可能な解決策であるが、非効率的でありネットワークトラフィックの量により影響を受けることがある。データウェアハウスで広く使用される超並列処理（ＭＰＰ）アーキテクチャ上での外部または行毎（ｒｏｗ−ａｔ−ａ−ｔｉｍｅ）解決策を使用する際に熟考された解決策の効率性の損失が特に大きい。また、独自のデータベースツールは専門的な知識を必要とし、他のプラットフォーム（例えば、ＯｒａｃｌｅのＰＬ／ＳＱＬ）に移植できない。これらの解決策は、準リアルタイム、非侵入型のロードを不可能にし、初期化のための異なるコーディングまたは許容可能なパフォーマンスを実現するためのデータの大容量ボリュームを必要とするかもしれない、データのより大容量ボリュームに対して非効率的である。

一態様では、一時的なデータウェアハウス内に入力データセットをロードするのに使用するためのシステムが提供される。システムはストレージ装置およびストレージ装置に結合されたプロセッサユニットを含む。ストレージ装置は一時的なデータウェアハウスおよび入力データセットを含む。プロセッサユニットは入力データセットを第１のパーティションおよび第２のパーティションを含む複数のパーティションに分割するようにプログラムされる。複数のパーティションの各パーティションは複数のデータレコードを含む。プロセッサはまた第１のパーティションをプリロードテーブルにインポートし、第２のパーティションをプリロードテーブルにインポートし、プリロードテーブルを一時的なデータウェアハウスに適用するようにプログラムされる。

別の態様では、一時的なデータウェアハウスに複数のデータレコードをロードするのに使用するための方法が提供される。この方法は、コンピューティング装置により、データレコードを第１のパーティションおよび第２のパーティションを含む複数のパーティションに分割することを含む。第１のパーティションおよび第２のパーティションはコンピューティング装置によりプリロードテーブルにインポートされる。プリロードテーブルはコンピューティング装置により一時的なデータウェアハウスに適用される。

さらに別の態様では、コンピュータプログラム製品が提供される。コンピュータプログラム製品はネット変更データ（正味の変更データ）とともにデータウェアハウスをロードするための具現化されたコンピュータ実行可能命令をその上に有する非一時的なコンピュータ可読媒体を含む。少なくとも１つのプロセッサにより実行される場合、コンピュータ実行可能命令はプロセッサが入力データセットを第１のパーティションおよび第２のパーティションを含む複数のパーティションに分割するようにさせる。複数のパーティションの各パーティションは複数のデータレコードを含む。コンピュータ実行可能命令はまたプロセッサが第１のパーティションをプリロードテーブルにインポートし、第２のパーティションをプリロードテーブルにインポートし、プリロードテーブルをデータウェアハウスに適用するようにさせる。

コンピュータシステムの簡略化したブロック図である。 コンピュータネットワークのブロック図である。 例示的な変更データキャプチャプロセスを示すフローチャートである。 例示的なパーティションロードプロセスを示すフローチャートである。 例示的なデータアプリケーションプロセスを示すフローチャートである。 図４に示すステップ１００に関連付けられたデータフロー図である。 図４に示すステップ１０１に関連付けられたデータフロー図である。 図４に示すステップ１０２に関連付けられたデータフロー図である。 図４に示すステップ１０３に関連付けられたデータフロー図である。 図４に示すステップ１０４に関連付けられたデータフロー図である。 図４に示すステップ１０５に関連付けられたデータフロー図である。 図４に示すステップ１０６に関連付けられたデータフロー図である。 図４に示すステップ１０７に関連付けられたデータフロー図である。 図４に示すステップ１０８に関連付けられたデータフロー図である。 図４に示すステップ１０９に関連付けられたデータフロー図である。 図４に示すステップ１１０に関連付けられたデータフロー図である。 図４に示すステップ１１１に関連付けられたデータフロー図である。 図４に示すステップ１１２に関連付けられたデータフロー図である。 図５に示す適用ステップ２０２に関連付けられたデータフロー図である。 図５に示す適用ステップ２０３に関連付けられたデータフロー図である。 図５に示す適用ステップ２０４に関連付けられたデータフロー図である。 図５に示す適用ステップ２０５に関連付けられたデータフロー図である。 図５に示す適用ステップ２０６に関連付けられたデータフロー図である。 例示的なコンピューティング装置のブロック図である。

実施形態は変更データキャプチャ（ＣＤＣ）プロセスを参照して本明細書に記述されている。本明細書で使用するとき、用語「ＣＤＣ」は一時的なデータウェアハウスへの変更をキャプチャし適用するプロセスを指す。ＣＤＣプロセスへの入力、入力データセットは目標ウェアハウス（例えば、正規化された、ビジネスまたは自然キー）のデータモデルと一致するように既に変換されていてもよいが、タイムシーケンス、一時的な正規化および／または一時的な衝突を解決することなどのような一時的な処理なしでもよい。入力データセットはＣＤＣプロセスにより直接アクセス可能であるように、データベースシステムに既にロードされていてもよい。

本開示は、コンピュータまたはパーソナルデータアシスタントまたは他のハンドヘルド装置のような他の機械により実行されるプログラムモジュールなどのコンピュータ実行可能命令を含む、コンピュータコードまたは機械使用可能な命令の一般的なコンテキストで説明されてもよい。一般的には、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含むプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するコードを指す。本開示は、ハンドヘルド機器、民生用電子機器、汎用コンピュータ、より専門的なコンピューティング装置などを含む様々なシステム構成で実施されてもよい。本開示はまた通信ネットワークを介してリンクされるリモート処理装置によりタスクが実行される分散コンピューティング環境で実施されてもよい。

説明されるシステムは、それ自体および演算子のリレーショナル代数セットを使用して、データウェアハウス内に既に格納されたデータと比較するように、ネット変更データを識別しシーケンスする既存のデータウェアハウスに関して、入力データセットと呼ばれてもよい、入力データのセットを解析することが動作可能であり、データウェアハウスへのアップデートを適用する。入力データセットはソースデータベース（例えば、ある時点でのソースデータベース内のすべてのデータレコード）のスナップショットを表していてもよい複数のデータレコードおよび／またはソースデータベースに対して実行された複数のメッセージまたはトランザクション（例えば、挿入（ｉｎｓｅｒｔｓ）、アップデート（ｕｐｄａｔｅｓ）、および／または削除（ｄｅｌｅｔｅｓ））を含む。

構造化照会言語（ＳＱＬ）コードのような、データウェアハウスに対応するこのような方法、ソフトウェアコードを達成することが、本明細書に記述されたソフトウェアがビルドされる（例えば、コンパイルされる）際、ソフトウェアが展開される際、および／またはメタデータ（例えば、データベース構造）が改訂される際に、生成されてもよい。生成されたコードは次にデータがデータウェアハウスにロードされるたび毎にシステムにより実行されてもよい。いくつかの実施形態では、生成されたコードは１つ以上のストアドプロシージャ（例えば、データベース内に格納されこれにより実行される機能コード）により生成され、生成されたコードをデータベース内に格納する。データのロード中に、入力データに対して生成されたステートメントが取り出され実行される。

データウェアハウスに入力データをロードするプロセスの実行時間および／またはコンピューティングリソースの使用率などのような性能は、１つ以上の最適化オプションを使用して改善されてもよい。コンピューティングリソースの使用率は、限定はされないが、プロセッサ使用率、メモリ使用率、および／またはネットワーク使用率を含んでいてもよい。最適化オプションは、例えば入力データを分割することおよび各パーティションを別々に処理すること、目標テーブルにデータを適用する前に揮発性テーブルへの入力データをインポートすること、入力データへの必要がないときに目標テーブルの比較から履歴をフィルタリングすることおよびデータを一時的に正規化する方法を含む。

本明細書に記述の実施形態はデータロードコードを作成するＳＱＬコードジェネレータを含む一般的なメタデータ駆動型の一時的なデータウェアハウスのロードの設計に関連する。実行時に、データロードコードは、有効期間と同等のものを生成するためにすべてのテーブルの主キー内の有効な開始タイムスタンプを有することに基づく一時的なデザインへのネット変更情報を識別することおよびシーケンスすることおよびｓｅｔ−ＳＱＬステートメントのみを使用して対応する有効な終了タイムスタンプまたは同等の期間の事前設定をする、ソースシステムデータの任意のボリューム（初期ロード、移行、毎日、毎時）および任意のタイプ（プッシュまたはプル、新しいまたは古いデータ）を効率的に処理し正規化された一時的なデータウェアハウスにロードすることができる。このようなプロセスは時として一括して変更データキャプチャ（ＣＤＣ）と呼ばれる。

開示した一時的なデータウェアハウスのロード設計はネット変更を決定するためにそれ自体に関するおよび既存のデータウェアハウスに関する両方の入力データのセットを解析することにより動作する。適切で有効なタイムシーケンス（一時的設計）は次にＡＮＳＩ ＳＱＬのみを使用して目標データウェアハウス内での期間を定義する終了タイムスタンプへの新しいシーケンス行およびアップデートに割り当てられ効率的に適用される。このプロセスはＳＱＬステートメント（例えば、挿入および一時的アップデート）を事前生成し、データをロードする際に、データウェアハウスデータベース内全体でＳＱＬを取得し実行する。

本明細書に記述の実施形態の例示的な技術的効果は、これらには限定されないが、（ａ）入力データセットを第１のパーティションおよび第２パーティションを含む複数のパーティションに分割することであり、複数のパーティションの各パーティションは複数のデータレコードを含み、（ｂ）ハッシュ関数およびパーティションの所定量に基づいて入力データセットを分割すること、（ｃ）順次または並列に（例えば、同時に）、第１のパーティションおよび第２のパーティションをプリロードテーブルにインポートすること、（ｄ）プリロードテーブルを一時的なデータウェアハウスに適用すること、（ｅ）パーティションを対応する揮発性テーブルにインポートすること、（ｆ）パーティションを揮発性テーブルからプリロードテーブルにコピーすること、（ｇ）以前にインポートされたデータレコードの非キーフィールドに等しいタイムスタンプ以外の複数のフィールドを含む、第１のパーティション内のデータレコードを識別すること、（ｈ）第１のパーティションをプリロードテーブルにインポートする際に識別されたレコードを除外すること、（ｉ）一時的なデータウェアハウス内のアクティブデータレコードが入力データセット内のデータレコードに関連付けられていないことを検出することに基づいて、アクティブデータレコードの暗示的削除を実行すること、（ｊ）入力データセット内の第１のデータレコードに関連付けられた最先のソースタイムスタンプを決定すること、（ｋ）最先のソースタイムスタンプの直前のソースタイムスタンプに関連付けられた一時的なデータウェアハウス内のデータレコードを表す主キーのセットおよび最先のソースタイムスタンプよりも後のソースタイムスタンプに関連付けられている一時的なデータウェアハウス内の１つ以上のデータレコードを識別すること、および（ｌ）主キーの識別されたセットに基づいて第１のパーティションおよび第２のパーティションをインポートすること、を含んでいてもよい。

実施形態は材料の明細に関する情報（部品表）および／または部品（例えば、機械設備の部品）に関する情報を格納するデータウェアハウスなどのような特定の用途を参照して以下に説明されてもよい。そのような実施形態は任意の一時的なデータウェアハウスに適用可能であることが予期される。

図１は、サーバシステム１２、およびサーバシステム１２に接続されたクライアントシステム１４とも呼ばれる、複数のクライアントサブシステムを含む例示的なシステム１０の簡略化されたブロック図である。以下でより詳細に説明される、コンピュータ化されたモデリングおよびグルーピングツールは、サーバシステム１２に格納され、クライアントシステム１４（例えば、コンピュータ）のいずれかにおいてリクエスタによりアクセスすることができる。図１に示すように、クライアントシステムは、サーバシステム１２がインターネットを使用してクライアントシステム１４にアクセス可能であるように、ウェブブラウザを含むコンピュータ１４である。クライアントシステム１４は、ローカルエリアネットワーク（ＬＡＮ）またはワイドエリアネットワーク（ＷＡＮ）、ダイヤルイン接続、ケーブルモデム、および特殊高速ＩＳＤＮ回線等のネットワークを含む多くのインターフェースを介してインターネットに相互接続される。クライアントシステム１４は、ウェブベースの電話、パーソナルデジタルアシスタント（ＰＤＡ）、または他のウェブベースの接続可能な機器を含むインターネットに相互接続することができる任意の装置とすることができる。以下でより詳細に説明するように、データベースサーバ１６は事項の様々な情報を含むデータベース２０に接続される。一実施形態では、集中型データベース２０はサーバシステム１２に格納され、クライアントシステム１４のいずれかを介してサーバシステム１２にログオンすることによりクライアントシステム１４のいずれかのポテンシャルユーザによりアクセスすることができる。代替実施形態では、データベース２０はサーバシステム１２からリモートに格納され非集中型であってもよい。

図２は、システム２２の例示的な実施形態の拡張ブロック図である。システム２２は適切なコンピューティング環境の一例であるが、本発明の使用または機能の範囲に関するいかなる限定を示唆するものではない。システム２２は本明細書に示される構成要素のいずれか１つまたは組合せに関する依存性または要件のどちらをも有すると解釈されるべきではない。システム１０の構成要素（図１参照）と同一の、システム２２内の構成要素は図１で使用される同じ符号を使用して図２で識別される。システム２２はサーバシステム１２およびクライアントシステム１４を含む。サーバシステム１２は、データベースサーバ１６、アプリケーションサーバ２４、ウェブサーバ２６、ファックスサーバ２８、ディレクトリサーバ３０、およびメールサーバ３２をさらに含む。ディスクストレージユニット３４（データベース２０を含む）はデータベースサーバ１６およびディレクトリサーバ３０に結合される。サーバ１６、２４、２６、２８、３０、および３２はローカルエリアネットワーク（ＬＡＮ）３６に結合される。さらに、システム管理者のワークステーション３８、ユーザワークステーション４０、およびスーパーバイザのワークステーション４２はＬＡＮ３６に接続される。代替的に、ワークステーション３８、４０、および４２は、インターネットリンクを使用してＬＡＮ３６に結合されるか、またはイントラネットを介して接続される。いくつかの実施形態では、データベースサーバ１６はディレクトリサーバ３０などのような他の装置にアクセスできないディスクストレージユニット３４に結合される。

各ワークステーション３８、４０、および４２はウェブブラウザを有するパーソナルコンピュータである。ワークステーションで実行される機能は典型的にはそれぞれのステーション３８、４０、および４２で実行されるものとして示されているが、そのような機能はＬＡＮ３６に結合された多数のパーソナルコンピュータのいずれかで行うことができる。ワークステーション３８、４０、および４２はＬＡＮ３６へのアクセスを有する個々により実行することができる異なったタイプの機能の理解をただ容易にするために別々の機能に関連するものとして示されている。

サーバシステム１２は社員４４を含む様々な個々人およびインターネットサービスプロバイダ（ＩＳＰ）のインターネット接続４８を使用する第三者、例えば顧客／請負業者４６に通信可能に結合されるように構成される。例示的な実施形態における通信はインターネットを使用して実行されるものとして示されているが、任意の他のワイドエリアネットワーク（ＷＡＮ）タイプの通信が他の実施形態で利用することができ、すなわちシステムおよびプロセスはインターネットを使用して実施されることに限定されない。加えて、ＷＡＮ５０というよりも、ローカルエリアネットワーク３６をＷＡＮ５０の代わりに使用することができる。

例示的な実施形態では、ワークステーション５４を有する任意の許可された個々人はシステム２２にアクセスすることができる。クライアントシステムのうち少なくとも１つはリモートロケーションに配置されたマネージャワークステーション５６を含む。ワークステーション５４および５６はウェブブラウザを有するパーソナルコンピュータである。また、ワークステーション５４および５６はサーバシステム１２と通信するように構成される。さらに、ファックスサーバ２８は電話リンクを使用してワークステーション５６を含む遠くに位置するクライアントシステムと通信する。ファックスサーバ２８は他のクライアントシステムおよび／またはワークステーション３８、４０、および４２とも同様に通信するように構成されている。

図１および図２のシステムを利用して、非常に効率的で比較的非侵入性の準リアルタイムロードはユーザのクエリを中断することなくスケジュールされたミニバッチ実行を介して有効になっている。プロセスは標準ＡＮＳＩ ＳＱＬに基づいており、したがって、特に超並列処理（ＭＰＰ）アーキテクチャ上で、データベース管理システム（ＤＢＭＳ）能力に効力を発揮し、超線形スケーラビリティを提供する、任意のデータベースプラットフォームに適用可能であり、外部サーバ上でデータ処理を必要としない（例えば、ＳＱＬはどこからでも呼び出すことができる）。一実施形態では、データウェアハウスのロードは完全に主キー定義の使用を通じた実行時のメタデータ駆動型およびパラメータとしてテーブル名である。もう一つの利点はスキーマの変更は変更データキャプチャシステムの再コンパイルまたは再起動を必要としないことであり、運用メタデータは任意のとき間に変更されてもよい（例えば、明示的または暗示的な削除フォーム、パーティションの量、および／または並列度のレベル）。そうでなければ、任意のインターフェースタイプに適応することができ、データモデル（有効時間はすべての主キーに含まれる）内のすべてのテーブルは単一のプログラムを適応することができる。候補行のみが入力（列＋有効なタイムスタンプ）として要求され、どちらかといえば、何が変更されたのかの識別は変更データキャプチャシステムへの入力として必要ない。スナップショットインターフェースの場合は、削除の識別は必要ない。有効時間の関係はデータセットおよび複数の呼び出し内でおよびその全体に渡って非常に短いシーケンス時間で主キー内で壊れている可能性がある。遡及的および／または履歴的アップデートは入力および既存データの両方のとき間シーケンシングをアップデートすることにより実行される。

既存の解決策がしばしばインターフェースタイプに合わせてカスタマイズされており、典型的には完全に各テーブルの列毎にハードコードされているため、上記の改善は既存の解決策に関して実現される。加えて、一時的なシーケンシングへの既存のアプローチは単一の行毎であり、ｓｅｔ−ＳＱＬ（例えば、集合演算子のリレーショナル代数を使用）を介してひとまとめではない。したがってこれらの解決策は変更データキャプチャシステムが行うように超直線的にスケーリングしない。例えば、本明細書に説明の実施形態は１００行を処理するのに必要な時間の１０倍未満で１，０００行を処理してもよい。例示的な実施形態では、処理中のデータベースからデータは除去されず、変更データキャプチャシステムの呼び出し形式は外部（例えば、Ｐｅｒｌ）または内部データベース手続きであり得る。

説明される実施形態は識別変更（例えば、挿入、アップデート、削除、再表示、および／または履歴アップデート）および開始−終了の有効なタイムスタンプにより定義された期間を介して履歴を保持する一時的なデータウェアハウスへの適用変更に関連付けられた開発コストを削減することおよび潜在的に排除することを容易にする。非効率的なカーソル（行毎）、外部データロードサーバを使用し関連するネットワークトラフィックを生成する既存の解決策とは異なる、ＤＢＭＳエンジンおよびｓｅｔ−ＳＱＬでのアーキテクチャを活用する、効率的かつ非常にスケーラブルな設計が説明される。最小限の侵入型設計は、エンドユーザのロック方法およびＳＱＬ修飾子を介して一時的履歴の使用を含むが、これらに限定されない様々なクエリ手法を使用して効率を最大化された非常に迅速なｓｅｔ−ＳＱＬ適用トランザクション（ワークロードを最小化しＤＢＭＳ内のスループットを最大化するための最終ステージおよび目標の同じ構造）を介してロード中に連続クエリを可能にする。

本明細書でさらに説明するように、実施形態はデータベースカタログ（例えば、列名および基本データ型情報）および主キーメタデータテーブルに対して問い合わせ（クエリ）することによりデータをロードするためのＳＱＬステートメントを生成し格納するＳＱＬジェネレータのシーケンスとして少なくとも部分的に実装されてもよい。事前に生成されたＳＱＬは入力データに対して実行時に実行されてもよい。下記に説明されるステップのシーケンスは目標データベース内の候補行を単一の効率的なトランザクションで解析し、準備し、適用する。これらのステップはデータベースに対するＳＱＬジェネレータを実行するためのアクセス権を持つ任意のプログラミング、スクリプトまたはプロシージャ言語で実装することができ、データベースに対する結果のＳＱＬステートメントをフェッチし、フェッチされたステートメントを実行する。

以下は本明細書で使用される特定の用語および略語の定義を含む。オンライントランザクション処理（ＯＬＴＰ）データベースは正規化されたデータベース構造を典型的に含むトランザクションベースのデータベースである。例えば、ＯＬＴＰのデータレコード（例えば、テーブル内の行）はその参照されるデータレコード内のデータのコピーとは対照的に、別のデータレコード（例えば、別のテーブル内の行）への参照を含んでいてもよい。さらに、ＯＬＴＰデータベースはこのような参照が有効であることを保証するために参照整合性を強制してもよい（例えば、現存するデータレコードおよび／または特定のタイプのデータレコードを参照する）。

主キー（ＰＫ）は目標テーブル（例えば、コアテーブル、非コアテーブル、または派生層）のデータモデリングツールで定義されている完全な主キーである。本明細書で使用するとき、「非コア」テーブルとは目標データベース層として本明細書に示される正規化された一時的な目標テーブルである。ＰＫはＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ（データベースビューＣＤＷ＿ＰＫ＿ＣＯＬＳ＿Ｖで利用可能）と呼ばれるソースシステム開始タイムスタンプ列を含み、履歴の保持をサポートする。ソースタイムスタンプは多くのシステムでそれを作成し作成または最後の修正のタイムスタンプと呼ばれることもあるオーサリングシステムの行の有効期間の開始を表す。一時的なデータウェアハウスの有効期間は、このケースではＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳの包括的およびＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳの排他的期間を表すタイムスタンプの対（例えば、開始タイムスタンプおよび終了タイムスタンプ）として表されてもよい。

ＰＫ＿ＬａｔｅｓｔはＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳを除く主キーであり、典型的にオンライントランザクション処理システムのビジネスキー（データベースビューＣＤＷ＿ＰＫ＿ＣＯＬＳ＿ＬＡＴＥＳＴ＿Ｖで利用可能）である。

Ｗ＿ｔａｂｌｅは入力データセット変換の目標である。例示的な実施形態では、Ｗ＿ｔａｂｌｅは両方の一時的な期間を表す標準の開始終了タイムスタンプの２組は省略されるが、ＳＲＣ＿ＳＴＡＲＴ＿ＴＳと名称付けられる現在のソースシステムタイムスタンプとともに非コアテーブルのコピーを含む。オプションのＡＬＬ＿ＶＴ（以下でより詳細に説明する）がＹに設定されている際に、Ｗ＿ｔａｂｌｅの揮発性コピーを使用してもよい。

Ｘ＿ｔａｂｌｅは目標テーブルにロードされたすべての行のソースのプリロードテーブルである。Ｘ＿ｔａｂｌｅは割り当てアクション（ＥＴＬインジケータ）およびソース（ｓｏｕｒｃｅ）の代わりにｓｒｃとして名称付けられた２つのソースタイムスタンプを格納するカラムの追加とともに目標テーブルのコピーであってもよい。

目標はデータウェアハウスの範囲を表す一意の名称付けをされたテーブルを持つ単一のデータベースに対応する１層のコンピュータデータウェアハウスである。非コアは目標の一例である。他の潜在的なデータベーステーブル層はコア（例えば、第３正規形、すなわち３ＮＦで完全に統合された）および派生（例えば、事前結合された、集約された）である。すべてのプロセスは、非コアまたはコアテーブルを潜在的に供給源として派生するデータで、特に明記しない限りこれらの３つの層に適用することができるが、それでもプロセスを呼び出す前にＷ＿ｔａｂｌｅへの入力として提示することができる。オプションＡＬＬ＿ＶＴ（以下でより詳細に説明する）がＹに設定されている際は、目標の揮発性コピーが使用されてもよい。

ＡＬＬ＿ＶＴオプションはシステムが揮発性作業テーブルを使用すべきかどうかを示す。ＡＬＬ＿ＶＴが無効になっている際（例えば、Ｎに設定）には、システムはそれらの目標の対応物に基づいたステージデータベース内に生成された２つの作業テーブル（例えば、Ｗ＿ｔａｂｌｅおよびＸ＿ｔａｂｌｅ）を使用する。第３の揮発性または非永続性テーブルはＷ＿ｔａｂｌｅをロードするために本明細書に記述されたプロセスの実行前に利用されてもよい。目標テーブル毎に、ＣＤＣプロセスによる使用のための入力データセットを変換するために外部で使用される他の任意のテーブルに加えて、ステージング領域データベースにビルドされたこれらのテーブルの３つまでのスクリプトが生成した変異型があってもよい。ＡＬＬ＿ＶＴが有効になっている際（例えば、Ｙに設定）には、これらの揮発性テーブルのコピーが作成される。これらの３つのテーブルはデータベースモデリングツールにより直接モデル化されてはいけない追加のテーブルである。むしろ、それらは、実行時にビルドされる揮発性テーブルを除き、ビルド時にスクリプトによりビルドされ目標ビルドスクリプトに含まれてもよい。

例示的な実施形態では、表１に示すようにスクリプトは各テーブルを作成し名前を指定する。

Ｗ＿ｔａｂｌｅは、明示的な削除を除いて、ＣＤＣシステムを起動する前のすべてのステージ変換のための目標テーブルである。Ｘ＿ｔａｂｌｅはすべての目標データの直接のソースであり、明示的またはカスケード型削除の場合にはＷ＿ｔａｂｌｅまたは潜在的に外部プロセスを経由してのいずれかからロードされる。ＣＤＣシステムの適用フェーズでは本明細書の他の箇所で定義されているようなＩ、Ｏ、Ｕ、ＤのようなＸ＿ｔａｂｌｅ内でＥＴＬインジケータコードを追加するまたは使用する。ＣＤＣシステムに関連するコードはデータをＷ＿ｔａｂｌｅからＸ＿ｔａｂｌｅに移動する際に初期化または設定し、さらに目標データベースへの変更の最終的なアプリケーションを制御する前にＸ＿ｔａｂｌｅ内でアップデートされる。

例示的な実施形態では、ＡＬＬ＿ＶＴが有効になっている際には、スクリプトはＴＮＡＭＥが実際の目標テーブル名に対応する、表２に示すテーブルを作成しアクセスする。

抽出、変換、およびロード（ＥＴＬ）の操作は表３に示すＥＴＬインジケータを使用して呼ばれてもよい。

上記のように、抽出、変換、およびロード（ＥＴＬ）インジケータはＩ、Ｕ、Ｏ、およびＤを含み、各々は既存の行上での新しい目標行のロードまたはタイムスタンプの終了などのような、１つまたは複数の目標非コアテーブルアクションに関連付けられる。ＥＴＬインジケータＩについては、非コアアクションは新しい行の挿入であり、新しい目標行の終了タイムスタンプは取って代わられるまたは論理的に削除されるまでＮＵＬＬ（最新行、有効期間の終了なし）である。ＥＴＬインジケータＵについては、非コアアクションは新しい行の挿入、非コア最新行終了タイムスタンプ（既に有効期間が切れていない場合）のＸ＿ｔａｂｌｅで主キー（ＰＫ）内にある最先のＵ行開始タイムスタンプへのアップデートである。任意の終了タイムスタンプは他のＸ＿ｔａｂｌｅレコードから来る。最新行がＸ＿ｔａｂｌｅでＰＫ内、または次のＸ＿ｔａｂｌｅ行の開始である場合、インジケータＵの新しい目標行終了タイムスタンプはＮＵＬＬである。期間ギャップが明示的に論理的削除を介して設定されるかまたはそうでなければ事前に指定されていない限り、終了タイムスタンプまたは終了期間行が主キー内の後続行の開始タイムスタンプにより暗示される。このようにデフォルトの終了タイムスタンプまたは新しい行の有効期間は「取って代わられるまで」である。

ＥＴＬインジケータＯについては、最新の主キー（ＰＫ＿Ｌａｔｅｓｔ）内で最新の開始タイムスタンプではない、または最新の行ではあるがその開始タイムスタンプが主キー内の最新の有効期間よりも古いという点では、非コアアクションはシーケンスアップデート外にある新しい行の挿入である。いずれの場合も、行はＸ＿ｔａｂｌｅでまたは非コアへのロード後のいずれかで、終了タイムスタンプに関連付けられる（すなわち、事前期限切れである）。インジケータＤ（論理的削除）については、非コアアクションは有効期間内の終了タイムスタンプまたは以前のＸ＿ｔａｂｌｅ（直前の場合）とともに最新の現在の目標テーブル行のアップデートであり、Ｘ＿ｔａｂｌｅ行のその開始タイムスタンプからの終了タイムスタンプの設定である。行は直接ロードしない。インジケータＤの新しい目標行終了タイムスタンプは初期値はＮＵＬＬであり、後でＸ＿ｔａｂｌｅ内でより新しい行に基づいてアップデートされてもよい。

例示的な実施形態では、ＥＴＬ ＣＤＣ処理およびコードジェネレータはステージテーブルに事前設定された主キーメタデータに依存する。２つのビューがＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳを含む完全なデータウェアハウスの主キー、またはＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳを除く、典型的にはＯＬＴＰビジネスキーである、このキーの最新ビューのどちらかを提供するために作成される。加えて、コードジェネレータはデータベース構造を記述する情報（例えば、データベース、テーブル、および／または列）を提供する、標準的なデータベースカタログビューに依存する。唯一のビューとして実装されてもよい最初のビューはＣＤＷ＿ＰＫ＿ＣＯＬＳ＿ＬＡＴＥＳＴ＿Ｖと名称付けられてもよい。ベーステーブル上のビューであってもよい２番目のビューはＣＤＷ＿ＰＫ＿ＣＯＬＳ＿Ｖと名称付けられてもよい。最初のビューおよび２番目のビューの両方はモデリングツール主キーからロードされ、ＤＡＴＡ＿ＬＡＹＥＲ上のクエリ、および通常非コアを使用し、ＥＴＬ処理の派生層である。

変更データキャプチャプロセスはワークテーブル、すなわちＷ＿ｔａｂｌｅおよびＸ＿ｔａｂｌｅの一般的な形式および先に述べた２つのビューを介して主キーメタデータの可用性を構築するために定義された標準化されたスキーマのプロセスに基づいて動作する。

変更データキャプチャプロセスの機能の概要に関して、ステージングテーブルからＷ＿ｔａｂｌｅ（ステージデータベース内）へのソースデータの変換およびロードを通じて、派生したおよび任意の他の関連したデータロードの、非コア毎のソース−システム特定の変換プロセスは、明示的な削除メッセージを除いて、変更データキャプチャを呼び出す前に実行される。Ｗ＿ｔａｂｌｅをロードするプロセスは典型的にテーブル毎に独立しているが、データベースに定義された特定の変換プロセスに基づいて完全に独立していなくてもよい。

一実施形態では、Ｗ＿ｔａｂｌｅおよびＸ＿ｔａｂｌｅはソースシステムの各ＣＤＣ実行の開始前に空にされる。変更データキャプチャは、明示的な削除を除き、Ｘ＿ｔａｂｌｅを介してＷ＿ｔａｂｌｅからコンピュータデータウェアハウス（ＣＤＷ）データ層（例えば、非コア）にデータをロードする。例示的な実施形態では、このプロセスは目標テーブル全体の可能な範囲で並列化され、相互依存性を有していない。

例示的な実施形態では、ＣＤＣシステムは比較的短い時間（典型的には数秒以内）でｓｅｔ−ＳＱＬを使用して単一のデータベーストランザクション内の各目標テーブルにフェーズロードを適用する。これらのトランザクションはテーブル全体の可能な範囲で並列化され、相互依存性を有していない。本明細書にて説明される変更データキャプチャシステムおよび方法は、一時的判定基準に効力を発揮してもよい適切なクエリアクセス方法に基づいて、レポートを中断することなくＣＤＷの柔軟で迅速なロードを可能にするミニバッチの設計に関連する。目標テーブルをロードするためにデータベースユーティリティは使用されていない。所与のソースシステムまたは関連テーブルのセットについては、バッチ全体の実行は新しいバッチの実行を開始する前に完了されてもよい。換言すれば、データロードのＣＤＣ関連の部分は目標テーブルに関して並列または重ならないように実行される。

ＣＤＣシステムは、論理的な削除により作成されたギャップを除いて、削除タイムスタンプに指定されたソースシステム（削除用）または次の行のソース開始タイムスタンプのみに典型的に設定されるソース終了タイムスタンプ（ｓｏｕｒｃｅ＿ｅｎｄ＿ｔｓ）とともに既存の目標行の２つの標準終了タイムスタンプ（ソースまたは有効およびトランザクションまたはＥＴＬ）のみをアップデートする。これは、一般性を失うことなくタイムスタンプのペアの代わりに、可能であれば期間タイプを使用して実装されてもよい有効期間を事実上アップデートする。すべての新しいデータ（例えば、任意の新しいキーまたは非キー属性値）は結果として新しい目標行となる。いくつかのケースで指定された派生テーブルが完全に最新の内容にされてもよいことを除き、他のＣＤＷ列はＣＤＣプロセスにより目標テーブル内でアップデートされなくてもよい。

ＣＤＣシステムはデータモデルから直接ロードされたコンピュータデータウェアハウスメタデータ毎に主キーの一意性を保証する。アクティブな整合性制約を実装することは想定または要求されていない。したがって、受動的なチェックスクリプトはさらに検証として実行されてもよい。ＣＤＣシステムはまたタイムスタンプの範囲が有効であることをも保証する。例えば、システムは終了ソースまたは有効なタイムスタンプが開始タイムスタンプよりも大きいまたは等しいこと、および／またはＰＫ以内であること、ソース開始タイムスタンプが削除を除き前の行のソース終了タイムスタンプに等しいこと、および／または論理的に削除しない限りソース終了タイムスタンプが主キー内の最新行のＮＵＬＬであることを確認してもよい。同様の機能はタイムスタンプのペアの代わりに期間データ型上で想起される動作であってもよい。

ＣＤＣシステムは、ソース開始タイムスタンプがソースデータ行（Ｗ＿ｔａｂｌｅおよびＸ＿ｔａｂｌｅ内でＳＲＣ＿ＳＴＡＲＴ＿ＴＳと名称付けされる）から常に事前設定されるタイムスタンプのみであることと、両方の一時的な期間を表す４つのすべての標準化されたタイムスタンプを取り込む。ソース終了タイムスタンプ属性はまた一意なコンテンツまたは現在行の削除時間（既知の場合、別に現在時間）とともに主キー内の次の行の開始タイムスタンプとしてソースから取得されるが、行が最新の情報を表す際にはｎｕｌｌであり得る。

２つのＣＤＷタイムスタンプは実際のロード時間（トランザクション時間）を反映するが、所与のテーブルの所与のミニバッチ実行のために標準化されてもよい。例えば、ＣＤＷタイムスタンプは所与のテーブルの所与のミニバッチ実行にロードされたすべての行を容易に識別できるように固定値としてのロードおよび設定の直前に取得されてもよい。ＣＤＣシステムはまた各テーブルがロードされた後に統計情報を収集し最新の内容にする（ｐｒｅ＿ＣＤＣ内のＷ＿ｔａｂｌｅ、ＡＬＬ＿ＶＴが無効になっている場合のステップ１０４の一部としてのＸ＿ｔａｂｌｅ、またはステップ１１２の最後の繰り返しの終わりに）。変更データキャプチャシステムはまた、別々に呼び出されない場合、機能要件毎に受動的な主キーの一意性および外部キーの整合性チェックを呼び出すことができる。

ＣＤＣシステムでは、暗示的親−子（ｐａｒｅｎｔ−ｔｏ−ｃｈｉｌｄ）削除はプロセスフローが収容されるように示すためにプレースホルダとして実装されてもよい。複雑なステージ変換および混合モデルの公開（例えば、１つのテーブルのプッシュおよびスナップショット）で必要とされる変化は対処されない。注意されるように、任意の明示的および任意の複合暗示的削除はソースシステム特定の変換コードによりＣＤＣの開始前にＸ＿ｔａｂｌｅにロードされてもよい。ＣＤＣシステムは削除レコードを同じバッチ内であっても復元または「再生」させることができる。ソースの開始タイムスタンプが削除の唯一のインデックスとなる前のレコードのソース終了タイムスタンプよりも大きいまたは等しいことに注意する際、そのような状態が検出されてもよい。

例示的な実施形態では、非コアの新しい行カウントは非コアの古い行カウント＋Ｉ＋Ｏ＋Ｕカウントに等しい。システムはアップデートをカウント（ＯおよびＵは別々に追跡されてもよい）し、終了タイムスタンプがｎｕｌｌでないＸ＿ｔａｂｌｅにおけるＯおよびＵのカウントに対してこれらのカウントを検証してもよい。

コードジェネレータにより生成された事前生成クエリは異なる層（例えば、非コア、コア、および派生）の潜在的な重複するテーブル名を防ぐためにデータ層に関連する条件を含んでいてもよい。例示的な実施形態では、指定されたＣＤＷおよびＳＯＵＲＣＥタイムスタンプではないタイムスタンプ列はタイムゾーンおよび６桁の精度を含む。これらの要件のいずれかまたは両方がコードジェネレータへの適切な変更を省略されてもよい。

データウェアハウスに入力データをロードするための例示的な方法は特定の処理ステップまたは操作を参照して以下に説明される。独立したモジュールは、呼び出しが目標Ｗ＿ｔａｂｌｅまたはＸ＿ｔａｂｌｅに一度あることと、メタデータの設定毎にパーティションロードステップ（図４に示される）内で複数の繰り返しで並列に複数のパーティションを実行するオプションで、適用される前提条件に基づいて提供される。例えば、本明細書に説明されるステップ１００から１１２は、入力データの中に相互依存性があるイベントでは、ソースシステムに関連するすべてのＷ＿ｔａｂｌｅが処理の開始前に完全にロードされることを要求してもよい。しかしながら、ＣＤＣプロセス自体がそのような相互依存性を導入していない。

例示的な実施形態では、各ステップはデータベースのパフォーマンスの低下の回避を可能にする、独立したＳＱＬステートメントとして実行される。さらに、ステップ１００から１１２が単一のデータベーストランザクションに含まれていなくてもよい。むしろ、例えば、各ステップまたはステップの複数のグループの各々は、個別のトランザクションで実行されてもよい。いくつかの実施形態では、ロードプロセス全体は任意のデータベースエラーが発生した場合には中止されるが、情報メッセージおよび／または警告メッセージの場合には継続してもよい。適用ステップ２０１−２０７は、任意のエラーに発行された明示的なロールバックとともに、複数の単一要求の単一データベーストランザクションとして実行されてもよい。すべてのＣＤＣプロセスが所与のソースシステム用の新しいミニバッチ実行が開始される前に完了されてもよい。

ステージおよび目標データベースのデータベース名は各ＣＤＷ環境に合わせて適切にパラメータ化されてもよい。テーブル名は目標テーブル名に基づいてパラメータ化され、正しいデータベース名（Ｗ＿、Ｘ＿、および＿Ｘテーブルはステージデータベース内にあり、目標テーブルは非コア、コア、または派生データベース内にあることができる）に割り当てられる。いくつかの例示テーブルはデータベースとして認定されていないことに注意されたい。例えば、Ｗ＿およびＸ＿はＳＴＡＧＥであってもよいのに対し、目標は典型的にはＮＯＮＣＯＲＥである。

適切なロック修飾子は目標テーブルまたは共有型持続性ステージ上でロックの競合を最小限に抑えるためにＣＤＣコードジェネレータにより追加される。例示的な実施形態では、ＥＴＬは適用フェーズをカプセル化するトランザクション中に目標データへのアクセスを制御しない。一般的なデータウェアハウスのアーキテクチャはアウトバウンドデータベースビューのための「ＬＯＣＫ ＦＯＲ ＡＣＣＥＳＳ」と同等な「ダーティリード（ｄｉｒｔｙ ｒｅａｄ）」を含む。トランザクション内での上述の適用ステップの順序はこの問題を最小化するように設定される。代替の実施形態では、追加のＳＱＬビューは必要に応じてトランザクションの待ちが完了するように定義される。

例示的な実施形態では、ＣＤＣプロセスはＥＴＬコードに従って文書化され構成されたジョブに対応する、ソースシステムレベルで制御される同期ポイントで、目標テーブルレベルで制御される。ソースシステム内のすべてのテーブルのための適用ステップ（テーブル毎に１つのデータベーストランザクション）は新しいデータの一貫したビューを提供するために可能な限り並列化され、クエリ内で参照整合性の問題を最小限に抑えてもよい。いくつかの実施形態では、真の参照整合性がソース開始タイムスタンプが主キーの一部であることおよび親と子の間で変化するために従来の制約で強制されないことに留意すべきである。可能であれば、期間データ型の使用は一時的なＰＫおよび外部キー（ＦＫ）の制約が強制されることを可能にする。

所望してもよい前提条件外部ロードプロセスをサポートするとともに例示的な変更データキャプチャプロセスを示すフローチャート７０である図３を参照すると、明確な候補列が外部プロセス（例えば、ＣＤＣプロセス以外のプロセス）によりＷ＿ｔａｂｌｅにステップ７２で挿入される。例示的な実施形態では、すべての適格なソースシステムテーブルの行（例えば、メッセージまたはスナップショット）はテーブル特定の変換を使用してＷ＿ｔａｂｌｅに書き込まれる。ＩＮＳＥＲＴ ＳＥＬＥＣＴ設定ロジックが使用されてもよい。ステップ７２の一代替案では、候補行が１つの「バッチ」実行のＣＤＣコードの開始点またはベースラインとともにＷ＿ｔａｂｌｅに挿入され移入される。完全に重複した行はＳＥＬＥＣＴステートメント内のＤＩＳＴＩＮＣＴの使用で排除される。ステップ７２で挿入した後、Ｗ＿ｔａｂｌｅはソースにより保持され提供された場合履歴を含んでいてもよい、変換された入力データセットの完全で明確なスナップショットを包含する。メッセージベースのインターフェースについては、このステップは削除メッセージを除外してもよい。

ステップ７４で、明示的な削除は、以下でさらに説明されるステップ１０１を除いてまたはそれとの組み合わせで、ステージからＸ＿ｔａｂｌｅに挿入される。ステージ／変換ＳＱＬコードはこのような場合にＰＫ属性および「Ｄ」（削除）ＥＴＬインジケータをＸ＿ｔａｂｌｅにロードする。１つの代替案では、Ｘ＿ｔａｂｌｅはステップ７４で明示的な削除を挿入する前にきれいにされる（例えば、空に）。別の代替案では、ステップ７４は、両方の組み合わせが許容されてもよい場合の、ＬＯＡＤ＿ＴＹＰＥ＝Ｂのときを除いて、任意の明示的な削除を含まなくてもよい、スナップショットタイプのインターフェースのための省略された明示的な削除の挿入を含む。暗示的な削除が明示的な削除の代わりに使用される際には、ステップ７４は省略されてもよい。

ステップ７６で、ＣＤＣプロセスはソーステーブルに関連付けられているロードジョブが完了するのを７６で待つ。オプションのステップ７８で、ロードジョブが完了すると、カスケード削除が実行される。いくつかのテーブルについては（例えば、従属子）、削除行がＸ＿ｔａｂｌｅに書き込まれる。ソースシステムのための変換ＳＱＬプロセスはＰＫ、親ｓｒｃ＿ｓｔａｒｔ＿ｔｓ、「Ｄ」のＥＴＬインジケータ、および期限切れする行のソース開始タイムスタンプを直接ロードする。例示的な一実施形態では、ステップ７８のカスケード削除は、子にカスケードして明示的に提供されない親の削除のためのソース変換に基づくＣＤＣプロセスへのオプションの前提条件である。最新ではない目標行については、これらの削除は、以下でより詳細に説明する適用ステップ２０６で実行されてもよい。

オプションのステップ８０で、親−子暗示的削除が実行される。一代替案では、削除行はアップデートに応答して、１つまたは複数のテーブル（例えば、従属子）用のＸ＿ｔａｂｌｅに書き込まれる。ソースシステムの変換ＳＱＬプロセスはＰＫ、親ｓｒｃ＿ｓｔａｒｔ＿ｔｓ、「Ｄ」のＥＴＬインジケータ、およびｓｒｃ＿ｅｎｄ＿ｔｓに格納されているこの子と一緒に送信されない前の親の行のソース開始タイムスタンプをロードする。別の実施形態では、設計はソースシステムインターフェース（例えば、継承する親ＴＳ）に基づいて変化する。ステップ８０の１つの代替案で、親−子暗示的削除は以前のすべての子の削除を暗示する従属子行のアップデート用のソース変換に基づいたＣＤＣプロセスへのオプションの前提条件である。一代替実施形態では、最新ではない目標行については、これらの削除は以下に開示する適用ステップ２０６に従って実行される。いくつかの実施形態では、ステップ７２から８２はＣＤＣプロセスの予備的なものであり、本明細書に記述のプロセス内には含まれない。

ステップ８２で、ＣＤＣプロセスはソーステーブルに関連付けられているジョブが完了するのを待つ。これらのジョブが完了した際に、８４で、データベースセッションが作成される。ステップ８４はデータベースセッションに特定であるプロセスおよび／またはスレッドでデータベースセッションの作成を含んでいてもよく、１セッションで実行されるそのような操作は別のセッションで実行される操作には影響しない。

ステップ８６で、作成されたセッションの量はＳＥＳＳＩＯＮ＿ＰＡＲＡＬＬＥＬＩＳＭと比較される。セッションの量がＳＥＳＳＩＯＮ＿ＰＡＲＡＬＬＥＬＩＳＭ未満である場合、ステップ８４は別のデータベースセッションを作成するために再度実行される。そうでない場合は、ステップ８８で、ＣＤＣプロセスはすべてのデータベースセッションが処理を完了するのを待つ。

ステップ８４で作成された各データベースセッションについては、ＣＤＣプロセスはステップ９０で任意のパーティションがロードに利用可能であるかどうかを決定する。そうである場合、ステップ９２で、パーティションロードが、図４を参照して以下で説明するように、ステップ８４で作成された利用可能なデータベースセッションを使用して実行される。一実施形態では、ステップ９２はＸ＿ｔａｂｌｅなどのようなプリロードテーブルに入力データの１つのパーティションのインポートを実行するためにパーティションロードを提供する。

いくつかの実施形態では、入力データは複数のパーティション（例えば、１より大きい値をＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳに設定することにより）に分割され、ステップ９２は各パーティションに対して実行されてもよい。例えば、入力データはメタデータを使用してＰＫに関して明確におよび実質的に均等に（例えば、パーティションサイズの１％、５％、または１０％の変動で）分割されてもよい。一例では、パーティションの量はユーザ提供パラメータ、ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳにより定義されてもよい。ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳを値１に設定することは、入力データセット全体を単一のパーティションとして扱われることに起因して入力データセットのパーティショニングを効果的に無効にしてもよい。

ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＞１であるとき、複数のパーティションは個々のパーティションの実行の並列度の所望の程度を表す別のユーザ定義パラメータ、ＳＥＳＳＩＯＮ＿ＰＡＲＡＬＬＥＬＩＳＭに基づいて並列にロードされてもよい。あるいは、パーティションは順次、すなわち連続してロードされてもよい。例えば、１に等しいＳＥＳＳＩＯＮ＿ＰＡＲＡＬＬＥＬＩＳＭを設定することは結果としてパーティションの逐次処理となってもよい。

ステップ９０で、ＣＤＣプロセスがデータベースセッションでインポートするために利用できるパーティションがないと判断した際には、セッションは処理を完了し、ＣＤＣプロセスがすべてのデータベースセッションが完了するのを待つステップ８８に実行が継続する。

ステップ９４で、すべてのパーティションロードが完了した後、図６を参照して説明したように、すべてのロードされたデータが１つのデータベースセッションに適用される。例示的な一実施例では、ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳは５に設定され、ＳＥＳＳＩＯＮ＿ＰＡＲＡＬＬＥＬＩＳＭは３に設定される。ステップ８４は３つのデータベースセッションを作成するために３回実行される。第１のセッションは第１のパーティションのロードを実行するためにステップ９２を実行し、第２のセッションは第２のパーティションのロードを実行するためにステップ９２を実行し、第３のセッションは第３のパーティションのロードを実行するためにステップ９２を実行する。この例でパーティションのサイズが実質的に同様であると仮定すると、第１のデータベースセッションはステップ９２（最初のパーティションに対する）を完了し、それ以上のパーティション（すなわち、第４および第５のパーティション）がロードに使用可能であることを決定する、ステップ９０を実行する。第１のデータベースセッションは第４のパーティションのロードを実行するためにステップ９２を実行する。第２のデータベースセッションはステップ９２（第２パーティションに対する）を完了し、パーティション（すなわち、第５のパーティション）がロードに利用可能であることを決定する、ステップ９０を実行する。第２のデータベースセッションは第５のパーティションのロードを実行するためにステップ９２を実行する。第３のデータベースセッションはステップ９２（第３のパーティションに対する）を完了し、ロードに利用可能なパーティションがないことを決定するステップ９０を実行し、ステップ８８に進みすべてのセッションが完了するのを待つ。同様に、第１および第２のデータベースセッションの両方はステップ９２（それぞれ、第４および第５のパーティションに対する）を完了し、ロードに利用可能なパーティションがないことを決定するステップ９０を実行し、ステップ８８に進みすべてのセッションが完了するのを待つ。すべてのデータベースセッションの完了とともに、ＣＤＣプロセスはステップ９４に進み１つのデータベースセッション内でロードされたパーティションを適用する。

図４は、例示的なパーティションロードプロセスを示すフローチャート９８である。例示的な実施形態では、フローチャート９８で示すプロセスは、順次および／または並列に、ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳパーティションの各々について実行される。以下に説明するステップは、表４に示すように、１つ以上のメタデータパラメータに依存してもよい。

例示的な実施形態では、表４の文字の値（例えば、「Ｙ」または「Ｓ」）は、メタデータパラメータが文字の値に等しい場合にのみそのステップが実行されることを示す。パイプ記号（「｜」）はメタデータパラメータがリストされている文字の値のいずれかに等しいときステップが実行されるケースでの、文字の値の間の選言的（「ｏｒ」）の関係を示す。さらに、「ｎ／ａ」はメタデータパラメータがプロセスステップには適用されないことを示す。このような場合には、ステップはメタデータパラメータの値に関係なく実行されてもよい。

ステップ１００で、目標パーティションのロードはＡＬＬ＿ＶＴ＝ＹおよびＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＞１のときスナップショットロード（例えば、ＬＯＡＤ＿ＴＹＰＥ＝ＳまたはＢ）に対して実行される。要約すると、ステップ１００は、別々の揮発性のテーブル内にテーブルの明確な論理パーティションを作成するためのコストがプロセッサ使用率および／またはこのステップを追加するコストよりも多くの実行経過時間を低減する、大きなテーブルに対して呼び出される。一実施形態では、ステップ１００はステップ１０１と同一の条件下で呼び出されてもよい。

ステップ１００および１０１で、論理パーティションは、例示的な実施形態でソース開始タイムスタンプを除いて主キー列に基づいて１および１００万の間の整数を生成する、ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（））関数を使用して作成される。これは相対的に均一なパーティショニング（例えば、同様なサイズのパーティション）を提供し、別個のパーティションにデータ行を決定論的に割り当てる低コストな（例えば、コンピューティングリソースの点で）方法である。ＭＯＤ（モジュラス）関数は、ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮのためのメタデータ値である残余として１からＮで、メタデータパラメータＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳに対して使用される。コードジェネレータはステップ１００および１０１のためにＳＱＬでこれらの値をインスタンス化し、ＣＤＷ＿ＣＤＣ＿ＰＡＲＭ内のテーブルパラメータに基づいてＣＤＷ＿ＣＤＣ＿ＳＱＬテーブル内の検索のためにそれらを適切に格納する。

ステップ１００
例示的な実施形態では、ステップ１００は、Ｎ（いいえ）の典型的な値で、ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹと呼ばれる履歴フィルタリングパラメータを使用する。ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹがＹに等しい場合、ＣＤＣシステムはＷ＿ｔａｂｌｅの入力データに基づいてＣＤＣの実行中に必要のない目標テーブル内のより古い履歴行を取り除く。各Ｗ＿ｔａｂｌｅ ＰＫのための最先のタイムスタンプは、パーティションを切られた揮発性テーブル上のフィルタとして機能する、目標テーブルの主キーのセットを構築するために問い合わせおよび比較される。派生テーブルはパーティションフィルタを適用するＷ＿ｔａｂｌｅ内の主キー毎のより古いソースタイムスタンプのＷＩＴＨ句を使用して構築される。これは次にすべてのより古い履歴を除外する対象テーブルから必要な主キーの別個のセットを作成するために使用される。

一実施形態では、セットは、既に含まれていない場合は、ステップ１０２で適切な暗示的削除処理を保証するために、最先のＷ＿ｔａｂｌｅ行よりも新しい行、最先のＷ＿ｔａｂｌｅ行の前の行、および最新の行を含む。一代替案では、パーティション表現はそれぞれのケースに適合する。加えて、ＬＯＡＤ＿ＴＹＰＥ＝Ｂは、さらにクエリ条件を別のクエリ条件を介して明示的な削除行の主キーに一致する目標テーブルから行を提供するために追加されるという点では、このオプションの動作に影響を与えてもよい。

別の例示的な実施形態では、ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹは有効になっており、結果としてステップ１０４のような後ステップにおけるより低いコンピューティングリソースの使用率となる。この実施形態を続けると、ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹは相対的に大きく（例えば、数百万行を含む）履歴行の相対的に大きな割合（例えば、テーブルの内容の７５％以上）を有するテーブルのリソース使用率を低減するのに有効であってもよい。

ＡＬＬ＿ＶＴを有効にする１つの利点は、指定された１つまたは複数の列でハッシュアルゴリズムの実装を通して超並列処理（ＭＰＰ）データベースシステム上でデータを配信する方法である、主インデックス（ＰＩ）としてＰＫ＿Ｌａｔｅｓｔの使用をもたらすことである。有利なことに、このオプションはＰＩがＰＫよりもはるかに少ない列を有するテーブル内よりもＰＫ＿Ｌａｔｅｓｔがよりスキューが少ないように具える。加えて、ＡＬＬ＿ＶＴが有効になっている場合、システムはベーステーブルビュー内にフィルタを有するリスクを避けるために、アクセスロッキング修飾子をベーステーブルから読み出す。改善された効率は明示的な列名の一覧を記載するベーステーブルからワンステップ読み取りで揮発性テーブル（ＶＴ）を作成することにより達成されてもよい。これはアクセスビューから作成するのとは異なり、列が「ｎｕｌｌでない」属性を保持するようにさせる。一代替案では、ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝１であるとき、ハッシュパーティションはコンピューティングリソースを浪費しないようにこのステップでバイパスされる。例えば、ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳは、相対的に小さなパーティション内のデータの処理に関連付けられたコンピューティングリソースの減少により相殺されるようにパーティショニングに関連付けられたコンピューティングコストにはその他の点で十分に大きくはないスキューのあるテーブルのために１に設定されてもよい。

ステップ１０１
例示的な実施形態では、ＡＬＬ＿ＶＴ＝ＹおよびＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＞１であるとき、ステップ１０１はスナップショットをロードするために実行される（例えば、ＬＯＡＤ＿ＴＹＰＥ＝ＳまたはＢ）。換言すると、このステップは、別々の揮発性テーブルのテーブルの別個の論理パーティションを作成するコストがこのステップを追加するコストよりもプロセッサの使用率および／または経過実行時間を低減するために大規模なテーブル用に呼び出されてもよい。一代替案では、ステップ１０１はステップ１００と同一の条件下で呼び出され、必要に応じて論理パーティションを別々におよび並列セッションで処理することができるように、Ｗテーブル、Ｘテーブルおよび目標テーブル用の揮発性テーブルを構築するプロセスを完了する。

論理パーティションは、例示的な実施形態ではソース開始タイムスタンプを除く主キー列に基づいて１および１００万の間の整数を生成するＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（））関数を使用して作成される。これは相対的に均一なパーティショニング（例えば、同様なサイズのパーティション）を提供し、別個のパーティションにデータ行を決定論的に割り当てる低コストな（例えば、コンピューティングリソースの点で）方法である。ＭＯＤ（モジュラス）関数は、ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮのためのメタデータ値である残余として１からＮで、メタデータパラメータＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳに対して使用される。コードジェネレータはこのステップおよびステップ１００のためにＳＱＬでこれらの値をインスタンス化し、ＣＤＷ＿ＣＤＣ＿ＰＡＲＭ内のテーブルパラメータに基づいてＣＤＷ＿ＣＤＣ＿ＳＱＬテーブル内の検索のためにそれらを適切に格納する。

Ｘ＿ｔａｂｌｅの空の揮発性コピーが作成される。ＬＯＡＤ＿ＴＹＰＥ＝Ｂについては、第３のＳＱＬステートメントは現在のハッシュパーティションに一致するＸ＿ｔａｂｌｅから明示的な削除行（例えば、ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝「Ｄ」）を挿入するために実行されてもよい。他の行は、その他の点でＬＯＡＤ＿ＴＹＰＥ＝「Ｓ」についてＣＤＣの開始時に完全に空であるかまたはＬＯＡＤ＿ＴＹＰＥ＝「Ｂ」について明示的な削除で移入されるこのようなケースを除いてＸ＿ｔａｂｌｅから読み込まれない。

ステップ１０２
［０００１］例示的な実施形態では、ステップ１０２はスナップショットロードを実行し（例えば、ＬＯＡＤ＿ＴＹＰＥ＝ＳまたはＢ）、ロードタイプＳおよびＢの間には、ステップ１０２でコードの差はなくてもよい。換言すれば、暗示的削除のためのＸ＿ｔａｂｌｅ行の構築は、ソースデータの完全なスナップショットが使用可能であり、その存在のために親テーブルに依存していないテーブル用であるときには、呼び出されてもよい。これらの後のケースは親―子暗示的削除である。いくつかの実施形態では、ステップ１０２は、変更された行のみをロードするための行修正タイムスタンプを使用するなどのような、スナップショットインターフェースへの代替手段が実用的でないときに使用される。

［０００２］一実施形態では、ステップ１０２は暗示的削除ステップを含む。削除は非コアでアクティブ行であり（終了タイムスタンプがｎｕｌｌである）、もう入力スナップショットではなくなっている最新の主キー（ＰＫ＿ｌａｔｅｓｔ）を検出することにより決定され、このように最後のデータフィード以来ソースシステム内で削除されたと推定される。一実施形態では、現在のデータベースのタイムスタンプは適用ステップ（例えば、適用ステップ２０２）で使用するためにＳＲＣ＿ＳＴＡＲＴ＿ＴＳに挿入される。例えば、単一の適用ステップは現在のデータベースのタイムスタンプを使用して暗示的および明示的な削除を実行してもよい。このタイムスタンプは目標テーブル内の終了タイムスタンプになる。ソースシステムからのトリガまたは削除時間がないので、現在のタイムスタンプはソースシステム内での推定削除時刻として使用される。

ステップ１０３
［０００３］例示的な実施形態では、ステップ１０３はＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｙであるとき、ロードタイプＳおよびＢの間でコードの違いなしでスナップショットロード（例えば、ＬＯＡＤ＿ＴＹＰＥ＝ＳまたはＢ）に対して実行される。このステップは、例えばテーブルが新しいコンテンツなしに新しい行のかなりの量を有するときに呼び出されてもよい。特に、このステップは目標テーブルの最新のアクティブな行よりも新しいＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳで主キー毎に次の連続した行のみを排除し、他のすべての非キー属性は同じである。例えば、ステップ１０３はＷ＿ｔａｂｌｅ行の大部分が新しいタイムスタンプで新しい属性なしで現在の目標テーブルの行を表すところで有効であってもよい。

［０００４］ステップ１０３の追加は結果として変更を識別し、より複雑なフルシーケンスと比較から行を除外するためにステップ１０４でのみ順番に使用される、ｔａｂｌｅ＿ＫＶＴと名称付けられた揮発性テーブルの中に変更されていない新しい行の主キーをロードするためにステップ１０４のみを使用するよりも低コストのプロセスになってもよい。完全な比較がステップ１０４で必要とされないように、このアプローチのコンピューティングリソースの節約は実質的であってもよい。

ステップ１０４
［０００５］例示的な実施形態では、ステップ１０４は、ソースタイムスタンプの最後の３桁以外の少なくとも１つの属性が異なるＷ＿ｔａｂｌｅから、目標テーブル行（ＡＬＬ＿ＶＴ＝Ｎのとき）またはＶＴに格納されたフィルタされた目標行（ＡＬＬ＿ＶＴ＝Ｙのとき）から、候補行とともにＸ＿ｔａｂｌｅをロードする。このような行は最初にＥＴＬインジケータ「Ｉ」としてコーディングされており、ＳＯＵＲＣＥ ＳＴＡＲＴ ＴＳは必要に応じて一意に１マイクロ秒でシーケンスされる。このプロセスは、エラー中で以前に論理的に削除された最新レコードの再活性化などのような、目標テーブル内への非キー属性の変更のアップデートを（ｓｏｕｒｃｅ ｓｔａｒｔ ＴＳへの対応する１ミリ秒追加で）することを可能にする。これは、個別の入力データセットの行がロードされることのみを保証するために有効な時間で一意性違反を解決する。

［０００６］例えば、ジョブの失敗はジョブの再実行の必要性に繋がる筈であり、ソース開始タイムスタンプではなくＷ＿ｔａｂｌｅ内の列をアップデートし、変更データキャプチャシステムは新しい非キー属性を検出し一意であるシーケンスされたソース開始タイムスタンプとともに新しい行を非コアに挿入する。いずれにしても、所与の主キーの任意の新しいソース開始タイムスタンプはまた、結果として入力および既存のデータの両方を考慮する、その主キーの直前の行とは異なる非キー属性を提供した新しい行となる。

［０００７］いくつかの実施形態では、ステップ１０４のタイムスタンプの再シーケンス部（例えば、ソースシステムがソース開始タイムスタンプを除いた一意のビジネスキーを保証している場合）は省略される。最小時間増分、例えば１マイクロ秒は、ｒｏｗ＿ｎｕｍｂｅｒ（）関数の等価物のような、ＰＫ内の順序付け機能に依存する、さらにシーケンシングを行わない同一の主キーを有する後続行のソース開始タイムスタンプに追加される。

［０００８］タイムスタンプの再シーケンスは、アップデート処理が一対一での行の割り当てを保証されるように、最初に一意の主キーを（タイムスタンプで）保証するために利用される。再シーケンスされた行の一部は、明確な非キー属性を有していないためにその後削除されてもよい（ステップ１０７を参照）。保持された最古のそのような行で、これは導入されている新しいシーケンシングの可能性を最小限に抑える（例えば、最古の行には追加された時間がない）。Ｘ＿ｔａｂｌｅが揮発性テーブルではないとき（例えば、ＡＬＬ＿ＶＴが無効になっている）ステップ１０４のＸ＿ｔａｂｌｅでの統計情報の収集または最新の内容にすることは最適なロードパフォーマンスの実現を容易にする。

［０００９］例示的な実施形態では、ステップ１０４の動作は最適化オプションに基づいて異なる。例えば、ＡＬＬ＿ＶＴが有効になっているとき、ステップ１０４は従来のまたは永続的テーブルではなく揮発性テーブルに対して受信および動作してもよい。さらに、ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｙであるとき、追加のサブクエリは前述したように、ステップ１０３で移入された＿ＫＶＴ揮発性テーブルから行を除外するためにＳＱＬステートメントの最後に追加される。これはそのステップで検出された新しいけれども変更されていない行のはるかに大きいセットのコスト高な自己結合を回避する。ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴはＡＬＬ＿ＶＴと併せて有効にされてもよい。

ステップ１０５
［００１０］例示的な実施形態では、ステップ１０５はＸ＿ｔａｂｌｅが前のステップで候補挿入行がロードされた後で実行される。それ故選択クエリは現在の実行に関与する主キーのセットを決定するためにＷ＿ｔａｂｌｅ内の入力行およびＸ＿ｔａｂｌｅ内の削除行を統合する必要はない。このアプローチは結果として、特にスナップショットロードのケースでは、入力Ｗ＿ｔａｂｌｅ行がロードされる前に除去される際に揮発性の比較的小さなテーブルとなってもよい。

［００１１］ステップ１０４と同様に、ステップ１０５はＡＬＬ＿ＶＴが有効になっているときに揮発性テーブル名に対して受け入れるおよび動作してもよい。さらにＡＬＬ＿ＶＴオプションは結果の揮発性テーブルの主インデックスに影響してもよい。ＡＬＬ＿ＶＴ＝Ｎであるとき、Ｗ＿ｔａｂｌｅおよびＸ＿ｔａｂｌｅ主インデックスに一致する主インデックスが使用されてもよい。逆に、ＡＬＬ＿ＶＴ＝Ｙであるとき、使用される主インデックスは他の３つの揮発性テーブルに一致するように、ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳを除く主キーであってもよい。

［００１２］ステップ１０５は、一時的テーブルに格納される目標テーブル行の限定されたサブセットを使用することにより、ステップ１０６−１１０で実行される解析のコストを低減する実質的なパフォーマンスの最適化、特にステップ１０７の一時的な正規化を容易にしてもよい。改善は新しい候補行のみをＷ＿ｔａｂｌｅ内に送るプッシュインターフェース用に宣言されてもよくおよび／または広範な履歴が目標テーブル内に存在する際であってもよい。２つの範囲の性能向上も可能であってもよい。先ず、ＣＤＣシステムはＷ＿ｔａｂｌｅおよびＸ＿ｔａｂｌｅに含まれる主キー（ソース開始タイムスタンプを除く）に対して目標テーブル行のみを考慮してもよい。ネット変更またはプッシュインターフェースについては、より頻繁なロード、より効率的なこのステップは、解析ステップのコストを低減することであってもよい。結合データボリュームの量は、少なくとも１００の因子で減少されてもよい（例えば、提示ロード主キー毎に１％）。

［００１３］次に、ＣＤＣシステムは、最古の入力Ｗ＿ｔａｂｌｅおよびＸ＿ｔａｂｌｅソース開始タイムスタンプおよびすべての後続行の前で、もしあれば、目標テーブルから行へのこのようなＰＫ行の期間を制限してもよい。換言すれば、ＣＤＣシステムは、各ＰＫための最新のＷ＿ｔａｂｌｅまたはＸ＿ｔａｂｌｅへの前の行よりも以前の行を除いて、解析ステップで不要な過去の行を無視してもよい。いくつかのより新しい中間目標行もまた必要とされなくてもよいので、この最適化は行の最小数を決定しなくてもよい。入力行の直前または以降の行のみが一時的シーケンスのために必要である。一時的フィルタリングへのこのアプローチは比較的低いコンピューティングコストで実質的な利益を提供することが期待される。履歴の再ステートメントは一般的にまれである。それ故、新しい入力データはすべての以前に格納されたデータよりも典型的に新しいものである。それ故、このステップは上記の最初のパフォーマンス改善範囲で選択したＰＫ毎に最新の現在行のみを典型的に読み取る。

［００１４］ステップ１０５は各実行または関与するＤＢＭＳに適用可能な任意の形式の一時テーブルでクリアされる永続的なテーブルを移入してもよい。一般性を失うことなく、揮発性一時テーブルはユーザアカウントのスプール（関与する結合をサポートするのに既に大きい）から割り当てられたスペースで選択される。テーブルはデータベースカタログへの影響やテーブルの作成権限を必要とすることなく、目標テーブルに対するｓｅｌｅｃｔステートメントの出力で自動的に定義され具現化される。

［００１５］いくつかの実施形態では、ＣＤＣシステムはＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝１である（パーティショニングを行わない）ときには、ステップ１００の任意の後続の実行（例えば、次のＣＤＣ実行）が揮発性テーブルおよびその内容が破壊されそれ故にｃｒｅａｔｅ ｔａｂｌｅコマンドがエラーなしで許可されていることを保証するであろう、別々のデータベースセッションを使用していることを前提としている。パーティショニングを使用する時（例えば、ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＞１）、ステップ１１１は、以下に説明するように、単一のセッションで繰り返し反復を許可するためにこのテーブルをドロップする。

ステップ１０６
［００１６］例示的な実施形態では、ステップ１０６のシーケンスは挿入候補（例えば、削除を除く）についてＸ＿ｔａｂｌｅおよび非コア間の完全な主キーを複製する。いくつかの実施形態では、Ｘ＿ｔａｂｌｅ内でのシーケンシングはステップ１０４により実行されてもよい。ステップ１０６はＡＬＬ＿ＶＴが有効になっているときに揮発性テーブル名に対して受け入れおよび動作をしてもよい。

［００１７］６つのサブ秒のタイムスタンプの数字の使用されていない最後の３桁の数字に他の方法で含まれる最大のシーケンスよりも１つ大きくして始まる値を追加することにより、ＣＤＣシステムは主キーが既存および将来のデータ行の両方に渡って一意でありシーケンスされていることを保証する。より新しいミニバッチロードは新しいタイムスタンプを毎回受信し、タイムスタンプの重要な部分が一意である場合、潜在的に最新のレコードを表している。

［００１８］ステップ１０６はステップ１０７およびそれ以降の前提条件であってもよく、重複する主キーを有するデータレコードが新しいコンテンツを有している場合一意なタイムスタンプにシーケンスされるであろうから、主キー等価性ケースを排除してもよい。削除レコードは除外される。加えて、タイムスタンプの「幹」（例えば、すべてであるが、最後の３つのシーケンスされた桁）はシーケンスされる唯一のタイムスタンプによってのみ区別される複数の主キーの値を許可するための後続する「グループ単位での」操作のために使用されてもよい。

ステップ１０７
［００１９］例示的な実施形態では、ステップ１０７はＡＬＬ＿ＶＴが有効になっているときに揮発性テーブル名に対して受け入れおよび動作をしてもよい。ステップ１０７は、主キー内のソース開始タイムスタンプでソートする直前の行と比較される際、ソース開始タイムスタンプ以外の新しいキーまたは非キー属性を含まない候補Ｗ＿ｔａｂｌｅ行を削除する。このステップは一般的に一時的正規化と呼ばれるプロセスの圧縮ユニットを表す。

［００２０］コンピューティングリソースは同じデータを含む行が複数回ロードされた際に浪費されてもよい。したがって、ステップ１０４は一時的な期間の圧縮ユニットを実装する。しかしながら、それはまだデータが「Ａ」から「Ｂ」、次に「Ａ」に戻る任意の変更を記録するために所望されてもよい。したがって、開始タイムスタンプを除く各個別行の最初のインスタンスはＸ＿ｔａｂｌｅ内で維持される。より具体的には、ＰＫ＿ｌａｔｅｓｔが同じ場合、およびＸ＿ｔａｂｌｅおよび非コアテーブルのユニオン内で、ＰＫ＿Ｌａｔｅｓｔ内のソース開始タイムスタンプによりソートされた際にタイムスタンプを除くすべての列が前の行と同じである場合にＸ＿ｔａｂｌｅ内のデータが削除される。

［００２１］いくつかの実施形態では、ＡＬＬ＿ＶＴを有効にすることは、、特に入力行の数が限定され（例えば、頻繁なロードでのプッシュインターフェース）広範な履歴（例えば、一部改定を含む）での目標テーブルのケースでは、ステップ１０７でのコンピューティングリソースの使用率を実質的に減少してもよい。この意図的な製品の結合の改善は桁違いに達する可能性があってもよい。例えば、プロセッサの使用率および／またはメモリ使用率を低減してもよい。さらに、コンピューティングリソースの利用率向上の結果、ステップ１０７の経過時間もまた短縮されてもよい。

［００２２］２つ以上の同一の連続した行のケースでは（例えば、ＰＫおよび属性の両方が同一）、ＣＤＣシステムは、最新の行が現在の最新の有効期限切れの目標行の終了後に開始するおよび以前の候補行が最新の目標行の期間内に開始する際にすべてが冗長として削除されないことを保証してもよい。この状況は、例えば、ソースシステムが論理的に時間のためのデータを削除し、次にデータをより新しいタイムスタンプなしで復元する際に、発生してもよい「再活性化」ケースと呼ばれてもよい。期限切れ行の最後のタイムスタンプに１ミリ秒を追加することは、ＣＤＣシステムが前の行に一致し、最小の一時的粒度を提供する、すべての他の属性で新しい行を開始することを可能にする。具体的には、追加の結合（テーブルＣというエイリアス）は論理的に削除される場合であっても、最新のソース開始タイムスタンプを見つけるためオンライン分析処理（ＯＬＡＰ）クエリを使用してステップ１０７に含まれていてもよく、最新のＸ＿ｔａｂｌｅ行と比較するために開始日付（または、このような行が存在しない場合は年２５００）および終了日付を戻してもよい。ＳＱＬステートメントに追加されるロジックは、次の最新行（Ｂ．）がＸテーブルにあるが最新Ｃテーブルの目標行の期間に含まれており、このようにＢ行がこのステップで削除されるであろう場合、最新Ｘ＿ｔａｂｌｅ行（Ａ．）をドロップすることを防いでもよい。例示的な実施形態では、Ｃ．結合の余分な計算コストは最小である。

［００２３］コンピュータデータウェアハウスは開始−終了タイムスタンプの範囲または期間として一時的な有効性を格納するので、同一の入力行がまだ有効であり提供された新しい情報ではなくそれが非コアの最新行であることを知る。同様に、Ｗ＿ｔａｂｌｅ内の２つの同一の行は連続ではあるが別の開始時刻を有することを知ることもまた新しい情報ではなく、一度終了タイムスタンプが入力データのケースに割り当てられると最先行の開始時刻は開始および終了タイムスタンプ間の期間で既にこのコンテンツをキャプチャしている。例示的な実施形態では、ステップ１０７は履歴的なアップデートに対応しＸ＿ｔａｂｌｅ内で連続した重複を除去する。ステップ１０７に関連付けられているＳＱＬステートメントは、テーブルが多くの列を有する場合、特に比較のいずれかの側でｎｕｌｌ値をチェックする必要性で、相対的に大きくなってもよい。１つの一般的に利用されるシステムがステートメント毎に１メガバイト（１ＭＢ）の制限を含む一方で、他のツールは低減された複雑さまたはサイズの実行単位内への非キー属性比較を分解するために複数のステップを必要としてもよいより小さいサイズの制限を課してもよい。オプション列のすべて（一般的にすべての非ＰＫの）を比較する場合にＮｕｌｌ保護が合体機能を介して提供される。ｒｏｗ＿ｎｕｍｂｅｒ関数の使用は、ステップ１０６により保証されるＸ＿ｔａｂｌｅおよび非コアの間で明確なｓｏｕｒｃｅ ｓｔａｒｔ ＴＳに依存する。

ステップ１０８
［００２４］例示的な実施形態では、ステップ１０８はＡＬＬ＿ＶＴが有効になっているときに揮発性テーブル名に対して受け入れおよび動作をしてもよい。ステップ１０８はこのケースでは新しいアップデートのための「Ｉ」から「Ｕ」である候補挿入行（「Ｉ」）の抽出、変換、ロード（ＥＴＬ）インジケータをアップデートする２つのステップの最初のものである。ここで使用されるように、用語「より新しい」は削除済みとしてフラグが付けられていても、非コアの同じＰＫ＿ｌａｔｅｓｔ内の最新行の主キーよりももっと後のソース開始タイムスタンプを含む、主キーを有するデータレコードを意味する。このステップは、各々が新しいコンテンツを表しステップ１０７で削除されていないことを提供される、主キー内の複数のＸ＿ｔａｂｌｅ行のＥＴＬインジケータをアップデートすることができる。例示的な実施形態では、最新のアクティブな非コア行の終了タイムスタンプのみは最新の非コア行の終了タイムスタンプとしてその開始タイムスタンプを適用するためのＰＫ毎の最先の「Ｕ」行のみを探し出す適用フェーズ（例えば、以下の適用ステップ２０２）でアップデートされる。後述するステップ１１０は、すべてであるが最新の行が目標の事前期限切れ内に挿入されることを反映するために、Ｘ＿ｔａｂｌｅ内のＰＫ毎の「Ｕ」に設定される複数の行がある際には終了タイムスタンプを提供してもよい。

ステップ１０９
［００２５］例示的な実施形態では、ステップ１０９はＡＬＬ＿ＶＴが有効になっているときに揮発性テーブル名に対して受け入れおよび動作をしてもよい。ステップ１０９は新しい履歴行がコンピュータデータウェアハウスに追加されることを可能にする。このステップは、このケースでは「より古い」データのアップデートのための「Ｉ」または「Ｕ」から「Ｏ」である、候補挿入行（「Ｉ」または「Ｕ」）用のＥＴＬインジケータをアップデートする２つのステップの２番目である。「Ο」：１のＥＴＬインジケータでの「古い」アップデートには２つのケースがある。ソース開始タイムスタンプは、削除済みとしてフラグが付けられていても、シーケンスアップデート外および２と呼ばれる、同じＰＫ＿ｌａｔｅｓｔ内で最新の非コア行の前にある。開始タイムスタンプは非コアのＰＫ＿ｌａｔｅｓｔ内の任意の行よりも新しいが、開始タイムスタンプはまた非コアの最新終了タイムスタンプよりも小さいので、ケース１は適合しない。換言すると、この行はより新しいアップデートであるが、非コア内で既にもっと後の有効期限切れ日付により既に論理的に削除され期限切れの一回入力としてマークされるであろう。定義により、この行はその開始タイムスタンプが最新の非コア開始タイムスタンプよりも新しいため、最新の行の削除ではなく既に「Ｕ」としてフラグが付けられている。

ステップ１１０
［００２６］例示的な実施形態では、ステップ１１０はＡＬＬ＿ＶＴが有効になっているときに揮発性テーブル名に対して受け入れおよび動作をしてもよい。ステップ１１０は、すべてであるが最新の行が非コア事前期限切れ内に挿入されるであろうことを反映するＸ＿ｔａｂｌｅ内の主キー毎に「Ｕ」に設定される複数の行がある場合終了タイムスタンプを提供する。ステップ１１０は、非コア内の最新の行になることを予定されていないすべての事前期限切れの新しい行の終了タイムスタンプを設定する。ＥＴＬインジケータ「Ｏ」でのすべての行は終了タイムスタンプを必要とし、Ｘ＿ｔａｂｌｅおよび非コア内で最新ではないＥＴＬインジケータ「Ｕ」でのこれら行のみはまた次行の開始タイムスタンプに等しい終了タイムスタンプを取得するであろう。「Ｏ」行は定義により適用フェーズ（例えば、後述の適用ステップ２０４）内で、それらの終了タイムスタンプをその後の非コア行から取得する。このステップはユニオンまたは例外演算子を使用することにより単一のＳＱＬステートメントで達成されることができる。

ステップ１１１
［００２７］例示的な実施形態では、ステップ１１１はＡＬＬ＿ＶＴが有効になっているときに揮発性テーブル名に対して受け入れおよび動作をしてもよい。ステップ１１１は、行の正確な開始タイムスタンプがＸ＿ｔａｂｌｅ内ですべての削除行（「Ｄ」ＥＴＬインジケータ）のために論理的に削除されるように設定しこの値をその行のｓｒｃ＿ｅｎｄ＿ｔｓ列内に格納する。これは、削除が適用されるであろう非コアおよびＸテーブル行から前の行を見つけることにより、有効期限が切れるように単一の非コア行を配置するための適用フェーズ（例えば、後述のステップ２０６）の正確な完全主キーを提供する。最新行および他の事前期限切れＸ＿ｔａｂｌｅ行はアップデートされてもよいが、このアップデートは必須ではなく、他のステップがこれらの行を期限切れとしてもよい。削除行のソース終了タイムスタンプは有効期限が切れるように行のソース開始タイムスタンプであり、そのとき点で存在していた行の終了タイムスタンプになる。例示的な実施形態では、ステップ１１１は、事前ＣＤＣのステップ（例えば、図３に示すステップ９２の前のステップ）が子のカスケードおよび暗示的削除を決定する際に参照整合性を維持する。ステップ１１１は、それにより親レコードがＣＤＣを呼び出す前に正確なタイムスタンプを決定するために事前ＣＤＣ処理を要することなくそれらに適用される対応する過去の削除を有することを確実に容易にする。

ステップ１１２
［００２８］例示的な実施形態では、ステップ１１２はＬＯＡＤ＿ＴＹＰＥ＝Ｓ（スナップショットロード）またはＢ（明示的および暗示的削除両方でのスナップショットロード）およびＡＬＬ＿ＶＴ＝Ｙ（揮発性テーブルを使用）であるときのみ実行される。ステップ１１２は結果データを揮発性Ｘ＿ｔａｂｌｅから、並列セッションがセッション特定の揮発性テーブルを使用するテーブルデータの一意のパーティションを処理することができる実際の（例えば、永続的または「物理的」）Ｘ＿ｔａｂｌｅにロードする。

［００２９］ＬＯＡＤ＿ＴＹＰＥ＝Ｂであるとき、ステップ１１２は現在のパーティション用のＸ＿ｔａｂｌｅ内に既にロードされた明示的な削除を最初に削除する。これらの明示的な削除はステップ１０１で＿ＸＶＴテーブルにロードされ現在の実行中に処理される。これは最初にＸ＿ｔａｂｌｅ内で重複行を防止し未処理の明示的な削除を除去するために行われてもよい。例えば、ＣＤＣはステップ１００の間に目標テーブル内の一致するタイムスタンプをシーケンスおよび設定してもよい。

［００３０］図３に示すように、ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＞１であるとき、ステップ１００から１１２は、１からＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳまでの各パーティションのために適用ステップを実行する前にステップ、パーティション、およびセッションに一致する事前生成されたＳＱＬを使用して繰り返される（例えば、ＳＥＳＳＩＯＮ＿ＰＡＲＡＬＬＥＬＩＳＭパラメータ毎に直列または並列で）。エラーが発生する場合には、フローチャート７０（図３に示す）により示されたプロセスは停止されてもよい。いくつかの実施形態では、実際のＸ＿ｔａｂｌｅ上の統計が最後のパーティションのロード（例えば、ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ＝ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳである）に集計される。

［００３１］図５は、例示的なデータアプリケーションプロセスを示すフローチャート２００である。例示的な実施形態では、以下に説明する適用ステップ２０１〜２０７は、各目標テーブル用に目標テーブル毎に１つの開始で単一のデータベーストランザクション内で一緒に実行される。ステップ２０１〜２０７のすべては単一のマルチステートメント要求にまとめ、エラーチェックを提供されることができ、行数アレイが適切に管理される。ステップが個別に提示されステップでエラーが発生している場合は、適用ステップ２０１〜２０７の実行が中止されてもよく、それ以上のＳＱＬステートメントが提出されなくてもよい。このようなシナリオでは、トランザクション全体がキャンセルされる、または「ロールバックされる」。ソース変換要件に応じて、ＣＤＣプロセスは適用ステップ２０１〜２０７いずれかを開始する前に、ステップ１００から１１２を通して完了するすべてのソーステーブルを待ってもよい。適用ステップは連続クエリアクセス中に目標データベースの参照整合性を最大化するためにすべてのテーブルに対して並列に実行されてもよい。

適用ステップ２０１
［００３２］例示的な実施形態では、適用ステップ２０１は、適用ステップ２０７、下記のＥＮＤ ＴＲＡＮＳＡＣＴＩＯＮステップまでのすべての後続のステップに関連付けられるＳＱＬステートメントが完全に適用されるまたはエラーの場合にはＳＱＬステートメント内のどこにもまったく適用されない、データベーストランザクションを開始する。これは、例えばその行が論理的に削除される限り、ＰＫ＿ｌａｔｅｓｔ毎に多くても１つのソース終了タイムスタンプで、多くても１つのアクティブな行で、有効な状態で目標テーブルをレンダリングするのを容易にする。

適用ステップ２０２
［００３３］適用ステップ２０２は、１つ以上のより新しい行の到達のせいで最新の非コアタイムスタンプを期限切れとさせるＥＴＬインジケータ「Ｕ」のために論理的に削除されたとして行をマークするために両方の終了タイムスタンプ（ソースおよびＣＤＷ）を設定するＰＫ＿ｌａｔｅｓｔ毎の１つの最新アクティブ行（ソース終了タイムスタンプがｎｕｌｌである）をアップデートする。すべて削除またはインジケータ「Ｄ」の処理は適用ステップ２０６で発生する。ステップ２０２で適用される条件は、終了時刻になったＸ＿ｔａｂｌｅソース開始タイムスタンプが少なくとも非コア開始時間（例えば、期間＞０）と同じ大きさであることを含む。

適用ステップ２０３
［００３４］例示的な実施形態では、適用ステップ２０３は新しい行を非コアに挿入するための唯一の適用ステップである。削除を除くＡｌｌ ＥＴＬインジケータは結果として新しい非コア行（Ｉ、ＯおよびＵ）となる。行は事前期限切れ（例えば、Ｘ＿ｔａｂｌｅソース終了タイムスタンプ列が値を有するため）またはそうでなくてもよい。トランザクションまたはＣＤＷタイムスタンプを割り当てることができる任意のステップのように、この値は、一定の開始ＣＤＷタイムスタンプもまた目標テーブル上でのＣＤＣの呼び出しを一意に識別するように、典型的に適用ステップの前に決定されそれぞれに一貫して使用される、適用フェーズの現在のタイムスタンプを表す。

適用ステップ２０４
［００３５］適用ステップ２０４は、適用ステップ２０３（「Ｏ」行の１つのケース）で挿入された新しい行が最新のソース開始タイムスタンプを有しているが、そのタイムスタンプが既に非コア内の最新のソース終了タイムスタンプよりも前のときに、以前の非コア行の終了タイムスタンプを修正する。これは、既に期限切れの行が既存の期限切れタイムスタンプより少ない開始タイムスタンプでシーケンスアップデート外で受信することであり、「Ｏ」行の比較的まれなケースである。

［００３６］適用ステップ２０４のコンピューティングリソース使用率は、目標テーブルが完全に自分自身に結合されていること、テーブルが広範な履歴を有している際に潜在的に大規模なプロセッサの使用率および潜在的な追加スキューに関連付けられている操作を避けるため、Ｘ＿ｔａｂｌｅ上の最新の主キーに対するサブ−クエリを含めることにより低減されてもよい。

適用ステップ２０５
［００３７］適用ステップ２０５はＥＴＬインジケータ「Ο」でマークされた行に対して呼び出される。ステップ２０５は、もしあれば、直前の非コア行を決定するために非コアテーブルにすべてのＸ＿ｔａｂｌｅ「Ο」の行を結合し、ＣＤＷ終了タイムスタンプをアップデートするのと同様に、次にこれらの行を終了タイムスタンプとしてＸ＿ｔａｂｌｅ行の開始タイムスタンプでアップデートする。適用ステップ２０５はソースタイムスタンプ内の別個の非重複期間を提供するために、シーケンスの新しい行外用のソースタイムスタンプをラダーステッピングする処理を終了する。論理的に削除済みとしてマークされた任意の行を除き、ソース開始タイムスタンプはソース開始タイムスタンプにより主キーの残りの部分の中にソートされる際に直前の行（もしあれば）のソース終了タイムスタンプである。

適用ステップ２０６
［００３８］適用ステップ２０６はＥＴＬインジケータ「Ｄ」でマークされた行のために呼び出され、非コアまたはバッチに新たにロードされたものからの過去および現在の行の両方に適用する。このプロセスは、非コアの既存の終了タイムスタンプを削除行の開始タイムスタンプ（例えば、ＥＴＬインジケータ＝「Ｄ」）にアップデートする。Ｘ＿ｔａｂｌｅに直接挿入された行（例えば、親−子暗示的削除）については、行を構築するプリＣＤＣプロセスは終了タイムスタンプがまだ開始タイムスタンプより大きく、後続行のソース開始タイムスタンプより小さいか等しくなるように保証する。

［００３９］一対一の結合を保証するために、非コアの目標行のソース開始タイムスタンプはＸ＿ｔａｂｌｅ内のソース開始タイムスタンプが行の終了タイムスタンプになる目標テーブル内の削除イベントのソースタイムスタンプを記録するために既に使用されるので、Ｘ＿ｔａｂｌｅでｓｒｃ＿ｅｎｄ＿ｔｓ列に格納される。ステップ２０６で具現化されるこの最終条件は、最新の非コア行の論理的な削除に対応し、過去の削除が終了タイムスタンプをアップデートする際に新しい終了タイムスタンプが小さいことを保証するために対応する（例えば、ＰＫ＿ｌａｔｅｓｔ内の行に渡るソースタイムスタンプの開始および終了期間の重複のないことを保証ために、長くするのではなく行のみの寿命または期間を短縮してもよい）。

適用ステップ２０７
［００４０］最終的な適用ステップ２０７は、エラー発生なしで提供される、前の開始トランザクション以降のすべての以前のステートメントのトランザクション範囲を終了する、データベースのトランザクションを終了するためのＳＱＬステートメントを提示する。既に行われていない場合、統計情報はこのとき点で目標テーブル上に収集されるまたは最新の内容にされてもよい。

［００４１］図６〜図２３は、記述された変更データキャプチャシステムに関連付けられる各ステップをさらに説明するデータフロー図である。例えば、図６は、ステップ１００での非コアデータ３０２からの入力データのパーティションのロードに関連するデータフロー図３００である。揮発性テーブル３０４はハッシュ関数に従って非コアデータ３０２からのデータレコードの部分を選択することによりに作成３０６される。さらに、履歴フィルタリングが有効になっている場合（例えば、ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹ＝Ｙ）に、揮発性テーブル３０４を作成３０６することはＷ＿ｔａｂｌｅ３０８内のデータに基づいて非コアデータ３０２からデータレコードを省略することを含んでいてもよい。加えて、履歴フィルタリングが有効になっておりＬＯＡＤ＿ＴＹＰＥ＝Ｂであるとき、Ｘ＿ｔａｂｌｅ３１０はステップ１００への入力として使用されてもよい。

［００４２］以下は、ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹ＝Ｎ、およびＬＯＡＤ＿ＴＹＰＥ＝Ｓであるとき、ステップ１００に関連付けられる擬似コードの例である。

ステップ１００−擬似コード（ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹ＝Ｎ、ＬＯＡＤ＿ＴＹＰＥ＝Ｓ）：
Ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔａｂｌｅ＿ＴＶＴ ａｓ
Ｓｅｌｅｃｔ ＊ ｆｒｏｍ ｔａｒｇｅｔ ｔａｂｌｅ
Ｗｈｅｒｅ ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
Ｐｒｉｍａｒｙ Ｉｎｄｅｘ ＰＫ Ｌａｔｅｓｔ；

以下は、ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹ＝Ｙ、およびＬＯＡＤ＿ＴＹＰＥ＝Ｓであるとき、ステップ１００に関連付けられる擬似コードの例である。

ステップ１００−擬似コード（ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹ＝Ｙ、ＬＯＡＤ＿ＴＹＰＥ＝Ｓ）：
ＷＩＴＨ Ｗ ｔａｂｌｅ ｍｉｎｉｍｕｍ ｐｒｉｍａｒｙ ｋｅｙ ａｎｄ ｓｒｃ ｓｔａｒｔ ＴＳ ｗｈｅｒｅ
ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
Ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔａｂｌｅ＿ＴＶＴ ａｓ
Ｓｅｌｅｃｔ ＊ ｆｒｏｍ ｔａｒｇｅｔ ｔａｂｌｅ
Ｗｈｅｒｅ ｆｕｌｌ ｐｒｉｍａｒｙ ｋｅｙ ｉｎ（
Ｓｅｌｅｃｔ ｎｅｗｅｒ ｒｏｗｓ ｉｎ ｔａｒｇｅｔ ｔａｂｌｅ ｔｈａｎ ｄｅｒｉｖｅｄ Ｗ ｔａｂｌｅ ｗｉｔｈ ｈａｓｈ ｐａｒｔｉｔｉｏｎ
Ｕｎｉｏｎ
Ｓｅｌｅｃｔ ｌａｔｅｓｔ ｏｌｄｅｒ ｒｏｗ ｉｎ ｔａｒｇｅｔ ｔａｂｌｅ ｒｅｌａｔｉｖｅ ｔｏ ｄｅｒｉｖｅｄ Ｗ ｔａｂｌｅ ｗｉｔｈ ｈａｓｈ ｐａｒｔｉｔｉｏｎ
Ｕｎｉｏｎ
Ｓｅｌｅｃｔ ｌａｔｅｓｔ ｒｏｗ ｆｒｏｍ ｔａｒｇｅｔ ｔａｂｌｅ）
Ｗｈｅｒｅ ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
Ｐｒｉｍａｒｙ Ｉｎｄｅｘ ＰＫ Ｌａｔｅｓｔ；

以下は、ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹ＝Ｙ、およびＬＯＡＤ＿ＴＹＰＥ＝Ｂであるとき、ステップ１００に関連付けられる擬似コードの例である。

ステップ１００−擬似コード（ＴＶＴ＿ＦＩＬＴＥＲ＿ＨＩＳＴＯＲＹ＝Ｙ、ＬＯＡＤ＿ＴＹＰＥ＝Ｂ）。
ＷＩＴＨ Ｗ ｔａｂｌｅ ｍｉｎｉｍｕｍ ｐｒｉｍａｒｙ ｋｅｙ ａｎｄ ｓｒｃ ｓｔａｒｔ ＴＳ ｗｈｅｒｅ
ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
Ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔａｂｌｅ＿ＴＶＴ ａｓ
Ｓｅｌｅｃｔ ＊ ｆｒｏｍ ｔａｒｇｅｔ ｔａｂｌｅ
Ｗｈｅｒｅ ｆｕｌｌ ｐｒｉｍａｒｙ ｋｅｙ ｉｎ（
Ｓｅｌｅｃｔ ｎｅｗｅｒ ｒｏｗｓ ｉｎ ｔａｒｇｅｔ ｔａｂｌｅ ｔｈａｎ ｄｅｒｉｖｅｄ Ｗ ｔａｂｌｅ ｗｉｔｈ ｈａｓｈ ｐａｒｔｉｔｉｏｎ
Ｕｎｉｏｎ
Ｓｅｌｅｃｔ ｌａｔｅｓｔ ｏｌｄｅｒ ｒｏｗ ｉｎ ｔａｒｇｅｔ ｔａｂｌｅ ｒｅｌａｔｉｖｅ ｔｏ ｄｅｒｉｖｅｄ Ｗ ｔａｂｌｅ ｗｉｔｈ ｈａｓｈ ｐａｒｔｉｔｉｏｎ
Ｕｎｉｏｎ
Ｓｅｌｅｃｔ ｌａｔｅｓｔ ｒｏｗ ｆｒｏｍ ｔａｒｇｅｔ ｔａｂｌｅ）
Ｏｒ ＰＫ＿Ｌａｔｅｓｔ ｉｎ（ｓｅｌｅｃｔ ＰＫ＿Ｌａｔｅｓｔ ｆｒｏｍ Ｘ ｔａｂｌｅ ｗｈｅｒｅ ＥＴＬ＿Ｉｎｄｉｃａｔｏｒ ｉｓ Ｄ ｆｒｏｍ ｈａｓｈ ｐａｒｔｉｔｉｏｎ）
Ｗｈｅｒｅ ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
Ｐｒｉｍａｒｙ Ｉｎｄｅｘ ＰＫ Ｌａｔｅｓｔ；

図７は、Ｗ＿ｔａｂｌｅ３２２からの入力データのパーティションのローディングをする、ステップ１０１に関連するデータフロー図３２０である。揮発性テーブル＿ＷＶＴ３２４および＿ＸＶＴ３２６が作成３２８される。＿ＷＶＴテーブル３２４はハッシュ関数に従ってＷ＿ｔａｂｌｅ３２２からデータレコードの部分を選択することによりロードされる。ＬＯＡＤ＿ＴＹＰＥ＝Ｂであるとき、Ｘ＿ｔａｂｌｅ３３０からの「Ｄ」行は揮発性テーブル＿ＸＶＴ３２６にロード３３２される。

以下は、ＬＯＡＤ＿ＴＹＰＥ＝Ｓであるとき、ステップ１０１に関連付けられる擬似コードの例である。

ステップ１０１−擬似コード（ＬＯＡＤ＿ＴＹＰＥ＝Ｓ）：
Ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔａｂｌｅ＿ＷＶＴ ａｓ
Ｓｅｌｅｃｔ ＊ ｆｒｏｍ Ｗ ｔａｂｌｅ
Ｗｈｅｒｅ ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
Ｐｒｉｍａｒｙ Ｉｎｄｅｘ ＰＫ Ｌａｔｅｓｔ；

Ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔａｂｌｅ＿ＸＶＴ ａｓ
Ｘ ｔａｂｌｅ ｗｉｔｈ ｎｏ ｄａｔａ
Ｐｒｉｍａｒｙ Ｉｎｄｅｘ ＰＫ Ｌａｔｅｓｔ；

以下は、ＬＯＡＤ＿ＴＹＰＥ＝Ｂであるとき、ステップ１０１に関連付けられる擬似コードの例である。

ステップ１０１−擬似コード（ＬＯＡＤ＿ＴＹＰＥ＝Ｂ）。
Ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔａｂｌｅ＿ＷＶＴ ａｓ
Ｓｅｌｅｃｔ ＊ ｆｒｏｍ Ｗ ｔａｂｌｅ
Ｗｈｅｒｅ ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
Ｐｒｉｍａｒｙ Ｉｎｄｅｘ ＰＫ Ｌａｔｅｓｔ；

Ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔａｂｌｅ＿ＸＶＴ ａｓ
Ｘ ｔａｂｌｅ ｗｉｔｈ ｎｏ ｄａｔａ
Ｐｒｉｍａｒｙ Ｉｎｄｅｘ ＰＫ Ｌａｔｅｓｔ；

Ｉｎｓｅｒｔ ｉｎｔｏ＿ＸＶＴ（ＰＫ，４ ｒｏｗ ｍａｒｋｉｎｇ ｃｏｌｕｍｎｓ）
Ｓｅｌｅｃｔ ＰＫ，４ ｒｏｗ ｍａｒｋｉｎｇ ｃｏｌｕｍｎｓ ｆｒｏｍ Ｘ ｔａｂｌｅ
Ｗｈｅｒｅ ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＰＫ Ｌａｔｅｓｔ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝ＣＵＲＲＥＮＴ＿ＰＡＲＴＩＴＩＯＮ
ＡＮＤ ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｄ’

図８は、暗示的削除用のＸ＿ｔａｂｌｅ行の構築をする、ステップ１０２に関連するデータフロー図３４０である。図３４０は、非コアデータ３４２からの行がもはやＷ＿ｔａｂｌｅ３４４に表示されない場合、それがソースから削除されたことを想定していることを示す。行は「現在の」非コア主キーがＷ＿ｔａｂｌｅ３４４内にない非コアデータ３４２、現在のタイムスタンプ、およびＥＴＬ＿Ｉｎｄｉｃａｔｏｒ「Ｄ」から最新の主キー（ＰＫ＿ｌａｔｅｓｔ）でＸ＿ｔａｂｌｅ３４８に挿入３４６される。これはテーブルが親に依存しない単純なケースである。

以下は、ステップ１０２に関連付けられる擬似コードの例である。

ステップ１０２−擬似コード：
Ｉｎｓｅｒｔ ｉｎｔｏ Ｘ＿ｔａｂｌｅ
Ｓｅｌｅｃｔ［＊，Ｃｕｒｒｅｎｔ＿Ｔｉｍｅｓｔａｍｐ，‘Ｄ’］ｆｒｏｍ ｔａｒｇｅｔ
ＷＨＥＲＥ ＰＫ−Ｌａｔｅｓｔ ＮＯＴ ＩＮ
（Ｓｅｌｅｃｔ［ＰＫ＿Ｌａｔｅｓｔ］ｆｒｏｍ Ｗ−ｔａｂｌｅ）；

図９は、ステップ１０３に関連付けられるデータフロー図３６０である。Ｗ＿ｔａｂｌｅ３６２内のデータレコードは変更されていないより新しい行の主キー３６６を識別するために非コアデータ内のデータレコード３６４と比較される。同一コンテンツでの最先の入力データ行のこれらの主キーは揮発性テーブル＿ＫＶＴ３６８に格納される。

以下は、ステップ１０３に関連付けられる擬似コードの例である。

ステップ１０３−擬似コード：
Ｃｒｅａｔｅ ＶＴ ｏｆ Ｗ ｔａｂｌｅ ｆｕｌｌ ＰＫ’ｓ ｔｏ ｅｘｃｌｕｄｅ ｉｎ ｓｔｅｐ １０４
Ｓｅｌｅｃｔ ｆｕｌｌ ＰＫ ｆｒｏｍ Ｗ ｔａｂｌｅ
Ｗｈｅｒｅ ｆｕｌｌ ＰＫ ｉｎ（
Ｓｅｌｅｃｔ ｅａｒｌｉｅｓｔ ｆｕｌｌ ＰＫ ｒｏｗ ｆｒｏｍ Ｗ ｔａｂｌｅ ｊｏｉｎｅｄ ｔｏ ｔａｒｇｅｔ ｔａｂｌｅ
Ｗｈｅｒｅ ｔａｒｇｅｔ ｔａｂｌｅ ｉｓ ｌａｔｅｓｔ ｒｏｗ ａｎｄ Ｗ ｔａｂｌｅ ｉｓ ｎｅｘｔ ｎｅｗｅｓｔ ｒｏｗ
Ａｎｄ ａｌｌ ａｔｔｒｉｂｕｔｅｓ ｏｆ ｂｏｔｈ ｒｏｗｓ ａｒｅ ｉｄｅｎｔｉｃａｌ ｅｘｃｌｕｄｉｎｇ ｓｏｕｒｃｅ ＴＳ

図１０は、非別個の完全な主キーのシーケンスである、新しいおよび変更されたレコードのＸ＿ｔａｂｌｅ行の構築をする、およびＸ＿ｔａｂｌｅ３８２の統計情報の収集をする、ステップ１０４に関連するデータフロー図３８０である。少なくとも１つの列が新しいデータ履歴がＸ＿ｔａｂｌｅにロードされることを可能にする非コアデータ３８６内のすべての他の行と異なる場合、行はＸ＿ｔａｂｌｅ３８２に挿入３８４される。すべてのＷ＿ｔａｂｌｅ３８８行がすべての非コア３８６の行をマイナスする（ＳＱＬ ｅｘｃｅｐｔ）のを選択することにより、デフォルトＥＴＬインジケータがＩに設定される。変更データキャプチャシステム、および主キーの整合性は、データ内で保証される場合は常に必要とされなくてもよいそのようなステップを要求する。１マイクロ秒はＰＫ＿ｌａｔｅｓｔ内のｎ番目の行の秒のためにＷ＿ｔａｂｌｅ３８８内でｓｒｃ＿ｓｔａｒｔ＿ｔｓタイムスタンプに追加される。同様に、任意のタイムスタンプシーケンシングのために予約されているソースタイムスタンプの最後の３つのサブ秒桁がＷ＿ｔａｂｌｅおよびノンコア間の変化の比較から除外される。

以下は、ステップ１０４に関連付けられる擬似コードの例である。

ステップ１０４−擬似コード：
Ｉｎｓｅｒｔ ｉｎｔｏ Ｘ＿ｔａｂｌｅ
Ｓｅｌｅｃｔ［＊］ｆｒｏｍ Ｗ＿ｔａｂｌｅ−−１ ｍｉｃｒｏｓｅｃｏｎｄ ｓｅｑｕｅｎｃｉｎｇ ａｄｄｅｄ ｔｏ ｓｔａｒｔ ＴＳ
Ｗｈｅｒｅ ＊ ｎｏｔ ｉｎ（−−ｅｘｃｌｕｄｅ ｍｉｃｒｏｓｅｃｏｎｄ ｓｅｑｕｅｎｃｉｎｇ ｗｈｅｎ ｓｅｌｅｃｔｉｎｇ ｓｔａｒｔ ＴＳ
Ｓｅｌｅｃｔ［＊］ｆｒｏｍ ｔａｒｇｅｔ）；−−ｅｘｃｌｕｄｅ ｎｓ ｓｅｑｕｅｎｃｉｎｇ ｗｈｅｎ ｓｅｌｅｃｔｉｎｇ ｓｔａｒｔ ＴＳ
Ｃｏｌｌｅｃｔ ｓｔａｔｉｓｔｉｃｓ ｏｎ Ｘ＿ｔａｂｌｅ；

さらに、ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｙであるとき、上記のように＿ＫＶＴテーブル３９０はステップ１０３で主キーを事前設定されてもよい。このようなシナリオでは、ステップ１０４は＿ＫＶＴテーブル３９０に表示される主キーに関連付けられたデータレコードを除外する（例えば、Ｘ＿ｔａｂｌｅ３８２内には挿入３８４しない）。

図１１は、ステップ１０５に関連付けられたデータフロー図４００である。Ｘ＿Ｔａｂｌｅ４０４に表示されるＰＫ＿Ｌａｔｅｓｔに関連付けられる非コアデータ４０２内のデータレコードは、非コアデータ４０２内のソース開始タイムスタンプに基づいてフィルタリングされ揮発性目標テーブル４０８に挿入４０６される。

以下は、ステップ１０５に関連付けられる擬似コードの例である。

ステップ１０５−擬似コード：
Ｉｎｓｅｒｔ ｉｎｔｏ Ｔａｒｇｅｔ＿Ｔａｂｌｅ＿ＶＴ（ｃｒｅａｔｅ ｖｏｌａｔｉｌｅ ｔｅｍｐｏｒａｒｙ ｔａｂｌｅ ｖｉａ ｓｅｌｅｃｔ ｓｔａｔｅｍｅｎｔ）
Ｓｅｌｅｃｔ ＊ ｆｒｏｍ Ｔａｒｇｅｔ Ｔａｂｌｅ ｗｈｅｒｅ
ＰＫ＿Ｌａｔｅｓｔ ｉｎ（ｓｅｌｅｃｔ ＰＫ＿Ｌａｔｅｓｔ ｆｒｏｍ Ｘ＿ｔａｂｌｅ）
Ａｎｄ（ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ＞＝ＭＩＮ ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ ｉｎ Ｘ ｔａｂｌｅ ｆｏｒ ｔｈａｔ ｅｘａｃｔ ＰＫ
ＯＲ ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ ｉｓ ＭＡＸ ｆｏｒ ＰＫ＜ＭＩＮ ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ ｉｎ Ｘ）

図１２は、既存の非コア４２４行を順番にアップデートするであろうＸ＿ｔａｂｌｅ４２２行の再シーケンシングをする、ステップ１０６に関連するデータフロー図４２０である。ステップ１０６の意図は同じＰＫ内の別の同一の開始タイムスタンプ（最後の３つのサブ秒桁を除く）ですべてのＸ＿ｔａｂｌｅ「Ｉ」行に最大の非コアスタンプ（ＴＳ＿ｍｉｃｒｏｓｅｃｏｎｄｓ）を加えることにより、Ｘ＿ｔａｂｌｅ４２２に関連付けられるソース開始タイムスタンプをアップデートすることである。既存の行と同じタイムスタンプ（ＴＳ）を有する、主キー（ＰＫ）のための新しい、シーケンスされた（ステップ１０４で）行４２６が受信された場合、新しい行が非コア行４２４の後にシーケンスに落ちることが保証される。

以下は、ステップ１０６に関連付けられる擬似コードの例である。

ステップ１０６−擬似コード：
ＵＰＤＡＴＥ Ｘ−ａｌｉａｓ
ＦＲＯＭ Ｘ−ｔａｂｌｅ Ｘ−ａｌｉａｓ
，（ＳＥＬＥＣＴ
ＰＫ＿Ｌａｔｅｓｔ
，ＣＡＳＴ（ＭＡＸ（ｓｒｃ＿ｓｔａｒｔ＿ｔｓ）ａｓ ｃｈａｒ（２３））Ｆ２３Ｃ
，ｓｕｂｓｔｒｉｎｇ（ｃａｓｔ（ｍａｘ（ｓｏｕｒｃｅ＿ｓｔａｒｔ＿ｔｓ）ａｓ ｃｈａｒ（２６））ｆｒｏｍ ２４ ｆｏｒ ３）＋１ Ｌ３Ｃ
，ｓｕｂｓｔｒｉｎｇ（ｃａｓｔ（ｓｏｕｒｃｅ＿ｓｔａｒｔ＿ｔｓ ａｓ ｃｈａｒ（３２）），ｆｒｏｍ ２７ ｆｏｒ ６）＋１ Ｌ３Ｃ
ＦＲＯＭ ｔａｒｇｅｔ
ＧＲＯＵＰ ＢＹ ＰＫ＿Ｌａｔｅｓｔ，Ｆ２３Ｃ，ＴＳＴＺ）ＱＱＱ
ＳＥＴ ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ
＝Ｆ２３Ｃ｜｜ＳＵＢＳＴＲＩＮＧ（ＣＡＳＴ（（Ｌ３Ｃ／１０００＋
（ＳＵＢＳＴＲＩＮＧ（ｃａｓｔ（ｘｐｍ．ｓｒｃ＿ｓｔａｒｔ＿ｔｓ ａｓ ｃｈａｒ（２６））ＦＲＯＭ ２４ ＦＯＲ ３））／１０００）ＡＳ ＤＥＣ（４，３））ＦＲＯＭ
４ ＦＯＲ ３）
ＷＨＥＲＥ Ｘ−ａｌｉａｓ．ＰＫ＿Ｌａｔｅｓｔ＝ＱＱＱ．ＰＫ＿Ｌａｔｅｓｔ
ＡＮＤ ＣＡＳＴ（Ｘ−ａｌｉａｓ．ｓｒｃ＿ｓｔａｒｔ＿ｔｓ ＡＳ ＣＨＡＲ（２３））＝ＱＱＱ．Ｆ２３Ｃ
ＡＮＤ Ｘ−ａｌｉａｓ．ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｉ’；

図１３は、ユニオン、例えば、Ｘ＿ｔａｂｌｅ４４２および非コアテーブル４４４および付加的にＸ＿ｔａｂｌｅ４４６および非コアテーブル４４８のユニオン内で、連続した冗長Ｘ＿ｔａｂｌｅ行のドロップを行う、ステップ１０７に関連付けられたデータフロー図４４０である。２つのユニオンは主キー上でシーケンス行に結合され、すべての非キー属性に関して複製され次に最新の目標テーブルＰＫに結合される連続した行の検出を可能にする。ステップ１０７は、同一のデータを含む行が複数回ロードされた際にリソースが浪費されるという認識を表し、一時的な期間の圧縮ユニットを実装する。しかしながら、データ内で「Ａ」から「Ｂ」、次に「Ａ」に戻る任意の変更を記録することがそれでもなお望ましい。したがって、開始タイムスタンプを除く各個別行の最初のインスタンスはＸ＿ｔａｂｌｅ４５０に保持される。より具体的には、ＰＫ＿ｌａｔｅｓｔが同じ場合、およびＰＫ＿Ｌａｔｅｓｔ内、Ｘ＿ｔａｂｌｅおよび非コアテーブルのユニオン内のソース開始タイムスタンプによりソートされた際にタイムスタンプを除くすべての列が前の行と同じ場合、Ｘ＿ｔａｂｌｅ４５０内のデータは削除される。

例示的な実施形態では、Ｘ＿ｔａｂｌｅ４５２および非コアテーブル４５４の付加的な結合（テーブルＣというエイリアス）は、論理的に削除され最新Ｘ＿ｔａｂｌｅ行と比較するために開始日付（またはそのような行が存在しない場合には２５００年）および終了日付を返す場合であっても、最新のソース開始タイムスタンプを見つけるために含まれる。

以下は、ステップ１０７に関連付けられる擬似コードの例である。

ステップ１０７−擬似コード：
Ｄｅｌｅｔｅ ｆｒｏｍ Ｘ＿ｔａｂｌｅ ｗｈｅｒｅ ＰＫ ＩＮ（
（Ｓｅｌｅｃｔ ＰＫ ｆｒｏｍ
（Ｓｅｌｅｃｔ Ａ．＊ ｆｒｏｍ
（Ｓｅｌｅｃｔ ＊，ｔａｂｌｅ＿ｓｏｕｒｃｅ，Ｒｏｗ＿Ｎｕｍｂｅｒ（）ｆｒｏｍ Ｘ＿ｔａｂｌｅ ｕｎｉｏｎ ｎｏｎｃｏｒｅ
ｐａｒｔｉｔｉｏｎ ｂｙ ＰＫ＿Ｌａｔｅｓｔ Ｏｒｄｅｒ ｂｙ ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ ｔｏ ｃｒｅａｔｅ Ｒｏｗ＿Ｎｕｍｂｅｒ）Ａ
ＩＮＮＥＲ ＪＯＩＮ （Ｓｅｌｅｃｔ ＊，ｔａｂｌｅ＿ｓｏｕｒｃｅ，Ｒｏｗ＿Ｎｕｍｂｅｒ（）ｆｒｏｍ Ｘ＿ｔａｂｌｅ ｕｎｉｏｎ ｎｏｎｃｏｒｅ
ｐａｒｔｉｔｉｏｎ ｂｙ ＰＫ＿Ｌａｔｅｓｔ Ｏｒｄｅｒ ｂｙ ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ ｔｏ ｃｒｅａｔｅ Ｒｏｗ＿Ｎｕｍｂｅｒ）Ｂ
Ｗｈｅｒｅ Ａ．ＰＫ＿Ｌａｔｅｓｔ＝Ｂ．ＰＫ＿Ｌａｔｅｓｔ
ａｎｄ Ｂ．Ｒｏｗ＿Ｎｕｍｂｅｒ＝Ａ．Ｒｏｗ＿Ｎｕｍｂｅｒ−１
ａｎｄ ａｌｌ ｎｏｎ−ｋｅｙ ａｔｔｒｉｂｕｔｅ ａｒｅ ｔｈｅ ｓａｍｅ （ｖａｌｕｅｓ ｅｑｕａｌ ｏｒ ｂｏｔｈ ｎｕｌｌ）
）
ＡＮＤ Ａ．Ｔａｂｌｅ Ｓｏｕｒｃｅ＝‘Ｘ’
Ｌｅｆｔ Ｏｕｔｅｒ Ｊｏｉｎ（Ｓｅｌｅｃｔ ＰＫ＿Ｌａｔｅｓｔ，Ｉｆ ｎｏｔ ｎｕｌｌ ｔｈｅｎ Ｓｏｕｒｃｅ Ｓｔａｒｔ ＴＳ ｅｌｓｅ Ｙｅａｒ ２５００，
ＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ
Ｆｒｏｍ Ｔａｒｇｅｔ ｐａｒｔｉｔｉｏｎ ＰＫ＿Ｌａｔｅｓｔ ａｎｄ ｐｒｅｓｅｎｔ ｎｅｗｅｓｔ Ｓｏｕｒｃｅ Ｓｔａｒｔ ｔｓ）Ｃ ＯＮ Ａ．ＰＫ＿Ｌａｔｅｓｔ＝Ｃ．ＰＫ＿Ｌａｔｅｓｔ
ＷＨＥＲＥ（Ｂ．Ｔａｂｌｅ Ｓｏｕｒｃｅ＝‘Ｘ’
ＡＮＤ Ａ．Ｔｉｍｅ ｐｅｒｉｏｄ ｉｓ ｎｅｗｅｒ ｔｈａｎ ｔｈｅ ｌａｔｅｓｔ ｔａｒｇｅｔ ｒｏｗ

図１４は、非コアデータ４６４内の現在の行へのアップデートであるＸ＿ｔａｂｌｅ４６２の行のマーキングをする、ステップ１０８に関連するデータフロー図４６０である。ステップ１０８では、Ｘ＿ｔａｂｌｅをアップデート４６６するために、ＥＴＬ＿Ｉｎｄｉｃａｔｏｒは入力ソースタイムスタンプが非コアテーブル内の最新のソースタイムスタンプより大きい既存の非コア「現在」行をアップデートする「Ｉ」行上で「Ｕ」に設定される。本明細書に記述する適用ステップ２０２では、これらの 「Ｕ」行の最先の開始タイムスタンプは最新の非コア行を期限切れにするため主キー内で使用される。

以下は、ステップ１０８に関連付けられる擬似コードの例である。

ステップ１０８−擬似コード：
ＵＰＤＡＴＥ Ｘ＿ｔｂｌ
ＦＲＯＭ Ｘ＿ＴＡＢＬＥ Ｘ＿ｔｂｌ
，（ｓｅｌｅｃｔ ＰＫ＿Ｌａｔｅｓｔ
，ｍａｘ（ｓｒｃ＿ｓｔａｒｔ＿ｔｓ）ｓｒｃ＿ｓｔａｒｔ＿ｔｓ
ｆｒｏｍ ｔａｒｇｅｔ
ｇｒｏｕｐ ｂｙ ＰＫ＿Ｌａｔｅｓｔ）ＮＣ＿ｔｂｌ
ＳＥＴ ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｕ’
ＷＨＥＲＥ Ｘ＿ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ＝ＮＣ＿ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ
ＡＮＤ Ｘ＿ｔｂｌ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ＞ＮＣ＿ｔｂｌ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ
ＡＮＤ Ｘ＿ｔｂｌ．ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｉ’；

図１５は、非コアデータ４８４内の「過去」行へのアップデートであるＸ＿ｔａｂｌｅ４８２内の行のマーキングをする、ステップ１０９を示すデータフロー図４８０である。フロー図４８０は、シーケンス外で適用されるアップデートに関する。ステップ１０９では、Ｘ＿ｔａｂｌｅ４８２内のデータをアップデート４８６するために、ＥＴＬ＿Ｉｎｄｉｃａｔｏｒは既存の非コア「履歴」行のアップデートのためにＩまたはＵに以前設定した行で「Ｏ」に設定される。そのような行では、入力ソースタイムスタンプは、一度Ｘ＿ｔａｂｌｅおよびノンコアテーブル行全体が考慮されると、非コア行内の最新のソース開始スタンプよりも小さい。これは、ＰＫ＿Ｌａｔｅｓｔ毎の全体的な最大値を達成するために非コアおよびＸ＿ｔａｂｌｅの両方からのタイムスタンプの比較を組み合わせることにより達成される。あるいは、入力ソースタイムスタンプは最新のソース終了タイムスタンプよりも小さいので、したがって行が事前期限切れでなければならない。これらの「Ｏ」行は履歴的なシーケンスを修正するために非コアデータ内の終了タイムスタンプをアップデートする。これらのアップデートはタイムシーケンス外で適用されているので、ほとんどがステップ１１０内の次の行の終了タイムスタンプを取得する。その他は適用ステップ２０４の終了タイムスタンプを取得する。

以下は、ステップ１０９に関連付けられている擬似コードの例である。

ステップ１０９−擬似コード：
ＵＰＤＡＴＥ Ｘ＿ｔｂｌ
ＦＲＯＭ Ｘ＿ＴＡＢＬＥ Ｘ＿ｔｂｌ
，（ｓｅｌｅｃｔ ＰＫ＿Ｌａｔｅｓｔ
，ｍａｘ（ｓｒｃ＿ｅｎｄ＿ｔｓ）ｍａｘ＿ｅｎｄ＿ｔｓ
，ｍａｘ（ｓｒｃ＿ｓｔａｒｔ＿ｔｓ）ｍａｘ＿ｓｔａｒｔ＿ｔｓ
ｆｒｏｍ ｔａｒｇｅｔ
ｇｒｏｕｐ ｂｙ ＰＫ＿Ｌａｔｅｓｔ）Ｍａｘ＿ｔｂｌ
ＳＥＴ ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｏ’
ＷＨＥＲＥ Ｘ＿ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ＝Ｍａｘ＿ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ
ＡＮＤ （（Ｘ＿ｔｂｌ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ＜Ｍａｘ＿ｔｂｌ．ＭＡＸ＿ＥＮ Ｄ＿ＴＳ
ＯＲ（Ｘ＿ｔｂｌ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ＜Ｍａｘ＿ｔｂｌ．ＭＡＸ＿ＳＴＡＲＴ＿ＴＳ））
ＡＮＤ Ｘ＿ｔｂｌ．ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ ＩＮ（‘Ｉ’，‘Ｕ’）；

図１６は、非コアまたはＸ＿ｔａｂｌｅ内で既にアップデートされたＸ＿ｔａｂｌｅ行（「Ｏ」または「Ｕ」）の期限切れをする、ステップ１１０を示すデータフロー図５００である。Ｘ＿ｔａｂｌｅ行の終了タイムスタンプは前の行の開始タイムスタンプ（非コアまたはＸ＿ｔａｂｌｅ内のいずれか）に設定される。ＥＴＬ＿Ｉｎｄｉｃａｔｏｒが「Ｏ」に設定されている行はロードする履歴のアップデートを可能にする。これらは主キー内の最新の行ではない入力行であり、すなわち、それらはユニオン５０６を介してＸ＿ｔａｂｌｅ５０２および非コア５０４に渡って既にアップデートされている。それらはそれらの終了タイムスタンプに基づいて履歴行として非コアデータ内に挿入される。

以下は、ステップ１１０に関連付けられる擬似コードの例である。

ステップ１１０−擬似コード：
Ｕｐｄａｔｅ Ｘ−ｔｂｌ
ＦＲＯＭ Ｘ−ｔａｂｌｅ Ｘ−ｔｂｌ
，（Ｓｅｌｅｃｔ ＡＡＡ．ＰＫ−Ｌａｔｅｓｔ， ｍｉｎ（ＢＢＢ．ＳＴＡＲＴ＿ＴＳ）ａｓ ＥＮＤ＿ＴＳ
Ｆｒｏｍ （Ｓｅｌｅｃｔ ＰＫ
Ｆｒｏｍ Ｘ−ｔａｂｌｅ）ＡＡＡ，
（Ｓｅｌｅｃｔ ＰＫ
Ｆｒｏｍ Ｘ−ｔａｂｌｅ
ＵＮＩＯＮ
Ｓｅｌｅｃｔ ＰＫ
Ｆｒｏｍ ｔａｒｇｅｔ）ＢＢＢ
Ｗｈｅｒｅ ＢＢＢ．ＰＫ＿Ｌａｔｅｓｔ＝ＡＡＡ．ＰＫ＿Ｌａｔｅｓｔ
Ａｎｄ ＢＢＢ．ＳＴＡＲＴ＿ＴＳ＞ＡＡＡ．ＳＴＡＲＴ＿ＴＳ
Ｇｒｏｕｐ Ｂｙ ＡＡＡ．ＰＫ
）ＱＱＱ
ＳＥＴ ＥＮＤ＿ＴＳ＝ＱＱＱ．ＥＮＤ＿ＴＳ
ＷＨＥＲＥ Ｘ−ｔａｂｌｅ．ＰＫ＝ＱＱＱ．ＰＫ
ａｎｄ Ｘ−ｔａｂｌｅ．ＥＴＬ＿Ｉｎｄｉｃａｔｏｒ ＩＮ（‘Ｏ’，‘Ｕ’）；

図１７は、論理的削除が適用する最新の非コア行のタイムスタンプを見つけることによりすべての削除行（「Ｄ」のＥＴＬ＿Ｉｎｄｉｃａｔｏｒ）用の完全キー（ソース開始タイムスタンプで）の提供をする、ステップ１１１を示すデータフロー図５２０である。より具体的には、終了タイムスタンプは削除タイムスタンプに基づいて直前のＸ＿ｔａｂｌｅ行または非コア行の開始タイムスタンプにＸ＿ｔａｂｌｅ行上で設定される。論理的に削除されるこれらの行は、既に用意された親−子に加えて変更データキャプチャの前の暗示的またはカスケード削除行である。このようなケースは適用ステップ２０６で実行される。

以下は、ステップ１１１に関連付けられる擬似コードの例である。

ステップ１１１−擬似コード：
Ｕｐｄａｔｅ Ｘ−ｔｂｌ
ＦＲＯＭ Ｘ−ｔａｂｌｅ Ｘ−ｔｂｌ
，（Ｓｅｌｅｃｔ ＡＡＡ．ＰＫ−Ｌａｔｅｓｔ，ｍｉｎ（ＢＢＢ．ＳＴＡＲＴ＿ＴＳ）ａｓ ＥＮＤ＿ＴＳ
Ｆｒｏｍ（Ｓｅｌｅｃｔ ＰＫ
Ｆｒｏｍ Ｘ−ｔａｂｌｅ）ＡＡＡ，
（Ｓｅｌｅｃｔ ＰＫ，Ｍａｘ Ｓｔａｒｔ ＴＳ
Ｆｒｏｍ Ｘ−ｔａｂｌｅ
ＵＮＩＯＮ
Ｓｅｌｅｃｔ ＰＫ，Ｍａｘ Ｓｔａｒｔ ＴＳ
Ｆｒｏｍ ｔａｒｇｅｔ）ＢＢＢ
Ｗｈｅｒｅ ＢＢＢ．ＰＫ＿Ｌａｔｅｓｔ＝ＡＡＡ．ＰＫ＿Ｌａｔｅｓｔ
Ａｎｄ ＢＢＢ．ＳＴＡＲＴ＿ＴＳ＞ＡＡＡ．ＳＴＡＲＴ＿ＴＳ
Ｇｒｏｕｐ Ｂｙ ＡＡＡ．ＰＫ，ＢＢＢ．Ｍａｘ Ｓｔａｒｔ ＴＳ
）ＱＱＱ
ＳＥＴ ＥＮＤ＿ＴＳ＝ＱＱＱ．ＥＮＤ＿ＴＳ
ＷＨＥＲＥ Ｘ−ｔａｂｌｅ．ＰＫ＝ＱＱＱ．ＰＫ ａｎｄ Ｘ−ｔａｂｌｅ．Ｓｔａｒｔ ＴＳ＜ＱＱＱ．Ｓｔａｒｔ ＴＳ
ａｎｄ Ｘ−ｔａｂｌｅ．ＥＴＬ＿ｌｎｄｉｃａｔｏｒ＝‘Ｄ’；

図１８は、＿ＸＶＴテーブル５４４からＸ＿ｔａｂｌｅ５４６にデータレコードの挿入５４２をする、ステップ１１２を示すデータフロー図５４０である。データがＸ＿Ｔａｂｌｅ５４６に挿入５４２された後、ステップ１１２はパーティション用に作成されたすべての揮発性テーブルをドロップ５４８することを含む。特定の場合（例えば、ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｎ、およびＬＯＡＤ＿ＴＹＰＥ＝Ｂであるとき）、ステップ１１２は現在のパーティションにある「Ｄ」のＥＴＬインジケータでＸ＿ｔａｂｌｅ５４６内の行を削除５５０することを含んでいてもよい。

以下は、ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｎ、およびＬＯＡＤ＿ＴＹＰＥ＝Ｓであるときにステップ１１２に関連付けられる擬似コードの例である。

ステップ１１２−擬似コード（ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｎ、ＬＯＡＤ＿ＴＹＰＥ＝Ｓ）：
ＩＮＳＥＲＴ ＩＮＴＯ Ｘ−ｔａｂｌｅ ＳＥＬＥＣＴ ＊ ＦＲＯＭ＿ＸＶＴ；

ＤＲＯＰ ＴＡＢＬＥ＿ＸＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＷＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＴＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＶＴ；

ＣＯＬＬＥＣＴ ＳＴＡＴＩＳＴＩＣＳ Ｘ−ｔａｂｌｅ；（ｌａｓｔ ｐａｒｔｉｔｉｏｎ ｏｎｌｙ）

以下は、ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｙ、およびＬＯＡＤ＿ＴＹＰＥ＝Ｓであるときにステップ１１２に関連付けられる擬似コードの例である。

ステップ１１２−擬似コード（ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｙ、ＬＯＡＤ＿ＴＹＰＥ＝Ｓ）：
ＩＮＳＥＲＴ ＩＮＴＯ Ｘ−ｔａｂｌｅ ＳＥＬＥＣＴ ＊ ＦＲＯＭ＿ＸＶＴ；

ＤＲＯＰ ＴＡＢＬＥ＿ＸＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＷＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＴＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＫＶＴ

ＣＯＬＬＥＣＴ ＳＴＡＴＩＳＴＩＣＳ Ｘ−ｔａｂｌｅ；（ｌａｓｔ ｐａｒｔｉｔｉｏｎ ｏｎｌｙ）

以下は、ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｎ、およびＬＯＡＤ＿ＴＹＰＥ＝Ｂであるときにステップ１１２に関連付けられる擬似コードの例である。

ステップ１１２−擬似コード（ＮＯＲＭＡＬＩＺＥ＿ＬＡＴＥＳＴ＝Ｎ、ＬＯＡＤ＿ＴＹＰＥ＝Ｂ）
ＤＥＬＥＴＥ ＦＲＯＭ Ｘ−ｔａｂｌｅ
ＷＨＥＲＥ ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｄ’
ＡＮＤ ＨＡＳＨＢＵＣＫＥＴ（ＨＡＳＨＲＯＷ（ＵＳＡＧＥ＿ＩＮＳＴＡＮＣＥ＿ＮＵＭ＿ＩＤ））ＭＯＤ ＮＵＭ＿ＰＡＲＴＩＴＩＯＮＳ＝０；
ＩＮＳＥＲＴ ＩＮＴＯ Ｘ−ｔａｂｌｅ ＳＥＬＥＣＴ ＊ ＦＲＯＭ＿ＸＶＴ

ＤＲＯＰ ＴＡＢＬＥ＿ＸＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＷＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＴＶＴ；
ＤＲＯＰ ＴＡＢＬＥ＿ＶＴ；

ＣＯＬＬＥＣＴ ＳＴＡＴＩＳＴＩＣＳ Ｘ−ｔａｂｌｅ；（ｌａｓｔ ｐａｒｔｉｔｉｏｎ ｏｎｌｙ）

最初の適用ステップ、ステップ２０１は適用ステップ２０７、ＥＮＤ ＴＲＡＮＳＡＣＴＩＯＮまでの後続のすべてのＳＱＬステートメントがステートメント内のどこでも完全に適用されるかまたはエラーが発生した場合にはまったく適用されないことを保証する。これは有効な状態（例えば、その行が論理的に削除されていない限り、ＰＫ＿ｌａｔｅｓｔ毎にせいぜい１つのＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ、せいぜい１つのアクティブな行）で目標テーブルを残すことが必要である。

以下は、適用ステップ２０１に関連付けられる擬似コードの例である。

ステップ２０１ 擬似コード：
ＳＴＡＲＴ ＴＲＡＮＳＡＣＴＩＯＮ

図１９は、アップデートされた非コア６０２行の以前のバージョンの期限切れである、適用ステップ２０２を示すデータフロー図６００である。非コア行をアップデートするために、終了タイムスタンプはＥＴＬインジケータが「Ｕ」に設定されているＸ＿ｔａｂｌｅ６０６から最新の主キー内でｎｕｌｌから最先の後継行の開始タイムスタンプにアップデート６０４される。このステップは、アップデート用の最新の非コア行の終了タイムスタンプを設定することを、次の行の開始タイムスタンプである１行の終了タイムスタンプでカバーする。

以下は、適用ステップ２０２に関連付けられる擬似コードの例である。

ステップ２０２−擬似コード
ＵＰＤＡＴＥ ｎｏｎｃｏｒｅ
ＳＥＴ ＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ＝ＭＩＮ（Ｘ−ｔａｂｌｅ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ）
ＣＤＷ＿ＥＮＤ＿ＴＳ＝ｃｕｒｒｅｎｔ ｔｉｍｅｓｔａｍｐ ｆｏｒ ｔａｂｌｅ
ＷＨＥＲＥ ｎｏｎｃｏｒｅ．ＰＫ＿Ｌａｔｅｓｔ＝Ｘ−ｔａｂｌｅ．ＰＫ＿Ｌａｔｅｓｔ
ＡＮＤ ＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ ＩＳ ＮＵＬＬ
ＡＮＤ Ｘ−ｔａｂｌｅ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ＞＝ｎｏｎｃｏｒｅ．ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ
ＡＮＤ Ｘ−ｔａｂｌｅ．ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｕ’
ＡＮＤ ｓｒｃ＿ｓｔａｒｔ＿ｔｓ ｉｓ ｔｈｅ ｅａｒｌｉｅｓｔ ｗｉｔｈｉｎ ｔｈｅ ＰＫ＿Ｌａｔｅｓｔ；

図２０は、ＥＴＬインジケータＩ、ＯおよびＵ用の非コア６２４への新しい行の挿入６２２である、適用ステップ２０３を示すデータフロー図６２０である。削除用にマークされた行を除いて、すべての入力行がロードされる。最新の、残りのＵおよびすべてのＯ行になる、ＩのＥＴＬ＿Ｉｎｄｉｃａｔｏｒを有するおよびいくつかはＵのＥＴＬ＿Ｉｎｄｉｃａｔｏｒを有する行は事前期限切れである。ｃａｓｅステートメントは、ソース用の終了タイムスタンプがＸ＿ｔａｂｌｅ６２６（ほとんどの場合、ＥＴＬインジケータはＯおよびＵ）でｎｕｌｌでない際に、終了タイムスタンプを固定された、現在のタイムスタンプに設定するために使用される。削除を除き、すべての入力行がロードされる。主キー毎にＩ行および１つのＵ行は追加のＵ行が事前期限切れにしている間に最新（終了タイムスタンプなしで）になることができる。

以下は、適用ステップ２０３に関連付けられる擬似コードの例である。

ステップ２０３−擬似コード
ＩＮＳＥＲＴ ｉｎｔｏ ｎｏｎｃｏｒｅ
Ｓｅｌｅｃｔ ＊ ｆｒｏｍ Ｘ−ｔａｂｌｅ
Ｗｈｅｒｅ ＥＴＬ＿Ｉｎｄｉｃａｔｏｒ＝‘Ｉ’，‘Ｏ’ｏｒ‘Ｕ’；

図２１は、前の行から後の期限切れを継承すべき際に非コアデータ６４２内の新しく挿入された「Ｏ」行をアップデートすることである、適用ステップ２０４を示すデータフロー図６４０である。これは、行が既に削除されている（期限切れ６４４）が、削除が行われる前であるが論理的に削除された行の開始時間後に起こることであるアウト−オブ−シーケンスのアップデートを受信したケースである。最新のソース開始タイムスタンプを有しているので、新たに挿入された行はもっと後の終了タイムスタンプを取得すべきである。適用ステップ２０４はＸ＿ｔａｂｌｅ６４６からのＰＫのみをフィルタしてもよい。

以下は、適用ステップ２０４に関連付けられる擬似コードの例である。

ステップ２０４−擬似コード
ＵＰＤＡＴＥ ＮＣ＿Ｔｂｌ
ＦＲＯＭ
ｎｏｎｃｏｒｅ ＮＣ＿Ｔｂｌ，
（ＳＥＬＥＣＴ ＰＫ＿Ｌａｔｅｓｔ ＭＡＸ（ＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ）ＭＡＸ＿ＥＮＤ＿ＴＳ
ＦＲＯＭ ｎｏｎｃｏｒｅ
ＷＨＥＲＥ（ＰＫ＿Ｌａｔｅｓｔ ｉｎ（ＳＥＬＥＣＴ ＰＫ＿Ｌａｔｅｓｔ ＦＲＯＭ Ｘ＿ｔａｂｌｅ））
ＧＲＯＵＰ ＢＹ ＰＫ＿Ｌａｔｅｓｔ）Ｍａｘ＿ＮＣ
ＳＥＴ ＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ＝Ｍａｘ＿ＮＣ．ＭＡＸ＿ＥＮＤ＿ＴＳ，
ＣＤＷ＿ＥＮＤ＿ＴＳ＝ｃｕｒｒｅｎｔ ｔｉｍｅｓｔａｍｐ ｆｏｒ ｔａｂｌｅ
ＷＨＥＲＥ ＮＣ＿Ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ＝Ｍａｘ＿ＮＣ．ＰＫ＿Ｌａｔｅｓｔ
ＡＮＤ ＮＣ＿Ｔｂｌ．ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ＜Ｍａｘ＿ＮＣ．ＭＡＸ＿ＥＮＤ＿ＴＳ
ＡＮＤ ＮＣ＿Ｔｂｌ．ＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ ＩＳ ＮＵＬＬ；

図２２は、既に期限切れの非コア６６２行上での終了タイムスタンプのアップデートであるが、適用ステップ２０３中その直後に挿入された「し損ない」アップデート６６４を有していた、適用ステップ２０５を示すデータフロー図６６０である。適用ステップ２０５では、「Ｏ」行は、「Ｏ」行が挿入されていることにより現在別の後続行を有する行の終了タイムスタンプを修正するためにＸ＿ｔａｂｌｅ６６６から使用される。新しい終了タイムスタンプは新たに挿入された「Ｏ」行の開始タイムスタンプである。

以下は、適用ステップ２０５に関連付けられる擬似コードの例である。

ステップ２０５−擬似コード
ＵＰＤＡＴＥ ＮＣ＿Ｔｂｌ
ＦＲＯＭ ｎｏｎｃｏｒｅ ＮＣ＿Ｔｂｌ，
（ＳＥＬＥＣＴ ＮＣ＿Ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ
，Ｘ＿Ｔｂｌ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ ＳＲＣ＿ＥＮＤ＿ＴＳ
，ＭＡＸ（ＮＣ＿Ｔｂｌ．ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ）ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ
ＦＲＯＭ（ＳＥＬＥＣＴ ＰＫ＿Ｌａｔｅｓｔ
，ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ
ＦＲＯＭ Ｘ−Ｔａｂｌｅ
ＷＨＥＲＥ ＥＴＬ＿ＩＮＤＩＣＡＴＯＲ＝‘Ｏ’）Ｘ＿Ｔｂｌ
，（ＳＥＬＥＣＴ ＰＫ＿Ｌａｔｅｓｔ
，ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ
ＦＲＯＭ ｎｏｎｃｏｒｅ）ＮＣ＿Ｔｂｌ
ＷＨＥＲＥ ＮＣ＿Ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ＝Ｘ＿Ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ
ＡＮＤ ＮＣ＿Ｔｂｌ．ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ＜Ｘ＿Ｔｂｌ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ
ＧＲＯＵＰ ＢＹ ＮＣ＿Ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ，Ｘ＿Ｔｂｌ．ＳＲＣ＿ＳＴＡＲＴ＿ＴＳ
）ＱＱＱ
ＳＥＴ ＳＯＵＲＣＥ＿ＥＮＤ＿ＴＳ＝ＱＱＱ．ＳＲＣ＿ＥＮＤ＿ＴＳ，
ＣＤＷ＿ＥＮＤ＿ＴＳ＝ｃｕｒｒｅｎｔ ｔｉｍｅｓｔａｍｐ ｆｏｒ ｔａｂｌｅ
ＷＨＥＲＥ ＮＣ＿Ｔｂｌ．ＰＫ＿Ｌａｔｅｓｔ＝ＱＱＱ．ＰＫ＿Ｌａｔｅｓｔ
ＡＮＤ ＮＣ＿Ｔｂｌ．ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ＝ＱＱＱ．ＳＯＵＲＣＥ＿ＳＴＡＲＴ＿ＴＳ；

図２３は、論理的な削除による非コア行の期限切れである、適用ステップ２０６を示すデータフロー図６８０である。「Ｄ」のＥＴＬ＿Ｉｎｄｉｃａｔｏｒについては、ソース開始タイムスタンプは完全目標主キーを提供し、終了タイムスタンプを削除タイムスタンプ値にアップデート６８４するためにＸ＿ｔａｂｌｅ６８２内のソース終了タイムスタンプ内に保存されている。

以下は、適用ステップ２０６に関連付けられる擬似コードの例である。

ステップ２０６−擬似コード
ＵＰＤＡＴＥ ＮＣ＿Ｔｂｌ
ＦＲＯＭ ｎｏｎｃｏｒｅ ＮＣ＿Ｔｂｌ，ｘ ｔａｂｌｅ Ｘ＿Ｔｂｌ
Ｓｅｔ ＮＣ＿Ｔｂｌ ｓｏｕｒｃｅ ｅｎｄ ｔｓ＝Ｘ ｔｂｌ ｓｏｕｒｃｅ ｓｔａｒｔ ｔｓ，
ＮＣ＿Ｔｂｌ．ｃｄｗ ｅｎｄ ｔｓ＝ｃｕｒｒｅｎｔ ｔｉｍｅｓｔａｍｐ ｆｏｒ ｔａｂｌｅ
Ｗｈｅｒｅ ＮＣ＿Ｔｂｌ．ＰＫ＿ｌａｔｅｓｔ＝Ｘ＿Ｔｂｌ．ＰＫ＿ｌａｔｅｓｔ
Ａｎｄ ＮＣ＿Ｔｂｌ．ｓｏｕｒｃｅ＿ｓｔａｒｔ＿ｔｓ＝Ｘ＿Ｔｂｌ．ｓｒｃ＿ｅｎｄ ｔｓ−−ｅｎｓｕｒｅｓ １−ｔｏ−１
Ａｎｄ Ｘ＿Ｔａｂｌｅ．ＥＴＬ＿ｌｎｄｉｃａｔｏｒ ｉｓ ‘Ｄ’
Ａｎｄ ＮＣ＿Ｔｂｌ ｓｏｕｒｃｅ ｅｎｄ ｔｓ ｉｓ ｎｕｌｌ ｏｒ ｇｒｅａｔｅｒ ｔｈａｎ Ｘ ｔａｂｌｅ ｓｔａｒｔ ｔｓ

以下は、適用ステップ２０７に関連付けられる擬似コードの例である。

ステップ２０７−擬似コード
ＥＮＤ ＴＲＡＮＳＡＣＴＩＯＮ
Ｅｖａｌｕａｔｅ ｗｈｅｔｈｅｒ ｔｏ ｒｅｆｒｅｓｈ ｎｏｎｃｏｒｅ ｓｔａｔｉｓｔｉｃｓ

例示的な実施形態では、すべての変更データキャプチャ（ＣＤＣ）のプロセス（上述したステップおよび適用ステップ）は、Ｗ＿ｔａｂｌｅおよび／またはＸ＿ｔａｂｌｅへの書き込みをするまたは所与のソースシステムまたは目標テーブルのセット用にＣＤＣを呼び出す、任意の後続のミニバッチデータロードの部分が始まる前に完了している。このように、ロードプロセス全体は、Ｗ＿ｔａｂｌｅおよび／またはＸ＿ｔａｂｌｅへの書き込みおよびＣＤＣの呼び出しを除いてシリアライズされない。

上述の実施形態は、連続的に利用できる一時的な正規化されたデータウェアハウス内に多くの場合１０または１５分程度のミニバッチスケジュールをサポートするのに十分な効率で、変更せずに任意のソースシステムからのデータの任意のボリュームをロードするために利用される。これらの実施形態は、小さなデータベース固有の調整（例えば、列をリストするカタログテーブルの名前）を伴い、履歴を保持し積極的に参照整合性を実施する必要のない一時的な正規化されたデータウェアハウスをロードするためにＡＮＳＩ ＳＱＬ−２００３標準（またはいくつかの変換での下位の標準）をサポートする任意のリレーショナルデータベースで使用することができる。さらに、具現化されたメタデータ最適化パラメータの使用は、特にワークロードをパーティショニングすることに関して、データウェアハウスで一般的に使用されるより高価な超並列処理（ＭＰＰ）アーキテクチャではなく、対称型マルチプロセッシング（ＳＭＰ）アーキテクチャを使用した商用コンピュータサーバ上で、増加した待ち時間で、データのローディングを許可するロードプロセス毎のコンピューティングリソースのコストを十分に低減することを促進する。本実施形態は、時間間隔に関して連続的に重複する場合、主キー内の複数の行が一度に処理され、シーケンスされ、折り畳まれることができるように、候補行のセット内およびそれらの行と目標データベース間で動作する。

したがって、少なくとも１つの実施形態では、一時的に正規化されたデータウェアハウスを移入する方法は、それ自体および演算子（ｓｅｔ−ＳＱＬ）のリレーショナル代数セットを使用してネット変更データを識別およびシーケンスする、およびデータがデータウェアハウス自体の中に残存する間すべてのデータウェアハウスへの挿入および一時的なアップデートを適用する、既存のデータウェアハウスに関する入力データのセットを解析することを含むことが提供される。上述した方法を達成するために、ソフトウェアコードは、データの挿入および一時的なアップデートを実行するために動的に生成されることができ、次に生成されたコードが実行される。加えて、連続したデータは期間の最小数に圧縮され、一意なタイムスタンプ内のマイクロ秒レベルのシーケンスが必要に応じて生成および維持される。

少なくとも１つの実施形態において、システムは、データウェアハウス、データウェアハウス内に格納される入力データのセットを受信する能力、およびデータウェアハウス内に以前に格納されたものにその対する受信データのネット変更を識別しシーケンスするように動作可能なシーケンシングユニットを含むことが提供される。システムは、最小期間内に連続するデータを圧縮するように動作可能な１つ以上の圧縮ユニット、データウェアハウスのアップデートを実行するためのコードを生成するオートコーダユニット、および生成されたコードを実行するための実行ユニットを含んでいてもよい。シーケンシングユニットは広く受け入れられているＡＮＳＩ標準構造化照会言語（ＳＱＬ）データ操作言語（ＤＭＬ）を使用して、このインスタンスで実装されたデータを識別およびシーケンスするための演算子のリレーショナル代数セットを利用するように動作可能である。

オペレーショナルデータストアおよびデータマートの数百を置き換える、すべての分析ニーズではない場合のほとんどのための正規化された一時的なデータウェアハウスの単一または少数を有するために大きな成功を収めている企業が事業を活発化していることが広く認識されている。このパラダイムは効率的で比較的非侵入型のロードソフトウェアのまったく新しいタイプのための実質的な必要性を作成している。記述された実施形態は、作業としてのデータロードサーバ利用およびネットワークトラフィック内での大規模なコスト削減がデータベース内のＳＱＬではるかに効率的に処理され、そして連続的なクエリの可用性を厳密にサポートするためにローディング期間中に目標データベースの第２のコピーの必要性を回避する（第２のコピーはまだ他の理由のために利用されてもよい）、一時的なデータウェアハウスのための開発および維持コストの劇的な削減を提供する。記述された実施形態は、１つ以上の目的領域または企業全体であろうと、一時的なデータウェアハウスの使用が世界的に成長する任意のデータベースプラットフォームに適用可能であり、データウェアハウスの範囲に渡る連続的に利用可能なデータの単一のコピーからの解析ニーズ（運用上、戦術的、戦略的）の複数のタイプをサポートするデータウェアハウス戦略を一意に可能にしながら同様の機能を提供する現在の技術はない。

記述されたシステムおよび方法はほぼリアルタイム、および単一システム内のすべてのデータの単一コピーを必要な最小の期間内に正規化された完全な一時的履歴で、適切なセキュリティおよび承認のコントロールを介して、継続的およびほぼ即時の外部からのアクセスを順番に可能にする単一の正規化されたデータウェアハウスの最小限に侵入型のロードをサポートする。

例示的な実施形態では、入力データセットのパーティショニングはオプションである。パーティションは実行中のプロセスが複数のパーティションからのデータにアクセスしないように独立して処理されてもよい。むしろ、さらに上述したように、各パーティションの処理結果は、単一の適用するステップで使用するためのＸ＿ｔａｂｌｅに蓄積されてもよい（並列化またはパーティショニングされずに）。

いくつかの実施形態は入力データセットをインポートする揮発性（例えば、非永続的）テーブルを用いる。揮発性テーブルのフルセットは、例えばパーティションが指定されている際に使用されてもよい。さらに、データは、従来の、永続的な（「物理的な」）テーブルおよびパーティションなしで使用するかまたはパーティションおよび物理的なテーブルの揮発性コピーを使用するかどうかのどちらであっても、パーティション毎に１セット（例えば、パーティション毎に４つの仮想テーブル）で、コンピュータデータウェアハウス（ＣＤＷ）内の既存のデータおよび入力データセットとの間で正規化（例えば、一時的に正規化）されてもよい。

本発明の実施形態は、データベースサーバ１６および／またはアプリケーションサーバ２４（図２に示す）などのような１つ以上のコンピューティング装置を使用して実行されてもよい。図２４は、例示的なコンピューティング装置７００のブロック図である。例示的な実施形態では、コンピューティング装置７００は、プロセッサユニット７１０、メモリ７１５、永続的ストレージ７２０、通信ユニット７２５、入力／出力（Ｉ／Ｏ）ユニット７３０、およびディスプレイ７３５のようなプレゼンテーションインターフェースとの間の通信を提供する通信ファブリック７０５を含む。プレゼンテーションインターフェースに加えてまたは代替として、オーディオ装置（図示せず）および／またはユーザに情報を伝えることができる任意の装置を含んでいてもよい。

プロセッサユニット７１０はメモリ７１５にロードされてもよいソフトウェア用の命令を実行する。プロセッサユニット７１０は１つ以上のプロセッサのセットであってもよく、または特定の実装に応じて、複数のプロセッサコアを含んでいてもよい。さらに、プロセッサユニット７１０はメインプロセッサが単一チップ上に二次プロセッサと存在する１つ以上の異機種プロセッサシステムを用いて実装されてもよい。別の実施形態では、プロセッサユニット７１０は同じタイプの複数のプロセッサを含む同機種プロセッサシステムであってもよい。

メモリ７１５および永続的ストレージ７２０はストレージ装置の例である。本明細書で使用されるストレージ装置は一時的および／または永続的のいずれかの情報を格納することができるハードウェアの任意の部分である。メモリ７１５は、例えば、限定されないが、ランダムアクセスメモリおよび／または他の任意の適当な揮発性または不揮発性のストレージ装置であってもよい。永続的ストレージ７２０は特定の実装に応じて様々な形態を採ってもよく、永続的ストレージ７２０は１つ以上のコンポーネントまたは装置を含んでいてもよい。例えば、永続的ストレージ７２０はハードドライブ、フラッシュメモリ、書き換え可能な光ディスク、書き換え可能な磁気テープ、および／または上記のいくつかの組み合わせであってもよい。永続的ストレージ７２０により使用される媒体はまたリムーバブルであってもよい。例えば、限定されないが、リムーバブルハードドライブは永続的ストレージ７２０に使用されてもよい。

メモリ７１５および／または永続的ストレージ７２０などのストレージ装置は、本明細書に記述されたプロセスで使用するためのデータを格納するように構成されてもよい。例えば、ストレージ装置はコンピュータ実行可能命令、実行可能なソフトウェアコンポーネント（例えば、データロードコンポーネントおよび／またはデータウェアハウスコンポーネント）、データソースから受信したデータ、コンフィギュレーションデータ（例えば、最適化オプション）、および／または本明細書に記述した方法での使用に適した任意の他の情報を格納してもよい。

通信ユニット７２５は、これらの例では、他のコンピューティング装置またはシステムとの通信を提供する。例示的な実施形態では、通信ユニット７２５はネットワークインターフェースカードである。通信ユニット７２５は物理的および無線通信リンクの一方または両方の使用を通した通信を提供してもよい。

入力／出力ユニット７３０はコンピューティング装置７００に接続されてもよい他の装置とのデータの入力および出力を可能にする。例えば、限定されないが、入力／出力ユニット７３０はキーボードおよび／またはマウスのようなユーザ入力装置を通してユーザ入力用の接続を提供してもよい。さらに、入力／出力ユニット７３０はプリンタに出力を送ってもよい。ディスプレイ７３５はユーザに情報を表示するための機構を提供する。例えば、ディスプレイ７３５のようなプレゼンテーションインターフェースはグラフィカルユーザインターフェースを表示してもよい。

オペレーティングシステムおよびアプリケーション用の命令またはプログラムは永続的ストレージ７２０上に配置される。これらの命令はプロセッサユニット７１０による実行のためにメモリ７１５にロードされてもよい。異なる実施形態のプロセスはメモリ７１５などのようなメモリ内に配置されてもよいコンピュータ実装命令および／またはコンピュータ実行可能命令を使用して、プロセッサユニット７１０により実行されてもよい。これらの命令はプロセッサユニット７１０内のプロセッサにより読み取られて実行されてもよいプログラムコード（例えば、オブジェクトコードおよび／またはソースコード）と本明細書では呼ばれる。別の実施形態でのプログラムコードは、メモリ７１５または永続的ストレージ７２０のような異なる物理的または有形のコンピュータ可読媒体上に具現化されてもよい。

プログラムコード７４０は、選択的に取り外し可能であり、プロセッサユニット７１０による実行のためにコンピューティング装置７００上にロードまたは転送されてもよい非一時的なコンピュータ可読媒体７４５上に機能的な形式で配置される。プログラムコード７４０およびコンピュータ可読媒体７４５はこれらの例ではコンピュータプログラム製品７５０を形成する。一例では、コンピュータ可読媒体７４５は、例えば永続的ストレージ７２０の一部であるハードドライブなどのようなストレージ装置への転送のための永続的ストレージ７２０の一部であるドライブまたは他の装置に挿入または配置される光学的または磁気ディスクなどのような有形の形態であってもよい。有形の形態では、コンピュータ可読媒体７４５はまた、コンピューティング装置７００に接続されたハードドライブ、サムドライブ、またはフラッシュメモリなどのような永続的ストレージの形態をとってもよい。コンピュータ可読媒体７４５の有形の形態はまたコンピュータ記録可能記憶媒体とも呼ばれる。いくつかの例では、コンピュータ可読媒体７４５は取り外し可能でなくてもよい。

あるいは、プログラムコード７４０は通信ユニット７２５への通信リンクを介しておよび／または入力／出力ユニット７３０への接続を介してコンピュータ可読媒体７４５からコンピューティング装置７００に転送されてもよい。通信リンクおよび／または接続は、例示的な実施例では物理的またはワイヤレスであってもよい。コンピュータ可読媒体はまた、プログラムコードを含む通信リンクまたはワイヤレス送信などのような非有形媒体の形態をとってもよい。

いくつかの例示的な実施形態では、プログラムコード７４０はコンピューティング装置７００内で使用するために別のコンピューティング装置またはコンピュータシステムから永続的ストレージ装置７２０にネットワークを介してダウンロードされてもよい。例えば、サーバコンピューティング装置内のコンピュータ可読記憶媒体に格納されたプログラムコードはサーバからコンピューティング装置７００にネットワークを介してダウンロードされてもよい。プログラムコード７４０を提供するコンピューティング装置はサーバコンピュータ、ワークステーション、クライアントコンピュータ、またはプログラムコード７４０を格納および送信することができる他の何らかの装置であってもよい。

プログラムコード７４０は機能的に関連するコンピュータ実行可能コンポーネントに編成されてもよい。各コンポーネントは、プロセッサユニット７１０により実行される際に、プロセッサユニット７１０を本明細書に記述の１つ以上の操作を実行させるようにするためのコンピュータ実行可能命令を含んでいてもよい。

コンピューティング装置７００用に本明細書で示された異なるコンポーネントは、異なる実施形態を実装されてもよい方法へのアーキテクチャ上の制限を提供することを意味するものではない。別の例示的な実施形態は、コンピューティング装置７００用に示されるこれらに加えてまたはその代わりのコンポーネントを含むコンピュータシステムにおいて実装されてもよい。例えば、図２４に示す他のコンポーネントは図示の例示的な実施例から変化させることができる。

一例として、コンピューティング装置７００内のストレージ装置はデータを格納してもよい任意のハードウェア装置である。メモリ７１５、永続的ストレージ７２０およびコンピュータ可読媒体７４５は、有形形態のストレージ装置の例である。

別の例では、バスシステムは通信ファブリック７０５を実装するために使用されてもよく、システムバスまたは入出力バスなどのような１つ以上のバスを含んでいてもよい。勿論、バスシステムはバスシステムに接続される異なるコンポーネントまたは装置間のデータ転送を提供するアーキテクチャの任意の適切なタイプを使用して実装されてもよい。加えて、通信ユニットは、モデムまたはネットワークアダプタなどのようなデータを送受信するために使用される１つ以上の装置を含んでいてもよい。さらに、メモリは、例えば、限定されないが、通信ファブリック７０５に存在してもよいインターフェースおよびメモリコントローラハブに見られるようなメモリ７１５またはキャッシュであってもよい。

上述した実施形態は入力データセットを一時的なデータウェアハウスにロードするのに使用するためのシステムを提供する。このようなシステムは、一時的なデータウェアハウスおよび入力データセットを含むストレージ装置およびストレージ装置に結合されたプロセッサユニットを含む。少なくとも１つの実施形態におけるプロセッサは、入力データセットを第１のパーティションおよび第２パーティションを含む複数のパーティションに分割するようにプログラムされ、複数のパーティションの各パーティションは、第１のパーティションをプリロードテーブルにインポートし、第２のパーティションをプリロードテーブルにインポートし、そしてプリロードテーブルを一時的なデータウェアハウスに適用する、複数のデータレコードを含む。

別の実施形態では、プロセッサユニットは、少なくとも１つのデータレコードに対応するハッシュ値を生成するための少なくとも１つのデータレコードに関連付けられた主キーにハッシュ関数を適用することにより少なくとも部分的に複数のパーティションに入力データセットを分割するようにプログラムされる。別の実施形態では、プロセッサユニットは、第１のパーティションがテーブルにプリロードされた後に第２のパーティションをプリロードテーブルにインポートするようにさらにプログラムされる。さらに別の実施形態では、プロセッサユニットは、第１のパーティションがプリロードテーブルにインポートされている間に第２のパーティションをプリロードテーブルにインポートするようにさらにプログラムされる。そのような実施形態では、プロセッサユニットは、並列インポートの現在の量が並列インポートの所定の最大量よりも少ないことを判定することに基づいて、第１のパーティションがプリロードテーブルにインポートされている間に第２のパーティションをプリロードテーブルにインポートするようにプログラムされる。

代替実施形態では、プロセッサユニットは、少なくとも第１のパーティションの１つおよびパーティションに対応する揮発性テーブルおよび揮発性テーブルからプリロードテーブルへデータレコードのコピー内にパーティションのデータレコードのインポートにより少なくとも部分的に第２のパーティションをインポートするようにプログラムされる。

さらに別の実施形態では、プロセッサユニットは、以前にインポートされたデータレコードの非キーフィールドに等しいタイムスタンプ以外の複数のフィールドを含む最初のパーティション内のデータレコードを識別し、第１のパーティションをプリロードテーブルにインポートする際に識別されたデータレコードを除外するようにさらにプログラムされる。入力データはソースデータベースからのデータのスナップショットを含むかもしれず、このような実施形態では、プロセッサユニットは、一時的なデータウェアハウス内のアクティブなデータレコードが入力データセット内のデータレコードに関連付けられていないことを検出し、前記検出に基づいてアクティブデータレコードの暗示的削除を実行するようにさらにプログラムされる。プロセッサユニットは、入力データセット内の最初のデータレコードに関連付けられている最先のソースタイムスタンプを決定し、最先のソースタイムスタンプの直前のソースタイムスタンプに関連付けられた一時的なデータウェアハウス内のデータレコードおよび最先のソースタイムスタンプよりも後のソースタイムスタンプに関連付けられている一時的なデータウェアハウス内の１つ以上のデータレコードを表す主キーのセットを識別し、そして主キーの識別されたセットに基づいて第１のパーティションおよび第２のパーティションをインポートするようにさらにプログラムされるかもしれない。

加えて、本明細書に記述の実施形態は、一時的なデータウェアハウスに複数のデータレコードのローディングに使用するための方法を提供する。このような方法は、コンピューティング装置により、データレコードを第１のパーティションおよび第２パーティションを含む複数のパーティションに分割すること、コンピューティング装置により、第１のパーティションをプリロードテーブルにインポートすること、コンピューティング装置により、第２のパーティションをプリロードテーブルにインポートすること、およびコンピューティング装置により、プリロードテーブルを一時的なデータウェアハウスに適用することを含む。本方法の特定の実施形態では第１のパーティションおよび第２のパーティションは並列にインポートされる。方法は並列インポートの現在の量が並列インポートの所定の最大量よりも少ないことを判定することをさらに含んでいてもよく、第１のパーティションおよび第２のパーティションは前記判定に基づいて並列にインポートされる。方法は並列インポートの現在の量が並列インポートの所定の最大量よりも多いか等しいことを判定することをさらに含んでいてもよく、第１のパーティションおよび第２のパーティションは前記判定に基づいて連続してインポートされる。

本方法の代替実施形態は、コンピューティング装置により、少なくとも１つのデータレコードに関連付けられたハッシュ値を作成するために、少なくとも１つのデータレコードにハッシュ関数を適用することを備える複数のパーティション内にデータを分割すること、および少なくとも１つのデータレコードに対応するおよび関連付けられたパーティション番号を決定するためにパーティションの所定量に基づいたハッシュ値にモジュロ演算子を適用することを意図する。

本方法の実施形態はまた、以前にインポートされたデータレコードの非キーフィールドに等しいタイムスタンプ以外の複数のフィールドを含む第１のパーティション内のデータレコードを識別し、第１のパーティションをプリロードテーブルにインポートする際に識別されたデータレコードを除外することを含んでいてもよい。

上述の実施形態は、ネット変更データでデータウェアハウスをロードするためにその上で具現化されたコンピュータ実行可能命令を有する非一時的なコンピュータ可読媒体を備えるコンピュータプログラム製品としてさらに特徴付けられてもよい。少なくとも１つのプロセッサにより実行される際に、コンピュータ実行可能命令はプロセッサが入力データセットを第１のパーティションおよび第２のパーティションを含む複数のパーティションに分割するようにさせ、複数のパーティションのうちの少なくとも１つのパーティションは、第１のパーティションをプリロードテーブルにインポートし、第２のパーティションをプリロードテーブルにインポートし、そしてプリロードテーブルをデータウェアハウスに適用する、複数のデータレコードを含む。

さらに実施形態では、コンピュータ実行可能命令は、少なくとも１つのプロセッサが第１のパーティションおよび第２のパーティションを互いに並列にインポートさせるようにする。他の実施形態では、コンピュータ実行可能命令は、少なくとも１つのプロセッサが並列インポートの現在の量と並列インポートの所定の最大量を比較するようにさらにさせ、並列インポートの現在の量が最大量よりも少ない時、第１のパーティションのインポートと並行して第２のパーティションをインポートし、並列インポートの現在の量が最大量よりも多いか等しい時、第１のパーティションのインポート後に第２のパーティションをインポートする。

さらに別の実施形態では、コンピュータ実行可能命令は、少なくとも１つのプロセッサが、第２のパーティションのデータレコードを第２のパーティションに対応する第２の揮発性テーブルにインポートし、第１の揮発性テーブルおよび第２の揮発性テーブルのデータレコードをプリロードテーブルにコピーする、第１のパーティションに対応する第１の揮発性テーブル内に第１のパーティションのデータレコードをインポートすることにより少なくとも部分的に第１のパーティションおよび第２のパーティションをインポートするようにさせる。

さらに別の実施形態では、入力データセットはソースデータベースからのデータのスナップショットを含み、コンピュータ実行可能命令は少なくとも１つのプロセッサがデータウェアハウス内のアクティブなデータレコードが入力データセット内のデータレコードに関連付けられていないことを検出し、そして前記検出に応答してアクティブなデータレコードの暗示的削除を実行するようにさらにさせる。

本明細書は最良の形態を含む本発明を開示するために、また任意の当業者が任意の装置またはシステムを製造および使用することおよび任意の組み込まれた方法を実行することを含めて本発明を実施できるようにするために例示を使用する。本発明の特許可能な範囲は特許請求の範囲によって定義され、当業者が想到する他の例示を含んでいてもよい。そのような他の例示は、それらが特許請求の範囲の文言と異ならない構造要素を有する場合、またはそれらが特許請求の範囲の文言と実質的に差違のない同等な構造要素を含む場合、特許請求の範囲内にあることが意図される。
また、本願は以下に記載する態様を含む。
（態様１）
入力データセットの一時的なデータウェアハウスへのローディングに使用するためのシステム（１０）であって、
一時的なデータウェアハウスおよび入力データセットを含むストレージ装置（７２０）と、
前記ストレージ装置に結合され、
前記入力データセットを第１のパーティションおよび第２のパーティションを含む複数のパーティションに分割し、前記複数のパーティションの各パーティションは複数のデータレコードを含み、
前記第１のパーティションをプリロードテーブルにインポートし、
前記第２のパーティションを前記プリロードテーブルにインポートし、
前記プリロードテーブルを前記一時的なデータウェアハウスに適用する、
ようにプログラムされたプロセッサユニット（７１０）と、
を備えるシステム。
（態様２）
前記プロセッサユニット（７１０）は、前記入力データセットを少なくとも１つのデータレコードに対応するハッシュ値を生成するために前記少なくとも１つのデータレコードに関連付けられた主キーにハッシュ関数を適用することにより少なくとも部分的に前記複数のパーティションに分割するようにプログラムされる、態様１に記載のシステム（１０）。
（態様３）
前記プロセッサユニット（７１０）は、前記第１のパーティションが前記テーブルにプリロードされた後、前記第２のパーティションを前記プリロードテーブルにインポートするようにさらにプログラムされる、態様１に記載のシステム（１０）。
（態様４）
前記プロセッサユニット（７１０）は、前記第１のパーティションが前記プリロードテーブルにインポートされている間、前記第２のパーティションを前記プリロードテーブルにインポートするようにさらにプログラムされる、態様１に記載のシステム（１０）。
（態様５）
前記プロセッサユニット（７１０）は、並列インポートの現在の量が並列インポートの所定の最大数よりも少ないことの判定に基づいて、前記第１のパーティションが前記プリロードテーブルにインポートされている間、前記第２のパーティションを前記プリロードテーブルにインポートするようにプログラムされる、態様４に記載のシステム（１０）。
（態様６）
前記プロセッサユニット（７１０）は、少なくとも部分的に、
前記パーティションの前記データレコードを前記パーティションに対応する揮発性テーブルにインポートすることと、
前記データレコードを前記揮発性テーブルから前記プリロードテーブルにコピーすることと、
により前記第１のパーティションおよび前記第２のパーティションの少なくとも１つをインポートするようにプログラムされる、態様１に記載のシステム（１０）。
（態様７）
前記プロセッサユニット（７１０）は、
以前にインポートされたデータレコードの非キーフィールドに等しいタイムスタンプ以外の複数のフィールドを含む前記第１のパーティション内のデータレコードを識別し、
前記第１のパーティションを前記プリロードテーブルにインポートする際に前記識別されたデータレコードを除外する、
ようにさらにプログラムされる態様１に記載のシステム（１０）。
（態様８）
前記入力データは、ソースデータベース（２０）からのデータのスナップショットを含み、前記プロセッサユニット（７１０）は、
一時的なデータウェアハウス内のアクティブデータレコードが前記入力データセット内のデータレコードに関連付けられていないことを検出し、
前記検出に基づいて前記アクティブデータレコードの暗示的削除を実行する、
ようにさらにプログラムされる、態様１に記載のシステム（１０）。
（態様９）
前記プロセッサユニット（７１０）は、
前記入力データセット内の最初のデータレコードに関連付けられた最先のソースタイムスタンプを決定し
前記最先のソースタイムスタンプの直前のソースタイムスタンプに関連付けられた前記一時的なデータウェアハウス内のデータレコードと、
前記最先のソースタイムスタンプよりも後のソースタイムスタンプに関連付けられている前記一時的なデータウェアハウス内の１つ以上のデータレコードと、
を表す主キーのセットを識別し、
主キーの前記識別されたセットに基づいて前記第１のパーティションおよび前記第２のパーティションをインポートする、
ようにさらにプログラムされる、態様８に記載のシステム（１０）。
（態様１０）
一時的なデータウェアハウスへの複数のデータレコードのローディングに使用するための方法であって、
コンピューティング装置（７００）により、前記データレコードを第１のパーティションおよび第２のパーティションを含む複数のパーティションに分割することと、
前記コンピューティング装置により、前記第１のパーティションをプリロードテーブルにインポートすることと、
前記コンピューティング装置により、前記第２のパーティションを前記プリロードテーブルにインポートすることと、
前記コンピューティング装置により、前記プリロードテーブルを前記一時的なデータウェアハウスに適用することと、
を備える方法。
（態様１１）
前記第１のパーティションおよび前記第２のパーティションは並列にインポートされる、態様１０に記載の方法。
（態様１２）
並列インポートの現在の量は、並列インポートの所定の最大量よりも少ないことを判定することであって、前記判定に基づいて前記第１のパーティションおよび前記第２のパーティションは並列にインポートされる、判定することをさらに備える、態様１０に記載の方法。
（態様１３）
前記並列インポートの現在の量は、並列インポートの所定の最大量よりも多いか等しいことを判定することであって、前記判定に基づいて前記第１のパーティションおよび前記第２のパーティションは連続してインポートされる、判定することをさらに備える、態様１０に記載の方法。
（態様１４）
コンピューティング装置（７００）により、前記データを前記複数のパーティションに分割することは、
少なくとも１つのデータレコードに関連付けられたハッシュ値を作成するために、ハッシュ関数を前記少なくとも１つのデータレコードに適用することと、
前記少なくとも１つのデータレコードに対応するおよび関連付けられたパーティション数を決定するためにパーティションの所定量に基づいてモジュロ演算子を前記ハッシュ値に適用することと、
を備える、態様１０に記載の方法。
（態様１５）
以前にインポートされたデータレコードの非キーフィールドに等しいタイムスタンプ以外の複数のフィールドを含む第１のパーティション内のデータレコードを識別することと、
前記第１のパーティションを前記プリロードテーブルにインポートする際に前記識別されたデータレコードを除外することと、
をさらに備える、態様１０に記載の方法。

Claims (13)

1. 入力データセットを一時的なデータウェアハウスにロードするように構成されたシステム（１０、２２、７００）であって、
   一時的なデータウェアハウスおよび入力データセットを含むストレージ装置（７２０）と、
   前記ストレージ装置に結合されたプロセッサユニット（７１０）であって、該プロセッサユニットは、
   前記入力データセットがソースデータベースからのデータのスナップショットを含むことを判断し、
   前記入力データセット中の第１のデータレコードに関連した最も早いソースタイムスタンプを判断し、
   前記最も早いソースタイムスタンプの直前のソースタイムスタンプと関連した前記一時的なデータウェアハウス中のデータレコードと、前記一時的なデータウェアハウス中の１または複数のデータレコードであって、前記最も早いソースタイムスタンプよりも遅いソースタイムスタンプに関連した１または複数のデータレコードとを示す主キーの組を認識し、
   前記入力データセットを、第１のパーティションおよび第２のパーティションを含む複数のパーティションであって前記複数のパーティションの各パーティションは複数のデータレコードを含む複数のパーティションに分割し、
   前記第１のパーティションを前記認識された主キーの組に基づいてプリロードテーブルにインポートし、
   前記第２のパーティションを、前記認識された主キーの組に基づいて前記プリロードテーブルにインポートし、
   前記プリロードテーブルを前記一時的なデータウェアハウスに適用し、
   前記一時的なデータウェアハウス中のアクティブデータレコードが前記入力データセット中の前記複数のデータレコードの1つと関連していないことを検知し、
   前記入力データセットが前記ソースデータベースからのデータの前記スナップショットを含むことの前記判断と前記検知とに基づいて前記アクティブデータレコードの暗示的削除を実行するようにプログラムされた、プロセッサユニット（７１０）とを含むシステム（１０、２２、７００）。
2. 前記プロセッサユニット（７１０）は、少なくとも１つのデータレコードに対応するハッシュ値を生成するために前記少なくとも１つのデータレコードに関連付けられた主キーにハッシュ関数を適用することにより少なくとも部分的に前記複数のパーティションに前記入力データセットを分割するようにプログラムされ、前記主キーは前記主キーの組に含まれる、請求項１に記載のシステム（１０、２２、７００）。
3. 前記プロセッサユニット（７１０）は、前記第１のパーティションが前記テーブルにプリロードされた後、前記第２のパーティションを前記プリロードテーブルにインポートするようにさらにプログラムされる、請求項１に記載のシステム（１０、２２、７００）。
4. 前記プロセッサユニット（７１０）は、前記第１のパーティションが前記プリロードテーブルにインポートされている間、前記第２のパーティションを前記プリロードテーブルにインポートするようにさらにプログラムされる、請求項１に記載のシステム（１０、２２、７００）。
5. 前記プロセッサユニット（７１０）は、並列インポートの現在の量が並列インポートの所定の最大量よりも少ないことの判定に基づいて、前記第１のパーティションが前記プリロードテーブルにインポートされている間、前記第２のパーティションを前記プリロードテーブルにインポートするようにプログラムされる、請求項４に記載のシステム（１０、２２、７００）。
6. 前記プロセッサユニット（７１０）は、少なくとも部分的に、
   前記第１のパーティション及び前記第２のパーティションの少なくとも一方のデータレコードを前記第１のパーティション及び前記第２のパーティションの前記少なくとも一方に対応する揮発性テーブルにインポートすることと、
   前記データレコードを前記揮発性テーブルから前記プリロードテーブルにコピーすることと、
   により前記第１のパーティションおよび前記第２のパーティションの前記少なくとも一方をインポートするようにプログラムされる、請求項１に記載のシステム（１０、２２、７００）。
7. 前記プロセッサユニット（７１０）は、
   以前にインポートされたデータレコードの非キーフィールドに等しいタイムスタンプ以外の複数のフィールドを含む前記第１のパーティション内のデータレコードを識別し、
   前記第１のパーティションを前記プリロードテーブルにインポートする際に前記識別されたデータレコードを除外する、
   ようにさらにプログラムされる請求項１に記載のシステム（１０、２２、７００）。
8. 一時的なデータウェアハウスへの複数のデータレコードのローディング方法であって、
   前記データレコードがソースデータベースからのデータのスナップショットを含むことを判断すること、
   前記データレコード中の第１のデータレコードと関連した最も早いタイムスタンプを判断することと、
   前記最も早いソースタイムスタンプの直前のソースタイムスタンプと関連した前記一時的なデータウェアハウス中のデータレコードと、前記一時的なデータウェアハウス中の１または複数のデータレコードであって、前記最も早いソースタイムスタンプよりも遅いソースタイムスタンプに関連した１または複数のデータレコードとを示す主キーの組を認識することと、
   前記データレコードを第１のパーティションおよび第２のパーティションを含む複数のパーティションに分割することと、
   コンピューティング装置（７００）により、前記認識された主キーの組に基づいて前記第１のパーティションをプリロードテーブルにインポートすることと、
   前記コンピューティング装置により、前記認識された主キーの組に基づいて前記第２のパーティションを前記プリロードテーブルにインポートすることと、
   前記プリロードテーブルを前記一時的なデータウェアハウスに適用することと、
   前記コンピューティング装置により、前記一時的なデータウェアハウス中のアクティブデータレコードが前記複数のデータレコードとの1つと関連していないことを検知し、
   前記コンピューティング装置により、前記データレコードが前記ソースデータベースからのデータの前記スナップショットを含むことの前記判断と前記検知とに基づいて前記アクティブデータレコードの暗示的削除を実行することと、
   を備える方法。
9. 前記第１のパーティションおよび前記第２のパーティションは並列にインポートされる、請求項８に記載の方法。
10. 並列インポートの現在の量は、並列インポートの所定の最大量よりも少ないことを判定することであって、前記判定に基づいて前記第１のパーティションおよび前記第２のパーティションは並列にインポートされる、判定することをさらに備える、請求項８に記載の方法。
11. 並列インポートの現在の量は、並列インポートの所定の最大量よりも多いか等しいことを判定することであって、前記判定に基づいて前記第１のパーティションおよび前記第２のパーティションは連続してインポートされる、判定することをさらに備える、請求項８に記載の方法。
12. コンピューティング装置（７００）により、前記データを前記複数のパーティションに分割することは、
    少なくとも１つのデータレコードに関連付けられたハッシュ値を作成するために、ハッシュ関数を前記少なくとも１つのデータレコードに適用することと、
    前記少なくとも１つのデータレコードに対応するおよび関連付けられたパーティション数を決定するためにパーティションの所定量に基づいてモジュロ演算子を前記ハッシュ値に適用することと、
    を備える、請求項８に記載の方法。
13. 以前にインポートされたデータレコードの非キーフィールドに等しいタイムスタンプ以外の複数のフィールドを含む第１のパーティション内のデータレコードを識別することと、
    前記第１のパーティションを前記プリロードテーブルにインポートする際に前記識別されたデータレコードを除外することと、
    をさらに備える、請求項８に記載の方法。

Images