スター スキーマと Power BI での重要性を理解するUnderstand star schema and the importance for Power BI

この記事は、Power BI Desktop データ モデラーを対象としています。This article targets Power BI Desktop data modelers. スター スキーマの設計と、パフォーマンスおよび使いやすさのために最適化された Power BI データ モデルの開発とのその関連性について説明します。It describes star schema design and its relevance to developing Power BI data models optimized for performance and usability.

この記事は、スター スキーマの設計に関する完全な説明を提供するためのものではありません。This article isn't intended to provide a complete discussion on star schema design. 詳細については、次のような出版されているコンテンツを直接参照してください: The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (データ ウェアハウス ツールキット: ディメンション モデリングに関する決定的なガイド) (2013 年第 3 版) (著者: Ralph Kimball 他)。For more details, refer directly to published content, like The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd edition, 2013) by Ralph Kimball et al.

スター スキーマの概要Star schema overview

スター スキーマは、リレーショナル データ ウェアハウスで広く採用されている成熟したモデリング手法です。Star schema is a mature modeling approach widely adopted by relational data warehouses. モデラーは、モデル テーブルを "ディメンション" または "ファクト" として分類する必要があります。It requires modelers to classify their model tables as either dimension or fact.

ディメンション テーブルでは、ビジネス エンティティ (モデル化の "対象") について説明します。Dimension tables describe business entities—the things you model. エンティティには、時間自体を含め、製品、人、場所および概念を含めることができます。Entities can include products, people, places, and concepts including time itself. スター スキーマに存在する最も一貫性のあるテーブルは、日付ディメンション テーブルです。The most consistent table you'll find in a star schema is a date dimension table. ディメンション テーブルには、一意の識別子として機能する 1 つのキー列 (または複数の列) と説明列が含まれています。A dimension table contains a key column (or columns) that acts as a unique identifier, and descriptive columns.

ファクト テーブルには観測値やイベントが格納されます。ファクト テーブルには、販売注文、在庫量、為替レート、気温などがあります。ファクト テーブルには、ディメンション テーブルに関連するディメンション キー列と、数値メジャー列が含まれています。Fact tables store observations or events, and can be sales orders, stock balances, exchange rates, temperatures, etc. A fact table contains dimension key columns that relate to dimension tables, and numeric measure columns. ディメンション キー列によってファクト テーブルの "次元" が決まり、ディメンション キーの値によってファクト テーブルの "粒度" が決まります。The dimension key columns determine the dimensionality of a fact table, while the dimension key values determine the granularity of a fact table. たとえば、DateProductKey という 2 つのディメンション キー列がある販売目標を格納するように設計されたファクト テーブルについて考えてみます。For example, consider a fact table designed to store sale targets that has two dimension key columns Date and ProductKey. このテーブルに 2 つのディメンションがあることは簡単に理解できます。It's easy to understand that the table has two dimensions. しかし、粒度は、ディメンション キーの値を考慮せずに決定することはできません。The granularity, however, can't be determined without considering the dimension key values. この例では、Date 列に格納されている値が各月の最初の日であると考えます。In this example, consider that the values stored in the Date column are the first day of each month. この場合、粒度は月単位の製品レベルとなります。In this case, the granularity is at month-product level.

一般に、ディメンション テーブルには比較的少数の行が含まれます。Generally, dimension tables contain a relatively small number of rows. 一方、ファクト テーブルには非常に多くの行を含めることができ、時間の経過と共に増加し続ける場合があります。Fact tables, on the other hand, can contain a very large number of rows and continue to grow over time.

スター スキーマの図

スター スキーマの Power BI モデルとの関連性Star schema relevance to Power BI models

この記事で紹介するスター スキーマの設計と関連する多くの概念は、パフォーマンスと使いやすさのために最適化された Power BI モデルの開発と非常に関連性があります。Star schema design and many related concepts introduced in this article are highly relevant to developing Power BI models that are optimized for performance and usability.

各 Power BI レポートのビジュアルで、Power BI モデルに送信されるクエリが生成されるとします (Power BI サービスでデータセットが呼び出される)。Consider that each Power BI report visual generates a query that is sent to the Power BI model (which the Power BI service calls a dataset). これらのクエリは、モデル データのフィルター処理、グループ化、および集計に使用されます。These queries are used to filter, group, and summarize model data. 適切に設計されたモデルは、フィルター処理とグループ化用のテーブルと、集計用のテーブルを提供するモデルです。A well-designed model, then, is one that provides tables for filtering and grouping, and tables for summarizing. この設計は、スター スキーマの原則に十分適しています。This design fits well with star schema principles:

  • ディメンション テーブルでは、"フィルター処理" と "グループ化" がサポートされますDimension tables support filtering and grouping
  • ファクト テーブルでは "集計" がサポートされますFact tables support summarization

テーブルの種類をディメンションまたはファクトとして構成するためにモデラーによって設定されるテーブル プロパティはありません。There's no table property that modelers set to configure the table type as dimension or fact. 実際には、これはモデル リレーションシップによって決定されます。It's in fact determined by the model relationships. モデル リレーションシップによって、2 つのテーブル間のフィルター伝達パスが確立されます。これは、テーブルの種類を決定するリレーションシップのカーディナリティ プロパティです。A model relationship establishes a filter propagation path between two tables, and it's the Cardinality property of the relationship that determines the table type. 一般的なリレーションシップのカーディナリティは、"一対多" またはその逆の "多対一" です。A common relationship cardinality is one-to-many or its inverse many-to-one. "一" 側は常にディメンションの種類のテーブルであり、一方、"多" 側は常にファクトの種類のテーブルとなります。The "one" side is always a dimension-type table while the "many" side is always a fact-type table. リレーションシップについて詳しくは、Power BI Desktop でのモデル リレーションシップに関する記事をご覧ください。For more information about relationships, see Model relationships in Power BI Desktop.

スター スキーマの概念

適切に構造化されたモデル設計には、ディメンションの種類のテーブルまたはファクトの種類のテーブルのいずれかであるテーブルが含まれる必要があります。A well-structured model design should include tables that are either dimension-type tables or fact-type tables. 単一のテーブルに 2 つの種類を混在させないようにしてください。Avoid mixing the two types together for a single table. また、適所に正しいリレーションシップがある正しい数のテーブルを提供するよう心がけることをお勧めします。We also recommend that you should strive to deliver the right number of tables with the right relationships in place. また、ファクトの種類のテーブルでは常に一貫した粒度でデータを読み込むことが重要です。It's also important that fact-type tables always load data at a consistent grain.

最後に、最適なモデル設計は科学と芸術にまたがっていることを理解することが重要です。Lastly, it's important to understand that optimal model design is part science and part art. 場合によっては、そうすることが妥当な場合、適切なガイダンスを守らないこともあります。Sometimes you can break with good guidance when it makes sense to do so.

Power BI モデルに適用できるスター スキーマの設計に関連する概念は、他にも多数あります。There are many additional concepts related to star schema design that can be applied to a Power BI model. たとえば、次のような概念です。These concepts include:

メジャーMeasures

スター スキーマの設計では、メジャーは集計する値を格納するファクト テーブルの列です。In star schema design, a measure is a fact table column that stores values to be summarized.

Power BI モデルでは、メジャーの定義は異なりますが、似ています。In a Power BI model, a measure has a different—but similar—definition. これは、集計を実現する Data Analysis Expressions (DAX) で記述された数式です。It's a formula written in Data Analysis Expressions (DAX) that achieves summarization. メジャー式では、多くの場合、SUM、MIN、MAX、AVERAGE などの DAX 集計関数を利用して、クエリ時にスカラー値の結果を生成します (値がモデルに格納されることはありません)。Measure expressions often leverage DAX aggregation functions like SUM, MIN, MAX, AVERAGE, etc. to produce a scalar value result at query time (values are never stored in the model). メジャー式には、シンプルな列集計から、フィルター コンテキストやリレーションシップの伝達をオーバーライドする、より高度な数式までさまざまなものがあります。Measure expression can range from simple column aggregations to more sophisticated formulas that override filter context and/or relationship propagation. 詳細については、「Power BI Desktop における DAX の基本事項」の記事をお読みください。For more information, read the DAX Basics in Power BI Desktop article.

Power BI モデルでは集計を実現するための 2 つ目の方法がサポートされていることを理解しておくことが重要です。It's important to understand that Power BI models support a second method for achieving summarization. すべての列 (通常は数値列) は、レポートのビジュアルまたは Q&A で集計できます。Any column—and typically numeric columns—can be summarized by a report visual or Q&A. これらの列は_暗黙のメジャー_と呼ばれます。These columns are referred to as implicit measures. メジャーを作成する必要がない多くの実例と同じように、モデル開発者にとって便利です。They offer a convenience for you as a model developer, as in many instances you do not need to create measures. たとえば、Adventure Works の再販業者の販売の [売上高] 列は、考えられる集計の種類ごとにメジャーを作成することなく、さまざまな方法 (合計、カウント、平均、中央値、最小、最大など) で集計できます。For example, the Adventure Works reseller sales Sales Amount column could be summarized in numerous ways (sum, count, average, median, min, max, etc.), without the need to create a measure for each possible aggregation type.

フィールド リストのアイコンの例

