Chapter 2. The Relational Model (cont.) IST2101. Review of Previous Class: Keys Key: – one (or more) columns of a relation that is (are) used to uniquely

IST210 1

Chapter 2. The Relational Model (cont.)

IST210 2

Review of Previous Class: Keys

• 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– StudentID

StudentID FirstName LastName DOB

9123450 John Smith Jan. 1, 1989

9123451 John Adam Jun. 1, 1988

9123452 Jane Adam Aug, 1,1989

9123453 Josh Cohen Aug. 1,1989

Relationships Between Tables

• A table is related to other tables– Shared columns in Chapter 1

IST210 3

StudentID FirstName LastName DOB9123450 John Smith Jan. 1, 19899123451 John Adam Jun. 1, 19889123452 Jane Adam Aug, 1,19899123453 Josh Cohen Aug. 1,1989

ClubID ClubName PresidentStudentID

12 Football 912345013 Medical 912345315 Dance 9123452

Primary KeyStudentID is the primary key in STUDENT table

Foreign KeyPresidentStudentID is the foreign key in CLUB table

CLUB(ClubID, ClubName, PresidentStudentID)STUDENT(StudentID, FirstName, LastName, DOB)

Italic

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(ProjID, ProjName, MgrID)MANAGER(MgrID, MgrName, Office)

ProjID ProjName MgrIDPROJECT

MgrID MgrName OfficeMANAGER

IST210 6

Foreign Key Example

Foreign Key

Primary Key

DEPARTMENT(DeptID, DeptName, Location)EMPLOYEE(EmpID, DeptID, EmpName)

DeptID DeptName Location

DEPARTMENT

EmpID DeptID EmpNameEMPLOYEE

IST210 7

Foreign Key ExampleSTUDENT 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 8

Referential Integrity Constraint

• Every value of a foreign key must match a value of an existing primary key

Student ID CourseID101 210102 210103 210104 210101 220104 220105 230105 250 250 does not exist in COURSE table!

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



• Q2. Is following design about primary key and foreign key correct?– BOOK(BookID, Title, PublishedYear, PublisherID)– PUBLISHER(PublisherID, Name, Location)

IST210 12




IST210 13




Question from last class

• What’s the primary key of this table?EmployeeID EmployeeName Skill Work Location

101 Jones Typing 114 Main Street

101 Jones Shorthand 114 Main Street

101 Jones Whittling 114 Main Street

102 Bravo Light Cleaning 73 Industrial Way

103 Ellis Alchemy 73 Industrial Way

103 Ellis Flying 73 Industrial Way

104 Harrison Light Cleaning 73 Industrial Way

EmployeeID: supposed to be a surrogate key. but not a primary key of the table?

IST210 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 * $5NumberOfBoxes CookieCost

CookieCost = NumberOfBoxes * UnitPrice(UnitPrice, NumberOfBoxes) CookieCost

determinant

The composite forms determinant

Functionally dependent on NumberofBoxes

IST210 17

Determinant in RelationsStudentID FirstName LastName DOB9123450 John Smith Jan. 1, 19899123451 John Adam Jun. 1, 19889123452 Jane Adam Aug, 1,19899123453 Josh Cohen Aug. 1,1989

ClubID ClubName President12 Football 912345013 Medical 912345315 Dance 9123452

Determinant: StudentIDStudentID (FirstName, LastName, DOB)

Determinant: ClubIDClueID (ClubName, President)

Determinant: CourseIDCourseID (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?

DeterminantsCandidate Key

(StudentID, CourseID)StudentIDCourseID(StudentID, CourseID)

In a relation, a candidate key must be a determinant

In a relation, a determinant may not be a candidate key

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 Process1. 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 23

Normalization Process: Example 1: Step 1

Step 1. Identify all the candidate keys of the relation.

PrescriptionNumber

IST210 24


Step 2. Identify all the functional dependencies in the relation.

• Drug Dosage? • No• CustomerEmail (CustomerName, CustomerPhone)?• Yes

PrescriptionNumber (Date, Drug, Dosage, CustomerName, CustomerPhone, CustomerEmail)

This is a trivial dependency by the definition of candidate key

IST210 25


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 26


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 (CustomerEmail, CustomerName, CustomerPhone)b. Make the determinant of the functional dependency the primary key

of the new relation.CUSTOMER (CustomerEmail, CustomerName, CustomerPhone)

c. Leave a copy of the determinant as a foreign key in the original relation.

PRESCRIPTION(PrescriptionNumber, Date, Drug, Dosage, CustomerEmail)

d. Create a referential integrity constraint between the original relation and the new relation.

CustomerEmail in PRESCRIPTION must exist in CustomerEmail in CUSTOMER

IST210 27


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

Documents

Chapter 2. The Relational Model (cont.) IST2101. Review of Previous Class: Keys Key: – one (or more) columns of a relation that is (are) used to uniquely