Modeling_Fundamentals

データモデリング・DAX 基礎解説・ベストプラクティス 2025年3月 Eiki Sui

スピーカー紹介 Sui Eiki スイスイ • Fabric CAT (CAT = Customer Advisory Team) • 元アナリスト (Power BIパワーユーザー） • Fabric (Power BI) 製品チーム、日本や 周辺諸国のFabric導入サポート @marshal_dabao https://aka.ms/techtech

• https://x.com/marshal_dabao
• https://aka.ms/techtech

ターゲットオーディエンス ビジネスユーザー • PBIレポートを見る人 • PBIレポートを使う人 Power BIモデル開発者 • モデリングの専門性 • M / DAXに精通 アナリスト、エンドユーザー等 企業規模によっては同じ人の場合も レポートデザイナー • ビジュアルデザイン • レポートを作る人 その他データを取り扱う人 • PBI管理者 • その他

アジェンダ 01 02 モデリングの概要 モデリングの詳細 03 04 05 06

モデリングの概要

BI（ビジネス・インテリジェンス）とは 数字/文字列等のデータを 人間が迅速に理解できる情報に変換 ビジュアルによる情報伝達速度は速い！

レポート作成プロセス ⚫ Power BIでレポートを作成する基本的な流れ 企業が保有する多種 データのETL データモデルの 多様なデータ （抽出・変換） 構築 基データ ETL* 分析モデル * ETL: Extract, Transform, Load（データの取得と変換）の略 可視化・分析に基づ く意思決定 レポーティング インサイト

モデリング・DAXとは ⚫ なぜモデリング・DAXは重要か？ • Power BIで洗練されたレポートを作るために必須 • レポートのパフォーマンスに直結 • 高度な分析を行うために必要なスキル ⚫ 用語確認 • モデリング（別名: データモデリング） – テーブル間にリレーションシップを構築したり、メジャー等を記述し、Power BIレポートを作り洞察を得るためのステップ モデリングのベストプラクティス = スタースキーマ • リレーションシップ（1対1、1対多、多対多） – テーブル同士（Dimension - Fact）を紐づけたもので、通常「1から多」という方向へフィルターが伝播していく – Dimension: フィルターする側（日付マスタ、商品マスタ、拠点マスタ等） – Fact: フィルターされる側（例: 売上実績、在庫詳細、月別販売予算等） – Dimension（1）- Fact（多）が基本（スタースキーマ）。略してDim • DAX: Data Analysis eXpression – Power BIのネイティブ言語。DAXで作った指標をメジャーと呼ぶ

• https://learn.microsoft.com/power-bi/guidance/star-schema

2. データモデルとDAXはペアで考える 1. スリムなモデルを目指す どちらも重要であり、どちらかというのではな く、両方を最適化していく 不要な列や行を削除し、データ量 を絞る モデリングとDAX はどっちが重要？ 圧倒的にモデリングの ほうが重要！ 3. スタースキーマ + シンプルなDAXメジャー ベストプラクティスであるスタースキーマに従い、複 雑なメジャーを避ける

Excelによる分析手法 vs BIによる分析手法 Excelのみを活用 データの整備 BIを活用 データの整備 ETL ETL Power Query 手動変換 Inventory Excel関数（VLOOKUP等） で紐づけ Sales シングルテーブル同士をExcel関 数（VLOOKUP等）で紐づけ Inventory A Sales A+B B 多次元分析が難しい 複数の指標を様々な“切り口” から分析可能

Excelによるシングルテーブルの特徴・デメリット ⚫ Excelにおけるシングルテーブル • エクセルでは、1つのテーブルを扱う • 実に単純であるが、それ自体はすでにデータ・モデル • Excelユーザーがピボットテーブルで分析しやすい ⚫ デメリット • 行数：100万行という制約 • スピードとメモリ使用量が最適ではない • 基本的な計算のみが可能 • 複数のテーブルを同時に分析するのが困難 • サイズの制限がデータモデルの制限になってしまう Excelがダメ！という意味ではなく、 Excelのスプレッドシートで分析する やり方に限界がある

Power BIのモデリング: シングル・ファクトテーブル 1対多（*）のリレーションシップ スタースキーマはDimとFactが直接 繋がっている形態 スタースキーマの重要性

• https://learn.microsoft.com/power-bi/guidance/star-schema

Power BIのモデリング: マルチ・ファクトテーブル テーブルは多いが、全て1対多（*）のリレーションシップ スタースキーマの重要性 Fact同士が直接リレーションシップ で繋がっていないことが重要！

• https://learn.microsoft.com/power-bi/guidance/star-schema

Power BIのモデリング: 時間ベースのモデリング 【時間ベースのスタースキーマ】 dCalendar: [年] [月] [日] 店舗 (dStore) dTime: [時間] [時] [分] 1 日付テーブル (dCalendar) 1 1 時間テーブル (dTime) ＊ ＊ 売上 （Fact Table) ＊ ＊ 1 1 顧客 (Dimension) 商品 (Dimension) 稼働時間のモデリング

