Snowflake schema

From Wikipedia, the free encyclopedia

The snowflake schema is a variation of the star schema used in a data warehouse. The snowflake and star schema are methods of storing data which are multidimensional in nature (i.e. which can be analysed by any or all of a number of independent factors) in a relational database.

The snowflake schema (sometimes called snowflake join schema) is a more complex schema than the star schema because the tables which describe the dimensions are normalized.

Snowflake schema is nothing but one Fact table which is connected to a number of dimension tables, and the dimension tables in turn connected to other dimension tables

Contents 1 Data normalization and storage 2 Benefits of "snowflaking" 3 See also 4 References 5 External links

[edit] Data normalization and storage

Normalization splits up data to avoid redundancy (duplication) by moving commonly repeating groups of data into a new table. Normalization therefore tends to increase the number of tables that need to be joined in order to perform a given query, but reduces the space required to hold the data and the number of places where it needs to be updated if the data changes.

In a data warehouse, the fact table in which data values (and its associated indexes) are stored, is typically responsible for 90% or more of the storage requirements, so the benefit here is normally insignificant.

However, normalization of the dimension tables ("snowflaking") can impair the performance of a data warehouse. Whereas conventional databases can be tuned to match the regular pattern of usage, such patterns rarely exist in a data warehouse. Snowflaking will increase the time taken to perform a query, and the design goals of many data warehouse projects is to minimize these response times.

Also, many data warehouses are designed to be used by business users, and the added complexity of the snowflake schema will often preclude non-specialist users from forming their own queries.

[edit] Benefits of "snowflaking"

• If a dimension is very sparse (i.e. most of the possible values for the dimension have no data) and/or a dimension has a very long list of attributes which may be used in a query, the dimension table may occupy a significant proportion of the database and snowflaking may be appropriate.
• A multidimensional view is sometimes added to an existing transactional database to aid reporting. In this case, the tables which describe the dimensions will already exist and will typically be normalised. A snowflake schema will hence be easier to implement.
• A snowflake schema can sometimes reflect the way in which users think about data. Users may prefer to generate queries using a star schema in some cases, although this may or may not be reflected in the underlying organisation of the database.
• Some users may wish to submit queries to the database which, using conventional multidimensional reporting tools, cannot be expressed within a simple star schema. This is particularly common in data mining of customer databases, where a common requirement is to locate common factors between customers who bought products meeting complex criteria. Some snowflaking would typically be required to permit simple query tools such as Cognos Powerplay to form such a query, especially if provision for these forms of query weren't anticipated when the data warehouse was first designed.

[edit] See also

[edit] References

• Anahory, S.; D. Murray. Data Warehousing in the Real World: A Practical Guide for Building Decision Support Systems. Addison Wesley Professional. 
• Kimball, Ralph (1996). The Data Warehousing Toolkit. John Wiley. 

[edit] External links

• "Why is the Snowflake Schema a Good Data Warehouse Design?" by Mark Levene and George Loizou
• Article "A Trio of Interesting Snowflakes" (Beat three common modeling challenges with extensions of the dimensional model) by Ralph Kimball
• Designing Snowflake Schema
• Snowflake Schema Design
• Star vs. Snowflake Schemas