Microsoft Fabric Warehouse でのディメンショナル モデリング: ディメンション テーブル

適用対象: Microsoft Fabric の SQL 分析エンドポイントとウェアハウス

この記事では、ディメンション モデルで ディメンション テーブルを設計するためのガイダンスとベスト プラクティスについて説明します。 Microsoft Fabric の Warehouse の実用的なガイダンスを提供します。これは、テーブルの作成やテーブル内のデータの管理など、多くの T-SQL 機能をサポートするエクスペリエンスです。 そのため、ディメンション モデル テーブルの作成し、データをそこに読み込むのを完全に制御できます。

ディメンショナル モデルでは、ディメンション テーブルは、ビジネス要件と分析要件に関連するエンティティを説明します。 大まかに言えば、ディメンション テーブルは、モデル化するものを表します。 日付と時刻を含む、製品、人、場所、その他の概念などがあります。 ディメンション テーブルを簡単に識別するには、通常、名前の先頭に d_ または Dim_ を付けます。

ディメンション テーブルの構造

ディメンション テーブルの構造を説明するには、d_Salesperson という名前の営業担当者ディメンション テーブルの次の例を考えます。 この例では、適切な設計プラクティスを適用します。 以下のセクションでは、列の各グループについて説明します。

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

代理キー

サンプル ディメンション テーブルには、Salesperson_SK という名前の代理キーがあります。 代理キーは、ディメンション テーブルに生成および格納される単一列の一意識別子です。 これは、ディメンショナル モデル内の他のテーブルに関連付けるために使用される 主キー 列です。

代理キーは、ソース データの変更からデータ ウェアハウスを隔離するよう努めています。 また、他にも多くの利点があり、次の機能を利用できます:

• 複数のデータ ソースを統合する (重複する識別子の競合を回避する)。
• 複数列のナチュラル キーを、より効率的な単一列キーに統合します。
• ゆっくりと変化するディメンション (SCD) タイプ 2 でディメンション履歴を追跡します。
• (可能な限り最小の整数型を選択して) ストレージの最適化のためにファクト テーブルの幅を制限します。　

代理キー列は、ナチュラル キー (次に説明) が容認された候補と思われる場合でも、推奨される方法です。 また、キー値に意味を与えないようにする必要があります (後で説明するように、日付と時刻のディメンション キーを除く)。

ナチュラル キー

サンプル ディメンション テーブルには、EmployeeID という名前のナチュラル キーもあります。 ナチュラル キーは、ソース システムに格納されているキーです。 これにより、ディメンション データをソース システムに関連付けることができます。これは通常、ディメンション テーブルを読み込むための抽出、読み込み、および変換 (ETL) プロセスによって行われます。 ナチュラル キーが ビジネス キー と呼ばれる場合があり、その値はビジネス ユーザーにとって意味がある場合があります。

ディメンションにナチュラル キーがない場合があります。 それは、日付ディメンション やルックアップ ディメンションの場合や、フラット ファイルを正規化してディメンション データを生成する場合に当てはまります。

[ディメンションの属性]

サンプル ディメンション テーブルには、FirstName列のような ディメンション属性 もあります。 ディメンション属性は、関連するファクト テーブルに格納されている数値データにコンテキストを提供します。 通常は、分析クエリでフィルター処理とグループ化 (スライスとサイコロ) に使用されるテキスト列ですが、それ自体は集計されません。 ディメンション テーブルの中には、いくつかの属性が含まれるものもあれば、多くの属性が含まれているものもあります (ディメンショナル モデルのクエリ要件をサポートするために必要な数です)。

Direct Lake セマンティック モデル を作成する場合は、フィルター処理とグループ化に必要なすべての列をディメンション属性として含める必要があります。 これは、Direct Lake セマンティック モデルが計算列をサポートしていないためです。

外部キー

サンプル ディメンション テーブルには、SalesRegion_FK という名前の外部キーもあります。 他のディメンション テーブルは外部キーを参照できます。そしてディメンション テーブル内に存在することは特殊なケースです。 これは、テーブルが別のディメンション テーブルに関連付けられていることを示します。つまり、テーブルが Snowflake ディメンション の一部を形成する可能性があるか、アウトリガー ディメンション に関連しています。

