Oracle® Fusion Middleware

Oracle Data Integratorの理解

12c (12.1.3)

E59404-01(原本部品番号:E51085-01)

2014年5月

Oracle Fusion Middleware Understanding Oracle Data Integratorの理解, 12c (12.1.3)

E59404-01

Copyright © 2010, 2014, Oracle and/or its affiliates. All rights reserved.

原本著者: Laura Hofman Miquel、Joshua Stanley、Aslam Khan

原本協力著者: Alex Kotopoulis、Michael Reiche、Jon Patt、Alex Prazma、Gail Risdal

原本協力者: David Allan、Linda Bittarelli、Sophia Chen、Pratima Chennupati、Victor Chow、Sowmya Dhandapani、Daniel Gallagher、Gary Hostetler、Kevin Hwang、Aslam Khan、Sebu T. Koleth、Christian Kurz、Venkata Lakkaraju、Thomas Lau、Deekshit Mantampady、Kevin McDonough、Luda Mogilevich、Ale Paez、Suresh Pendap、Sandrine Riley、Julien Testut、Sachin Thatte、Julie Timmons、Jay Turner、Vikas Varma、Robert Velisar、Winnie Wan、Geoff Watters、Jennifer Waywell

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアはさまざまな情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、Oracle社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

目次

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

1 Oracle Data Integratorの概要

- Oracle Data Integratorを使用したデータ統合の概要

- データ統合とは

- Oracle Data Integratorについて

- E-LTとは

- Oracle Data Integratorコンポーネントのアーキテクチャの理解

- リポジトリ

- ユーザー

- ランタイム・エージェント

- Oracle Data Integratorコンソール

- ODIドメイン

2 Oracle Data Integratorの概念の理解

- 宣言的設計の概要

- ナレッジ・モジュールの概要

- マッピングの概要

- データストア

- 宣言的ルール

- データ・フロー

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

- 設計時プロジェクト

- バッチ指向の統合

- イベント指向の統合

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

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

4 環境の管理

- 環境の管理

図一覧

- 1-1 従来のETLとODI E-LTの比較

- 1-2 Oracle Data Integratorコンポーネントのアーキテクチャ

- 2-1 ビジネスの問題の例

- 2-2 動作中のOracle Data Integratorナレッジ・モジュール

- 4-1 インフラストラクチャの論理ビューと物理ビュー

表一覧

- 2-1 宣言的ルールの例

- 2-2 変換されたビジネス・ルール

はじめに

このマニュアルでは、Oracle Data Integratorを使用したデータ統合プロジェクトの開発方法について説明します。

ここでは、次のトピックについて説明します。

- 対象読者

- ドキュメントのアクセシビリティについて

- 関連ドキュメント

- 表記規則

対象読者

このガイドは、Oracle Data Integratorの主要な概念とアーキテクチャの概要に関心があるすべての方を対象としています。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWebサイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

関連ドキュメント

詳細は、Oracle Data Integratorライブラリの次のドキュメントを参照してください。

- Oracle Data Integratorリリース・ノート

- Oracle Data Integratorの管理

- Oracle Data Integratorでの統合プロジェクトの開発

- Oracle Data Integratorのインストールと構成

- Oracle Data Integratorのアップグレード

- Oracle Data Integratorアプリケーション・アダプタ・ガイド

- Oracle Data Integratorでのナレッジ・モジュールの開発

- Oracle Data Integrator接続およびナレッジ・モジュール・ガイド

- Oracle Warehouse BuilderからOracle Data Integratorへの移行

- Oracle Data Integratorツール・リファレンス

- Oracle Data Integratorデータ・サービスJava APIリファレンス

- Oracle Data Integratorオープン・ツールJava APIリファレンス

- Oracle Data IntegratorのためのSAP ABAP BWアダプタ・スタート・ガイド

- Oracle Data Integrator Java APIリファレンス

- Oracle Data IntegratorのためのSAP ABAP ERPアダプタ・スタート・ガイド

- Oracle Data Integrator 12cオンライン・ヘルプ([F1]を押すか、「ヘルプ」を選択してから、「検索」または「目次」を選択してメイン・メニューからJDeveloperヘルプ・センターを開いて、ODI Studioで入手可能)

