1. Chapter 2. The Relational Model (cont.)
IST210

2. Review of Previous Class: Keys
StudentID
FirstName
LastName
DOB
John
Smith
Jan. 1, 1989
Adam
Jun. 1, 1988
Jane
Aug, 1,1989
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

3. 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
John
Smith
Jan. 1, 1989
Adam
Jun. 1, 1988
Jane
Aug, 1,1989
Josh
Cohen
Aug. 1,1989
ClubID
ClubName
PresidentStudentID 12
Football 13
Medical 15
Dance
Foreign Key
PresidentStudentID is the foreign key in CLUB table
Italic
CLUB(ClubID, ClubName, PresidentStudentID)
STUDENT(StudentID, FirstName, LastName, DOB)
IST210

4. 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

5. 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

6. 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

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

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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?

15. 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

16. 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

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

18. 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

19. 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

20. 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

21. 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

22. 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

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

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

25. Normalization Process: Example 1: Step 3
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)
IST210

26. 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 (Customer , 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, Customer )
Create a referential integrity constraint between the original relation and the new relation.
Customer in PRESCRIPTION must exist in Customer in CUSTOMER
IST210

27. 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 (Customer , CustomerName, CustomerPhone)
PRESCRIPTION(PrescriptionNumber, Date, Drug, Dosage, Customer )
Customer in PRESCRIPTION must exist in Customer in CUSTOMER
Well-formed relational model design
IST210

28. 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