スター型スキーマ の例。中央のテーブルはファクトテーブルです。データウェアハウス において、ファクトテーブルは ビジネスプロセス の測定値、メトリック、または事実で構成されます。これは、 ディメンションテーブル に囲まれたスター型スキーマ またはスノーフレーク型スキーマ の中心に位置します。複数のファクトテーブルが使用される場合、これらはファクトコンステレーションスキーマ として配置されます。ファクトテーブルには通常、事実を含む列とディメンションテーブルへの外部キー となる列の2種類の列があります。ファクトテーブルの主キーは通常、すべての外部キーで構成される複合キーです。ファクトテーブルにはデータウェアハウスの内容が含まれ、加算型、非加算型、半加算型などのさまざまな種類の測定値が格納されます。
ファクトテーブルは(通常)ディメンション属性を分析するための独立変数として機能する加算値を提供します。ファクトテーブルは多くの場合、粒度 によって定義されます。ファクトテーブルの粒度は、ファクトを定義できる最も最小単位のレベルを表します。売上ファクトテーブルの粒度は、「日別、製品別、店舗別の売上高」と表現できます。したがって、このファクトテーブルの各レコードは、日、製品、店舗によって一意に定義されます。他のディメンション(場所/地域など)もこのファクトテーブルのメンバーになり得ますが、これらはファクトレコードの一意性には何も追加しません。これらの「関連ディメンション」は、独立したファクトの追加のスライスを可能にしますが、一般的にはより高い集計レベル(1つの地域には多くの店舗が含まれる)での洞察を提供します。
例 ビジネスプロセス が販売である場合、対応するファクトテーブルには通常、次のような行に生データ と集計の 両方を表す列が含まれます。
12,000ドル は「2005年1月15日のニューヨーク店の売上」です。34,000ドル は「2005年1月15日のロサンゼルス店の売上」である。22,000ドル は「2005年1月16日のニューヨーク店の売上」である。21,000ドル は、「2005年1月のロサンゼルス店の1日平均売上高」である。65,000ドル は、「2005年2月のロサンゼルス店の1日平均売上高」である。33,000ドル は、「2005年のロサンゼルス店の1日平均売上高」である。「1日平均売上高」 は、ファクトテーブルに格納される測定値です。ファクトテーブルには、時系列データ (日付など)やその他のディメンション(店舗所在地、販売員、製品など)が格納されている ディメンションテーブル からの外部キー も含まれています。
ファクトテーブルとディメンションテーブル間の外部キーは すべてサロゲートキー であるべきであり、運用データから再利用されたキーであってはならない。
測定タイプ 加算性 – あらゆる次元にわたって加算できる指標。 非加算性 ― あらゆる次元にわたって加算できない指標。 半加算性 – いくつかの次元にわたって加算できる尺度。 ファクトテーブルには、詳細レベルのファクト、または集計されたファクトのいずれかが含まれる場合があります(集計されたファクトを含むファクトテーブルは、多くの場合、サマリーテーブルと呼ばれます)。
比率やパーセンテージを扱う際には、特に注意が必要です。優れた設計ルールの1つ[ 1 ] は、パーセンテージや比率をファクトテーブルに格納せず、データアクセスツールでのみ計算することです。つまり、ファクトテーブルには分子と分母のみを格納し、それらを集計します。集計された格納値は、データアクセスツールで比率やパーセンテージを計算するために使用できます。
現実世界では、メジャーやファクトを一切含まないファクトテーブルが存在する可能性があります。このようなテーブルは「ファクトレスファクトテーブル」または「ジャンクションテーブル 」と呼ばれます。
事実情報を含まない事実テーブルは、 多対多の関係をモデル化したり、イベントのタイムスタンプ を記録したりするために使用できます。[ 1 ]
ファクトテーブルの種類 すべてのファクトテーブルを特徴づける4つの基本的な測定イベントがあります。[ 2 ]
取引 トランザクションテーブルは、最も基本的で不可欠なテーブルです。トランザクションファクトテーブルの粒度は通常、「トランザクションの各行につき1行」と指定されます。例えば、レシートの各行が該当します。トランザクションファクトテーブルは通常、最も詳細なレベルのデータを保持するため、多数のディメンション が関連付けられます。 定期的なスナップショット 定期スナップショットは、その名の通り「その瞬間」を捉えるものであり、その瞬間とは、例えば営業担当者の前月の業績概要など、定義された任意の期間を指します。定期スナップショットテーブルはトランザクションテーブルに依存しており、選択した業績出力を生成するには、トランザクションファクトテーブルに格納されている詳細なデータが必要となります。 スナップショットの蓄積 このタイプのファクトテーブルは、注文処理など、開始と終了が明確に定義されたプロセスのアクティビティを表示するために使用されます。注文は、完全に処理されるまで特定のステップを経て進みます。注文の履行に向けたステップが完了するにつれて、ファクトテーブルの関連する行が更新されます。累積スナップショットテーブルには、多くの場合、プロセスのマイルストーンを表す複数の日付列があります。そのため、行の作成時点では多くのマイルストーンの日付が不明であるため、関連する日付ディメンションに、不明な日付のプレースホルダーを表すエントリを用意することが重要です。 一時的なスナップショット 時間データベース 理論とモデリング技術を適用することで、時間スナップショットファクトテーブル [ 3 ] は、実際に毎日のスナップショットを用意することなく、毎日のスナップショットと同等のものを得ることができます。ファクトテーブルに時間間隔の概念を導入することで、多くのスペースを節約し、パフォーマンスを最適化すると同時に、エンドユーザーが関心のある「その瞬間の姿」の論理的な同等物を得ることができます。
ファクトテーブルを設計する手順 キンボールの次元設計は4つのステップに従います: [ 4 ]
モデル化するビジネスプロセスを選択します (例:注文入力、請求処理)。[ 4 ] 粒度を宣言する – 単一のファクトテーブルの行が何を表すかを正確に定義する。異なる粒度を1つのテーブルに混在させてはならない。[ 5 ] 各ファクトテーブルの行に適用されるディメンションを特定します。 [ 4 ] 申告された穀物に真実である事実(測定値)を特定する。 [ 6 ] グレインが宣言されたら、適切なファクトテーブルタイプ(トランザクション、定期スナップショット、累積スナップショットなど)を選択します。[ 7 ] ファクトテーブルのメジャーは、一般的に次のように分類されます。[ 8 ]
加算可能 – すべての次元にわたって合計することができる(例:売上高)。半加法性 – 一部の側面では加法性を持つが、他の側面では加法性を持たない(例:口座残高は時間経過に対して加法性を持たない)。非加算性 – いずれの次元においても合計できない(例:比率)。通常は保存されるのではなく、クエリで計算される。例(トランザクション粒度、「注文明細ごとに1行」):
SELECT d.calendar_date , SUM ( f.sales_amount ) AS daily_sales FROM fact_sales f JOIN dim_date d ON f.date_key = d.date_key JOIN dim_product p ON f.product_key = p.product_key WHERE p.category = ' Widgets ' GROUP BY d.calendar_date ; この集計は、尺度が加算的であり、事実行が単一の宣言された粒度を共有しているため、有効です。[ 5 ]
参考文献 1 2 キンボール&ロス - データウェアハウスツールキット 第2版 [Wiley 2002] ↑ キンボール、ラルフ (2008). データウェアハウスライフサイクルツールキット、第2版 . ワイリー. ISBN 978-0-470-14977-5 。↑ Davide, Mauri. "Temporal Snapshot Fact Table" . 1 2 3 「4段階の次元設計プロセス」 . キンボールグループ. 2025年8月15日 取得 . 1 2 「穀物」 . キンボールグループ . 2025年8月15日 取得. ↑ 「ファクトテーブル」 . キンボールグループ. 2025年8月15日 取得 . ↑ 「デザインのヒント #13: ファクトテーブルをディメンションテーブルとして使用できる場合」 (PDF) . Kimball Group . 2025年8月15日 取得 . ↑ 「加算性、半加算性、非加算性の事実」 。 キンボールグループ。 2025年8月15日 取得 。