12.1 introduction (1/3)

Further Normalization I: Further Normalization I:

1NF, 2NF, 3NF, BCNF1NF, 2NF, 3NF, BCNF

Prof. Yin-Fu HuangProf. Yin-Fu Huang

CSIE, NYUST CSIE, NYUST

Chapter 12Chapter 12

Advanced Database System Yin-Fu Huang

Redundancy (See Fig. 12.1)

A good design principle is “one fact in one place” The principles of further normalization allow us to recognize t

he redundancy and to replace the relvars in question by ones that are more desirable in some way.

e.g., {S#,City,P#,Qty} {S#,City}, {S#,P#,Qty}

12.112.1 Introduction (1/3) Introduction (1/3)



Normal forms

A relvar is said to be in a particular normal form if it satisfies a

certain prescribed set of conditions. The normalization procedure is reversible; it means the normal

ization process is nonloss or information-preserving. Codd: 1NF, 2NF, 3NF, BCNF Fagin: 4NF, PJ/NF (5NF)

(See Fig. 12.2)



Two remarks:

1. Normalization is a useful aid in the process, but it is not a panacea.

2. The ideas of normalization can then be used to verify that the resulting design does not unintentionally violate any of the normalization principles.


12.212.2 Nonloss Decomposition and Functional DependeNonloss Decomposition and Functional Dependenciesncies

Whether a given decomposition is nonloss is intimately bound up with the concept of functional dependence.

Decomposition is actually a process of projection. Example (See Fig. 12.3)

The reversibility means that the original relvar is equal to the join of its projections.


12.212.2 Nonloss Decomposition and Functional DeNonloss Decomposition and Functional Dependencies (Cont.)pendencies (Cont.)

Heath’s theorem: Let R{A,B,C} be a relvar, where A, B, and C are sets of attributes. If R satisfies the FD A →B, then R is equal to the join of its projections on {A,B} and {A,C}.

In case (b), one of the FDs is lost in the decomposition.

FD S#→City More on functional dependencies: 1. Irreducibility {S#,P#}→City 2. FD diagrams (See Fig. 12.4)

3. FDs are a semantic notion A special kind of integrity constraint


We assume for simplicity that each relvar has exactly one candidate key, which we further assume is the primary key.

Third normal form (very informal definition): A relvar is in 3NF if and only if the nonkey attributes are both:

(a) Mutually independent

(b) Irreducibly dependent on the primary key. First normal form: A relvar is in 1NF if and only if, in every le

gal value of that relvar, every tuple contains exactly one value for each attribute.

Example (See Fig. 12.5 & 12.6)

The primary key of FIRST is {S#,P#}.

12.312.3 First, Second, and Third Normal Forms (1/6)First, Second, and Third Normal Forms (1/6)


Fig. 12.5 & 12.6Fig. 12.5 & 12.6


Relvar FIRST violates both conditions a and b in our preliminary 3NF definition. Update anomalies corresponding to the FD S#→City After decomposition

SECOND(S#,Status,City), SP(S#,P#,Qty)

(See Fig. 12.7 & 12.8)



Fig. 12.7 & 12.8Fig. 12.7 & 12.8


The effect of the decomposition of FIRST into SECOND and SP is to eliminate the dependencies that are not irreducible. Second normal form: A relvar is in 2NF if and only if it is in 1NF and every nonkey attribute is irreducibly dependent on the primary key. In summary

R{A,B,C,D}

Primary Key {A,B}

A →D

R1{A,D}

Primary Key {A}

R2{A,B,C}

Primary Key {A,B}

Foreign Key {A} References R1



Transitive: If A→B and B→C, then A→C Update anomalies corresponding to the FD City →Status After decomposition SC(S#,City), CS(City, Status)

(See Fig. 12.9 & 12.10)



The effect of the further decomposition is to eliminate the transitive dependencies of STATUS on S#.

Third normal form: A relvar is in 3NF if and only if it is in 2NF and every nonkey attribute is nontransitively dependent on the primary key.



In summary

R{A,B,C}

Primary Key {A}

B →C

R1{B,C}

Primary Key {B}

R2{A,B}

Primary Key {A}

Foreign Key {B} References R1 It is not possible just to look at the value at a given time and to

say whether the relvar is in 3NF. Even knowing the dependencies, it is never possible to prove b

y examining a given value that the relvar is in 3NF.



12.412.4 Dependency Preservation (1/3)Dependency Preservation (1/3)

A given relvar can be nonloss-decomposed in a variety of different ways.

Example (See Fig. 12.11)

Decomposition A: SC{S#,City} and CS{City,Status}

Decomposition B: SC{S#,City} and SS{S#,Status}



Decomposition B is less satisfactory than decomposition A.

It is still not possible in B to insert the information that a particular city has a particular status unless some supplier is located in that city.

In decomposition A, the two projections are independent of one another.

In decomposition B, updates to either of the two projections must be monitored to ensure that the FD City →Status is not violated.



A guideline for independent projections:

Rissanen shows that projections R1 and R2 of a relvar R are independent if and only if both of the following are true:

1. Every FD in R is a logical consequence of those in R1 and R2.

2. The common attributes of R1 and R2 form a candidate key for at least one of the pair.

A relvar that cannot be decomposed into independent projections is called atomic.

The fact that some given relvar is not atomic should not necessarily be taken to mean that it should be decomposed into atomic components.


12.512.5 Boyce/Codd Normal FormBoyce/Codd Normal Form (1/7) (1/7)

Considering the case of a relvar that

1. Had two or more candidate keys, such that

2. The candidate keys were composite, and

3. They overlapped (i.e., had at least one attribute in common) Boyce/Codd normal form: A relvar is in BCNF if and only if e

very nontrivial, left-irreducible FD has a candidate key as its determinant.

In other words, the only arrows in the FD diagram are arrows out of candidate keys.

e.g., FIRST is not in BCNF determinants S#, City, {S#,P#}

candidate keys {S#,P#}

SECOND is not in BCNF determinants S#, City

candidate keys S#

SP, SC, and CS are each in BCNF



Example: Two disjoint candidate keys

S{S#,Sname,Status,City} BCNF

(See Fig. 12.12)


12.512.5 Boyce/Codd Normal FormBoyce/Codd Normal Form (3/7) (3/7) Example: Overlapping candidate keys

SSP{S#,Sname,P#,Qty}

determinants S#, Sname, {S#,P#}, {Sname,P#}candidate keys {S#,P#}, {Sname,P#}

It is not in BCNF, but is in 3NF.(See Fig. 12.13)

Two projections:

1. SS{S#,Sname} and SP{S#,P#,Qty}

2. SS{S#,Sname} and SP{Sname,P#,Qty}



Example: Overlapping candidate keys

SJT{S,J,T}

The constraints:

1. For each subject, each student of that subject is

taught by only one teacher.

2. Each teacher teaches only one subject (but each

subject is taught by several teachers).

(See Fig. 12.14 & 12.15)



T is a determinant but not a candidate key.

not in BCNF

But they are not independent.

The FD {S,J}→T cannot be deduced from the FD

T →J.

Inserting a tuple for Smith and Prof. Brown into relvar ST

reject

Two projections: ST{S,T} and TJ{T,J}



The twin objectives of (a) decomposing a relvar into BCNF components, and (b) decomposing it into independent components can occasionally be in conflict.

Relation SJT is atomic in Rissanen’s sense, even though it is not in BCNF.

The fact that an atomic relvar cannot be decomposed into independent components does not mean that it cannot be decomposed at all.



Example: Overlapping candidate keys

EXAM{S,J,P}

The constraint:

There are no ties; that is, no two students obtained

the same position in the same subject.

(See Fig. 12.16)

Two candidate keys: {S,J}, {J,P} BCNF


12.612.6 A Note on Relation-Valued AttributesA Note on Relation-Valued Attributes(1/3)(1/3)

Asymmetric



Example: 1. Get S# for suppliers who supply part P1

2. Get P# for parts supplied by supplier S1

(SPQ Where Tuple {P# P#(‘P1’)} PQ {P#}) {S#}

((SPQ Where S# = S# (‘S1’)) Ungroup PQ) {P#}

Example: 1. Create a new shipment for supplier S6, part P5,

quantity 500

2. Create a new shipment for supplier S2, part P5,

quantity 500

Insert SPQ Relation

{ Tuple { S# S# (‘S6’),

PQ Relation { Tuple { P# P#(‘P5’),

Qty Qty (500) } } } };

Update SPQ Where S# = S# (‘S2’)

{ Insert PQ Relation { Tuple { P# P#(‘P5’),

Qty Qty (500) } } };


However this position should be seen as a guideline only, not as an inviolable law.

Var RVK Base Relation

{ Rvname Name, Ck Relation { Attrname Name } }

Key { Rvname, Ck };

(See Fig. 12.18)



Fig. 12.18Fig. 12.18


The End.

12.1 introduction (1/3)

Documents