Applied ICT A Level on That Blue Square Thing

Applied ICT A Level Unit 3 - Database Design

Note: this page applies to the AQA Applied ICT A level specification. This exam is being withdrawn in 2012, with final exams in 2013. The content will be retained as an archive and because it has some stuff that might be quite useful for someone or other

Part 3 - Data Inputs

In Part 1 you needed to find out what data would be input by whom and to get an idea of where that data comes from. This is where that basic information starts to get used.

This covers AO3 rows 1, 2 and 3. These sections link together - and also link back to some of the sections you've already dealt with. You need to make sure you cover all the markgrid rows - if necessary refer to evidence elsewhere in the portfolio.

The markgrids for these three rows are shown together at the end of the page.

These are important marks! You might not write this section up right at the beginning, but you will need to make sure you cover all three sections very clearly somewhere in your portfolio.

Don't forget this section!

Data Inputs - AO3 row 1

This is quite a tricky markband. Check out the markgrid carefully and cover everything it tells you to do!

You should have begun to think about data inputs back when you first started to describe the organisation. You'll also have thought about data entry forms when you were considering the tasks the database needed to do. You'll have designed the forms as well.

Make sure you:

say clearly exactly what information will need to be entered into the database
who is going to do the data entry
how they're going to enter the data - hopefully by using forms most of the time
where they're going to get the data from - from phone calls, e-mails, websites, paper records or from where else? You may need to go back to your client and check this

You will want to show that you've considered your client needs carefully. Well designed forms are part of this. You might also include features such as drop down lists, clear instructions on forms, helpful error messages, parameter query boxes which make it clear exactly what's required, sensible input masks.

Screenshot of effective drop down options Using drop down boxes or combo boxes for specific fields can help make inputs easier to manage for users. This sort of thing could be used for the title of a customer for example - are they a Mr, Mrs, Miss or Ms?

It's important to think about the values you put into input drop downs carefully though. The list on the right, from the UK Government's Foreign and Commonwealth Office website, shows an effective set of drop down values suitable for their users.

Compare that with the way the UK's Department for Education has chosen to use drop down options for the same purpose (yes, Education teaching you how to do it badly...). Sometimes you need to know when the stop!

Screenshot of poorly specified drop down options from the Department for Education's website

I still can't work out why the DfE thinks they could possibly need an "other" option at the end of their drop down of 40 choices. Perhaps they'd like to contact me and let me know?

You might well evidence a lot of this section elsewhere. That's OK - it's entirely sensible to do that. Simply refer to where you have evidenced it and that's fine (note: you may want to also refer to your actual implementation screenshots once you've produced the database. Again, that's absolutely fine to do. This is a section you may want to remember to come back to!).

A useful thing to be able to do is to use drop down boxes on forms to help you select a customer's details. Here's a way of doing that whch works for simple, one table forms without any foreign keys involved:

using a drop down box on a simple form (such as one for tblCustomer)

You can also use drop down boxes effectively on forms for joining tables (such as tblJob). These have foreign keys on them. The process is a bit more complex, but will get you cool geek-style marks:

using a more complex drop down box on a form for a joining table

You can simplify the drop down method to use on a simple tblCustomer, for example.

Validation and Accuracy of Data Entry - AO3 row 2

It's fairly obvious that the data that gets entered into a database has to be valid and accurate. In this section you need to show that you've planned to do that (and actually done it) and show that you understand why it's important to do so.

There is an absolutely crucial difference between two things that you need to understand here:

Validation is restricting the values which can be entered into the database. You usually do this through validation rules - you've specified these in your data dictionary and will implement them later. This stops you entering invalid data by accident - the database simply won't allow it

Verification is checking that the data that's been entered into the database is accurate - that it's actually been entered accurately. So, for example, the database will allow me to enter my surname as Frod. To show verification you have to get the user to check that the data they've entered is actually accurate.

Verification is harder to do. You'll probably end up evidencing this when you do your implementation - so it's a good idea to refer to it from this section at that point. Some useful techniques:

Enforcing referential integrity properly can help ensure accurate data is entered as well - and stop a user deleting data by accident.

How to do verification

guide to how to create textbox pop up alerts on a form - for use when a user clicks in a form box

guide to how to create tool tips on a form

guide to blanking out a box on a form

guide to creating a pop up message for a form button

This is a tough markband to get all the marks for. Make sure you've referred to everything you've done and shown you understand what you're talking about.

Error Messages - AO3 row 3

You need to use error messages which are suitable for the users of your system. These will probably need to be non-technical and helpful.

Each validation rule will need a validation text message - this is the error message which will show if the user fails to enter valid data. Specify exactly what messages you plan to use - a simple table will be useful:

Field & Table	Possible error	Error message	Justification
custGreeting in tblCustomer	User may enter an invalid title for customer	Choose a title from the drop down list	The message clearly instructs the user how to solve the problem
meetDate in tblMeeting	The meeting data entered must be in the future	That date is in the past. Please choose a date in the future.	...

You may have other error messages in place as well - for example, verification messages to check data accuracy.

The key marking point here is that the error message should explain what the user should do rather than just tell them that they have made an error.

The Markgrid:

Don't forget that in this section you may well end up referring to your design work and the evidence of implementation. It's a section you may need to write in a basic form and then come back to once you have implemented the database solution.

Note: this markscheme is a copy of one available freely on the AQA Applied ICT webpages. It is copyright AQA and reproduced here simply to make access easier for students. No attempt to claim copyright is being made, although I could have copied the text into my own interpretation...

You should probably look at That Blue Square Blog for all the really good other A Level stuff.