What You'll Master Here
Star = flat dimensions, fewer joins, cheap redundancy. Snowflake = normalized dimensions, more joins, less redundancy. Same information either way.
Chapter 8 built a star with deliberately flat dimensions. A snowflake is the same data with those dimensions normalized. Turn the dial below and watch what normalizing actually costs — and what it never changes.
The chapter runs on one warehouse throughout: Lumen Cinemas, 62 sites, one row per ticket sold — 144 M fact rows over eight years, 4.6 M of them in the last quarter, against a 41,000-row dim_film. By the end you should be able to look at a dimension attribute and say, with evidence, whether it stays flat or earns its own table.
Star = flat dimensions, fewer joins, cheap redundancy. Snowflake = normalized dimensions, more joins, less redundancy. Same information either way.
Star vs snowflake is decided by reflex more often than by argument, and the reflex is usually "normalization is correct" — an instinct borrowed from OLTP that quietly taxes every analytical query.
- star schema
- Fact surrounded by flat, denormalized dimensions; one join per dimension.
- snowflake schema
- A star whose dimensions are normalized into linked sub-tables; multiple join hops.
- outrigger
- A single normalized sub-table hung off one dimension, rather than snowflaking the whole model.
- fact constellation
- Several fact tables sharing conformed dimensions (a "galaxy" of stars).
- dim_film41,000 rows · film_title, genre, certificate, distributor_name, studio_group
select f.studio_group, count(*) as admissions
from fact_ticket_sale t
join dim_film f on f.film_key = t.film_key
group by f.studio_group;- Joins to reach studio_group: 1
- Joins to reach genre: 1
- Tables in this dimension: 1
- 18,400 film rows carry the text "Meridian Group"
| studio_group | admissions |
|---|---|
| Meridian Group | 2,411,400 |
| Northgate | 1,588,200 |
| Kestrel | 600,400 |
Snowflaking every dimension because normalization "feels correct". You add joins and complexity to every query for storage savings that compression already delivered.
Default to a star; snowflake only with a written reason.
Judge the choice by query cost and ownership, not tidiness.
Normalize the specific attribute, not the whole model.
In analytics, redundancy inside a dimension is cheap and joins are expensive — the opposite of the OLTP instinct. Chapter 5 taught you to remove redundancy; this chapter is where you learn when not to.
Chapter 5: normalization & denormalizationStar and snowflake are the same information at different normalization levels; the dial moves join count and storage, never the answer.
