Databases 2009

Normalization

Michael I. Schwartzbach
Computer Science, University of Aarhus
 Database Anomalies

Redundancy anomaly
• information is repeated unnecessarily

Update anomaly
• updating a row causes inconsistent information

Deletion anomaly
• deleting a row causes too much information to
disappear

Normalization 2
 Redundancy Anomaly

MeetingsOwners
meetid what date slot userid name group office

34716 dDB 2008-08-25 14 mis Michael I. Schwartzbach vip Turing-222

34727 dDB 2008-08-25 15 mis Michael I. Schwartzbach vip Turing-222

42835 TA-meeting 2008-12-24 18 amoeller Anders Møller vip Turing-224

Information about owners is duplicated

Normalization 3
 Update Anomaly

MeetingsOwners
meetid what date slot userid name group office

34716 dDB 2008-08-25 14 mis Michael I. Schwartzbach vip Turing-222

34727 dDB 2008-08-25 15 mis Michael I. Schwartzbach vip Turing-220

42835 TA-meeting 2008-12-24 18 amoeller Anders Møller vip Turing-224

Michael now has conflicting office information

Normalization 4
 Deletion Anomaly

MeetingsOwners
meetid what date slot userid name group office

34716 dDB 2008-08-25 14 mis Michael I. Schwartzbach vip Turing-222

34727 dDB 2008-08-25 15 mis Michael I. Schwartzbach vip Turing-222

42835 TA-meeting 2008-12-24 18 amoeller Anders Møller vip Turing-224

When Anders’ meeting is deleted, we no longer

know anything about him

Normalization 5
 Decomposition

Anomalies may be avoided by decomposition:

Meetings
meetid what date slot userid

34716 dDB 2008-08-25 14 mis

34727 dDB 2008-08-25 15 mis

42835 TA-meeting 2008-12-24 18 amoeller

Owner
userid name group office

Lossless: mis Michael I. Schwartzbach vip Turing-222

R = R1
 R2 mis Michael I. Schwartzbach vip Turing-222

amoeller Anders Møller vip Turing-224

Normalization 6
 Keys

A key in a table is a set of attributes a1,...,an

For any other attribute b and for any row:

the values of a1,...,an determine the value of b

Example: the attribute userid is a key for Owner

A key is always minimal:

a1,...,ai-1,ai+1,...,an is not a key for any i

Normalization 7
 Superkeys

A superkey is a superset of a key:

a set of attributes of which a subset is a key

Example: meetid,what is a superkey for Meetings

Example: userid,name is a superkey for Owners

Normalization 8
 Lossless Decomposition

Let R have schema a1,...,an,b1,...,bk,c1,...,cm

Define R1 = π a ,...,a ,b ,...,b (R)

1 n 1 k

Define R2 = π a ,...,a ,c ,...,c (R)

1 n 1 m

If a1,...,an is a superkey for R1 or for R2

then this is a lossless decomposition

Meetings and Owners form a lossless

decomposition since userid is a (superkey) for
Owners
Normalization 9
 Functional Dependencies

A functional dependency in a table is of the form:

a1,...,an → b
for some attributes ai and b

It implies that the values of a1,...,an determine the

value of b in any row

Normalization 10
 Dependencies Cause Anomalies

MeetingsOwners
meetid what date slot userid name group office

34716 dDB 2008-08-25 14 mis Michael I. Schwartzbach vip Turing-222

34727 dDB 2008-08-25 15 mis Michael I. Schwartzbach vip Turing-222

42835 TA-meeting 2008-12-24 18 amoeller Anders Møller vip Turing-224

userid → name

userid → group

userid → office

Normalization 11
 Recognizing Dependencies

A functional dependency must be known about

the data domain

It cannot be inferred from the data in a table

userid name group office

amoeller Anders Møller vip Turing-224
bnielsen Birger Nielsen tap Hopper-017
jn Jesper Nielsen phd 090-113

userid name group office

group →office? amoeller

bnielsen
Anders Møller
Birger Nielsen
vip
tap
Turing-224
Hopper-017

