DEVELOPMENT OF A DATABASE FOR WORK … · DEVELOPMENT OF A DATABASE FOR WORK-BASED LEARNING TIMESHEETS BSc Computing Studies ... 2.7.1 Top Level Data Flow Diagram ... the WBL Management

THE UNIVERSITY OF TEESSIDE

SCHOOL OF COMPUTING

MIDDLESBROUGH

TEES VALLEY TS1 3BA

DEVELOPMENT OF A DATABASE FOR WORK-BASED LEARNING TIMESHEETS

BSc Computing Studies

February 2008

Andrea Stewart

Supervisor: M Nawaz

Second Reader: M Birtle

iv

ABSTRACT This document follows the development of a timesheet database to enable the recording,

monitoring and reporting of attendance of all Work Based Learning (WBL) students of

Hartlepool College of Further Education and to provide accurate and timely information

to enable Education Maintenance Allowance (EMA) and travel funds to be paid

promptly.

v

ACKNOWLEDGEMENTS I would like to thank my project supervisor at the university, Mansha Nawaz for

believing in me and without whose support and encouragement I would have found this

project and my years at the university much more of a struggle.

I would also like to thank a colleague from my place of work, Ron Smith, who

throughout this project has provided me with all the help and assistance I needed to

complete this project.

vi

CONTENTS CHAPTER 1 - INTRODUCTION........................................................................... 8

1.1 Development Strategy................................................................................... 11

1.2 Project Aims and Objectives........................................................................ 12

1.3 Standards and Procedures ........................................................................... 13

1.2.1 British Computer Society (BCS) - Code of Conduct .................................. 13

1.2.2 Ethical Issues............................................................................................... 13

1.3 Methodology .................................................................................................. 14

1.3.1 Systems Development .................................................................................. 14

1.3.2 Analysis Methodologies............................................................................... 15

1.3.3 Design Methodologies ................................................................................. 15

1.3.4 Implementation Methodologies .................................................................. 15

1.4 Case Tools & Techniques ............................................................................. 16

CHAPTER 2 - DATABASE ANALYSIS ............................................................. 17

2.1 Statement of Purpose.................................................................................... 17

2.2 Requirements - User ..................................................................................... 17

2.4 General Interface Design.............................................................................. 18

2.4.1 Style & Layout ............................................................................................. 18

2.4.2 Data Security ............................................................................................... 18

2.4.3 System Security............................................................................................ 18

2.5 Analysis using Yourdon’s notation ............................................................. 19

2.5.1 Diagram Objects .......................................................................................... 19

2.5.2 Process ......................................................................................................... 19

2.5.3 Entity............................................................................................................ 19

2.5.3 Data Flow .................................................................................................... 20

2.5.4 Data Store .................................................................................................... 20

2.6 Context Diagram........................................................................................... 21

2.6.1 Events List.................................................................................................... 21

2.7 Data Flow Diagrams (DFDs)........................................................................ 22

2.7.1 Top Level Data Flow Diagram (DFD) ....................................................... 22

2.8 Low Level Data Flow Diagrams (DFD’s).................................................... 23

2.8.1 Process 1.1 “Student Submits Timesheet”. ................................................ 23

2.8.2 Process 1.2 “Student Requests Holiday”.................................................... 24

vii

2.8.3 Process 1.3 “Student Suffers Sickness”. .................................................... 25

2.8.4 Process 1.4 “WBL Admin Requests Login”. .............................................. 26

2.8.5 Process 1.5 “WBL Admin Imports Data”................................................... 27

2.8.6 Process 1.6 “WBL Admin Enters Timesheet”............................................ 28

2.8.7 Process 1.7 “WBL Admin Request Report”. .............................................. 29

CHAPTER 3 - DATABASE DESIGN .................................................................. 30

2.1 Database Functionality................................................................................. 31

2.2 Database Systems Development Lifecycle .................................................. 32

2.3 Logical Database Design............................................................................... 33

2.4 Data Dictionary ............................................................................................. 33

2.4.1 Entities ......................................................................................................... 33

2.4.2 Relationships ............................................................................................... 34

2.4.3 Attributes...................................................................................................... 35

2.5 Entity Relationship Diagram (ERD) ........................................................... 36

2.6 Logical Tables................................................................................................ 37

2.6.1 Create Tables ............................................................................................... 37

2.7 Physical Database Design............................................................................. 38

2.8 Physical Tables .............................................................................................. 38

2.8.1 Create Base Tables ...................................................................................... 38

2.9 Analysing Transactions ................................................................................ 40

2.10 Interface Design ............................................................................................ 41

2.10.1 Style & Layout ............................................................................................. 41

2.10.2 Data Security ............................................................................................... 41

2.10.3 System Security............................................................................................ 41

2.11 Page Designs .................................................................................................. 42

CHAPTER 4 - DATABASE IMPLEMENTATION ........................................... 43

4.1 Development Platform.................................................................................. 43

4.2 Table Implementation .................................................................................. 45

4.3 Form Implementation................................................................................... 46

4.3.1 Stored Procedure Import............................................................................. 47

4.3.2 Macro – Update/Append ............................................................................. 49

4.3.3 Macros – Create CSV.................................................................................. 53

4.4 Test & Evaluation Strategy.......................................................................... 55

4.4.1 Validation Testing ....................................................................................... 55

viii

4.4.2 User Testing................................................................................................. 57

4.4.3 Developer Testing ........................................................................................ 57

CHAPTER 5 - CONCLUSIONS............................................................................. 59

5.1 CRITICAL REVIEW of PROJECT DELIVERABLES........................... 59

5.1.1 INTRODUCTION ....................................................................................... 59

5.1.2 SYSTEMS ANALYSIS ................................................................................ 59

5.1.3 SYSTEMS DESIGN .................................................................................... 59

5.1.4 SYSTEMS IMPLEMENTATION .............................................................. 59

5.1.5 CRITICAL REVIEW .................................................................................. 60

5.2 CRITICAL REVIEW of PROJECT........................................................... 60

5.2.1 PROJECT GOALS ...................................................................................... 60

5.2.2 PROJECT ACHIEVEMENTS ................................................................... 60

5.2.3 PROJECT REFLECTION.......................................................................... 60

5.3 CRITICAL REVIEW of PRODUCT.......................................................... 61

5.3.1 PRODUCT GOALS..................................................................................... 61

5.3.2 PRODUCT ACHIEVEMENTS .................................................................. 61

5.3.3 PRODUCT EVALUATION ........................................................................ 63

5.3.4 PRODUCT REFLECTION ........................................................................ 64

5.4 CRITICAL REVIEW of PERSONAL DEVELOPMENT ....................... 64

CHAPTER 6 - RECOMMENDATIONS ............................................................... 66

6.1 Late Timesheet Warning.............................................................................. 66

6.2 Period of Sickness Warning ......................................................................... 66

6.3 Holidays not Accrued Warning ................................................................... 66

6.4 Holiday Entitlement Warning ..................................................................... 66

REFERENCES.............................................................................................................. 67

APPENDIX A SPECIFICATION......................................................................... 68

APPENDIX B WORK BASED LEARNING TIMESHEET.............................. 70

APPENDIX C SELF-CERTIFICATION OF ABSENCE .................................. 71

APPENDIX D HOLIDAY BOOKING FORM.................................................... 72

APPENDIX E DEVELOPMENT SCHEDULE PLAN ...................................... 73

APPENDIX F BCS CODE OF CONDUCT ........................................................ 74

APPENDIX G DATA DICTIONARY: ENTITIES............................................. 77

APPENDIX H DATA DICTIONARY: RELATIONSHIPS............................... 78

APPENDIX I DATA DICTIONARY: ATTRIBUTES.......................................... 79

ix

APPENDIX J LOGICAL: CREATE TABLES..................................................... 84

APPENDIX K PHYSICAL: CREATE BASE TABLES.................................... 86

K.1 Base table for dbo.Student ........................................................................... 86

K.2 Base table for dbo.Enrolment ...................................................................... 87

K.3 Base table for dbo.Sickness .......................................................................... 88

K.4 Base table for dbo.Holiday........................................................................... 89

K.5 Base table for dbo.EMA ............................................................................... 90

K.6 Base table for dbo.Travel ............................................................................. 91

K.7 Base table for dbo.TimesheetAttendance ................................................... 92

K.8 Base table for dbo.MarkType ...................................................................... 92

K.9 Base table for dbo.Staff ................................................................................ 93

K.10 Base table for dbo.Supervisor...................................................................... 93

APPENDIX L PAGE DESIGNS........................................................................... 94

L.1 WBL Timesheet Database - Home page ..................................................... 94

L.2 WBL Timesheet Database – Timesheet Entry page .................................. 94

L.3 WBL Timesheet Database – Student Sickness page .................................. 95

L.4 WBL Timesheet Database – Student Holiday page ................................... 95

L.5 WBL Timesheet Database - Reports page .................................................. 96

APPENDIX M SQL TABLES................................................................................ 97

M.1 SQL table of dbo.Student ............................................................................. 97

M.2 SQL table of dbo.Enrolment........................................................................ 98

M.3 SQL table of dbo.Sickness............................................................................ 98

M.4 SQL table of dbo.Holiday............................................................................. 99

M.5 SQL table of dbo.EMA................................................................................. 99

M.6 SQL table of dbo.Travel ............................................................................. 100

M.7 SQL table of dbo.TimesheetAttendance ................................................... 100

M.8 SQL table of dbo.MarkType...................................................................... 101

M.9 SQL table of dbo.Staff ................................................................................ 101

M.10 SQL table of dbo.Supervisor...................................................................... 102

APPENDIX N ENROLMENT STORED PROCEDURE................................. 103

APPENDIX O VB IMPORT................................................................................ 104

APPENDIX P USER GUIDE.............................................................................. 105

APPENDIX Q VALIDATION TESTING.......................................................... 113

APPENDIX R USER TESTING ......................................................................... 114

x

CHAPTER 1 - INTRODUCTION

Hartlepool College of Further Education is a medium sized further education college

with an annual enrolment of approximately 8,000 students. Within Hartlepool College

there is the division of Work-based Learning (WBL) which incorporates Apprentice

programmes; Entry to Employment programmes, Work-based Learning for Adults

(WBLA) and New Opportunities programmes.

“The profile of WBL has never been higher, and never has the need for it been

greater. There are now more apprentices in learning than ever, and more than

ever are gaining their National Vocational Qualification (NVQ) and achieving

their full framework. Entry to Employment (E2E) is in its fourth successful

year, and record numbers of young people are progressing into WBL, further

education (FE) and jobs. This high profile and these successes put WBL under

the spotlight and increase pressures on the budget.”

([1] – Requirements for Funding Work-based Learning 2007/08, Page 2)

The timesheet system used by the

work based learning team currently is

all paper based. Students submit one

timesheet per week which are then

logged on a chart in a file. Figure 1.1

shows an example of the current

paper based timesheet used to record

students’ timesheet attendance. To

view a full size example timesheet,

please refer to Appendix B.

Figure 1.1 WBL Timesheet

8

This chart is then monitored by a member of the work based learning team for any

timesheets that have yet to be submitted or any that have been submitted late. After a

number of late timesheet submissions, students could have their Education Maintenance

Allowance (EMA) payments stopped as a result of this. In order for the payments to be

processed a member of the work based learning team manually enters each student onto

the EMA website. EMA can give students up to £30 per week to help with the costs of

staying in learning after they leave school. The money is paid directly into the student’s

bank account, which then allows them to use it to pay for whatever they want such as

books or equipment etc, further details of EMA can be found at EMA: Directgov –

Education and learning, http://ema.direct.gov.uk/ema.html [2].

As well as recording timesheets the work

based learning team record student

sickness and holidays. If a student has a

period of sickness of up to 5 working

days they are required to complete a Self-

Certification form, an example is shown

in Figure 1.2. This process is also paper

based and is again monitored by a WBL

administrator and checked for any

continuous periods of sickness as any

student who is absent for more than 5

working days is requested to provide a

sick note from their doctor. To view a

full size Self-Certification of Absence

form, please refer to Appendix C.

Figure 1.2 Self-Certification of Absence

9

When students want to request

holidays they do so by completing a

Holiday Booking form giving a

minimum of 7 days notice as shown in

Figure 1.3. Students accrue two days

holiday per calendar month, therefore

student holiday entitlement needs to be

monitored to check how many days

holiday a student may have left as a

student may submit a holiday request

form but not actually have enough

holidays to cover it. To view a full

size Self Certification form, please

refer to Appendix D.

Figure 1.3 Holiday Booking Form

This is obviously a very bureaucratic way of recording such data and makes reporting

for example an impossible task. The work based learning team therefore require a

system to allow them to record electronically student timesheet information on a weekly

basis. The system must recognise if timesheets are submitted late and also determine as

to whether a student is to be paid EMA, Travel, both or neither.

The timesheet database is intended to link to PICS, the WBL Management Information

System (MIS) and from this import any new work based learning students into the

timesheet database that don’t already exist avoiding the need to enter them manually.

The timesheet database is to be created using a relational Database Management System

(DBMS) known as SQL Server together with a Microsoft Access front end application.

10

The structure of this report is intended to cover every aspect of design that the timesheet

database will need in order for it to be developed. The report has been designed to

study the feasibility and the need for a WBL Timesheet database. The following

headings make up the structure of the report and each provides a brief explanation of its

content:

• Introduction – The introduction explains the background to the project and

provides an overview of the existing practices and procedures, project aims and

objectives, standards and procedures and methodologies that will be followed.

• Database Analysis – The analysis section provides an explanation of the

analysis that was undertaken using Yourdon’s notation and also the user

requirements.

• Database Design – The design section provides an explanation of the design

process used which was “The Database System Development Lifecycle” by

Database Solutions, A step-by-step guide to building databases, [3].

• Database Implementation – The implementation section provides an

explanation into how the timesheet database was implemented.

• Critical Review – This section of the report provides a critical review of the

project deliverables, project goals, achievements and reflection together with a

critical review of the product to be implemented and finally a critical review of

the personal development.

