# NORMALIZATION

1.

TUTORIAL (EXTRA)
Given the dependency diagram, answer items a-c:

C 1

C 2

C 3

C 4

C 5

a.

Identify and discuss each of the indicated dependencies.

C1 → C2 represents a partial dependency, because C2 depends only on C1, rather than on the entire primary key composed of C1 and C3. C4 → C5 represents a transitive dependency, because C5 depends on an attribute (C4) that is not part of a primary key. C1, C3 → C2, C4, C5 represents a set of proper functional dependencies, because C2, C4, and C5 depend on the primary key composed of C1 and C3. b. Create a database whose tables are at least in 2NF, showing the dependency diagrams for each table.

Tab 1 le Prim key: C ary 1 Foreign key: N one N orm form 3N al : F

C 1

C 2

T le 2 ab C 1 C 3 C 4 C 5 Prim key: C + C ary 1 3 Foreign key: C (to Table 1) 1 N orm form 2N because the al : F, table exhibits the transitive dependencies C 4 C 5

c. Create a database whose tables are at least in 3NF, showing the dependency diagrams for each table.

C1

C2

Table 1 Primary key: C1 Foreign key: None Normal form: 3NF

C1

C3

C4

Table 2 Primary key: C1 + C3 Foreign key: C1 (to Table 1) C4 (to Table 3) Normal form: 3NF Table 3 Primary key: C4 Foreign key: None Normal form: 3NF

C4

C5

Transitive dependency is a condition in which an attribute is dependent on another attribute that is not part of the primary key. This kind of dependency usually requires the decomposition of the table containing the transitive dependency. To remove a transitive dependency, the designer must perform the following actions: • Place the attributes that create the transitive dependency in a separate table. • Make sure that the new table's primary key attribute is the foreign key in the original table. Figure Q5.9 shows an example of a transitive dependency removal.

Figure Q5.9 Transitive Dependency Removal

Original table

INV_NUM

INV_DATE

INV_AMOUNT

CUS_NUM

CUS_PHONE

Transitive Dependencies

INV_NUM

INV_DATE

INV_AMOUNT

CUS_NUM New Tables

CUS_NUM

CUS_PHONE

1. Using the INVOICE table structure shown in Table P5.1, write the relational schema, draw its dependency diagram and identify all dependencies (including all partial and transitive dependencies). You can assume that the table does not contain repeating groups and that any invoice number may reference more than one product. (Hint: This table uses a composite primary key.) 2. Using the initial dependency diagram drawn in Problem 1, remove all partial dependencies, draw the new dependency diagrams, and identify the normal forms for each table structure you created.

Table P5.1 Sample INVOICE Records
Attribute Name INV_NUM PROD_NUM SALE_DATE PROD_LABEL VEND_CODE VEND_NAME QUANT_SOLD Sample Value 211347 AA-E3422QW 15-Jan-2006 Rotary sander 211 NeverFail, Inc. 1 Sample Value 211347 QD-300932X 15-Jan-2006 0.25-in. drill bit 211 NeverFail, Inc. 8 Sample Value 211347 RU-995748G 15-Jan-2006 Band saw 309 BeGood, Inc. 1 Sample Value 211348 AA-E3422QW 15-Jan-2006 Rotary sander 211 NeverFail, Inc. 2 Sample Value 211349 GH-778345P 16-Jan-2006 Power drill 157 ToughGo, Inc. 1

\$3.45

\$39.99

\$49.95

\$87.75

NOTE
You can assume that any given product is supplied by a single vendor but a vendor can supply many products. Therefore, it is proper to conclude that the following dependency exists: PROD_NUM → PROD_DESCRIPTION, PROD_PRICE, VEND_CODE, VEND_NAME (Hint: Your actions should produce three dependency diagrams.)

Figure P5.1&2 The Problems 1 and 2

Dependency

Diagrams

for

INV_NUM PROD_NUM SALE_DATE

Partial dependency

Relational schema: 1NF(INV_NUM

VEND_NA

Sign up to vote on this title