Data Warehouse
A data warehouse is not a database with bigger tables.
It is a different way of thinking about data — oriented towards analysis, history, decisions.
The difference between a DWH that works and one that becomes a problem almost always lies in the model. Fact tables with the wrong granularity, poorly designed dimensions, hierarchies that cannot support aggregation queries. Problems that are invisible during development but explode when the business asks for reports the model cannot deliver.
In this section I share real cases of data warehouse design and restructuring: dimensional modeling, balanced hierarchies, slowly changing dimensions, loading strategies. Not Kimball textbook theory, but solutions applied in production on systems that serve real business decisions.
Because a data warehouse is not built to contain data.
It is built to answer questions.
Ragged hierarchies: when the client has no parent and the group has no grandparent
A client with a three-level hierarchy — Top Group, Group, Client — where not all branches are complete. How I balanced a ragged hierarchy with self-parenting: whoever has no parent becomes their own parent.
SCD Type 2: the history the business didn't know it needed
A sales director asks how many customers were in the North region last June. The DWH can't answer because every update overwrites previous data. How I implemented an SCD Type 2 with surrogate keys and validity dates to give the business back its historical memory.
Wrong grain: when the fact table can't answer the right questions
A fact table built on monthly invoice totals looked perfect. Then the business asked for product-level, line-level, customer-level detail. And the data warehouse went silent.