What is a star schema?

WHAT THIS TESTS This checks foundational dimensional modeling knowledge used in data warehousing and whether you understand why analytics schemas deliberately denormalize.

A GOOD ANSWER COVERS A star schema centers on a fact table that stores the quantitative measures of a business process, such as sales amount, quantity, or duration, along with foreign keys referencing each related dimension. Surrounding it are dimension tables that hold the descriptive, textual context by which you filter and group, such as a date dimension, a product dimension, a customer dimension, and a store dimension. Diagrammed, the central fact with radiating dimensions looks like a star. The dimensions are denormalized, meaning each keeps its attributes flat in one table rather than split across normalized lookup tables. This is preferred for analytics because queries join the fact to each needed dimension in a single hop, producing simple, predictable, fast query plans and intuitive grouping for reporting tools. The trade-off is some data redundancy and larger dimension tables.

COMMON WRONG ANSWERS Reversing the roles, putting measures in dimensions or descriptive text in the fact table. Saying the schema is fully normalized; the deliberate point is denormalized dimensions. Claiming star schemas are bad because of redundancy, missing that the redundancy is an intentional trade for read speed. Forgetting that the fact table is usually the largest and grows fastest.

LIKELY FOLLOW-UPS How does a snowflake schema differ? What are fact table grain and additive versus non-additive measures? How do surrogate keys help dimensions? How do slowly changing dimensions fit in?

ONE CONCRETE EXAMPLE A retail sales star has a sales fact with columns for amount, quantity, and foreign keys to date, product, store, and customer dimensions. Total revenue by product category and month is a single fact-to-two-dimensions query, fast and easy to express, which is exactly what BI dashboards need.