ビジネス・モデルの計画

ビジネス・モデルの計画は、意志決定支援に使用可能なデータ・モデルを開発する際の最初の手順です。

この項で説明するガイドラインに従って計画した後、リポジトリの作成を開始できます。

ビジネス・モデルの要件の分析

最初の作業は、ビジネス・モデルの要件を十分に理解することです。

必要な物理レイヤーを決定するにはまず、作成するビジネス・モデルを理解しておく必要があります。

意志決定支援環境では、データ・モデリングの目的は、ビジネス・アナリストによるビジネス構造の理解と同様にビジネス情報を表すモデルを設計することです。適切なモデルを設計すると、アナリストはビジネス上の質問をするのと同様に直感的に問合せを構成できるため、問合せプロセスが自然なプロセスとなります。このモデルは、ビジネス・アナリストが本質的に理解し、有効な質問に正しく回答するものである必要があります。

Oracle BI Publisherなどの視覚的なSQLツールとは異なり、ビジネス・モデルではBIアプリケーションの分析動作を定義します。一方、物理レイヤーでは、ビジネス・モデル・ロジックからマップされた物理問合せをまとめるために使用されるコンポーネントのみが提供されます。

これには、ビジネスを複数のコンポーネントに分割して、次の質問に回答する必要があります。

アナリストはどのようなビジネス上の質問に回答しようとしていますか。
ビジネス・パフォーマンスを理解するためにどのようなメジャーが必要ですか。
ビジネスの運営の基準とするディメンションをすべてあげてください。つまり、測定を分割してレポートのヘッダーとして使用するディメンションをあげてください。
各ディメンションに階層要素はありますか。各階層はどのようなリレーションシップによって定義されますか。

これらの質問に回答したら、ビジネス・モデルの要素を特定し、定義できます。

ビジネス・モデルのコンテンツの特定

ビジネス・モデルに含めるコンテンツを決定するにはまず、ユーザーが問い合せる必要がある論理列を特定する必要があります。

次に、各列のロールをメジャー列、またはディメンション属性のいずれかとして特定する必要があります。最後に、関連するロール、列間のリレーションシップ、およびロジックに基づいて、論理列をディメンション・モデルに配置します。

ビジネスは関連するディメンション基準によって分析されるため、これらの関連するディメンションからビジネス・モデルを開発します。これらのディメンション・モデルは、Oracle BIサーバーで使用する有効なビジネス・モデルの基盤となります。

すべてのディメンション・モデルがスター・スキーマに基づいて作成されるわけではありませんが、ビジネス・モデル・レイヤーでは単純なスター・スキーマを使用することをお薦めします。つまり、ディメンション・モデルは、様々なディメンション属性に関して表示される測定可能なファクトを表す必要があります。

ビジネス・モデルの要件を分析したら、ビジネス・モデルに含める必要がある具体的な論理表や階層を特定する必要があります。

この項では、次の項目について説明します。

論理ファクト表の特定

ビジネス・モデルとマッピング・レイヤーの論理ファクト表には、集計が定義に組み込まれているメジャーが含まれます。

論理ファクト表は、表の最下位単位でファクトを定義するリレーショナル・モデルの物理ファクト表とは異なります。

ファクトから集計されるメジャーは、論理ファクト表で定義する必要があります。メジャーは通常、売上額や販売数量のような計算データで、ディメンションに関して指定できます。たとえば、特定の期間における特定の市場での特定の製品の売上合計を求めることができます。

各メジャーには、SUM、AVG、MIN、MAXなどの独自の集計ルールがあります。企業はメジャーの値を比較したり、比較を表す計算を作成することができます。また、特定のディメンションに固有の集計ルールを定義することもできます。Oracle BIサーバーでは、ディメンション固有の複雑な集計ルールを定義できます。

ビジネス・モデルとマッピング・レイヤーの表は、ファクト表またはディメンション表として明示的に指定されるわけではありません。Oracle BIサーバーでは、結合の1側の表がディメンション表として扱われ、結合の多側の表がファクト表として扱われます。

この図は、ビジネス・モデル図におけるファクト表への多対1結合を示しています。この図では、すべての結合は、Fact-Pipeline表から発する(1方向の)矢印を持っており、その表を指す結合はありません。ビジネス・モデルにおけるこの例については、管理ツールでリポジトリを開き、ファクト表を右クリックし、「ビジネス・モデル図」→ 「図全体」を選択します。

GUID-EF526956-3E8D-4ED5-A0E7-9F656D912E9A-default.gifの説明

論理ディメンション表の特定

ディメンション表には、ビジネス・エンティティ(顧客名、地域、住所、国など)を説明する属性が格納されています。

企業では、ファクトを使用して、時間、製品、市場など、適切に確立されたディメンションによってパフォーマンスを測定します。すべてのディメンションに説明属性のセットがあります。また、各メンバーを特定する主キーも格納されています。リレーショナル・モデルの物理ファクト表とは異なる論理ファクト表とは違い、論理ディメンション表の動作はリレーショナル・ディメンション表と非常によく似ています。

ディメンション表の属性によって、サービス・リクエストを分類できるなど、数値データにコンテキストが提供されます。このディメンションに保存される属性には、サービス・リクエストの所有者、領域、アカウント、優先度などがあります。

ビジネス・モデルのディメンションは、適合済ディメンションです。つまり、特定のデータ・ソースに特定の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タイプにはHoliday属性がありません。
設計時にレベルが固定されているか(年-四半期-月)、実行時のビジネス・トランザクションによってレベルが増えたり減ったりする可能性があるか。たとえば、現在最下位の従業員が新たに最下位になる部下を雇用する場合はレベルを追加できます。
特定の階層タイプを必要とする制約がプライマリ・データ・ソースにあるかどうか。プライマリ・データ・ソースがある方法でモデル化されている場合、その他の要因とは無関係に、ビジネス・モデルで同じ階層タイプを使用する必要があります。

詳細は、論理ディメンションの操作を参照してください。

複数の階層を持つディメンションについて

ディメンションに複数の階層が含まれる場合があります。

たとえば、Timeディメンションには多くの場合、暦年を表す階層と会計年度を表す階層があります。

注意:

複数の階層を持つディメンションは必ず、同じリーフ表で終わる必要があります。

この図は、Oracle BI管理ツールのビジネス・モデルとマッピング・レイヤーに表示された、複数の階層を持つディメンションを示しています。

GUID-36D61851-B553-425D-9EAE-E12CDE26DBF5-default.gifの説明

参照表の特定

多言語スキーマから翻訳されたフィールド情報を表示する必要がある場合は、物理レイヤーの参照表に対応する論理参照表を作成します。

参照表には、ベース表の行に対応する多言語データが格納されます。特定の論理参照表を使用するには、まず、「論理表」ダイアログの「一般」タブで、その表を参照表として指定する必要があります。ローカライゼーションと参照表の詳細は、『Oracle Business Intelligence Enterprise Editionシステム管理者ガイド』のリポジトリ内のメタデータ名のローカライズに関する項を参照してください。

参照表は、ある値セットをユーザーに表示し、対応する別の値セットを物理問合せで使用する場合に使用できます。参照表は、別のデータソースで検索される判読可能な値を提供するために使用できます。