Previous Next

What a database does, and how the Electron Database from Acornsoft measures up. Reviewed by Pete Bibby.

The excellent Penguin Dictionary of Microprocessors defines a database as:

1. A file of data structured to allow a number of applications to access the data and update it
2. Any file which might sound more important as a database.

The question I asked myself when I received the Acorn Electron Database was, which of the two was it?

Having come across some dire databases in my time, I approached the package warily.

My needs are simple - all I want in a database is something that will allow me to record information about things, say my birdwatching, retrieve and update it as necessary, and also use the information in a variety of ways.

Rarely have I found a database that comes up to scratch, so I'm pretty difficult to please.

With the Acorn Database, what you get for your money is a 3.5" disc for use with a Plus 3 and a manual. The disc gives you all the programs needed to create and maintain a database, whilst the manual tells you how to use them.

To start using the Database, all you have to do is to put the disc in the drive, boot it and a menu appears on the screen giving you a set of six choices as to what to do next.

Incidentally, booting the disc is not as violent as it might seem. All it means is that the disc has been prepared with a previous:

*OPT 4 3

so that, when you hold down Shift, then press and release Break and, finally, release Shift, one of the programs on the disc is CHAINed automatically.

As you'll see if you catalogue the disc with:

*MOUNT
*.

the database consists of some twenty programs. These are used to create, maintain and analyse files of information.

So what is a file and what information can it hold?

At its simplest, a file is just a collection of data, structured in a way that allows you to get at the information easily and flexibly.

A particular file is made up of a series of records, and these records are made up of the items you want to store in the database.

This is the data you want to record, hence the name record. Each record has a strict format, or "shape", and it is the database's job to help the user establish this format to meet his or her needs.

If that all seems a bit formal, the following examples should make it clearer.

In the simplest case, each record would consist of one item. A file of magazines may consist of the records:

Here each of the records has only one field, the name of the magazine. However that information could be as easily stored in an array. There's no real need to use a database for such a simple case.

Usually a record is more complicated, and contains two or more items of information linked together. Examples that spring to mind are records of people's names along with their ages or a stock list where each record gives the name of an item, its price, and the number left in stock.

These separate categories of information that go into making up a record are called the fields of a record.

In the case of the name and age example, the records are made up of two fields, one containing the name and the other the age as shown in:

So, to recap, a file is made up of a list of records and each record is made up of one or more fields. The fields in each record contain the data we wish to record.

Notice that the structure of each record is the same. They all have the same number of fields in the same order. What makes them different, of course, is that the information contained in each field varies from record to record.

The Electron Database is a set of programs that allows you to create such files and then amend and analyse them as needed. Again, an example should make things clearer.

In my case, being an avid avian enthusiast, I want to keep a record of all the birds I've seen this year. There will be one record for each of the birds spotted.

Each record will consist of the species' name, where I've seen them, the month and any comment I want to make about a particular species. In other words, there'll be four fields in each record, as shown in Figure 1.

Each field is identified by name which can be up to seven letters long, while the entry in each field can range from 2 to 240 characters.

When I used Database to set up my file I named my first field "Species" and set its maximum length to 20 characters. The next field I decided would be called "Place" and be up to ten characters in length, and so on for the remaining two fields.

If this sounds complicated, it isn't. The program takes you through creating a file step by step, asking you how many fields you want and then requesting information about each field in turn.

It's surprisingly easy, though it does help if you've decided how you want your records structured before you run the program.

Once all the details of the record are established you're asked for the name of the whole file, and the micro creates that file on the disc. You can then add records, delete them or alter the information in the fields as required.

The individual records making up the file are displayed one at a time in the form of cards. Each "card" holds one record, the record consisting of the field names and the data you've put into those fields. Figure II shows this diagrammatically.

As there can be up to 32 field, each of which can be up to 240 characters in length. You can see that some records could overflow the card. What happens then is that the record is spread over two or three cards.

Taking the case of my ornithological database, each record would fit on one card. In the whole file there would be five cards; one for each species. On each card there are the four fields showing the species, where it was seen, when and any comments.

Once you've got a file of records like this, you can do all sorts with it. For a start, you can change the information held in each record, altering whatever is written in the fields by using the cursor control keys to target the area to be changed and then typing as usual.

Once you've updated the file, it can be saved again. Also, new records can be added or old ones deleted easily and speedily, so your database can grow and alter with time.

However there's a lot more to it than that. So far we've only seen the records being used as a list. We enter the data and it stays there until it's deleted or amended. In many ways, paper, a pencil and an eraser could do the job as well.