• https://marshal115.hatenablog.com/entry/2022/09/26/232204

リレーションシップ: 基礎 【Dimension】 PrimaryとForeignはRelationshipで結合 【Dimension】 【Fact】 1対多(*) 【Dimension】 Primary key 重複のないKey（列） Foreign key 重複があるKey（列） ただし・・・ Dimension – Dimension – Fact ⚫ スノーフレークスキーマ 【Dimension】 【Dimension】 – 一般的にスタースキーマよりもクエ リパフォーマンスは落ちる – 非正規化が可能ならば行う (後述) – データ濃度（Cardinality）が 高い場合は要注意

スタースキーマを選ぶ理由 ビジネスインテリジェンスは1958年に誕生し、 BIの先人たちは殆ど全ての現存するデータ モデルを分析した。その結果、スタースキーマ が最良の選択肢であることを発見した。 自分が何をしているのか本当に分かってい るのでなければ、標準的なモデリングから逸 脱しないことが重要である！

デモ1 ⚫ モデリングの重要性: 異なるFactの指標を同じ切り口で計算 デモ SalesAmt = SUM( Sales[売上高] ), リレーションシップがない場 合、DAXメジャーは非常に 複雑になってしまう SalesAmt = CALCULATE( SUM( Sales[売上高] ), TREATAS( VALUES( Inv[年月] ), Sales[年月] ) )

モデリングの詳細

FactとDimensionの違い DimProductに商品単価と 販売単価がある場合 ⚫ Fact: 出来事・実績 • 通常は大きいテーブル: 数十億の販売実績は現実的 であるが、数十億の顧客は非現実的 • Factは数字と関連: 引出額、販売数量など • 全ての数字がFactに帰属するものではない 商品単価はDimに帰属する場合もあるが、 販売数量はFactに帰属 • メジャーは通常、Factの数値列より算出 ⚫ Dimension: 来事を説明するもの • 通常は小さいテーブル: 100万行は既に大きいテーブル • Dimは文字列情報を多く含む – 顧客名、住所、性別、学歴 – 商品名、色、サイズ、ブランド、メーカー • 殆どの場合、Dimでスライシングを行う • Dimは通常、お互いが関連していない 1つのFactには複数のDimが紐づき、 リレーションシップのキーは同じ名称が望ましい

Dimensionの数（あくまで目安） ⚫ 1つのDimension = 1つのエンティティ（属性） • Dimensionを増やしても無駄なことが多いし、混乱を招く • Dimension数の目安 – 10個以下 = Good – 20個 = ちょっと違う – 30個 = 完全に間違っている ⚫ 1つのDimensionにおける列数 • 1つのDimensionに20列はGood • 20個のDimensionで1列ずつしかない場合はBad

(参考) ヘルパーカラム（列）・ヘルパーテーブル ⚫ テーブルや列がユーザーに有用ではなく、モデルに有用なケース（例: 列で並び替え） 並び順バラバラ Month NameをMonth Numberで並び替え 正しい並び順に

• https://learn.microsoft.com/power-bi/create-reports/desktop-sort-by-column?tabs=powerbi-desktop

