A degenerate dimension is a dimension attribute that lives in the fact table itself, with no separate dimension table behind it. The classic example is an order number, invoice number, or transaction ID: it's a dimensional attribute - you group and filter by it - but it has no descriptive attributes of its own that would justify a table. So it sits right in the fact row as a column, "degenerate" in the sense that the dimension has degenerated to nothing but its key.

Why the dimension is empty

A normal dimension exists to hold descriptive context: dim_customer carries name, segment, region. But an order number has no attributes - there's no "name of the order" or "category of the order" to describe. Everything you'd want to know about the order is already on the fact rows that share that order number: the line items, amounts, dates, and the customer and product keys. Creating a separate dim_order table whose only column is the order number would be a pointless join to a table that adds nothing. The degenerate dimension avoids that by keeping the identifier where it's useful - on the fact.

What it's good for

Degenerate dimensions earn their place in two ways. They group the line items of a single transaction: an order number on each line-item fact row lets you roll lines back up to the order ("average lines per order," "order-level totals") even though the fact's grain is the line item. And they support operational drill-through and traceability - linking a warehouse fact back to the exact source document for audit or customer-service lookup. They're common in any transaction-grained fact: order numbers in retail, invoice numbers in billing, ticket numbers in support.

Modeling it correctly

The rule of thumb: if an identifier has descriptive attributes, it belongs in a dimension table; if it's a bare identifier used for grouping and drill-through, make it a degenerate dimension on the fact. The mistake to avoid is reflexively building a one-column dimension table for every ID - that adds joins and complexity for no analytical gain. The opposite mistake is hiding genuine attributes inside the fact when they really deserve their own dimension. Degenerate dimensions sit alongside the warehouse's conformed dimensions as one of the standard tools of dimensional modeling.

Frequently asked questions

What is a degenerate dimension? A dimensional attribute (like an order or invoice number) stored directly in the fact table, with no separate dimension table because it has no descriptive attributes of its own.

Why not give it its own dimension table? A one-column dimension holding only the identifier adds a pointless join - the descriptive context already lives on the fact rows that share the identifier.

What is it used for? Grouping the line items of a single transaction back to the order, and operational drill-through or traceability back to the source document.

How do I decide? If the identifier has descriptive attributes, use a dimension table; if it's a bare key for grouping and drill-through, make it a degenerate dimension on the fact.