About Degenerate Dimensions

Per Wikipedia, the term "degenerate dimension" is attributed to Ralph Kimball who defined it as:

A degenerate dimension is a dimension key in the fact table that does not have its own dimension table, because all the interesting attributes have been placed in analytic dimensions.

Wikipedia provides this description by Bob Becker:

Degenerate dimensions commonly occur when the fact table's grain is a single transaction or transaction line. Transaction control header numbers assigned by the operational business process are typically degenerate dimensions, such as order numbers, ticket numbers, credit card transaction numbers, or check numbers. These degenerate dimensions are natural keys of the "parents" of the line items.

Even though there is no corresponding dimension table of attributes, degenerate dimensions can be useful for grouping together related fact table rows. For example, retail point-of-sale transaction numbers tie all the individual items purchased together into a single market basket. In health care, degenerate dimensions can group the claims items related to a single hospital stay or episode of care.

Using a degenerate dimension saves space and improves performance.

When to Use a Degenerate Dimension

You can target a column in a source with a property called Analyze Measure as shown in the example below.

This tags the column as a measure in a degenerate dimension, allowing you to use a measure like an attribute in order to group other measures. This method can be used if you do not need to use the level the column belongs to as the grain of another table. If you need to use the column's level as the grain of another table, you should create a degenerate dimension using the procedure described below rather than using the Analyze Measure property.

Creating a Degenerate Dimension in Birst

Creating a degenerate dimension in Birst is a multi-step process. In the following example scenario, a Test Fact table contains the transactions of people taking tests. The Test ID refers to the particular test being taken while the Test Fact ID identifies the particular time when a certain person took that test. Therefore, hierarchies have been created for Test and Test Fact (as well as Student). In this example we are making Test Fact a degenerate dimension.

To create a degenerate dimension

In the Manage Sources page under the Define Sources tab of the Infor Admin module, check the Rows in Data Source are Transactions box in the Properties tab for the data source.
In the Set Primary Key dialog box for the data source in the Data Flow page, set the primary key to the level key or keys of the degenerate dimension level.
Also using the Set Primary Key dialog box, set the Hierarchy Name and Level Name to the degenerate dimension hierarchy and level as shown above.

Tip: By default, these will be set to the name of the source, so they will not need to be changed if the hierarchy and level name match, as in the example above.
Set the grain of the source to the appropriate hierarchy levels. For our example, we need to set the grain on the Test Fact source to Test, Student and Test Fact.
Process the data.
After processing, go to Data Flow to check if the degenerate dimension was created. The degenerate dimension will still appear in green like a standard dimension. Right-click the dimension level and select Properties.

The physical table name should be in the form DW_SF_[levels in alphabetical order] as in the example below. SF stands for snapshot fact, indicating it is a fact table. This means you have successfully created the degenerate dimension. If the physical table name begins with DW_DM_, this means it is a standard dimension table indicating it did not get set as a degenerate dimension.