表記規則

このマニュアルでは次の表記規則を使用します。

規則

意味

太字

太字は、操作に関連するGraphical User Interface要素、または本文中で定義されている用語および用語集に記載されている用語を示します。

イタリック体

イタリックは、ユーザーが特定の値を指定するプレースホルダ変数を示します。

固定幅フォント

固定幅フォントは、段落内のコマンド、URL、サンプル内のコード、画面に表示されるテキスト、または入力するテキストを示します。

1 Oracle Data Integratorの概要

この章では、Oracle Data Integratorについて説明します。

この章の内容は次のとおりです。

- Oracle Data Integratorを使用したデータ統合の概要

- Oracle Data Integratorコンポーネントのアーキテクチャの理解

Oracle Data Integratorを使用したデータ統合の概要

データ統合によって、複雑なシステム全体で情報の適時性、正確性および一貫性が確保されます。この項では、データ統合の概要を説明し、Oracle Data Integratorによるデータ統合のサポート方法についても説明します。

データ統合とは

企業全体でデータとアプリケーションを統合し、統一されたビューで示すことは、難しい課題です。テクノロジ、データ構造、アプリケーション機能に明らかな差異があるのみでなく、統合アーキテクチャにも基本的な相違があります。一部の統合ニーズ、特に大量のデータを統合する場合のニーズはデータ指向です。他の統合プロジェクトでは、非同期統合または同期統合のために、プロジェクト自体がイベント駆動型アーキテクチャ(EDA)またはサービス指向アーキテクチャ(SOA)に適合するようにします。

データ統合によって、複雑なシステム全体で情報の適時性、正確性および一貫性が確保されます。今でもExtract-Transform-Load (ETL)と呼ばれることがよくありますが、データ統合は当初、エンタープライズ・データ・ウェアハウス・システムをロードするために使用されるアーキテクチャとみなされていました。現在のデータ統合には、データ移動、データ同期、データ品質、データ管理およびデータ・サービスが含まれています。

Oracle Data Integratorについて

Oracle Data Integratorには、複雑なデータ・ウェアハウスを構築、デプロイおよび管理するため、あるいはSOAまたはビジネス・インテリジェンス環境のデータ集中型アーキテクチャの一部として、完全に統一されたソリューションが用意されています。さらに、データ統合のすべての要素(データ移動、データ同期、データ品質、データ管理およびデータ・サービス)が結合され、複雑なシステム全体で情報の適時性、正確性および一貫性が確保されます。

Oracle Data Integrator (ODI)の特徴は、データ統合のあらゆるスタイル(データ中心、イベント中心、サービス中心)を組み込んだアクティブな統合プラットフォームです。ODIでは、大量のデータの効率的な変換、高度なチェンジ・データ・キャプチャ(CDC)フレームワークによるリアルタイムのイベント処理、Oracle SOA Suiteに対するデータ・サービスの提供によって、分断化状態の統合が統一されます。また、堅牢なデータ整合性制御機能によって、データの一貫性と正確性が保証されます。異種のE-LT、宣言的な設計、ナレッジ・モジュールなど、中核となる強力な差別化機能によって、Oracle Data Integratorは、統合プラットフォームのパフォーマンス、柔軟性、生産性、モジュール性およびホットプラガブル性の要件を満たします。

E-LTとは

従来のETLツールの動作では、最初に各種ソースからデータが抽出され、ステージング領域として使用される独自の中間層ETLエンジンでデータが変換された後、変換したデータがターゲット・データ・ウェアハウス、統合サーバーまたはHadoopクラスタにロードされます。このようにETLという用語は、図1-1に示すように、実行される動作の名前と順序の両方を表しています。

図1-1 従来のETLとODI E-LTの比較

