If the title of this tutorial sounds a little intimidating, never fear. Toss the term ‘parameter query’ around at a party and you may get a few gasps of admiration, but understanding and using this highly useful type of query is no big deal.

A parameter query is interactive – it prompts the user for information when it’s run. You can use a parameter query to ask the user for criteria for retrieving records or for a particular value to insert in a field. This makes parameter queries great for generating dynamic, on-the-fly results.

If you think of the queries we’ve examined in earlier articles in this series, while the data may change, the query itself is static:

• Which countries have a population over 20 million and an area of over 2 million square kilometres?
• Which country has the smallest population density?

With parameter queries, both the data and the queries may change over time:

• Which countries have a population between x and y?
• Which countries joined the United Nations in the nth decade of 2000?

You obtain the values for those variables – x, y and n – by asking the user to supply them each time the query is run.

Creating a parameter query

Let’s take a look at some parameter queries in action, using Microsoft Access, which provides tools that let us do this job easily. We’ll use the Countries database we’ve used previously (you’ll find a download link at the bottom of this page) and start by creating a non-parameter query to answer the question “Which countries have a population greater than one hundred million?” We’ll then transform that query into a parameter query and contrast the results.

Here goes:

1. Open the Countries database in Access.
2. In the main Database Window, click Queries in the Objects list.
3. Double-click Create Query In Design View to open the Query window and Show Table box.
4. Select the Countries table to add it to the Query window, click Add, and then click Close.
5. Click Name in the list of fields, hold down the Ctrl key and click Population. Drag the two fields to the left-hand column in the query design grid to add the fields to the query.
6. In the Population column in the grid, type:

>100000000

in the Criteria row.

7. Click the Run button (it has an exclamation mark on it) to run the query. You should see 11 countries listed, each with a population greater than 100 million.

That’s our simple, non-parameter query, which we created by providing a constant (100 million) as the matching criteria. Now let’s change it into a more flexible parameter query, which uses variables provided by the user instead of a constant.

1. Click the View button (it’s the left-most button on the toolbar) to return to Design View, so we can modify the query.
2. Delete the contents of the Criteria cell in the Population column and replace it with:

>[Show countries with a population over:]

You may need to resize the column (by dragging the right edge of the column header to the right) so you can see the entire contents.

3. Click the Run button. You’ll be presented with a dialog box containing the prompt, “Show countries with a population over:” Fill in any value you like and click OK to see the results.
4. Save this query by clicking the Save button and naming it Population over x.

Parameter tips

Neat, huh? Let’s examine the query to see how we did this.

The criteria consists of the greater than operator (>) followed by the prompt we wish to use enclosed in square brackets:

>[Show countries with a population over:]

That’s simple enough, but there are two important things to keep in mind when you create your parameter prompts. First, be succinct. Access lops the prompt off at 37 characters, so if you are verbose you’ll end up with shabby-looking, truncated prompts.

Second, be as clear as possible. Although you want to be succinct, don’t become cryptic. For instance, you could just as easily use the criteria:

>[Pop greater than:]

or even

>[Pop?]

Those will work, but if someone else tries to use your database or you use the query only occasionally, a more informative prompt will avoid confusion and ensure the correct input.

Obtaining a range

Your parameter queries are not restricted to a single prompt. You can use them to find a range of values or obtain multiple criteria.

Here’s a query which answers the question, “Which countries have a population between x and y?” by prompting for a lower and an upper value:

1. If you still have the results of the Population over X query open, click the View button to return to Design View. If you closed the query after saving it, highlight it in the Queries list and click Design to open it in Design View.

2. In the Criteria cell of the Population column, add:

AND <[and a population under:]

The full criterion should now read:

>[Show countries with a population over:] AND <[and a population under:]

3. Run the query and you’ll be prompted twice. Enter a lower limit in the first dialog and an upper limit in the second, then click OK to see the results.

4. From the File Menu choose Save As and name the query Population Range. By saving the query, you’ll be able to run it repeatedly, supplying different values each time.

This range query is similar to queries we’ve explored before, using two comparison operators (> and <) and the logical operator AND, but instead of using constant values, it substitutes two parameters obtained via dialogs.

A range example using dates

Let’s try one more range parameter query, this time using dates. This one will answer questions such as “Which countries joined the United Nations in the nth decade of 2000?”

1. Create a new query in Design View.
2. Select the Countries table and click Add to add it to the query, then close the Show Tables dialog.
3. Drag the fields Name and JoinedUN onto the query grid.
4. In the Criteria cell of the JoinedUN column, type:

>[Joined UN after what date:] And <[and before what date:]

