ARA-C01 Question 122
Single answerData vaultA retail company is building a Raw Data Vault in Snowflake to consolidate customer data from an e-commerce platform, point-of-sale system, and CRM. The source systems use different customer identifiers, deliver data at different times, and occasionally resend historical records with corrected attributes such as email address and loyalty tier. The architecture team wants to preserve full history, support auditability, and avoid reprocessing entire customer structures when only descriptive attributes change. Which modeling approach should the architect recommend?
- A
Create a single wide CUSTOMER table keyed by the CRM customer ID, and use MERGE to overwrite changed attributes so downstream users always see the latest version.
- B
Create a CUSTOMER hub with the business key, separate link tables for relationships to other business entities, and one or more satellites to store descriptive attributes with load dates and record source.
- C
Create a CUSTOMER dimension as Type 1 for frequently corrected attributes and Type 2 only for loyalty tier, because Data Vault does not track all descriptive changes efficiently.
- D
Store each source system's customer record in its own transient table and use a secure view to union the latest records, because Raw Data Vault history is better handled in views than in persistent structures.
Show answer and explanation
Correct answer: B
Explanation
The best answer is to model the customer domain using a hub, links, and satellites. In Data Vault 2.0-style architecture, hubs store unique business keys, links capture associations between business keys, and satellites store descriptive attributes plus historical and lineage metadata such as load date/timestamp and record source. This pattern is especially appropriate when multiple source systems provide the same business concept with differing identifiers, asynchronous loads, and late-arriving or corrected descriptive data. In Snowflake, this approach also aligns well with scalable ELT patterns using immutable historical inserts rather than overwriting current state. A common best practice is to use the Raw Data Vault for historical, auditable ingestion and then build Business Vault and dimensional/presentation models downstream for consumption use cases. This reflects widely used Data Vault modeling guidance and Snowflake architectural best practices for preserving lineage, handling schema evolution, and separating raw historical capture from business-friendly consumption layers.
- A. Incorrect.
Incorrect. A single wide table keyed by one source-specific identifier does not align with Data Vault principles. In a Raw Data Vault, the hub stores the stable business key, not a single system's surrogate or local identifier. Overwriting changed attributes with MERGE removes historical detail and weakens auditability, which is the opposite of the stated requirement to preserve full history and support traceability across multiple source systems.
- B. Correct.
Correct. This is the standard Data Vault modeling pattern for the scenario. A hub captures the core business key for Customer, links model relationships between business entities, and satellites hold descriptive context such as email address and loyalty tier along with metadata like load date/timestamp and record source. This design preserves history, supports auditability, and isolates attribute changes in satellites so the architect does not need to reprocess the entire customer structure when only descriptive attributes change.
- C. Incorrect.
Incorrect. This option mixes dimensional modeling with Data Vault requirements and introduces unnecessary compromises. While Type 1 and Type 2 dimensions are useful in downstream presentation layers, the Raw Data Vault is specifically intended to retain historical changes and source lineage in a more granular, auditable way. The claim that Data Vault does not track descriptive changes efficiently is a misconception; satellites are designed precisely for that purpose.
- D. Incorrect.
Incorrect. Keeping source-specific records in transient tables and exposing only the latest unioned version through views does not satisfy the requirement for durable historical preservation and full auditability. Transient tables reduce or eliminate fail-safe protection and are generally not the core persistent structure for an auditable Raw Data Vault. Views can help present data, but they do not replace the need for hubs, links, and satellites as persistent historical structures.