Many people believe Access is such a simple
product to use that database design is something they don’t need to
worry about. I couldn’t disagree more! Just as a poorly planned
vacation will generally not be very fun, a database with poorly
designed tables and relationships will fail to meet the needs of its
users.
The History of Relational Database Design
Dr. E. F. Codd first introduced formal relational database design in 1969 while he was at IBM. Relational theory,
which is based on set theory and predicate logic, applies to both
databases and database applications. Codd developed 12 rules that
determine how well an application and its data adhere to the relational
model. Since Codd first conceived these 12 rules, the number of rules
has expanded into the hundreds.
You should be happy to learn that, although
Microsoft Access is not a perfect application development environment,
it measures up quite well as a relational database system.
Goals of Relational Database Design
The number one goal of relational database design is
to, as closely as possible, develop a database that models some
real-world system. This involves breaking the real-world system into
tables and fields and determining how the tables relate to each
other. Although on the surface this might appear to be a trivial task,
it can be an extremely cumbersome process to translate a real-world
system into tables and fields.
A properly designed database has many benefits. The
processes of adding, editing, deleting, and retrieving table data are
greatly facilitated in a properly designed database. In addition,
reports are easy to build. Most important, the database is easy to
modify and maintain.
Rules of Relational Database Design
To adhere to the relational model, you must follow
certain rules. These rules determine what you store in a table and how
you relate the tables. The rules are as follows
The Rules of Tables
Each table in a system must store data about a single entity. An entity
usually represents a real-life object or event. Examples of objects are
customers, employees, and inventory items. Examples of events include
orders, appointments, and doctor visits.
The Rules of Uniqueness and Keys
Tables are composed of rows and columns. To adhere
to the relational model, each table must contain a unique identifier.
Without a unique identifier, it is programmatically impossible to
uniquely address a row. You guarantee uniqueness in a table by
designating a primary key, which is a single column or a set of columns that uniquely identifies a row in a table.
Each column or set of columns in a table that contains unique values is considered a candidate key. One candidate key becomes the primary key. The remaining candidate keys become alternate keys. A primary key made up of one column is considered a simple key. A primary key composed of multiple columns is considered a composite key.
It is generally a good idea to choose a primary key that is
Following
these rules greatly improves the performance and maintainability of a
database application, particularly if it deals with large volumes of
data.
Consider the example of an employee table. An
employee table is generally composed of employee-related fields such as
social security number, first name, last name, hire date, salary, and
so on. The combination of the first name and the last name fields could
be considered a primary key. This might work until the company hires
two employees who have the same name. Although the first and last names
could be combined with additional fields (for example, hire date) to
constitute uniqueness, that would violate the rule of keeping the
primary key minimal. Furthermore, an employee might get married, and
her last name might change. This violates the rule of keeping a primary
key stable. Therefore, using a name as the primary key violates the
principle of stability. The social security number might be a valid
choice for primary key, but a foreign employee might not have a social
security number. This is a case in which a derived, rather than a
natural, primary key is appropriate. A derived key is an artificial key that you create. A natural key is one that is already part of the database.
In examples such as this, I suggest adding
EmployeeID as an AutoNumber field. Although the field would violate the
rule of simplicity (because an employee number is meaningless to the
user), it is both small and stable. Because it is numeric, it is also
efficient to process. In fact, I use AutoNumber fields as primary keys for most of the tables that I build.
The Rules of Foreign Keys and Domains
A foreign key in
one table is the field that relates to the primary key in a second
table. For example, the CustomerID field may be the primary key in a
Customers table and the foreign key in an Orders table.
A domain is a pool of values from which
columns are drawn. A simple example of a domain is the specific data
range of employee hire dates. In the case of the Orders table, the
domain of the CustomerID column is the range of values for the
CustomerID in the Customers table.
