INFO20003 Database Systems: how is it assessed, and where do marks go?

Most students who struggle in INFO20003 are not struggling with SQL syntax. They are losing marks at the modelling stage, several days before they write a line of SQL, because a schema that misreads the brief will produce queries that run cleanly and answer the wrong question.

Author: MAAS Editorial Team · Reviewed by a MAAS subject mentor
Last updated: 2026-09-02
Category: it-data

What are the assessment components and weightings in INFO20003?

Direct answer: The University of Melbourne handbook lists three components for INFO20003 Database Systems in 2026: three practical assignments worth 10% each, ten short timed weekly quizzes worth 1% each, and one written 3 hour open-book final examination worth 60%. The handbook estimates 30 to 35 hours of work across the three assignments, all completed individually.

Evidence: That split matters more than the headline percentages suggest. The examination alone carries 60%, so a student who treats the subject as an assignment subject and revises in the final fortnight has left more than half the marks to a single 3 hour sitting. The quizzes are worth 1% each, which reads as trivial, but they run weekly through the teaching period and function as a pacing device rather than a mark opportunity. A student who skips 4 quizzes has lost 4 marks and, more importantly, has skipped 4 checkpoints that would have told them their understanding of normalisation was drifting.

What to do about it: in week 1, open the assessment page of the handbook entry for your own year, not a study-notes site, and write the three weightings and both hurdle thresholds on the first page of your notes. Handbook entries are versioned by year, and the 2018 and 2023 entries for this subject differ from the 2026 one.

What is the assignment hurdle, and how does it work?

Direct answer: INFO20003 carries two hurdles. Students must achieve at least 50% on the assignments, meaning 15 of the 30 available marks, and must also achieve a cumulative 50% across the examination and the weekly quizzes combined, meaning 35 of the 70 marks those two components share.

Evidence: A hurdle is structurally different from a weighting, and students who have not met one before tend to discover the difference too late. Under a pure weighting, marks are fungible, so a strong examination compensates for weak assignments. Under a hurdle they are not, because each 50% threshold has to be cleared on its own. A student sitting on 13 of 30 for assignments cannot pass the subject on an examination result of any size, because the second hurdle and the first are assessed separately. The two-hurdle structure here also means the quizzes are not decorative: they sit inside the 70 mark pool with the examination, so quiz marks banked during semester genuinely lower the examination score you need on the day.

Example: A student came to a mentoring session in week 11 with 12 of 30 on assignments and a plan to "make it up in the exam". The plan could not work, and the useful conversation was not about study technique but about the special consideration and re-assessment provisions in the subject's own assessment page. Reading the hurdle in week 1 would have changed which assignment she prioritised in week 4.

Which topics does the examination actually test?

Direct answer: The handbook's stated content covers entity relationship modelling from conceptual through to physical design, normalisation and de-normalisation, the relational model and relational algebra, SQL, query processing and query optimisation, transactions, storage organisation, database administration, data warehousing and big data analytics, with an overview of modern NoSQL systems.

Evidence: The published content list is a wide one, and the examination being open book changes what "knowing" it means. In a closed-book paper, recall is the constraint. In a 3 hour open-book paper, everyone in the room has the syntax in front of them, so the marks separate on judgement: which normal form this schema violates, whether an index would actually help this query, why a transaction anomaly appears under one isolation level and not another. The five stated learning outcomes point the same way, since they ask students to solve practical data-modelling tasks, design SQL queries, understand internal mechanisms and policies, apply transactions and argue for their use, and profile and tune analytics queries. Three of those five verbs are argumentative rather than procedural.

What to do about it: build a lookup sheet organised by decision, not by topic. One page per question you might be asked to decide, each listing the rule, the standard counterexample, and the case where the rule does not apply. A sheet organised as "chapter 5 notes" is close to useless under time pressure; a sheet organised as "how do I tell 2NF from 3NF" is not.

How do you approach an ER modelling task step by step?

Direct answer: Work outward from the brief in a fixed order: entities, then attributes and keys, then relationships and their degree, then cardinality and participation constraints, and only then the advanced constructs of weak entities, hierarchies and aggregations. Draft the model before you open any database tool, because a modelling error is cheap on paper and expensive in a script.

Evidence: The evidence on where novices fail is unusually specific. Rashkovits and Lavy (2021), analysing the ER diagrams of 65 second-year information systems students and classifying every error using the SOLO taxonomy, found that the failures cluster in the abstract constructs rather than the obvious ones. Seventy per cent of their participants produced the complete list of expected strong entities and 75% produced the expected binary relationships, but 80% missed a required ternary relationship, 83% failed to provide the aggregation the brief needed, 86% modelled the hierarchies incorrectly, and 88% failed to mark a weak entity as weak. Their explanation is that the difficult constructs are the ones the brief never names: "Aggregations, hierarchies, and weak entities are not specified in the text at all" (Rashkovits & Lavy, 2021, p. 15). The authors note plainly that "weak entities are elusive concepts" for designers at this stage. That gap between what the brief says and what the model must contain is the whole difficulty.

