Department of Computer Science

Federal University Lafia

First Semester Session: 2019/2020
CSC313: Database Design and Management Group Course Work Credit Units: 4
Submission Deadline: Tuesday of week 10, at exactly 12noon

Project Teams
This is the BSc group project, to be completed in teams of five BSc students. Only the course
coordinator may authorise teams of any different size, for example, to take into account even numbers
of students. You are to form yourselves into groups of five students and submit your group list to the
course representative for submission to the coordinator on or before 12noon Wednesday, 4th March
2020.

Periodically, new teams of five will be created by an algorithm that randomly combines pairs of
students. Consult the list of teams, which will be updated periodically.

Project Submission
Your group submission will consist of a paper report, and an electronic bundle of this report and your
software system in a disc handed to any of the course lecturers assigned to this course. The date for
the group defence of the project will be communicated to you in the course of the semester.
Note: The hand-in deadline is indicated above.

The report should be about 12 pages in length (max 20 pages); describing the software system you
constructed to satisfy the requirements below and showing clear examples (this may screenshots) of
its correct operation. Note: Please do not exceed the page limit. Each report must have a signed
declaration from each student at the last page of the report, describing in sentences what their
contribution to the project was; and also indicating their agreed share of the group effort, as a
percentage. This credit allocation must be agreed and signed-off by all team members. A penalty of 5%
reduction per day will be applied for late submitted work, and after one week, there will be a cut-off
after which no credit may be obtained.

Requirements for the Database System

Your team has been contracted to build a database to manage the information storage needs of a
university. You must analyse the information requirements implicit in the English documentation
supplied by the university and come up with a conceptual information model, then convert this into a
normalised data model. You need to make sure that all of the kinds of operation requested in the
documentation can be performed on the database in an efficient way. You will build the database
using MySQL and demonstrate that it can perform a number of requested operations.
Information Requirements
The university needs a new student registration and tracking system. The system will keep a
database about students, degrees, modules (courses), departments and other related information
about the relationships between these.
• Student – has a unique registration number, a gender (m or f), a forename and a surname,
and an email address.
• Degree – has a unique degree course code, a degree name, and a qualification (e.g. BSc,
MEng, obtained on graduation).
• Level – refers to the study programme specified for a given degree in one academic year, and
is uniquely identified by the degree code and level code (1-4 representing the first
undergraduate level to the final master’s level).
• Module – has a unique module code, a module name, and a credit value (2, 3, 4 etc).
• Department – has a unique department code (eg CSC, ACS, EEE, SOC, BOL etc), a department
name, contact phone number, contact email address, and the building name where the
department is located.
• Session – refers to a period of study undertaken by a student for one academic year; and is
uniquely identified by the registration number, the level of study (1-4) and the year in which
the session started. The session may also have a result grade for the student in that year,
after assessment is completed.

There are a number of relationships between these basic items.

• Every student registers for a single degree; and every degree may enroll many students.
• Every degree is delivered by one or many departments, such that one of these departments is
identified as the lead or home department; and every department may offer many degrees.
• Every degree consists of a number of levels (study programme for one academic year); and
every level belongs to exactly one degree.
• Every level prescribes many modules to be studied; but a module may belong to many
different levels (be part of different degrees). At least 17 credits of modules (courses) are
prescribed, and usually more than this are available at each level, to allow some choice but
not exceeding 24 credits. Some modules may be core (compulsory) and others will be elective
(recommended, but optional) for a given level of a given degree. The same module may be
both core or approved at different levels on different degrees.
• Every student is registered for a new session in each new academic year, so will eventually
register for many sessions, one for each level of study (possibly repeating the same level in a
following year, if they fail in their first attempt); and each session relates to exactly one
student.
• Every session consists of many modules chosen by the student for that academic year. The
session’s level of study (1-4) influences what modules may be selected. All the core modules
for that level must be taken, and sufficient approved modules for that level to make up
minimum of 17 credits and maximum of 24 credits in total.
 • Every module that students study in a session will be assessed, such that they will eventually
obtain a grade out of 100 for each module. An assessment may be marked as a repeat
attempt, if the same student previously failed in this module.

Query and Update Requirements

