D マージ・ルール

この付録では、Oracle BIリポジトリのマージ・プロセスのマージ・ルールおよび動作について説明します。

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

この付録のトピックは次のとおりです。

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

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

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

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

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

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

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

• パッチ・マージは、同一リポジトリの2つのバージョン間の差分の適用時に使用されます。たとえば、開発バージョンのリポジトリから本番リポジトリへの変更の適用時や、Oracle BIアプリケーションのアップグレード時などにパッチ・マージを利用できます。詳細は、「パッチ・マージの実行」を参照してください。

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

通常、マージ・プロセスには、元のリポジトリ、変更済リポジトリおよび現行のリポジトリの3バージョンのOracle BIリポジトリが関連します。元のリポジトリとは元の未編集ファイル(親リポジトリ)ですが、変更済(修正済)リポジトリと現行リポジトリは、変更が加えられマージを必要とする2つのファイルです。現行リポジトリは、管理ツールで現在開かれているリポジトリです。

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

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

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

パッチ・マージはこれらのいずれの状況にも使用できることに留意してください。パッチ・マージでは現行ファイルを開いて元のファイルを選択してパッチを生成します。パッチを適用するには、変更済ファイルを開いて元のファイルを選択してパッチを適用します。詳細は、「パッチ・マージの実行」を参照してください。

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

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

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

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

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

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

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

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

• オブジェクト関係は、プロパティによって相互連結することができます。文字列と数値だけではなく、特定のプロパティの内部値を別のリポジトリ・オブジェクトにすることができます。このため、特定のオブジェクトに対する変更に応じて相互に関連付けられたオブジェクトの変更が発生する場合があります。

  たとえば、初期化ブロックBのデータ・ソースを接続プールからカスタム認証システムAに変更するとします。初期化ブロック・オブジェクトに対するデータ・ソース・プロパティの変更以外に、カスタム認証システム・オブジェクトでもこれに対応するプロパティの変更が発生します(カスタム認証システムAの初期化ブロック・プロパティの値が初期化ブロックBに変わったため)。

  これらのプロパティに対するデシジョンは同期させる必要があるため、初期化ブロックBのデータ・ソース・プロパティのデシジョンに「現行」を選択すると、カスタム認証システムAの初期化ブロック・プロパティのデシジョンも「現行」になります。図D-1は、この例がリポジトリ・マージ・ウィザードにどのように表示されるかを示しています。

リポジトリ・マージ・ウィザードではユーザー入力が必要なデシジョンのすべてが「マージ戦略の定義」画面に表示されます。図D-1は、「マージ戦略の定義」を示しています。

図D-1 「マージ戦略の定義」画面

「図D-1「マージ戦略の定義」画面」の説明

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

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

この項には次のトピックが含まれます:

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

• 論理表ソースのマージ

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

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

• 別名のマージ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

例D-1は、アプリケーション・ロール・オブジェクトのオブジェクト関係がどのようにマージされるかの詳細を説明しています。

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

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

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

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

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

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

表D-1 オブジェクト関係に基づくアプリケーション・ロールのマージ結果

元のリポジトリ	変更済のリポジトリ	現行リポジトリ	結果
M	M	M	N脚注1
M	M	Y	Y
M	M	N	N
M	Y	M	Y
MFoot 2	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

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

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

論理表ソースのマージ

論理表ソース・オブジェクトにおける列のマッピングのマージ方法は、特殊なルールによって制御されます。各列のマッピングが個別にマージされます。変更済または現行のリポジトリでマッピングが変更されている場合、各列で変更が保持されます。両方のリポジトリでマッピングが変更されている場合、Oracle BIサーバーはマッピングの自動マージを試行します。

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

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

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

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

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

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

プレゼンテーション列には、「名前」プロパティと「論理列名の使用」プロパティの両方があります。状況によってはこれらのプロパティが競合することがあります。たとえば表D-2は、この状況が発生する可能性があるシナリオを示しています。

表D-2 プレゼンテーション列の「名前」プロパティと「論理列名の使用」プロパティの競合

リポジトリ	プレゼンテーション列名	論理列名	論理列名の使用
元	Sales	GroupSales	いいえ
現行	Sales	Sales	はい
変更済	GroupSales	GroupSales	はい

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

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

別名のマージ

完全マージ・プロセスでは、ユーザーに別名に関するデシジョンのプロンプトは表示されません。現行リポジトリおよび変更済リポジトリの別名は自動的にマージされます。

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

次の事項にも注意が必要です。

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

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

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

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

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

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

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

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

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

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

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

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

patchrpdコマンドライン・ユーティリティで-Uおよび-Vオプションを使用すると、パッチ・プロセスを自動化できます。-Uオプションでは、競合に対してデフォルトのデシジョンを受け入れることでパッチ・プロセスを完了できます。一方、-Vオプションでは、すべてのマージの競合を記録する出力ファイルを指定でき、後でそれを検証して対処できます。

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

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

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

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

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

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

patchrpdの使用方法と構文の詳細は、「patchrpdを使用したパッチの適用」を参照してください。