M365Con 2027 – 無料オンラインカンファレンス · 11–22 Jan 2027 · 120 sessions→ m365con.net

ブログ · Mirko Peters

Power Queryを使いこなす:フラットなデータをスタースキーマに変換する

By · · Updated

ポッドキャストのコンパニオンブログへようこそ!今回の投稿では、データモデリングの技術的な仕組みを詳しく掘り下げます。企業システムから巨大なフラットなデータのダンプを引き継いだことがある方なら、その苦労はご存じでしょう。すべてのトランザクションに顧客名、製品カテゴリ、地理的な場所が何百万回も繰り返し含まれており、レポートに多くの問題をもたらします。パフォーマンスの低下、分かりにくいDAX数式、肥大化したファイルサイズは、問題のほんの一部にすぎません。幸いなことに、このまさにその問題を解決するために、プロのBI開発者が頼りにしている実証済みのアーキテクチャパターンがあります。それがスタースキーマです。

Automatically translated with AI from the original post. Read the English original

▶ BLOGMastering Power Query:Transforming Flat Data…M365.FM
Titelbild: Mastering Power Query: Transforming Flat Data into a Star Schema

ポッドキャストのコンパニオンブログへようこそ!今回の投稿では、データモデリングの技術的な仕組みを詳しく掘り下げます。企業システムから巨大なフラットなデータのダンプを引き継いだことがある方なら、その苦労はご存じでしょう。すべてのトランザクションに顧客名、製品カテゴリ、地理的な場所が何百万回も繰り返し含まれており、レポートに多くの問題をもたらします。パフォーマンスの低下、分かりにくいDAX数式、肥大化したファイルサイズは、問題のほんの一部にすぎません。幸いなことに、このまさにその問題を解決するために、プロのBI開発者が頼りにしている実証済みのアーキテクチャパターンがあります。それがスタースキーマです。

本ガイドでは、雑然とした単一テーブルのデータエクスポートを、Power Queryを使ってクリーンな中心のファクトテーブルと、効率的で高性能なディメンションテーブルに分割する手順を順に解説します。その過程で、戦略的な計画、データクレンジングのベストプラクティス、サロゲートキーの生成、そしてPower BIレポートを非常に高速にするモデル最適化のテクニックも取り上げます。

Power Queryとスタースキーマの基礎

Microsoft Power BIでソリューションを構築する際は、基盤となるデータ構造がその後のすべてを決定します。スタースキーマは、成熟した高度に最適化されたデータモデリング手法です。ビジネスメトリックは中心のファクトテーブルに格納し、ビジネスエンティティの説明的な属性は周囲のディメンションテーブルに配置します。このレイアウトは、図にすると星の形に見えます。多くのBI開発者がこの方法を選ぶのは、保守と拡張が非常に容易なBIソリューションを実現できるからです。

この設計パターンを採用することの効果は非常に大きいことが、継続的な調査で示されています。実際、スタースキーマモデルを構築しているPower BIユーザーのおよそ80%が、フラットテーブル方式と比べてパフォーマンスと分析効率の向上を報告しています。逆に、スタースキーマを省略すると、開発のライフサイクルに深刻な摩擦が生じます。

  • 大量のデータの冗長性と重複によるクエリパフォーマンスの低下。
  • テーブル間のリレーションシップが曖昧または欠落していることに起因する、複雑なDAX数式。
  • 新しいビジネスデータが届いたときの保守の困難さと、拡張時のボトルネック。

データの再構成方法を完全に理解するために、変換コードを1行も書く前に必要な基本的な手順を見ていきましょう。

スタースキーマの計画

Power BIで変換手順を書き始める前に、スタースキーマについて明確で意図的な計画が必要です。慎重な計画は、混乱を避け、レポートを高速化し、モデルの保守を格段に容易にします。BI開発者は、未加工の大量データをPower BI Desktopに取り込む前に、必ずデータソースを監査し、スキーマを設計しておくべきです。

データソースを分析し、主要なテーブルを特定する

まず、未加工のデータソースを丁寧に確認することから始めましょう。販売トランザクション、Webクリック、在庫の動きなど、数値によるビジネスイベントを含むテーブルやフラットファイルを探します。これらが最終的に中心のファクトテーブルになります。次に、顧客名、製品説明、従業員名簿、カレンダーの日付など、ビジネスエンティティを説明する列を探します。これらがディメンションテーブルの基盤になります。

ヒント:テーブルの結合には、常に数値の整数キーを使うようにしてください。数値キーはVertiPaqエンジンのクエリを高速化し、テキストによる照合よりもリレーションシップを大幅に信頼性の高いものにします。

テーブルを特定したら、視覚的なエンティティ関連図を描きましょう。中心のファクトテーブルが、それぞれのディメンションテーブルに直接つながっていることを確認し、2つのファクトテーブルを直接接続することは厳に避けてください。ファクトとディメンションの間を1ホップに保つことで、フィルターの曖昧さを防ぎ、セマンティックモデルをすっきりと保てます。

Power Queryによるデータの取り込みとクレンジング

Power BIにデータを取り込むことは、信頼性の高いスタースキーマの確かな土台を築くことです。データソースに接続し、受け取ったデータをクレンジングして変換し、慎重にテーブルを読み込む必要があります。Power Queryは主要なデータ準備のワークベンチとして機能し、データがデータモデルに入る前に、情報を整形・加工できます。