Fabric Warehouse 外部キー制約をサポートしますが、適用することはできません。 そのため、データが読み込まれるときに、ETL プロセスで関連テーブル間の整合性をテストすることが重要です。

外部キーを作成することをお勧めします。 強制されていない外部キーを作成する理由の 1 つは、Power BI Desktop などのモデリング ツールがセマンティック モデル内のテーブル間のリレーションシップを自動的に検出して作成できるようにすることです。

履歴の追跡属性

サンプル ディメンション テーブルには、さまざまな履歴の追跡属性もあります。 履歴の追跡属性は、ソース システムで発生した特定の変更を追跡する必要に応じて省略可能です。 これにより、データ ウェアハウスの主要な役割をサポートする値を格納できます。これは、過去を正確に記述することです。 具体的には、ETL プロセスが新しいデータまたは変更されたデータをディメンションに読み込むにつれて、これらの属性には履歴コンテキストが格納されます。

詳細については、この記事で後述する「履歴変更の管理」を参照してください。

監査属性

サンプル ディメンション テーブルには、さまざまな監査属性もあります。 監査属性は省略可能ですが、おすすめです。 これにより、ディメンション レコードを作成または変更したタイミングと方法を追跡でき、ETL プロセス中に発生した診断またはトラブルシューティングの情報を含めることができます。 たとえば、行を更新したユーザー (またはどのプロセス) をいつ更新したかを追跡する必要があります。 監査属性は、ETL プロセスが予期せず停止した場合など、困難な問題を診断するのにも役立ちます。 また、エラーとしてのディメンション メンバーや 予想メンバー にフラグを設定することもできます。

ディメンション テーブルのサイズ

多くの場合、ディメンショナル モデルで最も便利で汎用性の高いディメンションは、大きく広いディメンションです。 これらは 行数が(数百万を超える) 多く、ディメンション属性の数 (数百もの可能性がある) は幅広く表示されます。 サイズはそれほど重要ではありません (ただし、可能な限り小さいサイズに合わせて設計および最適化する必要があります)。 重要なのは、ディメンションが必要なフィルター処理、グループ化、およびファクト データの正確な履歴分析をサポートしていることです。

大規模なディメンションは、複数のソース システムからソース化される場合があります。 この場合、ディメンション処理では、データを結合、マージ、重複除去、標準化する必要があります。サロゲート キーを割り当てます。

これに対して、いくつかのディメンジョンは小さいです。 複数のレコードと属性のみを含むルックアップ テーブルを表す場合があります。 多くの場合、これらの小さなディメンションは、ファクト テーブルのトランザクションに関連するカテゴリ値を格納し、ファクト レコードに関連する代理キーを持つディメンションとして実装されます。

ディメンション設計の概念

このセクションでは、さまざまなディメンション設計の概念について説明します。

非正規化と正規化

ほとんどの場合、ディメンション テーブルを 非正規化する 必要があります。 正規化 は、繰り返しデータを減らす方法で格納されるデータを記述するために使用される用語ですが、非正規化とは、事前計算された冗長データが存在する場所を定義するために使用される用語です。 通常、冗長データは階層のストレージ (後述) が原因で存在します。つまり、階層はフラット化されます。 たとえば、製品ディメンションには、サブカテゴリ (およびその関連属性) とカテゴリ (およびその関連属性) を格納できます。

ディメンションは一般的に小さいため (ファクト テーブルと比較すると)、ほとんどの場合、クエリのパフォーマンスと使いやすさの改善が、冗長なデータを格納するコストを上回ります。

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

非正規化の 1 つの例外は、Snowflake ディメンション を設計することです。 Snowflake ディメンションは正規化され、複数の関連テーブルにディメンション データが格納されます。

次の図は、Product、Subcategory、Categoryの 3 つの関連ディメンション テーブルで構成される Snowflake ディメンションを示しています。

次の場合は、Snowflake ディメンションの実装を検討してください:

• ディメンションは非常に大きく、ストレージ コストが高いクエリ パフォーマンスの必要性を上回ります。 (ただし、この問題が引き続き残っていることを定期的に再評価します。)
• ディメンションを粒度の高いファクトに関連付けるキーが必要です。 たとえば、販売ファクト テーブルには製品レベルで行が格納されますが、販売対象のファクト テーブルにはサブカテゴリ レベルの行が格納されます。
• より高いレベルの細分性で、履歴の変更を追跡する 必要があります。

