ケース・スタディ: 単一サーバー、多次元データベースの設計

この項の内容:

データベース設計のプロセス

ケース・スタディ: The Beverage Company

分析とプランニング

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

システム要件のチェック

テスト・データのロード

計算の定義

レポートの定義

設計の確認

この章の情報の一部は、ブロック・ストレージ・データベースのみに適用され、集約ストレージ・データベースとは関係がありません。集約ストレージとブロック・ストレージの比較。も参照してください。

データベース設計のプロセス

多次元データベースを実装するには、Essbaseをインストールした後、アプリケーションとデータベースを設計して作成します。データ・ソースを分析し、慎重に要件を定義して、単一サーバーを使用する方法とパーティションに分割する方法のどちらがよりニーズに合っているかを判断します。アプリケーションをパーティションに分割するかどうかを判断する基準として、データベースのパーティション化のガイドラインを参照してください。

この章では、ケース・スタディを使用して、データベース・プランニング・プロセスの概要を説明します。また、組織向けに単一サーバーによる多次元データベース・ソリューションを設計する際の作業ルールについても説明します。アプリケーションとデータベースの作成。を参照してください。

図26は、データベース設計のサイクルのプロセスを示しています。次の基本手順が含まれます:

  1. 業務ニーズの分析およびプラン設計。

    ユーザーと組織の情報ニーズを満たすアプリケーションおよびデータベースを作成する必要があります。そのため、ソース・データを特定し、ユーザーの情報アクセスのニーズを定義し、セキュリティの考慮事項を確認して、データベース・モデルを設計します。分析とプランニングを参照してください。

  2. データベース・アウトラインのドラフト作成。

    アウトラインとは、データベースの構造を決めるものです。つまり、保管する情報と、異なる情報同士の相互関連付けを決定します。アウトラインのドラフト作成を参照してください。

  3. システム要件の確認。

    データベースの効率とパフォーマンスは、システム要件を満たす方法およびシステム・パラメータの定義方法によって影響されます。システム要件のチェックを参照してください。

  4. データベースへのテスト・データのロード。

    アウトラインの定義およびセキュリティ・プランの立案が完了したら、データベースにテスト・データをロードし、このプロセス以降の手順を処理できるようにします。テスト・データのロードを参照してください。

  5. 計算の定義。

    アウトラインの集計をテストし、専用の計算のための式および計算スクリプトを記述してテストします。計算の定義を参照してください。

  6. レポートの定義。

    ユーザーは、印刷やオンラインのレポートおよびスプレッドシート、またはWebを介してデータにアクセスします。ユーザーに事前定義済のレポートを提供する予定がある場合は、レポート・レイアウトを設計してレポートを実行します。レポートの定義を参照してください。

  7. ユーザーと合同での確認。

    ユーザーのニーズを満たすデータベースを作成するには、ユーザーに意見を求め、その内容を慎重に検討します。設計の確認を参照してください。

  8. プロセスの繰返し。

    設計を調整するには、手順1から7を繰り返します。

図 26. データベース設計のサイクル

この図は、この図の前のテキストで説明されている、データベースを設計するための8つの基本手順を示しています。

ケース・スタディ: The Beverage Company

この章では、The Beverage Company(TBC)という名前の架空の会社の要件に基づいてデータベース・プランニング・プロセスを開発し、このTBCを例として、Essbaseデータベースの構築方法を説明します。TBCはEssbaseのインストールに含まれるSample.Basicアプリケーションのバリエーションです。

TBCは、国内外で清涼飲料水の製造、販売、流通を行っています。TBCのアナリストは、予算予測を策定し、毎月の予算予測と実績を比較します。アナリストが追跡する財務尺度は、損益および在庫です。

TBCでは、スプレッドシート・パッケージを使用して予算データを準備し、差異レポートの作成を実行しています。複数の市場で様々な製品のプランニングと追跡を実施しているため、データの取得や分析に時間がかかります。先月、アナリストは勤務時間の大部分をデータの入力とレポートの準備に費やしていました。

TBCは、財務データの中央リポジトリを作成するには、Essbaseが最適のツールであると判断しています。データ・リポジトリは、アナリストが組織のどこにいてもアクセスできる1台のサーバー上に置かれます。ユーザーはこのサーバーにアクセスして、様々なソースからデータをロードしたり、必要なデータを取得したりできます。なお、TBCには様々なユーザーが存在するため、ユーザーごとにデータ・アクセスのセキュリティ・レベルを変更する必要があります。

分析とプランニング

システムを細かく調整して、ビジネス情報を効果的に分析できるようにするには、Essbase多次元データベースの設計と操作が鍵となります。多次元データベースのサイズおよびパフォーマンスの変動を考えると、最適化されたデータベースを開発することが重要です。データ・ソース、ユーザーの要件および予想されるデータベース要素をアウトライン化した詳細なプランを立案することで、開発および実装の所要時間を短縮できます。

プランニングと分析のフェーズでは、次のタスクを実行します:

多次元アプリケーションを設計する場合、次の要因を検討します:

  • 社内での情報の流れ: 誰がどのデータを何の目的で使用するか

  • 会社が作成するレポートのタイプ: レポートに関するユーザーのニーズを満たすために、アウトラインにどのようなタイプのデータを含める必要があるか

    注:

    アプリケーションごとにデータベースを1つのみ定義することで、メモリーの使用率を向上させ、データベース管理を簡易化できます。ただし、オプションのEssbase通貨換算モジュールを使用するアプリケーションは、この推奨要件に当てはまりません。通貨換算アプリケーションは、通常、メイン・データベースと独立した通貨データベースで構成されます(通貨換算アプリケーションの設計および作成を参照)。

ソース・データの分析

まずデータベースに含めるソース・データを評価します。データの場所とデータベースのデータを更新する頻度を考慮してください。この事前調査を行うことで、データベースのアウトラインを作成してEssbaseデータベースにデータをロードするときの時間を節約できます。

データベースのスコープを決定します。膨大な数の製品を含む製品ファミリが多数存在する場合、製品ファミリのデータ値のみを保管できます。各ユーザー部門のメンバーにインタビューを実施して、どのようなデータを処理しているのか、現在はどのような方法でデータを処理しているか、将来どのような方法でデータを処理していきたいかを確認します。

レポートと分析に関するニーズを綿密に定義します。

  • ユーザーはどのようなデータの表示方法および分析方法を望んでいますか?

  • データベースには、どの程度詳細なデータを保管しますか?

  • そのデータは、分析とレポート作成に関する目標を満たしていますか?

  • 満たしていない場合、どのようなデータを追加する必要がありますか。また、必要なデータはどこにありますか?

