多次元式 (MDX) を使用して多次元データのクエリを実行したり、キューブ内に MDX 式を作成したりする前に、多次元の概念と用語を理解するのに役立ちます。
まず、既に知っているデータ要約の例を使用して、MDX とどのように関連しているかを確認することをお勧めします。 Analysis Services サンプル キューブのデータが入力された Excel で作成されたピボットテーブルを次に示します。
寸法と次元
Analysis Services キューブは、メジャー、ディメンション、およびディメンション属性で構成されており、これらはすべてピボットテーブルの例で示されています。
メジャー は、セル内で見つかった数値データ値であり、合計、カウント、パーセンテージ、最小、最大、または平均として集計されます。 メジャー値は動的であり、ユーザー ナビゲーションとピボットテーブルとの対話に応答してリアルタイムで計算されます。 この例では、軸を展開または折りたたむことで増減する "Reseller Sales Amounts" がセルに表示されます。 日付 (年、四半期、月、または日付) と Sales Territory (国グループ、国、地域) の任意の組み合わせについては、その特定のコンテキストの合計でリセラーの売上金額を取得できます。 メジャーと同義であるその他の用語は、ファクト (データ ウェアハウス内) と計算フィールド (表形式および Excel データ モデル) です。
ディメンション はピボットテーブルの列軸と行軸に配置されており、測定値の背後にある意味を提供します。 ディメンションは、リレーショナル データ モデルのテーブルに似ています。 ディメンションの一般的な例としては、時間、地理、製品、顧客、従業員などがあります。 この例では、行に Sales Territory という 2 つのディメンションがあり、上部に日付が含まれていますが、販売促進や製品など、Reseller Sales に関連付けられている他のディメンションを簡単にドラッグ アンド ドロップして、それらのディメンションに沿って販売実績を表示できます。 興味深い方法でデータを探索する機能は、作成するディメンションと、データ ソースのファクト テーブルに関連しているかどうかによって異なります。
ディメンション属性 は、テーブル内の列と同様に、ディメンション内の名前付きアイテムです。 この例では、営業区域のディメンション属性は、国グループ (ヨーロッパ、北米、太平洋)、国 (カナダ、米国)、地域 (中央、北東、北西、南東、南西) で構成されています。
各属性には、データ値またはメンバーのコレクションが関連付けられています。 この例では、Country Group 属性のメンバーはヨーロッパ、北米、太平洋です。 メンバー は、属性に属する実際のデータ値を参照します。
注
データ モデリングの 1 つの側面は、データ自体に既に存在するパターンとリレーションシップを形式化することです。 国と地域の都市の場合と同様に、自然階層に分類されるデータを操作する場合は、 属性リレーションシップを作成することで、そのリレーションシップを形式化できます。 属性リレーションシップは、属性間の一対多リレーションシップです。たとえば、州と市区町村の間のリレーションシップは、州には多くの都市がありますが、市区町村は 1 つの州のみに属します。 モデルで属性リレーションシップを作成すると、クエリのパフォーマンスが向上するため、データでサポートされている場合は作成することをお勧めします。 SQL Server Data Tools のディメンション デザイナーで属性リレーションシップを作成できます。 「 属性リレーションシップの定義」を参照してください。
Excel 内では、モデルメタデータがピボットテーブルフィールドリストに表示されます。 上のピボットテーブルを下のフィールド リストと比較します。 フィールド リストには Sales Territory、Group、Country、Region (metadata) が含まれているのに対し、ピボットテーブルにはメンバー (データ値) だけが含まれていることに注意してください。 アイコンの外観を把握すると、多次元モデルの部分を Excel のピボットテーブルに簡単に関連付けることができます。
属性階層
ほとんどの場合、ピボットテーブルの値は、各軸に沿ってレベルを展開したり折りたたんだりするときに上または下に移動することがわかりますが、その理由は何ですか? その答えは属性階層にあります。
すべてのレベルを折りたたんで、各国グループと暦年の総計に注目してください。 この値は、階層内の (All) メンバー と呼ばれるものから派生します。 (All) メンバーは、属性階層内のすべてのメンバーの計算値です。
すべての国グループと日付を組み合わせた (All) メンバーは $80,450,596.98 です
CY2008 の (All) メンバーは $16,038,062.60 です
Pacific の (All) メンバーは $1,594,335.38 です
このような集計は事前に計算され、事前に格納されます。これは、Analysis Services の高速クエリ パフォーマンスのためのシークレットの一部です。
階層を展開すると、最終的に最も低いレベルになります。 これは リーフ メンバーと呼ばれます。 リーフ メンバーは、子を持たない階層のメンバーです。 この例では、オーストラリアがリーフ メンバーです。
その上にあるものは親 メンバーと呼ばれます。 太平洋はオーストラリアの親です。
属性階層のコンポーネント
これらの概念はすべて、 属性階層の概念に向かって構築されます。 属性階層は、次のレベルを含む属性メンバーのツリーです。
個別の各属性メンバーを含むリーフ レベルがあり、このリーフ レベルの各メンバーはリーフ メンバーとも呼ばれます。
属性階層が親子階層の場合は中間レベルです (詳細については後で説明します)。
すべての子属性の集計値を含む (All) メンバー。 必要に応じて、(すべて) レベルがデータに対して意味をなさない場合は、非表示またはオフにすることができます。 たとえば、製品コードは数値ですが、すべての製品コードを合計または平均したり、集計したりしても意味がありません。
注
多くの場合、BI 開発者は、クライアント アプリケーションで特定の動作を実現したり、特定のパフォーマンス上の利点を得るために、属性階層にプロパティを設定します。 たとえば、(All) メンバーが意味をなさない属性に AttributeHierarchyEnabled=False を設定します。 または、単に (All) メンバーを非表示にしたい場合は、AttributeHierarchyVisible=False を設定します。 プロパティの詳細については、「 ディメンション属性プロパティ リファレンス 」を参照してください。
ナビゲーション階層
ピボットテーブル内 (少なくともこの例では) では、行軸と列軸が展開され、下位レベルの属性が表示されます。 展開可能なツリーは、モデルで作成したナビゲーション階層によって実現されます。 AdventureWorks サンプル モデルでは、Sales Territory ディメンションには、国グループから始まり、Country、Region の順に続く複数レベルの階層があります。
ご覧のように、階層は、ピボットテーブルまたはその他のデータ集計オブジェクトにナビゲーション パスを提供するために使用されます。 バランス型と不均衡型の 2 種類があります。
バランス階層構造
![]() |
バランス階層は、最上位レベルとリーフ メンバーの間に同じ数のレベルが存在する階層です。 自然階層は、基になるデータから自然に出現する階層です。 一般的な例として、Country-Region-State または Year-Month-Date または Category-Subcategory-Model があり、各下位レベルは親から予測どおりに流れます。 多次元モデルでは、ほとんどの階層はバランスの取れた階層であり、その多くは自然階層でもあります。 もう 1 つの関連するモデリング用語は、属性階層とのコントラストとしてよく使用される user-defined hierarchy です。 これは、属性を定義するときに Analysis Services によって自動的に生成される属性階層とは対照的に、BI 開発者によって作成された階層を意味します。 |
不均衡階層
![]() |
不規則階層または不均衡階層は、最上位レベルとリーフ メンバーの間に異なる数のレベルが存在する階層です。 ここでも、これは BI 開発者によって作成された階層ですが、この場合はデータにギャップがあります。 AdventureWorks サンプル モデルでは、米国には、この例の他の国には存在しない追加レベル (リージョン) があるため、Sales Territory は不規則な階層を示しています。 クライアント アプリケーションが不規則階層をエレガントな方法で処理しない場合、不規則階層は BI 開発者の課題です。 Analysis Services モデルでは、複数レベルのデータ間のリレーションシップを明示的に定義する 親子階層 を構築し、1 つのレベルと次のレベルの関係に関するあいまいさを排除できます。 詳細については、「 Parent-Child 階層 」を参照してください。 |
キー属性
モデルは、関連付けを行うためにキーとインデックスに依存する関連オブジェクトのコレクションです。 Analysis Services モデルも違いはありません。 ディメンションごとに (リレーショナル モデルのテーブルと同等であることを思い出してください)、キー属性があります。 キー属性は、ファクト テーブル (メジャー グループ) との外部キー リレーションシップで使用されます。 ディメンション内のすべてのキー以外の属性は、キー属性に直接または間接的にリンクされます。
多くの場合、キー属性は 粒度属性でもありますが、必ずしもではありません。 粒度とは、データ内の詳細レベルまたは精度を指します。 ここでも、一般的な例では、理解するための最も簡単なパスが提供されます。 日付値を考慮する: 日次売上の場合、必要なのは日単位で指定された日付値です。売上目標がクォータの場合は、四半期単位で十分かもしれません。しかし、分析データがスポーツイベントのレース結果に関するものである場合、粒度はミリ秒単位である必要がある可能性があります。 データ値の精度における粒度はそのレベルです。
通貨はもう 1 つの例です。金融アプリケーションでは、小数点以下の桁数が多い通貨値を追跡する場合があります。一方、地元の学校の資金調達者は、最も近いドルの値のみを必要とする場合があります。 不要なデータの格納を回避する必要があるため、グレインを理解することが重要です。 タイムスタンプからミリ秒をトリミングするか、売上金額からペニーをトリミングすると、その詳細レベルが分析に関連しない場合に、ストレージと処理時間を節約できます。
粒度属性を設定するには、SQL Server Data Tools のキューブ デザイナーの [ディメンション使用法] タブを使用します。 AdventureWorks サンプル モデルでは、Date ディメンションのキー属性は Date キーです。 販売注文の場合、粒度属性はキー属性と同じです。 Sales Targets の場合、粒度のレベルは四半期単位であるため、粒度属性はそれに応じてカレンダー四半期に設定されます。
注
粒度属性とキー属性が異なる場合は、すべての非キー属性を直接または間接的に粒度属性にリンクする必要があります。 キューブ内では、粒度属性によってディメンションの粒度が定義されます。
クエリ スコープ (キューブ領域)
クエリのスコープは、データが選択されている境界を指します。 キューブ全体 (キューブは最大のクエリ オブジェクト) からセルまでの範囲を指定できます。
キューブ空間 は、キューブの属性階層のメンバーとキューブのメジャーの組み合わせです。
サブキューブ は、キューブのフィルター処理されたビューを表すキューブのサブセットです。 サブキューブは、MDX 計算スクリプトの Scope ステートメント、または MDX クエリまたはセッション キューブのサブセレクト句で定義できます。
セル は、メジャー次元のメンバーとキューブ内の各属性階層のメンバーが交差する場所を指します。
その他のモデリング用語
このセクションは、他のセクションには簡単に収まらない概念と用語のコレクションですが、まだ理解しておく必要があります。
計算されるメンバー は、クエリ時に定義および計算されるディメンション メンバーです。 計算されるメンバーは、ユーザー クエリまたは MDX 計算スクリプトで定義し、サーバーに格納できます。 計算されるメンバーは、定義されているディメンションのディメンション テーブル内の行に対応します。
個別カウント は、1 回だけカウントする必要があるデータ項目に使用される特殊な種類のメジャーです。 AdventureWorks サンプル モデルには、インターネット注文、リセラー注文、販売注文の個別のカウント メジャーが含まれています。
指標グループ は、1 つ以上の指標の集合体です。 ほとんどの場合、これらはユーザー定義であり、関連する指標を一緒にまとめるために使用します。 区別されたカウントメジャーは例外です。 これらは常に、個別のメジャーのみを含む専用のメジャー グループに配置されます。 ピボットテーブルの例の図ではメジャー グループを表示できませんが、メジャーの名前付きコレクションとしてピボットテーブル フィールド リストに表示されます。
メジャー ディメンション は、キューブ内のすべてのメジャーを含むディメンションです。 これは、SQL Server Data Tools で構築した多次元モデルでは公開されませんが、同じように存在します。 尺度が含まれているため、尺度次元のすべてのメンバーは通常、集計されます(合計または数値によって集約されます)。
データベース ディメンションとキューブ ディメンション。 モデル内では、同じモデル内の任意の数のキューブに含まれるスタンドアロン ディメンションを定義できます。 キューブにディメンションを追加すると、キューブ ディメンションと呼ばれます。 プロジェクト内では単独で、オブジェクト エクスプローラーのスタンドアロン項目として、データベース ディメンションと呼ばれます。 なぜ区別するのですか? プロパティは個別に設定できるためです。 製品ドキュメントでは、両方の用語が使用されているため、その意味を理解する価値があります。
次のステップ
重要な概念と用語を理解したら、Analysis Services の基本的な概念をさらに説明する次の追加トピックに進むことができます。
基本的な MDX クエリ (MDX) を
する
こちらもご覧ください
キューブスペース
タプル
Autoexists
メンバー、タプル、およびセットを扱う (MDX)
ビジュアル合計と非ビジュアル合計
MDX クエリの基礎 (Analysis Services)
MDX スクリプトの基礎 (Analysis Services)
MDX 言語リファレンス (MDX)
多次元式 (MDX) リファレンス