Database Reference
In-Depth Information
field represents. It should also state the field's role within the table or its relation-
ship to the table's subject. Here's an example of such a description:
CustCity—the metropolitan area in which a customer resides or
conducts business. This is an integral component of a customer's
complete address.
•
Write a clear and succinct statement.
The description should be free of confusing
sentences or ambiguous phrases. Although the description should be as complete
as possible, use the minimum number of words necessary to convey the required
information. As you've seen with table descriptions, verbose statements are diffi-
cult to read and understand.
•
Refrain from restating or rephrasing the field name.
Neither of these practices
does anything to illuminate the identity or purpose of the field. Remember that the
purpose of a description is to provide a complete interpretation of the field. Here's
an example of a poor description:
CustLast Name—the last name of a customer.
A description is far more useful when you write it in this manner:
CustLast Name—the surname of a customer, whether original or
by marriage, that we use in all formal communications and cor-
respondence with that customer.
•
Avoid using technical jargon, acronyms, or abbreviations.
Although some people
within the organization will understand these types of idioms, it's better for you to
use terminology that everyone understands. Remember that a description must be
as clear as possible to
anyone
who reads it. For example, you should avoid this
type of statement:
Employee ID Number—a unique number used to identify an em-
ployee within the organization. It is a component of the SSP.
The problem with this description is that there is no inherent way to determine the
meaning of the acronym SSP. You could resolve this problem by spelling out the
complete term, but it would be better for you to restate the purpose of the field.
•
Do not include implementation-specific information.
There's no reason to include
the fact that a given field appears on a particular data entry screen or is used within
a specific piece of programming code. This type of information is more appropri-
ate for the implementation phase of the overall database development process.
•
Do not make this description dependent upon the description of another field.
Each
description should be as complete as possible and independent of every other de-
scription in the database.
Interdependent
descriptions introduce unnecessary con-
