次の方法で共有

スター スキーマと Power BI での重要性を理解する

  • [アーティクル]

この記事は、Power BI Desktop データ モデラーを対象としています。 スター スキーマの設計と、パフォーマンスと使いやすさのために最適化された Power BI セマンティック モデルの開発との関連性について説明します。

重要

Power BI セマンティック モデルは、データをインポートまたは接続する Power Query に依存します。 つまり、 Power Query を使用してソース データを変換および準備する必要があります。これは、大量のデータがある場合や、緩やかに変化するディメンションなどの高度な概念を実装する必要がある場合に困難になる可能性があります (この記事では later を参照)。

これらの課題が提示されたら、データ ウェアハウスを定期的に読み込むデータ ウェアハウスと抽出、変換、読み込み (ETL) プロセスを最初に開発することをお勧めします。 その後、セマンティック モデルをデータ ウェアハウスに接続できます。 詳細については、「 Microsoft Fabric Warehouse でのDimensional モデリング」を参照してください。

ヒント

この記事は、スター スキーマの設計に関する完全な説明を提供するためのものではありません。 詳細については、Ralph Kimball その他による「The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (2013 年第 3 版)」など、広く採用されている公開コンテンツを直接参照してください。

スター スキーマの概要

スター スキーマは、リレーショナル データ ウェアハウスで広く採用されている成熟したモデリング手法です。 モデラーは、モデル テーブルを "ディメンション" または "ファクト" として分類する必要があります。

  • ディメンション テーブルでは、ビジネス エンティティ (モデル化の "対象") について説明します。 エンティティには、時間自体を含め、製品、人、場所および概念を含めることができます。 スター スキーマに存在する最も一貫性のあるテーブルは、日付ディメンション テーブルです。 ディメンション テーブルには、一意の識別子として機能するキー列 (または列) とその他の列が含まれています。 その他の列では、データのフィルター処理とグループ化がサポートされています。
  • ファクト テーブル 観測値やイベントを格納し、販売注文、在庫残高、為替レート、温度などを格納できます。 ファクト テーブルには、分析コード テーブルに関連する分析コード キー列と数値メジャー列が含まれます。 ディメンション キー列によってファクト テーブルの "次元" が決まり、ディメンション キーの値によってファクト テーブルの "粒度" が決まります。 たとえば、 Date と ProductKeyの 2 つのディメンション キー列を持つ販売目標を格納するように設計されたファクト テーブルを考えてみましょう。 このテーブルに 2 つのディメンションがあることは簡単に理解できます。 しかし、粒度は、ディメンション キーの値を考慮せずに決定することはできません。 この例では、 Date 列に格納されている値が各月の最初の日であるとします。 この場合、粒度は月単位の製品レベルとなります。

一般に、ディメンション テーブルには比較的少数の行が含まれます。 一方、ファクト テーブルには多数の行を含め、時間の経過と同時に拡大し続けることができます。

スター スキーマの図を示す図。

正規化と非正規化

この記事で説明するスター スキーマのいくつかの概念を理解するには、正規化と非正規化という 2 つの用語を理解することが重要です。

"正規化" とは、同じデータの繰り返しが減る方法で格納されたデータを記述するために使用される用語です。 プロダクト キーなどの一意のキー値列を持つ製品のテーブルと、製品名、カテゴリ、色、サイズなど、製品の特性を記述するその他の列について考えてみましょう。 販売テーブルは、製品キーのようなキーのみが格納されている場合、正規化されていると見なされます。 次の図では、 ProductKey 列のみが製品を記録していることに注意してください。

プロダクト キー列を含むデータのテーブルを示す図。

一方、キー以外の製品の詳細が販売テーブルに格納されている場合は、"非正規化されている" ものと見なされます。 次の図では、 ProductKey およびその他の製品関連の列に製品が記録されていることに注意してください。

プロダクト キーとその他の製品関連の列 (カテゴリ、色、サイズなど) を含むデータのテーブルを示す図。

エクスポート ファイルまたはデータの抽出からのデータをソースにする場合は、非正規化されたデータ セットを表している可能性があります。 この場合は、Power Query を使って、ソース データを変換して複数の正規化されたテーブルに整形します。

この記事で説明されているように、正規化されたファクトデータとディメンション データを表すテーブルを使用して、最適化された Power BI セマンティック モデルの開発に努める必要があります。 ただし、1 つのモデル テーブルを生成するために、 snowflake ディメンション が非正規化される場合がある例外が 1 つあります。

Power BI セマンティック モデルに関連するスター スキーマ

この記事で紹介するスター スキーマの設計と関連する多くの概念は、パフォーマンスと使いやすさのために最適化された Power BI モデルの開発と非常に関連性があります。

各 Power BI レポート ビジュアルで、Power BI セマンティック モデルに送信されるクエリが生成されることを検討してください。 一般に、クエリはモデル データをフィルター処理、グループ化、集計します。 適切に設計されたモデルは、フィルター処理とグループ化用のテーブルと、集計用のテーブルを提供するモデルです。 この設計は、スター スキーマの原則に十分適しています。

  • ディメンション テーブルを使用すると、 フィルター処理 および グループ化。
  • ファクト テーブルでは、 ummarization を有効にします。

modeler がテーブルの種類をディメンションまたはファクトとして設定するように設定するテーブル プロパティはありません。 実際には、 モデルのリレーションシップによって決まります。 モデル リレーションシップは、2 つのテーブル間にフィルター伝達パスを確立し、テーブルの種類を決定するリレーションシップのカーディナリティ プロパティです。 一般的なリレーションシップのカーディナリティは、"一対多" またはその逆の "多対一" です。 "一" 側は常にディメンション テーブルですが、"多" 側は常にファクト テーブルです。

スター スキーマの概念図を示す図。

適切に構造化されたモデル設計には、ディメンション テーブルまたはファクト テーブルであるテーブルが含まれます。 単一のテーブルに 2 つの種類を混在させないようにしてください。 また、適切なリレーションシップが設定された適切な数のテーブルを提供するよう努力することもお勧めします。 また、ファクト テーブルでは常に一貫性のあるグレインでデータが読み込まれることも重要です。

最後に、最適なモデル設計は科学と芸術にまたがっていることを理解することが重要です。 場合によっては、そうすることが妥当な場合、適切なガイダンスを守らないこともあります。

Power BI セマンティック モデルに適用できるスター スキーマ設計に関連する多くの概念があります。 たとえば、次のような概念です。

メジャー

スター スキーマの設計では、メジャーは集計する値を格納するファクト テーブルの列です。 Power BI セマンティック モデルでは、メジャーの定義は異なりますが、似ています。 モデルでは、明示的なメジャーと暗黙的なメジャーの両方がサポートされます。

  • 明示的なメジャー は明示的に作成され、集計を実現する Data Analysis Expressions (DAX) で記述された数式に基づいています。 メジャー式では、多くの場合、 SUM、 MIN、 MAX、 AVERAGEなどの DAX 集計関数を使用して、クエリ時にスカラー値の結果を生成します (値はモデルに格納されません)。 メジャー式には、シンプルな列集計から、フィルター コンテキストやリレーションシップの伝達をオーバーライドする、より高度な数式までさまざまなものがあります。 詳細については、Power BI Desktop の DAX の基本を参照してください。
  • 暗黙的なメジャー は、レポートビジュアルまたは Q&Aで集計できる列です。 多くの場合、メジャーを作成する必要がない (明示的な) 場合と同様に、モデル開発者にとって便利です。 たとえば、Adventure Works リセラーの売上 Sales Amount 列は、可能な集計の種類ごとにメジャーを作成しなくても、さまざまな方法 (合計、カウント、平均、中央値、最小、最大など) で集計できます。

Data ペインでは、明示的なメジャーは電卓アイコンで表され、暗黙的なメジャーはシグマ記号 (∑) で表されます。

