Database design basics

Access for Microsoft 365 Access 2021 Access 2019 Access 2016 Access 2013.

A properly designed database provides you with access to up-to-date, accurate information.
Because a correct design is essential to achieving your goals in working with a database,
investing the time required to learn the principles of good design makes sense. In the end, you
are much more likely to end up with a database that meets your needs and can easily
accommodate change.

This article provides guidelines for planning a desktop database. You will learn how to decide
what information you need, how to divide that information into the appropriate tables and
columns, and how those tables relate to each other. You should read this article before you create
your first desktop database.

Important:  Access provides design experiences that let you create database applications for the
Web. Many design considerations are different when you design for the Web. This article doesn't
discuss Web database application design. For more information, see the article Build a database
to share on the Web.

In this article

 Some database terms to know

 What is good database design?
 The design process
 Determining the purpose of your database
 Finding and organizing the required information
 Dividing the information into tables
 Turning information items into columns
 Specifying primary keys
 Creating the table relationships
 Refining the design
 Applying the normalization rules

Some database terms to know

Access organizes your information into tables: lists of rows and columns reminiscent of an
accountant’s pad or a spreadsheet. In a simple database, you might have only one table. For most
databases you will need more than one. For example, you might have a table that stores
information about products, another table that stores information about orders, and another table
with information about customers.

Each row is more correctly called a record, and each column, a field. A record is a meaningful
and consistent way to combine information about something. A field is a single item of
information — an item type that appears in every record. In the Products table, for instance, each
row or record would hold information about one product. Each column or field holds some type
of information about that product, such as its name or price.

What is good database design?

Certain principles guide the database design process. The first principle is that duplicate
information (also called redundant data) is bad, because it wastes space and increases the
likelihood of errors and inconsistencies. The second principle is that the correctness and
completeness of information is important. If your database contains incorrect information, any
reports that pull information from the database will also contain incorrect information. As a
result, any decisions you make that are based on those reports will then be misinformed.

A good database design is, therefore, one that:

 Divides your information into subject-based tables to reduce redundant data.

 Provides Access with the information it requires to join the information in the tables
together as needed.
 Helps support and ensure the accuracy and integrity of your information.
 Accommodates your data processing and reporting needs

The design process

The design process consists of the following steps:

 Determine the purpose of your database    

This helps prepare you for the remaining steps.

 Find and organize the information required     

Gather all of the types of information you might want to record in the database, such as
product name and order number.

 Divide the information into tables    

Divide your information items into major entities or subjects, such as Products or Orders.
Each subject then becomes a table.

 Turn information items into columns    

Decide what information you want to store in each table. Each item becomes a field, and is
displayed as a column in the table. For example, an Employees table might include fields such as
Last Name and Hire Date.

 Specify primary keys    

Choose each table’s primary key. The primary key is a column that is used to uniquely identify
each row. An example might be Product ID or Order ID.

 Set up the table relationships    

Look at each table and decide how the data in one table is related to the data in other tables. Add
fields to tables or create new tables to clarify the relationships, as necessary.

 Refine your design    

Analyze your design for errors. Create the tables and add a few records of sample data. See if
you can get the results you want from your tables. Make adjustments to the design, as needed.

 Apply the normalization rules    

Apply the data normalization rules to see if your tables are structured correctly. Make
adjustments to the tables, as needed.

Determining the purpose of your database

It is a good idea to write down the purpose of the database on paper — its purpose, how you
expect to use it, and who will use it. For a small database for a home based business, for
example, you might write something simple like "The customer database keeps a list of customer
information for the purpose of producing mailings and reports." If the database is more complex
or is used by many people, as often occurs in a corporate setting, the purpose could easily be a
paragraph or more and should include when and how each person will use the database. The idea
is to have a well developed mission statement that can be referred to throughout the design
process. Having such a statement helps you focus on your goals when you make decisions.

Finding and organizing the required information

To find and organize the information required, start with your existing information. For example,
you might record purchase orders in a ledger or keep customer information on paper forms in a
file cabinet. Gather those documents and list each type of information shown (for example, each
box that you fill in on a form). If you don't have any existing forms, imagine instead that you
have to design a form to record the customer information. What information would you put on
the form? What fill-in boxes would you create? Identify and list each of these items. For
example, suppose you currently keep the customer list on index cards. Examining these cards
might show that each card holds a customers name, address, city, state, postal code and
telephone number. Each of these items represents a potential column in a table.

As you prepare this list, don’t worry about getting it perfect at first. Instead, list each item that
comes to mind. If someone else will be using the database, ask for their ideas, too. You can fine-
tune the list later.
Next, consider the types of reports or mailings you might want to produce from the database. For
instance, you might want a product sales report to show sales by region, or an inventory
summary report that shows product inventory levels. You might also want to generate form
letters to send to customers that announces a sale event or offers a premium. Design the report in
your mind, and imagine what it would look like. What information would you place on the
report? List each item. Do the same for the form letter and for any other report you anticipate
creating.

Giving thought to the reports and mailings you might want to create helps you identify items you
will need in your database. For example, suppose you give customers the opportunity to opt in to
(or out of) periodic e-mail updates, and you want to print a listing of those who have opted in. To
record that information, you add a “Send e-mail” column to the customer table. For each
customer, you can set the field to Yes or No.

