Essbaseアウトラインのドラフトの作成

Essbaseデータベース・モデルのドラフトを作成したら、アプリケーションとデータベースを作成し、アウトラインの最初のドラフトを構築できます。ドラフトでは、すべてのディメンション、メンバーおよび集計を定義します。アウトラインを使用して、集計の要件を設計し、式と計算スクリプトが必要な場所を特定します。

アウトラインはEssbaseデータベース(またはキューブ)の一部で、Essbaseアプリケーション内に存在します。

前述のBeverage Companyの例を使用するために、TBCアプリケーション設計者はデータベース・アウトラインについて次のドラフトを発行しました。このプランでは、Year、Measures、Product、Market、Scenario、Pkg TypeおよびOuncesがディメンション名です。TBCで、集計、計算、式およびレポートの要件がどのように構想されたかを確認します。アプリケーション・デザイナは、製品を記述するときに製品名ではなく製品コードを使用しました。

Year。TBCでは、毎月データを収集して、その月次データを四半期または年ごとに要約する必要があります。Jan、Feb、Marなどのメンバーに保管される月次データは、四半期に集計されます。Qtr1、Qtr2などのメンバーに保管される四半期ごとのデータは、年に集計されます。
Measures。Sales、Cost of Goods Sold、Marketing、Payroll、Miscellaneous、Opening Inventory、AdditionsおよびEnding Inventoryが標準メジャーです。Essbaseでは、Margin、Total Expenses、Profit、Total Inventory、Profit %、Margin %およびProfit per Ounceをこのメジャーから計算できます。TBCでは、月ごと、四半期ごと、年ごとにメジャーを計算する必要があります。
Product。製品コードは、100‑10、100‑20、100‑30、200‑10、200‑20、200‑30、200‑40、300‑10、300‑20、300‑30、400‑10、400‑20および400‑30です。各製品は、それぞれのファミリ(100、200、300および400)に集計されます。各製品はOunces属性ディメンションとPkg Type属性ディメンションのメンバーに関連付けられているため、TBCでは各集計をサイズ別およびパッケージ別に分析できます。
Market。複数の州で1つの地域が構成されます。4つの地域で1つの市場が構成されます。州は、Connecticut、Florida、Massachusetts、New Hampshire、New York、California、Nevada、Oregon、Utah、Washington、Louisiana、New Mexico、Oklahoma、Texas、Colorado、Illinois、Iowa、Missouri、OhioおよびWisconsinです。各州は、その地域(East、West、SouthまたはCentral)に集計されます。各地域はMarketに集計されます。
Scenario。TBCでは、予算と実績データの差異を導出し、追跡します。マネージャは、予算と実績、および予算と実績の差異と差異のパーセンテージをモニターして追跡する必要があります。
Pkg Type。TBCでは、製品のパッケージが売上高と利益に及ぼす影響を確認する必要があります。Pkg Type属性ディメンションを作成することで、ユーザーは製品のパッケージがボトルであるか缶であるかに基づいて、製品情報を分析できます。
Ounces。TBCでは、市場によって異なるサイズ(オンス単位)で製品を販売しています。Ounces属性ディメンションを作成することは、どの市場でどのサイズがよく売れるかをユーザーがモニターするために役立ちます。

次のトピックでは、ディメンションおよびメンバー・プロパティの基本を確認し、パフォーマンスに影響を及ぼすアウトライン設計について説明します。

ディメンション・タイプ

ディメンション・タイプは、Essbaseに用意されているプロパティの1つで、ディメンションに特別な機能を追加します。特殊で一般的に使用されるディメンション・タイプは、時間、勘定科目および属性です。

このトピックでは、TBCデータベースの次のディメンションを使用して、ディメンション・タイプについて説明します。

Database:Design
  Year (Type: time)
  Measures (Type: accounts)
  Product
  Market
  Scenario
  Pkg Type (Type: attribute)
  Ounces (Type: attribute)

次の表に、Essbaseの各ディメンション・タイプの説明を示します。

表1-4 ディメンション・タイプ

ディメンション・タイプ	説明
なし	特定のディメンション・タイプを指定しません。
時間	データをレポートおよび更新する期間を定義します。1つのディメンションのみを時間としてタグ付けできます。時間ディメンションによって、期首タイム・バランスや期末タイム・バランスなど、複数の勘定科目ディメンションの関数が使用可能になります。
勘定科目	利益や在庫などの測定するアイテムを含み、Essbaseの組込み会計機能を使用可能にします。勘定科目として定義できるディメンションは1つのみです。
属性	別のいわゆる基本ディメンションのメンバーを説明するために使用できるメンバーを含みます。たとえば、Pkg Type属性ディメンションには、Productディメンションのメンバーに適用される各種のパッケージ(ボトルや缶など)に対応するメンバーが含まれます。
国(通貨換算機能にのみ使用)	ビジネス・アクティビティが実行される場所に関するデータを含みます。国ディメンションでは、各メンバーで使用される通貨を指定できます。たとえば、カナダにはバンクーバー、トロント、モントリオールという3つの市場があり、同じ通貨であるカナダ・ドルを使用します。

メンバー・ストレージ・プロパティ