5. Run this query and respond to the prompts by typing dates in the format dd/mm/yyyy. To view all countries that joined the United Nations during the nineties, for instance, enter the values 31/12/1989 and 1/1/2001. If you use mm/dd format instead of dd/mm format for dates, you’ll want to make that first value 12/31/1989, of course.
6. Save this query and name it Date Range.

You can, of course, use other operators (<>, =, <= and so on) and logical expressions (OR, NOT) in range queries.

Multiple values

As well as matching a range of values in a single field, you can use parameter queries to match values in more than one field.

Let’s modify the Date Range query to let us not only specify a date range, but also limit the answer to countries over a certain population.

1. Open the Date Range query in Design View.
2. Drag the Population field from the field list onto the query design grid to the right of the JoinedUN field. Our query now contains three fields – Name, JoinedUN and Population.
3. In the Criteria cell of the Population column, type:

>[and has a population over:]

4. Run the query.

You’ll be presented with three prompts, asking for lower and upper dates and then a lower population limit. Note that this query in essence uses the AND logical operator to extend the query, so it’s the equivalent of: Show me countries that joined the UN between date x AND date y AND which have a population over n.

Running a parameter query: A parameter query prompts the user for one or more criteria. In this example, the user specifies a population range and the query returns all matching records.

Avoiding endless dialogs

Try experimenting with parameter queries on your own. You’ll find they add enormous flexibility to the types of information you can wheedle out of your database. A tourist bureau, for example, can use them to provide information to the public on local events occurring this week. A small business can find all those customers who placed orders over a specific amount in the previous quarter. You’re sure to come up with instances where you can use them with your own data.

The only drawback with these queries is that you can end up peppering your users with endless, rather unattractive prompt boxes as you try to collect all the necessary parameters.

There’s good news. With a little fast footwork, you can avoid these dialogs and replace them with a single, good-looking dialog of your own design. I’ll show you how in the next article in this series.

Related posts:

1. Databasics VI: Exploring query types
2. Databasics V: Getting information out
3. Databasics I: Records & queries & keys, oh my!

In the previous tutorial we used Query By Example (QBE) on a database of countries to answer questions such as ‘Which countries are members of the UN Security Council?’ and ‘Which countries have a population over 20 million and an area over 2 million square kilometres?’ These are simple queries which we created using QBE and basic operators such as > (greater than).

It’s possible to ask more complex questions, such as:

• Which country joined the UN most recently?
• Which countries are in the top 5% in terms of area?
• Which five countries have the lowest population density?

The way you tackle these queries depends on which database program you use. I’ll be using Microsoft Access in the examples, as it has querying tools that leave most other PC databases in the shade. You can download a sample copy of the database to try this out for yourself.

Comparative queries

The simple queries we explored last time did nothing more than find a matching value (Name=Namibia), or compare a value in a field to a constant (Population<=20000000).

We can take this a step further and run queries that will compare one piece of data against the rest of the data in the table. These are real bread-and-butter queries. For instance, in a sales database, you might want the answers to questions such as: Which region had the lowest sales for the quarter? Who are our five best salespeople? Which salespeople performed better this quarter than last?

To ask these types of questions, you need to use something a little more sophisticated than QBE. In Access, you use the Query Designer.

Using Access’s Query Designer

Let’s start with the question, Which country joined the UN most recently? Here’s how to get the answer:

1. Open the Countries database in Access.
2. In the main Database Window, click Queries in the Objects list.
3. Double-click Create Query In Design View. A Query window opens together with a Show Table box containing all the tables in our database.
4. Select the Countries table, click Add, and then click Close. This adds the Countries database to the Query window, so we can work with it.
5. Click Name in the list of fields and then hold down the Ctrl key and click JoinedUN (you may need to scroll to see it). Drag the two fields to the left-hand column in the query design grid. The two fields will appear side by side in the grid. The top row in the grid shows the field name; the second row shows which table the field belongs to (we’ll get into multi-table queries at a later date); the third row lets you specify a sort order for the results; the fourth row (Show) specifies whether you want the contents of this field displayed in the results; the fifth and sixth rows specify criteria for selecting records.
6. In the JoinedUN column on the grid, click in the Sort row and, from the drop-down box, select Descending. This tells Access we want the table sorted with the most recent records (those with the’largest’ dates) first.
7. In the toolbar, beside the Sigma button you’ll see an empty drop-down box. This is the Top Values button. Type 1 in this box. We’re looking for the ‘top date’, so to speak – the most recent date in the JoinedUN field – so we want the top, single value.
8. Run the query by clicking the Run button (it has an exclamation mark on it). You’ll see the result is Tuvalu, which joined the UN on the 5th September, 2000.

geekgirl:geopolitical update

In fact, if you run this query on the updated version of the Countries database I now have online, you’ll find the answer is not Tuvalu, but South Sudan. East Timor, Switzerland, Montenegro and South Sudan have all joined the United Nations since I first wrote this article. While I’ve left the article text the same, I have updated the database to reflect these recent additions to the United Nations family (I haven’t had a chance to update the population figures, alas).

