Dimensional Model

Dimensional modelling survives every generation of technology because it optimises for the thing that does not change: how people ask analytical questions. A fact table holds the measurements — one row per event or transaction, mostly numeric, very tall. Dimensions hold the descriptive attributes you filter and group by: customer, product, date, store, channel.

The structure makes the common query shape trivially expressible and trivially optimisable, and it makes the model comprehensible to people who are not engineers, which is a genuine architectural property rather than a nicety — a model analysts cannot understand gets bypassed, and the bypass route is a spreadsheet.

Two decisions carry most of the weight. Grain: exactly what one fact row represents, stated in a sentence, decided before anything else, and never mixed within a table. And conformed dimensions: the same customer dimension shared across facts, which is what makes measures from different processes comparable and is the hard organisational work the technique actually depends on.

The claim that columnar engines make dimensional modelling obsolete confuses performance with comprehension. Wide denormalised tables do perform well; they also duplicate business logic, break consistency across subject areas, and make history handling ad hoc.