39
Goal… l Given a database schema, how do you judge whether or not
the design is good?
l How do you ensure it does not have redundancy or anomaly problems?
l To ensure your database schema is in a good form we use: l Functional Dependencies l Normalization Rules
2
What is Normalization l Normalization is a set of rules to systematically
achieve a good design
l If these rules are followed, then the DB design is guarantee to avoid several problems: l Inconsistent data l Anomalies: insert, delete and update l Redundancy: which wastes storage, and often slows down
query processing
3
Problem I: Insert Anomaly
sNumber sName pNumber pName s1 Dave p1 MM s2 Greg p2 ER
Student
Question: Could we insert a professor without student? Note: We cannot insert a professor who has no students.
Insert Anomaly: We are not able to insert “valid” value/(s)
Student Info Professor Info
4
Problem II: Delete Anomaly
Question: Can we delete a student and keep a professor info ? Note: We cannot delete a student that is the only student of a professor.
Delete Anomaly: We are not able to perform a delete without losing some “valid” information.
sNumber sName pNumber pName s1 Dave p1 MM s2 Greg p2 ER
Student
Student Info Professor Info
5
Problem III: Update Anomaly
Question: Can we simply update a professor’s name ? Note: To update the name of a professor, we have to update in multiple tuples.
Update Anomaly: To update a value, we have to update multiple rows. Update anomalies are due to redundancy.
sNumber sName pNumber pName s1 Dave p1 MM s2 Greg p1 MM
Student
Student Info Professor Info
VV VV
6
Problem IV: Inconsistency
What if the name of professor p1 is updated in one place and not the other!!!
Inconsistent Data: The same object has multiple values. Inconsistency is due to redundancy.
sNumber sName pNumber pName s1 Dave p1 MM s2 Greg p1 MM
Student
Student Info Professor Info
VV
7
Schema Normalization
l Following the normalization rules, we avoid l Insert anomaly l Delete anomaly l Update anomaly l Inconsistency
8
What to Cover
l Functional Dependencies (FDs)
l Closure of Functional Dependencies
l Lossy & Lossless Decomposition
l Normalization 9
Usage of Functional Dependencies
l Discover all dependencies between attributes
l Identify the keys of relations
l Enable good (Lossless) decomposition of a given relation
10
Functional Dependencies (FDs)
sNumber sName address
1 Dave 144FL
2 Greg 320FL
Student
Suppose we have the FD: sNumber → address That is, there is a functional dependency from sNumber to address
11
Meaning: A student number determines the student address
Or: For any two rows in the Student relation with the same value for sNumber, the value for address must be same.
Functional Dependencies (FDs)
l Require that the value for a certain set of attributes determines uniquely the value for another set of attributes
l A functional dependency is a generalization of the notion of a key
l FD: A1,A2,…An → B1, B2,…Bm
12
L.H.S R.H.S
Functional Dependencies (FDs)
l The basic form of a FDs A1,A2,…An → B1, B2,…Bm
13
L.H.S R.H.S
>> The values in the L.H.S uniquely determine the values in the R.H.S attributes (when you lookup the DB) >> It does not mean that L.H.S values compute the R.H.S values
Examples: SSN à personName, personDoB, personAddress DepartmentID, CourseNum à CourseTitle, NumCredits personName personAddress X
FD and Keys
sNumber sName address
1 Dave 144FL
2 Greg 320FL
Student
Questions : • Does a primary key implies functional dependencies? Which ones ? • Does unique keys imply functional dependencies? Which ones ? • Does a functional dependency imply keys ? Which ones ?
Observation : Any key (primary or candidate) or superkey of a relation R functionally determines all attributes of R.
Primary Key : <sNumber>
14
Functional Dependencies (FDs) l Let R be a relation schema where
l α⊆R and β⊆R -- α and β are subsets of R’s attributes
l The functional dependency α→β holds on R if and only if: l For any legal instance of R, whenever any two tuples t1 and t2 agree
on the attributes α, they also agree on the attributes β. That is, l t1[α]=t2[α] ⇒ t1[β] =t2[β]
15
©Silberschatz, Korth and Sudarshan7.12Database System Concepts - 5th Edition, July 28, 2005.
Functional Dependencies (Cont.)Functional Dependencies (Cont.)
� Let R be a relation schema� � R and � � R
� The functional dependency� � �
holds on R if and only if for any legal relations r(R), whenever any two tuples t1 and t2 of r agree on the attributes �, they also agree on the attributes �. That is,
t1[�] = t2 [�] � t1[� ] = t2 [� ] � Example: Consider r(A,B ) with the following instance of r.
� On this instance, A � B does NOT hold, but B � A does hold.
1 41 53 7
A B
A à B (Does not hold) B à A (holds)
Functional Dependencies & Keys
l K is a superkey for relation schema R if and only if l K → R -- K determines all attributes of R
l K is a candidate key for R if and only if l K→R, and l No α⊂K, α→R
16
Keys imply FDs, and FDs imply keys
Example I
Student(SSN, Fname, Mname, Lname, DoB, address, age, admissionDate)
l If you know that SSN is a key, Then l SSN à Fname, Mname, Lname, DoB, address, age, admissionDate
l If you know that (Fname, Mname, Lname) is a key, Then l Fname, Mname, Lname à SSN, DoB, address, age, admissionDate
17
Need to know all of L.H.S to determine any of the R.H.S
Example II
Student(SSN, Fname, Mname, Lname, DoB, address, age, admissionDate)
l If you know that SSN à Fname, Mname, Lname, DoB, address, age, admissionDate l Then, we infer that SSN is a candidate key
l If you know that Fname, Mname, Lname à SSN, DoB, address, age, admissionDate l Then, we infer that (Fname, Mname, Lname) is a key. Is it Candidate or super key??? l Does any pair of attributes together form a key??
l If no à (Fname, Mname, Lname) is a candidate key (minimal) l If yes à (Fname, Mname, Lname) is a super key
18
Example III
l Does this FD hold? l Title, year à length, genre, studioName
l Does this FD hold? l Title, year à starName
l What is a key of this relation instance? l {title, year, starName} l Is it candidate key?
19
YES
NO
>> For this instance à not a candidate key (title, starName) can be a key
Properties of FDs
l Consider A, B, C, Z are sets of attributes l Reflexive (trivial):
l A → B is trivial if B ⊆ A
20
©Silberschatz, Korth and Sudarshan7.15Database System Concepts - 5th Edition, July 28, 2005.
Functional Dependencies (Cont.)Functional Dependencies (Cont.)
� A functional dependency is trivial if it is satisfied by all instances of a relation
� Example:
� customer_name, loan_number � customer_name
� customer_name � customer_name
� In general, � � � is trivial if � � �
Properties of FDs (Cont’d) l Consider A, B, C, Z are sets of attributes l Transitive:
l if A → B, and B → C, then A → C
l Augmentation: l if A → B, then AZ → BZ
l Union: l if A → B, A → C, then A → BC
l Decomposition: l if A → BC, then A → B, A → C
21
Use these properties to derive more FDs
Example l Given R( A, B, C, D, E)
l F = {A à BC, DE à C, B à D}
l Is A a key for R or not? Does A determine all other attributes? l A à A B C D
l Is BE a key for R? l BE à B E D C
l Is ABE a candidate or super key for R? l ABE à A B E D C l AE à A E B C D
22
NO
NO
>> ABE is a super key >> AE is a candidate key
Use the FD properties to derive more FDs
What to Cover
l Functional Dependencies (FDs)
l Closure of Functional Dependencies
l Lossy & Lossless Decomposition
l Normalization 23
Closure of a Set of Functional Dependencies l Given a set F set of functional dependencies, there
are other FDs that can be inferred based on F l For example: If A → B and B → C, then we can infer that
A → C
l Closure set F è F+
l The set of all FDs that can be inferred from F l We denote the closure of F by F+ l F+ is a superset of F
l Computing the closure F+ of a set of FDs can be expensive
24
Inferring FDs l Suppose we have:
l a relation R (A, B, C, D) and l functional dependencies A → B, C → D, A à C
l Question: l What is a key for R?
l We can infer A → ABC, and since C → D, then l A → ABCD
l Hence A is a key in R 25
Is it is the only candidate key ???
Attribute Closure
l Attribute Closure of A l Given a set of FDs, compute all attributes X that A
determines l A à X
l Attribute closure is easy to compute l Just recursively apply the transitive property
l A can be a single attribute or set of attributes
26
Algorithm for Computing Attribute Closures l Computing the closure of set of attributes {A1, A2, …, An}:
1. Let X = {A1, A2, …, An} 2. If there exists a FD: B1, B2, …, Bm → C, such that
every Bi ∈ X, then X = X ∪ C 3. Repeat step 2 until no more attributes can be added.
l X is the closure of the {A1, A2, …, An} attributes l X = {A1, A2, …, An} +
27
Example 1: Inferring FDs l Assume relation R (A, B, C) l Given FDs : A → B, B → C, C → A
l What are the possible keys for R ? l Compute the closure of each attribute X, i.e., X+
l X+ contains all attributes, then X is a key
l For example: l {A}+ = {A, B, C} l {B}+
= {A, B, C} l {C}+
= {A, B, C}
l So keys for R are <A>, <B>, <C>
28
Example 2: Attribute Closure
l Given R( A, B, C, D, E) l F = {A à BC, DE à C, B à D}
l What is the attribute closure {AB}+ ? l {AB}+ = {A B} l {AB}+ = {A B C} l {AB}+ = {A B C D}
l What is the attribute closure {BE}+ ? l {BE}+ = {B E} l {BE}+ = {B E D} l {BE}+ = {B E D C}
29
Set of attributes α is a key if α+ contains all
attributes
Example 3: Inferring FDs
l Assume relation R (A, B, C, D, E)
l Given F = {A à B, B à C, C D à E } l Does A à E?
l The above question is the same as l Is E in the attribute closure of A (A+)? l Is A à E in the function closure F+ ?
30
A à E does not hold
A D à ABCDE does hold A D is a key for R
Summary of FDs l They capture the dependencies between attributes
l How to infer more FDs using properties such as transitivity, augmentation, and union
l Functional closure F+
l Attribute closure A+
l Relationship between FDs and keys
31
What to Cover
l Functional Dependencies (FDs)
l Closure of Functional Dependencies
l Lossy & Lossless Decomposition
l Normalization 32
Decomposing Relations
Greg Dave
sName
p2 p1
pNumber
MM s2 MM s1
pName sNumber StudentProf
FDs: pNumber → pName
Greg Dave
sName
p2 p1
pNumber
s2 s1
sNumber
Student
p2 p1
pNumber
MM MM
pName
Professor
Greg Dave
sName
MM MM
pName
S2 S1
sNumber
Student
p2 p1
pNumber
MM MM
pName
Professor
33
Lossless
Lossy
Lossless vs. Lossy Decomposition
l Assume R is divided into R1 and R2
l Lossless Decomposition l R1 natural join R2 should create exactly R
l Lossy Decomposition l R1 natural join R2 adds more records (or deletes
records) from R
34
Lossless Decomposition
35
Greg Dave
sName
p2 p1
pNumber
MM s2 MM s1
pName sNumber StudentProf
FDs: pNumber → pName
Greg Dave
sName
p2 p1
pNumber
s2 s1
sNumber
Student
p2 p1
pNumber
MM MM
pName
Professor Lossless
Student & Professor are lossless decomposition of StudentProf (Student ⋈ Professor = StudentProf)
Lossy Decomposition
36
Greg Dave
sName
p2 p1
pNumber
MM s2 MM s1
pName sNumber StudentProf
FDs: pNumber → pName
Greg Dave
sName
MM MM
pName
S2 S1
sNumber
Student
p2 p1
pNumber
MM MM
pName
Professor Lossy
Student & Professor are lossy decomposition of StudentProf (Student ⋈ Professor != StudentProf)
Goal: Ensure Lossless Decomposition
l How to ensure lossless decomposition?
l Answer: l The common columns must be candidate key in
one of the two relations
37
Back to our example
Greg Dave
sName
p2 p1
pNumber
MM s2 MM s1
pName sNumber StudentProf
FDs: pNumber → pName
Greg Dave
sName
p2 p1
pNumber
s2 s1
sNumber
Student
p2 p1
pNumber
MM MM
pName
Professor
Greg Dave
sName
MM MM
pName
S2 S1
sNumber
Student
p2 p1
pNumber
MM MM
pName
Professor
38
Lossless
Lossy
pNumber is candidate key
pName is not candidate key
What to Cover
l Functional Dependencies (FDs)
l Closure of Functional Dependencies
l Lossy & Lossless Decomposition
l Normalization 39
