ISYS1055 Database Concepts

How ISYS1055 is assessed

What ISYS1055 covers

ISYS1055 runs as twelve teaching weeks in one straight line: relational foundations (Weeks 1-2), entity-relationship modelling and schema mapping (Weeks 3-4), SQL on SQLite (Weeks 5-8), relational design and normalisation (Weeks 9-10) and NoSQL with MongoDB (Week 11), before a revision week with no new material.

The assessment tracks that arc exactly - Assignment 1 lands after the ER weeks, Assignment 2 after normalisation, the five quizzes fall in the practicals of Weeks 3, 5, 7, 9 and 11, and the Database Design Project closes the course in Week 14. The chapters below follow the same teaching order, so you can read forward with the course or jump straight to the week you are being assessed on.

The five Course Learning Outcomes (CLOs) published on the Canvas welcome page run from describing the theoretical basis of the relational model to developing a sound design and applying SQL to define schemas, update contents and extract data.

The course runs in one straight line: relational foundations and integrity constraints (Weeks 1-2), entity-relationship modelling in UML notation and the seven-step mapping to a relational schema (Weeks 3-4), SQL on SQLite through SQLite Studio (Weeks 5-8, including joins, nested queries, grouped aggregation, views and triggers), relational design and normalisation to 3NF (Weeks 9-10), and document modelling with MongoDB on Atlas (Week 11), before a revision week that presents no new material.

There is no exam in this course. The whole 100% sits in four continuous tasks: Assessment Task 1 Database Design 20%, Assessment Task 2 SQL Programming and Normalisation 30%, Assessment Task 3 in-class quizzes 20% (five online quizzes run inside your practical class in Weeks 3, 5, 7, 9 and 11, stated as 5 x 4 = 20 marks, 4% per quiz), and Assessment Task 4 Database Design Project 30%.

Canvas sometimes calls Assessment Task 4 the "Final Assessment", but the link behind that phrase is the Database Design Project - a take-home build on a publicly available dataset, not a written paper.

Three of the four tasks open with a draft gate roughly two weeks before the final submission, and each gate carries its own penalty wording in the course source, so the cheapest marks in the course are the ones you lose by not submitting a draft. Hurdle requirements: none stated in the course source.

The course is co-taught in the same Canvas shell as the postgraduate ISYS3412, and two of the rubrics print two mark columns - always read the ISYS1055 column.

The toolchain is SQLite Studio for SQL, LucidChart for UML entity-relationship diagrams (free with an RMIT academic account) and MongoDB Atlas plus Compass in Week 11. SQL scope is stated as SQL-92 standard features except for the handling of dates and times, with all activity carried out on SQLite. The result you take out of this course feeds the Grade Point Average (GPA) RMIT reports.

Weights, due windows and submission rules here mirror the Canvas Syllabus for the Semester 2, 2026 offering - confirm the current version on Canvas and in the Course Guide (Part A and Part B).

Worked example · free

AT2 Part A shape: list the FDs, derive the primary key, name the highest normal form, decompose to 3NF

Key terms

Relation (vs table)

A table that also satisfies all five relational rules: every cell holds a single atomic value, each column draws on one domain, column names are unique, row and column order carry no meaning, and no two rows are identical. The course states it as "every relation is a table; every table cannot be a relation". Formally, a relation schema is the name plus the attribute set, e.g. Member(memberID, email, joinDate); the instance is the data held at one point in time.

Primary key, candidate key and foreign key

A candidate key is a minimal set of attributes whose values are unique for every tuple; the one chosen to identify tuples is the primary key (unique, never null), the others are alternate keys. A foreign key is an attribute in one relation whose values must match a primary-key value in the referenced relation, or be wholly null. Key claims rest on the semantics of the data, not on the sample rows: email is unique by definition, a person's name is not.

Entity and referential integrity

The two integrity constraints the relational model enforces alongside the key constraint. Entity integrity: no primary-key attribute may hold a null. Referential integrity: every foreign-key value must already exist in the referenced primary key, or be null - so no child row is left dangling and no parent may be deleted out from under one. In SQLite the referential constraint only fires once PRAGMA foreign_keys = ON is set on the connection.

Multiplicity (min .. max)

The UML notation this course marks against. Multiplicity written at an association end counts how many occurrences of that entity relate to one occurrence of the entity at the other end, as a min .. max pair (1 .. 1, 0 .. 1, 0 .. *, 1 .. N). The maximums give the cardinality (1:1, 1:N, M:N); the minimums give the participation - minimum 1 means mandatory (total) participation, minimum 0 means optional (partial). Both halves come from business rules, never from sample data.

Functional dependency

A one-way constraint between attributes of a relation, written A → B and read as "B is functionally dependent on A" or "A determines B": each value of A is associated with exactly one value of B. A is the determinant, B the dependent. FDs come from the semantics and must hold for all time. A dependency is full when every left-hand attribute is needed, partial when a proper subset of the left already determines the right, and transitive when A → B and B → C. Normalisation is guided entirely by the FD set.

Third normal form (3NF)

