a candidate key

IST210
THE RELATIONAL
MODEL II
IST 210: Organization of Data
1
IST210
2
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
3
IST210
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
CookieCost = NumberOfBoxes * $5
NumberOfBoxes  CookieCost
determinant
Functionally dependent on
NumberofBoxes
CookieCost = NumberOfBoxes * UnitPrice
(UnitPrice, NumberOfBoxes)  CookieCost
The composite forms determinant
IST210
4
Determinant in Relations
StudentI
D
9123450
9123451
9123452
9123453
ClubID
12
13
15
FirstName
LastName
DOB
John
John
Jane
Josh
Smith
Adam
Adam
Cohen
Jan. 1, 1989
Jun. 1, 1988
Aug. 1,1989
Aug. 1,1989
ClubName
Football
Medical
Dance
President
9123450
9123453
9123452
Determinant: StudentID
Determinant: ClubID
Determinant: CourseID
Determinant = Candidate key?
IST210
5
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
6
IST210
Determinant = Candidate Key?
Student ID
1
5
2
3
1
3
10
Student
Name
Bob
Lisa
Sarah
Jim
Bob
Jim
Kate
Student's
Department
IST
IST
IST
CSE
IST
CSE
IST
Email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
CourseID Instructor
CourseName
Location
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
220
John
Network
208IST
220
John
Network
208IST
230
David
Computer Language 206IST
In a relation, a candidate key must be a determinant
Candidate Key
(StudentID, CourseID)
Determinants
In a relation, a determinant
may not be a candidate key
If every determinant is a candidate
key, it is a well-formed relation.
StudentID
CourseID
(StudentID,
CourseID)
IST210
7
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
8
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
9
Normalization Process
1.
2.
3.
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:
a.
b.
c.
d.
4.
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
10
Normalization Process: Example 1: Step 1
Step 1. Identify all the candidate keys of the relation.
PrescriptionNumber
IST210
11
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?
This is a trivial
No
CustomerEmail  (CustomerName, CustomerPhone)? dependency by
the definition of
Yes, in this example
candidate key
IST210
12
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
13
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:
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
14
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
15
Normalization Process: Example 2
Step 1. Candidate keys
Step 2. Functional dependencies
Step 3. Split the relation
IST210
16
Normalization Process: Example 2: Step 1
Step 1. Identify all the candidate keys of the relation.
StudentNumber
IST210
17
Normalization Process: Example 2: Step 2
Step 2. Identify all the functional dependencies in the relation.
Trivial dependency:
StudentNumber  (LastName, FirstName, DormName, DormCost)
• DormName  DormCost
IST210
18
Normalization Process: Example 2: Step 3
Step 3. If any determinant is not a candidate key, the relation is not well
formed.
StudentNumber
StudentNumber  (LastName, FirstName, DormName, DormCost)
DormName  DormCost
IST210
19
Normalization Process: Example 2: 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:
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
IST210
20
Normalization Process: Example 2: Step 4
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
IST210
21
Normalization Process: Example 3
Step 1. Candidate keys
Step 2. Functional dependencies
Step 3. Split the relation
IST210
22
Normalization Process: Example 3: Step 1
Step 1. Identify all the candidate keys of the relation.
(Attorney, ClientNumber, MeetingDate)
IST210
23
Normalization Process: Example 3: Step 2
Step 2. Identify all the functional dependencies in the relation.
Trivial dependency:
(Attorney, ClientNumber, MeetingDate) (ClientName, Duration)
• ClientNumber  ClientName
IST210
24
Normalization Process: Example 3: Step 3
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
IST210
25
Normalization Process: Example 3: 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:
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
IST210
26
Normalization Process: Example 3: Step 4
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
IST210
27
Normalization Process: Example 4
Student ID
1
5
2
3
1
3
10
Student
Name
Bob
Lisa
Sarah
Jim
Bob
Jim
Kate
Student's
Department
IST
IST
IST
CSE
IST
CSE
IST
Email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
Step 1. Candidate keys
Step 2. Functional dependencies
Step 3. Split the relation
CourseID Instructor
CourseName
Location
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
220
John
Network
208IST
220
John
Network
208IST
230
David
Computer Language 206IST
IST210
28
Normalization Process: Example 4
Student ID
1
5
2
3
1
3
10
Student
Name
Bob
Lisa
Sarah
Jim
Bob
Jim
Kate
Student's
Department
IST
IST
IST
CSE
IST
CSE
IST
Step 1. Candidate keys
(StudentID, CourseID)
Step 3. Split the relation
Email
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
[email protected]
CourseID Instructor
CourseName
Location
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
210
Jessie
Organization of Data 110IST
220
John
Network
208IST
220
John
Network
208IST
230
David
Computer Language 206IST
Step 2. Functional dependencies
• (StudentID, CourseID)  all other columns
• StudentID  (StudentName, Student’s Department,
Email)
• CourseID  (Instructor, CourseName, Location)
STUDENT(StudentID, StudentName, Student’sDepartment, Email)
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
IST210
29
Normalization Process: Example 5
GRADE(ClassName, Section, Term, Grade,
StudentNumber, StudentName, Professor, Department,
ProfessorEmail)
IST210
30
Normalization Process: Example 5: Step 1
GRADE(ClassName, Section, Term, Grade,
StudentNumber, StudentName, Professor, Department,
ProfessorEmail)
Step 1. Identify all the candidate keys of the relation.
(ClassName, Section, Term, StudentNumber)
IST210
31
Normalization Process: Example 5: Step 2
GRADE(ClassName, Section, Term, Grade,
StudentNumber, StudentName, Professor, Department,
ProfessorEmail)
Step 2. Identify all the functional dependencies in the relation.
Trivial dependency:
(ClassName, Section, Term, StudentNumber)
(Grade, StudentName, Professor, Department,
ProfessorEmail)
• StudentNumber  StudentName
• Professor  (Department, ProfessorEmail)
• (Classname, Section, Term)  Professor
IST210
32
Normalization Process: Example 5: Step 3
GRADE(ClassName, Section, Term, Grade,
StudentNumber, StudentName, Professor, Department,
ProfessorEmail)
Step 3. If any determinant is not a candidate key, the relation is not well
formed.
• (ClassName, Section, Term,
(ClassName, Section, Term, StudentNumber)
StudentNumber)  all other columns
• StudentNumber  StudentName
• Professor  (Department,
ProfessorEmail)
• (Classname, Section, Term)  Professor
IST210
33
Normalization Process: Example 5: 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:
STUDENT(StudentNumber, StudentName)
PROFESSOR(Professor, Department, ProfessorEmail)
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
• (ClassName, Section, Term,
StudentNumber)  all other columns
•
•
•
StudentNumber  StudentName
Professor  (Department, ProfessorEmail)
(Classname, Section, Term)  Professor
IST210
Review Question
• A relation is well-formed if
• A. Every determinant is a candidate key.
• B. Every candidate key is a determinant.
40
IST210
41
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
Reminder
• Homework 2 is out – due Sept 14th at 11:59PM
• No Class on Labor day
42