Why does an Inmon-style warehouse keep a normalized integration layer beneath its dimensional marts?
answer
- Where should reconciliation happen — once or per mart?
- Count the mappings: sources times marts
- Modelled on the business, not on a report
- Neutral to reporting change, expensive to query
- Marts inherit definitions instead of re-deriving them
basics
~20 sBecause reconciling sources once, in a model of the enterprise rather than of any report, means every mart built on top inherits the same definitions and history. New sources and new marts attach to that layer instead of re-deriving the truth.
solid answer
~50 sThe integration layer exists to make reconciliation a **one-time, single-place job**. Sources disagree — different customer identifiers, different status codes, different granularity — and someone has to decide what the enterprise means by a customer. Inmon's answer is to make that decision once, in a normalized store modelled on business entities rather than on any report. Three things follow. New marts are cheap and consistent, because they read an already-reconciled store instead of re-deriving it from raw sources. A new source system is absorbed by mapping it into existing entities, so the number of integration paths grows with sources, not with sources times marts. And because the layer is neutral about reporting, it survives BI requirements changing. The costs are real: an extra layer to build and maintain, slower first delivery, and a store nobody can query comfortably — which is why dimensional marts sit on top of it rather than beside it.
code
text · 7 linescrm.contact_id = 'C-9912' name='J. Rivera' status='active'
billing.acct_no = 44120 name='Jose Rivera' status='A'
web.user_email = '[email protected]' name='jose' status=1
-- integration layer decides ONCE:
customer(customer_bk='CUST-7781', name='Jose Rivera', status='ACTIVE')
-- every downstream mart inherits this decisiongo deeper
Recall that this layer sits between sources and marts and exists to reconcile data once, and that users query the marts on top of it rather than the layer itself.
Explain the mechanics: one place to resolve identities and codes, integration paths that grow with sources rather than sources times marts, and a model built around business entities so reporting changes do not invalidate it.
Demonstrate judgment about cost. Be ready to say when the extra layer earns its keep — many volatile sources, many consumers, real reconciliation work — and when it is ceremony that just delays delivery.
Own the argument that stable business structure belongs underneath and volatile reporting belongs on top, and be prepared to defend the maintenance cost of two models against a stakeholder who wants a dashboard this quarter.
## What the layer is for An Inmon-style enterprise data warehouse is an **integration layer**, not a reporting layer. Its job is to take data from many operational systems that disagree with each other and produce one reconciled, historized representation of the business, modelled around enterprise entities — customer, product, order, contract — rather than around any report someone asked for. The disagreement is the point. The billing system knows a customer by account number; the CRM knows the same human by a different identifier; the web platform knows them by email. One system codes an order status as `S`, another as `SHIPPED`, a third as an integer. Somebody must decide what the enterprise means. The architectural choice is *where* that decision is made and *how many times*. ## Why do it once, upstream **Marts stop re-deriving the truth.** If each mart integrates for itself, the same reconciliation logic is written repeatedly by different people at different times, and it drifts. Put it in one place and every mart downstream inherits the same customer, the same history, the same status vocabulary. Divergence becomes structurally hard rather than merely discouraged. **The number of integration paths stays linear.** Without a central layer, N sources feeding M marts trends toward N×M mappings. With one, you build N mappings into the enterprise model, and each mart reads from it. Adding the eleventh source system is a single mapping exercise, not a sweep through every mart. **The layer is neutral about consumption.** Because it models the business rather than a report, a new question or a new BI tool does not invalidate it. Reporting requirements are the most volatile thing in analytics; the shape of the business changes far more slowly. Keeping the volatile part in the marts and the stable part underneath is the whole bet. **History is captured once.** The integration layer keeps change over time — Inmon's *time-variant* and *non-volatile* properties — so a mart that needs point-in-time correctness reads it from a store that already has it, rather than each mart inventing its own history capture from source snapshots. ## Why it is normalized rather than dimensional The layer is normalized because its optimization target is **integration and change absorption**, not query ergonomics. Storing each attribute in the table that owns it means a new source contributes attributes to the entity it describes without restructuring anything else, and one correction lands in one place. Dimensional modelling optimizes for something different — a business user reading a query, and an engine scanning a wide table — so it is applied where users actually are: the marts. This is precisely why the layer is *not* the consumption surface. Answering a business question against it takes many joins and expert knowledge of the model. Pointing BI tools at it is a common anti-pattern and usually means the mart layer was skipped to save time. ## The costs, stated honestly An interviewer will push on the downside, and it exists. - **Slower first delivery.** Nothing is reportable until the enterprise model covers the entities the report needs. That is the central complaint against the approach and the reason bottom-up delivery exists. - **Two models to maintain.** The enterprise model plus the marts, and every attribute travels through both. Changes cost twice. - **Modelling the enterprise is political.** Deciding what a customer *is* requires agreement across departments that may not want to agree. The architecture cannot manufacture that consensus; it only gives it somewhere to live. - **Ripple on change.** A change to a core entity in the integration layer can touch every dependent mart, which is the mirror image of the bottom-up problem where a cross-cutting change touches every fact table. ## How this shows up in modern stacks Most platforms today keep a version of this layer even when nobody calls it Inmon. Raw data lands untouched; a middle layer cleans, deduplicates, resolves identity and historizes; a publish layer exposes stars for consumption. Whether that middle layer is strictly normalized, uses another integration modelling style, or is simply a well-tested set of intermediate transformation models, its purpose is the one described here — integrate once so the serving layer can stay thin and consistent. ## Answering in an interview Say what the layer buys (reconcile once, linear integration paths, consumption-neutral, history in one place), why it is normalized (optimized for absorbing change, not for querying), and why marts still exist on top (users need dimensional models). Then concede the cost — slower time to first report and two models to maintain — because a candidate who names only the benefits sounds like a brochure.
- If the integration layer already holds every attribute, why build marts at all?Because the integration layer is optimized for absorbing change, not for answering questions. Getting a revenue-by-region number from it takes many joins and expert knowledge of the model. Marts present the same data as facts and dimensions that business users and BI tools can navigate, with the grain declared and the joins already decided.
- What breaks first when a team skips this layer and lets each mart integrate for itself?Definitions drift. Two teams write their own identity resolution and status mapping at different times, and their numbers stop matching — usually noticed when an executive compares two dashboards. Fixing it late is expensive because the logic is embedded in many places rather than one.
saying these in an interview costs you the question
- Says the integration layer exists to make queries faster
- Points BI tools directly at the normalized layer
- Claims no marts are needed once the enterprise model exists
- Ignores that the layer delays the first usable report
- Describes it as a raw landing zone with no reconciliation