Microsoft Office Tutorials and References
In Depth Information
Designing a Database
of tables in this database, I can assemble team rosters, make a list of coaches
and their contact information, list teams by division, put together a mailing
list of all players, find out which players have paid their fee, and list players
by age group, among other things. This database comprises four tables:
✦ Players: Includes fields for tracking players’ names, addresses,
birthdays, which teams they’re on, and whether they paid their fees.
✦ Coaches: Includes fields for tracking coaches’ names, addresses, and the
names of the teams they coach.
✦ Teams: Includes fields for tracking team names and which division each
team is in.
✦ Divisions: Includes fields for tracking division numbers and names.
Deciding how many database tables you need and how to separate data
across the different tables is the hardest part of designing a database. To
make the task a little easier, do it the old-fashioned way with a pencil and
eraser. Here are the basic rules for separating data into different tables:
✦ Restrict a table to one subject only: Each database table should hold
information about one subject only — customers, employees, products,
and so on. This way, you can maintain data in one table independently
from data in another table. Consider what would happen in the little
league database (refer to Figure 1-7) if coach and team data were kept in
a single table, and one team’s coach was replaced by someone new. You
would have to delete the old coach’s record, delete information about
the team, enter information about the new coach, and re-enter
information about the team that you just deleted. But by keeping team
information separate from coach information, you can update coach information
and still maintain the team information.
✦ Avoid duplicate information: Try not to keep duplicate information in
the same database table or duplicate information across different tables.
By keeping the information in one place, you have to enter it only once,
and if you have to update it, you can do so in one database table, not
Entire books have been written about database design, and this topic can’t
do the subject justice. You can, however, store all your data in a single table
if the data you want to store isn’t very complex. The time you lose entering
all the data in a single table is made up by the time you save not having to
design a complex database with more than one table.