Data Marts & the Semantic Layer

## What a data mart is A **data mart** is the part of an analytics platform that an actual analyst points a BI tool at. It is a curated set of fact and dimension tables scoped to one **subject area** (orders, subscriptions, support tickets, web sessions) or one **department** (finance, marketing, supply chain). It contains the tables that audience queries, at the grains they query them at, with names in their language — `net_revenue`, not `amt_net_calc_v3`. Physically a mart is not a special technology. It may be a schema in the same warehouse, a separate database, a set of views, or a folder of models in a transformation project. "Data mart" is a **scoping, naming and ownership** decision, not a storage format. ## What it is not: the whole warehouse The warehouse — or the shared modelled core beneath the marts — holds the complete estate: every business process modelled at atomic grain, with dimensions shared across processes. It is deliberately broad, deliberately neutral, and deliberately not shaped for any one audience. Two consequences follow: - **Breadth.** A finance analyst should not have to navigate four hundred tables to find the three they need. A mart is the answer to "which tables are mine?" - **Neutrality.** The core cannot encode finance's definition of a closed period *and* marketing's, because they differ. The mart is where an audience's particular business rules and vocabulary get applied. ## Subject-area marts versus departmental marts Subject-area marts follow business processes, which are stable: a company still takes orders after a reorg. Departmental marts follow the org chart, which is not stable — when marketing splits into growth and lifecycle, a `marketing` mart has to be carved up or grow two owners. The practical compromise is subject-area marts as the substrate, with thin department-facing views or a semantic-layer scope on top. That keeps the expensive part (the modelled facts and dimensions) organised around durable things and the cheap part (naming and selection) organised around whoever is asking this quarter. ## Where a mart is built from — the decision that matters A mart built **on top of the shared modelled core** inherits its conformance: the same customer dimension, the same date dimension, the same atomic fact rows. Two such marts can be reconciled, because they descend from the same rows. A mart built **directly from source extracts** by one team — because the shared model lacked a column, or the request queue was six weeks long — is a second, private implementation of the same business logic. It will diverge, and it will diverge silently, because nothing joins the two together to reveal the gap. This is the classic siloed-mart failure, and note that the root cause is usually organisational (the shared path was too slow) rather than technical. If you find yourself refusing such marts, you also have to make the governed path fast enough to use. ## What belongs in a mart, and what does not Belongs: selections and renames of core tables; joins pre-resolved for convenience; measures that only this audience needs; business rules genuinely specific to this audience (finance's fiscal calendar, marketing's attribution window). Does not belong: a re-derivation of an atomic fact from raw with slightly different filters; a private copy of a shared dimension with locally-edited attributes; a business rule that three other departments will also need — that one belongs in the shared core so everyone inherits it. ## Marts and the semantic layer are complements A **semantic layer** defines metrics, dimensions and join paths once, so consuming tools ask for `net_revenue by month` rather than writing SQL. It is not a replacement for marts, and marts are not a replacement for it: - A semantic layer over an ungoverned pile of tables still returns wrong numbers — it just returns them consistently. - Marts without a semantic layer still let every dashboard re-derive metrics with its own filters. In a modern stack you usually have both: modelled core → marts → semantic layer → tools. ## In an interview Define it in one sentence, then immediately say what it is built from and who owns it. The follow-up is almost always some version of "a team wants their own mart because ours doesn't fit — what do you do?", and the expected answer is: find out whether the missing thing is genuinely audience-specific (fine, put it in their mart) or generally useful (put it in the core), and never let a second copy of the atomic facts appear.