Lecture 09: Functional Dependencies, Database Design Friday, October 17, 2003

Outline Functional dependencies (3.4) Rules about FDs (3.5) Design of a Relational schema (3.6)

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’

Inference If some FDs are satisfied, then others are satisfied too name  color category  department color, category  price If all these FDs are true: Then this FD also holds: name, category  price Why ??

Inference Rules for FD’s A1, A2, …, An  B1, B2, …, Bm Splitting rule and Combing rule Is equivalent to A1 ... Am B1 Bm A1, A2, …, An  B1 A1, A2, …, An  B2 . . . . . A1, A2, …, An  Bm

Inference Rules for FD’s (continued) Trivial Rule A1, A2, …, An  Ai where i = 1, 2, ..., n A1 … Am Why ?

Inference Rules for FD’s (continued) Transitive Closure Rule If A1, A2, …, An  B1, B2, …, Bm Why ? and B1, B2, …, Bm  C1, C2, …, Cp then A1, A2, …, An  C1, C2, …, Cp A1 … Am B1 Bm C1 ... Cp

Example (continued) Which Rule did we apply ? Inferred FD 1. name  color 2. category  department 3. color, category  price Start from the following FDs: Infer the following FDs: Inferred FD Which Rule did we apply ? 4. name, category  name 5. name, category  color 6. name, category  category 7. name, category  color, category 8. name, category  price

Example (continued) 1. name  color 2. category  department 3. color, category  price Answers: Inferred FD Which Rule did we apply ? 4. name, category  name Trivial rule 5. name, category  color Transitivity on 4, 1 6. name, category  category 7. name, category  color, category Split/combine on 5, 6 8. name, category  price Transitivity on 3, 7

Another Example Enrollment(student, major, course, room, time) course  time What else can we infer ? [in class, or at home]

Another Rule Augmentation A1, A2, …, An  B If then A1, A2, …, An , C1, C2, …, Cp  B Augmentation follows from trivial rules and transitivity How ?

Problem: infer ALL FDs Given a set of FDs, infer all possible FDs How to proceed ? Try all possible FDs, apply all 3 rules E.g. R(A, B, C, D): how many FDs are possible ? Drop trivial FDs, drop augmented FDs Still way too many Better: use the Closure Algorithm (next)

Closure of a set of Attributes Given a set of attributes A1, …, An The closure, {A1, …, An}+ , is the set of attributes B s.t. A1, …, An  B Example: name  color category  department color, category  price Closures: name+ = {name, color} {name, category}+ = {name, category, color, department, price} color+ = {color}

Closure Algorithm Start with X={A1, …, An}. Example: Repeat until X doesn’t change do: if B1, …, Bn  C is a FD and B1, …, Bn are all in X then add C to X. Example: name  color category  department color, category  price {name, category}+ = {name, category, color, department, price}

Example In class: A, B  C R(A,B,C,D,E,F) A, D  E B  D A, F  B Compute {A,B}+ X = {A, B, } Compute {A, F}+ X = {A, F, }

Using Closure to Infer ALL FDs Example: A, B  C A, D  B B  D Step 1: Compute X+, for every X: A+ = A, B+ = BD, C+ = C, D+ = D AB+ = ABCD, AC+ = AC, AD+ = ABCD ABC+ = ABD+ = ACD+ = ABCD (no need to compute– why ?) BCD+ = BCD, ABCD+ = ABCD Step 2: Enumerate all FD’s X  Y, s.t. Y  X+ and XY = : AB  CD, ADBC, ABC  D, ABD  C, ACD  B

Problem: find FD from the data Given a database instance Find all FD’s satisfied by that instance Useful if we don’t get enough information from our users: need to reverse engineer a data instance

In Class: Find All FDs Student Dept Course Room Alice CSE C++ 020 Bob EE HW 040 Carol DB 045 Dan Java 050 Elsa Frank Circuits Do all FDs make sense in practice ? Course  Dept, Room Dept, Room  Course Student, Dept  Course, Room Student, Course  Dept, Room Student, Room  Dept, Course

Answer Course  Dept, Room Do all FDs make sense in practice ? Dept, Room  Course Student, Dept  Course, Room Student, Course  Dept, Room Student, Room  Dept, Course Do all FDs make sense in practice ?

Keys A key is a set of attributes A1, ..., An s.t. for any other attribute B, we have 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

Computing Keys Compute X+ for all sets X If X+ = all attributes, then X is a key List only the minimal keys Note: there can be many minimal keys ! Example: R(A,B,C), ABC, BCA Minimal keys: AB and BC

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

FD’s for E/R Diagrams Given a relation constructed from an E/R diagram, what is its key? Rule 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)

FD’s for E/R Diagrams buys(name, ssn, date) Rule 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)

FD’s for E/R Diagrams 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)

FD’s for E/R Diagrams More rules: Many-one, one-many, one-one relationships Multi-way relationships Weak entity sets (Try to find them yourself, or check book)

Incomplete (what does it say ?) FD’s for E/R Diagrams 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  ssn

Relational Schema Design (or Logical Design) Main idea: Start with some relational schema Find out its FD’s Use them to design a better relational schema

Data Anomalies When a database is poorly designed we get anomalies: Redundancy: data is repeated Updated anomalies: need to change in several places Delete anomalies: may lose data when we don’t want

Relational Schema Design Recall set attributes (persons with several phones): Name SSN PhoneNumber City Fred 123-45-6789 206-555-1234 Seattle 206-555-6543 Joe 987-65-4321 908-555-2121 Westfield SSN  Name, City but not SSN  PhoneNumber Anomalies: Redundancy = repeat data Update anomalies = Fred moves to “Bellevue” Deletion anomalies = Joe deletes his phone number: what is his city ?

Relation Decomposition Break the relation into two: Name SSN PhoneNumber City Fred 123-45-6789 206-555-1234 Seattle 206-555-6543 Joe 987-65-4321 908-555-2121 Westfield Name SSN City Fred 123-45-6789 Seattle Joe 987-65-4321 Westfield SSN PhoneNumber 123-45-6789 206-555-1234 206-555-6543 987-65-4321 908-555-2121 Anomalies have gone: No more repeated data Easy to move Fred to “Bellevue” (how ?) Easy to delete all Joe’s phone number (how ?)

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

Decompositions in General R(A1, ..., An, B1, ..., Bm, C1, ..., Cp) R1(A1, ..., An, B1, ..., Bm) R2(A1, ..., An, C1, ..., Cp) R1 = projection of R on A1, ..., An, B1, ..., Bm R2 = projection of R on A1, ..., An, C1, ..., Cp

Decomposition Sometimes it is correct: Lossless decomposition Name Price Category Gizmo 19.99 Gadget OneClick 24.99 Camera Name Price Gizmo 19.99 OneClick 24.99 Name Category Gizmo Gadget OneClick Camera Lossless decomposition

Incorrect Decomposition Sometimes it is not: Name Price Category Gizmo 19.99 Gadget OneClick 24.99 Camera What’s incorrect ?? Name Category Gizmo Gadget OneClick Camera Price Category 19.99 Gadget 24.99 Camera Lossy decomposition

Decompositions in General R(A1, ..., An, B1, ..., Bm, C1, ..., Cp) R1(A1, ..., An, B1, ..., Bm) R2(A1, ..., An, C1, ..., Cp) If A1, ..., An  B1, ..., Bm Then the decomposition is lossless Note: don’t need necessarily A1, ..., An  C1, ..., Cp Example: name  price, hence the first decomposition is lossless