About designing a database

The first step in designing a database is to determine its purpose and how it's to be used:

• Talk to people who will use the database. Brainstorm about the questions you and they would like the database to answer.

• Sketch out the reports you'd like the database to produce.

• Gather the forms you currently use to record your data.

As you determine the purpose of your database, a list of information you want from the database will begin to emerge. From that, you can determine what facts you need to store in the database and what subject each fact belongs to. These facts correspond to the fields (columns) in your database, and the subjects that those facts belong to correspond to the tables.

Each field is a fact about a particular subject. For example, you might need to store the following facts about your customers: company name, address, city, state, and phone number. You need to create a separate field for each of these facts. When determining which fields you need, keep these design principles in mind:

• Include all of the information you will need.
• Store information in the smallest logical parts. For example, employee names are often split into two fields, FirstName and LastName, so that it's easy to sort data by LastName.

• Don't create fields for data that consists of lists of multiple items. For example, in a Suppliers table, if you create a Products field that contains a comma-separated list of each product you receive from the supplier, it will be more difficult to find only the suppliers that provide a particular product.

• Don't include derived or calculated data (data that is the result of an expression). For example, if you have a UnitPrice field and a Quantity field, don't create an additional field that multiplies the values in these two fields.
• Don't create fields that are similar to each other. For example, in a Suppliers table, if you create the fields Product1, Product2, and Product3, it will be more difficult to find all suppliers who provide a particular product. Also, you will have to change the design of your database if a supplier provides more than three products. You need only one field for products if you put that field in the Products table instead of in the Suppliers table.

Each table should contain information about one subject. Your list of fields will provide clues to the tables you need. For example, if you have a HireDate field, its subject is an employee, so it belongs in the Employees table. You might have a table for Customers, a table for Products, and a table for Orders.

When you decide which table each field belongs to, keep these design principles in mind:

• Add the field to only one table.

• Don't add the field to a table if it will result in the same information appearing in multiple records in that table. If you determine that a field in a table will contain a lot of duplicate information, that field is probably in the wrong table.

  For example, if you put the field containing the address of a customer in the Orders table, that information will probably be repeated in more than one record, because the customer will probably place more than one order. However, if you put the address field in the Customers table, it will appear only once. In this respect, a table in a Microsoft Access database differs from a table in a flat file database such as a spreadsheet.

  When each piece of information is stored only once, you update it in one place. This is more efficient, and it also eliminates the possibility of duplicate entries that contain different information.

In order for Microsoft Access to connect information stored in separate tables— for example, to connect a customer with all the customer's orders— each table in your database must include a field or set of fields that uniquely identifies each individual record in the table. Such a field or set of fields is called a primary key.

Now that you've divided your information into tables and identified primary key fields, you need a way to tell Microsoft Access how to bring related information back together again in meaningful ways. To do this, you define relationships between tables.

You may find it useful to view the relationships in an existing well-designed database such as the Northwind sample database.

After you have designed the tables, fields, and relationships you need, it's time to study the design and detect any flaws that might remain. It is easier to change your database design now than it will be after you have filled the tables with data.

Use Microsoft Access to create your tables, specify relationships between the tables, and enter enough sample data in your tables so you can test your design. To test the relationships in your database, see if you can create queries to get the answers you want. Create rough drafts of your forms and reports and see if they show the data you expect. Look for unnecessary duplications of data and eliminate them.

When you are satisfied that the table structures meet the design principles described here, then it's time to go ahead and add all your existing data to the tables. You can then create other database objects— - queries, forms, reports, data access pages, macros, and modules.

Microsoft Access includes two tools that can help you refine the design of a Microsoft Access database.

• The Table Analyzer can analyze the design of one table at a time, can propose new table structures and relationships if appropriate, and can divide a table into new related tables if that makes sense.

• The Performance Analyzer can analyze your entire database and make recommendations and suggestions for improving it. The wizard can also implement these recommendations and suggestions.