[データ] ペインにあるアイコンを示す図。

ただし、単純な列レベルの要約であっても、メジャーを作成する理由は 3 つあります。

  • レポート作成者が 多次元式 (MDX) を使用してセマンティック モデルにクエリを実行することがわかっている場合、モデルには明示的なメジャーが含まれている必要があります。 これは、MDX では列値の要約を実現できないためです。 特に、MDX は Excel で Analyze を実行するときに使用されます ピボットテーブルは MDX クエリを発行するためです。

  • レポート作成者が MDX クエリ デザイナーを使用して Power BI のページ分割されたレポートを作成することがわかっている場合は、セマンティック モデルに明示的なメジャーを含める必要があります。 サーバー集計をサポートするのは、MDX クエリ デザイナーのみです。 そのため、レポート作成者が (ページ分割されたレポート エンジンではなく) Power BI によって評価されるメジャーが必要な場合には、MDX クエリ デザイナーを使用する必要があります。

  • レポート作成者が特定の方法で列を集計する方法を制御する場合。 たとえば、リセラーの売上 Unit Price 列 (単位単価を表します) は、特定の集計関数を使用してのみ集計できます。 合計するべきではありませんが、min、max、average などの他の集計関数を使用して集計するのが適切です。 この場合、modeler は Unit Price 列を非表示にし、すべての適切な集計関数のメジャーを作成できます。

    この設計手法は、Power BI サービスで作成されたレポートと、Q&A に適しています。 ただし、Power BI Desktop live 接続では レポート作成者が Data ペインに非表示フィールドを表示できるため、この設計アプローチが回避される可能性があります。

代理キー

代理キーは、スター スキーマ モデリングをサポートするためにテーブルに追加する一意の識別子です。 定義上、ソース データに定義されたり、格納されたりすることはありません。 通常、代理キーは、ディメンション テーブルの各行に一意の識別子を提供するために、リレーショナル データ ウェアハウスのディメンション テーブルに追加されます。

Power BI セマンティック モデルのリレーションシップは、1 つのテーブル内の 1 つの一意の列に基づいており、フィルターは別のテーブルの 1 つの列に反映されます。 セマンティック モデルのディメンション テーブルに 1 つの一意の列が含まれていない場合は、リレーションシップの "一" 側になるように一意の識別子を追加する必要があります。 Power BI Desktop では、Power Query index 列を追加することで、この要件を満たすことができます。

Power Query エディターの [インデックス列の作成] コマンドを示す図。

インデックス列も追加できるように、このクエリを "多" 側のクエリと結合する必要があります。 これらのクエリをセマンティック モデルに読み込むと、モデル テーブル間に一対多リレーションシップを作成できます。

スノーフレーク ディメンション

スノーフレーク ディメンションは、単一のビジネス エンティティの正規化されたテーブルのセットです。 たとえば、Adventure Works では、商品がカテゴリとサブカテゴリ別に分類されます。 製品がサブカテゴリに割り当てられ、その後、サブカテゴリがカテゴリに割り当てられます。 Adventure Works リレーショナル データ ウェアハウスでは、製品ディメンションは正規化され、 DimProductCategory、 DimProductSubcategory、 DimProductの 3 つの関連テーブルに格納されます。

3つの関連テーブルを含むスノーフレーク図の一例を示す図。

想像力を働かせれば、スノーフレーク設計を形成する、ファクト テーブルから外に向けて配置された正規化テーブルを思い描くことができます。

3 つの関連テーブルを含むスノーフレーク図の概念例を示す図。

Power BI Desktop では、スノーフレーク ディメンションデザインを模倣するか (ソース データが行うためなど)、ソース テーブルを組み合わせて単一の非正規化モデル テーブルを形成することもできます。 一般に、単一のモデル テーブルの利点は、複数のモデル テーブルの利点を上回ります。 最適な決定は、データの量とモデルの使いやすさの要件によって異なる場合があります。

