| Oracle® Fusion Middleware Oracle Data Integrator開発者ガイド 11g リリース1 (11.1.1) B62260-01 |
|
 前 |
 次 |
この章の内容は、次のとおりです。
データ統合によって、複雑なシステム全体で情報の適時性、正確性および一貫性が確保されます。この項では、データ統合の概要を説明し、Oracle Data Integratorによるデータ統合のサポート方法についても説明します。
企業全体でデータとアプリケーションを統合し、統一されたビューで示すことは、難しい課題です。テクノロジ、データ構造、アプリケーション機能に明らかな差異があるのみでなく、統合アーキテクチャにも基本的な相違があります。一部の統合ニーズ、特に大量のデータを統合する場合のニーズはデータ指向です。他の統合プロジェクトでは、非同期統合または同期統合のために、プロジェクト自体がイベント駆動型アーキテクチャ(EDA)またはサービス指向アーキテクチャ(SOA)に適合するようにします。
データ統合によって、複雑なシステム全体で情報の適時性、正確性および一貫性が確保されます。データ統合は、当初は企業データ・ウェアハウス・システムのロードに使用されるアーキテクチャと考えられていたため、今でも抽出-ロード-変換(ETL)と呼ばれることがよくありますが、現在では、データ移動、データ同期、データ品質、データ管理およびデータ・サービスが含まれます。
Oracle Data Integratorには、複雑なデータ・ウェアハウスを構築、デプロイおよび管理するため、あるいはSOAまたはビジネス・インテリジェンス環境のデータ集中型アーキテクチャの一部として、完全に統一されたソリューションが用意されています。さらに、データ統合のすべての要素(データ移動、データ同期、データ品質、データ管理およびデータ・サービス)が結合され、複雑なシステム全体で情報の適時性、正確性および一貫性が確保されます。
Oracle Data Integrator (ODI)の特徴は、データ統合のあらゆるスタイル(データ中心、イベント中心、サービス中心)を組み込んだアクティブな統合プラットフォームです。ODIでは、大量のデータの効率的な変換、高度なチェンジ・データ・キャプチャ(CDC)機能によるリアルタイムのイベント処理、Oracle SOA Suiteに対するデータ・サービスの提供によって、分断化状態の統合が統一されます。また、堅牢なデータ整合性制御機能によって、データの一貫性と正確性が保証されます。異種のE-LT、宣言的な設計、ナレッジ・モジュールなど、中核となる強力な差別化機能によって、Oracle Data Integratorは、統合プラットフォームのパフォーマンス、柔軟性、生産性、モジュール性およびホットプラガブル性の要件を満たします。
従来のETLツールの動作では、最初に各種ソースからデータが抽出され、ステージング領域として使用される独自の中間層ETLエンジンでデータが変換された後、変換したデータがターゲット・データ・ウェアハウスまたは統合サーバーにロードされます。このようにETLという用語は、図1-1に示すように、実行される動作の名前と順序の両方を表しています。
ETLプロセスのデータ変換ステップはコンピュータ資源を大量消費する処理であり、専用サーバー上の独自のETLエンジンによってすべて実行されます。ETLエンジンでは、行単位でデータ変換が実行(場合によってデータ品質チェックも実行)されるため、プロセス全体のボトルネックになることがよくあります。また、データはネットワーク上を2回(1回はソースとETLサーバー間、もう1回はETLサーバーとターゲット・データ・ウェアハウス間)移動する必要があります。さらに、データ・フロー参照をターゲット・データ・ウェアハウスの値と比較することによって参照整合性を保証する場合、参照されるデータをターゲットからエンジンにダウンロードする必要があるため、ネットワーク・トラフィックとダウンロード時間がさらに増加し、パフォーマンスの問題が深刻化します。
ETLアーキテクチャによって提起された問題に対応して、新しいアーキテクチャが出現しています。このアーキテクチャでは、手作業によるコーディングと自動コード生成アプローチの最良の特徴が様々な方法で統合されています。E-LTと呼ばれるこの新しいアプローチでは、データ変換が行われる場所と方法が変更され、既存の開発者のスキル、RDBMSエンジンおよびサーバー・ハードウェアが最大限に活用されます。実際には、E-LTでは操作の順序が変更されて、データ変換ステップがターゲットRDBMSに移動されています。つまり、ソース表からのデータの抽出、宛先サーバーへの表のロード、およびネイティブSQL演算子を使用したターゲットRDBMSでのデータの変換という順序になります。E-LTを使用した場合は、図1-1に示した中間層エンジン(サーバー)が必要ないことに注意してください。
Oracle Data Integratorでは、ETLスタイルとE-LTスタイルの両方のデータ統合がサポートされています。詳細は、11.5項「統合インタフェースの設計: E-LTスタイルのインタフェースとETLスタイルのインタフェース」を参照してください。
この項では、Oracle Data Integratorの主要概念の概要を示します。
従来のETLシステムを使用して統合プロセスを設計する場合、開発者はプロセスの各ステップを設計する必要があります。たとえば、一定期間の売上高を顧客の様々な年齢別グループで集計する一般的な例について考えます。売上データは売上管理データベースから取得され、年齢別グループは年齢分布ファイルに記載されています。これらのソースを組み合せて、顧客統計システムに対して適切なレコードを挿入および更新するには、次のような各ステップを設計する必要があります。
エンジンにある顧客売上データをロードします。
エンジンにある年齢分布ファイルをロードします。
顧客売上データと年齢分布データ間のルックアップを実行します。
年齢分布別にグループ化した顧客売上高を集計します。
ターゲット売上統計データをエンジンにロードします。
集計した情報を統計システムのデータと比較して、挿入または更新が必要なデータを判別します。
新しいレコードをターゲットに挿入します。
既存のレコードをターゲットに更新します。
この方法では、設計する必要があるステップに応じて特別なスキルが要求されます。また、ターゲットでの挿入/更新の管理など、反復する一連のタスクでも、各タスクで開発が必要であるため、開発にはかなりの労力が必要です。最終的に、この方法ではメンテナンスにもかなりの労力が必要です。統合プロセスの変更では、プロセスによる処理内容の完全な理解および処理方法の知識が必要です。従来のETL方法による設計では、統合の論理面と技術面が密接に関係しています。宣言的設計は、処理方法(プロセス)ではなく、処理内容(宣言的ルール)を中心にした設計方法です。ここで示す例では、プロセスの処理内容は次のとおりです。
売上アプリケーションからの顧客年齢を、統計ファイルの年齢別グループに関連付けます。
年齢別グループで顧客売上を集計して、売上統計をロードします。
この処理の実行方法、つまり一時データ構造の作成やローダーの呼出しなど、この統合タスクを実行するための基礎となる技術的な側面や戦略は、宣言的ルールから明確に切り離されます。
Oracle Data Integratorの宣言的設計では、既知のリレーショナル・パラダイムを使用して、ソース、ターゲットおよび変換の指示を含んだ、データ統合タスクに対する宣言的ルールがインタフェースの形式で宣言されます。
宣言的ルールは、データを変換するためにメタデータに適用されることが多く、通常は、ビジネス・ユーザーが自然言語で記述します。通常のデータ統合プロジェクト(データ・ウェアハウス・プロジェクトなど)では、これらのルールは、ビジネス・アナリストがプロジェクト・マネージャと協力して作成したドキュメントに、仕様の段階で定義されます。参照するメタデータが既知であり、メタデータ・リポジトリで修飾されている場合、ルールはSQL式を使用して実装されることがよくあります。
宣言的ルールの主要なタイプは、マッピング、結合、フィルタおよび制約の4つです。
マッピングは、SQL式として実装されるビジネス・ルールであり、ソース列(フィールド)をターゲット列の1つにマップする変換ルールです。マッピングは、実行時にリレーショナル・データベース・サーバーによって実行されます。このサーバーには、ソース・サーバー(可能な場合)、中間層サーバーまたはターゲット・サーバーを使用できます。
結合操作では、表やファイルなど、複数のデータ・セット内のレコードがリンクされます。結合は、複数のソースをリンクするために使用され、2つ以上のデータ・セットの列(フィールド)をリンクするSQL式として実装されます。結合は、関係するソース・データ・セットの物理的な位置に関係なく定義できます。たとえば、JMSキューをOracle表に結合できます。結合を実行するテクノロジに応じて、結合は、内部結合、右の外部結合、左の外部結合および完全外部結合として表すことができます。
フィルタは、ソース・データ・セットの列に適用される式です。このフィルタに一致するレコードのみが、データ・フローによって処理されます。
制約は、データ・セットのデータに適用されるルールを定義するオブジェクトです。制約によって、特定のデータ・セット内のデータの妥当性、およびモデルのデータの整合性が保証されます。ターゲットに対する制約は、ターゲットでの統合前にデータの妥当性をチェックするために使用されます。
表1-1は、宣言的ルールの例を示しています。
表1-1 宣言的ルールの例
| 宣言的ルール | タイプ | SQL式 |
|---|---|---|
|
全金額の合計、つまり2005年10月に販売された品目に品目価格を乗算した金額 |
マッピング |
SUM( CASE WHEN SALES.YEARMONTH=200510 THEN SALES.AMOUNT*product.item_PRICE ELSE 0 END ) |
|
CPUで始まり、ハードウェア・カテゴリに属する製品 |
フィルタ |
Upper(PRODUCT.PRODUCT_NAME)like 'CPU%' And PRODCUT.CATEGORY = 'HARDWARE' |
|
注文および注文明細がある顧客 |
結合 |
CUSTOMER.CUSTOMER_ID = ORDER.ORDER_ID And ORDER.ORDER_ID = ORDER_LINE.ORDER_ID |
|
重複顧客名の拒否 |
一意キー制約 |
Unique key (CUSTOMER_NAME) |
|
存在しない顧客へのリンクが指定されている注文の拒否 |
参照制約 |
Foreign key on ORDERS(CUSTOMER_ID) references CUSTOMER(CUSTOMER_ID) |
ナレッジ・モジュール(KM)は、統合プロセスが発生する方法を実装しています。ナレッジ・モジュールの各タイプは、それぞれ特定の統合タスクを表します。
異種システムのメタデータをOracle Data Integratorで使用するためのリバースエンジニアリング(RKM)。RKMの使用方法の詳細は、第5章「モデルの作成およびリバースエンジニアリング」を参照してください。
特定のシステムにおけるチェンジ・データ・キャプチャ(CDC)の処理(JKM)。ジャーナル化ナレッジ・モジュールの使用方法の詳細は、第7章「チェンジ・データ・キャプチャの使用」を参照してください。
システムに最適な方法を使用した、あるシステムから別のシステムへのデータのロード(LKM)。これらのKMは、インタフェースで使用されます。ロード・ナレッジ・モジュールの使用方法の詳細は、第11章「統合インタフェースの使用」を参照してください。
特定の戦略(挿入/更新、緩やかに変化するディメンジョン)を使用した、ターゲット・システムでのデータの統合(IKM)。これらのKMは、インタフェースで使用されます。統合ナレッジ・モジュールの使用方法の詳細は、第11章「統合インタフェースの使用」を参照してください。
データ・フローでのデータ整合性の制御(CKM)。これらのKMは、データ・モデルの静的チェックおよびインタフェースのフロー・チェックで使用されます。チェック・ナレッジ・モジュールの使用方法の詳細は、第5章「モデルの作成およびリバースエンジニアリング」および第11章「統合インタフェースの使用」を参照してください。
Webサービスの形式でのデータの公開(SKM)。サービス・ナレッジ・モジュールの使用方法の詳細は、第8章「データ・サービスの使用」を参照してください。
ナレッジ・モジュールは、特定の統合タスクのためのコード・テンプレートです。このコードは、処理する必要がある宣言的ルールから独立しています。設計時に、開発者は統合プロセスを記述する宣言的ルールを作成します。これらの宣言的ルールはナレッジ・モジュールとマージされ、実行時に使用できるコードが生成されます。実行時に、Oracle Data Integratorによって、このコードがソース・システムとターゲット・システムに実行用に送信され、プロセスを実行するためにE-LTアーキテクチャで利用されます。
ナレッジ・モジュールのテクノロジと技術は広範囲にわたります。ナレッジ・モジュールは、ある状況の特定のタスクに対して最適なソリューションや微調整されたソリューションにユーザーがアクセスできるようにして、柔軟性を高めます。たとえば、データをあるDBMSから別のDBMSに転送する場合、開発者は状況に応じて複数の方法のいずれかを使用できます。
DBMSローダー(OracleのSQL*Loader、Microsoft SQL ServerのBCP、Teradata TPump)は、ソース・エンジンのデータをファイルにダンプし、このファイルをターゲット・エンジンにロードできます。
データベース・リンク機能(Oracle Database Links、Microsoft SQL ServerのLinked Servers)はサーバー間で直接データを転送できます。
これらの技術的戦略は特に、特定のプラットフォームのネイティブな機能を使用するようにチューニングされたナレッジ・モジュールに対応しています。
また、ナレッジ・モジュールは完全に拡張可能です。コードはオープンであり、新しい統合メソッドやベスト・プラクティスを実装する技術専門家は、グラフィカル・ユーザー・インタフェースを使用してコードを編集できます(たとえば、パフォーマンスの向上を目的として、または法令や会社の標準に準拠するため)。開発者は、技術専門家のスキルがなくても、これらのカスタム・ナレッジ・モジュールを統合プロセスで使用できます。
ナレッジ・モジュールの詳細は、Oracle Data Integrator接続性およびモジュール・ガイドおよびOracle Data Integratorナレッジ・モジュール開発者ガイドを参照してください。
統合インタフェースは、保存されたOracle Data Integratorオブジェクトです。このオブジェクトを使用すると、マッピング、結合、フィルタおよび制約として実装される宣言的ルールに基づいて、1つ以上のソース・データストアから変換されたデータを1つのターゲット・データストアにロードできます。
統合インタフェースは、統合プロセスの生成に使用されるナレッジ・モジュール(コード・テンプレート)も参照します。
データストアは、統合インタフェースでソースまたはターゲットとして使用できるデータ構造です。次に例を示します。
リレーショナル・データベースに格納された表
ASCIIまたはEBCDICファイル(デリミタ付きまたは固定長)
XMLファイルのノード
メッセージ指向ミドルウェアのJMSトピックまたはキュー
エンタープライズ・ディレクトリのノード
レコード配列の形式でデータを戻すAPI
基礎となるテクノロジに関係なく、Oracle Data Integratorでは、すべてのデータ・ソースが、同じ方法で操作および統合が可能なデータストアの形式で表示されます。データストアはデータ・モデルにグループ化されます。これらのモデルには、データストアに関連付けられる制約などのすべての宣言的ルール(メタデータ)が含まれます。
インタフェースを構成する宣言的ルールは、通常の言語で表すことができます。たとえば、次の例のように記述します。データは2つのMicrosoft SQL Server表(ORDER_LINESとそれに結合されたORDERS)から取得され、CORRECTIONSファイルのデータと結合されます。ターゲットのSALES Oracle表は、ID列が一意であることやSALES_REP表に対する有効な参照があることなど、いくつかの制約を照合する必要があります。
データは、図1-2に示すように、通常の言語で表されるいくつかのマッピングに従って変換および集計する必要があります。
これらのビジネス・ルールの自然言語からSQL式への変換は、通常は簡単な作業です。この例では、図1-2に示したルールは、表1-2に示すように変換できます。
表1-2 変換されたビジネス・ルール
| タイプ | ルール | SQL式/制約 |
|---|---|---|
|
フィルタ |
クローズ済のマークが付けられたORDERSのみ |
ORDERS.STATUS = 'CLOSED' |
|
結合 |
LINESの行に、ORDERSのものと一致するORDER_IDがあります |
ORDERS.ORDER_ID = LINES.ORDER_ID |
|
マッピング |
ターゲットのSALESが営業担当者別にグループ化された注文明細のAMOUNTの合計で、修正が適用されています |
SUM(LINES.AMOUNT + CORRECTIONS.VALUE) |
|
マッピング |
営業担当者 = ORDERSの営業担当者ID |
ORDERS.SALES_REP_ID |
|
制約 |
IDはnullでないことが必要です。 |
IDはデータ・モデルでnot nullに設定されています |
|
制約 |
IDは一意であることが必要です |
一意のキーが列セットとしての(ID)でデータ・モデルに追加されています |
|
制約 |
営業担当者IDがターゲットのSalesRep表に存在している必要があります |
参照(外部キー)が |
Oracle Data Integratorを使用してこのビジネス課題を実装することは、非常に簡単でわかりやすい課題です。ビジネス・ルールをインタフェースに変換するのみで実装できます。図1-3に示すように、すべてのビジネス・ルールがインタフェースのダイアグラムからアクセス可能な状態のままです。
インタフェースで定義されたビジネス・ルールは、データ・フローに自動的に変換されます。データ・フローでは、ソース・データからターゲット表への結合、フィルタ、マッピングおよび制約が実行されます。
デフォルトでは、Oracle Data Integratorでは、ターゲットRBDMSがステージング領域として使用されます。この領域は、ソース・データを一時表にロードし、必要なすべてのマッピング、ステージング・フィルタ、結合および制約を適用するための領域です。ステージング領域は、RDBMS(ユーザー/データベース)内の別個の領域です。この領域に、Oracle Data Integratorによってその一時オブジェクトが作成され、一部のルール(マッピング、結合、最終フィルタ、集計など)が実行されます。このように操作を実行する場合、Oracle Data IntegratorはE-LTのように動作します。つまり、最初に一時表が抽出され、ロードされた後、最後にターゲットRDBMSで変換が実行されます。
一部の特定のケースでは、ソースのデータ量が少ない(500,000レコード未満)場合、このステージング領域をメモリー内のOracle Data Integratorのメモリー内リレーショナル・データベース(メモリー内エンジン)に配置できます。この場合、Oracle Data Integratorは従来のETLツールのように動作します。
図1-4に、最終的なSALES表をロードするためにOracle Data Integratorによって自動的に生成されるデータ・フローを示します。ビジネス・ルールは、ナレッジ・モジュール(KM)によってコードに変換されます。作成されたコードによって、複数のステップが生成されます。これらのステップの一部で、データがソースから抽出されてステージング領域にロードされます(ロード・ナレッジ・モジュール - LKM)。他のステップでは、データが変換されて、ステージング領域からターゲット表に統合されます(統合ナレッジ・モジュール - IKM)。データ品質を保証するために、チェック・ナレッジ・モジュール(CKM)によって、ユーザー定義制約がステージング・データに適用され、エラーのあるレコードはエラー表に分離されます。
Oracle Data Integratorのナレッジ・モジュールには、インフラストラクチャの様々なサーバーによって実行される実際のコードが含まれています。ナレッジ・モジュールに含まれているコードの一部は汎用的です。実行時に、ビジネス・ルールに結合されるOracle Data Integratorの置換APIをコールして、実行される最終的なコードを生成します。
設計時には、宣言的ルールはインタフェースで定義され、ナレッジ・モジュールは選択および構成されるのみです。
実行時に、コードが生成され、ナレッジ・モジュールのOracle Data Integratorの各APIコール(<%と%>に囲まれた部分)は、リポジトリに提供されているメタデータに関しては、対応するオブジェクト名または式で置換されます。生成されたコードは、ソースおよびターゲット・システム上のOracle Data Integratorのランタイム・コンポーネント(エージェント)によって調整されて、E-LTアプローチの定義に従って、処理が実行されるようにします。
統合インタフェースの使用方法の詳細は、第11章「統合インタフェースの使用」を参照してください。
Oracle Data Integratorの統合機能は広範囲にわたります。この項では、最も一般的なODI統合プロジェクトについて説明します。
ODIは、すべての主要データベース、データ・ウェアハウスおよび分析アプリケーションに対する組込みの接続を備えた総合的なデータ統合プラットフォームであり、大規模かつ高パフォーマンスなバッチ統合を提供します。
データ・ウェアハウスの主な目的は、ビジネス・ユーザーが日常業務に関する意思決定を行うことができるように、正確な指標を整理統合して配信することです。一般的なプロジェクトは、複数のステップとマイルストンで構成されます。次にその一部を示します。
ビジネス・ニーズ(キー・インジケータ)の定義
キー・インジケータに関係するソース・データの識別、ソース情報をキー・インジケータに変換するためのビジネス・ルールの指定
キー・インジケータを格納するターゲット・ウェアハウスのデータ構造のモデル化
ビジネス・ルールの実装によるインジケータの移入
データ品質ルールの設定によるデータの全体的な正確度の測定
キー・インジケータに関するレポートの開発
非定型問合せツールまたは事前定義レポートを使用した、ビジネス・ユーザーによるキー・インジケータおよびメタデータの利用可能化
ビジネス・ユーザーの満足度の測定およびキー・インジケータの追加/変更
Oracle Data Integratorでは、これらのほとんどのステップ(ソース・データの検証からメタデータ系統、およびロードやデータ品質監査まで)を実行できます。ODIでは、そのリポジトリによって、仕様および開発作業が集中管理され、プロジェクトの成功の基礎となる独自のアーキテクチャが提供されます。
シナリオのスケジュールおよび操作
シナリオのスケジュールおよび操作は通常、テスト環境および本番環境で別々の作業リポジトリで実行されます。シナリオはオペレーティング・システム・コマンドで呼び出せるため、ODIエージェントまたは外部スケジューラによって任意のシナリオをスケジュールできます。
シナリオを本番で実行している場合は、エージェントによってODI作業リポジトリに実行ログが生成されます。これらのログは、オペレータ・ナビゲータを使用して、またはOracle Data Integratorコンソールが設定されている場合はWebブラウザを使用して監視できます。失敗したジョブは再開でき、実行のために非定型のタスクを発行できます。
E-LT
ODIでは、独自のE-LTアーキテクチャが使用されます。このアーキテクチャでは、すべての変換を実行するネイティブSQLとバルク・ローダー制御スクリプトの生成によって、既存のRDBMSエンジンの機能が利用されます。
メッセージ指向ミドルウェアまたはエンタープライズ・サービス・バスからのイベントの取得は、リアルタイム環境におけるアプリケーション統合の一般的なタスクになりました。アプリケーションおよびビジネス・プロセスは、複数のサブスクライバに対するメッセージを生成するか、またはメッセージング・インフラストラクチャからのメッセージを使用します。
Oracle Data Integratorには、メッセージベースの統合をサポートし、Java Message Service (JMS)標準に準拠するテクノロジが組み込まれています。たとえば、Oracle Data Integrator内の変換ジョブは、メッセージ・キューまたはトピックのメッセージをサブスクライブし、使用できます。メッセージはリアルタイムで取得および変換され、ターゲット・システムに書き込まれます。
この統合タイプの他のユースケースでは、データベース・レベルで変更を取得する必要がある場合があります。Oracle Data Integratorのチェンジ・データ・キャプチャ(CDC)機能によって、ソースに対して挿入、更新または削除されたデータが識別および取得され、統合プロセスでデータを使用できるようになります。
ODIには、ソース・データストアからCDCフレームワークまで変更を追跡するために、トリガーとRDBMSログ・マイニングの2つの方法が用意されています。最初の方法は、データベース・トリガーを実装するほとんどのRDBMSにデプロイできます。この方法は、ソース・システムに対するオーバーヘッドを最小限に抑えるように最適化されています。たとえば、トリガーによって取得された変更データは複製されず、ソース・システムのパフォーマンスを低下させる入出力操作の数を最小限にします。2番目の方法には、RDBMSログ(データベース・エンジンの内部変更履歴)のマイニングが含まれます。この方法は、システムのトランザクション・パフォーマンスに多少影響を与え、サポートされるのはOracle (Log Miner機能を使用)およびIBM DB2/400です。
変更の管理に使用されるCDCフレームワークは、ナレッジ・モジュールに基づいており、汎用的でオープンであるため、変更追跡方法はカスタマイズできます。フレームワークに変更をロードするために、サード・パーティの変更プロバイダを使用できます。
頻繁に発生する変更では、同時に複数のデータ・ソースが関係します。たとえば、注文の作成、更新または削除の場合は、注文表と注文明細表の両方が関係します。新規注文明細の処理時に、明細が関連付けられる新規注文も考慮することが重要です。ODIには、一貫性セットCDCと呼ばれる変更追跡モードがあります。このモードでは、複数の変更セットを処理でき、そのデータ一貫性が保証されます。
たとえば、CDCを使用して受注をデータベース・レベルで検出できます。これらの新規注文は、適切なメッセージ・キューまたはトピックに転送される前に、ODIによって拡充および変換されます。Oracle BPELまたはOracle Business Activity Monitoringなどの他のアプリケーションは、これらのメッセージをサブスクライブでき、受信イベントによって適切なビジネス・プロセスがトリガーされます。
ODIでのCDCフレームワークの使用方法の詳細は、第7章「チェンジ・データ・キャプチャの使用」を参照してください。
Oracle Data Integratorは、サービス指向アーキテクチャ(SOA)にいくつかの方法でシームレスに統合できます。
データ・サービスは、データベース表に格納されているデータに対するアクセスを提供する専用のWebサービスです。チェンジ・データ・キャプチャ機能と組み合せると、データ・サービスは、特定のサブスクライバに対して、変更されたレコードに対するアクセスを提供することもできます。データ・サービスはOracle Data Integratorによって自動的に生成され、WebサービスとしてWebコンテナ(通常はJavaアプリケーション・サーバー)にデプロイされます。データ・サービスの設定、生成およびデプロイ方法の詳細は、第8章「データ・サービスの使用」を参照してください。
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サービスを使用する方法の詳細は、第14章「Oracle Data IntegratorでのWebサービスの使用」を参照してください。
宣言的ルールに基づいたアプローチによって、Oracle Data Integratorは、データの非一貫性を追跡するデータ品質フレームワークの構築に利用できる最も適したツールです。
Oracle Data Integratorでは、集中管理されたメタデータ・リポジトリに定義された宣言的データ整合性ルールが使用されます。これらのルールがアプリケーション・データに適用され、企業情報の整合性と一貫性が保証されます。データ整合性の利点によって、全体的なデータ品質イニシアティブが高まり、この特定のニーズに対処する既存および将来のビジネス・プロセスとの統合が容易になります。
Oracle Data Integratorでは、リバースエンジニアリング・プロセスによって、データ・レベルで定義された既存のルール(データベース制約など)が自動的に取得されます。また、ODIを使用すると、開発者は、ODI内のデータ検出およびプロファイリングから推測され、即時チェックされる、ユーザー定義の宣言的ルールを追加定義することもできます。
Oracle Data Integratorには、次の2通りの方法でデータの品質をチェックする組込みのフレームワークが用意されています。
データ・サーバーのデータをチェックして、このデータがOracle Data Integratorのデータストアで宣言されたすべてのルールに違反していないことを検証します。このデータ品質チェックは静的チェックと呼ばれ、データ・モデルおよびデータストアで実行されます。このタイプのチェックを使用すると、記憶域テクノロジによって実施されないルールに対して、データの品質をプロファイリングできます。
インタフェースによるデータの移動および変換中に、フロー・チェックでデータをチェックします。このチェックでは、ターゲット・データストアに定義されたルールに対してデータ・フローがチェックされます。このようなチェックを使用すると、正しいデータはターゲット・データストアに統合できるのに対して、不正なデータはエラー表に自動的に移動されます。
静的チェックとフロー・チェックの両方で、データストアおよびデータ・モデルに定義された制約が使用されています。また、両方でチェック・ナレッジ・モジュール(CKM)が使用されます。詳細は、11.3.7項「フロー制御および統合後制御の設定」を参照してください。
これらのチェックでは、データの整合性がチェックされ、制約が検証されます。高度なデータ品質プロジェクト(例: 名前と住所のクレンジング・プロジェクト)、および高度なデータ・プロファイリングの場合は、Oracle Date IntegratorとともにOracle Data ProfilingおよびOracle Data Quality for Data Integrator製品を使用できます。
Oracle Data QualityおよびOracle Data Profilingの統合
Oracle Data ProfilingおよびOracle Data Quality for Data Integrator(あわせてOracle Data Quality製品とも呼ばれます)は、Oracle Data Integratorのインライン・データ品質機能を拡張して、より高度なデータ・ガバナンス機能を提供します。
Oracle Data Profilingは、データ調査と品質監視用のツールです。このツールを使用すると、ビジネス・ユーザーはメトリックを介してデータの品質にアクセスでき、そのデータに基づくルールを検出または推測し、データ品質の変化を一定期間監視できます。
Oracle Data Quality for Data Integratorは、最も複雑なデータ品質ニーズにも対応する、包括的で優れたデータ品質プラットフォームです。強力なルール・ベースのエンジンと、堅牢でスケーラブルなアーキテクチャによって、データ品質および名前と住所のクレンジングが企業のデータ統合戦略の中心となります。
Oracle Data QualityおよびOracle Data Profilingの詳細は、第15章「Oracle Data Quality製品の使用」を参照してください。
統合プロジェクトは、そのライフ・サイクル中に様々な環境(開発、テスト、本番)に存在し、本番の様々な環境(複数サイトのデプロイ)で実行される場合もあります。Oracle Data Integratorを使用すると、トポロジを使用して、これらの環境、およびこれらの環境にまたがるプロジェクトのライフ・サイクルの定義と保守をより簡単に実行できるようになります。
トポロジでは、情報システムの物理アーキテクチャと論理アーキテクチャが記述されます。トポロジを使用すると、様々なサーバー、環境およびエージェントを非常に柔軟な方法で管理できます。トポロジの情報はすべてマスター・リポジトリに格納され、最適な管理のために集中管理されます。作業リポジトリ内で操作されるすべてのオブジェクトがトポロジを参照します。このため、トポロジは、アーキテクチャの定義および計画時の最も重要な開始点です。
トポロジは、データ・サーバー、物理スキーマと論理スキーマ、およびコンテキストで構成されます。
データ・サーバーでは、実際の物理的なアプリケーション・サーバーとデータベースに対する接続が記述されます。たとえば、次のものを表すことができます。
Oracleインスタンス
IBM DB2データベース
Microsoft SQL Serverインスタンス
Sybase ASEサーバー
ファイル・システム
XMLファイル
Microsoft Excelワークブック
その他
実行時に、サーバーに接続するために記述した接続情報がOracle Data Integratorによって使用されます。
物理スキーマは、データ・サーバー内のデータストア(表、ファイル、トピック、キュー)の物理的な場所を示します。アクセスする必要があるすべての物理スキーマが、対応するデータ・サーバーに登録されている必要があります。物理スキーマは、オブジェクト名に接頭辞を付加し、その修飾名でオブジェクトにアクセスするために使用されます。物理スキーマの作成時に、実行時に必要な一時オブジェクトまたは永続オブジェクトを格納する一時スキーマまたは作業スキーマを指定する必要があります。
論理スキーマは、同一のデータストア構造が保持されているすべての物理スキーマに一意の名前を与えることを可能にする別名です。論理スキーマの目的は、異なる設計時環境とランタイム環境でプロシージャおよびモデルの移植性を確保することです。
コンテキストは、これらの環境の1つを表し、同じ環境に属する物理リソースをグループ化するために使用されます。
一般的なプロジェクトには、開発、テストおよび本番用に別々の環境を設定します。プロジェクトによっては、複数の重複したテスト環境または本番環境が存在する場合もあります。たとえば、独自の本番システムを実行している子会社に対して複数の本番コンテキスト(本番ニューヨーク、本番ボストンなど)を設定する場合があります。図1-5に示すように、情報システムの論理ビューとその物理実装の間には明らかに違いがあります。
論理ビューでは、既存アプリケーションの物理実装とは関係なく、その物理スキーマを表す論理スキーマが記述されます。これらの論理スキーマは、コンテキストを介して物理リソースにリンクされます。
設計者は常に、トポロジで定義された論理ビューを参照します。したがって、完成したすべての開発は、処理するリソースの物理的な場所とは無関係になります。実行時に、適切なコンテキストを指定すると、論理情報が物理リソースにマップされます。様々なコンテキストを指定するのみで、同じシナリオを様々な物理サーバーおよびアプリケーションで実行できます。この結果、使用するサーバーの基礎となる物理実装を開発者が気にする必要のない、非常に柔軟なアーキテクチャが実現します。
Oracle Data Integratorのアーキテクチャは、図1-6に示すように、連携して動作する様々なコンポーネントに依存しています。
アーキテクチャの核となるコンポーネントは、Oracle Data Integratorリポジトリです。このリポジトリには、ITインフラストラクチャに関する構成情報、すべてのアプリケーションのメタデータ、プロジェクト、シナリオおよび実行ログが格納されています。多数のリポジトリ・インスタンスがITインフラストラクチャに共存できます。リポジトリのアーキテクチャは、メタデータやシナリオを交換する複数の別々の環境(例: 開発、テスト、保守および本番の各環境)を許容するように設計されています。前述の図では、開発環境用と本番環境用の2つのリポジトリが示されています。リポジトリは、バージョン管理システムとしても機能し、この場合、オブジェクトはアーカイブされ、バージョン番号が割り当てられます。Oracle Data Integratorリポジトリは、OLTPリレーショナル・データベースにインストールできます。
Oracle Data Integratorリポジトリは、1つのマスター・リポジトリと複数の作業リポジトリで構成されます。ユーザー・インタフェースを使用して開発または構成されたオブジェクトは、これらのリポジトリ・タイプの1つに格納されます。
通常、次の情報を格納するマスター・リポジトリが1つ存在します。
ODIプラットフォームのユーザー、プロファイルおよび権限などのセキュリティ情報
テクノロジ、サーバー定義、スキーマ、コンテキスト、言語などのトポロジ情報
バージョニングしたオブジェクトおよびアーカイブしたオブジェクト
作業リポジトリは、開発した実際のオブジェクトが格納されるリポジトリです。同じODIインストールに複数の作業リポジトリが共存可能です(たとえば、別々の環境を使用するため、または特定のバージョニング・ライフ・サイクルと一致させるため)。作業リポジトリには、次の情報が格納されます。
モデル: スキーマ定義、データストア構造とメタデータ、フィールドと列の定義、データ品質制約、相互参照、データ系統などが含まれます。
プロジェクト: ビジネス・ルール、パッケージ、プロシージャ、フォルダ、ナレッジ・モジュール、変数などが含まれます。
シナリオ実行: シナリオ、スケジューリング情報およびログが含まれます。
作業リポジトリは、その中に実行情報(通常は本番のための情報)のみが含まれる場合は、実行リポジトリと呼ばれます。
ODIリポジトリの管理方法の詳細は、第3章「Oracle Data Integratorリポジトリの管理」を参照してください。
管理者、開発者およびオペレータは、Oracle Data Integrator Studioを使用してリポジトリにアクセスします。このFusionクライアント・プラットフォーム(FCP)ベースのUIは、インフラストラクチャ(セキュリティおよびトポロジ)の管理、メタデータのリバースエンジニアリング、プロジェクトの開発、実行のスケジューリング、操作および監視に使用されます。
ビジネス・ユーザー(および開発者、管理者、オペレータ)にはリポジトリに対する読取りアクセス権限があり、Oracle Data Integratorコンソールと呼ばれるWebベースのUIを使用して、トポロジ構成および本番操作を実行できます。このWebアプリケーションは、Oracle WebLogicなどのJava EEアプリケーションにデプロイできます。
ODI Studioには、ODI統合プロジェクトの様々な側面やステップを管理するための4つのナビゲータが用意されています。
トポロジ・ナビゲータ
トポロジ・ナビゲータは、情報システムの物理アーキテクチャと論理アーキテクチャを記述するデータを管理するために使用されます。トポロジ・ナビゲータを使用すると、情報システムのトポロジ、テクノロジとそのデータ型、これらのテクノロジにリンクされているデータ・サーバーとその中に含まれているスキーマ、コンテキスト、言語とエージェント、リポジトリを管理できます。サイト、マシンおよびデータ・サーバーの説明によって、Oracle Data Integratorでは様々な環境で同じインタフェースの実行が可能になります。
デザイナ・ナビゲータ
デザイナ・ナビゲータは、データ整合性チェックの設計および変換の作成に使用されます。例:
既存のアプリケーションまたはデータベースの自動リバースエンジニアリング
変換および統合インタフェースのグラフィカルな開発および保守
インタフェース内のデータ・フローの視覚化
ドキュメントの自動生成
生成されたコードのカスタマイズ
デザイナ・ナビゲータで処理する主要なオブジェクトは、モデルとプロジェクトです。
オペレータ・ナビゲータ
オペレータ・ナビゲータは、本番の管理および監視ツールであり、IT本番オペレータ用に設計されています。オペレータ・ナビゲータを使用すると、セッションのインタフェース実行、および本番のシナリオを管理できます。
セキュリティ・ナビゲータ
セキュリティ・ナビゲータは、Oracle Data Integrator内のセキュリティ情報を管理するためのツールです。セキュリティ・ナビゲータを使用すると、ユーザーとプロファイルを作成し、汎用オブジェクト(データ・サーバー、データ型など)に対するメソッド(編集、削除など)に関するユーザー権限を割り当て、オブジェクト・インスタンス(サーバー1、サーバー2など)に対してこれらの権限を微調整できます。
一般的なプロジェクトは、複数のステップとマイルストンで構成されます。
次にいくつか例を示します。
ビジネス・ニーズの定義
トポロジ内のソースとターゲットの識別および宣言
データ・モデルの形式によるソースとターゲットのデータ構造の設計およびリバースエンジニアリング
これらのデータ・モデルに対するデータ品質ルールの実装、およびこれらのデータ・モデルに対する静的チェックの実行によるデータ品質ルールの検証
これらのデータ・モデルのデータストアをソースおよびターゲットとして使用した統合インタフェースの開発
電子メールの送受信、ファイルの処理(コピー、圧縮、名前変更など)、Webサービスの実行など、インタフェースを使用して実施できないタスクに対する追加コンポーネントの開発
パッケージ・ワークフローを構築するためのインタフェースと追加コンポーネントの統合
作業のバージョン化、およびシナリオの形式でのリリース
シナリオのスケジュールおよび操作
Oracle Data Integratorでは、これらのほとんどのステップ(ソース・データの検証からメタデータ系統、およびロードやデータ品質監査まで)を実行できます。Oracle Data Integratorでは、そのリポジトリによって、仕様および開発作業が集中管理され、プロジェクトの成功の基礎となる独自のアーキテクチャが提供されます。
第2章「Oracle Data Integratorクイックスタート」では、Oracle Data Integratorを使用して統合プロジェクトを作成するための基本的な手順を説明します。第9章「統合プロジェクトの作成」では、ODIで統合プロジェクトを作成するためのいくつかの手順について、より詳細な情報を提供します。
設計時に、開発者は、設計したビジネス・ルールからシナリオを生成します。これらのシナリオのコードは、ランタイム・エージェントによってリポジトリから取得されます。コードの取得後、このエージェントは、データ・サーバーに接続して、これらのサーバー上でコード実行を調整します。また、実行に関するリターン・コードやメッセージ、およびリポジトリ内のその他のログ情報(処理数、実行時間など)を取得します。
特徴の異なる次の2つのエージェントがあります。
Java EEエージェントは、Webアプリケーションとしてデプロイでき、アプリケーション・サーバーの機能を利用できます。
スタンドアロン・エージェントは、単純なJavaマシンで実行され、統合フローの実行に必要な場合にデプロイできます。
これらのエージェントはマルチスレッドJavaプログラムであり、ロード・バランシングをサポートし、情報システム全体に配布できます。このエージェントには、独自の実行スケジュールが保持されています。実行スケジュールはOracle Data Integratorで定義でき、外部スケジューラから呼び出すこともできます。また、Java APIまたはWebサービス・インタフェースから呼び出すこともできます。エージェントの作成および管理方法の詳細は、第4章「トポロジの設定」を参照してください。