Power Query の「読み込みを有効にする」設定は慎重に使い分けましょう。ステージング クエリや中間の補助テーブルは読み込みを無効にし、最終的に最適化したファクト テーブルとディメンション テーブルだけがモデルのメモリを使うようにします。さらに、フィルターや変換の処理はできるだけデータ ソースに近い段階で行いましょう。これはクエリ フォールディングと呼ばれる考え方で、データの更新時間を大幅に短縮できます。

データのクレンジングとは、エラーを体系的に取り除き、書式の不整合を修正して、テキスト文字列を統一することです。重要な外部キー列に欠損値がないか確認し、見つかったらすぐに修正してください。テーブル間でキーのデータ型が同じであることを確保することは、リレーションシップを正しく構成するうえで欠かせません。

ディメンション テーブルとサロゲート キーの作成

適切に設計されたディメンション テーブルは、スター スキーマの中核です。ディメンション テーブルは、業務の文脈を詳しく説明する情報を提供するために使います。フラットなデータ エクスポートからディメンションを抽出するには、エンティティの固有の属性を切り出し、重複する行を取り除く必要があります。

属性の抽出と重複の削除

フラットなデータ ダンプからディメンション テーブルを作成するときは、フィルターやグループ化に関係する列だけを選択します。たとえば、製品ディメンションには、製品 ID、製品名、カテゴリ、サブカテゴリ、単価を含めるとよいでしょう。列を絞り込んだら、各エンティティが必ず 1 行だけ存在するように重複レコードを削除します。行が一意であれば、1 対多のリレーションシップが予期しない相互フィルターの副作用なしに機能します。

ディメンション テーブルを、ソース システムの変更に強いものにするために、サロゲート キーの生成を検討してください。サロゲート キーとは、Power Query の変換ステップで作成する、人工的な自動採番の整数インデックス列です。変化しやすいテキストの自然キーではなくサロゲート キーを使うと、顧客の住所や製品名などのソースの説明情報が時間とともに変わっても、過去のファクト データを保護できます。

ファクト テーブルの構築と集計

クリーンなディメンション テーブルを確実に用意できたら、中核となるファクト テーブルの作成に取りかかれます。ファクト テーブルには、測定可能な定量的ビジネス イベントを格納します。各行は、関係者が必要とする最も細かい粒度での、特定のトランザクションや発生事象を表します。

大量のデータを扱う場合は、クエリ レベルまたはデータ ウェアハウス レベルで集計テーブルの作成を検討してください。月、地域、製品カテゴリごとにあらかじめ集計しておくと、行数が大きく減り、ビジュアルの描画も速くなります。ファクト テーブルを作成する際は、粒度が一貫していることを確認してください。日次の集計行と秒単位の個別トランザクションを同じファクト テーブルに混在させると、メジャーの集計が崩れ、二重計上の原因になります。

リレーションシップとモデルの最適化

テーブルを Power BI に読み込んだら、モデル ビューでモデルのリレーションシップを構成します。ディメンション テーブルの「1」側から、中央のファクト テーブルの「多」側へ向かう、シンプルな 1 対多のリレーションシップを設定してください。

相互フィルターは、既定では単一方向のままにしてください。どうしても必要な場合を除き、双方向フィルターは避けましょう。複雑なフィルター経路が生まれ、VertiPaq エンジンのパフォーマンスが低下し、想定外の分析結果になることが多いためです。定期的にモデルを監査し、未使用の列を削除して、リレーションシップに含まれる高カーディナリティのテキスト フィールドを減らしてください。また、連続した日付のカレンダー テーブルは、日付テーブルとして明示的にマークし、時間インテリジェンスの計算をスムーズに使えるようにしましょう。

スター スキーマを使ったレポートと分析

データ モデリングの取り組みは、最終的にはレポート層で成果となります。セマンティック モデルがクリーンなスター スキーマで構成されていれば、インタラクティブなダッシュボードの作成は非常に快適になります。スライサーやフィルターは即座に反応し、DAX メジャーは読みやすく、デバッグもしやすくなります。自然言語による Q&A 機能も驚くほど正確になります。

このアーキテクチャ パターンをより詳しく理解し、よくあるモデリングの落とし穴を避けるための専門家の知見を得るには、関連するポッドキャスト エピソードをぜひご覧ください: Build a Power BI Star Schema for Faster Reports。

まとめ

Power Query を使って雑然としたフラットなデータを最適化されたスタースキーマに変換することは、Power BI 開発者が身につけるべきスキルの中でも特に効果の大きいものの一つです。スキーマを慎重に設計し、ディメンションをクリーンアップし、安定したサロゲートキーを生成し、厳密な一対多のリレーションシップを構成することで、クエリのパフォーマンスを飛躍的に高め、DAX の計算をシンプルにし、堅牢なエンタープライズレポートを実現できます。

モデリングのチェックリストを活用し、行数をソースシステムと照合して検証し、組織のニーズの変化に合わせてモデルを継続的に監査することを忘れないでください。これらの戦略や Microsoft エコシステムのベストプラクティスに関する実践的な議論を深く掘り下げたい方は、Build a Power BI Star Schema for Faster Reports のエピソード全編をぜひお聴きください。それでは、良いモデリングを!

Entities in this article

Star schema Power Query Power BI Surrogate key Power BI Desktop Semantic model VertiPaq engine

Related articles

RSS