603 Database Systems Senior Lecturer: Laurie Webster II, M.S.S.E.,M.S.E.E., M.S.BME, Ph.D., P.E. Lecture 6 A First Course in Database Systems

Normalization Normal Form(R) ==> refers to the highest normal form condition that it meets (degree of normalization) NOTE: Normal Forms when considered in isolation from other factors, DO NOT GUARANTEE A GOOD DATABASE DESIGN!!! It is generally not sufficient to check separately that each R i (relation schema) in the database is, say BCNF or 3NF.

Normalization Rather, The process of normalization through decomposition must also confirm the existence of additional properties that the R i s taken together should possess!!

Two key Normalization Properties The lossless join or nonadditive join property ==> guarantees spurious tuple generation does not occur with respect to the R i s created after decomposition The dependency preservation property, which ensures that each FD is represented in some individual R i resulting after decomposition

Normalization Nonadditive Join Property => extremely critical property!!!! MUST BE ACHIEVED AT ANY COST!!!!!! Dependency Preservation Property => Desirable but sometimes sacrificed!

Keys of Relation Schemas R i Superkey of R => R{A 1, A 2, ……, A n } is a set of attributes S  R with property that no two tuples t 1 or t 2 in any legal r(R) will have t 1 [S] = t 2 [S] Relation state

Keys of Relation Schemas R i A Key K is a superkey with an additional property that removal of any attribute from K will cause K not to be a superkey any more. DIFFERENCE between KEY and SUPERKEY : Key has to be minimal => If K = {A 1, A 2, ……, A n ) of R then K - {A i } is not a key of R  ( i), 1  i  k.

Keys of Relations If R (relation schema) has more than one key, each is called a candidate key One of the candidate keys is arbitrarily designated to be the primary key Attribute A i of R is called a prime attribute of R if it is a member of some candidate key of R

Functional Dependencies and Normal Forms All of the Normal Forms (1NF, 2NF, 3NF, …BCNF, etc.) are based on FDs among the attributes of R!! 4NF => based on multivalued dependencies 5NF => based on join dependencies

FDs and NFs What is “Functional” About Functional Dependencies? A 1, A 2, ……, A n  B is a “functional” dependency because in principle there is a function that takes a list of values, one for each of the attributes A 1, A 2, ……, A n and produces a unique value (or no value at all) for B NOTE: Not like a the usual sort of function in mathematics.

FDs and NFs FDs are functional in the following sense: FD is a function applied to Movies relation R that takes a string like “Star Wars” and an integer 1977 and produces the unique value of length, namely 124, that appears in the relation Movies. This function is only computed by lookup in the relation!(look for the tuple with the given title and year values and see what that tuple has for length)

Discovering Keys for Relations When a relation schema R was developed by converting an E/R design to relations we can often predict the key of the relation. First Rule about inferring keys is: If the relation comes from an entity set then the key for the relation is the key attributes of this entity set

Discovering Keys for Relations E/R Diagram for Movies Database Schema titleyear Movies Stars name address Studios length filmType Stars-in Owns name address Movies (title, year, length, filmType) Stars ( name, address) R’s with keys underlined

Discovering Keys for Relations Second Rule concerns binary relationships. R constructed from a relationship ==> the multiplicity of the relationship affects the key for R Note: There are three cases for this to described on the next slide

Discovering Keys for Relations Three cases for the Second Rule: Case 1:If the relationship is many-many then the keys of both connected E.S.s are the key attributes for R Case 2:If the relationship is many-one from entity set E 1 to entity set E 2 then the key attributes of E 1 are key attributes of R, but those of E 2 are not. Case 3:If the relationship is one-one then the key attributes for either E.S.s are key attributes of R => not a unique key for R

Reasoning about FD’s If we are told that a relation R  ( A, B, C ) and satisfies the following FD’s : 1) A  B and B  C ==> R also satisfies the FD A  C. HOW DOES THAT REASONING GO?? To prove that A  C, we must consider two tuples of R that agree on A and prove they also agree on C.

Reasoning about FD’s PROOF: R A B C t 1 ab 1 c 1 t 2 ab 2 c 2 Since R satisfies A  B, tuples agreeing on A must also agree on B. That is, b 1 = b 2, and the tuples are really (a, b, c 1 ) and (a, b, c 2 ) where b is both b 1 and b 2. Similarly, since R satisfies B  C, and the tuples agree on B, then they agree on C. Thus c 1 = c 2 ; I.e, the tuples do agree on C. We have proved that any two tuples of R that agree on A also agree on C and that is the FD A  C.

Next Lecture on FD and NF The Splitting / Combining Rule Trivial Functional Dependencies Computing the Closure of Attributes Closing Sets of Functional Dependencies