DAA-C01 Question 227
Single answerEvaluate and select the data for building dashboardsA retail analytics team is building an executive sales dashboard in Snowsight. The dashboard must show daily revenue, order count, and average order value by region for the last 24 months. Executives expect the dashboard to load quickly during business reviews, while analysts still need access to detailed transaction-level data for ad hoc investigation. The source table contains 4 billion order-line records, including late-arriving updates and occasional corrections to historical orders. Which approach is the BEST choice for selecting the data used by the dashboard?
- A
Point the dashboard directly at the raw order-line fact table and rely on Snowsight chart filters to limit the visible date range to 24 months.
- B
Create a secure view on top of the raw fact table that calculates revenue, order count, and average order value at query time for each dashboard refresh.
- C
Create a curated, aggregated table or dynamic table at the daily-by-region grain for the last 24 months, sourced from the detailed fact table, and use that object for the dashboard while preserving the detailed table for ad hoc analysis.
- D
Export the last 24 months of order data to a CSV file and upload it into a separate Snowflake table before each executive review so the dashboard queries a smaller static dataset.
Show answer and explanation
Correct answer: C
Explanation
The best answer is to select data for the dashboard at the grain and scope required by the business questions, rather than querying the lowest-level transactional data directly. For executive dashboards, Snowflake best practice is typically to use curated, analytics-ready objects that reduce complexity and improve performance. In this scenario, the dashboard needs daily metrics by region over 24 months, so a daily-by-region aggregate is the appropriate serving layer. This approach also supports data quality needs when historical data can change, because the aggregate can be refreshed from the underlying source. Dynamic tables are particularly relevant in Snowflake for maintaining derived tables through declarative refresh, while regular tables built through ELT pipelines are also valid. Views are useful for semantic abstraction and governance, but they do not inherently pre-aggregate or guarantee fast dashboard performance. The key evaluation principle is to choose data that matches the dashboard's required granularity, freshness, and performance expectations, while keeping detailed source data available for deeper analysis.
- A. Incorrect.
Incorrect. Filtering the dashboard to 24 months reduces the result set returned to the visualization, but the underlying queries may still scan very large volumes of detailed data depending on clustering, pruning, and the metrics being computed. Using a 4 billion row order-line table directly for executive dashboards is typically not the best design when the dashboard needs consistently fast performance. This option also mixes dashboard consumption needs with detailed investigative workloads.
- B. Incorrect.
Incorrect. A secure view can be useful for governance and abstraction, but it does not materialize the aggregation by itself. If revenue, order count, and average order value are computed on every refresh from the raw transaction table, dashboard performance can still be poor at scale. The misconception is assuming that a view, including a secure view, inherently improves performance; in Snowflake, a standard or secure view mainly defines query logic and access boundaries, not precomputed results.
- C. Correct.
Correct. Executive dashboards usually perform best when they query curated data at the grain needed by the visuals. A daily-by-region aggregate aligns directly to the dashboard metrics, reduces scanned data, and simplifies dashboard logic. Using an aggregated table or a dynamic table sourced from the detailed fact data supports performance while still allowing updates for late-arriving changes and corrections. Keeping the detailed fact table available separately preserves flexibility for analysts who need drill-back or ad hoc analysis.
- D. Incorrect.
Incorrect. Creating a separate manually refreshed CSV-based dataset adds operational overhead, risks data staleness, and breaks a governed analytics pattern. It also handles late-arriving updates and corrections poorly unless the process is carefully rebuilt each time. Snowflake provides native ways to curate and refresh dashboard-ready datasets without relying on ad hoc file exports.