Essbaseアプリケーションの分析および計画
Essbaseアプリケーションでビジネス情報を効率的に分析できるようにするには、データ・ソース、ユーザー・ニーズおよび予想されるデータベース要素についてアウトラインを示す詳細なプランを策定します。この設計フェーズに注意を払うことで、開発と実装の時間を節約できます。
プランニングと分析のフェーズでは、次のタスクを実行します。
マルチディメンショナル・アプリケーションを設計するとき、次の要因を考慮します。
-
社内での情報の流れ: 誰がどのデータを何の目的で使用するのか
-
会社が作成するレポートのタイプ: レポートに関するユーザー・ニーズを満たすために、アウトラインにどのタイプのデータを含める必要があるのか
ノート:
アプリケーションごとに定義するデータベースを1つのみにすると、メモリー使用率が向上し、データベース管理が容易になります。
ソース・データの分析
Essbaseデータベースに含めるデータを評価します。その取得元および必要な更新の頻度とサイズを検討します。Essbaseには、ピボット・レポートおよびドリルスルーに必要なもののみをロードする必要があります。残りは、パーティションまたはドリルスルーによってアクセス可能なリレーショナル・ソースに保持できます。
データベースのスコープを決定します。膨大な数の製品を含む製品ファミリが組織に多数存在する場合、製品ファミリのデータ値のみを保管できます。各ユーザー部門のメンバーにインタビューを実施して、どのようなデータを処理しているのか、現在はどのような方法でデータを計算してレポート作成しているのか、将来どのような方法でデータを処理していきたいのかを確認します。
レポートおよび分析に関するニーズを慎重に定義します。
-
ユーザーはどのようにデータを表示および分析する必要があるのか
-
データベースにどの程度詳細なデータを含めるか
-
データは必要な分析およびレポート作成に関する目標を満たしているか
-
満たしていない場合、どのようなデータを追加する必要があり、そのデータはどこにあるのか
現在のデータの場所を特定します。
-
各部門は現在どこにデータを保存しているのか
-
データはEssbaseで使用できる形式になっているか
-
部門はWindowsまたはUNIXサーバーのリレーショナル・データベース、またはExcelスプレッドシートにデータを保存しているか
-
誰がどれぐらいの頻度でデータベースを更新するのか
-
データの更新を必要としているユーザーがデータにアクセスできるか
Essbaseにデータをロードする準備ができていることを確認します。
-
データソースは単一か複数か
-
データはEssbaseで使用できる形式になっているかEssbaseにロードできる有効なデータ・ソースのリストについては、「データ・ソース」を参照してください。
-
使用するすべてのデータの準備ができているか
ユーザー要件の明確化
Essbaseデータベースの計画時に、データの現在のユーザーと情報のニーズについて話し合い、それらのユーザーからのサンプル・レポートを要求します。ユーザーが使用する情報と、他のユーザーによる確認用に作成する必要があるレポートを確認します。
次の要件について、判断します。
-
ユーザーはどのようなタイプの分析を必要としていますか。
-
ユーザーは、アドホック(ピボット・スタイル)レポートと構造化レポートを必要としていますか。
-
ユーザーは、どのような要約レベルおよび詳細レベルの情報を必要としていますか。
-
あるユーザーは、他のユーザーが表示できない情報にアクセスする必要がありますか。
複数ユーザー環境におけるセキュリティの計画
Essbaseのセキュリティ権限の設定方法の計画の一環として、様々なレベルのユーザー情報ニーズを特定します。分析の終了までに、ユーザーとその必要な権限のリストが必要です。
次のチェックリストを使用して、セキュリティを計画します。
-
ユーザーは誰で、データベース内のデータの読取りまたは書込みのためにどの権限を付与しますか。
-
データ・ロード権限は誰に付与しますか。
-
計算を実行する権限は誰に付与しますか。
-
どのユーザーをグループ化して同様の権限を割り当てることができますか。
ユーザーとロールの管理を参照してください。
データベース・モデルの作成
Essbaseデータベースのモデルを作成します。モデルを構築するには、ビジネスにとって重要なパースペクティブとビューを識別する必要があります。これらのビューが、データベース・モデルのディメンションになります。
多くのビジネスでは、次のビューを分析します。
-
期間
-
メジャー
-
シナリオ
-
製品
-
顧客
-
地域
-
ビジネス・ユニット
次に、情報の収集と意思決定を支援するために、データ分析の目標を特定し、データベースのディメンションとメンバーを決定し、データベース設計を分析する必要があります。
分析対象の特定
業務における情報の主要なビューを特定した後、Essbaseデータベースを設計する次のステップは、データベースでデータを分析する方法を決定することです。たとえば、期間別、地理別または製品タイプ別にデータを表示することが必要になる場合があります。
-
時間で分析する場合、どの期間が必要ですか。分析には現在の年のみを含めますか、複数の年を含めますか。分析には四半期ごとのデータと月ごとのデータを含めますか。季節ごとのデータを含めますか。
-
地理的な地域で分析する場合、地域をどのように定義しますか。地域を販売区域ごとに定義しますか。都道府県や市区町村などの地理的な境界で地域を定義しますか。
-
製品ラインで分析する場合、各製品のデータを確認しますか。データを製品クラスに要約できますか。
ビジネス・ビューに関係なく、分析に必要なパースペクティブと詳細を決定する必要があります。分析するビジネス領域ごとに、異なるデータのビューが提供されます。
ディメンションおよびメンバーの決定
選択したEssbaseディメンションによって、実行できる分析のタイプが決まります。各ディメンション内では、メンバーの階層はビジネスの側面を表します。たとえば、時間階層には四半期と月を含めることができます。製品階層は製品を分類します。地域階層は地理的市場に基づいています。
各ビジネス・ビューをデータベース内の個々の標準ディメンションとして表現できます。ビジネス・アナリストが、製品別、地域別、期間別など、ビジネスの「別」に言及することがあります。分類や属性(製品のサイズや色など)によってビジネス・ビューを分析する必要がある場合、属性ディメンションまたはプロパティを使用して分類ビューを表現できます。
分析のニーズにあわせて必要な数のディメンションを使用できます。必要なディメンションとメンバーをほぼ把握できている場合は、仮のデータベース設計を開発します。
データベース・モデルのディメンションを決定したら、各ディメンション内の要素またはアイテムを選択します。これらの要素がそれぞれのディメンションの階層およびメンバーになります。たとえば、時間の階層には、分析対象の期間(四半期、四半期内の月など)が含まれます。各四半期と月は、時間に対して作成するディメンションのメンバーになります。四半期と月は、メンバーとその子の2レベルの階層を表します。四半期内の月を集計すると、その四半期の合計が得られます。
ディメンション間の関係
ディメンション間の関係について考えます。Essbaseデータベースは、ユーザーが多くのパースペクティブから情報を簡単に分析できる構造になっています。たとえば、財務アナリストが次のような疑問を持つとします。
-
特定の月の売上はどのくらいか。この数字は過去5年間の同月の売上と比べてどうか。
-
利益マージンは何パーセント増加しているか。
-
実績値は予算値にどの程度近いか。
つまり、アナリストは、時間、勘定科目およびシナリオの3つのディメンションから情報を調査する必要があります。次に示すサンプル・データベースはこれらの3つのディメンションを表し、3つの軸それぞれに沿って1つのディメンションが表されています。
-
時間ディメンション。Jan、Feb、MarおよびQtr1の合計で構成され、X軸に沿って示されます。
-
勘定科目ディメンション。会計数値(Sales、COGS、Margin、Margin%など)で構成され、Y軸に沿って示されます。
-
もう1つのディメンション。別の視点(予算値のBudgetや実績値のActualなど)を提供し、Z軸に沿って示されます。
図1-1 3つのデータベース・ディメンションを表すキューブ
キューブ内のセル(メンバーが交差している箇所)には、交差している3つのメンバーすべてに関連するデータが含まれています。たとえば、1月の販売実績などです。
ディメンションとメンバーの構造の例
次の表は、TBCのディメンションの要約を示しています。アプリケーション・デザイナは3つの列を作成し、左の列にディメンション、右の2つの列にメンバーを配置しました。列3のメンバーは列2のメンバーのサブカテゴリです。列3のメンバーが別のレベルのサブカテゴリに分割される場合もあります。たとえば、MeasuresディメンションのMarginは、SalesとCOGSに分割されます。
表1-1 TBCのサンプルのディメンション
| ディメンション | メンバー | 子メンバー |
|---|---|---|
|
Year |
Qtr1 |
Jan、Feb、Mar |
|
Year |
Qtr2 |
Apr、May、Jun |
|
Year |
Qtr3 |
Jul、Aug、Sep |
|
Year |
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 |
|
Product |
Colas (100) |
Cola (100‑10)、Diet Cola (100‑20)、Caffeine Free Cola (100‑30) |
|
Product |
Root Beer (200) |
Old Fashioned (200‑10)、Diet Root Beer (200‑20)、Sarsaparilla (200‑30)、Birch Beer (200‑40) |
|
Product |
Cream Soda (300) |
Dark Cream (300‑10)、Vanilla Cream (300‑20)、Diet Cream Soda (300‑30) |
|
Product |
Fruit Soda (400) |
Grape (400‑10)、Orange (400‑20)、Strawberry (400‑30) |
|
Market |
East |
Connecticut、Florida、Massachusetts、New Hampshire、New York |
|
Market |
West |
California、Nevada、Oregon、Utah、Washington |
|
Market |
South |
Louisiana、New Mexico、Oklahoma、Texas |
|
Market |
Central |
Colorado、Illinois、Iowa、Missouri、Ohio、Wisconsin |
|
Scenario |
Actual |
該当なし |
|
Scenario |
Budget |
該当なし |
|
Scenario |
Variance |
該当なし |
|
Scenario |
Variance % |
該当なし |
また、アプリケーション・デザイナは、サイズおよびパッケージに基づいて製品を分析できるようにするために、次の属性ディメンションを追加しました。
表1-2 TBCのサンプルの属性ディメンション
| ディメンション | メンバー | 子メンバー |
|---|---|---|
|
Ounces |
Large Small |
64, 32, 20 16, 12 |
|
Pkg Type |
Bottle Can |
該当なし |
ディメンションおよびメンバーを決定するためのチェックリスト
モデル・データベースのディメンションおよびメンバーを決定するときには、次のチェックリストを使用します。
-
ディメンションの候補には何がありますか。
-
他のディメンションを分類または説明するディメンションはありますか。そのようなディメンションは、属性ディメンションの候補です。
-
ユーザーはディメンションのビューを限定することを希望していますか。ユーザーがディメンションを限定するカテゴリは、属性ディメンションの候補です。
-
メンバーの候補には何がありますか。
-
データにはいくつのレベルが必要ですか。
-
データをどのように集計しますか。
データベース設計の分析
ディメンション数、それらの結合分析値および繰返しの回避に関する次のガイドラインに従って、最初のEssbaseディメンション設計を確認します。この事前分析を実行すると、データの集計と計算の目標を満たす効率的なデータベース設計を実現できます。
潜在的データ・ポイントを記述するために必要なメンバーの数によって、ディメンションの数が決まります。ディメンションを削除する必要があるかどうかわからない場合は、ディメンションを保持して、削除または保持する確信が得られるまで、さらに分析ルールを適用します。
密ディメンションおよび疎ディメンション
どのディメンションが疎で、どのディメンションが密であるかは、パフォーマンスに影響します。参照:
標準ディメンションおよび属性ディメンション
簡単にするために、このトピックの例では、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 30Cust 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に存在します。この状況では、会社は通常、大きいディメンションである顧客を標準ディメンションとして定義し、小さいディメンションであるMarketを属性ディメンションとして定義します。会社は、MarketディメンションのメンバーをCustomerディメンションのメンバーの属性として関連付けます。Marketディメンションのメンバーは、顧客の場所を表します。各顧客に1つの市場があります。
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 30Cust 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で提案されたディメンションには、次の組合せがあります。
-
YearとMeasures
-
YearとProduct
-
YearとMarket
-
YearとScenario
-
MeasuresとProduct
-
MeasuresとMarket
-
MeasuresとScenario
-
MarketとProduct
-
MarketとScenario
-
ScenarioとProduct
-
OuncesとPkg Type
OuncesとPkg Typeは、属性ディメンションとしてProductディメンションに関連付けられており、Productディメンションと一緒に考慮できます。
各ディメンションを視覚的に表すために、マトリックスを作成し、最初の世代のメンバーをいくつか含めます。次のイメージは、3つのディメンションの簡単なマトリックスのセットを示しています。
図1-2 ディメンションの関係の分析
ディメンションの組合せごとに、次の3つの質問をします。
-
その組合せは分析値を追加しますか。
-
その組合せはレポート用のユーティリティを追加しますか。
-
使用されない組合せが生成されないようになっていますか。
組合せごとにこの質問に答えることによって、その組合せがデータベースにとって有効であるかどうかを判断できます。各質問の答えが「はい」であるのが理想です。そうでない場合は、より有効なディメンションにデータを再配置することを検討します。このプロセスを実行するときに、必要な情報についてユーザーと話し合います。
アウトラインでの繰返し
アウトラインでの要素の繰返しは、多くの場合、ディメンションを分割する必要があることを示しています。次の例で、繰り返しを回避する方法を示します。
この例では、"Repetition"というラベルの付いた左側の列では、AccountsディメンションのBudgetとActualの下に、Profit、Margin、Sales、COGSおよびExpensesが繰り返し表示されています。"No Repetition"というラベルの付いた右側の列では、BudgetとActualを別のディメンション(Scenario)に分け、AccountsディメンションにProfit、Margin、Sales、COGSおよびExpensesメンバーが1セットのみ表示されています。このアプローチは、アウトラインを単純化し、データベース内の他のディメンションの予算数値と実績数値のより単純なビューを提供します。
図1-3 Scenarioディメンションを作成することで繰返しをなくす例
この例では、Repetitionというラベルの付いた左側の列では、ダイエット飲料を分析するためにDietディメンションの共有メンバーを使用しています。メンバー100–20、200–20および300–20は、Dietの下で1回、それぞれの親の下で1回表示されています。No Repetitionというラベルの付いた右側の列では、ブール・タイプ(TrueまたはFalse)のDiet属性ディメンションを作成して、アウトラインを単純化しています。すべてのメンバーはそれぞれの親の下に1回のみ表示され、該当する属性(Diet: TrueまたはDiet: False)でタグ付けされています。
図1-4 属性ディメンションを作成することで繰返しをなくす例
属性ディメンションには、その他の分析機能もあります。「Essbase属性の利点」を参照してください。
ディメンション間の無関係性
ディメンション間の無関係性は、ディメンションの多数のメンバーが他のディメンションで無関係である場合に発生します。Essbaseでは、要約(ディメンション)レベルでのみEssbaseで保管されるデータとして無関係データを定義します。このような状況では、データベースからディメンションを削除してそのメンバーを別のディメンションに追加したり、モデルを個別のデータベースに分割できる場合があります。
たとえば、TBCでは、Measuresディメンションのメンバーとして給与を分析することを検討しました。ただし、給与情報は、多くの場合、企業データベースのコンテキストで無関係であることがわかりました。ほとんどの給与は機密情報であり、個人に適用されます。個人と給与は通常、1つのセルを表し、他のディメンションと交差する理由はありません。
TBCは、従業員を別のディメンションに分離することを検討しました。次の表は、TBCがディメンション間の無関係性について、提案された従業員ディメンションを分析した方法の例を示しています。提案された従業員ディメンションのメンバー(表のヘッダー行に表示)を、Measuresディメンションのメンバー(左端の列に表示)と比較しています。Measuresディメンションのメンバー(Revenueなど)はAll Employeesに適用されます。Salaryメジャーのみが個々の従業員に関係しています。
表1-3 ディメンション間の無関係性の例
 |