Where a database scores is in what you can do with the information once you've got it in a file. For a start, you can sort it into alphabetical order at the press of a key. So I could rearrange my bird database so that the card with the Bittern data comes first, the Black Tern next and so on.

However the sort facility isn't just available on the first field, you can choose any field to sort on. So I could have the records in the alphabetical order of the months, or the order of the places, the card with Blacktoft coming first, the one with Titchwell last.

You can even sort on different fields, giving one field precedence and, if two data items were the same (as in Cley) using whatever is in the other field as a "tie-breaker" to choose what comes next.

In fact, you can sort on all the 32 allowable fields, giving each a different priority. I doubt if anyone would take advantage of that too often!

If you've ever tried any sorting, you'll probably have come across the weird case where a sort routine tells you that 123 comes before 5. This is because only the first characters in each have been compared and, of course, 1 comes before 5.

The Electron Database allows you to sort numbers properly. You simply specify which fields are to be treated as numbers with a letter N. Unless you've fallen into the 123 before 5 trap, you won't realise what a gift this is.

As well as sorting the file, you can search it for particular items. If I wanted to find out where and when I'd seen a Redthroat, all I have to do is press a key, specifying that I want all the records with REDTHROAT in the first field.

The Database then looks through the whole file and collects together all the relevant records. In this case, there's only one.

As with sorting, the search facility is much more powerful than it seems at first. By creating patterns made up of characters and symbols with special meanings, you can hunt through the file for all the records that fit that pattern.

For example, if I wanted all the records of birds I'd seen whose name begins with RED I could tell the Database to select them from the file with the template pattern RED*. The asterisk is a special character that means "and any other characters in this field".

What you get from this is what is known as a subset of the original file, in this case containing two cards with the information:

This can be saved as a data file if needed and all the other Database operations can be performed on it.

The asterisk is just one example of a special character that can be used to create a search pattern. There are several of these characters which, taken together, give the Database an amazingly powerful and flexible method of searching files for particular sets of records.

And like the sort, the search isn't just confined to the first field in a record, it can work on any field or any combination of fields. All you have to do is to supply a pattern for each field.

If I wanted all the birds I'd seen at Cley I'd just use the pattern CLEY in the Place field and, at the press of a key, the Database would find all the records that matched this. I'd end up with a subset of the original file made up of the following records:

As you'll have seen from the descriptions of the search and sort facilities the Database has, the structure of the records has a powerful effect on what it can and cannot do.

This can cause problems. For example, in my birding file I couldn't search out the birds I'd seen on rainy days with an East wind blowing because I have no weather field.

Similarly I've only got 10 characters in my Place field. What if I'd been birdwatching at Oswaldtwistle?

As you can see, the fixed record format that allows the Database to search and sort records could be a bit of a straitjacket.

The ideal would be to have all the fields you need, all at the right length at the start. However no-one's perfect, and the Database realises this. It allows fields to be added to records or existing field names and lengths to be altered quickly and simply.

And, once you've got all the records you want containing the information you want, you can print them out, choosing which fields of the records to print out and also the format of the hard copy.

I think that the Electron Database would be great value for money if these were all the facilities it had, but in addition, there are three more.

The first allows you to perform statistical analyses of numeric data, producing the sum, mean and standard deviation of a set of figures.

The second is that the Database has the ability to create a text file copy of one of its data fles. This text file can then be loaded into a word brocessor and treated in the way you would any other piece of word processor text. Hence datafiles can be used in documents.

Still with word processing, the Database can produce a file to be used as parameters for a VIEW macro. Briefly this means that the VIEW word processor holds a piece of text with gaps in it and reads the parameter file created from the data file to fill in these gaps.

A macro could be a standard letter. The names and addresses for each "individualised" letter could then be added from the parameter file that the Database has created from the data file.

All in all, it's an excellent piece of software. Powerful and flexible, it's simple to learn and easy to use, though I advise practising on short, uncomplicated files before you computerise your firm's records.

While it's always easy to think of a few more options you could do with, I think that the Database has all the facilities that any normal user, home or business, would need.

What I particularly like is the ease of use, single key entry of commands being the order of the day. Given this and a manual that's well above the usual standard I have no hesitation in recommending it to people who have little or no previous experience of databases or even micros.

Having said that though, with a piece of software with as many options as the Electron Database does, it does take time and practice before you'll be an expert in its use.

So to sum up, it's a powerful, practical, straightforward piece of software that turns the Electron into a serious tool, suitable for both home and small business use.

Surprisingly easy to use, it has a depth and scope that only becomes apparent with familiarity and practice.

And, to answer the question posed in the first paragraph, it fits the first definition, not the second. If you keep written records, maintaining them on Database files should make your life a lot easier. Recommended.