現在のデータの場所を決定します。

  • また、各部門では現在どこにデータを保管しているかを確認します。

  • Essbaseで使用できるフォームのデータですか?

  • 各部門では、Windowsサーバー上のリレーショナル・データベース、UNIXサーバー上のリレーショナル・データベース、Excelスプレッドシートのうち、どこにデータを保管していますか?

  • 誰がどのくらいの頻度でデータベースを更新しますか?

  • データを更新する必要があるユーザーは、データにアクセスできますか?

データをEssbaseにロードする準備ができていることを確認します。

  • データ・ソースは1つですか、それとも複数ですか?

  • Essbaseで使用できるフォーマットのデータですか。Essbaseにロード可能な有効なデータ・ソースのリストについては、データ・ソースを参照してください。

  • 使用するすべてのデータが、すぐに使用できる状態になっていますか?

ユーザー要件の明確化

情報の要件についてユーザーと話し合います。ユーザーが使用する情報と、他のユーザーに確認してもらうために作成する必要があるレポートを確認します。次の要件について、判断します:

  • ユーザーはどのようなタイプの分析を必要としていますか?

  • ユーザーは、どのような要約レベルおよび詳細レベルの情報を必要としていますか?

  • アクセス可能な情報を、ユーザーごとに個別に設定する必要がありますか?

マルチ・ユーザー環境におけるセキュリティのプランニング

セキュリティ権限の設定方法をプランするときは、ユーザーの情報の要件を考慮します。分析の最後に、ユーザーと権限のリストを作成します。

次のチェックリストを使用して、セキュリティ・プランを立てます:

  • ユーザーは誰ですか? また、ユーザーにどのような権限を与えますか?

  • データ・ロード権限を誰に与えますか?

  • どのユーザーをグループ化できますか? また、グループ化した場合、そのグループに対して同様の権限を与えることができますか?

EPM Systemセキュリティ・モードでのユーザーの管理およびセキュリティを参照してください。

データベース・モデルの作成

次に、データベースのモデルを紙に書き出します。モデルを構築するには、業務にとって重要なパースペクティブとビューを識別します。これらのビューが、データベース・モデルの次元になります。

多くの業務では、次の項目を分析対象としています:

  • 期間

  • 会計方法

  • シナリオ

  • 製品

  • 流通チャネル

  • 地域

  • ビジネス・ユニット

次の項目を参照して、情報を収集し判断してください。

分析対象の明確化

業務情報の主要分野を明確にした後、Essbaseデータベース設計の次の手順は、データベースでどのようにデータを分析するかを決定することです。たとえば、次の内容を検討します:

  • 時間で分析する場合、どの期間が必要ですか?分析には現在の年のみを含めますか、複数の年を含めますか?分析には四半期ごとのデータと月ごとのデータを含めますか?季節ごとのデータを含めますか?

  • 地理的な地域で分析する場合、地域をどのように定義しますか?地域を販売区域ごとに定義しますか?都道府県や市区町村などの地理的な境界で地域を定義しますか?

  • 製品ラインで分析する場合、各製品のデータを確認しますか?データを製品クラスに要約できますか?

業務の分野を問わず、分析に必要なパースペクティブと詳細を決定する必要があります。分析するビジネス領域ごとに、異なるデータ・ビューが提供されます。

次元およびメンバーの決定

各ビジネス・ビューをデータベース内の個々の標準次元として表現できます。分類や属性(製品のサイズや色など)によってビジネス領域を分析する必要がある場合、属性次元を使用して分類ビューを表現できます。

選択した次元によって、データに対して実行できる分析のタイプが決まります。Essbaseでは、分析のニーズに合わせて必要な数の次元を使用できます。一般的なEssbaseデータベースの場合、標準次元(非属性次元)が少なくとも7つと、さらに多数の属性次元が含まれます。

必要な次元とメンバーをほぼ把握できている場合は、次の項目を検討して、仮のデータベース設計を作成します:

データベース・モデルの次元を決定したら、各次元のパースペクティブ内の要素またはアイテムを選択します。これらの要素がそれぞれの次元のメンバーになります。たとえば、時間のパースペクティブには、分析対象の期間(四半期、四半期内の月など)が含まれます。各四半期と各月は、作成した時間を表す次元のメンバーになります。四半期と月は、メンバーとその子からなる2レベルの階層を表します。四半期内の月を集計すると、その四半期の合計が得られます。

次元間の関係

次に、ビジネス領域間の関係について考えます。Essbaseデータベースは、ユーザーが多くのパースペクティブから情報を簡単に分析できるような構造になっています。たとえば財務アナリストが、次のような疑問を持つとします:

  • 特定の月の売上はどのくらいか?この数字は過去5年間の同月の売上と比べてどうか?

  • 収益マージンの増加率は何%か?

  • 実績値と予算値の差異はどのくらいか?

つまり、アナリストは、次の3つのパースペクティブから情報を調査する必要があります - 時間、勘定科目およびシナリオ。図27のサンプル・データベースでは、これら3つのパースペクティブが3つの次元として表されています。1つの次元が3つの軸に沿って表現されます:

  • 時間次元: Jan、Feb、MarおよびQtr1の合計で構成され、X軸で示されます。

  • 会計次元: 会計値(Sales、COGS、Margin、Margin%など)で構成され、Y軸で示されます。

  • 別の視点から見るためのもう1つの次元(予定値Budgetおよび実績値Actual)は、Z軸で示されます。

図 27. 3つのデータベース次元を表しているキューブ

この図は、この図の前のテキストで説明されている、3つの次元を表すキューブを示しています。

このキューブ内のセル(メンバーが交差している箇所)には、交差している3つのメンバーすべてに対応したデータが含まれています。たとえば、1月の販売実績などです。

次元とメンバーの構造の例

表2は、プランナが次元として定義したTBCのビジネス領域の要約です。次元は、分析対象の主要なビジネス領域を表します。プランナは3つの列を作成しています。左端の列に次元、右の2列にメンバーが入ります。列3のメンバーは列2のメンバーのサブカテゴリです。列3のメンバーがさらにサブカテゴリ・レベルに分割される場合もあります。たとえばメジャー次元のMarginは、SalesとCOGSに分割されます。

表 2. TBCのサンプルの次元

次元

メンバー

子メンバー

Qtr1

Jan、Feb、Mar

Qtr2

Apr、May、Jun

Qtr3

Jul、Aug、Sep

Qtr4

Oct、Nov、Dec

メジャー

Profit

Margin: Sales、COGS

Total Expenses: Marketing、Payroll、Miscellaneous

メジャー

Inventory

Opening Inventory、Additions、Ending Inventory

メジャー

Ratios

Margin %、Profit %、Profit per Ounce

製品

Colas (100)

Cola (100‑10)、Diet Cola (100‑20)、Caffeine Free Cola (100‑30)

製品

Root Beer (200)

Old Fashioned (200‑10)、Diet Root Beer (200‑20)、Sarsaparilla (200‑30)、Birch Beer (200‑40)

