Database Reference
In-Depth Information
many different departments can use the same data mart. If you define it on a department, it may be isolated from
being reused, and you can end up with redundant data marts that cause more confusion rather than provide
accurate information.
Data marts can be thought of as a subset of a data warehouse. Because data warehouses represent multiple
processes and a data mart focuses on a single process, a data warehouse can be thought of as containing one or
more data marts. Therefore, if a business has both a sales or inventory process, a sales and inventory data mart
would be part of that business's data warehouse. When you build your data warehouse, you create two fact tables
in one database. These two tables provide the core data for the data warehouse (Listing 4-1).
Listing 4-1.
An Expression Describing a Data Mart
/* Data Warehouse=a set of data marts {Sales Data Mart, Inventory Data Mart} */
Select * from FactSales
Select * from FactInventory
This allows for easy access to the information for a particular process and a way of managing data for all of
the company's processes. In summary, a data warehouse is a collection of one or more data marts, and a data
mart is a collection of data around a particular process.
Competing Definitions
he denitions we use in this topic are found in many other books as well, but not all. A number of competing
viewpoints exist that describe what something is called in the business intelligence world. This diversity of terms
began with two different industry leaders, Bill Inmon and Ralph Kimball.
In the early 1990s, Inmon published several articles on data warehousing. Later, Kimball also published
articles, as well as a famous book known as
The Data Warehouse Toolkit
in the mid-to-late 1990s.
Although both agree on the principle of data warehousing providing information to the users, they differ on
how to accomplish this task. Inmon believes that a data warehouse should be very comprehensive and reflect
all aspects of the business before it can truly be useful. This tactic has proven to be most effective for many
large companies. But it has proven to be less useful for smaller to midsize companies that do not require such
complete integration from all aspects of the company in order for their businesses to operate.
Kimball's theory is that a BI solution should focus on smaller specific topics such as business processes. As
soon as you implement one process in a BI solution, it is available for reporting, and work can begin on the next
process to be added to the solution. This is considered a bottom-up approach.
To paraphrase, Kimball outlines a bottom-up approach by starting small and using building blocks to create
something of larger scope, which can be added to over time. Inmon's theory, on the other hand, focuses on a
large holistic approach building from the top down in a comprehensive manner that requires all aspects to be
incorporated before the data warehouse can function as it is designed.
Many developers have adopted one philosophy or another. Sometimes they even get a bit overzealous about
it, not unlike choosing an athletic team to root for in sports. Both approaches, however, have their uses and
should be considered tools that, when used appropriately, provide maximum results.
Stereotypically, larger companies will benefit from the top-down approach because they often need holistic
information about the many departments that make up the company. Small to midsize companies are more
likely to benefit from the bottom-up approach. These companies have few departments, and communication
between these departments is easier to manage.
Keep in mind that both approaches will work for companies of all sizes, so each solution must be evaluated
independently, but a bottom-up approach usually is appropriate more often than not. In addition, all companies
can benefit from a bottom-up approach at some point, because it requires less time and fewer resources before
reporting can begin.
