| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 11g リリース1 (11.1.1) B63028-05 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Business Intelligence Enterprise Editionメタデータ・リポジトリ作成者ガイド 11g リリース1 (11.1.1) B63028-05 |
|
前 |
次 |
この章では、ビジネス・モデルを計画する方法、ビジネス・モデルの物理コンテンツを操作する方法、リポジトリ設計の全般的なガイドラインなど、Oracle Business Intelligenceメタデータ・リポジトリを計画および設計する方法について説明します。
メタデータ・リポジトリを効果的に計画して作成するには、SQL問合せに関する経験があり、レポートと分析に精通している必要があります。また、業界標準のデータ・ウェアハウス・モデリングの実践経験があり、一般的なリレーショナルE-Rモデリングに精通している必要があります。
この章には次のトピックが含まれます:
Oracle BIサーバーとOracle BIリポジトリのアーキテクチャによって、ユーザーが複雑なフェデレーテッド・データ・ソースに対する単純な論理SQL問合せを送信できる抽象化のレイヤーが提供されます。
この項には次のトピックが含まれます:
Oracle BIサーバーは、ユーザー・リクエストを処理し、基礎となるデータ・ソースに問い合せるOracle Business Intelligenceコンポーネントです。Oracle BIサーバーは論理データ・モデルを保持し、ODBCを介してそのモデルへのクライアント・アクセスを提供します。
Oracle BIサーバーは、Oracle BIリポジトリ内のメタデータを使用して、次の2つのタスクを実行します。
論理SQL問合せを解析し、適切なデータ・ソースに対する対応する物理問合せを作成します。
物理結果セットを変換および結合し、最終的な計算を実行します。
Oracle BIサーバーは、ODBC、またはOracle DatabaseのOCIなどのネイティブAPIを介して基礎となるデータ・ソースに接続します。
管理ツール・クライアントは、Oracle BIリポジトリの作成や編集に使用できるWindowsアプリケーションです。管理ツールは、オフライン・モードでリポジトリに直接接続することも、Oracle BIサーバーを経由してリポジトリに接続することもできます。オンライン・モードで使用できるのは一部のオプションのみです。詳細は、「オンラインとオフラインのリポジトリ・モードの使用」を参照してください。
図1-1に、Oracle BIサーバーが問合せクライアント、データ・ソース、Oracle BIリポジトリおよび管理ツールとどのように連携するかを示します。
例1-1に、Oracle BIサーバーが論理SQL問合せをどのように解析および変換するかを示します。
例1-1 論理リクエストから複雑な物理問合せへの変換
Oracle BIサーバーが次の単純なクライアント・リクエストを受け取るとします。
SELECT "D0 Time"."T02 Per Name Month" saw_0, "D4 Product"."P01 Product" saw_1, "F2 Units"."2-01 Billed Qty (Sum All)" saw_2 FROM "Sample Sales" ORDER BY saw_0, saw_1
Oracle BIサーバーはその後、次のように論理SQL問合せを高度な物理問合せに変換します。
WITH SAWITH0 AS ( select T986.Per_Name_Month as c1, T879.Prod_Dsc as c2, sum(T835.Units) as c3, T879.Prod_Key as c4 from Product T879 /* A05 Product */ , Time_Mth T986 /* A08 Time Mth */ , FactsRev T835 /* A11 Revenue (Billed Time Join) */ where ( T835.Prod_Key = T879.Prod_Key and T835.Bill_Mth = T986.Row_Wid) group by T879.Prod_Dsc, T879.Prod_Key, T986.Per_Name_Month ) select SAWITH0.c1 as c1, SAWITH0.c2 as c2, SAWITH0.c3 as c3 from SAWITH0 order by c1, c2
Oracle BIリポジトリには次のレイヤーがあります。
物理レイヤー。このレイヤーでは、Oracle BIサーバーが各物理データ・ソースに対するネイティブな問合せを作成するために必要とするオブジェクトとリレーションシップが定義されます。このレイヤーを作成するには、データ・ソースから表、キューブおよびフラット・ファイルをインポートします。
アプリケーションの論理動作を物理モデルから切り離すと、複数の物理ソースを同じ論理オブジェクトにフェデレートできるため、集計ナビゲーションやパーティション化のほか、ディメンションの適合や物理ソース内の変更からの分離が可能になります。また、この切り離しによって、ポータブルなBIアプリケーションの作成も可能になります。
ビジネス・モデルとマッピング・レイヤー。このレイヤーでは、データのビジネス・モデルまたは論理モデルが定義され、ビジネス・モデルと物理スキーマ間のマッピングが指定されます。このレイヤーによって、ユーザーから見える分析動作が決まり、ユーザーが使用できるオブジェクトおよびリレーションシップのスーパーセットが定義されます。ソース・データ・モデルの複雑さも認識されなくなります。
ビジネス・モデルの各列は、物理レイヤーの1つ以上の列にマップします。実行時に、Oracle BIサーバーがビジネス・モデルに対する論理SQL問合せを評価し、マッピングを使用して、必要な物理問合せを生成するための物理表、ファイルおよびキューブの最適なセットを決定します。多くの場合、マッピングには計算と変換が含まれ、複数の物理表が結合されることがあります。
プレゼンテーション・レイヤー。このレイヤーは、カスタマイズされた、ロール・ベースのセキュアなビジネス・モデルのビューをユーザーに表示する方法を提供します。また、ビジネス・モデルとマッピング・レイヤーに抽象化のレベルを加え、プレゼンテーション・サービスやその他のクライアントでリクエストを作成するユーザーに表示されるデータのビューを提供します。
1つのビジネス・モデルにマップする複数のサブジェクト・エリアをプレゼンテーション・レイヤーに作成することで、ビジネス・モデルを管理可能な部分に効果的に分割できます。
管理ツールでリポジトリのレイヤーを作成する前に、ユーザーの分析要件に基づいて、ビジネス・モデルとマッピング・レイヤーの大まかな設計を作成しておくことが重要です。作業の指針となる概念設計を作成したら、メタデータ・オブジェクトを作成できます。
通常は、物理レイヤー、ビジネス・モデルとマッピング・レイヤー、プレゼンテーション・レイヤーの順にオブジェクトを作成します。ただし、どの段階でも各レイヤーの作業を行うことができます。3つのレイヤーがすべて完成したら、リポジトリのテストを開始する準備をする際に、セキュリティを設定できます。
図1-2に、論理SQL問合せがどのようにOracle BIリポジトリのレイヤーを通過するかを示します。
1つのOracle BIリポジトリには、エンタープライズ全体の1つの統合モデルではなく、複数の独立セマンティック・モデルを格納できます。セマンティック・モデルは、1つのビジネス・モデル、プレゼンテーション・レイヤーと物理レイヤー内の関連オブジェクト、および変数、初期化ブロック、アプリケーション・ロールのようなその他の関連オブジェクトで構成されます。セマンティック・モデルは、共通エンタープライズ情報モデルとも呼ばれます。
複数のセマンティック・モデルを視覚的に示した図A-4も参照してください。
ビジネス・モデルの計画は、意志決定支援に使用可能なデータ・モデルを開発する際の最初の手順です。この項で説明するガイドラインに従って計画した後、リポジトリの作成を開始できます。
最初の作業は、ビジネス・モデルの要件を十分に理解することです。必要な物理レイヤーを決定するにはまず、作成するビジネス・モデルを理解しておく必要があります。
意志決定支援環境では、データ・モデリングの目的は、ビジネス・アナリストによるビジネス構造の理解と同様にビジネス情報を表すモデルを設計することです。適切なモデルを設計すると、アナリストはビジネス上の質問をするのと同様に直感的に問合せを構成できるため、問合せプロセスが自然なプロセスとなります。このモデルは、ビジネス・アナリストが本質的に理解し、有効な質問に正しく回答するものである必要があります。
Oracle BI Publisherなどの視覚的なSQLツールとは異なり、ビジネス・モデルではBIアプリケーションの分析動作を定義します。一方、物理レイヤーでは、ビジネス・モデル・ロジックからマップされた物理問合せをまとめるために使用されるコンポーネントのみが提供されます。
これには、ビジネスを複数のコンポーネントに分割して、次の質問に回答する必要があります。
アナリストはどのようなビジネス上の質問に回答しようとしていますか。
ビジネス・パフォーマンスを理解するためにどのようなメジャーが必要ですか。
ビジネスの運営の基準とするディメンションをすべてあげてください。つまり、測定を分割してレポートのヘッダーとして使用するディメンションをあげてください。
各ディメンションに階層要素はありますか。各階層はどのようなリレーションシップによって定義されますか。
これらの質問に回答したら、ビジネス・モデルの要素を特定し、定義できます。
ビジネス・モデルに含めるコンテンツを決定するにはまず、ユーザーが問い合せる必要がある論理列を特定する必要があります。次に、各列のロールをメジャー列、またはディメンション属性のいずれかとして特定する必要があります。最後に、関連するロール、列間のリレーションシップ、およびロジックに基づいて、論理列をディメンション・モデルに配置します。
ビジネスは関連するディメンション基準によって分析されるため、これらの関連するディメンションからビジネス・モデルを開発します。これらのディメンション・モデルは、Oracle BIサーバーで使用する有効なビジネス・モデルの基盤となります。
すべてのディメンション・モデルがスター・スキーマに基づいて作成されるわけではありませんが、ビジネス・モデル・レイヤーでは単純なスター・スキーマを使用することをお薦めします。つまり、ディメンション・モデルは、様々なディメンション属性に関して表示される測定可能なファクトを表す必要があります。
ビジネス・モデルの要件を分析したら、ビジネス・モデルに含める必要がある具体的な論理表や階層を特定する必要があります。
この項には次のトピックが含まれます:
ビジネス・モデルとマッピング・レイヤーの論理ファクト表には、集計が定義に組み込まれているメジャーが含まれます。論理ファクト表は、表の最下位単位でファクトを定義するリレーショナル・モデルの物理ファクト表とは異なります。
ファクトから集計されるメジャーは、論理ファクト表で定義する必要があります。メジャーは通常、売上額や販売数量のような計算データで、ディメンションに関して指定できます。たとえば、特定の期間における特定の市場での特定の製品の売上合計を求めることができます。
各メジャーには、SUM、AVG、MIN、MAXなどの独自の集計ルールがあります。企業はメジャーの値を比較したり、比較を表す計算を作成することができます。また、特定のディメンションに固有の集計ルールを定義することもできます。Oracle BIサーバーでは、ディメンション固有の複雑な集計ルールを定義できます。
ビジネス・モデルとマッピング・レイヤーの表は、ファクト表またはディメンション表として明示的に指定されるわけではありません。Oracle BIサーバーでは、結合の「1」側の表がディメンション表として扱われ、結合の「多」側の表がファクト表として扱われます。
図1-3は、ビジネス・モデル図におけるファクト表への多対1結合を示しています。この図では、すべての結合は、Fact-Pipeline表から発する(1方向の)矢印を持っており、その表を指す結合はありません。ビジネス・モデルにおけるこの例については、管理ツールでリポジトリを開き、ファクト表を右クリックし、「ビジネス・モデル図」→「図全体」を選択します。
企業では、ファクトを使用して、時間、製品、市場など、適切に確立されたディメンションによってパフォーマンスを測定します。すべてのディメンションに説明属性のセットがあります。ディメンション表には、ビジネス・エンティティ(顧客名、地域、住所、国など)を説明する属性が格納されています。また、各メンバーを特定する主キーも格納されています。リレーショナル・モデルの物理ファクト表とは異なる論理ファクト表とは違い、論理ディメンション表の動作はリレーショナル・ディメンション表と非常によく似ています。
ディメンション表の属性によって、サービス・リクエストを分類できるなど、数値データにコンテキストが提供されます。このディメンションに保存される属性には、サービス・リクエストの所有者、領域、アカウント、優先度などがあります。
ビジネス・モデルのディメンションは、適合済ディメンションです。つまり、特定のデータ・ソースに特定のCustomer表の5つの異なるインスタンスがある場合でも、ビジネス・モデルの表は1つだけです。これを実現するために、Customerの5つの物理ソース・インスタンスすべてが1つのCustomer論理表にマップされ、必要に応じて論理表ソースで変換が行われます。適合済ディメンションによって、ユーザーには物理レイヤーの複雑さが認識されず、様々な単位の複数のファクト・ソースのデータを結合できます。また、複数のデータ・ソースをフェデレートすることもできます。
ビジネス・モデルのディメンションおよびレベル・キーは、生成された代理キーではなく、ビジネス・キーである必要があります。つまり、「1076823」のような値を持つ「Customer Key」ではなく、「Oracle」のような値を持つ「Customer Name」を使用してください。ビジネス・モデルでビジネス・キーを使用することで、そのディメンションのすべてのソースを、同じ論理キーおよびレベル・キーを持つ同じ論理ディメンション表に適合させることができます。
生成された代理キーは、結合における問合せのパフォーマンスを向上させるうえで役立つため、物理レイヤーに残しておいてもかまいませんが、通常、ビジネス・モデルとマッピング・レイヤーに代理キー列はありません。
ディメンションは、ビジネスを定義するための属性のカテゴリです。一般的な属性としては、期間、製品、市場、顧客、仕入先、プロモーション条件、原材料、製造工場、輸送手段、メディアの種類、時刻などがあります。特定のディメンション内に多数の属性がある場合があります。たとえば、期間ディメンションには、属性として日、週、月、四半期および年を含めることができます。ディメンションに含まれる属性は、ビジネスをどのように分析するかによって決まります。
ディメンションには通常、ディメンション内のメンバー間のトップダウン・リレーションシップのセットである階層が含まれています。階層には、レベル・ベース階層(構造階層)と親子階層(値階層)の2種類があります。レベル・ベース階層は、同じタイプのメンバーが1つのレベルにのみ存在する階層です。一方、親子階層のメンバーはすべて同じタイプです。Oracle Business Intelligenceでは、時系列データをモデリングするための特殊な機能を備えた、時間ディメンションと呼ばれる特殊なタイプのレベル・ベース・ディメンションもサポートされます。
レベル・ベース階層では、下位レベルから上位レベルへとレベルがロールアップされます。たとえば、月を年にロールアップできます。このようなロールアップは階層要素全体で行われ、存在するビジネス・リレーションシップにまたがります。
親子階層では、組織階層ツリーの管理者-従業員リレーションシップなど、実際の同一タイプの異なるメンバー間にビジネス・リレーションシップが存在します。親子階層には、明示的に指定されたレベルはありません。親子階層内の暗黙レベルの数に制限はありません。
階層を定義するには、すべての計算におけるロールアップ集計、およびレポートやダッシュボードにおけるドリルダウン・ナビゲーションを容易にするための「含む」リレーションシップをビジネス(地理、製品、時間など)に定義します。たとえば、月が年にロールアップされ、集計表が月レベルに存在する場合、月レベルのすべてのデータを合計して年のデータを計算することによって、その表を使用して年レベルの質問に回答できます。
ニーズに合せて適切なタイプの階層を使用することが重要です。使用するタイプを決定するには、次の点を検討してください。
すべて同じタイプのメンバーであるか(従業員、組立品、顧客など)、基本的にレベルに分類される別のタイプのメンバーであるか(年-四半期-月、大陸-国-都道府県、ブランド-ライン-製品など)。
メンバーの属性セットが同じかどうか。たとえば、Employeesのような親子階層では、すべてのメンバーにHire Date属性があると考えられます。一方、Timeのようなレベル・ベース階層では、DayタイプにはHoliday属性がありますが、Monthタイプにはありません。
設計時にレベルが固定されているか(年-四半期-月)、実行時のビジネス・トランザクションによってレベルが増えたり減ったりする可能性があるか。たとえば、現在の最下位の従業員が、新たに最下位となる部下を雇用した場合、レベルが追加される可能性があります。
特定の階層タイプを必要とする制約がプライマリ・データ・ソースにあるかどうか。プライマリ・データ・ソースがいずれかの階層タイプでモデリングされている場合、他の要素に関係なく、ビジネス・モデルで同じ階層タイプを使用する必要があります。
詳細は、第10章「論理ディメンションの操作」を参照してください。
ディメンションに複数の階層が含まれる場合があります。たとえば、Timeディメンションには多くの場合、暦年を表す階層と会計年度を表す階層があります。複数の階層を持つディメンションは必ず、同じリーフ表で終わる必要があります。
図1-4に、管理ツールのビジネス・モデルとマッピング・レイヤーに表示された、複数の階層を持つディメンションを示します。
多言語スキーマから翻訳されたフィールド情報を表示する必要がある場合は、物理レイヤーの参照表に対応する論理参照表を作成します。参照表には、ベース表の行に対応する多言語データが格納されます。特定の論理参照表を使用するには、「論理表」ダイアログの「一般」タブでその表を参照表として指定する必要があります。ローカライズと参照表の詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のOracle Business Intelligenceのローカライズに関する項を参照してください。
ローカライズに加えて、ある値セットをユーザーに表示し、対応する別の値セットを物理問合せで使用する場合にも、参照表を使用できます。必要に応じて、まったく異なるデータ・ソースで判読可能な値を参照できます。
ビジネス・モデルの要件を特定したら、物理レイヤーに必要なデータ・ソース・コンテンツを確認できます。常にディメンション化されるビジネス・モデルとマッピング・レイヤーとは異なり、各物理モデルはソースの形状(正規化、キューブなど)を反映します。
この項には次のトピックが含まれます:
どの物理ソースのモデルも、ディメンション化された重複するサブセットに分割できるため、Oracle BIリポジトリでは、タイプに関係なく物理スキーマを適切にモデリングできます。
次の4種類の物理スキーマ(モデル)があります。
スター・スキーマ。スター・スキーマは、複数のディメンション表への外部キー結合関係を持つファクト表がそれぞれ1つずつあるディメンション・スキーマ(スター)のセットです。スターをビジネス・モデルにマップする際にはまず、物理ファクト列を1つ以上の論理ファクト表にマップします。次に、そのスターの物理ファクト表に結合するそれぞれの物理ディメンション表について、物理ディメンション列を適切な適合済論理ディメンション表にマップします。
スノーフレーク・スキーマ。スノーフレーク・スキーマはスター・スキーマと同様ですが、各ディメンションが、結合された複数の表で構成される点が異なります。スター・スキーマと同様に、まず、物理ファクト列を1つ以上の論理ファクト表にマップします。次に、それぞれのディメンションについて、スノーフレーク化された物理ディメンション表を1つの論理表にマップします。そのためには、複数の論理表ソースを使用するか、結合がある1つの論理表ソースを使用します。
正規化スキーマ。正規化スキーマでは、データ保存の冗長性を最小限に抑え、データの更新を最適化するために、データ・エンティティが複数の表に分散されます。正規化スキーマをビジネス・モデルにマップする前に、ファクトとディメンションに関して分散構造を理解しておく必要があります。
構造を分析したら、ファクト列を持つ表を選択し、物理ファクト列を1つ以上の論理ファクト表にマップします。次に、その物理ファクト列のセットに関連するそれぞれのディメンションについて、ディメンション列を含む分散物理表を1つの論理表にマップします。そのためには、スノーフレーク・スキーマと同様に、複数の論理表ソースを使用するか、結合がある1つの論理表ソースを使用します。まず特定のファクト・セットをマップし、次に関連するディメンションをマップした後、次のファクト・セットに進むため、正規化スキーマのマッピングは反復プロセスです。
1つの物理表にファクト列とディメンション列の両方がある場合は、その表が果たす複数の役割を処理するために、物理別名表の作成が必要になることがあります。
完全非正規化スキーマ。このタイプのディメンション・スキーマは、ファクトとディメンションを列として1つの表(またはフラット・ファイル)に結合し、他のタイプのスキーマとは異なる方法でマップされます。完全非正規化スキーマを星形のビジネス・モデルにマップする際には、1つの物理ファクト表の物理ファクト列をビジネス・モデル内の複数の論理ファクト表にマップします。次に、物理ディメンション列を適切な適合済論理ディメンション表にマップします。
キューブはメジャーで構成され、ディメンションによって編成されます。すでにディメンション化されているため、各キューブは、ビジネス・モデルの論理ファクト表および論理ディメンション表に簡単にマップします。
メジャーとディメンションに関する次の点に注意してください。
マルチディメンション・キューブとリレーショナル・ファクト列のメジャーはどちらも、ビジネス・モデルとマッピング・レイヤーの論理メジャーにマップします。ただし、ビジネス・モデルで計算と集計を適用する必要があるリレーショナル・ファクト列とは異なり、マルチディメンション・キューブのメジャーには、計算と集計がすでに組み込まれています。リレーショナル・ソースのようなキューブを処理するのではなく、Oracle BIサーバーは、キューブ内のあらかじめ集計されたデータと強力な計算を利用できます。
マルチディメンション物理オブジェクトとリレーショナル物理オブジェクトはどちらも、ビジネス・モデルとマッピング・レイヤーの論理ディメンションにマップします。ただし、リレーショナル・ソースとは異なり、マルチディメンション・データ・ソースには、ディメンションおよび階層セマンティックがすでに組み込まれています。Oracle BIサーバーは、インポート時にも問合せ時にも、キューブ内のより完全な階層およびディメンションのサポートを利用できます。
管理ツールによって、データ・ソース内の基礎となる物理表に論理表をマップするためのインタフェースが提供されます。表をマップするには、ビジネス・モデルに関連する物理データ・ソースのコンテンツを特定しておく必要があります。これを正しく行うためには、物理データ・ソースの次のコンテンツを特定する必要があります。
各表のコンテンツの特定
各表の詳細レベルの特定
各集計表の表定義の特定。これによって、集計ナビゲーションを設定できます。Oracle BIサーバーでは、次の詳細が必要です。
表のグループ化に使用する列(集計レベル)
集計のタイプ(SUM、AVG、MIN、MAXまたはCOUNT)
リポジトリで集計ナビゲーションを設定する方法については、第11章を参照してください。
各列のコンテンツの特定
メジャーの計算方法の特定
データベースに定義されている結合の特定
データに関するこれらの情報を入手するには、データ・ソースが実装されたときに作成されたデータ要素を説明するドキュメントを参照してください。これらの情報を入手するために、各データ・ソースについてDBAと協力することが必要になる場合があります。すべてのデータ要素を完全に理解するには、組織内のデータのユーザー、データの所有者、またはデータを作成するアプリケーションのアプリケーション開発者に質問する必要がある場合もあります。
ビジネス・モデルのニーズを分析し、ビジネスに必要なデータベース・コンテンツを特定したら、リポジトリの設計を行うことができます。この項では、より効率的なリポジトリを実装するために役立つ設計のベスト・プラクティスを紹介します。
通常は、データベースをインポートしてテストするまで、パフォーマンス・チューニングの変更は行わないでください。これらの作業は、リポジトリの設定を完了する最終手順で行います。これらの最終手順の詳細は、第15章を参照してください。
この項には次のトピックが含まれます:
Oracle BIリポジトリを構成する際には、次の設計方針に従うことをお薦めします。
オンライン・モードで作業する場合、1つの作業が完了するたびに作業の前後にオンライン・リポジトリのバックアップを保存します。必要に応じて、「ファイル」メニューの「名前を付けてコピー」を使用して、変更内容を含むオフライン・コピーを作成してください。
管理ツールの物理図を使用して、ソースと結合を確認します。
データベースとリポジトリのどちらで行レベルのセキュリティ制御を設定するかを決定します。この決定によって、接続プールとキャッシュを共有するかどうかが決まります。また、開発に含める個々のソース・データベースの数が制限される場合があります。詳細は、第14章「リポジトリ・オブジェクトへのデータ・アクセス・セキュリティの適用」を参照してください。
管理ツールのほとんどの図には、作業の実行方法に関する情報を提供するヘルプが用意されています。ヘルプ・トピックにアクセスするには、ダイアログで「ヘルプ」ボタンをクリックするか、一部のメニューから「ヘルプ」を選択します。
物理レイヤーには、物理データ・ソースに関する情報が格納されます。物理レイヤーでスキーマを作成する際の最も一般的な方法は、データベースなどのデータ・ソースからメタデータをインポートする方法です。メタデータをインポートすると、インポート・プロセスで収集された情報に基づいて、多くのプロパティが自動的に構成されます。また、データ・ソースのメタデータには存在しない場合がある、物理データ・ソースの他の属性(結合関係など)を定義することもできます。
物理レイヤーには、マルチディメンション、リレーショナル、XMLソースなど、様々なタイプのデータ・ソースを含めることができます。サポートされるデータベースについては、「システム要件と動作要件」を参照してください。
データ・ソースごとに、対応する接続プールが少なくとも1つずつあります。接続プールには、データ・ソースへの接続に使用されるデータ・ソース名(DSN)、許可される接続の数、タイムアウトなど、接続関連の詳細な管理情報が格納されています。詳細は、「接続プールについて」を参照してください。
物理レイヤーを設計する際のヒントは次のとおりです。
物理レイヤーでは表の別名を頻繁に使用して、次のような無関係な結合を削除することをお薦めします。
物理表の別名を作成することによって、物理モデルの論理表ソースにおける循環結合(ディメンション間の循環結合)をすべて削除します。
たとえば、出荷先住所の参照に使用できるCustomer表があり、別の結合を使用して請求先住所を参照できるとします。循環結合を避けるには、それぞれの結合で、用途ごとに1つのインスタンスが存在するように物理レイヤーに別名表を作成します。
循環結合を削除しなかった場合、レポート結果が正しくなくなることがあります。さらに、問合せのパフォーマンスが低下する可能性もあります。
ある論理表ソースでは結合を内部結合にし、別の論理表ソースでは外部結合にする必要がある場合は、別名表を使用して別の物理結合を作成することをお薦めします。
すぐには使用しないものの、削除はしたくない表を物理レイヤーにインポートできます。ビジネス・モデルとマッピング・レイヤーですぐに使用しない表を特定するには、物理表に別名を割り当ててから、ビジネス・モデル・レイヤーにマップします。
|
注意: 別名を割り当てた表の名前を表示するには、「ツール」→「オプション」→「一般」で「図の別名に対する元の名前の表示」を選択します。 |
不透明なビュー(1つのSELECT文で構成される物理レイヤー表)を使用するのは、モデリングの問題に対する解決策がそれ以外にない場合のみにしてください。物理表、またはマテリアライズド・ビューを作成することをお薦めします。不透明なビューには、基礎となるデータ・ソースに送信される固定されたSQL文が含まれるため、Oracle BIサーバーは、最適化された独自のSQLを生成できません。
ビジネス・モデルとマッピング・レイヤーでは、ビジネス・モデルによって情報が編成されます。このレイヤーでは事実上、各ビジネス・モデルが別個のアプリケーションとなります。
各ビジネス・モデルで定義された論理スキーマには、論理表を少なくとも2つ含める必要があります。すべての論理表間にリレーションシップを定義する必要があります。ビジネス・モデルのスキーマの詳細は、「Oracle BIリポジトリのレイヤーについて」を参照してください。ビジネス・モデルとマッピング・レイヤーの設定の詳細は、第9章を参照してください。
ビジネス・モデルとマッピング・レイヤーを設計する際のヒントは次のとおりです。
可能であれば、論理ディメンション表とファクト表間に1対多の論理結合を持つビジネス・モデルを作成します。各ファクト表がそのディメンションに直接結合される単純なスター・スキーマのようなビジネス・モデルを作成することをお薦めします。
すべての論理ファクト表を少なくとも1つの論理ディメンション表に結合する必要があります。ソースが完全非正規化表またはフラット・ファイルである場合は、その物理ファクト列を1つ以上の論理ファクト表にマップし、その物理ディメンション列を論理ディメンション表にマップする必要があります。
すべての論理ディメンション表にディメンション階層が関連付けられている必要があります。シナリオ・ディメンション(実績、予測、計画)のように階層のレベルが1つだけの場合でも、このルールが適用されます。
レベル・ベース・メジャーを作成する際には、集計内容を使用して、適切なファクト・ソースすべてを階層内の適切なレベルにマップしてください。メジャーの集計内容は、「論理列」ダイアログの「レベル」タブで設定します。これは、マップ先のソース表の単位を指定する際に使用する「論理表ソース」ダイアログの「内容」タブとは異なります。
「論理列」ダイアログの「レベル」タブで集計内容を設定するのは、レベル・ベース・メジャーのみでかまいません。レベル・ベースでないメジャーについては、「論理レベル」フィールドを空白のままにしてください。
通常、論理ファクト表にはキーを含めないでください。ただし、キーを必要とする論理SQL問合せをクライアントからOracle BIサーバーに対して送信する必要がある場合は除きます。この場合は、論理ファクト表とプレゼンテーション・レイヤーの両方でキーを公開する必要があります。
通常、論理ファクト表内の列はすべて集計メジャーです。ただし、外部クライアントで必要とされるキーや、区切りとして使用されるダミー列は除きます。その他の非集計列は、論理ディメンション表に存在する必要があります。
場合によって、1つのビジネス・モデルに複数の論理ファクト表を含めることができます。論理SQL問合せについては、複数の論理ファクト表が1つの表のように動作します。
複数の論理ファクト表を含める理由としては、次のようなものがあります。
プロジェクトを割り当てます。詳細は、「プロジェクトの設定」を参照してください。
プレゼンテーション・レイヤーに小さいサブジェクト・エリアを自動的に作成します。詳細は、「論理的なスターとスノーフレークに基づくサブジェクト・エリアの自動作成」を参照してください。
わかりやすく編成します。
リレーショナル・ファクト表とは異なり、論理ファクト表には様々な単位のメジャーを含めることができます。そのため、単位は、論理ファクト表を分割する理由にはなりません。
計算は、次のいずれかの方法で定義できます。
集計前に、論理表ソースで定義します。例:
sum(col_A *( col_B))
集計後に、他の2つの論理列から派生した論理列で定義します。例:
sum(col A) * sum(col B)
アンサーまたは論理SQL問合せで集計後計算を定義することもできます。
Oracle Scorecardと戦略管理を使用する予定がある場合は、KPIに使用するOracle BIリポジトリに時間ディメンションを少なくとも1つ実装することをお薦めします。この処理が必要なのは、スコアカードでKPIを使用して、時間の経過に伴う進捗とパフォーマンスを測定するためです。スコアカードでKPIによって使用されるディメンションは、個々のスコアカードによって自動的にインクルードされます。
集計ソースは、別個の論理表ソースとして作成する必要があります。ファクト集計については、「論理表ソース」ダイアログの「内容」タブを使用して、適切な論理レベルを各ディメンションに割り当ててください。
階層内の各ディメンション・レベルには一意のレベル・キーが必要です。また、各論理ディメンション表には一意の主キーが必要です。このキーは通常、最下位階層レベルのレベル・キーとしても使用されます。
ビジネス・モデルとマッピング・レイヤーで列の名前を変更すると、「論理列名の使用」プロパティが選択されているプレゼンテーション・レイヤー列について別名(シノニム)が自動的に作成されます。これは、論理列とプレゼンテーション列の名前が同期をとれるように、このオプションを選択したときに「プレゼンテーション・レイヤー」列の名前が自動的に変更されるために起こります。(「論理列名の使用」が選択されていない場合に)「プレゼンテーション・レイヤー」列の名前を直接変更することによっても、別名が作成されます。
集計ナビゲーションに関する問題を回避するために、ディメンション階層の各論理レベルについて、「このレベルの要素数」フィールドに適切な値を入力してください。ファクト・ソースは、選択したフィールドの組合せとマップ先のディメンションのレベルに基づいて選択されます。これらの値を調整することによって、Oracle BIサーバーで選択されるファクト・ソースを変更できます。この値を設定する方法の詳細は、「ディメンション内の論理レベルの作成」を参照してください。
次のガイドラインでは、外部結合のモデリング方法に関するヒントを紹介します。
外部結合の性質により、通常、外部結合を使用する問合せには時間がかかります。そのため、外部結合を使用するのは、必要な場合のみにしてください。可能であれば、レポート作成SQLで外部結合を使用しなくて済むように、ETL手法を使用してください。
外部結合は常に、ビジネス・モデルとマッピング・レイヤーで定義されます。物理レイヤーの結合では、内部または外部は指定されません。
外部結合は、論理表の結合を使用するか、論理表ソースで定義できます。使用する外部結合のタイプは、物理結合がビジネス・モデルの結合と論理表ソースの結合のどちらにマップするかによって決まります。
外部結合を定義する必要がある場合は、外部結合を使用するディメンションと外部結合を使用しないディメンションの2つの別個のディメンションを作成してみてください。外部結合を使用するディメンションには、それを明確に特定するような名前を付けて、クライアント・ユーザーができるだけそのディメンションを使用しないようにしてください。
複数の外部結合の使用は避けてください。論理外部結合と同じ効果を上げるには、かわりに論理結合を内部結合にし、設計時に分析設計者が対応する分析で「NULL値を含む」オプションを選択することをお薦めします。分析エディタの「NULL値を含む」オプションの詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionユーザーズ・ガイド』のnullの抑制の理解に関する項を参照してください。
プレゼンテーション・レイヤーでは、ビジネス・モデルのユーザー・ビューを設定します。プレゼンテーション・レイヤーのフォルダや列の名前は、ローカライズされた言語で表示できます。プレゼンテーション・レイヤーは、ユーザー許可の設定に適したレイヤーです。プレゼンテーション・レイヤーにおける作業の詳細は、第12章を参照してください。
このレイヤーでは、次のような作業を行うことができます。
ビジネス・モデルとマッピング・レイヤーに存在する列の一部のみを表示できます。たとえば、キー列にはビジネス上の意味がないため除外できます。
ビジネス・モデルとマッピング・レイヤーの表構造とは異なる構造を使用して、列を編成できます。
ビジネス・モデルとマッピング・レイヤーの列名とは異なる列名を表示できます。
権限を設定して、個々のサブジェクト・エリア、表および列へのアクセスをユーザーに許可または禁止できます。
ODBCベースの問合せおよびレポート・ツールに論理キーをエクスポートできます。
1つのビジネス・モデルについて複数のサブジェクト・エリアを作成できます。
論理SQL問合せで使用可能なプレゼンテーション・オブジェクトの別名(シノニム)の一覧を作成できます。この機能を使用すると、既存のレポートに影響を与えることなく、プレゼンテーション列の名前を変更できます。
プレゼンテーション・レイヤーを設計する際のヒントは次のとおりです。
ビジネス・モデルとマッピング・レイヤーとプレゼンテーション・レイヤー間ですべての変更を自動的に同期することはできないため、ビジネス・モデルとマッピング・レイヤーが比較的安定してから、プレゼンテーション・レイヤーにカスタマイズを加えることをお薦めします。
サブジェクト・エリアを作成する際には、ビジネス・モデル全体をドラッグ・アンド・ドロップする、モデルの増分部分をドラッグ・アンド・ドロップする、論理スターまたはスノーフレークに基づいてサブジェクト・エリアを自動的に作成するなど、様々な方法があります。それぞれの方法については、「サブジェクト・エリアの作成」を参照してください。ビジネス・モデルの特定の部分が変更中でも、増分ドラッグ・アンド・ドロップは正しく機能します。
メンテナンス性を向上させるために、プレゼンテーション・レイヤーではなく、ビジネス・モデルとマッピング・レイヤーでオブジェクトの名前を変更することをお薦めします。プレゼンテーション・オブジェクトではなく論理オブジェクトにわかりやすい名前を指定することによって、複数のサブジェクト・エリアで名前を再利用できます。また、ビジネス・モデルに変更を組み込むためにサブジェクト・エリアを削除して再作成する必要がある場合でも、名前が保持されます。
プレゼンテーション階層のメンバーは、プレゼンテーション・レイヤーには表示されません。かわりに、アンサーで階層のメンバーを表示できます。
管理ツールを使用してプレゼンテーション・レイヤーのメタデータを更新することで、ネストされたフォルダをアンサーに表示できます。詳細は、「アンサーおよびBIコンポーザでのフォルダのネスト」を参照してください。
多数のオブジェクトのデータ・アクセス・セキュリティを設定する際には、個々の列の権限を設定するのではなく、ロールによってオブジェクト権限を設定することを検討してください。詳細は、第14章「リポジトリ・オブジェクトへのデータ・アクセス・セキュリティの適用」を参照してください。
プレゼンテーション・オブジェクトの権限を設定する際には、NQSConfig.INIファイルでDEFAULT_PRIVILEGES構成設定を設定することによって、デフォルト権限を変更できます。詳細は、『Oracle Fusion Middleware Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』の付録A: NQSConfig.INIファイルの構成設定に関する項を参照してください。
メタデータ・リポジトリ作成者に関係の深いトピックが他のガイドでも取り上げられています。表1-1にこれらのトピックを掲載し、詳細の参照先を示します。
表1-1 他のガイドで取り上げられているトピック
ハードウェアとソフトウェアの要件、プラットフォーム、データベースおよびその他の情報の詳細は、システム要件と動作要件のドキュメントを参照してください。いずれのドキュメントもOracle Technology Network (OTN)から入手できます。
システム要件のドキュメントには、ハードウェアとソフトウェアの要件、ディスク領域とメモリーの最小要件、必要なシステム・ライブラリ、パッケージまたはパッチなどの情報が記載されています。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-requirements-100147.html
動作要件に関するドキュメントには、サポートされるインストール・タイプ、プラットフォーム、オペレーティング・システム、データベース、JDKおよびサード・パーティ製品が記載されています。
http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html
