MDX の主な概念 (Analysis Services)

  • [アーティクル]

適用対象: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

多次元式 (MDX) を使用して多次元データを照会したり、キューブ内で MDX 式を作成したりするには、多次元の概念と用語を理解しておく必要があります。

既にご存じのデータ要約の例を足掛かりにして、それと MDX の関連性を確認することをお勧めします。 ここでは、Analysis Services サンプル キューブのデータが入力された Excel で作成されたピボットテーブルを示します。

メジャーとディメンションが呼び出されたピボットテーブル メジャー

メジャーとディメンション

Analysis Services キューブは、ピボットテーブルの例で示したメジャー、ディメンション、およびディメンション属性で構成されます。

メジャー は、合計、カウント、パーセンテージ、最小、最大、または平均として集計されるセル内の数値データ値です。 メジャー値は、動的で、ユーザーのナビゲーションやピボットテーブルとのやり取りに反応して、リアルタイムに計算されます。 この例では、各セルが軸の展開と折りたたみに基づいて増減する Reseller Sales Amounts を表しています。 Date (年、四半期、月、または日付) と Sales Territory (国のグループ、国、地域) の任意の組み合わせに対して、その特定のコンテキストで集計された Reseller Sales Amount を取得できます。 メジャーの同義語である他の用語としては、ファクト (データ ウェアハウス内) と計算フィールド (テーブルと Excel データ モデル内) があります。

ディメンション は、ピボットテーブルの列軸と行軸上に表示され、メジャーの背後にある意味を表します。 ディメンションは、リレーショナル データ モデル内のテーブルに似ています。 ディメンションの一般的な例として、Time、Geography、Products、Customers、Employees などが挙げられます。 この例は、各行の Sales Territory と最上部の Date の 2 つのディメンションで構成されていますが、Promotions や Products などの Reseller Sales に関連付けられた他のディメンションをドラッグ アンド ドロップして、簡単に、それらのディメンションに沿った販売実績を表示することができます。 データを効率的に探索できるかどうかは、作成するディメンションと、それがデータ ソース内のファクト テーブルと関連性があるかどうかに応じて異なります。

ディメンション属性 は、テーブル内の列と同様の、ディメンション内の名前付きアイテムです。 この例では、Sales Territory ディメンション属性が、Country Group (Europe、North America、Pacific)、Country (Canada、United States)、および Region (Central、Northeast、Northwest、Southeast、Southwest) で構成されています。

各属性には、データ値のコレクション、または、それに関連付けられたメンバーが含まれています。 この例では、Country Group 属性のメンバーは、Europe、North America、および Pacific です。 メンバー は、属性に属している実際のデータ値を表します。

注意

データ モデリングの 1 つの側面は、データ自体に内在するパターンとリレーションシップを形式化することです。 自然階層に分類されるデータを操作する場合は、国/地域と地域の都市の場合と同様に、 属性リレーションシップを作成することで、そのリレーションシップを正式化できます。 属性リレーションシップは、州と市区町村の間のリレーションシップなど、属性間の一対多リレーションシップです。州には多くの都市がありますが、都市は 1 つの州に属します。 モデルで属性リレーションシップを作成すると、クエリのパフォーマンスが向上するため、データでサポートされている場合は、それらを作成することをお勧めします。 属性リレーションシップは、SQL Server Data Tools 内のディメンション デザイナーで作成できます。 「 Define Attribute Relationships」を参照してください。

Excel 内部のピボットテーブル フィールド リストにモデル メタデータが表示されます。 上のピボットテーブルと下のフィールド リストを比較します。 フィールド リストには Sales Territory、Group、Country、Region (メタデータ) が含まれているのに対して、ピボットテーブルにはメンバー (データ値) しか含まれていないことに注意してください。 アイコンの外観を識別することによって、多次元モデルの部品を容易に Excel 内のピボットテーブルに関連付けることができます。

ピボットテーブル フィールド リスト

属性階層

深く考えなくても、各軸に沿ってレベルを展開したり、折りたたんだりするだけで、ピボットテーブル内の値が増減することがわかっていますが、どうしてこんなことができるのでしょうか。 答えは属性階層にあります。

すべてのレベルを折りたたむと、各 Country Group と Calendar Year の総合計が表示されます。 この値は、階層内の (すべての) メンバー と呼ばれるものから抽出されます。 (すべての) メンバーは、属性階層内のすべてのメンバーの値を計算したものです。

  • すべての Country Groups と Dates の (すべての) メンバーを集計すると、$80,450,596.98 になります。

  • CY2008 の (すべての) メンバーは $16,038,062.60 です。

  • Pacific の (すべての) メンバーは $1,594,335.38 です。