ETLプロセスのデータ変換ステップはコンピュータ資源を大量消費する処理であり、専用サーバー上の独自のETLエンジンによってすべて実行されます。ETLエンジンでは、行単位でデータ変換が実行(場合によってデータ品質チェックも実行)されるため、プロセス全体のボトルネックになることがよくあります。また、データはネットワーク上を2回(1回はソースとETLサーバー間、もう1回はETLサーバーとターゲット・データ・ウェアハウスまたはHadoopクラスタ間)移動する必要があります。さらに、データ・フロー参照をターゲット・データ・ウェアハウスの値と比較することによって参照整合性を保証する場合、参照されるデータをターゲットからエンジンにダウンロードする必要があるため、ネットワーク・トラフィックとダウンロード時間がさらに増加し、パフォーマンスの問題が深刻化します。

ETLアーキテクチャによって提起された問題に対応して、新しいアーキテクチャが出現しています。このアーキテクチャでは、手作業によるコーディングと自動コード生成アプローチの最良の特徴が様々な方法で統合されています。E-LTと呼ばれるこの新しいアプローチでは、データ変換が行われる場所と方法が変更され、既存の開発者のスキル、RDBMSエンジン、Big Dataエンジンおよびサーバー・ハードウェアが最大限に活用されます。実際には、E-LTでは操作の順序が変更されて、データ変換ステップがターゲットRDBMSに移動されています。つまり、ソース表からのデータの抽出、宛先サーバーへの表のロード、およびネイティブSQL演算子を使用したターゲットRDBMSでのデータの変換という順序になります。E-LTを使用した場合は、図1-1に示した中間層エンジン(サーバー)が必要ないことに注意してください。

Oracle Data Integratorでは、ETLスタイルとE-LTスタイルの両方のデータ統合がサポートされています。詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』のE-LTおよびETLスタイル・マッピングの設計に関する項を参照してください。

Oracle Data Integratorコンポーネントのアーキテクチャの理解

Oracle Data Integratorプラットフォームは、広義のFusion Middlewareプラットフォームに統合され、このスタックの主要なコンポーネントになります。Oracle Data Integratorにはランタイム・コンポーネントがJava EEアプリケーションとして含まれ、Oracle WebLogicアプリケーション・サーバーの機能が十分に活用されるよう強化されています。Oracle Data Integratorコンポーネントには、エンタープライズ規模のデプロイメント、高可用性、スケーラビリティおよび強固なセキュリティのための独自の機能が含まれています。図1-2に、ODIコンポーネントのアーキテクチャを示します。

図1-2 Oracle Data Integratorコンポーネントのアーキテクチャ

リポジトリ

アーキテクチャの核となるコンポーネントは、Oracle Data Integratorリポジトリです。このリポジトリには、ITインフラストラクチャに関する構成情報、すべてのアプリケーションのメタデータ、プロジェクト、シナリオおよび実行ログが格納されています。多数のリポジトリ・インスタンスがITインフラストラクチャに共存できます。リポジトリのアーキテクチャは、メタデータやシナリオを交換する複数の別々の環境(例: 開発、テスト、保守および本番の各環境)を許容するように設計されています。前述の図では、開発環境用と本番環境用の2つのリポジトリが示されています。リポジトリは、バージョン管理システムとしても機能し、この場合、オブジェクトはアーカイブされ、バージョン番号が割り当てられます。Oracle Data Integratorリポジトリは、OLTPリレーショナル・データベースにインストールできます。

Oracle Data Integratorリポジトリは、1つのマスター・リポジトリと複数の作業リポジトリで構成されます。ユーザーを介して開発または構成されたオブジェクトは、これらのリポジトリ・タイプの1つに格納されます。

通常、次の情報を格納するマスター・リポジトリが1つ存在します。

- ODIプラットフォームのユーザー、プロファイルおよび権限などのセキュリティ情報。

- テクノロジ、サーバー定義、スキーマ、コンテキスト、言語などのトポロジ情報。

- バージョニングしたオブジェクトおよびアーカイブしたオブジェクト

作業リポジトリは、開発した実際のオブジェクトが格納されるリポジトリです。同じODIインストールに複数の作業リポジトリが共存可能です(たとえば、別々の環境を使用するため、または特定のバージョニング・ライフ・サイクルと一致させるため)。作業リポジトリには、次の情報が格納されます。

