1. Oracle Essbaseキューブの設計およびメンテナンス
  2. 導入事例: 単一サーバーのマルチディメンショナル・データベースの設計
  3. 分析と計画
  4. データベース・モデルの作成
機械翻訳について

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

データベースのモデルを作成します。 モデルを構築するには、ビジネスにとって重要なパースペクティブとビューを特定します。 これらのビューは、データベース・モデルのディメンションに変換されます。

多くの企業が次のビューを分析しています:

  • 期間

  • メジャー

  • シナリオ

  • Products

  • Customers

  • 地理的リージョン

  • ビジネス・ユニット

次のトピックを参照して、情報を収集し、ディシジョンしてください。

分析目標の識別

ビジネスにおける情報の主要なビューを特定した後、Essbaseデータベースを設計する次のステップでは、データベースでデータ分析を有効にする方法を決定します。

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

  • リージョン別に分析する場合、リージョンをどのように定義しますか。 リージョンを営業テリトリ別に定義していますか。 州や市などの地理的境界によってリージョンを定義していますか。

  • 製品ライン別に分析する場合、各製品のデータをレビューする必要がありますか。 データを製品クラスにまとめることはできますか?

ビジネス・ビューに関係なく、分析に必要なパースペクティブと詳細を決定する必要があります。 分析するビジネスエリアごとに、異なるデータ・ビューが提供されます。

ディメンションおよびメンバーの決定

各ビジネス・ビューは、データベース内の個別の標準ディメンションとして表すことができます。 ビジネス・アナリストは、製品別、地理別、期間別など、ビジネスの「バイ」を参照することがあります。 製品のサイズや色など、分類または属性別にビジネス・ビューを分析する必要がある場合は、属性ディメンションまたはプロパティを使用して分類ビューを表すことができます。

選択したディメンションによって、データに対して実行できる分析のタイプが決まります。 Essbaseでは、分析に必要な数のディメンションを使用できます。

必要なディメンションおよびメンバーがほぼわかっている場合は、仮のデータベース設計を作成します。

データベース・モデルのディメンションを決定した後、各ディメンション内の要素またはアイテムを選択します。 これらの要素は、それぞれのディメンションの階層およびメンバーになります。 たとえば、時間階層には、四半期や四半期、月など、分析する期間を含めることができます。 各四半期および各月は、時間に対して作成するディメンションのメンバーになります。 四半期と月は、メンバーとその子の2レベルの階層を表します。 四半期内の月は、四半期ごとに合計に連結できます。

ディメンション間の関係

ディメンション間の関係を検討します。 Essbaseデータベースの構造により、ユーザーは様々なパースペクティブから情報を簡単に分析できます。 たとえば、財務アナリストは次の質問をする場合があります:

  • 特定の月の販売はいくらですか。 この図は、過去5年間の同月の販売と比較してどのようになりますか。

  • 利益率は何パーセント増加していますか?

  • 実績値は予算値にどの程度近いですか?

つまり、アナリストは、時間、勘定科目およびシナリオの3つのディメンションの情報を調べることができます。 次のサンプル・データベースは、これらの3つのディメンションを表しており、各ディメンションは3つの軸に沿って表されています:

  • Jan、Feb、MarおよびQtr1の合計で構成される時間ディメンションがX軸に沿って表示されます。

  • 販売高、売上原価、マージン、マージン%などの会計数値で構成される勘定科目ディメンションがY軸に沿って表示されます。

  • 予算値の予算や実績値の実績など、異なる視点を提供する別のディメンションがZ軸に沿って表示されます。

図1-1 3つのデータベース・ディメンションを表すキューブ


この図は、図の前のテキストで説明されている3つのディメンションを表すキューブを示しています。

メンバーが交差するキューブ内のセルには、交差する3つのメンバーすべてに関連するデータ(たとえば、1月の実際の販売)が含まれます。

dimension-member構造の例

次の表に、TBCディメンションのサマリーを示します。 アプリケーション設計者は、左側の列にディメンション、右側の2つの列にメンバーがある3つの列を作成しました。 列3のメンバーは、列2のメンバーのサブカテゴリです。 場合によっては、列3のメンバーは別のレベルのサブカテゴリに分割されます。たとえば、Measuresディメンションのマージンは販売高と売上原価に分割されます。

表1-1 TBCサンプル・ディメンション

Dimensions メンバー 子メンバー

Year

Qtr1

Jan、Feb、Mar

Year

Qtr2

Apr, May, Jun

Year

Qtr3

Jul, Aug, Sep

Year

Qtr4

Oct、Nov、Dec

メジャー

Profit

マージン: 販売、売上原価

