Attempting to create an Access database from scratch can be a daunting process, particularly if you are a beginner. Experienced users will be able to tell you of the many mistakes we all make while learning particularly on a trial and error basis. Most designers of databases will spend most of their time on the design as this is the tricky bit. It is actually relatively simple to build a database, but designing it is the tricky part. One reason for this is that users do not know what they want or they have an idea, but do not express it to you clearly. If you rush the process or do not understand their requirements fully then you are in danger of building them a database which will be redundant before you have even begun. The first step in database design is to fully understand the user requirements.

How can this be achieved? The first step is to find out exactly who will be using it and go and talk to them. Everyone will have their own ideas. The first alarm bell of database design comes up here. A user will say, 'I just want a simple database where I can enter these details and get a sales total at the end of the month.' Be warned in bright red letters! They may want this, but they will want a whole lot more than this as well, particularly once they start to use it. This is known in the trade as the wish list and it gets bigger with every step. Part of database design is anticipating this.

One reason for fully exploring a possible wish list is that as the designer it is likely you will be helping to help estimate the cost for the project. It should be made clear to the client and to the project manager exactly what you are estimating time for. I would suggest giving a detailed list of tasks and requirements to both parties to justify your estimate and get them signed off. This way a client can see exactly what you are charging them for and will have a much harder time arguing. When they come back with an increased wish list it will also prevent them saying that they already requested things that they did not and expecting them done for free. In my experience, half the battle of designing and building is getting the client to be fully aware of what they have asked for and been quoted for and what they will be charged for in addition if they request it.

In order to prevent problems like this it is best to learn to ask the right questions. Do not ask the user what they want the database to do. You are the designer not them. Instead, begin by asking them to describe their work, tasks and processes. If it is a sales process, how is the sale made from start to finish? As the designer you will be able to deduce what information will be required and translate that into tables and forms. Remember to ask the clients about situations that are outside of the normal parameters. Some of the most useful questions begin with 'what happens in this scenario?' It may be that exceptions to the rules require special database design and a user may not even think of it to begin with.

Once the processes have been examined, ask what information the users require from the database. Do they have regular meetings with sales managers that require sales reports? What information is on those reports? What is the breakdown of the reports? Are they required by sales area and sales person or simply a total? This will enable you to build a series of Access reports that will be truly useful to the user. Finding out the full details of the requirements in advance will prevent you having to design and build as you go. There will always be extras and changes, but these should be minimum one off type of tasks rather than a continued theme of your project.

One major part of the Access database project should always be the testing of the database. Time should be allowed for you to test that the database works and then for the users to test it. They will come back with problems or requested changes which you will complete and then the final stage of testing should be completed. A database should never be delivered as finished without this stage as there are always things that will require changes.

One final note is that all emails received from and sent to a client should always be saved. On many occasions irate clients have sworn that they did not ask for something that has been done and charged for. It is very satisfying for the designer to politely send them their own email with the original request! As a database designer it is important to protect yourself as well as the client!