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

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

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

柔軟性と機能性を最大にするために、属性ディメンションを使用して属性データを定義します。属性ディメンションの使用には、次のような特徴があります。

洗練された柔軟なデータ取得

必要なときにのみ属性データを参照できます。クロス集計を使用して有用なサマリーを作成できます。また、タイプベースの比較を使用すると、必要なデータのみを選択して参照できます。
追加の計算機能

属性ディメンションのメンバーの名前で計算を実行して標準ディメンションのメンバーを定義できるだけでなく、属性データの5つのタイプの集計(合計、カウント、平均、最小および最大)にアクセスすることもできます。
経済性と単純性

属性ディメンションは疎(動的計算)であるため、データとして保管されません。共有メンバーの使用と比較して、属性ディメンションを使用するアウトラインは含まれるメンバーが少なく、読取りが容易です。

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

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

状況に応じて、次のアプローチのいずれかを検討します。

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

次の表に、データベースの属性データの管理に対する代替アプローチを検討する状況を示します。

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

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

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

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

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

属性ディメンションがアウトラインで唯一の疎の動的計算ディメンションになるようにします。
アウトラインで密ディメンションの後に疎ディメンションを配置します。最も問合せの多いディメンションを疎ディメンションの最初に配置し、属性ディメンションをアウトラインの最後に配置します。ほとんどの場合は、基本ディメンションが最も多く問い合されます。

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