You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
195 lines
24 KiB
195 lines
24 KiB
<!--
|
|
CO_OP_TRANSLATOR_METADATA:
|
|
{
|
|
"original_hash": "9399d7b4767e75068f95ce5c660b285c",
|
|
"translation_date": "2025-09-05T14:54:30+00:00",
|
|
"source_file": "2-Working-With-Data/05-relational-databases/README.md",
|
|
"language_code": "hi"
|
|
}
|
|
-->
|
|
# डेटा के साथ काम करना: रिलेशनल डेटाबेस
|
|
|
|
| द्वारा ](../../sketchnotes/05-RelationalData.png)|
|
|
|:---:|
|
|
| डेटा के साथ काम करना: रिलेशनल डेटाबेस - _[@nitya](https://twitter.com/nitya) द्वारा स्केच नोट_ |
|
|
|
|
संभावना है कि आपने पहले जानकारी संग्रहीत करने के लिए स्प्रेडशीट का उपयोग किया होगा। आपके पास पंक्तियों और स्तंभों का एक सेट था, जहां पंक्तियों में जानकारी (या डेटा) होती थी, और स्तंभ उस जानकारी का वर्णन करते थे (जिसे कभी-कभी मेटाडेटा कहा जाता है)। एक रिलेशनल डेटाबेस इस मूल सिद्धांत पर आधारित होता है, जिसमें तालिकाओं में पंक्तियाँ और स्तंभ होते हैं, जो आपको जानकारी को कई तालिकाओं में फैलाने की अनुमति देता है। यह आपको अधिक जटिल डेटा के साथ काम करने, डुप्लीकेशन से बचने और डेटा को एक्सप्लोर करने के तरीके में लचीलापन प्रदान करता है। आइए रिलेशनल डेटाबेस की अवधारणाओं का पता लगाएं।
|
|
|
|
## [प्री-लेक्चर क्विज़](https://ff-quizzes.netlify.app/en/ds/quiz/8)
|
|
|
|
## यह सब तालिकाओं से शुरू होता है
|
|
|
|
रिलेशनल डेटाबेस का मूल तालिकाओं में होता है। ठीक वैसे ही जैसे स्प्रेडशीट में, एक तालिका पंक्तियों और स्तंभों का संग्रह होती है। पंक्ति में वह डेटा या जानकारी होती है जिसके साथ हम काम करना चाहते हैं, जैसे किसी शहर का नाम या वर्षा की मात्रा। स्तंभ उस डेटा का वर्णन करते हैं जिसे वे संग्रहीत करते हैं।
|
|
|
|
आइए शहरों के बारे में जानकारी संग्रहीत करने के लिए एक तालिका बनाकर अपनी खोज शुरू करें। हम उनके नाम और देश से शुरुआत कर सकते हैं। आप इसे निम्नलिखित तालिका में संग्रहीत कर सकते हैं:
|
|
|
|
| शहर | देश |
|
|
| -------- | ------------- |
|
|
| टोक्यो | जापान |
|
|
| अटलांटा | संयुक्त राज्य |
|
|
| ऑकलैंड | न्यूज़ीलैंड |
|
|
|
|
ध्यान दें कि **शहर**, **देश** और **जनसंख्या** जैसे स्तंभ नाम संग्रहीत डेटा का वर्णन करते हैं, और प्रत्येक पंक्ति में एक शहर की जानकारी होती है।
|
|
|
|
## एकल तालिका दृष्टिकोण की सीमाएँ
|
|
|
|
संभावना है कि ऊपर दी गई तालिका आपको काफी परिचित लग रही होगी। आइए हमारे बढ़ते डेटाबेस में कुछ अतिरिक्त डेटा जोड़ें - वार्षिक वर्षा (मिलीमीटर में)। हम 2018, 2019 और 2020 वर्षों पर ध्यान केंद्रित करेंगे। यदि हम इसे टोक्यो के लिए जोड़ें, तो यह कुछ इस तरह दिख सकता है:
|
|
|
|
| शहर | देश | वर्ष | मात्रा |
|
|
| ----- | ------- | ---- | ------ |
|
|
| टोक्यो | जापान | 2020 | 1690 |
|
|
| टोक्यो | जापान | 2019 | 1874 |
|
|
| टोक्यो | जापान | 2018 | 1445 |
|
|
|
|
आप हमारी तालिका में क्या देखते हैं? आप देख सकते हैं कि हम शहर का नाम और देश बार-बार दोहरा रहे हैं। यह काफी जगह ले सकता है, और कई प्रतियों को रखना काफी हद तक अनावश्यक है। आखिरकार, टोक्यो का केवल एक नाम है जिसमें हम रुचि रखते हैं।
|
|
|
|
ठीक है, आइए कुछ और प्रयास करें। आइए प्रत्येक वर्ष के लिए नए स्तंभ जोड़ें:
|
|
|
|
| शहर | देश | 2018 | 2019 | 2020 |
|
|
| -------- | ------------- | ---- | ---- | ---- |
|
|
| टोक्यो | जापान | 1445 | 1874 | 1690 |
|
|
| अटलांटा | संयुक्त राज्य | 1779 | 1111 | 1683 |
|
|
| ऑकलैंड | न्यूज़ीलैंड | 1386 | 942 | 1176 |
|
|
|
|
हालांकि यह पंक्ति डुप्लीकेशन से बचाता है, यह कुछ अन्य चुनौतियाँ जोड़ता है। हमें हर बार जब कोई नया वर्ष आता है, तो अपनी तालिका की संरचना को संशोधित करना होगा। इसके अलावा, जैसे-जैसे हमारा डेटा बढ़ता है, हमारे वर्षों को स्तंभों के रूप में रखना मानों डेटा को पुनः प्राप्त करना और गणना करना कठिन बना देगा।
|
|
|
|
इसीलिए हमें कई तालिकाओं और संबंधों की आवश्यकता होती है। अपने डेटा को विभाजित करके हम डुप्लीकेशन से बच सकते हैं और अपने डेटा के साथ काम करने में अधिक लचीलापन प्राप्त कर सकते हैं।
|
|
|
|
## संबंधों की अवधारणाएँ
|
|
|
|
आइए अपने डेटा पर वापस लौटें और तय करें कि हम इसे कैसे विभाजित करना चाहते हैं। हम जानते हैं कि हमें अपने शहरों के नाम और देश को संग्रहीत करना है, इसलिए यह एक तालिका में सबसे अच्छा काम करेगा।
|
|
|
|
| शहर | देश |
|
|
| -------- | ------------- |
|
|
| टोक्यो | जापान |
|
|
| अटलांटा | संयुक्त राज्य |
|
|
| ऑकलैंड | न्यूज़ीलैंड |
|
|
|
|
लेकिन अगली तालिका बनाने से पहले, हमें यह पता लगाना होगा कि प्रत्येक शहर को कैसे संदर्भित किया जाए। हमें किसी प्रकार का पहचानकर्ता, आईडी या (तकनीकी डेटाबेस शब्दों में) एक प्राथमिक कुंजी की आवश्यकता है। प्राथमिक कुंजी एक मान है जिसका उपयोग किसी तालिका में एक विशिष्ट पंक्ति की पहचान करने के लिए किया जाता है। हालांकि यह स्वयं एक मान पर आधारित हो सकता है (उदाहरण के लिए, हम शहर के नाम का उपयोग कर सकते हैं), यह लगभग हमेशा एक संख्या या अन्य पहचानकर्ता होना चाहिए। हम नहीं चाहते कि आईडी कभी बदले क्योंकि यह संबंध को तोड़ देगा। आप पाएंगे कि अधिकांश मामलों में प्राथमिक कुंजी या आईडी एक स्वचालित रूप से उत्पन्न संख्या होगी।
|
|
|
|
> ✅ प्राथमिक कुंजी को अक्सर PK के रूप में संक्षिप्त किया जाता है
|
|
|
|
### शहर
|
|
|
|
| शहर_आईडी | शहर | देश |
|
|
| ------- | -------- | ------------- |
|
|
| 1 | टोक्यो | जापान |
|
|
| 2 | अटलांटा | संयुक्त राज्य |
|
|
| 3 | ऑकलैंड | न्यूज़ीलैंड |
|
|
|
|
> ✅ आप देखेंगे कि हम इस पाठ के दौरान "आईडी" और "प्राथमिक कुंजी" शब्दों का परस्पर उपयोग करते हैं। यहां दी गई अवधारणाएँ डेटा फ्रेम पर भी लागू होती हैं, जिन्हें आप बाद में एक्सप्लोर करेंगे। डेटा फ्रेम "प्राथमिक कुंजी" शब्दावली का उपयोग नहीं करते हैं, हालांकि आप देखेंगे कि वे लगभग उसी तरह व्यवहार करते हैं।
|
|
|
|
हमारी शहरों की तालिका बन जाने के बाद, आइए वर्षा को संग्रहीत करें। शहर की पूरी जानकारी को दोहराने के बजाय, हम आईडी का उपयोग कर सकते हैं। हमें यह भी सुनिश्चित करना चाहिए कि नई बनाई गई तालिका में एक *आईडी* कॉलम हो, क्योंकि सभी तालिकाओं में एक आईडी या प्राथमिक कुंजी होनी चाहिए।
|
|
|
|
### वर्षा
|
|
|
|
| वर्षा_आईडी | शहर_आईडी | वर्ष | मात्रा |
|
|
| ----------- | ------- | ---- | ------ |
|
|
| 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 |
|
|
|
|
ध्यान दें कि **शहर_आईडी** कॉलम नई बनाई गई **वर्षा** तालिका के अंदर है। इस कॉलम में वे मान होते हैं जो **शहरों** तालिका में आईडी को संदर्भित करते हैं। तकनीकी रिलेशनल डेटा शब्दों में, इसे **विदेशी कुंजी** कहा जाता है; यह दूसरी तालिका से प्राथमिक कुंजी है। आप इसे बस एक संदर्भ या पॉइंटर के रूप में सोच सकते हैं। **शहर_आईडी** 1 टोक्यो को संदर्भित करता है।
|
|
|
|
> [!NOTE] विदेशी कुंजी को अक्सर FK के रूप में संक्षिप्त किया जाता है
|
|
|
|
## डेटा को पुनः प्राप्त करना
|
|
|
|
हमारे डेटा को दो तालिकाओं में विभाजित करने के बाद, आप सोच सकते हैं कि हम इसे कैसे पुनः प्राप्त करेंगे। यदि हम MySQL, SQL Server या Oracle जैसे रिलेशनल डेटाबेस का उपयोग कर रहे हैं, तो हम एक भाषा का उपयोग कर सकते हैं जिसे स्ट्रक्चर्ड क्वेरी लैंग्वेज या SQL कहा जाता है। SQL (कभी-कभी सीक्वल के रूप में उच्चारित) एक मानक भाषा है जिसका उपयोग रिलेशनल डेटाबेस में डेटा को पुनः प्राप्त करने और संशोधित करने के लिए किया जाता है।
|
|
|
|
डेटा को पुनः प्राप्त करने के लिए आप कमांड `SELECT` का उपयोग करते हैं। मूल रूप से, आप **उन स्तंभों को चुनते हैं** जिन्हें आप देखना चाहते हैं **उस तालिका से** जिसमें वे होते हैं। यदि आप केवल शहरों के नाम प्रदर्शित करना चाहते हैं, तो आप निम्नलिखित का उपयोग कर सकते हैं:
|
|
|
|
```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
|
|
```
|
|
|
|
## डेटा को जोड़ना
|
|
|
|
अब तक हमने एक ही तालिका से डेटा पुनः प्राप्त किया है। अब हम **शहरों** और **वर्षा** दोनों से डेटा को एक साथ लाना चाहते हैं। यह उन्हें *जोड़कर* किया जाता है। आप प्रभावी रूप से दो तालिकाओं के बीच एक सीम बनाएंगे, और प्रत्येक तालिका के एक कॉलम से मानों को मिलाएंगे।
|
|
|
|
हमारे उदाहरण में, हम **वर्षा** में **शहर_आईडी** कॉलम को **शहरों** में **शहर_आईडी** कॉलम के साथ मिलाएंगे। यह वर्षा के मान को उसके संबंधित शहर के साथ मिलाएगा। जिस प्रकार का जोड़ हम करेंगे उसे *आंतरिक* जोड़ कहा जाता है, जिसका अर्थ है कि यदि कोई पंक्तियाँ दूसरी तालिका से किसी भी चीज़ से मेल नहीं खाती हैं, तो उन्हें प्रदर्शित नहीं किया जाएगा। हमारे मामले में हर शहर की वर्षा है, इसलिए सब कुछ प्रदर्शित किया जाएगा।
|
|
|
|
आइए 2019 के लिए सभी शहरों की वर्षा को पुनः प्राप्त करें।
|
|
|
|
हम इसे चरणों में करेंगे। पहला चरण है डेटा को एक साथ जोड़ना, सीम के लिए कॉलम को इंगित करके - जैसा कि पहले **शहर_आईडी** में हाइलाइट किया गया है।
|
|
|
|
```sql
|
|
SELECT cities.city
|
|
rainfall.amount
|
|
FROM cities
|
|
INNER JOIN rainfall ON cities.city_id = rainfall.city_id
|
|
```
|
|
|
|
हमने उन दो कॉलमों को हाइलाइट किया है जिन्हें हम चाहते हैं, और यह तथ्य कि हम तालिकाओं को **शहर_आईडी** द्वारा जोड़ना चाहते हैं। अब हम केवल वर्ष 2019 को फ़िल्टर करने के लिए `WHERE` स्टेटमेंट जोड़ सकते हैं।
|
|
|
|
```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://ff-quizzes.netlify.app/en/ds/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) का उपयोग करके अनुवादित किया गया है। जबकि हम सटीकता सुनिश्चित करने का प्रयास करते हैं, कृपया ध्यान दें कि स्वचालित अनुवाद में त्रुटियां या अशुद्धियां हो सकती हैं। मूल भाषा में उपलब्ध मूल दस्तावेज़ को प्रामाणिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सिफारिश की जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम जिम्मेदार नहीं हैं। |