The shop ledger that stopped working
Meera ran a small electronics shop and tracked everything in one spreadsheet: a row per sale, a column for item, price, date, customer name. It worked fine for years. Then she added an online store, and the spreadsheet started breaking in ways it never had before.
Product photos didn't fit in a cell. Customer support chat logs were walls of unstructured text. Warehouse sensor data came in as a constant stream, not a row she could add once a day. Meera's spreadsheet wasn't badly designed, it was just built for one specific shape of data, and her business had outgrown that shape.
Data comes in three shapes
Almost everything you'll deal with in DP-900, and in real data work, falls into one of three categories:
- Structured data — fits neatly into rows and columns, a fixed set of fields, every row shaped the same way. Meera's original sales spreadsheet. A customer table with name, email, phone. This is what relational databases are built for.
- Semi-structured data — has some organization, tags, key-value pairs, nesting, but not a fixed rigid shape every record must match. A JSON file describing a product, where some products have five attributes and others have twelve, is semi-structured. This is where document databases like Azure Cosmos DB live.
- Unstructured data — no predefined shape at all: photos, video, PDFs, free-text chat logs. You can store it and search around it, but there's no natural row-and-column structure to enforce. This is what blob storage is built for.
Meera's product photos are unstructured. Her chat support logs are unstructured. Her original sales table is structured. The moment her business needed all three, one spreadsheet stopped being the right tool, not because she did something wrong, but because no single format handles all three shapes well.
Why the shape decides the tool
This is the single idea that makes the rest of DP-900 make sense: the shape of your data determines which Azure service is even a reasonable option. Relational services like Azure SQL Database expect structured data with a defined schema up front. Cosmos DB is built to flex with semi-structured documents that don't all look alike. Azure Blob Storage doesn't try to understand the shape of what you're storing at all, it just stores the file.
None of these are "better" in the abstract, they're built for different shapes. A big part of being effective with data on Azure is recognizing which shape you're holding before you pick where it lives.
Two very different jobs data does
Beyond shape, data work splits into two kinds of workload, worth knowing before the later modules go deeper:
- Transactional (OLTP) — fast, frequent, small operations: recording one sale, updating one customer's address. Optimized for many quick reads and writes.
- Analytical (OLAP) — big, slower queries across huge amounts of historical data: "what were our top ten products by region last quarter." Optimized for scanning and summarizing, not quick single-row updates.
Meera recording today's sale is a transactional operation. Meera asking "what sold best in December across the last three years" is analytical. Trying to run heavy analytical queries against the same system handling live transactions is a classic way systems slow to a crawl, which is exactly why Azure offers separate services tuned for each.
Check your understanding
Five questions, all from this module. Get 4 out of 5 to mark it complete.
1. Meera's original sales spreadsheet, one row per sale with fixed columns, is an example of:
2. A folder full of customer-submitted photos has no fixed row-and-column shape. This is:
3. A JSON product catalog where some items have 5 fields and others have 12 is best described as:
4. Recording a single new sale as it happens is an example of which workload type?
5. "What were our top ten products by region over the last three years?" is best described as: