Chapter 2. The Relational Model (cont.) IST210

Review of Previous Class: Keys StudentID FirstName LastName DOB 9123450 John Smith Jan. 1, 1989 9123451 Adam Jun. 1, 1988 9123452 Jane Aug, 1,1989 9123453 Josh Cohen Aug. 1,1989 Key: one (or more) columns of a relation that is (are) used to uniquely identify a row. StudentID, (StudentID, FirstName), … Candidate key: a candidate to become the primary key StudentID Primary key: a candidate key chosen to be the main key for the relation (StudentID, FirstName, LastName, DOB) Surrogate key: a column with unique numeric values that is added to a relation to serve as the primary key IST210

Relationships Between Tables A table is related to other tables Shared columns in Chapter 1 Primary Key StudentID is the primary key in STUDENT table StudentID FirstName LastName DOB 9123450 John Smith Jan. 1, 1989 9123451 Adam Jun. 1, 1988 9123452 Jane Aug, 1,1989 9123453 Josh Cohen Aug. 1,1989 ClubID ClubName PresidentStudentID 12 Football 9123450 13 Medical 9123453 15 Dance 9123452 Foreign Key PresidentStudentID is the foreign key in CLUB table Italic CLUB(ClubID, ClubName, PresidentStudentID) STUDENT(StudentID, FirstName, LastName, DOB) IST210

A Foreign Key To preserve relationships of relations, it is needed to create a foreign key A foreign key is a primary key from one table placed into another table The key is called a foreign key in the relation that receives the key Presenting a foreign key Attributes name in italic RELATION_NAME(Column1, Column 2, …, Column n) IST210

Foreign Key Example Foreign Key Primary Key PROJECT MANAGER ProjID ProjName MgrID MgrID MgrName Office Foreign Key Primary Key PROJECT(ProjID, ProjName, MgrID) MANAGER(MgrID, MgrName, Office) IST210

Foreign Key Example Foreign Key Primary Key EMPLOYEE EmpID DeptID EmpName Foreign Key DEPARTMENT DeptID DeptName Location Primary Key DEPARTMENT(DeptID, DeptName, Location) EMPLOYEE(EmpID, DeptID, EmpName) IST210

Foreign Key Example STUDENT(StudentID, Name, Department, Email) STUDENT table COURSE table REGISTRATION table STUDENT(StudentID, Name, Department, Email) COURSE(CourseID, Instructor, CourseName, Location) REGISTRATION(StudentID, CourseID) An attribute can be both part of primary key and foreign key! IST210

Referential Integrity Constraint Student ID CourseID 101 210 102 103 104 220 105 230 250 250 does not exist in COURSE table! Every value of a foreign key must match a value of an existing primary key IST210

Summary of Keys A Key is one (or more) columns of a relation that is (are) used to uniquely identify a row Single key and composite key A key (can be) a candidate key (may be chosen to be) a primary key A surrogate key: an intentionally created attribute to serve as a primary key A foreign key: link to the primary key in another table IST210

Exercise: True/False Suppose we have two tables: BOOK(BookID, Title, PublishedYear, PublisherID) PUBLISHER(PublisherID, Name, Location) Q1. PublisherID is a foreign key in PUBLISHER table? IST210

Exercise: True/False Suppose we have two tables: BOOK(BookID, Title, PublishedYear, PublisherID) PUBLISHER(PublisherID, Name, Location) Q2. Is following design about primary key and foreign key correct? IST210

Exercise: True/False Suppose we have two tables: BOOK(BookID, Title, PublishedYear, PublisherID) PUBLISHER(PublisherID, Name, Location) Q3. Is following design about primary key and foreign key correct? IST210

Exercise: True/False Suppose we have two tables: BOOK(BookID, Title, PublishedYear, PublisherID) PUBLISHER(PublisherID, Name, Location) Q4. Is following design about primary key and foreign key correct? IST210

Question from last class What’s the primary key of this table? EmployeeID EmployeeName Skill Work Location 101 Jones Typing 114 Main Street Shorthand Whittling 102 Bravo Light Cleaning 73 Industrial Way 103 Ellis Alchemy Flying 104 Harrison EmployeeID: supposed to be a surrogate key. but not a primary key of the table?

How to design a well-formed model? Revisit Chapter 1 Break list into tables, one for each theme Tables are joined together using the value of data No redundancy, easy to update, modify, delete Functional Dependency  Formal way to determine if a list/table is well-formed Normalization Process  Formal way to break a list into tables IST210

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

Determinant in Relations StudentID FirstName LastName DOB 9123450 John Smith Jan. 1, 1989 9123451 Adam Jun. 1, 1988 9123452 Jane Aug, 1,1989 9123453 Josh Cohen Aug. 1,1989 Determinant: StudentID StudentID  (FirstName, LastName, DOB) ClubID ClubName President 12 Football 9123450 13 Medical 9123453 15 Dance 9123452 Determinant: ClubID ClueID  (ClubName, President) Determinant: CourseID CourseID  (Instructor, CourseName, Location) Determinant = Candidate key? IST210

Review: Candidate Key Old Def: 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 New Def: A candidate key is “one or more attributes that functionally determine all the other attributes of the relation”. IST210

Determinant = Candidate Key? In a relation, a candidate key must be a determinant Candidate Key Determinants In a relation, a determinant may not be a candidate key StudentID CourseID (StudentID, CourseID) (StudentID, CourseID) A relation is well-formed if and only if every determinant is a candidate key. IST210

Normalization Normalization is a process of breaking a table with more than one theme into a set of tables to ensure that each table is well-formed No data redundancy Data can be inserted, deleted, or modified without creating modification problems IST210

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

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

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

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

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

Normalization Process: Example 1: Step 3 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: Place the columns of the functional dependency in a new relation of their own. CUSTOMER (CustomerEmail, CustomerName, CustomerPhone) Make the determinant of the functional dependency the primary key of the new relation. Leave a copy of the determinant as a foreign key in the original relation. PRESCRIPTION(PrescriptionNumber, Date, Drug, Dosage, CustomerEmail) Create a referential integrity constraint between the original relation and the new relation. CustomerEmail in PRESCRIPTION must exist in CustomerEmail in CUSTOMER IST210

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

Normalization Process: Exercise 1 Step 1. Candidate keys: Step 2. Functional dependencies: Step 3. Determine if the relation is well-formed. If not, split the relation into multiple well-formed relations and specify all the primary keys, foreign keys and referential integrity constraints: Hint: If any determinant is not a candidate key, the relation is not well formed. IST210