Schema Refinement and Normal Forms

421B: Database Systems - Functional Dependencies 2 Why schema refinement? q Consider relation obtained from Hourly_Emps: I Hourly_Emps (sin,rating,hourly_wages,hourly_worked)  Problems: I Update Anomaly: Can we change the wages only in the 1st tuple? I Insertion Anomaly: What if we want to insert an employee and don’t know the hourly wage for her/his rating? I Insertion Anomaly II: We can only introduce a new rating scheme when we enter an employee with this rating into the relation  Deletion Anomaly: If we delete all employees with rating 5, we lose the information about the wage for rating 5! sin rat wages hours

421B: Database Systems - Functional Dependencies 3 Functional Dependencies (FDs) q A functional dependency X  Y (X and Y are sets of attributes; X,Y  schema(R)) holds over relation R if for every allowable instance r of R: I Given two tuples t1 and t2 in instance r of R, if the X values of t1 and t2 agree, then the Y values must also agree I t1  r, t2  r,  X (t1) =  X (t2) implies  Y (t1) =  Y (t2) q FDs are determined by the semantics of the application I Let schema(R) = (a1,a2,…an); a set of attributes X  schema(R) is a candidate key for a relation R if X  R (= X  a1,a2,…an) i.e., X implies all attributes of R (typically, the key K of an entity-set has been chosen exactly because K  R) I Relationship sets (many-one,one-one) deduce FDs I Other example: no two courses can meet in the same room at the same time l {room, time}  {course} sOr short: room, time  course

421B: Database Systems - Functional Dependencies 4 FDs (contd.) q An FD is a constraint on all allowable instances of a relation R (on data that might appear in R) I Given some instance r of R, we can check if it violates some FD f, but we CANNOT deduce that some FD f’ holds over R only because it holds over r q Goal (very informal): a relation should only contain key induced FDs I We will see that other FDs lead to some form of redundancy I We achieve this goal by decomposing relations into smaller relations

421B: Database Systems - Functional Dependencies 5 Example FDs q Consider relation obtained from Hourly_Emps: I Hourly_Emps (sin,rating,hourly_wages,hourly_worked) q Notation: we will denote this relation schema by listing the attributes SRWH q Some FDs on Hourly_Emps:  sin is the key: S  SRWH  rating determines hourly_wages : R  W SR W H

421B: Database Systems - Functional Dependencies 6 Example Redundancy Anomalies q Update/Insertion/Deletion Anomalies due to R  W q How to solve the problems? I Wages is an entity set by itself with two attributes. SR W H SR H R W

421B: Database Systems - Functional Dependencies 7 Reasoning about FDs q When improving relational design, we often need to ask “does this FD hold in this relation” q Given some FDs, we can usually infer additional FDs: I Example: sin --> did, did --> location implies sin --> location I Basic set F of FDs (determined a priori by designer) I An FD f is implied by a set of FDs F if f holds whenever all FDs in F hold I F + = closure of F: set of all FDs that are implied by F q Armstrong’s Axioms (X, Y, Z are sets of attributes,i.e, X,Y,Z  schema(R)): I Reflexivity: If Y  X, then X  Y I Augmentation: If X  Y, then XZ  YZ for any Z I Transitivity: If X  Y and Y  Z, then X  Z These are sound and complete inference rules for FDs (only deduce FDs that hold and deduce all FDs) q Some additional rules (that follow from AA): I Union: If X  Y and X  Z, then X  YZ I Decomposition: If X  YZ, then X  Y and X  Z

421B: Database Systems - Functional Dependencies 8 Reasoning about FDs (Example)  Example: Contracts(C,S,J,D,P,V )  contract-id, supplier-id, proJect-id, department-id, part-id, value I C is the key: C  CSJDPV l (or more precise: {C}  {C, S, J, D, P, V}) I Application Semantics: Project (J) purchases each part using single contract: JP  C I Application Semantics: Department purchases at most one part from a supplier: SD  P I JP  C, C  CSJPDPV imply JP  CSJDPV (transitivity; JP is also key candidate) I SD  P implies SDJ  JP (augmentation) I SDJ  JP, JP  CSJPDPV imply SDJ  CSJDPV (transitivity; SDJ is also key candidate)

421B: Database Systems - Functional Dependencies 9 Attribute Closure of X q Computing F + given F is expensive I Size of closure is exponential in #attributes q Attribute closure of X = X + wrt F: I set of all attributes A such that X  A is in F + l Basis: X + = X l Induction: If Z  X +, and Z  A is in F, then add A to X + l End when X + cannot be changed I Linear time q Example F = {A  B, BC  D} : I A + = AB, B + = B, C + = C, (AB) + = AB l More precise: {A} + = {A, B}, {B} + = {B}, {C} + = {C}, {AB} + = {A,B} I (BC) + = BCD, I (AC) + = ABCD I …

421B: Database Systems - Functional Dependencies 10 Using Attribute Closure q Problem: Is FD X  Y  F + ? I Is X  Y implied by F? q Solution: I Check whether Y in X + wrt. F q Does F = {A  B, B  C, C D  E } imply A  E? I i.e, is A  E in the closure F + ? I Equivalently, is E in A + ?

421B: Database Systems - Functional Dependencies 11 Finding all key candidates q Sometimes we want to find all the key candidates for a given relation I a set of attributes X is a key candidate if X  R and there is no subset Y  X such that Y  R q Algorithm to determine the set K of all key candidates I For each set of attributes X l Set iskey = true l If X +  R then iskey = false l For each A  X while iskey sIf (X-A) + = R then iskey = false l If iskey then K = K  {X} q Exponential in the #attributes

421B: Database Systems - Functional Dependencies 12 Example Bottom Up q R(S,C,R,P) and CS  P, CS  R, CR  S I S=student-id, C=course-id, R=ranking, P=examining prof. I CS  P: a student has in a given course only one examining prof. I CS  R: in a given course a student receives exactly one ranking I CR  S: in a given course a specific ranking value can only be assigned to one student (relative evaluation of students) q Key candidates I S + = {S}, C + = {C}, R + = {R}, P + = {P} I (SC) + = {S,C,R,P} l because of CS  P and CS  R I (SR) + = {S, R}, (SP) + = {S,P} I (CR) + = {C,R,S,P} l because of CR  S and then CS  P I (CP) + = {C,P}, (RP) + = {R,P} I (SRP) + = {S, R, P} I Not interesting: l (SCR) + / (SCP) + / (CRP) + / (SCRP) + = superkey q Informal Reasoning I No attribute alone is primary key I C is not on the right site of any FD, therefore it must be part of any candidate key I CS is key candidate as shown on the left I CR is key candidate as shown on the left I CP is not candidate I No 3-attribute or 4-attribute set is key candidate because l It either does not contain C l Or it is a superset of CS or CR

421B: Database Systems - Functional Dependencies 13 Finding the closure of F q Exponential in #attributes q Algorithm I For each set of attributes X compute X + l Add X  A for each A in X + - X l Ignore or drop some “obvious” dependencies that follow from others q Obvious dependencies I Trivial FDs: right side is a subset of left side l Consequence: no point in computing {} + or closure of full set of attributes I Drop XY  A if X  A holds l Consequence: If X + is all attributes then there is no need to compute closure of superset of X I Keep only fully decomposed FDs: keep X  Y and X  Z, ignore X  YZ

421B: Database Systems - Functional Dependencies 14 Example q F = AB  C, C  D, D  A q A + = A; B + = B (nothing) q C + = ACD (add C  A) q D + = DA (nothing new) q (AB) + = ABCD (add AB  D; skip all supersets of AB) q (BC) + = ABCD (nothing new; skip all supersets of BC) q (BD) + = ABCD (add BD  C; skip all supersets of BD) q (AC) + = ACD; (AD) + = AD; CD + = ACD (nothing new) q All other sets contain AB, BC, or BD, so skip q Thus, the only interesting FDs that follow from F are C  A, AB  D, BD  C

421B: Database Systems - Functional Dependencies 15 Normalization q Remind the relation between redundancy anomalies and FDs I Only key-induced FDs hold: there is no redundancy I Given A  B and A is not key candidate: several tuples could have the same A value, and if so, they’ll have the same B value! q If a relation is in a certain normal form (BCNF, 3NF) it is known that only certain kind of FDs hold. Hence, some forms of anomalies are avoided or minimized.

421B: Database Systems - Functional Dependencies 16 BCNF and 3NF q A relation R with FDs F is in Boyce-Codd Normal Form (BCNF) if for all X  A in F+ I A  X (trivial FDs) or I X contains a key for R (X is superkey) q In other words, R is in BCNF if the only non-trivial FDs that hold over R are key constraints. I If there are two tuples that agree upon the X value we cannot infer the A value in one tuple from the A value in the other tuple q A relation R with FDs F is in 3NF (3rd Normal Form), if for all X  A in F+ I A  X (trivial FDs) or I X contains a key for R (X is superkey) or I A is part of some key for R. q If R is in BCNF, then it is in 3NF X A x a x ?

421B: Database Systems - Functional Dependencies 17 Examples q An additional FD I Hourly_Emps (sin,rating,hourly_wages,hourly_worked) I S  SRWH (sin key) and R  W (rating determines wages) I R  W violates both BCNF and 3NF conditions q Dependency only on subkey I Works In(sin,did,daddress)  Did  daddress violates both BCNF and 3NF q Hourly_Emps2 and Wages are in BCNF I Hourly_Emps2 (sin,rating,hourly_worked) I Wages (rating, hourly_wages) q In 3NF but not in BCNF I Room time  course, course  room I Key candidates are {room, time} and {time, course}  The FD course  room violates the BCNF condition.  The FD course  room does not violate 3NF since room part of a key candidate q 3NF means “third normal form”. 1NF and 2NF do exist, but only of historical interest Course Time 421 T TH M 2-4 Aaud Room

421B: Database Systems - Functional Dependencies 18 Decomposition q If a relation is not in the desired normal form we decompose it: given relation R with attributes A1 … An. A decomposition of R consists of replacing R by two or more relations such that I Each new relation scheme contains a subset of the attributes of R (and no attributes that do not appear in R), and I Every attribute of R appears as an attribute in one of the new relations I The tuples of R are split such that the corresponding subtuples appear in the new relations. I For instance, decompose Hourly_Emps SRWH into SRH and RW I Tuples of SRH:  SRH (SRWH) I Tuples of RW:  RW (SRWH) q Disadvantage of Decomposition: I some queries become more expensive since several relations must be joined (salary = wages * hours)

421B: Database Systems - Functional Dependencies 19 Lossless Join Decompositions q A decomposition of schema R into schemas R1 with attribute set X and R2 with attribute set Y is lossless-join w.r.t. to a set of FDs F, if for any instance r of R satisfying F, I  X (r)  y (r) = r I I.e., we can reconstruct r by joining the corresponding decomposed relation instances r1 and r2. q Lossless decomposition is crucial! A B C Decomp. Reconstruction r1 r2 A B B C A B C  AB (r) = r1  BC (r) = r2

421B: Database Systems - Functional Dependencies 20 Lossless Join Decompositions q The decomposition of R into R1 and R2 is lossless-join wrt F if and only if the closure of F contains I Let {a1, … an} be the set of attributes that are both in R1 and R2: then {a1, … an}  R1 or {a1,.. an}  R2 I In particular, if U  V (non trivial) holds over R then the decomposition of R into UV and R-V is lossless-join (rejoin does not create new tuples because U is key in UV and foreign key in R-V). We denote this as a decomposition along FD U  V SR W H SR H R W