製品

Cream Soda (300)

Dark Cream (300‑10)、Vanilla Cream (300‑20)、Diet Cream Soda (300‑30)

製品

Fruit Soda (400)

Grape (400‑10)、Orange (400‑20)、Strawberry (400‑30)

市場

East

Connecticut、Florida、Massachusetts、New Hampshire、New York

市場

West

California、Nevada、Oregon、Utah、Washington

市場

South

Louisiana、New Mexico、Oklahoma、Texas

市場

中部

Colorado、Illinois、Iowa、Missouri、Ohio、Wisconsin

シナリオ

Actual

該当なし

シナリオ

Budget

該当なし

シナリオ

Variance

該当なし

シナリオ

Variance %

該当なし

また、プランナは2つの属性次元の追加を行い、サイズ別および容器別に製品を分析できるようにしました:

表 3. TBCサンプルの属性次元

次元

メンバー

子メンバー

オンス

Large

Small

64、32、20

16、12

パッケージ・タイプ

Bottle

Can

該当なし

次元およびメンバーを決定するためのチェックリスト

モデル・データベースの次元およびメンバーを決定するときには、次のチェックリストを使用します:

  • 次元の候補としては何がありますか?

  • 他の次元を分類または説明する次元はありますか?そのような次元は、属性次元の候補です。

  • ユーザーは次元のビューを限定することを希望していますか?ユーザーが次元を限定するためのカテゴリは、属性次元の候補です。

  • メンバーの候補としては何がありますか?

  • データにはいくつのレベルが必要ですか?

  • データをどのように集計しますか?

データベース設計の分析

初期の次元設計が準備段階の間に、一連のガイドラインに基づいて設計を見直す必要があります。ガイドラインを使用することで、データベースを調整して、多次元技術を活用できるようになります。ガイドラインは、効果的な設計を実現し、集計と計算の目標を達成するのに役立つプロセスまたは課題です。

潜在的データ・ポイントを記述するために必要なメンバーの数によって、次元の数が決まります。次元を削除すべきかどうかわからない場合は、削除を保留にして、その次元を削除すべきか保持すべきかの確信が得られるまで、さらに多くの分析ルールを適用します。

次のトピックの情報を使用して、データベース設計を分析し、改善します。

密次元および疎次元

どの次元が疎で、どの密次元がパフォーマンスに影響するかについて考えます。初めに、疎次元および密次元を参照してください。パフォーマンスを最適化するためのアウトラインの設計を参照してください。

標準次元および属性次元

簡単にするため、このトピックの例では、2つの次元として最初に設計されたものとは別の配置を使用します。すべての次元の組合せに同じ論理を適用できます。

製品を複数の市場の複数の顧客に販売する会社における設計について考えてみます。この場合、市場は各顧客に対して一意です:

                   Cust A  Cust B  Cust C
New York     100     N/A     N/A
Illinois     N/A     150     N/A
California   N/A     N/A     30
   

Cust AはNew Yorkのみ、Cust BはIllinoisのみ、Cust CはCaliforniaのみに存在します。会社は、1つの標準次元でデータを定義できます:

      Market
  New York
    Cust A
  Illinois
    Cust B
  California
    Cust C
   

しかし、データのサンプリング規模を大きくしたところ、多数の顧客が各市場に存在することがわかったとします。たとえば、Cust AとCust EがNew Yorkに、Cust B、Cust MおよびCust PがIllinoisに、Cust CとCust FがCaliforniaに存在するとします。この状況では、一般的に、大きい次元である顧客を標準次元として定義し、小さい次元である市場を属性次元として定義します。市場次元のメンバーを顧客次元のメンバーの属性として関連付けます。市場次元のメンバーは、顧客の場所を表します。

      Customer (Standard dimension)
  Cust A (Attribute:New York)
  Cust B (Attribute:Illinois)
  Cust C (Attribute:California)
  Cust E (Attribute:New York)
  Cust F (Attribute:California)
  Cust M (Attribute:Illinois)
  Cust P (Attribute:Illinois)
Market (Attribute dimension)
  New York
  Illinois
  California
   

別の状況について考えます。同様に、製品を複数の市場の複数の顧客に販売する会社ですが、この会社は異なる複数の市場に存在する顧客に製品を発送することがあります:

                   Cust A  Cust B  Cust C
New York     100      75     N/A
Illinois     N/A     150     N/A
California   150     N/A      30
   

Cust AはNew YorkとCaliforniaに存在します。Cust BはNew YorkとIllinoisに存在します。Cust CはCaliforniaのみに存在します。この状況で属性次元を使用しても機能しません。顧客のメンバーは、複数の属性メンバーを持つことができません。このため、次のように2つの標準次元を使用してデータを設計します:

      Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California
   
次元の組合せ

2つの次元の各組合せを2次元マトリックスに配置します。たとえば、TBCの次元の候補(表2を参照)には、次の組合せがあります:

  • 年とメジャー

  • 年と製品

  • 年と市場

  • 年とシナリオ

  • メジャーと製品

  • メジャーと市場

  • メジャーとシナリオ

  • 市場と製品

  • 市場とシナリオ

  • シナリオと製品

  • オンスとパッケージ・タイプ

オンスとパッケージ・タイプは、属性次元として製品次元に関連付けられているので、製品次元と一緒に検討できます。

各次元を視覚的に表すために、マトリックスを作成し、最初の世代のメンバーのいくつかを配置します。図28は、3つの次元の簡単なマトリックスを示しています。

図 28. 次元の関係の分析

この図は、次元の関係の分析方法を示す、3つの次元の簡単なマトリックス・セットを示しています。

次元の各組合せに関する3つの質問について考えてみます:

  • その組合せによって、分析値が追加されますか?

  • その組合せによって、レポート作成のユーティリティが追加されますか?

  • 使用されない組合せが、過剰に生じないようになっていますか?

組合せごとにこの質問に答えることによって、その組合せがデータベースにとって有効であるかどうかを判断できます。すべての質問の答えが「はい」であるのが理想です。そうでない場合は、より有効な次元にデータを配置しなおすことを検討します。このプロセスで、必要な情報についてユーザーと話し合います。

アウトラインにおける繰返し

アウトラインにある要素の繰返しは、ほとんどの場合、次元を分割する必要があることを示しています。次の例で、繰返しを避ける方法を説明します。

図29では、左側の列「Repetition」では、「Accounts」次元の「Budget」と「Actual」の下に、「Profit」、「Margin」、「Sales」、「COGS」および「Expenses」が繰り返し表示されています。右側の列「No Repetition」では、「Budget」と「Actual」を別の次元(「Scenario」)に分け、「Accounts」次元には「Profit」、「Margin」、「Sales」、「COGS」および「Expenses」メンバーが1セットのみ表示されています。この方法によって、アウトラインが単純になり、データベースの他の次元の予算と実績の数値の表示がわかりやすくなります。

