Another essential building block of an analytical model is a dimension. If a fact repre‐ sents a business process or action (a verb), a dimension describes the fact (an adjective).

The dimensions are designed to describe the facts’ attributes and are referenced as a foreign key from a fact table to a dimension table. The attributes modeled as dimen‐ sions are any measurements or data that is repeated across different fact records and cannot fit in a single column. For example, the schema in Figure 16-4 augments the SolvedCases fact with its dimensions.

Figure 16-4. The SolvedCases fact surrounded by its dimensions

The reason for the high normalization of the dimensions is the analytical system’s need to support flexible querying. That’s another difference between operational and analytical models. It’s possible to predict how an operational model will be queried to support the business requirements. The querying patterns of the analytical models

are not predictable. The data analysts need flexible ways of looking at the data, and it’s hard to predict what queries will be executed in the future. As a result, the normaliza‐ tion supports dynamic querying and filtering, and grouping the facts data across the different dimensions.