You are designing a SQL Server Analysis Services (SSAS) cube based on a Windows Azure SQL Database data warehouse. You need to implement a degenerate dimension. What should you do?

A degenerate dimension is one whose attributes exist directly in the fact table with no corresponding separate dimension table in the data warehouse. Using the fact table itself as the data source for the dimension correctly implements this pattern, allowing attributes like order numbers or invoice IDs to serve as dimension keys without requiring a separate lookup table.

Creating a junk dimension table combines low-cardinality flags or codes from the fact table into a new separate table - this describes a junk dimension, not a degenerate dimension.

Snowflake dimension tables represent normalized dimension hierarchies split across multiple related tables, which is a snowflake schema pattern entirely unrelated to degenerate dimensions.

Adding a surrogate key to the fact table describes surrogate key usage, but a degenerate dimension by definition uses a naturally occurring fact attribute such as an order number rather than a system-generated key.