Degenerate dimension

Template:Use dmy dates According to Ralph Kimball, in a data warehouse, a degenerate dimension is a dimension key (primary key for a dimension table) in the fact table that does not have its own dimension table, because all the interesting attributes have been placed in analytic dimensions. The term "degenerate dimension" was originated by Ralph Kimball.

As Bob Becker says:Template:Main other

Other uses of the term

Although most writers and practitioners use the term degenerate dimension correctly, it is very easy to find misleading definitions in online and printed sources. For example, the Oracle FAQ defines a degenerate dimension as a "data dimension that is stored in the fact table rather than a separate dimension table. This eliminates the need to join to a dimension table. You can use the data in the degenerate dimension to limit or 'slice and dice' your fact table measures."

This common interpretation implies that it is good dimensional modeling practice to place dimension attributes in the fact table, as long as you call them a degenerate dimension. This is not the case; the concept of degenerate dimension was developed by Kimball to support a specific, well-defined exception to the otherwise ironclad rule that dimension attributes are always pulled out into dimension tables.

See also

• Data warehouse
• Dimension table
• Early-arriving fact
• Fact table
• Measure (data warehouse)

Bibliography

• Kimball, Ralph et al. (1998); The Data Warehouse Lifecycle Toolkit, p17. Pub. Wiley. Template:ISBN.
• Kimball, Ralph (1996); The Data Warehouse Toolkit, p. 100. Pub. Wiley. Template:ISBN.