Kimball perspective should be added for balance, author is clearly an Disciple of Imnom ;-)
A data mart (DM) is a specialized version of a data warehouse (DW). Like data warehouses, data marts contain a snapshot of operational data that helps business people to strategize based on analyses of past trends and experiences. The key difference is that the creation of a data mart is predicated on a specific, predefined need for a certain grouping and configuration of select data. Since data mart configuration emphasizes easy access to relevant information, the star schema or dimensional model is a fairly popular design choice, as it enables a relational database to emulate the analytical functionality of a multidimensional database.
There can be multiple data marts inside a single corporation; each one relevant to one or more business units for which it was designed. DMs may or may not be dependent or related to other data marts in a single corporation. If the data marts are designed using conformed facts and dimensions, then they will be related. In some deployments, each department or business unit is considered the
“owner” of their data mart which includes all the
“hardware, software and data.”* This enables each department to use, manipulate and develop their data any way they see fit; without altering information inside other data marts or the data warehouse. In other deployments where conformed dimensions are used, this business unit ownership will not hold true for shared dimensions like customer, product, etc.
Structure of a Data Mart
A common framework called the
star-join structure has become a standard across all industries. This is because it emphasises easy access to relevant information as well as enabling a relational database to emulate the analytical functionality of a multidimensional database. A
star-join structure generally contains the following components
*:
1. predefined requirements of what is expected of the DM
2. limited amounts of historical data relevant to the department.
3. data is housed in multidimensional technology for ideal analytical accessibility.
4. data must be well recorded and well indicated.
To see a diagram of a star-join structure designed by Bill Inmon visit this link: *
Dependent Data Mart
According to the
Inmon school of data warehousing, a
dependent data mart is a logical subset (
view) or a physical subset (extract) of a larger
data warehouse, isolated for one of the following reasons:
- A need for a special data model or schema: e.g., to restructure for OLAP
- Performance: to offload the data mart to a separate computer for greater efficiency or to obviate the need to manage that workload on the centralized data warehouse.
- Security: to separate an authorized data subset selectively
- Expediency: to bypass the data governance and authorizations required to incorporate a new application on the Enterprise Data Warehouse
- Proving Ground: to demonstrate the viability and ROI (return on investment) potential of an application prior to migrating it to the Enterprise Data Warehouse
- Politics: a coping strategy for IT (Information Technology) in situations where a user group has more influence than funding or is not a good citizen on the centralized data warehouse.
- Politics: a coping strategy for consumers of data in situations where a data warehouse team is inept and unable to create a usable data warehouse.
According to the Inmon school of data warehousing, tradeoffs inherent with datamarts include limited scalability, duplicaton of data, data inconsistency with other silos of information, and inability to leverage enterprise sources of data.
Misconceptions
According to the Inmon school of data warehousing, there are many
misconceptions about data marts that can cause confusion to those first learning about the subject. The first is that a collection of separate DMs does not comprise or become a substitute for a DW. This was a claim that had been made, but proven false by the
Inmon school of thought. It was originally argued that a group of data marts could not only be built faster than a central data warehouse, but that it was also more cost-effective. However, this notion provided massive problems for companies, both structurally and financially, as they learned the hard way of the importance of a central warehouse. By exclusively building data marts, there was no nucleus to the BI system and no way to integrate the various data marts. It was summarized by Inmon when he said “DSS environment without integration is like a man without a skeletal system--hardly a useful, viable entity.”
The other notion that the
Inmon school of thought disproved was the notion that a DM could be turned into a DW when it reached a certain size. This was a false claim as the core misconception was that a data mart and a data warehouse could be used as substitute goods; along with being complementary goods. In several cases, this can be a difficult distinction to make; however it is essential to determine the difference in this particular case. To discredit the notion, Inmon used another analogy when he said, “This is no more valid than saying that when a tumbleweed grows large enough that it can be turned into an oak tree. Reality and genetics being what they are, it is true that a tumbleweed and an oak tree are, at one point in their life, green living organisms planted in the soil and are approximately the same size. But just because those two plants share a few basic characteristics at some moment in time does not mean that a tumbleweed can be turned into an oak tree.” Therefore, no matter how many characteristics they have in common, data marts and data warehouses will always be different. They can not be used interchangeably, and it’s only when they’re paired together that they operate at their optimal potential.
External links
Data warehousing
Data-Mart | Datamart | Data mart | Datamart | Data mart | Витрина данных