Scribd
Upload
40 views

Normal

The document discusses database normalization. It aims to avoid data redundancy and anomalies during updates or deletes. Normalization decomposes relations into boyce-codd normal form (BCNF) or third normal form (3NF) by removing partial and transitive dependencies. This ensures decompositions are lossless joins that preserve all functional dependencies.

Uploaded by

benben08
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
40 views

Normal

The document discusses database normalization. It aims to avoid data redundancy and anomalies during updates or deletes. Normalization decomposes relations into boyce-codd normal form (BCNF) or third normal form (3NF) by removing partial and transitive dependencies. This ensures decompositions are lossless joins that preserve all functional dependencies.

Uploaded by

benben08
Copyright
© Attribution Non-Commercial (BY-NC)
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 34

Normalization

CIS 331: Introduction to Database Systems

Normalization: Reminder
Why do we need to normalize?
To avoid redundancy (less storage space needed, and data is consistent) To avoid update/delete anomalies

Vladimir Vacic, Temple University

Normalization: Reminder
Ssn 123 123 123 c-id Grade Name smith smith smith Address Main Main Main cs331 A cs351 B cs211 A

Clearly, Name and Address are redundant (larger relation + you have to update 3 rows to update the Address)
Vladimir Vacic, Temple University
3

Normalization: Reminder
Ssn c-id Grade Name 123 cs331A Address smith Main

234 null null

jones Forbes

Insertion anomaly: Cannot make a record Jones address because he is not taking any classes
Vladimir Vacic, Temple University
4

Normalization: Reminder
Ssn 123 124 125 c-id Grade Name jones smith shmoo Address 123 Main 124 Broad 42 Penn cs331 A cs351 B cs211 A

Delete anomaly: Cannot delete Shmoos enrolment without loosing his address as well
Vladimir Vacic, Temple University
5

Normal Forms
First Normal Form 1NF Second Normal Form 2NF Third Normal Form 3NF Fourth Normal Form 4NF Fifth Normal Form 5NF (so far conveniently named) Boyce-Codd Normal Form BCNF
Vladimir Vacic, Temple University
6

First Normal Form (1NF)


1NF: all attributes are atomic (no repeating groups)
Last Name
Smith

First Name

Not in 1NF

Peter Mary John Rumpelstiltskin Anne Michael


Vladimir Vacic, Temple University
7

First Normal Form (1NF)


Last Name
Smith Smith Smith Rumpelstiltskin Rumpelstiltskin

First Name
Peter Mary John Anne Michael

Normalized to 1NF

Vladimir Vacic, Temple University

First Normal Form (1NF)


Name Michael Raphael Gabriel Uriel Metatron Weight 187 lb 192 lb 201 lb 165 lb 195 kg

Not in 1NF

Vladimir Vacic, Temple University

First Normal Form (1NF)


Name Michael Raphael Gabriel Uriel Metatron Weight 187 192 201 165 195 Unit lb lb lb lb kg

Normalized to 1NF

Vladimir Vacic, Temple University

10

First Normal Form (1NF)


Supplier S1 S2 S3 Part P1, P3, P4 P3 P2, P3

Not in 1NF

Vladimir Vacic, Temple University

11

First Normal Form (1NF)


Is this relation in 1NF?
Supplier S1 S2 S3 Part1 P1 P3 P2 Part2 P3 null P3 Part3 P4 null null

Formally yes, but in essence, NO!


Vladimir Vacic, Temple University
12

First Normal Form (1NF)


Supplier S1 S1 S1 S2 S3 S3 Part P1 P3 P4 P3 P2 P3

Normalized to 1NF

Vladimir Vacic, Temple University

13

Second Normal Form (2NF)


2NF:
1NF and all non-key attributes are fully dependent on the PK (no partial dependencies)
Student Erik Sven Inge Hildur Course_ID CIS331 CIS331 CIS331 CIS362 Grade A B C A Address 80 Ericsson Av. 12 Olafson St. 192 Odin Blvd. 212 Reykjavik St.
14

Not in 2NF

Vladimir Vacic, Temple University

Second Normal Form (2NF)


Student Erik Sven Inge Hildur Student Erik Sven Inge Hildur
Vladimir Vacic, Temple University

Address 80 Ericsson Av. 12 Olafson St. 192 Freya Blvd. 212 Reykjavik St. Course_ID CIS331 CIS331 CIS331 CIS362 Grade A B C A

Normalized to 2NF

15

Second Normal Form (2NF)

Student

Address

Course_ID

Grade

Vladimir Vacic, Temple University

16

Third Normal Form (3NF)


3NF:
2NF and no transitive dependencies Not in 3NF

Student Erik Sven Inge Hildur

Course_ID CIS331 CIS331 CIS331 CIS362

Grade A B C A

Grade_value 4.00 3.00 2.00 4.00

