This series of short tutorials is designed to cover some of the issues that you might come across when creating a small database application. The intention is not to create a database that is the last word in elegance and sophistication, but rather to demonstrate some useful techniques and procedures as part of a usable application. If you have never set up a database before, you will hopefully find the tutorials interesting , but we haven’t included complete explanations or step by step guidance. There are other resources on
AccountingWEB that will guide you through these areas in greater detail.
In the first instalment we will deal mainly with setting up the main tables for our database. A few other tables will be required in later instalments, and these will be described when needed.
Our database will be called ‘ETB’ and is intended to produce a trial balance and associated prints and displays. The input screens are designed to allow transactions to be posted from the normal prime entry sources:

Opening balances

Cash book

Sales and purchase day books

Accruals and prepayments

Journals
In order to keep things simple, we will not include facilities for multiple sets of data or for year end functions.
First of all we need to establish the structure of the data - this will define the tables which we create in Access and how those tables are related to each other.
Our application needs to store transactions and details of the nominal code structure. The main types of information we need to hold will be as follows:
Transactions
Nominal account details
This is as far as many people get with trying to set up a database. Unlike the way many spreadsheets tend to be set up, you really do need to sort out how your database is going to be structured before you start typing anything. If you are used to stream-of-consciousness spreadsheet creation, then you will probably find the far more structured nature of databases is initially challenging. However, please persevere – at least to the end of these tutorials.
Once you understand how to set up a simple database you are likely to find a whole range of uses for your database skills.
We will be using Access 2000 for our examples. If you have a different version of Access you might find there are some cosmetic differences, but most things will work in pretty much the same way.

When you first open Access you will see the following screen. The ‘wizards, pages and projects ’ option is worth investigating – you can, for example, set up your own Time and
Billing system – but in order to explain the basics of Access we will ignore the wizards and start off with a Blank Access database.
We will call our new database ‘ETB’. The first screen you see will show you the different types of ‘objects’ that form a database. First of all we’ll explain the uses of the different objects within an Access database:
Tables – tables are used to store the data that our database holds – they present the data as a grid, similar to the rows and columns of a spreadsheet.
Queries – these serve two main purposes, at their simplest they allow you to choose the data you want to look at – e.g. the names and addresses of all clients based in Yorkshire, but they can also be used to carry out actions on the data. For example to increase all the prices in a price list by 10%.
Forms – as well as a simple method of collecting and storing data, databases can be used to create complete applications. Forms can be used for entering and editing data, and as the main interface between the user and the application. Forms would be used to create the
‘menus’ for the application.
Reports – used to print or preview chosen elements of the data, particularly useful for
‘grouping’ and sub-totalling data. For example showing the total of all expenses by employee by month.
Pages – similar to forms, but used to create browser-based screens to review or edit and enter data.
Macros – used to automate database actions in a similar way to the use of macros in a WP or spreadsheet program. However Access cannot ‘record’ actions, instead it uses a series of commands and options that you select. Macros are generally not used, most developers or even casual users opting for the use of Visual Basic code instead.
Modules – used to automate database actions using Visual Basic for Applications code. Most of the code in a simple application would not be developed or held within the ‘Modules’ objects, instead it would be part of the forms. So a form might have a button to print a report.
The code that carries this out would be part of the form, not a separate ‘module’, and Access would ‘write’ most of it automatically.
Groups – used to group objects together if required.
2

The starting point of our new database is to set up the tables of data that we will be using.
We need a separate table for each different ‘entity’ that our database is to contain. The obvious different entities in our incomplete records system are nominal code details, and transactions. So we will need at least two tables. There are important rules that underpin the structure of data in a database and if you intend to work on more complex structures it is well worth getting to grips with them. Most books on how to use Access will include a section on the underlying theory, and again AccountingWeb has some very useful resources that should help. For this tutorial, we will use a ‘common sense’ approach to setting up our tables, basically seeking to eliminate any duplication of data within our tables.
First, let’s try to explain how we would have arrived at two main tables even if we hadn’t intuitively considered transactions and nominal codes to be separate entities. If we had tried to set up our database with just one table we would have had to include all the nominal code information in the transactions tables – so if, for example, 11 transactions were posted to
‘Miscellaneous expenses’ we would have to enter ‘Miscellaneous expenses’ 11 times. Not only would this be tedious, but if the code and its description were included in the transaction table itself there would be several problems:
Data duplication
Data inconsistency
Updating
Deletion
The same data would be repeated hundreds of times in the transaction table - and if the data included codes and descriptions this would be inefficient to enter and store
By having to enter what should be the same item of data several times, we run the risk of entering it differently or spelling it incorrectly.
This could make it difficult or impossible to retrieve the records that relate to a particular nominal code for example
If a nominal description was changed many transactions would need to be edited.
If no transaction refers to a particular nominal code, there will be no record anywhere in the database of that code’s existence.
By putting all the nominal codes and their descriptions into a separate table we can solve all these problems:

Each code and description is held once only - the duplicated field is a small numeric field rather than two large text fields;

Changing the code or description once in the nominal codes table changes it for all transactions;

