リアルタイム・データ統合の概要

SOAにおけるセットベースのデータ統合タスクをデータベースで実行するJavaを基盤と したミドルウェア、Oracle Data Integratorの概要を説明します。

近年、複雑で"ホットプラガブル"なシステムとサービス指向アーキテクチャ（SOA）が主流とな り、データを統合してその意味を理解することがますます難しくなってきています。 主要アプリケーション・データベースをOracleデータベースで実行している場合でも、それ以外の規模の小さいシステムについては、ほかのベンダーの データベースやプラットフォームで実行するということも十分に考えられます。 また、Webサービスなどの技術を使用してアプリケーション間で相互通信がおこなわれる場合や、アプリケーションやデータを自社のデータ・センターで自ら 管理するだけでなく、それらがリモートでホスティングされる場合もあります。

Oracle Data Integratorは、 Oracle Fusion Middleware製品群の1つで、こうした複雑化する異機種環境でのデータ統合の必要性に対応しています。 Oracle Data Integratorは、データベースを使用してセットベースのデータ統合タスクを実行するJavaを基盤としたアプリケーションですが、その機能は Oracle Databaseだけでなく、さまざまなデータベース・プラットフォームをカバーしています。 また、Webサービスおよびメッセージを利用してデータ抽出や変換データを提供する機能のほか、サービス指向アーキテクチャにおいて、イベントへの対応や イベントの作成を実行できるようにするための統合プロセスを構築する機能も提供されています。

Oracle Data Integratorの製品アーキテクチャ

Oracle Data Integratorは、Javaグラフィカル・モジュールおよびスケジューリング・エージェントでアクセスするモジュール形式のリポジトリを中心に構築 されています。 グラフィカル・モジュールは、統合プロセスの設計と構築のために、統合タスクのスケジューリングおよび調整に使用するエージェントとあわせて使用されま す。 Oracle Data Integratorのプロジェクトが稼動段階に入ると、データ担当者は、WebベースのMetadata Navigatorアプリケーションを使用して、リポジトリ内のメタデータに関するレポートを作成できます。 また、標準のナレッジ・モジュールでは、プラットフォーム固有のコードとユーティリティを使用し、異機種のプラットフォームにまたがってデータの抽出およ びロードを実行します。

Oracle Data Integratorのリポジトリは、1つのマスター・リポジトリと1つ以上の作業リポジトリで構成されています。マスター・リポジトリには、ユーザーお よびロールの詳細、データベースやその他のデータソースへの接続、プロジェクトのバージョンなどが含まれ、作業リポジトリにはデータ統合に使用されるデー タ・モデルおよびマッピングの詳細が含まれています。 これらのリポジトリは、OracleとOracle以外のリレーショナル・データベースのどちらにも格納できます。また、グラフィカル・モジュールを使用 した管理や、エージェントによる実行時のアクセスも可能です。

Oracle Data Integratorプロジェクトの作成および管理には、以下の4つのグラフィカル・モジュールが使用されます。

• Designerは、データ・ストア（表、ファイル、Webサービスな ど）、インタフェース（データ・マッピング）、およびパッケージ（インタフェースを含む統合手順のセット）を定義するために使用します。
• Topology Managerは、データソースとエージェントに対する 接続の作成および管理に使用します。アクセスについては、通常、管理者のみに制限されています。
• Operatorは、製品の統合ジョブの参照および管理に使用します。
• Security Managerでは、ユーザーとユーザーのリポジトリ権 限を管理します。

宣言的な設計

通常、データ統合タスクには、以下の2つの主要領域があります。

• データのどの部分を変換してほかのデータと統合するかに関するビジネス・ルール
• 実際にデータの抽出やロードなどを実行する方法に関する技術的な詳細

