Designing the Data Warehouse for Analysis Services - Expert Cube Development with SSAS Multidimensional Models - page 12

Degenerate dimensions
Degenerate dimensions are created when we have columns on the fact table that
we want to use for analysis, but which do not relate to any existing dimension.
Degenerate dimensions often have almost the same cardinality of the fact table;
a typical example is the transaction number for a point of sale data mart. The
transaction number may be useful for several reasons, for example, to calculate a
"total sold in one transaction" measure. Moreover, it might be useful if we need to go
back to the OLTP database to gather other information. However, even if it is feature
that is requested often, users should not be allowed to navigate sales data using a
transaction number because the resulting queries are likely to bring back enormous
amounts of data and run very slowly. Instead, if the transaction number is ever
needed as a dimension attribute, it should be displayed in a specifically-designed
report that shows the contents of a small number of transactions.
Keep in mind that, even though the literature often discusses degenerate dimensions
as separate entities, it is often the case that a big dimension might have some
standard attributes and some degenerate ones. In the case of the transaction number,
we might have a dimension holding both the transaction number and the point of
sale number. The two attributes live in the same dimension, but one is degenerate
(the transaction number) and one is a standard one (the POS number). Users
might be interested in slicing sales by POS number and they would expect good
performance when they did so; however, they should not be encouraged to slice by
transaction number due to the cardinality of the attribute.
From an Analysis Services point of view, degenerate dimensions are no different
than any other dimension. The only area to pay attention to is the design of the
attributes. Degenerate attributes should not be made query-able to the end user
(you can do this by setting the attribute's AttributeHierarchyEnabled property to
False ) for the reasons already mentioned. Also, for degenerate dimensions that are
built exclusively from a fact table, Analysis Services has a specific type of dimension
relationship type called Fact . Using the Fact relationship type will lead to some
optimizations being made to the SQL generated if Relational Online Analytical
Processing ( ROLAP ) storage is used for the dimension.
Slowly Changing Dimensions
Dimensions change over time. A customer changes his or her address, a product
may change its price or other characteristics, and—in general—any attribute of a
dimension might change its value. Some of these changes are useful to track while
some of them are not; working out which changes should be tracked and those
which shouldn't can be quite difficult though.