A gold dataset for a finance dashboard aggregates daily revenue by region from a silver Delta table that receives inserts, updates and deletes every night. The dashboard has to read precomputed results rather than recomputing the aggregate on each query, the definition must live in Unity Catalog as one SQL object, and the team wants Databricks to work out how much of the result needs rebuilding on each refresh instead of writing that logic itself. Which gold object fits the requirement?
- AA materialized view defined over the silver table with the aggregation in its query, refreshed on a nightly schedule. Correct
- BA managed Delta table populated by a nightly Lakeflow Jobs task that overwrites the whole aggregate from the silver table on every run.
- CA streaming table defined over the silver table with the aggregation in its query, refreshed on a nightly schedule.
- DA view defined over the silver table with the aggregation in its query, read directly by the dashboard at report time.
Why A is correct: A materialized view persists the aggregate in Unity Catalog so the dashboard reads stored rows, and its refresh recomputes incrementally where the query and the source changes allow, falling back to a full recompute by itself when they do not.
Why B is wrong: This does store results and is a familiar pattern, which makes it tempting, but the team has to author and maintain the aggregation and overwrite logic itself and every run recomputes the full history rather than the part that changed.
Why C is wrong: Streaming tables do store results and refresh incrementally, which makes them look interchangeable here, but they process an append-mostly source and the nightly updates and deletes in the silver table are the change type a streaming read is not designed to consume.
Why D is wrong: A view gives the same single SQL definition in Unity Catalog, which is the trap, but it holds no data of its own and runs the aggregation against the silver table on every dashboard query.