ただし、シンプルな列レベルの集計の場合でも、メジャーを作成する説得力のある 3 つの理由があります。However, there are three compelling reasons for you to create measures, even for simple column-level summarizations:

  • ご自分のレポート作成者が多次元式 (MDX) を使用してモデルに対してクエリを実行することがわかっている場合は、モデルに_明示的メジャー_を含める必要があります。When you know your report authors will query the model by using Multidimensional Expressions (MDX), the model must include explicit measures. 暗黙のメジャーは DAX 式で定義されます。Explicit measures are defined by using DAX. この設計手法は、MDX を使用し、Power BI データセットにクエリが実行されるときに大いに関連します。MDX では、列の値を合計できないからです。This design approach is highly relevant when a Power BI dataset is queried by using MDX, because MDX can't achieve summarization of column values. 特に、MDX は Excel で分析を実行するときに使用されます (ピボットテーブルから MDX クエリが発行されるため)。Notably, MDX will be used when performing Analyze in Excel, because PivotTables issue MDX queries.
  • レポート作成者が MDX クエリ デザイナーを使用して Power BI ページ分割されたレポートを作成することがわかっている場合は、モデルに明示的なメジャーを含める必要があります。When you know your report authors will create Power BI paginated reports using the MDX query designer, the model must include explicit measures. サーバー集計をサポートするのは、MDX クエリ デザイナーのみです。Only the MDX query designer supports server aggregates. そのため、レポート作成者が (ページ分割されたレポート エンジンではなく) Power BI によって評価されるメジャーが必要な場合には、MDX クエリ デザイナーを使用する必要があります。So, if report authors need to have measures evaluated by Power BI (instead of by the paginated report engine), they must use the MDX query designer.
  • 確実にレポート作成者が特定の方法でのみ列を集計できるようにする必要がある場合。When you need to ensure that your report authors can only summarize columns in specific ways. たとえば、再販業者の販売の [単価] 列 (単位あたりのレートを表す) を集計できますが、それは特定の集計関数を使用する場合のみです。For example, the reseller sales Unit Price column (which represents a per unit rate) can be summarized, but only by using specific aggregation functions. これは、合計することはできませんが、他の集計関数 (min、max、average など) を使用して集計するには適しています。この場合、モデラーは [単価] 列を非表示にして、適切なすべての集計関数のメジャーを作成できます。It should never be summed, but it's appropriate to summarize by using other aggregation functions like min, max, average, etc. In this instance, the modeler can hide the Unit Price column, and create measures for all appropriate aggregation functions.

この設計手法は、Power BI サービスで作成されたレポートと、Q&A に適しています。This design approach works well for reports authored in the Power BI service and for Q&A. ただし、Power BI Desktop のライブ接続を使用すれば、レポート作成者は [フィールド] ウィンドウで非表示フィールドを表示できます。これにより、この設計手法が回避される可能性があります。However, Power BI Desktop live connections allow report authors to show hidden fields in the Fields pane, which can result in circumventing this design approach.

代理キーSurrogate keys

代理キーは、スター スキーマ モデリングをサポートするためにテーブルに追加する一意の識別子です。A surrogate key is a unique identifier that you add to a table to support star schema modeling. 定義上、ソース データに定義されたり、格納されたりすることはありません。By definition, it's not defined or stored in the source data. 通常、代理キーは、ディメンション テーブルの各行に一意の識別子を提供するために、リレーショナル データ ウェアハウスのディメンション テーブルに追加されます。Commonly, surrogate keys are added to relational data warehouse dimension tables to provide a unique identifier for each dimension table row.

Power BI モデルのリレーションシップは、1 つのテーブル内の単一の一意の列に基づいており、フィルターは別のテーブルの単一の列に伝達されます。Power BI model relationships are based on a single unique column in one table, which propagates filters to a single column in a different table. モデル内のディメンションの種類のテーブルに単一の一意の列が含まれていない場合は、リレーションシップの "一" の側になるように一意の識別子を追加する必要があります。When a dimension-type table in your model doesn't include a single unique column, you must add a unique identifier to become the "one" side of a relationship. Power BI Desktop では、Power Query のインデックス列を作成することによって、この要件を簡単に実現できます。In Power BI Desktop, you can easily achieve this requirement by creating a Power Query index column.

Power Query ツールバーでインデックス列を作成する

インデックス列も追加できるように、このクエリを "多" 側のクエリと結合する必要があります。You must merge this query with the "many"-side query so that you can add the index column to it also. これらのクエリをモデルに読み込むと、モデル テーブル間に一対多のリレーションシップを作成できます。When you load these queries to the model, you can then create a one-to-many relationship between the model tables.

スノーフレーク ディメンションSnowflake dimensions

スノーフレーク ディメンションは、単一のビジネス エンティティの正規化されたテーブルのセットです。A snowflake dimension is a set of normalized tables for a single business entity. たとえば、Adventure Works では、商品がカテゴリとサブカテゴリ別に分類されます。For example, Adventure Works classifies products by category and subcategory. カテゴリがサブカテゴリに割り当てられ、その後、製品がサブカテゴリに割り当てられます。Categories are assigned to subcategories, and products are in turn assigned to subcategories. Adventure Works のリレーショナル データ ウェアハウスでは、製品ディメンションが正規化され、次の 3 つの関連テーブルに格納されます: DimProductCategoryDimProductSubcategory、および DimProductIn the Adventure Works relational data warehouse, the product dimension is normalized and stored in three related tables: DimProductCategory, DimProductSubcategory, and DimProduct.

