ITインフラストラクチャで複数のアプリケーションを使用し、異なるデータストア間で様々な形式での読取りや書込みを行う場合、企業内の誰もがデータを簡単に使用できるようにデータを統合するプロセスを実装することが不可欠になります。この目的に使用できるデータ統合の方法は、ETL、データのレプリケーション、データの同期など多数あります。いずれの方法でも、使用する情報システムのデータと組織のアプリケーションを正常に統合するための第一歩は、データの整合性を確保することです。
データ整合性の制御は、使用する情報システムのアプリケーションに含まれるすべてのデータの一貫性を確保するために必要です。
アプリケーション・データは、情報システムによって課せられる制約および宣言規則に対して有効でない場合があります。たとえば、顧客が指定されていない注文や商品が指定されていない注文明細行などが検出される可能性があります。
Oracle Data Integratorが提供する作業環境では、制約違反を検出し、リサイクルまたはレポート作成のために格納できます。
制御には、静的制御およびフロー制御の2種類があります。これらの2つの違いを説明します。
静的制御は、アプリケーション・データの整合性を検証するための規則が存在することを意味します。これらの規則（制約とも呼ぶ）の一部は、（主キー、参照制約などを使用して）データ・サーバーですでに実装されている可能性があります。
Oracle Data Integratorでは、追加の制約を宣言せずに直接サーバーで定義することで、データの検証を調整できます。このプロシージャは静的制約と呼ばれます。このプロシージャによって、既存のデータ（つまり静的データ）に対するチェックを直接実行することが可能になるためです。
変換プロセスおよび統合プロセスのターゲットとなる情報システムでは、多くの場合、独自の宣言規則が実装されます。フロー制御関数は、アプリケーションが受け取ったデータをこれらのターゲットにロードする前に、制約に従って検証するために使用します。フロー制御プロシージャの詳細は、インタフェースに関する章で説明しています。
データ整合性チェックを実行する主な利点は次のとおりです。
ターゲット・データベースをライフ・サイクル全体で使用することで、生産性が向上します。データのビジネス・ルール違反によって、ターゲット・データベースのライフ・サイクル全体でアプリケーション・プログラミングの速度は低下します。そのため、転送されたデータをクリーニングすると、アプリケーション・プログラミングの時間を短縮できます。
ターゲット・データベースのモデルが検証されます。検出される規則違反は、常にソース・データの整合性が不十分であることを意味するわけではありません。ターゲット・モデルの一定の不備を示す可能性もあります。アプリケーションが再書込みされる前にデータを移行すると、現実に即したテスト・データベースを提供しながら、新しいデータ・モデルを検証できます。
ビジネス・ルール違反をフィルタ処理で排除するために前処理されたデータを使用することで、エンドユーザーへのサービスの質が向上します。
データの整合性の確保は、複雑な作業を伴う場合があります。実際には、宣言規則に違反するすべてのデータを分離してリサイクルする必要があります。つまり、複雑なプログラミングの開発が必要になります（特に、ターゲット・データベースに整合性制約検証のメカニズムが含まれている場合）。操作制約に関しては、（ソース、ターゲットまたはリサイクルされたフローの）誤ったデータを修正する方法を実装し、その方法を企業全体で再利用することが最も効率的です。
次に示す例では、データ整合性監査プロセス（静的制御）の流れを説明します。
Orders Application - HSQLアプリケーションには、様々なレベルでビジネス・ルール制約を満たさないデータが含まれています。ここでの目的は、このアプリケーションに含まれるデータのうち、情報システムによって課せられた制約を満たさないデータを検出することです。