| 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 |
|
前 |
次 |
この付録では、特定のビジネス・ケースでマルチユーザー開発環境を使用する方法を示す架空の事例について説明します。
この付録のトピックは次のとおりです。
Eden Corporation社 (架空の会社)は、最近Oracle Business Intelligenceを購入しました。この会社の2つの部署がライセンスを保有し、製品を使用する予定です。そのため、この会社には2つの個別のイニシアティブがあります。
イニシアティブS: 販売部は、計画に対する収益のダッシュボードおよび分析にOracle Business Intelligenceを使用します。この部署では、要件を即座に満たすように初期フェーズを本番にデプロイし、フェーズIIおよびフェーズIIIではより高度な機能をロールアウトします。イニシアティブSは、2人の開発者が作業するには十分な大きさです。
イニシアティブH: 人事部(HR)では、HRデータのダッシュボードおよび分析を行う必要があります。イニシアティブHは小さなイニシアティブのため、1人の開発者しかいません。この部署では、イニシアティブSのフェーズIIとフェーズIIIとの間でアプリケーションを本番に配信する予定です。
販売部と人事部の開発者は、お互いのデータおよびメタデータを参照することはできません。すべてのメタデータのセキュリティ権限を持つユーザーは、メタデータ管理者のみです。
多くの組織と同様に、緊急要求の定型的な傾向や本番での不具合も時折ある可能性があります。長期間のイニシアティブSとイニシアティブHがともに開発期間中であっても、開発者はその修正バージョンを数日以内に配信する必要があります。
技術チームのロールおよび職責について
Eden Corporation社では、次のようなチームを配置しています。
Adam Straight: MUD管理者
Sally Andre: 販売部のRevenueプロジェクトの開発者
Scott Baker: 販売部のQuotaプロジェクトの開発者
Helen Rowe: 人事部の開発者
Eden Corporation社の開発フェーズについて
Eden Corporation社では、次のタイムラインに基づいてRPDを本番にデプロイします。
1月: 販売フェーズI (プロジェクトRevenueおよびQuota)
2月: 販売フェーズII (プロジェクトTargetの追加、プロジェクトRevenueおよびQuotaの拡張)
3月: HR (1つのプロジェクトを使用)
4月: 販売フェーズIII (3つすべてのプロジェクトの拡張)
Eden Corporation社のトポロジについて
Eden Corporation社では、マルチユーザー開発環境に次のシステムを使用する予定です。
MUD管理者: NTコンピュータ(共有)
Sally Andre: 管理ツール・クライアント用NTコンピュータ、およびOracle Business Intelligenceスタックの実行用Linuxコンピュータ
Scott Baker: 高機能NTコンピュータ
Helen Rowe: 前述のいずれか
テスト: Linuxコンピュータ
本番: クラスタ化されたLinuxコンピュータ
リポジトリ・アーキテクチャについて
Eden Corporation社のビジネス構造およびイニシアティブでは、リポジトリに2つの独立なセマンティック・モデルを持つ必要があります。1つは販売部用、1つは人事部用です。それぞれのモデルには複数のプロジェクトを持つことができます。
リポジトリ構造の計画
リポジトリ・ファイルの構造次第で組織のマルチユーザーの開発ニーズをサポートできるようになるため、Eden Corporation社ではリポジトリ・ファイルの構造を計画することの重要性を認識しています。主要なオブジェクトには所有者が割り当てられるため、開発者は競合が発生したときに誰に照会したらよいか、自身で変更してはならないオブジェクトはどれかがわかります。
ヒント: 複数の独立したセマンティック・モデルをホストする場合、トップレベル・オブジェクトの名前を列挙して、名前が重複しないようにしてください。
表B-1および表B-2に、イニシアティブSおよびイニシアティブHでmain.rpdの高レベル・オブジェクトを示します。これらは、プロジェクトおよび所有者にマップされます。Adamは、イニシアティブSおよびイニシアティブHの全体の所有者です。
表B-1 プロジェクトおよび所有者にマップされたイニシアティブSのリポジトリ・オブジェクト
| オブジェクト・タイプ | オブジェクト | 所有者 | ProjRevenue | ProjQuota | ProjTarget |
|---|---|---|---|---|---|
|
物理データベース |
Sample App Data |
Sally |
はい |
はい |
はい |
|
ビジネス・モデル |
Sales |
Sally |
該当なし |
該当なし |
該当なし |
|
論理ファクト表1 |
F10 Billed Rev |
Sally |
はい |
はい |
いいえ |
|
論理ファクト表2 |
F30 Facts Targets |
Scott |
いいえ |
いいえ |
はい |
|
論理ファクト表3 |
F50 Facts Quotas |
Scott |
いいえ |
はい |
いいえ |
|
論理ディメンション |
(各種オブジェクト) |
Sally |
はい |
はい |
はい |
|
サブジェクト・エリア(1) |
Sales Quota |
Scott |
いいえ |
はい |
いいえ |
|
サブジェクト・エリア(2) |
Sales Revenue |
Sally |
はい |
いいえ |
いいえ |
|
サブジェクト・エリア(3) |
Sales Target |
Scott |
いいえ |
いいえ |
はい |
|
変数 |
S_Last_Load |
Sally |
はい |
はい |
はい |
|
初期化ブロック |
S_Last_Load |
Sally |
はい |
はい |
はい |
|
アプリケーション・ロール(1) |
Sales Management |
Sally |
はい |
はい |
はい |
|
アプリケーション・ロール(2) |
Sales Rep |
Sally |
はい |
はい |
はい |
表B-2 プロジェクトおよび所有者にマップされたイニシアティブHのリポジトリ・オブジェクト
| オブジェクト・タイプ | オブジェクト | 所有者 | ProjHR |
|---|---|---|---|
|
物理データベース |
Human Resources Data |
Helen |
はい |
|
ビジネス・モデル |
HR |
Helen |
該当なし |
|
論理ファクト表(1) |
Payroll Facts |
Helen |
はい |
|
論理ファクト表(2) |
Medical Ins Facts |
Helen |
はい |
|
論理ディメンション |
(各種オブジェクト) |
Helen |
はい |
|
サブジェクト・エリア(1) |
HR Payroll |
Helen |
はい |
|
サブジェクト・エリア(2) |
HR Medical |
Helen |
はい |
|
変数 |
H_Last_Load |
Helen |
はい |
|
初期化ブロック |
H_Last_Load |
Helen |
はい |
|
アプリケーション・ロール(1) |
HR Management |
Helen |
はい |
|
アプリケーション・ロール(2) |
HR Rep |
Helen |
はい |
第1フェーズでは、Sally AndreとScott Bakerは平行で開発を行います。Sallyは初期コンテンツを作成し、Adam Straightはそれをプロジェクトに分割して、SallyとScottがチェックアウトして開発を実行できるようにMUDディレクトリを作成します。ユニット・テストを終えたら、それらの変更をマージして公開し、Adamはリポジトリをテスト環境に移行します。不具合修正サイクルの後、Adamはリポジトリを本番にプロモートします。
次の項では、フェーズIの開発について説明します。
Sally Andreは、空のRPDからイニシアティブSを開始します。いくつかの論理スターおよびサブジェクト・エリアを最初に定義している場合、リポジトリをMUDプロジェクトに分割する方が容易なため、始めにフェーズIに必要な物理モデルを開発します。独自のローカル・テスト・データソースの接続プールの詳細も含まれます。
ヒント: 物理モデルには、物理表、すべての物理表に別名を定義して意味のある名前を付けるためのベスト・プラクティス、および結合が含まれます。
図B-1に、イニシアティブSの物理モデルを示します。
Sallyは、物理レイヤーをビジネス・モデルおよびマッピング・レイヤーにドラッグしていくつかの初期コンテンツを作成します。また、不要な表を削除したり、スター結合が正しくなるようにします。さらに、開発時に必要なすべての物理表が開始論理表からのマッピングを持たせ、チェックアウトするときにそれらがプロジェクトに含まれるようにします。Sallyはこれらの手順を使用してF10 RevenueおよびF50 Quotasの2つのファクト表を作成し、これらはプロジェクトの基盤として機能します。
また、Sallyはビジネス・モデルのプロジェクトをマップするためのサブジェクト・エリアをいくつか持つ必要があります。ビジネス・モデル全体をドラッグすることができますが、ビジネス・モデルを右クリックして「Logical StarsとSnowflakes向けのサブジェクト・エリアの作成」を選択するとこの機能をより便利に実行できます。この機能を使用すると、それぞれの論理ファクト表からサブジェクト・エリアを作成できます。
Sallyは、この時点でサブジェクト・エリアのコンテンツについて考慮する必要はありません。重要なのは各サブジェクト・エリアを同じプロジェクトの論理ファクト表にマップするということです。ただし、サブジェクト・エリアは管理ミーティングSales QuotaおよびSales Revenueで合意された計画に基づいて名前を付けます。
Sallyはこの時点で、RevenueおよびQuotaファクト表に基づいて最初の2つのプロジェクトを作成するための十分なMUD管理者のコンテンツを持ちます。これらを確認するには、Sallyは最低でも次の基準を満たしていることを確認する必要があります。
別のプロジェクトに対する、管理計画に応じた最低1つの論理ファクト表。論理ファクト表の列は、完成していなくても、さらには正しく名前が付けられていなくてもかまいませんが、すべての物理コンテンツをマップできる程度に完成している必要があります。
リポジトリが整合性チェックに合格できる十分な論理ディメンション。
プロジェクトに含められる1つ以上の論理ファクト表にマップされる物理コンテンツ。
管理計画に応じて必要なサブジェクト・エリア。
Eden Corporation社のMUD管理者Adam Straightは、ここで次の手順を実行してプロジェクトを作成し、それらをチェックアウトできるようにします。
最初に、MUDディレクトリRPD_mainを作成します。ここには、マスターRPDが保存されます。このマスターRPDには、開発者のコンテンツのスーパーセットが含まれます。ユーザーはマスターからプロジェクトをチェックアウトし、その変更を共有する際にそれをマージして戻します。Sallyは、開始したRPDをマスター・フォルダにコピーして、Adamが最初の2つのプロジェクトProjRevenueおよびProjQuotaを作成できるようにします。
最初に、Adamは管理ツールでマスターRPDを開き、「管理」→「プロジェクト」を選択します。ここで、プロジェクト・マネージャで、「アクション」→「新規プロジェクト」を選択します。彼はこのプロジェクトに「ProjRevenue」という名前を付けてから、プロジェクトの中央の論理ファクト表を選択します。リストの一番上のオブジェクトが開き、論理ファクト表が表示されます。また、論理ファクト表が属するビジネス・モデルごと、またはサブジェクト・エリアごとにまとめて表示することもできます。
図B-2は、Adamが論理ファクト表を表示できる各種の方法を示します。
図B-2 ビジネス・モデルおよびサブジェクト・エリアごとにグループ化されたファクトを含むプロジェクト・ダイアログ
Adamは、サブジェクト・エリアのグループを使用して同じファクト表を選択できたかもしれませんが、便宜上、ビジネス・モデルごとにファクトをグループ化することに決めます。彼はこのプロジェクトに指定されたファクト表、さらにデフォルトのアプリケーション・ロールおよびサブジェクト・エリアを追加します。カスタムで定義されたアプリケーション・ロール、ユーザー、変数または初期化ブロックはまだないため、それらをプロジェクトに追加することはできません。Adamは、2番目のプロジェクトのProjQuotaでもこの処理を繰り返します。
ヒント: 一部の明示的なオブジェクトは、両方のプロジェクトでアプリケーション・ロールを共有しているため、両プロジェクトで同一になります。同様に、多くの暗示的なプロジェクトのオブジェクトも共有されます(特に論理モデルと物理モデルの両方のディメンション表など)。作業しやすい小さなサブセットを複数作成すると、プロジェクトは使用しやすくなります(セキュリティの目的ではありません)。それぞれのトップレベル・オブジェクトの所有者がチーム全体に割り当てられてドキュメントが作成される管理プロセスにおいては、開発者が競合を回避できることからも、これは重要になります。
プロジェクトの論理ファクト表F10 Bill Revの所有者はSally Andreであり、このプロジェクトの所有者であるScott Bakerではありませんが、Adamはこれをこのプロジェクトに含めています。これは、Scottが両方のファクト表(販売ノルマの割合)のメジャーから導出するメジャーを作成する必要があるため、このようにしています。要は、ユーザーが所有するオブジェクトのみでなく、ユーザーの要件の実装に必要なコンテンツのサブセットもユーザーに提供されるということです。
Adamは、マスターRPDを共有ドライブRPD_Mainに「sales.rpd」として保存します。これで、ユーザーはプロジェクトをチェックアウトし、作業を平行して進められるようになります。
ここで、2人の開発者は、マスター・リポジトリの管理ツール・クライアントを設定して、プロジェクトをチェックアウトし、作業を開始します。Sallyはまず、マスター・リポジトリを使用するように管理ツール・クライアントを設定します。そのためには、「ツール」→「オプション」を選択してから、「マルチユーザー」タブを選択します。そこで、マスター・リポジトリ・ディレクトリへのポインタを設定します。また、ログやロックで便利になるので、彼女のフルネームも入力します。これで、彼女は自分のプロジェクトをチェックアウトして、その作業ができるようになります。
一方、マスター・リポジトリ・ディレクトリには、sales.000とsales.mhlという2つの新しいファイルが作成されています。図B-3に、これらの新しいファイルを示します。
sales.000ファイルは、Sallyがsales.rpdをチェックアウトするときに作成されるsales.rpdの自動バックアップ・ファイルです。問題が発生した場合、このファイルを使用してロールバックできます。sales.mhlファイルでは、プロジェクト、コンピュータ、ユーザーなどのパラメータおよびチェックアウト・ステータスを追跡します。
一方、Sallyのローカル・リポジトリ・ディレクトリには、3つのファイルが作成されています。
originalProjRevenue.rpd: このファイルは、チェックアウト時のプロジェクト・サブセットRPDです。これは、3方向のマージ処理において後でオリジナルとして使用されます。またSallyが変更を廃棄する場合にも使用されます。
ProjRevenue.rpd: このファイルには、自己完結のサブセット・プロジェクト(ProjRevenue)のみが含まれます。これは、編集時に開くファイルです。
ProjRevenue.rpd.Log: このファイルは、管理ツールのこの編集セッション用のログ・ファイルです。管理ツールで「ファイル」→「マルチユーザー」→「履歴」を選択すると、そのコンテンツを表示できます。
図B-4に、ローカル・リポジトリ・ディレクトリの3つのファイルを示します。
ここで、Sallyは自分のアプリケーションのモデルで作業を開始します。彼女は初期コンテンツを作成したときに独自のテスト・データソース接続プールの詳細を使用していたので、接続プール設定を変更する必要はありません。
Sallyはまずファクト表を開いて、モデリングのベスト・プラクティスに基づいて使用されていないキーを削除します。それから、Discnt_Value、RevenueおよびUnitsの3つのメジャーにSUM集計ルールを追加します。またそれらの名前を、Discnt_Valueは「Discount Amount」、Unitsは「Units Sold」、Revenueは「Sales Revenue」にそれぞれ変更します。
また、D10 Product表にProd_Dsc列の大文字バージョンとなる新しい「PRODUCT DESCRIPTION」という列を追加する必要があります。これは、「Upper("Sales"."D10 Product (Dynamic Table)"."Prod_Dsc")」の式を使用します。さらに、ディメンション階層を追加し、「Constant One」という変数を作成して、それを値1に初期化します。これを使用して新しいメジャーConstant Oneを作成します。
Sallyは、アプリケーション・ロールを追加できるようにサンドボックスOracle Business Intelligenceスタックを開始してから、アンサーを使用してリポジトリをテストします。次の手順に従ってコンポーネントを正しい順序で開始し、システム環境を構成します。
標準コントロールを使用して、RCUスキーマが含まれるデータベースを開始します。
Oracle WebLogic Server管理サーバーを起動します。たとえば、Windowsでは、「スタート」→「すべてのプログラム」→「Oracle WebLogic」→「User Projects」→「bifoundation_domain」→「Start Admin Server for WebLogic Server Domain」を選択して、入力を求められたらインストール時に作成したユーザー名とパスワードを入力します。
「エンタープライズ・インストール」または「ソフトウェアのみインストール」のタイプを使用している場合、Oracle WebLogic Server管理コンソールを使用してOracle WebLogic Server管理対象サーバーを起動する必要があります。通常、開発サンドボックスをインストールしている場合は、簡易インストール・タイプを使用します。
正しいリポジトリ・パスワードを入力して、Fusion Middleware Controlにログインし、リポジトリ・ファイルをアップロードします。
また、クエリ・ログの解析が容易になるように、Fusion Middleware ControlでOracle BIサーバー・キャッシュをオフにします。
さらに、Fusion Middleware ControlのBusiness Intelligence概要ページからシステム・コンポーネントを起動します。
ステップ2 - 5の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』を参照してください。
SallyのOracle BIサーバーはLinuxシステム上にあるため、管理ツール・クライアントからそこのBIサーバーにアクセスできるように彼女のWindowsコンピュータにODBC接続を設定する必要があります。
Sallyは、Linuxコンピュータ上のOracle BIサーバーを指すように、Oracle BIサーバーODBC DSNを手動で追加します。Oracle BIサーバーのODBC DSNの作成方法の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイド』のOracle Business Intelligenceと他のクライアントとの統合に関する項を参照してください。
Sallyは、Oracle WebLogic Serverの組込みポリシー・ストアを使用するため、2つのアプリケーション・ロール「Sales Management」および「Sales Rep」を追加する必要があります。ロールを追加するには、WindowsコンピュータでWebブラウザを開き、(彼女のLinux上のOracle Business Intelligenceスタックを指す) Fusion Middleware Controlにログインします。Fusion Middleware Controlを使用して新しいロールを作成し、それを適切なユーザー、グループまたは他のロールにマップして、そのロールに適切な権限を付与します。
ヒント: 詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionセキュリティ・ガイド』のアプリケーション・ロールの作成に関する項を参照してください。
次に、Sallyは新しいアプリケーション・ロールを彼女のリポジトリに追加して、それらをオブジェクトの権限およびデータ・アクセス・フィルタに使用する必要があります。そのためには、Sallyは次の処理を実行します。
管理ツールを開き、「ファイル」→「開く」→「オンライン」を選択します。そこで、彼女のOracle Business Intelligenceスタックに接続するローカルWindows ODBC DSNを選択して、リポジトリ・パスワードを入力し、さらにインストール時に作成したスタックを管理するためのデフォルトのユーザー名とパスワードも入力します。
次に、「管理」→「アイデンティティ」を選択して、Identity Managerを開きます。ナビゲーション・ツリーで「BIリポジトリ」をクリックしてから、「アプリケーション・ロール」タブをクリックします。すると、5つのデフォルトのアプリケーション・ロールに加えて、作成したばかりの新しいロールも表示されます。
Sallyは、Sales Repアプリケーション・ロールをダブルクリックして、「権限」をクリックします。「データ・フィルタ」タブで、このロールに属するユーザーは自分自身で作成した売上を参照することのみが許可されることを示す式を含むデータ・フィルタを追加します。「オブジェクト権限」タブで、Sales Repユーザーに収益の参照を許可しノルマやコスト情報の参照を許可しないように、「読取り」、「読取り/書込み」、「アクセス権なし」を設定します。「問合せ制限」タブでは、「最大行数」および「最大時間」をデフォルトのままにして、時間の制限は何も設定しません。「OK」をクリックしてIdentity Managerに戻ります。
次に、「Sales Management」アプリケーション・ロールをダブルクリックして、管理委員会の決定に基づいてこのロールに最適な「データ・フィルタ」、「オブジェクト権限」および「問合せ制限」を設定します。
最後にIdentity Managerを終了します。
次にチェックアウトするときにSallyのプロジェクトに入る新しい変数およびアプリケーション・ロールは、変更をチェックインする前にプロジェクトに追加する必要があります。そのためには、Adamがプロジェクトを作成したときに行った手順と同じ手順を実行します。「管理」→「プロジェクト」を選択して新しいプロジェクトを選択し、左のペインで新しいオブジェクトを選択して「追加」をクリックします。
Sally AndreはProjRevenueプロジェクトで作業を行っていますが、Scott BakerはProjQuotaで作業を開始します。彼はMUDの管理ツール・オプションを設定し、プロジェクトをチェックアウトして、作業を開始しています。
Scottは、オンライン・モードを選んで作業します。Oracle BIサーバーで稼働中にリポジトリを変更するので、オンライン・モードで作業することで開発とユニット・テストの循環が強化されます。管理ツールのツールバーで「変更のチェックイン」をクリックするたびに、稼働中のサーバーに変更が適用されます。その直後にアンサーに移動して、そこで変更をテストできます。プレゼンテーション・レイヤー・オブジェクトを追加、削除、名前変更または再編成する場合、アンサーの基準タブでメタデータをリロードして、そこに表示されているツリーをリフレッシュする必要があります。
最初に、Scottは自分のOracle Business Intelligenceスタックを開始し、Fusion Middleware Controlを使用してチェックアウトしたリポジトリをアップロードします。Oracle BIサーバーを再起動して、管理ツールを開き、オンライン・モードでリポジトリを開きます。
マスター・リポジトリにはSallyの設定が含まれているため、Scottはローカル・テスト・データベースを指すように接続プール設定を変更する必要があります。マージ処理で、これらの接続プールの変更はマスター・リポジトリに存在している接続プールにより上書きされてしまうので、次にScottがチェックアウトしたときに、再度ローカル・テスト接続プールの変更を適用する必要があります。
ヒント: 本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイド』のテストから本番環境への移行に関する項を参照してください。
Scottの次のタスクは、キーを削除して彼の論理ファクト表をクリーンアップすることです。また、メジャーにSUM集計ルールおよび業務上わかりやすい名前(Quota Amount)を指定します。
F10論理表はSallyが所有しているので、Scottは表内の何も変更しません。SallyがマスターRPDに対して変更をチェックイン、マージおよび公開したら、Scottも同じことを行います。そこで、Scottは再度チェックアウトしてSallyの変更を取得します。
次にScottは、「Sales percent of quota」という新しいメジャーをF50表に追加します。これは、次の式を使用して両方のファクト表から導出します。
"Sales"."F10 Billed Rev."."Revenue" / "Sales"."F50 Facts Quotas"."Quota Amount"
Sallyが自身のプロジェクトでRevenueの名前を変更しても、マージ処理ではそれが同じオブジェクトと識別され、Scottの式で同じ名前が使用されます。オブジェクトのアップグレードIDは元のIDと同一であるため、マージ・ロジックで名前の変更を識別できます。
最後に、ScottはすべてのディメンションはSallyが所有するという管理委員会のミーティングでの決定を忘れてしまいます。D10 Product.Prod_Dsc列の大文字バージョンのPRODUCT DESCRIPTIONという列が必要でしたが、彼はSallyと同じ列を作成してしまいます。この誤りはチェックイン・マージ処理で即座に検出され解決されます。
Scottは、オンライン・モードで作業しているため、自分のリポジトリをアップロードしたり自分のシステムを再起動する必要はありません。そのかわり、変更を行った直後にそのユニット・テストを行います。その間にSallyは、彼女の変更のテストを終えます。
Sallyは変更の最初のバッチの作成およびユニット・テストを終えたので、作業を保存してそれをマスター・リポジトリにマージします。「ファイル」→「マルチユーザー」→「ローカル変更のマージ」を選択します。新しいオブジェクトをプロジェクトに追加することを忘れても、詳細な警告が表示されるので、オブジェクトをプロジェクトに追加して再度マージできます。そうしないと、次に彼女がプロジェクトをチェックアウトしたときに、オブジェクトは抽出されません。
次に、他のユーザーがマージすることでSallyの変更が破損してしまうことなく彼女が自分の変更をマージできるように、管理ツールはマスター・リポジトリをロックします。
ヒント: コメント・フィールドを使用してチェックインする変更の説明を記録用に残しておくことをお薦めします。また、頻繁にチェックインを行うと後で変更の追跡および履歴の監査がしやすくなります。さらに、管理ツールのモデリングでは、作業を段階的に行うことでテストを簡易化して各タスクの複雑性を低減することをお薦めします。
Sallyの変更により競合が発生することはないので、次に示す「マージ戦略の定義」の手順では競合について触れていません。ただし、プレゼンテーション・オブジェクトの別名は特殊なケースで、変更(ローカル・バージョン)、現行(マスター)、または2つのマージを保持することを選択できます。Sallyが列名を変更すると別名が自動的に作成されるため、新しい名前を本番に配置したときに、古い名前に記述されたレポートが破損することはありません。Eden Corporation社にはまだレポートがないため、「現行」を選択しても別名は空のままです。Sallyは「Sales Revenue」、「Units Sold」および「Discount Amount」に対してこれを行います。
ヒント: 名前を複数回変更すると、一連の別名ができることがあります。古い名前を使用しているレポートのセットが存在する場合があるため、「マージ戦略の定義」画面で「選択内容のマージ」を選択して、「現行」に存在する別名および「変更」の新しい別名を保持できます。
マージが完了したら、Sallyはもう一度テストを行い、他のコンテンツとのマージにより機能が破損していないことを確認します。ただし、Sallyがリポジトリをマスター・ディレクトリに公開するか変更を廃棄するまでマスター・リポジトリのロックは解放されないので、テストが長引かないように注意する必要があります。
最後に、Sallyは「ファイル」→「マルチユーザー」→「ネットワークに公開」を選択します。これにより、まずマスターsales.rpdがバックアップ(sales.001)にコピーされ、sales.rpdはSallyの変更で上書きされます。マージ・ログも保存されます。
Scottはこのフェーズの開発作業を完了したので、ローカルの変更をマージします。「マージ戦略の定義」画面で、プレゼンテーション列「Quota Amount」で作成した別名を保持するかどうか尋ねられるので、Scottは、Sallyと同様に、現在のリポジトリ値を保持するように選択します(別名は使用されません)。
ローカルをマージしたら、Scottはマスター・リポジトリのロックを保持していることを認識しつつ再度簡潔にユニット・テストを行います。彼はテスト中に、Sallyのものと同じPRODUCT DESCRIPTIONという列を誤って作成していたことに気づきます。Scottの列は個別に作成されているので、内部アップグレードIDはSallyのものとは異なります。そのため、名前が同じでも、マージ・ロジックではそれを別の列と認識し、上書きされることなく、名前に「#1 (PRODUCT DESCRIPTION#1)」が付加されます。
Scottはマージを完了したので、リポジトリ全体が開かれてロックされています。Scottは外部列を削除し、彼のロジックをSallyのPRODUCT DESCRIPTION列に接続して、再度簡潔にテストしてから、ネットワーク・マスター・リポジトリに変更を公開します。
Scottが様々なユーザーのオブジェクトを削除または変更していると、エラーの解決は困難になることがあります。その場合、オブジェクトの再作成および補正、またはリポジトリのバックアップ・バージョンへのロールバックおよび彼の変更の再作成が必要になることがあります。
テスト環境のリポジトリの準備をするために、MUD管理者Adam Straightはここで、マスター・リポジトリで直接いくつかのタスクを実行する必要があります。つまり、「ファイル」→「マルチユーザー」→「チェックアウト」ではなく、「ファイル」→「開く」→「オフライン」を使用します。
Adamはまず管理ツールを開いてからsales.rpdをオフライン・モードで開きます。その直後、他のユーザーはロックアウトされるので、それらのユーザーがプロジェクトをチェックアウトしようとするとWindows権限エラーが発生します。Adamが何度もファイルを開いたり閉じたりする必要がある場合、他のユーザーがそれぞれの変更の間にチェックアウトできないように、RPDをどこか他の場所で変更して共有ディレクトリからそれを削除する必要があります。
Adamはテスト環境に適合するように接続プール設定を変更します。管理ツール・ユーザーがプロジェクトをチェックアウトする場合、接続プール・パラメータはチェックアウトに含まれません。通常、MUDディレクトリのマスター・リポジトリにはテスト接続プールが含まれますが、個々の開発者は独自にテストデータベースに接続するために様々な設定が必要になる場合があります。チェックインおよび公開時は、マスター・リポジトリの接続プールは開発者の変更で上書きされないため、引き続き共有テスト・データベースを指すことができます。
また、Adamは新しいアプリケーション・ロールがテスト・システムに移行されていることを確認する必要があります。このロールは2つしかないので、彼はテスト・システムのFusion Middleware Controlでそれらを再入力することにします。さらに、Adamはいくつかのテスト・ユーザーまたはグループを新しいアプリケーション・ロールにプロビジョニングして、セキュリティ・フィルタ、権限および問合せ制限をテストできるようにします。
最後に、AdamはFusion Middleware Controlを使用してリポジトリをテスト・システムをアップロードし、Oracle BIサーバーを再起動します。ローカルの管理ツールを使用して、テストOracle BIサーバーをオンライン・モードで接続し、整合性チェッカーを実行します。このリポジトリで参照されるいずれかのアプリケーション・ロールに欠落またを不正があると、整合性チェッカーでそのエラーのリストが出力されます。
この時点でテスト・チームはリポジトリをテストできます。テスト中に、テスト・チームは"Sales"."F50 Facts Quotas"."Sales percent of quota"が式sales/quotaではなくquota/salesで誤って作成されているという不具合を発見します。テスト・チームは不具合レポートを記述し、不具合の修正はScott Bakerが割り当てられます。
Scottは管理ツールを開いて、ProjQuotaをチェックアウトし、変更を行い、ローカル・テスト・データベースを指すように接続プールを変更して独自のサンドボックスでテストします。そこで彼の変更をマージしてそれを共有MUDディレクトリに公開します。Scottは、不具合が修正され、リポジトリは再度テストするために送信する準備ができたことをAdamに通知します。
MUD機能によりマスター・リポジトリはチェックアウトされたプロジェクトの接続プールの変更から隔離されるので、Adamは接続プールが正しいテスト・システムで指定されていることを認識できます。Adamはテスト・コンピュータ上で、Fusion Middleware Controlを開き、リポジトリをアップロードして、Oracle BIサーバーを再起動します。
テスト・チームは完成するまでテストを行い、本番用のリポジトリはクリアされます。
リポジトリがテスト・フェーズで合格すると、データベース接続パラメータを更新して本番にアップロードできるようにする必要があります。また、アプリケーション・ロールを移行およびプロビジョニングする必要があります。
管理チームが立てた計画に基づき、本番運用チームは新しいアプリケーション・ロールが必要なことを認識します。本番運用チームは、Adamと同様に、テスト環境に新しいアプリケーション・ロールを作成します。また、管理チームからのセキュリティ仕様に基づき、ユーザーまたはグループをそれらのアプリケーション・ロールにプロビジョニングします。
本番に移行する前に、Adamは接続プール・パラメータを本番データベースに必要な値に変更する必要があります。Eden Corporation社では、Adamには本番接続プールを参照する権限がありますが、リポジトリ開発者にはありません。そのため、Adamはテストから本番接続プールに変更して、リポジトリをマスター・ディレクトリに配置することはできません。これは、開発者にそれを読書きするためのWindows権限があるためです。かわりに、Adamは本番に必要な接続プールのXMLパッチを作成します。そして、sales.rpdをセキュア・ディレクトリにコピーしてパッチを適用してから、それが実際に本番データソースに接続されていることを確認するテストを行います。その後リポジトリを本番システムにアップロードして、サーバーの本番クラスタを起動します。
ヒント: 本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionインテグレーターズ・ガイド』のテストから本番環境への移行に関する項を参照してください。
マスター・リポジトリはまだテスト・データベースを指しているため、管理ツール・ユーザーはそれを参照することができます。一方、本番リポジトリの新しいバージョンは、XMLパッチ・ファイルの接続プールの変更を適用することで、いつでも構築できます。
ここで本番の検証が実行されます。テスト・システムへの移行と同様に、重要な検証では、アプリケーション・ロールがすべて正しくなるように、オンライン・モードで整合性チェッカーが実行されます。この検証が完了すると、フェーズIは本番になります。
フェーズIIでは、開発は新しいフェーズIIブランチで続行され、メイン・ブランチでは本番アプリケーションを追跡します。この作業を管理するために、Adamはブランチ・プロジェクトを追加して、2番目のマスター・リポジトリの共有ディレクトリを設定し、1つはメイン、もう1つは新しいフェーズIIブランチに指定します。
SallyはさらにコンテンツをProjRevenueに追加します。Sallyがその作業をしている間、Scottは新しいコンテンツを追加します。Scottがマージおよび公開を終えたら、Adamは新しいプロジェクトProjTargetを作成し、Scottの新しいコンテンツをそれに移動します。一方、彼らは本番で発生したすべての不具合に対処する必要があります。これもメインsales.rpdブランチで行われます。
次の項では、フェーズIIの開発について説明します。
Adamはまず、別のMUDディレクトリを作成して、新しいブランチのマスターを保持します。また、SallyとScottがそれを読書きできるように、Windows共有セキュリティを設定します。
次に、メイン・リポジトリをメインMUDディレクトリに配置します。ブランチに新しいプロジェクトを追加します。これには既存のすべての機能が含まれます。ここで、リポジトリを閉じ、ローカル管理ツールのリポジトリ・フォルダにブランチ・プロジェクトをチェックアウトします。それをブランチMUDディレクトリにコピーします。すると、そこがブランチのマスターとして機能するようになります。
SallyとScottは再度プロジェクトをチェックアウトして、Sales InitiativeフェーズIIの開発を相互に並列して、また本番中のフェーズIと並列して開始します。Scottは新しいプロジェクトになる新しいコンテンツを追加しているので、新しいコンテンツにマップまたは結合する必要がある共有オブジェクトを提供する他のプロジェクトを1つ以上チェックアウトする必要があります。彼は、ProjQuotaをチェックアウトすることを選択します。
SallyとScottがフェーズIIの開発を行っている間、緊急CEOリクエストがエスカレーションされます。CEOは主要な販売マネージャにダッシュボード上の「Sales Quota Variance」という新しいメジャーを2日以内に閲覧させたいと考えています。ScottはフェーズIIブランチの新しいプロジェクトで作業を閉じます。これはチェックアウトされたままになります。そこで、メイン・ブランチ・マスター・リポジトリ(sales.rpd)から新しいメジャーProjQuoteが含まれるプロジェクトをチェックアウトします。新しいメジャーと対応するプレゼンテーション列を作成し、ローカルでそれをテストして、ローカルでそれをマージし、それを再度メイン・ブランチに公開します。それから、ScottはチェックアウトされたフェーズIIリポジトリをローカル・ドライブから再度開いて開発を続行します。一方、Adamは新しいsales.rpdをテスト環境に送信し、そこでテスト・チームは修正を検証します。次にAdamは修正したリポジトリを本番に送信する準備をします。リポジトリ全体ではなく、変更のパッチを送信します。パッチを作成するために、Adamは変更したリポジトリと本番で現在稼働中のリポジトリを比較します。本番で稼働しているリポジトリは、新しい変更がマージされる直前はメイン・リポジトリと同じなので、これはMUDディレクトリのバックアップ・リポジトリの1つになります。現在本番で稼働しているリポジトリはsales.006というバックアップで、次のブランチ・マージのオリジナルとして識別されるものと同じです。管理ツールがそのファイルを認識して開けるように、Adamはこれをsales.006.rpdにコピーします(これは後で別のマージで必要になる場合があるので、単純にその名前を変更することできません)。
図B-6に、sales.rpdとsales.006が含まれるMUDディレクトリのファイルを示します。
次に、Adamは更新sales.rpdが含まれるリポジトリを開きます。「ファイル」→「比較」を選択してから、比較する古いバージョンにsales.006.rpdを選択します。「リポジトリの比較」ダイアログには、パッチに含まれるバージョン間の差異が表示されます。
図B-7に、「リポジトリの比較」ダイアログを示します。
次に、Adamは「パッチの作成」をクリックして、結果をPatch_variance.xmlとして保存します。パッチには、2つの新しい列を適用する必要があるオブジェクトとそれに関連する相互接続のみが含まれます。
ヒント: より複雑なパッチを使用すると、オブジェクトを削除したり、新しいプロパティ値でマージするオブジェクトを上書きすることができます。
Adamのパッチは、次のようになります。
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<DECLARE>
<LogicalTable name="F50 Facts Quotas" parentName=""Sales""
parentId="2000:68667" parentUid="2160843965" id="2035:69454" uid="2160843966"
x="718" y="288">
<Description/>
<Columns>
<RefLogicalColumn id="2006:69460" uid="2160844041"
qualifiedName=""Sales"."F50 Facts Quotas"."Quota
Amount""/>
<RefLogicalColumn id="2006:69786" uid="2160845070" qualifiedName=
""Sales"."F50 Facts Quotas"."
Sales percent of quota""/>
<RefLogicalColumn id="2006:70033" uid="2160845342" qualifiedName=
""Sales"."F50 Facts Quotas"."
Sales Quota Variance""/>
</Columns>
<TableSources>
<RefLogicalTableSource id="2037:69456" uid="2160844747"
qualifiedName=""Sales"."F50 Facts Quotas"."
F50 Facts Quotas""/>
</TableSources>
</LogicalTable>
<LogicalColumn name="Sales Quota Variance" parentName=
""Sales"."F50 Facts Quotas"" parentId="2035:69454"
parentUid="2160843966" id="2006:70033" uid="2160845342" isDerived="true"
isWriteable="false">
<Description><![CDATA[quota - sales]]></Description>
<Expr><![CDATA["Sales"."F50 Facts Quotas"."Quota Amount" - "Sales".
"F10 Billed Rev."."Sales Revenue" ]]></Expr>
</LogicalColumn>
<PresentationTable name="F50 Facts Quotas" parentName=
""Sales Quota"."""
parentId="4004:69706" parentUid="2160844968" id="4008:69707"
uid="2160844969" hasDispName="false" hasDispDescription="false">
<Description/>
<Columns>
<RefPresentationColumn id="4010:69711" uid="2160844973" qualifiedName=
""Sales Quota".."F50 Facts Quotas"."
Quota Amount""/>
<RefPresentationColumn id="4010:70032" uid="2160845338" qualifiedName=
""Sales Quota".."F50 Facts Quotas"."
Sales percent of quota""/>
<RefPresentationColumn id="4010:70036" uid="2160845345" qualifiedName=
""Sales Quota".."F50 Facts Quotas"."
Sales Quota Variance""/>
</Columns>
</PresentationTable>
<PresentationColumn name="Sales Quota Variance" parentName="
"Sales Quota".."F50 Facts Quotas"" parentId=
"4008:69707" parentUid="2160844969" id="4010:70036" uid="2160845345"
hasDispName="false" hasDispDescription="false" overrideLogicalName="false">
<Description><![CDATA[quota - sales]]></Description>
<RefLogicalColumn id="2006:70033" uid="2160845342" qualifiedName=
""Sales"."F50 Facts Quotas".
"Sales Quota Variance""/>
</PresentationColumn>
</DECLARE>
</Repository>
ヒント: リポジトリ全体の移行と異なり、このパッチを適用する前に接続プールを変更する必要はありません。本番で稼動するリポジトリにはすでに正しい接続プールの設定が行われています。パッチがこのロジックに影響することはないので、接続プールは介入されることなく正しく動作し続けます。
最後に、Adamはこのパッチを移行して本番システムに適用する必要があります。これを実行するにはいくつかの方法があります。
メイン・リポジトリのオフラインのパッチおよびFusion Middleware Controlを使用したアップロード: Adamは、管理ツールを使用してパッチ・マージを実行することで、彼のWindowsコンピュータで本番リポジトリのコピーにローカルでパッチを適用できます。ここで、Sallyが前にサンドボックスで実行したように、Fusion Middleware Controlを使用してリポジトリを本番システムにアップロードできます。本番システムはクラスタ化されているため、リポジトリをアップロードした後、すべてのOracle BIサーバーを再起動する必要があります。Fusion Middleware Controlを使用して、サーバーを一度に1つずつ手動で再起動することもできます。このようにローリング再起動を実行すると、エンド・ユーザーが使用不能になることはありません。また、Adamまたは運用スタッフの1人がBI Systems Management APIを使用してスクリプトを記述し、ローリング再起動を自動化することもできます。
patchrpdユーティリティを使用した本番リポジトリの適切なパッチ: 運用スタッフは本番システムに直接ログオンし、patchrpdユーティリティを使用してXMLパッチを適用できます。なんらかの競合が発生すると、ユーティリティは更新をキャンセルし、変更を行わずに終了します。更新が成功すると、前のパラグラフの説明にあるように、運用スタッフはローリング再起動を実行できます。
biserverxmlcliユーティリティを使用した稼働中のシステムのパッチ: この方法は本番システムにお薦めしません。
ヒント: 管理ツールを使用して本番のOracle BIサーバーにオンライン・モードでログオンする権限がある場合、「ファイル」→「名前を付けてコピー」を使用してそれをローカル・ドライブにコピーします。
SallyとScottは、新しいブランチで変更を完了し、それらをチェックインします。そこでAdamはScottのコンテンツを新しいプロジェクトprojTargetに追加します。Adamは前と同じ手順を実行し、ブランチ・リポジトリをテスト・チームに送信します。テストが完了したら、MUDマージを使用してそのブランチをメイン・ブランチにマージしなおす必要があります。このようにして、本番パッチと新しく開発されたコンテンツがマージされ、後で本番に移行できるようになります。この時点で、sales.rpdにはすべての変更が含まれており、ブランチは不要になります。sales.rpdは統合テストに送られて、マージされたコンテンツでは既存のコンテンツのいずれの不具合も発生しないことを確認されます。統合テストが完了すると、Adamは変更が含まれる別のパッチを作成し、それを稼働中の本番システムに適用するように運用スタッフに指示します。この時点で、Sales InitiativeフェーズIIは本番になります。
次のフェーズでは、SallyとScottはSalesイニシアティブのフェーズIIIの開発を開始します。一方、Helen RoweはHRイニシアティブの最初のフェーズを構築して、新しい独立のセマンティック・モデルを本番に配置します。
次の項では、フェーズIIIの開発について説明します。
Helenのアプリケーションには、給与や医療情報などの機密性の高い個人情報が含まれます。一方、Salesアプリケーションには、法的に機密性の高い財務情報が含まれます。企業のセキュリティ・コンプライアンスにより、これらの2つのチームは相互のデータまたはメタデータを参照することはできません。また、この2つのチームには、時間ディメンションなどの一般的なディメンションを除いて共有できるコンテンツはほとんどありません。この2つのチームのビジネス・ドライバ、予算およびスケジュールも異なります。
そのため、Eden Corporation社の管理委員会は、リポジトリで独立したセマンティック・モデルを使用することを決定します。1つは販売部用で、もう1つはHR用です。このアプローチでは、2つのチームで共有するオブジェクトがなく、コンテンツ間で競合が発生しないようにする必要があります。そうするための最も簡単の方法は、すべてのトップレベル・オブジェクトの名前が競合しないようにすることです。変数およびアプリケーション・ロールも異なる必要があります。
ヒント: ある管理委員会では、それぞれのトップレベル・オブジェクトの名前の前に各セマンティック・モデルに固有の接頭辞(販売部には「S_」、HRには「H_」など)を付けることを開発者に指示することで、トップレベル・オブジェクトが競合しないようにしています。このプラクティスにより、どのオブジェクトがどちらの組織に属しているかわかりやすくなります。別の委員会では、トップレベル・オブジェクトのマスター・リストを保持し、競合が発生しないように確認するためにトップレベル・オブジェクトの名前を提出することを新しいアプリケーションに求めたいと考えています。また、2方向マージでは、上書きによりコンテンツを破損したり予期しないオブジェクト名の変更が発生する前に、誤りを捕捉できます。
別のセキュリティ要件は、正しい開発者のみがそれぞれのリポジトリにアクセスできるように個々のMUDディレクトリにセキュリティを適用する必要があるということです。SallyとScottはSales MUDディレクトリから参照およびチェックアウトのみ実行できます。Mainディレクトリは本番に実際に存在するマージされたマスターを保持する必要があるので存在し続けますが、Adamのみがそのディレクトリを参照および変更する権限を持ちます。
Eden Corporation社の最後のセキュリティ要件は、独立のセマンティック・モデル開発者がマージ後にオンライン・モードで稼働中のリポジトリにアクセスする機能を無効にすることです。リポジトリ・パスワードは1つしかないので、リポジトリのパスワードおよびアクセス権を持つ開発者はオフライン・モードでそのすべてのコンテンツを参照および変更できます。ただし、オンライン・モードでは、開発者はOracle BIサーバーにログオンするためにデータ・アクセス・ユーザー名とパスワードも必要です。このセキュリティ要件を施行するために、Adamは開発者が本番にログオンしたり、このように本番をテストする権限を与えないようにする必要があります。また、本番運用スタッフはリポジトリ・パスワードを自分たちしか知らないパスワードに変更できますが、リポジトリ・パスワードは管理ツールを使用して変更されるため、Windowsコンピュータでこのタスクを実行する必要があります。
SallyとScottは新しいセキュアな販売部のブランチMUDディレクトリからプロジェクトをチェックアウトして、作業を開始します。
Helenはセキュアな独立のセマンティック・モデルで1人で作業しているので、まだプロジェクトをチェックアウトする必要はありません。実際は、ローカル・コンピュータ上の新しいブランク・リポジトリからコンテンツの構築を開始する必要があります。彼女は、コンテンツの構築およびユニット・テストを通常の手順で段階的に実行します。
Helenはユニット・テストが完了すると、独立のリポジトリが完成します。彼女はそれをAdamに送信し、Adamは2方向マージを使用してそれをメイン・ブランチ・リポジトリに組み込みます。Adamは次の2つの手順を実行します。
最初に、Adamは2つのリポジトリを補正して、トップレベル・オブジェクトに付与された異なる名前を考慮してIDを再割り当てします。このプラクティスにより、マージ時に競合が発生しなくなります。
次に、Adamは「リポジトリ・マージ・ウィザード」を使用して2方向マージを実行してから、元のブランク・リポジトリを使用して完全なマージを実行します。
ヒント: ブランク・リポジトリを作成するには、「ファイル」→「新規リポジトリ」を選択して、名前(blank.rpdなど)とリポジトリ・パスワードを指定します。「メタデータのインポート」に「いいえ」を選択して「終了」をクリックします。
マージ後に、Adamは展開されるコンテンツを管理するための新しいプロジェクトhr_payrollを作成します。AdamはHelenのコンテンツをそのプロジェクトに追加します。また、それをメインからチェックアウトし、HR Branch MUDディレクトリに送信します。プロジェクトのチェックアウトを使用すると、後でIDおよびマージの管理が容易になります。
Adamは、接続プール・パラメータを調整して、リポジトリをテスト・コンピュータに移行します。不具合が見つかると、Helenはhr_payrollプロジェクトをチェックアウトし、そのユニット・テストを行ってから、チェックインして戻します(彼女の機能プロジェクトは、チェックアウトされたブランチ・プロジェクトからチェックアウトします)。Adamはそれを詳細にテストするためにテスト・システムに移行します。テストが完了したら、完成したHRブランチ・リポジトリをメイン・ブランチにチェックインして戻し、統合されたリポジトリをテスト・システムの統合テストに送信します。
統合されたリポジトリでテストが完了すると、本番への移行の準備が整います。ここでは、完全なリポジトリの移行、またはpatchrpdを使用した本番環境へのパッチの適用というオプションがあります。両方の方法ともローリング再起動が必要です。
この手順の実行後には、本番リポジトリにイニシアティブSとイニシアティブHの両方のコンテンツが格納されます。
