Why are reporting tables usually denormalized when transactional databases are normalized?

Normalization optimizes for writes and integrity, so a transactional database avoids duplicating data and updates one row in one place. Reporting optimizes for reads across huge scans, where every join costs time and every extra table costs the analyst clarity. A denormalized star schema means fewer joins, faster queries on columnar storage, and column names an analyst can understand without a data dictionary.

They are solving different problems. A transactional database is built for lots of small writes with strict integrity, so normalizing means a customer's address exists once and updating it is one write. An analytics table is built for scanning millions of rows at a time, where every join is a cost and a fifteen table join is both slow and hard to get right. So we denormalize into facts and conformed dimensions, which cuts joins and gives analysts readable column names instead of a schema diagram and three lookup tables. Columnar storage makes this cheap, because repeating a country string across millions of rows compresses down to almost nothing. The other reason is operational. Running a heavy analytical scan against the production database competes with the application for resources, and I have seen an ad hoc query take a checkout service down. Even ignoring modeling entirely, the analytics workload belongs somewhere it cannot hurt customers.