Every few years, someone announces that dimensional modeling is dead. The data lake was supposed to kill it. Then NoSQL databases were supposed to finish the job. Then came cloud warehouses with storage so cheap and computing so elastic that, we were told, you could pour everything into one enormous table and let the machine sort it out. Today the obituary writers have a fresh candidate: AI models that answer questions in plain English, which seem to make the careful arrangement of data a quaint relic. Each obituary names a different killer, and each killer is the latest storage technology.
And yet the star schema, the design Ralph Kimball popularized in The Data Warehouse Toolkit in 1996, is still the shape most analytical data takes by the time a human being looks at it. That is a puzzle worth explaining. Technologies usually die when something better comes along. When one keeps surviving its predicted replacements, decade after decade, the likeliest explanation is that its success was never about the technology. It was about us.
That is the argument of this essay. Dimensional modeling endures because it is fitted to the shape of human questions, and to the questions that minds ask of businesses. Its engineering virtues (speed, flexibility, a talent for history) are real, but they follow from that first fact rather than explaining it.
Every hype cycle files an obituary. Each one is paid in full, then quietly forgotten.
The star keeps printing. Thirty years on, nobody has torn off the receipt.
What a dimensional model is, explained with a receipt
Pull a receipt out of your wallet. Somewhere on it is a line saying you bought three tubes of toothpaste for $12. That line records an event, and the event carries two kinds of information.
The first kind is the measurement: three units, twelve dollars. These are numbers you can add, average, or compare. Data modelers call them facts. The second kind is the context: who bought the toothpaste, what brand it was, which store sold it, and when. These are not things you add up. They are the lenses through which you look at the numbers. Data modelers call them dimensions.
A dimensional model simply puts the measurements in one central table and the context in a ring of surrounding tables, each linked to the center. Sketch it on a napkin and it looks like a star, which is why it is called a star schema. A variant that splits some outer tables into smaller pieces looks more like a snowflake, and is called, with admirable literalism, a snowflake schema.
That is essentially the whole idea. A skeptic might reply that anything so simple cannot be important. I will argue the opposite: the simplicity is the point, and everything else follows from it.
Reason 1: It matches the way people already think
Psychologists and linguists have long observed that people understand the world as a series of events, each with a cast of participants: who did what, to whom, where, and when. Language itself is built on this template. Nearly every sentence has a verb for what happened, surrounded by phrases naming the doer, the thing affected, the place, and the time.
Now look again at the star schema. The fact table is the verb. The dimension tables are the cast. "Maria bought three tubes of toothpaste at the Burbank store on Tuesday" maps onto one fact table and four dimensions almost word for word. A dimensional model is, in effect, a grammar for business events, and every literate adult already speaks it.
Compare the databases that run a company's daily operations. They are designed to record transactions without storing any piece of information twice, a goal called normalization after the rules Edgar Codd laid out in the 1970s. That is excellent for writing data accurately, but it scatters the story across dozens of tables. A simple question like "How did toothpaste sell in the West last quarter?" can require stitching together a dozen tables whose names only a database administrator could love. The engineers who built the system rarely notice how opaque it is, because they suffer from what psychologists call the curse of knowledge: once you know something, it is very hard to imagine not knowing it.
When the structure of the data matches the structure of thought, good things cascade. More people can read the model and relate it to the business they already understand. People who can read it can write their own reports, which frees engineers for harder problems. A shared model gives the organization a shared vocabulary, so meetings spend less time on whose number is right and more on what the number means. And what is easy to explain is easy to document, which is the raw material of governance, lineage, and data quality.
Reason 2: What is easy for the mind is easy for the machine
Here is a happy coincidence that turns out not to be a coincidence. The design that makes data legible to people also makes it fast for computers, because both benefit from predictable structure. Think of a library shelved by subject versus a warehouse where books lie wherever they landed. A request for "history of medicine after 1990" sends you to one aisle in the library and on a tour of every pile in the warehouse.
Questions against a star schema nearly always take one shape: filter by some dimensions, group by others, and add up the facts. Because the shape is so regular, the machinery can be tuned for it. Monthly totals can be stored in advance instead of summed from millions of receipts each time. Indexes on the dimensions work like the index at the back of a book. Database optimizers have special strategies for star-shaped queries, and repeated values like "West" compress extremely well, which means fewer disk reads and faster answers.
A skeptic will point out that modern cloud engines are fast enough to brute-force almost anything. That is partly true, and it is a real change since the 1990s. But a flat table with five hundred columns can be scanned quickly and still be incomprehensible, and on platforms that bill by data scanned, brute force has a price tag. Speed was never the deepest reason for the star schema. Clarity was.
Reason 3: It grows without breaking
Businesses never stop asking new questions, so a design that cannot absorb them is doomed. The star schema handles growth the way a bicycle wheel takes a new spoke: you attach it to the hub without rebuilding the rim. When a retailer suddenly wants sales by promotion, the modeler adds a promotion dimension. Time, product, store, and customer are untouched, and every existing report keeps working.
Hierarchies let people zoom, from year to quarter to month to day, the way you zoom a digital map. The level of detail, which modelers call grain, is a deliberate choice, so detailed tables for investigators and summary tables for executives can live side by side. In fairness, growth is not free: changing the grain of an existing table is real surgery. But the common case, a new way of slicing the same events, is cheap, and the common case is what most organizations face most of the time.
Reason 4: It remembers
If you could tally every question asked of every business report, I suspect the most common word would be compared. Compared to last year, to last month, to the week before the price change. A number by itself means almost nothing until you know what it used to be. Dimensional models are built for this obsession: time is a dimension in its own right, with its calendar, fiscal periods, holidays, and seasons spelled out in advance, so trends, seasonality, and year-over-year comparisons are easy to ask.
There is a subtler problem the technique has also worked out. The context around events changes too. If a store moves from the West region to the Mountain region, should last year's sales count toward the old region or the new one? The honest answer is "it depends on the question," and the method known as slowly changing dimensions keeps both versions of history so the analyst can choose. In regulated fields like finance and healthcare, an accurate, well-organized history is also a legal obligation, and far easier to defend in an audit than a heap of old files.
Finally, many organizations have spent years building dimensional warehouses and keep extending them. It is tempting to dismiss that as inertia. But the real asset in an established warehouse is not the hardware. It is years of agreed definitions and reconciled history, and those are expensive to rebuild.
Reason 5: The questions it answers are the questions businesses ask
One could prove the technique's versatility with a list of industries. The single pattern they share is more illuminating. Nearly every analytical question in nearly every field takes the same form: how much of something, broken down by something else, over some period of time.
A finance team asks how margin changed by product line this year. A hospital administrator asks whether readmission rates are improving at each facility, by diagnosis and month. A retailer asks which stores should get more of an item; an HR leader asks where turnover is highest by department and tenure; an energy manager asks where emissions are rising by site. The vocabularies, regulations, and stakes differ enormously. The logical shape of the questions does not. Dimensional modeling did not have to be adapted to each of these fields. It was already the shape of the questions.
Where it does not fit
A defense that admits no weaknesses is a sales pitch. Raw, unstructured material such as images, clinical notes, and server logs does not arrive as tidy events, and belongs in a lake until someone extracts its structure. A data scientist hunting for unknown patterns often wants the raw, unsummarized feed, which a curated model may have filtered out. Questions about networks, like who is connected to whom through how many steps, are answered far more naturally by graph databases. And the systems that take orders and book appointments need normalized designs built for writing, not reading.
None of these competes for the same job. Mature architectures stack the approaches: raw data lands in a lake, gets cleaned and conformed in the middle, and is presented to people in a dimensional layer at the top. The question was never star schema or data lake. It was always which tool for which stage.
The verdict, and the AI question
Which brings us back to the newest obituary. If an AI model can answer any question in plain English, why arrange the data at all? Because the machine faces the same problem as the novice analyst. To answer "How did revenue in the West change last quarter?" it must know what revenue means here, which table holds it, how the West is defined, and which calendar "last quarter" refers to. Hand it hundreds of cryptic tables and it will guess, sometimes confidently and wrongly. Hand it a star schema with clear facts, named dimensions, and agreed definitions, and it has the most legible map of the business anyone has yet devised.
Storage technologies change every few years. The shape of the questions people ask has not changed since merchants first kept ledgers.
That is the deeper lesson of the star schema's longevity. Query engines get faster by orders of magnitude, and the latest storage technology will be old news soon enough. But how much, of what, by what, over time: the shape of human questions is unlikely to change, and a design fitted to it will keep outliving the technologies that were supposed to replace it. So is dimensional modeling dead? The reports of its death, to borrow a line attributed to Mark Twain, have been greatly exaggerated. It is not the answer to every data problem, and it was never meant to be. But for turning a company's events into answers people can understand and trust, it remains the best idea we have.
Four questions for your own warehouse
- Can a newcomer read it? Show the model to a new analyst. If they can name the events and their context in an afternoon, the design is doing its job.
- Does each number have one meaning? If two dashboards disagree about revenue, the problem is the vocabulary, not the visualization.
- Can it take a new question without surgery? A new dimension should be an addition, not a rebuild.
- Could a machine read it too? The model you would hand a new hire is the model you should hand an AI.