Now that the fundamental table definitions are complete, you need to
conduct interviews with users and management to review the work you've
done so far. This set of interviews is fairly straightforward and should
be relatively easy to conduct.
During these interviews, you will
accomplish these tasks:
- Ensure that the appropriate subjects are represented in the
database. Although it's highly unlikely that an important subject
is missing at this stage of the database-design process, it can
happen. When it does happen, identify the subject, use the proper
techniques to transform it into a table, and develop it to the same
degree as the other tables in the database.
- Make certain that the table names and table descriptions are
suitable and meaningful to everyone. When a name or description
appears to be confusing or ambiguous to several people in the
organization, work with them to clarify the item as much as possible.
It's common for some table names and descriptions to improve during
the interview process.
- Make certain that the field names are suitable and meaningful
to everyone. Selecting field names typically generates a great
deal of discussion, especially when there is an existing database in
place. You'll commonly find people who customarily refer to a
particular field by a certain name because "that's what it's called on
my screen." When you change a field name—you have good reasons for
doing so—you must diplomatically explain to these folks that you
renamed the field so that it conforms to the standards imposed by the
new database. You can also tell them that the field can appear with
the more familiar name once the database is implemented in an RDBMS
program. What you've said is true; many RDBMSs allow you to use one
name for the field's physical definition and another name for display
purposes. This feature, however, does not change, reduce, or negate
the need for you to follow the guidelines for creating field names
that you learned.
- Verify that all the appropriate fields are assigned to each
table. This is your best opportunity to make certain that all of
the necessary characteristics pertaining to the subject of the table
are in place. You'll commonly discover that you accidentally
overlooked one or two characteristics earlier in the design process.
When this happens, identify the characteristics, use the appropriate
techniques to transform them into fields, and follow all the necessary
steps to add them to the table.
When you've completed the interviews, you'll move to the next phase
of the database-design process and establish field specifications
for every field in the database.
It's now time to establish keys for each table in the Mike's Bikes
database. As you know, your first order of business is to establish
candidate keys for each table. Let's say you decide to start with the
CUSTOMERS table in Figure 8.9.
8.9 The CUSTOMERS table structure in the Mike’s Bikes database.
As you review each field, you try to determine whether it conforms to
the Elements of a Candidate Key. You determine that STATUS, CUSTHOME
PHONE, and the combination of CUSTFIRST NAME and CUSTLAST NAME are
potential candidate keys, but you're not quite certain whether any of
them will completely conform to all of the elements. So you decide to
test the keys by loading the table with sample data as shown in
8.10 Testing candidate keys in the CUSTOMERS table.
Always remember that a field must comply with all of the
Elements of a Candidate Key in order to qualify as a candidate key. You
must immediately disqualify the field if it does not fulfill this
As you examine the table, you draw these conclusions:
- STATUS is ineligible because it will probably contain duplicate
values. As business grows, Mike is going to have many "Valued"
- CUSTHOME PHONE is ineligible because it will probably contain
duplicate values. The sample data reveals that two customers can live
in the same residence and have the same phone number.
- CUSTFIRST NAME and CUSTLAST NAME are ineligible because they will
probably contain duplicate values. The sample data reveals that the
combination of first name and last name can represent more than one
These findings convince you to establish an artificial candidate key
for this table. You then create a field called CUSTOMER ID, confirm that
it complies with the requirements for a candidate key, and add the new
field to the table structure with the appropriate designation.
Figure 8.11 shows the revised structure of
the CUSTOMERS table.
8.11 The CUSTOMERS table with the new artificial candidate key,
Now you'll repeat this procedure for each table in the database.
Remember to make certain that every table has at least one
The next order of business is to establish a primary key for each
table. As you know, you select the primary key for a particular table
from the table's pool of available candidate keys. Here are a few points
to keep in mind when you're choosing a primary key for a table with more
than one candidate key:
- Choose a simple (single-field) candidate key over a composite
- If possible, pick a candidate key that has the table name
incorporated into its own name.
- Select the candidate key that best identifies the subject of the
table or is most meaningful to everyone in the organization.
You begin by working with the EMPLOYEES table in
Figure 8.12. As you review the candidate keys,
you decide that EMPLOYEE NUMBER is a much better choice for a primary
key than the combination of EMPFIRST NAME and EMPLAST NAME because
Mike's employees are already accustomed to identifying themselves by
their assigned numbers. Using EMPLOYEE NUMBER makes perfect sense, so
you select it as the primary key for the table.
8.12 The EMPLOYEES table structure in the Mike’s Bikes database.
Now you perform one final task before you designate EMPLOYEE NUMBER
as the official primary key of the table: You make absolutely certain
that it exclusively identifies the value of each field within a given
record. So, you test EMPLOYEE NUMBER by following these steps:
- Load the EMPLOYEES table with sample data.
- Select a record for test purposes and note the current value of
- Examine the value of the first field (the one immediately after
EMPLOYEE NUMBER) and ask yourself this question:
Does this primary
key value exclusively identify the current value of
- If the answer is yes, move to the next field and repeat the
- If the answer is no, remove the field from the table,
move to the next field and repeat the question. (Be sure to
determine whether you can add the field you just removed to another
table structure, if appropriate, or discard it completely because it
is truly unnecessary.)
- Continue this procedure until you've examined every field value in
You know that you'll have to remove any field containing a value that
EMPLOYEE NUMBER does not exclusively identify. EMPLOYEE NUMBER
does exclusively identify the value of each field in the test record,
however, so you use it as the official primary key for the EMPLOYEES
table and mark its name with the letters "PK" in the table structure.
You then repeat this process with the rest of the tables in Mike's new
database until every table has a primary key.
Remember to keep these rules in mind as you establish primary keys
for each table:
- Each table must have one—and only one—primary key.
- Each primary key within the database should be unique—no two
tables should have the same primary key (unless one of them is a
As you work through the tables in Mike's database, you remember that
the SERVICES table is a subset table. You created it during the previous
stage of the design process, and it represents a more
specific version of the subject represented by the PRODUCTS table. The
PRODUCT NAME field is what currently relates the PRODUCTS table to the
SERVICES subset table. You now know, however, that a subset table
must have the same primary key as the table to which it is related,
so you'll use PRODUCT NUMBER (the primary key of the PRODUCTS table) as
the primary key of the SERVICES table. Figure 8.13
shows the PRODUCTS and SERVICES tables with their primary keys.
8.13 Establishing the primary key for the SERVICES subset table.
The last order of business is to conduct interviews with Mike and his
staff and review all the work you've performed on the tables in the
database. As you conduct these interviews, make certain you check the
- That the appropriate subjects are represented in the database
- That the table names and descriptions are suitable and meaningful
- That the field names are suitable and meaningful to everyone
- That all the appropriate fields are assigned to each table
By the end of the interview, everyone agrees that the tables are in
good form and that all the subjects with which they are concerned are
represented in the database. Only one minor point came up during the
discussions: Mike wants to add a CALL PRIORITY field to the VENDORS
table. There are instances in which more than one vendor supplies a
particular product, and Mike wants to create a way to indicate which
vendor he should call first if that product is unexpectedly out of
stock. So, you add the new field to the VENDORS table and bring the
interview to a close.