次の方法で共有


のディメンション デザイナーでは、[ディメンション構造] ビューの

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

Microsoft SQL Server SQL Server Analysis Services では、ディメンション内の属性は常にキー属性に直接または間接的に関連付けます。 同一のリレーショナル テーブルからすべてのディメンション属性が派生するスター スキーマに基づいてディメンションを定義すると、ディメンションのキー属性と各非キー属性の間に自動的に属性リレーションシップが定義されます。 関連を持った複数のテーブルからディメンション属性が派生するスノーフレーク スキーマを基にディメンションを定義すると、属性リレーションシップが自動的に次のように定義されます。

  • キー属性と、メイン ディメンション テーブルの列にバインドされた各非キー属性の間

  • キー属性と、基になるディメンション テーブルにリンクしているセカンダリ テーブルの外部キーにバインドされた属性の間

  • セカンダリ テーブルの外部キーにバインドされた属性と、セカンダリ テーブルの列にバインドされた各非キー属性の間

ただし、さまざまな理由で、上記の既定の属性リレーションシップの変更が必要になる場合もあります。 たとえば、非キー属性に基づいて、自然階層、カスタムの並べ替え順、ディメンションの粒度などを定義できます。 詳細については、「 ディメンション属性プロパティ リファレンス」を参照してください

注意

属性リレーションシップは、多次元式 (MDX) ではメンバーのプロパティと呼ばれます。

自然階層リレーションシップ

ユーザー定義階層内の各属性がそのすぐ下の属性と一対多のリレーションシップにある場合、階層は自然階層になります。 たとえば、次の 8 つの列から構成されるリレーショナル ソース テーブルを基にした Customer ディメンションを考えてみます。

  • CustomerKey

  • CustomerName

  • Age

  • 性別

  • 電子メール

  • City

  • Region

対応する Analysis Services ディメンションには、次の 7 つの属性があります。

  • Customer (CustomerKey キーを基に CustomerName でメンバー名を指定)

  • Age、Gender、Email、City、Region、Country

自然階層を表すリレーションシップを適用するには、あるレベルの属性とその下のレベルの属性との間に属性リレーションシップを作成します。 SQL Server Analysis Servicesの場合、これは自然なリレーションシップと潜在的な集計を指定します。 Customer ディメンションには、Country 属性、Region 属性、City 属性、および Customer 属性に対する自然階層が存在します。 {Country, Region, City, Customer} の自然階層は、次の属性リレーションシップを追加して記述します。

  • Region 属性に対する属性リレーションシップとしての Country 属性

  • City 属性に対する属性リレーションシップとしての Region 属性

  • Customer 属性に対する属性リレーションシップとしての City 属性

キューブ内のデータを移動するために、データ内の自然階層 ( アドホック 階層またはレポート階層と呼ばれます) を表さないユーザー定義階層 作成することもできます。 たとえば、{Age, Gender} を基にしたユーザー定義階層を作成できます。 2 つの階層の動作に違いは見られませんが、自然階層は、ソース データ内の自然なリレーションシップを考慮した集計構造とインデックス作成構造 (ユーザーから非表示) の恩恵を受けます。

レベルの SourceAttribute プロパティによって、レベルの記述に使用される属性が決まります。 属性 の KeyColumns プロパティは、メンバーを提供するデータ ソース ビューの列を指定します。 属性 の NameColumn プロパティは、メンバーに別の名前列を指定できます。

SQL Server Data Toolsを使用してユーザー定義階層のレベルを定義するには、ディメンション Designerを使用して、ディメンション属性、ディメンション テーブル内の列、またはキューブのデータ ソース ビューに含まれる関連テーブルの列を選択できます。 ユーザー定義階層の作成の詳細については、「 create User-Defined Hierarchies」を参照してください。

Analysis Services では通常、メンバーの内容が想定されています。 リーフ メンバーには子孫がなく、元のデータ ソースから派生したデータが含まれています。 非リーフ メンバーには子孫があり、子メンバーで実行した集計から派生したデータが含まれています。 集計レベルのメンバーは、下位レベルの集計が基になっています。 したがって、レベルのソース属性で IsAggregatable プロパティが False に設定されている場合は、その上のレベルとして集計可能な属性を追加する必要はありません。

属性リレーションシップの定義

属性リレーションシップを作成するときの主な制約は、属性リレーションシップによって参照される属性に、属性リレーションシップが所属する属性のメンバーの値が 2 つ以上含まれていないことを確認する必要があることです。 たとえば、City 属性と State 属性の間のリレーションシップを定義する場合、それぞれの市区町村は 1 つの都道府県にのみ関連付けることができます。

属性リレーションシップのクエリ

MDX クエリを使用すると、MDX SELECT ステートメントの PROPERTIES キーワード (keyword)を使用して、メンバー プロパティの形式で属性リレーションシップからデータを取得できます。 MDX を使用してメンバー プロパティを取得する方法の詳細については、「 Using Member Properties (MDX)」を参照してください。

参照

属性と属性階層
ディメンションの属性のプロパティの参照
ユーザー階層
ユーザー階層プロパティ