421B: Database Systems - Functional Dependencies 21 Decomposition into BCNF q Given relation R with FDs F and X  Y  FD violating BCNF I Compute X + (cannot be all attributes!) I Decompose R into X + and (R - X + )  X. I Repeat until all relations in BCNF. I If X + = {X,Y} we denote this as a decomposition along X  Y q Decomposition is lossless join q Example CSJDPV, key C, JP  C, SD  P, J  S I Determine key candidates: C, JP I SD  P violates BCNF l (SD)+ = {S, D, P} l decompose into SDP, CSJDV along FD SD  P l Only FD in SDP is SD  P; SD key candidate for this relation, so in BCNF l FDs in CSJDV are C  CSJDV and J  S; C key candidate, I J  S violates BCNF for CSJDV l decompose CSJDV into JS and CJDV along J  S l For JS, F+ = {J  S}; J is key candidate for this relation, so in BCNF l For CJDV, F+ = {C  CSJDV}; C key candidate for this relation, so in BCNF q In general, several dependencies may cause violation of BCNF. The order in which we deal with them could lead to very different sets of relations q Note that we only need to look at F, not at F +. X R X+X+

421B: Database Systems - Functional Dependencies 22 BCNF and Dependency Preservation q Dependency preserving decomposition (intuitive) I Give relation R with FDs F. A dependency preserving decomposition allows us to check each dependency in F by looking at one of the decomposed relations. q Not all BCNF decompositions are dependency preserving I E.g., given CSJDPV, key C, JP  C, SD  P, J  S: l Decompose into SDP, JS and CJDQV (covering SD  P and J  S) l But now checking JP  C requires a join!  Example 2: time room  course, course  room l Keys are {time, room} and {time, course}, but course  room has a left side which is not a superkey l Decompose along course  room: R1(course,room) and R2(course,time) l Problem: you can only check the FD time room  course when joining R1 and R2 q Possible workaround in some situations I E.g., in CSJDPV example above, add JPC to the collection of relations; note that JPC tuples only stored for checking FD on a single relation (Redundancy!)

421B: Database Systems - Functional Dependencies 23 Formal Definition q Projection: I Let R be a relation schema that is decomposed into two schemas R1 and R2. The projection of F on R1 (denoted F R1 ) is the set of FDs U  V in the closure F + (NOT ONLY F) that involve only attributes in R1. Note that a dependency U  V in F + is in F R1 only if all the attributes in U and V are in R1. q Example: given CSJDPV, key C, JP  C, SD  P, J  S: l Decompose into SDP, JS and CJDQV l F SDP = {SD  P, other trivial}, F JS = {J  S, trivial}, F CJDQV = {C  JDQV, trivial} q Dependency preserving decomposition (formal) I Give relation R with FDs F decomposed into schemas R1, … Rn. The decomposition is dependency-preserving if (F R1  F R2  … F Rn ) + = F +. I Example above: lost JP  C

421B: Database Systems - Functional Dependencies 24 3NF is Dependency Preserving q We can decompose any relation R with an arbitrary set FD, such that all decomposed relations are in 3NF and the decomposition is dependency preserving. However, it might happen that not all dependencies are key induced dependencies I Room time  course, course  room I Key candidates are {room, time} and {time, course}  The FD course  room does not violate 3NF since room part of a key. However, it cannot be guaranteed by the key condition but must be guaranteed by other forms of constraints. q Obviously, the algorithm for decomposition into BCNF can be used to obtain a decomposition into 3NF (typically can stop earlier) but it does not preserve dependencies.

421B: Database Systems - Functional Dependencies 25 Summary q If a relation is in BCNF, it is free of redundancies that can be detected using FDs. Thus, trying to ensure that all relations are in BCNF is a good heuristic. q If a relation is not in BCNF, we can try to decompose it into a collection of BCNF relations. I Must consider whether all FDs are preserved. If a lossless- join, dependency preserving decomposition into BCNF is not possible (or unsuitable, given typical queries), should consider decomposition into 3NF q Decompositions should be carried out and/or re- examined while keeping performance requirements in mind.

421B: Database Systems - Functional Dependencies 26 Overall Design Process q We have assumed schema R is given I R could have been generated when converting E-R diagram to a set of tables. I R could have been a single relation containing all attributes that are of interest (called universal relation). I Normalization breaks R into smaller relations. I R could have been the result of some ad hoc design of relations, which we then test/convert to normal form. q Might keep “bad” design with redundancy for performance reasons! I Application must guarantee consistency

421B: Database Systems - Functional Dependencies 27 ER Model and Normalization q When an E-R diagram is carefully designed, identifying all entities correctly, the tables generated from the E- R diagram should not need further normalization. q However, in a real (imperfect) design there can be FDs from non-key attributes of an entity to other attributes of the entity q E.g. employee entity with attributes department- number and department-address, and an FD department-number  department-address I Good design would have made department an entity q FDs from non-key attributes of a relationship set possible, but rare --- most relationships are binary

421B: Database Systems - Functional Dependencies 28 Other Design Issues q Some aspects of database design are not caught by normalization q Examples of bad database design, to be avoided: Instead of earnings(company-id, year, amount), use I earnings-2000, earnings-2001, earnings-2002, etc., all on the schema (company-id, earnings). l Above are in BCNF, but make querying across years difficult and needs new table each year I company-year(company-id, earnings-2000, earnings-2001, earnings-2002) l Also in BCNF, but also makes querying across years difficult and requires new attribute each year. l Is an example of a crosstab, where values for one attribute become column names l Used in spreadsheets, and in data analysis tools

421B: Database Systems - Functional Dependencies 29 Minimal Cover for a Set of FDs q Usage of a minimal cover G for a given set of FDs F I Closure of F = closure of G I Right hand side of each FD in G is a single attribute I If we modify G by deleting an FD or by deleting attributes from an FD in G, the closure changes. q Intuitively, every FD in G is needed, and “as small as possible” in order to get the same closure as F I E.g., A  B, ABCD  E, EF  GH, ACDF  EG has the following minimal cover: A  B, ACD  E, EF  G and EF  H q Rules to create the cover I Put the FDs in standard form: only a single attribute on the right side I Minimize left side of each FD: check whether attribute of left side can be deleted while preserving equivalence I Delete redundant FDs

421B: Database Systems - Functional Dependencies 30 Dependency Preserving Decomposition into 3NF q Let R be a relation with a set F of FDs that is a minimal cover I decompose R into R1…Rn according to the BCNF algorithm such that each R1…Rn is 3NF. Let Fi be the projection of F onto the attributes in Ri. I Identify the set N of dependencies in F + that are not preserved, that is, not included in the closure of the union of Fi’s. I For each FD X  A in N, create a relation XA and add it to the decomposition of R. I If N contains several FDs with the same left side X  A1, …, X  An we can create one relation Ri(X,A1,.,.An)

421B: Database Systems - Functional Dependencies 31 Example q Concert(orchestra, conductor, city, date-of-concert, year- of-birth, opus, year-of-creation, date-of-world-premiere, composer) I e.g., (’Montreal Philharmonic Orchestra’, ‘L. Siegel’, ’Toronto’, ’ ’, 1937, ’Piano Concert No. 1 b-moll Op. 23’, 1874, ’ ’, ’P. Tschaikowsky’) q shortcuts: I Or (orchestra), Con (conductor), Ci (city), Doc (date-of-concerts), Yob (year-of-birth), Op (opus), Yoc (year-of-creation), Dow (date- of-world-premiere), Com (composer) q The following functional dependencies hold: q Con --> Yob q Or --> Con q Op --> Yoc, Dow, Com q Yoc, Com, Dow --> Op

421B: Database Systems - Functional Dependencies 32 Example q ISBN → publisher, title q ISBN, no → author q ISBN, author → no q publisher, title, no → author. AuthorNoTitlePublisherISBN Elmari1Fundamentals of DB systemsAddison-Wesley Navathe2Fundamentals of DB systemsAddison-Wesley Ramakrishnan1Database Management Systems McGraw Hill Gehrke2Database Management Systems McGraw Hill