The registrar must be able to perform the following kinds of modifying actions on the data. Assume
that the registrar must also be able to see the results of each kind of modification:
• Insert new records for students, modules, departments and degrees, which are never
deleted. Each new degree must be associated with one or more departments, and one
department must be identified as the home or lead department. Each student must be
registered for a given degree (which may be changed later).
• Insert new levels specifying the regulations for each degree, such that each level identifies the
degree and level of study (1-4), and each level is associated with some core modules and
some approved modules, such that there are at least 17 credits of study available at each
level (and usually more, to allow some freedom of choice) but must not exceed 24 credits.
• Enroll students in the next academic session for the degree they are taking, such that each
session identifies the student, the level of study, and each session is associated with the
modules being taken by that student, including whether this is a repeat attempt, such that a
grade may later be recorded for each module chosen.
• Change the regulations for a given degree, by changing the core and approved modules
associated with one or more levels for that degree.
• Change the enrolled status of a student, either by changing the student’s current degree, or
by changing the selection of elective modules chosen by the student for the current session.
The credit total must always add up to 17 credits and must not exceed 24 credits.
• Enter marks for each module taken in a session by a student. For each module, the raw
(unadjusted) mark is entered for a first attempt; but a capped (adjusted) mark is entered if a
repeat assessment was undertaken, in which case the maximum raw mark for that module is
the pass mark 40%.
• Calculate the result grade for that session, based on a weighted average (raw marks times
credits, summed and normalized), and determine if the student has passed the session and
gained an average mark of at least 40%)

Suggested Team Working Strategy

You will need to delegate effectively in order to complete this project within the deadline specified
above. The most effective strategy will be something like:
• Get a MySQL tool preferably, MySQL Workbench installed on more than one system in the
group and ensure you always have a backup of your work after every group session.
• Working together as a team, design the database first, building a conceptual information
model, then convert this into a normalized data model, until you are convinced that you can
do all the insert, update and delete actions independently.
 • Have a pair of students work on building the departments, degrees, levels and modules part
of the database, such that there is a suitably large set of information available for the rest of
the team.
• Have a pair of students work on building the students, sessions, modules and grades part of
the database, using the modules developed along with the rest of the team.
• Everybody work on designing the kinds of SQL update and query necessary to perform the
data manipulation actions requested below, to demonstrate that your database works, which
will be written up in the later part of your report.

Structure of the Team Report

Pre-Normal and Normalised Data Models

The report should include suitable documentation for the analysis and design of the student
registration and tracking system. This will therefore include:
• A conceptual model of the information requirements for the student registration and tracking
system, showing classes and attributes, binary associations between classes, together with
association end roles, multiplicities and any attached association classes to model the
attributes of the associations.
• A suitably normalized data model for the application, identifying all tables, attributes and
primary and foreign keys. The data model should show the direction of linkage between each
associated table with a directed association, and the revised multiplicities on the normalized
associations.

Behaviour of Query Processing (with Evidence)

The documentation for the demonstration of the MySQL database should give screen-shots of the
results of the SQL updates and queries requested below. The report should demonstrate, with clear
output evidence from your screenshots, how your system behaves under the following 10 conditions:
• Registering a new student for a particular degree;
• Searching for the degree name taken by a particular student;
• Adding a new MEng Aerospace Engineering degree shared between 5 departments MEC,
MAT, EEE, ACS, COM and led by MEC1;
• Searching for the home department name of a given student taking the Aerospace
Engineering degree;
• Inserting a level of study for a given degree, specifying the core and elective modules for that
level;
• Verifying that sufficient credits are available for that level of study you just inserted;
• Inserting a study session for a given student, using modules that are core or elective for the
level of study;
• Verifying that the above student has taken exactly between 17 credits as minimum or 24
credits as maximum and has chosen only modules that are core or elective for the level of
study;
 • Inserting the marks for the assessment of a given student for a given session, including two
repeated assessments, where a student had to resit the examination (in the next seesion);
• Calculating the end of session result for the above student, including whether the student
passed.

If you don’t manage to demonstrate all of these, marks will be awarded proportionately for the
required behaviour that you succeed in implementing and demonstrating in your report. Note that it
is not sufficient for the User Interface just to report success; you will need to display the state of the
database after each insertion or deletion.

Team Working and Effort Allocation

Finally, the report should contain a short discussion about your team-working strategy and end with
the required allocation of work declaration (see under the Rules of the Project, above), which should
• describe the actual work that each team member did, and also
• give a percentage share of the team’s effort contributed by each member.

The team must sign off this declaration of effort, as proof that you all agreed to it. If five team
members share the work equally, each member will contribute 20%.