BI 計画ソリューションとシナリオのデータ マートを計画する

 

適用先: SharePoint Server 2010 Enterprise

トピックの最終更新日: 2016-11-30

この記事の内容:

  • スキーマとレイアウト

  • ソリューションのモデル

  • ディメンション テーブルを作成する

  • 階層テーブルを作成する

  • ファクト テーブルを作成する

スキーマとレイアウト

データマートは、データマートに入ってくるすべてのデータを厳密に制御しながら、IW にとって単一の記録のポイントとして機能するように、SQL Server 2008 R2 リレーショナル サーバーを使用して作成されます。データ マートは、すべてのキューブ、ディメンション、階層の中心的なデータ ソースとして SSAS サーバーで使用されます。SSAS データ モデルをサポートし、ディメンション、階層、およびファクトを含むように、3 つの種類のテーブルが必要になります。

注意

キューブは複数のファクト テーブルを使用できます。これは、メジャー グループを分割するか、キューブ内で複数のメジャー グループを使用することにより行うことができます。

計画プロセスで必要なデータ モデルをサポートする、以下のモデルを作成します。これらのモデルは、データ マート内に含まれることになるテーブルの数を既定します。

ソリューションのモデル

  • 予測: このモデルは、今後の期間の収益と運用経費の予測のデータ入力を取得する目的で、主に使用します。

  • 勘定科目: 勘定科目ディメンションは、予測の収益および経費アイテムを示す勘定科目のグラフを含みます。

  • シナリオ: シナリオ ディメンションは、データを "実際" と "予測" に分割します。

  • 時間: 時間ディメンションは、予測の会計期間を決定します。

  • 地域: 地域ディメンションは、各 IW がデータ入力プロセスを管理する際に使用します。各地域の個別の IW は、現地通貨でデータ入力を行います。

  • 製品: 製品ディメンションは、現行と入手可能な製品の完全なリストを表します。収益は製品ごとに予想されます。

  • 人事管理予算: このモデルは、ライン管理者が、特定会計年度での適切な人数確認に基づく予算作成をするときに使用します。IW は、予測される勤務時間と各リソースについての給与等級分類を入力することで、このモデルを操作します。仮定の変更に基づいて、どれだけの予算が給与に必要かを決定する目的で、What-If 分析が実行されます。

  • 測定基準: このディメンションは、"作業時間"、"給与等級"、"補償の合計" のようなメンバーを保存します

  • 地域: リソースを受信する場所。

  • 時間: 年レベルで行う、人数に対する予算。

  • 従業員: 既存のリソースと新しい TBH プレースホルダーのリスト。

  • 賃金率: このモデルは、年の基準賃金率を設定します。賃金率情報は、計算で使用する基準仮定データとして人事管理予算モデルに送られます。

  • 時間: 賃金率が年レベルで入力されます。

  • 給与等級: 基本給を決定する給与等級のリスト。

  • 為替レート: 為替レート モデルは、予測モデルから財務統合モデルにデータを変換するとき、月ごとに使用する通貨変換レートを決定する際に使用されます。データは、各地域の現地通貨によって入力されることから、通貨変換ルールとデータ フロー パッケージには為替レート テーブルが使用されます。

  • 時間: 為替レートを月単位で入力します。

  • SourceCurrency: 変換元通貨。

  • DestinationCurrency: 変換先通貨。

  • 財務統合: 財務統合モデルは、すべての地域で単一の通貨を使用する財務報告で使用されます。

  • アカウント: アカウントをまとめたグラフ。

  • シナリオ: "実際" と "予測" が含まれます。

  • 時間: 最も詳細な単位は月です。

  • 地域: P&L を持つすべての地域。

  • 通貨の種類: 報告通貨 (EUR) あるいは現地通貨でデータを表示します。後者の場合、フィルターで、現在、選択されている地域によって決定されます。

必要なモデルを十分理解したあとで、データ ストアをセットアップできます。5 つのファクト テーブル、適切なディメンション、および階層テーブルがあります。これらのテーブルは、星状のスキーマで配置されます。ファクト テーブルが中央に位置し、ディメンションと階層テーブルが "星" のとがった点となります。データ ストア内のファクト テーブル、ディメンション、および階層の関係を外部キーによって定義することにより、キューブとディメンションを構築するとき、SSAS ですばやくデータ ソースビューを生成できます。

ディメンション テーブルを作成する

ディメンションは、多次元のデータベースの構成要素です。一連のディメンションをグループ化することにより、一般的なキューブの基盤が作成されます。ディメンション テーブルは、特定の種類のデータをまとめて保存します。たとえば、テーブルの各行がディメンションの一意のアカウント メンバーを示すような、すべてのアカウント メンバーを保存するディメンション テーブルがあります。また、ディメンション テーブルでは、テーブル列ごとに関連するプロパティをまとめて保存できます。たとえば、勘定科目ディメンションには、ディメンション メンバーの特定のアカウントの種類を保存する "AccountType" と呼ばれる列があります。

MemberId MemberLabel MemberName SortOrder AccountType ExpenseType

1

3100

Sales Revenue

100

Income

該当なし

2

3200

Other Operating Revenue

200

Income

該当なし

3

8100

Interest Revenues

300

Income

該当なし

MemberId MemberLabel MemberName SortOrder 入力通貨 対象通貨

1

SEA

Seattle

100

USD

USD

2

OLY

Olympia

200

USD

USD

3

SPK

Spokane

300

USD

USD

推奨事項

ディメンション テーブルで以下のフィールドを作成することを推奨します。

Id: 最適なパフォーマンスを得るには、ディメンション キーを整数型 (TinyIntSmallIntInt、BigInt) にすることを推奨します。パフォーマンスについてのその他のセクションを参照してください。また、ディメンションの規模設定に基づいて最適なデータ型を使用します。

