{"id":"l-sql-1-1","courseId":"sql-for-analysts","lang":"en","kind":"intro","summary":"Find your way around the Cartwheel database, turn a vague request into a precise question, and answer it with SELECT, computed columns, ORDER BY and LIMIT.","html":"

Your first week at Cartwheel, a message lands from Rania Aziz, the CEO: “Which of our products are expensive but barely profitable? I want to look at pricing before the spring catalogue.” It sounds simple. It’s also a perfect example of the job: someone with a real decision to make asks a question in plain words, and you turn it into a query that answers exactly that question, no more and no less.

\n

Cartwheel is an online store for home and outdoor goods, selling in eight countries. Its SQLite database holds two years of history, from January 2024 to December 2025. Every query in this course runs against it, in your browser.

\n

Meet the database

\n

Before writing the real query, look around. SQLite keeps a catalogue of its own tables in sqlite_schema (older code calls it sqlite_master, which still works):

\n
SQL
SELECT name\nFROM sqlite_schema\nWHERE type = 'table';
\n

Nine tables. To see one table’s columns and types, ask for its column list:

\n
SQL
SELECT name, type, \"notnull\"\nFROM pragma_table_info('orders');
\n

Here’s how the tables connect. Arrows point from a table to the table it references; the label is the shared key.

\n
\n Customers place orders; orders contain order_items; order_items reference products, which belong to categories. Returns reference order_items. Support tickets reference customers, orders and employees. Web sessions reference customers.\n \n web_sessions\n \n support_tickets\n \n employees\n \n customers\n \n orders\n \n order_items\n \n products\n \n categories\n \n returns\n \n \n \n \n \n \n \n \n \n customer_id\n order_id\n product_id\n
The Cartwheel schema: orders sit between customers and products
\n

The three highlighted tables are the spine of most questions: a customer places an order, and an order has one or more order items. Money lives on order_items, not on orders: line revenue is quantity * unit_price * (1 - discount).

\n

From request to query

\n

Rania’s request has two fuzzy words. “Expensive” can mean list price. “Barely profitable” needs a number: margin as a percentage of price, (unit_price - unit_cost) / unit_price, is the usual way to compare a $22 dripper with a $449 desk. Write the precise version down before you type: one row per product, showing price and margin percent, thinnest margins first.

\n
SQL
SELECT\n  name,\n  unit_price,\n  unit_cost,\n  ROUND((unit_price - unit_cost) / unit_price * 100, 1) AS margin_pct\nFROM products\nORDER BY margin_pct\nLIMIT 5;
\n

Three habits are already at work. The computed column gets a readable name with AS. ORDER BY can sort by that alias. And LIMIT 5 comes last, cutting the sorted list.

\n\n

The analyst’s loop

\n

Every request in this course goes through the same loop, and it’s worth making it a habit now:

\n
    \n
  1. Restate the question precisely, including what one row of the answer is.
    2. \n
  2. Explore the tables and columns you need.
    3. \n
  3. Query, starting small and building up.
    4. \n
  4. Sanity-check the result: row count, a total you know, an edge case.
    5. \n
  5. Answer in a sentence a non-analyst can act on.
    6. \n
\n

For Rania, step 5 might read: “Our thinnest margins are around 40%, on the Burr Coffee Grinder and Compact Writing Desk; no product is listed below cost.” Short, specific, and it points to the next question.

\n

Next you’ll add the most-used clause in analytics, WHERE, and learn where its logic trips people up.

\n","toc":[{"id":"sec-1","text":"Meet the database","level":2},{"id":"sec-2","text":"From request to query","level":2},{"id":"sec-3","text":"The analyst’s loop","level":2}],"takeaways":["An analyst’s query starts with a precise question, including what one row of the answer represents.","Explore an unfamiliar database through its tables and columns before writing the real query.","Computed columns with AS names make a result readable without changing the stored data.","ORDER BY decides which rows LIMIT keeps, so a LIMIT without an ORDER BY returns an arbitrary sample."],"further":[{"title":"SQLite SELECT statement","url":"https://www.sqlite.org/lang_select.html"},{"title":"The sqlite_schema table","url":"https://www.sqlite.org/schematab.html"}],"quiz":[{"q":"

Rania asks for “our best products”. What should you do before writing any SQL?

","options":[{"text":"Pin down what “best” means (revenue, units, margin) and over which period.","why":"Correct. “Best” has at least three defensible meanings, and each one gives a different list. Agreeing on the metric first saves a rewrite."},{"text":"Write SELECT * FROM products and send her the whole table.","why":"Forty-eight rows of raw columns don’t answer a question; they hand the analysis back to the person who asked."},{"text":"Sort products by unit_price, because expensive products are the best ones.","why":"Price isn’t performance. A $449 desk that sells twice a year may matter less than a $24 mug that sells daily."}],"answer":0},{"q":"

What does this query return?

\n
SQL
SELECT name, unit_price\nFROM products\nLIMIT 3;
\n","options":[{"text":"The three most expensive products.","why":"Nothing in the query sorts by price. LIMIT only cuts the result; it never chooses the “top” rows by itself."},{"text":"The three cheapest products.","why":"There is no ORDER BY, so there’s no notion of cheapest here either."},{"text":"Three rows in whatever order SQLite reads them, which you shouldn’t rely on.","why":"Correct. Without ORDER BY, row order is an implementation detail. Today it’s the insertion order; after an index change it might not be."}],"answer":2},{"q":"

You write unit_price - unit_cost AS margin in the SELECT list. What happens to the products table?

","options":[{"text":"A new margin column is added to the table permanently.","why":"SELECT never changes stored data. Adding a column would take ALTER TABLE."},{"text":"Nothing; margin exists only in this query’s result.","why":"Correct. A computed column is calculated for each output row and disappears when the query finishes."},{"text":"The query fails because margin isn’t a real column.","why":"Expressions with an alias are exactly how you create columns that don’t exist in the table."}],"answer":1}],"exercise":{"kind":"sql","starter":"-- Highest-margin products, by margin percent\nSELECT\n name,\n unit_price,\n ROUND(unit_price - unit_cost, 2) AS margin\nFROM products\nORDER BY margin DESC\nLIMIT 5;","solution":"SELECT\n name,\n unit_price,\n ROUND(unit_price - unit_cost, 2) AS margin,\n ROUND((unit_price - unit_cost) / unit_price * 100, 1) AS margin_pct\nFROM products\nORDER BY margin_pct DESC\nLIMIT 5;","orderMatters":true,"title":"Find the fattest margins","prompt":"

Rania liked the thin-margin list and now wants the opposite: the 5 products with the highest margin percent, so marketing can feature them.

\n

Return four columns in this order: name, unit_price, margin (unit_price - unit_cost, rounded to 2 decimals) and margin_pct (margin as a percentage of unit_price, rounded to 1 decimal). Sort by margin_pct, highest first. Order matters.

\n

The starter sorts by margin in dollars, which favours expensive products. Fix it.

\n","hints":["Add a fourth column that divides the margin by unit_price and multiplies by 100.","Wrap it in ROUND(..., 1) and give it the alias margin_pct.","Change the ORDER BY to margin_pct DESC; LIMIT stays last."],"explanation":"

Sorting by dollar margin puts the Standing Desk first, because a big price leaves a big gap even at an ordinary percentage. Margin percent compares products of any price on the same scale: the $19 Cable Management Kit keeps 61.5% of its price, the best in the catalogue. ORDER BY can use the alias defined in the SELECT list, and LIMIT 5 then keeps the first five rows of that sorted result.

\n","checkLabels":{}},"words":490,"readMinutes":3}