Database

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 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 to examine its design.
Follow these basic steps when designing your database.
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). 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 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
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.