図 29. シナリオ次元を作成して繰返しをなくす例

この図は、この図の前のテキストで説明されている、繰返しの問題に対する1つの解決策を示しています。

図30では、左側の列「Repetition」で、ダイエット飲料を分析するために「Diet」次元の共有メンバーを使用しています。メンバー「100-20」、「200-20」および「300-20」は、「Diet」の下で1回、それぞれの親の下で1回表示されています。右側の列「No Repetition」では、ブール・タイプ(TrueまたはFalse)の「Diet」属性次元を作成して、アウトラインを単純にしています。すべてのメンバーはそれぞれの親の下に1回のみ表示され、該当する属性(「Diet: True」または「Diet: False」)でタグ付けされています。

図 30. 属性次元を作成して繰返しをなくす例

この図は、この図の前のテキストで説明されている、繰返しの問題に対する1つの解決策を示しています。

属性次元には、その他の分析機能もあります。属性次元の設計を参照してください。

次元間の無関係性

次元間の無関係性は、ある次元の多数のメンバーが他の次元にとって無関係であるときに起こります。Essbaseでは、要約(次元)レベルでのみEssbaseによって保管されるデータとして、無関係データを定義します。このような場合、データベースから次元を削除して、そのメンバーを他の次元に追加するか、モデルを個別のデータベースに分けることができます。

たとえば、TBCは、メジャー次元のメンバーとして給与を分析することを考えました。ただし、給与情報は、ほとんどの場合、企業データベースのコンテキストで無関係であることがわかりました。ほとんどの給与は機密情報で、個人に適用されます。個人と給与は一般的に、1つのセルを表し、他の次元と交差する必要はありません。

TBCは、従業員を個別の次元に分けることを考えました。表4は、次元間の無関係性について、TBCが従業員次元の候補を分析した様子を示しています。候補の従業員次元のメンバー(表のヘッダー行)を、メジャー次元のメンバー(左端の列)と比較しています。メジャー次元のメンバー(Revenueなど)はAll Employeesに関係します。Salaryメジャーのみが個々の従業員に関係しています。

表 4. 次元間の無関係性の例

 

Joe Smith

Mary Jones

Mike Garcia

All Employees

Revenue

無関係

無関係

無関係

関係あり

Variable Costs

無関係

無関係

無関係

関係あり

COGS

無関係

無関係

無関係

関係あり

Advertising

無関係

無関係

無関係

関係あり

Salaries

関係あり

関係あり

関係あり

関係あり

Fixed Costs

無関係

無関係

無関係

関係あり

Expenses

無関係

無関係

無関係

関係あり

Profit

無関係

無関係

無関係

関係あり

データベースを分割する理由

個別の従業員情報はデータベースの他の情報とは関係がなく、従業員次元を追加すると必要なデータベース・ストレージが大幅に増えるので、TBCでは人事部(HR)データベースを個別に作成しました。新しいHRデータベースには、関連する次元のグループが含まれ、給与、福利厚生、保険および401(k)プランの情報が保管されます。

データベースを分割する理由は様々です。たとえば、ある会社で、タイム・ゾーンの異なる複数の海外の子会社が含まれる組織データベースを運営しているとします。各子会社には、時間依存の財務計算が必要です。財務計算を適切なタイミングで提供できるように、タイム・ゾーンが同じ子会社のグループのデータベースを分割できます。また、パーティション化されたアプリケーションを使用して、子会社ごとに情報を分割できます。

データベース設計分析のチェックリスト

次のチェックリストを使用して、データベース設計を分析します。

  • 次元数は最小限に抑えていますか?

  • 次元の各組合せに関して、次のことを確認しましたか:

    • その組合せによって、分析値が追加されますか?

    • その組合せによって、レポート作成のユーティリティが追加されますか?

    • 使用されない組合せが、過剰に生じないようになっていますか?

  • アウトライン内における繰返しを回避しましたか?

  • 次元間の無関係性を回避しましたか?

  • 必要に応じてデータベースを分割しましたか?

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

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

注:

データベースを作成し、そのアウトラインを構築する前に、データベースの追加先のEssbaseアプリケーションを作成します。

TBCのプランナは、データベース・アウトラインに関して次のようなドラフトを発行しました。このプランでは、年、メジャー、製品、市場、シナリオ、パッケージ・タイプおよびオンスが次元名です。TBCが集計、計算、式およびレポートの要件をどのように予想したかについて説明します。プランナは、製品を説明するときに製品名ではなく製品コードを使用しています。

  • 年。TBCでは、毎月データを収集して、その月次データを四半期または年ごとに集計する必要があります。1月、2月、3月などのメンバーに保管される月次データは、四半期に集計されます。第1四半期、第2四半期などのメンバーに保管される四半期ごとのデータは、年に集計されます。

  • メジャー。売上高、売上原価、マーケティング、給与計算、その他、期首在庫、追加および期末在庫が標準のメジャーです。Essbaseでは、マージン、合計支出、利益、合計在庫、利益%、マージン%および1オンス当たりの利益をこのメジャーから計算できます。TBCでは、月ごと、四半期ごと、年ごとにメジャーを計算する必要があります。

  • 製品。製品コードは、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)に集計されます。各製品はオンス属性次元とパッケージ・タイプ属性次元のメンバーに関連付けられているので、TBCでは各集計によってサイズ別およびパッケージ別の分析を行えます。

  • 市場。複数の州で1つの地域が構成されます。4つの地域で1つの市場が構成されます。州は、コネチカット、フロリダ、マサチューセッツ、ニューハンプシャー、ニューヨーク、カリフォルニア、ネバダ、オレゴン、ユタ、ワシントン、ルイジアナ、ニューメキシコ、オクラホマ、テキサス、コロラド、イリノイ、アイオワ、ミズーリ、オハイオおよびウィスコンシンです。各州は、その地域(東部、西部、南部または中央)に集計されます。各地域は市場に集計されます。

  • シナリオ。TBCでは、予算と実績データを取り出して、追跡します。マネージャは、予算と実績、および予算と実績の差異と差異のパーセンテージを監視して追跡する必要があります。

  • パッケージ・タイプ。TBCでは、製品のパッケージングが売上高と利益に与える影響を確認したいと考えています。パッケージ・タイプ属性次元を作成することで、ユーザーは製品のパッケージ・タイプがビンであるのか缶であるのかに基づいて、製品情報を分析できます。

  • オンス。TBCでは、市場によって異なるサイズ(オンス単位)で製品を販売しています。オンス属性次元を作成することで、ユーザーは各市場の適切な販売サイズを監視できます。

次のトピックでは、次元とメンバー・プロパティの基本を概観し、パフォーマンスに影響を与えるアウトライン設計について説明します。