想像力を働かせれば、スノーフレーク設計を形成する、ファクト テーブルから外に向けて配置された正規化テーブルを思い描くことができます。If you use your imagination, you can picture the normalized tables positioned outwards from the fact table, forming a snowflake design.

スノーフレーク ダイアグラムの例

Power BI Desktop では、スノーフレーク ディメンションの設計を模倣したり (おそらく、ソース データで行われているため)、ソース テーブルを単一のモデル テーブルに統合 (非正規化) したりするように選択できます。In Power BI Desktop, you can choose to mimic a snowflake dimension design (perhaps because your source data does) or integrate (denormalize) the source tables into a single model table. 一般に、単一のモデル テーブルの利点は、複数のモデル テーブルの利点を上回ります。Generally, the benefits of a single model table outweigh the benefits of multiple model tables. 最適な決定は、データの量とモデルの使いやすさの要件によって異なる場合があります。The most optimal decision can depend on the volumes of data and the usability requirements for the model.

スノーフレーク ディメンションの設計を模倣するように選択した場合:When you choose to mimic a snowflake dimension design:

  • Power BI によってより多くのテーブルが読み込まれるため、ストレージとパフォーマンスの観点からは効率が悪くなります。Power BI loads more tables, which is less efficient from storage and performance perspectives. これらのテーブルには、モデルのリレーションシップをサポートするための列を含める必要があります。これにより、モデルのサイズがより大きくなる可能性があります。These tables must include columns to support model relationships, and it can result in a larger model size.
  • より長いリレーションシップのフィルター伝達チェーンを走査する必要があり、これにより、単一のテーブルに適用されるフィルターよりも効率が悪くなる可能性があります。Longer relationship filter propagation chains will need to be traversed, which will likely be less efficient than filters applied to a single table.
  • [フィールド] ウィンドウには、レポート作成者に対してより多くのモデル テーブルが示されます。これにより、特にスノーフレーク ディメンション テーブルに 1 つまたは 2 つの列のみが含まれている場合は、直感的な操作が少なくなる可能性があります。The Fields pane presents more model tables to report authors, which can result in a less intuitive experience, especially when snowflake dimension tables contain just one or two columns.
  • テーブルにまたがる階層を作成することはできません。It's not possible to create a hierarchy that spans the tables.

単一のモデル テーブルに統合するように選択した場合は、ディメンションの粒度が最も高いものと低いものを含む階層を定義することもできます。When you choose to integrate into a single model table, you can also define a hierarchy that encompasses the highest and lowest grain of the dimension. 場合によっては、冗長な非正規化データを格納すると、特に非常に大きなディメンション テーブルでは、モデル ストレージのサイズが増加する可能性があります。Possibly, the storage of redundant denormalized data can result in increased model storage size, particularly for very large dimension tables.

ディメンション内の階層

緩やかに変化するディメンションSlowly changing dimensions

緩やかに変化するディメンション (SCD) は、時間の経過に伴うディメンション メンバーの変化を適切に管理するものです。A slowly changing dimension (SCD) is one that appropriately manages change of dimension members over time. これは、ビジネス エンティティの値が時間の経過と共に、また、アドホックに変化する場合に適用されます。It applies when business entity values change over time, and in an ad hoc manner. _緩やかに_変化するディメンションの良い例として、顧客ディメンション (具体的には、電子メール アドレスや電話番号などの連絡先詳細列) があります。A good example of a slowly changing dimension is a customer dimension, specifically its contact detail columns like email address and phone number. これに対して、株価など、ディメンションの属性が頻繁に変化する場合、一部のディメンションは_急速に_変化すると見なされます。In contrast, some dimensions are considered to be rapidly changing when a dimension attribute changes often, like a stock's market price. このような場合の一般的な設計手法は、急速に変化する属性値をファクト テーブル メジャーに格納することです。The common design approach in these instances is to store rapidly changing attribute values in a fact table measure.

スター スキーマの設計理論では、次の 2 つの一般的な SCD の種類を参照します: 種類 1 と種類 2。Star schema design theory refers to two common SCD types: Type 1 and Type 2. ディメンションの種類のテーブルは、種類 1 や種類 2 の場合もあれば、異なる列に対して両方の種類が同時にサポートされる場合もあります。A dimension-type table could be Type 1 or Type 2, or support both types simultaneously for different columns.

種類 1 の SCDType 1 SCD

種類 1SCD では常に最新の値が反映され、ソース データの変更が検出されると、ディメンション テーブルのデータが上書きされます。A Type 1 SCD always reflects the latest values, and when changes in source data are detected, the dimension table data is overwritten. この設計手法は、顧客の電子メール アドレスや電話番号などの補足値を格納する列では一般的なものです。This design approach is common for columns that store supplementary values, like the email address or phone number of a customer. 顧客の電子メール アドレスまたは電話番号が変更されると、ディメンション テーブルで顧客の行が新しい値で更新されます。When a customer email address or phone number changes, the dimension table updates the customer row with the new values. 顧客が常にこの連絡先情報を持っているかのように見えます。It's as if the customer always had this contact information.