What to do about it: after you have a draft model, run one deliberate pass looking only for the four constructs the brief will not have named. Ask whether any entity cannot be identified without its parent, whether any relationship truly needs three participants rather than two chained pairs, whether any pair of entities shares a parent, and whether any relationship itself participates in another relationship. Rashkovits and Lavy found no student in their sample proposed an n-ary solution where one was defensible, so this pass costs about 20 minutes and targets precisely where the marks were lost.

What are the most common mistakes in SQL, and why do they recur?

Direct answer: The recurring SQL failures are logical rather than syntactic. A syntax error stops the query and announces itself; a logical error returns a result set that looks plausible and answers a different question, which is why it survives all the way to submission.

Evidence: Taipalus et al. (2018), analysing over 33,000 SQL queries submitted by students in an introductory database course, built a database-management-system-independent categorisation of query errors and reported that the analysis "reveals new types of errors, namely logical errors recurring in similar manners among different students" (Taipalus et al., 2018, p. 1). The word doing the work there is recurring: these are not random slips but the same mistakes reproduced independently, which is the signature of a shared misconception rather than carelessness. Miedema et al. (2023) pursued that point by running a two-round Policy Delphi with 19 SQL experts to collect hypotheses about the causes behind each error, arguing that identifying misconceptions is what allows teaching to address the cause rather than the symptom. For a student, the practical consequence is that a query which runs is not evidence of a correct query.

Example: A student's aggregate query returned a sensible-looking figure per customer and lost marks anyway. The join had silently dropped every customer with no orders, so the report answered "average value among customers who ordered" while the brief asked for the average across all customers. Nothing errored. The fix was one word in the join type, and the habit that would have caught it was checking the row count against a known total before trusting the output.

What to do about it: verify every query against something you already know. Count the rows in each base table first, predict roughly how many rows your result should have, then run it. Where the count surprises you, the query is wrong even when the numbers look reasonable, and this check takes under a minute per query.

How do you spread the work across the teaching period?

Direct answer: Treat the three assignments and ten quizzes as one schedule rather than thirteen separate events. The handbook's own estimate of 30 to 35 hours across the assignments is roughly 3 hours a week during a 12 week teaching period, which is only manageable if it starts in week 1.

Evidence: The subject's content sequence is cumulative in a way that punishes catching up. Normalisation depends on a correct relational schema, which depends on a correct conceptual model; query optimisation depends on understanding how the query processor uses the physical structures. A student who defers the modelling material until the second assignment is due is trying to learn three dependent layers in the same week, and the weekly quizzes will already have recorded the drift. Because the quizzes sit in the same 70 mark pool as the examination, that drift is visible in the mark ledger well before the examination period.

What to do about it: after each quiz, write one line naming what you got wrong and which layer it belonged to. Three entries pointing at the same layer is your signal to book help that week rather than in the swot vac.

Frequently asked questions

Is INFO20003 the same subject at every Australian university?
No. INFO20003 as Database Systems is a University of Melbourne subject, listed as core in the Bachelor of Science for the Computing and Software Systems major and the Informatics major, and also required in the Diploma in Informatics. Codes beginning INFO are used widely across the sector for unrelated subjects, so confirm the code against your own institution's handbook before buying textbooks or downloading notes.

Does the open-book exam mean I do not need to memorise anything?
No. Open book removes the recall penalty, not the time pressure. In 3 hours you cannot look up something you have never read, so the material still has to be familiar enough that lookup is confirmation rather than learning.

What happens if I fail the assignment hurdle but pass everything else?
The hurdle is a separate condition from the weighted mark, so failing it means failing the subject regardless of your examination result. If you are at risk, the assessment page for your year and your subject coordinator are the correct first contacts, and week 8 is a far better time to raise it than week 12.

Can MAAS write my database assignment or SQL scripts for me?
No. MAAS works as an academic advisor under Australian academic integrity expectations, and the work you submit must be your own. A MAAS mentor can help you read a brief accurately, test whether your ER model holds up against the requirements, and talk through why a query returns what it returns, in the same way a consultation with a tutor works.

Do I need programming experience before this subject?
Not the same kind. The subject is about data modelling and database management rather than general programming, so students arriving from a programming background often find the modelling harder than the SQL, and students arriving from a business background often find the reverse.

References

Miedema, D., Fletcher, G., & Aivaloglou, E. (2023). Expert perspectives on student errors in SQL. ACM Transactions on Computing Education, 23(1), 1–28. https://doi.org/10.1145/3551392

Rashkovits, R., & Lavy, I. (2021). Mapping common errors in entity relationship diagram design of novice designers. International Journal of Database Management Systems, 13(1), 1–19. https://doi.org/10.5121/ijdms.2021.13101

Taipalus, T., Siponen, M., & Vartiainen, T. (2018). Errors and complications in SQL query formulation. ACM Transactions on Computing Education, 18(3), 1–29. https://doi.org/10.1145/3231712

Tools & resources

• MAAS academic support for feedback on a data model or a draft you have written.
• MAAS tutoring for working through normalisation and query logic with a mentor.
• Related course guides: COMM2822 Databases for Business Analytics and INFO1110 Introduction to Programming.