These changes show how useful database queries can be: Provided the data in your database is accurate and up to date, you can use a query you created years ago on your current data and get an accurate and up-to-date result.

Saving and re-running queries

Click the Close box on the Query window. You’ll be asked whether you want to save the query. Click Yes, name the query Most Recent Member and click OK.

Why should you save a query? After all, you already know the answer to your question is Tuvalu. But then, the answer won’t always be Tuvalu. Say Switzerland decides to join the UN this year, or a new country emerges from one of the bubbling spots on the globe and becomes a new member? (See the Geopolitical Update above.)

By saving the query, you can re-run it at any time and find the up-to-date answer to your question. This may seem a fairly trivial operation with our simple example, but when you’re creating complex queries or, more importantly, when your data changes regularly, saved queries eliminate a lot of work.

To use your saved query, simply double-click it in the Queries list.

Query types

The Most Recent Member query you created is called a Select query. Access lets you create five different types of query:

Select queries. Used to retrieve data from one or more tables and display the results in a datasheet, which you can save or modify. You can also use Select queries to group records and calculate sums, averages and so on.

Parameter queries. For creating on-the-fly queries which prompt the user for criteria at the time the query is run. For example, you can create a parameter query that answers the question: Which countries have a population greater than X and less than Y? Each time you run the query, it will prompt you for the values of X and Y. Thus you can use the same query repeatedly to discover different information.

Crosstab queries. Used to summarise data from one field and group it in tabular fashion according to two criteria.

Action queries. Queries that make changes to the records in a table. There are four type of action queries: Delete queries remove records from a table; Update queries make global changes to a group of records in a table; Append queries add records from one or more tables to the end or one or more tables; Make-table queries create a new table from all or part of the data in an existing table.

SQL queries. A query created using SQL, which is a highly advanced querying language. SQL queries give you enormous flexibility, but require a high degree of expertise to use effectively.

A select query example

Let’s quickly run through a second select query, answering the question: Which countries are in the top 5% in terms of area?

1. Double-click Create Query In Design View.
2. Select the Countries table, click Add, and then click Close.
3. Click Name in the list of fields, Ctrl-click Area, and drag the two fields to the grid.
4. In the Area column, choose Descending from the Sort drop-down box.
5. In the Top Values box on the toolbar, type 5% (or select it from the drop-down list).
6. Click Run to execute the query.

Calculated fields

How about the question: Which five countries have the lowest population density? We don’t have a Population Density field in our table, so how can we calculate it?

We do it by creating a new field which becomes part of our results (note, though, that the field does not become part of the existing table structure). Here’s how:

1. Double-click Create Query In Design View.
2. Select the Countries table, click Add, and then click Close.
3. Drag the Name and Population fields onto the grid.
4. In the top row of the empty third column on the grid, type:

PopDensity: population/area

and press Enter. We’re creating a new column (PopDensity) whose values will be calculated by dividing each country’s population by its area. By the way, if you can’t see the entire contents of this column, drag the right-hand edge of the column header to the right to resize it.

5. In the Top Values box on the toolbar, type 5.
6. Click the Totals button (it has the Sigma sign on it). A new Totals row appears in the grid.
7. In the PopDensity column choose Ascending from the Sort box.
8. Click Run to execute the query.

The results show the names, population and population density for the world’s least populated countries.

This Select query in Access finds the five most sparsely populated countries in the world using a calculated field, PopDen

An action query

Let’s finish up by converting that last query into an action query. This query doesn’t merely provide us with the results; it saves them in a new table which includes a PopDensity field in its structure. The original table remains intact and unchanged; it’s the new results table which has the extended structure.

1. If you have the query results still showing, click the View button at the left end of the toolbar to view the query in design mode once more. If you have already closed the query, recreate it.
2. Click the down arrow on the Query Type button on the toolbar and select Make-Table Query.
3. Name the query Sparsely Populated, leave the Current Database option selected, and click OK.
4. Run the query and, when prompted, say Yes to create the new table.
5. Close the query, click Tables in the Objects panel, and you’ll see a new table called Sparsely Populated. Double-click it to see the query results in the new table. You’ll notice the new table contains five records (the most sparsely populated five countries) and three fields – Name, Population and PopDensity.

Related posts:

1. Databasics VII: Parameter Queries
2. Databasics V: Getting information out
3. Databasics I: Records & queries & keys, oh my!

Think of a customer database containing information such as customer names, addresses and phone numbers. In the State field, you’ll find the values QLD, VIC, WA, NT, NSW and so on repeated over and over (that is, if you live in Australia – adjust the values to suit your locale if you live elsewhere). Without a context, this list of state abbreviations is meaningless. Put a question to your database such as “What percentage of our customers live in WA?”, however, and the resulting answer is useful, meaningful information.

