| Oracle® Fusion Middleware Oracle Data Integratorの理解 12c (12.1.3) E59404-01 |
|
 前 |
 次 |
この章では、Oracle Data Integratorの主要概念の概要を示します。
内容は次のとおりです。
従来のETLシステムを使用して統合プロセスを設計する場合、開発者はプロセスの各ステップを設計する必要があります。たとえば、一定期間の売上高を顧客の様々な年齢別グループで集計する一般的な例について考えます。売上データは売上管理データベースから取得され、年齢別グループは年齢分布ファイルに記載されています。これらのソースを組み合せて、顧客統計システムに対して適切なレコードを挿入および更新するには、次のような各ステップを設計する必要があります。
エンジンにある顧客売上データをロードします。
エンジンにある年齢分布ファイルをロードします。
顧客売上データと年齢分布データ間のルックアップを実行します。
年齢分布別にグループ化した顧客売上高を集計します。
ターゲット売上統計データをエンジンにロードします。
集計した情報を統計システムのデータと比較して、挿入または更新が必要なデータを判別します。
新しいレコードをターゲットに挿入します。
既存のレコードをターゲットに更新します。
この方法では、設計する必要があるステップに応じて特別なスキルが要求されます。また、ターゲットでの挿入/更新の管理など、反復する一連のタスクでも、各タスクで開発が必要であるため、開発にはかなりの労力が必要です。最終的に、この方法ではメンテナンスにもかなりの労力が必要です。統合プロセスの変更では、プロセスによる処理内容の完全な理解および処理方法の知識が必要です。従来のETL設計メソッドでは、統合の論理的側面と技術的側面が入り交じっています。宣言的設計は、「どのように」行うか(プロセス)ではなく「何を」するか(宣言的ルール)にフォーカスした設計メソッドです。ここで示す例では、プロセスの処理内容は次のとおりです。
売上アプリケーションからの顧客年齢を、統計ファイルの年齢別グループに関連付けます。
年齢別グループで顧客売上を集計して、売上統計をロードします。
この処理の実行方法、つまり一時データ構造の作成やローダーの呼出しなど、この統合タスクを実行するための基礎となる技術的な側面や戦略は、宣言的ルールから明確に切り離されます。
Oracle Data Integratorの宣言的設計では、既知のリレーショナル・パラダイムを使用して、ソース、ターゲットおよび変換の指示を含んだ、データ統合タスクに対する宣言的ルールがマッピングの形式で宣言されます。
宣言的ルールは、データを変換するためにメタデータに適用されることが多く、通常は、ビジネス・ユーザーが自然言語で記述します。通常のデータ統合プロジェクト(データ・ウェアハウス・プロジェクトなど)では、これらのルールは、ビジネス・アナリストがプロジェクト・マネージャと協力して作成したドキュメントに、仕様の段階で定義されます。参照するメタデータが既知であり、メタデータ・リポジトリで修飾されている場合、ルールはSQL式を使用して実装されることがよくあります。
マッピングを使用した宣言的ルールが導入され、これにより、結合、フィルタ、集計、設定、分割などのコンポーネントのフローを介してソースがターゲットに接続されます。
表2-1は、宣言的ルールの例を示しています。
表2-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 PRODUCT.CATEGORY = 'HARDWARE' |
|
注文および注文明細がある顧客 |
結合 |
CUSTOMER.CUSTOMER_ID = ORDER.CUSTOMER_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の使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「データ・モデルおよびデータストアの作成および使用」を参照してください。
特定のシステムにおけるチェンジ・データ・キャプチャ(CDC)の処理(JKM)。ジャーナル化ナレッジ・モジュールの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「ジャーナル化の使用」を参照してください。
システムに最適な方法を使用した、あるシステムから別のシステムへのデータのロード(LKM)。これらのKMはマッピングで使用されます。ロード・ナレッジ・モジュールの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「マッピングの作成および使用」を参照してください。
特定の戦略(挿入/更新、緩やかに変化するディメンション)を使用した、ターゲット・システムでのデータの統合(IKM)。これらのKMはマッピングで使用されます。統合ナレッジ・モジュールの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「マッピングの作成および使用」を参照してください。
データ・フローでのデータ整合性の制御(CKM)。このKMは、データ・モデルの静的チェックおよびマッピングのフロー・チェックで使用します。チェック・ナレッジ・モジュールの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「データ・モデルおよびデータストアの作成および使用」と「マッピングの作成および使用」を参照してください。
Webサービスの形式でのデータの公開(SKM)。サービス・ナレッジ・モジュールの使用方法の詳細は、『Oracle Data Integratorの管理』の「データ・サービスの作成および使用」を参照してください。
ナレッジ・モジュールは、特定の統合タスクのためのコード・テンプレートです。このコードは、処理する必要がある宣言的ルールから独立しています。設計時に、開発者は統合プロセスを記述する宣言的ルールを作成します。これらの宣言的ルールはナレッジ・モジュールとマージされ、実行時に使用できるコードが生成されます。実行時に、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ナレッジ・モジュール開発者ガイド』を参照してください。
マッピングにより、結合、フィルタ、集計、設定、分割などのコンポーネントのフローを介してソースがターゲットに接続されます。
また、マッピングは、統合プロセスの生成に使用されるナレッジ・モジュール(コード・テンプレート)も参照してください。
データストアは、マッピングでソースまたはターゲットとして使用できるデータ構造です。次に例を示します。
リレーショナル・データベースに格納された表
Hadoopクラスタ内のHive表
ASCIIまたはEBCDICファイル(デリミタ付きまたは固定長)
XMLファイルのノード
メッセージ指向ミドルウェアのJMSトピックまたはキュー
エンタープライズ・ディレクトリのノード
レコード配列の形式でデータを戻すAPI
基礎となるテクノロジに関係なく、Oracle Data Integratorでは、すべてのデータ・ソースが、同じ方法で操作および統合が可能なデータストアの形式で表示されます。データストアはデータ・モデルにグループ化されます。これらのモデルには、データストアに関連付けられる制約などのすべての宣言的ルール(メタデータ)が含まれます。
マッピングを構成する宣言的ルールは、たとえば、次の例に示すように、通常の言語で表すことができます。データは2つのMicrosoft SQL Server表(LINESとそれに結合されたORDERS)から取得され、CORRECTIONSファイルのデータと結合されます。ターゲットのSALES Oracle表は、ID列が一意であることやSALES_REP表に対する有効な参照があることなど、いくつかの制約を照合する必要があります。
データは、図2-1に示すように、通常の言語で表されるいくつかのマッピングに従って変換および集計する必要があります。
これらのビジネス・ルールの自然言語からSQL式への変換は、通常は簡単な作業です。この例では、図2-1に示したルールは、表2-2に示すように変換できます。
表2-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はデータ・モデルで |
|
制約 |
IDは一意であることが必要です |
一意のキーが列セットとしての(ID)でデータ・モデルに追加されています |
|
制約 |
営業担当者IDがターゲットのSalesRep表に存在している必要があります |
参照(外部キー)が |
Oracle Data Integratorを使用してこのビジネス課題を実装することは、非常に簡単でわかりやすい課題です。ビジネス・ルールをマッピングに変換するのみで実装できます。
マッピングで定義されたビジネス・ルールはデータ・フローに自動的に変換され、データ・フローでは、ソース・データからターゲット表への結合、フィルタ、マッピングおよび制約が実行されます。
デフォルトでは、Oracle Data Integratorでは、ターゲットRDBMSがステージング領域として使用されます。この領域は、ソース・データを一時表にロードし、必要なすべてのマッピング、ステージング・フィルタ、結合および制約を適用するための領域です。ステージング領域は、RDBMS(ユーザー/データベース)内の別個の領域です。この領域に、Oracle Data Integratorによってその一時オブジェクトが作成され、一部のルール(マッピング、結合、最終フィルタ、集計など)が実行されます。このように操作を実行する場合、Oracle Data IntegratorではE-LT戦略が使用され、最初に一時表が抽出されてロードされた後、最後にターゲットRDBMSで変換が実行されます。
一部の特定のケースでは、ソースのデータ量が少ない(500,000レコード未満)場合、このステージング領域をメモリー内のOracle Data Integratorのメモリー内リレーショナル・データベース(メモリー内エンジン)に配置できます。この場合、Oracle Data Integratorは従来のETLツールのように動作します。
図2-2に、最終的なSALES表をロードするためにOracle Data Integratorによって自動的に生成されるデータ・フローを示します。ビジネス・ルールは、ナレッジ・モジュール(KM)によってコードに変換されます。作成されたコードによって、複数のステップが生成されます。これらのステップの一部で、データがソースから抽出されてステージング領域にロードされます(ロード・ナレッジ・モジュール - LKM)。他のステップでは、データが変換されて、ステージング領域からターゲット表に統合されます(統合ナレッジ・モジュール - IKM)。データ品質を保証するために、チェック・ナレッジ・モジュール(CKM)によって、ユーザー定義制約がステージング・データに適用され、エラーのあるレコードはエラー表に分離されます。
Oracle Data Integratorのナレッジ・モジュールには、インフラストラクチャの様々なサーバーによって実行される実際のコードが含まれています。ナレッジ・モジュールに含まれているコードの一部は汎用的です。実行時に、ビジネス・ルールに結合されるOracle Data Integratorの置換APIをコールして、実行される最終的なコードを生成します。
デザインタイムでは、宣言的ルールはマッピングで定義され、ナレッジ・モジュールは選択および構成されるのみです。
実行時に、コードが生成され、ナレッジ・モジュールのOracle Data Integratorの各APIコール(<%と%>に囲まれた部分)は、リポジトリに提供されているメタデータに関しては、対応するオブジェクト名または式で置換されます。生成されたコードは、ソースおよびターゲット・システム上のOracle Data Integratorのランタイム・コンポーネント(エージェント)によって調整されて、E-LTアプローチの定義に従って、処理が実行されるようにします。
マッピングの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「マッピングの作成および使用」を参照してください。