このような集計は、事前に計算され、保存されます。これが、Analysis Services のクエリ パフォーマンスが優れている秘密の一部です。

すべてのメンバーが呼び出されたピボットテーブル

階層を展開すると、最終的に、最下位レベルに到達します。 これは リーフ メンバーと呼ばれます。 リーフ メンバーは、子が存在しない階層のメンバーです。 この例では、Southwest がリーフ メンバーです。

リーフ メンバー calle dout

上位にあるものは 親メンバーと呼ばれます。 米国は南西部の親です。

属性階層の構成要素

総じて、これらの概念のすべてが 属性階層という概念を作り上げています。 属性階層は、さまざまな属性メンバーからなる 1 つのツリー構造であり、それには以下のレベルが含まれています。

  • リーフ レベル。個別の属性メンバーが含まれています。リーフ レベルの各メンバーを リーフ メンバーともいいます。

  • 属性階層が親子階層の場合の中間レベル (詳細は後述)。

  • すべての子属性の集計値を含む (すべての) メンバー。 必要に応じて、(すべて) レベルがデータに対して意味をなさない場合は、非表示またはオフにすることができます。 たとえば、Product Code は数値ですが、すべての製品コードを合計または平均化したり、集計したりしても意味がありません。

注意

BI 開発者の多くは、クライアント アプリケーションで特定の動作を実現するためや特定のパフォーマンス メリットを得るために、属性階層のプロパティを設定します。 たとえば、 (All) メンバーが意味をなさない属性に対して AttributeHierarchyEnabled=False を設定します。 または、(すべての) メンバーを非表示にするだけなら、AttributeHierarchyVisible=False を設定することができます。 プロパティの詳細については、「 Dimension Attribute Properties Reference 」を参照してください。

ピボットテーブル (少なくともこの例の) では、行軸と列軸を展開すると、下位レベルの属性が表示されます。 拡張可能なツリーは、モデル内に作成されたナビゲーション階層を通して実現されます。 AdventureWorks サンプル モデルでは、Sales Territory ディメンションに Country Group、Country、および Region の順で複数レベル階層が含まれています。

ご存じのように、階層はピボットテーブルまたはその他のデータ要約オブジェクト内のナビゲーション パスを提供するために使用されます。 これには均衡と不均衡という 2 つの基本的な種類があります。

均衡階層

バランスの取れた階層を持つピボットテーブルが呼び出され

均衡階層 は、最上位メンバーと任意のリーフ メンバーの間のレベル数が等しい階層です。

自然階層 は基になるデータから自然に発生する階層です。 一般的な例は、それぞれの下位レベルが予想どおり親から派生する、国/地域/州や年/月/日などのカテゴリ/サブカテゴリ モデルです。

多次元モデルでは、ほとんどの階層が均衡階層で、その多くが自然階層でもあります。

属性階層とよく対比される、もう 1 つの関連モデリング用語として、 ユーザー定義階層があります。 これは、属性を定義すると Analysis Services によって自動的に生成される属性階層とは対照的に、BI 開発者によって作成される階層を意味します。

不均衡階層

不規則階層のピボットテーブルが呼び出され、

不規則階層 または 不均衡階層 は、トップ レベル メンバーとリーフ メンバーの間に存在するレベルの数が一様でない階層です。 ここでも、これは BI 開発者によって作成された階層ですが、この場合はデータにギャップがあります。

AdventureWorks サンプル モデルでは、Sales Territory は、この例の他の国/地域には存在しない追加レベル (リージョン) を米国があるため、不規則な階層を示しています。

不規則階層は、クライアント アプリケーションでうまく処理されない場合、BI 開発者が対処する必要があります。 Analysis Services モデルでは、複数レベルのデータ間のリレーションシップを明示的に定義することによって、レベル間のあいまいな関係性を排除した 親子階層 を構築できます。 詳細については、「 親子ディメンション 」を参照してください。

キー属性

モデルは、キーとインデックスを使って関連付けを示す関連オブジェクトのコレクションです。 Analysis Services モデルについても違いはありません。 ディメンション (リレーショナル モデルのテーブルに相当することを思い出してください) ごとに、キー属性が存在します。 キー属性 は、ファクト テーブル (メジャー グループ) に対する外部キー リレーションシップで使用されます。 ディメンション内のすべての非キー属性がキー属性に (直接的または間接的に) リンクされます。

必ずではありませんが、キー属性の多くは 粒度属性でもあります。 粒度は、データ内の詳細または精度のレベルを表します。 この場合も、一般的な例が理解の助けになります。 日付の値を考えてみましょう。日次売上の場合は、日付の値を日に設定する必要があります。売上予算の場合は、四半期ごとで十分ですが、分析データがスポーツ イベントのレース結果で構成されている場合は、粒度をミリ秒にする必要があります。 データ値の精度のレベルが粒度です。

