THE RELATIONAL MODEL II IST 210: Organization of Data IST210 1

How to design a well-formed model? Revisit assignment 1 Break list into tables How to split? Functional Dependency  important criteria Normalization Process  process to design a well-formed model IST210 2

Functional Dependency A relationship between attributes: some attribute(s) determine the value of other attribute(s) in the same table These attributes we name them determinant The other attributes are functionally dependent on this determinant IST210 3 CookieCost = NumberOfBoxes * $5 NumberOfBoxes  CookieCost CookieCost = NumberOfBoxes * UnitPrice (UnitPrice, NumberOfBoxes)  CookieCost determinant The composite forms determinant Functionally dependent on NumberofBoxes

Determinant in Relations IST210 4 StudentI D FirstNameLastNameDOB JohnSmithJan. 1, JohnAdamJun. 1, JaneAdamAug. 1, JoshCohenAug. 1,1989 ClubIDClubNamePresident 12Football Medical Dance Determinant: StudentID Determinant: ClubID Determinant: CourseID Determinant = Candidate key?

Review: Candidate Key A candidate key is a special key Any subset of a candidate key is NOT a key (StudentID, FirstName) is not a candidate key, because StudentID is a key IST210 5

Determinant = Candidate Key? Student ID Student Name Student's Department CourseIDInstructorCourseNameLocation 1BobIST 210JessieOrganization of Data110IST 5LisaIST 210JessieOrganization of Data110IST 2SarahIST 210JessieOrganization of Data110IST 3JimCSE 210JessieOrganization of Data110IST 1BobIST 220JohnNetwork208IST 3JimCSE 220JohnNetwork208IST 10KateIST 230DavidComputer Language206IST IST210 6 DeterminantsCandidate Key (StudentID, CourseID) StudentID CourseID (StudentID, CourseID) In a relation, a candidate key must be a determinant In a relation, a determinant may not be a candidate key If every determinant is a candidate key, it is a well-formed relation.

Normalization Normalization is a process of analyzing a relation to ensure that it is well formed No data redundancy among the nonkey attributes Data can be inserted, deleted, or modified without creating update anomalies IST210 7

Normalization Principles Relational design principle for normalized relations: To be a well-formed relation, every determinant must be a candidate key Any relation that is not well formed should be broken into two or more well-formed relations IST210 8

Normalization Process 1. Identify all the candidate keys of the relation. 2. Identify all the functional dependencies in the relation. 3. Examine the determinants of the functional dependencies. If any determinant is not a candidate key, the relation is not well formed. In this case: a. Place the columns of the functional dependency in a new relation of their own. b. Make the determinant of the functional dependency the primary key of the new relation. c. Leave a copy of the determinant as a foreign key in the original relation. d. Create a referential integrity constraint between the original relation and the new relation. 4. Repeat step 3 as many times as necessary until every determinant of every relation is a candidate key. IST210 9

Normalization Process: Example 1: Step 1 IST Step 1. Identify all the candidate keys of the relation. PrescriptionNumber

Normalization Process: Example 1: Step 2 IST Step 2. Identify all the functional dependencies in the relation. Drug  Dosage? No Customer  (CustomerName, CustomerPhone)? Yes, in this example PrescriptionNumber  (Date, Drug, Dosage, CustomerName, CustomerPhone, Customer ) This is a trivial dependency by the definition of candidate key

Normalization Process: Example 1: Step 3 IST Step 3. If any determinant is not a candidate key, the relation is not well formed. Determinant: PrescriptionNumber, Customer Candidate key: PrescriptionNumber Customer is NOT a candidate key, so the relation NOT well formed Then, we will normalize it (break it into multiple relations)

Normalization Process: Example 1: Step 3 IST Step 3. Examine the determinants of the functional dependencies. If any determinant is not a candidate key, the relation is not well formed. In this case: a.Place the columns of the functional dependency in a new relation of their own. CUSTOMER (Customer , CustomerName, CustomerPhone) b.Make the determinant of the functional dependency the primary key of the new relation. CUSTOMER (Customer , CustomerName, CustomerPhone) c.Leave a copy of the determinant as a foreign key in the original relation. PRESCRIPTION(PrescriptionNumber, Date, Drug, Dosage, Customer ) d.Create a referential integrity constraint between the original relation and the new relation. Customer in PRESCRIPTION must exist in Customer in CUSTOMER

Normalization Process: Example 1: Step 4 IST Step 4. Repeat step 3 as many times as necessary until every determinant of every relation is a candidate key. CUSTOMER (Customer , CustomerName, CustomerPhone) PRESCRIPTION(PrescriptionNumber, Date, Drug, Dosage, Customer ) Customer in PRESCRIPTION must exist in Customer in CUSTOMER Well-formed relational model design

Normalization Process: Example 2 IST Step 1. Candidate keys Step 2. Functional dependencies Step 3. Split the relation

