A retailer runs a point-of-sale system that records thousands of short sales transactions per minute, and a separate warehouse where analysts aggregate years of sales by region and product. Which description matches the two systems' designs?
Select an answer to reveal the explanation.
Short Explanation
The cash register needs to write lots of tiny transactions fast and clean, which is OLTP. The analyst wants to read mountains of history and sum it up, which is OLAP. Mix them up and you've got a register that crawls or a warehouse that can't add.
Full Explanation
Online transaction processing systems handle many concurrent, short transactions that insert, update and read small numbers of rows. They are normalized to minimize redundancy, so each fact is written once, writes stay small and integrity is enforced by keys and constraints; a point-of-sale system is the classic example. Online analytical processing systems serve queries that scan and aggregate large volumes of historical data. They are typically denormalized, often as star or snowflake schemas with fact and dimension tables, to reduce joins and speed aggregation; a sales warehouse fits this pattern. Describing the register as a nightly-refreshed OLAP cube ignores that it must capture each sale as it happens, and describing the warehouse as tuned for single-row lookups contradicts its job of scanning and aggregating years of history. Treating both as OLTP because they hold the same sales facts ignores that workload, not subject matter, drives the design. Treating both as OLAP because of high volume ignores that the register's volume is many small writes, not large reads. Exam caveat: data volume alone does not decide OLTP versus OLAP; the access pattern does. Operational check: profile each system's workload and confirm the register is dominated by short write transactions and the warehouse by large read and aggregate queries.