• Recommendations – Suggested recommendations on any future system

enhancements.

• References – Reference material used to help produce the project report.

Appendices - Provides in-depth information of items referenced in the body of the

report.

1.1 Development Strategy A development strategy plan is to be put in place in the form of a Gantt chart to enable

all project tasks to be completed within their allocated timescales. The Project

Development Strategy can be viewed in Appendix E.

11

1.2 Project Aims and Objectives The aim of the project is to build a system that can record, monitor and report on the

attendance of Work Based Learning (WBL) students and provide accurate and timely

information to enable Education Maintenance Allowance (EMA) and travel funds to be

paid promptly.

The objectives are as follows:

• To enable the submission of student timesheets to be processed and

recorded in a more accurate and efficient way.

• To provide a more effective way of processing and recording student

holiday requests and to know instantly if the student has the holiday

entitlement to cover the request.

• To provide a more effective way of processing and recording student

sickness and to instantly know if the student needs to provide or

complete further documentation i.e. Self Certification form.

• To only allow the relevant members of staff to access the WBL

Timesheet database and its data using a secure login and password.

• To import work based learning students from the college’s WBL

Management Information System (MIS) into the WBL Timesheets

Database that don’t already exist, avoiding the need to enter them

manually.

• To provide a fast and efficient way of generating management reports.

• To enable admin staff to generate accurate and prompt payments to

students for Education Maintenance Allowance (EMA) and Travel on a

weekly basis.

12

1.3 Standards and Procedures

1.2.1 British Computer Society (BCS) - Code of Conduct To ensure this project meets the required professional standards, the BCS Code of

Conduct will be followed throughout. To view in full the BCS Code of Conduct, please

refer to Appendix F.

1.2.2 Ethical Issues Certain ethical issues need to be taken into consideration throughout the project and

when implementing the timesheet database. The affected administration staff will need

to be trained to enable the system to process efficiently. As the system is to hold

student personal information the project will follow strictly The Data Protection Act

1998. The Data Protection Act contains eight Data Protection Principles. The act states

that all data must be:

1 Processed fairly and lawfully

2 Obtained and used only for specified and lawful purposes

3 Adequate, relevant and not excessive

4 Accurate and where necessary, kept up to date

5 Kept for no longer than necessary

6 Processed in accordance with the individuals rights (as defined)

7 Kept secure

8 Transferred only to countries that offer adequate data protection

13

1.3 Methodology

1.3.1 Systems Development A system should be built through the process of a structured methodology. The systems

development of a project involves the construction and maintenance of a computer

system through its lifecycle. The Waterfall methodology as shown in Figure 1.4 is

sometimes considered to be the classic approach to the systems development lifecycle.

It defines a distinct set of steps for each phase of the development. More information

on the Waterfall model can be accessed from Systems Development,https://outranet.

scm.tees.ac.uk /users/u0000706/HND_SAD/sad_01%20Systems%20

Development%20Life%20Cycle.ppt, [4].

The project overall will aim to follow the Waterfall model as a guide to carrying out the

analysis, design and implementation stages of the project.

Systems Analysis

Systems Design

Systems Implementation

System Testing

Figure 1.4 The Waterfall Model

14

1.3.2 Analysis Methodologies To undertake the analysis stage of the project the methodology used was Yourdon.

Both Data Flow Diagrams (DFD’s) and Entity Relationship Diagrams (ERD’s) were

used to help with the development of the timesheet database.

Other sources of information were also used to help with the analysis of the project such

as internet websites and academic books. As the timesheet database is to have a SQL

Server backend and a Microsoft Access front end application an investigation needed to

be carried out to determine whether or not the two combined could in actual fact allow

the system to be developed with all the required functionality needed for it to work

effectively.

1.3.3 Design Methodologies To enable the development of a more powerful and more efficiently built system it was

decided that the methodology to be used for the design stage of the project would be

“The Database System Development Lifecycle” from Database Solutions, A step-by-

step guide to building databases, [3], p 78.

The methodology is aimed at relational database management systems and is divided up

into two phases. The first, a conceptual/logical database design phase, supports the

development of a model it is intended to represent while ignoring the implementation

details. The second, a physical database design phase, provides guidance in deciding

how to realise the implementation in the target database management system, as

previously mentioned is SQL Server. The notation used to support the methodology is

the class diagram notation from the latest object-orientated modelling language called

UML, short for Unified Modelling Language.

1.3.4 Implementation Methodologies The implementation stage of the project was done as a series of stages in itself.

Meaning that certain parts of the database needed to be completed before moving on to

the next. If any problems arose throughout the implementation stage they had to be

addressed and corrected before the development could proceed.

15

1.4 Case Tools & Techniques To create the data flow diagrams used in Yourdon’s methodology a drawing tool called

Ascent was used and to create the entity relationship diagrams, Microsoft Office Viso

2007 was used.

16

CHAPTER 2 - DATABASE ANALYSIS

2.1 Statement of Purpose A database system to record the attendance, sickness & holidays of work based learning

students to ensure prompt and accurate payment of Education Maintenance Allowance

(EMA) and Travel on a weekly basis.

2.2 Requirements - User

• Must show timesheet information for each week.

• Notification required after two late timesheets.

• Notification required after four late timesheets.

• System must be able to distinguish between Education Maintenance

Allowance (EMA) and Travel and also whether the student is claiming

one or the other, both or neither.

• Must show individual periods of sickness.

• Notification required showing individual sickness periods e.g. > 5

working days.

• Notification required when a student has had 4 separate periods of

sickness.

• Notification required continuously after 4 separate periods of sickness.

• Must show individual holidays.

• Notification required for holidays not accrued as student is entitled to 2

per month.

• Notification required when a student has used all of their holiday

entitlement i.e. >24.

• Notification required continuously after all 24 holidays have been used

within the specified academic year.

17

2.4 General Interface Design

2.4.1 Style & Layout The style and layout of any user interface should be easy and pleasant to look at

meaning that it shouldn’t appear too busy or over crowded. Each screen the user visits

should follow a consistent style and layout with each screen only consisting of data or

information relevant to that specific subject/area. The user should be able to recognise

instantly where in the system they are, therefore the use of page headings or titles is

essential. The user should also be able to locate their way back to the home page easily.

Appropriate and consistent use of colours and font sizes should be used throughout the

system. Colours however should be used with caution as certain colours can affect the

way for example a person who is colour blind may see it. The contrast between

background colour and text colours or images can make a good system very irritating to

use as the readability can be very poor.

2.4.2 Data Security Data security is the way in which the data is accessed and used and also the actions

users can have on the system. Any system that requires the user to input data needs to

deal with the accuracy and validation of the data being entered. Therefore all systems

should have some form of integrity constraints built in to prevent the user from

inputting obscure or irrelevant data. The database should be created to protect the data

for example if the data is to be read-only thus not allowing the user to modify certain

types of data in any way, Information Systems Security, [5], p 13.

2.4.3 System Security System Security is the way in which the user can access and use the data at the system

level. Any system that holds sensitive or personal data about something or someone

should be protected with some form of security feature. A username and password is

the first step in securing data, from this, levels of authorization and permission can be

granted against each user to identify what they are able to do within the system,

Database Security, [6], p 23.

18

2.5 Analysis using Yourdon’s notation To help with the analysis phase of the project a Context Diagram and Data Flow

Diagrams (DFD’s) were used in Yourdon’s notation. The Context Diagram is the first

phase in Yourdon’s notation which explains the main processes that would take place in

the database. The Data Flow Diagrams provide a more in-depth view of processes from

the context diagram. They not only explain where the process of information may come

from but also where the information is to be stored within the database.

2.5.1 Diagram Objects The objects used to create the diagrams used in Yourdon’s notation all represent

important parts of the database. The following provides a brief explanation of what

they represent.

2.5.2 Process

The ‘Process’ symbol or otherwise know as

the Data Transform object represents the

processes which must take place inside the

system.

Figure 2.1 Process

2.5.3 Entity

The ‘Entity’ symbol or otherwise known as

the Terminator object has an input into the

system or receives output from it. The

entity does not however exist within the

system itself.

Figure 2.2 Entity

19

2.5.3 Data Flow

The ‘Data Flow’ symbol represents the

direction and destination of the data

flowing within the database.

Figure 2.3 Data Flow

2.5.4 Data Store

The ‘Data Store’ symbol represents where

the different types of data are stored over

time within the database.

Figure 2.4 Data Store

The above data flow diagram symbols and information regarding Yourdon’s notation

can be viewed in greater detail from Systems Development,https://outranet.scm.tees

.ac.uk/users/u0000706/HND_SAD/sad_01%20Systems%20Development%20Life%20Cy

cle.ppt, [4].

20

2.6 Context Diagram

Figure 2.5 Context Diagram

The context diagram shown in Figure 2.5 is a basic overview of the processes and

events that are to exist in the WBL Timesheet database. The following events list

provides a short but precise explanation of each of the above processes.

2.6.1 Events List

1. Student submits timesheet.

2. Student requests holiday.

3. Student suffers sickness.

4. WBL Admin request login.

5. WBL Admin import data.

6. WBL Admin enters timesheet.

7. WBL Admin requests report.

21

2.7 Data Flow Diagrams (DFDs)

2.7.1 Top Level Data Flow Diagram (DFD)

Figure 2.6 Top Level Data Flow Diagram

The Top Level Data Flow Diagram shown in Figure 2.6 is an exploded view of the

context diagram and provides a more detailed overview of the processes that are to exist

within the database. WBL administrators must first login into the database before they

can process any type of transaction. The first transaction the WBL staff will generally

carry out is the import of any new WBL students. Students will submit manual

timesheets to the WBL office where they will be collected and electronically processed

by a member of the WBL admin team. The validation of each student needs to be

checked which will be built into the database as only existing students can have their

timesheets processed.

Students may report periods of sickness to the WBL staff that will automatically

validate the student exists before processing. This will consequently notify the member

of staff if the student in question needs to provide further documentation to support their

period of sickness. Students may also request holidays to be taken from their allocated

entitlement. A validation check is again carried out which ensures the student exists

and also checks if the student has the correct amount of holiday entitlement left to cover

22

the request. On receipt and conditions of the submission of timesheets, students may

receive EMA and/or Travel payments on a weekly basis.

2.8 Low Level Data Flow Diagrams (DFD’s) The following Data Flow Diagrams provide a more in depth view of the processes

shown in the above Top Level Data Flow Diagram.

2.8.1 Process 1.1 “Student Submits Timesheet”.

Figure 2.7 Low Level DFD – Student Submits Timesheet

Students submit their timesheets on a weekly basis. All new timesheets are then filed in

the relevant data store to be processed. Travel and/or EMA are paid to the appropriate

student(s).

23

2.8.2 Process 1.2 “Student Requests Holiday”.

Figure 2.8 Low Level DFD – Student Requests Holiday

A student requests a holiday by submitting the relevant holiday request form. The work

based learning administrator will check the system to validate that the student is an

existing student. Depending upon the student having the correct amount of holidays

required for the holiday request, the request will either be accepted or rejected by the

work based learning administrator. All holiday requests are processed and stored in the

relevant data store.

24

2.8.3 Process 1.3 “Student Suffers Sickness”.

Figure 2.9 Low Level DFD – Student Suffers Sickness

When students suffer a sickness they inform the work based learning administrator who

will first check the system to validate the student exists and secondly will log the

sickness against the students’ record. From this information the system will inform the

administrator if the student is required to complete a Self Certification form or supply a

sick note from their doctor.

25

2.8.4 Process 1.4 “WBL Admin Requests Login”.

Figure 2.10 Low Level DFD – WBL Admin Requests Login

A work based learning administrator makes a request to login to the system. Depending

upon the administrators’ login details the request will either be accepted or rejected. If

the administrator is an existing user then the system will retrieve their details from the

‘Admin Users’ data store. If the administrator is a new user then they must be allocated

a username and password before they can proceed.

26

2.8.5 Process 1.5 “WBL Admin Imports Data”.

Figure 2.11 Low Level DFD – WBL Admin Imports Data

On a daily basis the work based learning administrator must import any new work based

learning students into the database. If successful then any new students will be stored in

the ‘Student Details’ data store. If unsuccessful then the administrator will be informed

of this.

27

2.8.6 Process 1.6 “WBL Admin Enters Timesheet”.

Figure 2.12 Low Level DFD – WBL Admin Enters Timesheet

Student timesheets are entered on a daily basis. The manual timesheets are collected for

processing and students are checked to validate they exist in the system. The

administrator will receive a warning if any student needs further investigation.

28

2.8.7 Process 1.7 “WBL Admin Request Report”.

Figure 2.13 Low Level DFD – WBL Admin Requests Report

Work based learning administrators request all reports in this process. Reports such as

holiday reports, sickness reports, student reports, attendance reports can all be requested

from this process.

29

CHAPTER 3 - DATABASE DESIGN

This chapter focuses on the design of the timesheet database and as previously

mentioned the methodology used to create this phase of the Database Management

System (DBMS) was “The Database System Development Lifecycle” by Database

Solutions, A step-by-step guide to building databases, [3].

“The process of creating a design for a database that will support the

enterprise’s/user’s operations and objectives.”

([3] – Database Solutions, A step-by-step guide to building databases, Page 21)

A database is considered to be a collection of related data and the database management

system is the software that manages and controls access to the database, where as a

database system is considered to be a collection of application programs that

communicate with the database along with the DBMS.

A database can be defined as:

“A database is a complex object for storing structured information, which is

organized and stored in a way that allows quick and efficient retrieval.”

([10] – SQL Server and ADO Programming – Complete, Page 4)

A Database Management System (DBMS) can be defined as:

“A software system that enables users to define, create, and maintain the

database and also provides controlled access to the database.”

[3] – Database Solutions, A step-by-step guide to building databases, Page 8)

A DBMS allows the user to update, insert, delete and retrieve data from a database,

providing a central storage place for data and also allowing the DBMS to provide a

general inquiry facility to the data, called SQL query language.

30

2.1 Database Functionality The timesheet database is to adopt a Microsoft Access Client/Server Application

configuration architecture, more traditionally known as the 2-Tier structure which is

represented in Figure 3.1. It uses Microsoft Access converted to a Microkernel

Development Environment (MDE) format for deployment that connects to an Open

Database Connectivity (ODBC) or ActiveX Data Objects (ADO) compliant data store.

A 2-Tier structure consists of a primary tier that incorporates the presentation logic

which is a user interface that displays data to the user together with the business logic

which is data validation, ensuring it is 100% accurate before adding it to the database.

The secondary tier contains all the data access logic which is the database

communication for accessing the tables etc, more information on the 2-Tier model can

be sought from Microsoft Belgie & Luxemburg,http://www.microsoft.com/belux/msdn

/nl/community/ columns/hyatt/ntier1.mspx, [7].

.

Figure 3.1 A representation of 2-Tier Architecture

Database design is crucial for the system to be accepted by the end user as a poorly

designed database can lead to serious errors with potential repercussions for the

organisation and the timesheet database is no exception.

31

2.2 Database Systems Development Lifecycle The Database Systems Development Lifecycle (DSDLC) came about due to what was

termed as the ‘software crisis’ in the late 1960’s and is still used today. The dramatic

increase in the number of software applications being developed from small to large

complex databases became incredibly hard to maintain and the effort that went in to

maintaining them began to consume huge amounts of resources. The introduction of a

structured approach to the development of software was proposed which is more

commonly known as the information systems (IS) lifecycle or the software development

lifecycle (SDLC), Database Solutions, A step-by-step guide to building databases, [3].

There are several phases to the database systems development lifecycle but for the

purpose of this project the phases used where the Logical Database Design and Physical

Database Design phases. The logical and physical design stages of the model both

represent the development of an individual part of the system.

Logical Database Design

Physical Database Design

Figure 3.2 Database Systems Development Lifecycle

32

2.3 Logical Database Design Logical database design can be defined as:

“The process of constructing a model of the data used in an organisation based

on a specific data model, but independent of a particular DBMS and other

physical considerations”.


The logical database design phase focuses on building a logical representation of the

database, which includes identifying the important entities and relationships and then

translating this representation into a useable set of database tables.

Logical database design consists of two phases. The first involves the creation of an

Entity Relationship (ER) model which will then be checked for any possible

redundancy. The following data dictionary explains the process of identifying the

relevant entities and relationships needed to create the model.

2.4 Data Dictionary

2.4.1 Entities The first step to creating the ER model required the identification of the important user

objects. These user objects are the entities for the model, they where identified by

looking at the user requirements list and where represented in the form of data stores in

the analysis chapter of the project. Table 1.1 is an example of the ‘Student’ entity and

Figure 3.3 is the represented data store. To view a complete description of the entities

identified, refer to Appendix G.

Table 1.1 Student Entity Entity Name Description Aliases Occurrence

Student General term describing all

students enrolled at HCFE.

Student Each student is

enrolled on a course.

33

Figure 3.3 Student Data Store

2.4.2 Relationships After identifying the entities the next step was to identify the relationships that would

exist between the entities. The relationships were identified again by looking at the user

requirements list. This phase also involved specifying the multiplicity of each

relationship. Multiplicity requires constraints that are used to check and maintain the

quality of the data. Using multiplicity constraints in a model clearly represents the

meaning of a relationship and therefore provides a better representation of the model.

Table 1.2 is an example of the ‘Student’ entity which shows the relationships that were

identified. Refer to Appendix H for a complete view of the relationships identified.

Table 1.2 Student Entity - Relationships Entity Multiplicity Relationship Multiplicity Entity

Student

1..1

1..1

1..1

1..1

1..1

1..1

IsEnrolledTo

Suffers

Requests

IsPaid

Receives

Submits

1..*

0..*

0..24

0..*

0..*

1..*

Enrolment

Sickness

Holiday

EMA

Travel

TimesheetAttendance

34

2.4.3 Attributes When the entities and relationships had been identified the next step involved three

steps of its own, associate attributes with the appropriate entities and relationships,

determine attribute domains, and finally determine primary key attributes. Attributes

are the types of facts about entities and relationships, in other words, asking the question

of “What information is required to be held in the database?”

A domain can be defined as:

“A domain is a pool of values from which one or more attributes draw their

values”


A primary key is a key in the database that is unique for each record. It is a unique

identifier e.g. a person’s National Insurance Number. Table 1.3 is a shortened view of

the ‘Student’ entity showing the attributes, attribute domains and the primary key

attributes that were identified. Refer to Appendix I for a complete view of the attributes

identified.

Table 1.3 Student Entity - Attributes Entity Attributes Description Data type &

length Null Primary Key

Student StudentDetailID

AcademicYearID

RefNo

Title

Surname

FirstForename

OtherForenames

DateOfBirth

Sex

Address1

Address2

Address3

Address4

Uniquely identifies a student

Specifies the Academic Year

Student Reference No

Students Title

Students Surname

Students First Forename

Students Other Name

Students Date of Birth

Students Gender

No. & Street of student add

Town of student add

County of student add

Address 4 of student add

int

char(5)

char(12)

char(5)

varchar(40)

varchar(20)

varchar(30)

smalldatetime

char(1)

varchar(50)

varchar(50)

varchar(50)

varchar(50)

NO

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

StudentDetailID

35

2.5 Entity Relationship Diagram (ERD) The Entity Relationship (ER) model shown in Figure 3.4 provides an overall view of the

WBL Timesheet Database. The ER model has been developed through identification of

the important entities and relationships using the data dictionary.

Figure 3.4 Entity Relationship Diagram

36

2.6 Logical Tables The second phase of logical database design involved the creation of a set of tables for

the ER model to represent the entities, relationships, attributes and constraints. The

structure of each of the tables has been developed using the information described in the

ER diagram and data dictionary documentation.

2.6.1 Create Tables To help describe the structure of the tables for the database in a clear and precise

manner, a Database Design Language (DBDL) was used. This DBDL first of all

involved providing a name for each table, followed by the names of the table attributes.

The primary and foreign keys for each table were specified and for each foreign key, the

table containing the referenced primary key was also specified.

Table 1.4 is an example of the ‘Student’ table created to represent the entities,

relationships, attributes and constraints from the ER model. To view the complete set of

tables, refer to Appendix J.

Table 1.4 Logical view of Student table Student (StudentDetailID, AcademicYearID, RefNo, Title,

Surname, FirstForename, OtherForenames, DateOfBirth, Sex, Address1, Address2, Address3, Address4, PostcodeOut, PostcodeIn, Tel1, Tel2, MobileTel, NI, Contact1, ContactTel1, EthnicGroupID, EGDescription, EmployerID, EmployerName, EmpAddress1, EmpAddress2, EmpAddress3, EmpAddress4, EmpPostcodeOut, EmpPostcodeIn, EmpWorkTel, CountryID, CDescription, DisabilityID, DisDescription, LearningDifficultyID, DifDescription, Cohort, CohortStartDate, TravelNo)

Primary Key StudentDetailNo Foreign Key TravelNo references Travel(TravelNo)

37

2.7 Physical Database Design Physical database design can be defined as:

“The process of producing a description of the implementation of the database

on secondary storage; it describes the base tables, file organizations, and indexes

used to achieve efficient access to the data, and any associated integrity

constraints and security restrictions.”.


The physical database design phase focuses on translating the logical database structure,

the entities, attributes, relationships and constraints into a physical database design to

which can then be implemented using the Database Management System (DBMS).

The physical design phase involved translating the tables created in the logical data

model into useable base tables that can be implemented into the timesheet database.

2.8 Physical Tables This step of the methodology involved the creation of the base tables identified in the

logical model.

2.8.1 Create Base Tables To help describe the structure of the base tables for the database an extended form of the

Database Design Language (DBDL) was used to define domains, null indicators,

primary keys and referential integrity constraints for any foreign keys.

Table 1.5 is a shortened example of the ‘Student’ table which defines domains, null

indicators and any primary/foreign key constraints. For further reference of all the base

tables created for the timesheet database, refer to Appendix K.

38

Table 1.5 Physical view of Student table CREATE TABLE [dbo].[Student](

[StudentDetailID] [int] IDENTITY(1,1) NOT NULL,

[AcademicYearID] [char](5) COLLATE Latin1_General_CI_AS NULL,

[RefNo] [char](12) COLLATE Latin1_General_CI_AS NULL,

[Title] [char](5) COLLATE Latin1_General_CI_AS NULL,

[Surname] [varchar](40) COLLATE Latin1_General_CI_AS NULL,

[FirstForename] [varchar](20) COLLATE Latin1_General_CI_AS NULL,

[OtherForenames] [varchar](30) COLLATE Latin1_General_CI_AS NULL,

[DateOfBirth] [smalldatetime] NULL,

[Sex] [char](1) COLLATE Latin1_General_CI_AS NULL,

[Address1] [varchar](50) COLLATE Latin1_General_CI_AS NULL,




[SupervisorID] [int] NULL,

[HolEntitlement] [char](3) COLLATE Latin1_General_CI_AS NULL,

[SickEntitlement] [char](3) COLLATE Latin1_General_CI_AS NULL,

CONSTRAINT [PK_Student] PRIMARY KEY CLUSTERED

(

[StudentDetailID] ASC

)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY],

CONSTRAINT [FK_Student_Supervisor] FOREIGN KEY

(

[SupervisorID]

) REFERENCES [SupervisorID]

),

CONSTRAINT [FK_Student_Travel] FOREIGN KEY

(

[TravelNo]

) REFERENCES [TravelNo] (

[TravelNo]

)

) ON [PRIMARY]

GO

39

2.9 Analysing Transactions In order to carry out the physical design stage of the methodology effectively, a good

understanding of the transactions that are expected to run on the database is essential. It

would be far too time consuming to be expected to analyse every database transaction,

but trying to analyse the most important ones would prove beneficial.

To analyse the most important transactions to be run on the database, a

Transaction/Table Cross-Reference Matrix was used. Table 1.6 shows the table using

the following entry/update/delete, and retrieval queries:

(a) Import new Work Based Learning (WBL) students.

(b) Enter student timesheet information.

(c) Process student holiday request.

(d) Process student sickness.

(e) List all late timesheets.

Table 1.6 Cross-Reference Matrix

Transaction/ Table

(a) (b) (c) (d) (e)

I R U D I R U D I R U D I R U D I R U D

Student X X X X X Enrolment X Sickness X X Holiday X X X X X X EMA Travel T. Attendance X X X X X Mark Type X X Staff Supervisor

I=Insert; R=Read; U=Update; D=Delete

40

2.10 Interface Design

2.10.1 Style & Layout The aesthetics of a database management system are just as import as any website but

should focus not on how creative or artistic it looks but more on the layout and how user

friendly it is. As mentioned earlier in the report about the general requirements of any

user interface, the timesheet database will follow a consistent style and layout

throughout. Each page created in the application will only contain data relevant to its

subject to avoid the pages becoming over busy with too much information. Each page

will clearly identify itself with the use of page titles, the pages will also be designed to

ensure the user cannot get lost by opening up too many pages at one time.

Again as mentioned previously the use of colours and font sizes should be used

consistently throughout any system, therefore the timesheet database will follow a strict

selection of colour and font sizes. The colours to be used will aim to follow the colours

used on the college’s logo to remain in keeping with the college’s theme.

2.10.2 Data Security The security of the data entered and stored in the timesheet database will be dealt with

mainly in the creation of the base tables in SQL Server in the form of integrity

constraints. However, certain fields in the database will need to be read-only to the user

and therefore will need to have the appropriate properties set within the access front-end

to prevent the user from modifying them in any way. The timesheet entry page will be

one of the pages the user is required to enter data, therefore security measures need to

be put in place to ensure only valid data is allowed to be entered and where necessary

the user will be forced to enter data into non-null data fields.

2.10.3 System Security The security for the database will be dealt with in SQL Server. Each user of the

timesheet database will be provided with a login and password together with the

appropriate permissions to access the database.

41

2.11 Page Designs The suggested design of the timesheet database has been attempted in the way of

Microsoft PowerPoint page designs. Figure 3.5 provides an insight into the expected

design of the main front page of the timesheet database. The background colours and

font colours will be used throughout to give a consistent look and feel to the database

using the same colours from the college’s logo. To obtain a complete view all the page

designs, please refer to Appendix L.

Figure 3.5 Expected design of WBL Timesheet Database

42

CHAPTER 4 - DATABASE IMPLEMENTATION

The implementation chapter of the report describes the major areas involved in the

implementation stage of the timesheet database. Although an adequate amount of time

was allocated to the analysis and design stage of the project, a considerable amount of

time and effort went into the implementation stage. Most of the complicated and time

consuming work went into developing the back-end of the database which from a user’s

perspective is basically invisible.

4.1 Development Platform It was required that the WBL Timesheet database be developed using SQL Server as the

back-end or primarily known as the database management system (DBMS) and the

front-end application created using Microsoft Access. To have a direct link to the SQL

Server table from within MS Access an ODBC (Open Database Connectivity) link was

created to do this. An ODBC link is created through the ODBC Data Source

Administrator stored on a local machine. To set up the connection you must first

provide the SQL Server in which to connect to as shown in Figure 4.1.

Figure 4.1 ODBC Data Source – Choose Server

43

The next step required a valid administrator’s Login ID and Password as shown in

Figure 4.2 in order to connect to the database using SQL Server authentication. Having

this ODBC link also meant that only authorised persons could access the database as the

user is prompted for a login and password. Users are given their own login and

password to access the database which are created in SQL Server and assigned the

relevant user permission. These are the two most important steps in setting up a

successful ODBC link.

Figure 4.2 ODBC Data Source – Enter login and password

Once the ODBC link is complete any SQL server table or view can then be linked

directly to MS Access using the Link Table Manager facility which can then be used in

the timesheet database.

44

4.2 Table Implementation The implementation of the database tables were done so using Microsoft SQL Server.

Figure 4.4 shows an example of the Student table and is represented in the form of data

stores (see Figure 4.3) which were previously described in more detail in the analysis

