FIT2094 Databases
The Complete Study & Assessment Guide · S2 2026FIT2094 Overview
- Monash University
- Semester 2, 2026
- Level 2
- Information Technology
FIT2094 Databases develops a complete path from business requirements to a working database. The early weeks explain why organisations use databases and how a conceptual model represents entities, attributes, relationships, cardinality and participation.
- Assessed by Two class tests worth 15% each and two artefact groups worth 35% each
- Design chain Requirements to conceptual model to normalisation to logical model to Oracle schema
- Query method State the result grain, build the row set, then test boundary cases
- Submission priority Keep models, dependencies, constraints, schema output and development history consistent
What you get in the full FIT2094 Study & Assessment Guide
- 8 chapters, 37 pages — every assessed topic, week by week
- 18 original practice questions, each with a model answer
- 8 worked examples, solved the way FIT2094 marks
- 12 computed figures, redrawn from the course’s own numbers
- Before-you-submit checklist for the 2 - Artefact (35%) — what markers reward, what costs marks
Free on this page: assessment table, chapter map, one worked example, key terms, FAQ. The rest is in the full study & assessment guide.
How FIT2094 is assessed
| Component | Weight | Format |
|---|---|---|
| 1 - Quiz / Test | 15% | Class Test 1: Database Design. Individual and on campus during the allocated workshop. Published coverage is conceptual modelling, relational algebra and normalisation. |
| 2 - Artefact | 35% | Applied Tasks 3 to 7 plus Assignment 1: Database Design. The package covers a conceptual model, normalisation, a logical model, an Oracle schema and development history. Applied Task 3 must receive a pass before Assignment 1 submission becomes available. |
| 3 - Quiz / Test | 15% | Class Test 2: SQL Queries and Transactions. Individual and on campus during the allocated workshop. Published coverage is transactions, basic SQL and intermediate SQL. |
| 4 - Artefact | 35% | Applied Tasks 8 to 12 plus Assignment 2: Creating, Populating and Manipulating Databases. The published task covers Oracle implementation, data changes, transactions, relational queries and MongoDB queries. |
The four official rows total 100%. The Monash Handbook and the Semester 2 Moodle assessment structure agree on the weights. The AT3 pass condition controls access to Assignment 1, but the Handbook does not label the complete 35% artefact group as a hurdle. The class-test pages publish coverage and delivery, not a question count or per-question mark split.
What other students are asking about FIT2094
- Where can I find lecture notes or study guides for FIT2094 at Monash?
- The FIT2094 study guide in AskSia Library covers Databases in 8 chapters, with the assessment table, a chapter-by-chapter topic map, key terms and a worked example, free to read on this page.
- Is there a final exam in FIT2094?
- No final exam is listed in the offering this AskSia Library guide is built from; FIT2094 is assessed by 1 - Quiz / Test 15%, 2 - Artefact 35%, 3 - Quiz / Test 15%, 4 - Artefact 35%.
- What does FIT2094 cover on relational models, keys and algebra?
- In AskSia Library's FIT2094 guide, the Relational Models, Keys and Algebra chapter explains week 3: relations, candidate and foreign keys, entity and referential integrity, insert, update and delete anomalies, and relational algebra.
- What does FIT2094 cover on normalisation from unf to 3nf?
- In AskSia Library's FIT2094 guide, the Normalisation from UNF to 3NF chapter explains week 4: repeating groups, candidate keys, full, partial and transitive dependencies, dependency diagrams, and the complete UNF to 3NF method.
- What does FIT2094 cover on logical models and database definition?
- In AskSia Library's FIT2094 guide, the Logical Models and Database Definition chapter explains weeks 5 and 6: ER to relational mapping, logical modelling, Oracle data types, CREATE TABLE, ALTER, DROP and foreign-key constraints.
Current FIT2094 dates
| Date | Item | Control |
|---|---|---|
| 4 September 2026 | Class Test 1 | 15%, Database Design during the allocated workshop |
| 16 September 2026 | Assignment 1 | Part of the first 35% artefact group |
| 23 October 2026 | Class Test 2 | 15%, SQL Queries and Transactions during the allocated workshop |
| 2 November 2026 | Assignment 2 | Part of the second 35% artefact group |
Dates are as published in the Semester 2, 2026 Monash Moodle schedule. Confirm exact deadlines and submission settings in the live LMS.
What FIT2094 covers
Follow the unit from conceptual modelling and relational theory through normalisation, Oracle implementation, SQL, NoSQL, warehousing and responsible data use.
Database Foundations and Conceptual Models
Weeks 1 and 2: database purpose, database types, entities, attributes, relationships, cardinality, participation, strong and weak entities, and conceptual diagrams.Database foundations and conceptual modelling connect an information problem to a defensible representation of the domain.
- Why organisations use managed databases instead of repeated files
- Entities, attributes and independently maintained identity
- Relationships, roles and associative entities
- Maximum cardinality and minimum participation
- Strong entities, weak entities and identifying relationships
- Reading an ER diagram back into business-rule sentences
Relational Models, Keys and Algebra
Week 3: relations, candidate and foreign keys, entity and referential integrity, insert, update and delete anomalies, and relational algebra.The relational model represents facts as tuples in relations and protects meaning through keys and integrity constraints. Candidate keys are minimal attribute sets that uniquely identify tuples.
- Relations, tuples, attributes and domains
- Candidate keys, primary keys and alternate uniqueness
- Foreign keys, entity integrity and referential integrity
- Insert, update and delete anomalies as mixed-fact symptoms
- Selection and projection in relational algebra
- Joins and compatible set operations
Normalisation from UNF to 3NF
Week 4: repeating groups, candidate keys, full, partial and transitive dependencies, dependency diagrams, and the complete UNF to 3NF method.Normalisation restructures data around functional dependencies so that each fact is stored under the key that determines it. The required method begins with an unnormalised relation that faithfully represents the source document.
- Functional dependencies and determinants
- Repeating groups and unnormalised form
- Atomic rows and candidate keys in first normal form
- Partial dependencies and second normal form
- Transitive dependencies and third normal form
- Dependency diagrams and relation decomposition
Logical Models and Database Definition
Weeks 5 and 6: ER to relational mapping, logical modelling, Oracle data types, CREATE TABLE, ALTER, DROP and foreign-key constraints.Logical modelling maps conceptual meaning and normalised relations into a design suitable for an RDBMS.
- Mapping strong and weak entities to relations
- Mapping one-to-many and many-to-many relationships
- Primary keys, alternate keys and surrogate-key justification
- Oracle data types and column nullability
- CREATE TABLE, ALTER and DROP
- Foreign keys, checks and attribute comments
DML, Transactions and Locking
Week 7: INSERT, UPDATE, DELETE, Oracle sequences, transaction properties, transaction boundaries, serialisation and locking.Data manipulation and transaction management turn a specification into a controlled state change. INSERT creates rows, UPDATE changes existing rows and DELETE removes rows.
- Translating a change specification into target rows
- INSERT, UPDATE and DELETE operations
- Oracle sequences and generated identifiers
- Atomicity, consistency, isolation and durability
- Transaction boundaries, commit, rollback and savepoints
- Locking, serialisation and stale-read windows
SQL Selection, Joins and Aggregation
Weeks 8 and 9: SELECT, row conditions, aliases, dates, ordering, ANSI joins, aggregates, GROUP BY, HAVING and subqueries.SQL querying begins by defining what one result row represents.
- SELECT expressions, aliases and ordering
- Row conditions, null tests and date boundaries
- ANSI inner joins and relationship grain
- Outer joins and preservation of unmatched rows
- SUM, AVG and COUNT semantics
- GROUP BY and aggregate conditions in HAVING
Advanced SQL and Query Optimisation
Week 10: set operators, views, outer and recursive joins, multiple relationship joins, built-in functions and query optimisation.Advanced SQL adds set operators, views, outer and recursive joins, multiple relationship roles and built-in functions. Each construct has a row-preservation rule.
- UNION, INTERSECT and difference semantics
- Column compatibility and duplicate preservation
- Views as named query boundaries
- Outer joins, self-joins and multiple relationship roles
- Built-in functions and implicit conversion risks
- Relational algebra and equivalent query rewrites
NoSQL, Warehousing and Responsible Data
Weeks 11 and 12: non-relational data, MongoDB mapping, operational and decision-support data, warehouses, business intelligence, privacy and ethics.Later database topics compare relational and non-relational structures, operational and decision-support data, and technical possibility with responsible use.
- Relational and non-relational model trade-offs
- Document embedding, referencing and aggregate boundaries
- Operational data and decision-support data
- Data warehouses, integrated history and lineage
- Business intelligence measures and interpretation
- Privacy, access control and data minimisation
Relational theory then makes identity and integrity precise through candidate keys, foreign keys and constraints.
Normalisation uses functional dependencies to remove insert, update and delete anomalies before the design is mapped into a logical model and implemented in Oracle.
The implementation half covers creating and altering tables, inserting, changing and deleting rows, using sequences, defining transaction boundaries and reasoning about serialisation and locking in a multiuser environment.
SQL begins with single-table selection, conditions, aliases, date handling and ordering, then expands into ANSI joins, aggregate functions, grouping, HAVING, subqueries, set operators, views, complex joins and query optimisation. The closing topics connect non-relational data and MongoDB with operational data, warehouses, business intelligence, privacy and legal or ethical judgement.
The unit rewards visible reasoning.
A convincing model states the business rule behind each key and cardinality. A convincing normalisation shows every stage and the dependency that forces each decomposition. A convincing schema preserves candidate keys, references, nullability and domains. A convincing query states what one result row represents and tests a boundary case.
The guide therefore treats every answer as a chain from requirement to representation to verification.
Worked example · free
Normalise a booking record and preserve its rule
- +1Represent the source as BOOKING_UNF(booking_no, booking_date, client_no, client_name, {room_no, room_name, hours}) so the repeating group remains visible before transformation.
- +2Create one row per booked room in 1NF. The candidate key is (booking_no, room_no). State booking_no to booking_date and client_no, room_no to room_name, and the full pair to hours.
- +2Remove the partial dependencies for 2NF: BOOKING(booking_no, booking_date, client_no), ROOM(room_no, room_name), and BOOKING_ROOM(booking_no, room_no, hours).
- +2Remove the transitive dependency client_no to client_name for 3NF by creating CLIENT(client_no, client_name) and retaining client_no as a foreign key in BOOKING.
- +1Verify a lossless reconstruction by joining CLIENT, BOOKING, BOOKING_ROOM and ROOM, then test that the same room may appear on different bookings without duplicating one booking-room pair.
Key terms
- Candidate key
- A minimal attribute set that uniquely identifies each tuple in a relation. Every candidate key remains a business rule even when another key is chosen as primary.
- Referential integrity
- The rule that a foreign-key value must match an existing candidate key in the referenced relation, unless the relationship permits a null value.
- Functional dependency
- A constraint in which one attribute set determines another under the business rules. Dependencies guide candidate-key analysis and normalisation.
- Third normal form
- A relation state in which non-key attributes depend directly on a key, with partial and transitive dependencies removed after the earlier normal forms are satisfied.
- Transaction boundary
- The start and end of one logical unit of work whose related changes should commit together or roll back together.
- Relational algebra
- A formal collection of relation operators such as selection, projection, join and difference that describes how result sets are derived.
- Query grain
- What one row in a query result represents, such as one customer, booking or category. Declaring the grain helps prevent join duplication and incorrect aggregation.
- Outer join
- A join that preserves unmatched rows from a selected side while supplying null values for missing matches. Filter placement determines whether that preservation survives.
- Data warehouse
- An integrated historical store designed for decision support, shared definitions and analytical access rather than day-to-day transaction processing.
- Document database
- A non-relational database model that stores aggregate-shaped documents with flexible nested fields. Embedding and referencing choices follow ownership and update patterns.
FIT2094 FAQ
How is the unit assessed?
The published structure has four groups: Class Test 1 at 15%, Artefact 2 at 35%, Class Test 2 at 15%, and Artefact 4 at 35%. The two artefact groups combine supporting applied tasks with the larger database design and implementation assignments. The four numeric rows sum to 100%.
What does the first class test cover?
The Moodle assessment page names conceptual modelling, relational algebra and normalisation. Prepare by converting prose into entities and relationships, identifying keys and integrity rules, writing algebra as named intermediate relations, and showing the full dependency path from UNF to 3NF.
Why does Applied Task 3 matter before Assignment 1?
The current assessment page says Applied Task 3 must be submitted and receive a pass before Assignment 1 can be submitted. Complete the conceptual-model prerequisite early, confirm that submission access is available, and keep developing the full design rather than treating the supporting task as a separate exercise.
What normalisation method should I use?
Begin with one UNF relation that represents the supplied document, convert to atomic 1NF rows, state every candidate key, remove partial dependencies for 2NF, then remove transitive dependencies for 3NF. Keep every source attribute, show each dependency and avoid adding a surrogate key during the formal normalisation stage.
How should I practise SQL for the second class test?
State the result grain, build the FROM and JOIN row set, apply row conditions in WHERE, form groups, apply aggregate conditions in HAVING and shape the final output. Test nulls, date boundaries, unmatched rows and duplicate-producing joins. The published coverage names transactions, basic SQL and intermediate SQL.
How can I match practice to the published coverage?
Build original problems around the named skills: conceptual modelling, relational algebra and normalisation for the first class test, then transactions, basic SQL and intermediate SQL for the second. Do not assume a question count or per-question mark allocation that the current assessment pages do not publish.
Is this an official Monash resource?
No. This is an independent AskSia-authored study guide that uses the unit code and name for identification. Check current task instructions, submission settings and operational updates in Monash Moodle before acting on a deadline or assessment requirement.
Questions students ask in each FIT2094 chapter
- How do I decide whether a noun should become an entity?
- Ask whether instances require independent identity, retained facts and a lifecycle. A word that merely describes another entity is usually an attribute. A verb that links roles is usually a relationship. If a repeated pairing has its own facts, it often deserves an associative entity. Chapter 01 · Database Foundations and Conceptual Models
- Why should alternate candidate keys still be constrained?
- Choosing one candidate key as primary does not make the other real-world identities disappear. Without uniqueness on an alternate key, different rows can represent the same business instance under different surrogate values. Preserve every source-backed candidate key. Chapter 02 · Relational Models, Keys and Algebra
- Why must I show every normal form?
- The transformation demonstrates which dependency caused each decomposition. Jumping directly to final relations hides candidate-key analysis and makes it impossible to verify whether attributes were lost, added or assigned to the wrong determinant. Chapter 03 · Normalisation from UNF to 3NF
- How does a conceptual model become a logical model?
- Map entities to relations, identifiers to candidate keys and relationships according to cardinality. Place foreign keys on the many side, create associative relations for many-to-many cases and integrate every relation discovered through normalisation. Chapter 04 · Logical Models and Database Definition
- How do I make an UPDATE safer?
- Preview the exact predicate with SELECT, compare the candidate count with the requirement, include the current-state precondition where relevant and inspect the affected-row count. Verify changed and unchanged rows before committing. Chapter 05 · DML, Transactions and Locking
- What is the difference between WHERE and HAVING?
- WHERE filters individual rows before groups are formed. HAVING filters grouped results after aggregation. Put status and date conditions in WHERE, and put thresholds such as COUNT greater than a value in HAVING. Chapter 06 · SQL Selection, Joins and Aggregation
- When should I use UNION instead of UNION ALL?
- Use UNION when the required result is unique membership across either set. Use UNION ALL when repeated rows are meaningful or will be handled deliberately later. Test a value present in both inputs to expose the difference. Chapter 07 · Advanced SQL and Query Optimisation
- When is embedding a good document-model choice?
- Embed when nested values belong to one parent, share its lifecycle, remain bounded and are usually created or read together. Reference when the related record changes independently, is reused or needs separate access and identity. Chapter 08 · NoSQL, Warehousing and Responsible Data
How to prepare for the assessments
Revise FIT2094 as one transformation chain. Start with a fresh scenario and write its business rules in plain language. Build a conceptual model, read every relationship in both directions and challenge each proposed key with a legitimate duplicate. Convert the design to relations, write the functional dependencies and complete normalisation without skipping stages.
Map the result into a logical model that preserves alternate keys, references, optionality and domains, then generate and test the Oracle schema. For SQL, declare what one result row represents before writing clauses, predict a positive and negative example, and include null, date-boundary and duplicate cases.
For transaction questions, name the invariant, place all related changes inside one boundary and verify it before commit. End each practice session by tracing one rule across the model, schema, data-changing statement and query result. This exposes inconsistent names or missing constraints earlier than rereading notes.
For the first artefact, use the published checklist as a negative test and open the exact submitted files in a clean location. For the later material, compare relational and document choices through access pattern, update pattern and governance risk rather than declaring one model universally better.
