COMM2822 Databases for Business Analytics: what gets marked?

Direct answer: COMM2822 Databases for Business Analytics (full title Introduction to Databases for Business Analytics) is a 6 unit of credit undergraduate course in the UNSW Business School, run by the School of Information Systems and Technology Management. The 2026 handbook describes business databases, SQL and the principles and characteristics of Big Data, with offerings in Term 1 and Term 2.

The handbook says students "will learn the Structured Query Language (SQL) language and how to use it to access data stored in relational database system, including fetch, delete, insert, and modify data" (UNSW Sydney, n.d.). The same entry sets five course learning outcomes (CLOs), running from conceptual and relational modelling methods in CLO1 to the ethical, privacy and security implications of Big Data in CLO5. Because CLO2 asks you to "Design, implement and evaluate database systems" (UNSW Sydney, n.d.), the word evaluate tells you that justifying your own design is part of the task.

The code history matters for enrolment. COMM2822 was previously COMM1822, and students who completed COMM1822 cannot enrol in the newer code, so check your own record before you search for old notes. Readers who want the language itself can start with the SQL overview, and the data side of CLO5 is covered by the Big data article. Assessment tasks, weights and dates change between terms, so take them from your Moodle course outline and not from a blog post.

Direct answer: Your course outline sets the tasks, weights and dates for your term, so confirm them there. Published error data shows where ER marks leak: Rashkovits and Lavy (2021) found that 88% of 65 students missed the weak entity and 83% missed the reflexive relationship, while basic entities and keys went mostly well.

Rashkovits and Lavy (2021) mapped the errors in their study of final-exam diagrams, and their abstract states that "novice designers encounter difficulties in understanding and implementing such models" (Rashkovits & Lavy, 2021). The difficulty is uneven. The simple constructs mostly went well: 45 students (70%) drew every strong entity, 48 (75%) got all binary relationships, 50 (79%) gave complete attributes and 54 (84%) chose correct keys.

Source: Rashkovits and Lavy (2021), final-exam ERD task, 65 students.

Only 11 students (17%) handled the reflexive relationship and 13 (20%) the ternary one, and 32 replaced a ternary relationship with two binary ones, which loses the fact that three things take part at once. Another 20 students (31%) added entities the scenario never asked for, and 17 of them added "Movie Series". Expect to lose marks on relationships the scenario implies without naming, not on drawing boxes. The entity-relationship model article lists these constructs.

Direct answer: Read the scenario for nouns that need a table and verbs that link them, decide each cardinality, and write the assumption behind it. Turn every many-to-many link into its own table, then name the anomaly each split removes.

The second gap is a worked ambiguity with its decisions on record. Take one sentence from an imagined scenario: "Each product is bought from one supplier." In Design A, the Product table holds a supplier_id, so one Supplier relates to many Products. In Design B, a separate Supply table links Product and Supplier with a start date and a unit cost, so a product can change supplier over time. Ask the manager's question, "what did we pay Supplier X for product P last March?" Design A cannot answer it once the supplier has changed, while Design B can, at the price of one extra table and one extra join. Neither design is wrong; the marks go to the report that states its assumption next to the diagram. This example is an illustration written by MAAS, not a UNSW case study.

Database normalization is where explaining wins marks. Kent (1983) states that "The normalization rules are designed to prevent update anomalies and data inconsistencies" (Kent, 1983). His example stores WAREHOUSE-ADDRESS in a record keyed on PART and WAREHOUSE, which causes 4 problems: the address repeats, every copy must change when it moves, copies can disagree, and an empty warehouse has nowhere to keep it. He adds that "There is no obligation to fully normalize all records when actual performance requirements are taken into account" (Kent, 1983), so say why if you stop at third normal form.

Direct answer: Write the business question as one plain sentence above each query, then run the query on a table you can count by hand. Ahadi et al. (2016) found that most semantic mistakes are omissions in queries needing a JOIN, a subquery or a GROUP BY, so test those queries first.

Ahadi et al. (2016) studied more than 160,000 query snapshots from over 2300 students across nine years and report that "the majority of semantic mistakes are of the type 'omission'" (Ahadi et al., 2016). Taipalus et al. (2018) analysed more than 33,000 queries from 237 students and sorted the errors and complications into 18 categories, numbered up to 105. About 59% of 158 students used an erroneous GROUP BY on one exercise, a query SQLite accepts without complaint, and about 45% of 152 students failed to use DISTINCT where it was needed on another. Brass and Goldberg (2006) compiled a list of semantic errors in SQL queries, the kind a database does not report. The errors that cost marks are the ones the database does not report.

A five-query test of join and COUNT

The third gap is a test showing the wrong results. MAAS built 3 products (Desk, Lamp, Chair) and 3 order lines in SQLite, where Chair was never ordered, and asked "how many order lines does each product have?" Five versions of the query gave five different results, and only the third matches the sentence.

Source: MAAS test with 3-row product and order_line tables in SQLite, run 2026-10-27. Re-run it on Oracle SQL.

COUNT of a column skips the null that the left join creates, and COUNT(*) does not, which is why Chair shows 1 in the second row. A WHERE filter removes the unmatched row again, so put the condition in the ON clause. The null value article explains why. For another university's database marking, see the INFO20003 Database Systems guide.

Direct answer: Three assumptions are worth testing: that public data is free to use, that security belongs to the IT team, and that Big Data is neutral. CLO5 asks you to discuss ethical, privacy and security implications, so your report needs concrete design consequences, not a generic paragraph on ethics.

UNSW teaches in Australia, so the Privacy Act 1988 is the natural reference for a local scenario. On the first assumption, the Office of the Australian Information Commissioner (OAIC) states that "Where personal information is publicly available on the internet, that does not allow it to be collected and used in whatever way the APP entity chooses without regard to the knowledge and reasonable expectations of the person whose information it concerns" (OAIC, 2026). On the second, choices about columns, access roles and deletion are security measures, so describe them.

On the third, boyd and Crawford (2012) offer six provocations and argue that "it is necessary to critically interrogate its assumptions and biases" (boyd & Crawford, 2012). Say what your dataset leaves out. This is general information, not legal advice; the COMM3050 guide covers misuse.

Source: OAIC (2026) guideline chapter 3 and boyd and Crawford (2012), read 2026-10-27.