| 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 |
|
|
前へ |
次へ |
架空の会社の例の次のフェーズで、SallyとScottはSalesイニシアティブ・フェーズIIIの開発を開始します。
一方、Helen RoweはHRイニシアティブの最初のフェーズを構築して、新しい独立のセマンティック・モデルを本番に配置します。
次の項では、フェーズIIIの開発について説明します。
架空の会社の例で、Helenのアプリケーションには、給与や医療情報などの機密性の高い個人情報が保持されます。
一方、Salesアプリケーションには、法的に機密性の高い財務情報が含まれます。企業のセキュリティ・コンプライアンスにより、これらの2つのチームは相互のデータまたはメタデータを参照することはできません。また、この2つのチームには、時間ディメンションなどの一般的なディメンションを除いて共有できるコンテンツはほとんどありません。この2つのチームのビジネス・ドライバ、予算およびスケジュールも異なります。
これらの理由により、Eden Corporation社の管理委員会は、リポジトリで独立したセマンティック・モデル(1つは販売部用、もう1つは人事部用)を使用することを決定しました。この手法では、共有オブジェクトがないことと、それらのコンテンツに矛盾が発生しないことを確実にするために2つのチームが必要です。これを確実にする最も簡単な方法は、トップレベル・オブジェクトの名前が競合しないようにすることです。変数およびアプリケーション・ロールも異なるものにする必要があります。
ヒント:
ある管理委員会では、それぞれのトップレベル・オブジェクトの名前の前に各セマンティック・モデルに固有の接頭辞(販売部には「S_」、HRには「H_」など)を付けることを開発者に指示することで、トップレベル・オブジェクトが競合しないようにしています。このプラクティスにより、どのオブジェクトがどちらの組織に属しているかわかりやすくなります。別の委員会では、トップレベル・オブジェクトのマスター・リストを保持し、競合が発生しないように確認するためにトップレベル・オブジェクトの名前を提出することを新しいアプリケーションに求めたいと考えています。また、2方向マージでは、上書きによりコンテンツを破損したり予期しないオブジェクト名の変更が発生する前に、誤りを捕捉できます。
別のセキュリティ要件は、正しい開発者のみがそれぞれのリポジトリにアクセスできるように個々のMUDディレクトリにセキュリティを適用する必要があるということです。SallyとScottはSales MUDディレクトリから参照およびチェックアウトのみ実行できます。またHelenはHR MUDディレクトリから参照およびチェックアウトのみ実行できます。Mainディレクトリは本番に実際に存在するマージされたマスターを保持する必要があるので存在し続けますが、Adamのみがそのディレクトリを参照および変更する権限を持ちます。
Eden Corporation社の最後のセキュリティ要件は、独立のセマンティック・モデル開発者がマージ後にオンライン・モードで稼働中のリポジトリにアクセスする機能を無効にすることです。リポジトリ・パスワードは1つしかないので、リポジトリのパスワードおよびアクセス権を持つ開発者はオフライン・モードでそのすべてのコンテンツを参照および変更できます。ただし、オンライン・モードでは、開発者はOracle BIサーバーにログオンするためにデータ・アクセス・ユーザー名とパスワードも必要です。このセキュリティ要件を施行するために、Adamは開発者が本番にログオンしたり、このように本番をテストする権限を与えないようにする必要があります。また、本番運用スタッフはリポジトリ・パスワードを自分たちしか知らないパスワードに変更できますが、リポジトリ・パスワードは管理ツールを使用して変更されるため、Windowsコンピュータでこのタスクを実行する必要があります。
Helenはセキュアな独立のセマンティック・モデルで1人で作業しているので、まだプロジェクトをチェックアウトする必要はありません。ローカル・コンピュータ上の新しいブランク・リポジトリからコンテンツの構築を開始する必要があります。
彼女は、コンテンツの構築およびユニット・テストを通常の手順で段階的に実行します。
Helenはユニット・テストが完了すると、独立のリポジトリが完成します。彼女はそれをAdamに送信し、Adamはマスター・リポジトリを手動で更新するか、別々の場所で2方向マージを実行します。Adamは、次のマージの手順のいずれかを実行します。
手動でリポジトリを更新
最初に、Adamは2つのリポジトリを補正して、トップレベル・オブジェクトに付与された異なる名前を考慮してIDを再割り当てします。このプラクティスにより、マージ時に競合が発生しなくなります。
次に、Adamはマスター・リポジトリをMUDディレクトリからローカル・ディレクトリにコピーして、必要な更新を手動で実行し、Helenのリポジトリのコンテンツをマスター・リポジトリに追加します。それから、マスター・リポジトリをマスター・ディレクトリに再度コピーします。
別の場所で2方向マージを実行
ヒント:
空のリポジトリを作成するには、「ファイル」→「新規リポジトリ」を選択します。その後、名前(blank.rpdなど)とリポジトリ・パスワードを指定します。「メタデータのインポート」には「いいえ」を選択し、「終了」をクリックします。
マージ後に、Adamは展開されるコンテンツを管理するための新しいプロジェクトhr_payrollを作成します。彼はHelenのコンテンツをそのプロジェクトに追加します。また、それをメインからチェックアウトし、HR Branch MUDディレクトリに送信します。プロジェクトのチェックアウトを使用すると、後でIDおよびマージの管理が容易になります。
Adamは接続プール・パラメータを調整し、リポジトリをテスト・コンピュータに移行します。不具合が見つかった場合は、Helenがhr_payrollプロジェクトをチェックアウトし、それを修正して、ユニット・テストをしてから公開します。(彼女は、チェックアウトしたブランチ・プロジェクトから自分の機能プロジェクトをチェックアウトします。)Adamは、それをテスト・システムに移行してさらにテストします。テストが完了したら、彼は、完了したHRブランチ・リポジトリをメイン・ブランチに戻してマージし、統合されたリポジトリをテスト・システムの統合テストに送信します。
統合されたリポジトリでテストが完了すると、本番への移行の準備が整います。ここでは、完全なリポジトリの移行、またはpatchrpdを使用した本番環境へのパッチの適用というオプションがあります。両方の方法ともローリング再起動が必要です。
この手順の実行後には、本番リポジトリにイニシアティブSとイニシアティブHの両方のコンテンツが格納されます。