and design phase of the report. The data dictionary that was described in detail in the

design stage of the report contributed to the actual implementation of the SQL Server

tables as this provided all the necessary attributes, attribute domains, primary and

foreign keys or otherwise known in SQL as column name, data types, primary and

foreign key constraints. To view a complete set of database tables refer to Appendix M.

Figure 4.3 Student Data Store

Figure 4.4 Design view of the Student table

45

4.3 Form Implementation The forms created for the front-end application needed to provide the user with all the

necessary features to correctly enter student timesheet information quickly and

efficiently. The colour scheme as previously mentioned was designed to coincide with

Hartlepool College’s existing colour scheme shown on the HCFE logo.

The ‘Home’ page for the WBL Timesheet Database intended to provide a clear but

simple view of the options available to the user within the database as shown in Figure

4.5.

Import Students Button

Figure 4.5 Home page of the WBL Timesheet Database

The “Import Students” button shown above was created to enable the user to easily

import any new work based learning students from the WBL Management Information

System (PICs) to prevent the user from having to manually enter each new student. To

obtain the correct student and enrolment information from the management information

system a stored procedure was created in the SQL Server back-end database.

46

4.3.1 Stored Procedure Import To prevent the user from manually entering new work based learning students and their

enrolment information into the WBL Timesheet Database an import script was created

which could be run on a daily basis to capture any new student records.

CREATE PROCEDURE [dbo].[Student_Import] AS INSERT INTO WBLTimesheets.dbo.Student (StudentDetailID, AcademicYearID, RefNo, Title, Surname, FirstForename, OtherForenames, DateOfBirth, Sex, Address1, Address2, Address3, Address4, PostcodeOut, PostcodeIn, Tel1, Tel2, MobileTel, NI, Contact1, Contact1Tel, EthnicGroupID, EGDescription, EmployerID, EmployerName, EmpAddress1, EmpAddress2, EmpAddress3, EmpAddress4, EmpPostcodeOut, EmpPostcodeIn, EmpWorkTel, CountryID, CDescription, DisabilityID, DisDescription, LearningDifficultyID, DifDescription) SELECT SD.StudentDetailID, SD.AcademicYearID, SD.RefNo, SD.Title, SD.Surname, SD.FirstForename, SD.OtherForenames, SD.DateOfBirth, SD.Sex, SD.Address1, SD.Address2, SD.Address3, SD.Address4, SD.PostcodeOut, SD.PostcodeIn, SD.Tel1, SD.Tel2, SD.MobileTel, SD.NI, SD.Contact1, SD.Contact1Tel, SD.EthnicGroupID, EG.Description, SD.EmployerID, Org.[Name], Org.Address1, Org.Address2, Org.Address3, Org.Address4, Org.PostcodeOut, Org.PostcodeIn, Org.WorkTel, SD.CountryID, C.Description, SD.DisabilityID, Dis.Description, SD.LearningDifficultyID, Dif.Description FROM ProSolution.dbo.StudentDetail SD WITH (NOLOCK) INNER JOIN ProSolution.dbo.Enrolment E WITH (NOLOCK) ON SD.StudentDetailID = E.StudentDetailID LEFT OUTER JOIN ProSolution.dbo.EthnicGroup EG WITH (NOLOCK) ON SD.EthnicGroupID = EG.EthnicGroupID LEFT OUTER JOIN ProSolution.dbo.Organisation Org WITH (NOLOCK) ON SD.EmployerID = Org.OrganisationID LEFT OUTER JOIN ProSolution.dbo.Country C WITH(NOLOCK) ON SD.CountryID = C.CountryID LEFT OUTER JOIN ProSolution.dbo.Disability Dis WITH (NOLOCK) ON SD.DisabilityID = Dis.DisabilityID LEFT OUTER JOIN ProSolution.dbo.LearningDifficulty Dif WITH (NOLOCK) ON SD.LearningDifficultyID = Dif.LearningDifficultyID WHERE SD.StudentDetailID = E.StudentDetailID AND E.IsWBL = 'Y' AND NOT EXISTS (SELECT * FROM WBLTimesheets.dbo.Student S WHERE S.StudentDetailID = SD.StudentDetailID)

Figure 4.6 Stored Procedure for Student_Import

Figure 4.6 was created using a stored procedure, which is a set of pre-defined Transact-

SQL (the programming language of SQL Server) statements which are used to perform

specific tasks.

47

This stored procedure looks at the relevant tables within the Management Information

System (MIS) for any student(s) who are flagged as work based learning. The stored

procedure then looks at the relevant table within the timesheet database to see if the

student(s) already exist. If the student(s) does exist the stored procedure would

terminate. If however, the student(s) did not exist the stored procedure would continue

to import the fields defined within the INSERT INTO section of the stored procedure.

Figure 4.6 shows the Student_Import, to view the Enrolment_Import which imports the

students’ course information, refer to Appendix N.

To allow the user to execute the stored procedure easily from within the front-end

application (Microsoft Access 2003) a Command object was created, which would call

its Execute method to execute the command. This Command object contains the name

of the stored procedure known as the CommandText property which holds the statement

that is sent through the Object Linking and Embedding Database (OLE DB) provider to

the data source. The Command object also sets the ActiveConnection property which

refers to an existing connection that point to the WBL Timesheet database in SQL

Server. Further information regarding the Command object can be sought from SQL

Server and ADO Programming – Complete [8].

Private Sub cmdImportStudents_and_Enrolments_Click() Dim ADOCmd As New ADODB.Command Dim ADOError As ADODB.Error With ADOCmd .ActiveConnection = "Provider=SQLOLEDB.1;Server=YOUR-0CDC4F5844\SQLEXPRESS;Initial Catalog=WBLTimesheets;User ID=sa;Pwd=wbltimesheets" .CommandText = "Student_Import" .CommandType = adCmdStoredProc .Execute End With MsgBox "Students imported successfully!" End Sub

Figure 4.7 Visual Basic Code to execute Command object

Figure 4.7 shows the Visual Basic code that was created to execute the Command object

for “Student_Import”, to view the complete code, refer to Appendix O.

48

4.3.2 Macro – Update/Append The main purpose of the timesheet database was to enable the user to easily enter

student timesheet information and Figure 4.8 provides a screen shot of the implemented

timesheet entry form. This form was the most time consuming of the all the forms

created as this form needed to retrieve student data from one table but at the same time

allow the user to input new timesheet data and view existing timesheet data using other

tables.

Close Button

Figure 4.8 Timesheet Entry Form

Using the ‘On Exit’ property on the close button of the timesheet entry form quite a

complex ‘Macro’ was created to automatically import sickness and holiday information

into the respective sickness and holiday table. As further information was needed for

any sickness or holidays, separate forms were created to avoid the timesheet entry form

becoming over crowded.

49

The import macro on exiting the form would execute a number of steps which included

appending any new students into the Sickness/Holiday tables, append any new

sickness/holiday records and finally update any sickness/holiday records that had been

modified for any reason. The steps of the Macro are shown Figure 4.9.

Figure 4.9 Macro to Update/Append to Sickness & Holiday tables

50

A screen shot of the ‘Student Sickness’ form is shown in Figure 4.10. Further

information is required whenever a student suffers a period of sickness such as the

actual start and end date they were ill and also the reason for their sickness. The student

sickness entitlement is also recorded in this form.

Figure 4.10 Student Sickness Form

51

A screen shot of the ‘Student Holidays’ form is shown in Figure 4.11. Further

information is required whenever a student requests holiday leave such as the actual

start and end date and also the holiday needs to be authorised, this is usually by the

student’s tutor. The student holiday entitlement is also recorded in this form.

Figure 4.11 Student Holidays Form

52

4.3.3 Macros – Create CSV One of the requirements for the WBL Timesheet database was for the user to easily

produce a CSV (Comma Separated Values or sometimes called Comma Delimited) file

automatically for payment of student Travel. At present this process is very inefficient

and time consuming as the WBL admin staff have to manually enter students into an

Excel Spreadsheet every week which is then sent via email to the Finance department

for payments to be processed.

As student travel information is now processed the same time student timesheet

information is entered onto the timesheet database this requirement can now be

automated. To enable this process to become an automated feature within the timesheet

database it was decided that the use of a Macro would be the best option. To create a

Macro to process this task involved several steps.

The first step was to create a user view in SQL Server to find students who were to be

paid travel which is demonstrated in Figure 4.12.

CREATE VIEW vTravelPaymentSheet AS SELECT dbo.TimesheetAttendance.WeekNo, dbo.TimesheetAttendance.WeekCommencingDate, dbo.Student.TravelNo, dbo.Student.RefNo, dbo.Student.Surname + ' ' + dbo.Student.FirstForename AS Student, dbo.TimesheetAttendance.[Travel(£)], dbo.TimesheetAttendance.TravelNotes FROM dbo.Student LEFT OUTER JOIN dbo.TimesheetAttendance ON dbo.Student.StudentDetailID = dbo.TimesheetAttendance.StudentDetailID WHERE (dbo.TimesheetAttendance.IsTravel = 'TRUE')

Figure 4.12 SQL Server View for vTravelPaymentsheet

The view would then be linked into MS Access to be used in the next step of the Macro.

The next step was to create a query in MS Access using the SQL view that would link

directly to a form that would require the user to enter a ‘Week Commencing Date’ to

ensure the report would only create a Travel Payment Sheet for the particular week

53

given. Secondly the query would need to make a table based on the results of the query

to be used as part of the Macro.

As the travel information needed to be exported into a CSV file a template table was

created that would provide a guide as to how the data would appear when it was

exported, to do this the Export Text Wizard in MS Access was used. Next a Visual

Basic Function was created as shown in Figure 4.13, which basically reads the input

file, “Preparation for Spreadsheet – Travel Payment Sheet” and creates a new file in the

correct format for an Excel Spreadsheet using “Spreadsheet Output – Travel Payment

Sheet”.

Function crefile2() Dim dbmyDB As Database Dim rsmyRS As Recordset Dim rs2outRS As Recordset Dim myField As Field Dim ingRecCount As Long Dim newstring As String Dim newref As String Set dbmyDB = CurrentDb Set rsmyRS = dbmyDB.OpenRecordset("Preparation for Spreadsheet - Travel Payment Sheet") Set rs2outRS = dbmyDB.OpenRecordset("Spreadsheet Output - Travel Payment Sheet") If rsmyRS.RecordCount <= 0 Then Exit Function rsmyRS.MoveLast ' count of records ingRecCount = rsmyRS.RecordCount rsmyRS.MoveFirst newstring = "WeekNo,W/C,TravelNo,RefNo,Student,Travel(£),TravelNotes" rs2outRS.AddNew rs2outRS("outputfield") = newstring rs2outRS.Update newstring = "" newref = rsmyRS("RefNo") newstring = rsmyRS("WeekNo") & "," & rsmyRS("W/C") & "," & rsmyRS("TravelNo") & "," & rsmyRS("RefNo") & "," & rsmyRS("Student") & "," & rsmyRS("Travel(£)") & "," & rsmyRS("TravelNotes") For i = 2 To ingRecCount rsmyRS.MoveNext If rsmyRS("RefNo") = newref Then newstring = newstring Else rs2outRS.AddNew rs2outRS("outputfield") = newstring rs2outRS.Update newstring = "" newref = rsmyRS("RefNo") newstring = rsmyRS("WeekNo") & "," & rsmyRS("W/C") & "," & rsmyRS("TravelNo") & "," & rsmyRS("RefNo") & "," & rsmyRS("Student") & "," & rsmyRS("Travel(£)") & "," & rsmyRS("TravelNotes") End If Next 'add final record rs2outRS.AddNew rs2outRS("outputfield") = newstring rs2outRS.Update End Function

Figure 4.13 Function in Visual Basic to generate Excel file format

54

Finally the TransferText and MsgBox actions were used in the Macro which provides

the location for where the file is to be saved and then provides the user with a message

to inform them of the location. The Macro is then assigned to the Travel Payment Sheet

report using the ‘On Click’ property for the user to generate automatically.

4.4 Test & Evaluation Strategy The purpose of testing is not only to test whether the system is providing all the

functionality required by the user but also to test for any errors the system may have.

The test and evaluation strategy for the timesheet database will be based on first testing

the individual components of the system and then the complete system as a whole.

These tests will be carried out using test plans together with documented results.

Various testing methods were carried out to each cover a different aspect of the system

functionality, which were Validation Testing, User Testing and Developer Testing. A

user guide was provided to the users during the testing phase of the WBL Timesheet

Database to assist them in using the database as required. To view the user guide,

please refer to Appendix P.

4.4.1 Validation Testing Validation testing was used to ensure the user was unable to enter irrelevant or

ambiguous data into the timesheet database. The user was asked to enter two new

timesheets into the timesheet entry form. The first entry they were ask to do was to

enter a week commencing date and week number but leave the attendance marks empty

and close the form. Figure 4.14 shows the error message the user would get if they tried

to close the form without completing one or all of the week’s attendance marks. The

‘MarkID’ fields in the dbo_TimesheetAttendance table in SQL have a NOT NULL

constraint and therefore will not allow the five days attendance marks to be empty.

55

Figure 4.14 Timesheet Entry Form – Testing NON-NULL fields

Secondly the user was asked to enter a week of attendances but instead of picking an

option from the attendance mark drop down box to enter a value other than 1- 8 i.e. 10.

Figure 4.15 shows the error message the user would receive if they entered a value into

the drop down box that wasn’t between 1 and 8.

Figure 4.15 Timesheet Entry Form – Testing data validation

The previous two examples and the rest of the validation testing can be viewed in

Appendix Q.

56

4.4.2 User Testing The user testing was a process that was completed at various stages throughout the

development. Allowing the user to be involved in the development proved beneficial as

any design decisions made were clarified by the user to avoid any unnecessary time

wasting. The main items that were included in the user testing documentation were

from the user requirements list defined in the analysis stage of the project, after all the

requirements list was what the user required as a minimum for the database to be a

complete useable system. A full list of the items used in the user testing can be found in