Power BI モデルのディメンションの種類のテーブルの非増分更新では、種類 1 の SCD の結果が得られます。A non-incremental refresh of a Power BI model dimension-type table achieves the result of a Type 1 SCD. テーブル データを更新し、確実に最新の値が読み込まれるようにします。It refreshes the table data to ensure the latest values are loaded.

種類 2 の SCDType 2 SCD

種類 2SCD では、ディメンション メンバーのバージョン管理がサポートされます。A Type 2 SCD supports versioning of dimension members. ソース システムにバージョンが格納されていない場合、これは通常、変更を検出し、ディメンション テーブルの変更を適切に管理するデータ ウェアハウスの読み込みプロセスとなります。If the source system doesn't store versions, then it's usually the data warehouse load process that detects changes, and appropriately manages the change in a dimension table. この場合、ディメンション テーブルでは、ディメンション メンバーの "バージョン" への一意の参照を提供するために、代理キーを使用する必要があります。In this case, the dimension table must use a surrogate key to provide a unique reference to a version of the dimension member. また、バージョンの有効期間の日付範囲 (StartDateEndDate など) を定義する列と、場合によってはフラグ列 (IsCurrent など) が含まれます。これらは、現在のディメンション メンバーで簡単にフィルター処理するためのものです。It also includes columns that define the date range validity of the version (for example, StartDate and EndDate) and possibly a flag column (for example, IsCurrent) to easily filter by current dimension members.

たとえば、Adventure Works では販売員を販売地域に割り当てます。For example, Adventure Works assigns salespeople to a sales region. 販売員が地域を再配置した場合、新しいバージョンの販売員を作成し、履歴ファクトを元の地域に関連付けたままにする必要があります。When a salesperson relocates region, a new version of the salesperson must be created to ensure that historical facts remain associated with the former region. 販売員ごとの売上の正確な履歴分析をサポートするには、ディメンション テーブルに販売員のバージョンと、それらに関連付けられている地域 (複数可) を格納する必要があります。To support accurate historic analysis of sales by salesperson, the dimension table must store versions of salespeople and their associated region(s). テーブルには、有効期間を定義するための開始日と終了日の値も含まれている必要があります。The table should also include start and end date values to define the time validity. 現在のバージョンでは、空の終了日 (または 12/31/9999) を定義できます。これは、その行が現在のバージョンであることを示します。Current versions may define an empty end date (or 12/31/9999), which indicates that the row is the current version. ビジネス キー (この場合は、従業員 ID) が一意ではないため、テーブルで代理キーも定義する必要があります。The table must also define a surrogate key because the business key (in this instance, employee ID) won't be unique.

ソース データにバージョンが格納されていない場合は、中間システム (データ ウェアハウスなど) を使用して変更を検出し、格納する必要があることを理解しておくことが重要です。It's important to understand that when the source data doesn't store versions, you must use an intermediate system (like a data warehouse) to detect and store changes. テーブルの読み込みプロセスでは、既存のデータを保持し、変更を検出する必要があります。The table load process must preserve existing data and detect changes. 変更が検出された場合、テーブルの読み込みプロセスで現在のバージョンを期限切れにする必要があります。When a change is detected, the table load process must expire the current version. EndDate 値を更新し、前の EndDate 値から始まる StartDate 値を使用して新しいバージョンを挿入することで、これらの変更が記録されます。It records these changes by updating the EndDate value and inserting a new version with the StartDate value commencing from the previous EndDate value. また、関連するファクトでは、時間ベースの参照を使用して、ファクトの日付に関連するディメンション キー値を取得する必要があります。Also, related facts must use a time-based lookup to retrieve the dimension key value relevant to the fact date. Power Query を使用する Power BI モデルでは、この結果を生成できません。A Power BI model using Power Query can't produce this result. しかし、事前に読み込まれた SCD の種類 2 のディメンション テーブルからデータを読み込むことはできます。It can, however, load data from a pre-loaded SCD Type 2 dimension table.

Power BI モデルでは、変更に関係なく、メンバー、およびメンバーの特定の時点の状態を表すメンバーのバージョンの履歴データに対するクエリをサポートする必要があります。The Power BI model should support querying historical data for a member, regardless of change, and for a version of the member, which represents a particular state of the member in time. この設計では、Adventure Works のコンテキストで、割り当てられた販売地域に関係なく、販売員、または販売員の特定のバージョンに対してクエリを実行できます。In the context of Adventure Works, this design enables you to query the salesperson regardless of assigned sales region, or for a particular version of the salesperson.

この要件を実現するには、Power BI モデルのディメンションの種類のテーブルに、販売員をフィルター処理するための列と、販売員の特定のバージョンをフィルター処理するための別の列を含める必要があります。To achieve this requirement, the Power BI model dimension-type table must include a column for filtering the salesperson, and a different column for filtering a specific version of the salesperson. バージョン列では、"Michael Blythe (12/15/2008-06/26/2019)" や "Michael Blythe (current)" など、あいまいでない説明を提供することが重要です。It's important that the version column provides a non-ambiguous description, like "Michael Blythe (12/15/2008-06/26/2019)" or "Michael Blythe (current)". また、レポートの作成者やコンシューマーに SCD 種類 2 の基本と、正しいフィルターを適用して適切なレポート設計を実現する方法について教えることが重要です。It's also important to educate report authors and consumers about the basics of SCD Type 2, and how to achieve appropriate report designs by applying correct filters.

また、ビジュアルでバージョン レベルにドリルダウンできるようにする階層を含めることをお勧めします。It's also a good design practice to include a hierarchy that allows visuals to drill down to the version level.

フィールド リストの階層例

階層例の出力

多様ディメンションRole-playing dimensions

多様ディメンションは、関連するファクトを異なる方法でフィルター処理できるディメンションです。A role-playing dimension is a dimension that can filter related facts differently. たとえば、Adventure Works では、日付ディメンション テーブルに再販業者の販売ファクトとの 3 つのリレーションシップがあります。For example, at Adventure Works, the date dimension table has three relationships to the reseller sales facts. 同じディメンション テーブルを使用して、注文日、出荷日、または納品日でファクトをフィルター処理することができます。The same dimension table can be used to filter the facts by order date, ship date, or delivery date.

データ ウェアハウスで、受け入れられる設計手法は、単一の日付ディメンション テーブルを定義することです。In a data warehouse, the accepted design approach is to define a single date dimension table. クエリ時には、日付ディメンションの "ロール" が、テーブルの結合に使用するファクト列によって確立されます。At query time, the "role" of the date dimension is established by which fact column you use to join the tables. たとえば、注文日別に売上を分析する場合、テーブルの結合は再販業者の販売注文日列に関連します。For example, when you analyze sales by order date, the table join relates to the reseller sales order date column.

Power BI モデルでは、2 つのテーブル間に複数のリレーションシップを作成することで、この設計を模倣できます。In a Power BI model, this design can be imitated by creating multiple relationships between two tables. Adventure Works の例では、日付および再販業者の販売テーブルに 3 つのリレーションシップがあります。In the Adventure Works example, the date and reseller sales tables would have three relationships. この設計は可能ですが、2 つの Power BI モデル テーブル間にはアクティブなリレーションシップが 1 つだけ存在できることを理解することが重要です。While this design is possible, it's important to understand that there can only be one active relationship between two Power BI model tables. 残りのすべてのリレーションシップは非アクティブに設定する必要があります。All remaining relationships must be set to inactive. 単一のアクティブなリレーションシップを持つということは、日付から再販業者の販売への既定のフィルター伝達があることを意味します。Having a single active relationship means there is a default filter propagation from date to reseller sales. この例では、アクティブなリレーションシップは、レポートで使用される最も一般的なフィルターに設定されます。これは、Adventure Works では注文日のリレーションシップとなります。In this instance, the active relationship is set to the most common filter that is used by reports, which at Adventure Works is the order date relationship.

単一の多様ディメンションとリレーションシップの例

非アクティブなリレーションシップを使用する唯一の方法は、USERELATIONSHIP 関数を使用する DAX 式を定義することです。The only way to use an inactive relationship is to define a DAX expression that uses the USERELATIONSHIP function. この例では、モデル開発者は、出荷日と納品日で再販業者の販売を分析できるようにするためのメジャーを作成する必要があります。In our example, the model developer must create measures to enable analysis of reseller sales by ship date and delivery date. この作業は、特に再販業者テーブルで多くのメジャーが定義されているときに、面倒な場合があります。This work can be tedious, especially when the reseller table defines many measures. また、 [フィールド] ウィンドウが乱雑になり、メジャーが過剰になります。It also creates Fields pane clutter, with an overabundance of measures. 他にも制限があります。There are other limitations, too:

  • レポート作成者が、メジャーの定義ではなく、列の集計に依存している場合、レポートレベルのメジャーを記述せずに非アクティブなリレーションシップの集計を実現することはできません。When report authors rely on summarizing columns, rather than defining measures, they can't achieve summarization for the inactive relationships without writing a report-level measure. レポートレベルのメジャーは、Power BI Desktop でレポートを作成する場合にのみ定義できます。Report-level measures can only be defined when authoring reports in Power BI Desktop.
  • 日付と再販業者の販売の間のアクティブなリレーションシップ パスが 1 つのみである場合、異なる種類の日付で再販業者の販売を同時にフィルター処理することはできません。With only one active relationship path between date and reseller sales, it's not possible to simultaneously filter reseller sales by different types of dates. たとえば、出荷済みの販売別に注文日の販売をプロットするビジュアルを生成することはできません。For example, you can't produce a visual that plots order date sales by shipped sales.

