Mata Kuliah Sistem Basis Data TA 2016/2017

Database Design
Normal forms & functional
dependencies

Sumber: http://web.stanford.edu/class/cs145/
University of Stanford
Database Design (1)

Overview of design theory & normal forms

Data anomalies & constraints

Functional dependencies

Mata Kuliah Sistem Basis Data TA 2016/2017

2
 Overview
design theory &
normal forms

Mata Kuliah Sistem Basis Data TA 2016/2017

Design Theory

Design theory is about how to represent your data to avoid

anomalies.
Teori desain digunakan untuk merepresentasikan data yang tidak menimbulkan anomali.

It is a mostly mechanical process

Tools can carry out routine portions

Mata Kuliah Sistem Basis Data TA 2016/2017

4
Normal Forms
1st Normal Form (1NF) = All tables are flat

2nd Normal Form = disused

Boyce-Codd Normal Form (BCNF) DB designs based on

functional
dependencies,
3rd Normal Form (3NF) intended to prevent
data anomalies

4th and 5th Normal Forms

Mata Kuliah Sistem Basis Data TA 2016/2017

5
1st Normal Form (1NF)

Student Courses
Student Courses
Mary CS145
Mary {CS145,CS229}
Mary CS229
Joe {CS145,CS106}
Joe CS145

Joe CS106

Violates 1NF. In 1st NF

1NF Constraint: harus bersifat atomic!

Mata Kuliah Sistem Basis Data TA 2016/2017

6
 Data anomalies
& constraints

Mata Kuliah Sistem Basis Data TA 2016/2017

Constraints Prevent (some)
Anomalies in the Data
A poorly designed database causes anomalies:

Student Course Room

Mary CS145 B01
If every course is in
Joe CS145 B01 only one room,
Sam CS145 B01 contains redundant
information!
.. .. ..

Mata Kuliah Sistem Basis Data TA 2016/2017

8
Constraints Prevent (some)
Anomalies in the Data
A poorly designed database causes anomalies:

Student Course Room

.. .. ..

If everyone drops the class, we lose what

room the class is in! = a delete anomaly

9
 Constraints Prevent (some)
Anomalies in the Data
A poorly designed database causes anomalies:

Student Course Room

Mary CS145 B01 Similarly, we cant
reserve a room
Joe CS145 B01 without students
Sam CS145 B01 = an insert
anomaly
CS229 C12 .. .. ..

Mata Kuliah Sistem Basis Data TA 2016/2017

10
Constraints Prevent (some)
Anomalies in the Data

Student Course Is this form better?

Mary CS145 Course Room

Redundancy?
Joe CS145 CS145 B01 Update anomaly?
Sam CS145 CS229 C12 Delete anomaly?
Insert anomaly?
.. ..
Today: develop theory to understand why this design may be better and how to find
this decomposition

Mata Kuliah Sistem Basis Data TA 2016/2017

11
 Functional
Dependencies

Mata Kuliah Sistem Basis Data TA 2016/2017

Functional Dependencies (FDs)
A functional dependency X Y holds over relation schema R if, for every
allowable instance r of R:
t1 r, t2 r, pX (t1) = pX (t2)
implies pY (t1) = pY (t2)
(where t1 and t2 are tuples;X and Y are sets of attributes)

Explanation: CAUTION: The opposite is not true.

X Y means:
If for 2 tuples X is the same, then Y must also be the same.
Read as determines
Functional Dependencies (FDs)
An FD is a statement about all allowable relations.
Identified based on semantics, NOT instances
Given an instance of R, we can disprove a FD, but we cannot verify
the validity of a FD.

Question: Are FDs related to keys?

if K all attributes of R then K is a superkey for R
(does not require K to be minimal.)
FDs are a generalization of keys.
Functional Dependencies (FDs): Example
Consider relation obtained from Hourly_Emps:
Hourly_Emps (ssn, name, lot, rating, wage_per_hr, hrs_per_wk)

We sometimes denote a relation schema by listing the attributes: e.g., SNLRWH

This is really the set of attributes {S,N,L,R,W,H}.

What are some FDs on Hourly_Emps? ssn is the key: S SNLRWH

rating determines wage_per_hr: R W
lot determines lot: L L (trivial
dependency)
Functional Dependencies (FDs): Example
Problems Due to R W
S N L R W H
123-22-3666 Attishoo 48 8 10 40
Hourly_Emps

231-31-5368 Smiley 22 8 10 30 R=6, W=?

131-24-3650 Smethurst 35 5 7 30
434-26-3751 Guldu 35 5 7 32
612-67-4134 Madayan 35 8 10 40

Update anomaly: Should we be allowed to modify W in only the 1st tuple of

SNLRWH?
Insertion anomaly: What if we want to insert an employee and dont know the hourly
wage for his or her rating? (or we get it wrong?)
Deletion anomaly: If we delete all employees with rating 5, we lose the information
about the wage for rating 5!
Functional Dependencies (FDs): Example

Detecting Reduncancy
S N L R W H
123-22-3666 Attishoo 48 8 10 40
Hourly_Emps

231-31-5368 Smiley 22 8 10 30
131-24-3650 Smethurst 35 5 7 30
434-26-3751 Guldu 35 5 7 32
612-67-4134 Madayan 35 8 10 40

Q: Why was R W problematic, but S W not?

Functional Dependencies (FDs): Example
Redundancy can be removed by chopping the
Decomposing a Relation
relation into pieces (vertically!)
FDs are used to drive this process.
R W is causing the problems, so decompose SNLRWH
into what relations?
S N L R H
123-22-3666 Attishoo 48 8 40
R W
231-31-5368 Smiley 22 8 30
8 10
131-24-3650 Smethurst 35 5 30
5 7
434-26-3751 Guldu 35 5 32
612-67-4134 Madayan 35 8 40 Wages

Hourly_Emps2
Functional Dependencies (FDs):
Refining an ER Diagram
Before:
1st diagram becomes: since
Workers(S,N,L,D,Si) name dname
Departments(D,M,B) ssn lot did budget
Lots associated with workers.
Suppose all workers in a Employees Works_In Departments
dept are assigned the same lot:
DL
Redundancy; fixed by:
Workers2(S,N,D,Si) Dept_Lots(D,L)
After:
budget
Departments(D,M,B) since
name dname
Can fine-tune this:
ssn did
Workers2(S,N,D,Si) lot
Departments(D,M,B,L)
Employees Works_In Departments
Functional Dependencies (FDs): Reasoning About FDs
Given some FDs, we can usually infer additional FDs:
title studio, star implies title studio and title star
title studio and title star implies title studio, star
title studio, studio star implies title star

But,
title, star studio does NOT necessarily imply that title
studio or that star studio
An FD f is implied by a set of FDs F if f holds whenever all
FDs in F hold.
Finding Functional Dependencies
Equivalent to asking: Given a set of FDs, F = {f1,fn}, does an FD g hold?

Inference problem: How do we decide?

Answer: Three simple rules called Armstrongs

Rules.
1. Split/Combine,
2. Reduction, and
3. Transitivity ideas by picture
1. Split/Combine
A1 Am B1 Bn

A1, , Am B1,,Bn
1. Split/Combine
A1 Am B1 Bn

A1, , Am B1,,Bn

is equivalent to the following n FDs

A1,,Am Bi for i=1,,n

1. Split/Combine
A1 Am B1 Bn

And vice-versa, A1,,Am Bi for i=1,,n

is equivalent to

A1, , Am B1,,Bn
Reduction/Trivial
A1 Am

A1,,Am Aj for any j=1,,m

3. Transitive Closure
A1 Am B1 Bn C1 Ck

A1, , Am B1,,Bn and

B1,,Bn C1,,Ck
3. Transitive Closure
A1 Am B1 Bn C1 Ck

A1, , Am B1,,Bn and

B1,,Bn C1,,Ck
implies
A1,,Am C1,,Ck
Finding Functional Dependencies
Example:

Products Provided FDs:

Name Color Category Dep Price 1. {Name} {Color}
Gizmo Green Gadget Toys 49 2. {Category} {Department}
Widget Black Gadget Toys 59 3. {Color, Category} {Price}
Gizmo Green Whatsit Garden 99

