一般的な統合プロジェクト

3.1 設計時プロジェクト

一般的なプロジェクトは、複数のステップとマイルストンで構成されます。

その一部を次に示します:

ビジネス・ニーズの定義
トポロジ内のソースとターゲットの識別および宣言
データ・モデルの形式によるソースとターゲットのデータ構造の設計およびリバースエンジニアリング
これらのデータ・モデルに対するデータ品質ルールの実装、およびこれらのデータ・モデルに対する静的チェックの実行によるデータ品質ルールの検証
これらのデータ・モデルのデータストアをソースおよびターゲットとして使用したマッピングの開発
電子メールの送受信、ファイルの処理(コピー、圧縮、名前変更など)、Webサービスの実行など、マッピングを使用して実施できないタスクに対する追加コンポーネントの開発
パッケージ・ワークフローを構築するためのマッピングと追加コンポーネントの統合
作業のバージョン化、およびシナリオの形式でのリリース
シナリオのスケジュールおよび操作

Oracle Data Integratorでは、これらのほとんどのステップ(ソース・データの検証からメタデータ系統、およびロードやデータ品質監査まで)を実行できます。Oracle Data Integratorでは、そのリポジトリによって、仕様および開発作業が集中管理され、プロジェクトの成功の基礎となる独自のアーキテクチャが提供されます。

『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの概要に関する項に、Oracle Data Integratorを使用して統合プロジェクトを作成するための基本的なステップの概要が示されています。『Oracle Data Integratorでの統合プロジェクトの開発』の統合プロジェクトの作成に関する項に、ODIで統合プロジェクトを作成するステップのいくつかが詳細に説明されています。

3.2 バッチ指向の統合

ODIは、すべての主要データベース、Big Dataクラスタ、データ・ウェアハウスおよび分析アプリケーションに対する組込みの接続を備えた総合的なデータ統合プラットフォームであり、大規模かつ高パフォーマンスなバッチ統合を提供します。

データ・ウェアハウスの主な目的は、ビジネス・ユーザーが日常業務に関する意思決定を行うことができるように、正確な指標を整理統合して配信することです。一般的なプロジェクトは、複数のステップとマイルストンで構成されます。その一部を次に示します:

ビジネス・ニーズ(キー・インジケータ)の定義
キー・インジケータに関係するソース・データの識別、ソース情報をキー・インジケータに変換するためのビジネス・ルールの指定
キー・インジケータを格納するターゲット・ウェアハウスのデータ構造のモデル化
ビジネス・ルールの実装によるインジケータの移入
データ品質ルールの設定によるデータの全体的な正確度の測定
キー・インジケータに関するレポートの開発
非定型問合せツールまたは事前定義レポートを使用した、ビジネス・ユーザーによるキー・インジケータおよびメタデータの利用可能化
ビジネス・ユーザーの満足度の測定およびキー・インジケータの追加/変更

ODIでは、そのリポジトリによって、仕様および開発作業が集中管理され、プロジェクトの成功の基礎となる独自のアーキテクチャが提供されます。

シナリオのスケジュールおよび操作

シナリオのスケジュールおよび操作は通常、テスト環境および本番環境で別々の作業リポジトリで実行されます。シナリオはオペレーティング・システム・コマンドで呼び出せるため、ODIエージェントまたは外部スケジューラによって任意のシナリオをスケジュールできます。

シナリオを本番で実行している場合は、エージェントによってODI作業リポジトリに実行ログが生成されます。これらのログは、オペレータ・ナビゲータを使用して、またはOracle Data Integratorコンソールが設定されている場合はWebブラウザを使用してモニターできます。失敗したジョブは再開でき、実行のために非定型のタスクを発行できます。

E-LT

ODIでは、すべての変換を実行するネイティブSQLスクリプトおよびバルク・ローダー制御スクリプトを生成することによって、既存のRDBMSエンジンおよびBig Dataエンジンの機能を活用する独自のE-LTアーキテクチャを使用しています。

3.3 イベント指向の統合

メッセージ指向ミドルウェアまたはエンタープライズ・サービス・バスからのイベントの取得は、リアルタイム環境におけるアプリケーション統合の一般的なタスクになりました。アプリケーションおよびビジネス・プロセスは、複数のサブスクライバに対するメッセージを生成するか、またはメッセージング・インフラストラクチャからのメッセージを使用します。

Oracle Data Integratorには、メッセージベースの統合をサポートし、Java Message Service (JMS)標準に準拠するテクノロジが組み込まれています。たとえば、Oracle Data Integrator内の変換ジョブは、メッセージ・キューまたはトピックのメッセージをサブスクライブし、使用できます。メッセージはリアルタイムで取得および変換され、ターゲット・システムに書き込まれます。

この統合タイプの他のユース・ケースでは、データベース・レベルで変更を取得する必要がある場合があります。Oracle Data Integratorのチェンジ・データ・キャプチャ(CDC)機能によって、ソースに対して挿入、更新または削除されたデータが識別および取得され、統合プロセスでデータを使用できるようになります。

ODIには、ソース・データストアからCDCフレームワークまで変更を追跡するために、トリガーとRDBMSログ・マイニングの2つの方法が用意されています。最初の方法は、データベース・トリガーを実装するほとんどのRDBMSにデプロイできます。この方法は、ソース・システムに対するオーバーヘッドを最小限に抑えるように最適化されています。たとえば、トリガーによって取得された変更データは複製されず、ソース・システムのパフォーマンスを低下させる入出力操作の数を最小限にします。2番目の方法には、RDBMSログ(データベース・エンジンの内部変更履歴)のマイニングが含まれます。Oracle GoldenGateの使用により、ログ・ベースのCDCがサポートされています。