スノーフレーク ディメンションの設計を模倣するように選択した場合:

  • Power BI によってより多くのテーブルが読み込まれるため、ストレージとパフォーマンスの観点からは効率が悪くなります。 これらのテーブルには、モデルのリレーションシップをサポートするための列を含める必要があります。これにより、モデルのサイズがより大きくなる可能性があります。
  • リレーションシップ フィルター伝達チェーンを長く走査する必要があります。これは、1 つのテーブルに適用されるフィルターよりも効率が低い場合があります。
  • Data ペインには、作成者に対してより多くのモデル テーブルが表示されるため、特に snowflake ディメンション テーブルに 1 つまたは 2 つの列のみが含まれている場合は、直感的に操作できなくなる可能性があります。
  • 複数のテーブルの列を構成する階層を作成することはできません。

単一のモデル テーブルに統合するように選択した場合は、ディメンションの粒度が最も高いものと低いものを含む階層を定義することもできます。 場合によっては、冗長な非正規化データを格納すると、特に大きなディメンション テーブルの場合に、モデルのストレージ サイズが増加する可能性があります。

Category、Subcategory、Product などの列を含むディメンション テーブル内の階層の例を示す図。

緩やかに変化するディメンション

大幅に変化するディメンション (SCD) は、ディメンション メンバーの変更を時間の経過と同時に適切に管理するものです。 これは、ビジネス エンティティの値が計画外の方法で時間の経過と 低い に変化する場合に適用されます。 SCD の良い例として、顧客ディメンションがあります。これは、メール アドレスや電話番号などの連絡先の詳細列が変更される頻度が低いためです。 これに対し、一部のディメンションは と見なされ 株式の市場価格のようにディメンション属性が頻繁に変更されたときに変化します。 このような場合の一般的な設計手法は、急速に変化する属性値をファクト テーブル メジャーに格納することです。

スター スキーマの設計理論では、次の 2 つの一般的な SCD の種類を参照します: 種類 1 と種類 2。 ディメンション テーブルには、種類 1 または種類 2 を指定することも、異なる列に対して両方の型を同時にサポートすることもできます。

種類 1 の SCD

タイプ 1 の SCD では常に最新の値が反映され、ソース データの変更が検出されると、ディメンション テーブルのデータが上書きされます。 この設計手法は、顧客の電子メール アドレスや電話番号などの補足値を格納する列では一般的なものです。 顧客の電子メール アドレスまたは電話番号が変更されると、ディメンション テーブルで顧客の行が新しい値で更新されます。 顧客が常にこの連絡先情報を持っているかのように見えます。

従業員の電話番号が更新される緩やかに変化するディメンション タイプ 1 の例を示す図。

Power BI モデル ディメンション テーブルの非増分更新では、Type 1 SCD の結果が得られます。 テーブル データを更新し、確実に最新の値が読み込まれるようにします。

種類 2 の SCD

タイプ 2 の SCD は、ディメンション メンバーのバージョン管理をサポートしています。 ソース システムがバージョンを格納しない場合、通常は、変更を検出し、ディメンション テーブルの変更を適切に管理するデータ ウェアハウスの読み込みプロセスです。 この場合、ディメンション テーブルでは、ディメンション メンバーの "バージョン" への一意の参照を提供するために、代理キーを使用する必要があります。 また、バージョンの有効期間の日付範囲 (StartDate や EndDate など) を定義する列と、場合によってはフラグ列 (IsCurrent など) が含まれます。これらは、現在のディメンション メンバーで簡単にフィルター処理するためのものです。