All nominal codes that are, or maybe needed, are kept in the nominal codes table.
3

Having split our data into different tables, we need to be able to link the two tables. The nominal code table needs a field that uniquely identifies each record in the table, this is known as the ‘primary key’ field. The transaction table then needs a field that holds the reference to the nominal code key field. The linking fields need to be the same data type. Often the key field will be an ‘AutoNumber’ field – this is a Long Integer (big number, no decimal point) which is automatically incremented when new records are set up. When saving a table for the first time, you will be prompted to designate a key field if you haven’t already done so – if you have an AutoNumber field this will be used as the key field, otherwise a new AutoNumber field will be added. Tables don’t have to have a primary key field, but it’s usually a good idea to include one. A field that refers to another tables primary key field is knows as the ‘foreign key’ field.
So hopefully you are convinced that we have at least two entities, and need at least two tables. L et’s now list the items of data we will be keeping for each one:
2.2.3.1 Transactions
ID
Analysis code
Source code
Date
Reference number
Description
Value
Type
2.2.3.2 Nominal ledger code details
ID
Code
Description
Type
We have added some fields in green. We have already mentioned that we need to include a unique ‘ID’ field in the nominal codes table, and we need to link our transactions table to this unique field. Our example is relatively complicated, as our transactions table has two fields which link to the nominal code table – the source code and the analysis code. Usually there would just be one – e.g. an invoice would have single field linking it to a customer.
We have also in cluded an ID field in our transactions table. This isn’t essential – there is no other table in our database that will link TO our transactions table. However, as we mentioned above, having a unique field is usually a good idea as it does give us a quick and reliable method of identifying a particular record.
This leaves us with the two ‘type’ fields. Our database is designed to deal with different types of transaction – e.g. bank and cash, or journal. In order to identify the type of the transaction we need a type field. However, using the same logic we used to separate our transactions and nominal codes tables, we separate our transactions table from the description of our transaction type to avoid duplication or incorrect entries. So our ‘type’ field in the transactions table is a link to the ID field of our ‘transaction type’ table. Similarly we might need to separate our nominal codes into different types – profit and loss or balance sheet – for example. So again we have a nominal code type table, These are our additional tables:
4

2.2.3.3 Transaction types
ID
Description
Short description
2.2.3.4 Nominal ledger type
ID
Description
Again we could choose to use a wizard to help set up our table, but we will start with the basics and choose ‘Design view’. Here is our blank table design screen:
We now need to consider which table to set up first. Where one table links to another, Access has a ‘lookup wizard’ that helps us to set up the link. To use this as we set up the table, we need to ensure that the tables that are linked to (nominal analysis code type, transaction type and nominal analysis code) are set up before the tables that link to them (transactions). So we will start with Nominal analysis code type:
5

Transaction type
Transactions Nominal analysis code
Nominal analysis code type
When we set up the definition of a table field, we need to give that field a name, specify what sort of data it is to contain, and often enter further details about it – known as properties.
We enter the fields and main properties in Access as follows:
Field name
CodeTypeID
CodeTypeDescription
Data type Caption Data type/length
Autonumber ID
Text Description
Long integer
50
Notice that we have entered the ‘Field name’ without the spaces, but with initial capitals. You will often see this format used in databases – one advantage is that it makes it easier for
Access to know you are referring to a particular field, rather than just typing text, because there are no spaces to confuse it.
The CodeTypeID field is going to be the ‘key’ field, so it must be unique to each record. The simplest way of achieving this is to choose the ‘AutoNumber’ data type. This creates a number which is automatically incremented each time a new record is set up, and is therefore unique to each record. Unless you already have a unique code that you need to use, it is good idea to use AutoNumber for your key fields as the user then doesn’t have to worry about ensuring new entries have unique codes.
6

Let’s have a look at the field properties for this field. The field size options vary according to the data type of the field. For a number field such as this, the field size defines the type of number. Pressing ‘F1’ whilst the cursor is in the field size field will display a help screen detailing the options for this data type. Generally numbers where you don’t need to enter decimals are held as long integers, and numbers requiring decimal places as ‘double precision’. We can set a format to control how the information in the field is to be displayed – particularly useful for dates and times and numbers. We can also use the ‘Input mask’ field to speed up data entry by creating a defined format for the way the data is entered – for example, an input mask for a date field could be set up to request 3 sets of 2 numbers with the intervening ‘/’ being entered automatically. Next comes the caption. This is very useful, as it will appear as the heading for our columns, and can be automatically included in any forms or reports that refer to this field. Where we are using the initial capitals convention for our field name, it is a good idea to enter the caption in normal English:
You will see that the last entry in our Field Properties screen is ‘Indexed’ and currently shows:
Yes (Duplicates OK). This may strike you as strange, since we claimed that the whole point of this field was to be unique, the therefore duplicates are definitely not OK! Watch what happens when we set this field to be the ‘key’ field by clicking the picture of a key on the toolbar:
7

