ディメンションとメンバー

ディメンションとメンバーについて理解することで、マルチディメンショナル・データベースの機能についての理解が深まります。

ディメンションは、Essbaseデータベース・アウトライン内の最も高い集計レベルを表します。アウトラインは、階層集計関係を定義するツリー構造にディメンションとメンバーを示します。

たとえば、Yearはディメンション(タイプは時間)で、Qtr1はメンバーです。

Year Time
   Qtr1 (+)
      Jan (+)
......Feb (+)
......Mar (+)

標準ディメンションと属性ディメンションの2種類があります。

• 標準ディメンションは、ビジネス・プランの中心的なコンポーネントを表し、多くの場合、部門機能と関連しています。一般的な標準ディメンションは、時間、勘定科目、製品ライン、市場および部門です。ディメンションを変更する頻度はメンバーよりも低くなります。

• 属性ディメンションは標準ディメンションに関連付けられています。属性ディメンションを使用して、標準ディメンションのメンバーをメンバー属性(特性)に基づいてグループ化し、分析します。たとえば、パッケージがガラスのカフェインなし製品の収益性と、パッケージが缶のカフェインなし製品の収益性を比較できます。

メンバーは、ディメンションの個別のコンポーネントです。たとえば、製品A、製品Bおよび製品Cは製品ディメンションのメンバーです。各メンバーには一意の名前があります。メンバー(この章では、保管済メンバーと呼びます)に関連付けられているデータを保管するか、または、ユーザーがデータを取得するときにそのデータを動的に計算できます。

アウトラインの階層

アウトラインを定義して、Essbaseキューブの設計を開始します。アウトライン構成では、データ・カテゴリの関係が構造的な階層および数学的な階層として反映されます。

Essbaseデータベース(キューブ)の開発は、アウトラインの作成から始まります。この作業では、次のことを実行します:

• 構造的な関係を定義します

• データを編成します

• アイテム間の集計および数学的な関係を定義します

メンバーの概念を使用してデータ階層が表現されます。各ディメンションは1つ以上のメンバーで構成されます。メンバーは、同様に他のメンバーで構成されている可能性があります。ディメンションを作成するとき、その個々のメンバーの値の集計方法を定義します。キューブ・アウトラインのツリー構造で、集計はツリーの分岐内のメンバー・グループを示します。

たとえば、多くの企業が、月ごとにデータを要約し、月次データをロールアップして四半期の数値を取得し、さらに四半期データをロールアップして年間の数値を取得します。企業では、データを郵便番号別、都市別、都道府県別、国別に要約する場合もあります。レポートを作成するために、任意のディメンションを使用してデータを集計できます。

たとえば、Sample.Basicキューブでは、Yearディメンションに、四半期のデータを保管する四半期メンバーQtr1、Qtr2、Qtr3およびQtr4と、その年の要約データを保管する年が含まれます。Qtr1には、1か月のデータを保管するJan、Feb、Marと、四半期の要約データを保管するQtr1が含まれます。同様に、Qtr2、Qtr3およびQtr4には、個々の月を表すメンバーおよび四半期の合計を保管するメンバーが含まれます。

次の階層構造は、Qtr1内のデータの集計および関係を表します。

Year Time
   Qtr1 (+)
      Jan (+)
......Feb (+)
......Mar (+)

ディメンションは、比較的少数のメンバーで構成されるものと、多数のメンバーで構成されるものがあります。

ディメンションとメンバーの関係

Essbaseアウトラインの構成は、階層と家族の用語を使用して説明されています。これは、ディメンション内のメンバーのロールと関係を概念化する簡単な方法であるためです。階層の用語には、ルートやリーフに似た世代やレベルが含まれています。家族の用語には、親、子、兄弟、子孫および祖先が含まれています。

この項のサブトピックでは、次に示すアウトラインを参照し、アウトライン内でのメンバーの位置について説明します。

図2-1 メンバーの世代番号およびレベル番号