これらの制限を克服するための一般的な Power BI モデリング手法は、多様インスタンスごとにディメンションの種類のテーブルを作成することです。To overcome these limitations, a common Power BI modeling technique is to create a dimension-type table for each role-playing instance. 通常は、DAX を使用して、計算テーブルとして追加のディメンション テーブルを作成します。You typically create the additional dimension tables as calculated tables, using DAX. 計算テーブルを使用することで、モデルに日付テーブル、出荷日テーブル、および納品日テーブルを含めることができます。各テーブルには、それぞれの再販業者の販売テーブル列との単一のアクティブなリレーションシップがあります。Using calculated tables, the model can contain a Date table, a Ship Date table and a Delivery Date table, each with a single and active relationship to their respective reseller sales table columns.

多様ディメンションとリレーションシップの例

この設計手法では、異なる日付ロールに対して複数のメジャーを定義する必要はなく、異なる日付ロールで同時にフィルター処理を行うことができます。This design approach doesn't require you to define multiple measures for different date roles, and it allows simultaneous filtering by different date roles. しかし、この設計手法の小さな代償として、日付ディメンション テーブルが重複し、その結果、モデルのストレージ サイズが増加することになります。A minor price to pay, however, with this design approach is that there will be duplication of the date dimension table resulting in an increased model storage size. ディメンションの種類のテーブルでは、通常、ファクトの種類のテーブルと比べて少ない行が格納されるため、これはほとんど問題になりません。As dimension-type tables typically store fewer rows relative to fact-type tables, it is rarely a concern.

ロールごとにモデルのディメンションの種類のテーブルを作成するときは、次のような優れた設計プラクティスを確認してください。Observe the following good design practices when you create model dimension-type tables for each role:

  • 列名が自己記述型であることを確認します。Ensure that the column names are self-describing. すべての日付テーブルに [年] 列を含めることはできますが (列名がテーブル内で一意である)、既定のビジュアル タイトルでは自己記述されません。While it's possible to have a Year column in all date tables (column names are unique within their table), it's not self-describing by default visual titles. [出荷日] テーブルに出荷年などの名前の年の列が含まれるように、各ディメンション ロール テーブルの列の名前変更を検討してください。Consider renaming columns in each dimension role table, so that the Ship Date table has a year column named Ship Year, etc.
  • 関連性がある場合は、テーブルの説明で、フィルター伝達がどのように構成されているかについて、( [フィールド] ウィンドウのヒントを通じて) レポート作成者にフィードバックが提供されることを確認します。When relevant, ensure that table descriptions provide feedback to report authors (through Fields pane tooltips) about how filter propagation is configured. この明確さが重要なのは、モデルに汎用的な名前のテーブル (日付など) が含まれている場合です。これは、多くのファクトの種類のテーブルをフィルター処理するために使用されます。This clarity is important when the model contains a generically named table, like Date, which is used to filter many fact-type tables. このテーブルに、たとえば、再販業者の販売注文日列とのアクティブなリレーションシップがある場合、"再販業者の販売を注文日別にフィルター処理する" のようなテーブルの説明を指定することを検討してください。In the case that this table has, for example, an active relationship to the reseller sales order date column, consider providing a table description like "Filters reseller sales by order date".

詳細については、「アクティブなリレーションシップと非アクティブなリレーションシップのガイダンス」をご覧ください。For more information, see Active vs inactive relationship guidance.

ジャンク ディメンションJunk dimensions

ジャンク ディメンションは、特に少数の属性 (おそらく 1 つ) で構成されているディメンションが多数存在し、これらの属性の値が少ない場合に便利です。A junk dimension is useful when there are many dimensions, especially consisting of few attributes (perhaps one), and when these attributes have few values. 適切な候補としては、注文状態列や、顧客人口統計列 (性別、年齢グループなど) があります。Good candidates include order status columns, or customer demographic columns (gender, age group, etc.).

ジャンク ディメンションの設計目標は、多くの "小さな" ディメンションを単一のディメンションに統合し、モデルのストレージ サイズを小さくするだけでなく、モデル テーブルの表示数を減らして [フィールド] ウィンドウの乱雑さを減らすことです。The design objective of a junk dimension is to consolidate many "small" dimensions into a single dimension to both reduce the model storage size and also reduce Fields pane clutter by surfacing fewer model tables.

ジャンク ディメンション テーブルは、通常、すべてのディメンションの属性メンバーのデカルト積であり、代理キー列があります。A junk dimension table is typically the Cartesian product of all dimension attribute members, with a surrogate key column. 代理キーでは、テーブルの各行への一意の参照が提供されます。The surrogate key provides a unique reference to each row in the table. データ ウェアハウスでディメンションを構築することができます。あるいは、完全外部クエリ結合を実行してから、代理キー (インデックス列) を追加するクエリを作成するための Power Query を使用することもできます。You can build the dimension in a data warehouse, or by using Power Query to create a query that performs full outer query joins, then adds a surrogate key (index column).

