IS5413 Database Management Systems

How IS5413 is assessed

The weights above are those published in the course introduction materials for this offering: a 70 per cent examination and a 30 per cent group project divided into three equal 10 per cent components. The project brief for Semester A, 2026/27 sets the progress report at Friday of week seven, the final report and working prototype at Thursday of week twelve, and the group demonstration at within five minutes in weeks twelve to thirteen. The introduction slides still show an earlier offering's ten minute demonstration and its March and April deadlines, so take deadlines from Canvas. Weekly tutorial exercises are submitted on Canvas from week two to week ten, and the week two item shows a points value of zero; confirm there how they are recorded, and check Canvas and the departmental course syllabus for any pass requirement beyond these weights.

Current IS5413 dates

Dates are as published in the current course schedule and the reminder notice issued to new students. Confirm exact deadlines and submission settings in the live LMS.

What IS5413 covers

Eleven chapters follow the published sequence from the database environment through entity relationship modelling and normalisation to structured query language and delivery architecture.

Across the semester you learn to read a business description, turn it into an entity relationship diagram, convert that diagram into relations with keys, write out the functional dependencies those relations carry, and normalise them to third normal form, then implement and query the result in structured query language.

The examination and the group project both ask for that same chain, which is why this guide is organised around it rather than around the topic list.

How the assessment splits

Seventy per cent of the grade is a two hour closed book examination covering lecture material, database design principles, structured query language and practical knowledge, with questions that require application rather than recall.

The remaining thirty per cent is a group project completed by a team of four to five students, assessed in three equal parts: a conceptual design report, a working system with a live demonstration, and a final report.

The project brief for this offering asks the team to choose a topic from its own interests or working life, follow a database development life cycle, and produce an extended entity relationship schema, a logical schema with functional dependencies shown and third normal form demonstrated, considered denormalisation with data types and indexes chosen, and an implemented database with ten useful queries built around the select statement.

The chapters, and why they are in this order

The first two chapters set the environment: what data, information, metadata and a management system are, why file processing was abandoned, and where database work sits inside a systems project.

Chapters three to five build the conceptual model, moving from entity types and attributes through relationship degree and cardinality to supertypes and subtypes. Chapters six and seven are the conversion and validation pair that most of the marks depend on.

Chapter eight makes the result efficient, chapters nine and ten make it answerable, and chapter eleven delivers it through an application architecture.

Where students lose marks, and it is not where they expect

Three leaks account for most of the loss on the design question.

The first is an unnamed assumption: the narrative in a design question is deliberately incomplete, and a stated assumption is credited while a silent choice is indistinguishable from an error. The second is a many to many relationship left as a line on the diagram instead of becoming a relation.

The third, and the largest, is a functional dependency list that simply restates the schema rather than showing what determines what, which makes the normalisation step impossible for a marker to verify.

Each of those is a habit rather than a piece of knowledge, which is why this guide drills the artefact rather than the definition.

Software and vocabulary

The lab work uses relational database management tools, with the course materials naming Microsoft SQL Server for the advanced laboratories and project implementation and also naming Microsoft Access alongside it in the tutorial schedule.

Statement syntax in the lecture material follows an Oracle style, including variable length character types and a system date default, while the laboratory environment is SQL Server; the grammar you are examined on is standard to both, but if a statement fails in the laboratory, check the dialect before checking your logic.

The learning platform is Canvas, and the assessment materials use the word course rather than unit or subject.

How to use this guide

Work the chapters in order once, then work chapters six and seven again. Carry one small scenario of your own, four to six entity types, through every chapter, so that by the time the normalisation chapter asks for a transitive dependency you already have one to point at.

Produce every practice artefact on paper before reading the answer. Confirm every operational detail, deadlines, submission settings, demonstration length and the examination timetable, on Canvas, because several slide decks in circulation still carry the dates of an earlier offering.

Worked example · free

Take one narrative through all four deliverables

Key terms

Database

A managed store of data whose items are related to one another and held for one stated business purpose. The word logically is doing the work: a folder of files is a collection but not a database.

Metadata

A description of another item of data, covering its type, its length, the values it may take and the unit that owns it. It is what lets two applications agree on what a field means.

Entity Type

A named group of similarly described things, which becomes a table in the eventual schema. Distinguish it from an entity instance, which is a single occurrence and becomes a row.

Cardinality Constraint

The pair of facts recorded at one end of a relationship: the minimum number of instances that must participate and the maximum that may. The two are decided separately.

Associative Entity

A construct that is both a relationship and an entity type, used when a many to many association carries attributes of its own or deserves an identifier.

Supertype

A generic entity type holding the attributes and relationships shared by one or more specialised subtypes beneath it. Membership of a subtype carries membership of the parent with it.

Subtype Discriminator

A parent attribute whose value says which child a given member falls into. It is simple under the disjoint rule and composite under the overlap rule.

Referential Integrity

The rule that a foreign key must point at a primary key value that exists in the related table, unless it is left empty where that is allowed.

Functional Dependency

A constraint under which knowing one attribute, the determinant, settles what another must be. The dependency set is the input to normalisation.

Transitive Dependency

A dependency in which a non key attribute determines another non key attribute. Removing every one of them is what takes a relation from second to third normal form.

Denormalisation

The deliberate transformation of normalised relations into non normalised physical records, trading integrity risk for fewer joins. A physical design decision, never a logical one.

Three Schema Architecture

The separation of many external user views from one conceptual schema and one internal storage schema. The single middle layer is what makes the two outer layers independent.

IS5413 FAQ

Questions students ask in each IS5413 chapter

What is the difference between data and information?

Data are the stored representations themselves; information is what they become once processed and placed in context so that somebody's knowledge increases. The examinable consequence is that the same stored values are data or information depending on what surrounds them, which is why metadata is treated as a separate idea rather than as a kind of data. A short question here usually supplies a table and asks you to say which is which, and the answer turns on whether the context needed to interpret the values is present. Chapter 01 · Data, Metadata and the Database Environment

When does conceptual data modelling actually start?

It starts in the planning phase as enterprise modelling, at a high level and without attribute detail, and becomes thorough in the analysis phase once functional specifications exist. Saying that it starts in analysis is the common half answer; saying it starts in design is wrong, because by design the model is already being converted. The distinction matters because it tells you what input each version of the model had available. Chapter 02 · The Database Development Process and Schema Levels

How do I tell an entity type from an attribute?

Ask whether the thing has many instances and multiple properties the business cares about. Something with exactly one property of its own is usually an attribute of something else, and something the business describes with several facts is usually an entity type. The honest answer is that borderline cases exist and both readings can be correct; what loses marks is choosing without saying so, since a stated assumption is credited and a silent one reads as an error. Chapter 03 · Entity Types and Attributes in ER Modelling

How do I read cardinality on a ternary relationship?

Fix two of the three entity types and ask how many instances of the third the business rule permits, then repeat for each leg. Reading all three at once produces confusion, because the rules are stated one leg at a time in the narrative as well. Write down each leg's answer before moving on, since the second leg often sounds like a restatement of the first until the fixed pair is named explicitly. Chapter 04 · Relationship Degree and Cardinality Constraints

What is the difference between completeness and disjointness?

Completeness asks whether every parent instance reaches a child; disjointness asks whether one parent instance can reach two children. They are independent, so a hierarchy can be total and overlapping, total and disjoint, partial and overlapping, or partial and disjoint. Because neither implies the other, a correct diagram carries both marks, and a question giving you one of them is not giving you the other. Chapter 05 · Supertypes and Subtypes in the Enhanced ER Model

Where does the foreign key go in a one to one relationship?

On the side whose participation is optional, carrying the key of the side whose participation is compulsory. Putting it on the mandatory side would force every row there to hold a value that may not exist, producing a column full of nulls in a place where nulls should not be. When both sides are mandatory or both optional the choice is genuinely open, and a stated reason is what earns the mark. Chapter 06 · Mapping an Enhanced ER Diagram to Relations

How do I know when to stop normalising?

The course states that third normal form is generally considered sufficient, and the group project brief asks for third normal form specifically. Boyce Codd, fourth and fifth normal form exist above it and address anomalies arising from multiple candidate keys and from multivalued dependencies. Unless a question supplies a reason to go further, reaching third normal form and saying that you have is the complete answer. Chapter 07 · Functional Dependencies and Normal Forms

When is an index not worth creating?

When the table is small enough to scan faster than it can be looked up, when the field holds very few distinct values, when the values are long, or when the field is frequently null and the system will not match nulls through an index. The selectivity rule is the one most often forgotten: the published guidance puts the useful band above roughly a hundred distinct values and warns against fewer than thirty, because below that an index adds maintenance cost without narrowing the search much. Chapter 08 · Physical Design with File Organisation and Indexes

What is the difference between deleting rows and dropping a table?

Deleting removes rows while the table, its constraints and its indexes survive, so referential integrity rules still apply and a row referred to elsewhere may be refused. Dropping removes the table definition itself and takes every row, constraint and index with it. The pair is a favourite short question because the two words feel interchangeable in English and are not in this language. Chapter 09 · SQL for Defining Tables and Querying One Table

How many join conditions should a four table query have?

Three, one for each link in the diagram, which is the number of tables minus one. More than that means a relationship has been invented; fewer means a table has been left unjoined, and the consequence of that is not an error message but a result containing every combination of the unjoined table's rows. Counting conditions against tables takes two seconds and catches both faults. Chapter 10 · Joins, Subqueries and Transaction Control in SQL

What actually distinguishes two tier from three tier?

Where the processing logic lives. In two tier it rides on the client alongside presentation, which is what makes the client thick and what makes a business rule change expensive. In three tier it becomes a tier of its own that can be replaced or scaled without touching the client or the database. Counting servers is not the test; locating the business rules is. Chapter 11 · Application Architectures and Cloud Delivery

How to study for the exam

Build one small scenario of your own with four to six entity types and carry it through every chapter, adding to it rather than starting fresh each week. Every study session should end with a produced artefact: a diagram with cardinality marked, a relation list with keys underlined, a dependency set, or a statement. Read the answer only after producing yours.

In the fortnight before the examination, run the full four deliverable chain on three unfamiliar narratives under time pressure, and use the three point self check on each one: count the foreign keys against the diagram, look for any column holding more than one value, and ask of every non key column what determines it.

Your AI Information Technology tutor for IS5413

Stuck on a hard IS5413 question? Sia is AskSia’s AI Information Technology tutor — ask any IS5413 Database Management Systems 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.