Appendix R.

4.4.3 Developer Testing Developer testing involved a number of operational and functional performance checks

before the system could be released to the users. The following questions were vital in

identifying any errors in the database’s performance and usability.

1 Are all the buttons shown on the main page of the WBL Timesheet

Database in use and working correctly?

No. The Maintenance and Help buttons are not in use, but will be completed as

a future enhancement. All other buttons work correctly.

Notes: The two remaining buttons will be completed as a future enhancement.

2 Is the user prompted for a SQL Server Login before accessing any private

or confidential student information?

Yes. Yes the user is prompted with a SQL Server Login before they are

allowed to access any information.

Notes: None

57

3 Are all the database forms designed to prevent the user from opening up

more than one form at a time i.e. every form opened must be closed before

another can be accessed?

Yes. Each form’s properties have been modified to restrict the user from

having multiple forms open at once.

Notes: None

4 Do all the reports, imports etc work quickly with minimal time delay?

Yes. All reports, imports etc have been tested and they all complete in seconds

which suggests the SQL Server database is executing the commands

efficiently.

Notes: None

58

CHAPTER 5 - CONCLUSIONS

5.1 CRITICAL REVIEW of PROJECT DELIVERABLES

5.1.1 INTRODUCTION The project specification fully describes what was required from the WBL Timesheet

Database which was to build a system that was able to record, monitor and report on the

attendance of Work Based Learning (WBL) students and to provide accurate and timely


paid promptly. A development strategy plan was put in place in the form of a Gant

chart which defines when each phase of the project was undertaken.

5.1.2 SYSTEMS ANALYSIS A systems analysis methodology was implemented and followed throughout to

successfully analyse the key stages in order to proceed to the design and implementation

stages of the project. However, analysing the choice of software application could have

been investigated further as Microsoft Access severely restricted the successfulness of

the system implementation.

5.1.3 SYSTEMS DESIGN A systems design methodology was implemented and followed throughout to obtain a

clear and focused view of the system to be implemented. It highlighted any flaws in the

design of the SQL tables which were quickly rectified to ensure the implementation

could run as smoothly as possible.

5.1.4 SYSTEMS IMPLEMENTATION The systems implementation was less successful as various problems were identified in

this stage which restricted certain requirements of the system being achieved to their

highest functionality. However the systems implementation demonstrates adequately

the steps taken to bring the system to its current state.

59

5.1.5 CRITICAL REVIEW The critical review of the ICA provided a brief but clear discussion of the achievements

of the project and stated any future developments that would transform the system into a

fully functional system.

5.2 CRITICAL REVIEW of PROJECT

5.2.1 PROJECT GOALS The project goal was to utilise the skills already gained through previous years and also

to develop new skills which would be required to help develop the system from

analysis, design through to implementation as well as managing time and

documentation effectively.

5.2.2 PROJECT ACHIEVEMENTS I feel I have utilised my skills gained from my years at the university which have

enabled me to produce project systems that will undoubtedly benefit what I hope will be

a long term career in the field of Information Technology (IT) and believe I have

achieved a good understanding in the management and documentation of IT projects.

5.2.3 PROJECT REFLECTION This project has proven a very worth while experience. It has shown me that what may

look like a fairly simple task to achieve can in fact be a very time consuming difficult

one. At the beginning of this project I would have considered my knowledge of SQL to

be at a very basic level which is probably fair to say that it has made the project more

difficult than I had initially anticipated. My knowledge of Microsoft Access however

has really surprised me. At the start of the project I would have considered my

knowledge to be of an adequate level to successfully develop the intended target system,

however in terms of creating a database for data entry this was largely underestimated.

60

5.3 CRITICAL REVIEW of PRODUCT

5.3.1 PRODUCT GOALS The product objective was to build a system that could record, monitor and report on the

attendance of Work Based Learning (WBL) students and to provide accurate and timely


paid promptly.

5.3.2 PRODUCT ACHIEVEMENTS The most important requirement that was expected from the WBL Timesheet Database

was to successfully show student timesheet information on a weekly basis and to enable

the user to enter student timesheets quickly and efficiently. This requirement has

achieved its objective with much hard work being devoted to it. This area of the system

produced various problems which resulted in other areas of the database receiving less

attention than what was required. As the timesheet entry form was designed as a sub

form within a main form a problem arose that wouldn’t allow the user to add

information into a table linked directly to SQL Server.

After much searching and investigating from books and the internet I came to the

conclusion that the version of SQL Server and Access I was using simply didn’t support

this type of functionality of adding data to a linked SQL table via a sub form. I

therefore had to create temporary tables in access which were used in the sub form and

then create an update/append query to get the data back into the relevant SQL Server

tables. This for several reasons was highly inefficient. It first of all seemed to make the

idea of a SQL Server back-end a pointless option if every time the user entered a

timesheet they had to run an update/append query. It also restricted what information

and actions could be created against the timesheet attendance table.

This problem however was resolved as the development of the database was coming to

an end. I realised in the dbo_TimesheetAttendance table in SQL Server that the primary

key field had not been set to an Identity field. In other words setting it as an identity

field would generate an ID number automatically instead of expecting the user to

provide one. This problem may seem such a small issue but as a result set the project

61

back a number of weeks which could have been avoided had my knowledge of SQL

been greater, on the other hand this little problem actually taught me a lot after days and

days of trying to find a solution to the problem.

Another important requirement was for students and their enrolment information to be

imported into the timesheet database but only if the student did not already exist. The

creation of a stored procedure that extracted the information from the Management

Information System was relatively simple to do. The connection string however that

was needed to enable the stored procedure to be called from within the Microsoft

Access front-end proved more difficult. The connection string which is only several

lines of the Visual Basic code became another contributor to the development of the

database being set back a number of weeks.

Again after much searching and investigating from books and the internet I eventually

found the problem. The connection string I was using initially was only compatible for

SQL Server 2000 and Microsoft Access 2000. The versions I was using were SQL

Server 2005 and Access 2003 which had a slight modification to the name of the

parameters used in the connection string. The modification made was from Data

Source to Server and Password to Pwd. Figure 5.1 shows both connection strings in

full and also the modifications made.

Old Connection String: .ActiveConnection = "Provider=SQLOLEDB.1;Data Source=YOUR-0CDC4F5844\

SQLEXPRESS;Initial Catalog=WBLTimesheets;User ID=sa;Password=wbltimesheets"

New Connection String: .ActiveConnection = "Provider=SQLOLEDB.1;Server=YOUR-0CDC4F5844\

SQLEXPRESS;Initial Catalog=WBLTimesheets;User ID=sa;Pwd=wbltimesheets".

Figure 5.1 Visual Basic code for New & Old Connection Strings

The above two problems were major contributors in to the reasons why some of the user

requirements were completed to a satisfactory level but will need considerable

improvement.

62

The following is a list of the user requirements that were mentioned previously in the

introduction which states whether or not they were achieved:

Table 5.1 User Requirements – Achieved/NotAchieved?

User Requirement

Achieved? Improvement

Needed?

Must show timesheet information for each week. √

Notification required after two late timesheets. √ √

Notification required after four late timesheets. √ √

System must be able to distinguish between Education

Maintenance Allowance (EMA) & Travel & also whether the

student is claiming one or the other, both or neither.

√

Must show individual periods of sickness. √

Notification required showing individual sickness periods e.g. > 5

working days.

√

Notification required when a student has had 4 separate periods

of sickness.

√ √

Notification required continuously after 4 separate periods of

sickness.

Χ √

Must show individual holidays. √

Notification required for holidays not accrued as student is

entitled to 2 per month.

√ √

Notification required when a student has used all of their holiday

entitlement i.e. >24.

√ √

Notification required continuously after all 24 holidays have been

used within the specified academic year.

Χ √

5.3.3 PRODUCT EVALUATION The end product has achieved what was expected from it in that the user is fully able to

enter a student timesheet on a weekly basis, easily identify if they are to receive EMA,

Travel, both or neither and successfully record and monitor student holiday and sickness

information.

63

5.3.4 PRODUCT REFLECTION Given the chance to implement such a system again I would not use Microsoft Access

as the front-end application. Access does not seem to provide a flexible user interface

as I felt I was very restricted in the way it allowed me to design and implement the

timesheet database. However the product has been an overall success in that it does

what the user initially requested and the only issue I have is with the front-end

application which works fine but by implementing the database with a more flexible and

dynamic front-end would have made the database appear much more professional.

5.4 CRITICAL REVIEW of PERSONAL DEVELOPMENT My previous year’s studies from HNC/D through to degree level have all contributed to

my ability to undertake this project. Many of the modules have played a key role in my

skills and personal development, some more than others. The following modules I feel

have been of particular value are:

• Advanced Database Applications

• Systems, Analysis and Design

• Principals of Visual Basic

• Database Development

• Individual Project 1 & 2

• Database Systems

• Advanced Database Systems

Advanced Database Applications have provided me with underlying knowledge

required to develop databases created using Microsoft Access and from that I am

continually improving my access skills from both university modules and my place of

work.

Systems, Analysis and Design (SAD) have provided me with the ability to model a

database system and take it through the development stages to producing a working

system. It has taught me the understanding and importance of implementing a

structured methodology to a database system which is vital for my long term

development skills. I have adopted a systems methodology, which will structure the

64

development of future projects. This methodology was supported by various data

models such as Data Flow Diagrams and Entity Relationship Diagrams, which has

undoubtedly proved to be a major factor in identifying the database performance

requirements.

Principles of Visual Basic provided me with the basic knowledge I needed and from that

I have continued to use the language in various other applications including this project.

Further development of my knowledge of Visual Basic however, has come from self

learning in the way of academic books etc.

Database Development provided me with my first encounter with SQL Server in

developing server based databases and from this I am continually improving my skills

through projects from both university and my place of work. Various other modules

such as my Individual Projects, Database Systems and Advanced Database Systems

have also helped in further developing my SQL skills together with modelling skill

techniques.

I feel my personal development skills in areas such as problem solving and

communication have given me the confidence to undertake such projects in the future as

I feel I have taken on a consultant role in working with a client to build a system and

working towards a defined set of goals.

My overall knowledge of database systems has increased significantly which has mainly

come from weeks and weeks of searching and investigating various forms of research

i.e. books, internet to obtain the answers and solutions needed to resolve my many

database problems. It has been a greatly rewarding experience and learning opportunity

that has resulted in me adopting a more valuable methodical approach to database

development.

65

CHAPTER 6 - RECOMMENDATIONS

The following recommendations have been identified as future developments for

various reasons such as time limitations and system complications.

6.1 Late Timesheet Warning To currently check on late timesheets a report was written to identify this. The

timesheet database would benefit greatly if a warning was to appear on the timesheet

entry form when a student has two late timesheets against his record. This way the user

can instantly know by looking at a student’s timesheets if there is a problem which

could affect their Education Maintenance Allowance (EMA) or Travel payments.

6.2 Period of Sickness Warning To currently check how many separate periods of sickness a student has had the user

has to run a report. The timesheet database would benefit greatly if a warning was to

appear against the students sickness to inform the user how many individual periods of

sickness a student has had, if any. The user can then instantly know if the student is to

submit further documentation. The warning should appear continuously after 4

individual periods of sickness.

6.3 Holidays not Accrued Warning The user is currently provided with a calculated field to inform them of how many

holidays a student has remaining. The database could be modified to calculate the

current number of holidays accrued to date, to ensure the student has the required

number holidays that they have requested.

6.4 Holiday Entitlement Warning The timesheet database would benefit greatly if a waning could appear against the

students holidays to inform the user when a student has used all of their holiday

entitlement in one academic year.

66

REFERENCES

[1] LSC Requirements for Funding Work-based Learning for Young

People and Adults 2007/08, 2007

[2] EMA: Directgov – Education and learning,

http://ema.direct.gov.uk/ema.html

[3] Connolly T M Database Solutions, A step-by-step guide to building databases,

& Begg C E 2000

[4] Nawaz M Systems Development,

https://outranet.scm.tees.ac.uk/users/u0000706/HND_SAD/sad_01

%20Systems%20Development%20Life%20Cycle.ppt

[5] Fisher R P Information Systems Security, 1984

[6] Castano S et al Database Security, 1994

[7] Microsoft Belgie & Luxemburg,

http://www.microsoft.com/belux/msdn/nl/community/columns/hya

tt/ntier1.mspx

[8] Mills R SQL Server and ADO Programming – Complete, 2001

67

APPENDIX A SPECIFICATION PROJECT TITLE: Work-based Learning – Timesheet Database PROPOSER: Hartlepool College of Further Education From : Andrea StewartEmail: [email protected] Submit To: MANSHA NAWAZEmail : [email protected] SUBMISSION Feb 2008HARDWARE: Pentium PC SOFTWARE: Microsoft Access & SQL Query Analyser KEYWORDS Work-based Learning (WBL) Timesheet Database Project Environment:

A Timesheet database is to be developed to enable the Work Based Learning (WBL) Division at Hartlepool College of Further Education to record on a daily basis the timesheet attendance of students on either an Advanced Modern Apprenticeship (AMA) or a Foundation Modern Apprenticeship (FMA). The database will need to log any type of attendance mark, whether it is present, absent, holiday etc. Objectives: The database is intended to link to PICS, our Management Information System (MIS) as all WBL students are enrolled onto their appropriate course here. This will then give a basis for all students required to fill in a timesheet. It is intended that a member of the WBL team will have the facility to import on a daily basis any new WBL students into the timesheet database. The import will transfer the students personal and course details for information purposes. The timesheet database will link to the MIS system via an ODBC link. The timesheet database will not just be for recording timesheet attendance but will also provide the WBL team with many reports to maintain and analyse the students contained within the timesheet database. The reports will be created using a combination of SQL and Microsoft Access. WBL students are also entitled to Education Maintenance Allowance which is paid weekly and only to those students who have 100% every week. This means that the database will also need to generate reports or in some way provide the finance section with the relevant information in order for the students to be paid on time every week. Product Aims: The aim of a Work-based Learning Timesheet Database is to give the work based learning administrators the facility to monitor and record student attendances in order to provide accurate payments to students on apprenticeships. Analysis Stage: A full systems investigation will take place to determine what the system requirements are. A proposed model will be formulated, agreed and documented. Design Stage: Determine how the system requirements (analysis) are to be met and achieved. Produce a design specification to provide the information necessary to build the system.

68

Implementation Stage: Determine the system functions to be implemented in the time scale remaining. Build the relevant systems functions by coding the tables, forms, queries & reports. Test individual components and the complete system by following a test plan. Produce and document relevant test plans and results. Maintenance Stage: Produce the maintenance documentation which covers User Guides, Operation strategy for changeover from old to new, maintenance (fine tuning/bug fixing/upgrade) and Future enhancements. Academic Aim: To utilise the skills and knowledge gained in HND Computing (IT) modules, in particular, Applications in IT, Systems Analysis & Design, Database Development, and Internet Introduction. Research and adopt a Systems Methodology for project development. Gain new skills and knowledge in the area of Web Hosting. Resources & Constraints The choice of hardware & software will be restricted to that available in the School of Computing. Conform to the UoT standards for coding & documentation. Schedule: It is intended that all stages of the project will be completed within the time scales of 26 weeks. The approximate schedule is – Analysis (8 weeks), Design (8 weeks), Implementation (10 weeks), and Documentation to be completed over a 26 week period.

Instructions: Email specification to project co-ordinator [email protected] Email specification as a MS Word document with the file name format ps.surname.initials.doc

69

APPENDIX B WORK BASED LEARNING TIMESHEET

70

APPENDIX C SELF-CERTIFICATION OF ABSENCE

71

72

APPENDIX D HOLIDAY BOOKING FORM

APPENDIX E DEVELOPMENT SCHEDULE PLAN

73

APPENDIX F BCS CODE OF CONDUCT

BCS Code of Conduct

Introduction

This Code sets out the professional standards required by the Society as a condition of membership. It applies to members of all grades, including students, and affiliates, and also non-members who offer their expertise as part of the Society's Professional Advice Register.

Within this document, the term 'relevant authority' is used to identify the person or organisation which has authority over your activity as an individual. If you are a practising professional, this is normally an employer or client. If you are a student, this is normally an academic institution.

The Code governs your personal conduct as an individual member of the BCS and not the nature of business or ethics of the relevant authority. It will, therefore, be a matter of your exercising your personal judgement in meeting the Code's requirements.

Any breach of the Code of Conduct brought to the attention of the Society will be considered under the Society's disciplinary procedures. You should also ensure that you notify the Society of any significant violation of this Code by another BCS member.

The Public Interest Duty to Relevant Authority Duty to the Profession Professional Competence and Integrity

The Public Interest 1. You shall carry out work or study with due care and diligence in accordance with the relevant authority's requirements, and the interests of system users. If your professional judgement is overruled, you shall indicate the likely risks and consequences. - The crux of the issue here, familiar to all professionals in whatever field, is the potential conflict between full and committed compliance with the relevant authority's wishes, and the independent and considered exercise of your judgement. - If your judgement is overruled, you are encouraged to seek advice and guidance from a peer or colleague on how best to respond. 2. In your professional role you shall have regard for the public health, safety and environment. - This is a general responsibility, which may be governed by legislation, convention or protocol. - If in doubt over the appropriate course of action to take in particular circumstances you should seek the counsel of a peer or colleague. 3. You shall have regard to the legitimate rights of third parties. - The term 'third Party' includes professional colleagues, or possibly competitors, or members of 'the public' who might be affected by an IS project without their being directly aware of its existence. 4. You shall ensure that within your professional field/s you have knowledge and understanding of relevant legislation, regulations and standards, and that you comply with such requirements. - As examples, relevant legislation could, in the UK, include The UK Public Disclosure Act, Data Protection or Privacy legislation, Computer Misuse law, legislation concerned with the export or import of technology, possibly for national security reasons, or law relating to intellectual property. This list is not exhaustive, and you should ensure that you are aware of any legislation relevant to your professional responsibilities. - In the international context, you should be aware of, and understand, the requirements

74

of law specific to the jurisdiction within which you are working, and, where relevant, to supranational legislation such as EU law and regulation. You should seek specialist advice when necessary. 5. You shall conduct your professional activities without discrimination against clients or colleagues - Grounds of discrimination include race, colour, ethnic origin, sexual orientation - All colleagues have a right to be treated with dignity and respect. - You should adhere to relevant law within the jurisdiction where you are working and, if appropriate, the European Convention on Human Rights. - You are encouraged to promote equal access to the benefits of IS by all groups in society, and to avoid and reduce 'social exclusion' from IS wherever opportunities arise. 6. You shall reject any offer of bribery or inducement.

Back to top

Duty to Relevant Authority

7. You shall avoid any situation that may give rise to a conflict of interest between you and your relevant authority. You shall make full and immediate disclosure to them if any conflict is likely to occur or be seen by a third party as likely to occur.

8. You shall not disclose or authorise to be disclosed, or use for personal gain or to benefit a third party, confidential information except with the permission of your relevant authority, or at the direction of a court of law.

9. You shall not misrepresent or withhold information on the performance of products, systems or services, or take advantage of the lack of relevant knowledge or inexperience of others.

Back to top

Duty to the Profession

10. You shall uphold the reputation and good standing of the BCS in particular, and the profession in general, and shall seek to improve professional standards through participation in their development, use and enforcement.

- As a Member of the BCS you also have a wider responsibility to promote public understanding of IS - its benefits and pitfalls - and, whenever practical, to counter misinformation that brings or could bring the profession into disrepute. - You should encourage and support fellow members in their professional development and, where possible, provide opportunities for the professional development of new members, particularly student members. Enlightened mutual assistance between IS professionals furthers the reputation of the profession, and assists individual members.

11. You shall act with integrity in your relationships with all members of the BCS and with members of other professions with whom you work in a professional capacity.

12. You shall have due regard for the possible consequences of your statements on others. You shall not make any public statement in your professional capacity unless you are properly qualified and, where appropriate, authorised to do so. You shall not purport to represent the BCS unless authorised to do so.

- The offering of an opinion in public, holding oneself out to be an expert in the subject in question, is a major personal responsibility and should not be undertaken lightly. - To give an opinion that subsequently proves ill founded is a disservice to the profession, and to the BCS.

75

13. You shall notify the Society if convicted of a criminal offence or upon becoming bankrupt or disqualified as Company Director.

Back to top

Professional Competence and Integrity

14. You shall seek to upgrade your professional knowledge and skill, and shall maintain awareness of technological developments, procedures and standards which are relevant to your field, and encourage your subordinates to do likewise.

15. You shall not claim any level of competence that you do not possess. You shall only offer to do work or provide a service that is within your professional competence.

- You can self-assess your professional competence for undertaking a particular job or role by asking, for example,

i. am I familiar with the technology involved, or have I worked with similar technology before? ii. have I successfully completed similar assignments or roles in the past? iii. can I demonstrate adequate knowledge of the specific business application and requirements successfully to undertake the work?

16. You shall observe the relevant BCS Codes of Practice and all other standards which, in your judgement, are relevant, and you shall encourage your colleagues to do likewise.

17. You shall accept professional responsibility for your work and for the work of colleagues who are defined in a given context as working under your supervision.

76

APPENDIX G DATA DICTIONARY: ENTITIES Entity Name Description Aliases Occurrence

Student General term describing

all students enrolled at

HCFE.

Student Each student is

enrolled on a course.

Enrolment A specific course a

student is enrolled to.

Enrolment Each enrolment is

assigned to only one

student.

Sickness Records periods of

sickness.

Sickness and Sick A student can have

more than one period

of sick.

Holiday Records holidays. Holiday Students entitled to

24 holidays per

academic year.

EMA Records EMA students

& payments.

EMA Students are paid

EMA on a weekly

basis.

Travel Records Travel students

& payments.

Travel Students are paid

Travel on a weekly

basis.

TimesheetAttendance Records the student

timesheet attendance.

Attendance and

Timesheet

Students hand in one

timesheet per week.

MarkType List of attendance

marks.

Mark and Mark

Type

Mark indicates the

type of attendance of

a student.

Staff Members of staff

authorised to use the

timesheet database

Staff and

Administrator

Staff process

timesheets, holidays,

sickness etc.

Supervisor Supervisors are

responsible for the

supervision of student

work.

Supervisor and

Monitor

Each student is

assigned only one

supervisor.

77

APPENDIX H DATA DICTIONARY: RELATIONSHIPS Entity Multiplicity Relationship Multiplicity Entity

Student

1..1

1..1

1..1

1..1

1..1

1..1

IsEnrolledTo

Suffers

Requests

IsPaid

Receives

Submits

1..*

0..*

0..24

0..*

0..*

1..*

Enrolment

Sickness

Holiday

EMA

Travel

TimesheetAttendance

Staff 1..1

1..1

1..1

1..1

Imports

Imports

Processes

Processes

0..*

0..*

0..*

0..*

Student

Enrolment

Holiday

Sickness

Supervisor 1..1 AssignedTo 1..* Student

TimesheetAttendance 1..1

1..1

Generates

Generates

0..*

0..*

EMA

Travel

MarkType 1..1 Indicates 1..* TimesheetAttendance

78

APPENDIX I DATA DICTIONARY: ATTRIBUTES Entity Attributes Description Data type &

length Null Primary Key

Student StudentDetailID

AcademicYearID

RefNo

Title

Surname

FirstForename

OtherForenames

DateOfBirth

Sex

Address1

Address2

Address3

Address4

PostcodeOut

PostcodeIn

Tel1

Tel2

MobileTel

NI

Contact1

ContactTel1

EthnicGroupID

EGDescription

EmployerID

EmployerName

EmpAddress1

EmpAddress2


Specifies the Academic Year

Student Reference No

Students Title

Students Surname

Students First Forename

Students Other Name

Students Date of Birth

Students Gender

No. & Street of student

address

Town of student address

County of student address

Address 4 of student

address

Postcode Out of student

address

Postcode In of student

address

Telephone number 1 of

student

Telephone number 2 of

student

Mobile number of student

National Insurance number

of student

Emergency contact for

student

Emergency contact

telephone number for

student

Students ethnicity ID

Students ethnicity

Students employer ID

Students employer name

No. & Street of employer

address

Town of employer address

int

char(5)

char(12)

char(5)

varchar(40)

varchar(20)

varchar(30)

smalldatetime

char(1)

varchar(50)

varchar(50)

varchar(50)

varchar(50)

varchar(5)

varchar(5)

varchar(20)

varchar(20)

varchar(20)

char(9)

varchar(100)

varchar(20)

int

varchar(50)

int

varchar(50)

varchar(80)

varchar(50)

NO

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

StudentDetailID

79

EmpAddress3

EmpAddress4

EmpPostcodeOut

EmpPostcodeIn

EmpWorkTel

CountryID

CDescription

DisabilityID

DisDescription

Learning

DifficultyID

DifDescription

Cohort

CohortStartDate

TravelNo

CreatedBy

CreatedDate

SupervisorID

HolidayEntitlement

SickEntitlement

County of employer address

Address 4 of employer

address

Postcode Out of employer

address

Postcode In of employer

address

Telephone number of

employer

Country ID student is from

Country student is from

Students disability ID

Students disability

Students learning difficultyID

Students learning difficulty

Students cohort

Cohort start date

Students travel number

Person who created entry

Date entry was created

Students Supervisor

Students holiday entitlement

Students sickness

entitlement

varchar(50)

varchar(50)

varchar(5)

varchar(5)

varchar(25)

int

varchar(50)

int

varchar(50)

int

varchar(50)

varchar(50)

datetime

int

varchar(50)

datetime

int

char(3)

char(3)

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

Enrolment EnrolmentID

CourseCode

CourseTitle

StartDate

ExpEndDate

ActEndDate

Completion

StatusID

CSDescription

IsWBL

StudentDetailID

CreatedBy

CreatedDate

Uniquely identifies an

enrolment

Enrolment course code

Enrolment title

Enrolment start date

Enrolment expected end

date

Enrolment actual end date

Enrolment completion status

ID

Enrolment completion status

States if enrolment is WBL

or not




int

varchar(24)

varchar(255)

datetime

datetime

datetime

int

varchar(50)

char(1)

int

varchar(50)

datetime

NO

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

EnrolmentID

Sickness SicknessID Uniquely identifies a period int NO SicknessID

80

StudentDetailID

WeekCommencing

Date

StartDate

EndDate

NoOfDays

Reason

CreatedBy

CreatedDate

LastModifiedBy

LastModifiedDate

Timesheet

AttendanceID

of sickness


Week commencing date of a

period of sickness

Sickness start date

Sickness end date

No of days sick

Sickness reason



Last modified person

Last modified date

Uniquely identifies a

timesheet attendance

int

datetime

datetime

datetime

char(3)

char(100)

varchar(50)

datetime

varchar(50)

datetime

int

NO

NO

YES

YES

YES

YES

YES

YES

YES

YES

YES

Holiday HolidayID

StudentDetailID

WeekCommencing

Date

StartDate

EndDate

NoOfDays

DaysRemaining

AuthorisedBy

CreatedBy

CreatedDate

LastModifiedBy

LastModifiedDate

Timesheet

AttendanceID

Uniquely identifies a holiday

period



period of sickness

Sickness start date

Sickness end date

No of days sick

No of days holiday

remaining

Holiday authorised by




Last modified date



int

int

datetime

datetime

datetime

char(3)

char(3)

char(30)

varchar(50)

datetime

varchar(50)

datetime

int

NO

NO

NO

YESY

ES

YES

YES

YES

YES

YES

YES

YES

HolidayID

EMA EMANo

Date

Paid

Amount

StudentDetailID

Timesheet

AttendanceID

CreatedBy

CreatedDate

Uniquely identifies an EMA

payment

Date EMA paid on

EMA paid

Amount of EMA paid






int

datetime

char(1)

money

int

int

varchar(50)

datetime

NO

YES

YES

YES

YES

YES

YES

YES

EMANo

81

LastModifiedBy

LastModifiedDate


Last modified date

varchar(50)

datetime

YES

YES

Travel TravelNo

PayrollNo

WeekNo

Date

Paid

Amount

Bonus

StudentDetailID

Notes

Timesheet

AttendanceID

CreatedBy

CreatedDate

LastModifiedBy

LastModifiedDate

Uniquely identifies a travel

payment


students payroll

Travel payment week

number

Date travel paid on

Paid? Yes/No

Amount of travel paid

Amount of bonus paid


Notes about travel






Last modified date

int

int

char(2)

datetime

bit

money

money

int

text

int

varchar(50)

datetime

varchar(50)

datetime

NO

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

YES

TravelNo

Timesheet

Attendance

Timesheet

AttendanceID

StudentDetailID

WeekCommencing

Date

WeekNo

MonMarkID

TueMarkID

WedMarkID

ThurMarkID

FriMarkID

Notes/Reasons

SelfCertReceived

IsEMA

EMANotes

IsTravel

Travel(£)

TravelNotes

CreatedBy

CreatedDate

LastModifiedBy





timesheet

Week number of a timesheet

Mark ID for Monday

Mark ID for Tuesday

Mark ID for Wednesday

Mark ID for Thursday

Mark ID for Friday

Timesheet notes/reasons

Self certification received?

Yes/No

Is student EMA? Yes/No

EMA notes

Is student to receive travel?

Yes/No

Amount of travel to be paid

Travel notes




int

int

datetime

char(2)

int

int

int

int

int

text

bit

bit

text

bit

money

text

varchar(50)

datetime

varchar(50)

NO

NO

NO

NO

NO

NO

NO

NO

NO

YES

YES

NO

YES

NO

YES

YES

YES

YES

YES

Timesheet

AttendanceID

82

LastModifiedDate

Last modified date

datetime

YES

MarkType MarkTypeID

Mark

Description

Uniquely identifies an

attendance mark

Attendance mark code

Attendance mark description

int

char(1)

char(20)

NO

YES

YES

MarkTypeID

Staff StaffID

Username

Password

Title

Surname

FirstForename

Othername

DateOfBirth

Sex


member of staff

Staff username

Staff password

Staff title

Staff surname

Staff first forename

Staff othername

Staff date of birth

Staff gender

int

varchar(50)

varchar(50)

char(5)

varchar(40)

varchar(20)

varchar(30)

datetime

char(1)

NO

NO

NO

YES

YES

YES

YES

YES

YES

StaffID

Supervisor SupervisorID

Username

Code

Surname

FirstForename

Title

JobTitle

Type

Status

Address1

Address2

Address3

Address4

PostcodeOut

PostcodeIn

Tel1

MobileTel

Email

Quals

Subjects

Notes

Sex

Ethnicity

DisAbCode

EvPICSUser


supervisor

Supervisor username

Supervisor code

Supervisor surname

Supervisor first forename

Supervisor title

Supervisor job title

Supervisor type

Supervisor status

Supervisor address 1




Supervisor PostcodeOut

Supervisor PostcodeIn

Supervisor Tel

Supervisor Mobile

Supervisor email

Supervisor qualifications

Supervisor qual subjects

Supervisor noted

Supervisor gender

Supervisor ethnicity

Supervisor disability code

Supervisor EV PICS user

int

nvarchar(8)

varchar(5)

varchar(40)

varchar(20)

char(12)

varchar(30)

varchar(50)

varchar(5)

varchar(50)

varchar(50)

varchar(50)

varchar(50)

varchar(5)

varchar(5)

varchar(20)

varchar(20)

varchar(30)

text

text

text

char(1)

char(2)

char(2)

nvarchar(8)

SupervisorID

83

APPENDIX J LOGICAL: CREATE TABLES

Student (StudentDetailID, AcademicYearID, RefNo, Title, Surname, FirstForename, OtherForenames, DateOfBirth, Sex, Address1, Address2, Address3, Address4, PostcodeOut, PostcodeIn, Tel1, Tel2, MobileTel, NI, Contact1, ContactTel1, EthnicGroupID, EGDescription, EmployerID, EmployerName, EmpAddress1, EmpAddress2, EmpAddress3, EmpAddress4, EmpPostcodeOut, EmpPostcodeIn, EmpWorkTel, CountryID, CDescription, DisabilityID, DisDescription, LearningDifficultyID, DifDescription, Cohort, CohortStartDate, TravelNo, CreatedBy, CreatedDate, SupervisorID, HolEntilement, SickEntitlement)

Primary Key StudentDetailID Foreign Key SupervisorID references

Supervisor(SupervisorID) Foreign Key TravelNo references Travel(TravelNo)

Enrolment (EnrolmentID, CourseCode, CourseTitle, StartDate,

ExpEndDate, ActEndDate, CompletionStatusID, CSDescription, IsWBL, StudentDetailID, CreatedBy, CreatedDate)

Primary Key EnrolmentID Foreign Key StudentDetailID references

Student(StudentDetailID)

Sickness (SicknessID, StudentDetailID, WeekCommencingID,

StartDate, EndDate, NoOfDays, Reason, CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate, TimesheetAttendanceID)

Primary Key SicknessID Foreign Key StudentDetailID references

Student(StudentDeatilID) Foreign Key TimesheetAttendanceID references

TimesheetAttendance(TimesheetAttendanceID)

84

Holiday (HolidayID, StudentDetailID, WeekCommencingID, StartDate, EndDate, NoOfDays, DaysRemaining, AuthorisedBy, CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate, TimesheetAttendanceID)

Primary Key HolidayID Foreign Key StudentDetailID references

Student(StudentDetailID) Foreign Key TimesheetAttendanceID references


EMA (EMANo, Date, Paid, Amount, StudentDetailID, TimesheetAttendanceID, CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate)

Primary Key EMANo Foreign Key StudentDetailID references



Travel (TravelNo, PayrollNo, WeekNo, Date, Paid, Amount,

Bonus, StudentDetailID, Notes, TimesheetAttendanceID, CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate)

Primary Key TravelNo Foreign Key StudentDetailID references



Timesheet (TimesheetAttendanceID, StudentDetailID, Attendance WeekCommencingDate, WeekNo, MonMarkID, TueMarkID,

WedMarkID, ThurMarkID, FriMarkID, Notes/Reasons, SelfCertReceived, IsEMA, EMANotes, IsTravel, Travel(£), TravelNotes, CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate)

Primary Key TimesheetAttendanceID Foreign Key StudentDetailID references

Student(StudentDetailID) MarkType (MarkTypeID, Mark, Description)

Primary Key MarkTypeID

85

APPENDIX K PHYSICAL: CREATE BASE TABLES

K.1 Base table for dbo.Student CREATE TABLE [dbo].[Student]( [StudentDetailID] [int] IDENTITY(1,1) NOT NULL, [AcademicYearID] [char](5) COLLATE Latin1_General_CI_AS NULL, [RefNo] [char](12) COLLATE Latin1_General_CI_AS NULL, [Title] [char](5) COLLATE Latin1_General_CI_AS NULL, [Surname] [varchar](40) COLLATE Latin1_General_CI_AS NULL, [FirstForename] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [OtherForenames] [varchar](30) COLLATE Latin1_General_CI_AS NULL, [DateOfBirth] [smalldatetime] NULL, [Sex] [char](1) COLLATE Latin1_General_CI_AS NULL, [Address1] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Address2] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Address3] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Address4] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [PostcodeOut] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [PostcodeIn] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [Tel1] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [Tel2] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [MobileTel] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [NI] [char](9) COLLATE Latin1_General_CI_AS NULL, [Contact1] [varchar](100) COLLATE Latin1_General_CI_AS NULL, [Contact1Tel] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [EthnicGroupID] [int] NULL, [EGDescription] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [EmployerID] [int] NULL, [EmployerName] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [EmpAddress1] [varchar](80) COLLATE Latin1_General_CI_AS NULL, [EmpAddress2] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [EmpAddress3] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [EmpAddress4] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [EmpPostcodeOut] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [EmpPostcodeIn] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [EmpWorkTel] [varchar](25) COLLATE Latin1_General_CI_AS NULL, [CountryID] [int] NULL, [CDescription] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [DisabilityID] [int] NULL, [DisDescription] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [LearningDifficultyID] [int] NULL, [DifDescription] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Cohort] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CohortStartDate] [datetime] NULL, [TravelNo] [int] NULL, [CreatedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CreatedDate] [datetime] NULL CONSTRAINT [DF_Student_CreatedDate] DEFAULT (getdate()), [SupervisorID] [int] NULL, [HolEntitlement] [char](3) COLLATE Latin1_General_CI_AS NULL, [SickEntitlement] [char](3) COLLATE Latin1_General_CI_AS NULL, CONSTRAINT [PK_Student] PRIMARY KEY CLUSTERED ( [StudentDetailID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY],

86

CONSTRAINT [FK_Student_Supervisor] FOREIGN KEY ( [SupervisorID] ) REFERENCES [SupervisorID] ), CONSTRAINT [FK_Student_Travel] FOREIGN KEY ( [TravelNo] ) REFERENCES [TravelNo] ( [TravelNo] ) ) ON [PRIMARY] GO

