A fact table records measurable events, such as orders, payments or clicks, at a declared grain. Each row holds numbers that can be added up, such as amount or quantity, and keys that link to dimensions. Fact tables are usually the largest tables in a model and grow by appending.
For example, a fact_order_lines table might hold one row per line on a customer order: an order id, a line number, a date key, a customer key, a product key, a store key, the quantity, the unit price and the line amount. A question such as revenue by month and region sums the amount, joins the date and store dimensions, and groups. Because each row is one line, summing the amount gives revenue without double counting; summing a value that repeats on every line of an order, such as its shipping fee, would count it several times.
Fact tables come in a few common kinds. Transaction facts record each event as it happens, like the order line above. Periodic snapshot facts record a state at regular intervals, such as each account's balance at the end of each day. Accumulating snapshot facts follow a process with known steps, such as an order moving from placed to shipped to delivered, and update one row as it progresses.
Measures are additive when they can be summed across every dimension, such as an amount; semi-additive when they can be summed across some dimensions but not time, such as a balance; and non-additive when they cannot be summed at all, such as a ratio. Knowing which is which prevents wrong totals in reports. See also gold layer, surrogate key and semantic model.
Late facts, duplicates and joins to the wrong dimension version are common failure points, which Emolysis's Late-arriving and Dedupe / conform shapes handle. The grain of a fact table, such as one row per order line, decides which questions it can answer.