Queries

We’ve spent the last few tutorials looking at how to structure a database and how to design data entry forms. It’s vital to get this design phase right, otherwise you can’t be sure any information you get from your database will be trustworthy. Additionally, you want to make sure data entry is as easy as possible not only for the comfort of the people stuck with this task, but also to help ensure data is entered correctly. The more attention you pay to the design phase, the better. But the really interesting and useful stuff happens when you start trying to get information out of your database. This is where you turn the stored data into information – a process called querying.

A query is a question you ‘ask’ a database in order to get information in a useful format. As databases don’t understand plain English (although there have been attempts to design database programs that do), you have to phrase your question according to rules. The rules are usually referred to as a query language.

Query language

If this sounds a little intimidating, don’t let it faze you. Chances are you’re already familiar with using a simple form of query language on the Internet. That’s because Web search engines are, in fact, a type of database. When you type a search phrase such as:

piano steinway bechstein

into a Web search engine, the search engine queries its stored database of websites using the three keywords you’ve supplied. Your search will turn up all web pages that contain the word piano or Steinway or Bechstein, or any combination of the three words.

If you’ve done any advanced web searching, you may have tried creating Boolean search queries (named after George Boole, an English mathematician who helped develop symbolic logic). In Boolean queries you use logical operators such as AND (or &), OR and NOT to create more precise searches. Like this:

piano AND (steinway OR bechstein)

This search query will locate web pages that contain the words piano and Steinway, or the words piano and Bechstein, or all three words, but it won’t turn up pages that mention Steinway or Bechstein but don’t contain the word piano.

Querying a database is similar. The query language may be more extensive and you’ll be given tools that make the job very precise, but if you can use a search engine you won’t have too many problems learning how to query a database.

The actual way you create a query depends on the database program you use. For example, the database in Microsoft Works uses an ultra-simple, fill-in-the-blanks approach called query by example (QBE for short). Microsoft Access also has a QBE feature, called Filter By Form. Filter by Form is the easiest way to pull information out of an Access database, but for more complex queries and to create queries which can be re-run at any time, you’ll probably use Access’s Query Builder, a highly sophisticated query tool. Alpha Five and FileMaker Pro also offer a choice of methods to query your data, including QBE.

Making comparisons

You need more than Boolean operators to create a query. You also need a way to compare one value to another, and that’s where comparison operators come into play. In combination with Boolean operators, they let us create questions about our data that the database can understand.

You’ll be familiar with comparison operators from school arithmetic. Here’s a list of them.

To understand how to use comparison operators, imagine a database containing a country table which includes the following fields (the data type of each field is shown in parentheses):

(Note: You’ll find a link at the end of this article which will let you download a copy of the Countries database containing 194 country records, which you can use to try out your own queries.)

Using operators to make comparisons

Consider the types of information you might try to get from the database. Here are some examples:

1. What’s the population of Namibia?
2. Which countries are members of the Security Council and when did they join the UN?
3. Which countries are not members of the UN?
4. Which countries have a population under 20 million?
5. Which countries names begin with A, B or C?
6. Which countries have a population over 20 million or an area of over 2 million square kilometres?
7. Which countries have a population over 20 million and an area over 2 million square kilometres?

Take that first question – What’s the population of Namibia? To rephrase it so our database can understand what we’re asking, we make use of the = (is equal to) operator:

Show me the record in the Countries table where the Name field=”Namibia“, and display the value of the Population field for that record.

So, here are paraphrases for all of our questions:

1. Show me the record in the Countries table where the Name field=”Namibia”, and display the value of the Population field for that record.
2. Show me the records where SecurityCouncilMember=Yes, and display the value of the JoinedUN field for the matching records
3. Show me the records where UnitedNationsMember<>Yes
4. Show me the records where Population<20,000,000
5. Show me the records where Name<”D”
6. Show me the records where Population>20,000,000 OR Area>=2,000,000
7. Show me the records where Population>20,000,000 AND Area>=2,000,000

Broadening and narrowing the scope

Most of these are self explanatory, but let’s take a closer look at the last two where we’ve combined comparison and Boolean operators.

Example 6 displays all countries which either have a population of more than 20 million or which have an area of 2 million square miles or more or which have both a population over a million and an area that’s 2 million square miles or more.

Example 7 displays only those countries which have both a population of over 20 million and an area of 2 million square miles or greater.

The OR operator broadens the scope of the query to include more records. The AND operator narrows the scope of the query.

One other thing you may have noticed in example 5: You’re not restricted to using operators such as < and > with numbers alone. They work equally well with text and dates.

Using QBE

