属性リレーションシップ

属性リレーションシップの作成

入門編で作成した商品ディメンションは、次のように「区分名 → 商品名」という商品階層を作成 しましたが、属性リレーションシップを作成していないので、クエリ パフォーマンスが低下する 主旨の警告が表示されています（警告は、青い波線へマウス オーバーして確認できます）。

この階層に対して属性リレーションシップを設定するには、［属性リレーションシップ］タブをク リックして属性リレーションシップ デザイナーを開き、次のように「商品名」属性を「区分名」

属性へドラッグ＆ドロップします。

このように階層と同じように属性リレーションシップを作成することで、よりパフォーマンスの良 1

「商品名」を「区分名」へ ドラッグ ＆ 度rっぷ

2

↓

商品名 → 区分名 という階層と同じ形の 属性リレーションシップ

を作成できる

い集計を作成できるようになります。

なぜパフォーマンスの良い集計が作成できるかは、次の図で説明します。

この図は、「商品区分ごとの集計」と「全体の集計」の 2 個の集計がある様子ですが、「全体の集 計」に関しては、「商品区分ごとの集計」を Sum（合計）すれば計算できるので、事前に集計を作 成しておく必要がないという形です。

これは、次のように「商品ごとの集計」と「商品区分ごとの集計」にも同じことが言えます。

「区分ごとの集計」に関しては、「商品ごとの集計」を Sum（合計）すれば計算できるので、事前 に集計を作成しておく必要がないという形です。この状況を「集計デザイナー」で考えると次のよ うになります。

この画面では、「商品名と年の集計」と「区分名と年の集計」があります。しかし、区分名の集計

商品区分ごと の集計

全体の集計

商品区分ごとの集計を Sum（合計）すれば 全体の集計が計算できるので

全体の集計に関しては 事前に作成する必要がない

「乳製品」内の商品の 商品ごとの集計

「乳製品」区分の集計

商品ごとの集計を Sum（合計）すれば 区分集計が計算できるので

区分集計に関しては 事前に作成する必要がない

「商品名」と

「年」の集計

「区分名」と

「年」の集計

は商品名ごとの集計から計算できるので、わざわざ集計を作る必要がない（商品名と年の集計だけ でよい）という形です。

属性リレーションシップを「商品名 → 区分名」と設定している場合は、このような冗長な集計を 作る必要がなくなるので、余分な集計を作成しなくて済むわけです（前項の「集計のデザイン ウ ィザード」では、属性リレーションシップをもとに、より良い集計の組み合わせを探してくれてい ます）。逆に、属性リレーションシップを設定していない場合は、上記の集計は 2つとも作成して おいたほうがクエリ パフォーマンスが向上するので、必要な集計というわけです。

このように属性リレーションシップは、よりパフォーマンスの良い集計を作成するには不可欠な機 能で、Analysis Services 多次元モデルのパフォーマンスを最も左右する機能です。

集計によるクエリ処理とキューブ処理のトレード オフ

今まで説明してきたように、集計を作成すると、クエリ パフォーマンスを向上することができま すが、事前に集計を作成する分、キューブ処理にかかる時間は増えます（トレードオフがあります）。

したがって、属性リレーションシップを適切に設定して、冗長な集計を作成しないようにし、クラ イアントから頻繁にアクセスされる集計を中心に、Note で紹介した「使用法に基づく最適化ウィ ザード」なども利用しつつ、うまく集計をカスタマイズしていくことが重要です。属性リレーショ ンシップと集計の扱いは、Analysis Services を利用する上で最も重要な作業になります。

Note： 属性リレーションシップの種類を Regid へ変更

属性リレーションシップは、デフォルトでは Flexible（可変）へ設定されますが、これを Regid（固定）へ変更するこ とでパフォーマンスを向上させることができます。なお、Regid へ設定できるのは、時間が経っても関係に変更がない 属性の場合で、「年 → 四半期 → 月 → 日」のように階層が普遍のものに対して Regid を設定します。Regid へ設定 するには、次のように操作します。

クエリ処理時間

時間

キューブ処理時間

集計0%

デフォルト 集計100%

0

1