The requirement to send e-mail messages to customers suggests another item to record. Once
you know that a customer wants to receive e-mail messages, you will also need to know the e-
mail address to which to send them. Therefore you need to record an e-mail address for each
customer.

It makes good sense to construct a prototype of each report or output listing and consider what
items you will need to produce the report. For instance, when you examine a form letter, a few
things might come to mind. If you want to include a proper salutation — for example, the "Mr.",
"Mrs." or "Ms." string that starts a greeting, you will have to create a salutation item. Also, you
might typically start a letter with “Dear Mr. Smith”, rather than “Dear. Mr. Sylvester Smith”.
This suggests you would typically want to store the last name separate from the first name.

A key point to remember is that you should break each piece of information into its smallest
useful parts. In the case of a name, to make the last name readily available, you will break the
name into two parts — First Name and Last Name. To sort a report by last name, for example, it
helps to have the customer's last name stored separately. In general, if you want to sort, search,
calculate, or report based on an item of information, you should put that item in its own field.
Think about the questions you might want the database to answer. For instance, how many sales
of your featured product did you close last month? Where do your best customers live? Who is
the supplier for your best-selling product? Anticipating these questions helps you zero in on
additional items to record.

After gathering this information, you are ready for the next step.

Dividing the information into tables

To divide the information into tables, choose the major entities, or subjects. For example, after
finding and organizing information for a product sales database, the preliminary list might look
like this:

The major entities shown here are the products, the suppliers, the customers, and the orders.
Therefore, it makes sense to start out with these four tables: one for facts about products, one for
facts about suppliers, one for facts about customers, and one for facts about orders. Although this
doesn’t complete the list, it is a good starting point. You can continue to refine this list until you
have a design that works well.

When you first review the preliminary list of items, you might be tempted to place them all in a
single table, instead of the four shown in the preceding illustration. You will learn here why that
is a bad idea. Consider for a moment, the table shown here:

In this case, each row contains information about both the product and its supplier. Because you
can have many products from the same supplier, the supplier name and address information has
to be repeated many times. This wastes disk space. Recording the supplier information only once
in a separate Suppliers table, and then linking that table to the Products table, is a much better
solution.

A second problem with this design comes about when you need to modify information about the
supplier. For example, suppose you need to change a supplier's address. Because it appears in
many places, you might accidentally change the address in one place but forget to change it in
the others. Recording the supplier’s address in only one place solves the problem.

When you design your database, always try to record each fact just once. If you find yourself
repeating the same information in more than one place, such as the address for a particular
supplier, place that information in a separate table.

Finally, suppose there is only one product supplied by Coho Winery, and you want to delete the
product, but retain the supplier name and address information. How would you delete the product
record without also losing the supplier information? You can't. Because each record contains
facts about a product, as well as facts about a supplier, you cannot delete one without deleting
the other. To keep these facts separate, you must split the one table into two: one table for
product information, and another table for supplier information. Deleting a product record should
delete only the facts about the product, not the facts about the supplier.

Once you have chosen the subject that is represented by a table, columns in that table should
store facts only about the subject. For instance, the product table should store facts only about
products. Because the supplier address is a fact about the supplier, and not a fact about the
product, it belongs in the supplier table.

Turning information items into columns

To determine the columns in a table, decide what information you need to track about the subject
recorded in the table. For example, for the Customers table, Name, Address, City-State-Zip,
Send e-mail, Salutation and E-mail address comprise a good starting list of columns. Each record
in the table contains the same set of columns, so you can store Name, Address, City-State-Zip,
Send e-mail, Salutation and E-mail address information for each record. For example, the
address column contains customers’ addresses. Each record contains data about one customer,
and the address field contains the address for that customer.

Once you have determined the initial set of columns for each table, you can further refine the
columns. For example, it makes sense to store the customer name as two separate columns: first
name and last name, so that you can sort, search, and index on just those columns. Similarly, the
address actually consists of five separate components, address, city, state, postal code, and
country/region, and it also makes sense to store them in separate columns. If you want to perform
a search, filter or sort operation by state, for example, you need the state information stored in a
separate column.

You should also consider whether the database will hold information that is of domestic origin
only, or international, as well. For instance, if you plan to store international addresses, it is
better to have a Region column instead of State, because such a column can accommodate both
domestic states and the regions of other countries/regions. Similarly, Postal Code makes more
sense than Zip Code if you are going to store international addresses.

Don’t include calculated data    

In most cases, you should not store the result of calculations in tables. Instead, you can have
Access perform the calculations when you want to see the result. For example, suppose there is a
Products On Order report that displays the subtotal of units on order for each category of product
in the database. However, there is no Units On Order subtotal column in any table. Instead, the
Products table includes a Units On Order column that stores the units on order for each product.
Using that data, Access calculates the subtotal each time you print the report. The subtotal itself
should not be stored in a table.

 Store information in its smallest logical parts    

You may be tempted to have a single field for full names, or for product names along
with product descriptions. If you combine more than one kind of information in a field, it
is difficult to retrieve individual facts later. Try to break down information into logical
parts; for example, create separate fields for first and last name, or for product name,
category, and description.