Advanced SQL Queries Lab (AutoRentals)

Match the pairs

From What you'll be able to do — match each one to what it actually does. The descriptions have been shuffled.

• c1. One query at a time
• c2. Verified results
• c3. Concept first

• b1. Every question slide gives you the exact query to type.
• b2. Each result table matches what SQL Server returns.
• b3. New SQL ideas are taught right before the query that needs them.

Why: One query at a time, Verified results, Concept first are easy to tell apart while they are sitting next to their descriptions and much harder afterwards, which is what this checks.

Discussion prompt

Read the picture before the words. What is this showing, and what is the one thing it is built to make obvious? Commit to an answer, then read on.

Hint: Name the parts, then say what changes between them — and if nothing changes, say what is being held still.

Comparison matrix

From The three tables: refill the Primary key column from what you know. The rest of the table is as it appeared.

Predict first

Before question 2, run the setup script from the instructions once. It creates the database, the three tables, and inserts every row. The first query (Q1) is already answered for you.

Commit before you compute: what does Setup - build & populate the database come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Check the row counts before writing queries.

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. If a table is empty an INSERT failed - fix it now, or every later result will be wrong.

Comparison matrix

From Setup - build & populate the database: every row here is a choice with a cost. Fill the Rows column, then say which row you would actually pick and what you give up for it.

Discussion prompt

Every one of the 25 questions is delivered the same way. Miss a step and you lose the point even with a correct query.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Discussion prompt

Question 1. Return the name and age of all customers. You should have 7 rows.

What do you need to know — or decide — before the first line can be written? List everything the problem has to hand you.

Hint: Anything you would have to invent to get started is a thing the problem must supply.

Step through it

Step through Q1 - The model answer (given) one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: CName is Black
2. Step 2: CName is Green
3. Step 3: CName is Jones
4. Step 4: CName is Martin
5. Step 5: CName is Simon
6. Step 6: CName is Vernon
7. Step 7: CName is Wilson

Discussion prompt

Explain SELECT ... FROM ... WHERE by analogy to something with no Advanced SQL (CSIS 325) in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Predict first

The table runs: Black | Erie · Jones | Hemet

In Q2 - Filter with WHERE, given the rows so far: what is the next one — the row where CName is Martin?

Correct: Martin | Hemet

Why: The relationship between the columns, not the individual numbers, is what generates the next row. WHERE decides which rows; SELECT decides which columns.

Annotate

Walk the callouts on Q2 - Filter with WHERE. Each one is a place this is easy to get subtly wrong.

• WHERE decides which rows; SELECT decides which columns. They are independent.
• The grader wants to see the query you ran and the rows it returned in the same screenshot.

Predict first

The table runs: 7 | Wilson · 4 | Martin · 3 | Jones · 2 | Green

In Q3 - BETWEEN, ORDER BY, alias, given the rows so far: what is the next one — the row where CID is 1?

Correct: 1 | Black

Why: The relationship between the columns, not the individual numbers, is what generates the next row. Five customers fall in 25-40 inclusive (Green and Wilson are exactly 25, Black is exactly 40).

Step through it

Step through Q3 - BETWEEN, ORDER BY, alias one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: CID is 7
2. Step 2: CID is 4
3. Step 3: CID is 3
4. Step 4: CID is 2
5. Step 5: CID is 1

Predict first

A student writes this, and it looks reasonable:

Task says 25 to 40 inclusive.

It is wrong. Say what breaks — and say it before you turn the page.

Correct: This silently drops Green (25), Wilson (25), and Black (40) - you'd get 2 rows, not 5.

Task says 25 to 40 inclusive.

Why: This silently drops Green (25), Wilson (25), and Black (40) - you'd get 2 rows, not 5.

Discussion prompt

Work backwards. The example finished here:

Deliverable: screenshot the query and its results, then paste it below Question 4 in the Template.

What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.

Hint: Every quantity in the result had to enter somewhere. Account for each one.

Sort into buckets

Every line below is part of the definition of WHERE or of DISTINCT — one or the other, never both. Put each where it belongs.

WHERE

Keeps only the rows where the condition is true.; Text literals go in single quotes

DISTINCT

Applied to the whole SELECT list; keeps one copy of each unique combination of the selected columns.

b1

Keeps only the rows where the condition is true. Text literals go in single quotes: 'Tampa'.

b2

Applied to the whole SELECT list; keeps one copy of each unique combination of the selected columns.

Put in order

These are the steps of Pattern: the shape of every SELECT, scrambled. Put them back in order before the next slide shows you.

1. SELECT the columns (add DISTINCT to dedupe, AS to rename)
2. FROM the table
3. WHERE the row condition (=, BETWEEN, LIKE, ...)
4. ORDER BY column(s) (ASC default, DESC to reverse)

Why: This is the order the recipe itself gives. Recalling the sequence without the slide in front of you is the difference between recognising the method and being able to run it — most of what goes wrong in practice is a step done out of turn.

Eliminate the wrong options

Which WHERE clause returns customers aged 25 through 40, including 25 and 40?

3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.

• A. where Age between 25 and 40
• B. where Age > 25 and Age < 40
• C. where Age >= 25 or Age <= 40
• D. where Age in (25, 40)

Survives elimination: A

Why: BETWEEN is inclusive of both endpoints, so ages 25 and 40 are kept along with everything in between - exactly what 'inclusive' asks for.

Check your understanding

Which WHERE clause returns customers aged 25 through 40, including 25 and 40?

• A. where Age between 25 and 40 (correct)
• B. where Age > 25 and Age < 40
• C. where Age >= 25 or Age <= 40
• D. where Age in (25, 40)

Answer: A

Why: BETWEEN is inclusive of both endpoints, so ages 25 and 40 are kept along with everything in between - exactly what 'inclusive' asks for.

Why B tempts people

Strict > and < exclude the endpoints 25 and 40, losing three customers.

Why C tempts people

OR with >= and <= is true for every possible age, so it returns all 7 customers.

Why D tempts people

IN (25, 40) matches only ages that equal 25 or 40 exactly, skipping 30 and 35.

Discussion prompt

Explain INNER JOIN: match rows across tables to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Put in order

Put the moves of Q6 - Two-table INNER JOIN into the order they have to happen.

1. Start from Customer and join Rentals on the shared key CID
2. Select the three requested columns: CName, Make, and Pickup
3. Add ORDER BY r.Pickup to sort the output ascending
4. Deliverable: screenshot the query and its results, then paste it below Question 6 in the Template.

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Every rental stores the CID of the customer who made it, so matching Customer.CID to Rentals.CID places each person beside their own rentals.

Comparison matrix

From Q6 - Two-table INNER JOIN: refill the Pickup column from what you know. The rest of the table is as it appeared.

Predict first

A student writes this, and it looks reasonable:

Listing tables with no match condition:

It is wrong. Say what breaks — and say it before you turn the page.

Correct: 7 customers x 8 rentals = 56 meaningless rows.

Always state how the tables match:

Why: 7 customers x 8 rentals = 56 meaningless rows. This is a Cartesian product.

Draw it

Draw what Q7 - JOIN + IN list just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Discussion prompt

Q8 - Three-table JOIN — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: Join Customer to Rentals on CID, then Rentals to Rentcost on Make

Step through it

Step through Q8 - Three-table JOIN one row at a time. What is driving the change, and what would the row after the last one be?

1. Step 1: CName is Black
2. Step 2: CName is Black
3. Step 3: CName is Green
4. Step 4: CName is Jones
5. Step 5: CName is Martin
6. Step 6: CName is Black
7. Step 7: CName is Jones
8. Step 8: CName is Simon

Predict first

In 'Customer c join Rentals r on c.CID = r.CID', what happens to a customer who has no rentals?

Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.

Correct: They are left out of the result entirely

Why: An INNER JOIN keeps only rows that match on both sides. A customer with no matching Rentals row has nothing to pair with, so they are excluded - which is why Q6 returns 8 rows, not 10.

Check your understanding

In 'Customer c join Rentals r on c.CID = r.CID', what happens to a customer who has no rentals?

• A. They are left out of the result entirely (correct)
• B. They appear once with NULL rental columns
• C. They appear paired with every rental
• D. The query raises an error

Answer: A

Why: An INNER JOIN keeps only rows that match on both sides. A customer with no matching Rentals row has nothing to pair with, so they are excluded - which is why Q6 returns 8 rows, not 10.

Why B tempts people

That describes a LEFT OUTER JOIN, which keeps unmatched left rows with NULLs - not an inner join.

Why C tempts people

Pairing with every rental is a Cartesian product, which happens only when the ON condition is missing.

Why D tempts people

An unmatched row is a normal case, not an error; it is simply dropped.

Match the pairs

Match each term to the definition this lesson gave it — not the one you would guess from the word.

• t1. WHERE
• t2. DISTINCT
• t3. INNER JOIN ... ON
• t4. YEAR(date)
• t5. DATEDIFF(day, d1, d2)

• d1. Keeps only the rows where the condition is true. Text literals go in single quotes: 'Tampa'.
• d2. Applied to the whole SELECT list; keeps one copy of each unique combination of the selected columns.
• d3. Returns only rows where the ON condition matches in both tables. Unmatched rows are dropped.
• d4. A T-SQL function returning the 4-digit year. DATEPART(year, date) does the same thing.
• d5. Counts day boundaries crossed from d1 to d2. The unit 'day' can also be month, year, etc.

Why: These are the working definitions of WHERE, DISTINCT, INNER JOIN ... ON, YEAR(date), DATEDIFF(day, d1, d2) as Advanced SQL Queries Lab (AutoRentals) uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.

Predict first

Question 11. Total number of days Black rented a GM on November 1, 2009. One cell: 4.

Commit before you compute: what does Q11 - DATEDIFF for a rental length come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Deliverable: screenshot the query and its results, then paste it below Question 11 in the Template.

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. Nov 1 out, Nov 5 back: DATEDIFF(day, ...) = 4.

Annotate

In Q12 - DATEDIFF x Cost, before reading the notes: mark where the time actually goes. Which line dominates?

• 4 days x $40/day for a GM = $160. The join to Rentcost supplies the $40 rate.
• The grader wants to see the query you ran and the rows it returned in the same screenshot.

Discussion prompt

Q13 - SUM over all rows — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: Join Rentals to Rentcost so each rental knows its daily rate

Predict first

A student writes this, and it looks reasonable:

Average age per city, Cary has 25 and 60:

It is wrong. Say what breaks — and say it before you turn the page.

Correct: (25+60)/2 is computed as integers and truncated to 42 - the .5 is lost.

avg(cast(Age as float))

Why: (25+60)/2 is computed as integers and truncated to 42 - the .5 is lost.

Discussion prompt

The rule this trap just fixed:

(25.0+60.0)/2 = 42.5, exactly as the task requires.

Now break it on purpose. Build a case that violates it and follow the consequences until something visibly fails. Where does the failure first show up — and would you have noticed it if you had not been looking?

Hint: The dangerous rules are the ones whose violation still produces an answer. If yours fails loudly, try to find one that fails quietly.

Predict first

Q15 - AVG without truncation (CAST) is about to be worked. State your hypothesis first: which rule or definition decides this one, and what is the first move it forces? Then watch whether the example agrees with you.

Correct: Group the customers by Resid_City

Why: Grouping by residence city produces one output row per city so each city receives its own average age.

A hypothesis you wrote down is falsifiable; a vague sense of how it will go is not. If the example opens somewhere else, that gap is the thing worth chasing.

Comparison matrix

From Q15 - AVG without truncation (CAST): every row here is a choice with a cost. Fill the AvgAge column, then say which row you would actually pick and what you give up for it.

Check your understanding

Age is an integer column. Which expression averages ages as 42.5 rather than 42?

• A. avg(cast(Age as float)) (correct)
• B. avg(Age)
• C. cast(avg(Age) as int)
• D. round(avg(Age), 0)

Answer: A

Why: Casting Age to float before averaging makes SQL Server use decimal arithmetic, so (25+60)/2 evaluates to 42.5. Casting inside the AVG is what preserves the fraction.

Why B tempts people

With an integer column, AVG uses integer division and truncates 42.5 to 42.

Why C tempts people

Averaging as integers already lost the .5; casting the 42 result to int changes nothing.

Why D tempts people

ROUND runs after the integer AVG already truncated to 42, so it rounds 42, not 42.5.

Predict first

A student writes this, and it looks reasonable:

Find rentals not yet returned:

It is wrong. Say what breaks — and say it before you turn the page.

Correct: NULL is 'unknown', so = NULL is never true.

Find rentals not yet returned:

Why: NULL is 'unknown', so = NULL is never true. This returns zero rows every time.

Predict first

Which WHERE clause correctly finds rentals that have not been returned (Date_returned is missing)?

Commit to an answer, then rate it — certain, fairly sure, or guessing — and write the rating down before you turn the page.

Correct: where Date_returned is null

Why: IS NULL is the only operator that matches a missing value. A NULL means 'unknown', so any comparison with = or <> against it evaluates to unknown, never true.

The rating matters as much as the answer: confident-and-wrong is the combination that survives revision, because nothing about it feels like it needs revisiting.

Check your understanding

Which WHERE clause correctly finds rentals that have not been returned (Date_returned is missing)?

• A. where Date_returned is null (correct)
• B. where Date_returned = null
• C. where Date_returned = ''
• D. where Date_returned <> Date_returned

Answer: A

Why: IS NULL is the only operator that matches a missing value. A NULL means 'unknown', so any comparison with = or <> against it evaluates to unknown, never true.

Why B tempts people

= NULL is never true, even for a NULL value, so this returns no rows.

Why C tempts people

An empty string '' is a real value different from NULL; the date columns hold NULL, not ''.

Why D tempts people

Comparing a column to itself is unknown when the value is NULL, so this also matches nothing.

Discussion prompt

Read the picture before the words. What is this showing, and what is the one thing it is built to make obvious? Commit to an answer, then read on.

Hint: Name the parts, then say what changes between them — and if nothing changes, say what is being held still.

Discussion prompt

Explain Type I subquery: uncorrelated (NOT IN) to a student a year behind you. No notation, no jargon they have not met — and it still has to be true.

Hint: If your explanation needs a symbol they have never seen, you are describing the notation rather than the idea.

Discussion prompt

Question 18. Using a Type I query, display a unique list of makes that have never been rented. 2 rows: Toyota and Volvo.

What do you need to know — or decide — before the first line can be written? List everything the problem has to hand you.

Hint: Anything you would have to invent to get started is a thing the problem must supply.

Put in order

Put the moves of Q19 - RIGHT OUTER JOIN anti-join into the order they have to happen.

1. Put Customer on the right and RIGHT OUTER JOIN Rentals to it
2. Keep only the rows where r.CID IS NULL
3. Select the distinct customer names that remain
4. Customer is on the right, so RIGHT keeps every customer.
5. Deliverable: screenshot the query and its results, then paste it below Question 19 in the Template.

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. Keeping every customer means a customer with no rental still appears, with the Rentals side of the row left blank.

Discussion prompt

Explain Type II subquery: correlated (NOT EXISTS) by analogy to something with no Advanced SQL (CSIS 325) in it at all — a queue, a recipe, a map, a bank balance, whatever fits. Then say where your analogy breaks.

Hint: An analogy that never breaks is not an analogy, it is the same idea wearing a hat. Find the seam — that is the part that is actually new.

Discussion prompt

Q20 - Type II: NOT EXISTS — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: Test each customer with a correlated NOT EXISTS subquery

Draw it

Draw what Q20 - Type II: NOT EXISTS just did — the shape of it, not the line-by-line working. One picture, labels only where you need them. Then check it against the steps: anything you could not draw is a step you followed rather than understood.

Predict first

A student writes this, and it looks reasonable:

If the subquery's column can contain NULL:

It is wrong. Say what breaks — and say it before you turn the page.

Correct: If any subquery CID were NULL, NOT IN returns no rows at all - a silent wrong answer.

Correlated existence test is NULL-safe:

Why: If any subquery CID were NULL, NOT IN returns no rows at all - a silent wrong answer.

Sort into buckets

Some of these hold up and some are the exact mistakes this lesson is built to prevent. Sort them.

Holds up

The lab uses one database, AutoRentals, with three related tables. Know the keys and you know how they join.; Every one of the 25 questions is delivered the same way. Miss a step and you lose the point even with a correct query.; Every query names the columns you want (SELECT), the table (FROM), and optionally a row filter (WHERE).

Breaks

Task says 25 to 40 inclusive.; Listing tables with no match condition:

sound

These are stated as this lesson states them — each one survives the edge cases Advanced SQL Queries Lab (AutoRentals) puts it through.

flawed

Each of these is lifted from a trap in this deck: reasonable-sounding, and wrong in a way that only shows up once you rely on it.

Predict first

Question 23. Using a Type I query, show names and ages of customers who rented an automobile and returned it to Erie. Sort by name ascending. 3 rows.

Commit before you compute: what does Q23 - Type I with IN come out to? A rough magnitude and the right form is enough — the point is to have something concrete to be wrong about.

Correct: Deliverable: screenshot the query and its results, then paste it below Question 23 in the Template.

Why: A prediction you can defend turns the computation into a check rather than a leap of faith — and an answer that contradicts it is caught on the spot. The grader wants to see the query you ran and the rows it returned in the same screenshot.

Comparison matrix

From Q23 - Type I with IN: refill the Age column from what you know. The rest of the table is as it appeared.

Discussion prompt

Q24 - Type II with EXISTS — before any calculation: what is the plan? Name the moves in order, in plain English, without doing the arithmetic.

Hint: It starts with: Test each customer with a correlated EXISTS subquery

Discussion prompt

Work backwards. The example finished here:

Deliverable: screenshot the query and its results, then paste it below Question 24 in the Template.

What was it asked to do, and what must it have been given? Reconstruct the problem from its answer.

Hint: Every quantity in the result had to enter somewhere. Account for each one.

Predict first

What makes a subquery 'Type II' (correlated) rather than 'Type I'?

Answer it in your own words, now, with nothing to choose from. The options are on the next slide — and picking the right one off a list is an easier skill than producing it.

Correct: It references a column from the outer query, so it runs once per outer row

Why: A Type II (correlated) subquery names an outer column - such as c.CID - so it cannot run alone and is re-evaluated for each outer row. A Type I subquery is independent and runs once.

Check your understanding

What makes a subquery 'Type II' (correlated) rather than 'Type I'?

• A. It references a column from the outer query, so it runs once per outer row (correct)
• B. It uses IN instead of EXISTS
• C. It returns more than one column
• D. It is written on a single line

Answer: A

Why: A Type II (correlated) subquery names an outer column - such as c.CID - so it cannot run alone and is re-evaluated for each outer row. A Type I subquery is independent and runs once.

Why B tempts people

IN is typically used with Type I subqueries; EXISTS is the usual Type II form - the opposite of this claim.

Why C tempts people

Column count doesn't define correlation; EXISTS subqueries often select * and are still correlated.

Why D tempts people

Formatting on one line or many has no effect on whether a subquery is correlated.

Discussion prompt

A FULL OUTER JOIN keeps every row from both tables: matched rows join up, and unmatched rows from either side come back with NULLs.

That is stated as though it always holds. Do one of two things: produce a case where it fails, or say precisely what rules such a case out. "It just does" is not on the menu.

Hint: Hunt at the extremes first — zero, one, negative, empty, equal. If every extreme survives, the reason they survive is the proof.

Put in order

Put the moves of Q25 - FULL OUTER JOIN - all three tables into the order they have to happen.

1. Full outer join Customer to Rentals, then join Rentcost
2. Select each field exactly once across the three tables
3. Order the result by Customer.CID and Rentcost.Make
4. Deliverable: screenshot the query and its results, then paste it below Question 25 in the Template.

Why: These are the moves of the worked example in the order it makes them, and each one is set up by the one before it. A full outer join keeps matched rows and unmatched rows from every table, which is how all three kinds of leftover row appear.

Annotate

Walk the callouts on Q25 - FULL OUTER JOIN - all three tables. Each one is a place this is easy to get subtly wrong.

• A full outer join keeps matched rows and unmatched rows from every table, which is how all three kinds of leftover row appear.
• Make lives in both Rentals and Rentcost, so it is listed a single time to satisfy the 'each field once' rule.
• Ordering by customer id and then by make gives the 12-row, 12-column layout the question specifies.

Put in order

These are the steps of Pattern: how to attack any of these 25, scrambled. Put them back in order before the next slide shows you.

1. Which tables hold the columns I need? One table -> plain SELECT. Two or three -> JOIN on the keys.
2. Am I filtering rows? Use WHERE (=, BETWEEN, LIKE, IS NULL, or column-vs-column).
3. Am I summarizing? Use SUM/AVG, add GROUP BY for 'broken out by', and CAST to float to keep decimals.
4. Am I looking for what NEVER happened? Outer join + IS NULL, or a Type I (NOT IN) / Type II (NOT EXISTS) subquery.
5. Did I match the exact wording? row count, ordering, DISTINCT, and column headings.

Why: This is the order the recipe itself gives. Recalling the sequence without the slide in front of you is the difference between recognising the method and being able to run it — most of what goes wrong in practice is a step done out of turn.

Discussion prompt

Pattern: how to attack any of these 25 works on the cases you have just seen. Push it to the edge: what is the most degenerate input it still handles — empty, zero, one item, everything equal — and what is the first case where it stops being true? Name the case, not just "it breaks".

Hint: Try the smallest legal input, then the largest, then the one where two things collide. Methods are specified at their edges; the middle takes care of itself.

Eliminate the wrong options

Q25 must return 12 rows including customers with no rental and makes never rented. Which join accomplishes that?

3 of these 4 are wrong. Strike them one at a time, and say what rules each one out before you strike the next. The survivor is the answer.

• A. FULL OUTER JOIN across all three tables
• B. INNER JOIN across all three tables
• C. LEFT OUTER JOIN from Rentals only
• D. A Cartesian product of the three tables

Survives elimination: A

Why: A FULL OUTER JOIN keeps matched rows plus unmatched rows from both sides, so the 8 rentals, 2 rental-less customers, and 2 never-rented makes all appear - 12 rows in total.

Check your understanding

Q25 must return 12 rows including customers with no rental and makes never rented. Which join accomplishes that?

• A. FULL OUTER JOIN across all three tables (correct)
• B. INNER JOIN across all three tables
• C. LEFT OUTER JOIN from Rentals only
• D. A Cartesian product of the three tables

Answer: A

Why: A FULL OUTER JOIN keeps matched rows plus unmatched rows from both sides, so the 8 rentals, 2 rental-less customers, and 2 never-rented makes all appear - 12 rows in total.

Why B tempts people

INNER JOIN drops unmatched rows, giving only the 8 rentals - it loses Vernon, Wilson, Toyota, and Volvo.

Why C tempts people

A LEFT JOIN anchored on Rentals keeps the 8 rentals but never introduces the customers or makes that have no rental.

Why D tempts people

A Cartesian product multiplies the tables into dozens of meaningless rows, not the 12 required.

Draw it

One page, no notation unless you need it: draw how these connect — Setup & the AutoRentals database · Part 1 - Querying one table · Part 2 - Joining tables · Part 3 - Dates, aggregates & grouping · Part 4 - NULLs & comparing columns · Part 5 - Outer joins & subqueries. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.