プライマリ・コンテンツに移動
Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド
12c (12.2.1.3.0)
E90110-03
目次へ移動
目次

前
次

C マージ・ルール

Oracle BIリポジトリのマージ・プロセスのマージ・ルールおよび動作について学習できます。

管理ツールのリポジトリ・マージ・ウィザードやpatchrpdユーティリティを使用したり、変更をマルチユーザー開発環境のネットワークに公開すると、高度なルールによってオブジェクトのマージ方法が決定されます。オブジェクトのマージに関するデシジョンにはシステムによって自動的に実行されるものと、「マージ戦略の定義」画面のプロンプトとして表示されるものがあります。

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

マージ・プロセスについて

Oracle BIリポジトリには、3つのタイプのマージがあります。

  • 完全なマージ(アップグレード・マージとも呼ばれる)は、2つの異なるリポジトリをマージする必要がある際に、開発プロセス中に使用されます。管理ツール は、3方向マージ機能を提供します。この機能を使用すると、両方とも3番目の元のリポジトリから派生した2つのリポジトリをマージできます。完全マージは、リポジトリ間でのオブジェクトのインポートにも使用できます。「完全なリポジトリ・マージの実行」を参照してください。

  • パッチ・マージは、同じリポジトリの2つのバージョンの間の差を適用するときに使用されます。たとえば、開発バージョンのリポジトリから本番リポジトリに変更を適用するため、またはOracle BI Applicationsのリポジトリをアップグレードするためにパッチ・マージを使用する必要があります。「パッチ・マージの実行」を参照してください。

  • マルチユーザー開発マージは、マルチユーザー開発環境を使用して変更をプロジェクトに公開する際に使用されます。「マルチユーザー開発のマージ・プロセスについて」を参照してください。

マージ・プロセスには、次の3つのバージョンのOracle Business Intelligenceリポジトリが関与しています。元のリポジトリ、変更済リポジトリおよび現行のリポジトリです。元のリポジトリとは元の変更されていないファイル(親リポジトリ)ですが、変更済(修正済)リポジトリと現行リポジトリは、マージする2つの変更されたファイルです。現行のリポジトリは、管理ツールで現在開いているリポジトリです。

元のリポジトリ、修正済リポジトリおよび現行のリポジトリは、状況に応じて異なるものを意味する場合があります。例:

  • 開発から本番へのシナリオ。元の親ファイル、開発の最新変更が組み込まれた現行ファイル、および元のファイルのデプロイ済コピーである変更済ファイルが存在します。

  • Oracle BI Applicationsのリポジトリ・アップグレード・シナリオ。現行ファイルはOracleから出荷された最新バージョンのリポジトリで、元のファイルはOracleから出荷された元のリポジトリです。変更済ファイルは元のファイルにユーザーによる変更が加えられたものです。

パッチ・マージはこれらのいずれの状況にも使用できます。パッチ・マージでは現行ファイルを開いて元のファイルを選択してパッチを生成します。パッチを適用するには、変更済ファイルを開いて元のファイルを選択してパッチを適用します。

完全なマージのマージ・ルールと動作

完全なマージに適用されるルールについて説明します。

