| Oracle Warehouse Builderユーザーズ・ガイド 10gリリース2（10.2） B31258-02 |
|
 戻る |
 次へ |
この章は、パフォーマンス要件を満たすETLロジックを作成するためのガイドとして使用します。
この章の内容は次のとおりです。
このセクションでは、次の項目でPL/SQLマッピング設計を説明します。
Warehouse Builderでは、次の基準を満たすPL/SQLマッピングのコードが生成されます。
各演算子の出力コードは、その演算子の次のダウンストリーム演算子の入力コード要件を満たしている。
マッピングにPL/SQL出力のみを生成する演算子が含まれている場合は、すべてのダウンストリーム・データフロー演算子もPL/SQLによって実装可能である必要がある。このようなマッピングでのSQL演算子は、PL/SQL出力をターゲットにロードした後でのみ使用できます。
マッピングを設計するときは、そのマッピングの各演算子の入力および出力コードのタイプを記録して、その有効性を評価できます。たとえば、図8-1のマッピングでは、Match-Merge演算子MMはPL/SQL出力を生成しますが、後続の結合演算子はSQL出力のみを受け入れるため、無効であることがわかります。
目的のマッピング結果を実現するには、図8-2に示すようにMatch-Mergeを実行する前にソース表を結合するか、図8-3に示すように結合を実行する前にMatch-Mergeからステージング表に結果をロードすることを検討します。
表8-1および表8-2は、各Warehouse Builder演算子の実装タイプを示しています。これらの表は、PL/SQLコードにカーソルの演算子と関連付けられた演算があるかどうかも示しています。この情報は、指定のマッピング設計に有効なオペレーティング・モードを判断する際に使用します。また、エラー処理中に使用できる監査詳細の判断にも使用します。
表8-1 PL/SQLマッピングでのソースおよびターゲット演算子の実装
| 演算子 | 実装タイプ | セット・ベース・モードで有効か | 行ベース・モードで有効か | 行ベース（ターゲットのみ）で有効か |
|---|---|---|---|---|
|
ソース演算子: 表、キューブ、ビュー、外部表 |
SQL |
はい |
はい |
はい。カーソルの一部。 |
|
ターゲット演算子: 表、キューブ、ビュー |
SQL PL/SQL |
はい。ロードが=DELETEまたは=UPDATEで、データベースが10gより前の場合を除く。 |
はい |
はい。カーソルの一部ではない。 |
|
ソースとしてのフラット・ファイル |
PL/SQLの場合は、外部表を作成。 |
はい |
はい |
はい。カーソルの一部。 |
|
ターゲットとしてのフラット・ファイル |
SQL |
はい。ロードが=DELETEまたは=UPDATEで、データベースが10gより前の場合を除く。 |
はい |
はい。カーソルの一部ではない。 |
|
ソースとしてのアドバンスト・キュー |
SQL |
はい |
はい |
はい。カーソルの一部。 |
|
ターゲットとしてのアドバンスト・キュー |
SQL |
はい。ロードが=DELETEまたは=UPDATEで、データベースが10gより前の場合を除く。 |
はい |
はい。カーソルの一部ではない。 |
|
ソースとしての順序 |
SQL |
はい |
はい |
はい。カーソルの一部。 |
表8-2 PL/SQLマッピングでのデータ・フロー演算子の実装
| 演算子名 | 実装タイプ | セット・ベース・モードで有効か | 行ベース・モードで有効か | 行ベース（ターゲットのみ）モードで有効か |
|---|---|---|---|---|
|
アグリゲータ |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
定数演算子 |
PL/SQL SQL |
はい |
はい |
はい |
|
データ・ジェネレータ |
SQL*Loaderのみ |
N/A |
N/A |
N/A |
|
デュプリケータ解除 |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
式 |
SQL PL/SQL |
はい |
はい |
はい |
|
フィルタ |
SQL PL/SQL |
はい |
はい |
はい |
|
ジョイナ |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
キー参照 |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
入力パラメータのマッピング |
SQL PL/SQL |
はい |
はい |
はい |
|
出力パラメータのマッピング |
SQL PL/SQL |
はい |
はい |
はい |
|
Match-Merge |
SQL入力 PL/SQL出力 （XREFグループからのPL/SQL入力のみ） |
いいえ |
はい |
はい。カーソルの一部ではない。 |
|
Name and Address |
PL/SQL |
いいえ |
はい |
はい。カーソルの一部ではない。 |
|
ピボット |
SQL PL/SQL |
はい |
はい |
はい |
|
マッピング後プロセス |
不適切 |
はい。データ・フローとは無関係。 |
はい |
はい |
|
マッピング前プロセス |
不適切 |
はい。データ・フローとは無関係。 |
はい |
はい |
|
集合 |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部である場合のみ。 |
|
ソーター |
SQL |
はい |
はい。カーソルの一部である場合のみ。 |
はい。カーソルの一部として。 |
|
スプリッタ |
SQL PL/SQL |
はい |
はい |
はい |
|
テーブル・ファンクション |
SQLまたはPL/SQL入力 SQL出力のみ |
はい |
はい |
はい |
|
プロシージャとしての変換 |
PL/SQL |
いいえ |
はい |
はい。カーソルの一部ではない。 |
|
DMLを実行しないファンクションとしての変換 |
SQL PL/SQL |
はい |
はい |
はい。カーソルに含まれる。 |
PL/SQL実装でのマッピングの場合は、次のオペレーティング・モードのうち1つを選択します。
セット・ベースから行ベースへのフェイルオーバー
セット・ベースから行ベース（ターゲットのみ）へのフェイルオーバー
選択するデフォルト・オペレーティング・モードは、期待するパフォーマンス、必要な監査データの量、マッピングの設計方法によって異なります。マッピングには、行ベースへのフェイルオーバー・モードのオプションを除いて、最低1つ、最高3つの有効なオペレーティング・モードがあります。コードの作成時には、指定したデフォルトのオペレーティング・モードの他に、選択していないモードのコードも生成されます。そのため、実行時には、デフォルト・オペレーティング・モードまたは他の有効なオペレーティング・モードのいずれかで実行するように選択できます。
マッピングでの演算子のタイプによって、選択可能なオペレーティング・モードが制限される場合があります。原則として、セット・ベース・モードで実行されるマッピングには、プロシージャとして使用されるMatch-Merge、Name and Address、変換以外のすべての演算子を含めることができます。行ベース・モードおよび行ベース（ターゲットのみ）モードではすべての演算子を含めることができますが、アグリゲータ、ジョイナ、キー検索などのSQLベースの演算子の使用方法には重要な制限があります。SQLベースの演算子を行ベース・モードのいずれかで使用するには、演算子と関連付けられた演算をカーソルに含めることができることを確認します。
これらの一般的なルールについては、次の各項で説明します。
セット・ベース・モードでは、すべてのデータを処理し、すべての演算を実行する単一のSQL文が生成されます。データをセットで処理するとパフォーマンスが向上しますが、使用できる監査情報は制限されます。ランタイム監査のレポートは、実行エラーのみに制限されます。セット・ベース・モードでは、エラーを含む行の詳細を表示できません。
図8-4は、セット・ベースのオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。TAB1、FLTR、TAB2は、SQLを使用してセットとして処理されます。
セット・ベース・モードのマッピングを正確に設計するには、Match-Merge演算子やName and Address演算子など、行ごとの処理を必要とする演算子を避けます。SQLで実行できないデータフローの演算子を含めた場合、セット・ベース・コードは作成されず、セット・ベース・モードでのパッケージの実行時にエラーが発生します。
マッピングのターゲット演算子の場合、ロード・タイプINSERT/UPDATEおよびUPDATE/INSERTはセット・ベース・モードに対して常に有効です。UPDATEロードがセット・ベース・モードでサポートされるのは、Oracle Databaseが10g以上の場合のみです。セット・ベース・モードでは、DELETEロードはサポートされていません。セット・ベースのマッピングで演算子を処理する方法の一覧は、表8-2を参照してください。
行ベース・モードでは、データを行ごとに処理する文が生成されます。SQLカーソルには、SELECT文があります。後続のすべての文はPL/SQLです。PL/SQLで実行されたすべての演算子については、ランタイム監査の全情報にアクセスできますが、カーソルで実行された演算については、限られた情報にのみアクセスできます。
表8-2は、行ベースのオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。TAB1はカーソルに含まれ、SQLを使用してセットとして処理されます。FLTRおよびTAB2は、PL/SQLを使用して行ごとに処理されます。
PL/SQLで実行できないSQLベースの演算子がマッピングに含まれている場合は、カーソル内の演算を使用したコード生成が試行されます。有効な行ベース・コードを生成するには、次のSQLベース演算子のいずれかを含めた場合はその演算がカーソルに含まれるようにマッピングを設計します。
集計
デュプリケータ解除
結合
キー参照
順序
集合
ソーター
前述の演算子をカーソルに含める場合は、PL/SQLコードを生成する演算子を直前に配置しないでください。つまり、行ベース・モードのマッピングに、プロシージャとして実装された変換、ソースとして使用されるフラット・ファイル、Match-Merge演算子、Name and Address演算子の直後に7つのSQLベース演算子のいずれかが含まれている場合、そのマッピングは実行できません。有効な設計を行うには、PL/SQLを生成する演算子とSQLベース演算子の間にステージング表を含めます。
行ベース（ターゲットのみ）モードでは、SELECT文のカーソルが生成され、そのカーソルにできるだけ多くの演算が含まれます。各ターゲットには、行が個別に挿入されます。PL/SQLで実行されたすべての演算子については、ランタイム監査の全情報にアクセスできますが、カーソルで実行された演算については、限られた情報にのみアクセスできます。このモードは、データの抽出と変換には高速のセット・ベース演算を使用するが、エラーの発生しやすいデータのロードには高度な監査機能が必要な場合に使用します。
表8-2は、行ベース（ターゲットのみ）のオペレーティング・モードでの実行時に、マッピングのコード生成に使用される、単純なマッピングと関連ロジックを示しています。TAB1およびFLTRはカーソルに含まれ、SQLを使用してセットとして処理されます。TAB2は、行ごとに処理されます。
行ベース（ターゲットのみ）は、行ベースのオペレーティング・モードと同じ制限をSQLベース演算子に加えます。また、複数ターゲットのマッピングの場合は、各ターゲットのカーソルでコードが生成されます。
Warehouse Builderでデータをコミットする主な方法は2つあります。データのコミットまたはロールバックは、マッピング設計に基づいて実行できます。そのためには、「マッピング設計に基づいたデータのコミット」で説明するいずれかのコミット制御方法を使用します。
また、PL/SQLマッピングの場合は、マッピング設計とは無関係にデータをコミットまたはロールバックできます。「マッピング設計に依存しないデータのコミット」の説明に従って、プロセス・フローを使用してデータをコミットするか、独自の方法を作成します。
デフォルトでは、マッピング設計に基づいてデータがロードされ、自動的にコミットされます。PL/SQLマッピングの場合は、デフォルト設定を上書きして、Warehouse Builderでデータがコミットされる時期と方法を制御できます。マッピングでデータをコミットする方法には、次のオプションがあります。
自動: これはデフォルト設定で、すべてのマッピング・タイプに有効です。Warehouse Builderでは、マッピング設計に基づいてデータがロードされ、自動的にコミットされます。マッピングに複数ターゲットがある場合は、他のターゲットに関係なく、ターゲットごとに別々にコミットとロールバックが行われます。不規則にロードされた複数ターゲットの結果が、大きくない場合や相関関係にない場合は、自動コミットを使用します。
自動相関: 自動相関コミットは、自動コミットの特殊タイプで、複数ターゲットのPL/SQLマッピングにのみ適用されます。Warehouse Builderでは、すべてのターゲットは集合的に扱われ、全ターゲットにわたってコミットまたはロールバックが均一に実行されます。ソースのすべての行が、影響を受けるターゲットすべてに均一な影響を確実に与えることが重要な場合は、相関コミットを使用します。相関コミットの詳細は、「単一のソースから複数ターゲットへのデータのコミット」を参照してください。
手動: 手動コミット制御は、複雑なビジネス・ロジックの挿入、検証の実行、または他のマッピングの実行を、データのコミット前に実行するPL/SQLマッピングに対して選択します。この例は、「マッピングへのコミット・ロジックの埋込み」および「マッピング設計に依存しないデータのコミット」を参照してください。
共通ソースに基づいて複数ターゲットを作成する場合は、ソースのすべての行が、影響を受けるターゲットすべてに均一な影響を与えることを確認します。
図8-7は、このケースを示すPL/SQLマッピングです。ターゲット表はすべて、ソース表に依存しています。SOURCEの行によって、複数ターゲット（TARGET_1とTARGET_2など）が変更される場合、Warehouse Builderでは、影響を受ける両方のターゲットに対して適切なデータが同時にコミットされます。マッピングを再度実行したときにこの関係が維持されない場合、データは不正確になり、使用できなくなることもあります。
SOURCEからの行数が比較的少ない場合、3つのターゲットの関係を維持するのは難しくありません。ただし、共通ソースに依存するターゲットの手動による保持は、ソースからの行数を増加したり、より多くのターゲットと変換を持つさらに複雑なマッピングを設計する際に、手間がかかります。
ソースのすべての行がすべてのターゲットに正しく影響を与えていることを確認するには、相関コミット計画を使用するマッピングを構成します。
セット・ベース・モードでは、相関コミットがロールバック・セグメントのサイズに影響を与えます。データをマージ（insert/updateまたはupdated/insert）する際には、ロールバック・セグメントの空き領域が問題となる場合があります。
相関コミットは、PL/SQLバルク処理コードで透過的に操作されます。
相関コミット計画は、パーティション交換ロード用に構成されているモードで実行されるマッピングや、アドバンスト・キュー、Match-Mergeまたはテーブル・ファンクション演算子を含むマッピングでは使用できません。
コミット計画とオペレーティング・モードの組合せによって、マッピング動作が決定されます。表8-3に、選択できる有効な組合せを示します。
表8-3 オペレーティング・モードの有効なコミット計画
| オペレーティング・モード | 自動相関コミット | 自動コミット |
|---|---|---|
|
セット・ベース |
有効（Valid） |
有効（Valid） |
|
行ベース |
有効（Valid） |
有効（Valid） |
|
行ベース（ターゲットのみ） |
適用不可 |
有効（Valid） |
相関コミットは、行ベース（ターゲットのみ）に対して適用できません。このオペレーティング・モードでは、カーソルをターゲットのできるだけ近くに配置するように定義されています。この結果、ほとんどの場合、各SELECT文に対するターゲットは1つのみとなり、複数ターゲットに対してデータをコミットする目的が失われます。行ベース（ターゲットのみ）と相関コミットの組合せでマッピングを設計した場合、マッピングは実行されますが、相関コミットは実行されません。
各オペレーティング・モードとコミット計画の組合せがマッピングに与える影響を理解するために、図8-7にあるマッピングについて考えてください。ソース表からのデータが1,000個の新規行であると仮定します。マッピングが正常に実行された場合は、各ターゲットに1,000行がロードされます。このマッピングでTarget_2への100番目の新規行のロードに失敗した場合は、コミット頻度や最大エラー数など他の構成設定からの影響を無視すると、次の結果が得られます。
セット・ベース/相関コミット: マッピングにエラーが1つでもあると、すべてのデータがロールバックされます。Target_2への挿入中にエラーが発生した場合、その表のエラーがレポートされ、行はロードされません。Target_1に挿入済のすべての行がロールバックされ、Target_3には行がロードされません。どのターゲット表にも行が追加されません。エラーの詳細には、Target_2へのロード中に発生したエラーのみがレポートされます。
行ベース/相関コミット: 各行が最初の行から個別に評価され、3つのターゲットすべてにロードされます。行のロードは、行100のTarget_2へのロード・エラーが発生するまで続行されます。エラーがレポートされ、行はロードされません。Target_1に挿入済の行100がロール・バックされ、Target_3には行100がロードされません。その後、Target_1への行101のロードが再開され、残りの行のロードが続行されます。他のエラーが発生しないと、各ターゲットに999個の新規行が挿入されて、マッピングが完了します。ソース行は、これらのターゲットに正確に反映されます。
セット・ベース/自動コミット: Target_2への挿入中にエラーが発生した場合、行はロードされず、その表のエラーがレポートされます。Target_3への行の挿入は続行されますが、Target_1の行はロールバックされません。他のエラーが発生しないと、Target_2に関する1つのエラー・メッセージがレポートされて、マッピングは完了します。Target_2に行は挿入されず、Target_1とTarget_3に1,000行ずつ挿入されます。ソース行は、これらのターゲットに正確に反映されません。
行ベース/自動コミット: 各行が最初の行から個別に評価され、ターゲットにロードされます。行のロードは、Target_2に行100をロードする際にエラーが発生し、そのエラーがレポートされるまで続行されます。Target_1の行100はロールバックされず、Target_3には行100が挿入されます。その後、残りの行のロードが続行されます。他のエラーが発生しないと、Target_2に999行が挿入されて、マッピングは完了します。他のターゲットには1,000行がそれぞれ挿入されます。ソース行は、これらのターゲットに正確に反映されません。
PL/SQLマッピングの場合のみ、SQL文でマッピング前またはマッピング後演算子を追加してデータをコミットおよびロールバックすることによって、コミット・ロジックをマッピング設計に埋め込むことができます。マッピングを実行すると、マッピング前またはマッピング後演算子に指定したSQL文のみに基づいて、データがコミットまたはロールバックされます。
Warehouse Builderの既存のマッピング演算子の設計に手間がかかったり、設計が不可能なビジネス・ルールを実装するには、次の手順を使用してください。たとえば、あるターゲットに1つの行が存在することを確認するとします。その場合は、必要なロジックをSQLで記述し、マッピング前またはマッピング後に演算子を使用してそのロジックをマッピングに導入します。
コミット・ロジックをマッピング設計に組み込む手順は、次のとおりです。
マッピング前またはマッピング後演算子を含めるようにマッピングを設計します。いずれかの演算子を使用して、コミットおよびロールバックのSQL文を導入します。
「コミット制御」を「手動」に設定した状態で、マッピングを構成します。
プロジェクト・エクスプローラで、マッピングを右クリックして「構成」を選択します。「コード生成オプション」の「コミット制御」で「手動」を選択します。
手動によるデータのコミットを選択した場合の影響については、「手動コミット制御について」を参照してください。
マッピングを配布します。
マッピングを実行します。
マッピングは実行されますが、マッピング前またはマッピング後演算子で記述したコミット・ロジックが処理されるまでデータはコミットされません。
次のいずれかの理由で、マッピング設計に依存せずにデータをコミットする必要が生じる場合があります。
データのコミット前に複数マッピングを実行: すべてのマッピングが正常に実行および検証されるまで、データをコミットしないまま、複数マッピングを実行する場合があります。たとえば、ディメンションのロードとキューブのロードに対して個別のマッピングがある場合です。
ターゲットの効率的な維持: 誤ったデータがロードされて非常に大きいターゲットにコミットされると、その障害の修復は困難で時間がかかる場合があります。これを回避するには、最初にデータをチェックし、次に、commitまたはrollbackコマンドを発行するかどうかを決定します。
これらの目的を実現するための最初の手順は、「コミット制御」を「手動」に設定してマッピングを構成することです。
手動コミット制御について
手動コミット制御を使用すると、マッピング設計に関係なく、Warehouse Builderでデータをコミットする時期を指定できます。手動コミット制御は監査統計に影響を与えません。これは、commitまたはrollbackコマンドを発行する前に、挿入済の行数およびその他の監査情報を表示できることを意味します。
手動コミットを使用するときは、このオプションがパフォーマンスに与える影響を考慮してください。ターゲットをロード後に読み込む必要がある設計では、パラレルに実行するマッピングがシリアルに実行される場合があります。これは、データを、リモート・ソースから移動する場合や同じ表にバインドされた2つのターゲットにロードする場合に発生します。
手動コミット制御を有効にすると、Warehouse Builderでは、PELがオフの状態でマッピングが実行されます。
この項では、マッピング設計に依存しないデータのコミットについて、2つの手順を説明します。最初の手順では、マッピングを実行してから、SQL Plusセッションでデータをコミットする方法を説明します。この手順では、複数マッピングを実行してからデータをコミットする計画をテストしてデバッグします。次に、2番目の手順でその計画を自動化します。
両方の手順とも、各PL/SQLマッピングで生成されるメイン・プロシージャの使用を前提にしています。
メイン・プロシージャは、Warehouse Builderでマッピングを起動するためのロジックを示すプロシージャです。このプロシージャは、PL/SQLスクリプトで使用したり、インタラクティブなSQL Plusセッションで使用できます。
メイン・プロシージャを使用するときは、必須パラメータのp_statusを指定する必要があります。また、表8-4に示すように、マッピングの実行に関連する他のパラメータをオプションで指定できます。オプション・パラメータを指定しない場合、Warehouse Builderではデフォルト設定が使用されます。
表8-4 メイン・プロシージャのパラメータ
| パラメータ名 | 説明 |
|---|---|
|
p_status |
この必須パラメータを使用して、マッピングの完了時のステータスを記述します。このパラメータは、statusという事前定義済変数とともに機能します。 status変数は、たとえば、OKはマッピングがエラーなしで完了したことを示すように定義されています。OK_WITH_WARNINGSは、ユーザー・エラーが発生してマッピングが完了したことを示します。FAILUREは、マッピングで致命的エラーが発生したことを示します。 |
|
p_operating_mode |
このオプション・パラメータを使用して、SET_BASEDなどの「デフォルト・オペレーティング・モード」を渡します。 |
|
p_bulk_size |
このオプション・パラメータを使用して、「バルク・サイズ」を渡します。 |
|
p_audit_level |
このオプション・パラメータを使用して、COMPLETEなどの「デフォルト監査レベル」を渡します。 |
|
p_max_no_of_errors |
このオプション・パラメータを使用して、許容されている「エラーの最大数」を渡します。 |
|
p_commit_frequency |
このオプション・パラメータを使用して、「コミット頻度」を渡します。 |
PL/SQLマッピングの場合のみ、マッピングを実行して、SQL Plusセッションからcommitおよびrollbackコマンドを発行できます。SQL Plusに関する知識とメイン・プロシージャに基づいて、データのコミット前に複数マッピングを手動で実行して検証できます。
実行時に手動でデータをコミットする手順は、次のとおりです。
PL/SQLマッピングを設計します。たとえば、ディメンションをロードするためのマッピングを作成し、キューブをロードするための別のマッピングを作成します。
ここで説明する手順は、SQL*LoaderマッピングおよびABAPマッピングには該当しません。
「コミット制御」を「手動」に設定した状態で、両方のマッピングを構成します。
プロジェクト・エクスプローラで、マッピングを右クリックして「構成」を選択します。「コード生成オプション」で、「コミット制御」を「手動」に設定します。
各マッピングを生成します。
SQL Plusセッションから次のコマンドを発行して、最初のマッピング（この例ではmap1）を実行します。
var status varchar2(30);
execute map1.main(:status);
最初の行では、表8-4で説明している定義済変数statusを宣言します。2行目では、p_statusがstatus変数に設定されます。map1が完了すると、SQL Plusによって、OKなどのマッピング・ステータスが表示されます。
2番目のマッピングであるキューブ・マッピング（この例ではmap2）を実行します。
2番目のマッピングは、最初のマッピングと同じ方法で実行できます。または、表8-4に示す追加パラメータを指定して、この例のmap2の実行方法を指定することもできます。
map2.main (p_status => :status, \
p_operating_mode => 'SET_BASED', \
p_audit_level => 'COMPLETE') ;
2つのマッピングの実行結果を確認して、commitコマンドまたはrollbackコマンドのいずれかを送信します。
「プロセス・フロー・エディタを使用したマッピングのコミット」の手順に従って、コミット計画を自動化します。
PL/SQLマッピングの場合のみ、複数のマッピングをまとめてコミットまたはロールバックできます。Sqlplusアクティビティ、メイン・プロシージャおよびPL/SQLスクリプトの記述方法に関する知識に基づいて、プロセス・フローを使用すると、すべてのマッピングが正常に完了した後、またはマッピングに失敗した場合のデータのロールバック後にデータをコミットするロジックを自動化できます。
プロセス・フローを使用して複数のマッピングをコミットする手順は、次のとおりです。
PL/SQLマッピングを設計します。
ここで説明する手順は、SQL*LoaderマッピングおよびABAPマッピングには該当しません。
各マッピングが同じスキーマに配布されていることを確認します。
すべてのマッピングで、ロケーションが同じスキーマを指し示している必要があります。そのためには、同じターゲット・モジュールでマッピングを設計します。ターゲット・モジュールが複数の場合は、そのロケーションが同じスキーマを指し示していることを確認します。
「コミット制御」を「手動」に設定した状態で、各マッピングを構成します。
プロジェクト・エクスプローラで、マッピングを右クリックして「構成」を選択します。「コード生成オプション」で、「コミット制御」を「手動」に設定します。
複数のマッピング・アクティビティではなく、1つのSqlplusアクティビティを使用してプロセス・フローを設計します。
典型的なプロセス・フローでは、マッピングごとにマッピング・アクティビティを追加し、プロセス・フローで各マッピング・アクティビティ後に暗黙的なコミットを実行します。ただし、この設計では、マッピング・アクティビティを追加しないでください。かわりに、1つのSqlplusアクティビティを追加してください。
メイン・プロシージャを使用するPL/SQLスクリプトを作成して、各マッピングを実行します。次のスクリプトは、最初のマッピングが成功した場合のみ次のマッピングを実行する方法を示しています。
declare status varchar2(30);begin map1.main(status); if status!='OK' then rollback else map2.main(status); if status!='OK' then rollback; else commit; end if; end if;end if;
PL/SQLスクリプトをSqlplusアクティビティに貼り付けます。
エディタ・エクスプローラで、Sqlplusアクティビティの下の「SCRIPT」 を選択し、図8-8に示すオブジェクト・インスペクタで「値」をダブルクリックします。
オプションで、「スケジュールを定義および使用するプロセス」の手順に従って、スケジュールをプロセス・フローに適用します。
マッピング、プロセス・フローおよびスケジュール（定義した場合）を配布します。
複数ターゲットのマッピングを設計するときは、Warehouse Builderによるターゲットのロードが特定の順序で行われることを確認する場合があります。これは、あるターゲットの1つの列が別のターゲットからデータを導出する場合があるためです。
PL/SQLマッピングにおける参照整合性を確認する手順は、次のとおりです。
複数ターゲットのPL/SQLマッピングを設計します。
（オプション）外部キーを指定して、2つのターゲット間に親子関係を定義します。
子表の外部キーは、親表の主キーを参照している必要があります。主キーとして定義した列が親にない場合は、列を追加して主キーとして定義する必要があります。この方法の例は、「SQL*Loaderマッピングでの参照整合性を確認するための従来のロードの使用」を参照してください。
マッピングのプロパティで、「ターゲット・ロード順序」プロパティを表示します。
前の手順で外部キー関係を定義した場合、Warehouse Builderでは、子の前に親ターゲットをロードするデフォルトのロード順序が計算されます。外部キーを定義していない場合は、次の図に示す「ターゲット・ロード順序」ダイアログを使用して、ロード順序を定義します。
詳細は、「ターゲット・ロード順序」を参照してください。
すでに説明した「ターゲット・ロード順序付けを使用」構成プロパティが、デフォルト値のTRUEに設定されていることを確認します。
このトピックには、次の項目が含まれます。
マスター/ディテール構造を持つ複数レコード・タイプのファイルからデータを抽出して表にマッピングする場合は、順序のマッピング演算子をマッピングに追加して、マスター・レコードとディテール・レコード間の関係をサロゲート主キーまたは外部キーの関係で保持します。マスター/ディテール・ファイル構造とは、マスター・レコードの後にディテール・レコードが続く構造です。例8-1では、"E"で始まるレコードは従業員（Employee）情報が保存されているマスター・レコードです。"P"で始まるレコードは、対応する従業員の給与（Payroll）情報が保存されているディテール・レコードです。
例8-1 マスター/ディテール構造を持つ複数レコード・タイプのフラット・ファイル
E 003715 4 153 09061987 014000000 "IRENE HIRSH" 1 08500 P 01152000 01162000 00101 000500000 000700000 P 02152000 02162000 00102 000300000 000800000 E 003941 2 165 03111959 016700000 "ANNE FAHEY" 1 09900 P 03152000 03162000 00107 000300000 001000000 E 001939 2 265 09281988 021300000 "EMILY WELLMET" 1 07700 P 01152000 01162000 00108 000300000 001000000 P 02152000 02162000 00109 000300000 001000000
例8-1では、マスター・レコードとディテール・レコード間の関係は、物理的なレコードの順序のみが継承されます。つまり、給与レコードはその前の従業員レコードに対応しています。ただし、これがディテール・レコードをそのマスターに関連付ける唯一の方法である場合、この関係は、Warehouse Builderによって各レコードがターゲット表にロードされるときに失われます。
マスター・レコードとディテール・レコードが共通フィールドを共有している場合は、その両レコード間の関係を維持できます。たとえば、例8-1の「従業員ID」フィールドが従業員レコードと給与レコードの両方に存在する場合は、このフィールドを従業員表の主キー、給与表の外部キーとして使用すると、給与レコードを適切な従業員レコードに関連付けることができます。
ただし、共通フィールドがファイルに存在せず、マスター・レコードとディテール・レコードを結合できない場合は、順序列をマスター・ターゲットとディテール・ターゲットの両方に追加して、マスター・レコードとディテール・レコード間の関係を維持する必要があります（表8-5および表8-6を参照）。この追加する値を生成するには、順序のマッピング演算子を使用します。
表8-5は、例8-1にあるファイルからマスター・レコードを抽出したターゲット表を示しています。このマスター・レコードのターゲット表には、従業員情報が格納されています。列E1からE10には、フラット・ファイルから抽出したデータが格納されています。列E11は、マスター順序番号を格納するために追加された列です。この番号は従業員1人につき1ずつ増加します。
表8-5 マスター・レコードが格納されたターゲット表
| E1 | E2 | E3 | E4 | E5 | E6 | E7 | E8 | E9 | E10 | E11 |
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
表8-6は、例8-1にあるファイルからディテール・レコードを抽出したターゲット表を示しています。このディテール・レコードのターゲット表には、給与情報が格納されており、従業員1人につき1つ以上の給与レコードが存在します。列P1からP6には、フラット・ファイルから抽出したデータが格納されています。列P7は、ディテール順序番号を格納するために追加された列です。各給与レコードの順序番号は、表8-5の対応する従業員レコードの順序番号と一致します。
この項では、マスター・ディテール・フラット・ファイルからレコードを抽出し、そのレコードを2つの異なる表にロードするマッピングの作成方法を説明します。1つのターゲット表にはマスター・レコードを格納し、もう1つのターゲット表にはフラット・ファイルからのディテール・レコードを格納します。2つの表間のマスター・ディテール関係を維持するには、順序のマッピングを使用します。
|
注意: この説明は、従来型パスによるロードを対象にしています。マスター/ディテール・レコードにダイレクト・パス・ロードを使用する手順は、「SQL*Loaderマッピングでの参照整合性を確認するためのダイレクト・パス・ロードの使用」を参照してください。 |
この手順では、このようなマッピングを作成するための一般的な方法を概説します。次に示す詳細な手順も参照してください。
マスター/ディテール関係をマスター/ディテール・フラット・ファイルから抽出して維持する手順は、次のとおりです。
マスター・レコードとディテール・レコードで構成されたフラット・ファイル・ソースをインポートして、サンプリングします。
ファイルのサンプリング時にレコード・タイプに名前を指定する場合は、図8-10に示すように、マスター・レコードとディテール・レコードに説明的な名前を割り当てます。これによって、今後はこれらのレコードを容易に識別できます。
図8-10は、部門と従業員情報が含まれた複数レコード・タイプのフラット・ファイルに対するフラット・ファイル・サンプル・ウィザードを示しています。マスター・レコード・タイプ（従業員レコード）にはEmployeeMasterという名前が、ディテール・レコード・タイプ（給与情報）にはPayrollDetailという名前が指定されます。
図8-10 フラット・ファイルのマスター・レコード・タイプおよびディテール・レコード・タイプのネーミング
フラット・ファイルのマッピング演算子をマッピング・エディタのキャンバスにドラッグ・アンド・ドロップし、データの抽出元のマスター/ディテール・ファイルを指定します。
順序のマッピング演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
マスター・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のリポジトリ表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成できます。次に、必要なすべてのフィールドをファイル演算子のマスター・レコードからマスター表演算子にマッピングまたはコピーし（列の作成）、アウトバウンド調整を実行して後で表を定義できるようにします。
図8-11に示すように、この表には、ロードするマスター・フィールドに必要なすべての列と、順序の値をロードするための追加の数値列が含まれている必要があります。
ディテール・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のリポジトリ表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成できます。次に、必要なすべてのフィールドをファイル演算子のマスター・レコードからマスター表演算子にマッピングまたはコピーし（列の作成）、アウトバウンド同期化を実行して後で表を定義できるようにします。
この表には、ロードするディテール・フィールドに必要なすべての列と、順序の値をロードするための追加の数値列が含まれている必要があります。
図8-12に示すように、必要なすべてのフラット・ファイル・マスター・フィールドをマスター表にマップし、ディテール・フィールドをディテール表にマップします。
図8-12に示すように、順序のマッピングのNEXTVAL属性をマスター表の追加の順序列にマップします。
図8-12に示すように、順序のマッピングのCURRVAL属性をディテール表の追加の順序列にマップします。
図8-12は、マッピングが完成した状態を示しています。フラット・ファイルのマスター・フィールドはマスター・ターゲット表にマッピングされ、ディテール・フィールドはディテール・ターゲット表にマッピングされ、順序のマッピングのNEXTVAL属性とCURRVAL属性はマスター・ターゲット表とディテール・ターゲット表にそれぞれマッピングされています。
この項では、ファイルのエラー数に応じたエラーの対処方法について説明します。
データ・ファイルにほとんどエラーがない場合は、次のように対処します。
順序演算子でマッピングを作成します（「順序演算子」を参照）。
次のパラメータを使用して、マッピングを構成します。
ダイレクト・モード= false
行= 1
エラー許可= 0
コードを生成し、SQL Loaderスクリプトを実行します。
データ・ファイルにエラーがある場合は、最初のエラーが発生した時点でロードが停止します。
データ・ファイルを修正し、次の構成値を使用して制御ファイルを再度実行します。
CONTINUE_LOAD = TRUE
SKIP =ロード済のレコード数
データ・ファイルに少数のエラーがあると思われる場合は、次のように対処します。
seq_nextval列に基づいてマスター・レコードに主キー（PK）を作成します。
マスター表PKを参照するseq_currval列に基づいてディテール・レコードに外部キー（FK）を作成します。
この場合、エラーがあるマスター・レコードは、対応するすべてのディテール・レコードとともに拒否されます。次の手順に従って、これらのレコードを修復します。
マスター・レコードがない、失敗したディテール・レコードをすべて削除します。
不正なファイルのエラーを修正し、これらのレコードのみリロードします。
エラーが非常に少ない場合は、残りのレコードをロードし、正しい順序番号を使用して表を手動で更新することもできます。
ログ・ファイルでは、エラーで失敗したレコードを識別できます。これは、これらのエラーが整合性制約に違反しているためです。次に、エラーのあるログ・ファイル・レコードの例を示します。
Record 9: Rejected - Error on table "MASTER_T", column "C3". ORA-01722: invalid number Record 10: Rejected - Error on table "DETAIL1_T". ORA-02291: integrity constraint (SCOTT.FK_SEQ) violated - parent key not found Record 11: Rejected - Error on table "DETAIL1_T". ORA-02291: integrity constraint (SCOTT.FK_SEQ) violated - parent key not found Record 21: Rejected - Error on table "DETAIL2_T". ORA-02291: invalid number
データ・ファイルに常に多数のエラーが存在する場合は、次のように対処します。
順序のマッピング演算子を使用しないで、すべてのレコードをロードします。
レコードを独立した表にロードします。ダイレクト・モードでデータをロードする際には、次のパラメータを使用すると、データのロードを高速化できます。
行>1
エラー許可= MAX
拒否されたすべてのレコードを修正します。
順序演算子を使用してファイルを再ロードします（「順序演算子」を参照）。
マスター・レコードに一意のフィールドがある（または複数のフィールドを連結した結果、一意の識別子がある）マスター・ディテール・フラット・ファイルを使用している場合は、オプションのダイレクト・パス・ロードを使用すると、ロードを高速化できます。
ダイレクト・パス・ロードの場合、各レコードのレコード番号（RECNUM）はマスター表とディテール表に格納されます。ロード後の手順では、このRECNUMを使用して、各ディテール行を、対応するマスター行の一意の識別子で更新します。
この手順では、このようなマッピングを作成するための一般的な方法を概説します。次に示す詳細な手順も参照してください。
フラット・ファイル・ソースのインポート方法の詳細は、「インポート・メタデータ・ウィザードの使用」を参照してください。
ソースとしてフラット・ファイルのマッピングを使用する方法の詳細は、「フラット・ファイル演算子」を参照してください。
表演算子の使用方法の詳細は、「リポジトリ・オブジェクトにバインドする演算子の追加」を参照してください。
データ・ジェネレータ演算子の使用方法の詳細は、「データ・ジェネレータ演算子」を参照してください。
定数演算子の使用方法の詳細は、「定数演算子」を参照してください。
マッピングの構成方法の詳細は、「マッピング構成のリファレンス」を参照してください。
ダイレクト・パス・ロードを使用してマスター・ディテール・フラット・ファイルから抽出し、マスター・ディテール関係を維持する手順は、次のとおりです。
マスター・レコードとディテール・レコードで構成されたフラット・ファイル・ソースをインポートして、サンプリングします。
ファイルのサンプリング時にレコード・タイプに名前を指定する場合は、図8-10に示すように、マスター・レコードとディテール・レコードに説明的な名前を割り当てます。これによって、今後はこれらのレコードを容易に識別できます。
フラット・ファイルのマッピング演算子をマッピング・キャンバスにドラッグ・アンド・ドロップし、データの抽出元のマスター/ディテール・ファイルを指定します。
マスター・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のリポジトリ表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成し、アウトバウンド同期化を実行して後で表を定義できるようにします。
この表には、ロードするマスター・フィールドに必要なすべての列と、RECNUM値をロードするための追加の数値列が含まれている必要があります。
ディテール・レコードに対する表演算子をマッピング・キャンバスにドラッグ・アンド・ドロップします。
以前作成した既存のリポジトリ表を選択するか、属性を指定せずにバインドなしで新しい表演算子を作成し、アウトバウンド同期化を実行して後で表を定義できるようにします。
表には、ロードするディテール・フィールドに必要なすべての列と、RECNUM値をロードするための追加の数値列、および対応するマスター表の行の一意の識別子で更新する列が含まれている必要があります。
図8-14に示すように、必要なすべてのフラット・ファイル・マスター・フィールドをマスター表にマップし、ディテール・フィールドをディテール表にマップします。
図8-14に示すように、データ・ジェネレータ演算子のRECNUM属性をマスター表とディテール表のRECNUM列にマップします。
定数演算子の定数属性を追加します。
マスター行の一意の識別子列がCHARデータ型である場合は、式'*'を使用して定数属性をCHAR型にします。
マスター行の一意の識別子列が数字の場合は、式'0'を使用して定数属性をNUMBERにします。図8-13は、式プロパティが'0'に設定された定数属性を示しています。この定数によって、すべてのデータ行はロード済としてマークされます。
定数演算子の定数属性をディテール表の列にマッピングします。この列には、対応するマスター表レコードの一意の識別子が後で格納されます。
図8-14は、マッピングが完成した状態を示しています。フラット・ファイルのマスター・フィールドはマスター・ターゲット表にマッピングされ、ディテール・フィールドはディテール・ターゲット表にマッピングされ、データ・ジェネレータ演算子のRECNUM属性はマスター・ターゲット表とディテール・ターゲット表にそれぞれマッピングされ、定数属性はディテール・ターゲット表にマッピングされています。
図8-14 ダイレクト・パス・ロードを使用したマスター/ディテール・フラット・ファイルからのマッピング
ダイレクト・モード: True
エラー許可: 0
後続NULL列: True（すべての表）
マッピングを検証し、SQL*Loaderスクリプトを生成した後は、更新後のPL/SQLプロシージャを作成し、それをWarehouse Builderライブラリに追加します。
SQL*Loaderスクリプトを実行します。
更新後のPL/SQLプロシージャを実行するか、スクリプトを手動で実行して、UPDATE SQL文を実行します。
次に、生成されたSQL*Loader制御ファイルのスクリプトの例を示します。
OPTIONS ( DIRECT=TRUE,PARALLEL=FALSE, ERRORS=0, BINDSIZE=50000, ROWS=200, READSIZE=65536)
LOAD DATA
CHARACTERSET WE8MSWIN1252
INFILE 'g:\FFAS\DMR2.dat'
READBUFFERS 4
INTO TABLE "MATER_TABLE"
APPEND
REENABLE DISABLED_CONSTRAINTS
WHEN
"REC_TYPE"='P'
FIELDS
TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(
"REC_TYPE" POSITION (1) CHAR ,
"EMP_ID" CHAR ,
"ENAME" CHAR ,
"REC_NUM" RECNUM
)
INTO TABLE "DETAIL_TABLE"
APPEND
REENABLE DISABLED_CONSTRAINTS
WHEN
"REC_TYPE"='E'
FIELDS
TERMINATED BY ','
OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
(
"REC_TYPE" POSITION (1) CHAR ,
"C1" CHAR ,
"C2" CHAR ,
"C3" CHAR ,
"EMP_ID" CONSTANT '*',
"REC_NUM" RECNUM
次に、更新後のPL/SQLプロシージャの例を示します。
create or replace procedure wb_md_post_update(
master_table varchar2
,master_recnum_column varchar2
,master_unique_column varchar2
,detail_table varchar2
,detail_recnum_column varchar2
,detail_masterunique_column varchar2
,detail_just_load_condition varchar2)
IS
v_SqlStmt VARCHAR2(1000);
BEGIN
v_SqlStmt := 'UPDATE '││detail_table││' l '││
' SET l.'││detail_masterunique_column││' = (select i.'││master_unique_column││
' from '││master_table││' i '││
' WHERE i.'││master_recnum_column││' IN '││
' (select max(ii.'││master_recnum_column││') '││
' from '││master_table││' ii '││
' WHERE ii.'││master_recnum_column││' < l.'││detail_recnum_column││') '││
' ) '││
' WHERE l.'││detail_masterunique_column││' = '││''''││detail_just_load_condition││'''';
dbms_output.put_line(v_sqlStmt);
EXECUTE IMMEDIATE v_SqlStmt;
END;
/
データ・パーティションを使用すると、ターゲット・システムでデータをロードまたは削除するときのパフォーマンスが向上します。この方法は、パーティション交換ロード（PEL）と呼ばれています。
PELは、比較的少量のデータを、大量の履歴データを含むターゲットにロードする際に使用してください。ターゲットにできるものとしては、データ・ウェアハウスの表、ディメンション、キューブなどがあります。
このトピックには、次の項目が含まれます。
ターゲット・システムのパーティションを操作すると、パーティション交換ロード（PEL）を使用して、即時にデータを追加または削除できます。表が空のパーティションで交換されると、新規データが追加されます。
PELを使用すると、新規データをパーティションとしてターゲット表と交換し、ロードできます。たとえば、新規データを保持する表は、パーティションのアイデンティティをターゲット表から引き継ぎ、このパーティションはソース表のアイデンティティを引き継ぎます。この交換プロセスは、実際のデータの移動を伴わないDDL操作です。図8-15は、この例を示しています。
図8-15では、データが、ソース表Sourceから4つのパーティション（Target_P1、Target_P2、Target_P3およびTarget_P4）で構成されたターゲット表に挿入されます。新規データをTarget_P3にロードする必要がある場合、パーティション交換操作では、実際のデータを移動せずに、データ・オブジェクトの名前のみを交換します。交換後は、以前のSourceという名前がTarget_P3に変更され、このTarget_P3という名前がSourceになります。ターゲット表には、Target_P1、Target_P2、Target_P3およびTarget_P4の4つのパーティションが含まれたままです。Oracle9iで使用可能なパーティション交換操作は、データの移動なしにロード・プロセスを完了します。
パーティション交換ロードのマッピングを構成する手順は、次のとおりです。
プロジェクト・エクスプローラで、マッピングを右クリックして「構成」を選択します。
Warehouse Builderに「構成プロパティ」ダイアログが表示されます。
デフォルトでは、PELはすべてのマッピングに対して無効です。パーティション交換ロードを使用するには、「PEL有効」を選択します。
「データ・コレクション頻度」を使用して、マッピングを実行するたびに収集する新規データの量を指定します。このパラメータを設定して、年、四半期、月、日、時間、分ごとのデータの収集を指定します。これによって、パーティション数が決定されます。
収集したデータをステージングする一時表を作成する場合は、パーティション交換を実行する前に、「送る」を選択します。このパラメータを選択しないと、一時表は作成されないまま、ソース表がパーティションとしてターゲット表に直接スワップされます。詳細は、「ダイレクトPELと間接PEL」を参照してください。
「データの置換」を選択すると、ターゲット・パーティションにある既存のデータが新しく収集したデータで置換されます。このパラメータを選択しないと、ターゲット・パーティションにある既存のデータは保持されます。新規データは、空ではないパーティションに挿入されます。このパラメータは、ローカル・パーティションに影響を与え、ターゲット表のパーティションの削除またはスワップに使用できます。「TRUNCATE/INSERT」プロパティは、表レベルで設定できます。
パーティション交換によってターゲットをロードする場合は、ターゲットを間接的または直接的にロードできます。
間接PEL: デフォルトでは、パーティション交換プロセスを開始する前に、ソース・データをステージングする一時表が作成され、維持されます。たとえば、マッピングにリモート・ソースまたは複数ソースの結合が含まれている場合は、間接PELを使用します。
ダイレクトPEL: ターゲット構造に一致するマッピングのソースを設計します。たとえば、マッピングでダイレクトPELを使用すると、以前実行したマッピングでロードしたファクト表をすぐに公開できます。
PELを使用して設計したマッピングにリモート・ソースまたは複数ソースの結合が含まれている場合、Warehouse Builderでは、パーティション交換を続行する前に、ソース処理を実行し、データをステージングする必要があります。したがって、このようなマッピングは、ダイレクトPELをfalseに設定した状態で構成します。Warehouse Builderでは、ソース処理の結果を格納する一時表が透過的に作成され、維持されます。この表は、PELの実行後に削除されます。
図8-17は、2つのソースを結合し、集計を実行するマッピングを示しています。ORDER_SUMMARY表にロードされたすべての新規データが常に同じパーティションにロードされる場合は、このマッピングで間接PELを使用して、ロードのパフォーマンスを改善できます。この場合、Warehouse Builderでは、アグリゲータとORDER_SUMMARYの間に、一時表が透過的に作成されます。
Warehouse Builderでは、ターゲット表と同じ構造（列、索引、制約が同じ）を使用して、一時表が作成されます。この一時表は、パフォーマンス向上のために、パラレル直接パス・ロードINSERTを使用してロードされます。INSERTの後、Warehouse Builderでは、一時表の索引と制約がパラレルで作成されます。
ソース表がローカルで、データの品質が高い場合は、ダイレクトPELを使用します。マッピングは、ソースとターゲットが同じデータベースにあり、完全に同じ構造であるように設計する必要があります。ソースとターゲットの索引、制約、列数、列タイプおよび列の長さは、すべて同じである必要があります。
たとえば、図8-17と同じマッピングがあり、データをターゲットにロードするタイミングをより細かく制御するとします。データ量によってはロードに数時間がかかり、現状では、ターゲット表がいつ更新されるかも正確にはわかりません。
ダイレクトPELを使用してデータを即時にターゲットにロードする手順は、次のとおりです。
ソース・データを結合し、必要に応じてデータを変換し、確実に検証してステージング表にロードするマッピングを1つ設計します。このマッピングはPELを使用するように構成しないでください。
ステージング表を、別のマッピングでロードする最終ターゲットの構造に正確に一致するように設計します。たとえば、図8-17にあるステージング表のORDER_SUMMARYは、図8-18にある最終ターゲットORDER_CUBEと同じ構造である必要があります。
図8-18に示すように、ステージング表から最終ターゲットにデータをロードする2番目のマッピングを作成します。このマッピングはダイレクトPELを使用するように構成してください。
Warehouse Builderのプロセス・フロー・エディタまたはOracle Workflowを使用して、最初のマッピングの完了後に2番目のマッピングを起動します。
次の条件がtrueの場合は、スケーラビリティの高いロード・パフォーマンスのためにPELを効果的に使用できます。
表のパーティション化と表領域: ターゲット表は、1つのDATE列ごとにレンジ・パーティション化される必要があります。すべてのパーティションは同じ表領域内に作成される必要があります。すべての表は同じ表領域内に作成されます。
既存の履歴データ: ターゲット表には、大量の履歴データが格納される必要があります。PELの使用例には、ターゲットがOLTPデータベースやWebログ・ファイルからデータを毎日収集するクリック・ストリーム・アプリケーションがあります。新規データは変換され、履歴データが格納されているターゲットにロードされます。
新規データ: すべての新規データは、ターゲット表の同じパーティションにロードされる必要があります。たとえば、ターゲット表が日別に区切られている場合、日別のデータは1つのパーティションにロードされる必要があります。
ロード頻度: ロード頻度は、データ収集頻度以下である必要があります。
グローバル索引なし: ターゲット表にはグローバル索引は含めないでください。
PELのマッピングでターゲットを構成するには、次の手順を実行します。
パーティションは、実行中に自動的に作成されません。すべてのパーティションは、PELを使用する前に、「パーティションの使用方法」の説明に従って作成する必要があります。
たとえば、新規データの収集頻度に月別を選択した場合は、新規データの各月に対して、必要なすべてのパーティションを作成する必要があります。表、ディメンションまたはキューブのパーティションを作成するには、データ・オブジェクト・エディタを使用します。図8-18は、表ORDER_SUMMARYのプロパティ・インスペクタ・ウィンドウを示しています。この図は、この表に追加された6つのパーティションを示しています。
PELを使用するには、すべてのパーティションがネーミング規則に従って命名される必要があります。たとえば、2002年5月のデータを保持するパーティションの場合、そのパーティション名はY2002_Q2_M05という形式にする必要があります。
PELでパーティションを識別するには、次のいずれかの形式の名前をパーティションに指定する必要があります。
Ydddd
Ydddd_Qd
Ydddd_Qd_Mdd
Ydddd_Qd_Mdd_Ddd
Ydddd_Qd_Mdd_Ddd_Hdd
Ydddd_Qd_Mdd_Ddd_Hdd_Mdd
dには、10進数の数字が入ります。すべての文字は、大文字にする必要があります。小文字は認識されません。
各パーティションを正しく命名すると、各パーティションの「上限値」プロパティが自動的に計算されます。そうでない場合は、Warehouse BuilderでDDL文が作成されるように、上限値を各パーティションに対して手動で構成する必要があります。次に、Warehouse Builderによって作成されたDDL文の例を示します。
. . .
PARTITION A_PARTITION_NAME
VALUES LESS THAN (TO_DATE('01-06-2002','DD-MM-YYYY')),
. . .
図8-19に、「上限値」パラメータに対して自動的に生成された構成値を示します。
索引（ORDER_SUMMARY_PK_IDX）をORDER_SUMMARY表に追加します。この索引には、ORDER_DATEおよびITEM_IDの2つの列があります。次のように構成します。
「索引タイプ」パラメータをUNIQUEに設定します。
「ローカル索引」パラメータをtrueに設定します。
これで、表ORDER_SUMMARYにある一意のローカル索引のDDL文が作成できるようになります。
ローカル索引を使用すると、PELのパフォーマンスを最大限に活用できます。ローカル索引では、すべての索引が表と同じ方法でパーティション化されている必要があります。PELを使用して一時表をターゲット表にスワップすると、索引セグメントのアイデンティティもスワップされます。
ローカル索引として索引が作成されている場合、Oracleサーバーでは、パーティション・キー列を索引の最初の列にする必要があります。前述の例では、パーティション・キーはORDER_DATEで、索引ORDER_SUMMARY_PK_IDXの最初の列になります。
この手順では、USING INDEXオプションで作成したすべての主キー制約および一意キー制約を指定する必要があります。
「索引を使用」オプションを使用すると、表に制約を追加した際に索引が自動的に作成されなくなります。サーバーは、制約と同じ列リストを持つ既存の索引を検索します。したがって、主キー制約または一意キー制約は、ユーザー定義の一意のローカル索引で補足する必要があります。制約ORDER_SUMMARY_PKに必要な索引は、「手順2: 「LOCAL」オプションを使用したすべての索引の作成」で作成したORDER_SUMMARY_PK_IDXです。
Warehouse BuilderでのPELの使用には、次の制限があります。
日付パーティション・キーは1つのみ: 許容されるDATEデータ型のパーティション・キー列は1つのみです。数値パーティション・キーは、Warehouse Builderではサポートされていません。
一般的なカレンダのみ: 現在のPELメソッドは、世界中で採用されている一般的なカレンダのみをサポートしています。ユーザー定義の会計年度別や四半期別のビジネス・カレンダは、現時点ではサポートされていません。
すべての日付パーティションが同じ表領域内にあること: ターゲット（表、ディメンションまたはキューブ）のすべてのパーティションは、同じ表領域内に作成される必要があります。
すべての索引パーティションが同じ表領域内にあること: ターゲット（表、ディメンションまたはキューブ）のすべての索引は、同じ表領域内に作成される必要があります。ただし、索引とデータでは、別の表領域を使用できます。
データベース・リンクを介してリモート・ソースにアクセスするマッピングを設計できますが、大量のデータを移動するとパフォーマンスが低下する可能性があります。同じバージョンのOracle Databaseのソースとターゲット間で大量のデータを移動するマッピングについては、トランスポータブル・モジュールを使用してパフォーマンスを大幅に改善するためのオプションがあります。トランスポータブル・モジュールの使用方法は、第23章「大量データの移動」を参照してください。
