I have seen many times at clients where the terms business intelligence and data warehousing are used interchangeably. In reality, these are two separate disciplines. This is especially true for enterprise data warehouses due to an EDW’s scope, complexity, and large volumes of data.
As seen in the data warehouse maturity model (a future blog post), as a data warehouse matures, the data warehouse team spends more and more resources on data integration. This shifts the focus from data consumption to data production.
Simply put, data warehousing and BI differ because:
- The primary focus for a data warehouse is the production of data
- The primary focus for BI is the consumption, presentation, and delivery of the data produced by the data warehouse
One example of where BI is confused with data warehousing within the SQL Server community is the
AdventureWorks samples available at the Microsoft SQL Server Community Projects & Samples site.
These samples include the following databases:
- A sample OLTP database (AdventureWorks2012)
- A sample data warehouse database (AdventureWorksDW2012)
- A sample SQL Server Analysis Services (SSAS) database, or cube (multidimensional and tabular)
The AdventureWorks sample data warehouse link provides more information about the AdventureWorks data warehouse and supporting scenarios in which data warehouse, data mining, and Online Analytical Processing (OLAP) are relevant. However, note that these are BI scenarios because the focus is on consumption, not production. There are no samples for the data warehouse production scenario; instead, the data warehouse is populated directly from Comma Separated Values (CSV) files. So these AdventureWorks samples should be thought of as business intelligence samples, not data warehouse samples.
In summary, BI focuses more on data consumption and should not be equated to data warehousing, which concentrates more and more on data production as it matures, especially when you are working with very large data volumes.
More info:
Microsoft EDW Architecture, Guidance and Deployment Best Practices – Chapter 2: Data Architecture