The different aspects of the design of my website for Hatch end cars.

Table name: Cars                                Primary key: Car ID

Table name: Rentals                                

There will be another table called OLD RENTALS so that rentals that have been returned can be transferred there. This will have the same fields and validations as the rentals table above.

TOTAL NUMBER OF BYTES TO BE USED FOR EACH ENTITY

There are four entities required for this system as shown in the previous page. The estimated file size of each table has been calculated below:

ENTITY RELATIONSHIP DIAGRAM

The diagrams below show the tables included in the database and how they will be linked together:

QUERIES

Query name: Car rentals query

Purpose: To allow days overdue to be shown and fine to be charged on overdue Car rentals.

Type of query: Simple query

Tables included:

• Cars

Fields required from the table/s:

Cars:

Created Fields:

Rentals:

Query name: Member details

Purpose: To search for a particular member details.

Type of query: Parameter query

Tables included:

• Members

Fields required from the table/s:

Members table:

Query name: Old rentals append query

Purpose: To copy rentals that have been returned to another table called the OLD RENTALS so that it can be stored as archives.

Type of query: Append query

Tables included:

• Rentals

Fields required from the table/s:

Rentals table:

Query name: Old rentals delete query

Purpose: To delete rentals that has been returned in the RENTALS table.

Type of query: Delete query

Tables included:

• Rentals

Fields required from the table/s:

Rentals table:

Query name: Over three months delete query

Purpose: To delete rentals that is more than three months old that is stored in the OLD RENTALS table.

Type of query: Delete query

Tables included:

• Old Rentals

Fields required from the table/s:

Old rentals query:

Query name: Overdue cars

Purpose: To show all cars that is overdue and has not been returned. This will also show which member rented it so that they can be contacted to remind them of the rental.

Type of query: Simple query

Tables included:

• Member
• Rentals
• Cars

Fields required from the table/s:

Members:

Cars:  

Rentals:

Created fields:

Query name: Price update query for Cars

Purpose: To increase or reduce the prices of cars.

Type of query: Update query

Tables included:

• Cars

Fields required from the table/s:

Cars:

Created fields:

MACROS

In order to perform certain functions in the system a macro will be use. The various macros that will be used have been described below:

Name: Close start up screen macro.

Purpose: To close the start up screen after 2 seconds of display and open the MAIN MENU.

Name: No Data

Purpose: To display an error message if the search is not valid.

Name: No exit

Purpose: To prevent the system from closing down.

Name: Yes Exit

Purpose: To close down the whole system.

Name: Price update for CARS.

Purpose: To automatically update the prices of CARS that is entered.

Name: Rentals delete macro.

Purpose: To delete rentals that has been returned and the overdue is paid.

ERROR MESSAGES AND DIALOG BOXES

Since my client wanted help in some aspects of the system because this is their first time of using a computer based system. There will be error messages where it is necessary to enter data and where there is a validation in a field. Error messages will be displayed in these parts of the system:

• When adding, deleting or editing a customers and cars.
• Renting a car.
• Looking for a report that does not exist.

All the error messages will be in the same format, indicating to the user what they have done wrong and how they can correct it (Helpful Error Messages).

Test plan

USER AGREEMENT WITH TEST PLAN

The test plan has been shown to Mr. Ghulraham during one of our meetings. During this session, I explained to him that the purpose of the test plan is to tests all aspects of the end system, which will allow me to evaluate whether the system works as intended. In addition, this also tests if requirements have been met. He approved of this and thought it was a good idea and wished to see the results of the testing once this was done.

SYSTEM PLAN:

The various steps described below are the steps that will be taken to create the system:

1. Create table to store member details.
2. Create table to store car details.
3. Create tables to store rentals.
4. Set up relationship between the tables.
5. Set up a query to search for cars.
6. Set up a query to fine members for overdue rentals for cars.
7. Set up a query to search for a particular member’s details.
8. Set up a query to archive/delete returned cars.
9. Set up a query to show overdue cars with their fines and days overdue.
10. Set up a query to update prices of cars.
11. Create a report to print a particular member’s details.
12. Create a report to search for re
13. Create a report to print overdue rentals.
14. Create a report to print member card.
15. Create a macro to update prices of cars.
16. Create a macro to show error message.
17. Create a macro to archive/delete returned cars.
18. Create a form to delete, edit or add member.
19. Create a form to delete, edit or add cars.
20. Create a form to add rentals.
21. Create a form to show all reports.
22. Create a form to run all macros apart from the macro to show an error message.
23. Create a main menu which will contain various buttons connected to all the functions that can be performed on the system to make it easy to control for the user.
24. Create an exit function on the main menu.
25. Create a macro to shut down system or return to main menu.
26. Create a start up screen.
27. Create a macro to close the start up screen.
28. Set password.

TASK MODEL:

A time plan has been constructed below to estimate the amount of time that will be needed during the system implementation. Ample time has been given for each stage so that unexpected events can be tolerated to ensure the success of the end system.

(ii) INTENDED BENEFITS OF THE END SYSTEM:

BENEFT 1:

Storing data

The end system will allow HEC to store data electronically, with very little need for paper and storage space, thus reducing bureaucracy. This is one of the main problems faced by HEC from using the current system.

Safe storage and the use of passwords will prevent data loss, which could not be achieved in the current system.

In the current system, when data needs to be disposed off e.g. a member does not want to continue, the data will need to be shredded specifically by Mr. Ghulraham to ensure that they comply with the Data Protections Act. However, this problem will not be faced in the end system as the data is simply deleted by pressing a button. This makes it easy and efficient as data does not need to be carefully disposed off to comply with the Data Protections Act.

BENEFIT 2:

Searching for records:

It was a difficult to search for data such as member details in the current system. This therefore, made searching for data time consuming for the staff. However, Due to search criteria that will be provided in some aspects of the end system and well structured menu, the time taking to search for records will be significantly reduced. This will in effect reduce the time taking to serve customers, allowing faster customer services.

BENEFIT 3:

Reports to print data

The current system of HEC does not have the operations to collate all information of customers with overdue rentals. This system will be able to allow the employees to print reports of customers with overdue rentals and their contact information. This will allow the employees to call the customers with overdue rentals to remind them.

BENEFIT 4:

User interface

Since this is the first computer based system in HEC, some employees do not have the required experience. However, with the use of buttons to navigate the system, they can use the system more efficiently and confidently.

In addition, including the HEC logo on all the screens, making the pages more colourful and the use of on screen error messages makes the user interface user friendly.

(iii) LIMITATIONS OF THE END SYSTEM:

LIMITATION 1:

Power cut

The end system will be electronically based and will therefore be running on electricity. So one of the drawbacks is that, in cases of power cuts the system will be out of use. The use of generators in the cases of power cuts should supply power to the system, allowing it to run as intended. However, Mr. Ghulraham needs to be aware of the cost implications of doing this.

LIMITATIONS 2:

Viruses

The spread of viruses into the system for example through a memory stick will disable the whole functions that can be performed in the system. It will be essential to install or download a firewall to prevent unauthorized access into the system and back up regularly, preferably over night.

LIMITATIONS 3:

Training

Without the required level of skills, using the system will be very difficult for employees to navigate their way through the system despite the good user interface. Using an appropriate training technique to educate employees on how to use the system will definitely enhance their skills, allowing them to use the system much quicker and confidently. In addition, because of the simplicity of Access, hence my reason for choosing it and the design of the system, will also aid employees to easily navigate their way through the system.

ESTIMATION OF STORAGE SPACE REQUIRED OVER TIME

An estimation of the total storage space needed has been shown below: