1. Learning Outcomes#

2. Relationship म्हणजे काय?#

समजा आपण college साठी database तयार करत आहोत.

आपल्याकडे वेगवेगळी माहिती असू शकते:

• students
• departments
• courses
• teachers

ही सगळी माहिती एकाच table मध्ये भरली तर table इतका गोंधळेल की परिस्थिती अशी होईल — "एक ना धड भाराभर चिंध्या."

म्हणून आपण वेगवेगळ्या गोष्टींसाठी वेगवेगळे tables तयार करतो.

उदाहरणार्थ:

departments

department_id
department_name

आणि:

employees

employee_id
employee_name
department_id

आता प्रश्न असा आहे:

एखादा employee कोणत्या department मध्ये काम करतो हे database ला कसे समजणार?

इथे relationship उपयोगी पडते.

3. Definition#

उदाहरणार्थ:

Rahul हा employee आहे.

त्याचा department_id = 10 आहे.

departments table मध्ये:

10 → IT

असे असेल तर आपल्याला समजते:

Rahul → IT Department

इथे employee आणि department यांच्यामध्ये relationship तयार झाली.

4. Relationship ची गरज का पडते?#

समजा प्रत्येक employee च्या row मध्ये आपण department ची संपूर्ण माहिती ठेवली:

इथे IT आणि Pune पुन्हा पुन्हा store होत आहे.

उद्या IT department चे location Mumbai झाले तर अनेक rows update कराव्या लागतील.

एक row update झाली आणि दुसरी राहिली तर data inconsistent होऊ शकतो.

त्याऐवजी department स्वतंत्र table मध्ये ठेवू शकतो:

departments#

employees#

आता department ची माहिती एकाच ठिकाणी आहे.

Employees फक्त त्या department चा reference ठेवतात.

5. दोन tables connect कसे होतात?#

इथे दोन महत्त्वाचे terms समजून घ्या.

Primary Key#

Primary Key म्हणजे table मधील प्रत्येक row uniquely identify करणारी value.

उदाहरण:

departments.department_id

जर department_id = 10 असेल तर त्या ID ने एक specific department ओळखता येतो.

Foreign Key#

दुसऱ्या table मधील Primary Key ला refer करणाऱ्या column ला सामान्यतः Foreign Key म्हणून वापरले जाते.

उदाहरण:

employees.department_id

हा column:

departments.department_id

ला refer करू शकतो.

म्हणजे employee row जणू database ला सांगते:

"माझा department कोणता ते जाणून घ्यायचे आहे? माझ्याकडे असलेला department_id departments table मध्ये बघ."

थोडक्यात:

departments.department_id
        ↓
employees.department_id

हीच tables मधील connection तयार करण्याची मूलभूत कल्पना आहे.

6. One-to-One Relationship#

आता पहिला प्रकार पाहूया.

One-to-One म्हणजे एका table मधील एका row शी दुसऱ्या table मधील जास्तीत जास्त एक संबंधित row जोडलेली असते.

एक सोपे उदाहरण घेऊ.

आपल्याकडे:

users

आणि:

user_profiles

असे दोन tables आहेत.

आपला business rule असा आहे:

प्रत्येक user साठी एकच profile असू शकते.

उदाहरण:

User 1 Rahul → Profile 101
User 2 Sneha → Profile 102
User 3 Amit  → Profile 103

पण असे नसावे:

User 1 Rahul → Profile 101
User 1 Rahul → Profile 102
User 1 Rahul → Profile 103

कारण मग एका user च्या अनेक profiles झाल्या.

ते One-to-One राहणार नाही.

One-to-One visually समजून घेऊया#

या diagram मध्ये:

1. USER हा एक table आहे.
2. USER_PROFILE हा दुसरा table आहे.
3. user_id वापरून profile specific user सोबत जोडली जाते.
4. एका user शी एक profile जोडलेली आहे.
5. एका profile चा संबंध एका user शी आहे.

सोप्या भाषेत:

एक user → एक profile

हा One-to-One relationship चा basic mental model आहे.

7. One-to-One SQL मध्ये कशी enforce करायची?#

आता आपण फक्त diagram पाहून थांबणार नाही.

Database ला हेही सांगावे लागेल की:

"एका user साठी दुसरी profile insert करू देऊ नकोस."

त्यासाठी UNIQUE constraint उपयोगी पडते.

पहिला table:

CREATE TABLE users (
    user_id INT PRIMARY KEY,
    name VARCHAR(100)
);

दुसरा table:

CREATE TABLE user_profiles (
    profile_id INT PRIMARY KEY,
    user_id INT UNIQUE,
    bio VARCHAR(255),
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

इथे सर्वात महत्त्वाची line आहे:

user_id INT UNIQUE

user_id हा Foreign Key आहे.

पण त्याच्यावर UNIQUE सुद्धा आहे.

याचा अर्थ एकाच user_id ची duplicate value user_profiles table मध्ये पुन्हा येऊ शकत नाही.

उदाहरणार्थ:

INSERT INTO users VALUES (1, 'Rahul');

INSERT INTO user_profiles
VALUES (101, 1, 'Java Developer');

हे valid आहे.

पुन्हा:

INSERT INTO user_profiles
VALUES (102, 1, 'SQL Developer');

करण्याचा प्रयत्न केला तर user_id = 1 आधीच वापरलेला असल्यामुळे database duplicate value स्वीकारणार नाही.

आपण नेमके काय केले?#

FOREIGN KEY ने profile कोणत्या user ची आहे हे सांगितले.

UNIQUE ने एका user साठी अनेक profile rows तयार होऊ दिल्या नाहीत.

म्हणून:

Foreign Key
+
UNIQUE
=
One-to-One rule enforce करण्याचा एक सामान्य मार्ग

8. UNIQUE नसेल तर काय होईल?#

हे खूप महत्त्वाचे आहे.

समजा आपण table असा तयार केला:

CREATE TABLE user_profiles (
    profile_id INT PRIMARY KEY,
    user_id INT,
    bio VARCHAR(255),
    FOREIGN KEY (user_id) REFERENCES users(user_id)
);

इथे user_id वर UNIQUE नाही.

मग database अशा rows allow करू शकतो:

आता:

User 1
 ├─ Profile 101
 ├─ Profile 102
 └─ Profile 103

म्हणजे एका user सोबत अनेक profile rows जोडल्या गेल्या.

आपला original One-to-One business rule तुटला.

9. One-to-One कुठे वापरली जाऊ शकते?#

One-to-One प्रत्येक ठिकाणी वापरायची relationship नाही.

ती तेव्हा उपयुक्त ठरू शकते जेव्हा एका entity शी संबंधित अतिरिक्त माहिती स्वतंत्र table मध्ये ठेवायची असते.

उदाहरणे:

User आणि User Profile#

One User
→
One User Profile

Employee आणि Employee Detail#

One Employee
→
One Employee Detail

Person आणि Passport#

एखाद्या simplified system मध्ये business rule असा असू शकतो:

One Person
→
One Passport Record

इथे एक गोष्ट कायम लक्षात ठेवा:

relationship हा real-world business rule वर आधारित असतो.

"हे example इंटरनेटवर One-to-One म्हटले आहे म्हणून माझ्या application मध्येही ते One-to-Oneच असेल" असे नसते.

तुमच्या system चा rule महत्त्वाचा.

10. One-to-Many Relationship#

आता सर्वात जास्त वापरल्या जाणाऱ्या relationships पैकी एक पाहूया.

समजा company मध्ये departments आहेत.

एका department मध्ये अनेक employees काम करू शकतात.

उदाहरण:

IT Department
→ Rahul
→ Sneha
→ Amit

पण प्रत्येक employee एका specific department मध्ये आहे असे आपण या example मध्ये मानत आहोत.

मग relationship अशी होते:

एक department → अनेक employees

याला One-to-Many relationship म्हणतात.

11. One-to-Many visually समजून घेऊया#

हा diagram डावीकडून समजून घेऊया.

DEPARTMENT हा parent side आहे.

EMPLOYEE हा अनेक records असू शकणारा side आहे.

एक department:

IT

सोबत:

Rahul
Sneha
Amit

असे अनेक employee records जोडले जाऊ शकतात.

म्हणजे relationship चा mental model:

One Parent
→
Many Children

आता याला SQL मध्ये पाहू.

12. One-to-Many SQL Design#

Parent table:

CREATE TABLE departments (
    department_id INT PRIMARY KEY,
    department_name VARCHAR(100)
);

Child table:

CREATE TABLE employees (
    employee_id INT PRIMARY KEY,
    employee_name VARCHAR(100),
    department_id INT,
    FOREIGN KEY (department_id)
        REFERENCES departments(department_id)
);

इथे employees.department_id वर UNIQUE नाही.

हे मुद्दाम आहे.

का?

कारण अनेक employees कडे same department ID असणे valid आहे.

उदाहरण:

INSERT INTO departments
VALUES (10, 'IT');

आता:

INSERT INTO employees
VALUES (1, 'Rahul', 10);

INSERT INTO employees
VALUES (2, 'Sneha', 10);

INSERT INTO employees
VALUES (3, 'Amit', 10);

या तिन्ही employees चा:

department_id = 10

आहे.

हे duplicate दिसत असले तरी इथे ते चुकीचे नाही.

कारण प्रत्येक row वेगळ्या employee ची आहे.

तीन employees एकाच IT department मध्ये काम करत आहेत.

हीच आपली requirement होती.

Result#

इथे:

department_id 10

तीनदा दिसतो.

म्हणून One-to-Many relationship तयार होते.

13. Parent आणि Child म्हणजे काय?#

parent आणि child हे शब्द ऐकून family serial सुरू झाली असे समजू नका.

Database मध्ये त्यांचा साधा अर्थ आहे.

समजा:

departments

table चा department_id:

employees

table refer करत आहे.

मग सामान्यतः:

departments → Parent
employees   → Child

असे म्हणतो.

का?

कारण child row मध्ये parent चा reference असतो.

या example मध्ये:

employees.department_id

हा:

departments.department_id

ला refer करतो.

Parent-child flow#

या flow मध्ये आधी department record अस्तित्वात आहे.

उदाहरणार्थ:

department_id = 10
department_name = IT

नंतर Rahul ची employee row तयार करताना:

department_id = 10

ठेवतो.

त्यामुळे Rahul चा संबंध IT department शी तयार होतो.

सोप्या भाषेत:

Child row parent चा ID वापरून सांगते की ती कोणाशी संबंधित आहे.

14. Invalid parent reference म्हणजे काय?#

समजा departments table मध्ये फक्त:

10 → IT
20 → HR

हे departments आहेत.

आता आपण employee insert केला:

INSERT INTO employees
VALUES (4, 'Neha', 999);

पण:

department_id = 999

असा department अस्तित्वातच नाही.

जर योग्य FOREIGN KEY constraint असेल तर database ही invalid relationship स्वीकारणार नाही.

कारण child record अशा parent कडे बोट दाखवत आहे जो अस्तित्वातच नाही.

जणू कोणी म्हणाले:

"मी Room Number 999 मध्ये राहतो."

आणि hotel मध्ये Room 999 आहेच नाही.

Receptionist म्हणेल:

"साहेब, आधी room तरी असू द्या!"

Database सुद्धा त्याच logic ने referential consistency जपतो.

15. One-to-One आणि One-to-Many मधला मुख्य फरक#

हे लक्षात ठेवण्याचा सर्वात सोपा मार्ग:

One-to-One:
एका व्यक्तीसाठी एक locker

One-to-Many:
एका classroom मध्ये अनेक students

पण analogy फक्त कल्पना समजण्यासाठी आहे.

Actual database relationship नेहमी तुमच्या application's business rule नुसार ठरवा.

16. Relationship ठरवताना योग्य प्रश्न कोणता?#

हा प्रश्न विचारू नका:

"या दोन tables मध्ये कोणती relationship popular आहे?"

त्याऐवजी business requirement ला प्रश्न विचारा.

समजा entities आहेत:

Department
Employee

स्वतःला विचारा:

एका Department शी किती Employees जोडले जाऊ शकतात?

Many

One

Department → Employee
One        → Many

दुसरे example#

Entities:

User
User Profile

प्रश्न:

एका User ला किती Profiles allow आहेत?

One

एका Profile चा किती Users शी संबंध आहे?

One

म्हणून:

User → User Profile
One  → One

हे One-to-One आहे.

17. Real-World Examples#

Customer आणि Orders#

एक customer अनेक orders करू शकतो.

Customer
→ Order 1
→ Order 2
→ Order 3

म्हणून:

Customer → Orders
One      → Many

Category आणि Products#

एका category मध्ये अनेक products असू शकतात.

Electronics
→ Laptop
→ Mobile
→ Headphones

म्हणून:

Category → Products
One      → Many

Employee आणि Employee Profile#

जर application मध्ये प्रत्येक employee साठी फक्त एक profile record ठेवायचा असेल:

Employee → Employee Profile
One      → One

Country आणि Cities#

एका country मध्ये अनेक cities असतात.

Country → Cities
One     → Many

इथे एक pattern दिसतोय:

Relationship समजण्यासाठी आधी tables पाहण्यापेक्षा business sentence तयार करा.

उदाहरण:

"One department can have many employees."

या एका sentence मधूनच relationship जवळपास स्पष्ट होते.

18. Common Beginner Mistakes#

Mistake 1: Foreign Key दिसला म्हणजे One-to-Many#

नेहमीच नाही.

Foreign Key tables जोडतो.

Relationship One-to-One आहे की One-to-Many हे constraints आणि business rule ठरवतात.

Mistake 2: One-to-One मध्ये UNIQUE विसरणे#

जर child-side reference duplicate होऊ शकत असेल तर एका parent शी अनेक child rows जोडल्या जाऊ शकतात.

मग intended One-to-One rule database enforce करणार नाही.

Mistake 3: Parent आणि Child उलटे समजणे#

ज्या table मध्ये Foreign Key आहे तो सामान्यतः child असतो.

ज्या table च्या key ला तो refer करतो तो parent असतो.

Mistake 4: Real-world requirement न विचारता relationship बनवणे#

पहिले requirement समजा.

नंतर database design करा.

नाहीतर अवस्था होते — "आधी लगीन कोंढाण्याचं, मग रायबाचं."

म्हणजे design आधी आणि requirement नंतर असे करू नका.

Mistake 5: Duplicate Foreign Key म्हणजे नेहमी error#

One-to-Many मध्ये duplicate Foreign Key values पूर्णपणे योग्य असू शकतात.

उदाहरण:

department_id = 10

अनेक employee rows मध्ये असणे अपेक्षितच आहे.

19. Practical Modelling Strategy#

जेव्हा दोन entities दिसतील तेव्हा ही विचार करण्याची सवय लावा.

Step 1: दोन entities ओळखा#

उदाहरण:

Department
Employee

Step 2: पहिल्या entity च्या एका record कडे पाहा#

One Department

Step 3: त्याच्याशी दुसऱ्या entity चे किती records जोडले जाऊ शकतात ते विचारा#

Many Employees

Step 4: उलट दिशेने विचार करा#

One Employee
→
One Department

Step 5: Business rule database मध्ये enforce करा#

Primary Key, Foreign Key आणि आवश्यक constraints वापरून design तयार करा.

हा विचार करण्याचा approach पाठ केल्यास relationship पाठांतराने नाही तर logic ने समजू लागते.

20. Interview Preparation#

21. Hands-On Practice#

Practice 1#

Requirement

एका company मध्ये:

• एक department मध्ये अनेक employees असू शकतात.
• प्रत्येक employee एकाच department मध्ये काम करतो.

Your Task

Relationship चा प्रकार ओळखा आणि parent व child table सांगा.

Parent: departments
Child: employees

One Department
→
Many Employees

Practice 2#

Requirement

एका application मध्ये:

• प्रत्येक account साठी फक्त एक settings record असू शकतो.
• एक settings record फक्त एका account शी संबंधित असतो.

Your Task

Relationship ओळखा आणि SQL design मध्ये One-to-One rule कसा enforce कराल ते सांगा.

CREATE TABLE accounts (
    account_id INT PRIMARY KEY,
    username VARCHAR(100)
);

CREATE TABLE account_settings (
    settings_id INT PRIMARY KEY,
    account_id INT UNIQUE,
    theme VARCHAR(50),
    FOREIGN KEY (account_id)
        REFERENCES accounts(account_id)
);

Practice 3#

Requirement

खालील data पहा:

categories

1 → Books
2 → Electronics

products

101 → SQL Book     → category 1
102 → Java Book    → category 1
103 → Laptop       → category 2
104 → Smartphone   → category 2

Your Task

categories आणि products यांच्यातील relationship ओळखा.

One Category
→
Many Products

22. या Chapter मधून काय लक्षात ठेवायचे?#

• relationship दोन tables मधील related records कसे जोडलेले आहेत ते दर्शवते.
• Primary Key row uniquely identify करते.
• Foreign Key दुसऱ्या table मधील key ला refer करून connection तयार करते.
• One-to-One मध्ये एका record शी जास्तीत जास्त एक corresponding record जोडलेला असतो.
• One-to-One enforce करण्यासाठी Foreign Key सोबत UNIQUE constraint उपयुक्त ठरू शकते.
• One-to-Many मध्ये एका parent row शी अनेक child rows जोडलेल्या असू शकतात.
• One-to-Many मध्ये same Foreign Key value अनेक child rows मध्ये येणे normal असू शकते.
• Foreign Key असणे आणि relationship type ठरणे या दोन वेगळ्या गोष्टी आहेत.
• parent table च्या record ला child table refer करते.
• Relationship design नेहमी actual business rule वर आधारित असावी.
• योग्य relationship शोधण्यासाठी सर्वात चांगला प्रश्न आहे: "एका record शी दुसऱ्या बाजूचे किती records जोडले जाऊ शकतात?"