Database Modeling & Design Fourth Edition- P31 docx

6.6 Summary 137
A many-to-many-to-many ternary relationship is:
• BCNF if it can be replaced by two binary relationships
• 4NF if it can only be replaced by three binary relationships
• 5NF if it cannot be replaced in any way (and thus is a true ternary
relationship)
We observe the equivalence between certain ternary relationships
and the higher normal form tables transformed from those relation-
ships. Ternary relationships that have at least one “one” entity cannot
be decomposed (or broken down) into binary relationships, because that
would destroy the one or more FDs required in the definition, as shown
previously. A ternary relationship with all “many” entities, however, has
no FDs, but in some cases may have MVDs, and thus have a lossless
decomposition into equivalent binary relationships.
In summary, the three common cases that illustrate the correspon-
dence between a lossless decomposition in a many-to-many-to-many
ternary relationship table and higher normal forms in the relational
model are shown in Table 6.8.
6.6 Summary
In this chapter, we defined the constraints imposed on tables—most
commonly the functional dependencies or FDs. Based on these con-
straints, practical normal forms for database tables are defined: 1NF, 2NF,
3NF, and BCNF. All are based on the types of FDs present. In this chapter,
a practical algorithm for finding the minimum set of 3NF tables is given.
Table 6.8 Summary of Higher Normal Forms
Table Name Normal Form
Two-way Lossless
decomp/join?
Three-way Lossless
decomp/join?
Nontrivial

MVDs
skill_required BCNF yes yes 2
skill_in_
common
4NF no yes 0
skill_used 5NF no no 0
Teorey.book Page 137 Saturday, July 16, 2005 12:57 PM
138 CHAPTER 6 Normalization
The following statements summarize the functional equivalence
between the ER model and normalized tables:
1. Within an entity. The level of normalization is totally dependent
upon the interrelationships among the key and nonkey
attributes. It could be any form from unnormalized to BCNF or
higher.
2. Binary (or binary recursive) one-to-one or one-to-many relationship.
Within the “child” entity, the foreign key (a replication of the pri-
mary key of the “parent”) is functionally dependent upon the
child’s primary key. This is at least BCNF, assuming that the entity
by itself, without the foreign key, is already BCNF.
3. Binary (or binary recursive) many-to-many relationship. The intersec-
tion table has a composite key and possibly some nonkey
attributes functionally dependent upon it. This is at least BCNF.
4. Ternary relationship.
a. one-to-one-to-one => three overlapping composite keys, at
least BCNF
b. one-to-one-to-many => two overlapping composite keys, at
least BCNF
c. one-to-many-to-many => one composite key, at least BCNF
d. many-to-many-to-many => one composite key with three
attributes, at least BCNF; in some cases it can be also 4NF, or

even 5NF
In summary, we observed that a good, methodical conceptual design
procedure often results in database tables that are either normalized
(BCNF) already, or can be normalized with very minor changes.
6.7 Literature Summary
Good summaries of normal forms can be found in Date [1999], Kent
[1983], Dutka and Hanson [1989], and Smith [1985]. Algorithms for nor-
mal form decomposition and synthesis techniques are given in Bern-
stein [1976], Fagin [1977], and Maier [1983]. The earliest work in normal
forms was done by Codd [1970, 1974].
Teorey.book Page 138 Saturday, July 16, 2005 12:57 PM
139
7
An Example of Logical
Database Design
he following example illustrates how to proceed through the require-
ments analysis and logical design steps of the database life cycle, in a
practical way, for a relational database.
7.1 Requirements Specification
The management of a large retail store would like a database to keep
track of sales activities. The requirements analysis for this database led to
the six entities and their unique identifiers shown in Table 7.1.
The following assertions describe the data relationships:
• Each customer has one job title, but different customers may have
the same job title.
• Each customer may place many orders, but only one customer
may place a particular order.
• Each department has many salespeople, but each salesperson
must work in only one department.
• Each department has many items for sale, but each item is sold in

only one department. (“Item” means item type, like IBM PC).
T
Teorey.book Page 139 Saturday, July 16, 2005 12:57 PM
140 CHAPTER 7 An Example of Logical Database Design
• For each order, items ordered in different departments must
involve different salespeople, but all items ordered within one
department must be handled by exactly one salesperson. In other
words, for each order, each item has exactly one salesperson; and
for each order, each department has exactly one salesperson.
For physical design (e.g., access methods, etc.) it is necessary to
determine what kind of processing needs to be done on the data; that is,
what are the queries and updates needed to satisfy the user require-
ments, and what are their frequencies? In addition, the requirements
analysis should determine whether there will be substantial database
growth (i.e., volumetrics); in what time frame that growth will take
place; and whether the frequency and type of queries and updates will
change, as well. Decay as well as growth should be estimated, as each
will have significant effect on the later stages of database design.
7.1.1 Design Problems
1. Using the information given and, in particular, the five assertions,
derive a conceptual data model and a set of functional dependen-
cies (FDs) that represent all the known data relationships.
2. Transform the conceptual data model into a set of candidate SQL
tables. List the tables, their primary keys, and other attributes.
3. Find the minimum set of normalized (BCNF) tables that are func-
tionally equivalent to the candidate tables.
Table 7.1 Requirements Analysis Results
Entity
Entity key
in characters

Key
length(max)
Number of
occurrences
Customer cust-no 6 80,000
Job job-no 24 80
Order order-no 9 200,000
Salesperson sales-id 20 150
Department dept-no 2 10
Item item-no 6 5,000
Teorey.book Page 140 Saturday, July 16, 2005 12:57 PM
7.2 Logical Design 141
7.2 Logical Design
Our first step is to develop a conceptual data model diagram and a set of
FDs to correspond to each of the assertions given. Figure 7.1 presents the
diagram for the ER model, and Figure 7.2 shows the equivalent diagram
for UML. Normally, the conceptual data model is developed without
knowing all the FDs, but in this example the nonkey attributes are omit-
ted so that the entire database can be represented with only a few state-
ments and FDs. The result of this analysis, relative to each of the asser-
tions given, follows in Table 7.2.
The candidate tables required to represent the semantics of this
problem can be derived easily from the constructs for entities and rela-
tionships. Primary keys and foreign keys are explicitly defined.
Figure 7.1 Conceptual data model diagram for the ER model
N
N1
1
1
N

N
N
N11
1
N
1
Customer
SalespersonOrder
Job
Department
Item
order-
item-sales
contains
has
order-
dept-sales
places
hires
Teorey.book Page 141 Saturday, July 16, 2005 12:57 PM