Database Reference
In-Depth Information
It's sometimes the case that users will request that one or more attributes from a junk
dimension will be split off into a new dimension, and you will need to be careful if
you do this because of the risk that existing queries that reference the junk dimension
will break as a result of invalid MDX unique name references.
Modeling ragged hierarchies
Ragged hierarchies are another common design problem to deal with when
building an Analysis Services dimension. The hierarchies we've dealt with so far can
be easily separated out into distinct levels and can be thought of as pyramid-shaped:
all of the members on the hierarchy have at least one child, except the members
on the lowest level, which have no children at all. Ragged hierarchies, on the other
hand, are bush-shaped. The members at any given level may or may not have
children. Common examples of ragged hierarchies are those that represent a chart of
accounts or the organizational structure of a company.
Modeling parent/child hierarchies
One way of modeling a ragged hierarchy in a data warehouse is with a table with a
self-join: every row in the table represents an item somewhere on the hierarchy, and
every row has a key column and a foreign key that joins back onto the key column in
order to store the key of the parent item. Here's an example taken from the Adventure
Works data warehouse:
Search WWH ::
Custom Search