Data Mart
A data mart is a subject-specific slice of a data warehouse that bundles the data of a single business area such as sales, purchasing or finance for fast, focused analysis.
A data mart is a smaller, subject-focused analytical database that bundles the metrics and dimensions relevant to a single business area – for example, only the sales, purchasing or finance data. It is thus a thematic slice (a "market stall") of the comprehensive data warehouse: instead of representing the entire company, a data mart delivers exactly the pre-structured data a team needs for its recurring reports and dashboards. This makes queries faster, simpler and easier for business users to understand.
The term is defined mainly by its scope: a data warehouse is the central, company-wide and historised collection point for all data, whereas a data mart serves a clearly delimited business purpose. Technically, a data mart is usually modelled dimensionally as a star schema too, but it comprises only a few fact and dimension tables. The goal is not completeness but performance and the ability of a department to run its analyses independently.
At a glance
- Subject-oriented slice of a data warehouse (sales, purchasing, finance …)
- Contains only a few, purposefully prepared fact and dimension tables
- Faster queries and simpler models than the entire warehouse
- Distinction: dependent data marts (from the DWH) vs. independent ones (directly from sources)
- Gives departments data autonomy without burdening the operational ERP
How does a data mart work?
A data mart is created by filtering out only the metrics and attributes needed for one business area from a broad data base, condensing them and transferring them into a manageable analysis model. A sales data mart, for example, contains revenue, quantity and contribution margin as facts, plus customer, product, region and time as dimensions – but not HR, production or asset data. Reporting and OLAP tools access this lean model, often with noticeably shorter response times than a query against the complete warehouse.
Dependent and independent data marts
There are two design forms. A dependent data mart is derived from an existing data warehouse and adopts its cleansed, consolidated data – it is therefore guaranteed to be consistent with the company's other analyses. An independent data mart, by contrast, is populated directly from the source systems such as the ERP or shop, without the detour via a central warehouse. This is quicker to implement and cheaper, but carries the risk of siloed solutions with diverging metric definitions.
Loading via ETL and refresh
A data mart is loaded – like the warehouse – via an ETL or ELT process that extracts, transforms and loads data, often in nightly runs. For dependent marts this step is lean, because the data already lies prepared in the warehouse and only needs to be filtered and condensed. Some data marts are also implemented as a pure view or as a pre-computed aggregation within the warehouse, rather than as a standalone physical database.
Why a data mart matters
The benefit of a data mart lies in speed, simplicity and closeness to the business. A company-wide data warehouse is powerful but often confusing for a single department: it contains hundreds of tables, only a fraction of which are relevant. The data mart reduces this complexity to what the team actually needs and makes self-service BI practical in the first place – business users find their way around more easily in a manageable data model shaped in their own language.
Add to that performance: smaller data volumes and pre-computed aggregations deliver reports in seconds rather than minutes. Because each area uses its own mart, departments also do not compete for the same resources. A prerequisite for the benefit remains clean data quality and – especially with multiple marts – an aligned definition of the metrics, so that "revenue" means the same thing in the sales mart and the finance mart.
The data mart and the ERP system
For most mid-sized companies, the ERP system is the most important data source of a data mart, because that is where orders, invoices, stock and master data converge. A dependent data mart obtains this data indirectly via the data warehouse; an independent mart is connected directly to the ERP via API or ETL connector and takes over only the transaction and master data needed for the respective area.
In practice, many businesses initially get by with the reporting built into the ERP and its standard dashboards. A dedicated data mart becomes attractive when a department wants to run its own, more complex analyses repeatedly without slowing down the production system, or when data from several sources – such as ERP, online shop and marketplaces – is to be combined for one area. The data mart then becomes the lean analytical layer, while the ERP carries the operational business.
Distinction: data mart vs. data warehouse and data lake
Data mart, data warehouse and data lake describe different levels of data storage. The data warehouse is the central, company-wide and historised integration layer; the data mart is its subject-oriented slice. Both store structured, modelled data according to a fixed schema.
Top-down and bottom-up
The two classic architecture approaches tie in exactly here. In the top-down model according to Bill Inmon, a central data warehouse is built first, from which dependent data marts are then derived. In the bottom-up model according to Ralph Kimball, individual data marts are built first and grow together into a company-wide warehouse via shared, conformed dimensions. A data lake stands alongside: it stores raw, even unstructured data in its original format and defines the structure only at query time – a data mart, by contrast, deliberately delivers pre-built, query-ready data.
Data marts in the DACH mid-market
For small and medium-sized companies in the DACH region, data marts are often the pragmatic entry point into professional analytics: instead of building a complete data warehouse straight away, a business starts with a single, clearly delimited mart – for example for sales – and expands step by step. Cloud-based BI services and analysis tools integrated into ERP systems lower the barrier to entry further.
Data protection must be considered: if a data mart contains personal data such as customer or employee information, the requirements of the GDPR apply – in particular purpose limitation, data minimisation and a deletion concept. Precisely because a data mart bundles data for a concrete purpose, the principle of data minimisation is easy to implement here: only what the respective area truly needs for its analyses ends up in the mart.
Example
Data mart for the sales team of a wholesaler
A mid-sized wholesaler operates a central data warehouse in which data from ERP, CRM and online shop converge. The sales team wants to analyse revenue, contribution margin and order volume per customer, region and product group on a weekly basis. However, queries against the entire warehouse take a long time, and the field sales staff get lost in the many tables that are irrelevant to their questions.
IT sets up a dependent data mart for sales: a nightly ETL run pulls only the sales facts and the dimensions customer, product, region and time from the warehouse into a lean star schema. The sales dashboard accesses this mart exclusively and now delivers the weekly reports in seconds – with drill-down to the individual customer. Because the mart is fed from the warehouse, its revenue figures match those of the financial report exactly.
Frequently asked questions
Related services
Sources
Questions about Data Mart in your ERP project?
We advise vendor-neutrally – and implement it ourselves on request.