If all these operators have your head in a spin, never fear! Most database programs do all the hard work of concocting queries in the background, while you merely fill in a form to show the type of information you’re after. Nevertheless, if you want to create more complex queries or milk the most subtle information from your data, you’ll certainly put this knowledge to use. Even using query by example you’ll find yourself using comparison operators regularly.

Let’s step through a query by example in Microsoft Access and in FileMaker Pro. [You can download a copy of the sample Access database or the FileMaker database to try it for yourself. Note that you'll get a warning when you try to download the Access sample (countries.mdb) that it is an executable file. The file is completely safe, but if you're concerned, simply scan the file with your antivirus software before opening it.]

An example in Access

1. Double-click the Countries table in the Database window to open the table in Datasheet View. This view shows a list of all the records in the database.
2. Click the Filter By Form button on the toolbar (it has a picture of a funnel on top of a form). Your records will disappear and you’ll be presented with a single blank record.
3.  In the name field type Namibia and then click Apply Filter (the button with the filter on it). The matching record will be displayed.
4. Click the Apply Filter button (it’s now called the Remove Filter button) once more to redisplay all your records.

A more complex example

Now, for a slightly more complex query, let’s search for countries that have a population of 50 million or less which are also members of the UN Security Council:

1. Keep the Countries database open in Datasheet View.
2. Click the Filter By Form button.
3. If “Namibia” still shows in the Name field, delete it.
4. In the Population field, type <=50000000 (don’t put commas in the number) and tick the box in the SecurityCouncilMember field.
5. Click the Apply Filter button. You should see the records for Mali, Jamaica and the Ukraine.

Query By Example is delightfully simple, but it still has its pitfalls. For example, if you fail to tick (place a checkmark in) the UnitedNationsMember field in this Access query, you’ll get no matches. That’s because you’d be asking for records where the country is not a member of the United Nations but is a member of the UN Security Council, which, of course, cannot be. Click the image to see a full-sized version.

The same thing in FileMaker Pro

1. Open the Countries database and press Ctrl-F to go into Find Mode.
2. Type Namibia in the Name field and press Enter to display the matching record. Note that the number of matching records is displayed on the left.
3. Click the Show All Records button (the one with an eye) to redisplay all your records.

For the second query:

1. Press Ctrl-F to enter Find Mode.
2. Tab down to the Population field and type <=50000000.
3. Tab to the SecurityCouncilMember field, type Yes and press Enter to display the matching records. Flip through the matches by clicking the Records icon on the left.

More complex still

So far we’ve merely skimmed the surface of using queries. The QBE examples show how easy it is to get useful information out of a database, but there’s a whole lot more to querying, including the ability to save and re-use queries, and to create queries that prompt the user for information. We’ll examine queries in more detail in the next tutorial.

Related posts:

1. Databasics VI: Exploring query types
2. Databasics VII: Parameter Queries
3. Databasics I: Records & queries & keys, oh my!

If you’re looking for a nice, slow approach to learning databases, choose Databasics. It will help you learn the lingo, start with simple stuff, and eventually take on something a little more challenging. It’s a series in development, so you can munch on some new information, go away and put it to use, then come back in a month or so and try something new. It’s also a very practical series. In Databasics, although the techniques and general advice apply no matter which database product you use, you’ll find specific advanced examples feature Microsoft Access.

If, on the other hand, you want to dive right into the nitty gritty of database design, try the companion series of articles, Databases from Scratch. While there’s some overlap between the two series, Databases from Scratch moves onto advanced topics, such as relational database design, more rapidly and restricts its topic matter to design issues. Databasics wanders farther afield, and includes (or will eventually include) tutorials on queries, reports, forms design, application development as well as basic design principles.

Related posts:

1. The year of the database
2. Databases from scratch II: Simple Database Design
3. A database dictionary

One of the best ways to understand the importance of good database design is to start with an all-in-one, flat-file table design and then toss in some sample data to see what happens. By analysing the sample data, you’ll be able to identify problems caused by the initial design. You can then modify the design to eliminate the problems, test some more sample data, check for problems, and re-modify, continuing this process until you have a consistent and problem-free design.

Once you grow accustomed to the types of problems poor table design can create, hopefully you’ll be able to skip the interim steps and jump immediately to the final table design.

A sample design process

Let’s step through a sample database design process.

We’ll design a database to keep track of students’ sports activities. We’ll track each activity a student takes and the fee per semester to do that activity.

Step 1: Create an Activities table containing all the fields: student’s name, activity and cost. Because some students take more than one activity, we’ll make allowances for that and include a second activity and cost field. So our structure will be: Student, Activity 1, Cost 1, Activity 2, Cost 2

