What is a snowflake schema?

A snowflake schema starts like a star schema, a central fact table of measurable events surrounded by dimension tables for context (product, customer, date). The difference is that snowflake dimensions are broken into further normalized tables, so a product dimension might split into separate category and brand tables.

• Pros: less duplicated data, easier to keep dimension attributes consistent, smaller storage.
• Cons: more tables and joins, which can make queries harder to write and slower to run.

Snowflaking suits environments that prize data integrity and storage efficiency, whereas star schemas favour simpler, faster reporting. (The name has nothing to do with any vendor called Snowflake.)

Making sense of a snowflake schema by hand means tracing keys across many linked tables, which is exactly the friction iDBQuery removes. Its semantic layer and automatic schema introspection map the relationships between fact and dimension tables for you, so when you ask a plain-language question, iDBQuery infers the right joins across the snowflake, writes the SQL, and cites the answer back to the underlying rows, no manual join-hunting required.