Hierarchies (階層)

一般に、ディメンション列は 階層 を生成します。 階層を使用すると、異なるレベルの集計でデータを探索できます。 たとえば、マトリックス ビジュアルの初期ビューには年単位の売上が表示される場合があり、レポート コンシューマーは四半期および月次の売上を表示するために ドリルダウン を選ぶことができます。

ディメンションに階層を格納するには、3 通りの方法があります。 使用できるもの:

• 非正規化された単一のディメンションの列。
• 複数の関連テーブルで構成される Snowflake ディメンション。
• ディメンション内の親子 (自己参照) リレーションシップ。

階層は、均衡が取れているか、不均衡である可能性があります。 また、一部の階層が不規則であることを理解することも重要です。

均衡階層

均衡階層 は最も一般的な階層の種類です。 均衡階層には、同じ数のレベルがあります。 均衡階層の一般的な例は、年、四半期、月、および日付のレベルで構成される日付ディメンションのカレンダー階層です。

次の図は、販売地域の均衡階層を示しています。 これは、販売地域グループと販売地域の 2 つのレベルで構成されます。

均衡階層のレベルは、単一の非正規化ディメンションの列、または Snowflake ディメンションを形成するテーブルの列に基づいています。 単一の非正規化ディメンションに基づく場合、上位レベルを表す列には冗長データが含まれます。

均衡階層の場合、ファクトは常に階層の 1 つのレベル (通常は最下位レベル) に関連付けられます。 こうすることで、ファクトを階層の最上位レベルに集計 (ロールアップ) できます。 ファクトは、ファクト テーブルの粒度によって決定される任意のレベルに関連付けることができます。 たとえば、販売ファクト テーブルは日付レベルで格納され、売上目標ファクト テーブルは四半期レベルで格納される場合があります。

不均衡階層

不均衡階層 は、あまり一般的ではない種類の階層です。 不均衡階層には、親子関係に基づくレベルがあります。 このため、不均衡階層のレベルの数は、特定のディメンション テーブル列ではなく、ディメンション行によって決まります。

不均衡階層の一般的な例として、従業員ディメンションの各行が同じテーブル内のレポート マネージャー行に関連 従業員階層 があります。 この場合、すべての従業員は、レポートの従業員を持つマネージャーにすることができます。 当然ながら、階層の一部のブランチには、他のブランチよりも多くのレベルがあります。

次の図は、不均衡階層を示しています。 これは 4 つのレベルで構成され、階層内の各メンバーは営業担当者です。 営業担当者の報告先に応じて、階層内の先祖の数が異なっていることに注意してください。

不均衡階層の他の一般的な例としては、部品表、会社の所有権モデル、および一般会計があります。

不均衡階層の場合、ファクトは常にディメンション グレインに関連付けられます。 たとえば、販売ファクトは、レポート構造が異なるさまざまな営業担当者に関連します。 ディメンション テーブルには、代理キー (Salesperson_SK という名前) と、主キー列を参照する ReportsTo_Salesperson_FK 外部キー列があります。 管理する人がいない各営業担当者は、必ずしも階層のどのブランチでも最下位レベルにいるとは限りません。 最下位レベルでない場合、営業担当者は製品を販売し、製品も販売するレポート営業担当者を持つ可能性があります。 そのため、ファクト データのロールアップでは、個々の営業担当者とそのすべての子孫を考慮する必要があります。

親子階層のクエリは、特に大きなディメンションでは複雑かつ遅くなる可能性があります。 ソース システムではリレーションシップが親子として格納される場合があります。階層を 順応 させることをお勧めします。 この場合、順応とは、階層レベルを変換し、ディメンションに列として格納することを意味します。

不規則階層

階層内のメンバーの親が、そのすぐ上にないレベルに存在するため、階層がに 不規則 になることがあります。 このような場合、レベル値がない場合は、親の値が繰り返されます。

均衡地理階層の例を考えてみましょう。 国/地域に州や県がない場合、不規則階層が存在します。 たとえば、ニュージーランドには州も県もありません。 そのため、ニュージーランドの行を挿入するときは、StateProvince列にも国/地域の値を格納する必要があります。