完全なマージの場合、次のルールが適用されます。

  • 変更は変更済リポジトリで保持されることが想定され、たとえば、変更済リポジトリでオブジェクトの追加や削除を実行する場合は、そのオブジェクトの追加や削除の動作がプロンプトなしで実行されます。

  • 現行リポジトリでオブジェクトの追加や削除が実行される場合は、リポジトリ・マージ・ウィザードによって変更を保持するかどうかが確認されます。

    リポジトリ・マージ・ウィザードは、問合せへの対応に必要なオブジェクトの最小セットがあることを保証しようとします。マージの際は、マージ後のリポジトリには不要なオブジェクトが、現行リポジトリから導入された可能性があります。望ましくないオブジェクトの問題に対処するため、リポジトリ・マージ・ウィザードでは、現行リポジトリの新しいプレゼンテーション・レイヤー・オブジェクトがマージ後の最終成果物に必要であるかどうかが確認されます。新しいプレゼンテーション・オブジェクトを保持することを選択した場合、論理的および物理的な依存オブジェクトも追加されます。新しいプレゼンテーション・オブジェクトを保持しないことを選択した場合、論理的および物理的な依存オブジェクトは保持されません。リポジトリ・マージ・ウィザードは、これらのオブジェクトを廃棄してマージ後のリポジトリに使用されないオブジェクトが移入されないことを保証します。

  • 両方のリポジトリでオブジェクトの追加や削除が行われる場合、オブジェクトの追加や削除がプロンプトなしで実行されます。同じオブジェクトが追加されそのプロパティの相違がわずかである場合は、リポジトリ・マージ・ウィザードによってどちらのバージョンのプロパティを保持するかが確認されます。

  • オブジェクトが現行リポジトリでのみ、または変更済リポジトリでのみ変更されている場合、その変更は保持されます。同じオブジェクトが現行リポジトリと変更済リポジトリの双方で変更され、変更内容が異なる場合はマージの競合が発生します。競合が発生した場合、リポジトリ・マージ・ウィザードから、保持する変更を選択するように要求されます。

  • 付随するオブジェクト関係によっては、特定のオブジェクトに関するデシジョンが、デシジョン・セット全体に影響する場合があります。たとえば、現行リポジトリに追加されたプレゼンテーション列を保持することにした場合、関連付けられているプレゼンテーション表およびサブジェクト領域は、プレゼンテーション列のベースとなった論理列、物理列、およびその他の関連付けられたオブジェクトとともに、マージ・プロセスで保持されます。現行リポジトリに追加されたサブジェクト領域を保持しないことにした場合は、関連付けられているオブジェクトを保持するかどうかを選択するように求められることはありません。結合の追加には元表の追加が必要な場合がありますが、式の変更では物理列が追加される場合があります。

  • オブジェクト関係はそのプロパティ(文字列や数値など)、および他のリポジトリ・オブジェクトを表すプロパティの内部値によって相互に接続します。特定のオブジェクトに対する変更に応じて相互に関連付けられたオブジェクトの変更が発生する場合があります。たとえば、初期化ブロックBのデータ・ソースを接続プールからカスタム・オーセンティケータAに変更するとします。カスタム・オーセンティケータAの初期化ブロック・プロパティの値が初期化ブロックBに変わったため、初期化ブロック・オブジェクトに対するデータ・ソース・プロパティの変更以外に、カスタム・オーセンティケータ・オブジェクトでもこれに対応するプロパティの変更が発生します。マージ・プロセスではこれらのプロパティについて同期したデシジョンが必要です。初期化ブロックBのデータ・ソース・プロパティのデシジョンに「現行」を選択すると、カスタム・オーセンティケータAの初期化ブロック・プロパティのデシジョンも「現行」になります。

論理表ソースおよびその他のオブジェクトの特殊なマージ・アルゴリズム

特定のオブジェクトのタイプおよび状況で適用される特殊なルールがあり、それらはオブジェクトのマージ方法およびプロンプトが必要な状況を制御する一般的なルールに追加されるものです。

この項では、次の項目について説明します。

ベクター・マージ・アルゴリズムを使用するオブジェクトのマージ

レベル、アプリケーション・ロール、オブジェクト・パーミッションなどのオブジェクトでは、オブジェクト間の親/子関係を決定するベクター・マージ・アルゴリズムが使用されます。

ベクター・マージ・アルゴリズムを使用するオブジェクトには次のものがあります。

  • ディメンションのレベル、論理列に関連付けられたレベル、および子レベル

  • 論理表示フォルダのディメンションと表

  • 論理表ソースの集計内容

  • アプリケーション・ロールのメンバーシップ、パーミッションなどのセキュリティ・オブジェクト

  • 初期化ブロックのLDAPサーバー設定および実行優先度

マージ・プロセスでは、Oracle BIサーバーによって各リポジトリのオブジェクト関係の初期状態が判別されます。たとえば、次のリストはオブジェクト・パーミッションで想定される状況、およびユーザーとアプリケーション・ロールにどのように関連するかを示しています。

  • M - 欠落。アプリケーション・ロール、ユーザーまたはオブジェクトがリポジトリに存在していません。

  • D - デフォルト。パーミッションは親アプリケーション・ロールから継承されています。

  • Y - あり。パーミッションがユーザーまたはアプリケーション・ロールに明示的に付与されています。

  • N - なし。ユーザーまたはアプリケーション・ロールに対して、パーミッションが明示的に否認されています。

リポジトリ・マージ・ウィザードでは、各リポジトリのオブジェクト・パーミッション関係の状況に応じて、マージ対象のリポジトリに適切な関係が決定されます。例:

  • 元のリポジトリで結果がY、変更済のリポジトリの結果がN、現行リポジトリの結果がMの場合、リポジトリ・マージ・ウィザードによって、マージするリポジトリにはNの結果が決定されます。

  • 元のリポジトリで結果がN、変更済のリポジトリの結果がY、現行リポジトリの結果がMの場合、リポジトリ・マージ・ウィザードによって、マージするリポジトリにはYの結果が決定されます。

ベクター・マージの例: アプリケーション・ロールのマージ

次のリストは、ユーザーおよびアプリケーション・ロール関係で発生しうる様々な状況を示しています。

  • M - 欠落。アプリケーション・ロールまたはユーザーがリポジトリに存在していません。

  • Y - あり。アプリケーション・ロールまたはユーザーがアプリケーション・ロールに属しています。

  • N - なし。アプリケーション・ロールまたはユーザーはアプリケーション・ロールのメンバーではありません。