親、子および兄弟

アウトラインは、次のような親、子および兄弟の関係を示します。

• 親は、下位に分岐を持つメンバーです。たとえば、MarginはSalesとCost of Goods Soldの親メンバーです。

• 子は、上位に親を持つメンバーです。たとえば、SalesとCost of Goods SoldはMarginという親の子です。

• 兄弟は、すぐ上に同じ親を持つ同世代の子メンバーです。たとえば、SalesとCost of Goods Soldは兄弟です(両方ともMarginという親を持ちます)。一方、同じ分岐レベルのMarketingは、親がTotal Expensesであるため兄弟ではありません。

子孫および祖先

アウトラインは、次のような子孫と祖先の関係を示します。

• 子孫は、親の下位の分岐に含まれるメンバーです。たとえば、Profit、InventoryおよびRatiosはMeasuresの子孫です。Profit、InventoryおよびRatiosの子も、Measuresの子孫です。

• 祖先は、あるメンバーの上位の分岐に含まれるメンバーです。たとえば、Margin、ProfitおよびMeasuresはSalesの祖先です。

ルートおよびリーフ

アウトラインは、次のようなルート・メンバーとリーフ・メンバーの関係を示しています。

• ルートは、分岐内の最上位メンバーです。Measuresは、Profit、Inventory、Ratiosのルートです。

• リーフ・メンバーには子がなく、レベル0メンバーとも呼ばれます。たとえば、Opening Inventory、AdditionsおよびEnding Inventoryはレベル0メンバーです。

世代およびレベル

Essbaseでは、世代とレベルはアウトライン構造のメンバーの場所を示す指標です。世代は、ディメンションのルートからのメンバーの距離を示します。レベルでは、あるメンバーとその下の階層の最下位のメンバー(階層の"リーフ")間の分岐の数を測定します。

世代

世代とは、ディメンション内の集計レベルのことです。ツリーのルート分岐は世代1です。世代番号はルートからカウントして、リーフ・メンバーに向けて大きくなります。このアウトラインでは、Measuresは世代1、Profitは世代2、Marginは世代3です。各レベルの兄弟はすべて同じ世代に属します。たとえば、InventoryとRatiosはどちらも世代2です。

次の図は、Productディメンションの一部に世代番号を付けたものを示しています。Productは世代1、100は世代2、100-10は世代3、100-10-12および100-10-16は世代4です。

図2-2 世代

レベル

レベルもディメンション内の分岐を表しますが、レベルと世代では使用される番号の順序が逆になります。レベルはリーフ・メンバーからカウントし、ルートに向けて大きくなります。ルート・レベルの番号は、分岐の深さによって変わります。この項の初めにあるアウトラインの図では、SalesとCost of Goods Soldがレベル0です。その他すべてのリーフ・メンバーもレベル0です。Marginはレベル1、Profitはレベル2です。Measuresのレベル番号は、分岐によって異なります。Ratios分岐の場合、Measuresはレベル2です。Total Expenses分岐の場合、Measuresはレベル3です。

次の図は、Productディメンションの一部にレベル番号を付けたものを示しています。100はレベル2、100-10はレベル1、100-10-12および100-10-16はレベル0です。

図2-3 レベル

世代名とレベル名

レポートのメンテナンスを容易にするために、世代またはレベルに名前を割り当て、この名前をその世代またはレベル内のすべてのメンバーの省略名として使用できます。アウトラインの変更は自動的にレポートに反映されるため、メンバー名が変更されたりデータベース・アウトラインから削除された場合でも、世代名またはレベル名を使用するときにレポートに変更を加える必要はありません。

階層の形状

Essbaseでの階層は、対称または非対称(不規則)にすることができます。

Essbaseでは、階層の形状に応じて操作によって異なる方法で処理されます。表形式データ・エクスポート、特定の計算関数(@ANCESTVALなど)およびドリル・スルー・レポート・マッピングは、ディメンションに非対称階層が含まれている場合、結果が異なることがあります。

対称階層

対称階層では、同じレベル番号のメンバーは、アウトライン内で同じ深さにあります。たとえば、次の図では、メンバー100-10と200-10はどちらもレベル0のメンバーであり、どちらも世代3メンバーです。

世代番号は、ディメンション名が1の世代から数え始めます。世代番号が大きくなるほど、階層内のリーフ・メンバーに近付きます。

レベル番号は、階層の最も深い部分の0から始まります。最高レベル番号はディメンション名です。

非対称階層

非対称(不規則)階層では、同じレベル番号であることは、メンバーがアウトライン内で同じ深さにあることを意味しません。たとえば、次の図では、メンバーaaとメンバーfはどちらもレベル0のメンバーですが、同じ深さにありません。

標準ディメンションと属性ディメンション

Essbaseには、標準ディメンションと属性ディメンションがあります。属性ディメンションのメンバーにはEssbaseによってストレージが割り当てられないため、この章では標準ディメンションに焦点を当てます。かわりに、ユーザーが関連データの問合せを実行すると、メンバーが動的に計算されます。

属性ディメンションは、標準ディメンションに関連付けられる特別なタイプのディメンションです。「Essbase属性の操作」を参照してください。

疎ディメンションと密ディメンション

マルチディメンショナル・データベースのほとんどのデータ・セットは、次の2つの特性を備えています。

• データは、均等に一貫して分散されません。

• 大多数のメンバーの組合せには、データは存在しません。たとえば、すべての製品が国内の全地域で販売されているとは限りません。

Essbaseでは、アプリケーションの標準ディメンションが、密と疎の2つのタイプに分割されます。Essbaseは、この分割によりマトリックス方式のデータ・アクセスの長所を生かしながら、均等に分散されていないデータに対応できます。また、Essbaseはメモリーとディスクの要件を最小限に抑えながら、データ取得時間を短縮できます。

大多数のマルチディメンショナル・データベースは本質的に疎であり、大多数のメンバーの組合せにはデータ値がありません。疎ディメンションとは、使用可能なデータ位置にデータが入っているパーセンテージが低いディメンションです。

たとえば、図2-4のSample.Basicデータベースのアウトラインには、Year、Product、Market、MeasuresおよびScenarioディメンションが含まれています。Productは製品単位、Marketは製品を販売する地域、Measuresは勘定科目データを表します。すべての製品がすべての市場で販売されるわけではないため、MarketとProductは疎ディメンションとして選択されます。

マルチディメンショナル・データベースには、密ディメンションも含まれます。密ディメンションとは、ディメンションのすべての組合せで1つ以上のセルに値が入っている可能性が高いディメンションです。たとえば、Sample.Basicデータベースでは、すべての市場のほぼすべての製品に対して勘定科目データが存在するため、Measuresは密ディメンションとして選択されます。YearとScenarioも密ディメンションとして選択されます。Yearは時間を月単位で表し、Scenarioは勘定科目の値が予算値か実績値かを表します。

Caffeinated、Intro Date、Ounces、Pkg TypeおよびPopulationは属性ディメンションです。「Essbase属性の操作」を参照してください。

Essbaseデータベースがディスクに保管されている場合、密メンバーの組合せのデカルト積は、ブロックというストレージの単位になります。ブロックは、データベース内の疎メンバーの組合せごとにディスクに書き込まれます。

図2-4 Sample.Basicのデータベース・アウトライン

密ディメンションと疎ディメンションの選択

ほとんどのデータ・セットでは、既存のデータは予測可能な疎/密度のパターンに従います。正確にパターンを照合すると、非常に疎である多数のデータ・ブロックではなく、ある程度密である適切な数のデータ・ブロックに既存のデータを保管できます。

デフォルトでは、新規Essbaseディメンションは疎に設定されます。属性ディメンションは常に疎ディメンションになります。

ディメンションを密と疎のどちらにするかを決定するために、Essbaseではアウトライン・プロパティに自動構成オプションを用意しています。

Essbaseでは、次の要素に基づいて、ディメンションの疎密構成に関して推奨事項を提示します:

• ディメンションの時間タグと勘定科目タグ

• データ・ブロックの推定サイズ

• ディメンションの属性とする特性

推奨構成を適用することも、自動構成をオフにして、各ディメンションの疎または密のプロパティを手動で設定することもできます。属性ディメンションは疎標準ディメンションにのみ関連付けることができる点に注意してください。

ノート:

密ディメンションおよび疎ディメンションの自動構成では、見積りのみが提供されます。データベースにロードするデータの性質や、複数のユーザーの考慮事項を考慮することはできません。

Sample.Basicの密と疎の構成

The Beverage Company (TBC)のデータを表すSample.Basicデータベースについて考えます。

TBCはすべての製品をすべての市場で販売しているわけではないため、データ・セットは疎です。ProductディメンションとMarketディメンションのメンバーの組合せの多くには、データ値が存在しません。たとえば、FloridaでCaffeine Free Colaが販売されていない場合、Caffeine Free Cola (100-30) -> Floridaの組合せに対するデータ値は存在しないため、ProductディメンションとMarketディメンションは疎になります。したがって、これらのディメンションの特定のメンバーの組合せに対してデータ値が存在しない場合、その組合せに対するデータ・ブロックは作成されません。

次に、Year、MeasuresおよびScenarioディメンションのメンバーの組合せについて考えます。これらのディメンションのメンバーの組合せには、ほとんどの場合、データ値が存在します。たとえば、少なくともなんらかの製品が1月に販売されるため、Sales -> January -> Actualのメンバーの組合せにはデータ値が存在します。したがって、Yearディメンションと同様にMeasuresディメンション、Scenarioディメンションも密になります。

Sample.Basicデータベースの標準ディメンションの疎と密の構成は、次のように要約されます。

• 疎標準ディメンションは、ProductとMarketです。

• 密標準ディメンションは、Year、MeasuresおよびScenarioです。

データ・ブロックは、ProductディメンションとMarketディメンションのメンバーの一意の組合せに対して1つずつ作成されます(データ・ストレージを参照)。各データ・ブロックは、密ディメンションのデータを表します。データ・ブロックには、多くの場合、空のセルがいくつか含まれます。

たとえば、図2-5の疎メンバーの組合せCaffeine Free Cola (100-30)、New Yorkについて考えます。

• 1月のこの組合せに対する勘定科目データ(Measuresディメンションによって表される)が存在する場合、2月の勘定科目データおよびYearディメンションの全メンバーに対する勘定科目データも存在する可能性があります。

• Measuresディメンションの特定のメンバーに対するデータ値が存在する場合は、Measuresディメンションの他のメンバーに対する勘定科目データ値も存在する可能性があります。

• Actualという勘定科目データ値が存在する場合、Budgetという勘定科目データ値も存在する可能性があります。

  図2-5 Sample.Basicデータベースの密データ・ブロック

  
  
  

密と疎の選択のシナリオ

次のシナリオでは、異なる標準ディメンションを選択したときのデータベースに対する影響を示します。これらのシナリオは、7つ以上のディメンションと数百個のメンバーを持つ一般的なデータベースに基づいているものとします。

シナリオ1: すべてが疎の標準ディメンション

すべてのディメンションを疎にすると、Essbaseによって、単一のデータ値を含む単一のデータ・セルで構成されるデータ・ブロックが作成されます。それぞれのデータ・ブロックに対してインデックス・エントリが作成されるため、このシナリオでは、既存の各データ値に対してインデックス・エントリが作成されます。

この構成では、大量のメモリーを必要とするインデックスが生成されます。インデックス・エントリが多いほど、Essbaseで特定ブロックの検索にかかる時間が長くなります。

図2-6 すべてが疎の標準ディメンションのデータベース

シナリオ2: すべてが密の標準ディメンション

すべてのディメンションを密にすると、Essbaseによって、1つのインデックス・エントリとサイズの大きい1つの疎ブロックが作成されます。ほとんどの用途で、この構成には他の構成の何千倍ものストレージが必要になります。Essbaseがデータ値を検索するときにデータベース全体をメモリーにロードする必要があるため、膨大な量のメモリーが必要になります。

図2-7 すべてが密の標準ディメンションのデータベース

シナリオ3: 密標準ディメンションと疎標準ディメンション

会社のデータに関する知識に基づいて、事前に、疎標準ディメンションと密標準ディメンションをすべて識別しました。

Essbaseによって、メモリーに簡単に収まる密ブロックと比較的小さいインデックスが作成されます。データベースは、最小限のリソースを使用して効率的に実行されます。

図2-8 密ディメンションと疎ディメンションの組合せの理想的な構成

シナリオ4: マルチディメンショナルに関する一般的な問題

Time、Accounts、RegionおよびProductの4つの標準ディメンションを持つデータベースについて考えます。次の例では、TimeとAccountsが密ディメンション、RegionとProductが疎ディメンションです。

次のイメージに示されている2ディメンショナル・データ・ブロックは、密ディメンション(TimeおよびAccounts)のデータ値を表しています。Timeディメンションのメンバーは、J、F、MおよびQ1です。Accountsディメンションのメンバーは、Rev、ExpおよびNetです。

図2-9 TimeとAccountsの2ディメンショナル・データ・ブロック

Essbaseでは、疎標準ディメンションのメンバーの組合せに対してデータ・ブロックが作成されます(メンバーの組合せに対して1つ以上のデータ値が存在する場合)。疎ディメンションはRegionとProductです。Regionディメンションのメンバーは、East、West、SouthおよびTotal USです。Productディメンションのメンバーは、Product A、Product B、Product CおよびTotal Productです。

次のイメージは、11個のデータ・ブロックを示しています。WestとSouthのProduct A、EastとWestのProduct BまたはEastのProduct Cにはデータ値がありません。そのため、Essbaseによってこれらのメンバーの組合せに対するデータ・ブロックは作成されません。Essbaseによって作成されたデータ・ブロックには、いくつかの空のセルが含まれます。この例では、すべての疎が効果的にインデックスに集められ、全面的に活用されているブロックにすべてのデータが集められています。この構成によってデータの保管と取得が効率化されます。

図2-10 RegionとProductの疎メンバーに対して作成されたデータ・ブロック

次に、密ディメンションと疎ディメンションの選択を反対にした場合について考えます。次の例では、RegionとProductが密ディメンション、TimeとAccountsが疎ディメンションです。

次のイメージで、2ディメンショナル・データ・ブロックは、密ディメンションであるRegionとProductのデータ値を表しています。West地域では、Product AおよびProduct Bに対するデータは使用できません。USのTotal Productに対するデータも使用できません。

図2-11 RegionとProductの2ディメンショナル・データ・ブロック

Essbaseでは、疎標準ディメンションのメンバーの組合せに対してデータ・ブロックが作成されます(メンバーの組合せに対して1つ以上のデータ値が存在する場合)。疎標準ディメンションは、TimeとAccountsです。

次のイメージは、12個のデータ・ブロックを示しています。TimeディメンションとAccountsディメンションのメンバーのすべての組合せに対してデータ値が存在します。そのため、すべてのメンバーの組合せに対してEssbaseによってデータ・ブロックが作成されます。データ値はすべての地域のすべての製品に対して存在するわけではないため、データ・ブロックには空のセルが多数含まれます。空のセルが多いデータ・ブロックでは、データの保管が非効率的になります。

図2-12 TimeとAccountsの疎メンバーに対して作成されたデータ・ブロック