属性ディメンションの設計

Essbaseは、データベースに属性情報を設計するための複数の方法を提供します。ほとんどの場合、属性ディメンションおよびそのメンバーを介してデータの特性を定義するのが最善のアプローチです。次の各項では、属性ディメンションを使用する場合、他の機能を使用する場合、および属性を使用する際にパフォーマンスを最適化する方法について説明します。

属性ディメンションの使用

最も柔軟性と機能性を高めるには、属性ディメンションを使用して属性データを定義します。属性ディメンションを使用すると、次の機能が提供されます:

高度で柔軟なデータ取得

属性データを表示できるのは必要な場合のみです。クロス集計を使用して意味のあるサマリーを作成でき、タイプ・ベースの比較を使用して、表示するデータのみを選択できます。
追加の計算機能

属性ディメンションのメンバーの名前に対して計算を実行して標準ディメンションのメンバーを定義できるだけでなく、属性データの合計、件数、平均、最小および最大の5つのタイプの連結にアクセスすることもできます。
経済性とシンプルさ

属性ディメンションは疎な「動的計算」であるため、データとして格納されません。共有メンバーを使用するよりも、属性ディメンションを使用するアウトラインの方がメンバーが少なく、読みやすくなります。

「属性の理解」を参照してください。

代替設計アプローチの使用

状況によっては、次のいずれかのアプローチを検討してください:

ハイブリッド・モード。ハイブリッド・モードを実装する場合、必要に応じて非集計属性を使用でき、2パス計算を使用するかわりにカスタム解決順序を設定できます。「非集計属性」を参照してください。ハイブリッド・モードの詳細は、「ハイブリッド・モードを採用して迅速なアナリティク処理を実現」を参照してください。
UDA UDAは属性よりも柔軟性が低くなりますが、UDAを使用すると、その特性に基づいてデータをグループ化および取得できます。「属性とUDAの比較」を参照してください。
共有メンバーたとえば、Yearディメンションに季節性分析を含めるには、該当する季節(Winter)で共有メンバーとして月を繰り返します: Jan (共有メンバー)、Feb (共有メンバー)など。共有メンバーを使用する主なデメリットは、カテゴリが多数のメンバーを繰り返すとアウトラインが大きくなることです。
標準のディメンションおよびメンバー。追加の標準ディメンションは柔軟性を提供しますが、ストレージ要件と複雑さをデータベースに追加します。追加ディメンションの影響を評価するためのガイドラインは、「分析と計画」を参照してください。

次の表では、データベース内の属性データを管理するための代替アプローチを検討する状況について説明します。

表7-6 属性ディメンションの代替の検討

状況	代替
密ディメンションの属性の分析	UDAまたは共有メンバー
データのバッチ計算の実行	共有メンバーまたは個別の標準ディメンションのメンバー
式の結果の値としての属性ディメンションのメンバーの名前の定義	共有メンバーまたは個別の標準ディメンションのメンバー
時間の経過とともに変化する属性の定義	個別の標準ディメンションのメンバー。たとえば、一定期間の製品のメンテナンス・コストを追跡するには、メンテナンス時の製品の経過期間が重要です。ただし、属性機能を使用すると、1つの年齢のみを製品に関連付けることができます。追跡する期間ごとに、別々のディメンションに複数のメンバーが必要です。
多数の基本ディメンション・メンバーによる取得時間の最小化	共有メンバーまたは個別の標準ディメンションのメンバーを使用したバッチ計算。
パフォーマンスへの影響を抑えながらディメンション間分析を実行	非集計属性

アウトライン・パフォーマンスの最適化

アウトラインのレイアウトおよびコンテンツは、属性の計算および問合せのパフォーマンスに影響を与える可能性があります。一般的なアウトライン設計のガイドラインは、「パフォーマンスを最適化するためのアウトラインの設計」を参照してください。

属性問合せのパフォーマンスを最適化するには、次の設計ヒントを考慮してください:

属性ディメンションがアウトラインの唯一の疎「動的計算」ディメンションであることを確認します。
アウトラインで密ディメンションの後に疎ディメンションを見つけます。最もクエリーが多いディメンションを疎ディメンションの先頭に、属性ディメンションをアウトラインの末尾に配置します。ほとんどの場合、ベース・ディメンションの問合せは最も多く行われます。

「計算および取得のパフォーマンスの最適化」を参照してください。