Step 2: Test the table with some sample data. When you create sample data, you should see what your table lets you get away with. For instance, nothing prevents us from entering the same name for different students, or different fees for the same activity, so do so. You should also imagine trying to ask questions about your data and getting answers back (essentially querying the data and producing reports). For example, how do I find all the students taking tennis?

Step 3: Analyse the data. In this case, we can see a glaring problem in the first field. We have two John Smiths, and there’s no way to tell them apart. We need to find a way to identify each student uniquely.

Uniquely identify records

Let’s fix the glaring problem first, then examine the new results.

Step 4: Modify the design. We can identify each student uniquely by giving each one a unique ID, a new field that we add, called ID. We scrap the Student field and substitute an ID field. Note the asterisk (*) beside this field in the table below: it signals that the ID field is a key field, containing a unique value in each record. We can use that field to retrieve any specific record. When you create such a key field in a database program, the program will then prevent you from entering duplicate values in this field, safeguarding the uniqueness of each entry.

Our table structure is now: ID, Activity 1, Cost 1, Activity 2, Cost 2

While it’s easy for the computer to keep track of ID codes, it’s not so useful for humans. So we’re going to introduce a second table that lists each ID and the student it belongs to. Using a database program, we can create both table structures and then link them by the common field, ID. We’ve now turned our initial flat-file design into a relational database: a database containing multiple tables linked together by key fields. If you were using a database program that can’t handle relational databases, you’d basically be stuck with our first design and all its attendant problems. With a relational database program such as Microsoft Access or FileMaker, you can create as many tables as your data structure requires.

The Students table would normally contain each student’s first name, last name, address, age and other details, as well as the assigned ID. To keep things simple, we’ll restrict it to name and ID, and focus on the Activities table structure.

Step 5: Test the table with sample data.

Step 6: Analyse the data. There’s still a lot wrong with the Activities table:

1. Wasted space. Some students don’t take a second activity, and so we’re wasting space when we store the data. It doesn’t seem much of a bother in this sample, but what if we’re dealing with thousands of records?
2. Addition anomalies. What if #219 (we can look him up and find it’s Mark Antony) wants to do a third activity? School rules allow it, but there’s no space in this structure for another activity. We can’t add another record for Mark, as that would violate the unique key field ID, and it would also make it difficult to see all his information at once.
3. Redundant data entry. If the tennis fees go up to $39, we have to go through every record containing tennis and modify the cost in each and every one.
4. Querying difficulties. It’s difficult to find all people doing swimming: we have to search through Activity 1 and Activity 2 to make sure we catch them all.
5. Redundant information. If 50 students take swimming, we have to type in both the activity and its cost each time.
6. Inconsistent data. Notice that there are conflicting prices for swimming? Should it be $15 or $17? This happens when one record is updated and another isn’t.

Eliminate recurring fields

Our simple Students table is fine, so we’ll keep it. But there’s so much wrong with the Activities table let’s try to fix it in stages.

Step 7: Modify the design. We can fix the first four problems by creating a separate record for each activity a student takes, instead of having one record for all the activities a student takes.

First we eliminate the Activity 2 and Cost 2 fields. Then we need to adjust the table structure so we can enter multiple records for each student. To do that, we redefine the key so that it consists of two fields, ID and Activity. As each student can only take an activity once, this combination gives us a unique key for each record.

Our Activities table has now been simplified to: ID, Activity, Cost. Note how the new structure lets students take any number of activities – they’re no longer limited to two.

Step 8: Test sample data.

Step 9: Analyse the data. We know we still have the problems with redundant data (activity fees repeated) and inconsistent data (what’s the correct fee for swimming?). We need to fix these things, which are both problems when it comes to data entry – editing or modifying records.

Eliminate data entry anomalies

As well, we should check that other data entry processes, such as adding or deleting records, will function correctly too.

If you look closely, you’ll find that there are potential problems when we add or delete records:

