Database Design Principles - Access Database Design and Programming - page 35

ISBN = 0-55-123456-9
Title = Main Street
Authors = Jones, H. and Smith, K.
Publisher = Small House
Since the table scheme in this case allows more than one author name for the Authors
attribute, the scheme is not in first normal form. Indeed, one of the obvious problems
with the Authors attribute is that it is impossible to sort the data by individual author
name. It is also more difficult to, for instance, prepare a mailing label for each author, and
so on.
Attributes that allow only indivisible values are said to be scalar attributes or atomic
attributes . By contrast, an attribute whose values can be, for example, a list of items
(such as a list of authors) is said to be a structured attribute . Thus, a table scheme is in
first normal form if all of its attributes are atomic. Good database design almost always
requires that all attributes be atomic, so that the table scheme is in first normal form.
In general, making the adjustments necessary to ensure first normal form is not hard, and
it is a good general rule that table schemes should be put in first normal form. However,
as with the other normal forms (and even more so the higher up we go) each situation
must be considered on its own merits. For instance, a single field might be designed to
hold a street address, such as “1333 Bessemer Street.” Whether the house number and the
street name should be separated into distinct attributes is a matter of context. Put another
way, whether a street address is atomic depends upon the context. If there is reason to
manipulate the street numbers apart from the street names, then they should certainly
constitute their own attribute. Otherwise, perhaps not.
4.4 Functional Dependencies
Before we can discuss the other normal forms, we need to discuss the concept of
functional dependency , which is used to define these normal forms. This concept is quite
simple, and we have actually been using it for some time now. As an example, we have
remarked that, for the Publishers table scheme, the PubName attribute depends
completely on the PubID attribute. (More properly, we should say that the value of the
PubName attribute depends completely on the value of the PubID attribute, but the earlier
shorthand is convenient.) Thus, we can say that the functional dependency from PubID to
PubName, written:
PubID PubName
holds for the Publishers table scheme. This can be read “PubID determines PubName” or
“PubName depends on PubID.”
More generally, suppose that {A 1 ,...,A k } are attributes of a table scheme and that
{B 1 ,...,B n } are also attributes of the same table scheme. We do not require that the Bs be
different from the As. Then the attributes B 1 ,...,B n depend on the attributes A 1 ,...,A k ,
written: