セマンティック モデルのスター スキーマを設計する

  • 7 分

データがセマンティック モデルに流れ込む方法を選択しました。 次に、明確でパフォーマンスの高いクエリ用にスター スキーマを整理する設計を行います。 スター スキーマは、リレーションシップを介してファクト テーブルをディメンション テーブルに接続し、レポートと AI の使用に依存するフィルター パスを作成します。 Power BI Desktop でのスター スキーマの構築に慣れている場合、このユニットでは、モデルの複雑さとスケールの拡大に伴う関係設計の決定に焦点を当てます。

セマンティック モデルのスター スキーマ

スター スキーマでは、ファクト テーブルには測定可能なビジネス イベント (販売トランザクション、注文明細行、Web 訪問など) が格納され、ディメンション テーブルは説明的なコンテキスト (製品の詳細、顧客情報、日付属性など) を提供します。 ディメンション テーブルでは、リレーションシップを使用してファクト テーブルをフィルター処理します。これにより、ユーザーは任意の記述属性でメトリックをスライスできます。

中央のファクト テーブルと、星状の図形で編成されたリレーションシップによって接続された複数のディメンション テーブルを示す図。

Fabricセマンティック モデルでは、このパターンはレポートと AI 消費量の両方に対してクリーン なフィルター伝達を提供します。 Copilotまたはデータ エージェントが自然言語クエリを生成すると、適切なスター スキーマが AI に適切なデータへの明確なパスを提供します。 あいまいなリレーションシップまたは循環リレーションシップは、レポート コンシューマーと AI ツールの両方を混乱させます。

ストレージ モードがリレーションシップに与える影響

セマンティック モデルのリレーションシップの動作は、ストレージ モードによって異なります。 これらの違いを理解することは、さまざまなシナリオで優れたパフォーマンスを発揮するスター スキーマを設計するために不可欠です。

Direct Lake リレーションシップ

Direct Lake モードでは、エンジンは Delta テーブルメタデータから直接リレーションシップを読み取ります。 リレーションシップは、次の場合に最適に動作します。

  • ディメンション キー列のカーディナリティは、ファクト テーブルの行に比べて低いです。
  • 参照整合性はソース データで維持されます。 参照整合性が保持されている場合、エンジンは LEFT OUTER 結合の代わりに INNER 結合を使用するため、クエリのパフォーマンスが向上します。
  • リレーションシップで使用される列は、基になる Delta テーブルでインデックスが作成されます。

Note

モデルがメモリ制限を超えたり、サポートされていない操作を使用したりするリレーションシップがクエリに含まれている場合、Direct Lake は DirectQuery にフォールバックし、DirectQuery セマンティクスに合わせてリレーションシップの動作が変更されます。

ソース間のリレーションシップ

Fabricセマンティック モデルでは、さまざまなデータ ストアのテーブルを接続できます。 レイクハウスのファクト テーブルには、ウェアハウスのディメンション テーブルまたは SQL 分析エンドポイントを介してアクセスされるテーブルとのリレーションシップを持つことができます。 これらのソース間接続では、複合モデル機能が使用されます。

テーブルが異なるソースから取得された場合、各テーブルのストレージ モードによって、クエリ時のリレーションシップのしくみが決まります。 エンジンはそれぞれの側を個別に解決し、結果を結合します。

関係タイプ

一対多のリレーションシップ

一対多は、スター スキーマで最も一般的なリレーションシップ型です。 ディメンション テーブル内の 1 つの一意の値は、ファクト テーブル内の多数の行に関連しています。 たとえば、Product ディメンションの 1 つの製品行は、Sales ファクト テーブル内の何千もの注文行と一致します。

ディメンション ("一" 側) からファクト テーブル ("多" 側) に流れるフィルターの方向を使用して、一対多リレーションシップを構成します。 これは、標準のスター スキーマ フィルター パターンです。

多対多のリレーションシップ

リレーションシップ列に一意の値を持つテーブルが存在しない場合は、多対多リレーションシップが必要です。 これらのリレーションシップを解決するには、ブリッジ テーブルを使用します。 ブリッジ テーブルは 2 つのテーブルの間にあり、各側のキーの一意の組み合わせを保持します。

たとえば、顧客が複数のアカウントを持つ可能性があり、1 つのアカウントが複数の顧客に属できる場合、Customer-Account ブリッジ テーブルによってリレーションシップが解決されます。 ブリッジ テーブルには、Customer テーブルと Account テーブルの両方との一対多リレーションシップがあります。

フィルターの方向

ほとんどのスター スキーマ実装では、ディメンションからファクトへの単一方向のフィルター処理を使用します。 これにより、予測可能なフィルター伝達が提供され、クエリ結果のあいまいさが回避されます。

多対多リレーションシップや、ファクト テーブルの値でディメンション テーブルをフィルター処理する必要がある場合に、双方向フィルター処理が必要になる場合があります。 双方向フィルターは、クエリのパフォーマンスが低下し、レポートで予期しないフィルター動作が発生する可能性があるため、慎重に使用してください。

