DAA-C01 · Question #76
What considerations should be taken into account when choosing between a dimensional model and a flattened data set for BI requirements in Snowflake? (Select all that apply)
The correct answer is A. Flexibility and ease of maintenance C. Query complexity and performance expectations D. Data redundancy and normalization requirements. When choosing between a dimensional model and a flattened dataset in Snowflake, A, C, and D are all valid engineering trade-offs that directly impact design decisions. Why each correct answer applies: (A) Flexibility and ease of maintenance: Dimensional models (star/snowflake…
Question
What considerations should be taken into account when choosing between a dimensional model and a flattened data set for BI requirements in Snowflake? (Select all that apply)
Options
- AFlexibility and ease of maintenance
- BAvailability of only specific query types
- CQuery complexity and performance expectations
- DData redundancy and normalization requirements
How the community answered
(62 responses)- A84% (52)
- B16% (10)
Explanation
When choosing between a dimensional model and a flattened dataset in Snowflake, A, C, and D are all valid engineering trade-offs that directly impact design decisions.
Why each correct answer applies:
-
(A) Flexibility and ease of maintenance: Dimensional models (star/snowflake schemas) are easier to extend and modify as business requirements evolve, since changes are isolated to specific dimension or fact tables. Flattened datasets require broader restructuring when logic changes.
-
(C) Query complexity and performance expectations: Flattened datasets reduce join overhead, making queries simpler and faster for straightforward BI tools. Dimensional models introduce multi-table joins but can be optimized for complex analytical patterns - so your expected query patterns drive the choice.
-
(D) Data redundancy and normalization requirements: Flattened models denormalize data, trading storage efficiency for query simplicity. Dimensional models are more normalized, reducing redundancy but requiring joins. If data integrity and storage cost matter, normalization is a real factor.
Why B is wrong: Snowflake's SQL engine supports virtually all query types regardless of the modeling approach. The availability of query types is not constrained by your schema design - both models support aggregations, filters, window functions, etc.
Memory tip: Remember "FQD" - Flexibility, Query performance, Data normalization - the three real-world engineering levers. Option B is a red herring because Snowflake doesn't restrict what queries you can run based on schema shape.
Topics
Community Discussion
No community discussion yet for this question.