<!--
CO_OP_TRANSLATOR_METADATA:
{
  "original_hash": "870a0086adbc313a8eea5489bdcb2522",
  "translation_date": "2025-08-27T16:41:30+00:00",
  "source_file": "2-Working-With-Data/05-relational-databases/README.md",
  "language_code": "mr"
}
-->
# डेटासह काम करणे: रिलेशनल डेटाबेस

|![ Sketchnote by [(@sketchthedocs)](https://sketchthedocs.dev) ](../../sketchnotes/05-RelationalData.png)|
|:---:|
| डेटासह काम करणे: रिलेशनल डेटाबेस - _Sketchnote by [@nitya](https://twitter.com/nitya)_ |

संभावना आहे की तुम्ही पूर्वी माहिती साठवण्यासाठी स्प्रेडशीट वापरले असेल. तुमच्याकडे रकाने आणि स्तंभांचा संच असेल, जिथे रकाने माहिती (किंवा डेटा) असते आणि स्तंभ माहितीचे वर्णन करतात (कधीकधी याला मेटाडेटा म्हणतात). रिलेशनल डेटाबेस हा टेबल्समधील रकाने आणि स्तंभांच्या या मुख्य तत्त्वावर आधारित असतो, ज्यामुळे तुम्हाला माहिती अनेक टेबल्समध्ये पसरवता येते. यामुळे तुम्हाला अधिक जटिल डेटासह काम करता येते, पुनरावृत्ती टाळता येते आणि डेटाचा शोध घेण्याच्या पद्धतींमध्ये लवचिकता मिळते. चला रिलेशनल डेटाबेसच्या संकल्पना समजून घेऊया.

## [पूर्व-व्याख्यान क्विझ](https://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/8)

## सर्व काही टेबल्सपासून सुरू होते

रिलेशनल डेटाबेसच्या केंद्रस्थानी टेबल्स असतात. स्प्रेडशीटप्रमाणेच, टेबल म्हणजे स्तंभ आणि रकान्यांचा संग्रह असतो. रकानेमध्ये आपण ज्या डेटासह काम करू इच्छितो ती माहिती असते, जसे की शहराचे नाव किंवा पावसाचे प्रमाण. स्तंभ साठवलेल्या डेटाचे वर्णन करतात.

चला शहरांबद्दल माहिती साठवण्यासाठी टेबल तयार करून आपला अभ्यास सुरू करूया. आपण त्यांच्या नावाने आणि देशाने सुरुवात करू शकतो. तुम्ही हे टेबलमध्ये खालीलप्रमाणे साठवू शकता:

| शहर     | देश            |
| -------- | ------------- |
| टोकियो   | जपान          |
| अटलांटा  | युनायटेड स्टेट्स |
| ऑकलंड    | न्यूझीलंड      |

लक्षात घ्या की **शहर**, **देश** आणि **लोकसंख्या** या स्तंभांची नावे साठवलेल्या डेटाचे वर्णन करतात, आणि प्रत्येक रकान्यात एका शहराची माहिती आहे.

## एका टेबलच्या दृष्टिकोनातील मर्यादा

वरील टेबल तुम्हाला परिचित वाटत असेल. चला आपल्या डेटाबेसमध्ये वार्षिक पावसाची (मिलीमीटरमध्ये) अतिरिक्त माहिती जोडूया. आपण 2018, 2019 आणि 2020 या वर्षांवर लक्ष केंद्रित करू. जर आपण टोकियोसाठी ही माहिती जोडली, तर ती काहीशी अशी दिसेल:

| शहर  | देश    | वर्ष | प्रमाण |
| ----- | ------- | ---- | ------ |
| टोकियो | जपान   | 2020 | 1690   |
| टोकियो | जपान   | 2019 | 1874   |
| टोकियो | जपान   | 2018 | 1445   |

तुम्हाला आपल्या टेबलमध्ये काय दिसते? तुम्हाला कदाचित लक्षात येईल की आपण शहराचे नाव आणि देश पुन्हा पुन्हा डुप्लिकेट करत आहोत. यामुळे बरीच स्टोरेज लागेल आणि एकाच गोष्टीच्या अनेक प्रती ठेवणे अनावश्यक आहे. शेवटी, टोकियोसाठी आपल्याला फक्त एकच नाव हवे आहे.

ठीक आहे, काहीतरी वेगळे करून पाहूया. प्रत्येक वर्षासाठी नवीन स्तंभ जोडूया:

| शहर     | देश            | 2018 | 2019 | 2020 |
| -------- | ------------- | ---- | ---- | ---- |
| टोकियो   | जपान          | 1445 | 1874 | 1690 |
| अटलांटा  | युनायटेड स्टेट्स | 1779 | 1111 | 1683 |
| ऑकलंड    | न्यूझीलंड      | 1386 | 942  | 1176 |

यामुळे रकान्यांची पुनरावृत्ती टळते, परंतु यामुळे इतर काही अडचणी निर्माण होतात. प्रत्येक वेळी नवीन वर्ष आल्यावर आपल्याला टेबलची रचना बदलावी लागेल. याशिवाय, आपला डेटा वाढल्यावर वर्षे स्तंभांमध्ये असल्याने मूल्ये शोधणे आणि गणना करणे कठीण होईल.

म्हणूनच आपल्याला एकापेक्षा जास्त टेबल्स आणि नातेसंबंधांची गरज आहे. आपला डेटा वेगळा करून आपण पुनरावृत्ती टाळू शकतो आणि डेटासह काम करण्याच्या पद्धतींमध्ये अधिक लवचिकता मिळवू शकतो.

## नातेसंबंधांची संकल्पना

चला आपल्या डेटाकडे परत जाऊया आणि ते कसे विभाजित करायचे ते ठरवूया. आपल्याला माहित आहे की आपल्याला शहरांची नावे आणि देश साठवायचे आहेत, त्यामुळे हे एका टेबलमध्ये चांगले काम करेल.

| शहर     | देश            |
| -------- | ------------- |
| टोकियो   | जपान          |
| अटलांटा  | युनायटेड स्टेट्स |
| ऑकलंड    | न्यूझीलंड      |

पण पुढील टेबल तयार करण्यापूर्वी, आपल्याला प्रत्येक शहराचा संदर्भ कसा द्यायचा ते ठरवावे लागेल. आपल्याला ओळखण्यासाठी काहीतरी, आयडी किंवा (तांत्रिक डेटाबेस संज्ञेत) प्राथमिक कीची आवश्यकता आहे. प्राथमिक की म्हणजे टेबलमधील एका विशिष्ट रकान्याला ओळखण्यासाठी वापरलेले मूल्य. हे स्वतःच्या मूल्यावर आधारित असू शकते (उदाहरणार्थ, आपण शहराचे नाव वापरू शकतो), परंतु ते जवळजवळ नेहमीच एक संख्या किंवा इतर ओळखकर्ता असावा. आपण आयडी कधीही बदलू इच्छित नाही कारण त्यामुळे नातेसंबंध बिघडतील. बहुतेक प्रकरणांमध्ये प्राथमिक की किंवा आयडी ही स्वयंचलितपणे तयार केलेली संख्या असेल.

> ✅ प्राथमिक कीला अनेकदा PK असे संक्षेपित केले जाते

### शहर

| city_id | शहर     | देश            |
| ------- | -------- | ------------- |
| 1       | टोकियो   | जपान          |
| 2       | अटलांटा  | युनायटेड स्टेट्स |
| 3       | ऑकलंड    | न्यूझीलंड      |

> ✅ तुम्हाला लक्षात येईल की या धड्यात आपण "आयडी" आणि "प्राथमिक की" या संज्ञा परस्परविनिमयाने वापरतो. येथे दिलेल्या संकल्पना DataFrames वर लागू होतात, ज्याचा तुम्ही नंतर अभ्यास कराल. DataFrames "प्राथमिक की" ही संज्ञा वापरत नाहीत, परंतु तुम्हाला दिसेल की ते जवळजवळ त्याच प्रकारे वागतात.

आपले शहरांचे टेबल तयार झाल्यावर, चला पावसाची माहिती साठवूया. शहराबद्दलची संपूर्ण माहिती डुप्लिकेट करण्याऐवजी, आपण आयडी वापरू शकतो. आपण तयार केलेल्या नवीन टेबलमध्ये *आयडी* स्तंभ देखील असावा याची खात्री करणे आवश्यक आहे, कारण सर्व टेबल्समध्ये आयडी किंवा प्राथमिक की असावी.

### पाऊस

| rainfall_id | city_id | वर्ष | प्रमाण |
| ----------- | ------- | ---- | ------ |
| 1           | 1       | 2018 | 1445   |
| 2           | 1       | 2019 | 1874   |
| 3           | 1       | 2020 | 1690   |
| 4           | 2       | 2018 | 1779   |
| 5           | 2       | 2019 | 1111   |
| 6           | 2       | 2020 | 1683   |
| 7           | 3       | 2018 | 1386   |
| 8           | 3       | 2019 | 942    |
| 9           | 3       | 2020 | 1176   |

लक्षात घ्या की **city_id** स्तंभ नव्याने तयार केलेल्या **rainfall** टेबलमध्ये आहे. या स्तंभात **शहर** टेबलमधील आयडींचा संदर्भ असलेली मूल्ये आहेत. तांत्रिक रिलेशनल डेटाच्या भाषेत, याला **foreign key** म्हणतात; हे दुसऱ्या टेबलमधील प्राथमिक की आहे. तुम्ही याला फक्त संदर्भ किंवा पॉइंटर म्हणून विचार करू शकता. **city_id** 1 टोकियोचा संदर्भ देते.

> [!NOTE] Foreign key ला अनेकदा FK असे संक्षेपित केले जाते

## डेटा मिळवणे

आपला डेटा दोन टेबल्समध्ये विभाजित केल्यावर, तुम्हाला कदाचित आश्चर्य वाटेल की आपण तो कसा मिळवतो. जर आपण MySQL, SQL Server किंवा Oracle सारखा रिलेशनल डेटाबेस वापरत असू, तर आपण Structured Query Language किंवा SQL नावाची भाषा वापरू शकतो. SQL (कधीकधी sequel असे उच्चारले जाते) ही रिलेशनल डेटाबेसमधील डेटा मिळवण्यासाठी आणि बदलण्यासाठी वापरली जाणारी मानक भाषा आहे.

डेटा मिळवण्यासाठी तुम्ही `SELECT` कमांड वापरता. त्याच्या मूळ स्वरूपात, तुम्ही **select** करू इच्छित असलेले स्तंभ **from** टेबलमध्ये सूचीबद्ध करता. जर तुम्हाला फक्त शहरांची नावे प्रदर्शित करायची असतील, तर तुम्ही खालीलप्रमाणे वापरू शकता:

```sql
SELECT city
FROM cities;

-- Output:
-- Tokyo
-- Atlanta
-- Auckland
```

`SELECT` म्हणजे तुम्ही स्तंभांची यादी करता, आणि `FROM` म्हणजे तुम्ही टेबलची यादी करता.

> [NOTE] SQL सिंटॅक्स केस-इन्सेन्सिटिव्ह आहे, म्हणजे `select` आणि `SELECT` याचा अर्थ समान आहे. तथापि, तुम्ही वापरत असलेल्या डेटाबेसच्या प्रकारावर अवलंबून स्तंभ आणि टेबल्स केस सेंसिटिव्ह असू शकतात. परिणामी, प्रोग्रामिंगमध्ये सर्वकाही केस सेंसिटिव्ह असल्यासारखे वागवणे ही सर्वोत्तम पद्धत आहे. SQL क्वेरी लिहिताना कीवर्ड्स सर्व अपर-केस अक्षरांमध्ये लिहिण्याचा प्रघात आहे.

वरील क्वेरी सर्व शहरांचे प्रदर्शन करेल. कल्पना करा की आपल्याला फक्त न्यूझीलंडमधील शहरांचे प्रदर्शन करायचे आहे. आपल्याला काहीतरी फिल्टर करण्याची गरज आहे. यासाठी SQL कीवर्ड `WHERE` आहे, म्हणजे "जिथे काहीतरी खरे आहे".

```sql
SELECT city
FROM cities
WHERE country = 'New Zealand';

-- Output:
-- Auckland
```

## डेटा जोडणे

आत्तापर्यंत आपण एका टेबलमधून डेटा मिळवला आहे. आता आपल्याला **शहर** आणि **पाऊस** या दोन्ही टेबल्समधील डेटा एकत्र आणायचा आहे. हे त्यांना *जोडून* केले जाते. तुम्ही मूलत: दोन टेबल्समध्ये सीम तयार कराल आणि प्रत्येक टेबलमधील एका स्तंभातील मूल्ये जुळवाल.

आपल्या उदाहरणात, आपण **rainfall** मधील **city_id** स्तंभ **cities** मधील **city_id** स्तंभाशी जुळवू. यामुळे पावसाचे मूल्य त्याच्या संबंधित शहराशी जुळेल. आपण करणार असलेला जोड *inner* join म्हणतो, म्हणजे जर कोणत्याही रकान्यांचे दुसऱ्या टेबलमधील कोणत्याही गोष्टीशी जुळत नसेल, तर ते प्रदर्शित होणार नाही. आपल्या प्रकरणात प्रत्येक शहराला पाऊस आहे, त्यामुळे सर्व काही प्रदर्शित होईल.

चला 2019 साठी सर्व शहरांचा पाऊस मिळवूया.

आपण हे टप्प्याटप्प्याने करू. पहिला टप्पा म्हणजे **city_id** स्तंभाद्वारे डेटा जोडणे.

```sql
SELECT cities.city
    rainfall.amount
FROM cities
    INNER JOIN rainfall ON cities.city_id = rainfall.city_id
```

आता आपण हवे असलेले दोन स्तंभ हायलाइट केले आहेत, आणि **city_id** द्वारे टेबल्स जोडायचे आहेत हे नमूद केले आहे. आता आपण `WHERE` स्टेटमेंट जोडून फक्त 2019 वर्ष फिल्टर करू शकतो.

```sql
SELECT cities.city
    rainfall.amount
FROM cities
    INNER JOIN rainfall ON cities.city_id = rainfall.city_id
WHERE rainfall.year = 2019

-- Output

-- city     | amount
-- -------- | ------
-- Tokyo    | 1874
-- Atlanta  | 1111
-- Auckland |  942
```

## सारांश

रिलेशनल डेटाबेस ही माहिती अनेक टेबल्समध्ये विभागण्यावर केंद्रित असते, जी नंतर प्रदर्शन आणि विश्लेषणासाठी पुन्हा एकत्र आणली जाते. यामुळे गणना करण्यासाठी आणि अन्यथा डेटा हाताळण्यासाठी उच्च स्तराची लवचिकता मिळते. तुम्ही रिलेशनल डेटाबेसच्या मुख्य संकल्पना पाहिल्या आहेत आणि दोन टेबल्समधील जोड कसा करायचा हे शिकले आहे.

## 🚀 आव्हान

इंटरनेटवर अनेक रिलेशनल डेटाबेस उपलब्ध आहेत. तुम्ही वरील कौशल्यांचा वापर करून डेटा एक्सप्लोर करू शकता.

## व्याख्यानानंतरचा क्विझ

## [व्याख्यानानंतरचा क्विझ](https://purple-hill-04aebfb03.1.azurestaticapps.net/quiz/9)

## पुनरावलोकन आणि स्व-अभ्यास

SQL आणि रिलेशनल डेटाबेस संकल्पनांचा अभ्यास सुरू ठेवण्यासाठी [Microsoft Learn](https://docs.microsoft.com/learn?WT.mc_id=academic-77958-bethanycheum) वर अनेक संसाधने उपलब्ध आहेत.

- [रिलेशनल डेटाच्या संकल्पना वर्णन करा](https://docs.microsoft.com//learn/modules/describe-concepts-of-relational-data?WT.mc_id=academic-77958-bethanycheum)
- [Transact-SQL सह क्वेरी करणे सुरू करा](https://docs.microsoft.com//learn/paths/get-started-querying-with-transact-sql?WT.mc_id=academic-77958-bethanycheum) (Transact-SQL ही SQL ची आवृत्ती आहे)
- [Microsoft Learn वरील SQL सामग्री](https://docs.microsoft.com/learn/browse/?products=azure-sql-database%2Csql-server&expanded=azure&WT.mc_id=academic-77958-bethanycheum)

## असाइनमेंट

[असाइनमेंट शीर्षक](assignment.md)

---

**अस्वीकरण**:  
हा दस्तऐवज AI भाषांतर सेवा [Co-op Translator](https://github.com/Azure/co-op-translator) वापरून भाषांतरित करण्यात आला आहे. आम्ही अचूकतेसाठी प्रयत्नशील असलो तरी, कृपया लक्षात ठेवा की स्वयंचलित भाषांतरांमध्ये त्रुटी किंवा अचूकतेचा अभाव असू शकतो. मूळ भाषेतील दस्तऐवज हा अधिकृत स्रोत मानला जावा. महत्त्वाच्या माहितीसाठी, व्यावसायिक मानवी भाषांतराची शिफारस केली जाते. या भाषांतराचा वापर करून निर्माण होणाऱ्या कोणत्याही गैरसमज किंवा चुकीच्या अर्थासाठी आम्ही जबाबदार राहणार नाही.