メンバーのデータ・ストレージ・プロパティを指定して、集計を保管する場所とタイミングを定義します。デフォルトでは、メンバーは保管済としてタグ付けされます。Essbaseは値を合計し、親レベルで結果を保管します。データ・ストレージ・プロパティ・タグを変更することで、各メンバーのデフォルト・ロジックを変更できます。

次の表で、Essbaseデータ・ストレージ・プロパティがメンバーに及ぼす影響について説明します。

表1-5 Essbaseデータ・ストレージ・プロパティ

データ・ストレージ・プロパティ	メンバーへの影響
データの保管	メンバーのデータはデータベースに保管されます。データの保管は、デフォルトのストレージ・プロパティです。Essbaseでは、値が合計され、親レベルで結果が保管されます。
動的計算	メンバーに関連付けられたデータは、ユーザー問合せによって要求されたときに計算されます。計算済データは保管されず、問合せ要求の完了後に破棄されます。
共有メンバー	メンバーに関連付けられたデータは、同じ名前を持つ別のメンバーから取得されます。
共有しない	メンバーに関連付けられたデータは、暗黙的な共有関係が存在する場合、親とその子で複製されます。データは、アウトライン順にメンバーの最初の出現とともに保管されます。
ラベルのみ	データが関連付けられていないメンバーについて、保管されたメンバーを「ラベルのみ」に変更できます。ラベルのみのメンバーにはデータがありませんが、値を表示できます。ラベルのみのタグによって、メンバーがグループ化され、ナビゲーションとレポート作成が容易になります。通常、ラベルのみのメンバーは計算されません。たとえば、MeasuresディメンションのRatiosメンバーには、Margin%、Profit%およびProfit per Ounceという3つの子があります。Ratiosメンバーはメンバーのカテゴリを定義します。集計しても、Margin%、Profit%およびProfit per Ounceは比率として意味のある数値にロールアップされません。そのため、Ratiosはラベルのみとしてタグ付けします。

ディメンションおよびメンバーのプロパティのチェックリスト

時間ディメンションを特定できるか
勘定科目ディメンションを特定できるか
データには外貨が含まれているか。その場合、通貨パーティション・ディメンションを特定したか。
別の属性ディメンションとして定義する必要があるディメンションの品質または特性を特定できるか
特殊なデータ・ストレージ・プロパティが必要なメンバーはどれか

パフォーマンスを最適化するためのアウトラインの設計

属性ディメンションをEssbaseアウトラインの最後に配置し、密ディメンションを疎の前に配置し、メンバーが最も少ない疎ディメンションを最初に順序付けします。アウトライン内のディメンションの位置およびディメンションのストレージ・プロパティは、計算の実行速度およびデータの取得にかかる時間に影響します。

問合せパフォーマンスの最適化

問合せパフォーマンスを最適化するには、アウトラインの設計時に次のガイドラインを使用します。

アウトラインに属性ディメンションが含まれる場合、その属性ディメンションが疎の動的計算ディメンションのみであることを確認します。
アウトラインでは、問合せの少ない疎ディメンションの前に問合せの多い疎ディメンションを配置します。

次の図に示すアウトラインは、最適な問合せパフォーマンスを実現するよう設計されています。

アウトラインには属性ディメンションが含まれているため、標準ディメンションおよびすべての標準ディメンション・メンバーのストレージ・プロパティはデータの保管として設定されます。
最も問合せの多い疎ディメンションである、Productディメンションが疎ディメンションの最初に配置されています。基本ディメンションは、一般的に、他のディメンションよりも問合せの頻度が高くなります。

図1-5 問合せ時間を最適化するためのアウトラインの設計

このイメージは、イメージの前のテキストで説明されている、最適な問合せパフォーマンスを実現するように設計されたアウトラインを示しています。

計算パフォーマンスの最適化

計算パフォーマンスを最適化するには、アウトライン内の疎ディメンションを、メンバー数が少ないものからメンバー数の順に並べます。

次の図に示すアウトラインは、最適な計算パフォーマンスを実現するよう設計されています。

最も小さい標準ディメンションで、疎であるMarketは、アウトライン内の疎ディメンションの先頭に配置されています。
最も大きい標準ディメンションで、疎であるProductは、最初の属性ディメンションのすぐ上に配置されています。アウトラインに属性ディメンションが含まれていない場合は、Productディメンションがアウトラインの最後に配置されます。

図1-6 計算時間を最適化するためのアウトラインの設計

このイメージは、イメージの前のテキストで説明されている、最適な計算パフォーマンスを実現するように設計されたアウトラインを示しています。

計算と取得の両方のニーズへの対応

前述のアウトライン例には同じディメンションが含まれていますが、それらのアウトラインは異なっています。状況に最適なアウトラインの順序を決定するには、データベースで計算を実行するために必要な時間よりも、ユーザーのデータ取得要件を優先します。つまり、データベースの更新と再計算の頻度、ユーザー問合せの性質、ユーザー問合せの量を優先して考慮します。

まずアウトラインにディメンションを配置して計算を最適化することが1つの回避策となります。計算の実行後、取得を最適化するためにディメンションの順序を手動で変更できます。ディメンションの配置を変更した後にアウトラインを保存する場合は、データベースをインデックスのみで再構築することを選択します。再び計算を実行する前に、計算を最適化するためにアウトラインのディメンションの順序を変更します。