What are dependent and independent data marts, and which does Inmon's architecture produce?

## The distinction Data marts are subject-area or departmental slices of analytical data. The dependent/independent split classifies them by **their upstream**: - **Dependent mart** — sources from a central integrated warehouse. All transformation of raw source data into agreed enterprise entities has already happened upstream; the mart reshapes that into a consumption model for its audience. - **Independent mart** — sources directly from operational systems, built and owned by one department, with its own extraction, cleansing and business rules. The words describe a dependency, not a quality level. An independent mart can be well built and still create the problem below. ## Why Inmon's architecture produces dependent marts The top-down design exists to make integration a single upstream act. Every mart in that architecture is therefore dependent by definition: it reads the enterprise warehouse and nothing else. That is what gives the approach its main selling point — two marts *cannot* disagree about what a customer is, because neither of them decided. Consistency is enforced by the graph, not by a policy document. The cost, as always, is that nothing downstream exists until the upstream layer covers the needed entities. ## The independent-mart failure mode Independent marts appear organically, and usually for good reasons: a department has an urgent question, central data engineering has a six-month queue, and a competent analyst can wire an extract in a week. The first one is a success. The problem is cumulative. By the fourth independent mart, four teams have separately decided how to deduplicate customers, which orders count as revenue, how to treat cancellations, and what the fiscal calendar is. The definitions differ in small ways nobody documented. Two dashboards now show different active-customer counts and the meeting stops being about the business and starts being about whose number is right. These are **stovepipe** marts: locally rational, globally incoherent, and expensive to reconcile afterwards because the logic is embedded in many places. The secondary cost is load on the operational systems: each mart runs its own extracts against the same production databases. ## Where Kimball's marts sit A common interview trap is to equate bottom-up with independent. It is wrong. Kimball's marts are built one business process at a time, directly from staged source data, so they are not dependent on a central normalized warehouse — but they are not independent either, because the architecture requires that the **dimension tables be shared physically** across processes. The customer dimension is designed once and reused by orders, shipments and returns. Integration is achieved laterally, between marts, rather than vertically from an upstream store. What *does* turn a bottom-up programme into a set of independent marts is dropping that discipline — letting each team build its own private customer table. That is the recognized failure mode of the bottom-up approach, and it is exactly what the top-down approach prevents structurally. ## Turning independent marts back into something coherent When you inherit a landscape of independent marts, the realistic remedies are: 1. **Inventory the definitions.** Extract each mart's rules for the shared entities and the shared metrics, and put the differences on one page. This is usually the moment the organization discovers there are five definitions of *active customer*. 2. **Agree one definition per shared entity**, with a named owner. This step is organizational, not technical, and it is where the effort actually goes. 3. **Build the shared layer** — either a central integrated store the marts become dependent on, or a set of shared dimension tables they all adopt. The choice between those two is the top-down/bottom-up decision again. 4. **Migrate marts onto it one at a time**, keeping the old numbers computable during transition so the reconciliation is visible rather than a surprise. 5. **Retire the private extracts**, which also removes duplicate load from the operational systems. ## Answering in an interview Give the two definitions crisply, name Inmon's architecture as producing dependent marts and say *why that is the point*, then show you know the nuance: bottom-up marts are not automatically independent, and independent marts are a governance outcome rather than a modelling technique. Mentioning the stovepipe symptom — two dashboards, two numbers, no adjudicator — earns more than the vocabulary alone.