| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.2.0) E82973-02 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.2.0) E82973-02 |
|
|
前へ |
次へ |
プロジェクトまたはリポジトリ全体をチェックアウトし、ローカル・リポジトリ・ファイルで変更を行ったら、各開発者は変更内容をマスター・リポジトリに公開(マージ)するか、変更内容を破棄できます。
チェックアウト、リフレッシュおよび公開時には、マスター・リポジトリのコピーが開発者のローカル・リポジトリ・ディレクトリ(通常、デフォルトではORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repository)に一時的にコピーされます。
この項では、次の項目について説明します。
標準のリポジトリ・ファイルに加えることができる変更のほとんどは、ローカル・リポジトリ・ファイルでもサポートされています。
開発者は、新しい論理列や新しい論理表の追加、および表定義や論理表ソースの変更を行うことができます。開発者は、同一のプロジェクトまたはリポジトリ全体についてローカルで同時に作業をしている場合があります。Oracle Business Intelligenceでは、これらの変更がマスター・リポジトリに及ぼす可能性がある影響を個々の開発者が理解していることを前提としています。たとえば、開発者がローカル・リポジトリでオブジェクトを削除した場合、ローカルで行った変更が警告メッセージなしにマージされると、その変更がマスター・リポジトリに伝播されます。
メタデータの整合性を確保するために、物理列への論理表ソースのマッピングがない場合を除き、物理列を削除しないでください。このため、マルチユーザー開発環境を使用する場合は、論理列および関連する物理列を同時に削除することはできません。まず、論理列を削除し、マージを実行する必要があります。次に、物理列を削除し、もう一度マージを実行することで、オブジェクトを安全に削除できます。
論理列タイプがMUD開発の途上で変更されると、予期しない論理列タイプが生成されます。このような場合、管理ツールの「論理列タイプ・ドキュメントの生成」ユーティリティまたはbiservergentypexmlを使用して、論理列とそれに対応するタイプのリストを生成できます。「論理列タイプの比較」utilityを後続のMUDバージョンで使用して、論理列タイプが指定したタイプに合致することを確認します。たとえば、リポジトリ・バージョン20に対して論理列タイプのリストを生成し、論理列タイプの比較ユーティリティを使用してそのリストをリポジトリ・バージョン30と比較することができます。「論理列タイプのリストの生成」および「論理列タイプの比較」を参照してください。
物理接続設定に対する変更は、マージおよび公開時にマスター・リポジトリに伝播されません。これにより、開発者は、ローカル・テスト・データ・ソースに設定を適用し、他の開発者に影響を与えることなく自分のモデル変更のユニット・テストを実行できます。
物理接続の設定に加えて、セキュリティ設定、およびデータベース機能表の変更はマルチユーザー開発のマージで保持されず、開発者によるマスター・リポジトリ内のパスワードおよびその他の重要なオブジェクトの上書きが防止されます。
ローカル・リポジトリに変更を行った後、開発者はリポジトリをアップロードし、編集済のメタデータをテストします。
注意:
メタデータで指定されたDSNは、開発者のワークステーションに存在する必要があります。
これらのトピックでは、プロジェクトを使用して、マルチユーザー開発環境内で変更を行う方法について説明します。
Oracle管理ツールは、チェックアウト時に次のタスクを実行します。
管理ツールのタスクには次のものがあります。
開発者のローカル・リポジトリ・ディレクトリに、管理ツールにより、マスター・リポジトリの一時コピーが作成されます。
注意:
その名前のリポジトリがこの場所にある場合、開発者は既存のリポジトリの上書きを確認するように求められます。開発者が「はい」をクリックすると、既存のローカル・リポジトリがバックグラウンドで即座に上書きされ、新しいリポジトリが保存された後、一時マスター・リポジトリ・ファイルが自動的に削除されます。
開発者のローカル・リポジトリ・ディレクトリには、管理ツールによって、新しいリポジトリ内の選択したプロジェクトのローカル・コピー(たとえば、Metadata1.rpd)が保存されます。開発者がローカル・コピーの名前を指定します。開発者は、このファイルでメタデータを変更します。そのセッションでチェックアウトするたびに、番号が増えます。
開発者のローカル・リポジトリ・ディレクトリには、管理ツールによって、接頭辞としてoriginalが追加された新しいリポジトリの2つ目のローカル・コピー(たとえば、originalMetadata1.rpd)が保存されます。
開発者が新しいリポジトリ・ファイルを保存すると、チェックアウトは完了です。開発者のローカル・リポジトリ・ディレクトリで、マスター・リポジトリの一時コピーが自動的に削除されます。
注意:
開発者がプロジェクトを選択し、ローカル・リポジトリ・ファイルに保存しても、管理ツールにより、共有ネットワーク・ドライブ上のマスター・リポジトリ内のプロジェクトがロックされることはありません。そのため、物理的には、他のユーザーが同じプロジェクトで作業することが可能です。プロジェクトがチェックアウトされているかどうかを確認するには、共有ネットワーク・ドライブ上のマルチユーザー開発ディレクトリのログ・ファイルを調べる必要があります。
Oracle BIサーバーのextractprojectsユーティリティを使用すると、MUD環境のオーバーヘッドなしで特定のリポジトリからプロジェクトを切り取ることができます。
extractprojectsユーティリティは、WindowsシステムとUNIXシステムで使用できます。extractprojectsは、RPD形式のバイナリ・リポジトリでのみ使用できます。
extractprojectsユーティリティでは、指定したプロジェクトのセットを含むRPDファイルが生成されます。元のリポジトリ・ファイルの保存やMUDディレクトリでのチェックアウトとしての抽出の追跡など、管理ツールを使用してプロジェクトをチェックアウトした場合に実行される作業は実行されません。
extractprojectsユーティリティは、次のディレクトリにあります。
BI_DOMAIN/bitools/bin
構文
extractprojectsユーティリティは次のパラメータを取ります。
extractprojects -B base_repository_name -O output_repository_name {-I input_project_name} [-P repository_password] [-L] [-E project_list_file_name]
変数は、次のとおりです。
base_repository_nameは、プロジェクトの抽出元のリポジトリの名前とパスです。
output_repository_nameは、ユーティリティによって生成されたリポジトリの名前とパスです。
input_project_nameは、抽出するプロジェクトの名前です。複数のプロジェクトを入力できます。各プロジェクト・エントリの先頭に-Iを付けてください(例: -I project1 -I project2)。プロジェクト名にスペースが含まれる場合は、二重引用符で囲みます(例: "project 1")。
repository_password引数はオプションです。パスワード引数を指定しなかった場合、コマンドの実行時にパスワードを入力するように求められます。セキュリティ侵害のリスクを最小化するために、パスワード引数をコマンドラインまたはスクリプトで入力しないことをお薦めします。パスワード引数は下位互換性のためにのみサポートされています。スクリプト上の理由から、標準入力によってパスワードを指定できます。
- Lを指定すると、ロギングが有効になります。ロギングを有効にすると、ProjExtr.YYYYMMDD.HHMMSS.xmlという形式のログ・ファイルがOracle BIサーバーのロギング・ディレクトリに作成されます。次に例を示します。
ORACLE_INSTANCE/diagnostics/logs/OracleBIServerComponent/coreapplication_obisn/ProjExtr.20100616.082904.xml
-Eはオプションの引数であり、リポジトリに含まれているすべてのプロジェクトのリストをファイルに印刷できます。このオプションの後でproject_list_file_nameを指定して、プロジェクト名を格納するファイル名と場所を指定します。-Eは-Bおよび-Pのみとともに使用され、実際にはプロジェクト抽出を実行しません。
-Uおよび-Fは構文リストに表示されますが、社内使用専用です。
例
次の例では、my_repos.rpdからproject1とproject2が抽出され、extract_repos.rpdというリポジトリが新しく作成されます。
extractprojects -B my_repos.rpd -O extract_repos.rpd -I project1 -I project2 Give password: my_rpd_password
注意:
入力ファイルと出力ファイルが別のディレクトリにある場合は、両方のファイルについて、リポジトリ・ファイルへの完全なパス名を指定してください。
「サブセットのリフレッシュ」オプションを使用して、マスター・リポジトリに行った変更で、ローカル・プロジェクトの抽出を更新します。
このオプションでは、最新の変更もローカル・プロジェクトの抽出とマージされます。このタスクは、開発セッションの最後に最終変更を公開する前に、開発中の段階的な手順として実行します。
ローカル・プロジェクトの抽出を頻繁にリフレッシュすることをお薦めします。それにより、マージ中の競合を段階的に特定し処理できます。一度にマージする変更が多すぎる場合、競合に対して適切なマージの決定をすることが難しくなり、エラーが発生しやすくなります。
マルチユーザー開発環境内でリポジトリへの変更をおこなう場合、推奨される方法はプロジェクトの使用です。
同時にリポジトリ全体にアクセスして変更をするYou might encounter situations during which you want to make changes that involve you accessing the entire repository at one time.
システム・パフォーマンスが低下することがあるため、この方法は必要な場合にのみ使用してください。特に大きなリポジトリのマージの最中に低下します。
「マルチユーザー」メニューから、多数のタスクを実行できます。
ローカル開発者は変更を加え、変更内容をテストして、リポジトリをローカルに保存した後、次の作業を実行できます。
元との比較。抽出された作業用のローカル・リポジトリを、抽出された元のリポジトリと比較します。このオプションを選択すると、「リポジトリの比較」ダイアログが開き、抽出された作業用のリポジトリに対してプロジェクトまたはリポジトリ全体のチェックアウト以降に行ったすべての変更が表示されます。
サブセットのリフレッシュ。マスター・リポジトリに行った変更でのローカル・プロジェクトの抽出をリフレッシュします。マスターの変更が、ローカルで行った変更とマージされます。
マスター・リポジトリに変更を行った場合、古いプロジェクト抽出ファイル(originalfilename.rpd)が、currentfilename.rpdという新しいプロジェクト抽出ファイルに置き換えられます。
ネットワークに公開。ローカル・プロジェクトの抽出またはリポジトリ全体に行った変更をマスター・リポジトリに公開します。ロックが取得され、公開手順中はマスター・リポジトリがロックされます。変更を公開すると、自動的に「サブセットのリフレッシュ」操作が実行され、ローカルで行った変更が、マスターの追加の変更とマージされます。その後、マージされた変更がマスター・リポジトリに公開され、ロックが解放され、ローカル・リポジトリが閉じられます。
公開を元に戻す。公開手順中に必須の整合性チェックが施行され、エラーが発生した場合に使用されます。公開中に整合性チェック・エラーを通知された場合、公開手順の一部としてただちにエラーを修正することを選択できます。このプロセス中はマスター・リポジトリがロックされます。後でマスター上のロックを解放して変更を修正する必要がある場合は、「公開を元に戻す」を選択してロックを解放し、最新のサブセット抽出リポジトリに戻ります。
ローカル変更の破棄。チェックアウトしてから公開するまでの間であればいつでも、変更を破棄できます。このオプションを選択すると、作業内容を保存せずに、作業中のリポジトリが閉じます。
注意:
このオプションを選択した場合、操作を取り消すことはできません。たとえば、確認ダイアログは表示されません。
