Three individual assignments, one team project, and the participation that holds the lab sessions together. Everything is marked on the decision you reach, not the technology you used to reach it.
Part 2 of the course (Lectures 11–20) is assessed out of 100. The weighting deliberately favours the project, because the project is the only component where you choose the problem.
Deadlines are expressed relative to lectures, not dates. Each assignment is due at 23:59 on the day before the lecture named below, so the material is fresh and the next session can build on your answers. Calendar dates are confirmed in class and on the LMS.
All three run on the course dataset — 15,000 ride bookings in bdma.rides. Because the dataset is seeded, your numbers must match the published figures exactly. If they do not, your query is wrong, and that is useful feedback before the deadline rather than after it.
Load the dataset into your own Atlas cluster, then argue for a document design.
uber_bookings.json and prove the load with countDocuments()route and ratings are embedded rather than referencedEight questions, each answered with a query you wrote and a number you can defend.
$match, and justify your thresholdexplain("executionStats") output from before and after with totalDocsExamined highlightedBuild a four-chart dashboard in Atlas Charts, then write the memo a manager would actually read.
The same standard applies to all three. A correct number with no interpretation scores roughly half. A confident interpretation built on a wrong number scores less. We are training the habit of checking the figure and saying what it means.
Teams of three or four. One dataset, modelled in a non-relational database, visualised in a dashboard, and argued into a recommendation. Presented in Lecture 19 or Lecture 20 and worth 40% of Part 2.
Five things, all of which the rubric marks explicitly.
explain(), or a documented Redis key design with its memory argumentYou may use the course Uber dataset, but a dataset you chose yourself nearly always produces a better presentation — you care about the answer.
The grade is for the decision, not the technology. A simple dashboard carrying a sharp, quantified recommendation beats an elaborate one that stops at “here are some charts”. If your final slide does not contain a verb — do this — you have not finished the project.
Marked out of 100 and scaled to the 40% weighting. The full brief, run sheet and peer-review process are in the Lecture 19 notes.
| Criterion | Marks | What a strong answer looks like |
|---|---|---|
| Technical execution | 25 | Queries, pipelines, indexes and key designs are correct, efficient and explained. The explain() comparison shows a real improvement and you can say why. |
| Data modelling & justification | 20 | The embed/reference or key-naming decision is stated, defended against the obvious alternative, and tied to a specific access pattern. |
| Dashboard design & clarity | 20 | Each chart answers a stated question. Chart types suit the data. Axes, units and filters are labelled. Nothing on the page is decorative. |
| Business framing & relevance | 15 | The problem is one an organisation would pay to solve, stated in a sentence, with the cost of not solving it quantified. |
| Insight & recommendation | 15 | A specific action, an expected impact with a number attached, and an honest statement of what would disprove it. |
| Presentation & Q&A | 5 | On time, evenly shared across the team, and questions answered directly — including “we don't know, and here is how we would find out”. |
One mechanism for everything: a Git repository, submitted as a link. It takes ten minutes to set up once and then costs you nothing for the rest of the course.
Create one repository for the course. Name it bdma-<your-roll-number>. Keep a folder per assignment: assignment1/, assignment2/, assignment3/, project/.
Commit the actual artefacts, not screenshots of them. Queries go in .js or .md files as text that can be copied and run. Screenshots are for dashboard output and explain() plans only.
Write a README.md in each folder. It should state what the assignment asked, how to run your work, and the headline numbers you found. Assume the reader has three minutes.
Never commit a connection string. Put credentials in a .env file and add it to .gitignore. A leaked Atlas URI in a public repository is an automatic deduction, and it is the single most common mistake in this course.
# .gitignore
.env
node_modules/Submit the repository link through the LMS before the deadline. For the project, one submission per team listing every member's name and roll number. The exact LMS link is announced in class.
Make the repository public, or add the lecturer as a collaborator. A private repository nobody can open is an unsubmitted assignment, and the timestamp on your fix will be after the deadline.
| Situation | Policy |
|---|---|
| Late submission | 10% of the component deducted per started day, up to three days. After that the submission is not marked. Git commit timestamps are the record. |
| Discussing approach with classmates | Encouraged. Argue about whether to embed or reference — that argument is the learning. |
| Sharing queries or memo text | Not permitted on individual assignments. Two identical pipelines with identical variable names is not a coincidence. |
| Using an AI assistant | Permitted and expected — it is how this work is done now. Disclose it in your README, one line on what you used it for. You remain fully answerable for every number and every claim in Q&A. |
| Submitting output you cannot explain | Treated as not submitted, whatever its source. The viva question “why did you write it this way?” is always available to the marker. |
| Using confidential workplace data | Only with written permission from the data owner and with identifiers removed. When in doubt, use a public dataset. |
These are the recurring ones, listed so that they are avoidable rather than surprising.
| Failure mode | Why it costs you |
|---|---|
| A dashboard with no recommendation | Charts describe; they do not decide. The final 15 marks are reserved for the decision. |
| Ranking a rate without a volume floor | 03:00 shows a 43.48% failure rate on 46 bookings. Rank by rate alone and you will recommend staffing the night shift. |
| Unlabelled axes or undisclosed filters | An unlabelled chart cannot be checked, so it cannot be trusted, so it cannot be marked. |
| Correlation presented as causation | “Cancellations rise with surge pricing” is an observation. “Surge pricing causes cancellations” needs an experiment you did not run. |
| Averaging over missing fields without noticing | $avg skips absent values silently. Average booking value across all bookings is not the same as across completed ones, and the gap is large. |
| A live demo with no fallback | Venue wi-fi fails. Keep screenshots or a recording. Losing four minutes of a twelve-minute slot to a loading spinner costs more than the demo was worth. |
| A model copied from the course dataset | Your dataset has different access patterns. Reusing our schema without re-deriving it is the one thing Lecture 11 told you never to do. |
If you are picking up the project for the first time, read the full brief and run sheet in the Lecture 19 notes, then look at the reference dashboard to see the standard a finished analysis is held to. The Atlas Charts build guide gives you the exact pipeline behind every panel on it, and the command reference has every query you will need.