次元プロパティおよびメンバー・プロパティ

次元とメンバーのプロパティでは、多次元構造の設計での次元とメンバーの役割を定義します。そのプロパティは次のとおりです:

次元とメンバーのプロパティの詳細なリストは、次元およびメンバーのプロパティの設定。を参照してください。

次元タイプ

次元タイプは、Essbaseに用意されているプロパティの1つで、次元に特別な機能を追加します。最もよく使用される次元タイプは、時間、勘定科目および属性です。このトピックでは、TBCデータベースの次の次元を使用して、次元タイプを説明します。

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

表5で、各Essbase次元タイプを定義します。

表 5. 次元タイプ

次元タイプ

説明

なし

特定の次元タイプを指定しません。

時間

データをレポートおよび更新する期間を定義します。「時間」というタグを付けることができる次元は1つのみです。時間次元によって、期首タイム・バランスや期末タイム・バランスなどの複数の会計次元の関数が使用可能になります。

会計

利益や在庫などの測定するアイテムを含み、Essbaseの組込み会計機能を使用可能にします。勘定科目として定義できる次元は1つのみです。

2つの形式の会計次元の計算については、会計次元の計算を参照してください。

属性

別の関連次元のメンバーを分類する際に使用するメンバーを含みます。

たとえば、Pkg Type属性次元には、Product次元のメンバーに適用される容器の各タイプ(ビンや缶など)に対応するメンバーが含まれます。

ビジネス活動が行われる場所に関するデータを含みます。国次元では、各メンバーで使用される通貨を指定できます。

たとえば、カナダにはバンクーバー、トロント、モントリオールという3つの市場があり、すべての市場で同じ通貨(カナダ・ドル)を使用します。

通貨パーティション

現地通貨メンバーをアプリケーションで定義されている基本通貨から分離します。この次元タイプは、メイン・データベースでのみ使用し、通貨換算アプリケーション専用です。分析用に基本通貨を米国ドルにすることができ、現地通貨メンバーには、各地域の通貨タイプに基づいた値を入れることができます。

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

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

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

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

表 6. Essbaseデータ・ストレージ・プロパティ

データ・ストレージ・プロパティ

メンバーへの影響

データの保管

メンバーはデータを保管します。データの保管はデフォルトのストレージ・プロパティです。

動的計算

メンバーに関連付けられたデータはユーザーによって要求されるまで計算されません。計算されたデータは保管されません。要求の完了後に破棄されます。

動的計算および保管

メンバーに関連付けられたデータはユーザーによって要求されるまで計算されません。計算されたデータは保管されます。

共有メンバー

メンバーに関連付けられたデータは、同じ名前を持つ別のメンバーから取得されます。

共有しない

暗黙的な共有関係が存在する場合に、メンバーに関連付けられたデータは、その親および子に複写されます。

ラベルのみ

ラベルのみメンバーにはデータが関連付けられませんが、値を表示できます。ラベルのみメンバーは、メンバーをグループ化し、ナビゲーションとレポートを容易にします。通常、ラベルのみメンバーは計算されません。

たとえば、メジャー次元のメンバー「比率」に3つの子(マージン%、利益%および1オンス当たりの利益)が設定されているとします。メンバー「比率」では、メンバーのカテゴリを定義しています。マージン%、利益%および1オンス当たりの利益は集計しても比率として意味のある数値にロール・アップされません。このため、比率にラベルのみのタグが付きます。

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

  • 時間次元を明確化できましたか?

  • 会計次元を明確化できましたか?

  • データに外貨が含まれますか?含まれる場合、通貨パーティション次元を明確化できましたか?

  • 別の属性次元として定義するべき次元の特性を明確化できましたか?

  • 特殊なデータ・ストレージ・プロパティを必要とするメンバーはどれですか?

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

属性次元をアウトラインの最後に置きます。疎次元の前に密次元を置きます。

アウトライン内の次元の位置および次元のストレージ・プロパティは、パフォーマンスの2つの面に影響を及ぼす可能性があります。1つは計算の実行速度、もう1つはユーザーが情報取得に要する時間です。

次のトピックでは、パフォーマンスの最適化の基本について説明します。

クエリーのパフォーマンスの最適化

クエリーのパフォーマンスを最適化するには、アウトラインの設計時に、次のガイドラインに従います:

  • アウトラインに属性次元がある場合、その属性次元が動的計算疎次元のみであることを確認します。

  • アウトラインでは、クエリーの少ない疎次元の前にクエリーの多い疎次元を置きます。

図31のアウトラインは、最適なクエリー・パフォーマンスを実現します:

  • このアウトラインには属性次元があるので、標準次元およびすべての標準次元メンバーに対するストレージ・プロパティは、データの保管として設定されます。

  • 最もクエリーの多い疎次元として、「Product」次元が疎次元の1番目に配置されています。「Base」次元は一般的に、他の次元よりも多くクエリーされます。

図 31. クエリー所要時間を最適化するためのアウトラインの設計

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

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

計算のパフォーマンスを最適化するには、アウトライン内の疎次元をメンバー数の順に配列します。その際、最もメンバー数の少ない次元を先頭に配置します。

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

図32のアウトラインは、最適な計算のパフォーマンスを実現します:

  • 最も小さい疎の標準次元である「Market」は、アウトライン内の疎次元の先頭に配置されています。

  • 疎次元の中で最も大きい標準次元である「Product」は、最初の属性次元のすぐ上に配置されています。アウトラインに属性次元がない場合は、「Product」次元がアウトラインの最後になります。

図 32. 計算所要時間を最適化するためのアウトラインの設計

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

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

図31図32のアウトライン例には、同じ次元が含まれていますが、この2つのアウトラインはそれぞれ異なります。状況に最適なアウトラインの順序を決定するには、データベースで計算を実行するために必要な時間に対するユーザーのデータ取得要件を優先させます。データベースの更新と再計算の頻度はどれくらいですか?ユーザー・クエリーの性質は?ユーザー・クエリーの予想量は?

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

システム要件のチェック

ここでは、データベースのシステム要件を確認します。

テスト・データのロード

計算、集計およびレポートをテストするためには、データベースにデータを用意する必要があります。設計プロセス中に、ダミー・データまたは実際のデータのサブセットをロードすると、柔軟性が生まれ、テストと結果の分析に必要な時間を短縮できます。

データのロードの詳細な指示は、次の章を参照してください:

予備テストを行い、データベース設計が適切であると判断した場合は、最終的なデータベースに読み込む実際のデータの完全なセットをテスト・ロードします。可能な場合は、テスト・ルール・ファイルを使用します。この最終テストによって、前の設計プロセス・フェーズで予測できなかった、ソース・データの問題が明らかになる可能性があります。

計算の定義

