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 Duration Head of Department Program Name Program Student Start Date Student Name Student ID # Students

Classification Units per Course Course Names Students enrolled Overall % Achieved Units Achieved Units Taken Student Name Program Program Name Program Results

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

Student Assessment Database (Brainstorming)

Student ID# Exam Questions


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    Entities  Attributes  Students  Student ID#  Name  Start Date  Program  Name  Relationship Model  Keys  Student ID#  (Pri Key)  Relationships Students  Studying  Courses  Students  Enrolled on a  Program  Students  Exam Results  Student  coursework  results   Courses  included in  programs  Course Exam  Paper  Course Exam  Results   Program to  Students  Program to  courses  Course ID#  &   Program  Name (Pri  Key)  Course ID#  (Pri Key)    None  Attributes  Relationship  Types  1:N 



Results Total For Exam  Results Weight of Final  Mark   None 

1:N  1:1 



Program  Courses 

Course ID#  Course Name  Course Tutor  Start Date  Student ID#  Course Units  Coursework  Weight  Program  Name  Head of  Department  Duration  Entry Date  Course ID#  Program  Name 

Course ID#  (Pri Key) 


None  Weight of exam  questions/coursework  None 

1:N  1:N 

Program  Name (Pri  Key) 




Exam Paper 

Course ID#  Question ID#  Marks  Allocated 

Exam  Results 

Course ID#  Student ID#  Question ID#  Exam Results  Per Question  Coursework  Course ID#  Results  Student ID#  Coursework  Results (%)    Page | 5   

Course ID#,  Student ID#  & Question  ID# (Pri Key)  Course ID#  &   Student ID#  (Pri Key) 

Marks  allocated for  each  question in  the results   





Coursework  weight  allocated per  course 

Weight of exam  questions/coursework 


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 




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  Courses  Attribute  Course ID#  Course Name  Course Tutor  Start Date  Student ID#  Course Units  Coursework Weight  Programs  Program Name  Head of Department  Duration  Entry Date  Program Courses  Course ID#  Program Name  Students  Student ID#  Name  Start Date  Program Name  Exam Paper  Course ID#  Question ID#  Marks Allocated  Exam Results  Course ID#  Student ID#  Question ID#  Exam Results Per  Question  Coursework Results  Course ID#  Student ID#  Coursework Results (%)      Data Type  Int (auto increment)  Varchar(25)  Varchar(30)  Date  Int  Int  Int  Varchar(25)  Varchar(30)  Varchar(15)  Date  Int  Text  Int (auto increment)  Varchar(30)  Date  Varchar(15)  Int  Int (auto increment)  int  Int  Int  Int  Int  Int  Int  Int  Key  Course ID# (Pri Key)  Student ID# (Foreign Key) 

Program Name (Pri Key) 

Program Name & Course  ID# (Pri Key & Foreign Key) Student ID (Pri Key) 

Course ID# (Pri Key &  Foreign Key)  Question ID# (Pri Key)  Course ID#, Student ID#  and Question ID# (Pri Key  & Foreign Key) 

Course ID# and Student  ID# (Pri Key & Foreign Key)

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 PK,FK1,FK2 ProgramName HeadofDepartment Duration EntryDate CourseID# FK2 ProgramCourses PK PK,FK1 CourseID# ProgramName Courses PK,FK1,FK2,FK2 CourseID# CourseName CourseTutor StartDate UnitsPerCourse CourseworkWeight QuestionID#


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

CourseworkResult PK,FK1 PK,FK2 CourseID# 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 

Insert Data            Delete Data    Select Students  studying program    Select Students that  started at an entry  point studying a  specific program    Select all students  Insert Data        Delete Data      Select all Courses  Insert Data        Delete Data      Select all programs 

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 * FROM Student WHERE StudentID = “085453”;    SELECT * FROM student WHERE ProgramName = “BSc  Applied Computing”;    SELECT * FROM Students WHERE StartDate =  “01/01/2008” AND WHERE ProgramName = “Applied  Computing”;      SELECT * FROM Students;  INSERT INTO STUDENT (CourseName, TutorName,  UnitsperCourse, CourseworkWeight)  values(“Programming”, “Name”, “35”, “15”);    DELETE * FROM Course WHERE CourseName =  “Programming”;    SELECT * FROM Courses;  INSERT INTO STUDENT (ProgramName,  HeadofDepartment, Duration, EntryDate) values(“BSc  Applied Computing”, “Hongbo Du”, “2”, “Jan and July”);    DELETE * FROM Course WHERE ProgramName = “BSc  Applied Computing”;    SELECT * FROM Program; 



Page | 10   

Departmental Academic Assessment Database – Database Design Model 

ProgramCourses                Insert Data              Select Courses part of   Program  Insert Data              Select Exam Paper  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 * FROM ProgramCourses WHERE ProgramName =  “BSc Applied Computing”;    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”);    SSELECT * FROM ExamPaper WHERE CourseID# = (SELECT  CourseID# FROM Course WHERE CourseName =  “Programming”);  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”);    INSERT INTO Coursework WHERE StudentID# = “xxxxxx”  AND CourseID# = “xx” (CourseworkResults) values(“xx”);    DELETE * FROM Coursework;    SELECT * FROM Coursework;    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”);    INSERT INTO ExamResults WHERE StudentID# = “xxxxxx”  AND QuestionID# = “xx” (ExamResults) values(“xx”);   

Exam Paper 


Insert Data            Update Results      Delete Table Contents    Select all data  Insert Data              Update Results 

Exam Results 

Page | 11   

Departmental Academic Assessment Database – Database Design Model 

General Results Queries  To display all  students’ name , id,  program name who  sat for the HCI exam  To display all  students’ name , id,  program name, total  exam marks course  work who sat for the  HCI exam      To display particular  student’s details who  got highest marks for  HCI  SELECT Students.StudentID,,  Program.ProgramName FROM Students, Program WHERE  ExamResults.StudentID = Students.StudentID AND  ExamResults.CourseID = ”HCI”;  SELECT Students.StudentID,,  Program.ProgramName,  SUM(ExamResults.ExamResultperQuestion) as Exam  Marks, Coursework.coursework FROM Students, Program,  Coursework WHERE  ExamResults.StudentID =  Students.StudentID AND ExamResults.StudentID =  Coursework.StudentID ExamResults.CourseID = ”HCI”  GROUP BY ExamResults.StudentID;  SELECT Students.StudentID,,  Students.ProgramName,  SUM(ExamResults.ExamResultperQuestion) as  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   

Sign up to vote on this title
UsefulNot useful

Master Your Semester with Scribd & The New York Times

Special offer for students: Only $4.99/month.

Master Your Semester with a Special Offer from Scribd & The New York Times

Cancel anytime.