- モデル: スキーマ定義、データストア構造とメタデータ、フィールドと属性の定義、データ品質制約、相互参照、データ系統などが含まれます。

- プロジェクト: ビジネス・ルール、パッケージ、プロシージャ、フォルダ、ナレッジ・モジュール、変数などが含まれます。

- シナリオ実行: シナリオ、スケジューリング情報およびログが含まれます。

作業リポジトリは、その中に実行情報(通常は本番のための情報)のみが含まれる場合は、実行リポジトリと呼ばれます。

ODIリポジトリの管理方法の詳細は、『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など)に対してこれらの権限を微調整できます。

ランタイム・エージェント

設計時に、開発者は、設計したビジネス・ルールからシナリオを生成します。これらのシナリオのコードは、ランタイム・エージェントによってリポジトリから取得されます。コードの取得後、このエージェントは、データ・サーバーに接続して、これらのサーバー上でコード実行を調整します。また、実行に関するリターン・コードやメッセージおよびリポジトリ内のその他のログ情報(処理レコード数、実行時間など)を取得します。

特徴の異なる次の3つのエージェントがあります。

- スタンドアロン・エージェント
スタンドアロン・エージェントは、独立したJava仮想マシン(JVM)プロセスで動作します。スタンドアロン・エージェントは、JDBCによって、作業リポジトリとソースおよびターゲット・データ・サーバーに接続します。スタンドアロン・エージェントはJava仮想マシンがインストールされているサーバーにインストールできます。いずれかのデータ・サーバーに対してローカルであるリソース(ファイル・システムまたはデータベース・インスタンスがインストールされたローダー・ユーティリティなど)を使用する必要があり、このマシンにはJava EEアプリケーション・サーバーをインストールしない場合、このタイプのエージェントはより適切です。

- スタンドアロン・コロケート・エージェント
スタンドアロン・コロケート・エージェントは、独立したJava Virtual Machine (JVM)プロセスで動作しますが、WebLogic Serverドメインの一部であり、WebLogic管理サーバーによって制御されます。スタンドアロン・コロケート・エージェントは、Java仮想マシンがインストールされている任意のサーバーにインストールできますが、WebLogic管理サーバーへの接続が必要です。データ・サーバーの1つにローカルなリソースを使用する必要があるが、すべてのアプリケーションの管理をエンタープライズ・アプリケーション・サーバーで一元化する場合は、このタイプのエージェントが適しています。

- Java EEエージェント
Java EEエージェントは、Java EEアプリケーション・サーバー(Oracle WebLogic Serverなど)にWebアプリケーションとしてデプロイされます。Java EEエージェントは、アプリケーション・サーバーのあらゆる機能の恩恵を受けることができます(JDBCデータソースまたはOracle WebLogic Serverのクラスタ化など)。エンタープライズ・アプリケーション・サーバーにおけるすべてのアプリケーションのデプロイおよび管理を集中させる必要がある場合や、高可用性の要件がある場合、このタイプのエージェントはより適切です。

これらのエージェントはマルチスレッドJavaプログラムであり、ロード・バランシングをサポートし、情報システム全体に配布できます。このエージェントには、独自の実行スケジュールが保持されています。実行スケジュールはOracle Data Integratorで定義でき、外部スケジューラから呼び出すこともできます。また、Java APIまたはWebサービスから呼び出すこともできます。エージェントの作成および管理方法の詳細は、『Oracle Data Integratorの管理』の「トポロジの設定」を参照してください。

Oracle Data Integratorコンソール

ビジネス・ユーザー(および開発者、管理者、オペレータ)にはリポジトリに対する読取りアクセス権限があり、Oracle Data Integratorコンソールと呼ばれるWebベースのUIを使用して、トポロジ構成および本番操作を実行できます。このWebアプリケーションは、Oracle WebLogicなどのJava EEアプリケーション・サーバーにデプロイできます。

Java EEエージェント、スタンドアロン・エージェントおよびODIコンソールの管理とモニターを行うために、Oracle Data Integratorには、Oracle Fusion Middleware Controlコンソールだけでなく、Oracle Enterprise Manager Cloud Controlと統合するためのプラグインも用意されています。

