0% found this document useful (0 votes)
10 views95 pages

Functional Dependency

A pdf to learn functional dependency in dbms

Uploaded by

narayaanmadhavan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
10 views95 pages

Functional Dependency

A pdf to learn functional dependency in dbms

Uploaded by

narayaanmadhavan
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 95

22AIE303: Database Management Systems

Lecture 6

Functional Dependency
Relational Model
The relational model uses a collection of tables to represent both data and
relationships among those data

Student(Rno, name, fathername, DOB) ➔ R(A,B,C,D)


Relational Database Design
• To identify the features of good relational design
• To familiarize with Normal Form (Atomic Domain and First Normal
Form)
• To introduce Functional Dependency
Feature of Good Relational Design
Minimal Redundancy
Feature of Good Relational Design
Minimal Redundancy Combine Schema?
instructor Department
Feature of Good Relational Design
Minimal Redundancy

Redundancy leads anomaly

Anomaly → An anomaly in database management refers to an issue or inconsistency that arises


when data is not properly organized or normalized within a relational database.
These anomalies can lead to problems with data integrity, redundancy, and
consistency, particularly during data insertion, updating, or deletion operations.
Feature of Good Relational Design

painter

painter

An update anomaly occurs when the same piece of data is stored in multiple places,
and all instances of the data must be updated to maintain consistency. If one instance is
updated and others are not, it leads to inconsistent data
Feature of Good Relational Design

A deletion anomaly occurs when the deletion of data representing one fact inadvertently
results in the loss of additional, potentially important data.

Example: Mozart leave the university, lets delete Mozart → lead → loss information about
Music Department
Feature of Good Relational Design

A deletion anomaly occurs when the deletion of data representing one fact inadvertently
results in the loss of additional, potentially important data.

Example: Mozart leave the university, lets delete Mozart → lead → loss information about
Music Department
Feature of Good Relational Design

Chemistry Watson 80000000

An insertion anomaly occurs when certain data cannot be inserted into the
database without the presence of other, potentially unrelated data.

ID, name, salary absent and where ID may primary Key (therefore we can’t insert
that department using SQL)
Feature of Good Relational Design
Minimal Redundancy Combine Schema?
instructor Department

This suggests that using inst dept is a bad idea since it stores the budget amounts
redundantly and runs the risk that some user might update the budget amount in one tuple
but not all, and thus create inconsistency.

Why do we think of joining two table → Simple SQL query (without JOIN)
Feature of Good Relational Design
Decomposition
To avoid redundancy and inconsistency of data/record , need to decompose the LARGE
table.

Is ALL Decomposition GOOD?


employee (ID, name, street, city, salary)

employee1(ID,name)
employee2(name,street,city,salary)

[why common attribute in two decomposition table → to JOIN]


Feature of Good Relational Design
All Decomposition is Not GOOD

lossy decompositions

lossless decompositions
→ Design a good relational database

lossless Join decompositions


→ Design a good relational database
Feature of Good Relational Design
Feature of Good Relational Design

Element of good relational database design


• Functional Dependency
• Atomic Domain / First Normal Form

Decide a Relation(R) is Good or not


If not good then Decompose R into a set of relation
such that these conditions satify
• Each relation is in GOOD form
• The decomposition is a lossless join decomposition

To ensure that we maintain two key ideas


• Functional dependency
• Multivalued dependency
Functional Dependency
Consider a relation R and 2 attributes A and B in R

R(A,B) B is functionally dependent on A


Denote as
A B
A→B
A1 B1
A2 B2
Each value of A is associated with exactly
A3 B3
one value of B
A1 B1
A4 B4
Functional Dependency
Consider a relation R and 2 attributes A and B in R

R(A,B) B is functionally dependent on A


Denote as
A B
A→B
A1 B1
A2 B2
Each value of A is associated with exactly
A3 B3
one value of B
A1 B1
A4 B4

The functional dependency α→β holds on the relation R,


whenever any two tuples agree on attribute α, they also agree on attribute
β.

t1[α] = t2[α] ➔ t1[β] = t2[β]


Functional Dependency

Is it correct? / Does it hold?

A→B
Functional Dependency

Is it correct? / Does it hold?

A→B

Does not hold


Functional Dependency

Is it correct? / Does it hold?

A→B
Does not hold

A→C
Functional Dependency

Is it correct? / Does it hold?

A→B
Does not hold

A→C
It is hold
Functional Dependency

Is it correct? / Does it hold?

A→B
Does not hold

A→C
It is hold

C→A
Functional Dependency

Is it correct? / Does it hold?

A→B
Does not hold

A→C
It is hold

C→A
Does not hold

A→D
Functional Dependency

Is it correct? / Does it hold?

A→B
Does not hold

A→C
It is hold

C→A
Does not hold

A→D
Does not hold

D→B
It is hold
Functional Dependency
Is it correct? / Does it hold?

AB → C

CD → B

A → CD

Functional Dependency
Functional Dependency

E
E1
E2
E3
E4
E5
Functional Dependency
Key
E
E→A
E1
E2 E→B
E3
E4 E → AB
E5
Functional Dependency
Key
E
Superkey
E1
E2
E3
E4
E5

K is a superkey for relation schema R if and only if K→R,


where R is the set of all attributes in the relation.

K is a candidate key for R if and only if


K → R and
for no α ⸦ K, α → R
Functional Dependency
Key

F E
Candidate Key
F1 E1
F1 E2
F2 E3
F3 E4
F4 E1

K is a superkey for relation schema R if and only if K→R,


where R is the set of all attributes in the relation.

K is a candidate key for R if and only if


K → R and
for no α ⸦ K, α → R
Functional Dependency

• Functional dependency plays a key role in differencing


good database design and bad database design

• Functional dependency is a type of constraint that is a


generalisation of the notion of key

• X → Y, where X is a set of attributes that can determine


the value of Y
Functional Dependency

• Functional dependency plays a key role in differencing


good database design and bad database design

• Functional dependency is a type of constraint that is a


generalisation of the notion of key

• X → Y, where X is a set of attributes that can determine


the value of Y - -→ closure of Attribute

Student(Rno, name, fathername, DOB)


Rno Name Fname DOB
Rno → name
Clouser of Attribute

Set of all attributes that can be functionally determined by a given set


of attributes within a relation, based on a set of functional
dependencies

Given a relation R with a set of attribute X ⸦ R, a set of functional


dependencies , the closure of X, denoted as X+ , is the set of attributes
that can be functionally determined by X using the functional dependency
F.
Clouser of Attribute
Clouser of Attribute
Clouser of Attribute
Clouser of Attribute
Clouser of Attribute
FDs Properties

Some functional dependencies are said to be trivial because they are


Satisfied by all relations
FDs Properties
Armstrong’s Axioms
1. Reflexivity Rule
2. Augmentation Rule
3. Transitivity Rule
FDs Properties
Armstrong’s Axioms
Reflexivity Rule

A functional dependency α → β holds if β α


where are attributes or set of attributes in a relation R
FDs Properties
Armstrong’s Axioms
Augmentation

If X → Y
Then adding any set of attribute Z to both X and Y does not change the
functional dependency
FDs Properties
Armstrong’s Axioms
Transitivity

If X→ Y and Y → Z, then X → Z.
FDs Properties
Additional Rule
Union Rule:
FDs Properties
Additional Rule
Union Rule:
FDs Properties
Additional Rule
Decomposition Rule:
FDs Properties
Additional Rule
Decomposition Rule:
FDs Properties
Additional Rule
Pseudo-transitivity Rule:
Functional Dependency
Functional Dependency
FDs Rules
FDs Rules
X and Y → either single attribute or set of attribute
FDs Rules
FDs Rules
Closure of a Set of Functional Dependency
Closure of a Set of Functional Dependency
Closure of a Set of Functional Dependency
Closure of a Set of Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency
Find Key Using Functional Dependency

You might also like