タスク領域が上記のように明確に分割されているため、通常、ビジネス・ルールを定義する担当者に 最適なのは、各組織のビジネスまたはデータ関連の技術者であり、一方、技術的な詳細に関しては開発者やデータベース管理者などの技術スタッフに任せるほう がいい結果を得られます。 多くのデータ統合ツールの場合、このように担当を分割することは困難です。こうしたツールのデータ・マッピング機能では、同一データのマッピングにおける ビジネス・ルールと技術的な実装に関する詳細とが混同されているためです。 しかし、Oracle Data Integratorでは別のアプローチを取り入れ、データ・マッピングに対して、SQLのように宣言的な手法を採用しています。Oracle Data Integratorでは、このデータ・マッピングを"インタフェース"と呼んでいます。

新規インタフェースを作成する場合、開発者や技術ビジネス・ユーザーは、まず統合するデータと使 用するビジネス・ルールを定義します。 この手順で、表の結合、フィルタの適用、およびSQL式を使用したデータの変換を実行します。 どのSQLダイアレクトを使用するかは、コードを実行するデータベース・プラットフォームによって決まります。

技術スタッフはその後、別の手順で対象データの抽出、結合、そして統合を実行するためのもっとも 効率的な方法を選択し、増分ロード、バルク・ロード・ユーティリティ、緩やかに変化するディメンション、Changed Data Captureなどのデータベース固有のツールや設計技術を使用できます。

拡張可能なナレッジ・モジュール

Oracle Data Integratorでは、さまざまなデータベース・プラットフォームからデータをロードおよび変換します。また、イベントへの対応が可能であり、Web サービスなどのメッセージ・ベースの技術も使用します。このため、これらの各種データソースへのアクセスやロードに使用される技術は、高い柔軟性および拡 張性を備えながらも効率的なものである必要があります。 Oracle Data Integratorでは、ナレッジ・モジュールを使用することで、この問題を解決しています。

ナレッジ・モジュールは、Oracle Data Integratorの"プラグイン"で、特定のデータソースやターゲットのデータについて、ロード、変換、または統合する際のベスト・プラクティスがカ プセル化されています。 Oracle Data Integratorには、以下の図で示すとおり、6種類のナレッジ・モジュールがあります。

• リバースエンジニアリング・ナレッジ・モジュールは、ソース・データベース から表やその他のオブジェクト・メタデータを読み取る場合に使用します。
• ジャーナライズ・ナレッジ・モジュールは、単一の表/ビューと一貫性のある 表/ビューのセットのいずれかを使用して、新規データおよび変更データを記録します。
• ロード・ナレッジ・モジュールは、ソース・データベースからデータを効率的 に抽出するために使用します。また、利用可能な場合にはデータベース固有のバルク・アンロード・ユーティリティが含まれます。
• チェック・ナレッジ・モジュールは、ソース・データ内のエラー検出に使用し ます。
• 統合ナレッジ・モジュールは、ステージング領域からターゲットの表へのデー タ変換を効率的に実行し、特定のデータベース用に最適化されたネイティブSQLを生成するために使用します。
• サービス・ナレッジ・モジュールは、Webサービスとして公開する機能を提 供します。

ナレッジ・モジュールも拡張が可能であるため、標準のOracle Data Integratorで現在提供されていない機能を追加できます。 たとえば、Oracleを基盤とした既存のナレッジ・モジュールのセットを導入し、それを拡張してOracle Database 10gのOracle Data Pump機能に対応できるようにするというタスクも、比較的簡単に実行できます。

データ品質ファイアウォール

データ・ウェアハウスのロード担当者であれば間違いなく対処しなくてはならない問題の1つに、夜 間のロード実行に充てられる時間枠が刻々と減少しているという点があります。 時間の問題は、データ・ウェアハウスのステージング領域へのロードが完了しなければ検出できないエラーがソース・データに多数含まれている場合、とくに厳 しいものとなります。

この問題に対して、Oracle Data Integratorでは、チェック・ナレッジ・モジュールを使用してデータソースのダーティ・データの"ファイアウォールをオフ"にし、ビジネス・ルー ルに適合するデータだけが統合プロセスに入力されるようにするという革新的なアプローチを採用しています。 データ品質を効率的に保証するこのアプローチを使用することで、まずソース・オブジェクトで1つ以上の制約を定義し、その後チェック・ナレッジ・モジュー ルを使用して定義した制約に違反する行をすべて特定したあとで、それらの行をエラー表にコピーすることが可能になります。

さらに、その後の作業でソース・オブジェクトからデータを取得してインタフェースで使用する場 合、定義した制約に適合しているデータだけがロードされるようにしたり、エラー表のダーティ・データを別のプロセスとして処理したりすることができます。

Changed Data Captureのサポート

データのロード時間最短化に役立つもう1つのテクニックとして、新規データまたは変更データだけ をロードするという方法があります。 アプリケーションの設計者によって、新規データや変更データを特定するためのインジケータや日付を提供されることもありますが、多くの場合はこうした情報 を利用できず、関心のあるデータの特定についてはすべてをユーザー自身がおこなうことになります。

この点は一般的な要件であるため、Oracle Data Integratorには、ソース・データベースを監視し、新規レコードや変更されたレコードをジャーナルにコピーするためのジャーナライズ・ナレッジ・ モジュールが用意されています。書き込まれたジャーナルは、その後、オリジナルのソース表の代わりとして読み取ることができます。 オラクルをはじめとするデータベース・ベンダーによって、変更データ取得に対するネイティブ・サポートが提供されている場合、これらの機能はそこで使用で きますが、そうしたサポートがない場合には、ジャーナライズ・ナレッジ・モジュールでトリガーなどの技術を使用し、データ操作言語（DML）のアクティビ ティを取得して変更を有効にします。 Oracle Data IntegratorによるOracle Change Data Capture機能についてのサポート方法と、異なるデータベース・プラットフォームでのデータベースの増分ロードをリアルタイムで実行する方法について は、後述します。

Oracle Data IntegratorとOracle Warehouse Builderとの関係

これまでの説明で、Oracle Warehouse Builderのユーザーは、Oracle Data Integratorがどのように関わってくるのか、またはオラクルのほかのデータ・ウェアハウス・テクノロジー・スタックにOracle Data Integratorをどう適合させればいいのかという疑問が生まれる場合があります。 その疑問に対する答えとして、まず、Oracle Data IntegratorはOracle Warehouse Builderを補完するツールであるという点が挙げられます。また、Oracleデータ・ウェアハウスにおけるステージング・レイヤーおよび統合レイ ヤー作成関連の作業が重要になり、その作業にSOAまたはOracle以外のデータベース・ソースが関連している場合に、Oracle Data Integratorが役立つ可能性があります。

Oracle Warehouse Builderには、Oracleデータ・ウェアハウス構築の担当者のために、Oracle固有の強力なデータ・ウェアハウス機能のセットが用意されてい ます。この機能には、リレーショナル・データ構造および多次元データ構造のモデル化のサポート、Oracle Business Intelligence Discovererとの統合、緩やかに変化するディメンションのロードに対するサポート、データの構造とセマンティクスを理解するためのデータ・プロ ファイラなどがあります。

Oracle Data Integratorによる価値提供は、ソース・データの初期準備と統合から、データ・ウェアハウスのステージング領域にまで及びます。

Oracle Data Integratorでは、Webサービスやイベントベースのアーキテクチャを含め、多数の異種データソースからデータの統合と同期をおこなうことができ ます。さらに、上の図で示したように、Oracle Change Data CaptureなどのOracle Database固有の機能に加え、使いやすいグラフィカル・インタフェースも用意されています。 データを統合し、データ・ウェアハウスのステージング領域にコピーした後は、作業をOracle Warehouse Builderに引き継ぎ、オペレーショナル・データ・ストアとディメンション・ウェアハウスのレイヤーに関する作成および移入をおこなうことができま す。

ここまでOracle Data Integratorの概要を説明してきましたが、ここからは、実際のデータ統合シナリオでOracle Data Integratorがどのように使用されているかを確認していきます。

Oracle Data Integratorの使用：クロスプラットフォームのリアルタイム・データ統合

このシナリオでは、Oracleデータベースから注文と顧客データを取得し、ファイルに保存され ている従業員データと組み合わせてから、統合したデータをMicrosoft SQL Server 2000データベースにロードするというタスクを実行します。 注文は、受けると同時に分析する必要があるため、できる限りリアルタイムに近いタイミングでターゲット・データベースに渡し、ワークロードを最小限に抑え るために新規データおよび変更されたデータだけを抽出します。 また、Oracle Technology NetworkでOracle Data Integratorに関する情報を得て、この新しいツールを使用してデータを抽出およびロードします。

最初に、以下の図に示すようにOracle Data Integratorにログインし、Topology Managerを開始します。

Oracle Data Integratorでは、物理データベース、サービス、またはイベントベース・データソースをデータ・サーバーと呼びます。 Topology Managerを使用して、以下の3つのデータ・サーバーを新規に作成します。

1. SYSTEMユーザーの資格証明で設定され、データベースのORDERSスキーマおよび ORDERS_WORKAREAスキーマにマッピングされた、Oracle Databaseデータ・サーバー。 ORDERSスキーマには抽出対象の注文データが含まれます。もう一方のORDERS_WORKAREAスキーマは、Oracle Data Integratorで作成する作業表を格納するために、空のスキーマとしてユーザーが特別に設定するスキーマです。 この接続をおこなうには、Oracle JDBCドライバを使用します。
2. 従業員に関する詳細を含むカンマ区切りファイルにマッピングされた、ファイル・データ・ サーバー。 この接続をおこなうには、Sunopsis File JDBCドライバを使用します。
3. ORDERS_DATA_MARTと呼ばれるデータベースにマッピングされた、 Microsoft SQL Serverデータ・サーバー。 この接続をおこなうには、Sun JDBC-ODBC Bridge JDBCドライバを使用するか、Microsoft WebサイトからダウンロードできるMicrosoft JDBCドライバを使用します。

データ・サーバーを定義した後、Topology Managerを終了し、Designerを開始します。 Designerを使用して、Oracle、ファイル、およびMicrosoft SQL Serverの表とファイルを示すためのデータ・モデルを作成します。これらの表やファイルは、Oracle Data Integratorではデータ・ストアと呼ばれます。 まず、OracleおよびMicrosoft SQL Serverのモデルを作成してから、以下の図で示すとおり、リバース機能を使用して表のメタデータをOracle Data Integratorのリポジトリにインポートします。

データ・モデルが定義され、ソース表とターゲット表、およびファイルの詳細について、リバース・ エンジニアリングを実行するかマニュアルで入力すると、以下の図のように、プロジェクトで使用するすべてのデータ・ストアのリストがDesignerで表 示されます。

基礎となるソース表に定義された主キーがないことを確認した後、主キーを定義し、 Designerアプリケーションを使用して、Oracle Data Integratorで定義した主キーが"実質的"に強制されるようにします。これは、Oracle Data Integratorのマッピング機能の多くが、制約の定義に依存しているためです。

データ・ストアを定義すると、ソース・データを取得するためのChanged Data Captureプロセスに関する設定を開始できます。

ただし、この設定を開始する前に、Changed Data Capture機能を使用できるようにするナレッジ・モジュールをプロジェクトにインポートします。 インポートを実行するには、Designerアプリケーションの「 Projects」タブをクリックし、インポート先 のプロジェクトを右クリックしてから、「 Import」→「 Import Knowledge Modules」の順に選択します。 リストから以下のナレッジ・モジュールを選択します。これにより、Changed Data Capture機能が使用可能になります。また、このモジュールはプロジェクトのほかの部分でも使用されます。

• CKM SQL
• IKM SQL Incremental Update
• JKM Oracle 10g Consistent（LOGMINER）
• LKM File to SQL
• LKM SQL to SQL

これで、必要なナレッジ・モジュールが利用可能となりました。以前に作成したOracleモ ジュールを編集し、「 Journalizing」タブを選択します。 ORDERS表とCUSTOMER表への変更を一貫性のある方法で取得する必要があるため、ここでは「 Consistent」 オプションと「 JKM Oracle 10g Consistent (LOGMINER)」ナレッジ・モジュールを 選択します。 以下の図は、選択したナレッジ・モジュールを示しています。このナレッジ・モジュールでは、Oracle Database 10gのLogMiner機能を使用して、新規データおよび変更データを取得します。また、Oracle Streamsを使用してキュー全体における変更を非同期で伝播します。

このナレッジ・モジュールには、3つの構成オプションが表示されます。 ここでは以下の値を選択してモジュールを構成します。

• Asynchronous Mode：Yes
• Auto-Configuration：Yes
• Journal Table Options：default

「 Apply」をクリックして変更を保存してから、「 OK」をク リックして構成を完了します。 次に、Changed Data Captureセットに表を追加する必要があります。

これを処理するには、Designerのモデル・リストでOracleデータ・サーバーを指定 し、CUSTOMERS表とORDERS表を右クリックして、「 Changed Data Capture」→「 Add to CDC」の順に選択します。 その後、再度 Journalized Tablesタブでモデルを編集し、上矢印/下矢印キーを使用 してORDERS表がCUSTOMERS表よりも上になるように配置します。

これで、これらの2つの表から変更されたデータを取得するためのジャーナルを作成する準備が完了 しました。 ジャーナルを作成するには、再度モデルを右クリックし、「 Changed Data Capture」→「 Start Journal」の順に選択します。 「 OK」をクリックしてコードをローカルで実行したら、Operatorアプリケーションを 開始して、作業の進捗を確認してください。 すべてが正常に進んだ場合、以下のように、完了した手順のリストが表示されます。

プロセスでエラーが発生した場合、その原因は通常、必要な権限のないユーザー・アカウントを使用 してOracleの接続を定義したことにあります。 残りの作業に進む前に、指定したユーザーの詳細とOracle Data Integratorの文書を確認してエラーを解決してください。

次に、ジャーナルにサブスクライバを追加します。これを実行するには、Designerアプリ ケーションに戻り、Oracleソース・データ・サーバーを右クリックして「 Changed Data Capture」→「 Subscriber」 →「 Subscribe」の順に選択します。 新しいサブスクライバを追加してコードをローカルで実行し、そのコードが適切に実行されていることを確認します（一部の操作によって警告が表示される場合 がありますが、これは必要としている表が以前の手順ですでに作成されているためです）。 この手順が終わると、Changed Data Captureプロセスの設定が完了し、インタフェースの作成を開始できます。

このプロジェクトでは、2つのインタフェースが必要となります。その1つは、以下の図に示すとお り、Oracleソース・データベースからの既存データ・セットを取得し、それをソース・ファイル内のデータと結合してターゲットのMicrosoft SQL Serverデータベースにロードします。

ターゲット表の列の一部は自動的にマッピングされていますが、SALES_PERSON_ID、 SALES_PERSON_NAME、CUSTOMER_NAMEなどのように、初期段階ではマッピングされていない列もあります。これは、マッピング・ プロセスにおいて一致するソース列が見つからなかったためです。 これらの列については、ここでマニュアルでマッピングします。この操作には式エディタを使用し、変換を実行する場所に基づいて、ソース・データベースと ターゲット・データベースいずれかの構文を使用したSQL式を入力します。

「 Flow」タブをクリックすると、以下の図に示すとおり、 データのロードとその後のデータ統合に実際に使用するナレッジ・モジュールを確認できます。

Oracle Data Integratorでは、任意のデータベースやファイルからのデータ抽出と、その後のデータベースへの増分データのロードを可能にするデフォルトのナ レッジ・モジュールが選択されています。 これらのナレッジ・モジュールは、使用している特定のデータベースおよびバージョンに適したモジュールにあとで変更できますが、ここではデフォルトのまま にしておきます。

