ファクト or ディメンション判定フロー#

データモデリング時に「このカラム（または概念）はファクトに持たせる？
それともディメンションに切り出す？」を判断するための分岐表。

判定フロー（YES/NO形式）#

STEP	質問	YESの場合	NOの場合
1	これは「数量・金額・回数・日数」など集計対象の値ですか？	→ ファクトのメジャー（measure）にする	次へ
2	このカラムは、ファクトの行を一意に識別するためのキーの一部ですか？（例: 明細ID、回答番号、バージョン番号など）	→ ファクトの属性（粒度構成キー）にする	次へ
3	値の種類が非常に多い or 一意ID（例: 取引ID、UUID）ですか？	→ デジェネレートディメンションとしてファクトに持つ	次へ
4	この概念は「名前・区分・分類など説明属性の塊」を持っていますか？	→ 次へ（ディメンション候補）	次へ（単発属性系）
5	この概念は複数のファクト（イベント）から参照されますか？	→ ディメンションとして切り出す	次へ
6	この値は分析軸（グルーピングやフィルタ）としてよく使いますか？	→ 次へ（6-1判定）	次へ
6-1	その軸に説明属性や再利用性がありますか？（例: ステータス名、カテゴリ名など）	→ ディメンション化を検討する（ただしファクト専用で単純なEnumならファクト内でOK）	→ ファクトに残す（例: `times` など）
7	これは単発フラグや小さなEnum（例: `is_latest`, `is_deleted`）ですか？	→ ファクトにそのまま持つ	→ 上のどこかを見直す

具体例#

カラム	役割	判定	理由
`amount`	見積金額	ファクト	集計対象の値
`times`	回答回数	ファクト	分析軸だが説明属性・再利用性がない。粒度構成キーの一部
`rfq_id`	見積依頼ID	ファクト（デジェネレート）	一意ID・高カーディナリティ
`status`	RFQステータス	ファクト or 小さなディメンション	分析軸＋説明属性あり。ただしRFQ専用ならファクト内でOK
`supplier_id`	サプライヤー	ディメンション	複数ファクトで共有される軸
`is_latest`	最新フラグ	ファクト	小さなEnum、属性がない

補足ルール#

「分析軸であっても、説明属性がない or 再利用しないならファクトに残す」
「複数ファクトで共有する“文脈”や“説明セット”を持つならディメンションに切る」
「粒度を構成するキー」はファクトが必ず持つ
必要に応じて、粒度キーを“説明”する小さなディメンションを別途作る（例: dim_response_iteration）
ステータスのように説明属性が少ないファクト専用Enumは、dim化せずファクト内でOK

用語整理#

用語	意味	例
粒度（grain）	ファクトの1行が何を表すか	「1見積回答」など
粒度を構成するキー	1行を一意に識別する列	`rfq_item_id`, `supplier_id`, `times`
デジェネレートディメンション	一意IDなど高カーディナリティの値をファクトに持つパターン	`order_id`, `rfq_id`
ディメンション	ファクトを説明・分類する文脈情報	サプライヤー、RFQ、ステータスなど

まとめ#

ファクト：数える／測る／発生を記録するもの
ディメンション：その出来事を説明・分類する文脈
times のような軸は粒度構成キーとしてファクトに置き、必要なら補助dimで説明。
status のような軸は、ファクト専用で単純ならそのまま持ち、再利用や属性拡張の可能性があればdim化する。