モデリング: スタースキーマの特徴 ⚫ Power BIの世界におけるベストプラクティス ⚫ シンプルな構造と分析のしやすさ ⚫ データサイズの圧縮 ⚫ メモリへの読み込み時間の短縮 ⚫ DAXクエリのパフォーマンスの向上 ⚫ データ品質の向上（重複排除） ⚫ モデルの設計変更への対応 例: 新しいDimテーブルの追加等 Factテーブルに存在する繰り返すレコード （分類名等）の列をDimensionテーブ ルへ移動させることがポイント Dimはフィルターする側、Factはフィルター される側 全ての属性（コード及び名称）を含む FactテーブルからDimテーブルを構築でき るよう、慣れておくこと（次頁）

デモ2 ⚫ Power BIのサンプル データセットをスタースキーマに デモ

知識の確認1: 下記在庫データはFactとして相応しいか？ 不要な列を多数抱えているため Not Good！ 不 要 不 要 不 要 不 要 不 要

知識の確認1: 下記在庫データはFactとして相応しいか？ Dimテーブルとリレーションシップ に使用されるID列と数値列の みが残されているためGood！

Q: それでも“使うかもしれない列”を最初から残しておきたい ⚫ データ量を見極める • 今だけでなく、今後増加していくデータ量（行だけでなく列）も考慮 ⚫ ユーザー体験 • 列が多すぎる場合、レポート作成者・エンドユーザーの使い勝手が悪くなる可能性 (例: ビジュアルをカスタマイズ) =>エンドユーザーが切り口として使用する列を制限できる ⚫ 必要な列を最初から限定（少なく）したほうが良い • 後から列を削除するほうが、最初に列を制限して後から追加するより大変！(※盲点) 理由: 削除するための確認作業が非常に大変のため • 追加が必要になった場合、追加前にパフォーマンスの測定、影響度の確認が可能 Measure Killer (不要な列を削除する3rdパーティツール） https://qiita.com/ayumito/items/9f8c0c7d559205612b22

• https://learn.microsoft.com/power-bi/create-reports/power-bi-personalize-visuals?tabs=powerbi-desktop#what-report-users-can-change
• https://qiita.com/ayumito/items/9f8c0c7d559205612b22

テーブルの正規化 ⚫ 正規化は同種の情報を保持するため、より多くのテーブルを作る一方、データベースの 総サイズを減らすプロセス（基幹系システム = OLTP） ⚫ 非正規化との違いは、正規化するほど、 テーブルが増えるため、ユーザー体験が悪くなる OLTP: Online Transaction Processing

テーブルの非正規化 ⚫ 非正規化するのはスタースキーマを作るため（1対多のリレーションシップ） ⚫ BIにおける分析という観点から、モデリングにおけるテーブルの非正規化はユーザー体験を 良くする 非正規化を行うのは分析ニー ズが強い場合 基幹系システムは通常、ガチガチに 正規化された状態となっている

ペルソナ (ユーザー) 別の正規化・非正規化の考え方 ⚫ Excelユーザーは正規化を心掛ける • 1つの大きなテーブルでピボットを作っている人はリレーションシップの概念を学ぶ • 大きなテーブルから1つまたは複数のDimテーブルを作ること = スタースキーマの構築 ⚫ データベースエンジニアは非正規化を心掛ける • Power BIはOLTPではなく、OLAPの概念 • テーブルのリレーションシップが“鎖(チェーン) ”のようにならないように気を付ける (スノーフレークスキーマ ) • Fact – Dimを繋げる場合、1-多(*)という”ダイレクト”なリレーションシップになるように (スタースキーマ ) OLAP: Online Analytical Processing https://qiita.com/PowerBIxyz/items/cc98414a1e71d837fd32

• https://qiita.com/PowerBIxyz/items/cc98414a1e71d837fd32

(参考) リレーションシップ: スノーフレークスキーマ ⚫ スノーフレークのサンプル スタースキーマはスノーフレークよりも テーブルが2つ少ない（非正規化） スノーフレーク 【Dim】 スタースキーマ 【Dim】 【Dim】 【Dim】 スノーフレークはリレーションシップが チェーン（連鎖）状態となっている 【Fact】 【Fact】

良く考えると・・・全てのテーブルを非正規化すると？ 非正規化の極論は 「全てのデータを1つのテーブルに格 納」 その場合、それ自体がデータモデル Power BIであればExcelのような 100万行の制限もない・・・

知識の確認2: 非正規化をして1つのFactで良いのでは？ No and Never！ ⚫ スタースキーマではない！ ⚫ モデルサイズの増大（SQLBI: Star schema or single table）  40億行  RAM*使用量: 1つ (44.5 GB) vs スタースキーマ (16.8 GB) ⚫ データモデルへのロード時間が長くなる: RAM使用量が増えるため ⚫ DAXクエリの複雑化 ⚫ クエリパフォーマンスの悪化: メジャーが複雑になるほど遅くなる ⚫ Fact同士（例: 売上Factと在庫Fact）を1つにするのは、現実的ではない ⚫ 間違った値の算出（Auto-Exist） * RAM = Random Access Memory（PCの物理メモリ） Value filter behavior (blog, docs) によるフィルター動作のコントロール

• https://www.sqlbi.com/articles/power-bi-star-schema-or-single-table/
• https://www.sqlbi.com/articles/understanding-dax-auto-exist/
• https://powerbi.microsoft.com/ja-jp/blog/power-bi-october-2024-feature-summary/
• https://learn.microsoft.com/power-bi/transform-model/value-filter-behavior

データの正規化（データは横持ち or 縦持ち？） ⚫ 横に年月別の数値が広がっている場合 正規化 ① 1列1属性ルール ② データは横ではなく、縦に広げる ③ 列が多いほど、データサイズは増大 ⇒正規化するほど、サイズは小さくなる 下記B参照 Unpivot = ピボット解除 1. スリムなモデルを目指す 不要な列や行を削除し、データ量 を絞る（→ピボット解除で縦長モ デルに変換していく）

カーディナリティ（データの濃度） ⚫ カーディナリティはユニークレコードの数に比例 カーディナリティ: 高カーディナリティは多様な値を、低カーディナリティは重複が多いことを意味する カーディナリティが低い（ユニーク なレコードが少ない）ほど、データ 圧縮率は高くなる Q: どちらのほうが計算の処理が速い？ A: ① 左、② 右、③ 同じ 理由はスキャンする 行数が異なるため！

縦長モデル vs 横長モデル ⚫ 下記モデルはどのように判断すべきか？ 縦長モデル 行数: 197 列数: 5 横長モデル 行数: 66 列数: 6 重要なことはどちらのモデルであっても、 年月のピボット解除が済んでいること

横長モデルの特徴 ⚫ DAXメジャーを作る場合、対象“数値列”に対してSUMするだけでOK ⚫ 主に売上数、売上高、売上原価、粗利益等の指標を定義する場合 ⚫ クロス集計で横軸が年月＋売上等の場合、年月をピボット解除し、縦持ちにすること！ ⚫ マトリックステーブルでは、複数の指標を入れたい場合、1つずつ入れる必要がある デモ

縦長モデルの特徴 ⚫ 数値列が1つになっていることが多い（Value or 値、等） ⚫ クロス集計は“列”で切り口となる列（ActPlan）+ [縦持ちTotal]*（メジャー）だけでOK *縦持ちTotal = SUM( 'Unpivoted_縦持ち'[Value] ) ⚫ 個別メジャーの算出に際しては、CALCULATE関数を使用して、フィルター条件を設定して あげる必要あり デモ 縦持ちActual = CALCULATE( [縦持ちTotal], 'Unpivoted_縦持ち'[ActPlan] = "Actual" ) VS 横持ちActual = SUM( 'Pivoted_ 横持ち'[Actual] )

その他データモデリングのTips ⚫ 安易に双方向のリレーションシップ（1、2）を有効にしないこと ⚫ 多対多のリレーションシップは概念や使いどころを知っておくこと ⚫ 日付テーブル（Dim）は必ず作っておくこと（月次テーブル、日次テーブル、その他①, ②, ③） – Power Queryで作成 – DAXで作成（CALENDAR、CALENDARAUTO等） – サードパーティーツール（Bravo for Power BI）で作成 ⚫ 計算列（DAXセクションにて解説）はむやみに作らないこと ⚫ 時間を含むモデリングはテーブルを日付テーブルと時間テーブルに分ける ⚫ Factテーブルの列は最終的に全て非表示にされるべきであり、その概念について理解しておく ※ワンポイント 最初から大きなモデルを作ろうとするのではなく、小さなモデルから徐々に作ること

• https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/
• https://learn.microsoft.com/power-bi/guidance/relationships-bidirectional-filtering
• https://learn.microsoft.com/power-bi/guidance/relationships-many-to-many
• https://marshal115.hatenablog.com/entry/2023/03/20/164311#月次べースの日付テーブル-vs-日次ベースの日付テーブル
• https://marshal115.hatenablog.com/entry/2023/03/20/164311#Dailyベースの日付テーブルでの検証
• https://marshal115.hatenablog.com/entry/2024/06/09/162250
• https://marshal115.hatenablog.com/entry/2024/06/21/175723
• https://marshal115.hatenablog.com/entry/2024/08/31/191059
• https://www.sqlbi.com/articles/reference-date-table-in-dax-and-power-bi/
• https://dax.guide/calendar/
• https://dax.guide/calendarauto/
• https://marshal115.hatenablog.com/entry/2022/04/01/121856
• https://marshal115.hatenablog.com/entry/2021/04/29/111308
• https://marshal115.hatenablog.com/entry/2022/09/26/232204
• https://marshal115.hatenablog.com/entry/2022/05/30/175230

双方向のリレーションシップ ⚫ 安易に双方向のリレーションシップ（1、2）を有効にしないこと • スタースキーマを常に意識することが重要であると同時に、双方向のリレーションは設定しないこと！例外はあるが 「自分が何をやっているかを理解できない場合は設定しない」。理由は単純、計算された数字が間違っている可 能性があり、意味がない数値となっていることがあるため 可能であれば、DAXのCROSSFILTERを使用する

• https://www.sqlbi.com/articles/bidirectional-relationships-and-ambiguity-in-dax/
• https://learn.microsoft.com/power-bi/guidance/relationships-bidirectional-filtering
• https://dax.guide/crossfilter/

データモデル vs セマンティックモデル（文脈） ⚫ データモデル vs セマンティックモデル（以前は「データセット」） • 公式ドキュメントで両者の明確な違いを述べている箇所はなし • 広義的: 同じことを指す • 狭義的: 使い分けをする場合がある • Excel Power Pivotではデータモデル • Power BIサービスに発行されたモデルはセマンティックモデル • Power BI Desktopではどちらでも良い • 解釈として、セマンティックモデルは「ビジネス上の意味付けが加わったモデル」として捉える • Power BI Desktop上では、技術的な「データモデル」の構築に近い • Power BI Service上では、データの更新や共有、再利用性が加わり、ビジネスユーザーにとっての実用性が向上し、 役割の進化を強調できることから「セマンティックモデル」と呼ぶ • 不毛な議論に発展しないように注意したい

Power BI Desktop vs Fabric Power BI ローカル環境 ⚫ インポート / DirectQuery モデル Power BI サービス クラウド上 Power BI Desktop インポートモード ソース 変換 データモデル クラウド環境 セマンティックモデル ソースデータの変換→メモリへ の複製→サービスへ発行 M DAX カプセル化 ⚫ Direct Lake モデル ソース 変換 データストア セマンティックモデル LH / WH Delta tables Direct Lake DAX モデリング M LH: Lakehouse WH: Warehouse Delta: Delta parquet データストアへ投入→Power BIからそのまま可視化

Microsoft Thank you! @marshal_dabao Tech Tech blog -Power BI, Fabric https://aka.ms/techtech https://aka.ms/techtech2 https://aka.ms/pbireport https://aka.ms/pbibest

• https://x.com/marshal_dabao
• https://aka.ms/techtech
• https://aka.ms/techtech2
• https://aka.ms/pbireport
• https://aka.ms/pbibest