Schema suitability: Evaluate the claim. “Star schema is suited to online transaction processing (OLTP) and therefore is generally used in operational systems, operational data stores (ODS), or an enterprise data warehouse (EDW).”

Introduction / Context:
Star schemas place a central fact table at a defined grain with surrounding dimensions for slicing and dicing. They are optimized for analytics (OLAP)—fast aggregations, drill downs, and ad hoc queries—not for high-volume transactional updates typical of OLTP systems. This statement claims star is suited to OLTP and used in operational stores; we must assess that.

Given Data / Assumptions:

• OLTP emphasizes write performance, strict normalization, and transaction integrity.
• OLAP emphasizes read performance, denormalization, and query simplicity.
• ODS may use more normalized structures to mirror sources for integration and light reporting.

Concept / Approach:
Star schemas favor denormalization and surrogate keys to enable fast aggregates and simpler joins, trading off some update anomalies that are irrelevant for read-mostly analytics. OLTP uses normalized 3NF designs to avoid redundancy during frequent inserts/updates. Therefore, stars are generally for EDW or data marts, not for operational systems or ODS cores.

Step-by-Step Solution:

Verification / Alternative check:
Benchmark analytical queries on star vs. 3NF: star typically reduces joins and improves aggregation speed; OLTP updates favor 3NF.

Why Other Options Are Wrong:

• “Correct” conflicts with well-established workload design principles.
• “Micro-batch ODS” and “snowflaked dimensions” are tangential and do not convert OLTP into OLAP.
• “Indeterminate” is unnecessary; the design intent is clear.

Common Pitfalls:
Forcing star schemas into heavily transactional contexts; misunderstanding ODS vs. EDW roles; mixing grains in a single fact table.

Final Answer:
Incorrect