ウェアハウス内のデータをモデル化する

データ モデリングを使用しない場合、すべてのconsumerは、どのテーブルが相互に関連するかを把握し、独自の集計ロジックを記述し、列の意味を推測する必要があります。 データ モデリングでは、構造、ビジネス ロジック、ドキュメントをウェアハウスに直接埋め込むことで、この問題を解決します。 Microsoft Fabric ウェアハウスでは、データを明確化するために準備し、テーブル間のリレーションシップを定義し、ビューとメジャーを用いてアクセスを標準化し、レポート用のセマンティックモデルを発行します。 これらのモデリングの選択肢は、T-SQL クエリ、Power BI レポート、AI 主導の自然言語分析など、すべてのダウンストリーム エクスペリエンスに影響します。

使用するデータを準備する

リレーションシップを定義したり、計算を追加したりする前に、コンシューマーに表示される内容をクリーンアップする必要があります。 生データウェアハウスのテーブルには、多くの場合、ステージングテーブル、代理キー列、およびETL処理用の内部フラグが含まれており、これらは分析用ではありません。 これらのオブジェクトは、コンシューマーがデータを参照するときにノイズを発生します。 倉庫を消費用に準備することは、関連するもののみを表示し、理解可能にすることを意味します。

モデル ビューでは、consumer エクスペリエンスを向上させるためにいくつかの手順を実行できます。

• ステージングテーブル、サロゲートキー列、ETLアーティファクト などの内部オブジェクトを非表示にして、フィールドリストの乱雑を避けます。
• 列の名前を変更して、倉庫の列名が技術的または省略されたビジネスフレンドリ名を使用します。 たとえば、 の名前を に変更します。
• 外部ドキュメントを参照せずにデータが何を表すのかをコンシューマーが理解できるように、テーブルと列に説明を追加します。

これらの手順は、単なる整理整頓を超えて重要です。 Power BI および Fabric IQ データ エージェントの Copilot は、テーブル名、列名、および説明に依存して自然言語の質問を解釈し、正確な SQL または DAX を生成します。 説明が「顧客のプライマリ アドレスの地域」を示すような列名は、説明のない列名よりも、自然言語の結果を生み出します。

クリーンで適切な名前のテーブルを配置すると、これらのテーブルが相互に接続する方法を定義する準備が整います。

テーブル間のリレーションシップを理解する

リレーションシップは、2 つのテーブル間の論理接続であり、これらのテーブル間でフィルター処理、グループ化、集計を行うことができます。 スター スキーマでは、リレーションシップは、ファクト テーブルを共有キー列を介してディメンション テーブルに接続します。

たとえば、との両方に存在する列は、地域、セグメント、アカウントの種類などの顧客属性別の売上の分析を可能にするリンクを確立します。

各リレーションシップには、2 つの重要なプロパティがあります。

• カーディナリティ は、2 つのテーブルの行がどのように対応するかを表します。 スター スキーマでは、ファクトとディメンションのリレーションシップは通常、多対 1 です。つまり、多くのファクト行が 1 つのディメンション行にマップされます。
• クロスフィルターの方向 によって、テーブル間でフィルターが伝達される方法が決まります。 ディメンションがファクト テーブルをフィルター処理する単一方向は、ほとんどのスター スキーマ 設計の標準設定です。フィルター動作は予測可能でパフォーマンスが高いためです。

リレーションシップが定義されていない場合、テーブル間でデータを結合するすべてのconsumerは、明示的な JOIN ロジックを記述する必要があります。 リレーションシップは、接続を 1 回エンコードすることで、その繰り返しを排除します。 ウェアハウスからセマンティック モデルを作成すると、これらのリレーションシップによって、Power BI、Copilot、Fabric IQ データ エージェントがデータを解釈する方法が通知されます。 たとえば、データ エージェントは、自然言語の質問を SQL に変換するときに、リレーションシップを使用して正確な結合を生成します。

データ アクセスをビューとメジャーで標準化する

テーブルがクリーンで接続されたので、次の手順は、コンシューマーに、そのデータに対してクエリと計算を行う信頼性の高い一貫性のある方法を提供することです。 標準化を行わないと、各チームは独自の結合ロジックを記述し、独自のフィルターを適用し、独自の数式を定義して、結果の競合につながります。

ビュー は、T-SQL コンシューマーにこの一貫性を提供します。 ビューは、結合ロジック、フィルター、列の選択を、コンシューマーがテーブルのように参照する再利用可能なクエリにカプセル化します。 たとえば、ファクト テーブルとディメンション テーブルを結合し、完了した注文をフィルター処理し、アナリストが必要とする列のみを表示するビューは、すべての T-SQL consumer信頼できる開始点を提供します。 ビューは、レポートの安定したデータ ソースとしても機能します。 変更される可能性があるベース テーブルに対して直接レポートを作成するのではなく、一貫性のある図形を表示するビューでレポートをポイントできます。

DAX 計算でも同様に整合性を提供するのはメジャーです。 メジャーは、合計、平均、比率、カウントなどの計算を定義する再利用可能な DAX 式です。 テーブルを選択し、新しいメジャーを追加することで、倉庫モデル ビューでメジャーを直接作成します。 たとえば、Total Sales 列を合計する SalesAmount メジャーを使用すると、すべての利用者で同じ計算が確実に行われます。

メジャー定義はデータと共に存在するため、そのメトリックの単一の信頼できるソースになります。 ビジネスが収益の計算方法を変更する場合は、個別の数式を含むすべてのレポートを追跡するのではなく、1か所で指標を更新します。

ビューとメジャーは、消費の両面をカバーします。ビューでは、T-SQL利用者によるデータのアクセスとクエリー方法が標準化され、メジャーではレポートやダッシュボードでの業務計算の表示方法が標準化されます。

Power BI レポート用のセマンティック モデルを作成する

準備されたテーブル、定義されたリレーションシップ、標準化されたビューとメジャーが用意されていることで、ウェアハウスは下流のレポートへの対応が整っています。 T-SQL を使用してウェアハウスに直接クエリを実行するチームや、サードパーティ製ツールを使用して接続する Teams は、ウェアハウス モデル as-isを操作できます。 ただし、対話型の Power BI レポートとダッシュボードを作成する場合は、セマンティック モデルを作成します。

ファブリック ウェアハウスから作成されたセマンティック モデルでは、Direct Lake モードが使用されます。 Power BI メモリにデータをコピーする従来のインポート モードとは異なり、Direct Lake は OneLake Parquet ファイルから直接データを読み取ります。 つまり、レポートには、スケジュールされた更新を必要とせずに、最新のウェアハウス データが反映されます。 データの個別のコピーを維持する必要がなくなり、ストレージおよび処理のオーバーヘッドを回避できることも意味します。

Power BI レポートのスクリーンショット。