Data Warehouse vs Operational Database (OLTP)

Feature	Operational DB (OLTP)	Data Warehouse (OLAP)
Purpose	Day-to-day transaction processing	Analysis, decision support
Users	Clerks, DBAs, front-line staff	Managers, analysts, executives
Data content	Current, detailed data	Historical, summarized, consolidated data
Data model	Normalized (E-R model), application-oriented	Denormalized — star/snowflake schema, subject-oriented
Access pattern	Short, atomic transactions (read/write/update)	Complex queries, mostly read-only, large scans
Operations	Insert, update, delete (many small txns)	Aggregate, drill-down, roll-up (few large queries)
Design goal	High concurrency, fast single-record access	Fast aggregation over large volumes
Data volume per query	Small	Large
Time orientation	Reflects current value	Reflects data over time (historical snapshots)
Redundancy	Minimized (normalization)	Encouraged (denormalization for query speed)
Backup/recovery	Critical, transaction-consistent	Less frequent, can be reloaded from source

Conceptual Diagram

 OLTP Systems                     Data Warehouse
 ┌───────────┐   ETL (Extract,   ┌────────────────┐
 │ Sales DB  │──Transform,Load──▶│                │
 ├───────────┤                   │  Subject-      │
 │ HR DB     │──────────────────▶│  oriented,     │──▶ OLAP / Reports
 ├───────────┤                   │  integrated,   │
 │ Inventory │──────────────────▶│  time-variant, │
 │ DB        │                   │  non-volatile  │
 └───────────┘                   └────────────────┘
   (many small,                    (one large,
   normalized DBs)                  denormalized store)

In short: OLTP is built for doing the business (fast writes, current data), a Data Warehouse is built for understanding the business (fast reads, historical/aggregated data). Bill Inmon defines the DW as subject-oriented, integrated, time-variant, and non-volatile — all properties an OLTP system deliberately does not have.