events
3月31日 23時 - 4月2日 23時
究極の Microsoft Fabric、Power BI、SQL、AI コミュニティ主導のイベント。 2025 年 3 月 31 日から 4 月 2 日。
今すぐ登録このブラウザーはサポートされなくなりました。
Microsoft Edge にアップグレードすると、最新の機能、セキュリティ更新プログラム、およびテクニカル サポートを利用できます。
この記事は、Power BI Desktop データ モデラーを対象としています。 スター スキーマの設計と、パフォーマンスと使いやすさのために最適化された Power BI セマンティック モデルの開発との関連性について説明します。
重要
Power BI セマンティック モデルは、データをインポートまたは接続する Power Query に依存します。 つまり、 Power Query を使用してソース データを変換および準備する必要があります。これは、大量のデータがある場合や、緩やかに変化するディメンションなどの高度な概念を実装する必要がある場合に困難になる可能性があります (この記事では later を参照)。
これらの課題が提示されたら、データ ウェアハウスを定期的に読み込むデータ ウェアハウスと抽出、変換、読み込み (ETL) プロセスを最初に開発することをお勧めします。 その後、セマンティック モデルをデータ ウェアハウスに接続できます。 詳細については、「 Microsoft Fabric Warehouse でのDimensional モデリング」を参照してください。
ヒント
この記事は、スター スキーマの設計に関する完全な説明を提供するためのものではありません。 詳細については、Ralph Kimball その他による「The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (2013 年第 3 版)」など、広く採用されている公開コンテンツを直接参照してください。
スター スキーマは、リレーショナル データ ウェアハウスで広く採用されている成熟したモデリング手法です。 モデラーは、モデル テーブルを "ディメンション" または "ファクト" として分類する必要があります。
Date
と ProductKey
の 2 つのディメンション キー列を持つ販売目標を格納するように設計されたファクト テーブルを考えてみましょう。 このテーブルに 2 つのディメンションがあることは簡単に理解できます。 しかし、粒度は、ディメンション キーの値を考慮せずに決定することはできません。 この例では、 Date
列に格納されている値が各月の最初の日であるとします。 この場合、粒度は月単位の製品レベルとなります。一般に、ディメンション テーブルには比較的少数の行が含まれます。 一方、ファクト テーブルには多数の行を含め、時間の経過と同時に拡大し続けることができます。
この記事で説明するスター スキーマのいくつかの概念を理解するには、正規化と非正規化という 2 つの用語を理解することが重要です。
"正規化" とは、同じデータの繰り返しが減る方法で格納されたデータを記述するために使用される用語です。 プロダクト キーなどの一意のキー値列を持つ製品のテーブルと、製品名、カテゴリ、色、サイズなど、製品の特性を記述するその他の列について考えてみましょう。 販売テーブルは、製品キーのようなキーのみが格納されている場合、正規化されていると見なされます。 次の図では、 ProductKey
列のみが製品を記録していることに注意してください。
一方、キー以外の製品の詳細が販売テーブルに格納されている場合は、"非正規化されている" ものと見なされます。 次の図では、 ProductKey
およびその他の製品関連の列に製品が記録されていることに注意してください。
エクスポート ファイルまたはデータの抽出からのデータをソースにする場合は、非正規化されたデータ セットを表している可能性があります。 この場合は、Power Query を使って、ソース データを変換して複数の正規化されたテーブルに整形します。
この記事で説明されているように、正規化されたファクトデータとディメンション データを表すテーブルを使用して、最適化された Power BI セマンティック モデルの開発に努める必要があります。 ただし、1 つのモデル テーブルを生成するために、 snowflake ディメンション が非正規化される場合がある例外が 1 つあります。
この記事で紹介するスター スキーマの設計と関連する多くの概念は、パフォーマンスと使いやすさのために最適化された Power BI モデルの開発と非常に関連性があります。
各 Power BI レポート ビジュアルで、Power BI セマンティック モデルに送信されるクエリが生成されることを検討してください。 一般に、クエリはモデル データをフィルター処理、グループ化、集計します。 適切に設計されたモデルは、フィルター処理とグループ化用のテーブルと、集計用のテーブルを提供するモデルです。 この設計は、スター スキーマの原則に十分適しています。
modeler がテーブルの種類をディメンションまたはファクトとして設定するように設定するテーブル プロパティはありません。 実際には、 モデルのリレーションシップによって決まります。 モデル リレーションシップは、2 つのテーブル間にフィルター伝達パスを確立し、テーブルの種類を決定するリレーションシップのカーディナリティ プロパティです。 一般的なリレーションシップのカーディナリティは、"一対多" またはその逆の "多対一" です。 "一" 側は常にディメンション テーブルですが、"多" 側は常にファクト テーブルです。
適切に構造化されたモデル設計には、ディメンション テーブルまたはファクト テーブルであるテーブルが含まれます。 単一のテーブルに 2 つの種類を混在させないようにしてください。 また、適切なリレーションシップが設定された適切な数のテーブルを提供するよう努力することもお勧めします。 また、ファクト テーブルでは常に一貫性のあるグレインでデータが読み込まれることも重要です。
最後に、最適なモデル設計は科学と芸術にまたがっていることを理解することが重要です。 場合によっては、そうすることが妥当な場合、適切なガイダンスを守らないこともあります。
Power BI セマンティック モデルに適用できるスター スキーマ設計に関連する多くの概念があります。 たとえば、次のような概念です。
スター スキーマの設計では、メジャーは集計する値を格納するファクト テーブルの列です。 Power BI セマンティック モデルでは、メジャーの定義は異なりますが、似ています。 モデルでは、明示的なメジャーと暗黙的なメジャーの両方がサポートされます。
SUM
、 MIN
、 MAX
、 AVERAGE
などの DAX 集計関数を使用して、クエリ時にスカラー値の結果を生成します (値はモデルに格納されません)。 メジャー式には、シンプルな列集計から、フィルター コンテキストやリレーションシップの伝達をオーバーライドする、より高度な数式までさまざまなものがあります。 詳細については、Power BI Desktop の DAX の基本を参照してください。Sales Amount
列は、可能な集計の種類ごとにメジャーを作成しなくても、さまざまな方法 (合計、カウント、平均、中央値、最小、最大など) で集計できます。Data ペインでは、明示的なメジャーは電卓アイコンで表され、暗黙的なメジャーはシグマ記号 (∑) で表されます。
ただし、単純な列レベルの要約であっても、メジャーを作成する理由は 3 つあります。
レポート作成者が 多次元式 (MDX) を使用してセマンティック モデルにクエリを実行することがわかっている場合、モデルには明示的なメジャーが含まれている必要があります。 これは、MDX では列値の要約を実現できないためです。 特に、MDX は Excel で Analyze を実行するときに使用されます ピボットテーブルは MDX クエリを発行するためです。
レポート作成者が MDX クエリ デザイナーを使用して Power BI のページ分割されたレポートを作成することがわかっている場合は、セマンティック モデルに明示的なメジャーを含める必要があります。 サーバー集計をサポートするのは、MDX クエリ デザイナーのみです。 そのため、レポート作成者が (ページ分割されたレポート エンジンではなく) Power BI によって評価されるメジャーが必要な場合には、MDX クエリ デザイナーを使用する必要があります。
レポート作成者が特定の方法で列を集計する方法を制御する場合。 たとえば、リセラーの売上 Unit Price
列 (単位単価を表します) は、特定の集計関数を使用してのみ集計できます。 合計するべきではありませんが、min、max、average などの他の集計関数を使用して集計するのが適切です。 この場合、modeler は Unit Price
列を非表示にし、すべての適切な集計関数のメジャーを作成できます。
この設計手法は、Power BI サービスで作成されたレポートと、Q&A に適しています。 ただし、Power BI Desktop live 接続では レポート作成者が Data ペインに非表示フィールドを表示できるため、この設計アプローチが回避される可能性があります。
代理キーは、スター スキーマ モデリングをサポートするためにテーブルに追加する一意の識別子です。 定義上、ソース データに定義されたり、格納されたりすることはありません。 通常、代理キーは、ディメンション テーブルの各行に一意の識別子を提供するために、リレーショナル データ ウェアハウスのディメンション テーブルに追加されます。
Power BI セマンティック モデルのリレーションシップは、1 つのテーブル内の 1 つの一意の列に基づいており、フィルターは別のテーブルの 1 つの列に反映されます。 セマンティック モデルのディメンション テーブルに 1 つの一意の列が含まれていない場合は、リレーションシップの "一" 側になるように一意の識別子を追加する必要があります。 Power BI Desktop では、Power Query index 列を追加することで、この要件を満たすことができます。
インデックス列も追加できるように、このクエリを "多" 側のクエリと結合する必要があります。 これらのクエリをセマンティック モデルに読み込むと、モデル テーブル間に一対多リレーションシップを作成できます。
スノーフレーク ディメンションは、単一のビジネス エンティティの正規化されたテーブルのセットです。 たとえば、Adventure Works では、商品がカテゴリとサブカテゴリ別に分類されます。 製品がサブカテゴリに割り当てられ、その後、サブカテゴリがカテゴリに割り当てられます。 Adventure Works リレーショナル データ ウェアハウスでは、製品ディメンションは正規化され、 DimProductCategory
、 DimProductSubcategory
、 DimProduct
の 3 つの関連テーブルに格納されます。
想像力を働かせれば、スノーフレーク設計を形成する、ファクト テーブルから外に向けて配置された正規化テーブルを思い描くことができます。
Power BI Desktop では、スノーフレーク ディメンションデザインを模倣するか (ソース データが行うためなど)、ソース テーブルを組み合わせて単一の非正規化モデル テーブルを形成することもできます。 一般に、単一のモデル テーブルの利点は、複数のモデル テーブルの利点を上回ります。 最適な決定は、データの量とモデルの使いやすさの要件によって異なる場合があります。
スノーフレーク ディメンションの設計を模倣するように選択した場合:
単一のモデル テーブルに統合するように選択した場合は、ディメンションの粒度が最も高いものと低いものを含む階層を定義することもできます。 場合によっては、冗長な非正規化データを格納すると、特に大きなディメンション テーブルの場合に、モデルのストレージ サイズが増加する可能性があります。
大幅に変化するディメンション (SCD) は、ディメンション メンバーの変更を時間の経過と同時に適切に管理するものです。 これは、ビジネス エンティティの値が計画外の方法で時間の経過と 低い に変化する場合に適用されます。 SCD の良い例として、顧客ディメンションがあります。これは、メール アドレスや電話番号などの連絡先の詳細列が変更される頻度が低いためです。 これに対し、一部のディメンションは と見なされ 株式の市場価格のようにディメンション属性が頻繁に変更されたときに変化します。 このような場合の一般的な設計手法は、急速に変化する属性値をファクト テーブル メジャーに格納することです。
スター スキーマの設計理論では、次の 2 つの一般的な SCD の種類を参照します: 種類 1 と種類 2。 ディメンション テーブルには、種類 1 または種類 2 を指定することも、異なる列に対して両方の型を同時にサポートすることもできます。
タイプ 1 の SCD では常に最新の値が反映され、ソース データの変更が検出されると、ディメンション テーブルのデータが上書きされます。 この設計手法は、顧客の電子メール アドレスや電話番号などの補足値を格納する列では一般的なものです。 顧客の電子メール アドレスまたは電話番号が変更されると、ディメンション テーブルで顧客の行が新しい値で更新されます。 顧客が常にこの連絡先情報を持っているかのように見えます。
Power BI モデル ディメンション テーブルの非増分更新では、Type 1 SCD の結果が得られます。 テーブル データを更新し、確実に最新の値が読み込まれるようにします。
タイプ 2 の SCD は、ディメンション メンバーのバージョン管理をサポートしています。 ソース システムがバージョンを格納しない場合、通常は、変更を検出し、ディメンション テーブルの変更を適切に管理するデータ ウェアハウスの読み込みプロセスです。 この場合、ディメンション テーブルでは、ディメンション メンバーの "バージョン" への一意の参照を提供するために、代理キーを使用する必要があります。 また、バージョンの有効期間の日付範囲 (StartDate
や EndDate
など) を定義する列と、場合によってはフラグ列 (IsCurrent
など) が含まれます。これらは、現在のディメンション メンバーで簡単にフィルター処理するためのものです。
たとえば、Adventure Works では、すべての営業担当者が販売地域に割り当てられます。 販売員が地域を再配置した場合、新しいバージョンの販売員を作成し、履歴ファクトを元の地域に関連付けたままにする必要があります。 販売員ごとの売上の正確な履歴分析をサポートするには、ディメンション テーブルに販売員のバージョンと、それらに関連付けられている地域 (複数可) を格納する必要があります。 テーブルには、有効期間を定義するための開始日と終了日の値も含まれている必要があります。 現在のバージョンでは、行が現在のバージョンであることを示す空の終了日 (または 12/31/9999) が定義されている場合があります。 ビジネス キー (このインスタンスでは従業員 ID) が一意ではないためテーブルには surrogate キーも必要です。
ソース データにバージョンが格納されていない場合は、中間システム (データ ウェアハウスなど) を使用して変更を検出し、格納する必要があることを理解しておくことが重要です。 テーブルの読み込みプロセスでは、既存のデータを保持し、変更を検出する必要があります。 変更が検出された場合、テーブルの読み込みプロセスで現在のバージョンを期限切れにする必要があります。 EndDate
値を更新し、前の EndDate
値から始まる StartDate
値を使用して新しいバージョンを挿入することで、これらの変更が記録されます。 また、関連するファクトでは、時間ベースの参照を使用して、ファクトの日付に関連するディメンション キー値を取得する必要があります。 Power BI セマンティック モデルでは Power Query を使用するため、この結果を生成できません。 しかし、事前に読み込まれた SCD の種類 2 のディメンション テーブルからデータを読み込むことはできます。
ヒント
Fabric ウェアハウスに Type 2 SCD ディメンション テーブルを実装する方法については、「 変更履歴の管理を参照してください。
Power BI セマンティック モデルでは、変更に関係なく、メンバーの履歴データと、メンバーの特定の状態を表すバージョンのメンバーに対するクエリをサポートする必要があります。 この設計では、Adventure Works のコンテキストで、割り当てられた販売地域に関係なく、販売員、または販売員の特定のバージョンに対してクエリを実行できます。
この要件を達成するには、Power BI セマンティック モデル ディメンション テーブルに、営業担当者をフィルター処理するための列と、特定のバージョンの販売員をフィルター処理するための別の列を含める必要があります。 バージョン列には、 David Campbell (12/15/2008-06/26/2019)
や David Campbell (06/27/2019-Current)
など、あいまいでない説明が用意されている必要があります。 また、レポートの作成者やコンシューマーに SCD 種類 2 の基本と、正しいフィルターを適用して適切なレポート設計を実現する方法について教えることが重要です。
ビジュアルをバージョン レベルにドリルダウンできる階層を含めるのは、設計上の良い方法です。
多様ディメンションは、関連するファクトを異なる方法でフィルター処理できるディメンションです。 たとえば、Adventure Works では、日付ディメンション テーブルはリセラーの売上ファクトと 3 つのリレーションシップを持ちます。 同じディメンション テーブルを使用して、注文日、出荷日、または納品日でファクトをフィルター処理することができます。
データ ウェアハウスで、受け入れられる設計手法は、単一の日付ディメンション テーブルを定義することです。 クエリ時には、日付ディメンションの "ロール" が、テーブルの結合に使用するファクト列によって確立されます。 たとえば、注文日別に売上を分析する場合、テーブルの結合は再販業者の販売注文日列に関連します。
Power BI セマンティック モデルでは、2 つのテーブル間に複数のリレーションシップを作成することで、この設計を模倣できます。 Adventure Works の例では、日付および再販業者の販売テーブルに 3 つのリレーションシップがあります。
この設計は可能ですが、2 つの Power BI セマンティック モデル テーブル間に アクティブ リレーションシップは 1 つだけ存在できます。 残りのすべてのリレーションシップは非アクティブに設定する必要があります。 アクティブなリレーションシップが 1 つあるということは、日付からリセラーの売上への既定のフィルター伝達があることを意味します。 この場合、アクティブなリレーションシップは、レポートで使用される最も一般的なフィルターに設定されます。Adventure Works では、注文日のリレーションシップです。
非アクティブなリレーションシップを使用する唯一の方法は、USERELATIONSHIP 関数を使用する DAX 式を定義することです。 この例では、モデル開発者は、出荷日と納品日で再販業者の販売を分析できるようにするためのメジャーを作成する必要があります。 この作業は、特に再販業者テーブルで多くのメジャーが定義されているときに、面倒な場合があります。 また、 Data ペインが作成され、メジャーが過剰に存在します。 他にも制限があります。
これらの制限を克服するために、一般的な Power BI モデリング手法は、ロールプレイング インスタンスごとにディメンション テーブルを作成することです。 各ディメンション テーブルは、power Query を使用して参照クエリとして、または DAX を使用して計算されたテーブルとして作成できます。 モデルには、 Date
テーブル、 Ship Date
テーブル、および Delivery Date
テーブルを含めることができます。各テーブルには、それぞれのリセラー販売テーブル列との 1 つのアクティブなリレーションシップがあります。
この設計手法では、異なる日付ロールに対して複数のメジャーを定義する必要はなく、異なる日付ロールで同時にフィルター処理を行うことができます。 ただし、この設計アプローチで支払う小さな価格は、日付ディメンション テーブルの重複が発生し、モデルのストレージ サイズが増加するという点です。 通常、ディメンション テーブルにはファクト テーブルに対して相対的に格納される行数が少ないため、問題になることはほとんどありません。
各ロールのモデル ディメンション テーブルを作成するときは、適切な設計プラクティスに従うことをお勧めします。
Year
列を持つことは可能ですが (列名はテーブル内で一意です)、既定のビジュアル タイトルでは自己記述できません。 Ship Date
テーブルに Ship Year
という名前の年の列が含まれるように、各ディメンション ロール テーブルの列の名前を変更することを検討してください。Date
など、一般的な名前のテーブルがモデルに含まれている場合に重要です。 このテーブルにリセラー販売注文日列とのアクティブなリレーションシップがある場合は、 Filters reseller sales by order date
などのテーブルの説明を指定することを検討してください。詳細については、「アクティブなリレーションシップと非アクティブなリレーションシップのガイダンス」をご覧ください。
ジャンク ディメンションは、特に少数の属性 (おそらく 1 つ) で構成されているディメンションが多数存在し、これらの属性の値が少ない場合に便利です。 適切な候補には、注文状態列や、性別や年齢グループなどの顧客の人口統計列が含まれます。
迷惑ディメンションの設計目標は、多数の small ディメンションを 1 つのディメンションに統合して、モデルのストレージ サイズを小さくし、さらに少ないモデル テーブルを表示して Data ウィンドウの乱雑さを減らすことです。
迷惑ディメンション テーブルは、通常、すべてのディメンション属性メンバーのデカルト積であり、各行を一意に識別するための surrogate キー 列があります。 データ ウェアハウスでディメンションを構築することができます。あるいは、完全外部クエリ結合を実行してから、代理キー (インデックス列) を追加するクエリを作成するための Power Query を使用することもできます。
このクエリは、ディメンション テーブルとしてモデルに読み込みます。 また、"一対多" モデルリレーションシップの作成をサポートするために、インデックス列がモデルに読み込まれるように、このクエリをファクト クエリとマージする必要があります。
生成ディメンションは、フィルター処理に必要なファクト テーブルの属性を参照します。 Adventure Works の再販業者の販売注文番号が良い例です。 この例では、この 1 つの列だけで構成される独立したテーブルを作成しても意味がありません。これは、モデルのストレージ サイズが大きくなり、 Data ペインが乱雑になるためです。
Power BI セマンティック モデルでは、販売注文番号の列をファクト テーブルに追加して、販売注文番号によるフィルター処理またはグループ化を可能にすることが適切な場合があります。 以前に導入されたルールでは、テーブルの種類を混在させるべきではありません (一般に、モデル テーブルはディメンションまたはファクトである必要があります)。
ただし、Adventure Works リセラーの販売テーブルに注文番号 と 注文明細行番号の列があり、フィルター処理に必要な場合は、退化ディメンション テーブルを作成することをお勧めします。 詳細については、一対一のリレーションシップのガイダンス (逆ディメンション) に関する記事をご覧ください。
ファクトレス ファクト テーブルには、メジャー列は含まれません。 ディメンション キーのみが含まれます。
ファクトレス ファクト テーブルには、ディメンション キーによって定義された観測値を格納できます。 たとえば、特定の日時に、特定の顧客が Web サイトにサインインしたとします。 ファクトレス ファクト テーブルの行をカウントするメジャーを定義して、サインインしたタイミングと顧客数の分析を実行できます。
ファクトレスファクト テーブルのより説得力のある用途は、ディメンション間のリレーションシップを格納することです。これは、多対多ディメンションリレーションシップを定義するために推奨される Power BI セマンティック モデル設計アプローチです。 多対多ディメンション リレーションシップの設計では、ファクトレス ファクト テーブルは "ブリッジング テーブル" と呼ばれます。
たとえば、販売者を 1 つまたは複数の販売地域に割り当てることができるとします。 ブリッジング テーブルは、販売員キーと地域キーという 2 つの列で構成されるファクトレス ファクト テーブルとして設計されます。 両方の列に重複する値を格納できます。
この多対多の設計手法は十分に立証されており、ブリッジング テーブルがなくても実現できます。 しかし、2 つのディメンションを関連付ける場合は、ブリッジング テーブル手法がベスト プラクティスと見なされます。 詳細については、多対多のリレーションシップのガイダンス (2 つのディメンションの種類のテーブルを関連付ける) に関する記事をご覧ください。
スター スキーマの設計または Power BI セマンティック モデルの設計の詳細については、次の記事を参照してください。
events
3月31日 23時 - 4月2日 23時
究極の Microsoft Fabric、Power BI、SQL、AI コミュニティ主導のイベント。 2025 年 3 月 31 日から 4 月 2 日。
今すぐ登録トレーニング
モジュール
Power BI でのセマンティック モデルの設計 - Training
Power BI で複雑なセマンティック モデルを作成するプロセスは簡単です。 データが複数のトランザクション システムから生成される場合、あっという間に数十ものテーブルを処理しなければならなくなることがあります。 優れたセマンティック モデルを構築するには、無秩序な状態を簡略化する必要があります。 スター スキーマは、セマンティック モデルを簡略化する 1 つの方法です。このモジュールでは、その用語と実装について学習します。 適切なデータ粒度を選択することが Power BI レポートのパフォーマンスと使いやすさにとって重要である理由についても学習します。 最後の点として、Power BI セマンティック モデルのパフォーマンス向上について学習します。
認定資格
Microsoft Certified: Power BI Data Analyst Associate - Certifications
Microsoft Power BI でデータをモデル化、視覚化、分析するためのビジネス要件と技術要件に沿った方法とベスト プラクティスを示します。