What is a Data Warehouse?

Picture a Monday meeting at a clothing chain. Sales quotes one August figure, finance quotes another, marketing has a third. Each number is right for the system it came from, and the meeting turns into an argument about spreadsheets instead of a decision about stores. We've sat in that meeting more than once. It's the reason companies spend months and a lot of rupees building a data warehouse, and it's where this track starts.

The problem a warehouse solves

Take that chain seriously for a moment. Say it has 42 shops across Punjab and Sindh. Sales sit in a POS system, stock and purchasing in an ERP, the loyalty programme in its own app, staff rosters in Excel. Each system does its own job well. None of them can answer a question like "Which categories are losing margin in Karachi mall stores compared with last Ramadan, and is that linked to staff turnover?"

So someone pulls exports from four systems, matches store codes that are spelled differently in each one, fixes dates written as 14/08/2025 in one file and 2025-08-14 in another, and stitches it together in a spreadsheet. Two weeks later the answer is ready, and nobody trusts it, because finance did the same exercise and got a different number.

A warehouse is that exercise done once, by a pipeline, every night. Data is copied out of the operational systems, cleaned, matched, given consistent names and keys, and stored in one place that's organised for asking questions. The stitching stops being somebody's Monday.

Four words interviewers still ask about

Bill Inmon, usually called the father of data warehousing, defined it back in 1992 as a collection of data that is:

Property	Meaning	In our clothing chain
Subject-oriented	Organised around business subjects (sales, customers, stock), not around applications	One "customer" area, even though customers appear in POS, loyalty app and CRM
Integrated	Same names, codes, units and formats regardless of source	Store LHR-DHA, "DHA Lahore" and store #17 all become one store record
Time-variant	Keeps history; you can see what was true on any past date	A customer who moved from Lahore to Karachi keeps both addresses with dates
Non-volatile	Data is loaded and read, not edited by users in the middle of the day	Yesterday's sales never change once loaded; corrections arrive as new loads

You'll be asked to recite these in Karachi and Lahore interviews. More usefully, each word becomes a design decision later in this track. Subject-orientation turns into dimensional modelling, integration into conformed dimensions and master data, time-variance into slowly changing dimensions, and non-volatility into batch pipelines.

What a warehouse is not

• Not a backup. A backup copies a system as it is. A warehouse reshapes data for analysis and combines many systems.
• Not a bigger database for the app. The app keeps its own database. The warehouse is a separate, read-mostly store with a different design (Lesson 2 explains why).
• Not a reporting tool. Power BI or Excel sit on top. The warehouse is the trusted data they read.
• Not necessarily huge. We've built a 200 MB warehouse for a school chain. It integrated sources and kept history, so it counts.

One version of the truth

The diagram is the Monday meeting we opened with. Sales quotes gross sales from the POS. Finance quotes net sales after returns from the ERP. Marketing includes cancelled online orders because the CRM never received the cancellation. A warehouse forces the company to write down one definition ("net sales = gross sales minus returns minus cancellations, in PKR, by transaction date") and apply it everywhere. On our projects that conversation has taken longer than building the tables. It's a business decision, not a technical one, and the warehouse team's job is to make sure it happens.

The margin question, answered in one query

Once the chain's warehouse exists, the Ramadan margin question becomes a single SQL query over a star schema. You'll learn to build one in Lessons 5 to 11. For now, just read it.

SELECT p.category,
       s.city,
       SUM(f.net_amount)                         AS net_sales,
       SUM(f.net_amount - f.cost)                AS gross_margin,
       ROUND(100.0 * SUM(f.net_amount - f.cost)
             / NULLIF(SUM(f.net_amount), 0), 1)  AS margin_pct
FROM fact_sales f
JOIN dim_date d    ON d.date_key    = f.date_key
JOIN dim_store s   ON s.store_key   = f.store_key
JOIN dim_product p ON p.product_key = f.product_key
WHERE d.is_ramadan = TRUE
  AND s.format = 'Mall'
  AND s.city = 'Karachi'
GROUP BY p.category, s.city
ORDER BY margin_pct;

Look at what the query doesn't do. No date parsing, no fixing of store names, no join to the HR system to find out where someone worked. All of that was solved once, in the pipeline. The analyst gets to think about the business instead of cleaning files. If your SQL is rusty, our free SQL track covers everything this query uses.

What it looked like at a Faisalabad exporter: a textile exporter we worked with ran production on one ERP, exports through the customs portal, and payments through two banks. The owner wanted a weekly view of orders received, produced, shipped and paid, by buyer country. Three staff spent every Monday building it in Excel. We built a small SQL Server warehouse with a nightly load, and the report was waiting at 6 am. The staff moved to chasing late payments, and the cash they recovered in the first quarter paid for the project. The hardest part wasn't the SQL. It was getting the owner to agree what "shipped" meant when a container had left the mill but hadn't cleared customs.

When you don't need one (yet)

A small business with one system and one person asking questions can live with direct reports for a long time. The warehouse becomes worth it once two of these are true: several source systems, more than one team consuming the numbers, questions about history or trends, or reports slowing the operational system. Most companies cross that line earlier than they think.

If you remember one thing

A warehouse is a separate store that pulls data from many systems, cleans and matches it once, keeps history, and gives everyone the same number. Inmon's four words (subject-oriented, integrated, time-variant, non-volatile) each turn into a design choice you'll make later. Size doesn't make a warehouse. Integration, history and consistency do.

Try this before the next lesson

1. List the source systems a mid-size private school network in Rawalpindi would have (admissions, fees, attendance, results, HR). Write one question a principal might ask that needs at least three of them.
2. For each of Inmon's four properties, write one sentence on how a JazzCash-style wallet warehouse would show it.
3. Take the "August sales" argument in the diagram. Write a one-paragraph definition of "net sales" that all three departments could sign, stating what's included, what's excluded, and which date is used.