たとえば、Adventure Works では、すべての営業担当者が販売地域に割り当てられます。 販売員が地域を再配置した場合、新しいバージョンの販売員を作成し、履歴ファクトを元の地域に関連付けたままにする必要があります。 販売員ごとの売上の正確な履歴分析をサポートするには、ディメンション テーブルに販売員のバージョンと、それらに関連付けられている地域 (複数可) を格納する必要があります。 テーブルには、有効期間を定義するための開始日と終了日の値も含まれている必要があります。 現在のバージョンでは、行が現在のバージョンであることを示す空の終了日 (または 12/31/9999) が定義されている場合があります。 ビジネス キー (このインスタンスでは従業員 ID) が一意ではないためテーブルには surrogate キーも必要です。

緩やかに変化するディメンション タイプ 2 の例を示す図。従業員の販売地域が新しいバージョンを作成して更新されます。

ソース データにバージョンが格納されていない場合は、中間システム (データ ウェアハウスなど) を使用して変更を検出し、格納する必要があることを理解しておくことが重要です。 テーブルの読み込みプロセスでは、既存のデータを保持し、変更を検出する必要があります。 変更が検出された場合、テーブルの読み込みプロセスで現在のバージョンを期限切れにする必要があります。 EndDate 値を更新し、前の EndDate 値から始まる StartDate 値を使用して新しいバージョンを挿入することで、これらの変更が記録されます。 また、関連するファクトでは、時間ベースの参照を使用して、ファクトの日付に関連するディメンション キー値を取得する必要があります。 Power BI セマンティック モデルでは Power Query を使用するため、この結果を生成できません。 しかし、事前に読み込まれた SCD の種類 2 のディメンション テーブルからデータを読み込むことはできます。

ヒント

Fabric ウェアハウスに Type 2 SCD ディメンション テーブルを実装する方法については、「 変更履歴の管理を参照してください。

Power BI セマンティック モデルでは、変更に関係なく、メンバーの履歴データと、メンバーの特定の状態を表すバージョンのメンバーに対するクエリをサポートする必要があります。 この設計では、Adventure Works のコンテキストで、割り当てられた販売地域に関係なく、販売員、または販売員の特定のバージョンに対してクエリを実行できます。

この要件を達成するには、Power BI セマンティック モデル ディメンション テーブルに、営業担当者をフィルター処理するための列と、特定のバージョンの販売員をフィルター処理するための別の列を含める必要があります。 バージョン列には、 David Campbell (12/15/2008-06/26/2019) や David Campbell (06/27/2019-Current)など、あいまいでない説明が用意されている必要があります。 また、レポートの作成者やコンシューマーに SCD 種類 2 の基本と、正しいフィルターを適用して適切なレポート設計を実現する方法について教えることが重要です。

ビジュアルをバージョン レベルにドリルダウンできる階層を含めるのは、設計上の良い方法です。

Salesperson と Salesperson Version の列を含む [データ] ペインを示す図。

多様ディメンション

多様ディメンションは、関連するファクトを異なる方法でフィルター処理できるディメンションです。 たとえば、Adventure Works では、日付ディメンション テーブルはリセラーの売上ファクトと 3 つのリレーションシップを持ちます。 同じディメンション テーブルを使用して、注文日、出荷日、または納品日でファクトをフィルター処理することができます。

1 つのロールプレイング ディメンションとリレーションシップの概念的な例を示す図。Date テーブルには、注文日と出荷日のファクト テーブルとの 2 つのリレーションシップがあります。

データ ウェアハウスで、受け入れられる設計手法は、単一の日付ディメンション テーブルを定義することです。 クエリ時には、日付ディメンションの "ロール" が、テーブルの結合に使用するファクト列によって確立されます。 たとえば、注文日別に売上を分析する場合、テーブルの結合は再販業者の販売注文日列に関連します。

Power BI セマンティック モデルでは、2 つのテーブル間に複数のリレーションシップを作成することで、この設計を模倣できます。 Adventure Works の例では、日付および再販業者の販売テーブルに 3 つのリレーションシップがあります。

1 つのロールプレイング ディメンションとリレーションシップの例を示す図。Date テーブルには、ファクト テーブルとのリレーションシップが 3 つ含まれます。