Vladimir Vacic, Temple University

17

Third Normal Form (3NF)


Student Erik Sven Inge Hildur Course_ID CIS331 CIS331 CIS331 CIS362 Grade A B C A Grade Grade_value A B C 4.00 3.00 2.00

Normalized to 3NF

Vladimir Vacic, Temple University

18

Third Normal Form (3NF)

Student

Value

Course_ID

Grade

Vladimir Vacic, Temple University

19

BCNF: Reminder
Informally: Everything depends on the full key, and nothing but the key Formally: For every FD a b in F+
a b is trivial (a is a superset of b) or a is a superkey (or both)
Vladimir Vacic, Temple University
20

Normal forms: BCNF vs. 3NF


If a relation is in BCNF, it is always in 3NF (but not the converse) In practice, aim for
BCNF

If thats impossible, we accept


3NF; but we insist on lossless join and dependency preservation

Vladimir Vacic, Temple University

21

Normal forms: BCNF vs. 3NF


Lets consider the classic example: STC (Student, Teacher, Course)
Teacher Course Student, Course Teacher

Is it in BCNF?
Student Course
Vladimir Vacic, Temple University

Teacher

22

Normal forms: BCNF vs. 3NF


STC (Student, Teacher, Course)
Teacher Course Student, Course Teacher

1) (Teacher, Course) (Student, Course)

(BCNF? Y+Y - Lossless? No - Dep. pres.? No)

2) (Teacher, Course) (Student, Teacher)


(BCNF? Y+Y - Lossless? Yes - Dep. pres.? No)
Vladimir Vacic, Temple University
23

Normal forms: BCNF vs. 3NF


STC (Student, Teacher, Course)
Teacher Course Student, Course Teacher

in this case it is impossible to have both


BCNF and dependency preservation

So we have to use the (weaker) 3NF.

Vladimir Vacic, Temple University

24

Normal forms: BCNF vs. 3NF


STC (Student, Teacher, Course)
Teacher Course Student, Course Teacher

S T C

Informally, 3NF forgives the red arrow

Vladimir Vacic, Temple University

25

Normalization: Examples
Supplier S1 S1 S1 S2 S7 Name Jones Jones Jones Spiritoso Kohl Status_City 10 10 10 12 10 City Paris Paris Paris London Paris Part P3 P1 P4 P3 P4 Qty 257 500 125 (null) 342

Start by determining functional dependencies!

Vladimir Vacic, Temple University

26

Normalization: Example
FDs Supplier Name Supplier City Status_City Supplier Status_City (Supplier, Part) Qty Partial Dependencies (Supplier, Part) Name (Supplier, Part) City (Supplier, Part) Status_City
Vladimir Vacic, Temple University
27

Normalization: Example
Supplier S1 S2 S7 Supplier S1 S1 S1 S2 S7 Name Jones Spiritoso Kohl Part P1 P3 P4 P3 P4 Status_City 10 12 10 Qty 500 257 125 (null) 342
28

City Paris London Paris

Vladimir Vacic, Temple University

Normalization: Example
We took care of the partial dependencies, but what about transitive dependencies?

Supplier S1 S2 S7

Name Jones Spiritoso Kohl

Status_City 10 12 10

City Paris London Paris

Vladimir Vacic, Temple University

29

Normalization: Example
Supplier S1 S1 S1 S2 S7 Part P1 P3 P4 P3 P4 Qty 500 257 125 (null) 342 Supplier S1 S2 S7 City Paris London Name Jones Spirit Kohl City Paris London Paris

Status_City 10 12
30

Vladimir Vacic, Temple University

Normalization: Examples
Silberschatz et al.:
7.2 (lossless-join decomposition) hint: use the theorem! A decomposition is a lossless-join decomposition if the joining attribute is a superkey in at least one of the new relations 7.16 (lossless-join decomposition) 7.18 (dependency-preserving decomposition)

Vladimir Vacic, Temple University

31

Normalization: Final Thoughts


There are higher normal forms (4NF, 5NF), but we will not talk about them In practice, normalized means in BCNF or 3NF Luckily, in practice, ER diagrams lead to normalized tables (but do not rely on luck)

Vladimir Vacic, Temple University

32

Normalization: Overview
Why do we normalize?
To avoid redundancy (less storage space needed, and data is consistent) To avoid update/delete anomalies

A good decomposition should:


be a lossless join decomposition (you can recover original tables with a join) preserve dependencies (FDs should not span two tables)
Vladimir Vacic, Temple University
33

Normalization: Overview
Boyce-Codd Normal Form (BCNF):
Everything should depend on the key, the whole key, and nothing but the key (so help me Codd joke attributed to C.J. Date )

1NF (all attributes are atomic) 2NF (no partial dependencies) 3NF (no transitive dependencies)

Vladimir Vacic, Temple University

34

You might also like