Jack Parsons

I can confidently say that my final database design has easily fulfilled the user requirements
and fits it intended purpose.
I feel that my database fits its requirements because as it contains all of the necessary data
needed for an appointment system. It also fits the other user requirements as it is a relational
database with all three of its tables linked together. All in all, those that I had test it feel that
the database is easy to understand and contains the data requirement for it to fulfil its
purpose. Not only that, but due to how the database is clearly lain out and sorted in a logical
manner, it helps inexperienced user figure out how to use the database. The guide also helps
inexperience users understand the database and learn how to use it as it explains to them how
the database works.
The first table, the Appointment Details Table, contains the details about the different
appointments and is the main table of the appointment system. Its first field, Appointment ID,
is its primary key and uses AutoNumber to uniquely number and identify each appointment.
Beyond that it contains the information requirement for the appointment such as the date and
time of appointment plus the reason for the appointment taking place. For the fields
containing the time and date, I have used the Date/Time data type and have set to medium
time and medium date respectively. I chose the medium length due to the fact I feel its
neither too long nor too short. The rest of the table has basic information for identifying the
patient and doctor. This is simply their names and their Patient ID/Doctor ID to find them on
the Patient Details Table and the Doctor Details Table. It is on those two tables that you can
find the rest of the information on the patient or doctor. Both the Patient ID and Doctor ID
are foreign keys and use the Number data type. These two fields are also the relationships
that connect the Appointment Details Table to the other tables in the database and also link
all of the tables in the database together as the Patient Details Table and the Doctor Details
Table dont share a direct link with each other. The last field in the table is simply there to
store information relevant to the appointment, but doesnt fit into any of the other fields. Due
to not knowing what sort of data or how much of it might be entered into that field, I gave it
the Memo data type so it wouldnt be limited in the what characters could be entered or how
much could be entered.
The second table, the Patient Details Table, contains the details about the different patients.
The first field of this table is the Patient ID and is the primary key of this table. As mentioned
above, this field is used to form relationship between the Patient Details Table and the
Appointment Details Table. Due to the nature of its purpose in the Appointment Details
Table and the fact that two fields have to have the same data type to form a relationship, the
Patient ID field uses the number data type. The following two fields contain the patients
name, the forename and surname respectively. I split the name into two separate fields as it is
easy to sort by either first name or last name and that cant happen if their stored in the same
field. The fourth and fifth fields of the table contain more personal details on the patient, their
date of birth and their gender. The Date of Birth Field uses the Date/Time data type and is set
to medium date as I feel it looks best that way when compared to either long date or short
date. For the Gender Field, it has a dropdown list menu with three different options to be
selected, Male, Female and Other. The following three fields after the Gender Field contain
the patients address. The first of these three fields contains their street address while the
second has their area while the third is the city or town they live in. Due to the fact that
address are quite long, I decided it would best to split into three separate fields as it would be
easier to store that way and users would find it easier to sort through later. The next field
contains the patients postcode. The following three fields contain the contact details for
patient if they have them, their landline number, their mobile number and their email address.

ICT B-Tech Level 2/Unit 4

Jack Parsons

