Data Warehousing
A data warehouse is a central repository that stores structured, historical data optimized for analytical queries rather than transaction processing. It consolidates data from multiple source systems into a consistent schema so business analysts can run reports and measure trends reliably.
itData engineering and analytics | OpenSkills.info
Intro
Data Warehousing
A data warehouse brings data from several source systems into a store built for analysis. It gives you a stable place to compare history, calculate measures, and answer questions that cross operational boundaries.
The central mental model is a historical measurement system.
operational systems -> ingest -> clean and conform -> warehouse -> analysis
change data preserve meaning read across history
An order system records a sale. A support system records a case. A marketing platform records a campaign response. Each system serves its own process. A warehouse reshapes selected data so analysts can study those processes together.
The warehouse does not replace the source systems. It serves a different workload.
Why a warehouse exists
Operational systems handle current business activity. They accept orders, update account balances, and reserve inventory. These systems favor short, predictable transactions and current state.
Analytical work asks different questions:
- How did revenue change by product and region over three years?
- Which customer segments create the most support demand?
- Did a promotion change unit volume or only shift timing?
- How do actual results compare with targets?
These questions scan, join, group, and summarize many records. They also need consistent definitions across systems and time.
A warehouse separates that analytical workload from operational processing. It integrates selected data, records historical context, and presents structures designed for filtering and aggregation.
The end-to-end system
A warehouse is more than a database. It is a system of sources, movement, transformation, storage, metadata, controls, and consumers.
sources -> landing or staging -> transformation -> dimensional tables
|
v
semantic models and reports
Source systems own operational records. They may use different identifiers, names, time zones, and update rules.
Ingestion copies source data into the analytical environment. A batch may run on a schedule. Change data capture may move smaller changes more frequently.
Staging holds data for loading and transformation. It can reduce repeated reads from operational systems and make a failed load easier to restart. Staging data is not the business-facing product.
Transformation combines sources, converts types, applies business rules, resolves identifiers, and checks quality. The result should use consistent meanings.
Continue the course
This section is part of the paid course.
See pricing to subscribe, or log in if you already have access.
Where this skill leads
Relevant careers
See how this topic contributes to broader role-level skill maps.
Sources
- https://www.ibm.com/think/topics/data-warehouse
Supports
- Data warehouses as integrated stores optimized for querying and analysis
- ETL and ELT as warehouse data-pipeline patterns
- OLAP analysis compared with operational transaction processing
- Warehouse architecture spanning data, analytics, and consumer layers
- Enterprise warehouses, data marts, and operational data stores
- Workload differences among warehouses, lakes, and lakehouses
- https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-overview
Supports
- Star schemas as fact and dimension table structures for analytical queries
- Facts as measurements associated with events or observations
- Dimensions as descriptive entities used for filtering and grouping
- Periodic ETL synchronization from operational sources
- Historical accuracy, permissions, and iterative warehouse planning
- https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/
Supports
- Business process and grain as fundamental dimensional-design concepts
- Additive, semi-additive, and non-additive facts
- Transaction, periodic snapshot, accumulating snapshot, and factless fact patterns
- Conformed dimensions and warehouse bus architecture
- Type 1, Type 2, and Type 3 slowly changing dimension techniques
- https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/grain/
Supports
- Grain as the definition of what one fact-table row represents
- Declaration of grain before dimensions and facts are selected
- https://www.kimballgroup.com/data-warehouse-business-intelligence-resources/kimball-techniques/dimensional-modeling-techniques/type-2
Supports
- Type 2 slowly changing dimensions as new rows with new surrogate keys
- Preservation of historical dimension context
- https://docs.oracle.com/cd/F19136_01/dwhsg/database-data-warehousing-guide.pdf
Supports
- Fact tables, dimension tables, star schemas, and snowflake schemas
- Single-grain fact tables and the analytical value of detailed grain
- Additive, semi-additive, and non-additive measure behavior
- Conformed dimensions and conformed facts across several stars
- Surrogate keys that insulate dimensions from operational changes
- Warehouse physical design through partitioning and materialized views
- https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-dimension-tables
Supports
- Surrogate and natural keys in dimension tables
- Dimension attributes for analytical filtering and grouping
- Historical tracking attributes and audit attributes
- Type 1 overwrite and Type 2 versioned-row behavior
- Date dimensions, hierarchies, and conformed dimensions
- Unknown and missing special dimension members
- https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-fact-tables
Supports
- Transaction, periodic snapshot, and accumulating snapshot fact tables
- Fact-table size as a result of dimensions, grain, measures, and history
- Aggregate fact tables for commonly queried summaries
- https://learn.microsoft.com/en-us/fabric/data-warehouse/dimensional-modeling-load-tables
Supports
- Staging to reduce source impact, support processing, and enable restart
- Transformation to reshape, clean, conform, combine, and convert source data
- Historical-change handling during dimensional loads
- Set-based warehouse loading approaches
- Data-quality validation before dimensional tables are published
- https://learn.microsoft.com/en-us/sql/relational-databases/indexes/columnstore-indexes-query-performance?view=sql-server-ver17
Supports
- Columnstore compression, row-group elimination, and batch processing
- Reduced input and output work for analytical scans
- Data ordering, deletion, and maintenance considerations
- Star-schema use in analytical and data-warehouse workloads
- https://learn.microsoft.com/en-us/azure/synapse-analytics/sql-data-warehouse/sql-data-warehouse-tables-partition
Supports
- Date-based partitioning for load maintenance and filtered queries
- Partition switching and elimination behavior
- Performance risks from too many partitions
- Platform-specific partition sizing considerations
