| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.1.0) E77227-02 |
|
 前へ |
 次へ |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 12c (12.2.1.1.0) E77227-02 |
|
|
前へ |
次へ |
架空の会社例の最初のフェーズでは、Sally AndreとScott Bakerの2人が並行して開発します。
Sallyが初期コンテンツを作成し、Adam Straightがそれを複数のプロジェクトに分割します。その後、彼はMUDディレクトリを作成し、SallyとScottがチェックアウトして開発を行えるようにします。ユニット・テストの後、彼らの変更をマージして公開し、その後、Adamがリポジトリをテスト環境に移行します。不具合の修正サイクルの後、Adamがリポジトリを本番にプロモートします。
次の項では、フェーズIの開発について説明します。
架空のMUDプロジェクトにおいて、Sally AndreがイニシアティブSを空のRPDから開始します。
いくつかの論理スターおよびサブジェクト・エリアを最初に定義している場合、リポジトリをMUDプロジェクトに分割する方が容易なため、始めにフェーズIに必要な物理モデルを開発します。独自のローカル・テスト・データソースの接続プールの詳細も含まれます。
ヒント:
物理モデルには、物理表、すべての物理表に別名を定義して意味のある名前を付けるためのベスト・プラクティス、および結合が含まれます。
この図は、イニシアティブSの物理モデルを示しています。
Sallyは、物理レイヤーをビジネス・モデルおよびマッピング・レイヤーにドラッグしていくつかの初期コンテンツを作成します。また、不要な表を削除したり、スター結合が正しくなるようにします。さらに、開発時に必要なすべての物理表が開始論理表からのマッピングを持たせ、チェックアウトするときにそれらがプロジェクトに含まれるようにします。Sallyはこれらの手順を使用してF10 RevenueおよびF50 Quotasの2つのファクト表を作成し、これらはプロジェクトの基盤として機能します。
また、Sallyはビジネス・モデルのプロジェクトをマップするためのサブジェクト・エリアをいくつか持つ必要があります。ビジネス・モデル全体をドラッグすることができますが、ビジネス・モデルを右クリックして「Logical StarsとSnowflakes向けのサブジェクト・エリアの作成」を選択するとこの機能をより便利に実行できます。この機能を使用すると、それぞれの論理ファクト表からサブジェクト・エリアを作成できます。
Sallyは、この時点でサブジェクト・エリアのコンテンツについて考慮する必要はありません。重要なのは各サブジェクト・エリアを同じプロジェクトの論理ファクト表にマップするということです。ただし、サブジェクト・エリアは管理ミーティングSales QuotaおよびSales Revenueで合意された計画に基づいて名前を付けます。
Sallyはこの時点で、RevenueおよびQuotaファクト表に基づいて最初の2つのプロジェクトを作成するための十分なMUD管理者のコンテンツを持ちます。これらを確認するには、Sallyは最低でも次の基準を満たしていることを確認する必要があります。
架空の会社例で、Eden Corporation社のMUD管理者Adam Straightは、ここで次の手順を実行してプロジェクトを作成し、それらをチェックアウトできるようにします。
Adam Straightは、MUDディレクトリ(RPD_main)を作成して、このディレクトリにマスターRPDを保存します。このマスターRPDには、開発者用のコンテンツのスーパーセットが含まれています。ユーザーはマスターからプロジェクトをチェックアウトし、変更を共有する場合は、そのプロジェクトをマスターに戻してマージします。Sallyは自分の初期RPDをマスター・フォルダにコピーし、Adamが最初の2つのプロジェクトProjRevenueとProjQuotaを作成できるようにします。
Adamは『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のマスターRPDを開き、「管理」→「プロジェクト」を選択します。次に、プロジェクト・マネージャで、「アクション」→「新規プロジェクト」を選択します。彼はこのプロジェクトに「ProjRevenue」という名前を付けてから、プロジェクトの中央の論理ファクト表を選択します。リストの一番上のオブジェクトが開き、論理ファクト表が表示されます。また、論理ファクト表が属するビジネス・モデルごと、またはサブジェクト・エリアごとにまとめて表示することもできます。
この図は、Adamが論理ファクト表を表示できる様々な方法を示しています。
Adamは、サブジェクト・エリアのグループを使用して同じファクト表を選択できたかもしれませんが、便宜上、ビジネス・モデルごとにファクトをグループ化することに決めます。彼はこのプロジェクトに指定されたファクト表、さらにデフォルトのアプリケーション・ロールおよびサブジェクト・エリアを追加します。カスタムで定義されたアプリケーション・ロール、ユーザー、変数または初期化ブロックはまだないため、それらをプロジェクトに追加することはできません。Adamは、2番目のプロジェクトのProjQuotaでもこの処理を繰り返します。
ヒント:
一部の明示的なオブジェクトは、両方のプロジェクトでアプリケーション・ロールを共有しているため、両プロジェクトで同一になります。同様に、多くの暗示的なプロジェクトのオブジェクトも共有されます(特に論理モデルと物理モデルの両方のディメンション表など)。プロジェクトは、作業が簡単になる小さなサブセットを作成する場合に役立ちます。プロジェクトは、セキュリティには向いていません。それぞれのトップレベル・オブジェクトの所有者がチーム全体に割り当てられてドキュメントが作成される管理プロセスにおいては、開発者が競合を回避できることからも、これは重要になります。
プロジェクトの論理ファクト表F10 Bill Revの所有者はSally Andreであり、このプロジェクトの所有者であるScott Bakerではありませんが、Adamはこれをこのプロジェクトに含めています。このようにした理由は、Scottが両方のファクト表のメジャー(販売ノルマの割合)から導出するメジャーを作成する必要があるためです。要は、ユーザーが所有するオブジェクトのみでなく、ユーザーの要件の実装に必要なコンテンツのサブセットもユーザーに提供されるということです。
Adamは、sales.rpdという名前でマスターRPDを共有ドライブRPD_Mainに保存します。これで、ユーザーはプロジェクトをチェックアウトし、作業を平行して進められるようになります。
2人の開発者は、マスター・リポジトリの管理ツール・クライアントを設定して、プロジェクトをチェックアウトし、作業を開始します。
Sallyはまず、マスター・リポジトリを使用するように管理ツール・クライアントを設定します。そのためには、「ツール」→「オプション」を選択してから、「マルチユーザー」タブを選択します。そこで、マスター・リポジトリ・ディレクトリへのポインタを設定します。また、ログやロックで便利になるので、彼女のフルネームも入力します。次に、彼女は自分のプロジェクトをチェックアウトして、そのプロジェクトでの作業を開始します。
一方、マスター・リポジトリ・ディレクトリには、sales.000とsales.mhlという2つの新しいファイルが作成されています。この図は、新しいファイルを示しています。
sales.000ファイルは、Sallyがsales.rpdをチェックアウトするときに作成されるsales.rpdの自動バックアップ・ファイルです。問題が発生した場合、このファイルを使用してロールバックできます。sales.mhlファイルでは、プロジェクト、コンピュータ、ユーザーなどのパラメータおよびチェックアウト・ステータスを追跡します。
一方、Sallyのローカル・リポジトリ・ディレクトリには、3つのファイルが作成されています。
originalProjRevenue.rpd: このファイルは、チェックアウト時のプロジェクト・サブセットRPDです。これは、3方向のマージ処理において後でオリジナルとして使用されます。またSallyが変更を廃棄する場合にも使用されます。
ProjRevenue.rpd: このファイルには、自己完結のサブセット・プロジェクト(ProjRevenue)のみが含まれます。これは、編集時に開くファイルです。
ProjRevenue.rpd.Log: このファイルは、管理ツールのこの編集セッション用のログ・ファイルです。管理ツールで、「ファイル」→「マルチユーザー」→「履歴」を使用して、そのコンテンツを表示できます。
この図は、ローカル・リポジトリ・ディレクトリの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にログインし、リポジトリ・ファイルをアップロードします。マスター・リポジトリではなく、ローカル・サブセット・リポジトリ(Sallyの場合はMUDチェックアウト・リポジトリ、ProjRevenue.rpd)をアップロードします。
また、問合せログの解析が容易になるように、Fusion Middleware ControlでOracle BIサーバー・キャッシュをオフにします。
さらに、Fusion Middleware ControlのBusiness Intelligence概要ページからシステム・コンポーネントを起動します。
ステップ2 - 5の詳細は、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 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 Business Intelligence Enterprise Editionセキュリティ・ガイドのアプリケーション・ロールの作成を参照してください。
次に、Sallyは新しいアプリケーション・ロールを彼女のリポジトリに追加して、それらをオブジェクトの権限およびデータ・アクセス・フィルタに使用する必要があります。そのためには、Sallyは次の処理を実行します。
Sallyが次に自分のプロジェクトをチェックアウトするときに新しい変数とアプリケーション・ロールがそれに含まれているようにするには、自分の変更をチェックインする前にプロジェクトにそれらを追加する必要があります。これを行うには、Adamがプロジェクトを作成したときと同じ手順を実行します。「管理」→「プロジェクト」を選択し、自分のプロジェクトを選択し、左のペインで新しいオブジェクトを選択して、「追加」をクリックします。
架空の会社例で、Sally AndreはProjRevenueプロジェクトで作業を行っていますが、Scott BakerはProjQuotaで作業を開始します。
彼はMUDの管理ツール・オプションを設定し、プロジェクトをチェックアウトして、作業を開始しています。
Scottは、オンライン・モードを選んで作業します。Oracle BIサーバーで稼働中にリポジトリを変更するので、オンライン・モードで作業することで開発とユニット・テストの循環が強化されます。管理ツールのツールバーで「変更のチェックイン」をクリックするたびに、稼働中のサーバーに変更が適用されます。その直後にアンサーに移動して、そこで変更をテストできます。プレゼンテーション・レイヤー・オブジェクトを追加、削除、名前変更または再編成する場合、アンサーの基準タブでメタデータをリロードして、そこに表示されているツリーをリフレッシュする必要があります。
最初に、Scottは自分のローカルOracle Business Intelligenceスタックを開始し、チェックアウト済のリポジトリをアップロードします。Oracle BIサーバーを再起動して、管理ツールを開き、オンライン・モードでリポジトリを開きます。
Scottは、接続プールの設定を変更し、自分のローカル・テスト・データベースを指すようにする必要があります。これは、マスター・リポジトリにはSallyの設定が含まれているためです。このマージ・プロセスで、これらの接続プールの変更は、すでにマスター・リポジトリに存在する接続プールによってオーバーライドされます。したがって、Scottは、次にチェックアウトするときに自分のローカル・テスト接続プールの変更を再び適用することが必要になります。
ヒント:
本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。詳細は、 Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンスの「テスト環境から本番環境への移行」を参照してください。
Scottの次のタスクは、キーを削除して彼の論理ファクト表をクリーンアップすることです。また、メジャーにSUM集計ルールおよび業務上わかりやすい名前(Quota Amount)を指定します。
F10論理表はSallyが所有しているので、Scottは表内の何も変更しません。彼女がマスターRPDに対して変更をマージおよび公開したら、彼も同じことを行います。そこで、彼は再度チェックアウトして彼女の変更を取得します。
次にScottは、「Sales percent of quota」という新しいメジャーをF50表に追加します。これは、次の式を使用して両方のファクト表から導出します。
"Sales"."F10 Billed Rev."."Revenue" / "Sales"."F50 Facts Quotas"."Quota Amount"
Sallyが自身のプロジェクトでRevenueの名前を変更しても、マージ処理ではそれが同じオブジェクトと識別され、Scottの式で同じ名前が使用されます。オブジェクトのアップグレードIDは元のIDと同一であるため、マージ・ロジックで名前の変更を識別できます。
最後に、Scottは、管理委員会のミーティングで彼が知ったことを忘れています。それは、Sallyがすべてのディメンションを所有していることです。彼は、PRODUCT DESCRIPTIONというD10 Product.Prod_Dsc列のすべてが大文字になっているバージョンを必要としています。彼は、Sallyが作成したものと同じ列を作成します。この誤りは、すぐに、公開手順の中のマージ・プロセスで検出され、解決されます。
Scottは、オンライン・モードで作業しているため、自分のリポジトリをアップロードしたり自分のシステムを再起動する必要はありません。そのかわり、変更をコミットした直後に、「変更のチェックイン」を使用してそのユニット・テストを行います。その間にSallyは、彼女の変更のテストを終えます。
Sallyは変更の最初のバッチの作成およびユニット・テストを終えたので、作業を保存してそれをマスター・リポジトリにマージします。
彼女は、「ファイル」→「マルチユーザー」→「ネットワークに公開」を選択します。新しいオブジェクトをプロジェクトに追加することを忘れても、詳細な警告が表示されるので、オブジェクトをプロジェクトに追加して再度マージできます。そうしないと、次に彼女がプロジェクトをチェックアウトしたときに、オブジェクトは抽出されません。
次に、他のユーザーがマージすることでSallyの変更が破損してしまうことなく彼女が自分の変更をマージできるように、管理ツールはマスター・リポジトリをロックします。
ヒント:
コメント・フィールドを使用して、公開する変更の説明を記録用に残しておくことをお薦めします。また、頻繁に公開すること、つまりサブセットのリフレッシュを実行することで、変更の追跡および後の履歴の監査が容易になります。さらに、管理ツールのモデリングでは、作業を段階的に行うことでテストを簡易化して各タスクの複雑性を低減することをお薦めします。
Sallyの変更により競合が発生することはないので、次に示す「マージ戦略の定義」の手順では競合について触れていません。ただし、プレゼンテーション・オブジェクトの別名は特殊なケースで、変更(ローカル・バージョン)、現行(マスター)、または2つのマージを保持することを選択できます。Sallyが列名を変更すると別名が自動的に作成されるため、新しい名前を本番に配置したときに、古い名前に記述されたレポートが破損することはありません。Eden Corporation社にはまだレポートがないため、「現行」を選択しても別名は空のままです。彼女は「Sales Revenue」、「Units Sold」および「Discount Amount」に対してこれを行います。
注意:
名前を複数回変更すると、一連の別名ができることがあります。古い名前を使用しているレポートのセットが存在する場合があるため、「マージ戦略の定義」画面で「選択内容のマージ」を選択して、「現行」に存在する別名および「変更」の新しい別名を保持できます。
マージ手順が完了すると、マスターsales.rpdは、Sallyによる変更で上書きされます。マージ・ログも保存されます。
架空の会社例で、Scottは、このフェーズの自分の開発作業を完了したので、「ファイル」→「マルチユーザー」→「サブセットのリフレッシュ」を選択し、サブセットのリフレッシュを実行して、自分の変更をマスター・リポジトリの最新バージョンにマージします。
「マージ戦略の定義」画面で、プレゼンテーション列Quota Amountに対して作成された別名を保持するかどうかが確認されます。Sallyと同様に、Scottも、現在のリポジトリの値(別名を使用しない)を保持することを選択します。
サブセットがリフレッシュされた後、Scottは再び簡単にユニット・テストを実行します。彼はテスト中に、Sallyのものと同じPRODUCT DESCRIPTIONという列を誤って作成していたことに気づきます。Scottの列は個別に作成されているので、内部アップグレードIDはSallyのものとは異なります。そのため、名前が同じでも、マージ・ロジックではそれを別の列と認識し、上書きされることなく、名前に「#1 (PRODUCT DESCRIPTION#1)」が付加されます。
Scottは外部列を削除し、自分のロジックをSallyのPRODUCT DESCRIPTION列に接続して、再度簡潔にテストしてから、ネットワーク・マスター・リポジトリに変更を公開します。
Scottが様々なユーザーのオブジェクトを削除または変更していると、エラーの解決は困難になることがあります。その場合、オブジェクトの再作成および補正、またはリポジトリのバックアップ・バージョンへのロールバックおよび彼の変更の再作成が必要になることがあります。
テスト環境のリポジトリの準備をするために、MUD管理者Adam Straightはここで、マスター・リポジトリで直接いくつかのタスクを実行する必要があります。
ここで、「ファイル」→「開く」→「オフライン」を使用します。
Adamはまず管理ツールを開いてからsales.rpdをオフライン・モードで開きます。その直後、他のユーザーはロックアウトされるので、それらのユーザーがプロジェクトをチェックアウトしようとするとWindows権限エラーが発生します。Adamが何度もファイルを開いたり閉じたりする必要がある場合、他のユーザーがそれぞれの変更の間にチェックアウトできないように、RPDをどこか他の場所で変更して共有ディレクトリからそれを削除する必要があります。
Adamはテスト環境に適合するように接続プール設定を変更します。管理ツール・ユーザーがプロジェクトをチェックアウトする場合、接続プール・パラメータはチェックアウトに含まれません。通常、MUDディレクトリのマスター・リポジトリにはテスト接続プールが含まれますが、個々の開発者は独自にテストデータベースに接続するために様々な設定が必要になる場合があります。マージおよび公開時は、マスター・リポジトリの接続プールは開発者の変更で上書きされないため、引き続き共有テスト・データベースを指すことができます。
また、Adamは新しいアプリケーション・ロールがテスト・システムに移行されていることを確認する必要があります。このロールは2つしかないので、彼はテスト・システムのFusion Middleware Controlでそれらを再入力することにします。さらに、Adamはいくつかのテスト・ユーザーまたはグループを新しいアプリケーション・ロールにプロビジョニングして、セキュリティ・フィルタ、権限および問合せ制限をテストできるようにします。
最後に、Adamはリポジトリをテスト・システムをアップロードし、Oracle BIサーバーを再起動します。ローカルの管理ツールを使用して、テストOracle BIサーバーをオンライン・モードで接続し、整合性チェッカを実行します。このリポジトリで参照されるいずれかのアプリケーション・ロールに欠落またを不正があると、整合性チェッカでそのエラーのリストが出力されます。
架空の会社例を検討して、マルチユーザー開発環境でのテストについて学習します。
この時点でテスト・チームはリポジトリをテストできます。テスト中に、テスト・チームは"Sales"."F50 Facts Quotas"."Sales percent of quota"が式sales/quotaではなくquota/salesで誤って作成されているという不具合を発見します。テスト・チームは不具合レポートを記述し、不具合の修正はScott Bakerが割り当てられます。
Scottは管理ツールを開いて、ProjQuotaをチェックアウトし、変更を行い、ローカル・テスト・データベースを指すように接続プールを変更して独自のサンドボックスでテストします。その後、彼は変更を共有MUDディレクトリに公開します。彼は、不具合が修正され、リポジトリは再度テストするために送信する準備ができたことをAdamに通知します。
MUD機能によりマスター・リポジトリはチェックアウトされたプロジェクトの接続プールの変更から隔離されるので、Adamは接続プールが正しいテスト・システムで指定されていることを認識できます。リポジトリをアップロードして、Oracle BIサーバーを再起動します。
テスト・チームは完成するまでテストを行い、本番用のリポジトリはクリアされます。
リポジトリがテスト・フェーズで合格すると、リポジトリを本番にアップロードする前に、リポジトリのデータベース接続パラメータを更新する必要があります。
アプリケーション・ロールを移行およびプロビジョニングする必要もあります。
管理チームが立てた計画に基づき、本番運用チームは新しいアプリケーション・ロールが必要なことを認識します。本番運用チームは、Adamと同様に、テスト環境に新しいアプリケーション・ロールを作成します。また、管理チームからのセキュリティ仕様に基づき、ユーザーまたはグループをそれらのアプリケーション・ロールにプロビジョニングします。
本番に移行する前に、Adamは、接続プール・パラメータを本番データベースに必要な値に変更する必要があります。Eden Corporation社では、Adamは本番接続プールを表示する権限を持っていますが、他のリポジトリ開発者は持っていません。したがって、Adamかテストから本番に接続プールを変更できず、リポジトリをマスター・ディレクトリに残したままにします。それは、開発者が、それを読み取って書き込むためのWindows権限を持っているためです。かわりに、彼は本番に必要な接続プールのXMLパッチを作成します。次に、彼は、sales.rpdをセキュアなディレクトリにコピーし、そのパッチを適用してから、テストを実行してそれが実際に本番データ・ソースに接続していることを確認します。その後、リポジトリを本番システムにアップロードし、本番クラスタのサーバーを起動します。
ヒント:
本番および他の環境への移行時に必要な接続プールの変更を自動化するには、Oracle BIサーバーXML APIを使用します。詳細は、Oracle Business Intelligence Enterprise Edition XMLスキーマ・リファレンスの「テスト環境から本番環境への移行」を参照してください。
マスター・リポジトリはまだテスト・データベースを指しているため、管理ツール・ユーザーはそれを参照できます。一方、本番リポジトリの新しいバージョンは、XMLパッチ・ファイルの接続プールの変更を適用することで、いつでも構築できます。
ここで本番の検証が実行されます。テスト・システムへの移行と同様に、重要な検証では、アプリケーション・ロールがすべて正しくなるように、オンライン・モードで整合性チェッカが実行されます。この検証が完了すると、フェーズIは本番になります。