Label: ディメンション メンバーのキャプション/名前表示に一意のコードを使用します。これを一意にすることで、"&[key]" のようなキー値記法を使用するメンバー仕様ではなく、人間に読みやすい MdxScript を使用してキューブに基づくルールを作成できます。

Name: エンド ユーザーは、ラベル コードではなくフレンドリ名でディメンションのメンバーを確認する必要がある場合があります。たとえば、このソリューションには、計算ルールを作成するときには意味がはっきりしているが、ピボットテーブルに表示されるときは意味がはっきりしない、ラベルで使用されるアカウント コードがあります。このプロパティを作成することにより、ルール定義の基礎となるロジックに影響せずに、表示名を簡単に更新できるようにします。

Order: ディメンション メンバーの順序を決定する目的でディメンションが使用する、並べ替え列があると役立ちます。

計画シナリオのディメンション テーブルのメンバーは、一般的には 200,000 を超えることはありません。非常に大きなディメンションで作業をしている場合、ディメンションを減らすことを推奨します。削減されたディメンション メンバーに関連付けられたデータは収集して、その他のディメンション メンバーに渡すことができます。一般的に、ディメンションが小さいほど、計画キューブのパフォーマンスは全体的に向上します。

注意

ディメンション列とメンバー プロパティは密接に関連しています。

階層テーブルを作成する

階層テーブルは、SSAS の親子階層機能を使用するときに必要です。親子階層は、key (階層のディメンションのメンバーを表す)、parent key (同じディメンションからの別のメンバー)、および sort 列 (階層のレベルでメンバーを並べ替える) の 3 つの列を使用する必要があります。カスタムのメンバー収集が必要なとき以外、ほとんどの親子階層は、これらの 3 つの列でサポートされます。たとえば、アカウントのグラフではカスタムの収集を定義する必要があります。アカウント収集は、各アカウント メンバーのアカウントの種類と、その各親アカウント メンバーによって決定されます。カスタム収集が必要な階層をサポートするには、4 番目の列を作成する必要があります。この Unary Operator 列は、以下の値を含みます。+-、および + を伴う ~ は親への収集を意味します。- は、親からの減算、~ は親への収集の無視をそれぞれ意味します。

Id Parent Id Sort Order Unary Operator Label Name

1

102

100

+

3100

Sales Revenue

2

102

200

+

3200

Other Operating Revenue

3

103

300

+

8100

Interest Revenues

4

103

400

+

9100

Gain on Sale of Assets

Id Parent Id Sort Order Label Name

1

4

500

SEA

Seattle

2

4

700

OLY

Olympia

3

4

600

SPK

Spokane

ディメンションに定義された列に基づいて、レベルベースの階層が作成されます。リレーショナル テーブルの列は、SSAS に属性階層を構築できます。属性階層間の関係を定義することにより、効率的なレベルベース階層を作成できます。SSAS のレベルベース階層を作るまでは、ディメンションのすべての関連するプロパティを、ディメンション テーブルに列として含めるだけで十分です。

詳細については、「[階層とレベル]」を参照してください。

ファクト テーブルを作成する

ファクト テーブルは、キューブのすべての数値データを保存します。ファクト テーブル内の列の数は、キューブに関連付けられるディメンションの数によって異なります。たとえば、予測キューブは、7 つの列を持っており、6 つの列が予測キューブに関わる各ディメンションを表し、1 つの列が数値を保存します。数値を保存する列は "メジャー" と呼ばれます。

メジャー列以外の各列は、キーによってディメンションに関連付けられます。以下の例では、人事管理予算モデルがファクト テーブルを関連している 5 つのディメンションを持っており、ファクト テーブルの各行が単一のファクト レコードを表しています。たとえば、複数のファクト行のすべてのディメンション キーの値が同じであるような場合、ディメンション キーのファクト レコードでの値の重複を避けることが推奨されます。このような場合は、単一の行に値を結合します。

Rowld Metric ID Geography ID EmployeeID TimeID Value

1

2

15

1010

20100000

2000

2

2

15

1009

20100000

2000

3

2

15

1008

20100000

2000

Rowld Account ID TimeID ScenarioID Geography ID ProductID VersionID Value

1151

1

20100200

1

1

232

1

1391

1153

1

20100400

2

1

232

1

1124

1155

1

20100600

2

1

232

1

1322

See Also

Concepts

BI 計画ソリューションとシナリオの基本的な計画シナリオ
BI 計画ソリューションとシナリオのデータ マートを計画する
BI 計画ソリューションとシナリオにおけるモデル化の概念の計画
BI 計画ソリューションとシナリオでの書き戻しキューブ モデリング
BI 計画ソリューションとシナリオにおけるパフォーマンスに関する考慮事項と方法
BI 計画ソリューションとシナリオの Excel PowerPivot を使用したキューブ モデリング
BI 計画ソリューションとシナリオのレポートおよびフォームの作成
BI 計画ソリューションとシナリオの計画データの提出
BI 計画ソリューションとシナリオのワークフロー アクション、ワークフロー図、および SharePoint ワークフローの設定
BI 計画ソリューションとシナリオの監査管理
BI 計画ソリューションとシナリオの管理
BI 計画ソリューションとシナリオの計算
BI 計画ソリューションとシナリオの追加の計画機能
BI 計画ソリューションとシナリオの移行
BI 計画ソリューションとシナリオのメンテナンス
BI 計画ソリューションとシナリオの企業による関連企業の管理
BI 計画ソリューションとシナリオのモデルおよびレポート作成の計画ガイド
BI 計画ソリューションとシナリオの計画機能の作成ガイド
BI 計画ソリューションとシナリオでの計画と予算の計算の例