ODIドメイン

ODIドメインには、Oracle Enterprise Manager Cloud Control (EMCC)を使用して管理できるOracle Data Integratorコンポーネントが含まれます。ODIドメインに含まれるコンポーネントは次のとおりです。

- いくつかのOracle Data Integratorコンソール・アプリケーション。Oracle Data Integratorコンソール・アプリケーションは、マスター・リポジトリおよび作業リポジトリをブラウズするために使用されます。

- マスター・リポジトリにアタッチされたいくつかのランタイム・エージェント。これらのエージェントをドメインに含めるには、マスター・リポジトリで宣言する必要があります。これらのエージェントは、スタンドアロン・エージェントまたはJava EEエージェントです。マスター・リポジトリでエージェントを宣言する方法の詳細は、『Oracle Data Integratorの管理』の「トポロジの設定」を参照してください。

EMCCでは、マスター・リポジトリ・ページおよびエージェント・ページには、マスター・リポジトリと作業リポジトリ両方のアプリケーション・メトリックと情報が表示されます。たとえば、セッションの詳細を表示するために、これらのページからOracle Data Integratorコンソールにナビゲートすることもできます。EMCCでOracle Data Integratorコンソールをブラウズするには、作業リポジトリとマスター・リポジトリへの接続をOracle Data Integratorコンソールで宣言する必要があります。詳細は、『Oracle Data Integratorのインストールと構成』を参照してください。

2 Oracle Data Integratorの概念の理解

この章では、Oracle Data Integratorの主要概念の概要を示します。

内容は次のとおりです。

- 宣言的設計の概要

- ナレッジ・モジュールの概要

- マッピングの概要

宣言的設計の概要

従来のETLシステムを使用して統合プロセスを設計する場合、開発者はプロセスの各ステップを設計する必要があります。たとえば、一定期間の売上高を顧客の様々な年齢別グループで集計する一般的な例について考えます。売上データは売上管理データベースから取得され、年齢別グループは年齢分布ファイルに記載されています。これらのソースを組み合せて、顧客統計システムに対して適切なレコードを挿入および更新するには、次のような各ステップを設計する必要があります。

1. エンジンにある顧客売上データをロードします。

2. エンジンにある年齢分布ファイルをロードします。

3. 顧客売上データと年齢分布データ間のルックアップを実行します。

4. 年齢分布別にグループ化した顧客売上高を集計します。

5. ターゲット売上統計データをエンジンにロードします。

6. 集計した情報を統計システムのデータと比較して、挿入または更新が必要なデータを判別します。

7. 新しいレコードをターゲットに挿入します。

8. 既存のレコードをターゲットに更新します。

この方法では、設計する必要があるステップに応じて特別なスキルが要求されます。また、ターゲットでの挿入/更新の管理など、反復する一連のタスクでも、各タスクで開発が必要であるため、開発にはかなりの労力が必要です。最終的に、この方法ではメンテナンスにもかなりの労力が必要です。統合プロセスの変更では、プロセスによる処理内容の完全な理解および処理方法の知識が必要です。従来の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に示すように、通常の言語で表されるいくつかのマッピングに従って変換および集計する必要があります。

図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はデータ・モデルでnot nullに設定されています

制約

IDは一意であることが必要です

一意のキーが列セットとしての(ID)でデータ・モデルに追加されています

制約

営業担当者IDがターゲットのSalesRep表に存在している必要があります

参照(外部キー)がSALES.SALES_REP = SALES_REP.SALES_REP_IDでデータ・モデルに追加されています

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)によって、ユーザー定義制約がステージング・データに適用され、エラーのあるレコードはエラー表に分離されます。

図2-2 動作中のOracle Data Integratorナレッジ・モジュール

Oracle Data Integratorのナレッジ・モジュールには、インフラストラクチャの様々なサーバーによって実行される実際のコードが含まれています。ナレッジ・モジュールに含まれているコードの一部は汎用的です。実行時に、ビジネス・ルールに結合されるOracle Data Integratorの置換APIをコールして、実行される最終的なコードを生成します。

