At The End of The Presentation, The Following Objectives May Be Achieved

Database Management Systems (DBMS)
RELATIONS
At the end of the presentation, the following objectives

may be achieved:
Define relations and determine its
fundamental concepts in RDBMS.
How to determine functional dependency.
Convert any table into a relational table.
Remove anomalies in a table.
ThrivingAndLiving.blogspot.com
RELATIONS
A named, two-dimensional table or data.

It consists of a set of named columns and an
arbitrary number of unnamed rows.
Properties of Relations
1.
2.
3.
4.
5.
Entries in columns are atomic (or single-valued)

Entries in columns are from the same domain.
Each row is unique (no duplicate rows).
The sequence of columns (left to right) is insignificant.
The sequence of rows (top to bottom) is insignificant.
RELATIONS
1. Entries in columns are atomic (or single-valued)

PATIENT
PatientNo
Name
987
John
988
Miranda
To correct the relation:

PATIENT
PatientNo
Name
DateVisit
Physician
Symptom
02/26/06
Dr. Smith
Nervousness
02/27/06
Dr. Alvarez
Panicky
02/26/06
Dr. Hope
Depression
DateVisit
Physician
Symptom
987
John
02/26/06
Dr. Smith
Nervousness
987
John
02/27/06
Dr. Alvarez
Panicky
988
Miranda
02/26/06
Dr. Hope
Depression
Make a separate row for each

value.
RELATIONS
2. Entries in columns are from the same domain

PATIENT
PatientNo
Name
DateVisit
Physician
Symptom
987
John
02/26/06
Dr. Smith
Nervousness
987
John
02/27/06
Dr. Alvarez
Panicky
988
Miranda
02/26/06
Dr. Hope
Depression
3-digit code only

Only date entries allowed.
RELATIONS
3. Each row is unique ( no duplicate rows ).
PATIENT
PatientNo
UNIQUE
Primary key is an attribute/s

that uniquely identifies the
instance of a row.
Name
DateVisit
Physician
Symptom
987
John
02/26/06
Dr. Smith
Nervousness
987
John
02/27/06
Dr. Alvarez
Panicky
988
Miranda
02/26/06
Dr. Hope
Depression
RELATIONS
4. The sequence of columns ( left to right ) is insignificant.

PATIENT
PatientNo
DateVisit Name
Symptom
Physician
987
02/26/06
John
Nervousness
Dr. Smith
987
02/27/06
John
Panicky
Dr. Alvarez
988
02/26/06
Miranda
Depression
Dr. Hope
5. The sequence of rows (top to bottom) is insignificant

PATIENT
PatientNo
Name
DateVisit
Physician
Symptom
987
John
02/26/06
Dr. Smith
Nervousness
988
Miranda
02/26/06
Dr. Hope
Depression
987
John
02/27/06
Dr. Alvarez
Panicky
RELATIONS
Relationship between two attributes

AB
- A is determinant of B;
- the value of A uniquely determines the value of B;
- the functional dependence of B on A.
RELATIONS
Problem No. 1: Determine the functional dependency notation and primary key
of the relation.
PATIENT
PatientNo Name
Address
0123
Ivy Goodings
Orange County, CA
0124
Janneth Virginia
San Francisco, CA
Solution:
PATIENT: PatientNo Name, Address

functional dependents
Therefore relation is :
PATIENT(PatientNo, Name, Address)
Primary Key
RELATIONS
Problem No. 2: Determine the functional dependency notation and primary key
of the given table.
Composite key
GRADE SHEET
- primary key
StudentNo SubjectCode Grade

0456
CS121
A+
0456
CS122
A+
0458
CS121
0458
CS222
Solution:
Therefore
relation is :
with more than

one attribute.
GRADE SHEET: StudentNo, SubjectCode Grade

GRADE SHEET(StudentNo, SubjectCode, Grade)
RELATIONS
Dependency in which one or more non-key attributes

are functionally dependent on part (but not all) of the primary key.
Problem 3: Determine the functional dependencies and primary key.
Remove partial functional dependencies. Design an ERD at the end.
EMPLOYEE
EmpID Name
Dept
Salary
Training
0123
Ivy Goodings
EDP
30,000
JavaScrpt 3/1/2010
0123
Ivy Goodings
EDP
30,000
C#
3/5/2010
0124
Janneth
Virginia
HelpDesk
20,000
MySQL
3/1/2010
Training
Date
RELATIONS
Solution:
EMPLOYEE:
EmpID Name, Dept, Salary

EmpID, Trainings TrainingDate
Therefore relation is,

EMPLOYEE ( EmpID, Trainings, Name, Dept, Salary, TrainingDate)
To remove partial functional dependencies, split the relation into
new relations according to functional dependencies.
PERSONNEL ( EmpID, Name, Dept, Salary )
TRAINING ( EmpID, Trainings, TrainingDate )
RELATIONS
Spliting the RELATION into two:

EMPLOYEE
EmpID Name
Dept
Salary
Training
0123
Ivy Goodings
EDP
30,000
JavaScrpt 3/1/2010
0123
Ivy Goodings
EDP
30,000
C#
3/5/2010
0124
Janneth
Virginia
HelpDesk
20,000
MySQL
3/1/2010
PERSONNEL
Training
Date
EmpID Name
Dept
Salary
TRAINING
EmpID Training
0123
Ivy G.
EDP
30,000
0123
JavaScrpt
3/1/2010
0124
Janneth
Virginia
HelpDesk
20,000
0123
C#
3/5/2010
0124
MySQL
3/1/2010
TrainingDate
RELATIONS
ERD will be:

maximum
(EmpID, Training, Training Date)
( EmpID, Name, Salary, Dept)
PERSONNEL
HAS
TRAINING
minimum
Cardinality constraint specifies
the number of instances of one
entity that can (or must) be
associated with each instance
of another entity.
RELATIONS
Why remove partial functional dependencies?

EMPLOYEE
EmpID Name
Dept
Salary
Training
0123
Ivy G.
EDP
30,000
JavaScrpt 3/1/2010
0123
Ivy G.
EDP
30,000
C#
3/5/2010
0124
Janneth V.
HelpDesk
20,000
MySQL
3/1/2010
Training
Date
There are ANOMALIES:

MODIFICATION - How many times do we need to update
Ivys record is she intends to transfer at Business Intelligence Dept?
INSERTION If new employee is entered, you are forced

to put an entry on training BECAUSE it is part of primary key.
DELETION If Janneth is deleted, do we need to delete also

the training she took?
RELATIONS
A functional dependency between two (or more) non-key

attributes in a relation.
Problem 4: Determine the functional dependencies and primary key.
Remove partial functional and transitive dependencies.
Design an ERD at the end.
EMPLOYEE
EmpID
Name
Gender
Branch
Code
Branch
Name
EMP01
Tom Parsons
BR01
Manila
EMP02
Anne Wells
BR02
Cebu
EMP03
Icee Almonds
BR01
Manila
RELATIONS
EMPLOYEE
EmpID
Name
Gender
Branch
Code
Branch
Name
EMP01
Tom Parsons
BR01
Manila
EMP02
Anne Wells
BR02
Cebu
EMP03
Icee Almonds
BR01
Manila
Solution:
EMPLOYEE:
Non-key
attribute
EmpID Name, Gender, BranchCode, BranchName

BranchCode BranchName
transitive dependent
RELATIONS
Therefore, relation is:

EMPLOYEE ( EmpID, Name, Gender, BranchCode, BranchName )
Are there partial functional dependents

Or transitive dependents from the given relation?
BranchName is transitive dependent.
To remove transitive dependent, split the relation into new relations.
PERSONNEL ( EmpID, Name, Gender,BranchCode )
BRANCH ( BranchCode, BranchName )
RELATIONS
Implementing the split up would mean:
EMPLOYEE
BRANCH
EmpID
Name
Gender
Branch
Code
Branch
Name
Branch
Code
Branch
Name
EMP01
Tom Parsons
BR01
Manila
BR01
Manila
EMP02
Anne Wells
BR02
Cebu
BR02
Cebu
EMP03
Icee Almonds
BR01
Manila
Foreign key is an attribute that appears

as a non-key attribute in one relation and
as a primary key in another relation.
PERSONNEL
EmpID
Name
Gender
Branch
Code
EMP01
Tom Parsons
BR01
EMP02
Anne Wells
BR02
EMP03
Icee Almonds
BR01
To design the ERD:

( EmpID, Name, Gender, BranchCode )
PERSONNEL
is included at
BRANCH
( BranchCode, BranchName )
RELATIONS
RELATIONS
Reference
Hoffer, J, Prescott, M. and McFadden, F., Modern Database
Management 6th Edition, Pearson Prentice Hall 2002
Kendall, K., Kendall, J., Systems Analysis and Design
7th Edition, Pearson Prentice Hall 2008
Visit the video presentation of this slide at:

http://thrivingandliving.blogspot.com/2010/05/functional-dependency-in-relational.html

At The End of The Presentation, The Following Objectives May Be Achieved

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

At The End of The Presentation, The Following Objectives May Be Achieved

Uploaded by

Copyright:

Available Formats

Database Management Systems (DBMS)