Which / how many other FDs hold?

 Finding Functional Dependencies
Example:

Inferred FDs: Provided FDs:

Inferred FD Rule used 1. {Name} {Color}
4. {Name, Category} -> {Name} ? 2. {Category} {Dept.}
5. {Name, Category} -> {Color} ? 3. {Color, Category}
{Price}
6. {Name, Category} -> {Category} ?
7. {Name, Category -> {Color, Category} ?
8. {Name, Category} -> {Price} ?

Which / how many other FDs hold?

 Finding Functional Dependencies
Example:

Inferred FDs: Provided FDs:

Inferred FD Rule used 1. {Name} {Color}
4. {Name, Category} -> {Name} Trivial 2. {Category} {Dept.}
5. {Name, Category} -> {Color} Transitive (4 -> 1) 3. {Color, Category}
{Price}
6. {Name, Category} -> {Category} Trivial
7. {Name, Category -> {Color, Category} Split/combine (5 + 6)
8. {Name, Category} -> {Price} Transitive (7 -> 3)

Can we find an algorithmic way to do this?

 Closures

Mata Kuliah Sistem Basis Data TA 2016/2017

Closure of a set of Attributes
Given a set of attributes A1, , An and a set of FDs F:
Then the closure, {A1, , An}+ is the set of attributes B s.t. {A1, , An} B

Example: F = {name} {color}

{category} {department}
{color, category} {price}

Example {name}+ = {name, color}

Closures: {name, category}+ =
{name, category, color, dept, price}
{color}+ = {color}
32
Closure Algorithm

Start with X = {A1, , An} and set of FDs F.

Repeat until X doesnt change; do:
if {B1, , Bn} C is entailed by F
and {B1, , Bn} X
then add C to X.
Return X as X+
33
 Closure Algorithm
Start with X = {A1, , An}, FDs F. {name, category}+ =
Repeat until X doesnt change; do: {name, category}
if {B1, , Bn} C is in F and {B1,
, Bn} X:
then add C to X.
Return X as X+

F=
{name} {color}

{category} {dept}

{color, category} {price}

34
 Closure Algorithm
Start with X = {A1, , An}, FDs F. {name, category}+ =
Repeat until X doesnt change; do: {name, category}
if {B1, , Bn} C is in F and {B1,
, Bn} X: {name, category}+ =
then add C to X. {name, category, color}
Return X as X+

F=
{name} {color}

{category} {dept}

{color, category} {price}

35
 Closure Algorithm
Start with X = {A1, , An}, FDs F. {name, category}+ =
Repeat until X doesnt change; do: {name, category}
if {B1, , Bn} C is in F and {B1,
, Bn} X: {name, category}+ =
then add C to X. {name, category, color}
Return X as X+

F= {name, category}+ =
{name} {color} {name, category, color, dept}

{category} {dept}

{color, category} {price}

36
 Closure Algorithm
Start with X = {A1, , An}, FDs F. {name, category}+ =
Repeat until X doesnt change; do: {name, category}
if {B1, , Bn} C is in F and {B1,
, Bn} X: {name, category}+ =
then add C to X. {name, category, color}
Return X as X+

F= {name, category}+ =
{name} {color} {name, category, color, dept}

{category} {dept}
{name, category}+ =
{name, category, color, dept, price}
{color, category} {price}
37
Example
R(A,B,C,D,E,F) {A,B} {C}
{A,D} {E}
{B} {D}
{A,F} {B}

Compute {A,B}+ = {A, B, }

Compute {A, F}+ = {A, F, }

38
Example
R(A,B,C,D,E,F) {A,B} {C}
{A,D} {E}
{B} {D}
{A,F} {B}

Compute {A,B}+ = {A, B, C, D }

Compute {A, F}+ = {A, F, B }

39
Example
R(A,B,C,D,E,F) {A,B} {C}
{A,D} {E}
{B} {D}
{A,F} {B}

Compute {A,B}+ = {A, B, C, D, E}

Compute {A, F}+ = {A, B, C, D, E, F}

40