K.2 Base table for dbo.Enrolment CREATE TABLE [dbo].[Enrolment]( [EnrolmentID] [int] IDENTITY(1,1) NOT NULL, [CourseCode] [varchar](24) COLLATE Latin1_General_CI_AS NULL, [CourseTitle] [varchar](255) COLLATE Latin1_General_CI_AS NULL, [StartDate] [datetime] NULL, [ExpEndDate] [datetime] NULL, [ActEndDate] [datetime] NULL, [CompletionStatusID] [int] NULL, [CSDescription] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [IsWBL] [char](1) COLLATE Latin1_General_CI_AS NULL, [StudentDetailID] [int] NOT NULL, [CreatedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CreadtedDate] [datetime] NULL CONSTRAINT [DF_Enrolment_CreadtedDate] DEFAULT (getdate()), CONSTRAINT [PK_Enrolment] PRIMARY KEY CLUSTERED ( [EnrolmentID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY], CONSTRAINT [FK_Enrolment_Student] FOREIGN KEY ( [StudentDetailID] ) REFERENCES [StudentDetailID] ( [StudentDetailID] ) ) ON [PRIMARY] GO

87

K.3 Base table for dbo.Sickness CREATE TABLE [dbo].[Sickness]( [SicknessID] [int] IDENTITY(1,1) NOT NULL, [StudentDetailID] [int] NOT NULL, [WeekCommencingDate] [datetime] NOT NULL, [StartDate] [datetime] NULL, [EndDate] [datetime] NULL, [NoOfDays] [char](3) COLLATE Latin1_General_CI_AS NULL, [Reason] [char](100) COLLATE Latin1_General_CI_AS NULL, [CreatedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CreatedDate] [datetime] NULL CONSTRAINT [DF_Sickness_CreatedDate] DEFAULT (getdate()), [LastModifiedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [LastModifiedDate] [datetime] NULL, [TimesheetAttendanceID] [int] NULL, CONSTRAINT [PK_Sickness] PRIMARY KEY CLUSTERED ( [SicknessID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY], CONSTRAINT [FK_Sickness_Student] FOREIGN KEY ( [StudentDetailID] ) REFERENCES [StudentDetailID] ( [StudentDetailID] ), CONSTRAINT [FK_Sickness_TimesheetAttendance] FOREIGN KEY ( [TimesheetAttendanceID] ) REFERENCES [TimesheetAttendanceID] ( [TimesheetAttendanceID] ) ) [PRIMARY] ONGO

88

K.4 Base table for dbo.Holiday CREATE TABLE [dbo].[Holiday]( [HolidayID] [int] IDENTITY(1,1) NOT NULL, [StudentDetailID] [int] NOT NULL, [WeekCommencingDate] [datetime] NOT NULL, [StartDate] [datetime] NULL, [EndDate] [datetime] NULL, [NoOfDays] [char](3) COLLATE Latin1_General_CI_AS NULL, [DaysRemaining] [char](3) COLLATE Latin1_General_CI_AS NULL, [AuthorisedBy] [char](30) COLLATE Latin1_General_CI_AS NULL, [CreatedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CreatedDate] [datetime] NULL CONSTRAINT [DF_Holiday_CreatedDate] DEFAULT (getdate()), [LastModifiedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [LastModifiedDate] [datetime] NULL, [TimesheetAttendanceID] [int] NULL, CONSTRAINT [PK_Holiday] PRIMARY KEY CLUSTERED ( [HolidayID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] CONSTRAINT [FK_Holiday_Student] FOREIGN KEY ( [StudentDetailID] ) REFERENCES [StudentDetailID] ( [StudentDetailID] ), CONSTRAINT [FK_Holiday_TimesheetAttendance] FOREIGN KEY ( [TimesheetAttendanceID] ) REFERENCES [TimesheetAttendanceID] ( [TimesheetAttendanceID] ) ) ON PRIMARY GO

89

K.5 Base table for dbo.EMA

CREATE TABLE [dbo].[EMA]( [EMANo] [int] IDENTITY(1,1) NOT NULL, [Date] [datetime] NULL, [Paid] [char](1) COLLATE Latin1_General_CI_AS NULL, [Amount] [money] NULL, [StudentDetailID] [int] NOT NULL, [TimesheetAttendanceID] [int] NOT NULL, [CreatedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CreadtedDate] [datetime] NULL CONSTRAINT [DF_EMA_CreadtedDate] DEFAULT (getdate()), [LastModifiedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [LastModifiedDate] [datetime] NULL, CONSTRAINT [PK_EMA] PRIMARY KEY CLUSTERED ( [EMANo] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY], CONSTRAINT [FK_EMA_Student] FOREIGN KEY ( [StudentDetailID] ) REFERENCES [Student] ( [StudentDetailID] ), CONSTRAINT [FK_EMA_TimesheetAttendance] FOREIGN KEY ( [TimesheetAttendanceID] ) REFERENCES [TimesheetAttendance] ( [TimesheetAttendanceID] ) ) ON [PRIMARY] GO

90

K.6 Base table for dbo.Travel

CREATE TABLE [dbo].[Travel]( [TravelNo] [int] IDENTITY(1,1) NOT NULL, [PayrollNo] [int] NOT NULL, [WeekNo] [char](2) COLLATE Latin1_General_CI_AS NOT NULL, [Date] [datetime] NOT NULL, [Paid] [bit] NULL, [Amount] [money] NULL, [Bonus] [money] NULL, [StudentDetailID] [int] NOT NULL, [Notes] [text] COLLATE Latin1_General_CI_AS NULL, [TimesheetAttendanceID] [int] NULL, [CreatedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CreatedDate] [datetime] NULL CONSTRAINT [DF_Travel_CreatedDate] DEFAULT (getdate()), [LastModifiedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [LastModifiedDate] [datetime] NULL, CONSTRAINT [PK_Travel] PRIMARY KEY CLUSTERED ( [TravelNo] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] CONSTRAINT [FK_Travel_TimesheetAttendance] FOREIGN KEY ( [TimesheetAttendanceID] ) REFERENCES [TimesheetAttendanceID] ( [TimesheetAttendanceID] ) ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO

91

K.7 Base table for dbo.TimesheetAttendance CREATE TABLE [dbo].[TimesheetAttendance]( [TimesheetAttendanceID] [int] IDENTITY(1,1) NOT NULL, [StudentDetailID] [int] NOT NULL, [WeekCommencingDate] [datetime] NOT NULL, [WeekNo] [char](2) COLLATE Latin1_General_CI_AS NOT NULL, [MonMarkID] [int] NOT NULL, [TueMarkID] [int] NOT NULL, [WedMarkID] [int] NOT NULL, [ThurMarkID] [int] NOT NULL, [FriMarkID] [int] NOT NULL, [Notes/Reasons] [text] COLLATE Latin1_General_CI_AS NULL, [SelfCertReceived] [bit] NOT NULL CONSTRAINT [DF__TimesheetAttendance__SelfCertReceived] DEFAULT ((0)), [IsEMA] [bit] NOT NULL CONSTRAINT [DF__TimesheetAttendance__IsEMA] DEFAULT ((0)), [EMANotes] [text] COLLATE Latin1_General_CI_AS NULL, [IsTravel] [bit] NOT NULL CONSTRAINT [DF__TimesheetAttendance__IsTravel] DEFAULT ((0)), [Travel(£)] [money] NULL, [TravelNotes] [text] COLLATE Latin1_General_CI_AS NULL, [CreatedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [CreadtedDate] [datetime] NULL CONSTRAINT [DF_TimesheetAttendance_CreadtedDate] DEFAULT (getdate()), [LastModifiedBy] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [LastModifiedDate] [datetime] NULL, CONSTRAINT [PK_TimesheetAttendance] PRIMARY KEY CLUSTERED ( [TimesheetAttendanceID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY], CONSTRAINT [FK_TimesheetAttendance_Student] FOREIGN KEY ( [StudentDetailID] ) REFERENCES [StudentDetailID] ( [StudentDetailID] ) ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO

K.8 Base table for dbo.MarkType

CREATE TABLE [dbo].[MarkType]( [MarkTypeID] [int] IDENTITY(1,1) NOT NULL, [Mark] [char](1) COLLATE Latin1_General_CI_AS NULL, [Description] [char](20) COLLATE Latin1_General_CI_AS NULL, CONSTRAINT [PK_MarkType] PRIMARY KEY CLUSTERED ( [MarkTypeID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] GO

92

K.9 Base table for dbo.Staff

CREATE TABLE [dbo].[Staff]( [StaffID] [int] IDENTITY(1,1) NOT NULL, [Username] [varchar](50) COLLATE Latin1_General_CI_AS NOT NULL, [Password] [varchar](50) COLLATE Latin1_General_CI_AS NOT NULL, [Title] [char](5) COLLATE Latin1_General_CI_AS NULL, [Surname] [varchar](40) COLLATE Latin1_General_CI_AS NULL, [FirstForename] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [Othername] [varchar](30) COLLATE Latin1_General_CI_AS NULL, [DateOfBirth] [datetime] NULL, [Sex] [char](1) COLLATE Latin1_General_CI_AS NULL, CONSTRAINT [PK_Staff] PRIMARY KEY CLUSTERED ( [StaffID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] GO

K.10 Base table for dbo.Supervisor CREATE TABLE [dbo].[Supervisor]( [SupervisorID] [int] IDENTITY(1,1) NOT NULL, [Username] [nvarchar](8) COLLATE Latin1_General_CI_AS NULL, [Code] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [Surname] [varchar](40) COLLATE Latin1_General_CI_AS NULL, [FirstForename] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [Title] [char](12) COLLATE Latin1_General_CI_AS NULL, [JobTitle] [varchar](30) COLLATE Latin1_General_CI_AS NULL, [Type] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Status] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [Address1] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Address2] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Address3] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [Address4] [varchar](50) COLLATE Latin1_General_CI_AS NULL, [PostcodeOut] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [PostcodeIn] [varchar](5) COLLATE Latin1_General_CI_AS NULL, [Tel1] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [MobileTel] [varchar](20) COLLATE Latin1_General_CI_AS NULL, [Email] [varchar](30) COLLATE Latin1_General_CI_AS NULL, [Quals] [text] COLLATE Latin1_General_CI_AS NULL, [Subjects] [text] COLLATE Latin1_General_CI_AS NULL, [Notes] [text] COLLATE Latin1_General_CI_AS NULL, [Sex] [char](1) COLLATE Latin1_General_CI_AS NULL, [Ethnicity] [char](2) COLLATE Latin1_General_CI_AS NULL, [DisAbCode] [char](2) COLLATE Latin1_General_CI_AS NULL, [EvPICSUser] [nvarchar](8) COLLATE Latin1_General_CI_AS NULL, CONSTRAINT [PK_Supervisor] PRIMARY KEY CLUSTERED ( [SupervisorID] ASC )WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY] GO

93

APPENDIX L PAGE DESIGNS

L.1 WBL Timesheet Database - Home page

L.2 WBL Timesheet Database – Timesheet Entry page

94

L.3 WBL Timesheet Database – Student Sickness page

L.4 WBL Timesheet Database – Student Holiday page

95

L.5 WBL Timesheet Database - Reports page

96

APPENDIX M SQL TABLES

M.1 SQL table of dbo.Student

97

M.2 SQL table of dbo.Enrolment

M.3 SQL table of dbo.Sickness

98

M.4 SQL table of dbo.Holiday

M.5 SQL table of dbo.EMA

99

M.6 SQL table of dbo.Travel

M.7 SQL table of dbo.TimesheetAttendance

100

M.8 SQL table of dbo.MarkType

M.9 SQL table of dbo.Staff

101

M.10 SQL table of dbo.Supervisor

102

APPENDIX N ENROLMENT STORED PROCEDURE

CREATE PROCEDURE [dbo].[Enrolment_Import] AS INSERT INTO WBLTimesheets.dbo.Enrolment (EnrolmentID, CourseCode, CourseTitle, StartDate, ExpEndDate, ActEndDate, CompletionStatusID, CSDescription, IsWBL, StudentDetailID) SELECT E.EnrolmentID, O.Code, O.[Name], E.StartDate, E.ExpEndDate, E.ActEndDate, E.CompletionStatusID, CS.Description, E.IsWBL, E.StudentDetailID FROM ProSolution.dbo.Enrolment E WITH (NOLOCK) INNER JOIN ProSolution.dbo.Offering O WITH (NOLOCK) ON E.OfferingID = O.OfferingID LEFT OUTER JOIN ProSolution.dbo.CompletionStatus CS WITH (NOLOCK) ON E.CompletionStatusID = CS.CompletionStatusID WHERE E.OfferingID = O.OfferingID AND E.IsWBL = 'Y' AND NOT EXISTS (SELECT * FROM WBLTimesheets.dbo.Enrolment WBLE WHERE WBLE.EnrolmentID = E.EnrolmentID)

103

APPENDIX O VB IMPORT

Private Sub cmdImportStudents_and_Enrolments_Click()

Dim ADOCmd As New ADODB.Command

Dim ADOError As ADODB.Error

With ADOCmd

.ActiveConnection =

"Provider=SQLOLEDB.1;Server=YOUR-

0CDC4F5844\SQLEXPRESS;Initial Catalog=WBLTimesheets;User

ID=sa;Pwd=wbltimesheets"

.CommandText = "Student_Import"

.CommandType = adCmdStoredProc

.Execute

End With

With ADOCmd

.ActiveConnection =

"Provider=SQLOLEDB.1;Server=YOUR-

0CDC4F5844\SQLEXPRESS;Initial Catalog=WBLTimesheets;User

ID=sa;Pwd=wbltimesheets"

.CommandText = "Enrolment_Import"

.CommandType = adCmdStoredProc

.Execute

End With

MsgBox "Students imported successfully!"

End Sub

104

APPENDIX P USER GUIDE

This user guide was provided to the users during the testing phase of the WBL

Timesheet Database to assist them in using the database as required.

The WBL Timesheet Database is accessible via an icon on the user’s desktop. The

following steps will guide you through the database.

The ‘Import Students’ button should be ran at least once a day to capture the most

recent student information.

Click to import Student & Enrolment info.

To view all current students in the WBL Timesheet Database together with their

enrolment and employment details click the ‘Student’ button.

105

Before the database will allow the user to view any student’s personal or confidential

information they will prompted for valid SQL Server login and password. If you have

not been assigned a login and password contact the system administrator.

Click to view student, enrolment & employment info.

Enter a valid login & password

106

Entering the ‘Student’ form provides you with the student’s personal details, their

course of study and their employer, if any. The screen shot below shows that by

clicking the ‘Find Student’ button that you can search for a student based on any field

on the form.

Click to search for a

student.

To enter student timesheet information click the ‘Timesheets’ button.

Click to enter or update

timesheets.

107

On entering the Timesheets form you are provided with a choice of either ‘Edit

Timesheets for this week’ in which case you are required to enter a date which must be

on a Monday for students based on the start and end date of their enrolment. Or you can

choose ‘Edit Timesheets – All students’ which gives you all students that exist in the

database regardless of date.

Enter a date – Must be a Monday

Choosing either of the above will display the same form layout but will contain a

different number of students.

108

Choosing either of the ‘Edit Timesheet’ buttons will display the screen shown below.

As previously shown and with this form, clicking the ‘Find Student’ button allows you

to search for a student using any of the fields on the top half of the form i.e. students

personal details.

To enter a new timesheet, first select the next blank line and enter the ‘WC Date’ and

‘Week No’. Next choose from the week day drop down boxes the appropriate

attendance mark for each day of the week. Note none of the week day fields must be

left blank or you will receive a system error. Continue to fill in the remainder of the

fields as required. When all of the timesheet entries are complete close the form to save

changes as indicated below.

Close form to save

changes.

109

To enter and view student sickness information click the ‘Sickness’ button.

Click to enter student

sickness.

On closing the timesheet entry form, any sickness data that is entered there will

automatically be transferred to the screen shown below such as the WC Date and the

number of days of sickness in the particular week. This form requires further

information to be entered such as the actual start and end date of the sickness and the

reason for the sickness. The user can easily check the number of days sick the student

has had in this form also.

110

To enter and view student holiday information click the ‘Holiday’ button.

Click to enter student holiday.

On closing the timesheet entry form, any holiday data that is entered there will

automatically be transferred to the screen shown below such as the WC Date and the

number of days holiday in the particular week. This form requires further information

to be entered such as the actual start and end date of the holiday and also the person who

authorized the holiday. The user can easily check the number of day’s holiday the

student has remaining in this form also.

111

To view the various user reports click the ‘Reports’ button.

The user can access and run various reports based on the timesheet attendance

information entered into the database. Some reports have been created based on a week

commencing date which must be entered as indicated below. Other reports can be run

without this date.

Click to view reports.

Enter a date – Must be a Monday

112

113

APPENDIX Q VALIDATION TESTING

Test

No.

Description Pass/Fail Result

1 Ensure ‘WC Date’ on the

timesheet entry form is entered

in the correct format.

Pass Error Message displayed –

“The value you entered isn’t

valid for this field”

2 Ensure the Mon-Fri attendance

marks on the timesheet entry

form are all completed for each

timesheet entered.


“Cannot insert the value

NULL into column

MonMarkID.”

3 Ensure the value entered into

attendance marks drop down box

on the timesheet entry form is a

valid value from the list.


“The text you entered isn’t an

item in the list.”

4 Ensure the value entered into the

Travel (£) field on the timesheet

entry form is a numeric value.



valid for this field.”

5 Ensure the ‘Start Date’ and ‘End

Date’ on the sickness form is

entered in the correct format.




6 Ensure the ‘Start Date’ and ‘End

Date’ on the holiday form is

entered in the correct format.




114

APPENDIX R USER TESTING

Test

No.

Action Expected Result Actual Result No. of

Records

Successful

1 Import new WBL students and their enrolments using the “Import Student” button.

Message displayed – “Students imported successfully!”


12

2 Import new WBL students and their enrolments using the “Import Student” button (again to check stored procedure is working correctly).

Message displayed – “No students to import!”


12 X

3 Search for a student in the Student form using the “Find Student” button.

Find and Replace box to appear. Find and Replace box to appear. N/A

4 Using the “Edit Timesheets – All Students” button view all students in the timesheet database.

All students in the timesheet database available to enter timesheet data.

All students in the timesheet database are available to enter timesheet data.

12

5 Using the “Edit Timesheets for this week” button find only those students who have a timesheet attendance for the WC Date entered.

Only students with a timesheet attendance for the specified week to be available on the form.

Only the students with a timesheet attendance for the week specified are available on the form.

2

115

Documents

DEVELOPMENT OF A DATABASE FOR WORK … · DEVELOPMENT OF A DATABASE FOR WORK-BASED LEARNING TIMESHEETS BSc Computing Studies ... 2.7.1 Top Level Data Flow Diagram ... the WBL Management