Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Table of Contents
SOME DATABASE TERMS TO KNOW ........................................................................................................ 1
WHAT IS GOOD DATABASE DESIGN? ....................................................................................................... 2
THE DESIGN PROCESS ................................................................................................................................... 2
DETERMINING THE PURPOSE OF YOUR DATABASE ............................................................................................. 3
FINDING AND ORGANIZING THE REQUIRED INFORMATION ................................................................................. 3
DIVIDING THE INFORMATION INTO TABLES ........................................................................................................ 4
TURNING INFORMATION ITEMS INTO COLUMNS ................................................................................................. 5
SPECIFYING PRIMARY KEYS................................................................................................................................ 6
CREATING THE TABLE RELATIONSHIPS............................................................................................................... 6
Creating a one-to-many relationship ............................................................................................................. 6
Creating a many-to-many relationship .......................................................................................................... 7
Creating a one-to-one relationship ................................................................................................................ 7
REFINING THE DESIGN ........................................................................................................................................ 8
REFINING A TABLE.............................................................................................................................................. 9
APPLYING THE NORMALIZATION RULES ........................................................................................................... 10
First normal form ......................................................................................................................................... 10
Second normal form ..................................................................................................................................... 10
Third normal form ........................................................................................................................................ 10
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.
http://ict.maxwell.syr.edu/
http://ict.maxwell.syr.edu/
http://ict.maxwell.syr.edu/
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.
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 doesnt 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 suppliers
address in only one place solves the problem.
Good Database Design Training Session Handout
Page 4
Most topics came directly from Microsoft Access Help.
http://ict.maxwell.syr.edu/
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.
http://ict.maxwell.syr.edu/
http://ict.maxwell.syr.edu/
Access can then use the supplier ID number in the Products table to locate the correct supplier for each
product. The Supplier ID column in the Products table is called a foreign key. A foreign key is another tables
primary key.
You provide the basis for joining related tables by establishing pairings of primary keys and foreign keys. If
you are not sure which tables should share a common column, identifying a one-to-many relationship ensures
that the two tables involved will, indeed, require a shared column.
http://ict.maxwell.syr.edu/
If the two tables have the same subject, you can probably set up the relationship by using the same primary
key in both tables.
If the two tables have different subjects with different primary keys, choose one of the tables (either one)
and insert its primary key in the other table as a foreign key.
Determining the relationships between tables helps you ensure that you have the right tables and columns.
When a one-to-one or one-to-many relationship exists, the tables involved need to share a common column or
columns. When a many-to-many relationship exists, a third table is needed to represent the relationship.
http://ict.maxwell.syr.edu/
Refining a table
Suppose that each product in the product sales database falls under a general category, such as beverages,
condiments, or seafood. The Products table could include a field that shows the category of each product.
Suppose that after examining and refining the design of the database, you decide to store a description of the
category along with its name. If you add a Category Description field to the Products table, you have to repeat
each category description for each product that falls under the category this is not a good solution.
A better solution is to make Categories a new subject for the database to track, with its own table and its own
primary key. You can then add the primary key from the Categories table to the Products table as a foreign
key.
The Categories and Products tables have a one-to-many relationship: a category can include more than one
product, but a product can belong to only one category.
When you review your table structures, be on the lookout for repeating groups. For example, consider a table
containing the following columns:
Product ID
Name
http://ict.maxwell.syr.edu/
http://ict.maxwell.syr.edu/