Database Reference
In-Depth Information
You began establishing table-level integrity when you defined a primary key for each table
andensureditsenforcementbymakingabsolutelycertainthateachprimarykeyfullycom-
plied with the Elements of a Primary Key. In the next chapter, you'll enhance the table's
integrity further as you establish
field specifications
for each field within the table.
Reviewing the Initial Table Structures
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 mean-
ingful to everyone.
When a name or description appears to be confusing or am-
biguous 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.
Select-
ing field names typically generates a great deal of discussion, especially when
there is an existing database in place. You'll commonly find people who customar-
ily 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 al-
low 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 in
•
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 accident-
ally overlooked one or two characteristics earlier in the design process. When this
