by Don Jones

A data mart is simply a subset of the available enterprise data, usually created to service a particular individual or audience. You can think of a data mart as a mini data warehouse, and many data marts draw their data from an existing data warehouse. Other data marts, called “independent data marts,” may instead draw their data from transaction-processing databases, from data generated specifically for the data mart, or from external sources.

There’s an alternate design approach called bottom-up, in which the organization builds several data marts, then creates an overarching data warehouse that references all the data marts. This is often an easier-to-grasp approach to data warehouse design because it tackles the design process in smaller chunks rather than attempting to consolidate all the enterprise’s data into a single data warehouse all at once.

Data marts can help solve a number of problems typically associated with data warehouses:

* A data mart can have a different database schema, meaning it may be able to meet department-specific needs more readily than a data warehouse that serves the entire company.
* A data mart can help offload work from a busy data warehouse, especially for demanding audiences or departments.
* A data mart can be a way of categorizing data for security purposes, giving a specific audience access to only a subset of the enterprise’s data.
* A data mart can often provide a “quick fix” solution for a specific departmental need, bypassing the often-complicated process of adding a new application to the enterprise data warehouse. Similarly, a data mart can act as a sort of trial or pilot of a new application before migrating it into the main data warehouse.
* A data mart may also offer a political solution to instances when a data warehouse cannot be implemented or modified quickly enough.

These benefits typically assume that a data mart is a physically separate entity; that is, the data mart contains its own copy of its data, although that data may have been physically extracted from a data warehouse. Some data marts do not take this approach; instead, they are a logical subset of a data warehouse, meaning they simply present an alternate view of the data inside an existing data warehouse. In practice, that’s a rarer implementation because it offers fewer benefits.

The fact is that implementing a new data warehouse, or modifying an existing one, can be a tremendously lengthy and tedious project. A data mart, addressing as it does a much smaller subset of data, can be faster to implement, usually requiring the participation of a single department and its needs rather than the entire enterprise. Many business intelligence vendors prefer to work with data marts simply because the sales and implementation cycle are shorter. Some experts (see http://csis.bits-pilani.ac.in/faculty/goel/Data%20Warehousing/Articles/Data%20Marts/dataWarehouse_com%20%20Article_DM%20VS%20DW.htm) feel that this approach—gradually building data marts on a departmental level and then aggregating them into something called a “data warehouse”—leads the organization in the wrong direction. There are advantages in tackling the organizational issues surrounding a data warehouse, and advocates of this approach suggest that truly valuable business intelligence can be gained in no other way.

Here’s a comparison offered by one expert, William Immon, in July 2000:

A data mart is a collection of subject areas organized for decision support based on the needs of a given department. Finance has their data mart, marketing has theirs, sales has theirs and so on. And the data mart for marketing only faintly resembles anyone else’s data mart.

Data warehouses are significantly different from data marts. Data warehouses are arranged around the corporate subject areas found in the corporate data model. Usually the data warehouse is built and owned by centrally coordinated organizations, such as the classic IT organization. The data warehouse represents a truly corporate effort.

The difference is the focus: The author suggests that you can’t simply take the finance data mart, the marketing data mart, and the sales data mart and suddenly have a data warehouse, “You can catch all the minnows in the ocean and stack them together, [but] they still do not make a whale” is the author’s analogy.

One reason you might want a data warehouse, then, is if you are truly attempting to solve companywide issues and gain companywide business intelligence. That data warehouse might then be broken down—through data extraction—so that its data can be made into smaller, audience-specific data marts; but by using a top-down design approach, you ensure that the overall data warehouse meets corporate needs.

About the Author

Don Jones has more than a decade of professional experience in the IT industry. He's the author of more than 30 IT books, including Windows PowerShell: TFM; VBScript, WMI, and ADSI Unleashed; Managing Windows with VBScript and WMI; and many more. He's a top-rated and in-demand speaker at conferences such as Microsoft TechEd and TechMentor, and writes the monthly Windows PowerShell column for Microsoft TechNet Magazine. Don is a multiple-year recipient of Microsoft's "Most Valuable Professional" (MVP) Award with a specialization in Windows PowerShell. Don's broad IT experience includes work in the financial, telecommunications, software, manufacturing, consulting, training, and retail industries and he's one of the rare IT professionals who can not only "cross the line" between administration and software development, but also between IT workers and IT management. Don is a co-founder of Concentrated Technologies, and serves as author and series editor for Realtime Publishers.