次の図は、地理的リージョンの不規則階層を示しています。

履歴変更の管理

必要に応じて、ゆっくり変化するディメンション (SCD) を実装することで履歴変更を管理できます。 SCD は、履歴コンテキストを新しいデータまたは変更されたデータとして保持します。

最も一般的な SCD タイプは以下のとおりです。

• タイプ 1: 既存のディメンション メンバーを上書きします。
• タイプ 2: 新しい時間ベースの バージョン管理 ディメンション メンバーを挿入します。
• タイプ 3: 属性を使用して制限された履歴を追跡します。

ディメンションでは、SCD タイプ 1 と SCD タイプ 2 の両方の変更をサポートできる可能性があります。

SCD タイプ 3 は、セマンティック モデルで使用するのが難しいという理由から、一般的には使用されません。 SCD タイプ 2 のアプローチの方が適しているかどうかを慎重に検討してください。

SCD タイプ 1

SCD タイプ 1 の変更は、変更を追跡する必要がないため、既存のディメンション行を上書きします。 この SCD タイプは、エラーの修正にも使用できます。 これは共通の SCD タイプであり、顧客名、電子メール アドレスなど、ほとんどの変化する属性に使用する必要があります。

次の図は、電話番号が変更された営業担当者ディメンション メンバーの前後の状態を示しています。

この SCD タイプでは、既存の行が更新されるため、履歴の全体像は保持されません。 つまり、SCD タイプ 1 の変更により、異なる高レベル集計につながる可能性があります。 たとえば、営業担当者が別の販売地域に割り当てられている場合、SCD タイプ 1 の変更によってディメンション行が上書きされます。 営業担当者の過去の販売実績を地域にロールアップすると、新しい現在の販売地域が使用されるため、別の結果が生成されます。 これは、その営業担当者が常に新しい販売地域に割り当てられている状況と類似していました。

SCD タイプ 2

SCD タイプ 2 の変更により、ディメンション メンバーの時間ベースのバージョンを表す新しい行が生成されます。 常に現在のバージョンの行があり、ソース システムのディメンション メンバーの状態を反映します。 ディメンション テーブルの 履歴追跡属性 には現在のバージョン (現在のフラグが TRUE ) とその有効期間を識別できる値が格納されます。 複数のバージョンが格納されている場合、重複するナチュラル キーが存在するため、代理キーが必要です。

これは一般的な種類の SCD ですが、履歴の全体像を保持する必要がある属性用に予約する必要があります。

たとえば、営業担当者が別の販売地域に割り当てられている場合、SCD タイプ 2 の変更には更新操作と挿入操作が含まれます。

1. 更新操作により、現在のバージョンが上書きされ、履歴追跡属性が設定されます。 具体的には、終了有効性列は ETL 処理日 (またはソース システムの適切なタイムスタンプ) に設定され、現在のフラグは FALSE に設定されます。
2. 挿入操作により、新しい現在のバージョンが追加され、開始の有効期間列が終了の有効期間列の値 (以前のバージョンを更新するために使用) に設定され、現在のフラグが TRUE に設定されます。

関連するファクト テーブルの細分性は、営業担当者レベルではなく、営業担当者バージョン レベルであることを理解しておくことが重要です。 過去の販売実績を地域にロールアップすると、正しい結果が生成されますが、分析する営業担当者メンバー バージョンが 2 つ (またはそれ以上) あります。

次の図は、販売地域が変更された営業担当のディメンション メンバーの前後の状態を示しています。 組織は、営業担当者の労力を割り当てられているリージョン別に分析したいので、SCD タイプ 2 の変更をトリガーします。

次の SCD タイプ 2 の履歴追跡属性について検討してみましょう。

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

履歴追跡属性の目的を次に示します。