通貨はもう 1 つの例です。金融アプリケーションでは、小数点以下の桁数が多い年額を追跡する場合があります。一方、地元の学校の資金調達者は、最も近いドルの値のみを必要とする場合があります。 粒度の理解は、不要なデータの保存を避けるという意味でも重要です。 詳細のレベルが分析に影響しない場合は、タイムスタンプからミリ秒を切り捨てる、または、売上高から少額を切り捨てることによって、ストレージと処理時間を節約することができます。

粒度属性を設定するには、SQL Server Data Tools 内のキューブ デザイナーの [ディメンションの使用法] タブを使用します。 AdventureWorks サンプル モデルでは、Date ディメンションのキー属性は Date キーです。 Sales Orders の場合は、粒度属性がキー属性と等価です。 Sales Targets の場合は、粒度のレベルが四半期ごとであり、それに応じて、粒度属性が Calendar Quarter に設定されます。

粒度属性を示すモデル 粒度属性

注意

粒度属性とキー属性が異なる場合は、すべての非キー属性を直接的または間接的に粒度属性にリンクする必要があります。 キューブ内ではディメンションの粒度が粒度属性で定義されます。

クエリ スコープ (キューブ空間)

クエリのスコープは、データが選択される境界を意味します。 これは、キューブ全体 (キューブは最大のクエリ オブジェクト) からセルまでの範囲になります。

キューブ空間 は、そのキューブのメジャーを伴った、キューブの属性階層のメンバーから構成されます。

サブキューブ は、キューブのフィルターを適用したビューを表す、キューブのサブセットです。 サブキューブは、MDX 計算スクリプト内の Scope ステートメントを使用して、あるいは、MDX クエリ内のサブセレクト句で、または、セッション キューブとして定義することができます。

セル は、メジャー ディメンション メンバーのメンバーとキューブ内の各属性階層からのメンバー間のスペースを意味します。

その他のモデリング用語

このセクションは、他のセクションには簡単に収まらない概念と用語のコレクションですが、まだ知る必要があります。

計算メンバー は、クエリ実行時に定義と計算がなされるディメンション メンバーです。 計算されるメンバーをユーザー クエリまたは MDX 計算スクリプトで定義して、サーバーに保存しておくことができます。 計算されるメンバーは、その計算されるメンバーが定義されているディメンション内のディメンション テーブルの行と対応します。

個別カウント は、1 度しかカウントされないデータ項目に使用される特殊なメジャーです。 AdventureWorks サンプル モデルには、Internet Orders、Reseller Orders、および Sales Orders の個別カウント メジャーが含まれています。

メジャー グループ は、1 つ以上のメジャーのコレクションです。 そのほとんどは、ユーザー定義であり、関連メジャーをまとめて保持するために使用します。 個別カウント メジャーは例外です。 このメジャーは、必ず、個別メジャーのみを含む専用のメジャー グループに配置されます。 ピボットテーブルの例の図にはメジャー グループが表示されませんが、メジャーの名前付きコレクションとしてピボットテーブル フィールド リストに表示されます。

メジャー ディメンション は、キューブ内のすべてのメジャーを含むディメンションです。 これは、SQL Server Data Toolsで構築する多次元モデルでは公開されませんが、同じものが存在します。 これにはメジャーが含まれているため、通常は、メジャー ディメンションのすべてのメンバーが集計されます (合計またはカウントによって)。

データベース ディメンションとキューブ ディメンション。 モデル内では、スタンドアロン ディメンションを定義して、同じモデル内の任意の数のキューブに含めることができます。 キューブにディメンションを追加すると、キューブ ディメンションと呼ばれます。 プロジェクト内で単独で、オブジェクト エクスプローラーのスタンドアロン項目として、データベース ディメンションと呼ばれます。 どうして区別が必要なのでしょうか。 それは、それぞれに独立的にプロパティを設定できるからです。 製品ドキュメントでは、両方の用語が使用されています。そのため、それらが何を意味するかを理解する価値があります。

次の手順

これで、重要な概念と用語が理解できたところで、Analysis Services の基本的な概念をさらに詳しく説明している以下のトピックに進むことができます。

参照

キューブ空間
タプル
autoexists
メンバー、組、およびセットの操作 (MDX)
表示部分の合計と非表示部分の合計
MDX クエリの基礎 (Analysis Services)
MDX スクリプティングの基礎 (Analysis Services)
MDX 言語リファレンス (MDX)
多次元式 (MDX) リファレンス