デザインタイムでは、宣言的ルールはマッピングで定義され、ナレッジ・モジュールは選択および構成されるのみです。

実行時に、コードが生成され、ナレッジ・モジュールのOracle Data Integratorの各APIコール(<%と%>に囲まれた部分)は、リポジトリに提供されているメタデータに関しては、対応するオブジェクト名または式で置換されます。生成されたコードは、ソースおよびターゲット・システム上のOracle Data Integratorのランタイム・コンポーネント(エージェント)によって調整されて、E-LTアプローチの定義に従って、処理が実行されるようにします。

マッピングの使用方法の詳細は、『Oracle Data Integratorでの統合プロジェクトの開発』の「マッピングの作成および使用」を参照してください。

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

Oracle Data Integratorの統合機能は広範囲にわたります。この章では、最も一般的なODI統合プロジェクトについて説明します。

内容は次のとおりです。

- 設計時プロジェクト

- バッチ指向の統合

- イベント指向の統合

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

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

設計時プロジェクト

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

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

- ビジネス・ニーズの定義

- トポロジ内のソースとターゲットの識別および宣言

- データ・モデルの形式によるソースとターゲットのデータ構造の設計およびリバースエンジニアリング

- これらのデータ・モデルに対するデータ品質ルールの実装、およびこれらのデータ・モデルに対する静的チェックの実行によるデータ品質ルールの検証

- これらのデータ・モデルのデータストアをソースおよびターゲットとして使用したマッピングの開発

- 電子メールの送受信、ファイルの処理(コピー、圧縮、名前変更など)、Webサービスの実行など、マッピングを使用して実施できないタスクに対する追加コンポーネントの開発

- パッケージ・ワークフローを構築するためのマッピングと追加コンポーネントの統合

- 作業のバージョン化、およびシナリオの形式でのリリース

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

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

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

バッチ指向の統合

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

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

- ビジネス・ニーズ(キー・インジケータ)の定義

- キー・インジケータに関係するソース・データの識別、ソース情報をキー・インジケータに変換するためのビジネス・ルールの指定

- キー・インジケータを格納するターゲット・ウェアハウスのデータ構造のモデル化

- ビジネス・ルールの実装によるインジケータの移入

- データ品質ルールの設定によるデータの全体的な正確度の測定

- キー・インジケータに関するレポートの開発

- 非定型問合せツールまたは事前定義レポートを使用した、ビジネス・ユーザーによるキー・インジケータおよびメタデータの利用可能化

- ビジネス・ユーザーの満足度の測定およびキー・インジケータの追加/変更

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

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

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

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

E-LT

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

イベント指向の統合

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

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での統合プロジェクトの開発』の「ジャーナル化の使用」を参照してください。

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

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サービスの使用」を参照してください。

ODIを使用したデータ品質

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

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

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

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

- データ・サーバーのデータをチェックして、このデータがOracle Data Integratorのデータストアで宣言されたすべてのルールに違反していないことを検証します。このデータ品質チェックは静的チェックと呼ばれ、データ・モデルおよびデータストアで実行されます。このタイプのチェックを使用すると、記憶域テクノロジによって実施されないルールに対して、データの品質をプロファイリングできます。

- マッピングによるデータの移動および変換中に、フロー・チェックでデータをチェックします。このチェックでは、ターゲット・データストアに定義されたルールに対してデータ・フローがチェックされます。このようなチェックを使用すると、正しいデータはターゲット・データストアに統合できるのに対して、不正なデータはエラー表に自動的に移動されます。

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

ヒント:

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

4 環境の管理

この章では、統合プロジェクト環境の管理について説明します。

内容は次のとおりです。

- 環境の管理

環境の管理

統合プロジェクトは、そのライフサイクル中に様々な環境(開発、テスト、本番)に存在し、さらに本番では様々な環境で実行される場合があります(複数サイトのデプロイ)。Oracle Data Integratorを使用すると、トポロジを使用して、これらの環境、およびこれらの環境にまたがるプロジェクトのライフサイクルの定義と保守をより簡単に実行できます。

