Good database design ensures that your database is easy to maintain. You store data in tables and each table contains data about only one subject, such as customers. Therefore, you update a particular piece of data, such as an address, in just one place and that change automatically appears throughout the database.
A well-designed database usually contains different types of queries that show the information you need. A query might show a subset of data, such as all customers in London, or combinations of data from different tables, such as order information combined with customer information.
This query retrieves the order ID, company name, city, and required date information for customers in London whose orders were required in April.
The results you want from your database —- the forms and data access pages (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.) you want to use, and the reports you want to print —- don't necessarily provide clues about how you should structure the tables in your database, because you often base forms, reports, and data access pages on queries instead of tables.
Before you use Microsoft Access to actually build tables, queries, forms, and other objects, it's a good idea to sketch out and rework your design on paper first. You can also examine well-designed databases similar to the one you are designing, or you can open the Northwind sample database and then open the Relationships window (Relationships window: An object tab in which you view, create, and modify relationships between tables and queries.) to examine its design.
Follow these basic steps when designing your database.
Determine the purpose of your 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.
Determine the fields you need in the database
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 (expression: Any combination of mathematical or logical operators, constants, functions, and names of fields, controls, and properties that evaluates to a single value. Expressions can perform calculations, manipulate characters, or test data.)). 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.
Determine the tables you need in the database
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.
Determine which table each field belongs to
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 (Microsoft Access database: A collection of data and objects (such as tables, queries, or forms) that is related to a particular topic or purpose.) 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.
Identify the field or fields with unique values in each record
Determine the relationships between tables
Refine your design
Enter data and create other database objects
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 (query: A question about the data stored in your tables, or a request to perform an action on the data. A query can bring together data from multiple tables to serve as the source of data for a form or report.), forms (form: An Access database object on which you place controls for taking actions or for entering, displaying, and editing data in fields.), reports (report: An Access database object that you can print, which contains information that is formatted and organized according to your specifications. Examples of reports are sales summaries, phone lists, and mailing labels.), data access pages (data access page: A Web page, published from Access, that has a connection to a database. In a data access page, you can view, add to, edit, and manipulate the data stored in the database. A page can also include data from other sources, such as Excel.), macros (macro: An action or set of actions that you can use to automate tasks.), and modules (module: A collection of declarations, statements, and procedures stored together as one named unit. There are two types of modules: standard modules and class modules.).
Use Microsoft Access analysis tools
For more information about designing a database in Access, see the Knowledge Base article Where to find information about designing a database in AccessWhere to find information about designing a database in Access.
