What is the grain of a fact table and why does everyone start there?
The grain is what one row means: one order line, one impression, one state transition. Every other decision (which dimensions attach, which measures are additive, what double-counting looks like) derives from it. Interviewers open with grain because a wrong grain invalidates everything drawn after it.
SCD Type 1 versus Type 2, in one breath each?
Type 1 overwrites: current value only, history gone, fine for corrections. Type 2 versions: a new effective-dated row per change, so facts join to the value that was true at event time. The cue for Type 2 is any phrasing like 'as of', 'at the time', or 'history'.
What is the difference between a star schema and a snowflake schema?
A star schema denormalizes dimensions flat, so each one is a single table joined once. A snowflake schema normalizes them into sub-dimensions, trading extra joins for less duplication. Analysts and BI tools want stars: fewer joins, predictable query shapes, and better performance for OLAP analytical warehouses. The snowflake answer is occasionally right for very large, very duplicated dimension attributes, and saying that exception is what keeps the answer senior.
Fact table types beyond the transaction fact?
Periodic snapshots (balance per account per day), accumulating snapshots (one row per process instance with milestone dates that fill in), and factless facts (event occurred, nothing to measure). Recognizing an accumulating-snapshot prompt, like an order fulfillment pipeline, is a strong mid-level signal.
What makes a dimension conformed, and why bother?
The same dimension, same keys and attributes, shared across fact tables, so revenue by customer and support tickets by customer agree on who the customer is. It is the difference between a warehouse and a pile of marts. The cost is governance, which is why the follow-up asks who owns the dimension.
Surrogate keys or natural keys?
Surrogate keys in the warehouse, natural keys preserved as attributes. Source systems recycle ids, merge companies, and change formats; a surrogate key decouples the model from all of it and is what makes SCD Type 2 rows possible at all, since one natural key maps to many versions.
Where do degenerate dimensions fit?
An identifier with no attributes of its own (order number, ticket id) lives directly on the fact instead of a one-column dimension table. It exists so analysts can group and drill without a pointless join. Naming it correctly is a small, cheap signal of fluency.
How do you model many-to-many relationships in a dimensional model?
A bridge table with the two keys and, when weighting matters, an allocation factor so measures do not double-count. The canonical example is accounts to customers in banking. The follow-up probes whether you know the allocation rows must sum to 1 per fact.
How do you implement an SCD Type 2 pipeline?
Compare the incoming row against the current row for that natural key. If tracked attributes are unchanged, do nothing. If any changed, close the current row by setting valid_to to the change timestamp and is_current to false, then insert a new row with a fresh surrogate key, valid_from at the change timestamp, valid_to as NULL or a far-future sentinel, and is_current true. Wrap both writes in one transaction, and key the MERGE so a re-run is idempotent.
What is normalization, and what are 1NF, 2NF, and 3NF?
Normalization removes redundancy so an update happens in one place. 1NF requires atomic column values with no repeating groups. 2NF additionally removes partial dependencies, where a non-key column depends on only part of a composite key. 3NF removes transitive dependencies, where a non-key column depends on another non-key column. OLTP systems target 3NF; analytical layers denormalize back down on purpose.
When do you deliberately denormalize?
In the serving layer, when join cost at read time outweighs the redundancy cost at write time. A star schema's dimensions are denormalized precisely so a query joins once per dimension rather than walking a normalized chain. The condition that makes it safe is a single writer: the pipeline owns the table, so the duplicated attribute cannot drift the way it would with ad-hoc updates.
What is a slowly changing dimension Type 3, and when is it enough?
Type 3 adds a column instead of a row: current_value alongside previous_value. It captures exactly one prior state, so it is enough when the business only ever asks about before-and-after a single known reorganization, and it keeps the row count flat. It is wrong whenever full history matters, which is why Type 2 is the default answer.
What is a factless fact table?
A fact table with foreign keys but no numeric measures, recording that an event or a coverage relationship existed. Ad impressions are the canonical example: user, campaign, timestamp, and nothing to sum. You answer questions by counting rows or by checking absence against a coverage table, such as which products were on promotion but sold nothing.
What are additive, semi-additive, and non-additive measures?
Additive measures sum across every dimension, like revenue. Semi-additive measures sum across some but not time, like an account balance or inventory level, where the correct time aggregate is a snapshot or an average. Non-additive measures cannot be summed at all, like a ratio or a percentage, and must be recomputed from their numerator and denominator after aggregating those separately.
How do you handle late-arriving dimensions?
A fact lands whose dimension row does not exist yet. The standard answer is an inferred member: insert a placeholder dimension row with the natural key and unknown attributes, attach the fact to that surrogate key immediately, and let the real dimension load update the placeholder in place when it arrives. The alternative, parking the fact in a quarantine table, delays reporting and is usually the weaker choice.
What is a data vault and when would you choose it over a star schema?
Data vault splits the model into hubs (business keys), links (relationships), and satellites (descriptive attributes with history). It is built for auditability and for absorbing schema change from many source systems without remodeling. The tradeoff is many more joins, so it usually sits as an integration layer with star schemas built on top for consumption.
What is medallion architecture?
A layering convention: bronze holds raw ingested data as received, silver holds cleaned, deduplicated, conformed data, and gold holds business-level aggregates and dimensional models for consumption. Its value in an interview is that it forces you to say what each layer is allowed to assume, which is the same discipline as naming the grain.
What is a surrogate key and why not just use the natural key?
A surrogate key is a meaningless integer or hash the warehouse issues. It insulates you from source systems that reuse, reformat, or recycle their identifiers, it keeps joins narrow and fast, and it is required for SCD Type 2, where one natural key must map to several rows. Keep the natural key on the row as a unique-per-version attribute so lineage back to the source stays intact.
How do you choose a partition column for a large fact table?
Pick the column that most queries filter on, which is almost always an event date, so partition pruning eliminates most of the table. Then check cardinality: too fine and you get the small files problem, too coarse and pruning does not help. Never partition on a high-cardinality key like user_id, and never on a column that arrives late enough to force partition rewrites.