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

この項では、マルチディメンショナル・データベース内のアウトライン、ディメンションおよびメンバーの概念について説明します。ディメンションおよびメンバーを理解している場合は、マルチディメンショナル・データベースの能力を十分に理解できます。

ディメンションは、データベース・アウトラインの最高の統合レベルを表します。データベース・アウトラインでは、ディメンションとメンバーがツリー構造で表示され、連結関係が示されます。たとえば、Yearは(Time型の)ディメンションで、Qtr1はメンバーです:

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

ディメンションには2つのタイプがあります: 標準および属性。

標準ディメンションはビジネス・プランのコア・コンポーネントを表し、多くの場合、部門の機能に関連しています。一般的な標準ディメンション: 時間、勘定科目、製品ライン、市場およびビジョン。ディメンションの変更頻度は、メンバーの変更頻度よりも低くなります。
属性ディメンションは標準ディメンションに関連付けられています。属性ディメンションを使用して、メンバー属性(特性)に基づいて標準ディメンションのメンバーをグループ化および分析します。たとえば、ガラスに梱包されている非アフィン製品の収益性を、缶に梱包されている非アフィン製品の収益性と比較できます。

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

アウトライン階層

データベース開発は、次の目的を達成するデータベース・アウトラインの作成から始まります:

データベース内のメンバー間の構造関係を定義します。
データベース内のデータを編成します。
品目間の連結および数学的関係を定義します。

メンバーの概念は、データ階層を表すために使用されます。各ディメンションは、1つ以上のメンバーで構成されます。次に、メンバーは他のメンバーで構成される場合があります。ディメンションを作成する場合、個々のメンバーの値を連結する方法を定義します。データベース・アウトラインのツリー構造内では、連結はツリーのブランチ内のメンバーのグループです。

たとえば、多くの企業ではデータを毎月集計し、月次データをロールアップして四半期ごとの数値を取得し、四半期データをロールアップして年間の数値を取得しています。企業は、郵便番号、市区町村、都道府県および国別にデータを要約することもできます。任意のディメンションを使用して、レポート目的でデータを連結できます。

たとえば、Sample.Basicデータベースでは、Yearディメンションは5つのメンバーで構成されます: Qtr1、Qtr2、Qtr3およびQtr4には、それぞれ個別の四半期のデータと年が格納され、年のサマリー・データが格納されます。 Qtr1は4つのメンバーで構成されます: Jan、FebおよびMarは、各月のデータとQtr1を格納し、四半期のサマリー・データを格納します。同様に、Qtr2、Qtr3およびQtr4は、個々の月を表すメンバーと四半期合計を格納するメンバーで構成されます。

次の階層構造は、前の段落で説明した四半期のデータ集計および関係を表しています。

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

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

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

階層(世代とレベル、およびルートとリーフ)およびファミリ履歴(親、子と兄弟、および子孫と祖先)の用語は、データベース・アウトラインのメンバーのロールと関係を説明するために使用されます。この項のサブ・トピックでは、アウトライン内のメンバーの位置を説明する際に次に示すアウトラインを参照します。

図2-1 メンバー生成およびレベル番号

この図は、図の後のテキストで説明されているアウトラインのメンバーのロールと関係を示しています。各メンバーの世代およびレベル番号にラベルが付けられます。メジャーのレベルはブランチによって異なります。

親、子および兄弟

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

親は、その下にブランチを持つメンバーです。たとえば、マージンは販売および売上原価の親メンバーです。
子は、その上に親を持つメンバーです。たとえば、販売高と売上原価は親マージンの子です。
兄弟は、同じ世代の同じ直接の親の子メンバーです。たとえば、販売高と売上原価は兄弟ですが(両方とも親マージンがあります)、マーケティング(同じブランチ・レベル)は親が費用合計であるため兄弟ではありません。

子孫および祖先

アウトラインは、次の子孫および祖先の関係を示しています:

子孫は、親の下のブランチのメンバーです。たとえば、利益、インベントリおよび比率はメジャーの子孫です。利益、インベントリおよび比率の子もメジャーの子孫です。
祖先は、メンバーの上のブランチのメンバーです。たとえば、マージン、利益およびメジャーは販売の祖先です。

ルートとリーフ

アウトラインは、次のルートおよびリーフ・メンバーの関係を示しています:

ルートはブランチの最上位メンバーです。メジャーは利益、インベントリ、比率のルートです。
リーフ・メンバーには子がなく、レベル0メンバーとも呼ばれます。たとえば、期首インベントリ、追加および期末インベントリはレベル0のメンバーです。

世代とレベル