• RecChangeDate_FK 列には、変更が有効になった日付が格納されます。 変更が行われたときにクエリを実行できます。
• RecValidFromKey 列と RecValidToKey 列には、行の有効日が格納されます。 最初のバージョンを表す RecValidFromKey の日付ディメンションに最も古い日付を格納し、現在のバージョンの RecValidToKey の 01/01/9999 を格納することを検討してください。
• RecReason 列の列は省略可能です。 これにより、バージョンが挿入された理由を文書化できます。 変更された属性をエンコードすることも、特定のビジネス上の理由を示すソース システムのコードである可能性もあります。
• RecIsCurrent 列を使用すると、現在のバージョンのみを取得できます。 これは、ETL プロセスがファクト テーブルを読み込むときにディメンション キーを検索するときに使用されます。

SCD タイプ 3

SCD タイプ 3 の変更では、属性を持つ限られた履歴が追跡されます。 この方法は、最終変更や最新の変更を記録する必要がある場合に役立ちます。

この SCD タイプは、制限された 履歴の全体像を保持します。 初期値と現在の値のみを格納する必要がある場合に便利です。 この場合、暫定の変更は必要ありません。

たとえば、営業担当者が別の販売地域に割り当てられている場合、SCD タイプ 3 の変更によってディメンション行が上書きされます。 前の販売地域を具体的に格納する列は前の販売地域として設定され、新しい販売地域は現在の販売地域として設定されます。

次の図は、販売地域が変更された営業担当のディメンション メンバーの前後の状態を示しています。 組織は以前の販売地域の割り当てを決定する必要があるため、SCD タイプ 3 の変更をトリガーします。

特殊なディメンション メンバー

不明、未確認、N/A、またはエラー状態を表すディメンションに行を挿入できます。 たとえば、次の代理キー値を使用するとします。

カレンダーと時刻

ほとんど例外なく、ファクト テーブルには特定の時点で測定値が格納されます。 日付 (および場合によっては時刻) による分析をサポートするには、カレンダー (日付と時刻) ディメンションが必要です。

ソース システムにカレンダー ディメンション データが含まれるのは珍しいので、データ ウェアハウスで生成する必要があります。 通常、1 回生成されますが、カレンダー ディメンションの場合は、必要に応じて将来の日付で拡張されます。

日付ディメンション

日付 (またはカレンダー) ディメンションは、分析に使用される最も一般的なディメンションです。 日付ごとに 1 行を格納し、年、四半期、月などの特定の期間でフィルター処理またはグループ化する一般的な要件をサポートします。

日付ディメンションの自然キーでは、日付 データ型を使用する必要があります。 代理キーは YYYYMMDD 形式と int データ型を使用して日付を格納する必要があります。 代理キー値が意味を持ち、人間が判読できる場合は、この受け入れられたプラクティスが (時間ディメンションとともに) 唯一の例外である必要があります。 YYYYMMDD を int データ型として格納することは、効率的で数値的に並べ替えられるだけでなく、明確な国際標準機構 (ISO) 8601 日付形式にも準拠しています。

日付ディメンションに含める一般的な属性を次に示します。

• Year、Quarter、Month、Day
• QuarterNumberInYear、MonthNumberInYear– テキスト ラベルの並べ替えに必要な場合があります。
• FiscalYear、FiscalQuarter- 一部の企業会計スケジュールは、カレンダーの年の開始/終了と会計年度が異なるように、中間期に開始されます。
• FiscalQuarterNumberInYear、FiscalMonthNumberInYear– テキスト ラベルの並べ替えに必要な場合があります。
• WeekOfYear – 52 週間または 53 週間の ISO 標準を含め、年の週にラベルを付ける方法は複数あります。
• IsHoliday、HolidayText– 組織が複数の地域で活動している場合は、各地域が個別のディメンションとして観察するか、日付ディメンションの複数の属性で順応する複数の休日リストのセットを保持する必要があります。 HolidayText 属性を追加すると、レポートの休日を識別するのに役立ちます。
• IsWeekday – 同様に、一部の地域では、標準の稼働日は月曜日から金曜日ではありません。 たとえば、多くの中東地域では稼働日は日曜日から木曜日で、他の地域では 4 日または 6 日間が採用されています。
• LastDayOfMonth
• RelativeYearOffset、RelativeQuarterOffset、RelativeMonthOffset、RelativeDayOffset- 相対日付フィルター処理 (前月など) をサポートするために必要な場合があります。 現在の期間では、ゼロ (0) のオフセットが使用されます。前の期間には、-1、-2、-3... のオフセットが格納されます。今後の期間には、1、2、3...のオフセットが格納されます。