Normalization Process: Example 2: Step 1 IST Step 1. Identify all the candidate keys of the relation. StudentNumber

Normalization Process: Example 2: Step 2 IST Step 2. Identify all the functional dependencies in the relation. DormName  DormCost Trivial dependency: StudentNumber  (LastName, FirstName, DormName, DormCost)

Normalization Process: Example 2: Step 3 IST Step 3. If any determinant is not a candidate key, the relation is not well formed. StudentNumber StudentNumber  (LastName, FirstName, DormName, DormCost) DormName  DormCost

Normalization Process: Example 2: Step 3 IST Step 3. Examine the determinants of the functional dependencies. If any determinant is not a candidate key, the relation is not well formed. In this case: a.Place the columns of the functional dependency in a new relation of their own. DORM(DormName, DormCost) b.Make the determinant of the functional dependency the primary key of the new relation. DORM(DormName, DormCost) c.Leave a copy of the determinant as a foreign key in the original relation. STU_DORM(StudentNumber, LastName, FirstName, DormName) d.Create a referential integrity constraint between the original relation and the new relation. DormName in STU_DORM must exist in DormName in DORM

Normalization Process: Example 2: Step 4 IST Step 4. Repeat step 3 as many times as necessary until every determinant of every relation is a candidate key. STU_DORM(StudentNumber, LastName, FirstName, DormName) DORM(DormName, DormCost) DormName in STU_DORM must exist in DormName in DORM Well-formed relational model design

Normalization Process: Example 3 IST Step 1. Candidate keys Step 2. Functional dependencies Step 3. Split the relation

Normalization Process: Example 3: Step 1 IST Step 1. Identify all the candidate keys of the relation. (Attorney, ClientNumber, MeetingDate)

Normalization Process: Example 3: Step 2 IST Step 2. Identify all the functional dependencies in the relation. ClientNumber  ClientName Trivial dependency: (Attorney, ClientNumber, MeetingDate)  (ClientName, Duration)

Normalization Process: Example 3: Step 3 IST Step 3. If any determinant is not a candidate key, the relation is not well formed. (Attorney, ClientNumber, MeetingDate) (Attorney, ClientNumber, MeetingDate)  (ClientName, Duration) ClientNumber  ClientName

Normalization Process: Example 3: Step 3 IST Step 3. Examine the determinants of the functional dependencies. If any determinant is not a candidate key, the relation is not well formed. In this case: a.Place the columns of the functional dependency in a new relation of their own. CLIENT(ClientNumber, ClientName) b.Make the determinant of the functional dependency the primary key of the new relation. CLIENT(ClientNumber, ClientName) c.Leave a copy of the determinant as a foreign key in the original relation. MEETING(Attorney, ClientNumber, MeetingDate, Duration) ClientNumber: A foreign key and also part of primary key d.Create a referential integrity constraint between the original relation and the new relation. ClientNumber in MEETING must exist in ClientNumber in CLIENT

Normalization Process: Example 3: Step 4 IST Step 4. Repeat step 3 as many times as necessary until every determinant of every relation is a candidate key. CLIENT(ClientNumber, ClientName) MEETING(Attorney, ClientNumber, MeetingDate, Duration) ClientNumber in MEETING must exist in ClientNumber in CLIENT Well-formed relational model design

Normalization Process: Example 4 IST Student ID Student Name Student's Department CourseIDInstructorCourseNameLocation 1BobIST 210JessieOrganization of Data110IST 5LisaIST 210JessieOrganization of Data110IST 2SarahIST 210JessieOrganization of Data110IST 3JimCSE 210JessieOrganization of Data110IST 1BobIST 220JohnNetwork208IST 3JimCSE 220JohnNetwork208IST 10KateIST 230DavidComputer Language206IST Step 1. Candidate keys Step 2. Functional dependencies Step 3. Split the relation

Normalization Process: Example 4 IST Student ID Student Name Student's Department CourseIDInstructorCourseNameLocation 1BobIST 210JessieOrganization of Data110IST 5LisaIST 210JessieOrganization of Data110IST 2SarahIST 210JessieOrganization of Data110IST 3JimCSE 210JessieOrganization of Data110IST 1BobIST 220JohnNetwork208IST 3JimCSE 220JohnNetwork208IST 10KateIST 230DavidComputer Language206IST Step 1. Candidate keys (StudentID, CourseID)(StudentID, CourseID)  all other columns StudentID  (StudentName, Student’s Department, ) CourseID  (Instructor, CourseName, Location) STUDENT(StudentID, StudentName, Student’sDepartment, ) COURSE(CourseID, Instructor, CourseName, Location) REGISTRATION(StudentID, CourseID) StudentID in REGISTRATION must exist in StudentID in STUDENT COURSEID in REGISTRATION must exist in CourseID in COURSE Step 2. Functional dependencies Step 3. Split the relation

Normalization Process: Example 5 IST GRADE(ClassName, Section, Term, Grade, StudentNumber, StudentName, Professor, Department, Professor )

