次の方法で共有

一対一のリレーションシップのガイダンス

  • [アーティクル]

この記事では、Power BI Desktop を使用するデータ モデリング担当者を対象にしています。 一対一のモデル リレーションシップを使用するためのガイダンスを提供します。 両方のテーブルそれぞれに共通の一意の値の列が含まれている場合は、一対一のリレーションシップを作成できます。

注意

この記事には、モデル リレーションシップの概要は含まれません。 リレーションシップやそのプロパティ、あるいはその構成方法に完全には慣れていない場合は、まず、Power BI Desktop でのモデル リレーションシップに関する記事をお読みになることをお勧めします。

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

一対一のリレーションシップを使用する、2 つのシナリオがあります。

  • 縮退次元: ファクトテーブルから 縮退次元 を派生させることができます。

  • 行データは、テーブルにまたがっています。1 つのビジネス エンティティまたはサブジェクトが 2 つ (または複数の) モデル テーブルとして読み込まれます。データが異なるデータ ストアからソース化されている可能性があります。 このシナリオは、ディメンション テーブルでよく使用できます。 たとえば、マスター製品の詳細が運用販売システムに格納され、補助製品の詳細が別のソースに格納される場合です。

    ただし、2 つのファクト テーブルを 1 対 1 のリレーションシップに関連付けるのは普通ではありません。 これは、両方のファクト テーブルの次元と粒度が同じである必要があるためです。 また、各ファクト テーブルには、モデル リレーションシップを作成できるようにするために一意の列が必要です。

逆ディメンション

ファクト テーブルの列をフィルター処理またはグループ化に使用する場合は、別のテーブルで使用できるようにすることを検討できます。 こうすることで、フィルター処理またはグループ化に使用する列を、ファクト行の要約に使用する列から分離させることができます。 この分離により次のことが可能になります。

  • ストレージ領域を減らします。
  • モデルの計算を簡略化します。
  • クエリパフォーマンスの向上に貢献します。
  • レポート作成者に、より直感的な データ ウィンドウ エクスペリエンスを提供します。

販売注文明細行の参照の詳細を 2 つの列に格納する Sales という名前のソース テーブルについて考えてみます。

Sales の逆ディメンション テーブルのテーブル行を示す図。設計については、次の段落で説明します。

OrderNumber 列には注文番号が格納され、OrderLineNumber 列には注文内の一連の行が格納されます。

次の図では、注文番号と注文明細行番号の列が Sales テーブルに読み込まれていないことに注意してください。 代わりに、その値を使用して、OrderLineNumberIDという名前の サロゲート キー 列を作成しました。 (このキーの値は、注文番号を 1000 で乗算した後、注文明細行番号を加算することによって計算されます。)

Sales と Sales Order の 2 つのテーブルを示す図。1 対 1 のリレーションシップは、Order Line Number ID 列を関連付けます。

Sales Order ディメンション テーブルは、Sales Order と Sales Order Lineの 2 つの列を持つレポート作成者向けの豊富なエクスペリエンスを提供します。 これらの特定の列は、注文と注文明細行をフィルター処理、グループ化、またはドリルダウンする必要があるレポート デザインをサポートします。

Sales Order テーブルは売上データから派生しているため、各テーブルにまったく同じ数の行が存在する必要があります。 さらに、各 OrderLineNumberID 列の間に一致する値が存在する必要があります。

行データが複数のテーブルにまたがる

2 つの一対一の関連ディメンション テーブル (Product と Product Category) を含む例を考えてみましょう。 各テーブルはインポートされたデータを表し、一意の値を含む SKU (在庫保管単位) 列を持ちます。

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

行データが複数のテーブルにまたがる 2 つのテーブルを含むモデルを示す図。設計については、次の段落で説明します。

最初のテーブルは Productという名前で、Color、Product、および SKUの 3 つの列が含まれています。 2 番目のテーブルは Product Categoryという名前で、Category と SKUの 2 つの列が含まれています。 1 対 1 のリレーションシップは、2 つの SKU 列を関連付けます。 このリレーションシップは両方向にフィルター処理されます。これは常に一対一のリレーションシップに当てはまります。

リレーションシップ フィルターの伝達のしくみを説明するために、次の図ではいくつかのテーブル行が表示されています。 この記事に含まれるすべての例は、このデータに基づいています。

Product テーブルと Product Category テーブルと一部のデータ行を示す図。行の詳細については、次の段落で説明します。

2 つのテーブルの行の詳細については、次の箇条書きで説明します。

  • Product テーブルには、次の 3 つの行があります。
    • SKUCL-01、 ProductTシャツ、 Colorグリーン
    • SKUCL-02、 Productジーンズ、 Colorブルー
    • SKU AC-01、Product帽子、Color青
  • Product Category テーブルには、次の 2 つの行があります。
    • SKU CL-01、Category衣類
    • SKUAC-01、 Categoryアクセサリ

テーブルには、CL-02製品 SKU の行が含まれていないことに注意してください。 この不足している行がもたらす結果については、この記事の後半で説明します。

データ ペインで、レポート作成者は、Product と Product Categoryの 2 つのテーブルで製品関連のフィールドを検索します。 両方のテーブルのフィールドをテーブル ビジュアルに追加するとどうなるかを見てみましょう。 この例では、SKU 列は Product テーブルから取得されます。

2 つのテーブルを含むデータ ペインと、4 つの列を含むテーブル ビジュアルを示す図。製品 SKU CL-02 のカテゴリ値は空白です。

