The Data Analyst's Toolkit — First Session (Sports Business)

Discussion prompt

Before we open The Data Analyst's Toolkit — First Session (Sports Business): without looking back, what was the main idea of Decision Analysis — Oceanview Property Purchase, and what could you do by the end of it that you could not do before?

Hint: One sentence for the idea, one for the skill. If the second one is blank, that is the part to revisit.

Comparison matrix

From One question, five tools: refill the Stage column from what you know. The rest of the table is as it appeared.

Discussion prompt

Picture a 4×100 relay. No single runner wins it. Each runs one leg, then hands off the baton — and the baton here is your data.

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.

Sort into buckets

Every line below is part of the definition of end-to-end project or of query — one or the other, never both. Put each where it belongs.

end-to-end project

One project that spans the whole arc; a real question → the data pulled to answer it → the analysis → a presentation a non-technical boss understands → published proof anyone can review.

query

A single statement that says which columns, from which tables, filtered how, grouped how, ordered how.; One query is a repeatable, shareable definition of "the data."

b1

One project that spans the whole arc: a real question → the data pulled to answer it → the analysis → a presentation a non-technical boss understands → published proof anyone can review.

b2

A single statement that says which columns, from which tables, filtered how, grouped how, ordered how. One query is a repeatable, shareable definition of "the data."

Put in order

Put the moves of SQL in action: revenue per game by channel into the order they have to happen.

1. FROM ticket_sales WHERE season = 2024
2. GROUP BY channel
3. SELECT the aggregates, then ORDER BY rev_per_game DESC

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. Point at the right table and keep only last season's rows — before doing any math.

Comparison matrix

From SQL in action: revenue per game by channel: refill the rev_per_game column from what you know. The rest of the table is as it appeared.

Predict first

A student writes this, and it looks reasonable:

Pull everything and figure it out later.

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

Correct: Excel caps near a million rows and chokes long before that; you've moved the database's own job onto a tool that can't do it.

Let SQL do what it's built for; export only the answer.

Why: Excel caps near a million rows and chokes long before that; you've moved the database's own job onto a tool that can't do it.

Annotate

Walk the callouts on Trap: doing the crunching in the wrong place. Each one is a place this is easy to get subtly wrong.

• Excel caps near a million rows and chokes long before that; you've moved the database's own job onto a tool that can't do it.
• Move the computation to the data. What leaves the database is small, clean, and ready for the next tool in the relay.

Put in order

Put the moves of Python in action: attendance by day of week into the order they have to happen.

1. read_csv(...) the tidy pull from SQL
2. groupby("weekday")["attendance"].mean()
3. sort_values(ascending=False) and print

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. The relay handoff: Python starts from the small, clean table SQL exported — not from the raw database.

Comparison matrix

From Python in action: attendance by day of week: refill the avg attendance column from what you know. The rest of the table is as it appeared.

Predict first

A student writes this, and it looks reasonable:

Do everything in Python, including the final report.

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

Correct: You spend the afternoon fighting fonts and legends to rebuild what Power BI does in three clicks — and the VP still can't filter it themselves.

Use each tool for its leg of the relay.

Why: You spend the afternoon fighting fonts and legends to rebuild what Power BI does in three clicks — and the VP still can't filter it themselves.

Discussion prompt

Your SQL and Python are the engine under the hood. Nobody in the front office ever sees the engine. They see the dashboard — that's your whole analysis, wearing a suit.

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.

Predict first

A student writes this, and it looks reasonable:

Plug raw data straight into Power BI and ship the good-looking result.

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

Correct: Duplicated rows and a mislabeled channel are invisible once they're a smooth line.

Verify upstream; let the dashboard show a story you already trust.

Why: Duplicated rows and a mislabeled channel are invisible once they're a smooth line. Garbage in, beautiful garbage out — and you present it with confidence.

Discussion prompt

The rule this trap just fixed:

The dashboard is the last mile, not the analysis. It should only ever display numbers you've already confirmed are real.

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

A student writes this, and it looks reasonable:

Rebuild the report by copy-pasting fresh data in each week.

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

Correct: No record of what you did, one wrong paste corrupts it silently, and next month you can't explain — or reproduce — how the number was made.

Keep the transformation in SQL/Python; let Excel just present the output.

Why: No record of what you did, one wrong paste corrupts it silently, and next month you can't explain — or reproduce — how the number was made.

Match the pairs

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

• t1. query
• t2. EDA (exploratory data analysis)
• t3. repository (repo)

• d1. A single statement that says which columns, from which tables, filtered how, grouped how, ordered how. One query is a repeatable, shareable definition of "the data."
• d2. Poking the data to see what's there before you commit to an answer: distributions, group averages, outliers, trends. This is where most real insight is found.
• d3. A project's home on GitHub: its code, its data-handling scripts, and — most importantly — its README, the front page that explains what the project is and what you found.

Why: These are the working definitions of query, EDA (exploratory data analysis), repository (repo) as The Data Analyst's Toolkit — First Session (Sports Business) uses them. Pairing them correctly is the test of whether you could state each one with the slide switched off.

Predict first

A student writes this, and it looks reasonable:

Push everything — data, secrets, no explanation.

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

Correct: You've leaked a credential, blown the size limit, and left a reviewer staring at files with no idea what the project even is.

Publish the story, not the mess.

Why: You've leaked a credential, blown the size limit, and left a reviewer staring at files with no idea what the project even is. That's a strike, not a portfolio piece.

Sort into buckets

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

Holds up

Each tool owns one stage. They're not competitors — they're a relay team. Here's the whole map on one slide:; Picture a 4×100 relay. No single runner wins it. Each runs one leg, then hands off the baton — and the baton here is your data.; Your SQL and Python are the engine under the hood. Nobody in the front office ever sees the engine. They see the dashboard — that's your whole analysis, wearing a suit.

Breaks

Pull everything and figure it out later.; Do everything in Python, including the final report.

sound

These are stated as this lesson states them — each one survives the edge cases The Data Analyst's Toolkit — First Session (Sports Business) 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.

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.

Put in order

These are the steps of The end-to-end recipe, scrambled. Put them back in order before the next slide shows you.

1. Ask a real operations question — one sentence, decision-oriented.
2. SQL: pull and pre-aggregate just the rows that answer it.
3. Python: clean, explore, and (if useful) forecast.
4. Power BI / Excel: build the dashboard that tells the story to a non-technical stakeholder.
5. GitHub: publish the code + a README so anyone can follow it.
6. Write it up: the question, what you found, what you'd do about it.

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

The end-to-end recipe 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.

Put in order

Put the moves of One project, all five tools into the order they have to happen.

1. SQL — pull per-game paid attendance, promo flag, opponent, and price tier for three seasons
2. Python — compare promo vs. non-promo games, adjusting for opponent strength and weekend effects
3. Power BI / Excel — dashboard: attendance lift per promo type, filterable by opponent and month
4. GitHub — publish the query, the notebook, and a README stating question, method, and finding

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. The warehouse holds millions of ticket rows; SQL filters to the ~120 home games and returns one tidy row per game — the baton.

Discussion prompt

Work backwards. The example finished here:

GitHub — publish the query, the notebook, and a README stating question, method, and finding

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.

Eliminate the wrong options

You need last season's ticket sales for the three home rivals, already summed per game, out of a 10-million-row database. Which tool is the right first stop?

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. SQL — filter and aggregate at the source, export the small result
• B. Excel — open the database and pivot the 10M rows
• C. Power BI — connect and build the chart first
• D. GitHub — create the repo first

Survives elimination: A

Why: Extraction is the first stage, and SQL owns it. Filtering to three opponents and summing per game happens on the server, so only a handful of clean rows ever leave the database — exactly what the next tool wants.

Check your understanding

You need last season's ticket sales for the three home rivals, already summed per game, out of a 10-million-row database. Which tool is the right first stop?

• A. SQL — filter and aggregate at the source, export the small result (correct)
• B. Excel — open the database and pivot the 10M rows
• C. Power BI — connect and build the chart first
• D. GitHub — create the repo first

Answer: A

Why: Extraction is the first stage, and SQL owns it. Filtering to three opponents and summing per game happens on the server, so only a handful of clean rows ever leave the database — exactly what the next tool wants.

Why B tempts people

Excel can't hold 10M rows (it caps near ~1.05M) and shouldn't be the one filtering a database — that's SQL's job. Excel comes later, on the small result.

Why C tempts people

Power BI is the present stage. Pointing it at 10M raw rows with no upstream aggregation is slow and skips the analysis you haven't done yet.

Why D tempts people

GitHub is the publish stage — it hosts finished work. There's nothing to publish before you've pulled and analyzed the data.

Eliminate the wrong options

Your cleaning steps and forecast live in a Jupyter notebook on your laptop. Which move best turns that into portfolio proof an interviewer can actually evaluate?

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. Push the notebook plus a README (question, method, finding) to a public GitHub repo
• B. Email them a screenshot of the final dashboard
• C. Keep it local and offer to demo it live sometime
• D. Paste the Python code into the Power BI report's description box

Survives elimination: A

Why: Publishing is the last stage, and GitHub owns it. A public repo with a README lets a stranger see the question, follow your method, and trust the finding on their own time — that's what "reviewable" means and it's the link you send.

Check your understanding

Your cleaning steps and forecast live in a Jupyter notebook on your laptop. Which move best turns that into portfolio proof an interviewer can actually evaluate?

• A. Push the notebook plus a README (question, method, finding) to a public GitHub repo (correct)
• B. Email them a screenshot of the final dashboard
• C. Keep it local and offer to demo it live sometime
• D. Paste the Python code into the Power BI report's description box

Answer: A

Why: Publishing is the last stage, and GitHub owns it. A public repo with a README lets a stranger see the question, follow your method, and trust the finding on their own time — that's what "reviewable" means and it's the link you send.

Why B tempts people

A screenshot shows the result but hides the work — the interviewer can't check the method, the cleaning, or whether the number is even right.

Why C tempts people

Work that only lives on your laptop isn't a portfolio; a live-only demo can't be reviewed before the interview and disappears after it.

Why D tempts people

Power BI's description box isn't a code host — no history, no README, no real way to read or run a notebook. That's what GitHub is for.

Draw it

One page, no notation unless you need it: draw how these connect — The Big Picture · SQL — Get the Data · Python — Explore & Forecast · Power BI — Show the Story · Excel — The Universal Tool · GitHub — Publish the Proof. Put an arrow wherever one of them is what makes another possible, and label the arrow with why.