最後に、以下の図に示すとおり、「 Control」タブをクリックし、ターゲット 表での制約違反によって発生したエラーの処理に使用するControlナレッジ・モジュールを選択します。 「 CKM SQL Knowledge Module」を選択します。これは、ISO-92準拠のデータベースでエラーのあるデータを処理するナレッジ・モジュール です。

これで、インタフェースをテストする準備が整いました。 このテストを実行するには、インタフェースのダイアログで右下隅に表示されている「 Execute」をクリックし、Operatorアプリ ケーションを開いてインタフェースに関する進捗状況を確認します。進捗状況は、以下の図のように表示されます。

エラーが発生することなくインタフェースの実行が完了したため、Designerアプリケーショ ンのターゲット・データ・ストアに移動し、ロードしたデータを参照します。これは、以下の図のように表示されます。

これで初期ロードの設定が完了したため、インタフェースを定義して、これまでに作成したジャーナ ルの表を使用して新規データおよび変更データをロードできます。

これらのデータ・ロードをおこなうために別のインタフェースを作成しますが、今回は CUSTOMERSソース表とORDERSソース表を追加する際に、データ・ストアのコンテンツではなく、ジャーナル処理されたデータを使用することを示 すチェック・ボックスをクリックします。 以下の図に示すように、ジャーナル処理がおこなわれた表の1つでこの操作を実行すると、一貫性のあるセットのほかの表すべてに対し、このチェック・ボック スが自動的に選択されます。

ジャーナル処理された表をインタフェースに追加した後に、残りのインタフェースについても前述の インタフェースと同じ方法で構成します。ただし、2つ目のインタフェースについては、ソース表ではなくジャーナライズされたデータからのデータが元になっ ているという点が唯一異なっています。

この2つ目のインタフェースをテストするには、ORDERS表とCUSTOMERS表に新規レ コードを挿入し、ジャーナルのウィンドウを拡張するためのDesignerインタフェースを使用します。このウィンドウは後で自動的に拡張され、 Oracle Data Integratorパッケージの一部として消去します。 この時点では、以下の図に示すように、Oracleデータ・モデルを右クリックしてコンテキスト・メニューから「 Changed Data」 →「 Consumption」→「 Extend Window」を選択し、新規データと変更されたデータの最新のセットを2 つ目のインタフェースで利用できるようにします。

関連するデータ・ストアを右クリックし、「 Changed Data Capture」の次に「 Journal Data」…と選択すると、どの行がジャーナルの表にあ るかを迅速に確認できます。また、エディタで再度インタフェースを開いて画面の右下隅の「 Execute」をクリック すると、そのインタフェースを実行できます。

初期データ・セットは、最初に作成したインタフェースを使用してすでにターゲット・データ・マー トにロードされているため、Oracle Data Integratorパッケージを作成して、以下の手順を実行します。

1. ORDERSおよびCUSTOMERのジャーナライズされたデータをチェックして、新規 データまたは変更データが追加されているかどうかを確認します。 事前定義された数のジャーナル・レコードが検出されたら、パッケージの残りの部分を実行するか、またはデータをロードせずに最後の手順にジャンプします。
2. ジャーナライズされたデータが検出された場合、ジャーナル・ウィンドウを拡張します。
3. インタフェースを実行してジャーナライズされたデータから読み取り、読み取ったデータを ファイルに結合して、ターゲット・データ・ストアをロードします。
4. ジャーナル・ウィンドウを消去します。
5. このパッケージを再度開始します。

このパッケージを作成してOracle Data Integratorのシナリオとして配置することで、リアルタイムで継続的に実行されるETL（抽出、変換、およびロード）プロセスが効率的に作成され ます。 Oracle Data Integratorのイベント検出機能を使用することで、設定された数の変更データ・レコードが検出されるか設定された時間（ミリ秒）が経過すると、機 能が自動的に開始されます。 ジャーナライズされたデータの量とタイムアウトについての適切なしきい値を設定することで、待機時間が最小限となるようにリアルタイム統合プロセスを作成 できます。

このパッケージを作成するには、Designerアプリケーションの Projectsタ ブに移動し、以前に定義したインタフェースを含むフォルダを指定して、Packagesエントリを見つけてそれを右クリックし、「 Insert Package」を選択します。 作成したパッケージに名前を付けてから、パッケージ詳細ダイアログ・ボックスの Diagramタ ブに移動します。

以下の図に示すように、右側のツールボックスを使用して、 Event Detectionフォルダに移動し、OdiWaitForLogDataツールをパッケージ・キャンバスに追加します。 このツールにより、定期的にジャーナライズされるデータがポーリングされ、行が検出されない場合は失敗となり、設定された数の行がジャーナル内で検出され た場合はパッケージの次の手順へと進むことになります。

ツール・プロパティを設定し、以前に定義したChanged Data Captureセットをチェックして、合計で3つのジャーナル行が検出されるか、チェック開始後1秒が経過した場合に終了するようにします。

次に、新規データで読取りをおこなえるように、ジャーナル・ウィンドウを拡張する手順を追加しま す。 この処理を実行するには、モデルのリストに移動し、Oracleモデルをキャンバスにドラッグ・アンド・ドロップします。 以下の図で示すとおり、モデルを選択してプロパティを表示し、そこで Model Typeリストを Journalizing Modelに変更します。

その後、「 Extend Window」チェック・ボックス をクリックして、そのジャーナルの手順がジャーナル・ウィンドウを拡張するものであることを示します。

次に、ジャーナルからマッピング用にデータを取得するインタフェースを追加して、再度パッケージ にOracleモデルを追加します。ただし今回は、読取りの後にジャーナルを消去する「 Purge Window」オ プションを選択します。 最後に、ツールボックスの UtilitiesフォルダからOdiStartScenツールを 追加して完了後に再度開始されるようにします。また、コネクタも追加し、以下の図で示すように、最初の手順でジャーナル行が検出されるかどうかに基づいて 手順の流れが表示されるようにします。

最後のOdiStartScen手順は、市販バージョンのパッケージのシナリオを参照しているた め、Designerアプリケーションの Projectタブで作業中のパッケージを指定して右クリックし、「 Generate Scenario」を選択します。 シナリオ作成後、作成したシナリオ名を参照するようにOdiStartScen手順のプロパティを編集します。 この最後の手順をパッケージに追加することで、パッケージが継続的に実行され、新規データおよび変更されたデータがOracleソース表からターゲット・ データベースにリアルタイムで伝播されるようになります。

まとめ

Oracle Fusion Middleware製品群に新しく追加されたOracle Data Integratorにより、幅広いプラットフォームでデータ、イベント、およびサービス指向統合の実行が可能となります。 また、Oracle Warehouse Builderを補完するとともに、データのバルク・ロードやOracle Change Data CaptureなどのOracle Database固有の機能に対するグラフィカル・インタフェースも提供します。 この記事では、異機種プラットフォームでリアルタイム・データ統合プロセスを作成するためのOracle Data Integratorの使用方法と、実装の詳細ではなくビジネス・ルールに焦点を当てた統合プロセスを可能にする宣言的なアプローチについて取り上げました。

Mark Rittman（ http://www.rittmanmead.com/blog/） はOracle ACEの一員で、Rittman Mead Consultingの共同創立者です。オラクルのビジネス・インテリジェンスおよびデータ・ウェアハウスを専門とするスペシャリストとして、イギリスを 拠点にオラクルのパートナーとして活躍しています。 また、OTNおよびOTN Forumsにも常時貢献しているほか、2008年に出版予定のOracle Pressの書籍『Oracle Business Intelligence Suite Developers’ Guide』の著者の1人としても名を連ねています。