| Oracle® Business Intelligence Applications ETLガイド 11g リリース1 (11.1.1.8.1) E57854-01 |
|
 前 |
 次 |
この章では、Oracle BI ApplicationsのETLプロセスに関連する基本概念について、概要を説明します。
この章には次のトピックが含まれます:
Oracle BI ApplicationsのETLプロセスの実行を開始する前に、Oracle BI Applicationsのインストールと設定を完了しておく必要があります。詳細は、『Oracle Business Intelligence Applicationsインストレーション・ガイド』を参照してください。
また、ドメインのロード・プラン(Oracle BI Applications構成マネージャの表にソース固有のデータをロードする)を実行しておく必要もあります。これにより、設定オブジェクトのドロップダウン・リストの選択肢として、構成マネージャで適切なソース固有の値を表示できるようになります。ドメインのロード・プランを実行する方法については、『Oracle Business Intelligence Applicationsインストレーション・ガイド』を参照してください。
図1-1に、オンプレミスのETLアーキテクチャを示します。一般に、抽出、ロード、変換プロセスには、主要なステップが2つあります。最初のステップは、抽出およびステージ・ロード・ステップで、2つ目のステップは、ロード変換ステップです。抽出およびステージ・ロード・ステップは、メイン・インタフェースとネストされた一時インタフェースを組み合せたものから生成されます。ロード変換ステップは、統合ナレッジ・モジュール(IKM)の結果として生成されます。この例のステップ1では、GL_SET_OF_BOOKS表とHR_ORGANIZATION_INFORMATION表を結合するSQL文がソースで発行されます。この結合は、ソース・データベースで実行され、結果データがステージングされます。次に、ロード変換ステージでは、W_DOMAIN_G表と一時ステージ表の間で2つ目の結合が行われます。その結果、ステージ表W_INV_ORG_DSがロードされます。
Oracle Databaseは、Oracle BI Applicationsのリポジトリ・スキーマとBusiness Analytics Warehouseでサポートされる唯一のデータベース・タイプであることに注意してください。
図1-2に、一般的なロード・プランのパターンを示します。主なステージは4つあります。SDE (ソース依存抽出)タスクでは、ソース・ディメンションとファクト表からデータを抽出して、そのデータを共通ディメンション表とファクト・ステージング表にロードします。SILタスクは共通のタスクであり、共通ステージング表のデータをウェアハウス・ステージング表にロードします。図1-2には、ディメンション表とファクト表の間の依存関係が示されています。このため、SIL FACTより先にSIL DIMを実行して、ディメンション・キーを解決しておく必要があります。SIL DIMには、このキーを生成するデータベース・シーケンスがあります。SIL FACTでは、ファクト・ステージング表のロード時にそのキーが参照されます。
Oracle BI ApplicationsのETLプロセスには、次のフェーズがあります。
SDE。SDEは、ソース依存抽出(Source Dependent Extract)の略称です。最初のフェーズでは、SDEタスクがソース・システムからデータを抽出し、そのデータをステージング表にステージします。SDEタスクは、ソース固有になります。
SIL。SILは、ソース非依存ロード(Source Independent Load)の略称です。ロード・タスクは、ステージング表のデータを変換して、基本ファクト表またはディメンション表に移植します。SILタスクは、ソースに依存していません。
PLP。PLPは、ロード後プロセス(Post Load Process)の略称です。PLPタスクは、ディメンション表とファクト表の移入後にのみ実行されます。PLPタスクの一般的な使用法として、基本ファクト表のデータを変換して、そのデータを集計表にロードする場合があげられます。PLPタスクは、ソースに依存していません。
Oracle BI ApplicationsのODIリポジトリは、次の2つのリポジトリで構成されます。
マスター・リポジトリ。リソース、セキュリティ、バージョン管理のトポロジです。マスター・リポジトリは通常、複数の作業リポジトリに関連付けられていますが、作業リポジトリは、常に単一のマスター・リポジトリにアタッチされます。
作業リポジトリ。データ・モデルとプロジェクトを格納します。これは、開発および実行用のリポジトリです。
マスター・リポジトリと作業リポジトリは、同一のデータベース・スキーマ内に常駐する必要があり、データベース・タイプはOracleである必要があります。マスター・リポジトリと作業リポジトリは、どちらもOracle BI Applicationsのインストール・プロセス中に設定されます。
デフォルトのODIリポジトリIDは500です。このIDは、ODIリポジトリ内で作成される各オブジェクトに対する、内部IDの一部になります。リポジトリIDは、500以上であることが重要です。これにより、ユーザーが作成するオブジェクトが、現在または将来のOracle BI Applicationsオブジェクトと重複する事態を防げます。デフォルトのODIリポジトリIDを変更するときには、新しい値が500より大きいことを必ず確認してください。
ロード・プランとは、ETLプロセスを実行する子オブジェクト(ステップと呼ばれる)から構成および編成される、実行可能なオブジェクトのことです。ロード・プランは、各種ステップのシーケンスからなります。各ステップには、複数の子ステップを含めることもできます。ステップの種類によっては、条件付き、パラレルまたはシリアルでステップを実行できます。
ロード・プランは、Oracle BI Applications構成マネージャで、データ・ソースと1つ以上のファクト・グループを選択することによって定義します。この選択により、ETLプロセス中に実行する必要のあるステップが決まります。各ファクト・グループは、特定の機能領域または1つ以上のオファリングに関連付けられた領域に属しています。この領域は、1つのデータ・サーバーに関連付けられています。トランザクション・データ・ソースは、1つ以上のデータ・サーバーに関連付けられています。
ロード・プランを定義したら、そのロード・プランを生成して、ODIリポジトリに作成します。その後、ロード・プランを実行して、ETLプロセスを実行します。
Oracle BI Applicationsのロード・プランに対する作業の詳細は、第2章「ロード・プランの管理」を参照してください。Oracle Data Integrator関連のロード・プランのトピックについては、Oracle Fusion Middleware Oracle Data Integrator開発者ガイドを参照してください。
Oracle BI Applicationsには、フル・モード、増分モードという、Oracle Business Analytics Warehouseへのデータ・ロード用の2つのETLモードがあります。
フル・ロード時には、Oracle BI Applicationsは次のものを抽出します。
ディメンション表のソース表のすべてのレコード。
ファクト表のソース表の、初期抽出日以降に作成されたレコード。初期抽出日では、レコードのすべてがデータ・ウェアハウスにロードされてしまわないように期限を定義します。データ・ソースごとの初期抽出日の値は、Oracle BI Applications構成マネージャで設定します。
1つのETLプロセスでは、1つの表からレコードを抽出することも、複数の表から抽出することもできます。レコードが複数の表を結合した後の成果物である場合、それらの表のいずれかがベース表として識別されます。この表により、レコードの粒度が定義されます。ファクト・レコードの抽出時には、ベース表の「作成日」と初期抽出日のみが比較されます。
増分ロード時には、最終抽出日の後で変更されたレコードまたは作成されたレコードが抽出されます。これは、最終抽出日の値と、ソース表の最終更新日(LUD)タイプ列を比較することで行われます。このような列がソース表に含まれていない場合、Oracle BI Applicationsでは、その表からすべてのレコードが抽出されます。最終抽出日の値は、その表から最後にデータを抽出した時点から削除日数の値を差し引いて計算されます。削除日数パラメータは、ETLを前回実際に実行した時点より前に、ETL抽出の時間枠を戻すために使用します。これにより、前回のETLでは見逃されていた可能性のあるレコードが、次回のETLで取り出されるようになります。ETLプロセスの実行中に更新され、ETLが完了するまでコミットされなかったレコードは、そのETLプロセスで見逃されることがあります。
削除日数パラメータの値は、Oracle BI Applications構成マネージャで設定します。小さな値を設定すると、ETLで抽出するレコード数が少なくなるためにパフォーマンスが向上しますが、レコードが検出されない危険性が高くなります。不定期に実行するETLには大きな値の設定が実用的ですが、これによりデータ・ウェアハウスで抽出および更新されるレコードの数が多くなります。そのため、削除日数の値は非常に大きな数には設定しないでください。大きな削除日数の数値は、以前に処理した、変更のないレコードの再抽出をトリガーするためにも使用されます。削除日数の値は、絶対に0に設定しないでください。
前述したように、1つのETLプロセスで単一の表から1つのレコードを抽出できますが、複数の表を結合した後の成果物である複数のレコードの抽出に使用するほうが一般的です。複数の表から抽出するときには、1つの表がベース表として識別されます。この表により、レコードの粒度が定義されます。ベース表に変更があると、レコードの抽出がトリガーされます。ただし、ベース表以外の表に変更が加えられたにもかかわらず、ベース表自体には変更がない場合があります。ベース表以外に変更があったときにもレコードの抽出をトリガーする必要がある場合は、これらの表を補助表として参照します。つまり、レコードの抽出が必要かどうかを判断するときに、ベース表のLUD列だけでなく、すべての補助表のLUD列も比較されるということです。これらの表のいずれかでLUD列に変更があると、レコードが抽出されます。抽出のトリガー操作に関連付けられていない表に変更があった場合、増分フィルタリング・ロジックでは、この表のLUD列が比較されません。
ナレッジ・モジュール(KM)は、Oracle Business Analytics Warehouseシステム内の各種タスクを実装します。使用可能な各種のKMは次のとおりです。
リバースエンジニアリング(RKM)。ソース・データベースから表などのオブジェクト・メタデータを読み取って、表、列、索引をモデルにインポートするために使用します。RKMの詳細は、「リバース・ナレッジ・モジュールについて」を参照してください。
ローディング(LKM)。ステージング領域へのロード時に、ソース・データベースからのデータ抽出を効率化するために使用します(使用可能な場合は、データベース固有のバルク・アンロード・ユーティリティを使用できる)。
統合(IKM)。各種の戦略(遅延変更ディメンションや、挿入/更新戦略など)を使用してターゲットにデータをロードするために使用します。
チェック(CKM)。データの検証とクレンジングに使用します。
ジャーナル化(JKM)。単一の表またはビューのいずれか、または表やビューの一貫したセットの中にある、新しいデータと変更されたデータを記録するために使用します。
サービス(SKM)。Webサービスの形式でデータを公開します。
Oracle BI Applicationsで使用可能なKMの詳細は、付録B「ナレッジ・モジュールのリファレンス」を参照してください。
Oracle BI Applicationsでは、ODIリーバス・エンジニアリング・プロセスを使用して、ソース・システムのメタデータをリポジトリに移入します。RKMは、データ・ストレージからメタデータを取得して、そのメタデータをリポジトリにロードします。たとえば、RKMは、データベースから表、列、データ型、制約の説明およびコメントを検出して、リポジトリにロードします。RKMは、データベース、XMLファイル、各種のフラット・ファイルなど、様々なテクノロジをサポートしています。また、RKMを使用して、データベースまたはアプリケーション(Oracle E-Business Suite、Siebel CRM、PeopleSoftなど)から非標準のメタデータを取得することもできます。
RKMロールは、モデルに対してカスタマイズされたリバース・エンジニアリングを実行するためのものです。RKMは、アプリケーションまたはメタデータ・プロバイダへの接続とメタデータの変換、およびその結果のODIリポジトリへの書き込みを処理します。メタデータは、一時表に書き込まれます。その後、RKMがODI APIを呼び出して、これらの表からメタデータを読み取ってから、それらを作業リポジトリのODIメタデータ表に増分更新モードで書き込みます。
Oracle BI ApplicationsのODIリポジトリには、関連するソース・データの各モデルが格納されています。そのため、RKMの実行は、ソース・システムにカスタマイズされた表があって、その変更内容をODIリポジトリにインポートする場合にのみ必要になります。表とタスクのカスタマイズの詳細は、『Oracle Business Intelligence Applications管理者ガイド』を参照してください。
Oracle BI Applicationsでは、Oracle Business Analytics Warehouseへの複数のソース・システムからのデータ・ロードがサポートされています。2つの異なるソースで同一のアダプタが必要な場合は、ODIリポジトリで複製するアダプタのモデルとマップが必要になります。
マルチソースの例
PeopleSoft 9.0ソースとOracle EBS 11.5.10ソースがあって、その両方がターゲット・ファクト表ASTXACT_FGをロードしているシナリオについて考えてみましょう。このターゲット表のロードには、次の3つのシリアル・ステップが含まれます。
ターゲット表(ASTXACT_FG)の初期化。
ターゲット表(ASTXACT_FG)のロード。
ターゲット表(ASTXACT_FG)のファイナライズ。
図1-3に、ODI Studioにおけるこれらのロード・プラン・ステップを示します。
両方のソース(PeopleSoft 9.0およびOracle EBS 11.5.10)からのデータは、初めてターゲット表(ASTXACT_FG)にロードされています。つまり、フル・ロードが行われます。一般に、フル・ロードの実行時にはターゲット表が切り捨てられます。この場合、これらのデータ・ソースは相互に依存していないため、ロード・プランをパラレルで実行できます。ただし、2つ目のソースからのロードによって、ターゲット表が切り捨てられないようにする必要があります(最初のソースのデータがすでに格納されている場合)。この問題は、次のように解決します。ターゲット表の初期化ステップでターゲット表を切り捨てます。その次のターゲット表のロード・ステップに、2つの子パラレル・ステップを含めます。これらでは、それぞれターゲットが各ソース・システムからロードされます。最後に、ターゲット表のファイナライズ・ステップで、索引が作成されて表が分析されます。したがって、生成されたロード・プランでは、必要なときにのみ(ここでは、ソース・システムが表をロードする前の1回のみ)表が切り捨てられます。
リソースごとに個別のロード・プランを用意できますが、ロード・プランのパラレル実行はできません。
|
注意: Oracle BI Applications構成マネージャおよびODIでは、ロード・プランのパラレル実行が禁止されていませんが、これは、次の理由から実行しないことをお薦めします。
|
Oracle BI Applicationsには、ETL操作用の2つの職務ロールがあります。
ロード・プラン・オペレータ職務
ロード・プラン管理者職務
Oracle BI Applicationsには、次の追加の職務ロールがあります。
BI Applications管理者職務
BI Applications機能開発者職務
BI Applications実装マネージャ職務
構成マネージャおよび機能設定マネージャへのアクセスは、これらの職務ロールによって制御されています。
セキュリティ管理者は、ユーザーのジョブ職責に基づいて、適切な職務ロールをユーザーに付与する必要があります。各職務ロールがアクセスできる構成マネージャおよび機能設定マネージャの画面については、『Oracle Business Intelligence Applicationsセキュリティ・ガイド』を参照してください。
BI Applications管理者、ロード・プラン・オペレータ、ロード・プラン管理者の各ユーザーは、ODIへの適切なアクセス権が必要になります。これらのユーザーは、LDAPシステムのみでなく、ODIリポジトリで作成する必要があります。また、スーパーバイザ・プロファイルまたは適切なODIプロファイルを付与する必要もあります。BI Applications管理者には、ODIのスーパーバイザ・ロールを付与する必要があります。セキュリティ管理者と協働して、適切な職務ロールを取得してください。
ODIでのセキュリティ管理の詳細は、Oracle Fusion Middleware Oracle Data Integrator開発者ガイドを参照してください。