費用合計: マーケティング、給与、その他

メジャー

インベントリ

インベントリ、追加、期末インベントリのオープン

メジャー

比率

マージン%、利益%、オンス当たりの利益

製品

コーラ (100)

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

製品

ルート・ビール (200)

オールドファッション(200-10)、ダイエット・ルート・ビール(200-20)、サルサ・パリ・ラ(200-30)、バーチビール(200-40)

製品

Cream Soda (300)

ダーク・クリーム(300-10)、バニラ・クリーム(300-20)、ダイエットクリームソーダ(300-30)

製品

Fruit Soda (400)

ブドウ(400-10)、オレンジ(400-20)、イチゴ(400-30)

Market

東部

Connecticut、Florida、Massachusetts、New Hampshire、New York

Market

West

California、Nevada、Oregon、Utah、Washington

Market

南部

Louisiana、New Mexico、Oklahoma、Texas

Market

中部

Colorado、Illinoi、Iowa、Missouri、Ohio、Wisconsin

シナリオ

実績

N/A

シナリオ

予算

N/A

シナリオ

差異

N/A

シナリオ

差異%

N/A

また、アプリケーション設計者は、次の属性ディメンションを追加して、サイズとパッケージ化に基づく製品分析を可能にしました:

表1-2 TBCサンプルの属性ディメンション

Dimensions メンバー 子メンバー

オンス

大

小

64, 32, 20

16, 12

パッケージ・タイプ

ボトル

Can

N/A

ディメンションおよびメンバーを決定するためのチェックリスト

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

  • ディメンションの候補は何ですか。

  • 他のディメンションを分類または記述するディメンションはありますか。 これらのディメンションは、属性ディメンションの候補です。

  • ユーザーはディメンションのビューを修飾しますか。 ディメンションを修飾するカテゴリは、属性ディメンションの候補です。

  • メンバーの候補は何ですか。

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

  • データの統合方法

データベース設計の分析

初期ディメンション設計はまだ紙に記載されていますが、一連のガイドラインに従って設計を確認する必要があります。 ガイドラインは、データベースを微調整し、多ディメンション・テクノロジを活用するのに役立ちます。 ガイドラインは、効率的な設計を実現し、連結および計算の目標を達成するのに役立つプロセスまたは質問です。

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

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

疎のディメンションと密のディメンションは、パフォーマンスに影響します。 参照:

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

簡単にするために、このトピックの例では、最初に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

顧客AはNew Yorkにのみ存在し、顧客BはIllinoiにのみ存在し、顧客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はIllinoiに、Cust CとCust FはCaliforniaにあります。 この場合、会社は通常、大規模なディメンションCustomerを標準ディメンションとして、小規模なディメンション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      30

顧客AはNew YorkとCaliforniaにいます。 顧客BはNew YorkとIllinoiにいます。 顧客CはCaliforniaにのみ存在します。 この場合、属性ディメンションの使用は機能しません。顧客メンバーは複数の属性メンバーを持つことができません。 したがって、会社は次の2つの標準ディメンションでデータを設計します: 

Customer
  Cust A
  Cust B
  Cust C
Market
  New York
  Illinois
  California

ディメンション組合せ

2つのディメンションの各組合せを2ディメンション・マトリックスに分割します。 たとえば、TBCで提案されるディメンションには、次の組合せが含まれます:

  • メジャー全体の年

  • 製品全体の年

  • マーケット全体の年

  • シナリオ全体の年

  • 製品全体のメジャー

  • 市場全体のメジャー

  • シナリオ全体のメジャー

  • 製品全体のマーケット

  • シナリオ全体のマーケット

  • 製品全体のシナリオ

  • パッケージ・タイプ全体のオンス

Productディメンションに関連付けられた属性ディメンションとしてOuncesおよびPkg TypeをProductディメンションとみなすことができます。

各ディメンションのビジュアル化に役立つように、マトリックスを描画し、第一世代のメンバーをいくつか含めます。 次の図は、3つのディメンションのマトリックスの単純なセットを示しています。

図1-2 ディメンション関係の分析


この図は、ディメンション関係の分析方法を示す、3つのディメンションのマトリックスの簡略化されたセットを示しています。

ディメンションの組合せごとに、次の3つの質問を行います:

  • アナリティク値を追加しますか。

  • レポート用のユーティリティを追加しますか。

  • これにより、使用されていない組合せが過剰になるのを回避できますか。

質問に対する回答は、組合せがデータベースに対して有効かどうかを判断するのに役立ちます。 理想的には、各質問に対する回答ははいです。 そうでない場合は、データを意味のあるディメンションに再配置することを検討してください。 このプロセスを進めるにつれて、情報のニーズについてユーザーと話し合います。

