Dimension table

A dimension table holds the descriptive, mostly textual attributes that give context to the numbers in a fact table — a customer's name and segment, a product's category and brand, a date's weekday and fiscal quarter. Each dimension row is referenced by many fact rows through a key, usually a surrogate key rather than the source system's own identifier.

Dimension tables are wide and comparatively short — many descriptive columns, far fewer rows than the facts that reference them — and are usually denormalized, repeating attributes like category name on every row rather than normalizing them into further lookup tables, because that makes ad hoc filtering fast and simple for BI tools. When a dimension's attributes change over time, such as a customer moving region, a slowly changing dimension strategy decides whether history is overwritten or preserved.

Dimension tables are what make dimensional models usable by non-technical analysts: dragging "region" or "product category" into a report is only possible because that attribute lives in a clean, denormalized dimension table joined to the facts. The main design risk is a dimension that changes grain or meaning over time without anyone updating the surrogate key strategy, which silently corrupts historical joins.