Gathering Data


To start creating an Access application, you need two things: a clear idea of what tasks the application should perform and the output it should produce, and an adequate quantity of realistic data. Rather than just asking the client for a list of the tasks the application needs to perform, I usually ask a series of questions designed to elicit the required information. A typical Q&A session is presented in the next section of this chapter. However, if there is already a functioning database, printouts of its reports and screen shots of its forms can be helpful as an indication of what tasks are currently being done.

For best results, there is no substitute for large quantities of real data, such as the ebook data in the sample EBook Companion database used in Chapter 9, Reworking an Existing Application. But if you have a reasonable quantity of representative data and a client who is willing to answer your questions, that should be sufficient to set up tables with the correct fields. With this information, you can create tables with the necessary fields; set up relationships between them; and proceed to create the queries, forms, reports, and VBA code that will let you create an application that does what the client wants.

Curiously, I’m often asked to start working on an application for a client without any data at all. It may be difficult to convey this concept to a client, but it is important to get real-life data (either in electronic or paper form) in order to set up tables and fields correctly. If you (the developer) have to create dummy data to have something to work with when creating tables and other database objects, you will probably end up having to make changes—possibly major changes—to tables later on, and find that further changes are needed to other database components; so, it really helps to have a substantial amount of representative data to work with.

However, realistically there are cases where you won’t be able to get data from the client. There are two cases where data isn’t available: a brand-new business (or other enterprise) that doesn’t have any data yet, and a business whose data is confidential. In these cases, you just have to do the best you can, creating dummy data after questioning the client about what data needs to be stored in the application’s tables.

Once you have obtained the data in electronic or paper form, it’s best to just use it as raw material to help you determine what fields you need when designing tables and other components, rather than as ready-made components to plug into your application. Looking at real data, you can see (for example) whether or not there are unique IDs for products. If there is a unique Product ID, that field should be the key field of the Products table; otherwise, you will need to create an AutoNumber field. If you see multiple addresses for customers or clients, you will need to create linked tables for address data, for purposes of normalization; if there is only one address per customer or client, address data can be stored directly in the Customers or Clients table. In most cases, even if you are given a database with Access tables, you will need to make some modifications for purposes of normalization, and create a number of supporting tables as well as lookup tables to use as the row sources of comboboxes used to select values or records.




Expert One-on-One(c) Microsoft Access Application Development
Expert One-on-One Microsoft Access Application Development
ISBN: 0764559044
EAN: 2147483647
Year: 2006
Pages: 124
Authors: Helen Feddema

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net