製図アウトライン

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

ノート:

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

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

Year。 TBCでは、毎月データを収集し、毎月のデータを四半期および年別に集計する必要があります。 Jan、Feb、Marなどのメンバーに保管される月次データは、四半期に集計されます。 Qtr1やQtr2などのメンバーに保管されている四半期データは、年に集計されます。
Measures。販売、売上原価、マーケティング、給与、その他、期首インベントリ、追加および期末インベントリは標準メジャーです。 Essbaseでは、これらのメジャーからマージン、費用合計、利益、インベントリ合計、利益%、マージン%およびオンス当たりの利益を計算できます。 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タイプ属性ディメンションのメンバーに関連付けられているため、TBCではサイズおよびパッケージ別に分析できます。
Market。複数の州が1つのリージョンを構成し、4つのリージョンが1つの市場を構成します。州はConnecticut、Florida、Massachusetts、New Hampshire、New York、California、Nevada、Oregon、Utah、Washington、Louisiana、New Mexico、Oklahoma、Texas、Colorado、Illinoi、Iowa、Missouri、OhioおよびWisconsinです。各州は、そのリージョン(東部、西部、南部または中部)に統合されます。各リージョンは市場に統合されます。
シナリオ TBCは、予算対実績データを導出して追跡します。マネージャは、予算と実績、およびそれらの差異と差異率をモニターおよび追跡する必要があります。
Pkg Type。 TBCは、製品パッケージが販売と利益に与える影響を確認したいと考えています。パッケージ・タイプ属性ディメンションを設定すると、ユーザーは、製品がボトルと缶のどちらにパッケージ化されているかに基づいて製品情報を分析できます。
オンス。 TBCは、市場ごとに異なる規模の製品を販売しています。 Ounces属性ディメンションを設定すると、ユーザーはどの市場でどの規模の売上が向上するかを監視できます。

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

ディメンション・プロパティおよびメンバー・プロパティ

ディメンションおよびメンバーのプロパティは、多ディメンション構造の設計におけるディメンションおよびメンバーのロールを定義します。これらのプロパティには、次のものがあります:

ディメンション・タイプと属性の関連付け。ディメンション・タイプを参照してください。
データ・ストレージのプロパティ。「メンバー・ストレージ・プロパティ」を参照してください。
集計演算子「ディメンションとメンバーの連結」を参照してください。
式「式と関数」を参照してください。

ディメンション・プロパティおよびメンバー・プロパティの完全なリストは、「ディメンション・プロパティおよびメンバー・プロパティの設定」を参照してください。

ディメンション・タイプ

ディメンション・タイプは、ディメンションに特別な機能を追加するためにEssbaseが提供するプロパティです。最もよく使用されるディメンション・タイプ: 時間、勘定科目および属性。このトピックでは、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ディメンションのメンバーに適用される各タイプのパッケージのメンバーが含まれます。

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

メンバーのデータ・ストレージ・プロパティを指定できます。データ・ストレージ・プロパティは、集計の保管場所と保管時期を定義します。たとえば、デフォルトでは、メンバーはストア・データとしてタグ付けされます。 Essbaseは、保管データ・メンバーの値を合計し、その結果を親レベルで保管します。

メンバーのデータ・ストレージ・プロパティ・タグを変更することで、各メンバーのデフォルト・ロジックを変更できます。たとえば、ストア・データ・メンバーをラベルのみのメンバーに変更できます。たとえば、ラベルのみのタグを持つメンバーには、関連付けられたデータはありません。

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

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

データ・ストレージのプロパティ	メンバーへの影響
データの保管	メンバーのデータはデータベースに格納されます。ストア・データは、デフォルトのストレージ・プロパティです。
動的計算	メンバーに関連付けられたデータは、ユーザー問合せによってリクエストされたときに計算されます。計算されたデータは格納されず、問合せリクエストの完了後に破棄されます。
共有メンバー	メンバーに関連付けられたデータは、同じ名前の別のメンバーから取得されます。
ラベルのみ	ラベルのみのメンバーにはデータが関連付けられていませんが、ラベルのみのメンバーは値を表示できます。ラベルのみがグループ・メンバーにタグ付けされ、ナビゲーションとレポートが容易になります。通常、ラベルのみのメンバーは計算されません。たとえば、Measuresディメンションでは、メンバーRatiosには、Margin%、Profit%、Profit per Ounceの3つの子があります。メンバー比率は、メンバーのカテゴリを定義します。連結すると、マージン%、利益%およびオンス当たりの利益は比率の有意義な数値に積み上げられません。したがって、比率はラベルのみとしてタグ付けされます。

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

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

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

属性ディメンションをアウトラインの最後に配置します。疎ディメンションの前に密ディメンションを配置します。

アウトライン内のディメンションの位置とディメンションのストレージ・プロパティは、パフォーマンスの2つの領域(計算の実行速度とユーザーが情報を取得するのにかかる時間)に影響を与える可能性があります。

パフォーマンス最適化の基本を理解するには、次のトピックを参照してください:

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

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

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

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

アウトラインには属性ディメンションが含まれているため、標準ディメンションおよびすべての標準ディメンション・メンバーのストレージ・プロパティはストア・データとして設定されます。
最もクエリーが多い疎ディメンションとして、Productディメンションが最初の疎ディメンションになります。通常、ベース・ディメンションは他のディメンションよりも多くの問合せが行われます。

図1-5 最適化された問合せ時間のアウトラインの設計

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

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

計算パフォーマンスを最適化するには、最も少ないディメンションを含むディメンションから順に、アウトラインの疎ディメンションをそのメンバー数で順序付けします。

「計算パフォーマンスのための設計」を参照してください。

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

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

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

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

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

これらには同じディメンションが含まれていますが、前に示したアウトラインの例は異なります。状況に最適なアウトライン順序を決定するには、データベースでの計算の実行に必要な時間に対して、ユーザーのデータ取得要件に優先順位を付けます。データベースを更新および再計算する頻度を指定してください。ユーザー問合せの性質は何ですか。予想されるユーザー問合せの量はどれくらいですか。

考えられる回避策は、最初にアウトラインにディメンションを配置して計算を最適化することです。計算を実行した後、ディメンションの順序を手動で変更して取得を最適化できます。アウトラインのディメンションを再配置した後にアウトラインを保存する場合は、索引のみを使用してデータベースを再構築することを選択します。計算を再実行する前に、アウトラインのディメンションの順序を変更して計算を最適化します。