1. Functional Dependencies
Database
Functional Dependencies

2. Designing Good Schemas
We know how to create schemas, but ...
how do we create good schemas?
what does good mean?
Schema quality measurements:
semantics of the attributes
minimal redundancy
minimal frequency of null values

3. Functional Dependences
A column Y of relational table R is functionally dependent up on column X of relational table R if and only if:
Each value of X in R associated with each value of Y at any given time

4. Functional Dependencies
Definition: A1, ..., Am  B1, ..., Bn holds in R if:
t, t’  R, (t.A1=t’.A1  ...  t.Am=t’.Am  t.B1=t’.B1  ...  t.Bm=t’.Bm ) R A1
... Am B1 Bm t
if t, t’ agree here
then t, t’ agree here t’

5. Examples EmpID Name, Phone, Position Position Phone but Phone Position
Smith
1234
Clerk
E1847
John
9876
Salesrep
E1111
Smith
9876
Salesrep
E9999
Mary
1234
Lawyer

6. Example Data name addr beersLiked manf favBeer
Janeway Voyager Bud A.B. WickedAle
Janeway Voyager WickedAle Pete’s WickedAle
Spock Enterprise Bud A.B. Bud
Because name -> addr
Because beersLiked -> manf
Because name -> favBeer

7. Example Reasonable FD's to assert: 1. name  addr
Drinkers(name, addr, beersLiked, manf, favoriteBeer)
Reasonable FD's to assert:
1. name  addr
2. name  favoriteBeer
3. beersLiked  manf

8. Functional dependences
Y is functional dependent up on X same as values of X identify values of Y
If X  Y then XZYZ
IF XY and Y  Z then XZ
X Y means that Y depend on X or
X identify Y

9. Examples S#  Ename {S#, P#}  Hours
If for each value of S#, there are exactly one corresponding value for sname, state, city then: S#
Sname
Sate
City

