🛒

Suno Dhyan Se

Ek Sawaal...

Jab tum Swiggy pe order karte ho —
tumhara Order ID daalte hi restaurant ka naam, address, delivery time
automatically aa jaata hai... kyun?

Ye coincidence nahi hai. Kuch rules hain database ke andar. Aaj hum wahi explore karenge. 👀

Real World Example

Swiggy Ka Database 📦

Order_ID	Customer_Name	Restaurant	City	Delivery_Time
ORD001	Rahul	Dominos	Delhi	30 min
ORD002	Priya	McDonald's	Mumbai	25 min
ORD003	Arjun	Biryani Hub	Pune	40 min

Dekho — ek Order_ID se hum sab kuch nikal sakte hain.
Lekin iska ulta karna possible nahi — ek City se ek hi Order_ID nahi milega.

Ye pattern... ye rule... is ke liye ek special naam hai. Thoda aur chalo. 🚶

Pattern Dekho

Koi Bhi Value → Ek Hi Jawab

Ek Student ka roll number daalo → uska naam milega. Hamesha wahi jawab.

Roll_No: 101

→

Name: Ankit Sharma

Roll_No: 102

→

Name: Sneha Patel

Roll_No: 101

→

Name: Ankit Sharma ✅

Jab bhi 101 daalo — Ankit hi aayega. Kabhi Rahul nahi, kabhi Priya nahi. Always Ankit.
Ye relationship kuch kehna chahti hai... aur ab waqt hai usse officially introduce karne ka. 🎓

🎉 Congratulations!

40%

Hum already Functional Dependency padhh chuke hain!

Woh pattern jo humne Order_ID aur Roll_No ke saath dekha —
wahi hota hai Functional Dependency in MySQL / Databases.

A → B means A determines B

If for every value of A, there is exactly one value of B — then B is Functionally Dependent on A.

Official Definition

Functional Dependency kya hai? 🔑

X → Y

Attribute Y is Functionally Dependent on attribute X, if:
"For every value of X in a relation, there is exactly one corresponding value of Y."

X = Determinant (Left side)

Jo attribute determine karta hai — jaise Roll_No, Order_ID, Aadhaar No, Employee_ID

Ye usually PRIMARY KEY hota hai

Y = Dependent (Right side)

Jo attribute determine hota hai — jaise Name, City, Salary, Department

Ye primary key pe depend karta hai

Types of FD

Functional Dependency ke Types 🗂️

1

Trivial FD

Jab dependent attribute, determinant ka hi part ho. Obvious wali.
2

Non-Trivial FD

Jab dependent attribute, determinant ka part na ho. Meaningful wali.
3

Partial FD

Composite key hai, lekin sirf uska ek part hi kisi attribute ko determine kar de.
4

Full FD

Poori composite key lagti hai ek attribute determine karne ke liye.
5

Transitive FD

A→B aur B→C, toh A→C bhi. Chain wali dependency.

Type 1

Trivial Functional Dependency

Jab Y already X ka subset ho — toh woh FD trivial hai.

{Student_ID, Name} → Name ✅ Trivial

{Student_ID, Name} → Student_ID ✅ Trivial

Yaar, isme koi naya information nahi nikal raha. Naam se naam hi milega. Obvious hai. Interesting nahi.

💡 Real life mein trivial FDs se koi design problem nahi hoti. Ye toh bas mathematical completeness ke liye define ki gayi hain.

Type 2

Non-Trivial FD

Jab Y, X ka subset na ho — tab woh Non-Trivial FD hai. Ye real aur useful hoti hain!

Student_ID → Name, Course, City ✅ Non-Trivial

EMP_ID: E101

→

Dept: HR

+

Salary: 50K

EMP_ID se Department aur Salary ka koi direct subset wala connection nahi — ye genuinely naya information de raha hai.
Yahi database design mein most commonly used type hai.

Type 3 & 4

Full vs Partial FD

Ye tab aata hai jab Composite Key ho (do ya zyada columns milke primary key banaate hain).

Student_ID	Course_ID	Student_Name	Marks
S01	C101	Ravi	85
S01	C102	Ravi	90
S02	C101	Meena	78

⚠️ Partial FD

(Student_ID, Course_ID) → Student_Name

Student_Name sirf Student_ID se hi determine hota hai — poori composite key ki zarurat nahi!

Ye problem hai! (2NF violation)

✅ Full FD

(Student_ID, Course_ID) → Marks

Marks determine karne ke liye dono chahiye — sirf Student_ID ya sirf Course_ID se Marks nahi milega.

Ye correct hai! Good design.

Type 5

Transitive Functional Dependency

Chain reaction wali dependency — A se B milta hai, B se C milta hai, toh A se C bhi mil sakta hai.

EMP_ID

→

Dept_ID

→

Dept_Manager

Toh indirectly: EMP_ID → Dept_Manager ← ye Transitive FD hai

🏥 Hospital Example:
Patient_ID → Doctor_ID → Doctor_Specialization
Patient_ID se directly specialization aa rahi hai transitively — because Doctor_ID ek bridge hai dono ke beech.

⚠️ Transitive FD ko remove karna zaroori hai 3NF (Third Normal Form) achieve karne ke liye!

Big Picture

FD aur Normalization 🔗

Functional Dependencies directly database normalization se linked hain — isiliye inhe samajhna itna critical hai.

1NF

Atomic values, no repeating groups

2NF

Partial FD remove karo

3NF

Transitive FD remove karo

BCNF

Only candidate keys should determine attributes

Yaad rakho: Jab bhi redundancy hoti hai, jab data repeat hota hai — iske peeche hamesha ek FD violation hoti hai. FD samjhe toh normalization khud samajh aa jaayegi!

Summary

Ek Nazar Mein Sab 👀

1
Trivial FD
{A,B} → A | Dependent is subset of Determinant. No new info.
2
Non-Trivial FD
A → B (B is not in A) | Real, useful FDs. Most common.
3
Partial FD
(A,B) → C, but A alone → C | Composite key ka sirf part kaafi. 2NF issue.
4
Full FD
(A,B) → C, and neither A nor B alone → C | Poori composite key zaroori. Good!
5
Transitive FD
A→B, B→C, so A→C | Chain dependency. 3NF issue.

🚀

Functional Dependency

Sirf ek rule hai — ek value se hamesha ek hi value milni chahiye.
Jab ye rule toota → redundancy, anomalies, aur data problems aate hain.

X → Y = X determines Y. Always. No exception.

Iska use hota hai: Database Design · Normalization · Query Optimization · DBMS Exams 🎯

"Jo data organized ho, woh system trusted hota hai." — Every Good DBA