この設計は可能ですが、2 つの Power BI セマンティック モデル テーブル間に アクティブ リレーションシップは 1 つだけ存在できます。 残りのすべてのリレーションシップは非アクティブに設定する必要があります。 アクティブなリレーションシップが 1 つあるということは、日付からリセラーの売上への既定のフィルター伝達があることを意味します。 この場合、アクティブなリレーションシップは、レポートで使用される最も一般的なフィルターに設定されます。Adventure Works では、注文日のリレーションシップです。

非アクティブなリレーションシップを使用する唯一の方法は、USERELATIONSHIP 関数を使用する DAX 式を定義することです。 この例では、モデル開発者は、出荷日と納品日で再販業者の販売を分析できるようにするためのメジャーを作成する必要があります。 この作業は、特に再販業者テーブルで多くのメジャーが定義されているときに、面倒な場合があります。 また、 Data ペインが作成され、メジャーが過剰に存在します。 他にも制限があります。

  • レポート作成者がメジャーを定義するのではなく、列の集計に依存している場合、レポート レベルのメジャーを記述しないと、非アクティブなリレーションシップの集計を実現できません。 レポートレベルのメジャーは、Power BI Desktop でレポートを作成する場合にのみ定義できます。
  • 日付と再販業者の販売の間のアクティブなリレーションシップ パスが 1 つのみである場合、異なる種類の日付で再販業者の販売を同時にフィルター処理することはできません。 たとえば、出荷済みの販売別に注文日の販売をプロットするビジュアルを生成することはできません。

これらの制限を克服するために、一般的な Power BI モデリング手法は、ロールプレイング インスタンスごとにディメンション テーブルを作成することです。 各ディメンション テーブルは、power Query を使用して参照クエリとして、または DAX を使用して計算されたテーブルとして作成できます。 モデルには、 Date テーブル、 Ship Date テーブル、および Delivery Date テーブルを含めることができます。各テーブルには、それぞれのリセラー販売テーブル列との 1 つのアクティブなリレーションシップがあります。

ロールプレイング ディメンションとリレーションシップの例を示す図。ファクト テーブルに関連する 3 つの異なる日付ディメンション テーブルがあります。

この設計手法では、異なる日付ロールに対して複数のメジャーを定義する必要はなく、異なる日付ロールで同時にフィルター処理を行うことができます。 ただし、この設計アプローチで支払う小さな価格は、日付ディメンション テーブルの重複が発生し、モデルのストレージ サイズが増加するという点です。 通常、ディメンション テーブルにはファクト テーブルに対して相対的に格納される行数が少ないため、問題になることはほとんどありません。

各ロールのモデル ディメンション テーブルを作成するときは、適切な設計プラクティスに従うことをお勧めします。

  • 列名が自己記述型であることを確認します。 すべての日付テーブルに Year 列を持つことは可能ですが (列名はテーブル内で一意です)、既定のビジュアル タイトルでは自己記述できません。 Ship Date テーブルに Ship Year という名前の年の列が含まれるように、各ディメンション ロール テーブルの列の名前を変更することを検討してください。
  • 関連する場合は、フィルター伝達の設定方法に関するレポート作成者 ( Data ペインのヒントを使用して) テーブルの説明がフィードバックを提供していることを確認します。 この明確さは、多くのファクト テーブルをフィルター処理するために使用される Dateなど、一般的な名前のテーブルがモデルに含まれている場合に重要です。 このテーブルにリセラー販売注文日列とのアクティブなリレーションシップがある場合は、 Filters reseller sales by order dateなどのテーブルの説明を指定することを検討してください。

詳細については、「アクティブなリレーションシップと非アクティブなリレーションシップのガイダンス」をご覧ください。

ジャンク ディメンション

ジャンク ディメンションは、特に少数の属性 (おそらく 1 つ) で構成されているディメンションが多数存在し、これらの属性の値が少ない場合に便利です。 適切な候補には、注文状態列や、性別や年齢グループなどの顧客の人口統計列が含まれます。

