【ITニュース解説】Relationships, Schemas and Joins in Power BI: A Practical Guide to Data Modelling

Power BIでのデータ分析では、単に見た目の良いグラフを作成するだけでなく、その土台となるデータモデルの設計が非常に重要になる。最初のレポートがシンプルな12列のテーブルだったとしても、「実績と予算の比較」といったより複雑な分析の要望に応えようとすると、このシンプルなテーブルでは対応できないことに気づくことがある。これは、一つのテーブルにすべてのデータを詰め込む「フラットテーブル」では、複数のビジネスプロセス間で顧客情報や日付情報といった共通の要素を共有できないためだ。ここでの重要な教訓は、画面に表示されるビジュアル（グラフや表）そのものよりも、その土台となるデータモデルこそが真の「プロダクト」であるということだ。データモデルを適切に設計することで、分析の柔軟性、パフォーマンス、そして保守性が大きく向上する。

データモデルの形にはいくつかの種類がある。最も単純なのは「フラットテーブル」で、すべてのデータを一つの大きなテーブルにまとめる。これは一見シンプルだが、同じ情報が何度も繰り返し格納されるためデータの冗長性が高く、一つの業務プロセス以外の分析をサポートするのが難しいという問題がある。この問題を解決するのが「スタースキーマ」だ。スタースキーマは、分析対象となる数値データ（売上金額や数量など）を含む「ファクトテーブル」を中央に配置し、その周囲に、それらの数値を説明する属性データ（顧客名、商品カテゴリなど）を含む「ディメンションテーブル」を配置する構成を指す。ファクトテーブルとディメンションテーブルは「1対多」の関係でつながる。スタースキーマは、Power BIの内部エンジンに最適化されており、高速で、データの可読性が高く、DAXと呼ばれる計算式も記述しやすいため、ほとんどのプロジェクトで推奨される形だ。さらに複雑な形として「スノーフレークスキーマ」がある。これはディメンションテーブルをさらに細かく正規化し、例えば「商品テーブル」が「サブカテゴリテーブル」につながり、さらにそれが「カテゴリテーブル」につながるように、階層的に分割するものだ。これによりデータの冗長性はさらに減るが、テーブル間の接続が増え、モデルが複雑になるため、通常はスタースキーマの方が好ましいとされる。

データモデルを構築する上で、テーブルを「ファクトテーブル」と「ディメンションテーブル」の二種類に分類して考えることが重要だ。「これは発生した出来事か、それとも存在する実体か？」という問いを立てると区別しやすい。「売上金額」や「数量」のように、あるイベントで発生した数値はファクトテーブルに格納される。一方、「顧客名」や「商品カテゴリ」のように、存在する実体を説明する属性情報はディメンションテーブルに格納される。ファクトテーブルを作成する際には、そのテーブルの「粒度（グレイン）」を明確にすることが非常に重要だ。粒度とは、「このテーブルの1行が何を意味するのか」をはっきりと定義することだ。例えば、「1行が1つの注文明細を表す」というように粒度を定めれば、データの二重計上などの誤りを防ぐことができる。

テーブルとテーブルをつなぐ「リレーションシップ」は、データ分析において非常に重要な役割を果たす。これはテーブルを物理的に結合する「マージ」とは異なり、データ間の論理的な関連性を宣言するメタデータであり、フィルターが伝播する経路を定義するものだ。ほとんどのリレーションシップは「1対多」となるべきだ。例えば、顧客情報が格納されたテーブルでは「顧客ID」は一意だが、売上情報が格納されたテーブルでは一人の顧客が複数の注文をするため「顧客ID」は何度も登場する。このように、一方のテーブルではキーが一意で、もう一方のテーブルではキーが繰り返し登場する関係が1対多である。もし二つのテーブルが「1対1」のリレーションシップであるならば、それはPower Queryでその二つのテーブルを一つにマージし忘れている可能性が高い。また、「多対多」のリレーションシップは通常避けるべきで、その場合は「ブリッジテーブル（結合テーブル）」と呼ばれる中間テーブルを挟むことで、両側をきれいな1対多のリレーションシップに変換するのが最善の策だ。二つのテーブル間に設定できるリレーションシップは通常一つしかアクティブにできない。

リレーションシップによって定義されたフィルターは、デフォルトでは「1」の側から「多」の側へと流れる。例えば、商品カテゴリを選択すると、そのカテゴリに属する商品の売上がフィルターされる。この一方向のフィルターがデータの整合性を保ち、パフォーマンスを維持する上で非常に重要である。「双方向フィルタリング」は一見便利に見えるが、複数のファクトテーブルを横断する複雑なフィルターパスを作り出し、パフォーマンスを著しく低下させる可能性がある。また、行レベルのセキュリティやプロセスを複雑にする原因にもなるため、特別な理由がない限りは避けるべきだ。特定の分析で双方向のフィルターが必要な場合は、リレーションシップ自体を双方向に変更するのではなく、CROSSFILTERやTREATASといったDAX関数を特定のメジャー（計算式）内で使用することを推奨する。

データモデルを作成する前のデータ準備段階では、Power Queryの「クエリのマージ」機能を使って複数のテーブルを物理的に結合することがある。これは新しいテーブルを作る処理だ。マージにはいくつかの種類がある。例えば、「左外部結合」は、左側のテーブルのすべての行と、右側のテーブルで一致する行を結合する。「内部結合」は、両方のテーブルで一致する行だけを結合する。さらに、「左アンチ結合」は左側のテーブルにのみ存在し、右側のテーブルには一致する行がない行を返す。これは例えば、注文履歴のない顧客を見つけたり、参照されていない外部キー（オーファンキー）を見つけたりするのに非常に便利だ。これらの結合方法を適切に使い分けることで、必要なデータを効果的に整形できる。

Power Queryでの「マージ」とPower BIモデル内での「リレーションシップ」は、どちらもテーブル間の関連付けを行うが、その性質は大きく異なる。マージはデータ更新時に実行され、物理的に新しい列をテーブルに追加する。これは一度実行されると永続的な変更となるが、ファクトテーブルに大量の列を追加するとメモリ使用量が増大し、コストが高くなる可能性がある。一方、リレーションシップはデータクエリ時に評価される論理的な関連付けであり、テーブルに物理的な列を追加しないため、ほとんどコストがかからない。ディメンションテーブル同士を結合してよりクリーンなディメンションテーブルを作る場合にはマージが有効だが、リレーションシップを構築する手間を省くためにディメンションテーブルを直接ファクトテーブルにマージすることは避けるべきだ。これは、せっかくスタースキーマで問題を解決しようとしているのに、再びフラットテーブルの問題を一つずつ作り直すことになりかねないため、注意が必要だ。

データモデルを構築する際の基本的な推奨事項は、スタースキーマを採用し、すべてのテーブル間に「1対多」のリレーションシップを確立することだ。また、日付データを扱うための適切な「DimDate（日付ディメンション）」テーブルを用意することは不可欠である。フィルターの方向は、特殊な理由がない限り「単一方向フィルタリング」を基本とし、双方向フィルタリングを採用する場合には、その必要性を書面で明確に説明できる理由がある場合に限定すべきだ。このようなデータモデルの設計に数時間を費やすことは、後になって発生する可能性のある数週間もの再構築やトラブルシューティングの時間を節約することにつながる。適切なモデル設計を怠ると、結局は最初からやり直すことになりかねないため、初期段階での丁寧なデータモデリングが何よりも重要である。