10. Example
If {S#, p#}  Qty S# P#
QTY

11. Redundancy Example
Where’s the redundancy?

12. Redundancy Example

13. Example FDs
Proper FDs
Transitive FDs
Partial Key FD
Partial Key FDs

14. Example R = (A, B, C, G, H, I) F = { A  B A  C CG  H CG  I B  H}
some members of F+
A  H
by transitivity from A  B and B  H
AG  I
by augmenting A  C with G, to get AG  CG and then transitivity with CG  I
CG  HI
by augmenting CG  I to infer CG  CGI,
and augmenting of CG  H to infer CGI  HI,
and then transitivity

15. Formal definition of a key
A key is a set of attributes A1, ..., An s.t. for any other attribute B, A1, ..., An  B
A minimal key is a set of attributes which is a key and for which no subset is a key
Note: book calls them superkey and key

16. Where Do Keys Come From?
We could simply assert a key K. Then the only FD’s are K -> A for all atributes A, and K turns out to be the only key obtainable from the FD’s.
We could assert FD’s and deduce the keys by systematic exploration.
E/R gives us FD’s from entity-set keys and many-one relationships.

17. Examples of Keys Product(name, price, category, color)
name, category  price
category  color
Keys are: {name, category} and all supersets
Enrollment(student, address, course, room, time)
student  address
room, time  course
student, course  room, time
Keys are: [in class]
Keys: {student, room, time}, {student, course} and all supersets

18. Example 2 Keys are {Lastname, Firstname} and {StudentID}
Lastname Firstname Student ID Major
Key Key
(2 attributes)
Superkey
Note: There are alternate keys
Keys are {Lastname, Firstname} and {StudentID}

19. Finding the Keys of a Relation
Given a relation constructed from an E/R diagram, what is its key?
Rules:
1. If the relation comes from an entity set,
the key of the relation is the set of attributes which is the
key of the entity set.
address
name
ssn
Person
Person(address, name, ssn)

20. Finding the Keys buys(name, ssn, date) Rules:
2. If the relation comes from a many-many relationship,
the key of the relation is the set of all attribute keys in the
relations corresponding to the entity sets
name
buys
Person
Product
price
name
ssn
date
buys(name, ssn, date)

21. Finding the Keys Purchase(name , sname, ssn, card-no)
Except: if there is an arrow from the relationship to E, then
we don’t need the key of E as part of the relation key.
Purchase
Product
Person
Store
CreditCard
sname
name
card-no
ssn
Purchase(name , sname, ssn, card-no)

22. Expressing Dependencies
Say: “the CreditCard determines the Person”
Product
sname
Purchase
name
Store
Incomplete (what does it say ?)
card-no
CreditCard
Person
ssn
Purchase(name , sname, ssn, card-no)
card-no  name

23. Enrollment(student, major, course, room, time)
course  time
What else can we infer ?

24. Relational Schema Design (or Logical Design)
Main idea:
Start with some relational schema
Find out its FD’s
Important also to look at inferred FD’s.
Use them to design a better relational schema

25. Relational Schema Design
Recall set attributes (persons with several phones):
Name
SSN
PhoneNumber
City
Fred
Seattle
Joe
Westfield
SSN  Name, City, but not SSN  PhoneNumber
Anomalies:
Redundancy = repeat data
Update anomalies = Fred moves to “Bellvue”
Deletion anomalies = Fred drops all phone numbers: what is his city ?

26. Relation Decomposition
Break the relation into two:
Name
SSN
City
Fred
Seattle
Joe
Westfield
SSN
PhoneNumber

27. Relational Schema Design
Person
buys
Product
name
price
ssn
Conceptual Model:
Relational Model:
plus FD’s
Normalization:
Eliminates anomalies

28. Decompositions in General
R(A1, ..., An)
Create two relations R1(B1, ..., Bm) and R2(C1, ..., Cp)
such that: B1, ..., Bm  C1, ..., Cp = A1, ..., An
and:
R1 = projection of R on B1, ..., Bm
R2 = projection of R on C1, ..., Cp

29. Incorrect Decomposition
Sometimes it is incorrect:
Name
Price
Category
Gizmo
19.99
Gadget
OneClick
24.99
Camera
DoubleClick
29.99
Decompose on : Name, Category and Price, Category

30. Incorrect Decomposition
Name
Category
Gizmo
Gadget
OneClick
Camera
DoubleClick
Price
Category
19.99
Gadget
24.99
Camera
29.99
Name
Price
Category
Gizmo
19.99
Gadget
OneClick
24.99
Camera
29.99
DoubleClick
When we put it back:
Cannot recover information

31. Normal Forms
Each normal form is a set of conditions on a schema that guarantees certain properties (relating to redundancy and update anomalies)
The two commonly used normal forms are third normal form (3NF) and Boyce-Codd normal form (BCNF)

32. Normalization 0NF 1NF 2NF 3NF BCNF 4NF 5NF remove multi-valued
attributes
1NF
2NF
3NF
partial
dependencies
transitive
BCNF
4NF
5NF
remove
remaining
FD anomal
dependencies
multivalue
anomalies

33. Goals of Normalization
Let R be a relation scheme with a set F of functional dependencies.
Decide whether a relation scheme R is in “good” form.
In the case that a relation scheme R is not in “good” form, decompose it into a set of relation scheme {R1, R2, ..., Rn} such that
each relation scheme is in good form
the decomposition is a lossless-join decomposition
Preferably, the decomposition should be dependency preserving.

34. 1 NF First normal form is NO multi-valued attributes
No composite attribute
No nested relation
We create new table or new field (telephone, visiting)

35. 1NF Normalization
Proper translation from ER multi-value attributes will achieve 1NF.
Still not a good solution, since we have redundancy in Dnumber and Dmgr_ssn. (This will be handled by 2NF.)

36. 2 NF form
Second normal form that if primary key is multiple attribute and non-key attribute depend on part of primary key S# P#
Hours
Cname
pname
Loc

37. 2NF Normalization
Move the partial key and dependent attributes to a new relation.

38. Transitive Dependencies
X → Y is a transitive dependency (PD) if there exists Z ⊈ any key such that X → Z → Y
TDs can cause redundancy if there are multiple values of X that determine the same value of Z
the value of Y for that value of Z is stored multiple times
3NF normalization: move (Z,Y) to new relation in which Z is the primary key

39. 3 NF
The relation in 3NF if it is 2 NF and every non-key attribute is non-transitively dependent on primary key

40. 3NF Normalization
Create new relation to hold the attributes in the transitive FD.
LHS of transitive FD becomes PK of new relation.

41. Transitive Dependency Example
DEPT
COURSE
SECTION
ROOM
INSTR
I_OFFICE
I_OFFICE (instructor's office) is determined
by the non-PK attribute INSTR
DEPT
COURSE
SECTION
COMP 51 1 2
163 53
ROOM
WPC122
WPC219
WPC130
INSTR
DOHERTY
CLIBURN
BOWRING
CARMAN
I_OFFICE
CSB109
CSB107
CSB108
CSB104

42. NF Decomposition: Foreign Keys
DEPT
COURSE
SECTION
ROOM
INSTR
I_OFFICE
DEPT
COURSE
SECTION
ROOM
INSTR
Decomposition:
INSTR
I_OFFICE

43. 3NF Example Relation dept_advisor:
dept_advisor (s_ID, i_ID, dept_name) F = {s_ID, dept_name  i_ID, i_ID  dept_name}
Two candidate keys: s_ID, dept_name, and i_ID, s_ID
R is in 3NF
s_ID, dept_name  i_ID s_ID
dept_name is a superkey
i_ID  dept_name
dept_name is contained in a candidate key

44. Redundancy in 3NF There is some redundancy in this schema
Example of problems due to redundancy in 3NF
R = (J, K, L) F = {JK  L, L  K } J L K j1 j2 j3
null l1 l2 k1 k2
repetition of information (e.g., the relationship l1, k1)
(i_ID, dept_name)
need to use null values (e.g., to represent the relationship l2, k2 where there is no corresponding value for J).
(i_ID, dept_nameI) if there is no separate relation mapping instructors to departments

45. 3NF Decomposition: An Example
Relation schema:
cust_banker_branch = (customer_id, employee_id, branch_name, type )
The functional dependencies for this relation schema are:
customer_id, employee_id  branch_name, type
employee_id  branch_name
customer_id, branch_name  employee_id
We first compute a canonical cover
branch_name is extraneous in the r.h.s. of the 1st dependency
No other attribute is extraneous, so we get FC =
customer_id, employee_id  type employee_id  branch_name customer_id, branch_name  employee_id

46. Why? Normalization Goal = BCNF = Boyce-Codd Normal Form =
all FD’s follow from the fact “key  everything.”
Formally, R is in BCNF if for every nontrivial FD for R, say X  A, then X is a superkey.
“Nontrivial” = right-side attribute not in left side.
Why?
1. Guarantees no redundancy due to FD’s.
2. Guarantees no update anomalies = one occurrence of a fact is updated, not all.
3. Guarantees no deletion anomalies = valid fact is lost when tuple is deleted.

47. Boyce-Codd Normal Form
A relation schema R is in BCNF with respect to a set F of functional dependencies if for all functional dependencies in F+ of the form
 
where   R and   R, at least one of the following holds:
   is trivial (i.e.,   )
 is a superkey for R
Example schema not in BCNF:
instr_dept (ID, name, salary, dept_name, building, budget )
because dept_name building, budget
holds on instr_dept, but dept_name is not a superkey

48. Third Normal Form
A relation schema R is in third normal form (3NF) if for all:
   in F+ at least one of the following holds:
   is trivial (i.e.,   )
 is a superkey for R
Each attribute A in  –  is contained in a candidate key for R.
(NOTE: each attribute may be in a different candidate key)
If a relation is in BCNF it is in 3NF (since in BCNF one of the first two conditions above must hold).
Third condition is a minimal relaxation of BCNF to ensure dependency preservation (will see why later).

49. Boyce-Codd Normal Form
Sample data for Course Section table
Because Prefix  Department, we know that (Prefix, Num, SecNum) could also be a primary key for this table.
Department
Prefix
Num
SecNum
CourseName
Instructor
Mathematics
Math
101 1
Algebra I
Al Jeebra 2
201
Calculus I
Kal Kuelus
Philosophy
Phil
Greek Thought
Arie Stottle
202
Euro Thought
Mike Angelo
Marketing
Mktg
410
Marketing Strategy
Marc Ekking
SpMkg
401
Advanced Sports Marketing
Hulk Hogan

50. Example Students(name, addr, phones, CarLiked)
A student’s phones are independent of the cars they like.
Thus, each of a student’s phones appears with each of the cars they like in all combinations.
This repetition is unlike redundancy due to FD’s, of which name->addr is the only one.

51. Example Only key is {name, CarsLiked}.
Students(name, addr, CarLiked, manf, favCar)
FD’s: name->addr favCar, carsLiked->manf
Only key is {name, CarsLiked}.
In each FD, the left side is not a superkey.
Any one of these FD’s shows Students is not in BCNF

52. Boyce-Codd Normal Form
We say a relation R is in BCNF if whenever X ->A is a nontrivial FD that holds in R, X is a superkey.
Remember: nontrivial means A is not a member of set X.
Remember, a superkey is any superset of a key (not necessarily a proper superset).

53. Example Students(name, addr, CarsLiked, manf, favCar)
F = name->addr, name -> favCar, CarsLiked->manf
Pick BCNF violation name->addr.
Close the left side: {name}+ = {name, addr, favCar}.
Decomposed relations:
Students1(name, addr, favCar)
Students2(name, CarsLiked, manf)

54. 3NF and BCNF
3rd Normal Form (3NF) modifies the BCNF condition so we do not have to decompose in this problem situation.
X ->A violates 3NF if and only if X is not a superkey, and also A is not prime.

55. Exercises
The following relation schema is not in third normal form (3NF) Is this an example of a transitive dependency or a partial key dependency? Give an equivalent schema that is in 3NF.
SID
FROM_CITY
TO_CITY
DISTANCE
SHIPMENT
WEIGHT

56. Exercises
This relation has been proposed to track Pacific alumni: Alumni( SID, LastName, FirstName, Degree, YearAwarded, Phone). Pacific allows students to receive multiple degrees, possibly in different years. Identify all FDs. Give a new schema that is in third normal form.

57. Exercises
Consider the following relation schema: Movie(title, genre, length, actor, sag_id, studio, studio_addr)  
Every movie has a unique title.
A movie may have multiple actors.
Each actor has a unique sag_id.
An actor may appear in multiple movies.
A movie has exactly one studio, but a studio may produce more than one movie.
Each studio has exactly one address.
Identify all functional dependencies.
Normalize the schema to 3NF.

58. INDEX
Is used to speed up the retrieval of records in response to certain search conditions
Any field of the file can be used to create an index

59. Index
Multiple indexes on different fields can be constructed on same file.
Is specified on the ordered key field of file (single index) and B+ tree (multiple indexes)

60. Primary index It has 2 fields: Primary key of the data file
Pointer to a disk block (address)

61. Index problem
The main problem with primary index is insertion and deletion of records
To insert a record in its correct position, other records be shifted to give space for new one.

62. Clustering index
It based on a non-key field in the file where the record value can be repeated so it clustering into groups
The record insertion and deletion still cause a problem

63. Clustering index
The primary index requires a distinct value for each record
In clustering index, there is one entry for each distinct value

64. Secondary index It based on some non-ordering field of the data file.
There can be many secondary indexes for same file

65. Example
Create a database for managing class enrollments in a single semester. You should keep track of all students (their names, Ids, and addresses) and professors (name, Id, department). Do not record the address of professors but keep track of their ages. Maintain records of courses also. Like what classroom is assigned to a course, what is the current enrollment, and which department offers it. At most one professor teaches each course. Each student evaluates the professor teaching the course. Note that all course offerings in the semester are unique, i.e. course names and numbers do not overlap. A course can have ≥ 0 pre-requisites, excluding itself. A student enrolled in a course must have enrolled in all its pre-requisites. Each student receives a grade in each course. The departments are also unique, and can have at most one chairperson (or dept. head). A chairperson is not allowed to head two or more departments.

66. Example
Create a database for managing class enrollments in a single semester. You should keep track of all students (their names, Ids, and addresses) and professors (name, Id, department). Do not record the address of professors but keep track of their ages. Maintain records of courses also. Like what classroom is assigned to a course, what is the current enrollment, and which department offers it. At most one professor teaches each course. Each student evaluates the professor teaching the course. Note that all course offerings in the semester are unique, i.e. course names and numbers do not overlap. A course can have ≥ 0 pre-requisites, excluding itself. A student enrolled in a course must have enrolled in all its pre-requisites. Each student receives a grade in each course. The departments are also unique, and can have at most one chairperson (or dept. head). A chairperson is not allowed to head two or more departments.