変更の管理に使用されるCDCフレームワークは、ナレッジ・モジュールに基づいており、汎用的でオープンであるため、変更追跡方法はカスタマイズできます。フレームワークに変更をロードするために、サード・パーティの変更プロバイダを使用できます。

頻繁に発生する変更では、同時に複数のデータ・ソースが関係します。たとえば、注文の作成、更新または削除の場合は、注文表と注文明細表の両方が関係します。新規注文明細の処理時に、明細が関連付けられる新規注文も考慮することが重要です。ODIには、一貫性セットCDCと呼ばれる変更追跡モードがあります。このモードでは、複数の変更セットを処理でき、そのデータ一貫性が保証されます。

たとえば、CDCを使用して受注をデータベース・レベルで検出できます。これらの新規注文は、適切なメッセージ・キューまたはトピックに転送される前に、ODIによって拡充および変換されます。Oracle BPELまたはOracle Business Activity Monitoringなどの他のアプリケーションは、これらのメッセージをサブスクライブでき、受信イベントによって適切なビジネス・プロセスがトリガーされます。

ODIでのCDCフレームワークの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のジャーナル化の使用に関する項を参照してください。

3.4 サービス指向アーキテクチャ

Oracle Data Integratorは、いくつかの方法でサービス指向アーキテクチャ(SOA)にシームレスに統合できます。

データ・サービスは、データベース表に格納されているデータに対するアクセスを提供する専用のWebサービスです。チェンジ・データ・キャプチャ機能と組み合せると、データ・サービスは、特定のサブスクライバに対して、変更されたレコードに対するアクセスを提供することもできます。データ・サービスはOracle Data Integratorによって自動的に生成され、WebサービスとしてWebコンテナ(通常はJavaアプリケーション・サーバー)にデプロイされます。データ・サービスの設定、生成およびデプロイ方法の詳細は、『Oracle Data Integratorの管理』のデータ・サービスの作成および使用に関する項を参照してください。

Oracle Data Integratorは、その変換プロセスをWebサービスとして公開することもでき、アプリケーションで統合サービスとして使用できます。たとえば、CRMアプリケーションの更新に使用するLOAD_SALESバッチ・プロセスは、Oracle BPEL、Oracle Enterprise Service Bus、Oracle Business Activity Monitoringなどのサービス準拠アプリケーションからWebサービスとしてトリガーできます。したがって、ODIを使用して開発された変換は、より広範囲なサービス指向アーキテクチャ・イニシアティブの一部になることができます。

サード・パーティのWebサービスをODIワークフローの一部として呼び出し、データ統合プロセスの一部として使用できます。リクエストはすぐに生成され、レスポンスは標準の変換を介して処理されます。たとえば、日次通貨換算レートをWebサービスとして公開するサード・パーティのサービスを会社がサブスクライブしたとします。このデータで複数の通貨データ・ウェアハウスを更新する場合、ODIではこのタスクを最小限の労力で自動化できます。ユーザーは、データ・ウェアハウス・ワークフローからWebサービスを呼び出して、受信データが特定の形式に適合するように適切な変換を実行するのみです。ODIでのWebサービスの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のWebサービスの使用に関する項を参照してください。

3.5 ODIを使用したデータ品質

宣言的ルールに基づいたアプローチによって、Oracle Data Integratorは、データの非一貫性を追跡するデータ品質フレームワークの構築に利用できる最も適したツールです。

Oracle Data Integratorでは、集中管理されたメタデータ・リポジトリに定義された宣言的データ整合性ルールが使用されます。これらのルールがアプリケーション・データに適用され、企業情報の整合性と一貫性が保証されます。データ整合性の利点によって、全体的なデータ品質イニシアティブが高まり、この特定のニーズに対処する既存および将来のビジネス・プロセスとの統合が容易になります。

Oracle Data Integratorでは、リバースエンジニアリング・プロセスによって、データ・レベルで定義された既存のルール(データベース制約など)が自動的に取得されます。また、ODIを使用すると、開発者は、ODI内のデータ検出およびプロファイリングから推測され、即時チェックされる、ユーザー定義の宣言的ルールを追加定義することもできます。

Oracle Data Integratorには、次の2通りの方法でデータの品質をチェックする組込みのフレームワークが用意されています。

データ・サーバーのデータをチェックして、このデータがOracle Data Integratorのデータストアで宣言されたすべてのルールに違反していないことを検証します。このデータ品質チェックは静的チェックと呼ばれ、データ・モデルおよびデータストアで実行されます。このタイプのチェックを使用すると、記憶域テクノロジによって実施されないルールに対して、データの品質をプロファイリングできます。
マッピングによるデータの移動および変換中に、フロー・チェックでデータをチェックします。このチェックでは、ターゲット・データストアに定義されたルールに対してデータ・フローがチェックされます。このようなチェックを使用すると、正しいデータはターゲット・データストアに統合できるのに対して、不正なデータはエラー表に自動的に移動されます。

静的チェックとフロー・チェックの両方で、データストアおよびデータ・モデルに定義された制約が使用されています。また、両方でチェック・ナレッジ・モジュール(CKM)が使用されます。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のフローおよび静的制御に関する項を参照してください。

これらのチェックでは、データの整合性がチェックされ、制約が検証されます。高度なデータ品質プロジェクト(たとえば名前と住所のクレンジング・プロジェクト)、および高度なデータ・プロファイリングの場合は、Oracle Date IntegratorとともにOracle Enterprise Data Quality製品を使用できます。

ヒント:

Oracle Enterprise Data Quality (EDQ)は、ODIのデータ品質機能を強化できます。EDQの詳細は、Oracle Enterprise Data Qualityドキュメントを参照してください。