DS2 — Working with Data
Program: MSBA · Credits: 1.0 · Academic year: 2026–2027 Format: 3 teaching sessions × 200 minutes + a closed-book final exam in a separate session (one handwritten A4 sheet of notes allowed) Instructor: Eduardo Ariño de la Rubia · RubiaE@ceu.edu · office hours by appointment
What this course is for
Real data arrives messy. Types are wrong, values are missing in three different notations, there is no obvious key, and an API sends the answer in pages. The analysis you actually want to run is rarely the hard part — getting the data into a shape where that analysis is possible, and being able to show the shape is right, is where the work goes.
This course is one credit of practical instruction in exactly that layer: tables, joins and pipelines. SQL on DuckDB for one table and for many, then a small pipeline in a notebook, from an API’s pages and a statistics office’s file: the reading and parsing are supplied, and you build bronze, silver and gold (raw data kept as it arrived, cleaned once, then shaped for the question) and check the steps that can lose something. Almost nothing in it crashes. The query runs, the number comes out, and the number is wrong — a join tripled the revenue, a filter quietly dropped every row with a missing value. The course’s thesis is one sentence: no error is not the same as correct. The skill is to look for evidence of wrongness before anyone complains, and then to build the check into the code so that next time it fails out loud.
What you will be able to do
- State the grain and the key of a table, and prove the key with a query.
- Read a column’s type and say what it did to the values; decide what “missing” means, and state what
NULLdoes to a filter, a count, an average, and a join. - Answer a business question from one table in SQL — filter, calculate, aggregate, group — and say how many rows to expect.
- Join tables without corrupting the result — choose the join the question needs, count before and after, find the unmatched rows, and aggregate at the right grain.
- Check a table made from an API’s pages against what the pages say they hold, and find the records it never read.
- Build bronze, silver and gold: keep the raw data as it arrived, clean it once into silver, shape gold for the question, and count between the layers to find which one lost a number.
- Reconcile every number against an independent computation before reporting it.
- Say what a number shows — what it assumes, which rows it excludes and why, and what the data cannot answer.
Format and workload
Each session runs two blocks of a 45-minute lecture plus a 45-minute hands-on lab, with a break between. Sessions 2 and 3 open with a 10-minute closed-book knowledge check, which takes the first ten minutes of that block’s lecture. In the lecture you predict, then watch: every query is on a slide, you write down what you expect, and the next slide shows what it printed; laptops are for notes. You type in the lab — each lab’s project downloads during the five-minute stretch before it. The labs are where the learning happens: each hands you a colleague’s report that runs without an error and prints a wrong number; you find out why, write the query the question actually needs, run the check that would have caught it, and explain it to classmates.
From Session 2 the labs are done in teams of three, on one work laptop. Each of you holds one role for a lab: the keyboard types; the AI person may use an assistant on their own device, and tells the team what it says; the checker says, before each query runs, which number must stay the same, go up or go down, and reads each check out. You keep the same team for the day and change role for the second lab. Homework, the knowledge checks and the exam are individual.
Expect about 14–15 hours of work outside class, most of it on the three homeworks: about 5 hours for Homework 1 (its two stretch questions are not graded), about 3 for Homework 2, about 3 for Homework 3, and 3–4 preparing for the exam, the mock and the Knowledge check 3 retry included. These are estimates; if you are well past one, say so on the Moodle forum. It is not a mark against you.
Prerequisites and setup
DS1 — Computing for Analytical Work (ECBS5293), and everything it left you with: the terminal, uv, VS Code and the .venv kernel, paths from the project folder, Git from git status to git archive, DS1’s five-part diagnosis note, and explaining your fix to a neighbour. This course re-teaches none of it. Windows users work in Git Bash, as in DS1. DuckDB arrives with each project’s uv sync: there is nothing new to install. No SQL is assumed. Bring a laptop to every session.
Before Session 1, run the setup check (the Pre-course setup page) and submit its output to the Moodle “Setup verification” slot. It walks the whole path once — clone, sync, run, notebook, commit, git archive, submit — so the first thing you submit in this course is the setup, not Homework 1.
If you did not take DS1, the Bridge from DS1 page lists the six DS1 habits this course assumes, each with the DS1 page that teaches it and a short exercise. Do it before Session 1. The exercises are practice; the setup check is the evidence. When you submit the setup check, say in the Moodle text box whether you took DS1 and roughly how long setup took you. If you did not take DS1, or setup failed or took you more than an hour, book a supported 30-minute rehearsal with a TA in the week before Session 1, on Moodle. The Glossary defines every term used here, and the SQL reference has every query pattern the course teaches.
AI policy
You may use AI assistants to explain errors, suggest diagnostic steps, teach you concepts, and improve your writing. You may not use AI to submit code or explanations you cannot defend in person, run commands you cannot explain, or describe work you did not do. In a team lab one person holds the AI role, on their own device: nobody else sees that screen, that person never types on the team’s work laptop, and for the first five minutes of every lab they share nothing from the assistant, so that the team meets the problem with its own heads first.
AI writes SQL that runs. Running is not right. An assistant given your schema will write a join that returns rows, and it will not tell you that the rows are tripled. The counts are yours to run. When you ask an assistant about a query, give it the schema and the grain of each table, the number you expected and the number you got, and ask for the checks that would tell them apart — then run those checks yourself.
You remain fully responsible for everything you run, change, and submit. The assessment design assumes you used AI; it checks whether you understood the result.
Assessment
| Component | Weight |
|---|---|
| Homework 1 — One table, the weekly numbers | 10% |
| Homework 2 — Tables that meet: three numbers for the board | 15% |
| Homework 3 — Waste per person: two files, three layers | 15% |
| Knowledge check 2 (start of Session 2, closed-book) | 5% |
| Knowledge check 3 (start of Session 3, closed-book) | 5% |
| Final exam (closed-book, in person, separate session) | 50% |
Homework is a larger lab, graded against a rubric published with each assignment. From Homework 2, every question is answered in the notebook with the query, what it printed, the supplied check cell filled in, and one sentence (what the number measures, which rows it comes from, which rows the query left out); the notebook is the whole submission. (Homework 1, already out when this was decided, kept its five written parts and its archive.) In Homework 3 you also write each question’s count yourself, and end with a short reflection on the course. A right number whose check is empty, or whose sentence says it counts something else, is a number that could be right by accident, and it is scored that way. Each homework is due Saturday at 23:59, with a one-day late window; its self-check key is posted on Moodle after the late window closes. Do not expect graded feedback on Homework 3 before the exam: its self-check key and the mock exam with its key are that feedback.
Labs carry no points. A lab is complete when its checkpoint is on Moodle; nobody signs you off. In Session 1 that was your diagnosis note. From Session 2 the labs are team work and there is no note: the team’s notebook is the checkpoint (the keyboard uploads it; everyone else pastes the team’s names and roles as their submission text). The last ten minutes of every lab are for explaining your work to the team next to you. The checkpoint is a completion record, not graded work: staff read a sample of notebooks, and come to any hand that goes up. Labs cost you preparation if skipped, not points.
Closed book, with one sheet. The two knowledge checks and the final exam are closed-book: no laptop, no phone, no AI. You may bring one A4 sheet of notes, handwritten by you, both sides. Making the sheet is revision in itself.
Knowledge checks are 10-minute closed-book checks on the previous session’s material. Each is 5%. Each asks you to write at least one short query by hand. Marked papers are at the TA office from the Monday after each check, and each check’s key is posted on Moodle that same Monday, so you have both checks and both keys before the exam. The key’s model queries, scored clause by clause, are how the exam’s written queries are marked. After Knowledge check 3, everyone gets a short retry: one query of the same kind, posted on Moodle on Monday 19 October, answered by Wednesday 21 October, and returned by Friday 23 October with its model answer and one correction. The retry is ungraded and is not a make-up: it is a second attempt at the query the exam tests again.
The final exam is closed-book, individual, in person, about 70 minutes, in a separate session after Homework 3 is due; the program calendar sets its date, and Moodle announces it. It tests the same skills as the homeworks on new scenarios: ten multiple-choice questions on short scenarios (40 points), four queries you write by hand and that are scored clause by clause (40 points), and one diagnosis note that ends with the two sentences you would send a manager — what the corrected number shows, and what it cannot (20 points). A mock exam in the same format is posted on Moodle on Monday 19 October, after Session 3, so you can sit it, check your own answers against the course materials, and try again; its self-check key follows with Homework 3’s, on Monday 2 November.
Schedule
| Session | Date | Arc | Homework |
|---|---|---|---|
| Setup check | before Session 1 | Clone, sync, run, commit, archive, submit — once | submit to Moodle before Session 1 |
| 1 — What is this data? | Mon 5 Oct 2026 | Grain, keys, types, and missing values; one table in SQL: rows, then groups | HW1 due Sat 10 Oct, 23:59 |
| 2 — What happens when tables meet? | Mon 12 Oct 2026 | How to join two tables: JOIN, LEFT JOIN, and the rows with no partner; then what one row is after a join, the keys that repeat, and one row per order first | HW2 due Sat 17 Oct, 23:59 |
| 3 — Can I trust the answer? | Mon 19 Oct 2026 | A small pipeline, and two questions at every step. Did every record arrive? An API’s pages as a table, counted against what the pages say they hold. Did every value survive? Bronze, silver and gold (raw as it arrived, cleaned, shaped for the question), CAST against TRY_CAST, and the count between the layers | HW3 due Sat 31 Oct, 23:59 |
| Final exam | separate session | Closed-book (one handwritten A4 sheet), about 70 minutes | date set by the program calendar, on Moodle |
Self-check keys are posted on the morning of Monday 12 October (HW1), Monday 19 October (HW2), and Monday 2 November (HW3, with the mock exam’s key). The mock exam’s questions and the ungraded Knowledge check 3 retry are posted on Monday 19 October, after Session 3. All deadlines are on Moodle, which is authoritative.
Submitting your work
Everything is submitted through Moodle; nothing is graded from GitHub. You clone each lab and homework from a public starter repository and work locally. For Homeworks 2 and 3 you upload the notebook, run top to bottom with its outputs saved, and nothing else; Homework 1’s README says how its archive was made. Submissions must run as instructed inside a clean copy of the starter and contain nothing you cannot explain.
Policies
- Late homework: accepted up to one day late at −10% (nothing after Sunday 23:59, so each self-check key can post on Monday morning — before that afternoon’s knowledge check for HW1 and HW2, and with the mock exam’s key for HW3).
- Extensions: ask before the deadline, by email, with a reason. Documented illness or emergencies are always accommodated.
- Missed knowledge check: a documented absence moves that 5% to the final exam; an undocumented absence scores 0. No make-up checks.
- Missed lab: do it at home that week, alone, and upload the notebook to its Moodle checkpoint; put a hand up on the forum if you want someone to look at it.
- Regrading: within 7 days, in writing, naming the rubric criterion you believe was misapplied. The whole submission is re-read; the grade can move either way.
- Oversubscription: this is a core MSBA course. If it is oversubscribed, seats go to MSBA students first, then EDP and data-track students, then others as space permits — in order of sign-up and subject to program rules.
- Grade conversion: CEU letter scale — A 94+ · A- 88–93 · B+ 80–87 · B 71–79 · B- 63–70 · C+ 58–62 (minimum pass) · F below.
Academic integrity and accessibility
CEU academic integrity and accessibility policies apply; contact me and the relevant university office early if you need accommodations. If speaking aloud is a barrier, the end-of-lab explanation can be written for your partner to read — arrange it with me in advance. Accessible-format exam papers are available on request per your CEU accommodation letter; ask at least a week ahead.