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