Data Science Foundations with Python & SQL

Ask a question the data can answer

Define a decision, an observation and a useful denominator before writing code.

In this chapter

  • Define a decision, an observation and a useful denominator before writing code.
  • Produce and check the chapter's practical artifact.
From evidence to decision
  1. Decision
  2. Observation
  3. Rate
  4. Caveat

Each transition should preserve enough information to explain and reproduce the result.

Begin with the decision

A library manager asks whether Saturday equipment loans need an extra service desk. This is a decision about queue capacity, not a contest to find the largest number in a spreadsheet. Define one observation as a completed loan transaction, then identify what is missing: a loan count does not measure waiting time. A defensible first question is whether recorded Saturday volume is consistently higher per opening hour than weekday volume.

Write a data dictionary before importing anything. For a small synthetic fixture, keep day, opening_hours and loans. Specify that hours must be positive, loans cannot be negative and each row represents one day. The word synthetic matters: these numbers are teaching examples, not evidence about an actual library. Do not replace missing information with an invented observation.

A rate changes the story

Consider a weekday with 60 loans over ten hours and Saturday with 48 over six hours. Looking only at totals suggests the weekday is busier. Comparing rates gives six versus eight loans per hour, so Saturday has greater average demand while still having fewer loans. Neither rate describes peak arrival bursts or staff availability. State the gap rather than presenting a staffing recommendation as proven.

The script uses dictionaries: named keys let a reader see what each number means. A loop processes one row at a time, and the assertion stops the calculation if its denominator is invalid. Save the snippet as lesson.py and run python lesson.py from a terminal. No external package or account is needed.

python
days = [
    {"day": "weekday", "hours": 10, "loans": 60},
    {"day": "Saturday", "hours": 6, "loans": 48},
]
for row in days:
    assert row["hours"] > 0
    rate = row["loans"] / row["hours"]
    print(row["day"], round(rate, 2))

Separate calculation from interpretation

A calculation answers only the question encoded in it. If Saturday includes self-service loans while weekdays exclude them, equal column names hide different definitions. Attach a measurement note to the output. Prefer 'the synthetic Saturday average is eight loans per hour' to 'hire another employee'. The first statement can be checked; the second needs cost, queues and alternatives.

Before sharing an analysis, ask another person to reproduce its unit of observation. If they interpret a row differently, resolve that disagreement before expanding the dataset. A five-line correct analysis is more useful than an elaborate dashboard built on mixed units.

Workbench

  • Run the snippet and record both rates.
  • Add a closed day with zero hours and observe the assertion; decide to exclude it with a reason, not a fake hour.
  • Write a four-sentence memo containing the decision, metric, calculation and missing measurement.

Expected checks

  • Weekday = 6.0 and Saturday = 8.0 loans/hour.
  • The memo does not claim queue times were observed.

Check your understanding

Which comparison answers the first question?

  • Total loans only
  • Loans per opening hour with consistent definitions
  • The largest single transaction
Answer explanation

The denominator adjusts for different exposure; consistent recording is still required.

Official tools & further reading

The curriculum

  1. Ask a question the data can answer — Free preview

    Define a decision, an observation and a useful denominator before writing code.

  2. Make invalid records visible — Free preview

    Parse a small dataset into validated records without hiding rejected observations.

  3. Turn an analysis into a reusable function — Sign-in access

    Separate a calculation from input/output and check its boundaries.

  4. Join tables without multiplying the story — Sign-in access

    Use keys, grouped queries and reconciliation checks to make SQL results trustworthy.

  5. Describe variation before choosing a headline — Free preview

    Distinguish typical values, unusual observations and uncertainty about the future.

  6. Design a chart that survives questions — Sign-in access

    Choose clear units, honest scales and a comparison that answers the decision.

  7. Build a pipeline that fails informatively — Sign-in access

    Connect validation, aggregation and a deterministic output with explicit failure behavior.

  8. Deliver the Community Meter decision pack — Sign-in access

    Combine code, checks and a careful recommendation in a complete local project.