アウトラインでの繰返し

アウトライン内の要素の繰返しは、多くの場合、ディメンションを分割する必要があることを示します。 次の例は、繰り返しを回避する方法を示しています。

この例では、「繰返し」というラベルの付いた左側の列に、「勘定科目」ディメンションの「予算と実績」で繰り返される「利益」、「マージン」、「販売」、「売上原価」および「費用」が表示されています。 「繰返しなし」というラベルの付いた右側の列では、予算と実績が別のディメンション(シナリオ)に分割され、「勘定科目」ディメンションの「利益」、「マージン」、「販売」、「売上原価」および「費用」メンバーのセットのみが残ります。 このアプローチにより、アウトラインが簡略化され、データベース内の他のディメンションの予算と実績の数値がより単純に表示されます。

図1-3 シナリオ・ディメンションの作成による繰返しの排除の例


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

この例では、「繰返し」というラベルの付いた左側の列で、Dietディメンションの共有メンバーを使用して食事飲料を分析します。 メンバー100-20、200-20および300-20は繰り返されます: Dietの下に1回、それぞれの親の下に1回。 「繰返しなし」というラベルの右側の列では、ブール型(TrueまたはFalse)のDiet属性ディメンションを作成することでアウトラインが簡略化されています。 すべてのメンバーは、それぞれの親の下に一度のみ表示され、適切な属性(Diet)でタグ付けされます: True"または"Diet: False").

図1-4 属性ディメンションの作成による繰返しの排除の例


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

属性ディメンションは、追加のアナリティク機能も提供します。 「属性ディメンションの設計」を参照してください。

ディメンション間の関連性

ディメンション間の無関係性は、ディメンションの多くのメンバーが他のディメンション間で無関係な場合に発生します。 Essbaseでは、無関係なデータは、Essbaseがサマリー(ディメンション)レベルでのみ格納するデータとして定義されます。 このような状況では、データベースからディメンションを削除し、そのメンバーを別のディメンションに追加したり、モデルを別のデータベースに分割できます。

たとえば、TBCでは、Measuresディメンションのメンバーとして給与の分析を検討していました。 ただし、企業データベースのコンテキストでは、給与情報は無関係であることがよくあります。 ほとんどの給与は機密であり、個人に適用されます。 個人と給与は通常、他のディメンションと交差する理由なしで1つのセルを表します。

TBCでは、従業員を別のディメンションに分割することを検討しました。 次の表に、TBCが提案された従業員ディメンションのディメンション間の無関係性を分析する方法の例を示します。 提案された従業員ディメンションのメンバー(表ヘッダー行に表示)が、Measuresディメンションのメンバー(左端の列に表示)と比較されます。 Measuresディメンション・メンバー(収益など)はすべての従業員に適用され、給与メジャーのみが個々の従業員に関連します。

表1-3 ディメンション間の関連性の例

スペースのイメージは空のスレッド・セルに使用されます Joe Smith Mary Jones Mike Garcia 全従業員

収益

無関係

無関係

無関係

関連性

変動費

無関係

無関係

無関係

関連性

COGS

無関係

無関係

無関係

関連性

Advertising

無関係

無関係

無関係

関連性

給与

関連性

関連性

関連性

関連性

固定費

無関係

無関係

無関係

関連性

費用

無関係

無関係

無関係

関連性

Profit

無関係

無関係

無関係

関連性

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

個々の従業員情報はデータベース内の他の情報とは無関係であり、従業員ディメンションを追加するとデータベース・ストレージのニーズが大幅に増加するため、TBCは別の人事管理(HR)データベースを作成しました。 新しいHRデータベースには、関連するディメンションのグループが含まれ、給与、福利厚生、保険および401(k)プランが含まれます。

データベースを分割する理由は数多くあります。たとえば、ある会社が、複数のタイム・ゾーンで複数の国際子会社を含む組織データベースを管理しているとします。 各子会社は、時間に依存する財務計算に依存しています。 同じタイム・ゾーンで子会社グループのデータベースを分割して、財務計算をタイム・リに行うことができます。 パーティション化されたアプリケーションを使用して、子会社別に情報を分離することもできます。

データベース設計を分析するためのチェックリスト

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

  • ディメンション数を最小化しましたか。

  • ディメンションの組合せごとに、次のことを尋ねましたか:

    • アナリティク値を追加しますか。

    • レポート用のユーティリティを追加しますか。

    • これにより、使用されていない組合せが過剰になるのを回避できますか。

  • アウトラインでの繰返しを回避しましたか。

  • ディメンション間の関係を回避しましたか。

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