リファレンシャル・インテグリティ

参照整合性を仮定する 設定は、リレーションシップ全体でクエリを実行するときに、LEFT OUTER 結合ではなく INNER 結合を使用するようにエンジンに指示します。 Direct Lake モードと DirectQuery モードでは、エンジンが処理する行数が減るため、この設定によってパフォーマンスが大幅に向上する可能性があります。

ファクト テーブル内のすべての外部キー値がディメンション テーブルに一致する値を持っていることを確信している場合は、この設定を有効にします。 参照整合性に違反すると、キーが一致しない行はクエリ結果から自動的に消えます。

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

一度に 2 つのテーブル間に存在できるアクティブなリレーションシップは 1 つだけです。 複数のリレーションシップ パス (注文日と出荷日の両方が同じ Date ディメンションに関連) が必要な場合は、1 つのリレーションシップをアクティブにし、他のリレーションシップを非アクティブにします。

DAX の USERELATIONSHIP 関数を使用して、計算内で非アクティブなリレーションシップをアクティブにします。

Shipped Amount =
CALCULATE(
    SUM(Sales[Amount]),
    USERELATIONSHIP(Sales[ShipDate], 'Date'[Date])
)

このパターンは、同じデータに対して複数の分析パースペクティブをサポートしながら、モデルをクリーンに保ちます。

セマンティック モデルでのスノーフレーク スキーマの処理

ソース データは、多くの場合、正規化されたスノーフレーク スキーマに到着します。ここで、ディメンション テーブルは複数の関連テーブルに分割されます。 たとえば、Product ディメンションは Product、Subcategory、Category の各テーブルに分割され、それぞれが外部キーを介してリンクされます。

セマンティック モデルには、スノーフレークをスター スキーマにフラット化するか、正規化された構造を保持するかの 2 つのオプションがあります。

星型スキーマにフラット化する

フラット化とは、正規化されたディメンション テーブルを 1 つの非正規化ディメンション テーブルに結合することを意味します。 Product テーブルには Subcategory 列と Category 列が直接含まれるので、追加のテーブルとリレーションシップは削除されます。

次の場合にフラット化します。

  • 統合されたディメンション テーブルは、ファクト テーブルと比べて小さいままです (これはディメンションの場合ではほぼ常に当てはまります)。
  • ディメンションからファクトへのより単純なフィルター パスが必要です。 各フィルターは、チェーンではなく 1 つのリレーションシップを通過します。
  • AI の消費量が優先されます。 テーブルが少なく、リレーションシップが単純な場合、Copilotおよびデータ エージェントは適切なデータへのパスを明確にします。

データがセマンティック モデルに到達する前に、レイクハウスまたはデータフローでのデータ準備中にディメンション テーブルをフラット化します。 Power Queryマージ、SQL 結合、またはノートブック変換を使用して、正規化されたテーブルを 1 つのディメンションに結合します。

スノーフレーク構造を保持する

場合によっては、正規化された構造を維持することは理にかなっています。

  • ディメンション階層には複数のレベルがあり、フラット化すると多数の冗長列が作成されます。
  • 複数のファクト テーブルがサブ次元テーブル (Sales ファクトと Inventory ファクトの両方で使用される共有カテゴリ テーブルなど) を共有し、非正規化によって一貫性のないコピーが作成されます。
  • 行レベルのセキュリティは、階層内の特定のレベルで適用する必要があります。

スノーフレーク構造を保持する場合は、リレーションシップを慎重に構成します。 チェーン内の各リレーションシップでは、フィルターが正しく伝達されるように、最も外側のテーブルからファクト テーブルへの単一方向のフィルター処理を使用する必要があります。 カテゴリのフィルターは、Subcategory、Product、ファクト テーブルの順に流れる必要があります。

Note

ほとんどのセマンティック モデル シナリオでは、ディメンションをスター スキーマにフラット化することをお勧めします。 テーブルの数が少ないほど、リレーションシップが少なくなり、DAX が単純になり、クエリが高速になり、AI の消費量が向上します。 スノーフレーク構造は、保持する強い理由がある場合にのみ保持します。

クロスソース シナリオで複合モデルを使用する場合

スター スキーマが複数のFabric データ ストアにまたがる場合、または外部ソースを含む場合は、複合モデルを使用します。 一般的なシナリオは次のとおりです。

  • レイクハウスにファクトテーブルがあり、ディメンションテーブルは倉庫で管理されています。
  • イベントハウスからのリアルタイム ストリーミング データと、レイクハウス内の履歴データの組み合わせ。
  • 外部ソース (インポート) からのデータをFabricネイティブ ファクト テーブル (Direct Lake) と組み合わせて参照します。

これらのシナリオでは、各テーブルのストレージ モードを個別に構成し、ソース間のリレーションシップが想定されるデータ ボリュームで許容可能に実行されることを確認します。