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

完了

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

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

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

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

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

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

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

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

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

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

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

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

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

注意

ほとんどのデータ ウェアハウスでは、ディメンション モデリングが使用されます。 リレーションシップを作成して スター スキーマを形成できます。これは、分析に最適なモデルです。 詳細については、 Microsoft Fabric モジュールの設計ディメンション モデルを参照してください。

ビューとメジャーを使用してデータアクセスを標準化する

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

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

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

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

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

ヒント

DAX の数式と高度なメジャー設計については、後のモジュールで詳しい説明を行います。 ビューとストアド プロシージャについては、データのクエリと変換に関する前のユニットを参照してください。

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

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

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

ヒント

セマンティック モデルの設計とスケーラビリティ パターンについては、「 スケーラブルなセマンティック モデルの設計」で詳しい説明があります。 このユニットでは、ウェアハウス自体のデータのモデリングに重点を置いています。