Facts: order, payment, inventory movement
Measures: quantity, amount, duration
Dimensions: customer, product, store, date
Attributes: category, region, tier
Relations: grain, keys, effective time
Start with what one row represents
A row describing a countable event or point-in-time state is usually a fact. A row describing attributes of a customer, product, or store is usually a dimension.
Do not classify by table name. Inventory snapshots are facts; price may be a current attribute or a history fact depending on the question.
Facts need grain and additivity
An order-line fact has one row per item; a payment fact has one per payment. Amounts cannot be combined without governed relations. Record grain, keys, time, and source.
Label measures additive, semi-additive, or non-additive. Balances cannot sum across time and ratios should usually recompute from components.
Dimensions provide business context
Names, categories, regions, tiers, and hierarchies turn technical keys into business language. Define enums, unknown members, and null behavior.
For changing attributes, choose current overwrite, historical versions, or separate events. Tell AI which version answers historical questions.
Constrain analytical paths
Facts usually join many-to-one to dimensions. Many-to-many, role-playing dates, and cross-fact analysis need bridges, shared dimensions, or pre-aggregation.
Put cardinality, filter direction, and effective time in semantics and test row counts and metrics.
Accept with business questions
Test order amount by transaction store, historical revenue by current customer tier, and daily inventory balance. Inspect fact, dimension, time, and aggregation choice.
BuildTable can be evaluated for organizing these models; automated inference, versioning, and tests require project confirmation.
Public references
Build an AI-ready data foundation
Download BuildTable or talk with us about your data modeling scenario.
Download BuildTable