この表は、マージするリポジトリ内のオブジェクトの各種の関係のマージ結果を示しています。

元のリポジトリ 変更済のリポジトリ 現行リポジトリ 結果

M

M

M

N

この状況は、元のリポジトリにアプリケーション・ロールもユーザーも存在せず、変更済リポジトリにユーザーが存在し、現行リポジトリにアプリケーション・ロールが存在する場合に発生する可能性があります。この場合、メンバーシップはないとみなされます。

M

M

Y

Y

M

M

N

N

M

Y

M

Y

M

この場合のオリジナルにMが含まれていると、ユーザーまたはアプリケーション・ロールのいずれかが存在しないことを意味します。欠落したオブジェクトが双方で追加されても、同じオブジェクトであると見なすことはできません

Y

Y

Y

M

Y

N

Y

M

N

M

N

M

N

Y

Y

M

N

N

N

Y

M

M

Y

Y

M

Y

Y

Y

M

N

N

Y

Y

M

Y

Y

Y

Y

Y

Y

Y

N

N

Y

N

M

N

Y

N

Y

N

Y

N

N

N

N

M

M

N

N

M

Y

Y

N

M

N

N

N

Y

M

Y

N

Y

Y

Y

N

Y

N

Y

N

N

M

N

N

N

Y

Y

N

N

N

N

論理表ソースのマージ

論理表ソース・オブジェクトにおける列のマッピングのマージ方法は、特殊なルールによって制御されます。各列のマッピングが個別にマージされます。

変更済または現行のリポジトリでマッピングが変更されている場合、各列で変更が保持されます。両方のリポジトリでマッピングが変更されている場合、Oracle BIサーバーはマッピングの自動マージを試行します。

列の削除はマッピングの変更とはみなされません。特定の列が変更後のリポジトリに存在しない場合、現行リポジトリのマッピングが使用されます。

集計内容に相違がある場合、レベル別で指定された集計内容が優先されます。つまり、集計内容がレベル別のリポジトリと、列別のリポジトリがある場合、レベル別の集計内容が保持されます。

セキュリティ・フィルタのマージ

1つのリポジトリでのみアプリケーション・ロールのフィルタが変更されている場合はその変更が保持されます。両方のリポジトリでフィルタが変更されている場合、Oracle BIサーバーではフィルタの自動マージが試行されます。

特定のフィルタ(プレゼンテーション列など)のマージに必要なオブジェクトがあり、そのオブジェクトが存在していない場合、当該のフィルタは無効と見なされマージ後のリポジトリには表示されません。このルールは変数には適用されません。特定のフィルタのマージに必要な変数がある場合、Oracle BIサーバーではマージ後のリポジトリでその変数が保持されることが保証されます。

プレゼンテーション列に対して「論理列の使用」プロパティを推論する

プレゼンテーション列には、「名前」プロパティと「論理列名の使用」プロパティの両方があります。

状況によってはこれらのプロパティが競合することがあります。たとえば、この表はこの状況が発生する可能性があるシナリオを示しています。

リポジトリ プレゼンテーション列名 論理列名 論理列名の使用

Sales

GroupSales

いいえ

現行

Sales

Sales

はい

変更済

GroupSales

GroupSales

はい

この表の通常のオブジェクト・マージ・ルールが適用された場合、マージ後のリポジトリには、GroupSalesというプレゼンテーション列とSalesという論理列が存在し、「論理列名の使用」プロパティが「はい」に設定されます。プレゼンテーション列の名前が論理列の名前と異なるため、この結果は不適切になります。

このような状況を回避するため、Oracle BIサーバーは、「論理列名の使用」プロパティの値を推論します。この推論ロジックを使用することで、マージ後のリポジトリでは、プレゼンテーション列がGroupSales、論理列がSalesとなり、「論理列名の使用」プロパティは「いいえ」に設定されます。

別名のマージ

完全マージ・プロセスでは、ユーザーに別名に関するデシジョンのプロンプトは表示されません。

現行リポジトリおよび変更済リポジトリの別名は自動的にマージされます。

ただし、マルチユーザー開発マージでは、現行リポジトリの別名を保持するか、変更済リポジトリの別名を保持するか、両方のリポジトリの別名を保持するため、候補をマージするかの選択が求められます。

  • マージ・プロセスの結果オブジェクト名が変更された場合、以前の名前は別名として追加されます。

  • プレゼンテーション・オブジェクトに関連付けられていない別名は削除されます。

マルチユーザー開発マージのマージ・ルールと動作