CL-02 製品 SKU の 値が空白であることに注意してください。 これは、この製品の Product Category テーブルに対応する行がないためです。

推奨事項

可能であれば、行データがモデル テーブル間にまたがる場合は一対一のモデル リレーションシップを作成しないようにすることをお勧めします。 これは、この設計で次のことが可能になるためです。

  • 必要以上のテーブルが一覧表示されており、[データ] ペインが煩雑になる。
  • 関連フィールドが複数のテーブルに分散しているため、レポート作成者がそれらを見つけにくい。
  • 階層のレベルは同じテーブルの列に基づいている必要があるので、階層を作成する機能を制限します。
  • テーブル間で完全に一致する行が存在しない場合に、予期しない結果が生成される。

具体的な推奨事項は、一対一のリレーションシップが "ソース グループ内" であるか、または "ソース グループ間" であるかによって異なります。 リレーションシップの評価の詳細については、「Power BI Desktopでのモデルリレーションシップ」を参照してください。

ソース グループ内の一対一のリレーションシップ

テーブル間に一対一の "ソース グループ内" のリレーションシップが存在する場合は、データを 1 つのモデル テーブルに統合することをお勧めします。 これを行うには、Power Query クエリをマージします。

次の手順では、1 対 1 の関連データを統合してモデル化する方法を示します。

  1. クエリをマージする:2 つのクエリを組み合わせる場合は、各クエリのデータの完全性を考慮してください。 1 つのクエリに行の完全なセット (マスター リストなど) が含まれている場合は、もう 1 つのクエリをそれとマージします。 既定の結合の種類である左外部結合使用するようにマージ変換を設定します。 この結合の種類を使用すると、最初のクエリの行がすべて維持され、2 番目のクエリの一致する行でそれらが補完されます。 2 番目のクエリの必要なすべての列を、最初のクエリに展開します。

    1 つの Product ディメンション テーブルに統合されたデータを示す図。

  2. クエリの読み込みの無効化:必ず 2 番目のクエリの読み込みの無効化を行います。 これにより、その結果がモデル テーブルとして読み込まれなくなります。 この構成により、データ モデルのストレージ サイズが削減され、[データ] ペインの煩雑さを減らすことができます。

    この例では、レポート作成者が Product という名前の 1 つのテーブルを Data ペインに見つけるようになりました。 これには、すべての製品関連フィールドが含まれます。

  3. 欠損値を置換する: 2 番目のクエリに一致しない行がある場合は、そこから導入された列に null 値が表示されます。 必要に応じて、NULL をトークン値に置き換えることを検討してください。 欠損値の置換は、レポート作成者が列の値でフィルター処理またはグループ化を行う場合に特に重要になります。レポートのビジュアルに空白が表示される可能性があるためです。

    次の画像で、製品 SKU CL-02 のカテゴリが現在 [未定義]と表示されていることに注意してください。 このクエリでは、null カテゴリがこのトークン テキスト値に置き換えられました。

    Product テーブルの [データ] ペインを示す図。また、4 つの列を含むテーブル ビジュアルも表示されます。製品 SKU CL-02 のカテゴリ値に Undefined というラベルが付けられます。

  4. 階層の作成:統合したテーブルの "列間に" リレーションシップが存在する場合は、階層の作成を検討してください。 これにより、レポート作成者が、レポートのビジュアルをドリルダウンする機会をすばやく特定できます。

    この例では、レポート作成者は、Category と Productの 2 つのレベルを持つ階層を使用できるようになりました。

    データ ペインを示す図。Product テーブルには、Products 階層が含まれています。

テーブルを分離することがフィールドの整理に役立つ場合でも、やはり 1 つのテーブルに統合することをお勧めします。 代わりに "表示フォルダー" を使用することで、引き続きフィールドを整理することができます。

この例では、レポート作成者は、Marketing 表示フォルダー内の Category フィールドを見つけることができます。

カテゴリ フィールドが Marketing という名前の表示フォルダー内にある [データ] ペインを示す図。

引き続きモデル内で一対一のソース グループ内のリレーションシップを定義する必要がある場合は、可能であれば、関連テーブルに一致する行が存在していることを確認してください。 一対一のソース グループ内のリレーションシップは標準リレーションシップとして評価されるため、レポートのビジュアルにおいて、データ整合性の問題が空白として発生する可能性があります。 (この記事に記載されている最初のテーブル ビジュアルでは、空白のグループ化の例を確認できます。)

ソース グループ間の一対一のリレーションシップ

テーブル間に 1 対 1 の クロス ソース グループ リレーションシップが存在する場合、データ ソース内のデータを事前に統合しない限り、代替モデル設計はありません。 Power BI によって、一対一のモデル リレーションシップは制限付きリレーションシップとして評価されます。 そのため、一致しない行がクエリ結果から除外されるため、関連するテーブルに一致する行があることを確認してください。

一対一リレーションシップを示すクロス ソース グループのリレーションシップを示す図。これは限られたリレーションシップです。

両方のテーブルのフィールドをテーブル ビジュアルに追加するときに、テーブル間に制限付きリレーションシップが存在するとどうなるかを見てみましょう。

次の段落で説明する 2 つのテーブル ビジュアルを示す図。

ソース間グループ リレーションシップを使用する最初のテーブル ビジュアルには、2 つの行のみが表示されます。 cl-02 製品 SKU は、 テーブルに一致する行がないため、不足しています。 2 番目のテーブル ビジュアルは、モデル内の単一の統合テーブルに基づいて、3 つの行を表示します。

関連するコンテンツ

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