A star schema puts one fact table — a narrow table of numeric measurements at a fixed grain (one row per event) — at the centre, radiating out to short, wide dimension tables that describe the "who / what / where / when" of each fact. Every dimension connects to the fact table through a single foreign key, which is why the diagram looks like a star rather than a tangled web of joins.
Dim_Customer panel changes shape: Type 1 overwrites history (one flat slab), Type 2 keeps a new row per change with effective/expiry dates (a stack of slabs), Type 3 keeps only the immediately-prior value in an extra column (two side-by-side columns).Ralph Kimball popularised the star schema in the 1990s specifically because it maps onto how business users ask questions — "sales by region by month" — rather than how an OLTP system stores data normalised into dozens of tables.
A central fact table wired to a ring of dimension tables in a 3D star schema, letting you change the fact table's grain, add or remove dimensions, and watch a customer dimension reshape itself under each type of slowly changing dimension.
Grain controls how many facts exist per business event; every dimension attaches to the fact table through a single foreign key; and SCD Type 1/2/3 trade off history for storage in visibly different ways.
Pick a fact grain, drag the dimension-count slider, and switch the customer dimension between SCD types. Click "Run join query" to watch a query pulse travel from every dimension into the fact table.
Because every dimension joins to the fact table directly rather than through other dimensions, a star schema query never needs more than one hop per dimension — which is exactly why it's fast for BI tools.