計算は、特定のタイプのデータを導き出すために必要です。計算から導き出されたデータを計算済データと呼び、基本の計算されていないデータを入力データと呼びます。

次のトピックでは、TBCアプリケーションの製品次元とメジャー次元を使用して、多くのEssbaseデータベースで見られる、一般的な計算のいくつかを紹介します。

ブロック・ストレージ計算の詳細は、次の章を参照してください:

次元およびメンバーの集計

標準次元のメンバーを定義すると、Essbaseによって自動的に、集計時にメンバーが加算されることを意味する+(加算を表すプラス符号)集計演算子がメンバーにタグ付けされます。メンバー集計プロパティは、必要に応じて、表7に示されている演算子のいずれかに変更できます。

集計は、Essbaseで最もよく使用される計算です。このトピックでは、製品次元を使用して集計について説明します。

TBCのアプリケーションには、次のようにいくつかの集計パスがあります:

  • 各製品をロール・アップしたものが製品ファミリであり、製品ファミリを集計したものが製品です。TBCのアウトラインには複数の集計パスも必要です。一部の製品は複数のカテゴリに集計する必要があります。

  • 州をロール・アップしたものが地域であり、地域を集計したものが市場です。

  • 月をロール・アップしたものが四半期であり、四半期を集計したものが年です。

次のトピックでは、集計の詳細について説明します:

集計演算子は、Essbaseで分岐の各メンバーのデータを親へロール・アップする方法を定義します。たとえば、デフォルトの加算(+)演算子を使用した場合、Essbaseでは、図33に示すように、100‑10、100‑20および100‑30を加算して、その結果を親100に保管します。

図 33. TBCの製品次元

この図は、この図の前のテキストで説明されている、アウトラインの集計演算子を示しています。

製品次元の大部分では、加算(+)演算子が使用されています。この演算子は、各メンバー・グループが加算され、親にロール・アップされることを示します。Dietにはチルダ(~)演算子が使用されています。この演算子は、Essbaseでは親である製品への集計にDietメンバーが入らないことを示します。Dietメンバーは、共有されるメンバーのみで構成されています。TBC製品管理グループは、レポートでダイエット飲料を分離することを望んでいるため、TBCは全体の集計に影響を与えないDietメンバーを個別に作成しました。

集計における位置および演算子の影響

Essbaseでは、上から下の方向に分岐のデータを計算します。たとえば、加算(+)演算子がタグ付けされた2つのメンバーの次に、乗算(*)演算子がタグ付けされた3番目のメンバーがあるとします。Essbaseでは、最初の2つのメンバーを加算し、その合計に3番目のメンバーを乗算します。

Essbaseでは、必ず最上位メンバーから集計を始めるので、メンバーの順序とラベルが重要です。異なる演算子を持つ場合のメンバーの計算を参照してください。

表7に、Essbaseの集計演算子を定義します。

表 7. 集計演算子

集計演算子

説明

プラス記号(+)

デフォルトの演算子です。Essbaseによって、分岐のメンバーに対して前に実行された計算の結果にメンバーが加算されます。

ダッシュ(-)

Essbaseによって、メンバーに‑1が乗算され、その積が、分岐のメンバーに対して前に実行された計算の結果に加算されます。

アスタリスク(*)

Essbaseによって、メンバーに、分岐のメンバーに対して前に実行された計算の結果が乗算されます。

スラッシュ(/)

Essbaseによって、分岐のメンバーに対して前に実行された計算の結果が、メンバーで除算されます。

パーセント記号(%)

Essbaseによって、分岐のメンバーに対して前に実行された計算の合計が、メンバーで除算されます。その結果に100が乗算されます。

チルダ(~)

Essbaseでは、親への集計にメンバーの値は使用されません。

キャレット(^)

Essbaseで、次元の集計にメンバーの値が使用されることはありません。

共有メンバーの集計

共有メンバーも集計パスに影響を与えます。共有メンバーの概念では、2つのメンバーが同じ名前を使用して同じデータを共有できます。共有メンバーは、他のメンバーに含まれているデータへのポインタを保管するので、Essbaseでは、データを1回のみ保管します。共有メンバーは同じ次元に属する必要があります。データは、複数のメンバーで共有できます。

集計のチェックリスト

次のチェックリストを使用して、集計を定義します:

  • アウトラインにおける集計を明確化しましたか?

  • 各メンバーに適切な集計演算子のタグを付けましたか?

  • 所定のメンバーに対して、共有メンバーのタグを指定しましたか?

  • 共有メンバーを(共有ではなく)属性次元内に指定した場合、より効率的になりますか?

メジャー次元の例でのタグおよび演算子

メジャー次元は、時間データと勘定科目データの両方を使用するので、TBCアウトラインで最も複雑な次元です。この次元には、Essbaseでのアウトラインの計算に役立つ式と特殊なタグも保管されています。このトピックでは、TBCがメジャー次元(勘定科目タグが付けられた次元)に保管した式とタグについて説明します。

(図34にある)TBCによって定義されたメジャー次元のタグをよく見てください。メジャー次元のほとんどのプロパティについては、この章の前のトピックで説明しています(加算(+)、減算(-)および集計なし(~)演算子、勘定科目タグとラベルのみタグ):

  • InventoryメンバーおよびRatiosメンバーは、ユーザーによるデータの操作を支援するためのものです。このメンバーにデータは含まれていません。したがって、ラベルのみタグが付いています。

  • メジャー次元自体にはラベルのみタグが付いています。メジャーの一部のメンバーには、動的計算タグが付いています。動的計算については、動的計算を参照してください。

  • メジャーの一部のメンバーにはタイム・バランス・タグ(TB FirstまたはTB Last)が付いています。タイム・バランス・タグについては、タイム・バランス・プロパティの設定を参照してください。

図 34. TBCのメジャー次元

この図は、この図の前のテキストで説明されている、TBCのメジャー次元内のメンバーのプロパティ(集計演算子やタグなど)を示しています。

会計次元の計算

このトピックでは、勘定科目タグが付けられた次元を計算するための2つのフォーム(タイム・バランス・プロパティと差異レポート)について説明します。

タイム・バランス・プロパティ

表9のメジャー次元には、TB期首とTB期末という2つのタグがあります。これらのタグは、タイム・バランス・タグまたはプロパティと呼ばれ、勘定科目タグが付けられた次元でのデータの計算方法に関する指示をEssbaseに提供します。タグを使用するには、勘定科目タグが付けられた次元と時間タグが付けられた次元が必要です。期首、期末、平均および支出タグは、会計次元メンバーでのみ使用できます。

TBCメジャー次元では、期首在庫データは、各月の初めにTBCが持っている在庫を表します。期首在庫の四半期ごとの値は、四半期の期首の値に等しいです。期首在庫には、タイム・バランス・タグ「TB期首」が必要です。

期末在庫データは、各月の終わりにTBCが持っている在庫を表します。期末在庫の四半期ごとの値は、四半期の期末の値に等しいです。期末在庫には、タイム・バランス・タグ「TB期末」が必要です。表8では、会計次元のタイム・バランス・タグを定義しています。

表 8. 勘定科目のメンバーのタグ

タグ

説明

タイム・バランス期末

最後の子メンバーの値が親に渡されます。たとえば、3月が第1四半期に渡されます。

タイム・バランス期首

最初の子の値が親に渡されます。たとえば、1月が第1四半期に渡されます。

表9で、第1四半期(右から2番目の列)と年(一番右側の列)は、会計次元のタイム・バランス・プロパティが時間次元の集計に与える影響を示しています。データは第1四半期分のみが表示されています。

表 9. タイム・バランス・プロパティがTBCの集計に及ぼす影響

次元

1月

Feb

Mar

第1四半期

勘定科目メンバー1

11

12

13

36

Qtr1 + Qtr2 + Qtr3 + Qtr4

勘定科目メンバー2 (TB期首)

20

25

21

20

20

勘定科目メンバー3 (TB期末)

25

21

30

30

Qtr4の値

通常、時間次元の親の計算は、その親の子の集計と式に基づきます。ただし、勘定科目の分岐のメンバーが「TB期首」とマークされている場合、時間次元のすべての親は、「TB期首」とマークされているメンバーに合わせます。

例については、タイム・バランス・プロパティの設定を参照してください。

差異レポート

TBCのEssbase要件の1つは、実績データと予算データの差異レポートを実行できることです。差異レポート計算では、会社の支出を表すすべてのアイテムに支出レポート・タグを付ける必要があります。在庫メンバー、合計支出メンバーおよびCOGSメンバーにそれぞれ、差異レポート用の支出レポート・タグを付けます。

Essbaseには、支出と支出外という2つの差異レポート・プロパティが用意されています。デフォルトは支出外です。差異レポート・プロパティでは、メンバーの実績データと予算データの差異を、そのメンバー式の@VAR関数または@VARPER関数を使用してEssbaseで計算する方法を定義します。

メンバーに「支出」のタグを付けた場合、@VAR関数では予算から実績を減算します。たとえば、予算額が$100で、実績の金額が$110の場合、その差異は-10です。

支出レポート・タグを付けなかった場合、@VAR関数では実績から予算を減算します。たとえば、予算額が$100で、実績の金額が$110の場合、その差異は10です。

式および関数

式は、データベース・アウトラインのメンバー間の関係を計算します。式は、アウトラインのメンバーに適用するか、計算スクリプトに置くことができます。このトピックでは、式を使用してTBCがどのようにパフォーマンスを最適化したかについて説明します。

関数は、専用の計算を実行し、メンバーのセットまたはデータ値のセットを戻す、事前定義ルーチンです。式は、演算子、関数、次元名、メンバー名および数値定数で構成されます。

Essbaseでは次の演算子をサポートします:

  • 算術演算を実行する算術演算子

  • 論理条件を計算に組み込む条件演算子

  • データベース・メンバーの特定の組合せのデータ値を示す次元間演算子

Essbaseの関数には、Essbaseの計算機能を拡張するための100を超える事前定義ルーチンが組み込まれています。Essbaseでは次の関数をサポートします:

  • ブール関数。この関数はTRUEまたはFALSEの値を戻すので、条件付テストを実行できます。

  • 数学関数。この関数は専用の数学計算を実行します。

  • 関係関数。この関数は、現在のメンバーの位置に基づいて、計算時にデータベース内のデータ値を調べます。

  • 範囲関数。この関数は、メンバーの範囲を、別の関数またはコマンドに対する引数として宣言します。

  • 財務関数。この関数は専用の財務計算を実行します。

  • メンバー・セット関数。この関数は、指定されたメンバーに基づいており、メンバーのリストを生成します。

  • 割当て関数。この関数は、親レベルで入力された値を子メンバーに割り当てます。

  • 予測関数。この関数は、データの平滑化、データの補間または将来の値の計算のために、データを操作します。

  • 統計関数。この関数は高度な統計値を計算します。

  • 日付関数および時刻関数。この関数は、計算式の中で日付特性および時刻特性を使用します。

  • 計算モード関数。この関数は、式を計算するためにEssbaseで使用する計算モードを指定します。

メジャー次元では、次の式を使用します:

  • Margin = Sales - COGS

  • Total Expenses = Marketing + Payroll + Miscellaneous

  • Profit = Margin - Total Expenses

  • Profit % = Profit % Sales

  • Margin % = Margin % Sales

  • Profit per Ounce = Profit / @ATTRIBUTEVAL(@NAME(Ounces))

Essbaseでは、集計演算子を使用して、Margin、Total ExpensesおよびProfitメンバーを計算します。Margin%式では、%演算子を使用しています。これは、「MarginをSalesのパーセンテージで表す」を意味します。Profit%式でも同じ%演算子を使用しています。Profit per Ounce式では、除算演算子(/)と関数(@ATTRIBUTEVAL)を使用して、オンス単位で作られた製品の1オンス当たりの収益性を計算します。

注:

Profit per Ounceの式では、@ATTRIBUTEVAL関数の文字列Ouncesを処理するために、@NAME関数も使用しています。

演算子、関数および構文の詳細なリストは、『Oracle Essbaseテクニカル・リファレンス』を参照してください。ブロック・ストレージ・データベース用の式の作成も参照してください。

動的計算

データベース全体の計算を設計するときに、メンバーを動的計算メンバーとして定義できます。メンバーに動的計算タグを付けると、Essbaseでは、通常のデータベース計算時にメンバーの組合せを事前に計算するのではなく、データの取得時にメンバーの組合せを計算します。動的計算によって、通常のデータベース計算にかかる時間は短くなりますが、動的に計算されたデータ値を取得する時間が増える可能性があります。

図35で、TBCのメジャー次元のメンバーProfit、Margin、Total Expenses、Margin %およびProfit %に、動的計算タグが付けられています。

図 35. TBCのメジャー次元における動的計算タグ

この図は、この図の前のテキストで説明されている、動的計算としてタグ付けされたTBCのメジャー次元のメンバーを示しています。

データベース全体の計算を実行すると、動的計算メンバーとそれに対応する式は、計算されません。これらのメンバーは、ユーザーが、たとえばSmart Viewから要求したときに計算されます。Essbaseでは計算された値は保管されません。値は、次の取得時に再計算されます。ただし、最初の取得後に動的に計算された値を保管することを選択できます。

データ値を動的に計算すべきか否かを決定する際、次の点に関する優先度を検討してください:

  • 定期的な計算時間(バッチ計算)の最適化

  • ディスク・スペースの使用率の低下

  • データベースの再構築時間の短縮

  • ユーザーがデータ取得に要する時間の短縮

  • バックアップ時間の短縮