A relation is in 3NF when it is in 2NF and no non-key attribute is determined by another non-key attribute. Read the ladder as "the key, the whole key, and nothing but the key": 1NF removes repeating groups and non-atomic values, 2NF removes partial dependencies on part of a composite key (automatic when the key is a single attribute), 3NF removes transitive dependencies. The decomposition recipe is the same each time - move the offending attributes out with a copy of their determinant, make the determinant the new relation's primary key, and leave it behind as a foreign key. This course stops at 3NF; BCNF, 4NF and 5NF are named but out of scope.

ISYS1055 FAQ

Questions students ask in each ISYS1055 chapter

Why does this course use SQLite rather than a big server engine?

SQLite is a very light-weight, single-user, embedded database, it is open source, and it is the most widely deployed database in the world - it ships inside mobile operating systems and countless applications. That makes it installable on a laptop for the practical with no server administration, which matters because you have to bring a laptop to your practical class. The GUI used with it is SQLite Studio. The trade-off is that SQLite relaxes a few standard behaviours, and the course flags those explicitly when they arrive (foreign keys off by default in Week 2, and the GROUP BY deviation in Week 7). Chapter 01 · Databases vs File-Based Storage: What a DBMS Adds

What is the difference between the key constraint and entity integrity?

They protect the two different halves of what a primary key promises. The key constraint enforces uniqueness - no two tuples may carry the same primary-key value - and is implemented by PRIMARY KEY or UNIQUE. Entity integrity enforces non-blankness - no primary-key attribute may hold a null - and is implemented by NOT NULL on every primary-key column. A composite key needs both halves on every participating attribute. Chapter 02 · Relational Model Building Blocks: Keys and Constraints

Which ER notation does ISYS1055 mark against?

UML. The lecture material surveys Chen, Crow's Foot, Barker's and Information Engineering notations so you can recognise them in the wild, but the course labels its own diagrams as its preferred notation and the Week 3 outcome names UML explicitly: class-style entity boxes with attributes listed underneath, {PK} on the key attribute, {Partial Key} on a weak entity's identifier, and multiplicity written as min .. max at each end. Diagrams are drawn in LucidChart, which is free with an RMIT academic account. Submitting Chen diamonds is a notation error, not a style preference. Chapter 03 · ER Modelling in UML Notation: Entities and Multiplicity

How do I know whether something should be an entity or an attribute?

Ask whether it is primary - of direct interest to the enterprise in its own right - and whether it has acquired facts of its own. A supplier's name sitting on a product row is an attribute until the business wants the supplier's contact details, rating and history, at which point it has become an entity and the product simply references it. A multi-valued attribute that keeps growing is the strongest single signal. Chapter 04 · Refining an ER Model: Design Choices and Weak Entities

Why is a 1:1 relationship decided by participation rather than by cardinality?

Because the cardinality is the same on both sides, so it cannot tell you which relation should hold the foreign key. Participation can: if one entity participates mandatorily, every one of its rows will have a value, so putting the key there produces no nulls - which is why the mandatory side is the child and a copy of the optional side's key goes into it. When both sides are mandatory the two entities are effectively one thing and are combined; when both are optional there is no definitive direction and you justify a choice. Chapter 05 · The Seven-Step ER-to-Relational Mapping Process

Why does the course insist on a particular SQL layout?

Because SQL ignores case and whitespace, which means a badly laid-out query is still correct and still unreadable - and unreadable queries are where errors hide. The required format is keywords in capitals, everything else lower case except string literals, and one clause per line. Assessment Task 2 Part B is marked on queries written this way, and it makes a long WHERE clause far easier to debug. Chapter 06 · Single-Table SQL in SQLite: SELECT, WHERE and LIKE

What is the difference between JOIN ... ON and listing tables in FROM with the condition in WHERE?

For an inner join they return the same rows - the comma form is the older style. The difference is safety and readability: with the explicit ON form the join condition sits next to the join it belongs to, whereas in the comma form omitting the condition is not an error, it just silently produces every combination of rows, which on real tables is both wrong and slow. Write the explicit form, and keep filtering conditions in WHERE where they belong. Chapter 07 · Multi-Table SQL: Simple, NATURAL, LEFT OUTER and Self Joins

When should I use a nested query instead of a join?

Use a nested query when the question breaks naturally into an inner sub-problem and the output only needs columns from the outer table - "which galleries hold something on loan" needs gallery columns, so the loan logic can be nested away. Use a join when the result has to show columns from both sides. Many questions can be written either way, and being able to convert between the forms is itself assessable. Chapter 08 · Nested Queries and FROM-Clause Sub-SELECTs

What is the difference between WHERE and HAVING?

WHERE filters individual rows before any grouping happens; HAVING filters whole groups after the aggregate has been computed, and cannot be used without a GROUP BY. If the condition is about a column value, it belongs in WHERE. If it is about a count, sum or average of a group, it belongs in HAVING. Moving a row condition into HAVING quietly changes the answer, which is exactly why the pair is assessed together. Chapter 09 · Grouped Aggregation, Set Operations and Views