マルチユーザー開発マージのルールは、完全なマージのルールにとてもよく似ていますが、重要な違いがあります。

  • MUDのマージを実行して、開発者がマスター・リポジトリ内のパスワードおよびその他の重要なオブジェクトを上書きできないようにしても、セキュリティ設定に対する変更は保持されません。

  • マスター・リポジトリ内のデータベースおよび接続プールのプロパティは、開発者のコンピュータ上の同じプロパティより優先されます。マルチユーザー開発のマージでは、メッセージを表示せずにこの優先順位が適用されます。

  • 挿入(作成されたオブジェクト)が自動的に適用されます。マスター・リポジトリのサブセットが元のリポジトリとして使用されるため、マスター・リポジトリのほとんどのオブジェクトが新しいように見えます。その結果、不要なメッセージが表示されることになり、開発者は手動で承認する必要があります。そのため、マルチユーザー開発のマージでは、メッセージを表示せずに新しいオブジェクトが作成されます。

  • マルチユーザー開発のマージでは、挿入ではないものの、自動挿入のために解決された競合が、メッセージを表示せずに適用されます。

マルチユーザー開発環境でセキュリティ設定やデータベース機能を変更するには、マスター・リポジトリを直接編集する必要があります。そのためには、マルチユーザー開発ディレクトリからマスター・リポジトリを削除し、オフライン・モードで編集して、元の場所に戻します。

パッチ・マージのマージ・ルールと動作

パッチ・マージのルールも、完全なマージのルールに似ていますが、オブジェクトの削除の動作が異なります。

たとえば、オブジェクトを現行のリポジトリで削除する場合、パッチ・マージのデフォルト動作では、オブジェクトを破棄するか保持するかを常にユーザーに確認します。これは、完全なマージでは異なっており、多くの場合、プロンプトが表示されることなく現行のリポジトリからの削除が受け入れられます。

パッチ・プロセスを自動化するためのPatchrpdの使用方法

patchrpdコマンドライン・ユーティリティで-Uおよび-Vオプションを使用すると、パッチ・プロセスを自動化できます。

-Uオプションでは、競合に対してデフォルトのデシジョンを受け入れることでパッチ・プロセスを完了できます。一方、-Vオプションでは、すべてのマージの競合を記録する出力ファイルを指定でき、後でそれを検証して対処できます。

patchrpdを使用してパッチ・プロセスを自動化するには、次のガイドラインに従ってください。

  • デフォルト・ルールを使用してパッチを自動的に適用します。patchrpdに-Uオプションを含めて、競合に対して常にデフォルトのデシジョンが適用されるようにします。たとえば、両方のリポジトリ(現行と修正済)でオブジェクトの名前が変更されている場合、デフォルトのデシジョンは、修正済リポジトリの名前を保持し、ユーザーによるカスタマイズを上書きしないようにすることです。このパラメータを含めない場合、競合が検出されると、patchrpdによって警告が表示されて終了します。

  • 出力デシジョン・ファイルに競合を記録します。-Vオプションを含めると、patchrpdによって、マージによるすべての競合を示すデシジョン・ファイルが生成されます。デシジョン・ファイルにはデシジョンがリストされます。これは、マージが管理ツールで実行されたのであれば、マージ・ウィザードの「マージ戦略の定義」画面に表示されるものです。デシジョン・ファイルは、ユーザーの入力によって影響を受ける可能性があるすべてのアイテムの記録を提供します。

  • デシジョン・ファイルを変更して結果を変更します。patchrpdを実行した後、結果として得られるリポジトリに変更を行う方法は2つあります。

    • マージ・ウィザードの「マージ戦略の定義」画面の「デシジョン・ファイルのロード」ボタンを使用して、マージ・デシジョンをロードし、必要に応じてデシジョンを変更します。その後、管理ツールでマージを完了できます。かわりに、ファイルへのデシジョンの保存ボタンを使用して、修正済のデシジョン・ファイルを保存し、その後、-Dオプションを使用してそのデシジョン・ファイルを入力として使用してpatchrpdを再実行し、新しいデシジョンでパッチを再適用できます。

    • そのデシジョン・ファイルを手動で編集し、その後、-Dオプションを使用してそのデシジョン・ファイルを入力として使用してpatchrpdを再実行し、新しいデシジョンでパッチを再適用できます。

patchrpdを設定して管理ツールのマージ機能と一致させるには、次のガイドラインに従ってください。

  • 管理ツールの完全なマージ: -Aオプション(リポジトリ全体の変更の適用)および-Mオプション(アップグレード・モードの使用)を使用します。

  • サブセット・パッチを使用するオプションを選択した管理ツールのパッチ・マージ - -Mオプションを含めないでください。-Mオプションを除くと、デフォルトのマージ・モードがパッチに設定されることを意味します。

  • サブセット・パッチを使用するオプションを選択しない管理ツールのパッチ・マージ - -Aオプションを使用し、-Mオプションを含めないでください。-Mオプションを除くと、デフォルトのマージ・モードがパッチに設定されることを意味します。

「patchrpdを使用したパッチの適用」を参照してください。