# डेटा के साथ काम करना: रिलेशनल डेटाबेस |![ स्केचनोट द्वारा [(@sketchthedocs)](https://sketchthedocs.dev) ](../../sketchnotes/05-RelationalData.png)| |:---:| | डेटा के साथ काम करना: रिलेशनल डेटाबेस - _स्केचनोट द्वारा [@nitya](https://twitter.com/nitya)_ | संभावना है कि आपने पहले किसी स्प्रेडशीट का उपयोग जानकारी संग्रहीत करने के लिए किया होगा। आपके पास पंक्तियों और स्तंभों का एक सेट था, जहां पंक्तियों में जानकारी (या डेटा) होती थी, और स्तंभ उस जानकारी का वर्णन करते थे (जिसे कभी-कभी मेटाडेटा कहा जाता है)। एक रिलेशनल डेटाबेस इस मूल सिद्धांत पर आधारित होता है कि तालिकाओं में स्तंभ और पंक्तियाँ होती हैं, जिससे आप जानकारी को कई तालिकाओं में फैला सकते हैं। यह आपको अधिक जटिल डेटा के साथ काम करने, पुनरावृत्ति से बचने, और डेटा का पता लगाने के तरीके में लचीलापन प्रदान करता है। आइए रिलेशनल डेटाबेस की अवधारणाओं का अन्वेषण करें। ## [पूर्व-व्याख्यान क्विज़](https://ff-quizzes.netlify.app/en/ds/quiz/8) ## यह सब तालिकाओं से शुरू होता है रिलेशनल डेटाबेस के मूल में तालिकाएँ होती हैं। ठीक वैसे ही जैसे स्प्रेडशीट में, एक तालिका स्तंभों और पंक्तियों का संग्रह होती है। पंक्ति में वह डेटा या जानकारी होती है जिसके साथ हम काम करना चाहते हैं, जैसे किसी शहर का नाम या वर्षा की मात्रा। स्तंभ उस डेटा का वर्णन करते हैं जो वे संग्रहीत करते हैं। आइए अपने अन्वेषण की शुरुआत शहरों के बारे में जानकारी संग्रहीत करने के लिए एक तालिका बनाकर करते हैं। हम उनके नाम और देश से शुरू कर सकते हैं। आप इसे निम्नलिखित तालिका में संग्रहीत कर सकते हैं: | City | Country | | -------- | ------------- | | Tokyo | Japan | | Atlanta | United States | | Auckland | New Zealand | ध्यान दें कि **city**, **country** और **population** जैसे स्तंभ नाम संग्रहीत डेटा का वर्णन करते हैं, और प्रत्येक पंक्ति में एक शहर के बारे में जानकारी होती है। ## एकल तालिका दृष्टिकोण की कमियाँ संभावना है कि ऊपर की तालिका आपको अपेक्षाकृत परिचित लगे। आइए अपने बढ़ते डेटाबेस में कुछ अतिरिक्त डेटा जोड़ें - वार्षिक वर्षा (मिलीमीटर में)। हम 2018, 2019 और 2020 वर्षों पर ध्यान केंद्रित करेंगे। यदि हम इसे टोक्यो के लिए जोड़ें, तो यह कुछ इस तरह दिख सकता है: | City | Country | Year | Amount | | ----- | ------- | ---- | ------ | | Tokyo | Japan | 2020 | 1690 | | Tokyo | Japan | 2019 | 1874 | | Tokyo | Japan | 2018 | 1445 | आप हमारी तालिका के बारे में क्या नोटिस करते हैं? आप देख सकते हैं कि हम शहर के नाम और देश को बार-बार दोहरा रहे हैं। यह काफी संग्रहण स्थान ले सकता है, और कई प्रतियां रखना ज़रूरी नहीं है। आखिरकार, टोक्यो का केवल एक नाम है जिसमें हम रुचि रखते हैं। ठीक है, कुछ और प्रयास करते हैं। प्रत्येक वर्ष के लिए नए स्तंभ जोड़ते हैं: | City | Country | 2018 | 2019 | 2020 | | -------- | ------------- | ---- | ---- | ---- | | Tokyo | Japan | 1445 | 1874 | 1690 | | Atlanta | United States | 1779 | 1111 | 1683 | | Auckland | New Zealand | 1386 | 942 | 1176 | हालांकि इससे पंक्ति की पुनरावृत्ति से बचा जाता है, यह कुछ अन्य चुनौतियाँ जोड़ता है। हमें हर नए वर्ष के लिए अपनी तालिका की संरचना को संशोधित करना होगा। इसके अलावा, जैसे-जैसे हमारा डेटा बढ़ता है, वर्षों को स्तंभ के रूप में रखना मान निकालने और पुनः प्राप्त करने को जटिल बना देगा। इसीलिए हमें कई तालिकाओं और संबंधों की आवश्यकता होती है। अपने डेटा को अलग करके हम पुनरावृत्ति से बच सकते हैं और अपने डेटा के साथ काम करने में अधिक लचीलापन प्राप्त कर सकते हैं। ## संबंधों की अवधारणाएँ आइए अपने डेटा पर वापस जाएं और तय करें कि हम चीज़ों को कैसे विभाजित करना चाहते हैं। हम जानते हैं कि हम अपने शहरों के नाम और देश संग्रहीत करना चाहते हैं, इसलिए यह शायद एक तालिका में सबसे अच्छा काम करेगा। | City | Country | | -------- | ------------- | | Tokyo | Japan | | Atlanta | United States | | Auckland | New Zealand | लेकिन अगली तालिका बनाने से पहले, हमें यह पता लगाना होगा कि प्रत्येक शहर को कैसे संदर्भित किया जाए। हमें किसी प्रकार का पहचानकर्ता, आईडी या (तकनीकी डेटाबेस शब्दों में) एक प्राथमिक कुंजी चाहिए। प्राथमिक कुंजी एक मान है जिसका उपयोग तालिका में एक विशिष्ट पंक्ति की पहचान के लिए किया जाता है। जबकि यह स्वयं किसी मान पर आधारित हो सकता है (उदाहरण के लिए, हम शहर का नाम उपयोग कर सकते हैं), यह लगभग हमेशा एक संख्या या अन्य पहचानकर्ता होना चाहिए। हम नहीं चाहते कि आईडी कभी बदले क्योंकि इससे संबंध टूट जाएगा। अधिकांश मामलों में प्राथमिक कुंजी या आईडी एक स्वचालित रूप से उत्पन्न संख्या होगी। > ✅ प्राथमिक कुंजी को अक्सर PK के रूप में संक्षिप्त किया जाता है ### cities | city_id | City | Country | | ------- | -------- | ------------- | | 1 | Tokyo | Japan | | 2 | Atlanta | United States | | 3 | Auckland | New Zealand | > ✅ आप देखेंगे कि इस पाठ के दौरान हम "id" और "primary key" शब्दों का परस्पर उपयोग करते हैं। यहां की अवधारणाएँ DataFrames पर भी लागू होती हैं, जिन्हें आप बाद में अन्वेषण करेंगे। DataFrames "primary key" शब्दावली का उपयोग नहीं करते हैं, लेकिन आप देखेंगे कि वे इसी तरह व्यवहार करते हैं। हमारी cities तालिका बनने के बाद, आइए वर्षा को संग्रहीत करें। शहर के पूर्ण विवरण को दोहराने के बजाय, हम id का उपयोग कर सकते हैं। हमें यह भी सुनिश्चित करना चाहिए कि नई बनाई गई तालिका में भी एक *id* स्तंभ हो, क्योंकि सभी तालिकाओं में id या प्राथमिक कुंजी होनी चाहिए। ### rainfall | rainfall_id | city_id | Year | Amount | | ----------- | ------- | ---- | ------ | | 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 | ध्यान दें कि नई बनाई गई **rainfall** तालिका के अंदर **city_id** स्तंभ है। इस स्तंभ में वे मान होते हैं जो **cities** तालिका में आईडी को संदर्भित करते हैं। तकनीकी रिलेशनल डेटा शब्दों में, इसे **foreign key** कहा जाता है; यह किसी अन्य तालिका की प्राथमिक कुंजी है। आप इसे बस एक संदर्भ या पॉइंटर के रूप में सोच सकते हैं। **city_id** 1 टोक्यो को संदर्भित करता है। > [!NOTE] > विदेशी कुंजी को अक्सर FK के रूप में संक्षिप्त किया जाता है ## डेटा पुनः प्राप्त करना हमारे डेटा को दो तालिकाओं में विभाजित करने के बाद, आप सोच रहे होंगे कि हम इसे कैसे पुनः प्राप्त करते हैं। यदि हम MySQL, SQL Server या Oracle जैसे रिलेशनल डेटाबेस का उपयोग कर रहे हैं, तो हम एक भाषा का उपयोग कर सकते हैं जिसे Structured Query Language या SQL कहा जाता है। SQL (जिसे कभी-कभी sequel भी कहा जाता है) एक मानक भाषा है जिसका उपयोग रिलेशनल डेटाबेस में डेटा पुनः प्राप्त करने और संशोधित करने के लिए किया जाता है। डेटा पुनः प्राप्त करने के लिए आप `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 ``` ## डेटा जोड़ना अब तक हमने एक ही तालिका से डेटा पुनः प्राप्त किया है। अब हम दोनों **cities** और **rainfall** से डेटा एक साथ लाना चाहते हैं। इसे *जोड़ने* के द्वारा किया जाता है। आप प्रभावी रूप से दोनों तालिकाओं के बीच एक जोड़ बनाएंगे, और प्रत्येक तालिका के एक स्तंभ के मानों को मिलाएंगे। हमारे उदाहरण में, हम **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** द्वारा जोड़ना चाहते हैं। अब हम केवल वर्ष 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) ## समीक्षा और स्व-अध्ययन [Microsoft Learn](https://docs.microsoft.com/learn?WT.mc_id=academic-77958-bethanycheum) पर कई संसाधन उपलब्ध हैं ताकि आप SQL और रिलेशनल डेटाबेस अवधारणाओं का अन्वेषण जारी रख सकें - [रिलेशनल डेटा की अवधारणाओं का वर्णन करें](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) का उपयोग करके किया गया है। जबकि हम सटीकता के लिए प्रयासरत हैं, कृपया ध्यान दें कि स्वचालित अनुवादों में त्रुटियाँ या अशुद्धियाँ हो सकती हैं। मूल दस्तावेज़ अपनी मूल भाषा में ही अधिकारिक स्रोत माना जाना चाहिए। महत्वपूर्ण जानकारी के लिए, पेशेवर मानव अनुवाद की सलाह दी जाती है। इस अनुवाद के उपयोग से उत्पन्न किसी भी गलतफहमी या गलत व्याख्या के लिए हम जिम्मेदार नहीं हैं।