ジャンク ディメンションの例

このクエリを、ディメンションの種類のテーブルとしてモデルに読み込みます。You load this query to the model as a dimension-type table. また、このクエリをファクト クエリと結合する必要があるため、"一対多" モデル リレーションシップの作成をサポートするために、インデックス列がモデルに読み込まれます。You also need to merge this query with the fact query, so the index column is loaded to the model to support the creation of a "one-to-many" model relationship.

逆ディメンションDegenerate dimensions

逆ディメンションでは、フィルター処理に必要なファクト テーブルの属性を参照します。A degenerate dimension refers to an attribute of the fact table that is required for filtering. Adventure Works の再販業者の販売注文番号が良い例です。At Adventure Works, the reseller sales order number is a good example. この場合、この 1 つの列のみで構成される独立したテーブルを作成することは、優れたモデル設計的に意味がありません。モデルのストレージ サイズが大きくなり、 [フィールド] ウィンドウが乱雑になるためです。In this case, it doesn't make good model design sense to create an independent table consisting of just this one column, because it would increase the model storage size and result in Fields pane clutter.

Power BI モデルでは、販売注文番号列をファクトの種類のテーブルに追加し、販売注文番号でフィルター処理またはグループ化できるようにすることが適切な場合があります。In the Power BI model, it can be appropriate to add the sales order number column to the fact-type table to allow filtering or grouping by sales order number. これは、テーブルの種類を混在させないようにする必要がある (通常、モデル テーブルはディメンションの種類またはファクトの種類のいずれかである必要がある) という、以前に紹介したルールの例外です。It is an exception to the formerly introduced rule that you should not mix table types (generally, model tables should be either dimension-type or fact-type).

逆ディメンションの例

しかし、Adventure Works 再販業者の sales テーブルに注文番号 "および" 注文明細行番号の列があり、フィルター処理に必要な場合は、逆ディメンション テーブルを使用することをお勧めします。However, if the Adventure Works resellers sales table has order number and order line number columns, and they're required for filtering, a degenerate dimension table would be a good design. 詳細については、一対一のリレーションシップのガイダンス (逆ディメンション) に関する記事をご覧ください。For more information, see One-to-one relationship guidance (Degenerate dimensions).

ファクトレス ファクト テーブルFactless fact tables

ファクトレス ファクト テーブルには、メジャー列は含まれません。A factless fact table doesn't include any measure columns. ディメンション キーのみが含まれます。It contains only dimension keys.

ファクトレス ファクト テーブルには、ディメンション キーによって定義された観測値を格納できます。A factless fact table could store observations defined by dimension keys. たとえば、特定の日付と時刻に、特定の顧客が Web サイトにログインしたとします。For example, at a particular date and time, a particular customer logged into your web site. メジャーを定義してファクトレス ファクト テーブルの行をカウントし、顧客がいつログインしたかと、その顧客の数を分析することができます。You could define a measure to count the rows of the factless fact table to perform analysis of when and how many customers have logged in.

ファクトレス ファクト テーブルのより説得力のある用途として、ディメンション間のリレーションシップの格納があります。これは、Power BI モデルの設計手法であり、多対多ディメンションのリレーションシップを定義することをお勧めします。A more compelling use of a factless fact table is to store relationships between dimensions, and it's the Power BI model design approach we recommend defining many-to-many dimension relationships. 多対多ディメンション リレーションシップの設計では、ファクトレス ファクト テーブルは "ブリッジング テーブル" と呼ばれます。In a many-to-many dimension relationship design, the factless fact table is referred to as a bridging table.

たとえば、販売者を 1 つ_または複数_の販売地域に割り当てることができるとします。For example, consider that salespeople can be assigned to one or more sales regions. ブリッジング テーブルは、販売員キーと地域キーという 2 つの列で構成されるファクトレス ファクト テーブルとして設計されます。The bridging table would be designed as a factless fact table consisting of two columns: salesperson key and region key. 両方の列に重複する値を格納できます。Duplicate values can be stored in both columns.

ファクトレス ファクト テーブルの例

この多対多の設計手法は十分に立証されており、ブリッジング テーブルがなくても実現できます。This many-to-many design approach is well documented, and it can be achieved without a bridging table. しかし、2 つのディメンションを関連付ける場合は、ブリッジング テーブル手法がベスト プラクティスと見なされます。However, the bridging table approach is considered the best practice when relating two dimensions. 詳細については、多対多のリレーションシップのガイダンス (2 つのディメンションの種類のテーブルを関連付ける) に関する記事をご覧ください。For more information, see Many-to-many relationship guidance (Relate two dimension-type tables).

次の手順Next steps

スター スキーマ設計または Power BI モデル設計の詳細については、次の記事を参照してください。For more information about star schema design or Power BI model design, see the following articles: