アクティブなリレーションシップと非アクティブなリレーションシップのガイダンス

この記事では、Power BI Desktop を使用するデータ モデリング担当者を対象にしています。 アクティブまたは非アクティブなモデル リレーションシップを作成するタイミングに関するガイダンスが提供されます。 既定では、アクティブなリレーションシップはフィルターを他のテーブルに伝達します。 ただし、非アクティブなリレーションシップは、DAX 式がリレーションシップをアクティブ化 (使用) するときにのみフィルターを伝達します。

手記

モデル リレーションシップの概要については、この記事では説明しません。 リレーションシップ、それらのプロパティ、またはそれらを構成する方法について完全に理解していない場合は、最初に Power BI Desktop の モデルのリレーションシップに関する記事を読んでお勧めします。

また、スター スキーマの設計について理解していることも重要です。 詳細については、「スター スキーマと Power BI の重要性を理解する」を参照してください。

アクティブなリレーションシップ

一般に、可能な限りアクティブなリレーションシップを定義することをお勧めします。 レポート作成者や Q&A を使用するユーザーがモデルを使用する方法の範囲と可能性が広がります。

航空会社のフライト オン タイム パフォーマンス (OTP) を分析するように設計された インポート モデルの例を考えてみましょう。 モデルには テーブルがあります。これは、フライトごとに 1 行を格納する ファクト テーブルです。 各行には、フライトの日付、フライト番号、出発空港と到着空港、および遅延時間 (分単位) が記録されます。 Airport テーブルもあります。これは、空港ごとに 1 行を格納する ディメンション テーブル です。 各行には、空港コード、空港名、国または地域が記述されています。

2 つのテーブルの部分的なモデル図を次に示します。

Flight テーブルと Airport テーブルの間には、2 つのモデル リレーションシップがあります。 Flight テーブルでは、DepartureAirport 列と ArrivalAirport 列は、Airport テーブルの Airport 列に関連しています。 スター スキーマ設計では、Airport テーブルは、ロールプレイング ディメンションとして記述されます。 このモデルでは、出発空港 と到着空港の 2 つの役割があります。

この設計はリレーショナル スター スキーマ設計には適していますが、Power BI モデルではうまく機能しません。 これは、モデル リレーションシップはフィルター伝達のパスであり、これらのパスは決定論的である必要があるためです。 フィルター伝達パスが決定論的であることを確認する方法の詳細については、「リレーションシップ パスのあいまいさを解決 を参照してください。したがって、この例で示すように、一方のリレーションシップはアクティブで、もう一方のリレーションシップは非アクティブです (破線で表されます)。 具体的には、アクティブな ArrivalAirport 列とのリレーションシップです。つまり、Airport テーブルに適用されたフィルターは、Flight テーブルの ArrivalAirport 列に自動的に反映されます。

このモデル設計では、データの報告方法に重大な制限が課されます。 具体的には、Airport テーブルをフィルター処理して、出発空港のフライトの詳細を自動的に分離することはできません。 と同時に 出発空港と到着空港でレポートをフィルター処理 (またはグループ化) する必要がある場合は、2 つのアクティブなリレーションシップが必要です。 この要件を Power BI モデルの設計に変換することは、モデルに 2 つの空港テーブルが必要です。

改善されたモデル設計を次に示します。

このモデルには、Departure Airport と Arrival Airportの 2 つの空港テーブルがあります。 これらのテーブルと Flight テーブルの間の各モデル リレーションシップがアクティブです。 また、 テーブルと テーブルの列名には、出発 または到着という単語が付いています。

改善されたモデル設計では、次のレポートデザインの作成がサポートされています。

このレポート ページは、出発空港 Melbourne によってフィルター処理され、テーブル ビジュアルは到着空港によってグループ化されています。

手記

モデルのインポートでは、別のディメンション テーブルを追加すると、モデル サイズが増加し、更新時間が長くなります。 そのため、これは「インポート モデリングのデータ削減手法」の記事で説明されている推奨事項と矛盾しています。 ただし、この例では、アクティブなリレーションシップのみを持つという要件によって、これらの推奨事項がオーバーライドされます。

さらに、ディメンション テーブルには、ファクト テーブルの行数に対する低い行数が格納されるのが一般的です。 そのため、モデルのサイズと更新時間の増加は、過度に大きくなる可能性はありません。

リファクタリング手法

ここでは、1 つのロールプレイング ディメンション テーブルから、ロールごとに 1 つのテーブルを持つデザイン モデルをリファクタリングする手法を示します。

1. 非アクティブなリレーションシップを削除します。

2. ロールプレイング ディメンション テーブルの名前を変更して、そのロールをより適切に説明することを検討してください。 この記事の例では、Airport テーブルは Flight テーブルの ArrivalAirport 列に関連付けられているため、Arrival Airportとして名前が変更されています。

3. ロールプレイング テーブルのコピーを作成し、ロールを反映する名前を指定します。 インポート テーブルの場合は、計算テーブルを作成することをお勧めします。 DirectQuery テーブルの場合は、Power Query クエリを複製できます。

   この例では、次の計算テーブル定義を使用して、Departure Airport テーブルを作成しました。

   Departure Airport = 'Arrival Airport'
   

4. 新しいテーブルを関連付けるアクティブなリレーションシップを作成します。

5. テーブル内の列の名前を変更して、それぞれの役割を正確に反映するようにすることを検討してください。 この記事の例では、すべての列の先頭に "出発 " または "到着" という語が付いています。 これらの名前を使用すると、デフォルトでレポートビジュアルにわかりやすいラベルとあいまいでないラベルが付けられます。 また、Q&A エクスペリエンスも向上し、ユーザーは簡単に正確な質問を記述できます。

6. ロールプレイング テーブルに説明を追加することを検討してください。 ([データ] ウィンドウでは、レポート作成者がテーブルの上にカーソルを置くと、説明がヒントに表示されます)。これにより、他のフィルター伝達の詳細をレポート作成者に伝えることができます。

非アクティブなリレーションシップ

特定の状況では、非アクティブなリレーションシップが特定のレポートのニーズに対応できます。

さまざまなモデルとレポートの要件を検討します。

• 販売モデルには、OrderDate と ShipDateの 2 つの日付列を持つ Sales テーブルが含まれています。
• Sales テーブルの各行は、1 つの注文を記録します。
• 日付フィルターは、ほとんどの場合、OrderDate 列に適用され、常に有効な日付が格納されます。
• 日付フィルターを ShipDate 列に伝達する必要があるメジャーは 1 つだけです。この列には空白を含めることができます (注文が出荷されるまで)。
• 注文 と 出荷期間を同時にフィルター処理 (またはグループ化) する必要はありません。

2 つのテーブルの部分的なモデル図を次に示します。

Sales テーブルと Date テーブルの間には、2 つのモデル リレーションシップがあります。 Sales テーブルでは、OrderDate 列と ShipDate 列は、Date テーブルの Date 列に関連しています。 このモデルでは、Date テーブルの 2 つの役割は、注文日 と出荷日 です。 アクティブな OrderDate 列とのリレーションシップです。

6 つのメジャー (1 つを除く) はすべて、OrderDate 列でフィルター処理する必要があります。 ただし、Orders Shipped メジャーは、ShipDate 列でフィルター処理する必要があります。

Orders メジャーの定義を次に示します。 フィルター コンテキスト内の Sales テーブルの行をカウントするだけです。 Date テーブルに適用されるすべてのフィルターは、OrderDate 列に反映されます。

Orders = COUNTROWS(Sales)

Orders Shipped メジャーの定義を次に示します。 USERELATIONSHIP DAX 関数を使用します。これは、式の評価中にのみ、特定のリレーションシップのフィルター伝達をアクティブにします。 この例では、ShipDate 列とのリレーションシップが使用されます。

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

このモデル 設計では、次のレポートデザインの作成がサポートされています。

レポート ページは、2019 年第 4 四半期 でフィルター処理されます。 テーブルビジュアルは月ごとにグループ化され、さまざまな売上統計が表示されます。 Orders 指標と Orders Shipped 指標では、異なる結果が生成されます。 それぞれが同じ集計ロジック (Sales テーブルの行数) を使用しますが、テーブル フィルターの伝達 Date 異なります。

四半期スライサーに BLANK オプションが含まれていることを確認してください。 このスライサー オプションは、テーブル拡張結果として表示されます。 各 Sales テーブル行には有効な注文日が設定されていますが、一部の行には空白の出荷日があります。これらの注文はまだ出荷されていません。 テーブルの拡張では非アクティブなリレーションシップも考慮されるため、BLANK はリレーションシップの多側の BLANK (またはデータ整合性の問題) により表示される可能性があります。

手記

行レベル セキュリティ (RLS) フィルターは、アクティブなリレーションシップを介してのみ伝達されます。 USERELATIONSHIP DAX 関数がメジャー定義によって使用されている場合でも、RLS フィルターは非アクティブなリレーションシップに対して伝達されません。

推奨 事項

特に RLS ロールがデータ モデルに対して定義されている場合は、可能な限りアクティブなリレーションシップを定義することをお勧めします。 レポート作成者や Q&A を使用するユーザーがモデルを使用する方法の範囲と可能性が広がります。 これは、ロールプレイング ディメンション テーブルをモデルで複製する必要があることを意味します。

ただし、特定の状況では、ロールプレイング ディメンション テーブルに対して 1 つ以上の非アクティブなリレーションシップを定義できます。 この方法は、次の場合に検討できます。

• レポート ビジュアルをさまざまなロールで同時にフィルター処理する必要はありません。
• USERELATIONSHIP DAX 関数を使用して、関連するモデル計算の特定のリレーションシップをアクティブ化します。

関連コンテンツ

この記事に関連する詳細については、次のリソースを参照してください。

• Power BI Desktop でのモデル関係について
• スター スキーマと Power BI の重要性を理解する
• リレーションシップのトラブルシューティング ガイダンス
• 問。 Fabric コミュニティに問い合わせてみる
• 提案はありますか？ Fabric の を向上させるためにアイデアを投稿する