There is, in Kimball’s opinion, only one permissible case for using the
snowflake technique. He uses the term outrigger tables to describe this partic-
ular type of snowflaking, so we kindly adopt the same word for this to avoid
any confusion. First, let’s explain what we mean by an outrigger: Suppose you
have a set of attributes that are all dependent on one of the dimension’s higher
level attributes.
An example is the database of Zipcensus (fake movie reseller), which contains a large set of analytical attributes. Zip code is a higher level attribute than customer (you can have multiple customers sharing the same zip code) and all Zipcensus attributes are dependent on zip code. If you store all these additional columns in the customer table, you are denormalizing a lot of data and cluttering the dimension table with a lot of extra attributes—in this case, 112 extra attributes besides the zip code itself. Table shows an example of the Zipcensus outrigger table in combination with the customer dimension.
An example is the database of Zipcensus (fake movie reseller), which contains a large set of analytical attributes. Zip code is a higher level attribute than customer (you can have multiple customers sharing the same zip code) and all Zipcensus attributes are dependent on zip code. If you store all these additional columns in the customer table, you are denormalizing a lot of data and cluttering the dimension table with a lot of extra attributes—in this case, 112 extra attributes besides the zip code itself. Table shows an example of the Zipcensus outrigger table in combination with the customer dimension.