The key appears to the left of the field to show it has been designated as the ‘Primary Key’, and we now have (No Duplicates) beside indexed. Indexing fields can have a dramatic effect on the performance of your database. It is a bit like an index in a book. If you want to find all references to ‘Word Art’ in ‘Using Microsoft Office 2000’ you could start at page one and check each page through to the last page (page 1473), or you could look it up in the index, and go straight to each reference. Like a book, the more data, the bigger the time difference between the two methods!
Once we have entered all the information required for the transactions table we can close the table . As we do so, we will be asked to give it a name and save it. We’ll call it ‘tblCodeType’.
Now we will set up the other tables required in the same way:
Field name Data type Caption Data type/length
TransactionTypeID Autonumber ID
TransactionTypeDescription Text Description
Long integer
50
Field name Data type Caption Data type/length
NominalID
NominalCode
NominalDescription
NominalTypeRef
Autonumber ID
Text Code
Text
Number
Description
Type
Long integer
10
50
Long Integer
8

Note that the last field in the table is the one that links to tblCodeType. We have used the
‘lookup wizard’ data type to let Access take us through the process of creating the link step by step. We have used both the fields in tblCodeType and accepted the default suggestions, but changed the label name to ‘Nominal Type’ and the field name to ‘NominalTypeRef’.
Field name Data type Caption Data format/length
TransactionID
TransactionAnalysisCode
TransactionSourceCode
TransactionDate
TransactionNumber
TransactionDescription
TransactionValue
TransactionTypeRef
Autonumber ID
Number Analysis code
Number
Date
Source code
Date
Text
Text
Currency
Number
Number
Description
Value
Type
Long integer
Long integer
Long integer
Short date
10
50
Currency
Long integer
The tran sactions table includes 3 ‘lookup’ fields. TransactionAnalysisCode and
TransactionSourceCode both refer to tblNominalCode, and we have included the first three fields – ID, code and description – when prompted by the wizard. TransactionTypeRef refers to tblTransactionType and is set up pretty much the same way as NominalTypeRef in tblNominalCode
Our tables have been named using the ‘Hungarian naming convention’. This convention allocates a three letter description to each object within the database. A few examples follow:
Object Designator table tbl query qry form frm report rpt
Example tblTransactionTypes qryDetailedNominal frmETB rptNominalDetails
In addition to the prefix, you will notice that all the object names use the initial capitals format.
The benefits of using a naming convention are as follows:
Consistency - all objects are named in a similar way. This makes it much easier to remember object names without having to look them up all the time.
Identification - because the name of each object identifies what type of object it is, it makes it much easier to understand any expressions or programming code that refer to a range of different kinds of Access objects.
9

A potential problem with any relational database is the deletion of records in one table that are related to those in another table. For example if there are transactions that are linked to nominal code ‘1000’ and someone deletes nominal code ‘1000’ those transactions will become ‘orphan’ records, and the integrity of the database will be compromised. When you used the ‘lookup wizard’ to create your ‘foreign key’ fields, Access created ‘joins’ between the two tables for you. You can look at the way your tables are joined by choosing the
‘Relationships’ option from the ‘Tools’ menu. This will show us the joins that Access has already created for us:
We have expanded the tables and moved them around to show the links more clearly.
We can right click on each of the join lines and then use the ‘Edit Relationship’ option to enforce referential integrity:
We can then click the ‘Enforce Referential Integrity’ check box. You can see that in our example the relationship is ‘One-To-Many’ - each NominalID exists once in tblNominalCode
(the ‘One’) table, but many times in tblTransaction (the ‘Many’ table).
Referential integrity can be enforced by ensuring that you cannot delete a record in the ‘One’ table if a record referring to it exists in the ‘Many’ table, or by ensuring that if you delete the
‘One’ record, all the ‘Many’ records will also be deleted - this is the ‘Cascade Delete Related
Records’ option. The latter option is obviously rather dangerous and is likely to be set only in unusual circumstances. Here we can see our Relationships screen with referential integrity set up for each join.
10

That’s the end of part 1. We have worked out how to structure the data within our applications, and create the four main tables, and enforced referential integrity. In the next episode we will concentrate on setting up some of the forms for our application.
11

Our IT Clinic feature has now been running for about 5 years. During this time we have covered an enormous range of different queries that our Gold Card and eSupport clients have presented us with. We have taken all the IT Clinic articles from IT Regularly and organised them by application with a full, detailed index. The CD includes a printable Word document version together with an HTML version suitable for browsing or adding to your office Intranet.
Just complete and return this order form, or send an email to clinic@tkb.co.uk
stating whether you would like a personal, 10 user or unlimited version.
Applications covered include Excel, Word, PowerPoint, Outlook and Access. Each article includes step-by-step instructions with appropriate screen shots. If you have any queries please call us on 01403 270970 or email simonh@tkb.co.uk
.
NAME
ORGANISATION
ADDRESS
Please tick
tick the appropriate boxes and return to us – we will send you an invoice
please SEND WITH REMITTANCE TO The Knowledge Base, 7 Kings Court, Harwood
Road, Horsham, West Sussex, RH13 5UR. Please make cheques payable to The
Knowledge Base
PHONE 01403 270970
FAX TO 0871 242 0556 (this is a fax to email service)
12