他のディメンションと同様に、重要なのは、既知のフィルター処理、グループ化、階層の要件をサポートする属性が含まれていることです。 ラベルの翻訳を他の言語に格納する属性もあります。

ディメンションを使用して粒度の高いファクトに関連付ける場合、ファクト テーブルでは、日付期間の最初の日付を使用できます。 たとえば、四半期ごとの営業担当者ターゲットを格納する売上目標ファクト テーブルでは、四半期の最初の日付が日付ディメンションに格納されます。 別の方法として、日付テーブルにキー列を作成します。 たとえば、四半期キーは、YYYYQ形式と smallint データ型を使用して四半期キーを格納できます。

ディメンションには、すべてのファクト テーブルで使用される既知の日付範囲が設定されている必要があります。 また、データ ウェアハウスがターゲット、予算、または予測に関するファクトを格納する将来の日付も含める必要があります。 他のディメンションと同様に、不明、未確認、N/A、またはエラーの状況を表す行を含めることができます。

通常、次の年の初めに、ETL プロセスでは、日付ディメンション行を特定の年数まで延長する必要があります。 ディメンションに相対オフセット属性が含まれている場合、現在の日付 (今日) に基づいてオフセット属性値を更新するには、ETL プロセスを毎日実行する必要があります。

時間ディメンション

場合によっては、特定の時点 (1 日のうちの時刻など) にファクトを格納する必要があります。 この場合は、時間 (またはクロック) ディメンションを作成します。 分単位 (24 x 60 = 1,440 行) または秒単位 (24 x 60 x 60 = 86,400 行) の場合があります。 その他の可能な粒度には、30 分または 1 時間が含まれます。

時間ディメンションのナチュラル キーでは、時間 データ型を使用する必要があります。 サロゲート キーは、適切な形式を使用し、意味を持ち、人間が判読できる値を格納できます(たとえば、HHMMまたは HHMMSS 形式を使用します)。

時間ディメンションに含める一般的な属性を次に示します。

• Hour、HalfHour、QuarterHour、Minute
• 時間帯ラベル (朝、午後、夕方、夜)
• 勤務シフト名
• 繁忙期フラグまたは閑散期フラグ

コンフォームド・ディメンション

一部のディメンションは、コンフォームド・ディメンション である場合があります。 コンフォームド・ディメンションは多くのファクト テーブルに関連するため、ディメンション モデル内の複数のスターで共有されます。 これらは一貫性をもたらし、継続的な開発とメンテナンスを減らすのに役立ちます。

たとえば、ファクト テーブルには少なくとも 1 つの日付ディメンション キーが格納されるのが一般的です (アクティビティはほとんどの場合、日付や時刻によって記録されるため)。 そのため、日付ディメンションは一般的なコンフォームド・ディメンションです。 したがって、日付ディメンションに、すべてのファクト テーブルの分析に関連する属性が含まれていることを確認する必要があります。

次の図は、Salesファクト テーブルと Inventory ファクト テーブルを示しています。 各ファクト テーブルは、コンフォームド・ディメンションである Date ディメンションと Product ディメンションに関連付けられます。

別の例として、従業員とユーザーは同じユーザーのセットである可能性があります。 この場合、各エンティティの属性を組み合わせて、1 つのコンフォームド・ディメンションを生成することが意味を成すことがあります。

多様ディメンション

ファクト テーブルでディメンションが複数回参照される場合、ディメンションは 多様ディメンション と呼ばれます。

たとえば、販売ファクト テーブルに注文日、出荷日、納品日のディメンション キーがある場合、日付ディメンションは 3 つの方法で関連しています。 それぞれの方法は個別の ロール を表しますが、物理的な日付ディメンションは 1 つだけです。

次の図は、Flightファクト テーブルを示しています。 Airport ディメンションは、Departure Airportディメンションと Arrival Airport ディメンションとしてファクト テーブルに 2 回関連するため、多様ディメンションです。

ジャンク ディメンション