世代とは、ディメンション内の連結レベルのことです。ツリーのルート・ブランチは世代1です。世代番号は、ルートからリーフ・メンバーにカウントするにつれて増加します。アウトラインでは、メジャーは世代1、利益は世代2、マージンは世代3です。各レベルの兄弟はすべて同じ世代に属します。たとえば、InventoryとRatiosの両方が世代2です。

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

図2-2 世代

この図は、この図の前のテキストで説明されているProductディメンションのメンバーの世代番号を示しています。

レベルは、ディメンション内のブランチも指します。レベルは、世代に使用される数値の順序を逆にします。レベルは、リーフ・メンバーからルートまでカウントされます。ルート・レベル番号は、ブランチの深さによって異なります。この項の冒頭にある概要図では、販売高と売上原価はレベル0です。他のすべてのリーフ・メンバーもレベル0です。マージンはレベル1、利益はレベル2です。メジャーのレベル数はブランチによって異なることに注意してください。比率ブランチの場合、メジャーはレベル2です。費用合計ブランチの場合、メジャーはレベル3です。

次の図では、Productディメンションの一部がレベル番号付きで示されています。100はレベル2、100-10はレベル1、100-10-12および100-10-16はレベル0です。

図2-3 レベル

この図は、図の前のテキストで説明されているProductディメンションのメンバーのレベル番号を示しています。

世代名とレベル名

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

標準ディメンションおよび属性ディメンション

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

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

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

マルチディメンション・データベースのほとんどのデータセットには、次の2つの特性があります:

データはスムーズかつ均一に分散されません。
メンバーの組合せの大部分にデータが存在しません。たとえば、すべての製品が国のすべてのエリアで販売されているわけではありません。

Essbaseは、アプリケーションの標準ディメンションを次の2つのタイプに分割することで、パフォーマンスを最大化: 密ディメンションおよび疎ディメンション。この区分により、Essbaseは、データへのマトリックス・スタイルのアクセスの利点を失うことなく、スムーズに分散されていないデータに対処できます。 Essbaseは、メモリーおよびディスクの要件を最小限に抑えながら、データ取得を高速化します。

ほとんどのマルチディメンショナル・データベースは本質的に疎であり、メンバーの組合せの大部分のデータ値が不足しています。疎ディメンションは、使用可能なデータ位置の割合が低いディメンションです。

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

マルチディメンショナル・データベースには密ディメンションも含まれます。密ディメンションは、ディメンションのすべての組合せで1つ以上のセルが占有される確率が高くなります。たとえば、Sample.Basicデータベースでは、アカウント・データはすべての市場のほぼすべての製品に存在するため、メジャーが密ディメンションとして選択されます。年およびシナリオも密ディメンションとして選択されます。年は月単位の時間を表し、シナリオは勘定科目値が予算値か実績値かを表します。

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

Essbaseデータベースがディスクに格納されている場合、密メンバーの組合せのデカルト積はブロックと呼ばれるストレージの単位を形成し、ブロックはデータベース内の疎メンバーの組合せごとにディスクに書き込まれます。

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

この図は、図の前のテキストで説明されているSample.Basicデータベースのアウトラインを示しています。

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

ほとんどのデータ・セットでは、既存のデータは予測可能な密度と疎性のパターンに従う傾向があります。パターンが正しく一致する場合は、多数の非常に疎なデータ・ブロックではなく、かなり密度の高いデータ・ブロックの適切な数に既存のデータを格納できます。

デフォルトでは、新しいディメンションは疎に設定されます。属性ディメンションは常に疎ディメンションです。属性ディメンションは疎標準ディメンションにのみ関連付けることができることに注意してください。

Sample.Basicの密疎構成

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

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

ただし、年、メジャーおよびScenarioディメンションのメンバーの組合せを検討してください。データ値は、ほとんどの場合、これらのディメンションの一部のメンバーの組合せに対して存在します。たとえば、少なくとも一部の製品は1月に販売されているため、メンバーの組合せSales -> January -> Actualにはデータ値が存在します。したがって、Yearは密ディメンションであり、同様にメジャーおよびシナリオも密ディメンションです。

Sample.Basicデータベースの標準ディメンションの疎密度構成の概要を次に示します:

疎標準ディメンションは製品および市場です。
密標準ディメンションは、年、メジャーおよびシナリオです。

データ・ブロックは、ProductディメンションとMarketディメンションのメンバーの一意の組合せごとに作成されます(「データ・ストレージ」を参照)。各データ・ブロックは、密ディメンションのデータを表します。データ・ブロックには空のセルがほとんどない可能性があります。

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

この組合せの勘定科目データ(Measuresディメンションで表される)が1月に存在する場合は、FebruaryとYearディメンションのすべてのメンバーに存在する可能性があります。
Measuresディメンションのあるメンバーにデータ値が存在する場合、Measuresディメンションの他のメンバーに他の勘定科目データ値が存在する可能性があります。
実績勘定科目データ値が存在する場合は、予算勘定科目データ値が存在する可能性があります。

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

密および疎の選択シナリオ

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

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

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

この構成では、大きいメモリーを必要とする索引が生成されます。索引エントリが多いほど、Essbaseは特定のブロックを検索します。

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

この図は、図の前のテキストで説明されている、疎標準ディメンションに複雑な索引がある様子を示しています。

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

すべてのディメンションを稠密にすると、Essbaseにより、単一の索引エントリと1つの大きな疎ブロックが作成されます。ほとんどのアプリケーションでは、この構成には他の構成よりも数千回多くのストレージが必要です。 Essbaseは、大量のメモリーを必要とするデータ値を検索するときに、データベース全体をメモリーにロードする必要があります。

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

この図は、図の前のテキストで説明されている、密標準ディメンションに単一エントリ索引がある様子を示しています。

シナリオ3: 密および疎標準ディメンション

会社のデータに関する知識に基づいて、すべての疎および密の標準ディメンションを特定しました。

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

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

この図は、図の前のテキストで説明されている、疎標準ディメンションと密標準ディメンションの組合せを使用した結果、密ブロックと比較的単純な索引がどのようになるかを示しています。

シナリオ4: 一般的な多ディメンションの問題

4つの標準ディメンションを持つデータベースについて考えてみます: 時間、勘定科目、リージョンおよび製品。次の例では、TimeとAccountsは密ディメンションで、RegionとProductは疎ディメンションです。

次の図に示す2ディメンション・データ・ブロックは、密ディメンションのデータ値を表しています: 時間と勘定科目。時間ディメンションのメンバーは、J、F、MおよびQ1です。勘定科目ディメンションのメンバーは、収益、支出および正味です。

図2-9 時間と勘定科目の2ディメンション・データ・ブロック

この図は、図の前のテキストで説明されている時間および勘定科目ディメンションのデータ・ブロックを示しています。

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

次の図は、11のデータ・ブロックを示しています。 WestとSouthの製品A、EastとWestの製品B、またはEastの製品Cのデータ値は存在しません。したがって、Essbaseでは、これらのメンバーの組合せに対してデータ・ブロックが作成されていません。 Essbaseによって作成されたデータ・ブロックには、空のセルがほとんどありません。この例では、すべての疎性を索引に効果的に集中させ、すべてのデータを完全に利用されたブロックに集中させます。この構成により、効率的なデータ・ストレージと取得が可能になります。

図2-10 リージョンおよび製品の疎メンバーに対して作成されたデータ・ブロック

この図は、この図の前のテキストで説明されている、リージョン・ディメンションおよびProductディメンションの疎メンバー用に作成されたデータ・ブロックを示しています。

次に、密ディメンションと疎ディメンションの選択を逆にすることを検討します。次の例では、RegionとProductが密ディメンションで、TimeとAccountsが疎ディメンションです。

次の図では、2ディメンション・データ・ブロックは密ディメンションのデータ値を表しています: リージョンおよび製品。 Westリージョンでは、製品Aおよび製品Bのデータは使用できません。データは米国の合計製品にも使用できません。

図2-11 リージョンおよび製品の2ディメンション・データ・ブロック

この図は、この図の前のテキストで説明されている、リージョンおよびProductディメンションの密メンバー用に作成されたデータ・ブロックを示しています。

Essbaseでは、疎標準ディメンションのメンバーの組合せに対してデータ・ブロックが作成されます(メンバーの組合せに対して少なくとも1つのデータ値が存在する場合)。疎標準ディメンションは、時間および勘定科目です。

次の図は、12個のデータ・ブロックを示しています。時間ディメンションと勘定科目ディメンションのすべてのメンバーの組合せに対してデータ値が存在するため、Essbaseはすべてのメンバーの組合せに対してデータ・ブロックを作成します。すべてのリージョンのすべての製品にデータ値が存在するわけではないため、データ・ブロックには空のセルが多数あります。空のセルが多数あるデータ・ブロックには、データが非効率的に格納されます。

図2-12 時間および勘定科目の疎メンバー用に作成されたデータ・ブロック

この図は、この図の前のテキストで説明されている、時間および勘定科目ディメンションの疎メンバー用に作成されたデータ・ブロックを示しています。