Normalization Process: Example 5: Step 1 IST Step 1. Identify all the candidate keys of the relation. (ClassName, Section, Term, StudentNumber) GRADE(ClassName, Section, Term, Grade, StudentNumber, StudentName, Professor, Department, Professor )

Normalization Process: Example 5: Step 2 IST Step 2. Identify all the functional dependencies in the relation. StudentNumber  StudentName Professor  (Department, Professor ) (Classname, Section, Term)  Professor GRADE(ClassName, Section, Term, Grade, StudentNumber, StudentName, Professor, Department, Professor ) Trivial dependency: (ClassName, Section, Term, StudentNumber)  (Grade, StudentName, Professor, Department, Professor )

Normalization Process: Example 5: Step 3 IST GRADE(ClassName, Section, Term, Grade, StudentNumber, StudentName, Professor, Department, Professor ) Step 3. If any determinant is not a candidate key, the relation is not well formed. (ClassName, Section, Term, StudentNumber) (ClassName, Section, Term, StudentNumber)  all other columns StudentNumber  StudentName Professor  (Department, Professor ) (Classname, Section, Term)  Professor

Normalization Process: Example 5: Step 3 IST Step 3. Examine the determinants of the functional dependencies. If any determinant is not a candidate key, the relation is not well formed. In this case: STUDENT(StudentNumber, StudentName) PROFESSOR(Professor, Department, Professor ) CLASS_PROFESSOR(ClassName, Section, Term, Professor) GRADE_1(ClassName, Section, Term, Grade, StudentNumber) StudentNumber in GRADE_1 must exist in StudentNumber in STUDENT Proessor in CLASS_PROFESSOR must exist in Professor in PROFESSOR (ClassName, Section, Term) in GRADE_1 must exist in (ClassName, Section, Term) of CLASS_PROFESSOR StudentNumber  StudentName Professor  (Department, Professor ) (Classname, Section, Term)  Professor (ClassName, Section, Term, StudentNumber)  all other columns

Normal Form The normal forms (abbrev. NF) of relational database theory provide criteria for determining a table's degree of vulnerability to logical inconsistencies and anomalies. In textbook, briefly mentioned in P. 261 This is an important theory in database IST210 34

IST Normal formBrief definition First normal formFirst normal form (1NF) Table faithfully represents a relation and has no repeating groupsrelation Second normal formSecond normal form (2NF) No non-prime attribute in the table is functionally dependent on a proper subset of any candidate keyfunctionally dependentproper subsetcandidate key Third normal formThird normal form (3NF) Every non-prime attribute is non-transitively dependent on every candidate key in the table. The attributes that do not contribute to the description of the primary key are removed from the table. In other words, no transitivity dependency is allowed.candidate key Elementary Key Normal Form Elementary Key Normal Form (EKNF) Every non-trivial functional dependency in the table is either the dependency of an elementary key attribute or a dependency on a superkey Boyce–Codd normal form Boyce–Codd normal form (BCNF) Every non-trivial functional dependency in the table is a dependency on a superkeysuperkey Fourth normal formFourth normal form (4NF) Every non-trivial multivalued dependency in the table is a dependency on a superkeymultivalued dependency Fifth normal formFifth normal form (5NF) Every non-trivial join dependency in the table is implied by the superkeys of the tablejoin dependency Domain/key normal form Domain/key normal form (DKNF) Every constraint on the table is a logical consequence of the table's domain constraints and key constraintslogical consequence Sixth normal formSixth normal form (6NF) Table features no non-trivial join dependencies at all (with reference to generalized join operator)

First Normal Form First normal form (1NF) is a property of a relation in a relational database. A relation is in first normal form if the domain of each attribute contains only atomic values, and the value of each attribute contains only a single value from that domain IST Fail to comply 1NF Comply 1NF

Second Normal Form A table is in 2NF if and only if it is in 1NF and no non prime attribute is dependent on any proper subset of any candidate key of the table. IST Fail to comply 2NF Comply 2NF

Second Normal Form (cont.) A table is in 2NF if and only if it is in 1NF and no non prime attribute is dependent on any proper subset of any candidate key of the table. IST Comply 2NF?

Third Normal Form A table is in 3NF if and only if both of the following conditions hold: The relation R (table) is in second normal form (2NF) Every non-prime attribute of R is non-transitively dependent (i.e. directly dependent) on every super key of R. IST Fail to comply 3NF (Tournament, Year)  Winner Winner  Winner DOB Comply 3NF

Review Question A relation is well-formed if A. Every determinant is a candidate key. B. Every candidate key is a determinant. IST210 40

Summary of Chapter 2 Learn the concept of the relational model Learn the meaning and importance of keys, candidate keys, primary keys, foreign keys, and related terminology Learn the meaning of functional dependencies Learn to apply a process for normalizing relations IST210 41

Reminder Homework 2 is out – due Sept 14 th at 11:59PM No Class on Labor day IST210 42