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

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

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

ディメンショナル モデルでは、ファクト テーブルには、観測またはイベントに関連付けられた測定値が格納されます。 販売注文、在庫残高、為替レート、温度の読み取りなどを格納できます。

ファクト テーブルには、通常、販売注文数量などの数値列の測定値を含みます。 分析クエリは、ディメンション フィルターとグループ化のコンテキスト内で (合計、カウント、平均、およびその他の関数を使用して) メジャーを集計します。

ファクト テーブルには、ファクトの ディメンショナリティ を決定するディメンション キーも含まれます。 ディメンション キーの値によって、ファクトの 細分性 が決まります。このように、ファクトは原子レベルで定義されます。 たとえば、販売ファクト テーブルにある注文日のディメンション キーは、日付レベルでファクトの細分性を設定し、販売目標ファクト テーブルの対象日付のディメンション キーは、四半期レベルで細分性を設定できます。

ファクト テーブルを簡単に識別するには、通常、名前の先頭に f_ または Fact_ を付けます。

ファクト テーブル構造

ファクト テーブルの構造を説明するには、f_Sales という名前の販売ファクト テーブルの次の例を考慮します。 この例では、適切な設計プラクティスを適用します。 以下のセクションでは、列の各グループについて説明します。

CREATE TABLE f_Sales
(
    --Dimension keys
    OrderDate_Date_FK INT NOT NULL,
    ShipDate_Date_FK INT NOT NULL,
    Product_FK INT NOT NULL,
    Salesperson_FK INT NOT NULL,
    <…>
    
    --Attributes
    SalesOrderNo INT NOT NULL,
    SalesOrderLineNo SMALLINT NOT NULL,
    
    --Measures
    Quantity INT NOT NULL,
    <…>
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Primary key (プライマリ キー)

この例の場合と同様に、サンプルファクト テーブルには 主キー がありません。 これは、通常は有益な目的を果たしていないし、不必要にテーブルのストレージのサイズを増やすことになるためです。 主キーは、多くの場合、ディメンション キーと属性のセットによって暗黙的に示されます。

ディメンション キー

サンプル ファクト テーブルには、ファクト テーブルの次元性を決定するさまざまなディメンション キーがあります。 ディメンション キーは、関連ディメンションの代理キー (または上位レベルの属性) への参照です。

ファクト テーブルは、ディメンションを複数回参照できます。 この場合、多様ディメンション として知られています。 この例では、ファクト テーブルに OrderDate_Date_FK と ShipDate_Date_FK のディメンション キーがあります。 各ディメンション キーは個別の ロール を表しますが、物理的な日付ディメンションは 1 つだけです。

各ディメンション キーを NOT NULL として設定することをお勧めします。 ファクト テーブルの読み込み中に、特殊ディメンション メンバー を使用して、不足している状態、不明な状態、N/A 状態、またはエラー状態 (必要な場合) を表すことができます。

属性

サンプル ファクト テーブルには、2 つの属性があります。 属性は追加情報を提供し、ファクト データの細分性を設定しますが、ディメンション キーでもディメンション属性でも測定値でもありません。 この例では、属性列は販売注文情報を格納します。 その他の例としては、追跡番号やチケット番号などがあります。 分析の目的で、属性は 生成ディメンション を形成できます。

メジャー

サンプル ファクト テーブルには、Quantity 列など、測定値も含まれています。 メジャーの列は通常、数値で、一般的に加法的です (つまり、その他の集計を使用して合計し、集約できます)。 詳細については、後の「測定値のタイプ」を参照してください。

監査属性

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

ファクト テーブルのサイズ

ファクト テーブルはサイズに幅があります。 それらのサイズは、ディメンショナリティ、細分性、尺度の数、履歴の量に対応します。 ディメンション テーブルと比較すると、ファクト テーブルの方が狭くなります (列数は少なくなります) が、行数は大きいか、さらに膨大 です (数 10 億を超えます)。

ファクト設計の概念

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

ファクト テーブルの種類

ファクト テーブルには次の 3 種類があります:

• トランザクション ファクト テーブル
• 定期的なスナップショットファクト テーブル
• スナップショット ファクト テーブルの累積

トランザクション ファクト テーブル

トランザクション ファクト テーブル には、ビジネス イベントまたはトランザクションが格納されます。 各行には、ディメンション キーと測定値、および必要に応じて他の属性の観点からファクトが格納されます。 すべてのデータは挿入時に完全に認識され、変更されることはありません (エラーの修正を除く)。

通常、トランザクション ファクト テーブルには、可能な限り低いレベルの細分性でファクトが格納され、すべてのディメンションで 加法式 の測定値が含まれます。 すべての販売注文明細行を格納する販売ファクト テーブルは、トランザクション ファクト テーブルの良い例です。

定期的なスナップショットファクト テーブル

周期的スナップショットのファクト テーブルには、事前定義済みの時間または特定の間隔で測定値が格納されます。 これにより、時間の経過に伴う主要なメトリックまたはパフォーマンス インジケーターの要約が提供されます。そのため、傾向分析や時間の経過に伴う変化の監視に役立ちます。 メジャーは常に 準加法 (後述) です。

インベントリ ファクト テーブルは、定期的なスナップショット テーブルの良い例です。 すべての製品の一日の終わりの在庫残高が毎日読み込まれます。

大量のトランザクションを記録するとコストがかかり、有用な分析要件をサポートしていない場合は、トランザクション ファクト テーブルの代わりに定期的なスナップショット テーブルを使用できます。 たとえば、1 日に何百万もの在庫移動があっても (トランザクション ファクト テーブルに格納される可能性があります)、分析は、一日の終わりの在庫レベルの傾向にのみ関係します。

スナップショット ファクト テーブルの累積

スナップショット ファクト テーブルには、明確に定義された期間またはワークフローにわたって蓄積された測定値が格納されます。 多くの場合、ビジネス プロセスの状態は、完了するまでに数日、数週間、または数か月かかる場合がある、個別のステージまたはマイルストーンで記録されます。

ファクト行は、プロセスの最初のイベントの直後に読み込まれ、マイルストーン イベントが発生するたびに予測可能なシーケンスで行が更新されます。 プロセスが完了するまで更新を続行します。

累積スナップショット ファクト テーブルには、マイルストーン イベントを表す複数の日付ディメンション キーがあります。 一部のディメンション キーは、プロセスが特定のマイルストーンに到達するまで N/A 状態 を記録することがあります。 メジャーは通常、期間を記録します。 マイルストーン間の期間は、ビジネス ワークフローまたはアセンブリ プロセスに関する貴重な分析情報を提供できます。

メジャーの種類

メジャーは通常、数値であり、一般的に加法です。 ただし、一部のメジャーを常に追加できるわけではありません。 これらのメジャーは、準加法または非加法のいずれかに分類されます。

加法メジャー

加法メジャー は、任意のディメンションで合計できます。 たとえば、注文数量と売上収益は加法メジャーです (単一の通貨に対して収益が記録される場合)。

準加法メジャー

準加法メジャー は、特定のディメンション間でのみ合計できます。

次に、準加法メジャーの例をいくつか示します。

• 定期的なスナップショット ファクト テーブル内のメジャーは、他の期間にわたって合計することはできません。 たとえば、夜間にサンプリングされた在庫品目の経過日数は合計する必要はありませんが、棚上のすべての在庫品目の経過日数を毎晩合計する可能性はあります。
• 在庫ファクト テーブルの在庫残高メジャーは、他の製品間で合計することはできません。
• 通貨ディメンション キーを持つ販売ファクト テーブルの売上収益は、通貨間で合計することはできません。

非加法メジャー

非加法メジャー は、どのディメンションでも合計できません。 たとえば、温度の読み取り値は、その性質上、他の読み取り値に追加しても意味がありません。

その他の例としては、単価や比率などのレートがあります。 ただし、比率の計算に使用する値を格納することをお勧めします。これにより、必要に応じて比率を計算することができます。 たとえば、販売ファクトの割引率は、割引額メジャーとして格納できます (販売売上メジャーで割ります)。 または、棚の在庫項目の経過日数を時間の経過と同時に合計することはできませんが、在庫品目の平均経過日数の傾向が観察される場合があります。

一部のメジャーは合計できなくても、有効なメジャーです。 カウント、個別のカウント、最小値、最大値、平均などを使用して集計できます。　 また、非加法メジャーは、計算で使用されるときに加法になる可能性があります。 たとえば、単価に注文数量を乗算すると、売上収益が生成されます。これは加法です。

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

ファクト テーブルにメジャー列が含まれていない場合は、ファクトレス ファクト テーブル と呼ばれます。 ファクトレス ファクトテーブルは、通常、クラスに出席する学生のように、イベントや出来事を記録します。 分析の観点から、ファクト行をカウントすることで測定を実現できます。

ファクト テーブルの集計

集計ファクト テーブル は、基本ファクト テーブルのロールアップを表し、より低い次元や高い細分性を実現します。 その目的は、一般的にクエリされるディメンションのクエリ パフォーマンスを高速化することです。

関連するコンテンツ

このシリーズの次の記事では、ディメンショナル モデル テーブルを読み込む ためのガイダンスと設計のベスト プラクティスについて説明します。