FoxPop
 

www.foxpop.co.uk

 

 

POWERBASE TUTORIAL 2

by Laurie Jane Kern

Designing the Address Book – or, what fields do I need?

The crucial element in building a database is deciding on the DEPTH or DETAIL of the information it will contain (SELECTING the information), for it is this element which shapes the ORGANISATION of the information and the effectiveness of the RETRIEVAL and collation function.

Consider our three examples:

The stack of business cards offers tremendous depth and detail of information that could be collated in a variety of ways – listing all the Sales Managers, or all IT companies, or those companies which are located in the same city, and so on – but as yet it does not operate within any system of organisation

The list of emergency numbers has the minimal required information because collation is not a necessary task – the numbers are targeted at specific situations, and nothing is gained by being able to list any common elements within the information store – so there is only a minimal organisation needed, such as an alphabetical arrangement

The spreadsheet can also offer tremendous depth and detail of information, but it is different from the stack of business cards because it has already SELECTED and ORGANISED the information deemed necessary

The basic functions of recording, storage and retrieval are mutually significant, and held together within the matrix of the system of organisation chosen for the database – while the system of organisation is itself dependent on decisions about depth and detail and selection of the data the database contains.

How does this relate to designing our Address Book?

Well, consider the question of NAMES. There are choices to be made about how much information to include:

Should we include the TITLE – Dr, Colonel, Professor, Mr, Mrs, Miss, Ms?

Should we separate out the names into First Name/Middle Name/Surname or just into First Name/Surname or enter them as one unit?

Clearly, the options we choose depend on the kind of retrieval and collation we want. An address book that was designed for friends only might use only first names.

The same questions arise with the subject of ADDRESSES. For friends, we might enter everything as one unit; but an address book targeted at business contacts would probably separate out the entry into Address Line 1/Address Line 2/City/Region/Postcode or Zip/Country – because this allows for greater choice when it comes to collating the information.

Indeed, these questions and choices arise with telephone numbers, Email information, how to describe/categorise the person – and so on.

Remember: there is no one ‘correct’ way to build a database – they are very personal things, geared to individual requirements and preferences. BUT: we need to decide what our requirements and preferences are!

Below I offer graphic examples of the kinds of choices available in table form. They are not meant to be exhaustive, and they certainly can’t accommodate every possible variation – for example, an individual might have two Email addresses they use at home, and none at work! But I hope they set out the major choices we need to think about for our address book.

And at the end of this tutorial I give you the decisions I have made for our basic Address Book, also in table form – though we will be adding and changing things in some of the later lessons!

 

Sample Fields A Sample Fields B
Title  
First Name Name
Middle Name  
Surname  
Address Line 1 Address
Address Line 2  
City  
County  
Postcode/Zip  
Country  
Telephone - home Home Phone
Telephone - work Work Phone
Mobile Mobile
Fax Fax
Email1 Email-Home
Email2 Email-Work
Website Website -Home
  Website -Work
Contact Type Category
Notes Notes

 

You have probably noticed the Headings I have used in this first table: Sample Fields A and Sample Fields B.

This brings us back to the question of the VOCABULARY of databases. You will recall from tutorial 1 the terms "record", "field", and "data type". Let’s think about these a little more.

Databases are organised in TABLES. You are probably more than familiar with their organisation into rows, columns, and cells – as below:

 

Column

 

WB00759_.GIF (539 bytes)

 

Row

WB00759_.GIF (1336 bytes)

Cell

Cell

Cell

Cell

 

A TABLE used within a database uses the vocabulary of database construction.

Each cell contains data of whatever type (text or numbers or a mixture) and falls within both a column and a row. The data in each COLUMN is of the same type – first names, or surnames, or telephone numbers, etc. In database terms, cells that contain data of the same type organised in columns fall within the same "field" and are "fields" themselves

The cells that form ROWS create the coherent information about the individuals in the address book: name, address, telephone number, etc. Coherent information of this kind is called a "record"

(NB. There’s a possibility of confusion here, in that the Sample Fields I have used in my table present the coherent information in column form. But this isn't a contradiction. Databases can present their information in a  variety of ways -  Card View (which is what my sample fields give) and List/Table View, are both familiar from DATA. PowerBase offers a third, Page View, which we will encounter later.)

Hence the title of this tutorial: what fields do I need? And here’s my answer:

Title

First Name

Last Name

Address Line 1

Address Line 2

City

Region

Postal Code

Country

Telephone - home

Telephone - work

Mobile

Fax

Email1

Email2

URL

Contact Type

Notes

Next lesson: creating that database, creating our first table and adding these fields- finally!

© LJKern and FoxPop 1999

[Previous] [ Index ] [ Next ]