| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.4.0) E96106-04 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.4.0) E96106-04 |
|
|
前 |
次 |
マルチユーザー開発(MUD)によって、重複するコード・ベースに基づく同時開発のメカニズムが提供されます。Oracle Business Intelligenceでは、リポジトリ開発の組込みバージョニング・システムが用意されているため、複数のユーザーに加えて、メタデータのサブセットを管理するMUD環境が実現します。
次の資料も参照してください。
この章のトピックは、次のとおりです:
Oracle Business Intelligenceのマルチユーザー開発によって、エンタープライズ規模のデプロイメントにおけるアプリケーション・メタデータの作成が容易になります。
アプリケーション・メタデータは、一元化されたメタデータ・リポジトリ(RPD)ファイルに保存されます。これらのリポジトリの操作には、管理ツールを使用します。MDS XML形式のリポジトリでは、マルチユーザー開発環境を使用しません。
「マスター・リポジトリ」とは、マルチユーザー開発ディレクトリ内のリポジトリのコピーを指します。
マルチユーザー開発環境を使用する状況の例を次に示します。
複数の開発者がメタデータのサブセットで同時に作業し、他の開発者と作業が競合することなく、それらのサブセットをマスター・リポジトリにマージして戻します。たとえば、会社でデータ・ウェアハウスの実装を行った後、管理者は他の機能領域にOracle Business Intelligenceをデプロイできます。
1人の開発者がすべての開発を管理します。簡易性とパフォーマンスを確保するため、その管理者はマルチユーザー開発環境を使用して、大きいリポジトリのかわりに、より小さい塊でメタデータ・コードを管理できます。
どちらの例でも、管理者は管理ツールでリポジトリ・ファイル内にプロジェクトを作成し、そのリポジトリ・ファイルを共有ネットワーク・ディレクトリ(マルチユーザー開発ディレクトリと呼ばれます)にコピーします。開発者は、プロジェクトをチェックアウトし、変更を加えて、変更内容をマスター・リポジトリにマージできます。開発者が管理ツールを使用してプロジェクトをチェックアウトすると、バックグラウンドでファイルが自動的にコピーされ、上書きされます。管理者は設定タスクを実行する必要があります。開発者は、チェックアウト、マージおよび公開の手順の際に表示される管理ツールのメッセージに細心の注意を払う必要があります。
開発者がプロジェクトをチェックアウトしても、リポジトリ・ファイルが自動的にコピーまたは上書きされることはありません。プロジェクトのチェックアウト時に、管理ツールによって2つのファイルが新しく作成されます。一方のファイルには元のプロジェクト・データが格納され、もう一方のファイルにはプロジェクトの変更内容が格納されます。
たとえば、リポジトリ開発者がC:\multiuser開発ディレクトリのmaster.rpdからプロジェクトAをチェックアウトした場合、管理ツールによって、プロジェクトAに関連するすべてのメタデータが抽出され、開発者は新しいファイル名を指定してデータを保存するように要求されます。開発者が新しいファイル名(例: Mychanges.rpd)を選択すると、管理ツールによって次の2つのファイルが新しく作成されます。
開発者が加えた変更が格納されるMyChanges.rpdというファイル
元のプロジェクト・データが格納されているoriginalMyChanges.rpdというファイル
管理ツールは、Mychanges.rpdとoriginalChanges.rpdを比較して開発者の変更を判別します。変更点に関する情報は、マルチユーザー開発のマージ・プロセスで必要になります。
ノート:
ストレージ要件を軽減するために、Oracle Business Intelligence Enterprise Edition 12cのリポジトリは圧縮形式で保存されます。以前のリリースのRPDファイルと比べると、開いているRPDファイルや保存したRPDファイルのサイズが大幅に小さくなっています。
マルチユーザー開発は、カスタマの技術上およびビジネス上の目的を明確に理解していることが前提条件となります。
また、一貫性のあるマージおよび調整の実施など、明確に定義された開発プロセスに従い、それらのプロセスに厳密に準拠する必要があります。
次の手順では、マルチユーザー開発環境をデプロイする際の一般的なステップについて説明します。通常、最初の3つのステップは管理者が実行し、残りのステップは1人以上の開発者が実行します。「プロジェクトの作成」を参照してください。
ヒント:
できるだけ速やかに、かつ頻繁に変更をマージすることをお薦めします。頻繁なマージにより、競合解決が容易になり、マージが単純化されます。
プロジェクトを定義して、大量のメタデータを管理可能なコンポーネントに編成します。次のヒントを考慮してください。
より小さいRPDを使用して、開発作業とユニット・テストを簡素化し、それに要する時間を短縮します。
開発リソースをプロジェクト別に編成して、ワークロードを分散し、不整合と上書きを減らします。
マルチユーザー開発ディレクトリとして使用する共有ネットワーク・ディレクトリを設定します。
マスター・リポジトリをマルチユーザー開発ディレクトリにコピーします。
ローカル開発のために1つ以上のプロジェクトまたはリポジトリ全体を抽出します。
リポジトリ・オブジェクトをマージし、競合を解決します。
多くの場合、メタデータ・オブジェクトは相関性が高いため、複数の開発者が同じオブジェクトで作業している可能性があります。
通常のサブセットのリフレッシュを実行して、自分のローカルの変更を、マスターの最新バージョンとマージできます。マージ・プロセス中に構成の競合が発生した場合、開発者は修正プロセスを実行するように求められます。
変更内容をネットワークに公開します。
最終的なサブセットのリフレッシュ(マージ)は、公開ステップ中に実行されます。多数の開発者が同じオブジェクトで同時に作業できますが、一度に公開できるのは1人だけです。公開ステップ中は、リポジトリはロックされます。
ロギングおよびバックアップ機能を使用して、誤った構成や不適切な構成のポイントを特定します。
ログ・ファイルでは、マルチ開発アクティビティがコメントとともに追跡されます。
マスター・リポジトリと開発者リポジトリは、その後の参考のために、また手動ロールバックで使用できるように、自動的にバックアップされます。
プロジェクトを使用すると、メタデータを集中管理できます。
プロジェクトは、関連するメタデータを持つ論理スターのグループとして、個別に定義されたリポジトリ・メタデータのサブセットで構成されます。プロジェクトの特性は次のとおりです。
該当するビジネス・モデルの論理ファクト表によって大部分が定義されます。
抽出時に、関連する論理ディメンション表およびその他のメタデータを追加します。
1対多の論理ファクト表を含む場合があります
初期のプロジェクトについては、必要な物理表および結合の定義をすべて含むリポジトリで開始することをお薦めします。このリポジトリに、ビジネス・モデルとマッピング・レイヤーのプレースホルダとして論理ファクト表を作成し、プレゼンテーション・レイヤーのプレースホルダとしてサブジェクト・エリアを作成します。ビジネス・モデルとサブジェクト・エリアのメタデータを追加すると、個々のサブジェクト・エリアおよび論理ファクトに基づくプロジェクトを新しく作成できます。
プロジェクトを設定するときは、次のガイドラインに従います。
マスター・リポジトリにプロジェクトを作成できるのは、一度に1人だけです。
プロジェクトは、アクティブな開発の対象でなくなった場合以外は削除しないでください。
プロジェクトを作成するときは、プロジェクト名を慎重に選択します。プロジェクトの名前は変更しないでください。
プロジェクトからオブジェクトを削除するときは慎重に行い、リポジトリの抽出またはチェックアウトで問題が発生しないようにしてください。
この項では、次の項目について説明します。
プロジェクトは、プレゼンテーション・レイヤーのサブジェクト・エリアおよび関連するビジネス・モデルの論理ファクト、ディメンション、グループ、ユーザー、変数および初期化ブロックで構成できます。
開発者が担当分野のプロジェクトで作業できるようにプロジェクトを作成できます。プロジェクトを作成する主な理由は、マルチユーザー開発をサポートすることです。開発プロセスでは、各プロジェクト・グループがメタデータの異なる部分にアクセスできるようにメタデータをプロジェクトに抽出することによって、社内の異なるチーム間で作業(メタデータ)を分割できます。
ライセンス上の理由からプロジェクトを作成することもあります。新しいソフトウェア・バージョンをリリースする前に、ライセンスされたアプリケーションに関連するメタデータのみをプロジェクトに抽出し、すべての整合性と完全性が確保されるようにすることができます。アプリケーションに関連するファクト表のみを追加します。プロジェクト抽出はファクト表中心にします。これによってプロジェクト抽出の一貫性が確保され、ライセンスの管理が可能になります。
プロジェクトは、サブジェクト・エリアを表すことも、選択したサブジェクト・エリアに関連する論理ファクト表のサブセットを表すこともできます。Oracle BI管理ツールは、関連するビジネス・モデルおよび物理レイヤー・オブジェクトをプロジェクトに自動的に追加します。
複数のプロジェクトで同じオブジェクトを使用できます。ビジネス・モデル別にファクトをグループ化できるほか、1つのビジネス・モデル、または1つのビジネス・モデルの一部である論理ファクト表のセットを選択してプロジェクトで使用できます。プレゼンテーション・レイヤー・オブジェクトを明示的にプロジェクトに追加する必要があります。
プロジェクト定義には物理レイヤー・オブジェクトは含まれませんが、プロジェクト定義によってこれらのオブジェクトが特定および抽出されます。
作成されたプロジェクトはメタデータの一部となり、同じマスター・リポジトリで開発作業を実行する必要がある複数の開発者が利用できます。そのように定義されていれば、開発者がプロジェクトをチェックアウトし、新しいリポジトリ・ファイルとして保存した後、プロジェクトは一貫性のあるリポジトリとなります。
プロジェクトでは、「グループ・ファクト基準」で「サブジェクト領域」を選択するほうがより一般的です。
抽出された他のオブジェクトによって直接参照される変数や初期化ブロックなど、参照されないプロジェクトにオブジェクトを含めることができます。各オブジェクト・タイプ(変数など)に最上位ノードを追加してから、個々のオブジェクトを選択して削除できます。
認証に初期化ブロックを使用する場合は、必要な初期化ブロックを追加します。
他のオブジェクトによってまだ参照されていないものの、今後のリポジトリ開発で使用する可能性があるリポジトリ変数などのオブジェクトを含めることができます。
ユーザーおよびアプリケーション・ロールは、データ・アクセス・セキュリティ設定の一部として含めることができます。
プロジェクトの作成後に必要なサブジェクト・エリアのセットが表示されない場合は、プロジェクトを編集して、必要なサブジェクト・エリアを明示的に追加してください。
10.1.3.2より前のバージョンのOracle Business Intelligenceからリポジトリをアップグレードすると、プロジェクト定義がアップグレードされます。
アップグレード時には、プロジェクト定義、サブジェクト・エリア、ターゲット・レベル、リスト・カタログおよび既存のファクト表が、次のようにして単純なファクト表へと自動的に変換されます。
修飾キーを使用して、ターゲット・レベルに関連するプレゼンテーション列を取得します。
修飾キーを使用して、リスト・カタログに関連するプレゼンテーション列を取得します。
サブジェクト・エリアに関連するプレゼンテーション列を取得します。
すべてのプレゼンテーション列からすべての論理列を取得します。
プロジェクト内のファクト表からすべての論理列を取得します。
すべての論理列からファクト表を取得します。
アップグレード後、プロジェクトには単純なファクト表のみが含まれます。セキュリティ・オブジェクトはすべて、元のまま保持されます。
12cより前のバージョンのリポジトリ内のプロジェクトは、プレゼンテーション・レイヤー・オブジェクトを明示的に含むようにアップグレードされます。
管理者は、これらのタスクを実行して、マルチユーザー開発について準備する必要があります。
マルチユーザー開発について準備するには:
マルチユーザー開発プロジェクト専用の共有ネットワーク・ディレクトリを特定または作成します。
すべてのプロジェクトを作成したら、プロジェクトを作成したリポジトリ・ファイルを、マルチユーザー開発のマスター・リポジトリとして使用するマルチユーザー開発ディレクトリにコピーします。
管理者がマルチユーザー開発ディレクトリを特定し、リポジトリ・ファイルをコピーしたら、開発者は、マルチユーザー開発ディレクトリを指すように管理ツールを設定して、プロジェクトをチェックアウトできるようにする必要があります。
この項では、次の項目について説明します。
すべてのプロジェクトを定義した後、管理者は、マルチユーザー開発ディレクトリと呼ばれる共有ネットワーク・ディレクトリを特定または作成する必要があります。
開発者は、マスター・リポジトリにアクセスして、マルチユーザー開発ディレクトリにアップロードできます。
共有ネットワーク・ディレクトリは、マルチユーザー開発のみに使用します。マルチユーザー開発ディレクトリには、複数の開発者が管理するリポジトリのコピーが格納されます。マルチユーザー開発ディレクトリにはWindowsシステムを使用する必要があります。
開発者は、各自のコンピュータで管理ツールを設定する際に、マルチユーザー開発ディレクトリへのポインタを作成します。
重要:
管理者は、マルチユーザー開発専用の共有ネットワーク・ディレクトリを別途設定する必要があります。共有ネットワーク・ディレクトリを指定どおりに設定および使用しなかった場合、重要なリポジトリ・ファイルが誤って上書きされたり、リポジトリ・データが失われる可能性があります。
マルチユーザー開発ディレクトリを特定したら、管理者はマスター・リポジトリ・ファイルをマルチユーザー開発ディレクトリにコピーする必要があります。
このマスター・リポジトリのプロジェクトが開発者によって抽出およびダウンロードされ、変更が加えられた後、それらの変更がマスター・リポジトリにマージされます。
リポジトリをマルチユーザー開発ネットワーク・ディレクトリにコピーしたら、マルチユーザー開発環境の準備が整ったことを開発者に通知してください。
リポジトリの開発を開始した後でも、時折、マスター・リポジトリに手動で変更を加えることが必要になることがあります。この実行方法に固有の指示は、「マルチユーザー開発のトラブルシューティング」の「マスターMUDリポジトリの手動更新」を参照してください。
プロジェクトをチェックアウトする前に、マルチユーザー開発環境で作業している開発者は、ネットワーク上のマルチユーザー開発ディレクトリを指すように管理ツールのローカル・コピーを設定する必要があります。
開発者がマルチユーザー開発ディレクトリのオブジェクトをチェックアウトおよびチェックインするときは、この場所が管理ツールによって使用されます。
ノート:
ポインタが設定されるまで、管理ツールでマルチユーザー・オプションを使用することはできません。
最初、ネットワーク・ディレクトリにはマスター・リポジトリが格納されます。この場所のリポジトリは、他の開発者と共有されます。ネットワーク・ディレクトリにはその後、履歴サブセットやリポジトリ・バージョンなど、マルチユーザー開発の履歴ファイルが追加されます。マルチユーザー開発ディレクトリのファイルは手動で削除しないでください。これらのファイルは重要で、システムで使用されます。
ポインタの設定時に、開発者は「氏名」フィールドに入力することもできます。「氏名」フィールドはオプションですが、他の開発者がリポジトリをロックしているユーザーを認識できるように、このフィールドに入力することをお薦めします。
各開発者はマルチユーザー開発環境で変更をマスター・リポジトリに公開(マージ)するか、変更を廃棄することができます。
チェックアウト、リフレッシュおよび公開時には、マスター・リポジトリのコピーが開発者のローカル・リポジトリ・ディレクトリ、デフォルトでは次のORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repositoryに似た場所に、一時的にコピーされます。
この項では、次の項目について説明します。
標準のリポジトリ・ファイルに加えることができる変更のほとんどは、ローカル・リポジトリ・ファイルでもサポートされています。
開発者は、新しい論理列や新しい論理表の追加、および表定義や論理表ソースの変更を行うことができます。開発者は、同一のプロジェクトまたはリポジトリ全体についてローカルで同時に作業をしている場合があります。Oracle Business Intelligenceでは、これらの変更がマスター・リポジトリに及ぼす可能性がある影響を個々の開発者が理解していることを前提としています。たとえば、開発者がローカル・リポジトリでオブジェクトを削除した場合、ローカルで行った変更が警告メッセージなしにマージされると、その変更がマスター・リポジトリに伝播されます。
メタデータの整合性を確保するために、物理列への論理表ソースのマッピングがない場合を除き、物理列を削除しないでください。このため、マルチユーザー開発環境を使用する場合は、論理列および関連する物理列を同時に削除することはできません。まず、論理列を削除し、マージを実行する必要があります。次に、物理列を削除し、もう一度マージを実行することで、オブジェクトを安全に削除できます。
論理列タイプがMUD開発の途上で変更されると、予期しない論理列タイプが生成されます。このような場合、管理ツールの「論理列タイプ・ドキュメントの生成」ユーティリティまたはbiservergentypexmlを使用して、論理列とそれに対応するタイプのリストを生成できます。「論理列タイプの比較」utilityを後続のMUDバージョンで使用して、論理列タイプが指定したタイプに合致することを確認します。たとえば、リポジトリ・バージョン20に対して論理列タイプのリストを生成し、論理列タイプの比較ユーティリティを使用してそのリストをリポジトリ・バージョン30と比較することができます。「論理列タイプのリストの生成」および「論理列タイプの比較」を参照してください。
物理接続設定に対する変更は、マージおよび公開時にマスター・リポジトリに伝播されません。これにより、開発者は、ローカル・テスト・データ・ソースに設定を適用し、他の開発者に影響を与えることなく自分のモデル変更のユニット・テストを実行できます。
物理接続の設定に加えて、セキュリティ設定、およびデータベース機能表の変更はマルチユーザー開発のマージで保持されず、開発者によるマスター・リポジトリ内のパスワードおよびその他の重要なオブジェクトの上書きが防止されます。
ローカル・リポジトリに変更を行った後、開発者はリポジトリをアップロードし、編集済のメタデータをテストします。
ノート:
メタデータで指定されたDSNは、開発者のワークステーションに存在する必要があります。
これらのトピックでは、プロジェクトを使用して、マルチユーザー開発環境内で変更を行う方法について説明します。
Oracle管理ツールは、チェックアウト時に次のタスクを実行します。
開発者のローカル・リポジトリ・ディレクトリに、管理ツールにより、マスター・リポジトリの一時コピーが作成されます。
重要:
その名前のリポジトリがこの場所にある場合、開発者は既存のリポジトリの上書きを確認するように求められます。開発者が「はい」をクリックすると、既存のローカル・リポジトリがバックグラウンドで即座に上書きされ、新しいリポジトリが保存された後、一時マスター・リポジトリ・ファイルが自動的に削除されます。
開発者のローカル・リポジトリ・ディレクトリには、管理ツールによって、新しいリポジトリ内の選択したプロジェクトのローカル・コピー(たとえば、Metadata1.rpd)が保存されます。開発者がローカル・コピーの名前を指定します。開発者は、このファイルでメタデータを変更します。そのセッションでチェックアウトするたびに、番号が1つ増えます。
開発者のローカル・リポジトリ・ディレクトリには、管理ツールによって、接頭辞としてoriginalが追加された新しいリポジトリの2つ目のローカル・コピー(たとえば、originalMetadata1.rpd)が保存されます。
開発者が新しいリポジトリ・ファイルを保存すると、チェックアウトは完了です。開発者のローカル・リポジトリ・ディレクトリで、マスター・リポジトリの一時コピーが自動的に削除されます。
重要:
開発者がプロジェクトを選択し、ローカル・リポジトリ・ファイルに保存しても、管理ツールにより、共有ネットワーク・ドライブ上のマスター・リポジトリ内のプロジェクトがロックされることはありません。そのため、物理的には、他のユーザーが同じプロジェクトで作業することが可能です。プロジェクトがチェックアウトされているかどうかを確認するには、共有ネットワーク・ドライブ上のマルチユーザー開発ディレクトリのログ・ファイルを調べる必要があります。
このタスクでは、Oracle BI管理ツールを使用してプロジェクトをチェックアウトします。
「マルチユーザー開発チェックアウト」ダイアログは、マルチユーザー開発ディレクトリに存在するリポジトリが1つのみの場合は表示されません。
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という新しいプロジェクト抽出ファイルに置き換えられます。
ネットワークに公開。ローカル・プロジェクトの抽出またはリポジトリ全体に行った変更をマスター・リポジトリに公開します。ロックが取得され、公開ステップ中はマスター・リポジトリがロックされます。変更を公開すると、自動的に「サブセットのリフレッシュ」操作が実行され、ローカルで行った変更が、マスターの追加の変更とマージされます。その後、マージされた変更がマスター・リポジトリに公開され、ロックが解放され、ローカル・リポジトリが閉じられます。
公開を元に戻す。公開ステップ中に必須の整合性チェックが施行され、エラーが発生した場合に使用されます。公開中に整合性チェック・エラーを通知された場合、公開ステップの一部としてただちにエラーを修正することを選択できます。このプロセス中はマスター・リポジトリがロックされます。後でマスター上のロックを解放して変更を修正する必要がある場合は、「公開を元に戻す」を選択してロックを解放し、最新のサブセット抽出リポジトリに戻ります。
ローカル変更の破棄。チェックアウトしてから公開するまでの間であればいつでも、変更を破棄できます。このオプションを選択すると、作業内容を保存せずに、作業中のリポジトリが閉じます。
ノート:
このオプションを選択した場合、操作を取り消すことはできません。たとえば、確認ダイアログは表示されません。
ローカル・コンピュータでメタデータを変更し、テストした後、開発者はローカルで行った変更をマルチユーザー開発ディレクトリのマスター・リポジトリに公開する必要があります。
Oracle BIリポジトリの開発プロセスでは、3方向のマージを使用して同時開発を管理します。最初にローカル環境でメタデータのマージが実行され、次にマスター・リポジトリとマージされます。3方向のマージでは、次のリポジトリ特性に基づいてローカルの変更が特定されます。
マスターRPD
プロジェクト抽出時のベースラインRPDまたはマスターRPDのスナップショット
ローカルで開発および変更された現在のRPD
変更は、マージと調整によって管理されます。マージ・プロセスのほとんどは自動で、変更内容は競合しません。競合するメタデータ・ソースがある場合、開発者はそれらを特定して解決できます。
また、管理者は複数のリポジトリの変更内容を手動でマージしたり、特定のMUD環境外の様々なリポジトリからオブジェクトをインポートすることもできます。
変更内容は頻繁にマージしてください。マージ・プロセスは非常に複雑で、多数の変更が加えられている場合はプロセスが困難になることがあります。マージ・プロセスでオブジェクトがどのようにマージされるかの詳細は、「マージ・ルール」を参照してください。
定期的にサブセット・リポジトリをリフレッシュし、競合を早期に特定することをお薦めします。サブセットのリフレッシュによって、サブセットがマスターの最新バージョンと再度マージされ、リポジトリが開いたままになり、公開する準備ができるまで変更を続行できるようになります。
この項では、次の項目について説明します。
このトピックでは、マルチユーザー開発のマージ・プロセスについて説明します。
マージ・プロセスには次のファイルが含まれます。
オリジナルまたは現在(リフレッシュ済)のいずれかのローカル(サブセット)リポジトリ。ローカル・サブセット・リポジトリは、次のいずれかです。
サブセットのリフレッシュが実行されていない場合、オリジナルの抽出したままのプロジェクトまたはリポジトリ全体の状態が含まれています。このリポジトリの名前は「original」で始まります(例: originalDevelopment2.rpd)。
サブセットのリフレッシュを実行済である場合、サブセットのリフレッシュ中に行われた最後のマージ以降のプロジェクトまたはリポジトリ全体の状態が含まれています。このリポジトリの名前は「current」で始まります(例: currentDevelopment2.rpd)。
変更済ローカル(サブセット)リポジトリ。開発者によって変更された後の、抽出されたプロジェクトが格納されます。このバージョンは、ローカル・サブセット・リポジトリのオリジナルまたは現在のバージョンと同じ場所に保存されます。
最新のマスター・リポジトリ。最新のマスターはローカルにコピーされてマージされ、マージ後にマルチユーザー開発ディレクトリに公開されます。このマージの前に、別の開発者がファイルに変更を加えた可能性があります。
マージ中には、管理ツールによって、追加されたオブジェクトがあるかどうかがチェックされ、オブジェクトが見つかった場合は警告メッセージが表示されます。このステップでは、次の処理が実行されます。
追加されたオブジェクトに関する警告。プロジェクトをチェックアウトする開発者は、そのプロジェクトを変更し、再度チェックインすることができます。削除と変更では、プロジェクトの整合性が維持されます。ただし、オブジェクトを追加した場合は、どのプロジェクトにも属さないオブジェクトがリポジトリに挿入される可能性があります。そのため、プロジェクト関連のすべてのオブジェクトがチェックされ、新しいオブジェクトが見つかった場合は警告メッセージが表示されます。
重要:
新しく作成したメタデータをプロジェクトのその後の抽出バージョンに表示するには、マスター・リポジトリのプロジェクト定義に追加する必要があります。たとえば、開発者がプロジェクトをチェックアウトし、新しいオブジェクトを追加して、チェックインした場合、プロジェクト定義に明示的に追加するまで、新しいオブジェクトはプロジェクトの抽出バージョンに表示されません。手順については、プロジェクトの作成を参照してください。
関連オブジェクトの集約。警告メッセージでは、親オブジェクトのみが報告されます。メッセージをより便利にするために、管理ツールによってすべてのオブジェクトが集約されます。たとえば、開発者が新しいビジネス・モデルを追加した場合、ユーザーへの警告メッセージにはビジネス・モデル名のみが含まれます。表、列およびディメンションの名前はユーザーに表示されません。
開発者が変更内容をネットワークに公開すると、次の処理が行われます。
マルチユーザー開発ディレクトリのマスター・リポジトリが、開発者が加えた変更を含むリポジトリで上書きされます。
master_repository.lckファイルが削除されます。別の開発者が、変更されたプロジェクトをマスター・リポジトリからチェックアウトする、またはリポジトリ全体をチェックアウトすると、最初の開発者が加えた変更が他の開発者に公開されます。
マルチユーザー開発の公開プロセスでは、標準のリポジトリ・マージ・プロセスと同じテクノロジが使用されますが、重要な違いがいくつかあります。
マルチユーザー開発マージでは、開発者によるマスター・リポジトリのパスワードやその他の重要オブジェクトの上書きを防止するため、セキュリティ設定とデータ・ソースの変更を保持しないことが望まれます。セキュリティ設定とデータ・ソース接続の変更は、MUDマージでは保持されません。さらに、挿入(作成されたオブジェクト)が自動的に適用されます。
「マルチユーザー開発マージのマージ・ルールと動作」を参照してください。
公開プロセスが始まると、Oracle BI管理ツールによって、現在のバージョンのマスター・リポジトリがマルチユーザー開発ディレクトリから開発者のコンピュータ上のローカル・リポジトリ・ディレクトリに自動的にコピーされます。
公開される場所は、 ORACLE_INSTANCE\bifoundation\OracleBIServerComponent\coreapplication_obisn\repositoryのようになります。公開プロセスでは、ローカルおよびマルチユーザー開発ディレクトリのログ・ファイルも更新されます。これが必要なのは、開発者がプロジェクトをチェックアウトした後または最後のサブセットのリフレッシュ以降にマルチユーザー開発ディレクトリのマスター・リポジトリが変更されている可能性があるためです。
競合がなくても、リポジトリ間に違いがないことを意味するわけではありません。変更内容を公開する際に開発者が明示的に行う必要がある決定がないことを意味します。「マルチユーザー開発のマージと標準のリポジトリ・マージの違い」を参照してください。
マルチユーザー開発オプション・ファイルでMandatory Consistency CheckオプションをYesに設定することで、ネットワークへの公開ステップ中に必須の整合性チェックを強制できます。
「マルチユーザー開発オプションの設定」を参照してください。
ブランチ化は、開発のマージ・プロセスをさらに向上させる手段です。
ブランチ化によって、重複するリリースがある大規模な管理チームの効率を高めることができます。ただし、管理オーバーヘッドは増大します。
この項では、次の項目について説明します。
ブランチ化では、開発者は、他の開発者からコードを分離するためにプライベート・ブランチで作業し、変更内容をメイン・ブランチにマージして戻します。
開発チームの規模に応じて、様々な戦略を使用できます。
簡易開発モデルでは、すべての開発が1つのメイン・ブランチで行われます。この戦略の特性は次のとおりです。
緊急の修正のみに対応します。
チェックアウトが最新のコードでない可能性があります。
メインライン・ブランチの安定性のリスクが伴います。
この図は、簡易開発モデルを示しています。
小規模チーム開発モデルでは、1つのDevブランチで開発が行われ、リリース専用のMainブランチが別にあります。この戦略の特性は次のとおりです。
メインラインは正式なリリース・ブランチです。
独立したブランチで開発が行われます。
主要マイルストーンで、安定したコードがMainにマージされます。
ブランチが定期的に同期されます。
この図は、小規模チーム開発モデルを示しています。
マルチチーム、マルチリリース・モデルでは、複数のDevブランチで開発が行われ、この場合もリリース専用のMainブランチが別にあります。この戦略の特性は次のとおりです。
多様なチームにおける効率化をサポートします。
独立したブランチで開発が行われます。
主要マイルストーンで、安定したコードがMainにマージされます。
ブランチが定期的に同期されます。
この図は、マルチチーム、マルチリリース・モデルを示しています。
Oracle Business Intelligenceで複雑なブランチ化戦略を使用するには、リポジトリ・ファイルを慎重に編成するとともに、Oracle BI管理ツールでマルチユーザー設定を変更する必要があります。
必要なステップの概要を次に示します。
マルチユーザー開発リポジトリの開発履歴を表示できます。
管理ツールでマルチユーザー開発履歴を使用できるのは、リポジトリが開いておらず、管理者が共有ネットワーク・ディレクトリを設定している場合のみです。これによって、開いている関連しないリポジトリと一致しない履歴ログをユーザーが開いた場合に生じる可能性がある混乱が回避されます。
履歴を削除できるのは、マルチユーザー開発管理者のみです。
管理者は、マルチユーザー開発ディレクトリ内の特殊な非表示オプション・ファイルで定義します。「マルチユーザー開発オプションの設定」を参照してください。
MUD履歴全体を削除することも、最も古い1からn個までのバージョンを削除することもできます。中間の範囲のバージョンは削除できません。たとえば、バージョン1とバージョン2がまだある場合、管理者はバージョン3を削除することはできません。管理者がMUD履歴全体を削除した場合、新しく割り当てられるバージョン番号は再びバージョン1から始まります。
開発者がサブセットをチェックアウトした元のMUD履歴バージョンを管理者が削除し、開発者が依然としてそれで作業をしている場合、開発者はMUDディレクトリに公開できません。すべてのMUD履歴を削除すると、サブセットを現在チェックアウトしている管理者はすべてそれを公開できなくなります。管理者はMUD履歴をクリアする前に開発者に通知する必要があります。
マルチユーザー開発オプション・ファイルを作成して、マルチユーザー開発のオプションを指定できます。オプション・ファイルは、標準のWindows INI形式のテキスト・ファイルです。
オプション・ファイルには、次のプロパティおよび特性があります。
オプション・ファイルは、マルチユーザー開発ディレクトリに格納されている必要があります。このファイルの名前は、対応するマスター・リポジトリと同じですが、.opt拡張子が付きます。たとえば、\\network\MUD\sales.rpdの場合、\\network\MUD\sales.optというオプション・ファイルを作成します。
ファイルの「非表示」フラグが有効になっている必要があります。
通常、オプション・ファイルはマルチユーザー開発管理者のみが管理する必要があります。そのためには、ファイルの共有権限を変更することをお薦めします。
次に、マルチユーザー開発オプション・ファイルの例を示します。
[Options] BuildNumber = Yes Enforce Build Number = 11.1.1.7.0 Enforce MUD Protocol Version Number = 1 Prevent Rpd Upgrade = Yes Admin = admin1;admin2 Mandatory Consistency Check = Yes Equalize During Merge = Yes
明示的に設定されないオプションは、デフォルトで無効になっています。オプションを有効にするには、値をYesに設定します。オプションを無効にするには、そのオプションをオプション・ファイルから削除するか、値をNoに設定します。
この表は、マルチユーザー開発オプション・ファイルのオプションを示しています。
| オプション | 説明 |
|---|---|
BuildNumber |
Yesに設定すると、管理ツールのビルド・バージョンがMUD履歴に表示されます。 |
Enforce Build Number |
これを指定すると、指定バージョンの管理ツールと完全に一致するユーザーのみがMUD操作を実行できるようになります。「ヘルプ」メニューを選択し、「情報」を選択して管理ツールのバージョンを表示します。 このオプションは、「Enforce MUD Protocol Version Number」および「Prevent Rpd Upgrade」とともに使用します。 MUD操作に対して管理ツールのバージョン整合性を施行しない場合は、この行を削除します。 |
MUDプロトコルのバージョン番号の施行 |
これを指定すると、指定のMUDバージョンと完全に一致するユーザーのみがMUD操作を実行できるようになります。「ヘルプ」メニューを選択し、「情報」を選択してMUDバージョンを表示します。 このオプションは、「Enforce Build Number 」および「Prevent Rpd Upgrade」とともに使用します。 MUD操作に対してMUDのバージョン整合性を施行しない場合は、この行を削除します。 |
Prevent Rpd Upgrade |
これを指定すると、指定のリポジトリ・バージョンと完全に一致するユーザーのみがMUD操作を実行できるようになります。「ヘルプ」メニューを選択し、「情報」を選択してリポジトリ・バージョンを表示します。 このオプションは、「Enforce Build Number」および「Enforce MUD Protocol Version Number」とともに使用します。 MUD操作に対してリポジトリのバージョン整合性を施行しない場合は、この行を削除します。 |
Admin |
マルチユーザー開発管理者をリストします。管理者がMUD履歴を削除するには、オプション・ファイルで定義されている必要があります。 管理者は、各自の Admin=jsmith;mramirez;plafleur |
Mandatory Consistency Check |
Yesに設定すると、公開ステップで整合性チェックが実行されます。指定したリポジトリにエラーがある場合、公開を続行することはできません。 |
Equalize During Merge |
Yesに設定すると、マルチユーザー開発のマージ・プロセスでMUDのマージ中に必須の等化が実行されます。このオプションをYesに設定した場合、マージ・プロセスのパフォーマンスに影響が生じます。 |
