Database Reference
In-Depth Information
Table 4.4
The Albums
AlbumName
ReleaseDate ArtistName
White
6/10/2005
Juices of Brazil
Home
10/01/2006
The Awkward Stage
On The Sea
5/25/1997
Girth
Spicy Legumes
11/12/2005
Wasabi Peanuts
Running the Game
7/27/1985
The Bobby Jenkins Band
Live!
10/30/1988
The Bobby Jenkins Band
Long Road
1/01/2003
Juices of Brazil
We've solved the problem by adding another entity that stores album
names as well the attribute that represents the relationship to the artist en-
tity. Neither of these entities has a repeating group, each attribute in both
entities holds a single value, and all of the previously mentioned query
problems have been eliminated. This database is now in 1NF and ready to
be deployed, right? Considering there are several other normal forms, we
think you know the answer.
Second Normal Form (2NF)
Second normal form
(2NF) specifies that, in addition to meeting 1NF,
all non-key attributes have a functional dependency on the entire primary
key. A
functional dependency
is a one-way relationship between the pri-
mary key attribute (or attributes) and all other non-key attributes in the
same entity. Referring again to Table 4.3, if ArtistName is the primary key,
then all other attributes in the entity must be identified by ArtistName. So
we can say, “ArtistName determines ReleaseDate” for each instance in the
entity. Notice that the relationship does not necessarily hold in the reverse
direction; any genre may appear multiple times throughout this entity.
Nonetheless, for any given artist, there is one genre. But what if an artist
crosses over to another genre?
To answer that question, let's compare 1NF to 2NF. In 1NF, we have
no repeating groups, and all attributes have a single value. However, in
1NF, if we have a composite primary key, it is possible that there are at-
tributes that rely on only one of the primary key attributes, and that can
lead to strange data manipulation anomalies. Take a look at Table 4.5, in
Search WWH ::
Custom Search