| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 11g リリース1 (11.1.1) B63028-01 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 11g リリース1 (11.1.1) B63028-01 |
|
前 |
次 |
管理ツールの「リポジトリ・マージ・ウィザード」を使用する際は、高度なルールによってオブジェクトのマージ方法が決定されます。オブジェクトのマージに関する決定事項にはウィザードによって自動的に実行されるものと、「マージ戦略の定義」画面のプロンプトとして表示されるものがあります。この付録では、リポジトリ・マージ・ウィザードのマージ・ルールおよび動作の一部について説明します。
マージ方法には次の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は、「マージ戦略の定義」を示しています。
その他のルールには、実行するマージのタイプに依存するものもあります。たとえば、パッチ・マージを実行してリポジトリをアップグレードする場合に、カスタマイズした(変更済)リポジトリのセキュリティ設定とデータベース機能表の変更を保持することが必要なことがあります。一方、マルチユーザー開発(MUD)マージを実行する場合は、開発者によるマスター・リポジトリのパスワードやその他の重要オブジェクトの上書きを防止するため、セキュリティ設定とデータベース機能表の変更を保持しないことが要求されます。このため、セキュリティ設定とデーターベース機能の変更は、MUDマージでは保持されません。
マルチユーザー開発環境でセキュリティ設定やデータベース機能を変更するには、マスター・リポジトリを直接編集する必要があります。そのためには、マルチユーザー開発ディレクトリからマスター・リポジトリを削除し、オフライン・モードで編集して、元の場所に戻します。
オブジェクトのマージ方法およびプロンプトが必要な状況を制御する一般的なルールに加え、オブジェクトのタイプおよび状況によって適用される特殊なルールがあります。
この項の項目は次のとおりです。
レベル、アプリケーション・ロール、オブジェクト・パーミッションなどのオブジェクトでは、オブジェクト間の親/子関係を決定するベクター・マージ・アルゴリズムが使用されます。
ベクター・マージ・アルゴリズムを使用するオブジェクトには次のものがあります。
ディメンションのレベル、論理列に関連付けられたレベル、および子レベル
論理表示フォルダのディメンションと表
論理表ソースの集計内容
アプリケーション・ロールのメンバーシップ、パーミッションなどのセキュリティ・オブジェクト
初期化ブロックのLDAPサーバー設定および実行優先度
マージ・プロセスでは、Oracle BIサーバーによって各リポジトリのオブジェクト関係の初期状態が判別されます。たとえば、次のリストはオブジェクト・パーミッションで想定される状況、およびユーザーとアプリケーション・ロールにどのように関連するかを示しています。
M: 欠落。アプリケーション・ロール、ユーザーまたはオブジェクトがリポジトリに存在していません。
D: デフォルト。パーミッションは親アプリケーション・ロールから継承されています。
Y: あり。パーミッションがユーザーまたはアプリケーション・ロールに明示的に付与されています。
N: なし。ユーザーまたはアプリケーション・ロールに対して、パーミッションが明示的に否認されています。
リポジトリ・マージ・ウィザードでは、各リポジトリのオブジェクト・パーミッション関係の状況に応じて、マージ対象のリポジトリに適切な関係が決定されます。たとえば、次のようになります。
元のリポジトリで結果がY、変更済のリポジトリの結果がN、現行リポジトリの結果がMの場合、リポジトリ・マージ・ウィザードによって、マージするリポジトリにはNの結果が決定されます。
元のリポジトリで結果がN、変更済のリポジトリの結果がY、現行リポジトリの結果がMの場合、リポジトリ・マージ・ウィザードによって、マージするリポジトリにはYの結果が決定されます。
例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 |
|
M |
Y |
Y |
不可脚注2 |
|
M |
Y |
N |
不可 |
|
M |
N |
M |
N |
|
M |
N |
Y |
不可 |
|
M |
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となり、「論理列名を使用する」プロパティは「いいえ」に設定されます。
