powerbi-core

Power BI のコア概念とデータモデリング

概要

データモデリングのベストプラクティス、接続モード、ソースの種類、リレーションシップ、よくある落とし穴など、Power BI の基礎知識を解説します。このスキルでは、すべての Power BI 開発者に必要な基本的なアーキテクチャの指針を提供します。

データモデルの設計 - スタースキーマ

データモデルは常にスタースキーマの構造で設計してください。

コンポーネント	目的	例
ファクトテーブル	数値イベント／トランザクション	Sales、Orders、WebVisits
ディメンションテーブル	記述属性	Date、Product、Customer、Geography
ブリッジテーブル	多対多の解決	StudentCourse、OrderProduct

必須ルール：

• 中央にファクトテーブルを1つ配置し、その周囲にディメンションを配置する
• リレーションシップはディメンション（1側）からファクト（多側）へ流れるようにする
• 自然キー／業務キーではなく、サロゲート整数キーを使用する
• ファクトテーブルは幅を抑える（キーとメジャーのみ）
• ディメンションを非正規化する（スノーフレークをスタースキーマに平坦化する）
• 専用の日付ディメンションテーブルを作成する（自動の日付／時刻を無効にする）
• 絶対に必要で、影響範囲を限定できる場合を除き、双方向のクロスフィルターを使用しない

ストレージモード

モード	データの場所	更新	パフォーマンス	使用するケース
Import	インメモリの VertiPaq	スケジュール／オンデマンド	クエリが最速	デフォルトの選択肢。圧縮後のデータが1GB未満の場合
DirectQuery	ソースデータベース	リアルタイム	ソースに依存	リアルタイム性が必要な場合、またはデータが大きすぎてインポートできない場合
Dual	両方	スケジュール＋リアルタイム	両方の利点	コンポジットモデルのディメンションテーブル
Direct Lake	OneLake の Delta テーブル	フレーミング（数秒）	Import に近い速度	Fabric のレイクハウス／ウェアハウスのシナリオ

Import モードに関する考慮事項：

• PBIX ファイルサイズの上限は1GB（サービスでは Premium／PPU で10GB）
• データは更新時点のスナップショットであり、リアルタイムではない
• スケジュール更新の上限：1日あたり8回（Pro）、48回（Premium／PPU）

DirectQuery の制限：

• クエリ実行時に Power Query の変換は適用されない
• モデルごとに使用できるソースは1つ（コンポジットモデルを除く）
• パフォーマンスはソースのクエリ速度に完全に依存する
• 多くの DAX 関数が使用できないか、性能が低下する
• DirectQuery テーブルには計算列を作成できない
• ビジュアルクエリごとの行数上限は100万行

Direct Lake の主な考慮事項（2025～2026年に一般提供）：

• 2つの種類があります：OneLake 上の Direct Lake（DL/OL）と SQL エンドポイント上の Direct Lake（DL/SQL）
• DL/OL は DirectQuery にフォールバックしません。データを提供できない場合、クエリは失敗します
• DL/SQL は SQL 分析エンドポイント経由で DirectQuery にフォールバックできます
• ガードレールは容量によって異なります：F32 ではテーブルごとに最大1,000個のファイル／行グループ、F64／P1 では最大5,000個です
• 最大メモリはページングのソフトリミットであり、ハードガードレールではありません。超過してページングが発生すると、パフォーマンスが低下します
• ディスク／OneLake 上のモデルの最大サイズはハードガードレールです。超過すると、DQ フォールバック（DL/SQL）または失敗（DL/OL）が発生します
• 計算列を含め、DAX を完全にサポートします
• フレーミング（メタデータのみの更新）は数秒で完了します
• Direct Lake モードの Power BI Embedded は、2025年3月から一般提供されています

ストレージモードの選択フローチャート：

