Database Reference
In-Depth Information
tion. So you decide to conduct a brief interview with some of the staff in order to
determine what the letters represent. (Now, this is the scary part.) To your disbe-
lief, you discover that the folks in
personnel
think it stands for “Steering Commit-
tees”; the
information systems
staff believes it to be “System Configurations”; and
the people in
security
insist that it represents “Security Codes.” This example
clearly illustrates why you should make every effort to avoid using abbreviations
and acronyms in a table name.
•
Do not use proper names or other words that will unduly restrict the data that can
be entered into the table.
This guideline will keep you from falling into the trap of
creating duplicate table structures. A name such as “Southwest Region Employ-
ees,” for example, severely restricts the data that you can enter into this table. As
the organization grows, how will you deal with employees from other regions?
When the organization begins to hire employees in Washington, Oregon, and
Idaho, you'll have to create a “Pacific Northwest Region Employees” table, and
you'll have to create a “Western Region Employees” table when the organization
begins to hire folks in Arizona, Utah, Nevada, and California.
Proper database design principles dictate that you should not create duplicate
structures such as these because they can be quite problematic.
1.
Users could have a difficult time retrieving data from all three tables simultan-
eously.
2.
The person maintaining the database would have the added responsibility of
ensuring that the tables are always structurally synchronized. If he adds, modi-
fies, or deletes a field in one table, he must take the same action on all the oth-
er tables.
3.
The person maintaining the database would also have the added responsibility
of ensuring synchronized data integrity between the tables. He must be able to
guarantee that data is completely and accurately transferred from one table to
the other when an employee relocates from one region to another.
•
Do not use a name that implicitly or explicitly identifies more than one subject.
This is one of the most common mistakes you can make with a table name, and it
is relatively easy to identify. This type of name typically contains the word
and
or
or
and characters such as the slash (\) or ampersand (&); examples include “De-
partment or Branch” and “Facility\Building.” A table with an ambiguous name
suggests that you may have not identified the subject clearly or accurately during
the analysis and interview processes. You can rectify this problem by reviewing
your notes and conducting further analysis and interviews as necessary. Just re-
member that you must always ensure that each table represents only one subject.