After the patients contact details, the table has contact details of their next of kin. The first
two fields contain the next of kins forename and surname. The first name and last name are
split into the two fields for the same reasons that the patients name is split into two fields.
After that the next of kins address, postcode, phone numbers and email is lain out in the
same manner as the patients. The final field of this table is like the final field of the first
table, an extra field for storing all information relevant to the patient that doesnt fit into any
of the other fields. It has the same layout as the one on the Appointment Details Table as well
as having that layout for the same reasons.
The third table, the Doctor Details Table, contains information on the doctors. The first field
of this table is the Doctor ID and is the tables primary. As mentioned in the paragraph on the
first table, this field forms a relationship between the Doctor Details Table and the
Appointment Details Table. Due to this, it has uses the Number data type as the fields in a
relationship have to have the same data type. The next two fields contain the doctors name,
also split into two fields containing the forename and surname. I did this for the same reasons
that I split the patients name into two fields and I split their next of kins name into two
fields. After that I have the doctors specialisation followed by two fields containing the
doctors date of birth and their gender. The Date of Birth Field is like that of the Date of Birth
Field on the Patient Details Table and uses the Date/Time data type and is set to medium
time. The Gender Field is also like its counterpart on the Patient Details Table with a
dropdown list menu with the same three options. The next seven fields contain the times that
the doctors are available during the week, one field for each day of the week. Despite
containing the times, I used the Text data type as I would be unable to use the Date/Time data
type without doubling the amount of fields that would be needed. The final field of this table
is the same as the final field of the previous tables with the same purpose, layout and reasons.
I feel that these tables fit the intended purpose of the database. I also believe that they are
simple and easy to understand. The Doctor Details Table contains the information necessary
for making an appointment while the Patient Details Table contains the relevant information
on the patients and contacting their next of kin. The Appointment Details Table contains the
needed information for the appointments in addition to having the basic information required
to identify the patient and doctor with whom the appointment is with. The description for
each field gives the user a guide on what to enter and collectively form a guide for the
database on a whole. I also have validation for some of the fields as the Doctor ID and the
Patient ID have to be 1 or higher. If 0 or a negative number is entered, the user will be forced
to leave the field blank or enter a valid value before they are allowed to move on.
The queries allow for meaningful data to be found such as all of the appointments within a
certain year or the next of kin that live in the local city or the details on the doctors of a
particular gender. The reports also display meaningful information such as what hours the
doctors are available or when the appointment happened or the contact details of the next of
kin. The forms have been customised and have useful navigation to make them more userfriendly. There is a form navigation connecting them all and I have added buttons to be able
to more easily go through the forms. I also have main form with a subform. This is case the
main form is the name, ID and specialisation of the doctor while the subform contains
information on each of the doctors appointments. I have changed the titles of the forms so
that the background is a bright red while the letters are in white and bold. I have chosen those
to colours as they are traditionally associated with the medical profession. I feel that these
queries, forms and reports fit the user requirements and intended purpose of my database.

ICT B-Tech Level 2/Unit 4

Jack Parsons

Those that I have test and review my database felt that it fitted its user requirements and
intended purpose like I also felt it did. The reviewers said that it was easy to understand and
use as required by the user requirements. They also felt it was logically designed and clearly
lain out in a logical manner. This resulted in them feeling that inexperienced users would find
my database easy to understand and use. They said that due to how the tables and fields were
sensible separated meant that it was easy to sort through the data and find what you are
looking for. The reviewers said that the table uses were sensible and appropriate validation
tests were included. They also said that the one-to many relationships that tied the tables
together worked and were accurate. They also found the onscreen guide and the notes useful
as they also made it easy to understand and use the database even if the user was
inexperienced. The main improvements they felt were necessary were to make the data more
realistic and to limit the length of some of the text field to save space.
My final design hasnt varied much from the original design with no major changes to it. The
majority of changes made were simply refining the database and making it easier to use. I put
this down to the original design fitting its intended purpose and fulfilling the user
requirements, rendering any big changes unnecessary. Despite the database working as
intended, there still improvements that can be made to it. For example, I could reduce field
size of some of the fields using the text data type. This would limit what could be entered and
help stopped extra characters being entered. Another thing I could do is change Available
Hours fields on the Doctor Details Table so there are twice as many, one for the start time
and the other for the end time. While this would add an extra seven fields to the table, it could
make the data easier to sort through and update in addition to allowing me to change the data
types from text to date/time, something that I feel would make more sense and easier to
validate. I could also add more detail to the guide. This would help explain how to the use the
database better to inexperienced users and therefore it would make it easier to learn how to
use the database. It would also help further fulfil the user requirements.
I personally believe that my database design is a success. It fits the user requirements and
fulfils its intended purpose. Myself and the reviewers felt it was simple and easy to use.
Despite there still being potential improvements and not that many changes to the original
design, I feel that no major changes are currently necessary to the database.

ICT B-Tech Level 2/Unit 4