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 course does not assess whether your database functions; it assesses whether the design decisions behind it can be defended against the business description, and whether your queries answer the question actually asked.
Author: MAAS Editorial Team · Reviewed by a MAAS subject mentor
Last updated: 2026-08-17
Category: communication-pr
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 through the School of Information Systems and Technology Management, covering business databases, the characteristics of Big Data, and SQL, with entity relationship modelling and normalisation as the core methods. It is a foundation course for the analytics side of a business degree.
Evidence: The course has five published learning outcomes, and the first three run in a deliberate sequence: create and apply conceptual and relational database modelling methods, then design, implement and evaluate database systems, then access and manipulate a relational database using SQL. The verb in the second 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. The remaining two outcomes cover working effectively in a team and the ethical, privacy and security implications of Big Data, and both are easy to forget precisely because they sit at the end of the list.
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: Chen introduced the entity-relationship approach as a way of representing a view of the real world in a form that could be discussed and agreed before implementation, on the premise that "the entity-relationship model adopts the more natural view that the real world consists of entities and relationships" (Chen, 1976, p. 9). 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.
Chen's 1976 paper was itself a reaction against the two models that dominated commercial databases before it, the hierarchical model behind IBM's Information Management System, first shipped in 1968, and the network model formalised by CODASYL in 1969. Both forced a fixed access path into the data. Codd's relational model, and Chen's diagramming approach on top of it, let the modeller describe the business first and defer the access path to the query, which is the entire reason COMM2822 can ask you to justify a design before writing a single line of SQL against it. Chen's notation also predates the class diagram now standard in software engineering, which the Object Management Group folded into UML in 1997. If a tutor sketches a design using boxes and lines that look slightly different from what your textbook shows, it is usually a UML variant of the same underlying idea rather than a competing method.
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.
Third normal form is not even the strictest option. Boyce and Codd introduced a stricter form in 1974, now taught as Boyce-Codd Normal Form, precisely to close anomaly cases 3NF leaves open when a table has more than one candidate key. Most COMM2822 assignments never need to go that far, but a marker who sees you name the option and explain why you stopped at 3NF is reading a stronger justification than one who sees 3NF asserted as if it were the ceiling.
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.
The same modelling failures recur in database subjects at other universities, and the pattern is documented in our guide to INFO20003 Database Systems at Melbourne, where the published research on novice ER errors is set out in detail.
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.
SQL's own standardisation history is why the syntax you learn here transfers. Oracle shipped the first commercial system built on Codd's model in 1979, ANSI adopted SQL as a national standard in 1986, and ISO adopted the equivalent standard the following year, which is why a SELECT statement behaves the same way whether you run it in this course's database engine, in PostgreSQL or in SQL Server on your own laptop. The join and filter logic is standard; the mistakes described above come from reasoning about the business, not from the dialect.
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.
The fifth learning outcome, ethical, privacy and security implications, is not decorative either. Two dates are worth knowing regardless of where you studied before. The European Union's General Data Protection Regulation took effect in 2018 and reshaped how organisations worldwide are expected to justify why they hold personal data, and SQL injection, a vulnerability that comes directly from building queries by concatenating user input, has appeared on the OWASP Top 10 list of web application risks in every edition since OWASP was founded in 2001. A schema that models personal data without a stated retention or access rationale, or a query built by string concatenation, fails this outcome even if the modelling elsewhere is strong.
The Big Data half of the course description also has a traceable origin. The three-part framing of volume, velocity and variety that most Big Data slides still use was coined by the analyst Doug Laney in a 2001 research note, more than a decade before the phrase Big Data became common. It is worth knowing the framing came from industry analysis rather than from a peer-reviewed database paper, because it explains why the course treats it as context rather than as a technique with the same rigour as normalisation. NoSQL systems built to handle that volume and velocity, MongoDB launched in 2009 and Apache Cassandra was open-sourced by Facebook a year earlier, in 2008, deliberately relax the normalisation rules this course teaches, which is why a document store answer to a relational modelling question is marked as a misunderstanding of the brief rather than as a valid alternative.
Evidence: Working effectively as a team is a named learning outcome of this course, not an incidental feature of how the assessment happens to be organised. Coherence is also 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.
Does the course cover Big Data as well as relational databases?
Yes. Big Data principles and characteristics are named in the course description, and the ethical, privacy and security implications of Big Data are one of the five learning outcomes. A guide that treats the course as relational databases alone is describing only part of it.
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 Support 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 Support 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 sets a three-tier target grade with you at the start (Pass, Merit or Distinction) and 90 days of follow-up support after submission.
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(02)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.). UNSW Library. Retrieved August 17, 2026, from https://www.library.unsw.edu.au
This article is part of the MAAS Journal series for Vietnamese international students. MAAS Academic Support 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.