Most application databases are designed to handle individual transactions efficiently. When a user creates an order or updates a profile, the system prioritizes data integrity and write speed. These systems, known as On-Line Transaction Processing (OLTP) environments, often struggle when the objective shifts to large-scale data aggregation and reporting.

Analytical architecture addresses this limitation by organizing data for retrieval speed rather than transaction throughput. In this chapter, we define the structural differences between operational workloads and analytical workloads (OLAP). A primary area of study is the physical storage layer. We will compare row-oriented storage, which suits transactional systems, against columnar storage, which enables faster aggregation over large datasets.

Take for instance a standard summation operation over a dataset $D$:

$S = \sum_{x \in D} x$

In a row-based system, computing $S$ often requires reading entire rows just to access the variable $x$. In a columnar system, the database engine reads only the specific column containing $x$, which significantly reduces Input/Output (I/O) overhead.

We will also examine the function of denormalization. While normalization eliminates redundancy in operational databases, analytical models frequently introduce redundancy intentionally to minimize complex joins during query execution. By the end of this chapter, you will be able to distinguish between these architectural patterns and interpret query execution plans to verify performance differences.