Data Warehousing
Data Warehousing Architecture and Design · Also known as: warehouse, DW design
Data warehousing is an approach to designing integrated repositories of historical business data optimized for analysis and reporting. Pioneered by William Inmon and Ralph Kimball in the early 1990s, data warehouses consolidate data from diverse operational sources into a centralized, time-stamped, non-volatile store supporting complex queries across multiple dimensions.
Read the full method
Sign in with a free account to read this section.
Method map
The neighbourhood of related methods — select a node to explore.
When to use it
Build a data warehouse when you need to analyze trends across multiple business domains, support complex analytics on historical data, or provide consistent reporting across the enterprise. It is most valuable for organizations with diverse operational systems and regular reporting requirements. Assumptions include stable analytical requirements and tolerance for batch loading latency.
Strengths & limitations
- Separates analytical workloads from operational systems, improving both performance profiles
- Provides consistent historical perspective for trend analysis and comparisons across time
- Centralizes data governance and enables consistent definitions across the enterprise
- Warehouse construction and maintenance requires significant investment in infrastructure and expertise
- Historical latency means real-time operational decisions cannot rely on warehouse data
- Schema changes can be complex and disruptive when dimensions evolve
Frequently asked
What is the difference between a data warehouse and a data mart?
A data warehouse is enterprise-wide and contains data from multiple sources across many business areas. A data mart is a subset focused on one business domain (e.g., sales). Data marts are often fed from the warehouse.
Should I use Inmon's top-down or Kimball's bottom-up approach?
Inmon's approach builds one enterprise warehouse first; Kimball builds separate dimensional marts incrementally. For smaller organizations or specific departments, Kimball's approach is faster. For large enterprises needing integration, Inmon's is more thorough.
What is a slowly changing dimension and why does it matter?
Slowly changing dimensions are attributes that change rarely (e.g., product category). Handling them correctly ensures historical queries show the correct dimension values at each point in time, supporting accurate trend analysis.
How often should I refresh the warehouse?
Refresh frequency depends on requirements. Daily batches suit most organizations; hourly or real-time refresh is necessary only for tactical systems. Balance freshness against resource costs and source system load.
Sources
- Inmon, W. H. (1992). Building the Data Warehouse. New York: QED Technical Publishing. link ↗
- Kimball, R. (1996). The Data Warehouse Toolkit: Practical Techniques for Building Dimensional Data Warehouses. New York: John Wiley & Sons. link ↗
- Kimball, R., & Ross, M. (2013). The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3rd ed.). Wiley. link ↗
How to cite this page
ScholarGate. (2026, June 3). Data Warehousing Architecture and Design. ScholarGate. https://scholargate.app/en/information-systems/data-warehousing
Which method?
Set this method beside its closest kin and read them side by side — the library lays the books on the table; the choice is yours.
- ETL ProcessInformation Systems↔ compare
- OLAP Cube DesignInformation Systems↔ compare