name →userid? jespern Jesper Nielsen tap Hopper-135

jn Jesper Nielsen phd 090-113

Normalization 12
 Obvious Dependencies

Some functional dependencies will always hold

a1,...,an → ai
for any set of attributes a1,...,an

a1,...,an → b
for any b when a1,...,an is a superkey

Normalization 13
 BCNF

We would like all tables to have only obvious

functional dependencies

This is called Boyce-Codd Normal Form (BCNF)

We can always obtain BCNF by systematic

lossless decomposition

Normalization 14
 Nonreducible Functional Dependencies

A functional dependency:
a1,...,an → b
is nonreducible if
a1,...,ai-1,ai+1,...an → b
is not a functional dependency for any i

If a table has a functional dependency then it also

has a nonreducible functional dependency

Normalization 15
 BCNF Normalization (1/3)

Find a table R with a nonobvious nonreducible

functional dependency:
a1,...,an → b1
(otherwise it is already in BCNF)

Collect all others with the same left-hand side:

a1,...,an → b2
...
a1,...,an → bk

Normalization 16
 BCNF Normalization (2/3)

Assume that the schema of R is

a1,...,an,b1,...,bk,c1,...,cm

Decompose R into:
R1 = πa ,...,a ,b ,...,b (R)
1 n 1 k

R2 = πa ,...,a ,c ,...,c (R)

1 n 1 m

This is lossless since a1,...,an is a key for R1

Normalization 17
 BCNF Normalization (3/3)

We have now removed all nonobvious

dependencies with left-hand side a1,...,an, since
R1 and R2 have none of those

Now, repeat this process all over again

Termination is guaranteed, since there are only

finitely many different left-hand sides

Normalization 18
 Inferring Dependencies

The BCNF algorithm assumes that we know all

functional dependencies

Given an initial set of dependencies, which other

ones follow logically?

For example, if we know that:

A,B →C and A,D → B
it follows logically that also:
A,D → C

Normalization 19
 Complete Inference Rules

For any A1,...,An then

A1,...,An → Ai

If A1,...,An → B then
A1,...,An,C → B

If A1,...,An → Bi for any B1,...,Bm and

B1,...,Bn → C then
A1,...,An → C

A closure algorithm can compute all of these

Normalization 20
 BCNF Example (1/3)

Exams
studentid date time vip room
20080001 2008-10-15 09:00 mis Turing-230
20080002 2008-10-15 09:30 mis Turing-230
20080001 2008-10-16 12:30 amoeller Turing-230
20080003 2008-10-16 10:30 eernst Ada-017
20080001 2008-10-17 11:00 eernst Ada-017

Keys: (studentid, date)

(vip, date, time)
(room, date, time)
Normalization 21
 BCNF Example (2/3)

Nonreducible functional dependencies:

studentid, date → time
studentid, date → vip
studentid, date → room
vip, date, time → studentid
room, date, time → studentid
room, date, time → vip
vip, date → room

Normalization 22
 BCNF Example (2/3)

Nonreducible functional dependencies:

studentid, date → time
studentid, date → vip
studentid, date → room
vip, date, time → studentid
room, date, time → studentid
room, date, time → vip
vip, date → room

Normalization 23
 BCNF Example (3/3)

Exams
studentid date time vip
20080001 2008-10-15 09:00 mis
20080002 2008-10-15 09:30 mis
20080001 2008-10-16 12:30 amoeller
20080003 2008-10-16 10:30 eernst
20080001 2008-10-16 11:00 eernst
Rooms
date vip room
2008-10-15 mis Turing-230

2008-10-16 amoeller Turing-230

2008-10-16 eernst Ada-017

Normalization 24
 Other Normal Forms

1NF 2NF 3NF BCNF 4NF 5NF

Higher normal form

⇒ less redundancy
⇒ less memory used
Normalization 25
 Denormalization

Redundancy may be good sometimes

• speeds up data access
• requires fewer join operations
• reduces wait time during locking

Denormalization is the careful introduction of

redundancy in a database design

Speeds up SELECT

Slows down INSERT, UPDATE, DELETE

Normalization 26