In a dimensional model, you may find a dimension table:
This kind of tables are often called:
as they contain often attributes that are related to the event of the fact table without containing a measure.
In an OLTP environment, you may find them as header tables of transaction lines such as sales, and invoices.
In this dimension table, you may find only two different data type attributes:
To avoid an expensive join between this fact dimension and the fact table, the attribute of this dimension are degenerate i.e. moved from the dimension to the fact table and can then be classified as:
For example of degenerate attribute:
Do not confuse! Degenerate dimensions can in articles referred to a fact dimension.
By moving the dimensional attribute in the fact table, you increase the need for storage and you may use a partial_degeneration
To overcome the increase of capacity needs when you degenerate a complete fact dimension, you can make a partial degeneration of the fact dimension by choosing to degenerate only a set of attribute with a high analytic value (i.e often used in reporting).
While it is generally not considered good dimensional modeling practice to create a dimension with a potential one-to-one relationship with the fact table, in this situation it's a reasonable tradeoff. This design tradeoff works because the reference dimension should very seldom actually join back to the fact table.