DP-600 - Prepare Data - Section 2.5

Implement a star schema for a lakehouse or warehouse and enrich data by adding columns or tables, denormalising, and aggregating.

Design a star schema with fact and dimension tables using surrogate keys to optimise analytical query performance in a Lakehouse or Warehouse. Enrich the model by adding derived columns, pre-aggregated tables, and denormalised attributes that reduce join complexity at query time.

star schemafact and dimension tablesdenormalisationaggregationsurrogate keys

Practice question for this objective

Free samplePrepare Datahard

Two fact tables in a "Lakehouse", Sales and Returns, both reference products and dates. Reports must slice both facts by the same product attributes and date attributes with consistent results. Which modelling approach best supports analysing both facts together across shared dimensions?

  • ACreate a separate Product dimension and a separate Date dimension per fact table so that Sales and Returns never share any dimension rows.
  • BMerge the Sales and Returns rows into one wide flat table and drop the separate Product and Date dimensions from the model altogether.
  • CBuild one conformed Product dimension and one conformed Date dimension, then relate both Sales and Returns fact tables to each shared dimension. Correct
  • DRelate the Returns fact table directly to the Sales fact table and let it inherit the product and date filter context through Sales.
Share a single conformed dimension across multiple fact tables so the same attributes slice every fact consistently in a star schema. Conformed dimensions are dimensions of identical structure and content reused by more than one fact table, which is the mechanism that lets multiple facts be filtered and compared on the same attributes without divergence.

Why A is wrong: Duplicate per-fact dimensions seem isolating but cause divergent keys and attributes, so the two facts cannot be sliced consistently by the same product or date.

Why B is wrong: Flattening two grains into one table conflates distinct events and loses the shared dimensional structure that consistent cross-fact slicing actually requires.

Why C is correct: Conformed dimensions shared by both facts guarantee identical attributes and keys, so slicing Sales and Returns by the same product or date gives consistent comparable results.

Why D is wrong: Chaining one fact table to another is invalid star modelling and propagates filters unpredictably, so it cannot deliver consistent slicing across both facts.

See more DP-600 practice questions, answers explained.

More in this domain

Back to all Prepare Data objectives, or the DP-600 cert hub.

Examworthy is not affiliated with or endorsed by Microsoft. Original, blueprint-aligned practice material only.