Joe Smith | Mary Jones | Mike Garcia | All Employees |
|---|---|---|---|---|
|
Revenue |
無関係 |
無関係 |
無関係 |
関係あり |
|
Variable Costs |
無関係 |
無関係 |
無関係 |
関係あり |
|
COGS |
無関係 |
無関係 |
無関係 |
関係あり |
|
Advertising |
無関係 |
無関係 |
無関係 |
関係あり |
|
Salaries |
関係あり |
関係あり |
関係あり |
関係あり |
|
Fixed Costs |
無関係 |
無関係 |
無関係 |
関係あり |
|
Expenses |
無関係 |
無関係 |
無関係 |
関係あり |
|
Profit |
無関係 |
無関係 |
無関係 |
関係あり |
データベースを分割する理由
個別の従業員情報はデータベース内の他の情報とは関係がなく、従業員ディメンションを追加すると必要なデータベース・ストレージが大幅に増加するため、TBCでは人事(HR)データベースを個別に作成しました。新しいHRデータベースには、関連するディメンションのグループが格納され、給与、福利厚生、保険および401(k)プランが格納されます。
データベースを分割する理由は様々です。たとえば、ある会社で、タイム・ゾーンの異なる複数の海外の子会社が含まれた組織データベースを運営しているとします。各子会社には、時間依存の財務計算が必要です。財務計算を適切なタイミングで行えるように、タイム・ゾーンが同じ子会社のグループのデータベースを分割できます。パーティション化されたアプリケーションを使用して、子会社ごとに情報を分離することもできます。
データベース設計分析のチェックリスト
次のチェックリストを使用して、データベース設計を分析します。
-
ディメンション数を最小限に抑えましたか。
-
ディメンションの組合せごとに、次のことを確認しましたか。
-
その組合せは分析値を追加しますか。
-
その組合せはレポート用のユーティリティを追加しますか。
-
使用されない組合せが生成されないようになっていますか。
-
-
アウトラインでの繰返しを回避しましたか。
-
ディメンション間の無関係性を回避しましたか。
-
必要に応じてデータベースを分割しましたか。