データ値の動的計算を参照してください。

2パス計算

TBCデータベースでは、Margin %とProfit %にラベル2パスが付いています。このデフォルトのラベルは、一部のメンバー式を2回計算して、目的の値を算出する必要があることを示します。2パス・プロパティは、勘定科目タグが付けられた次元のメンバー、動的計算タグまたは動的計算および保管タグが付けられたメンバーに対してのみ作用します。

次の例では、(式Profit % Salesに基づく) Profit %に2パス・タグが付いている理由を説明します。表には、5つの列(列ヘッダーは左から「次元」、「Jan」、「Feb」、「Mar」、「Qtr1」)と3つの行(「Profit」、「Sales」、「Profit %」)があります。Jan、Feb、MarおよびQtr1は、年次元のメンバーです。Profit、SalesおよびProfit %は、メジャー(勘定科目)次元のメンバーです。

表10では、Essbaseにロードする初期データを定義しています。Profit -> Jan、Profit -> FebおよびProfit -> Marのデータ値は100です。Sales -> Jan、Sales -> FebおよびSales -> Marのデータ値は1000です。

表 10. Essbaseにロードされたデータ

次元

Jan

Feb

Mar

Qtr1

Profit

100

100

100

該当なし

Sales

1000

1000

1000

該当なし

Profit %

該当なし

該当なし

該当なし

該当なし

まず、Essbaseでは、メジャー次元を計算します。表11のProfit % -> Jan、Profit % -> FebおよびProfit % -> Marのデータ値は10%です。

表 11. Essbaseでメジャー次元を計算後のデータ

次元

Jan

Feb

Mar

Qtr1

Profit

100

100

100

Sales

1000

1000

1000

Profit %

10%

10%

10%

該当なし

次に、Essbaseでは、年次元を計算します。データは、次元全体でロール・アップされます。表12のProfit -> Qtr1 (300)およびSales -> Qtr1 (3000)のデータ値は正しいです。Profit %に2パス計算のタグが付けられているので、Profit % -> Qtr1 (30%)のデータ値は正しくありません。

表 12. Essbaseで年次元を計算後のデータ

次元

Jan

Feb

Mar

Qtr1

Profit

100

100

100

300

Sales

1000

1000

1000

3000

Profit %

10%

10%

10%

30%

Essbaseでは、メンバーProfit %の出現ごとに利益パーセンテージを再計算します。表13のProfit % -> Qtr1 (10%)は、2回目のパスが実行された後で正しくなります。

表 13. Essbaseで利益パーセンテージを再計算後のデータ

次元

Jan

Feb

Mar

Qtr1

Profit

100

100

100

300

Sales

1000

1000

1000

3000

Profit %

10%

10%

10%

10%

計算のチェックリスト

次のチェックリストを使用して、計算を定義します:

  • デフォルトの計算ロジックで正確な結果が出ますか?

  • 式が必要なメンバーはどれですか?

  • 「タイム・バランス」タグが必要なメンバーはどれですか?

  • 差異レポートが必要なメンバーはどれですか?

  • 2パス計算が必要なメンバーはどれですか?

  • 「動的計算」タグを付けられるメンバーはどれですか?

注:

Essbaseのトリガー機能によって、データベース内のデータ変更の効率的な監視が可能になります。トリガー定義の理解を参照してください。

レポートの定義

設計が確実にユーザー情報の要件を満たすようにするには、データをユーザーに表示されるとおりに表示する必要があります。ユーザーは通常、スプレッドシート、印刷されたレポートまたはWeb上で公開されたレポートを通してデータを表示します。オラクル社およびそのパートナーは、ユーザーが使用するレポート作成システムを生成するための多くのツールを提供しています。

いくつかのツールは、データの表示やフォーマットをすばやく行ったり、データベース設計がユーザーのニーズを満たしているかどうかをテストしたりするのに役立ちます。管理サービス・コンソールにあるレポート・スクリプト・エディタを使用すると、レポート・スクリプトをすばやく記述できます。スプレッドシートに精通しているユーザーは、Smart Viewを使用できます(この場合はProvider Servicesが必要です)。

設計フェーズでは、次の項目を確認してください:

  • データのグループ化と順序付け。設計で使用可能になった交差によって、ユーザーが必要なデータが提供されますか?

  • 合計のレベル。たとえば、アウトライン設計の階層をドリル・ダウンおよびドリル・アップするSmart Viewのユーザーに必要な集計レベルは何ですか?

  • 属性のレポート。データベース設計によって、特定の次元またはメンバーの特性または属性に基づいた分析が容易になりますか?たとえば、16オンスのビン詰めコーラの売上高と32オンスのビン詰めコーラの売上高の比較など、サイズやパッケージングの特定の組合せで売上高を比較する必要がありますか?

事前に指定された使用レポートを作成したり、テスト・データに対してテストしたりする場合は、必ず適切なツールを使用するようにしてください。設計したレポートによって、元の目的を満たす情報が提供される必要があります。レポートを使いやすくして、データの適切な組合せと、適切なデータ量が提供されるようにしてください。多数の列や行が含まれているレポートは使用しにくいため、すべてを包含した1つのレポートではなく、複数のレポートを作成することが必要になる場合があります。

設計の確認

データを分析して予備の設計を作成した後、ユーザーとともに設計のすべての側面をチェックします。データベースがユーザーの分析やレポート作成のニーズを満たしていることはすでに確認しているはずです。データベースが、ユーザーのすべての目標を満たしていることを確認します。

計算は、ユーザーが必要としている情報を提供していますか?ユーザーはレポートをすばやく生成できますか?ユーザーは集計回数に満足していますか?つまり、データベースがユーザーのために機能しているかどうかをユーザーに尋ねます。

設計サイクルの終了近くになったら、実際のデータを使用してテストします。アウトラインは正常に構築されますか?すべてのデータがロードされますか?データベースがいずれかの領域で失敗した場合は、設計サイクルの手順を繰り返して問題の原因を識別します。

Essbaseによって、問題の分離に役立ついくつかの情報源が提供されます。これらの情報源には、アプリケーションやEssbaseサーバーのログ、例外ログ、Administration Servicesからアクセス可能なデータベース情報などが含まれます。問題に関連するドキュメントのトピック、たとえば、セキュリティ、計算、レポートまたは一般的なエラー・メッセージに関するトピックを参照してください。このガイドの索引を使用すると、問題の解決に役立ちます。トラブルシューティング、ログ、最適化、パフォーマンス、リカバリ、リソース、エラー、警告などの用語を探してください。

理想的なデータベース・ソリューションに到達するには、設計プロセスの手順を何度か繰り返す必要もあると思われます。