How do I decide between BEFORE and AFTER?

Ask what the action depends on. If it depends on the state before the change - logging the value that is about to be replaced, or checking something about the incoming row - the course's pattern is BEFORE. If it depends on the result of the change - recomputing an aggregate from rows that must already have been updated - it has to be AFTER, because the numbers do not exist yet otherwise. The lectorial's own practice set works exactly this way: for each scenario, decide the type and justify it. Chapter 10 · SQL Triggers in SQLite: BEFORE, AFTER and INSTEAD OF

How do I find the functional dependencies in the first place?

From the stated business rules, one rule at a time, asking "given I know this, what else do I know for certain, for all time?" Then prune the list: strike out any FD that is derivable from others (if an identifier determines a supplier and the supplier determines its address, do not also list the identifier determining the address), and strike out any FD that does not really hold. An attribute that turns out to be determined by nothing is a signal that it belongs in the key or in a relation of its own. Chapter 11 · Functional Dependencies and Update Anomalies

If I mapped my schema properly from an ER model, why normalise it at all?

Because not every functional dependency is captured in an ER model. The mapping steps faithfully reproduce the entities, relationships and attributes you drew, but a dependency between two attributes inside one entity - a suburb determining a postcode, a grade determining a rate - was never part of the diagram, so it survives the mapping intact. Validating the mapped relations against 1NF, 2NF and 3NF is cheap insurance, and the course calls this out as the muddiest point worth answering. Chapter 12 · Normalisation to 3NF: Top-Down and Bottom-Up

When is a document database the right choice, and when is it not?

It suits data whose shape genuinely varies between records, data that is read as a whole rather than joined together, and applications whose schema is still moving - which is why the course frames it around agile development. It is a poor choice where the value of the data lies in guaranteed consistency across many related records, because the model relaxes ACID guarantees and delegates validation to the application. This is the Week 11 reflection question, and the honest answer names one application of each kind. Chapter 13 · NoSQL Document Modelling with MongoDB: Schema-Free Design

Is there an exam in ISYS1055?

No. The four continuous tasks sum to exactly 100%: a 20% design assignment, a 30% SQL and normalisation assignment, five in-practical quizzes worth 20% in total and a 30% design project. The phrase that causes confusion is Canvas's label "Final Assessment" for Assessment Task 4, reinforced by a Week 8 syllabus topic row billed as a guide to starting it - but the link resolves to the Database Design Project, a take-home build on a publicly available dataset. There is no paper to sit and no timetabled paper to plan around. Chapter 14 · Assessment Playbook: Draft Gates and the Design Project

How to prepare for the assessments

Treat this course as one continuous build rather than eleven separate topics, because the assessment is continuous too. Set the weekly rhythm the course itself assumes - work through the pre-lecture material and the set reading before the lectorial, take the lectorial and the practical, then revise and revisit the points you could not follow - and protect the practical, because that is where the five quizzes are run.

Install SQLite Studio in Week 1 and open a LucidChart academic account before Week 3; from Week 5 on, never read a query without running it, and never submit one you have not executed against the supplied database. Map your calendar around the two mechanics that actually move marks.

First, the quizzes: they fall in the practicals of Weeks 3, 5, 7, 9 and 11, they are worth 4% each, and the course states that the first four cover the previous two weeks while the last covers the previous ten - so quiz 5 is cumulative and is the one to revise broadly for.

Second, the draft gates: Assessment Task 1's draft at the end of Week 4, Assessment Task 2's at the end of Week 9 and Assessment Task 4's at the end of Week 12, each roughly two weeks ahead of its final, each carrying its own stated deduction for a missing or incomplete submission.

Use the semester break after Week 7 the way the Canvas Syllabus tells you to: review Weeks 1-7 and start Milestone 1 of the Database Design Project, so Part A is under way before the Week 8 walkthrough. For the skills themselves, drill three procedures until they are automatic rather than re-reading slides.

(1) The seven-step ER-to-relational mapping, in order, writing out the partially built schema after every step, because the brief awards nothing to a final schema with no working. (2) Right-hand-side elimination to find a primary key from a functional-dependency set, then the 1NF / 2NF / 3NF verdict with the specific dependency that breaks the next form.

(3) The SQL escalation - single-table conditions, then joins, then a nested query, then grouped aggregation with HAVING - written in the format the course requires, keywords capitalised and one clause per line. Keep everything in the SQL-92-on-SQLite scope the course states, with date and time handling as the one exception it names.

When a step will not click, ask Sia to explain that single step a different way and set you a fresh practice relation or query in the same style; it teaches the method and checks your working, and it never stands in for your own graded submission. Confirm all weights, submission rules, the census date and the special consideration process on Canvas and in the Course Guide (Part A and Part B).

Your AI Information Technology tutor for ISYS1055

Stuck on a hard ISYS1055 question? Sia is AskSia’s AI Information Technology tutor — ask any ISYS1055 Database Concepts question and get a clear, step-by-step explanation grounded in how the course is actually taught and assessed. Read this whole study guide free, then take your hardest questions to Sia.