Departmental Academic Assessment Database – Database Design Model 

Page | 1 
 
 Departmental Academic Assessment Database – Database Design Model 
 
 

Database Design Process 

Based upon the customer requirements it was necessary to have a brain storming session amongst 
the  team  to  identify  the  specific  data  that  the  database  would  be  required  to  store  and  give  us  a 
clearer idea of the actual application of the database within the client’s environment.  Once the data 
had  been  identified,  we  then  drew  up  the  initial  conceptual  design  that  met  the  client’s 
requirements.    At  this  stage  of  the  overall  design  model  it  was  then  necessary  to  have  a  meeting 
with the client to go through entity sets, entity attributes, relationships, relationship attributes and 
initial conceptual design.  This would allow the client to specify feedback in specific areas so that the 
overall  design  model  could  incorporate  additional  functionality  of  information  that  may  not  have 
been  included.    Once  this  meeting  had  concluded  we  could  then  alter  the  conceptual  design  to 
incorporate all of the elements highlighted by the client and project team to move the project design 
stage forward to the logical design.   

The logical design incorporated verification of entity sets and their attributes, relationships and their 
attributes and overall database schema.  This verification process has been completed through the 
application  of  an  ER  diagram  that  brings  together  all  of  the  elements  discussed  throughout  the 
conceptual  design  therefore  verifying  the  design  and  data  sets  prior  to  the  physical  structure.  
Within this part of the database design model we can begin to introduce elements of data access, 
querying  and  report  functionality  to  add  a  layer  of  real  world  application  to  the  discussed 
architecture.    One  of  the  main  client  requirements  for  this  project  is  the  output  of  a  series  of 
detailed  reports  regarding  student  performance  on  courses  and  programme  throughout  the 
academic  time  frame.      For  user  friendliness  we  have  decided  to  try  and  keep  the  output  of  the 
reports close to the reports that are currently being used both in layout and information included.  
As such this section of the design model needs to have heavy consideration upon data queries that 
will output the correct information in the correct format ready to be captured using the reports. 

Once the data verification process and logical design has been completed we can progress into the 
physical design of the database schema; which throughout the process of the ER and normalisation 
will bring the final table layout and relationship model ready to be implemented.  Once this has been 
completed  we  can  begin  to  think  about  how  the  user  will  access  the  data  efficiently  and  via  what 
media,  for  example,  web  GUI  application  programme  interface.    At  this  stage  the  application  of 
multiply queries are applied for the purpose of selecting specific data, inserting, deleting, updating 
tables  and  data  sets.    It  must  be  noted  that  these  queries  may  change  throughout  the  process  of 
implementation according to user requirements and constraints. 

Page | 2 
 
 Departmental Academic Assessment Database – Database Design Model 
 
 

Conceptual Design 

The first part of the design model after meeting with the client to clarify customer requirements and 
scope  of  the  project  is  a  brainstorming  session.    This  brings  together  the  team  with  all  of  their 
various  strengths  and  weaknesses  to  visualise  the  overall  design  model  that  will  be  required  and 
more  importantly  the  actual  data  that  will  be  stored.        Figure  1.1  shows  the  output  from  our 
brainstorming session and the various aspects of data that was initially discussed.   

Figure 1.1 – Brainstorming Diagram 

Starting Dates Classification

Units per Course Overall % Achieved

Duration

Course Names Units Achieved

Head of
Department
Students enrolled Units Taken
Program Name
Student Name
Program Program
Program Name
Student Start Date

Program Results
Student Name

Student ID #

Students
Student Assessment
Database
Required Data
Database
(Brainstorming)
Courses

Course Name

Course Tutor
Program
Course Course Results
Commencement
Date Course Units
Student ID#
Coursework (%)
Exam Results (%) Course
Student ID#
Examination/
Coursework Weight Exam results per
Course Work (%)
Exam Questions examination
question (%)
Type

Page | 3 
 
 Departmental Academic Assessment Database – Database Design Model 
 
 

Entity and Relationship Model 

A large part of the conceptual design for this project is in highlighting the data (entity) sets and their 
attributes, for example, students would be the entity set and data such as student ID, student name 
etc would be attributes of the entity set students.  This allows us to visualise the data requirements 
and  then  produce  the  relationships  between  entity  sets.    An  example  of  this  would  be  given  two 
entity  sets:    students  and  programme,  a  relationship  between  these  two  entity  sets  would  be 
represented by each student being enrolled on a specific programme.   This would be considered to 
be a one too many relationship because each of the students are enrolled on a single programme, 
thus one too many.   

A  meeting  was  then  requested  between  the  team  and  the  client  to  discuss  the  conceptual  design 
and  ensure  that  both  the  client  and  the  project  team  are  aware  of  the  data  and  relationship 
requirements  for  the  project.    At  this  point  the  client  can  provide  feedback  on  the  data  models 
represented above so that any initial changes can be made early on within the database design prior 
to  committing  to  the  physical  layout.    The  client  suggested  changing  how  the  course  results  were 
being  stored  in  order  to  provide  a  clearer  understanding  of  where  the  students  were  losing  or 
gaining marks within the exams undertaken. These changes where then carried out from this point 
forward in the conceptual design. 

In Figure 1.2 we can see the entity and relationship model that has been designed by the team to 
visualise the data requirements and relationships that could be implemented  in the final database 
schema.  This table also includes a column for keys.  The keys represent an extremely important part 
of the database schema and are used as a method of accessing each row of data independently from 
each  other.    One  of  the  constraints  when  selecting  and  applying  your  primary  key  is  uniqueness.  
Your primary key can be made up of one or more attributes within each entity set (table) as long as 
the overall primary key is unique between rows.   

Page | 4 
 
 Departmental Academic Assessment Database – Database Design Model 
 
Figure 1.2 – Entity and Relationship Model 

Entity Relation Model  Relationship Model 
 
Entities  Attributes  Keys  Relationships Attributes  Relationship 
Types 
Students  Student ID#  Student ID#  Students  None  1:N 
Name  (Pri Key)  Studying 
Start Date  Courses 
Program  Students  None  N:1 
Name  Enrolled on a 
Program 
Students  Results Total For Exam  1:N 
Exam Results 
Student  Results Weight of Final  1:1 
coursework  Mark  
results  
Courses  Course ID#  Course ID#  Courses  None  M:N 
Course Name  (Pri Key)  included in 
Course Tutor  programs 
Start Date  Course Exam  None  1:N 
Student ID#  Paper 
Course Units  Course Exam  Weight of exam  1:N 
Coursework  Results   questions/coursework 
Weight 
Program  Program  Program  Program to  None  1:N 
Name  Name (Pri  Students 
Head of  Key) 
Department 
Program to  None  M:N 
Duration 
courses 
Entry Date 
Program  Course ID#  Course ID#       
Courses  Program  &  
Name  Program 
Name (Pri 
Key) 
Exam Paper  Course ID#  Course ID#  Marks  None  1:N 
Question ID#  (Pri Key)  allocated for 
Marks  each 
Allocated  question in 
the results 
Exam  Course ID#  Course ID#,       
Results  Student ID#  Student ID# 
Question ID#  & Question 
Exam Results  ID# (Pri Key) 
Per Question 
Coursework  Course ID#  Course ID#  Coursework  Weight of exam  1:N 
Results  Student ID#  &  weight  questions/coursework 
Coursework   Student ID#  allocated per 
Results (%)  (Pri Key)  course 
 

Page | 5 
 
 Departmental Academic Assessment Database – Database Design Model 
 
ER Diagram 