トポロジでは、情報システムの物理アーキテクチャと論理アーキテクチャが記述されます。トポロジを使用すると、様々なサーバー、環境およびエージェントを非常に柔軟な方法で管理できます。トポロジの情報はすべてマスター・リポジトリに格納され、最適な管理のために集中管理されます。作業リポジトリ内で操作されるすべてのオブジェクトがトポロジを参照します。このため、トポロジは、アーキテクチャの定義および計画時の最も重要な開始点です。

トポロジは、データ・サーバー、物理スキーマと論理スキーマ、およびコンテキストで構成されます。

データ・サーバーでは、実際の物理的なアプリケーション・サーバーとデータベースに対する接続が記述されます。たとえば、次のものを表すことができます。

- Apache Hive

- Oracleインスタンス

- IBM DB2データベース

- Microsoft SQL Serverインスタンス

- ファイル・システム

- XMLファイル

- その他。

実行時に、サーバーに接続するために記述した接続情報がOracle Data Integratorによって使用されます。

物理スキーマは、データ・サーバー内のデータストア(表、ファイル、トピック、キュー)の物理的な場所を示します。アクセス対象とする必要がある物理スキーマは、対応するデータ・サーバーに登録されなければなりません。物理スキーマは、オブジェクト名に接頭辞として付けて、それらの修飾名でそれらにアクセスするために使用されます。物理スキーマの作成時に、実行時に必要な一時オブジェクトまたは永続オブジェクトを格納する一時スキーマまたは作業スキーマを指定する必要があります。

論理スキーマは、同一のデータストア構造が保持されているすべての物理スキーマに一意の名前を与えることを可能にする別名です。論理スキーマの目的は、異なる設計時環境とランタイム環境でプロシージャおよびモデルの移植性を確保することです。

コンテキストは、これらの環境の1つを表し、同じ環境に属する物理リソースをグループ化するために使用されます。コンテキストは、同じ環境に属する物理リソースをグループ化するために使用されます。

一般的なプロジェクトには、開発、テストおよび本番用に別々の環境を設定します。プロジェクトによっては、複数の重複したテスト環境または本番環境が存在する場合もあります。たとえば、独自の本番システムを実行している子会社に対して複数の本番コンテキスト(本番ニューヨーク、本番ボストンなど)を設定する場合があります。図4-1に示すように、情報システムの論理ビューとその物理実装の間には明らかに違いがあります。

図4-1 インフラストラクチャの論理ビューと物理ビュー

論理ビューでは、既存アプリケーションの物理実装とは関係なく、その物理スキーマを表す論理スキーマが記述されます。これらの論理スキーマは、コンテキストを介して物理リソースにリンクされます。

設計者は常に、トポロジで定義された論理ビューを参照します。したがって、完成したすべての開発は、処理するリソースの物理的な場所とは無関係になります。実行時に、適切なコンテキストを指定すると、論理情報が物理リソースにマップされます。様々なコンテキストを指定するのみで、同じシナリオを様々な物理サーバーおよびアプリケーションで実行できます。この結果、使用するサーバーの基礎となる物理実装を開発者が気にする必要のない、非常に柔軟なアーキテクチャが実現します。

オラクル社の法律上の注意点について

コピーライトについて

Copyright © 1994-2015, Oracle and/or its affiliates.All rights reserved.

商標と登録商標について

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

ライセンス制約の保証と結果的に生じる損害の免責

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

保証免責

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

制限付権利

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

危険な用途への使用について

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション（人的傷害を発生させる可能性があるアプリケーションを含む）への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性（redundancy）、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

第三者のコンテンツ、製品、サービスに対する免責事項

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

ドラフトのアルファ版およびベータ版ドキュメントについて

このドキュメントが試作版の場合:

このドキュメントは試作版であり、デモおよび暫定使用のみを目的としたものです。このソフトウェアを使用するハードウェアに限定するものではありません。オラクル社およびその関連会社は、このドキュメントに関して一切の責任を負わず、いかなる保証もいたしません。また、このドキュメントを使用したことによって損失、費用、あるいは損害が発生しても、一切の責任を負いかねます。