迷惑ディメンションの設計目標は、多数の small ディメンションを 1 つのディメンションに統合して、モデルのストレージ サイズを小さくし、さらに少ないモデル テーブルを表示して Data ウィンドウの乱雑さを減らすことです。

迷惑ディメンション テーブルは、通常、すべてのディメンション属性メンバーのデカルト積であり、各行を一意に識別するための surrogate キー 列があります。 データ ウェアハウスでディメンションを構築することができます。あるいは、完全外部クエリ結合を実行してから、代理キー (インデックス列) を追加するクエリを作成するための Power Query を使用することもできます。

迷惑ディメンション テーブルの例を示す図。注文ステータスには 3 つの状態があり、配信ステータスには 2 つの状態があります。迷惑ディメンション テーブルには、2 つの状態の 6 つの組み合わせがすべて格納されます。

このクエリは、ディメンション テーブルとしてモデルに読み込みます。 また、"一対多" モデルリレーションシップの作成をサポートするために、インデックス列がモデルに読み込まれるように、このクエリをファクト クエリとマージする必要があります。

逆ディメンション

生成ディメンションは、フィルター処理に必要なファクト テーブルの属性を参照します。 Adventure Works の再販業者の販売注文番号が良い例です。 この例では、この 1 つの列だけで構成される独立したテーブルを作成しても意味がありません。これは、モデルのストレージ サイズが大きくなり、 Data ペインが乱雑になるためです。

Power BI セマンティック モデルでは、販売注文番号の列をファクト テーブルに追加して、販売注文番号によるフィルター処理またはグループ化を可能にすることが適切な場合があります。 以前に導入されたルールでは、テーブルの種類を混在させるべきではありません (一般に、モデル テーブルはディメンションまたはファクトである必要があります)。

[受注番号] フィールドを含むデータ ペインと販売ファクト テーブルを示す図。

ただし、Adventure Works リセラーの販売テーブルに注文番号 と 注文明細行番号の列があり、フィルター処理に必要な場合は、退化ディメンション テーブルを作成することをお勧めします。 詳細については、一対一のリレーションシップのガイダンス (逆ディメンション) に関する記事をご覧ください。

ファクトレス ファクト テーブル

ファクトレス ファクト テーブルには、メジャー列は含まれません。 ディメンション キーのみが含まれます。

ファクトレス ファクト テーブルには、ディメンション キーによって定義された観測値を格納できます。 たとえば、特定の日時に、特定の顧客が Web サイトにサインインしたとします。 ファクトレス ファクト テーブルの行をカウントするメジャーを定義して、サインインしたタイミングと顧客数の分析を実行できます。

ファクトレスファクト テーブルのより説得力のある用途は、ディメンション間のリレーションシップを格納することです。これは、多対多ディメンションリレーションシップを定義するために推奨される Power BI セマンティック モデル設計アプローチです。 多対多ディメンション リレーションシップの設計では、ファクトレス ファクト テーブルは "ブリッジング テーブル" と呼ばれます。

たとえば、販売者を 1 つまたは複数の販売地域に割り当てることができるとします。 ブリッジング テーブルは、販売員キーと地域キーという 2 つの列で構成されるファクトレス ファクト テーブルとして設計されます。 両方の列に重複する値を格納できます。

Salesperson ディメンションと Region ディメンションをブリッジするファクトレスファクト テーブルを示す図。ファクトレス ファクト テーブルは、ディメンション キーである 2 つの列で構成されます。

この多対多の設計手法は十分に立証されており、ブリッジング テーブルがなくても実現できます。 しかし、2 つのディメンションを関連付ける場合は、ブリッジング テーブル手法がベスト プラクティスと見なされます。 詳細については、多対多のリレーションシップのガイダンス (2 つのディメンションの種類のテーブルを関連付ける) に関する記事をご覧ください。

関連するコンテンツ

スター スキーマの設計または Power BI セマンティック モデルの設計の詳細については、次の記事を参照してください。