ジャンク ディメンション は、独立したディメンションが多数存在する場合、特に少数の属性 (おそらく 1 つ) で構成されており、これらの属性のカーディナリティが低い (値が小さい) の場合に、有用です。 ジャンク ディメンションの目的は、多数の小さなディメンションを単一のディメンションに集約することです。 この設計アプローチでは、ディメンションの数を減らし、ファクト テーブル キーの数とファクト テーブルのストレージ サイズを減らすことができます。 また、ユーザーに表示されるテーブルが少なくなるため、データ ペイン クラッターを減らすのに役立ちます。

ジャンク ディメンション テーブルは、通常、すべてのディメンションの属性値のデカルト積を、代理キー列とともに格納します。

適切な候補には、フラグとインジケーター、注文の状態、顧客の人口統計状態 (性別、年齢グループなど) が含まれます。

次の図は、注文状態の値と納品状態の値を組み合わせた Sales Status という名前のジャンク ディメンションを示しています。

逆ディメンション

逆ディメンション は、ディメンションが関連するファクトと同じ粒度にある場合に発生する可能性があります。 逆ディメンションの一般的な例は、販売ファクト テーブルに関連する販売注文番号ディメンションです。 通常、請求書番号はファクト テーブル内にある唯一の非階層属性です。 そのため、このデータをコピーして別のディメンション テーブルを作成することは認められていません。

次の図は、販売ファクト テーブルの SalesOrderNumber 列に基づく、逆ディメンションである Sales Order ディメンションを示しています。 このディメンションは、個別の販売注文番号の値を取得するビューとして実装されます。

Power BI セマンティック モデリングの観点から、Power Query を使用して、逆ディメンションを別のテーブルとして作成できます。 このように、セマンティック モデルは、フィルター処理またはグループ化に使用されるフィールドがディメンション テーブルから取得され、ファクトの集約に使用されるフィールドがファクト テーブルから取得されるというベスト プラクティスに従います。

アウトリガー ディメンション

ディメンション テーブルが他のディメンション テーブルに関連付けられている場合は、アウトリガー ディメンション と呼ばれます。 アウトリガー ディメンションは、ディメンション モデルの定義に適合して再利用するのに役立ちます。

たとえば、郵便番号ごとに地理的な場所を格納する地理ディメンションを作成できます。 そのディメンションは、顧客ディメンション および 営業担当者ディメンションが参照できます。このディメンションには、地理ディメンションの代理キーが格納されます。 これにより、顧客と営業担当者は、一致した地理的な場所を使用して分析できます。

次の図は、アウトリガー ディメンションである Geography ディメンションを示しています。 Sales ファクト テーブルには直接関係しません。 代わりに、Customerディメンションと Salesperson ディメンションを介して間接的に関連付けられます。

他のディメンション テーブル属性に日付が格納されている場合、日付ディメンションをアウトリガー ディメンションとして使用できることを検討してください。 たとえば、顧客ディメンションの生年月日は、日付ディメンション テーブルの代理キーを使用して格納できます。

多値ディメンション

ディメンション属性に複数の値を格納する必要がある場合は、多値ディメンション を設計する必要があります。 複数値ディメンションを実装するには、ブリッジ テーブル (結合テーブルとも呼ばれます) を作成します。 ブリッジ テーブルには、エンティティ間の多対多リレーションシップが格納されます。

たとえば、営業担当者ディメンションがあり、各営業担当者が 1 つまたは複数の販売地域に割り当てられているとします。 この場合、販売地域ディメンションを作成するのが賢明です。 そのディメンションは、各販売地域を 1 回だけ格納します。 ブリッジ テーブルと呼ばれる個別のテーブルには、営業担当者と販売地域のリレーションシップごとに 1 行格納されます。 物理的には、営業担当者ディメンションからブリッジ テーブルへの一対多リレーションシップと、販売地域ディメンションからブリッジ テーブルへの一対多リレーションシップがあります。 必然的に、営業担当者と販売地域の間には多対多リレーションシップがあります。

次の図では、Accountディメンション テーブルは Transaction ファクト テーブルに関連しています。 顧客は複数のアカウントを持つ可能性があり、アカウントには複数の顧客を含めることができるため、Customerディメンション テーブルは Customer Account ブリッジ テーブルを介して関連付けられます。

関連するコンテンツ

このシリーズの次の記事では、ファクト テーブル のガイダンスと設計のベスト プラクティスについて説明します。