COMM2822 Introduction to Databases for Business Analytics at UNSW is the rare business course where your work either runs or it does not, and that clarity misleads people.
COMM2822 Introduction to Databases for Business Analytics at UNSW is the rare business course where your work either runs or it does not, and that clarity misleads people. A schema loads, the queries return rows, nothing is broken, and the mark still lands mid-range. The reason is that this course does not assess whether your database functions. It assesses whether the design decisions behind it can be defended against the business description you were given, and whether your queries answer the question that was actually asked. Below is how MAAS mentors read a course built this way, and where Vietnamese students at UNSW most often lose the marks they earned elsewhere.
Author: MAAS Editorial Team · Reviewed by a Senior Information Systems mentor (PhD, Data Management)
Last updated: 2026-08-17
Category: writing-tips
What is COMM2822 and where does it sit in the degree?
Direct answer: COMM2822 Introduction to Databases for Business Analytics is a 6-unit-of-credit UNSW Business School course, taught out of the school responsible for information systems and technology management. It teaches the concepts and technologies used to create and manage business databases: entity relationship modelling, the relational model, normalisation, implementation in a relational database system, and Structured Query Language. It is a foundation course for the analytics side of a business degree rather than a computer science unit, and that positioning shapes everything about how it is marked.
Evidence: The published learning outcomes run in a deliberate sequence. Students are expected to create and apply conceptual and relational database modelling methods, then to design, implement and evaluate a database system, then to access and manipulate a relational database using SQL. The verb in the second outcome is the one people skim past. Evaluate is not the same as build, and a course that asks you to evaluate your own design is telling you in advance that justification carries marks.
Example: A Vietnamese student in her second year at UNSW came to MAAS frustrated that her assignment had been marked lower than a classmate's, when both databases contained the same tables. Reading both submissions side by side, her mentor found the difference in about half a page: the classmate had written a short paragraph explaining why a particular relationship had been modelled as many-to-many, and she had simply drawn it. The structure was identical. Only one of them had been argued.
Where does the mark actually sit in a database assignment?
Direct answer: In a course of this design the marks cluster in three places, and none of them is "does it run". They sit in the fidelity of your model to the business scenario, in the justification of the assumptions you had to make where the scenario was silent, and in whether your SQL answers the question posed rather than a nearby question that was easier to write. Technical correctness is the entry ticket, not the achievement.
| What students think is assessed | What is usually assessed | Where the gap shows |
|---|---|---|
| The diagram is drawn correctly | The diagram matches the described business | Entities invented that the scenario never mentions |
| The tables are normalised | You can say what normalising fixed | 3NF asserted, never demonstrated |
| The query returns rows | The query answers the stated question | Right output, wrong question |
| The design works | The design is defended against alternatives | No assumptions section at all |
Evidence: Empirical work on data model quality has long distinguished correctness from quality, and has argued that a model must be evaluated against dimensions such as completeness, integrity and understandability rather than against a single correct answer (Moody & Shanks, 2003). That is precisely the logic a database rubric applies. A model that is internally consistent can still be a poor representation of the business it was supposed to describe.
Example: A student modelling a small retail scenario built a beautifully normalised schema with eleven tables. His mentor asked one question: which sentence in the brief made you create the supplier-contact table? He could not find one. He had modelled the business he imagined rather than the one he was given, and every extra table was a place to lose marks rather than earn them.
Why do assumptions carry so much weight here?
Direct answer: Because every business scenario handed to a student is incomplete, deliberately. Real business descriptions are ambiguous, and the course is training you to notice ambiguity rather than paper over it. When the brief does not say whether a customer can hold more than one account, you must choose, and the mark comes from stating the choice and its consequence, not from choosing the option the marker had in mind. An unstated assumption reads as an oversight. A stated assumption reads as judgement.
Evidence: The entity relationship approach was introduced as a way of representing a view of the real world in a form that could be discussed and agreed before implementation (Chen, 1976). The word discussed matters. The notation exists so that a design can be interrogated by someone who was not in your head, which is exactly what a marker is doing.
Example: Two students in the same tutorial resolved the same ambiguity in opposite ways. One allowed a booking to reference multiple rooms, the other did not. Both were marked well, because both had written a line explaining what in the scenario had pushed them that way and what would need to change if the assumption turned out to be wrong. A third student made the same choice as the first and wrote nothing, and lost marks the other two kept.
What is normalisation actually testing?
Direct answer: Normalisation is testing whether you can name the problem a design change solves. Third normal form is not a decoration you apply at the end; it is a sequence of decisions that removes specific update, insertion and deletion anomalies. If you can say which anomaly a decomposition removed, you understand it. If you can only say the tables are in 3NF, you have recited a result rather than shown a process.
Evidence: The relational model was proposed to protect users from having to know how data is physically organised, and to keep the logical structure stable as the data changed (Codd, 1970). Normal forms were then set out as practical rules for eliminating redundancy and the anomalies it causes, and the classic plain-language treatment stresses that each form addresses a particular kind of trouble rather than being a general marker of quality (Kent, 1983). A design can be fully normalised and still be wrong for the business, which is why the justification matters more than the label.
Example: A student wrote in her report that her tables were in 3NF because she had removed transitive dependencies. Her mentor asked her to name one. She traced it, found that storing the branch postcode alongside the branch name in a transaction table meant a branch relocation would have required updating hundreds of rows, and wrote that sentence into the report instead. The technical work had not changed. The sentence was worth marks that the label was not.
How do you keep SQL from answering the wrong question?
Direct answer: Write the question in plain English above each query before you write the query, then read the result back against that sentence. Most SQL that loses marks is syntactically fine. It fails because a join silently dropped the rows that had no match, because an aggregate was computed over a filtered set that no longer represented the population asked about, or because a condition was applied after grouping when it belonged before. These are reasoning errors, and they survive testing precisely because the query still runs.
Evidence: Standard database texts treat query formulation as a modelling activity in its own right, not a translation exercise, and devote substantial attention to the semantic difference between join types and to where filtering belongs in the evaluation order (Connolly & Begg, 2015; Elmasri & Navathe, 2016). The reason those chapters exist is that the errors are conceptual rather than syntactic.
Example: A team assignment asked for the average order value per customer. The query returned a plausible number. Their mentor asked what happened to customers who had registered but never ordered, and the room went quiet. The inner join had removed them, so the figure described active customers rather than all customers. One word changed. The interpretation in the report changed completely, and so did the recommendation built on it.
What changes when the assessment is a team task?
Direct answer: Courses of this shape commonly split assessment between individual work and a later team component, which means the risk shifts from technical skill to consistency. Marks are lost when four people write four sections in four different vocabularies, when the entity names in the diagram do not match the table names in the implementation, and when the assumptions one member made are contradicted by another member's queries. Always confirm the exact structure and weighting of your own assessment in Moodle, because the split changes between terms.
Evidence: Coherence is a documented dimension of data model quality in its own right, alongside correctness and completeness (Moody & Shanks, 2003). A model that different readers interpret differently has failed at the thing the notation exists to do, and a group submission is the easiest place for that failure to appear.
Example: A group of four, three of them Vietnamese students, submitted a report where the diagram said Customer, the schema said Client, and the SQL aliased both as c. Nothing was technically wrong. The marker's comment was that the design was difficult to follow, and difficult to follow is a criterion. Their mentor's fix was a fifteen-minute naming pass before submission, which is now the first thing MAAS mentors ask a database group to do.
How should you work across the term?
Direct answer: Model before you build, and write before you finish. The order that works is: read the scenario twice and highlight every noun that might be an entity and every verb that might be a relationship; list the ambiguities; resolve them in writing; draw the ER model; map it to relations; normalise, recording what each step fixed; implement; then write the queries with their plain-English questions attached. Students who implement first almost always discover a modelling problem too late to fix cheaply.
Evidence: The conceptual-then-logical-then-physical progression is the standard design methodology in the textbooks the course draws on, and it exists because rework cost rises sharply at each stage (Connolly & Begg, 2015). A relationship corrected on paper costs minutes. The same correction after implementation touches the schema, the data and every query built on it.
Example: A student who had been rebuilding his schema for a third time in the final week was asked to stop touching the database and spend an hour on the diagram instead. He found that a single relationship had been modelled backwards from the beginning, which explained all three rebuilds. The hour that felt like a delay was the hour that ended the loop.
Frequently asked questions
Do I need programming experience to do well in COMM2822?
No. SQL is a declarative query language rather than a programming language in the usual sense, and the course is designed for business students. Students who struggle usually struggle with modelling ambiguity, not with syntax.
Is my design wrong if it differs from my classmate's?
Not necessarily. Two defensible models can differ where the scenario is ambiguous. What separates them is whether each one states the assumption that produced the difference and follows it through consistently.
How much of the mark is the diagram versus the SQL?
That varies by term, so read your brief. What is consistent is that the written justification around both is worth more than students expect, and is the part most often left until the last hour.
Should I normalise beyond third normal form?
Only if you can explain why, and only if the scenario justifies it. Going further without a reason invites the question of what problem you were solving, and an answer of thoroughness is not one that earns marks.
What referencing style and word count should I expect?
Confirm both in your own brief, because technical reports vary by term. What is stable is that any design principle you rely on should be attributed, and that a report which is mostly diagrams and code still needs sources for the concepts behind them.
Can MAAS help me with COMM2822?
Yes. MAAS Academic Mentoring coaches you through the assignment with the Outline → Draft → Final model, including scenario decoding, assumption mapping, design review and query-logic checks with mentors from a data background. We coach your work; we do not write it for you.
Ready to approach COMM2822 with a design you can defend?
If your database runs and you still cannot explain why it looks the way it does, that gap is exactly where a mentor is useful. MAAS Academic Mentoring works alongside you through Outline → Draft → Final so the design decisions stay yours and the reasoning behind them becomes visible to a marker. Every engagement is backed by our three-tier outcome guarantee (Pass / Merit / Distinction) and a 90-day warranty.
Bring your COMM2822 brief and we will match you to a data-management mentor, 23% of our 100+ experts hold a PhD, within 48 hours.
Book a free 20-minute COMM2822 consultation with MAAS Academic Mentoring →
Related guides
- COMM1190: why does a correct chart still score in the middle?: the UNSW sibling course on turning analytical output into a decision
- COMM2501: when does data storytelling become data distortion?: on the ethics of persuasive data work once the data is in hand
- How to approach the ISYS3453 Data Analytics assignment at RMIT?: a comparison point from another Australian analytics course
- ACC203 assignment: how do you approach Accounting Information Systems?: systems thinking applied to accounting data
- MAAS Academic Mentoring service: 1:1 coaching with PhD-level mentors in your discipline
- Course-code assignment coaching: pillar guide on tackling any unit assignment with a MAAS mentor
References
- Chen, P. P.-S. (1976). The entity-relationship model: Toward a unified view of data. ACM Transactions on Database Systems, 1(1), 9–36. https://doi.org/10.1145/320434.320440
- Codd, E. F. (1970). A relational model of data for large shared data banks. Communications of the ACM, 13(6), 377–387. https://doi.org/10.1145/362384.362685
- Connolly, T. & Begg, C. (2015). Database systems: A practical approach to design, implementation, and management (6th ed.). Pearson.
- Elmasri, R. & Navathe, S. B. (2016). Fundamentals of database systems (7th ed.). Pearson.
- Kent, W. (1983). A simple guide to five normal forms in relational database theory. Communications of the ACM, 26(2), 120–125. https://doi.org/10.1145/358024.358054
- Moody, D. L. & Shanks, G. G. (2003). Improving the quality of data models: Empirical validation of a quality management framework. Information Systems, 28(6), 619–650. https://doi.org/10.1016/S0306-4379(03)00043-1
Tools & resources
- UNSW Sydney. (n.d.). UNSW Handbook: COMM2822 Introduction to Databases for Business Analytics. Retrieved August 17, 2026, from https://www.handbook.unsw.edu.au/undergraduate/courses/2026/COMM2822
- UNSW Sydney. (n.d.). Referencing and citing. Retrieved August 17, 2026, from https://www.library.unsw.edu.au/study/referencing-and-citation
This article is part of the MAAS Journal series for Vietnamese international students. MAAS Academic Mentoring is an advisory partner; we coach students through the Outline → Draft → Final delivery model with developmental feedback from PhD-level mentors. We do not write or submit work on a student's behalf.