The word “database” can send people into a spin, so this introduction seeks to demystify the subject. Please let me know if it did not, and I will try it again!

An early form of database is the card index. Each card is a “record” and the information on it is arranged under headings such as Name, Address, Date of Birth, etc. In database parlance these are called “fields”. Thus a database contains a number of records and each record has a number of fields.

One major advantage of a computerised database is that the data it holds can be retrieved and sorted very rapidly indeed. You can sort a thousand records in less than a second – rather quicker than hand sorting a set of a thousand cards!

The simplest form of database (sometimes called a “flat” database – more on this later) is a table which can exist in a word processing document or a spreadsheet. In this case each row is a record and each column holds a field. Often the top row holds the column names (ie the field names). A table with 14 rows and 5 columns thus has 14 records each having 5 fields. An example (fictional and not very organised) is:

A quite general problem with databases is that when they grow they can take up large quantities of space on your computer’s internal disc (hard disc). This is not now such a problem since hard disc space is now cheap and plentiful. However, things undoubtedly run more smoothly if space can be saved.

A more advanced and capable form of database is called “relational” and there are rules about how the data should be organised. In such a database there is usually more than one table of data and often many more. One reason for this is that you only need to keep data in a single place. For example consider a database which lists all your U3A’s study groups and the days when they meet. If this was kept in the single table of a flat database, each record would contain all the details of the study group in question plus one date on which it is meeting. Thus for every meeting date there will be another whole record. Clearly a waste of space!

The solution is to keep the study group details in one table and the meeting dates in another. All that is necessary is to be able to join them up when you need to and this is done by having some sort of ID number in each table which links the group and its meeting dates and this is normally looked after for you by the relational database itself.

One database of particular interest to U3A Groups is the record of their Membership which can be stored in a flat table. Once the details have been entered it is easy to run off address labels for the whole or a particular group of the membership. You can send out reminders to those who have not paid their subscription, you can find out how many paid-up members you have, you can sort them by surname or membership number, you can find out where they live (eg by postcode), and perhaps even their email address if they have one.

What software should you use?

You could use a table in a word processor or use a spreadsheet and these can be found either in Microsoft Works or in Word or Excel in Microsoft Office but Access, which comes as part of Microsoft Office Pro, is undoubtedly the best as it is designed purely for one job and can cope, if required, with relational databases. It enables one to automate every task so that once set up, it can be operated by someone who really does not have to understand how it works. There are free or cheaper suites of the Office type of software some of which have relational database software but it is difficult cover more than one here. So it will be Access which we shall deal with from now on.

Sample Access U3A membership databases, together with a description of how to use them, can be downloaded from : http://www.u3a.org.uk/computing/membership_databases.htm. Please note that you may have to bring membership dates up to date before it will work as you would expect.

An introduction to using MS Access 2000 can be downloaded from here (as a Word document)

Back