# Model Data for Analytics, Reporting, and Applications Describe how you would model a shared business domain so that exploratory analytics, recurring reports, and data-backed applications can use it without creating contradictory definitions. Address source ingestion, facts and dimensions, history, data contracts, and serving patterns. ### Constraints & Assumptions - Source systems update at different cadences and can emit corrections. - Reports require reproducible historical values. - Applications need lower latency than most analytical scans. - Sensitive attributes require controlled access. - One metric definition should be reused across consumers. ### Clarifying Questions to Ask - Which entities, events, and business metrics are authoritative? - Is historical point-in-time reconstruction required? - What freshness and latency does each consumer need? - Which dimensions change over time? ```hint Start from grain For every fact table, state exactly what one row represents before choosing keys, dimensions, or aggregates. ``` ### What a Strong Answer Covers - Explicit grains, keys, facts, dimensions, and slowly changing attributes - Reproducible metric definitions and correction handling - Separate analytical and low-latency serving projections - Contracts, lineage, quality checks, and access control ### Follow-up Questions 1. How would you reproduce a report after a customer's segment changes? 2. Where should a shared metric definition live? 3. What signals show that an application should not query the warehouse directly?