1. Fabric OneLake の Delta テーブルにデータがありますか？Direct Lake を使用します
2. リアルタイムデータが必要で、ソースが高速ですか？DirectQuery を使用します
3. データが1GB未満で、更新の遅れを許容できますか？Import を使用します（最高のパフォーマンス）
4. 大規模なデータがあり、高速なクエリが必要ですか？コンポジットモデルを使用します（Import のディメンション＋DQ のファクト＋集計テーブル）

リレーションシップ

プロパティ	選択肢	既定値
カーディナリティ	1 対多、多対 1、1 対 1、多対多	1 対多
クロスフィルターの方向	単方向、両方向	単方向
アクティブ	はい／いいえ	はい（パスごとにアクティブにできるのは 1 つだけ）

リレーションシップのルール：

• 2 つのテーブル間でアクティブにできるリレーションシップは 1 つだけです
• 非アクティブなリレーションシップを有効にするには、DAX で USERELATIONSHIP() を使用します
• 双方向のフィルター処理は避けてください。フィルター パスのあいまいさ、パフォーマンスの低下、予期しない結果の原因になります
• 多対多には、ブリッジテーブルまたは複合モデルの多対多カーディナリティが必要です
• 参照整合性：DirectQuery のパフォーマンス向上のため、「参照整合性を仮定する」を設定します

データソースのクイックリファレンス

カテゴリ	ソース
Microsoft SQL	SQL Server、Azure SQL、Azure Synapse、SQL Server Analysis Services
Azure	Cosmos DB、Data Explorer (Kusto)、Blob Storage、Data Lake、Fabric Lakehouse/Warehouse
クラウドデータベース	Snowflake、Databricks、Google BigQuery、Amazon Redshift、Amazon Athena
ファイル	Excel、CSV/TSV、JSON、XML、Parquet、PDF
サービス	SharePoint、Dynamics 365、Salesforce、Google Analytics、Azure DevOps
プロトコル	OData、REST API、ODBC、OLEDB
ストリーミング	Azure Stream Analytics、PubNub、REST API プッシュ

増分更新

大規模な Import テーブルを全件更新せずに済むよう、増分更新を構成します。

1. Power Query で RangeStart と RangeEnd パラメーター（型は DateTime）を作成します
2. これらのパラメーターを使用して、日付列にフィルターを適用します
3. 更新ポリシーを構成します。アーカイブ期間（例：3 年）、増分期間（例：30 日）を設定します
4. 必要に応じて、最終更新日時列を使用して「データ変更の検出」を有効にします
5. 必要に応じて、最新のパーティションに DirectQuery を使用したリアルタイムデータを有効にします

要件： 基本的な増分更新を超える機能には、Premium、PPU、または Fabric の容量が必要です。Pro ワークスペースでも増分更新をサポートしていますが、制限があります。

2025-2026 年の改善点：

• 増分更新を使用するセマンティックモデルを Power BI Service で直接編集できるようになりました（計算列の変更、テーブル名の変更、階層の調整など）。Desktop を再度開く必要はありません
• 更新 API の強化により、パーティションを選択して更新できるようになり、より細かく制御できます
• パーティション処理の高速化により、テラバイト規模のデータセットのパフォーマンスが向上しました

ゲートウェイの構成

オンプレミスデータゲートウェイは、オンプレミスのソースと Power BI Service を接続します。

ゲートウェイの種類	用途
Standard（エンタープライズ）	複数のユーザーで共有し、一元管理します
Personal	単一ユーザー向け。開発／テスト専用です
Virtual Network (VNet)	Azure VNet に接続されたソース向け。オンプレミスのハードウェアは不要です

VNet データゲートウェイ（2025-2026 年）：

• オンプレミスのハードウェアを使わずに、VNet 内の Azure データソースに接続します
• Fabric/Power BI Service によって管理されるため、ゲートウェイマシンのメンテナンスは不要です
• Azure SQL、Synapse、Azure Data Explorer、およびその他の VNet にバインドされたサービスをサポートします
• Fabric 管理ポータルのゲートウェイ管理から有効にします

ゲートウェイのリリース（2025-2026 年）：