As a process of verification and to bring the entity and relationship model to third normal form, it is 
necessary to draw up an ER diagram that visualises all of the components required for the database 
schema.    Throughout  the  process,  we  bring    together  all  of  the  elements  previously  discussed  in 
order to bring the conceptual design process much closer to the eventual logical and physical layout 
of the database.  This process naturally verifies both the schema and the customer driven database 
requirements.  Figure 1.6 shows the ER diagram designed for the purpose of this project, we can see 
from this that there are a number of weak entity sets where the primary keys are based upon the 
relationship  to  other  entity  sets,  these  include  programme  courses,  exam  results  and  course  work 
results.    We  can  identify  weak  entity  sets  whereby  the  entity  set  does  not  exist  without  reliance 
upon  another  entity  set,  for  example,  in  applying  the  total  participation  constraint  the  entity  set 
programme  course  is  made  up  of  only  two  attributes:    programme  name  and  course  ID.    Both  of 
these make up the primary key for the entity set and are attributes taken from the programme and 
courses  entity  sets  with  a  many  too  many  (M:N)  to  both  of  these  entity  sets.    We  would  consider 
exam results  and course  work results  to be  weak  entity sets based upon the  primary key for both 
entity sets being as a result of attributes that belong to other entity sets.  Without the relationship 
between exam results and courses the attribute course ID which participates in the primary key for 
exam results would not exists.  Likewise the same could be said for student ID against the student 
entity set and question ID against exam paper entity set.  We can also see from the ER diagram more 
clearly the relationship model previously discussed.   

Figure 1.6 – ER Diagram 
N:2

N:2

Page | 6 
 
 Departmental Academic Assessment Database – Database Design Model 
 
Logical Design 

Using the ER diagram we can now bring together the design and the implementation of the database 
of this project to enable us to progress into a physical database design.  Shown below in Figure 2.1, is 
a  table  highlighting  each  entity  set,  attributes,  data  type  and  key.    You  will  notice  from  Figure  2.1 
that the keys are represented by highlighting a reliance on another entity set in order to meet the 
uniqueness  constraint.    As  a  result  it  is  necessary  to  utilise  foreign  keys  which  are  attributes 
borrowed  from  the  primary  key  of  another  entity  set.    Data  types  have  also  been  highlighted  in 
Figure 2.1, allowing us to initialise each column of each entity set in accordance with the type of data 
that would be expected.  This column also includes any data types that may be auto incremented, 
which is where an attribute for an entity set would be automatically generated incrementally.  From 
this  table  we  begin  to  see  the  physical  layout  of  the  database  and  the  eventual  database  schema 
come together.   

Figure 2.1 –  

Entity Set  Attribute  Data Type  Key 

Courses  Course ID#  Int (auto increment)  Course ID# (Pri Key) 
Course Name  Varchar(25)  Student ID# (Foreign Key) 
Course Tutor  Varchar(30) 
Start Date  Date 
Student ID#  Int 
Course Units  Int 
Coursework Weight  Int 
Programs  Program Name  Varchar(25)  Program Name (Pri Key) 
Head of Department  Varchar(30) 
Duration  Varchar(15) 
Entry Date  Date 
Program Courses  Course ID#  Int  Program Name & Course 
Program Name  Text  ID# (Pri Key & Foreign Key)
Students  Student ID#  Int (auto increment)  Student ID (Pri Key) 
Name  Varchar(30) 
Start Date  Date 
Program Name  Varchar(15) 
Exam Paper  Course ID#  Int  Course ID# (Pri Key & 
Question ID#  Int (auto increment)  Foreign Key) 
Marks Allocated  int  Question ID# (Pri Key) 
Exam Results  Course ID#  Int  Course ID#, Student ID# 
Student ID#  Int  and Question ID# (Pri Key 
Question ID#  Int  & Foreign Key) 
Exam Results Per  Int 
Question 
Coursework Results  Course ID#  Int  Course ID# and Student 
Student ID#  Int  ID# (Pri Key & Foreign Key)
Coursework Results (%)  Int 
 

Page | 7 
 
 Departmental Academic Assessment Database – Database Design Model 
 
Initial Table Design 

To help visualise the information and requirements  of this project figure 2.2 shows an initial table 
layout  based  upon  the  ER  Diagram  that  was  created  within  the  conceptual  design.  Each  attribute 
that is underlined represents the primary key for that entity set. 

Figure 2.2 – Initial Table Design 

Page | 8 
 
 Departmental Academic Assessment Database – Database Design Model 
 
 

Physical Design 

Now that the design and initialisation aspect of the database has been completed in order to give us 
a final overview of the database requirements for this project, it is necessary to implement within a 
working  environment  an  initial  database.    Shown  in  Figure  3.1  we  can  see  a  physical  table  and 
database  layout  that  meets  all  of  the  constraints  and  customer  requirements  for  this  project  and 
adheres  to  the  third  normal  form  layout  presented  by  the  conceptual  design  process.    It  must  be 
noted  that  as  the  project  progresses  into  the  implementation  stages  this  database  layout  may 
change  slightly.    By  following  the  design  model  that  has  been  applied  and  the  verification  process 
included, we know that this will be the physical layout within a given margin of error.    

Figure 3.1 – Physical Database Layout 

Programs ProgramCourses Courses

PK,FK1,FK2 ProgramName PK CourseID# PK,FK1,FK2,FK2 CourseID#

PK,FK1 ProgramName
HeadofDepartment CourseName
Duration CourseTutor
EntryDate StartDate
FK2 CourseID# UnitsPerCourse
CourseworkWeight
FK2 QuestionID#

Exam Paper
ExamResults PK,FK1 CourseID#
PK,FK1 CourseID# PK QuestionID#
PK,FK1 QuestionID#
PK,FK2 StudentID# MarksAllocated

ExamResultperQuestion
CourseworkResult

PK,FK1 CourseID#
PK,FK2 StudentID#

Coursework
Students

PK StudentID#

StudentName
StudentStartDate

FK1 ProgramName
 

Page | 9 
 
 Departmental Academic Assessment Database – Database Design Model 
 
 

Operational Design 

Now  that  we  have  a  physical  layout  to  adhere  to  it  is  necessary  to  look  closely  at  the  database 
operations that will need to exist in order to provide the customer with the necessary results as per 
their requirements.  Outlined in figure 3.2 are the initial queries that have been designed for various 
purposes including those  highlighted in the  conceptual design  phase.  It  must be noted  that these 
queries are likely to change, but again only within a set margin for error.   

Figure 3.2 – Operational Queries 

Table  Description  Query 

Students  Insert Data  INSERT INTO Students IF EXISTS (SELECT ProgramName 

  FROM Program WHERE Program.ProgramName = “BSc 
  Applied Computing”) (StudentID, Name, StartDate, 
  ProgramName) values(“xxxxxx”, “Name”, “01/01/2008”, 
  “BSc Applied Computing”); 
   
Delete Data  DELETE * FROM Student WHERE StudentID = “085453”; 
   
Select Students  SELECT * FROM student WHERE ProgramName = “BSc 
studying program  Applied Computing”; 
   
Select Students that  SELECT * FROM Students WHERE StartDate = 
started at an entry  “01/01/2008” AND WHERE ProgramName = “Applied 
point studying a  Computing”; 
specific program   
   
Select all students  SELECT * FROM Students; 
Course  Insert Data  INSERT INTO STUDENT (CourseName, TutorName, 
  UnitsperCourse, CourseworkWeight) 
  values(“Programming”, “Name”, “35”, “15”); 
   
Delete Data  DELETE * FROM Course WHERE CourseName = 
  “Programming”; 
   
Select all Courses  SELECT * FROM Courses; 
Program  Insert Data  INSERT INTO STUDENT (ProgramName, 
  HeadofDepartment, Duration, EntryDate) values(“BSc 
  Applied Computing”, “Hongbo Du”, “2”, “Jan and July”); 
   
Delete Data  DELETE * FROM Course WHERE ProgramName = “BSc 
  Applied Computing”; 
   
Select all programs  SELECT * FROM Program; 

Page | 10 
 
 Departmental Academic Assessment Database – Database Design Model 
 
 

ProgramCourses  Insert Data  INSERT INTO ProgramCourses IF EXISTS (SELECT 

    ProgramName FROM Program WHERE 
    Program.ProgramName = “BSc Applied Computing”) 
    (ProgramName, CourseID#) values(“BSc Applied 
    Computing”, (SELECT CourseID FROM Course WHERE 
    Course.CousreName = “Programming”)); 
     
  Select Courses part of   SELECT * FROM ProgramCourses WHERE ProgramName = 
Program  “BSc Applied Computing”; 
 
Exam Paper  Insert Data  INSERT INTO ExamPaper IF EXISTS (SELECT StudentID# 
  FROM Student WHERE Students.StudentID# = “xxxxxx”) 
  (CourseID#, StudentID#, QuestionID#, MarksAllocated) 
  values( (SELECT CourseID FROM Course WHERE 
  Course.CousreName = “Programming”), “xxxxxx”, “xx”, 
  “xx”); 
   
Select Exam Paper  SSELECT * FROM ExamPaper WHERE CourseID# = (SELECT 
CourseID# FROM Course WHERE CourseName = 
“Programming”); 
Coursework  Insert Data  INSERT INTO Coursework IF EXISTS (SELECT StudentID# 
  FROM Student WHERE Students.StudentID# = “xxxxxx”) 
  (CourseID#, StudentID#, CourseworkResults) values( 
  (SELECT CourseID FROM Course WHERE 
  Course.CousreName = “Programming”), “xxxxxx”, “xx”); 
   
Update Results  INSERT INTO Coursework WHERE StudentID# = “xxxxxx” 
  AND CourseID# = “xx” (CourseworkResults) values(“xx”); 
   
Delete Table Contents  DELETE * FROM Coursework; 
   
Select all data  SELECT * FROM Coursework; 
 
Exam Results  Insert Data  INSERT INTO ExamResults IF EXISTS (SELECT StudentID# 
  FROM Students, ExamPaper WHERE Students.StudentID# 
  = “xxxxxx” AND ExamPaper.QuestionID# = “xx”) 
  (CourseID#, StudentID#, QuestionID#, ExamResults) 
  values( (SELECT CourseID FROM Course WHERE 
  Course.CousreName = “Programming”), “xxxxxx”, “xx”); 
   
Update Results  INSERT INTO ExamResults WHERE StudentID# = “xxxxxx” 
AND QuestionID# = “xx” (ExamResults) values(“xx”); 
 

Page | 11 
 
 Departmental Academic Assessment Database – Database Design Model 
 
 

General Results Queries  To display all  SELECT Students.StudentID, Students.name, 

students’ name , id,  Program.ProgramName FROM Students, Program WHERE 
program name who  ExamResults.StudentID = Students.StudentID AND 
sat for the HCI exam  ExamResults.CourseID = ”HCI”; 

To display all  SELECT Students.StudentID, Students.name, 
students’ name , id,  Program.ProgramName, 
program name, total  SUM(ExamResults.ExamResultperQuestion) as Exam 
exam marks course  Marks, Coursework.coursework FROM Students, Program, 
work who sat for the  Coursework WHERE  ExamResults.StudentID = 
HCI exam  Students.StudentID AND ExamResults.StudentID = 
Coursework.StudentID ExamResults.CourseID = ”HCI” 
  GROUP BY ExamResults.StudentID; 
 
To display particular  SELECT Students.StudentID, Students.name, 
student’s details who  Students.ProgramName, 
got highest marks for  SUM(ExamResults.ExamResultperQuestion) as 
HCI  ExamMarks FROM Students, Programs, Coursework, 
Course WHERE ExamResults.StudentID = 
Students.StudentID AND ExamResults.StudentID = 
Coursework.StudentID AND Course.courseID = 
ExamResults.courseID AND 
EXAMRESULTS.CourseID=”HCI” AND ExamMarks  >= ALL  
(select MAX(SELECT 
(SUM(ExamResults.ExamResultperQuestion) * (100‐
Course.CourseWeight) + Coursework.coursework) * 
Course.CourseWeight From Students, Programs, 
Coursework, Course WHERE ExamResults.StudentID = 
Students.StudentID AND ExamResults.StudentID = 
Coursework.StudentID AND Course.courseID = 
ExamResults.CourseID AND ExamResults.CourseID = ”HCI” 
GROUP BY ExamResults.StudentID) GROUP BY 
ExamResults.StudentID; 

 
 

Application Design 

In  order  to  provide  a  working  solution  for  the  client  it  is  necessary  to  implement  a  phase  1 
Application Programme Interface (API).  The API will give the user access to insert, update and delete 
data  within  the  database,  view  the  database  tables  and  produce  the  required  reports.    It  must  be 
noted that no consideration will be given within the phase 1 API design to user groups, security or 
backup.  These will need  to be aspects considered in detail as we move from the database design 
and implementation into the application level design and implementation.   

Page | 12