DAA-C01 Question 214
Single answerIdentify demographics and relationshipsA retail analytics team stores customer transactions in Snowflake and wants business users to explore customer demographics and household relationships in Snowsight. The team has a CUSTOMER table with attributes such as AGE_BAND, INCOME_RANGE, and REGION, and a HOUSEHOLD_MEMBERSHIP bridge table that links multiple customers to a HOUSEHOLD_ID. Analysts need to answer questions such as which income ranges are most common in multi-adult households and how regional demographics differ by household composition. Which approach should the data analyst take to model this correctly for analysis and avoid misleading aggregations?
- A
Create a semantic model that treats CUSTOMER as a dimension, HOUSEHOLD_MEMBERSHIP as a bridge, and carefully defines metrics so household-level counts use distinct HOUSEHOLD_ID while customer-level metrics count CUSTOMER_ID.
- B
Flatten HOUSEHOLD_MEMBERSHIP into the CUSTOMER table so every customer record repeats all other household members, then aggregate directly from the denormalized table for faster dashboard performance.
- C
Model both CUSTOMER and HOUSEHOLD_MEMBERSHIP as fact tables and let business users choose either table in Snowsight depending on whether they want customer or household results.
- D
Use only the CUSTOMER table in the semantic model and infer household relationships at query time from REGION and INCOME_RANGE because demographic similarity is sufficient for household analysis.
Show answer and explanation
Correct answer: A
Explanation
The key requirement is to support demographic analysis together with relationship analysis at different grains: customer and household. In Snowflake analytics scenarios, the safest design is to model descriptive customer attributes separately from relationship structures and then define metrics that respect grain. A bridge table is a common technique for representing associations such as customer-to-household membership. The most important implementation detail is metric definition: distinct HOUSEHOLD_ID for household counts and CUSTOMER_ID for customer counts. This avoids double counting that often occurs when analysts join descriptive entities to relationship tables. This approach is consistent with dimensional modeling best practices and with semantic modeling principles used in Snowsight, where relationships and metric logic should be explicit so business users can analyze demographics and relationships accurately.
- A. Correct.
Correct. This approach preserves the many-to-one relationship between customers and households without duplicating customer demographic records unnecessarily. Using a bridge table supports analysis of relationships such as household composition, while defining metrics at the correct grain prevents double counting. For example, counting households should use distinct HOUSEHOLD_ID, whereas customer demographic analysis should count CUSTOMER_ID. This aligns with dimensional modeling best practices for relationship analysis and semantic-layer design, where dimensions, relationships, and metric grain must be explicit.
- B. Incorrect.
Incorrect. Repeating all household members across customer rows creates a data explosion and makes demographic counts unreliable. Analysts could easily overcount customers or households because each relationship is duplicated across multiple rows. Although denormalization can sometimes help performance, this specific design introduces many-to-many duplication that is especially risky for demographic and relationship analysis.
- C. Incorrect.
Incorrect. CUSTOMER is typically a dimension-like entity containing descriptive demographic attributes, while HOUSEHOLD_MEMBERSHIP is a relationship or bridge structure, not a fact table with additive business events. Treating both as fact tables obscures the intended grain and shifts too much responsibility to business users, increasing the risk of inconsistent metrics and incorrect joins.
- D. Incorrect.
Incorrect. REGION and INCOME_RANGE are demographic attributes, not reliable relationship keys. Two customers with similar demographics are not necessarily in the same household. Household analysis requires explicit relationship data such as HOUSEHOLD_ID or a validated bridge table. Inferring relationships from attribute similarity would produce inaccurate and misleading results.