• 2025-2026 年を通じて毎月リリースされ、キャッシュとクエリフォールディングが強化されています
• 接続プーリングの最適化により、クエリのパフォーマンスが向上しています
• Power BI Desktop for Report Server は、2025 年 9 月以降 64 ビット版のみとなります

ゲートウェイの一般的な障害：

• 資格情報の有効期限切れ -- ゲートウェイの設定で更新します
• ソースに到達できない -- ファイアウォール、VPN、DNS を確認します
• メモリ不足 -- ゲートウェイマシンのリソースを監視します
• Mashup エンジンのクラッシュ -- Power Query の複雑さを確認します

データソース認証

方法	ユースケース	最適な用途
OAuth2	クラウドソース（Azure SQL、Snowflake、Databricks）	対話型の利用、SSO
サービスプリンシパル	自動更新、CI/CD パイプライン	無人での操作
ワークスペース ID	Fabric ワークスペース（管理するシークレットが不要）	Fabric ネイティブモデル
マネージド ID	Dataflows Gen2 から Azure ソースへの接続	シークレット不要の PaaS アクセス
ユーザー名／パスワード	レガシーなオンプレミスソース	ゲートウェイにバインドされたソース

ワークスペース ID（2025-2026）：

• Azure マネージド ID と同様に、Fabric ワークスペースに紐付けられます
• 有効期限がなく、管理するシークレットやパスワードもありません
• ワークスペースの設定で構成し、セマンティックモデルのデータソースに割り当てます
• Fabric ネイティブのシナリオでは、サービスプリンシパルより推奨されます

OAuth2 トークンの制限： REST API（UI ではなく）で設定した場合、OAuth2 資格情報には更新トークンがなく、1 時間後に有効期限が切れます。長時間実行する自動化にはサービスプリンシパルを使用してください。

接続プールのベストプラクティス：

• ゲートウェイは可能な限り接続を再利用します。異なる資格情報セットを最小限に抑えてください
• データソースの設定でクエリのタイムアウトを設定します（既定値は 5 分。複雑なクエリの場合は延長してください）
• 一時的なソース障害に備えて、Power Query で try/otherwise を使用した再試行ロジックを実装します

よくある落とし穴とアンチパターン

落とし穴	影響	対処方法
自動日付／時刻が有効	非表示の日付テーブルによってモデルが肥大化します（日付列ごとに 1 つ）	Options > Data Load で無効にします
暗黙的なメジャー（数値をビジュアルにドラッグ）	集計を制御できず、再利用もできません	明示的な DAX メジャーを作成します
双方向のクロスフィルター	あいまいさ、パフォーマンスの低下、誤った結果につながります	単方向を使用し、DAX で処理します
ファクトテーブルの列が多すぎる	モデルの肥大化、更新の遅延、メモリの浪費につながります	ファクトテーブルはキーと数値のみのシンプルな構成にします
BLANK と 0 と null の混同	DAX は BLANK を 0 とは異なるものとして扱います。ビジュアルでは BLANK の行が非表示になります	IF／COALESCE を使って明示的に処理します
循環依存関係のエラー	通常は、互いを参照する計算列や双方向フィルターが原因です	モデルを再構成し、循環を解消します
1GB の PBIX 制限	ファイルをローカルに保存できません	未使用の列を削除し、カーディナリティを最適化します
Power BI Service と Desktop の違い	一部の機能は、どちらか一方でしか利用できません	設計前に機能マトリックスを確認します
計算列とメジャー	計算列はメモリを消費し、行ごとに保存されます	メジャー（クエリ実行時に計算）を優先します
ファクトテーブル内の文字列列	カーディナリティの高い文字列は VertiPaq の圧縮効率を大きく損ないます	ディメンションテーブルに移し、キー参照を使用します

追加リソース

参照ファイル

• references/data-sources-detail.md -- すべてのソースタイプに対応するコネクタの詳細な構成
• references/gotchas-deep-dive.md -- 例と解決パターンを含む、落とし穴の詳細な分析