• Insertion anomalies. What if our school introduces a new activity, such as sailing, at $50. Where can we store this information? With our current design we can’t until a student signs up for the activity.
• Deletion anomalies. If Mark Antony (#219) transfers to another school, all the information about golf disappears from our system, as he is the only student taking this activity.

Step 10: Modify the design. The cause of all our remaining problems is that we have a non-key field (cost) which is dependent on only part of the key (activity). Check it out for yourself: The cost of each activity is not dependent on the student’s ID, which is part of our composite key (ID + Activity). The cost of tennis, for example, is $36 for each and every student who takes the sport – so the student’s ID has no bearing on the value contained in this field. The cost of an activity is purely dependent on the activity itself – it’s dependent on only part of the combined ID/activity key. This is a design no-no, and it’s causing us problems. By checking our table structures and ensuring that every non-key field is dependent on the whole key, we will eliminate the rest of our problems.

Our final design will thus contain three tables: the Students table (Student, ID), a Participants table (ID, Activity), and a modified Activities table (Activity, Cost).

If you check these tables, you’ll see that each non-key value depends on the whole key: the student name is entirely dependent on the ID; the activity cost is entirely dependent on the activity. Our new Participants table essentially forms a union of information drawn from the other two tables, and each of its fields is part of the key. The tables are linked by key fields: the Students table:ID corresponds to the Participants table:ID; the Activities table:Activity corresponds to the Participants table:Activity.

Step 11: Test sample data.

Step 12: Analyse the results. This looks good:

• No redundant information. You need only list each activity fee once.
• No inconsistent data. There’s only one place where you can enter the price of each activity, so there’s no chance of creating inconsistent data. Also, if there’s a fee rise, all you need to do is update the cost in one place.
• No insertion anomalies. You can add a new activity to the Activities table without a student signing up for it.
• No deletion anomalies. If Mark Antony (#219) leaves, you still retain the details about the golfing activity.

Keep in mind that to simplify the process and focus on the relational aspects of designing our database structure, we’ve placed the student’s name in a single field. This is not what you’d normally do: you’d divide it into firstname, lastname (and initials) fields. Similarly, we’ve excluded other fields that you would normally store in a student table, such as date of birth, address, parents’ names and so on.

A summary of the design process

Although your ultimate design will depend on the complexity of your data, each time you design a database, make sure you do the following:

• Break composite fields down into constituent parts. Example: Name becomes lastname and firstname.
• Create a key field which uniquely identifies each record. You may need to create an ID field (with a lookup table that shows you the values for each ID) or use a composite key.
• Eliminate repeating groups of fields. Example: If your table contains fields Location 1, Location 2, Location 3 containing similar data, it’s a sure warning sign.
• Eliminate record modification problems (such as redundant or inconsistent data) and record deletion and addition problems by ensuring each non-key field depends on the entire key. To do this, create a separate table for any information that is used in multiple records, and then use a key to link these tables to one another.

Related posts:

1. Databases from scratch II: Simple Database Design
2. Databases from scratch I: Introduction
3. Databasics III: Data entry design

In fact, databases range from being ultra-simple to use to ultra-complex. In the world of personal computers, there are two main types of database programs. At the simple end of the scale are flat-file databases, also called single-file or list managers. These programs are as easy to learn as a word processor or spreadsheets. The initial concepts may take a little more time to absorb than word processing, but they’re well within anyone’s grasp. If you’re using a database at home, in a class at school or in a small club or organisation, chances are the simple flat-file database will fill your needs.

Relational databases

Things can get more complex when you use the other type of personal computer database program, called a relational database. With a relational database program you can create a range of databases, from flat-file structures to demanding multi-file systems. If you’re using a database in your small business, a large organisation, or an ambitious school project, you’re likely to need at least some of the features of a more complex relational database.

Whichever type of database program you use, the most crucial step in using it is to design your database structure carefully. The way you structure your data will affect every other action. It will determine how easy it is to enter information into the database; how well the database will trap inconsistencies and exclude duplicate records; and how flexibly you will be able to get information out of the database.

A simple example

Let’s take an ultra simple example: the phonebook. Say you’ve been given the job of placing your school or organisation’s phone directory on computer.

It should be easy: all you need is the name, the address and the phone number of each person. Your initial table design thus consists of three fields: name, address and phone number. Right?

Let’s check.

Testing your design

The way to see if your database design works is to test it with some sample data, so feed the following records into your hypothetical table:

J. T. Apples, 100 Megalong Dr, Haberfield, 4992122
B. York, 2/53 Alice St, Leichhardt, 5050011
M. R. Sullivan, 9 Jay St, Leichhardt, 4893892
B. J. Anderson, 71 Wally Rd, Glebe, 2298310

Now tell the database program to sort the information:

B. J. Anderson, 71 Wally Rd, Glebe, 2298310
B. York, 2/53 Alice St, Leichhardt, 5050011
J. T. Apples, 100 Megalong Dr, Haberfield, 4992122
M. R. Sullivan, 9 Jay St, Leichhardt, 4893892

Revising your design

Immediately, you can see this is not what you want. You want the table sorted alphabetically by last name, not initials.

How can you fix this? Well, you could do some complex manipulation using a database feature called ‘string functions’ – if your program supports such a feature. Or, you could come up with a better table design in the first place: last name, initials, address and phone number. Feed your test data into this revised structure then tell the database program to sort your table using the last name followed by the initials. This time, you’ll get the correct alphabetical listing:

Anderson, B. J., 71 Wally Rd, Glebe, 2298310
Apples, J. T., 100 Megalong Dr, Haberfield, 4992122
Sullivan, M. R., 9 Jay St, Leichhardt, 4893892
York, B., 2/53 Alice St, Leichhardt, 5050011

Keep on refining

Don’t stop there. The table can be even more effective if you break the structure down further. For instance, if you’d like to have an easy way to list only those people who live in Leichhardt, this design won’t help you. But with a little more work, you can break your database structure down further into last name, initials, street address, suburb, and phone number.

With this structure, you’ll be able to sort your database alphabetically by last name or by suburb, and you’ll be able to pluck out all those people who live in a particular suburb.

A visual example

Here’s another example of this process in action, starting with a badly designed table structure:

Figure 1: A simple – and flawed – students table

This fragment of a students table suffers from various defects. The combined name field makes it hard for us to locate students by using their last names, and also difficult to sort the table alphabetically by last name. Even worse, how do we uniquely identify each student? Currently, this table uses a combination of the Name and Date of Birth fields to identify each student. What if we happen to have two Jim Smiths, both born on 5th September 1982? It’s unlikely, yes, but not impossible.

The composite address field is also a problem: for instance, how do we pre-sort mail by postal code so we can do bulk mailouts at discount rates?

By breaking the fields down we end up with double the number of fields but a much simpler and more effective structure. The new Student ID field lets us uniquely identify any student, even when they share names and birthdates. We’ve split the Names field into first and last names so we can get an alphabetical listing. We’ve done the same to the address field, allowing us to sort by postal code or suburb.

Figure 2: An improved students table

More is less

Notice how creating an efficient table structure consists of breaking down your fields into simpler and simpler components? You end up with a table with many more fields than you might originally have thought necessary, but each of those fields houses much more basic information.

There’s a technical term for this process: normalisation. If you wanted to become a database architect you’d have to become conversant with normalisation and functional dependencies and normal forms. If you’re happy to remain a lesser mortal, you can safely ignore these terms, provided you keep in mind that your task is to create a database structure that provides an efficient store for your information and that makes it flexible and easy to extract useful information.

In some ways, creating a database that’s effective and simple to use is almost an anti-intuitive process. For example, our initial structure for the phone directory:

name
address
phone number

seems like it’s a simpler design than our end result:

first name
last name
street address
suburb
phone number

Creating useful fields

What you need to remember is that while the structure might look more complex, the contents of each field have been reduced to the simplest useful components. I say “useful” because we could, of course, break each field down further. For instance, we could break the street address field into two fields, street number and street name. But what would be the point? There’s no need to extract or sort information in the database simply by street number or name, and so it’s not a useful basis for breaking up the field. On the other hand, if we wanted to deal with multi-line addresses which are common for businesses, such as:

Suite 5
122 Jones Street

then it makes sense to break the address field down into two simpler fields, address line 1 and address line 2. You’re not likely to want to sort information based on only one of these fields, nor are you likely to use either of these fields in isolation. What is likely is that you’ll want to have an easy way to print address line 1 and address line 2 as separate lines when addressing envelopes. So this field division becomes useful when getting information out of your database.

Permissible design infractions

I should add that creating these address sub-fields is not, technically, a good solution. Notice how with this table design, many records will have nothing in the address line 2 field, as most people’s address consists of one line, rather than two. So you’ll be wasting a lot of space in your database. Additionally, what about addresses that require more than two lines, such as:

Suite 5
Level III, Building A20
122 Jones Street

Our new table structure can’t cope with this. Should we add another address line to ensure we cater to the infrequent address that needs three lines? Should we add a fourth line just in case…?

You can see the problems you can create by not getting the design right. A technically rigorous solution is to remove the address lines from our phonebook table altogether, and stick them in an address table, that we then link to the phonebook table by a common field.

However, there’s no need to fuss too much about such details. Many databases get by with minor infractions of database design rules, and you shouldn’t feel hampered by such rules provided your table structures:

• provide flexible and simple output (whether you’re asking an online query of the database or printing reports)
• eliminate redundant or duplicated information
• exclude inconsistencies

Computer-less design

One thing I hope you’ve noticed is that we’ve done all our design without the aid of a computer. This is as it should be: it lets you focus on the significance of the task without the distractions of trying to learn a database program at the same time.

You can design and test your database structure without going near a computer. The only thing you really need to know is the type of database program you’ll use: if it’s a flat-file database, such as Microsoft Works, you’ll be limited to single-table database design. If it’s a relational program, such as FileMaker Pro, Microsoft Access or Alpha Five, you can design single- or multi-table databases.

In the next article in this series, we’ll move on to relational design. You’ve seen how breaking down your fields into simpler components in a single table can help make it easier to get useful information out of your database. When we look at relational design, you’ll discover how extending this process lets you address the other two goals of database design: eliminating redundant information and excluding inconsistencies.

Related posts:

1. Databases from scratch III: The Design Process
2. Databases from scratch I: Introduction
3. Which database series should I read?